B2B Integration Protocols and Standards

Fastwater Rapids vol. 1.22, 31May99

The business-to-business (b2b) internet commerce market is certainly heating up. One sign of this is the proliferation of standards, frameworks and partnership announcements. Keeping all the protocols straight and understanding what each of them covers is not easy. We provide you some help this week by giving you a framework to understand the pieces involved in implementing b2b internet commerce relationships. In turn, this framework will help you sort out all the standards and work your way thru the ongoing stream of announcements.

Some of the Standards

We start with a brief description of some of the standards. Then we describe a framework for understanding where these standards fit.

cXML (Commerce XML): An XML scheme and associated messaging protocol for supporting purchasing over the Internet. Developed by a group led by Ariba.
CBL (Common Business Library): A set of XML building blocks that can be used to support a variety of Internet business relationships. CBL was originally developed by Veo Systems, which was recently acquired by Commerce One. CBL has been submitted to the eCo Working Group of Commerce Net.
BizTalk: Microsoft's framework intended to cover everything involved in b2b commerce. BizTalk is just now making past the press-release stage and starting to have some actual content. We'll describe it more below.
EDI: The original b2b framework. Traditional EDI relied heavily on proprietary communication schemes and on localized extensions. Recently, the various EDI standards groups have begun work on next generation EDI standards, including Open-EDI and OO-EDI. In addition, an informal Internet working group has coalesced under the name XML/EDI.

Layers of B2B Integration

At a very simple level, conducting business requires the ability for one organization to make requests of another, and for the second organization to respond to those requests. We can break this apart into three distinct layers:

transport -- the mechanics of exchanging messages. How are messages sent back and forth? Are they placed in wrappers (envelopes)?
Content -- what's inside the messages? Some content is straightforward, such as purchase orders. Other content is more complex, such as configurations for complex products.
Business process -- how do two organizations work together? What messages are exchanged to purchase a product?

Layers of B2b Transactions Consider a simple example of one organization making a purchase from a second. To begin with, the two organizations need to work out their joint business process. Does the seller accept online orders? Does the buyer need to open an account with the seller or can it simply charge purchases to a credit card? What are the terms of payment? What are the rules for specifying shipping options?

Once the buyer has figured out how to do business with the seller, the next step is for the buyer to figure out what to buy and submit a purchase request to the seller. Using the Internet, the most natural thing is for the seller to create an electronic catalog (possibly hosted on the seller's site, on an intermediary site, or distributed to a procurement system at the buyer). The buyer browses this catalog and then creates a purchase order and sends it to the seller. The actual content of these documents depends on the actual organizations involved, the market they're in, and the tools they use.

Finally, there must be a way to transport the documents between buyer and seller. Sometimes, the documents are transmitted directly, and sometimes they're packaged up inside a wrapper or envelope for transmission. Again, there are a number of choices regarding transport and document packaging.

We look into these layers in more depth below and show where the various standards and protocols fit.

Transport

The first problem organizations needed to solve in order to conduct business online was how to transfer information, requests, and other messages between the organizations. Thus, this was an early focus of EDI efforts, recently largely supplanted by message transports using Internet technologies.

To date, there have been three generations of approaches to this problem:

traditional EDI: pair-wise high speed data connections and VANs
distributed object systems: CORBA, COM/DCOM, Java RMI, etc.
internet messaging: email, HTTP, and messaging middleware.

Traditional EDI Message Transport

When EDI first emerged, messages were exchanged by creating direct high-speed data connections between each pair of business partners. To exchange EDI messages, each organization had to build wiring connecting to each of its possible partners.

This posed a substantial barrier to adoption of EDI. To address this, a number of intermediaries, known as Value Added Networks or VANs arose. VANs handle message delivery and routing between a whole series of businesses. Rather than communicating directly with their partners, organizations send and receive messages via a VAN. Originally communication to and between VANs relied on direct high-speed data connections. Recently, Internet-based VANs have emerged that use the Internet for connectivity.

While EDI has achieved tremendous successes in narrow domains, it has dramatically failed to extend its reach beyond the largest corporations. However, at the same time as EDI was being deployed in the Fortune 500 companies, a new style of computing, relying on client-server architectures and object oriented development was emerging.

Where EDI provided a relatively limited set of messages that were exchanged in a loosely coupled manner, distributed object applications took an opposite tack: exchanging a rich and extensible set of messages in a tightly coupled manner. Given the failure of EDI to move past its core large enterprise base, a reasonable next step was to use this distributed object approach for b2b integration.

Distributed Object Systems as Transport

In a distributed object application, the application consists of a set of objects that can run on multiple machines. When one object needs to communicate with another, the first object appears to make a request directly of the second object. In reality, this request is transported to the second object using a distributed object system. Correspondingly, any response from the second object is returned via the distributed object systems. The idea is that an object should be able to make a request of another object without needing to know whether that other object is on the same machine as the first object or on some other machine, possibly half-way around the world.

COM/DCOM, CORBA, and Java RMI are some of the distributed object systems that provide these services. And over recent years, a number of companies have attempted to build b2b transaction applications as distributed object applications. (See Fastwater coverage of some of these cross-organization electronic business systems.)

The EDI related standards groups have chosen the distributed object approach in their efforts to define the next generation of EDI standards. Current work on these standards, referred to as Open-EDI and OO-EDI, assumes that communication between organizations will use cross-organization distributed object oriented systems. In these applications, an object such as a purchase order at one organization will directly communicate to an ERP system at another organization by making a remote method call to objects at the second organization representing the ERP system interfaces.

While this is an understandable attempt to address the limitations of the loosely-coupled and coarse-grained approach of traditional EDI, we believe it is fundamentally flawed. Distributed object systems function well between systems that are "close" to each other. However, systems at different companies are "far" from each other: with significant "distance" due to network delays and difficulties due to crossing corporate firewalls. Just as ERP systems have failed to span organizations, these next generation EDI efforts will not gain widespread deployment because of the choice of underlying transport and communication infrastructure.

However, at the same time that these efforts began, a new kind of cross-organization application and multi-organization business relationship arose. These new applications and organizations realized that the flaw with traditional EDI was not its loosely coupled nature, but rather the limitations in the messages that could be exchange between organization. So, these new efforts used Web technologies and communication styles to build a communication transport between organizations, while focusing on providing a richer set of possible messages.

Internet Messaging as Transport

Internet messaging can be used as the underlying transport. Documents are exchanged by simply sending them via email, by ftp, or using HTTP by posting them to known URLs. Similarly, documents such as catalogs can be accessed by simply reading them over the Internet, either manually or using "web scraping" techniques available in webMethod's original product, the Web Automation Server, or in OnDisplay or Isadra's catalog tools.

The advantage to this approach derives from the ubiquity of the Internet. Almost every organization is already set up to send and receive Internet messages and thus very little needs to be done to enable exchange of business documents. However, because of the inherent unreliability of HTTP and Internet messaging, there must be additional logic to ensure delivery and to connect from the Internet servers to the actual applications.

These limitations are addressed by the use of messaging middleware running on top of the Internet transport. The ICE protocol can be viewed as a way to transport assets across the Internet reliably. Products such as IBM's MQSeries, Microsoft's MSMQ, webMethods's B2B Integration Server, and offers from other messaging vendors provide general tools for building robust message transports.

The newer b2b transaction standards all assume the use of Internet message transports. cXML specifies that messages are interchanged using a request-response pattern that must be implemented over HTTP. OBI, which builds on top of EDI to support Internet-based purchasing of office supplies, works by exchanging OBI messages over HTTP. Microsoft's BizTalk will presumably build on Microsoft's Commerce Interchange Pipeline, or CIP. CIP provides a framework for exchanging business messages using either straight HTTP or MSMQ on top of HTTP. As regards transport, CBL is agnostic. Particular CBL implementations are most likely to use HTTP transport, but the specification does not require a particular transport.

The Envelope

Just as a letter has to be placed in an envelope so it can be sent through postal mail, so business messages may need to be wrapped in some way before they can be sent. This wrapping may involve encryption so that messages cannot be observed while in transport, creation of a log so that an audit trail exists, or packaging of several messages and assets so they can be transported as a unit.

The ICE protocol essentially covers just the transport and wrapper issues. It consists of a method for packaging an arbitrary set of assets and ensuring that those asserts are delivered from a syndicator to one of its subscribers. Interestingly, while one of the main problems in b2b commerce is exchange of the assets making up a catalog and the ICE protocol looks ideal for this application, we have seen no use of ICE in this area.

Microsoft's CIP provides a number of options regarding message wrapping. Using CIP, modules can be included to do automatic packaging, to encrypt messages, and to create an audit trail. As previously mentioned, we expect BizTalk to presume the presence of CIP.

The other b2b protocols have varying support for message wrapping. OBI messages can themselves include other non-OBI EDI messages. cXML requires that each message be sent individually, so there is no packaging of multiple messages. Instead, when another resource must be referenced, cXML expects that reference to be an HTTP reference to the remote resource. Indeed, much of the cXML specification focuses on the details of such references. CBL does not directly address the transport issue and so doesn't address the issue of packaging multiple resources. But, CBL does expect any referenced resources to themselves by CBL documents.



		Next: Content of Messages