Building a Real-World Web Service - Part 2

Building a Real-World Web Service - Part 2

No, Web services isn't just hype. This series of articles will show you that Web services are real and can provide great benefits to organizations today. The series demonstrates how to build a real-world Web service by combining the features of Web services with components and knowledge of RosettaNet, an industry leader in e-business process standards.

I use WSDL (Web Service Description Language) and BPEL4WS (Business Process Execution Language for Web Services) to create Web services definitions for RosettaNet PIPs (Partner Interface Processes), and then use BPWS4J (Business Process Execution Language for Java Runtime) to implement these definitions. In this article, I will define the choreography for the real-world Web service by creating a BPEL4WS process that utilizes the Web service defined in Part 1. This article is all about choreographing the e-business dialogue, so put on your dancing shoes...the party's just begun.

Add a Little BPEL
In Part 1 (Vol. 4, issue 2), I showed you how to build a WSDL definition for a RosettaNet PIP. Along the way I discussed the true value of Web services, which is revealed in how they enable organizations to focus on services, and provide partners and customers access to these services through open and accessible public interfaces. I also talked about e-business dialogues and how to use the RosettaNet specification in Web services to conduct them. I ended the article by building a WSDL definition of the purchase order PIP from RosettaNet. In this installment, I'll take the real-world Web service definition further by adding BPEL4WS (written as BPEL from this point on) to the mix and defining an abstract process based on the WSDL definition. This abstract process will serve as a basis of the e-business dialogue definition that business partners will use to conduct e-business.

I need to add choreography definitions to the e-business dialogue I'm building for the real-world Web service. The choreography will describe how processes and partners will interact with each other. These interactions exceed the limited functionality offered by the message exchange patterns available in the WSDL, which is why I'm using BPEL to pick up where WSDL left off.

The choreography information is central to the e-business dialogue, and there is a strong need for choreography languages to compose standard messages into meaningful, long-running e-business dialogues that can be used to conduct complete business scenarios. Choreography languages become more relevant as organizations begin to conduct e-business through their digital representations; it's simply not enough to have common message definitions (like those specified by EDI) and leave the choreography aspect of the dialogue to be handled over the phone or in face-to-face meetings. E-business dialogues are about interactions between digital representations of the business, and these representations need concrete choreography definitions (see Figure 1).

The Digital Representation of a Business
I have been talking about creating e-business dialogues between business partners. In my informal definition of the term, an e-business dialogue is two or more partners accomplishing a business goal (e.g., buying and selling goods) by conducting a dialogue between their digital representations. What are digital representations? In the crudest terms, a digital representation can be thought of as the computer systems of an organization that a business partner's application can connect to.

A better way to think about digital representation is to think about how an organization conducts business in the physical realm. Typically, the organization provides partners and customers access to its services through its physical representation (e.g., a storefront or an office building). Similarly, when this organization is conducting e-business in the digital realm (over the Web), it provides access to its services through its digital representation. This representation is more than access to databases, or connecting software systems. Organizations need an overall strategy for building service-based architectures, including digital representations reflective of their services.

As more organizations conduct e-business dialogues, they'll need to understand how the various e-business process and choreography languages work. Even at this early stage, there are several choreography languages to choose from, and the task can be daunting. To help in this cause, this article provides information about how BPEL, RosettaNet, and ebXML handle e-business dialogues and choreography.

Choreography Languages for E-Business Dialogues
The e-business dialogue is known by many names in the various choreography and business process languages; Table 1 relates these definitions.

To understand what role Web services, ebXML, and RosettaNet play in the e-business dialogue, see Figure 2, which originally appeared in "The Truth About Web Services," a report by Ted Schadler of Forrester Research (used with permission).

This section describes how the e-business dialogue and choreography are handled in more mature e-business languages like RosettaNet and ebXML. Currently, several languages deal with creating choreography using Web services (WSCI, WSCL, and BPEL); from this group I will explore BPEL.

RosettaNet standardizes common e-business dialogues, capturing industry best practices for conducting business processes in the form of PIPs, which greatly reduce the setup time for starting a dialogue between business partners. RosettaNet specifications include the e-business dialogue specifications (the PIP), dictionaries that standardize usage of the terms used in messages, and an implementation framework that describes how to pack, unpack, and transport messages.

Here's how business partners conduct an e-business dialogue using RosettaNet: in order to conduct RosettaNet PIPs, both partners need to adhere to the RosettaNet implementation framework that describes how to pack and transport messages using open standards like HTTP and S-MIME. The e-business dialogue setup is simple - the partners agree on which RosettaNet e-business dialogue (PIP) to use, and they start conducting the dialogue over the Internet by exchanging secure XML-based messages. The PIP specifies a public process, the choreography of messages, definitions of the messages, definitions of process success and failure, and what to do when faced with exceptions.

EbXML is built upon the experience and knowledge of EDI and RosettaNet, and in a sense, it combines the best of both worlds. EbXML standards include the BPSS (Business Process Specification Schema) to define e-business dialogues, a transport and routing specification, capability profiles that describe what e-business dialogues an organization can conduct, and a registry to store specifications and capability profiles. EbXML has received a boost from RosettaNet as well, as RosettaNet has expressed interest in using the ebXML BPSS and messaging services to define and execute PIPs.

To conduct a typical e-business dialogue with ebXML, business partners need to have implemented the ebXML infrastructure, and they should have registered a capability profile with the ebXML registry. This profile expresses the partners' ability to conduct an industry-standard e-business dialogue written in the ebXML BPSS. To conduct an e-business dialogue, the partners would find each other's capability profile on the registry and form an agreement about which dialogues they will conduct. These dialogues can be simple (like RosettaNet PIPs), or elaborate compositions of other dialogues. All messages are XML-based, packaged with S-MIME and a little bit of SOAP, and exchanged in a secure manner over public networks like the Web.

Web services choreography languages
The Web services choreography languages are built on top of the WSDL specifications. Reusing the operations and transport information, they focus on providing choreography by composing stateless Web services into state-aware e-business dialogues. Figure 3 relates RosettaNet, ebXML, and Web services choreography languages.

Choreography languages like WSCI, WSCL, and BPEL are all trying to do the same thing - make Web services more useful for business, even though what they do may be known by different names (e.g., orchestration, composition, choreography, flow). In the current languages, BPEL seems to have a lot of momentum; it is the focus of the rest of this article.

To conduct an e-business dialogue using the WSDL and BPEL combination, the partners must have a Web services framework implemented. They could then construct a mutually agreeable e-business dialogue definition using the abstract process feature in BPEL. The partners can reuse existing Web services for this e-business dialogue, and create new Web services where necessary. Currently, the partners would have to define everything in the dialogue, including the vocabulary used, the messages exchanged, the choreography of the messages, and the definition of the business process. Hopefully, in the near future partners won't have to keep reinventing the wheel and can benefit from standardized processes that include standard vocabulary, messages, and choreography. This series of articles demonstrates how partners can utilize standardized processes defined by RosettaNet when defining Web services with WSDL and BPEL.

Exploring BPEL
BPEL can be used to create e-business dialogues by "composing" new and previously defined Web services. BPEL is the marriage of two rival specifications: WSFL from IBM, and XLANG from Microsoft. BPEL comes with a few complementary specifications, WS-Transaction and WS-Coordination, that take the BPEL process further by adding more transaction support and enabling processes to span different platforms, systems, and execution engines.

BPEL defines the choreography of Web services and the roles of the business partners involved in the process, and may include advanced features like exception and compensation handling for actions already performed. BPEL processes interact with new and previously defined Web services on any platform running within, or outside, a BPEL environment.

Two types of processes are defined in BPEL: abstract processes, which are the equivalent of defining public processes in an e-business dialogue, and executable processes, which run within the organization. The main difference between the two is that abstract processes cannot be executed; they are utilized as an agreement between two partners about how they will interact in the e-business dialogue. The abstract processes only define public processes and do not include what each organization does internally to conduct those public processes.

The executable process, on the other hand, is designed for executing business processes within an organization. It can link several Web services together, tie in business logic, and access sensitive data to achieve a business goal for the organization.

BPEL components
Figure 4 shows the process element definition in BPEL from the schema design view of XMLSPY. I am building the BPEL abstract process definition for a purchase order e-business dialogue and will be reusing WSDL definitions of the RosettaNet PIP3A4 defined in Part 1. I will explain BPEL in more detail as I build the BPEL definition of the e-business dialogue. The first element I have to define is the root element <process>:

<process name="loanApprovalProcess"

This process is the definition of the e-business dialogue between two business partners; this definition deals only with the public interactions between the two partners and not how they handle the business inside their organizations. This type of definition in BPEL is called an abstract process, and you can see that the attribute "abstractProcess" is set to "yes" to indicate this.

The process I'm currently describing is a synchronous process, assuming that when the buyer makes a purchase order request, the seller will be able to reply promptly with the answer. I will describe the more realistic, and slightly more involved, asynchronous process in Part 3, which focuses on creating and implementing more elaborate e-business dialogue definitions. Table 2 shows BPEL process components.

At a conceptual level, a BPEL process interacts with partners to receive, invoke, and reply to activities. These partners can be Web services within the organization or Web services at the business partner's organization. A process definition begins with describing which parties (Web services) are involved and what role they play. The most important part of the partner description is the service link type; it is a mechanism used to tie the partner description to the operations the partners can perform from the WSDL definition.

To begin the partner definition in my BPEL process, I first need to add a service link type to the WSDL definition I defined in the previous article. I need to add the following to the <wsdl:definitions> element:


The next step is to add the service link type as an immediate child of the <wsdl:definitions> element:

<slnk:serviceLinkType name="purchaseOrderRequestLT">
<slnk:role name="seller">
<portType name="QuoteAndOrderEntryPort"/>

Having updated the WSDL definition in the QuoteAndOrderEntry.wsdl file, I can start adding to my BPEL definition by using the service link defined above to compose a partner definition as follows (source code for PurchaseOrderProcess.bpel and QuoteAndEntry.wsdl is available for download at

<partner name="buyer"
<partner name="seller"

This definition is straightforward. There are two partners to the process: the customer and another internal Web service acting as a seller to the process. The first partner definition shows that the process is a seller and offers the customer the functionality defined in the QuoteAndOrderEntryPort. The second partner definition shows that the process is dealing with a partner (the internal Web service), which is the seller to the process.

The BPEL process uses containers to store state information such as temporary variables or incoming and outgoing messages. A container is really a WSDL message type and can be defined as an input or output container within invoke, receive, and reply activities. Here is the definition of the container for the process I'm defining:

<container name="requestPO" messageType="PO:placePuchase
<container name="processedPO"

Correlation sets
A correlation set makes it possible for messages to be addressed to the correct port Type, and more importantly, the correct instance of the process. A partner may be executing various processes with several partners, and it's important that the message exchanged within the processes go not only to the right partner and the right port Type, but also to the precise instance of the business process, since the partner might have instantiated several instances of the process. Correlation is an advanced feature for this installment and will be addressed in the next part of the series.

Fault handlers, compensation handlers, and scope
When a fault occurs at a WSDL port, it may fire off a fault message. This fault message reaches the BPEL process, which uses fault handlers to determine how to recover from the fault. One possible recovery option is to "undo" what the process has done so far. This recovery depends on how far the process had progressed when the fault occurred, and the best way to determine that is to use the scope structured activity.

The scope activity defines fault handlers for a collection of activities. Each activity is nested within a catch clause, and if a fault occurs, a fault handler for the activity handles the fault. The fault handler uses compensation handlers to undo actions that have already been committed. The scope activity ensures that either all activities defined within the scope will complete successfully, or all activities are "compensated."

To enable compensation handlers, partners need to provide an "undo" operation for every "do" operation. For example, if an operation from SafeAirlines allows "BuyTicket", SafeAirlines must also provide a "CancelTicket" operation. I'm not using fault handlers or compensation handlers for the process in this installment, so it's time to move on to activities, where all the action takes place.

A BPEL process uses activities to choreograph Web services into longer-running e-business dialogues.

BPEL provides a collection of basic and structured activities to use in a process. The difference between the two types of activities is that a basic activity cannot enclose other activities, while a structured activity encloses a collection of activities. The basic activities are: empty, invoke, receive, reply, assign, wait, throw, and terminate. Structured activities are: flow, switch, while, sequence, pick, and scope.

The process interacts with other Web services with invoke, receive, and reply activities, and these are the activities we will use in the current installment of the article. A BPEL process allows only one activity per process, so if you need to conduct a collection of activities, you can use a structured activity to enclose the collection. I will use the sequence activity to provide a sequential order to conduct the activities. The e-business dialogue described here receives a purchase order request from a buyer and replies to the buyer with a purchase order confirmation.

<receive name="PORequest" partner="buyer"
operation="requestPurchaseOrder" container="requestPO"

The definition above tells the process to monitor the given port Type for the specified operation conducted by the described partner. When the process receives a message matching these three criteria, it searches for the correct active "receive activity" and passes the received message to it. In our case, the receive activity stores the message in the requestPO container and ends execution. The sequence activity passes the execution control to the next activity in the sequence, the invoke activity. A BPEL process can be created only if the first activity in the process is the receive activity with the createInstance attribute set to "yes".

The process now moves to the next step - invoking an internal Web service with the inventory department, which goes over the purchase order request item by item, marking each with a status of "accepted", "rejected", or "pending". The inventory Web service receives the purchase order it needs to process through an input container and it places the processed purchase order in the output container. Since the workings of this Web service are not a public process, the details on how it works are not provided in the abstract process. Here is how the invoke activity is described:

<invoke name="POApprover"

The next step is to add a reply to the sequence activity definition. The process receives the processed purchase order from the inventory Web service through the processedPO container. It replies to the buyer's request by sending the buyer the processed purchase order. This is the definition for the reply:

<reply name="POResponse" partner="buyer"
operation="requestPurchaseOrder" container="processedPO">

We now have a simple BPEL definition of a RosettaNet PIP. However, we are just getting started...Part 3 is all about implementation. I'll build detailed abstract and executable asynchronous processes describing entire business scenarios, composed of several RosettaNet PIPs, and show you how to implement the BPEL processes using BPWS4J. Part 3 implements all the concepts and definitions covered in Parts 1 and 2. It promises to be an exciting ride!

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.