Wednesday July 25 2001

Part II ? ebXML and Web Services

The Way to Do Business

Romin Irani

In part I of our series of articles on ebXML (electronic business XML), we introduced ebXML and the steps that an organization needs to take in order to start doing electronic business based on ebXML. In this article, we will look at how ebXML enables us to implement Web Services protocols, such as WSDL (Web Services Definition Language), UDDI (Universal Description, Discovery and Integration) and SOAP (Simple Object Access Protocol).

Web Services

Web Services are the new wave in software development. In short, Web Services are software components that can be housed in an application on a local network or the Internet, and are accessible by applications that are connected to the above. Let us recall the Web Services Programming Model. We will not go into the technical details of the programming model, but list the three areas that this model covers to provide a context for the sections to follow. These three areas are:

Web Service Description

A Web Service has to be described to allow organizations to use it. WSDL is used to describe a Web Service. The description of a Web Service indicates this Web Service?s functions, such as the input/output parameters and transport protocols.

Web Service Publication and Discovery

An organization needs to publish the Web Services that they own, for other organizations to discover them. Universal Description, Discovery and Integration (UDDI) specification is used to publish a Web Service to a central UDDI Repository. Other organizations can then perform UDDI operations to access the UDDI Repository, and discover Web Services that are of interest to them.

Web Service Invocation

Once an organization has discovered a Web Service via the UDDI interface, and has made a decision to use it in their application, they need to invoke the Web Service. The Web Service invocation is done via SOAP over HTTP.

How can an organization take the Web Services Programming Model and apply it to real world business scenarios, without sacrificing inter-operability with applications from other organizations?

As we saw in An Introduction to ebXML, ebXML is a standard specification that provides guidelines for doing electronic business. ebXML provides actual business processes that mimic how most of the organizations would do business transactions. We will now look at how the Web Services Programming Model (outlined above) fits in with the functional architecture of ebXML. The programming model will help organizations design their own framework, integrating technologies such as WSDL, UDDI and SOAP, within the standard specification ebXML.

ebXML Architecture

The diagram below shows a functional service view of an ebXML system. The system is described in detail in the ebXML Technical Architecture Specification, available at http://www.ebxml.org/. The diagram below has been modified to help understand this system better. We are interested in the functional service view, as that view is associated with implementation details. The implementation technologies that we have at hand are WSDL, UDDI and SOAP.

Let us first look at how this functional service view of an ebXML system works in general, and how technologies such as WSDL, UDDI and SOAP fit in to it.

From our introductory article, we recollect that the ebXML Repository is a collection of business processes; that is, business scenarios that apply to most businesses. In our example, organization A is a supplier of Web Services and interested in enabling its existing Legacy Application to conform to ebXML standards. To do this, organization A exposes its Legacy Application as a Web Service, and, in doing so, makes its Web Services available to other organizations.

This is how organization A would adapt their system to ebXML standards (we?ll keep referring to the diagram):

• Organization A downloads the ebXML specs, i.e. the business process models and business scenarios, and look at the specifications.
• After organization A has looked at the specifications, it determines which business processes best fit the needs of their business. This means that an organization can implement only a subset of the business processes that it can engage. If an organization does not find a perfect fit with the business process defined in the specifications, it can modify an existing business process.

• Once organization A has determined the business processes it can support, it starts building an application to support the understood ebXML standards.This application defines the Service Interfaces that other organizations can invoke. It also describes the input and output messages that will be given to the service. Organization A already has an Internal Legacy Application, and so all they have to do is create an implementation wrapper around their Legacy Application, to help it understand ebXML messages.

  Once these interfaces have been built and all details necessary for other organizations to invoke organization A?s services are available, all this has to be packaged in what is, in ebXML terminology, known as the Collaboration Protocol Profile (CPP). This Profile will then have to be published to the ebXML Repository for other organizations to discover it. If any of the ebXML specifications change in the future, organization A would have to reevaluate them and appropriately implement them in their application.

  Note: Based on the above three steps, let us identify the relations between the Web Services Programming Model and ebXML.

  In the Web Services Programming Model, WSDL is used to describe a Web Service. In the ebXML spec, on the other hand, CPP is used to describe the same Web Service. WSDL provides information about a service name, parameters for that service and the endpoint to invoke it. CPP not only produces this information, but also other important parameters, such as the role of an organization in the context of a particular service, error-handling and failure scenarios.

  In essence, the ebXML business process schema is a more rigorous definition of a Web Service than simply a WSDL document. It not only identifies business processes but also, for instance, the roles that an organization has to play and messages being exchanged.

  UDDI is used in the Web Services Programming Model to publish Web Services to a global UDDI Repository. In ebXML we use a Registry Service Interface to publish an organization?s CPP.

• Organization B has followed the same steps as organization A in enabling their Legacy Application for ebXML. However, they are in need of a particular Web Service and are interested in discovering organizations providing that very Web Service. Let us assume that organization A did provide the Web Service organization B wants, and has published details about it using CPP.

  Note: The discovery of a business that provides a desired Web Service, and the downloading of its CPP will be done via the ebXML Registry Service. However, one may be confused whether to use UDDI or the ebXML Registry Service to look for a Web Service. UDDI is used to publish and discover Web Services; ebXML Registry Services, on the other hand, both publish and discover Web Services, and provide information about, for instance, business processes, business documents and business profiles. However, both systems can be used complementary; organizations can continue to use UDDI to inquire about businesses in the global UDDI Registry. Those entries can then be used in referring to ebXML Web Services in the ebXML Registry.

• Organization B looks in the ebXML Repository for possible organizations providing a particular Web Service, and downloads organization A?s CPP. The CPP gives enough detail on what organization A?s Web Service provides, messages that flow in and out from its Web Service and how to invoke this particular Web Service.
• When organization B has decided that they are interested in using organization A?s Web Service, the next step is for both organizations to come up with an agreement. Key employees from both organizations will now have to meet in person to chalk out the details for a business agreement. The details involve, for instance, the business process requirements of both organizations and the messaging protocols to use. Once an agreement has been reached, the organizations develop and settle a Collaboration Protocol Agreement (CPA), which includes all of the agreed-upon terms. The CPA, as shown in the diagram, has derived from the capabilities of both organizations (described by the CPP). The CPA is mutually agreed upon by both organizations and will then serve to govern the transactions between the two organizations.

• The final step is the actual transactions between the two companies. The PayLoad, i.e. messages, are exchanged between the two organizations and they are governed by the CPA defined above. The messages are transported in a standard manner using the secure and reliable ebXML Messaging Service.

  Note: In the Web Services Programming Model, once we have the WDSL for a particular Web Service, we can invoke that Web Service using SOAP and HTTP. In ebXML, on the other hand, we need to use the ebXML Messaging Service, which will provide a uniform way of sending messages. The ebXML Messaging Service utilizes SOAP and HTTP (it also allows for attachments). The ebXML Messaging Service will thus provide a standardized way to send messages to trading partners. It not only provides a secure and reliable transport infrastructure based on SOAP and HTTP, but, also, makes sure that the CPA governs any business transactions.

Conclusion

In this article, we have made clear the relation between the Web Services Programming Model and the emerging global electronic business standard, ebXML. Most organizations are eager to jump onto the Web Services bandwagon but they also need to maintain standards to ensure inter-operability between their applications and their trading partners' applications. We have, further, explained how organizations can take Web Services technologies like WSDL, UDDI and SOAP and understand their application within the realm of an electronic business standard such as ebXML. Unless Web Services technologies are applied within the context of standards such as ebXML, we will end up with simple, stateless Web Services, and not the complex and collaborative business transactions that organizations need.

This article is an extract from Web Services Business Strategies and Architectures. Buy the book from Amazon.com

Read other articles by Romin Irani: Part I - An Introduction to ebXML and Practical Considerations In Implementing Web Services.

Romin Irani is a Senior Software Engineer at InSync Information Systems, Inc in Fremont, California. He is also the co-author of Professional Java Web Services from Wrox Press.