![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
First, a recap. In Parts 1 and 2 of the series (see Resources), I claimed that the true value of Web services lies in enabling e-business dialogues between business partners. I discussed why RosettaNet is extremely relevant to building industry strength Web services, and I described how to map RosettaNet into the Web services world. In this article, I will describe the e-business dialogue further and introduce the e-business dialogue I will implement in this series.
As I mentioned earlier, the definition of a "dialogue"in the Merriam-Webster dictionary is "a written composition in which two or more characters are represented as conversing." If you examine this definition in further detail, these details are revealed:
- "a written composition..." -- The composition of the dialogue is the choreography, and every e-business dialogue needs to have one defined. Furthermore, you also need a language capable of expressing that choreography
- "...in which two or more characters..." -- These are the parties involved in the dialogue -- the business partners. The dialogue should optionally be capable of handling more than two business partners in cases where third parties need to be involved in the process. For example, a shipping or an insurance company might need to get involved in the process to complete a successful transaction.
- "...are represented as conversing." -- The organizations need to be represented in the e-business dialogue, this representation is through digital representatives.
The choreography language: BPEL4WS to the rescue
While Web Services Definination Language (WSDL) can be used to define simplistic Request/Response interactions, I cannot use WSDL with its limited capabilities to express realistic choreographies. Earlier assessments of RosettaNet and Web services focused on how WSDL can fit in the RosettaNet world. These assessments predictably found WSDL unable to express RosettaNet PIPs and therefore unsuitable. With Business Process Execution Language for Web Services (BPEL4WS), that picture has changed completely, and the RosettaNet and Web services relationship deserves a re-assessment.
As identified above, you need a language that is capable of expressing choreography, a language that can allow expressions where two or more partners can interact. That language in the Web services world is the BPEL4WS. It is highly flexible with its many logic and flow control mechanisms; it allows for multi party collaborations; and best of all, it provides a standard way for hooking up the public process to the back-end private processes.
To create a robust e-business dialogue for the RosettaNet-based Web service I am building for this series, I need to add choreography definitions to the dialogue. Choreography is an extremely important aspect of an e-business dialogue. It identifies the partners involved in the dialogue, and describes the sequence and content of the exchanges between the partners.
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 is simply not enough to have common message definitions, like those specified by EDI, and leave the choreography aspect of the dialogue to something that is handled over phone and face-to-face meetings. e-business dialogues are about interactions between digital representations of the business, and these representations need concrete choreography definitions.
Figure 1: Choreography makes Web services dance
The digital representation of a business
So, what are digital representations? Well, in the crudest terms, you can think of a digital representation as the organization’s computer systems that a business partner’s application can connect to. A better way of thinking about a digital representation is by considering how an organization conducts business in the physical realm.
Typically, the organization provides partners and customers access to its services through its physical representation (for example, a store front, or an office building). Similarly, when this organization is conducting e-business in the digital realm (for example, over the Web), it provides access to its services through its digital representation. This representation is not simply a technical issue of providing access to databases, or connecting software systems. Organizations need to think about an overall strategy of building service-based architectures, and creating digital representations reflective of their services.
As more organizations conduct e-business dialogues, they will need to understand how the various e-business processes and choreography languages work. Even at this early stage, there are several choreography languages to choose from, and this task can be daunting. To help this cause, I will now provide information about how BPEL, and the more mature standards like RosettaNet and ebXML, handle e-business dialogues and choreography.
Easing the confusion around choreography languages
The e-business dialogue is known by many names in the various choreography and business process languages, and to ease understanding, I have put together a table that relates these definitions (see Table 1).
Table 1. The e-business dialogue is known by different names
In this section, I will describe 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 (like Web Service Choreography Interface (WSCI), Web Service Choreography Language (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 Partner Interface Processes (PIPs) that 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 is 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 standards include the Business Process Specification Schema (BPSS), 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.
Now let me give you the example of how business partners 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 partner’s 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 what 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 specification, re-using 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 WS Choreography languages.
Figure 3. Understanding how RosettaNet, EbXML, and BPEL stack up
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 like orchestration, composition, choreography, or flow. In the current languages, BPEL seems to be leading the race and thus an ideal candidate for building e-business dialogues
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 definition of the business process. In the near future hopefully, partners would not have to keep re-inventing the wheel, and could benefit from standardized processes that include standard vocabulary, messages, and choreography. In this series of articles, I am demonstrating how partners can utilize standardized processes defined by RosettaNet, when defining Web services with WSDL and BPEL.
The extended e-business dialogue
Now that I have covered a lot of important issues like e-business dialogues, RosettaNet, BPEL4WS, and digital representations, it is time to start building the RosettaNet-based Web service. This Web service is a Purchase Order dialogue conducted between two business partners. The Web service is based on the RosettaNet PIP3A4.
Since BPEL4WS provides functionality further than the RosettaNet public process space, I will also demonstrate how you can hook up the public processes to your back-end private processes and applications. This means that you can actually start test-driving real data and real systems for your pilot projects.
Figure 4. The extended e-business dialogue
The extended e-business scenario that I am building in this series is illustrated in Figure 4. The extended e-business scenario works as follows: After a particularly successful day of selling laptops, the Inventory Manager application at ACME realizes the inventories are running low, and it triggers the ACME PO Requester process. The requester process then begins a public e-business dialogue with JoeLaptops Inc of placing a purchase order request.
JoeLaptops Inc receives the purchase order request from ACME and immediately sends back a message acknowledging receipt of the request. The PO Requester process at ACME receives the receipt acknowledgment and informs the Inventory Manager that the Purchase Order has been placed. The Inventory Manager returns to other activities and the PO Requester ends the request process. Meanwhile at JoeLaptops Inc, the Place PO process invokes the Sales Agent, an internal Web service, and passes ACME’s purchase order request to the Sales Agent. The Sales Agent figures out what parts of the purchase order can be fulfilled and forms a purchase order confirmation that provides a detailed line-by-line account of the items it can provide. This confirmation is then passed from the Sales Agent back to the public Place PO process at JoeLaptops.
The process at JoeLaptops then sends the purchase order confirmation to an ACME process that accepts purchase order confirmations. The ACME confirmation acceptance process invokes an internal Web service to inform the Accounts Service at ACME about the purchase. The ACME process next sends back a message acknowledging the receipt of the purchase order confirmation and concludes the purchase order e-business dialogue between ACME and JoeLaptops Inc. JoeLaptops Inc receives this receipt acknowledgement and invokes an internal Web service to its shipping department so that the order can be shipped to ACME.
In this article I have described choreography and the e-business dialogue and I have introduced digital representations as a strategic manner of providing access to services electronically. I have explored why BPEL4WS is an ideal choice for building our e-business dialogue and I introduced an elaborate e-business dialogue that I am constructing for this series.
In the next articles, to create this elaborate e-business dialogue, I will describe how to create reliable asynchronous messaging between the partners, how to bind to back-end systems with the public processes, how to create the public processes and I will also show you what tools are needed and how to install them. And of course, I will provide you the code that makes it all happen. See you in the next installation.
- Read the first two installments of this series:
- Use RosettaNet-based Web services, Part 1 (developerWorks, July 2003)
- Use RosettaNet-based Web services, Part 2 (developerWorks, July 2003)
- "Web services: An elephant in the dark" by Suhayl Masud offers additional insight on the true value of Web services.
- "Best practices for Web services: Part 1, Back to the basics" (developerWorks, October 2002) by Holt Adams et.al., is an excellent source for applying best practices to constructing Web services.
- "Business Process with BPEL4WS: all columns" (developerWorks, August 2002) by Sanjiva Weerawarana et.al. offers additional insight on writing business processes with BPEL4WS.
- "Asynchronous operations and Web services, Part 1: A primer on asynchronous transactions" (developerWorks, April 2002) by Holt Adams offers useful information on creating asynchronous Web services
- "Asynchronous operations and Web services, Part 2: Programming patterns to build asynchronous Web services" (developerWorks, June 2002) by Holt Adams offers more useful information on creating asynchronous Web services
- The RosettaNet Web site is the ideal place to find out more about the technical and business aspects of e-business dialogues
- Check out the specs referenced in this article in the developerWorks Web services specifications database.
- To find the definition of dialogue and other Web services words, check out Merriam-Webster OnLine.
Suhayl Masud is the president of Different Thinking, a consulting firm that enables organizations to understand and conduct electronic business, by providing training, architecture, and application construction services. Suhayl is also the co-founder of Agile Webservices, providing Policy Based Computing solutions. Suhayl's experience includes consulting as the lead technical architect for RosettaNet, where he helped define the next generation of e-business process standards. Suhayl would love to hear from you at: SuhaylA@DifferentThinking.com
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
