Related Topics: Pharmaceutical News

Pharmaceuticals: Article

Building a Real-World Web Service - Part 1

Building a Real-World Web Service - Part 1

The answer is yes; Web services can be used to conduct real business, and this series of articles will show you how. In this installment, the first in a three-part series, I'll show you how to conduct an e-business dialogue, explain RosettaNet specifications, and create a Web service definition based on RosettaNet messages. Your organization can benefit from this real-world Web service, read on to discover how.

Are We There Yet?
Are widespread Web services a distant dream? While some analysts claim that lack of security and maturity are the reasons that real use of Web services is about 5-10 years away, I believe that real Web services are much closer, and they offer us great opportunity even today; we just have to be smart and creative about them. Rest assured, Web services are not just a vague notion, they can solve problems today, and they offer attractive features like the use of open standards such as WSDL and SOAP, and the reuse of existing Web infrastructure including hardware, software, and expertise. Most important, Web services are not venturing into unchartered territory; they benefit from lessons learned from tried-and-trusted e-business standards like RosettaNet and OAGIS.

However promising and appealing Web services appear, many organizations are hesitant to commit funds to Web service projects. "Show me the money," that famous line from Jerry Maguire, seems to be on every battle-weary manager's lips. This is a valid demand, and I believe we can provide this proof by building Web services that focus on reducing costs and saving time for existing business problems, rather than focusing on new business models enabled by Web services.

My goal is to build a real-world Web service that enables e-business dialogue between business partners. For this article, I'm applying Web services to solve the real business problem of purchase order management, a common activity in the business world and well suited for automation. The RosettaNet Web site (www.rosettanet.org) contains case studies that prove the benefits of implementing this activity as an e-business process. For example, Intel recently announced that it has used RosettaNet e-business processes to conduct over 10% of its selling and purchasing. That's more than $5 billion dollars worth of transactions. The Web service I'm constructing in this article is based on this proven RosettaNet specification, and you can easily show your manager "the money," the ROI, the business case, and anything else he or she might need.

Uncovering the True Value of Web Services
In the simplest sense, Web services allow us to define services with a very accessible and technology-neutral public interface. This interface is defined in XML-based WSDL (Web Service Description Language) and may be accessed (among other options) via the Web infrastructure using XML-based SOAP (Simple Object Access Protocol) messages. I will now explain why these simple features are causing so much excitement.

Web services are a revolution in the relationship between business and information technology. This revolution enforces a few points about e-business (see Figure 1):

  • E-business is less about "e" and more about business.
  • The public interface of an e-business puts services first.
  • E-business dialogue is technology agnostic.
  • Technology should assist e-business, not overpower it.
Web services are poised to bring significant change to how organizations think about e-business. While some of these changes are subtle, the results promise to be dramatic. The first change Web services bring to e-business is an intense focus on services, which is fitting, as one of the primary reasons an organization exists is to provide services to customers and partners. The second change is better communication and knowledge sharing between the different groups of an organization; Web services help everyone think "services," a shared concept. This enhanced communication helps in designing robust services and in getting the design right at the concept phase.

The most significant change in e-business is that Web services make business dialogue pretty much technology agnostic. With Web services, an organization provides access to its services through a public interface based on open standards and a common language. This separation between the public and private sides of the Web service removes technology concerns, such as OS, programming language, and platforms, from the e-business dialogue, enabling business partners with completely different technology setups for effortless communication. Removing technology considerations from the dialogue is the first step for conducting e-business dialogues; the next step is to use standardized dialogues, messages, and vocabulary (see Figure 2).

How E-Business Dialogues Work
The basis for a successful real-world Web service is the ability for business partners to conduct electronic business dialogue. Since we're talking about e-business, the dialogue is digital, and the software systems at both ends must make sense of it. A software system can really only "understand" what it has been programmed to understand, and the cost to conduct e-business dialogue can become prohibitively expensive if you have to program several interpretations of dialogues for the same business activity. For example, if you have 22 business partners with whom you buy and sell goods, if each of these partners defines a different dialogue for conducting purchase orders, you will have to implement 22 dialogues to do the same thing. This is why standard ways of describing, accessing, and processing business activities and e-business dialogue become crucial.

An e-business dialogue is the conversation that takes place between the software systems of business partners, to conduct a business activity. The dialogue can be simple or elaborate, based on the business activity that needs to be executed. For example, Acme and Laptops, Inc., conduct an e-business dialogue when Acme places a purchase order for 100 laptops with Laptops, Inc. An e-business dialogue can also be an elaborate composition of e-business dialogues. For example, Acme conducts an e-business dialogue to request marketing material from Laptops, Inc.; chooses some products and executes another e-business dialogue to request the price and availability of the chosen products from Laptops, Inc.; and finally executes an e-business dialogue to place a purchase order with Laptops, Inc. This entire sequence of business dialogues is itself part of a business dialogue.

In Figure 3, you can see a simple e-business dialogue in which Acme places a purchase order request with Laptops, Inc. You can also see the necessary components of an e-business dialogue:

  • Open and accessible public interfaces
  • Partner roles
  • Standard messages exchanged in agreed-upon choreography
  • Standard vocabulary
  • An environment of security and trust
For Acme and Laptops, Inc., to start a business dialogue, both organizations need to have public interfaces that are defined in a standard manner and accessible via Internet-based protocols. The open and accessible interface makes it possible for Acme, which has a shop based on mainframes and COBOL, to communicate effortlessly and cheaply with Laptops, Inc., which is a Java shop.

To understand roles and choreography, think of a movie script. Just like a movie script, an e-business dialogue has different roles for the business partners to play. In our example, Acme assumes the role of a buyer and Laptops, Inc., assumes the role of the seller. Like actors delivering lines from a movie script, the organizations deliver messages to each other based on the order specified in the e-business dialogue. In e-business dialogues, this concept of sequence and order is known as choreography or orchestration. In the simplest form, it creates a sequence in which the messages are exchanged. The choreography can also be used to create elaborate dialogues that orchestrate services, partners, or other e-business dialogues. I will explain this in further detail in Part 2, which deals with BPEL4WS.

Keep in mind that the business dialogue is being conducted between software systems, and since they are not very good at guessing, nothing can be left ambiguous. The messages that Acme and Laptops, Inc., exchange have a standard structure and standard vocabulary. This means that the messages must follow a defined schema, and any words used in the message must have the same meaning to both organizations. Standardizing the definition and usage of a word is important, and we see this need even in our daily lives, as everyday words may take on different meanings in different professions. For example, when I mentioned a movie script earlier, if I had used only the word "script," it might have caused confusion about the meaning given our technical backgrounds - Perl script or movie script? Similarly, while "mouse" is a small, furry animal in a pharmaceutical lab, it is a pointing device in a computer lab. It is important that when a computer lab places a purchase order for a mouse, the seller doesn't ship a rodent. Luckily, there are standards bodies that build dictionaries to standardize definitions of words used in e-business messages.

One of the most important components of a business dialogue is trust and security. When organizations conduct business in the physical realm, they sign contracts to enter legally binding agreements. In e-business, this trust is established by treating each exchanged message as a contract. The messages are stored for an agreed period, and each partner is bound to the promise made in the message. This concept is known as nonrepudiation. The partners also identify which employees are authorized to conduct the e-business dialogue, and authority and identity are verified during the e-business dialogue by inspecting digital certificates and the digital signature on the message. The messages exchanged are tamper-proof so that no third party can change the content and cause harm to either party. The messages are also transported over a secure wire to be snoop-proof, so no third party can eavesdrop on the sensitive information passing between the business partners.

What Is RosettaNet?
As I stated before, to create a real-world Web service, I need to enable an e-business dialogue. Along with open and accessible public interfaces, I need to use standardized messages, vocabulary, and choreography. Essentially, I need to take a standard e-business process and enable it in the Web services environment.

RosettaNet is an industry leader for e-business process specifications and therefore a natural choice for our real-world Web service. For the real-world Web service, I'll translate the RosettaNet PIP3A4, an e-business dialogue specification for placing purchase order requests, by modeling the messages in WSDL definitions and the choreography definition in BPEL4WS. One advantage of RosettaNet is that along with creating standards for vocabulary and messages, RosettaNet also standardizes the e-business dialogue. With previous standards, partners wishing to conduct a business dialogue would first have to see what messages they were capable of exchanging; then they would have to define their own dialogue by determining what messages need to be exchanged, and in what sequence. With RosettaNet, this knowledge is standardized, enabling partners to conduct an e-business dialogue with very little setup time and lots of reuse (see Figure 4).

RosettaNet standards have three components:

  1. PIPs (Partner Interface Processes)
  2. Dictionaries
  3. RNIF (RosettaNet Implementation Framework)
The PIPs are specifications for standard messages and choreography to conduct a specific business activity. The dictionaries standardize the words used in the messages and the RNIF contains specifications to enable trust and security in the message exchange. Our interest lies in selecting relevant components from RosettaNet and implementing them in the Web services environment. In this article I'll focus only on how to understand a PIP specification and which components we can use from it.

RosettaNet PIPs
RosettaNet PIPs create standard e-business dialogues for several business activities, such as order and inventory management, transportation, sales forecasting, and so on. The PIPs are organized in functionally logical groupings of segments and clusters. For example, the e-business dialogue we wish to conduct is PIP3A4 Purchase Order Request, found in the Quote and Entry Segment grouping, which belongs to the Order Management cluster. All PIPs are available for public download at the RosettaNet Web site.

The PIP specification package is a zipped file that contains three types of documents (see Figure 5). The specification itself is a Word document, help and guidelines for the messages are in HTML documents, and the message structure and content are captured in the XML DTDs. For the real-world Web service, I'll extract the process definition and choreography information from the UML diagram and associated tables in the PIP3A4 specification Word document, and I'll use the DTDs to help create the messages and operations.

Figure 5 shows how the Request Purchase Order PIP works. The partners exchange two messages and two receipts; the two messages are the purchase order request and the purchase order acceptance, with receipt acknowledgment signals in between to signal the receipt of messages.

I want to model the messages as WSDL operations. What's missing from the PIP package is the DTD for the receipt messages. Since this message is common to all PIPs, it's part of the implementation framework and I will pull it out of the RNIF package (also available on the RosettaNet Web site).

To model the PIP receipt and messages as WSDL operations, I need to convert the DTDs to XML Schema documents; this is a simple task since most XML authoring tools can perform this conversion for you. However, there is a small problem with the DTDs in the RosettaNet specification, due to an improper object model of the elements, and each DTD appears to be stand-alone and not part of a bigger model. Therefore, elements are at times duplicated or redefined in different DTDs. While this is not a big problem in the RosettaNet environment, in the Web services definition it becomes a problem, as the schemas from these DTDs need to be combined in the same document. RosettaNet has promised that these problems will go away when they roll out a remodeled, well-connected schema. In the two DTDs I converted to schema, I manually renamed a couple of objects and changed references to fix this problem. Having extracted the messages I want to use in our e-business dialogue, I need to translate these messages into Web service operations. The next step will be to define the business dialogue as a BPEL4WS definition.

Translating RosettaNet into WSDL
It is now time to work with WSDL, the language used for defining and describing Web services. WSDL is based on XML, and has a simple, easy-to-learn grammar. A WSDL file defines the types, messages, and operations of a Web service, as well as the message format and protocol information for these operations. The main components of a Web service definition are:

  • Types
  • Message
  • Operation
  • Port Type
  • Binding
  • Port
  • Service
I'll explain each component further as I flesh out the WSDL definition for the real-world Web service.

I first want to construct the type element of the WSDL definition. The type element is where all the data type definitions are described; these data types are later used to describe the messages in the message element. I have extracted the message DTDs from the RosettaNet PIP3A4, and after converting them to schemas and fixing the duplication problem, they are placed in the type element. Listing 1 shows what a type definition looks like.

Next, I'll create the message elements of the WSDL definition. Messages defined in this section are used within operations. Each message is composed of one or more parts, and each part is associated with a type defined earlier. I will define the following messages:

  • Purchase Order Request
  • Purchase Order Response
  • Receipt Acknowledgement
  • Exception Message
Here are a couple of the WSDL message definitions:

<wsdl:message name="placePurchaseOrderRequest">
<wsdl:part type="typens:Pip3A4PurchaseOrderRequest"
name="purchaseOrderRequest"/>
</wsdl:message>
<wsdl:message name="sendPurchaseOrderConfirmation">
<wsdl:part type="typens:Pip3A4PurchaseOrderConfirmation"
name="purchaseOrderConfirmation"/>
</wsdl:message>

Now that I've created the messages that will be used in operation elements, it's time to think of how to define the operations and port types. A port type is a set of operations, and an operation is a pattern for exchanging messages. In WSDL, you can define four types of operations:

  • One Way: The service receives a message
  • Notification: The service sends a message
  • Request/Response: The service receives a message and it replies with a message
  • Solicit/Response: The service sends a message and receives a response
Looking back at the choreography of the PIP3A4 in Figure 5, Laptops, Inc., receives a request from Acme and sends back a receipt acknowledgement. Then Laptops, Inc., sends an acceptance to Acme and receives a receipt. Since I'm implementing this service assuming the role of the seller, and the WSDL specifications indicate that WSDL currently only contains bindings for the One Way and the Request/Response, my choices for implementing the operation are limited to a Request/Response operation. This means that I'll have to forget about the receipt acknowledgement signals for the time being. With this limitation, here is how to define the port types:

<wsdl:portType name="QuoteAndOrderEntryPort">
<wsdl:operation name="requestPurchaseOrder">
<wsdl:input message="typens:placePurchaseOrderRequest"/>
<wsdl:output message="typens:sendPurchaseOrderConfirmation"/>
</wsdl:operation>
</wsdl:portType>

The next step is to define the bindings; this part describes the message format of the service as well as the protocol details for the different messages and operations. WSDL includes bindings for SOAP 1.1 and HTTP GET and POST. I will use the SOAP binding for the real-world service. Listing 2 shows how it is described.

To wrap things up, I'll define the service element here:

<wsdl:service name="QuoteAndOrderEntryService">
<wsdl:port binding="typens:QuoteAndOrderEntryBinding"
name="QuoteAndOrderEntryPort">
<soap:address location=
"http://www.DifferentThinking.com/xmlj_article/soap"/>
</wsdl:port>
</wsdl:service>

We now have the WSDL definition of our real-world Web service. In Part 2, I'll show you how to use BPEL4WS to compose a full-fledged business dialogue using the WSDL definition from this article.

More Stories By Suhayl Masud

Suhayl Masud is an experienced software architect with over 8 years of experience in designing and developing e-Business and e-Commerce systems. Suhayl recently helped RosettaNet develop the next generation of e-business processes. Suhayl has worked extensively with Java and Smalltalk, and served as an instructor and mentor for Fortune 500 companies

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.