XML Protocols

While there are many standards that look like ebXML, ebXML is the first horizontal standard designed to address the exchange of information and adherence to inter-enterprise processes. However, in attempting to reach this lofty goal, ebXML is also a complex standard and takes some understanding before we can comprehend its value to the world of application integration and electronic business.

So, why do we need the ebXML standard? It's really a matter of leveraging the Internet to automate how we do business in real time, leveraging common processes and common information formats. The use of an electronic information standard and enabling technology drive how we do business, and the interest in standards that provide a common mechanism to do this will only push us farther along.

Thus was born ebXML, a collaboration between UN/CEFACT and OASIS. As you can tell by the name, ebXML is built on top of XML, as well as other Internet standards, including Web services, to create an infrastructure for information-based and process-based electronic businesses. This is a good standard, with growing interest from those doing B2B automation. ebXML provides just enough good technology to make it useful in the real world, without over-hyping its capabilities, thus disappointing its implementers.

What is unique about ebXML is that it's a complete standard, addressing:

• Process
• Trading partner management
• Semantics
• Notation
• Security
• Agreements
• Standard information exchange
• Standard information structure

Other standards, such as Business Process Execution Language for Web Services (BPEL4WS), address only the notion of process and semantics, or other more narrow aspects of application integration between trading partners or internal systems.

However, the aggressiveness of ebXML is also its most limiting factor, because it will take years before the standard finds its way into many enterprises and trading communities. This is due to the amount of work that must be done to get a trading community to leverage ebXML.

ebXML for Trade
The ebXML standard was created to replace EDI (at least, that was the idea) or other electronic commerce standards currently in use. Moreover, ebXML looks to create a set of standards that is affordable and will work in small to medium-sized enterprises. The ebXML standard is open and free to anyone with an interest, and does not seem to compete directly with other standards when you consider its application (but it could have some overlap with other process integration standards, such as WFMC or BPMI).

At its essence, ebXML is based on process models and encoded in XML. It is also an XML message system to exchange information and a repository to allow information sharing. The message system supports any type of data, including EDI transactions and binary information. In addition to information, ebXML supports trading partner agreements - a fundamental function of EDI partner/profile subsystems - and you may use ebXML to express business services agreements.

As with other standards, ebXML is not a product but a set of guidelines that allow application and application integration technology vendors to design their products to support it. To date, there are dozens of vendors and products that support ebXML; some in part, some completely. More will be added as the standard matures and adoption continues.

In recent years, it's been clear that ebXML (as well as many other modern Internet standards) has to take on a coexistence strategy rather than a replacement strategy. This is because most enterprises are reluctant to shut down their existing B2B systems, such as EDI, until new standards have proven their operational value. Thus, we have another evolution not revolution, which seems to be a common theme as we migrate to newer but more complex and invasive standards.

ebXML Components
There are several components to ebXML, including:

• Collaboration Protocol Profile (CPP)
• Collaboration Protocol Agreement (CPA)
• Business Process and Information Modeling
• Core components
• Messaging
• Registry/Repository

CPP describes an enterprise offering using a standard, portable format. This component describes the message-exchange mechanisms as well as business collaborations that are native to the enterprise or trading community. The ebXML standard also describes business processes within CPP, including how partners interact within a trading community. CPP supports intra- and inter-company processes, and public versus private processes, collaborating on both sides of a two-party B2B transaction. For example, when leveraging CPP, a trading community would define all processes between partners -for instance, buying parts to build a car -as well as semantic differences, and how processes and data need to interact to support any number of business activities.

CPA describes the particular requirements, facilities, and descriptions for the transaction of trading partner business. It is formed from either manual or automated systems, deriving the intersection of their agreed-upon CPPs. Thus, the CPA becomes the de facto contract between the trading partners, creating "rules of engagement" for a specific collaborative business transaction.

Business Process and Information Modeling is a specification for describing a business process in XML. This includes transactions, document flow, information encryption, binary collaborations, semantics, and such. Processes that leverage ebXML use these specifications when they create CPPs, which are also used to define shared business processes within a trading community.

ebXML and BPEL4WS
You should note that BPEL4WS focuses on the process alone, and not a more holistic view of electronic business. In other words, BPEL4WS is general purpose, whereas ebXML is applicable to B2B trading.

Core components are a set of ebXML schemas and other components that contain formats for business data, including customer account, amounts, and so on. They are particular to an entity, such as a particular trading partner, but not leveraged as vertical semantics (as with vertical standards within health care and financial services markets).

Messaging, as you may expect, is a standard format for ebXML messages that leverages concepts from messaging middleware, including the ability to transmit information asynchronously or synchronously. This is the visible portion of the CPA and provides specific business rules for processing. ebXML messaging is built inside SOAP, extending the SOAP protocol by frameworks that support attachments, security, and verifications of delivery.

The ebXML message service provides a mechanism to exchange business messages that does not rely upon proprietary technologies and solutions. The message contains structure for message headers used for routing and a payload section for the content.

The ebXML message service is broken down, at least conceptually, into three parts:

1. The abstract service interface
2. Functions provided by the messaging service layer
3. Mapping to the underlying transport service

Registry/Repository are services that maintain CPPs, CPAs, ebXML components, and other ebXML artifacts such as JAR files, video, WSDL, and semantics. This is a database, when you get right down to it, providing query capabilities that allow users to look for relevant content and even information about trading partners. The services defined by CPPs can be published to UDDI.

This portion of ebXML provides a Web service discovery scenario. Thus, a trading partner would first search for a shared service in UDDI, which may indeed contain a reference to a CPP that actually exists in the ebXML registry, which in turn provides access to information about the trading partner. From there you can use the CPA to create a partnership agreement for B2B transactions. We'll talk more about Registry/Repository services in the next section.

The ebXML registry provides a core set of services that enable the exchange of information between trading partners. As you may recall, the registry is like a database, allowing a trading partner to place and obtain information pertaining to the interaction between trading partners.

The registry maintains an interface to metadata for a registered item, and access to an ebXML registry is gained through the use of several APIs. To facilitate semantic recognition of business process and information meta-models, the registry provides a mechanism for incorporating human-readable descriptions of registry items. Moreover, you can assign UID keys from other existing business processes and information meta models, such as RosettaNet, and implement them using XML syntax.

Conclusion
Now we know what ebXML is, and its power. It's also surprising to me to see how slowly ebXML is finding its way into larger organizations, even those looking to replace EDI with something much more dynamic and process-oriented. It may be another case where the best technology, or standard, does not always win. However, I'm hoping from this column that we learn from the architecture of ebXML, and understand its place in the world of B2B application integration. We have to get off of the EDI train at some point. It's just too slow.