ebXML--an alternative approach to Web services.
An international group jointly sponsored by the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) and the Organization for the Advancement of Structured Information Standards (OASIS) (www.oasis-open.org.) drove the initial electronic business XML (ebXML) activity.
The ebXML group's charter was to research, develop, and promote global standards goals, based on XML to exchange business data electronically and by doing so to improve the efficiency and lower the cost of doing business worldwide. Hundreds of companies, industry organizations, vendors of software and services, and standards bodies participated in the open process that created the ebXML specifications. Anyone with a computer, an Internet connection, and an e-mail address could take part, and often did, although primarily Electronic Data Interchange (EDI) champions and large companies with sufficient capital to invest in specification drafting guided the effort. The initial eighteen-month effort began in November 1999 and ended in May 2001 with the publication of the phasel specifications.
(ebXML assumes, that businesses can connect their IT systems over the Internet) If implemented as specified, ebXML provides the ability for trading partners to exchange standard electronic business messages, such as orders, delivery schedules, receipts, and invoices. These messages might include entire XML documents or only the data that has changed or is required to fill in the document, assuming that both partners have a current copy.
The goal is to allow large and small businesses to concentrate on production and marketing and to devote less time and effort in administration, particularly of connected IT systems. The assumption is that businesses will be able to directly connect, or at least map, to their IT systems over the Internet. This same assumption also lies behind the SOAP, WSDL, and UDDI initiatives; ebXML differs mainly in the degree to which it recognizes business process modeling as a core feature and includes industrial-strength quality of services.
Late in the initial drafting cycle, the ebXML messaging team voted to adopt SOAP with Attachments, signaling convergence between ebXML and SOAP, WSDL, and UDDI. In contrast to those three specifications, the ebXML specifications reflect requirements from the business community for a more robust, secure communication environment and include a business process modeling methodology and schema.
In phase 2, OASIS assumed responsibility for maintaining and enhancing the infrastructure specifications, including the work of making the ebXML registry compatible with Web services metadata. UN/CEFACT continued with the development of metadata and information models, including the business process information model (BPIM), the core components (CC), and business information object (BIO) libraries.
Under UN/CEFACT, the ongoing ebXML effort comprises ten new projects defining BPIM rnetadata to ensure consistent business models, using the Unified Modeling Language (UML) and the Unified Modeling Methodology (UMM). This goal is driven by the need to define reusable processes and information blocks. It should also be noted that UN/CEFACT's BPIMs are technology neutral; that is, they can be used for ebXML, EDI, and any other packaging and transport syntax. As to the work on CC, it is a bridging tool for the migration of data-centric, bottom-up, EDI to the process-centric, top-down, BPIM world, but is not a mandatory component.
Overview of ebXML
Fundamentally, SOAP, WSDL, and UDDI grew out of an interest among Internet community members in establishing a remote procedure call (RPC) mechanism for exchanging XML documents across the Web. By contrast, ebXML grew out of an interest among existing EDI community members to create a better way to exchange business documents using XML and to transport them over the Internet, rather than using expensive, private value-added networks (VANs). Later, after a document oriented interaction style was added to SOAP, the two efforts began to converge, and ebXML adopted SOAP as its default messaging transport.
The goal of ebXML, like that of EDI, is to eliminate the expensive process of sending paper documents through the mall or via fax and to eliminate duplicate data entry tasks in the business applications of trading palmers by directly connecting their IT systems. In other words, the goal is to eliminate duplication when information is entered once by the trading partner that creates the document and again by the trading partner that receives the document and to achieve efficiencies and cost reductions by minimizing human steps within the processes. The idea is to encode business data in XML documents that can be mapped directly and automatically to existing business systems.
The intention of ebXML, furthermore, is to improve on the EDI model by eliminating the painful prior agreement aspect, which requires intense legal activity to create a trading partner agreement (TPA) between parties wishing to exchange documents via EDI. Furthermore, ebXML seeks to eliminate the difficult EDI setup period that requires encoding the TPA into the applications on both sides.
In addition, the ebXML alternative is intended to be available at lower cost, and to be easier to use than EDI. For nearly twenty years, the EDI standard has been used by a relatively small number of large businesses that could afford the start-up cost and deal with its complexity. EDI was developed by pooling many related data item definitions, creating a superset of all possible data items for such documents as purchase orders, shipping bills, invoices, and so on. This information set proved unwieldy. Also, EDI required private networks; expensive, specialized software; and high-priced consultants.
In deliberate contrast to the EDI approach, ebXML focuses on defining the processes and procedures by which businesses might agree to exchange documents and the messaging interactions required to implement those processes and procedures. Instead of identifying the various data items and many optional items in a business document, the ebXML user starts by idenfying the business process, or interaction, between two or more parties that exchange business documents.
Note: An earlier standard for intrabusiness document flows, RosettaNet, had adopted a similar model but was focused on the electronics industry. By contrast ebXML seeks to the same thing for general business. RosettaNet confirmed ebXML's accomplishment by annoucing that it would align with ebXML.
A Simple Example
Each business that participates in an exchange of documents that is ebXML-compliant identifies the actions that it must perform to send and to receive a given document. The information needed for such a document is then derived from the pattern of exchange. From the business process, therefore, ebXML derives the business data necessary to carry out the agreed-on interaction.
A business process between two companies might be defined as follows:
1. Based on its expected volume for its normal winter season, Harry's Sports sends an advance order to Skateboots Company.
2. Skateboots Company sends an acknowledgment of the order to Harry's Sports and provides an expected shipment date.
3. Harry's Sports may send an inquiry about the status of the order at any time and receive an update, such as a message saying that the shipment will be a week later than expected.
4. Skateboots ships the order and sends a message confirming the shipment to Harry's.
5. Harry's receives the order and sends Skateboots an acknowledgment that the order arrived.
6. Skateboots sends an invoice to Harry's for the order.
7. Harry's sends payment for the invoice.
8. On receipt of payment, Skateboots sends an acknowledgment, ending the transaction. Some aspects of this interaction may be defined as optional, such as sending acknowledgments on receipt of the order, the invoice, and the payment. Other aspects may not be defined as optional, such as sending the order and the invoice.
A business transaction, such as this purchase order, fundamentally involves an exchange of things between businesses, such as goods for money. The ebXML business process and trading partner information allow options and requirements in such an exchange to be explicitly defined and agreed on between two or more parties to a business transaction and implemented elec- tronically over the Internet.
In this case, Skateboots would have stored in the ebXML registry information about the business transactions it offers over the Internet, such as this long-running preseason order. Harry's Sports would have discovered the information from browsing the ebXML registry and contacting Skateboots to formalize the agreement. The goals for the ebXML registry include the automatic discovery of the trading partner, using search criteria specified in the collaboration partner profile (CPP).
Define the Documents
According to the interaction definition, the transaction depends on certain documents, including the purchase order and the invoice. With ebXML, the data and the documents are not defined; rather the interactions between the two businesses are formalized into an agreement that can be executed. The agreement assumes that the exchange of information will be carried out according to the predefined business process interaction. The ebXML BPIM identifies the interactions among trading partners participating in a transaction. Each activity within a transaction is associated with an exchange of information, whether request or response. Information is at the root of any exchange activity, transaction, and business process. Although the various parties to an interaction may have different information requirements, ebXML does not want to standardize the information exchange; EDI showed that this approach is neither reasonable nor successful, parties to an interaction may have different information requirements, ebXML does not want to standardize the information exchange; EDI showed that this approach is neither reasonable nor successful.
A business process may have a number of activities defined to achieve the same end result, but each of those activities typically has different constraints and different information requirements that dictate a different path through the BPIM. In other words, the ebXML BPIM allows and even assumes that multiple paths will be specified to achieve the same business interaction, depending on the trading partner or trading partners involved. Each valid path represents a separate scenario for that business process. In the CPP, an ebXML party identifies which of those scenarios it is capable of executing. For the collaboration partner agreement (CPA) to be completed, both parties agreeing to a scenario require at least one interaction pattern match. Once the interaction pattern is formalized and agreed on by the participating businesses, documents either can be chosen from one of the businesses or from one of the various standards bodies dealing with XML documents or can be based on one or more of the models stored in the registry. An ebXML assumption is that documents will be defined in a common, shareable way as companies implement ebXML and store their models and profiles in the repository.
As shown in Figure 1, ebXML interaction patterns contrast with those proposed by SOAP, WSDL, and UDDI in that ebXML assumes a negotiation phase between two or more businesses that use ebXML-compliant software. Similar to the SOAP/WSDL/UDDI approach ebXML assumes that an automatic discovery and negotiation phase will eventually become part of establishing a connection between trading partners. The automatic discovery and negotiation phase would be accomplished using ebXML-compliant software that searched the registry for compatible business process metadata and quality-of-service requirements on behalf of a trading partner. On finding such compatibility, the software would contact the trading partner's ebXML-compliant software to accept the process and initiate the interaction. The ebXML registry is designed to support browsing and ad hoc queries. Once the business searching the registry-Harry's Sports, in this case-finds the supplier it is looking for and identifies a target business process interaction-in this case, the preseason purchase order process-the client business can either contact the supplier to formalize agreement on the business process to be implemented between them or use automatic negotiation via CPP, if supported. In either case, once the process is agreed to, the final step is for both trading partners to set up their ebXML-compliant software to implement the agreed-on interaction-in this case, submitting preseason orders for skateboots.
[FIGURE 1 OMITTED]
Interactions, such as the fairly simple pattern described earlier, can be codified using the ebXML CPA, which serves a similar purpose as WSDL. Assuming that ebXML-compliant software systems are available, the CPA drives the automatic interaction between the IT systems of trading partners that can agree on a common business process, given sufficient information in the registry. In our example, Harry's wants to find a manufacturer of skateboots and uses the ebXML registry to obtain information necessary to order from Skateboots Company. Even if Harry already knows that it wants to order from Skateboots Company, Harry's can use the ebXML registry to obtain information about the services offered by Skateboots Company for online ordering. Harry's can examine Skateboots's registered CPP and associated business process models to see whether there's a potential match with Skateboots's codified terms, conditions, and interaction scenarios.
The ebXML model assumes that each business taking part in an Internet transaction will search the ebXML registry to find a qualified trading partner: one that has registered an appropriate interaction pattern, such as the purchase order and shipment process for Skateboots Company, and that a person or program at that business will explicitly decide whether the published interaction fits. After agreeing on the interaction pattern, or business process, the ebXML-compliant software at each company can begin to execute the defined interaction.
As shown in Figure 2, ebXML deployment requires ebXML-compliant software to implement the scenarios, or patterns, it describes and to which each trading partner agrees. The ebXML-compliant software has to understand how to derive or map interfaces to business applications, using the CPP, which defines all potential collaboration mechanisms that a given business supports. The CPA defines a specific collaboration on which the two or more trading partners agree; in other words, a CPA represents the intersection of two or more CPPS.
[FIGURE 2 OMITTED]
The modeling information is recommended but not required to be defined using the UMM, a subset or profile of the UML standardfrom the Object Management Group (OMG). The UMM or other modeling information is mapped to a business process specification schema (BPSS) and stored in the registry, where it can be referenced from a CPP. The information in a CPP, which is also intended to be stored in the repository, identifies which transports are available for the interaction, such as SMTP or HTTP, and security requirements, such as encryption, nonrepudiation, and digital signatures. The CPP also identifies the business processes available for engagement: Is it just order placement or a full supply-chain interaction? Does a business process have various scenarios?
The CPP allows a business to provide as many or as few details as it is willing to disclose publicly. Some businesses may provide a link to their complete product catalogs; other businesses may provide simply a high-level description of product categories or services. However, at least one business process model scenario has to be identified if an ebXML-compliant interaction is to be supported.
The CPA includes the agreed-on transport and security options, as well as the selected business scenario, via a binding to a business process specification schema (BPSS). The target party can either accept or reject an offered CPA. After the party accepts a CPA the selected business scenario can be initiated by sending the first business information in a payload over the agreed transport. Then the rest of the scenario is executed, and the corresponding messages are exchanged.
After the business process modeling is done, the models are mapped to XML-that is, using the BPSS fornat-and stored in one or more registries. The business service interfaces are registered, as are the CPPS, to describe the interface implementations. Vendors and businesses providing ebXML-compliant software then use information extracted from the registry to build the business service implementations that wrap existing or new business applications. The CPA defines the specific payload contents for each interaction, which by default is delivered using SOAP with Attachments as the transport, but other transports are possible.
The ebXML Specifications
Phase I ebXML work consists of three major parts:
* Transport, or messaging specification, based on SOAP with Attachments
* Registry, using either UDDI or native ebXML-stores business process model definitions and collaboration protocol definitions
* Collaboration, meaning the automatic execution of models and interactions among business partners
Vendors are typically implementing ebXML in this order, although some are concentrating first on modeling tools. Businesses can use ebXML to find out about one another using the registry, to define TPAS, and to exchange XML messages in support of business operations. The goal is to eventually perform all these activities, without human intervention, over the Internet. Work on ebXML is not yet completed, however. Work on the specifications and compliant software continues at UN/CEFACT, OASIS, W3C, and other consortia, and at various systems and software companies. Although phase 1 has been completed and implementations are on the market, the ebXML specifications remain works in progress.
Many similarities exist between ebXML and SOAP/WSDL/UDDI, as both efforts sprang from very similar requirements and objectives.
Because ebXML started from the business process model and SOAP/WSDL/UDDI started from the RPC model, the overlap is not complete. It's more like an intersection; ebXML maps down to implementations at the transport level, and SOAP/WSDL/UDDI map up to the document-oriented interaction style. Much commonality is also seen between UDDI and the ebXML registry.
The shaded area of Figure 3 illustrates the conceptual overlap between the ebXML specifications and the SOAP, WSDL, and UDDI Web services specifications. Both specify a type of service interface that gets stored in a registry, and both specify a transport using SOAP. Although WSDL is not really equivalent to CPA, the ideas are very similar.
[FIGURE 3 OMITTED]
Although originally SOAP/WSDL/UDDI and ebXML started out as separate, competing efforts, today the ebXML specifications can be seen as a source of requirements for the continuing W3C work on SOAP and related specifications. The ebXML specifications define features, functions, and qualities of service beyond those in the basic Web services specifications. Several vendors are supplying ebXML-compliant products, but it's possible that the convergence will overtake the momentum of ebXML and that all its features and functionality will be incorporated into Web services. The Java Community Process (JCP) initiative called Java APIs for XML Registry (JAXR)4 defines a Java API common to both the ebXML repository and UDDI, for example.
The ebXML specifications, created separately by individual authoring teams, were intended to fit within a comprehensive technical architecture, as described in the technical architecture specification. The ebXML technical architecture builds on the experience of EDI but takes advantage of the flexibility of XML and the ubiquity of the Internet. The ebXML architecture maps a business process and information model to XML documents and defines requirements for the software that processes the documents and exchanges them among trading partners.
Will ebXML be adopted?
Because ebXML aligned with SOAP, it seems likely that the ebXML transport will be adopted and implemented, However, the bigger question centers on business process, which is where ebXML started and how ebXML is different from EDI. Standardising business process is at least as big a job as standardizing business data. Many attempts at the latter have been made, and many failed. Business process, like the businesses that invented them, are often unique and sometimes part of a company's competitive advantage. It's not clear that businesses will agree to standardize them or even to disclose them in sufficient detail for standardization. And if this doesn't happen, ebXML may fall flat.
The ebXML Specifications
The ebXML architecture defines the following:
* Business processes and their associated messages and content
* A registry and discovery mechanism for publishing business process sequences and related message exchanges
* Company profiles
* Trading-partner agreements
* A uniform message transport layer Conformance to the ebXML architecture is defined for each individual specification and also, generally, in the technical architecture specification. Conformance appears to require implementation of all the specifications, although many of the features and functions are listed as optional within the individual specifications.
The main ebXML specifications are as follows:
* Technical Architecture: an overview and detailed summary of the complete architecture
* Business Process and Information Modeling: definition of the BPSS and a modeling methodology for producing a BPSS
* Collaboration Protocol Profile and Agreement Specification: definition of trading partner information and how it's codified in XML documents
* Registry and Repository Services: for storing and retrieving business process models and specifications, trading-partner identity, and technology requirements
* Messaging Service: definition of how ebXML-compliant documents are transported across a network
* Core Components and Core Library: shared components across industries, including a business document overview
Subsequent subsections detail the business process, collaboration protocol, registry, messaging, and core components specifications and provide some examples and illustrations of the major points.
Some people say that ebXML can be implemented in stages, but formal conformance is defined as comprising all the architectural components of the ebXML infrastructure. Sorting out which vendor confirms to what specification can be a complex task, however.
From: Understanding Web Services Addison-Wesley ISBN 0-201-75081-3
Legality of Electronic Documents
The legality of electronic commerce transactions is a thorny question. That is, does an electronic purchase order have the same legal standing as a paper one? This question is outside the scope of ebXML, which does not deal with the issue. However, for electronic commerce to become reality, this issue will have to be resolved. An electronic commerce transaction will have to have legal status equivalent to a paper transaction. This is already true for an automatic teller machine at a bank or an online stock trade. But these transactions use private networks and proprietary systems.
Generic purchase orders, invoices, and ebXML business processes do not yet have this status when transmitted over the Internet, unless, perhaps, when they are printed out. but such important questions as now to represent company letterhead and authorized signatures legally remain unanswered. UN/CEFACT's legal working group says that the CPP/CPA phase can form a legal contract and has published a document that descibes me requirements for an e-commerce agreement that is fullfilled when trading parties perform a static CPP/CPA agreement. This document does not have the legal standing of UN member-country law but provides a good indication of a possible future resolution of the issue.
Some ebXML members also are proposing to establish the legality of the dynamic, or on-the-fly, trade-partner negotation via intelligent software applications. But this is a much greater problem, perhaps unsolvable in practice, as there is very little, if any, precedent for software programs to be recognized as able to establish legal contracts or their own. The huge question here, of course, is defending or validating what your software program has negotiated on your behalf.
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||Standards--Electronic Business|
|Publication:||Database and Network Journal|
|Date:||Apr 1, 2004|
|Previous Article:||XML CD bookshelf.|
|Next Article:||Java Enterprise best practices.|