- The Basics of Web Services
- A Simple Example: Searching for Information
- The Next Generation of the Web
- Interacting with Web Services
- The Technology of Web Services
- XML for Business Collaboration: ebXML
- Web Services versus Other Technologies
- Additional Technologies
- Vendor Approaches to Web Services
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
XML for Business Collaboration: ebXML
As previously mentioned, several additional technologies, beyond what's provided in the basic Web services technologies, are required to support true business-to-business interaction over the Web. The Electronic Business XML (ebXML) consortium, for example, has defined a comprehensive set of specifications for an industrial-strength usage pattern for XML document exchange among trading partners. The ebXML messaging specification is based on SOAP with Attachments and does not use WSDL but does add several qualities of service, such as security, guaranteed messaging, and compliance with business process interaction patterns.
The ebXML initiative, the first phase of which ended in May 2001, was sponsored by an international group established by the United Nations Center for Trade Facilitation and Electronic Business (UN/CEFACT) and OASIS to research, develop, and promote global standards for the use of XML to facilitate the exchange of electronic business data.5 The ebXML architecture begins with a business process and information model, maps the model to XML schemas, and defines requirements for applications that process the documents and exchange them among trading partners.
Web Services and EDI versus ebXML
Although electronic data interchange (EDI) has been around for more than two decades, it is very complex, has multiple interpretations, and requires significant technical expertise to deploy, and it is based on a tightly coupled, inflexible architecture. Although they can be deployed on public networks, EDI applications are most often used on expensive dedicated networks and require a lot of expertise to set up and run.
By contrast, ebXML and Web services hold the promise of realizing the original goals of EDI, making it simpler and easier to exchange electronic documents over the Internet. However, ebXML and Web services also will have to mature for several years before they encompass all EDI's current functionality and feature set.
Although the ebXML consortium has completed its initial work, OASIS, UN/CEFACT, and other organizations continue to promote the adoption of the architecture and specifications to a broader audience, hoping to establish a global e-business marketplace through the standardized exchange of XML documents and messages, regardless of geographic or political boundaries, and with the qualities of service that businesses expect. The ebXML architecture defines
Business processes and their associated messages and content
A registry and discovery mechanism for publishing business process sequences with related message exchanges
Company profiles
Trading-partner agreements
A uniform message transport layer mapped to SOAP with multipart MIME attachments
Similarly to the way in which UDDI facilitates a search for Web service definitions, the ebXML architecture allows businesses to find one another by using a registry, to define trading-partner agreements, and to exchange XML messages in support of business operations. The goal is to allow all these activities to be performed automatically, without human intervention, over the Internet. The ebXML architecture has many similarities to SOAP/WSDL/UDDI, and some level of convergence is already taking place with the adoption of SOAP in the ebXML transport specification.6 RosettaNet also announced its adoption of the ebXML transport, as have many other vertical industry consortia.
The ebXML architecture clearly centers on document-oriented interactions; as ebXML gains acceptance, it may come to define the paradigm for B2B-oriented Web service interactions. Companies that already have been exchanging information electronically, perhaps using EDI standards, will find many parallels in the goals of ebXML, although ebXML aims at addressing this type of requirement more broadly and for the Internet.
Comparison of ebXML and SOAP
Initially, it seemed that the ebXML group was competing with the group of companies sponsoring SOAP, WSDL, and UDDI. In fact, the ebXML specifications cover a lot of the same territory as SOAP, WSDL, and UDDI. You could view the SOAP effort at W3C as a "bottom-up" approach, starting with a definition of the way to map XML documents to HTTP messages, and look at the ebXML effort as a "top-down" approach, starting with a definition of the business process as a series of messages mapped to any transport.
The ebXML group was formed primarily to create business process standards, the areas in which the work of ebXML has the most promise. The areas of transport, services description, and registry seem more appropriate to efforts focused more purely on issues of infrastructure than of business process and document interaction. One of the major motivators for ebXML is to produce standards that serve the same or similar purpose as EDI, including support for emerging industry-specific XML "vocabularies." It seems appropriate to consider the ebXML architecture as requirements on W3C and other XML-oriented initiatives as a way of ensuring that Web services will be ready for real business use, rather than as a competitive effort to define core infrastructure services.