Using Technology to Cross Organizational Boundaries, part 5

CBL

Commerce One has taken a fundamentally different approach from EDI or the middleware systems with its Common Business Library. CBL was originally developed by Veo Systems, which was recently acquired by Commerce One. CBL uses document exchange as the business-to-business interaction technique, as do EDI and XML middleware. But instead of producing a comprehensive set of complete documents as EDI does, or wrapping business service calls in documents as webMethods's XML middleware does, CBL defines a set of basic building blocks. These building blocks are then pulled together to make the actual documents describing the interactions between two organizations.

By doing this, CBL provides infrastructure out of the box for building entry-level systems that can immediately support loosely coupled, dynamic, and transient relationships. And because the building blocks are intended for extension and customization, CBL can form the basis for building electronic business systems with the kinds of rich interaction and tight coupling seen in the classic middleware systems.

CBL is an application of XML. The building blocks are XML fragments and are then assembled to create complete XML documents representing an interaction such as a purchase order, a shipping status inquiry, or an inventory stock query. The building blocks include such constructs as catalog entries, descriptions of a business, terms of shipment, terms of payment, and manifests. Where possible, the building blocks take advantage of other standards using, for example, the relevant ISO standards for dates, currencies, and names.

To use CBL, an organization starts by creating a CBL document describing its offer and its terms for doing business. This document is then made available on the organization's website. Similar to WIDL, the document describes the kinds of messages that the organization expects to receive. However these messages represent requests for certain business services, rather than encapsulating object level API calls to the services. This provides an additional layer of independence from the underlying services, allowing the organization to change and update its backend systems without having to change the set of requests that it supports.

After describing its offer and services using CBL, the organization needs to integrate a CBL system with its backend systems. This involves writing custom code that processes the expected CBL requests and makes the appropriate calls to the backend systems. Once this is done, the organization is open for business.

Users at other organizations can now access the offer and terms description available on the public website. This description has enough information that those users can select from among the available offers and terms and begin sending requests to the first business. The requests are made by constructing an appropriate CBL document using the specified CBL building blocks and then sending that document over the Internet to the receiving organization. The receiver's CBL system accepts the request, decomposes it based on the contained building blocks and processes the order. The vendor can then return another CBL document describing when the request will be processed, how product will be shipped, etc.

Figure 4. Issuing commerce request using CBL.

CBL shares several characteristics with EDI and XML middleware. Like those approaches, CBL uses document exchange as the interaction technique for business partners. This greatly reduces some of the integration and security costs. However, document exchange can limit the kinds of interactions supported between partners. In the case of EDI, this is a fundamental limitation. webMethods's XML middleware addresses this via WIDL, which as we've seen, reintroduces the tight-coupling costs associated with object-level interactions.

CBL takes a different approach to supporting rich interactions. Any CBL document is created by assembling a set of the basic building blocks provided by CBL. This gives organizations two ways to support rich interactions with their partners. First, by combining multiple building blocks, new types of documents not previously envisioned can be created. Second, because CBL is based on XML, the building blocks themselves can be extended in a safe way. For example, CBL defines a building block for a shipping method. The shipping method object describes how a particular item should be shipped. A vendor can extend this building block to include a "priority" field. Buyers who understand this extension can specify a shipping priority. At the same time, buyers who don't understand the extension can create valid shipping methods without specifying the priority. And the vendors effort to produce this extension is entirely focused on a high-value and differentiating feature. CBL already provided the mechanics for defining shipping method and the vendor's effort is confined to the extensions and refinements of the shipping method.

Commerce One anticipates that industry specific vocabularies of CBL will develop. Since extension of CBL is straightforward, multiple competing vocabularies can be created and experimented with. Over time, the best vocabularies for various industries will be settled on and industry specific registries defining the vocabularies can be created. This lightweight and evolutionary process will make the development of these vocabularies much easier than the corresponding EDI industry specific implementation conventions.

Industry specific ecommerce protocols are similar to industry specific commerce vocabularies. CBL is also appropriate to use in defining and experimenting with these protocols. Doing this reduces the amount of effort spent on mechanics during protocol definition and instead allows the protocol definers and implementors to focus on the unique capabilities of the protocol.

A number of such protocols have been proposed in the last several years. Among these are the Open Trading Protocol (OTP), Open Financial Exchange (OFX), and Open Buying on the Internet (OBI). The last of these, OBI, was developed by a consortium led by American Express, and is aimed at supporting online purchasing of office supplies and other non-essential products. A considerable amount of the effort in defining OBI involved the mechanics of describing an individual product, contacts at a business, etc. All of these are standard building blocks already included in CBL. OBI definition and evolution would be much easier if it were defined on top of CBL, as a set of specific extensions and additional building blocks to support its intended domain. As a proof of feasibility, Commerce One has produced a demonstration implementation of OBI using CBL.

Finally, note that CBL dramatically reduces the cost of entering into each new relationship. First, unlike any of the other approaches we've examined, CBL allows a vendor to completely describe its offer and terms for doing business. This enables vendors to provide an online description of themselves and enables others to decide to enter into a business relationship with the vendor without requiring the vendor to do any additional work. Second, given the use of document exchange to support electronic interactions, a vendor and its partners do not need to adopt CBL implementations and systems together. Instead, each can separately choose CBL vendors and integrators and proceed at its own pace. Finally, as opposed to EDI, CBL is designed to support scaling implementations from small pilots through large enterprise deployments. This makes it much easier for organizations to begin using CBL and then increase the size of the deployments.

As with any of these systems, there is integration work to interoperate with existing backend systems and to create client applications that can access those systems. The client applications must be able to generate CBL documents and the backend systems must be able to receive and process those documents. However, because CBL is an application of XML, there are many more choices for integration technologies than are available with other proprietary approaches. XML is simple enough that low end deployments and integrations can be done by hand. There is also a large and growing set of commercial and public domain tools available for processing XML. And at the high-end, we can expect to see full featured and large scale CBL systems offered by vendors including Veo Systems.

To promote support of CBL by multiple vendors, Commerce One submitted CBL to CommerceNet, an industry consortium intended to promote and advance interoperable electronic commerce. Following the submission of CBL, CommerceNet formed the eCo working group, including representatives from Sun, Lockheed, Netscape, Microsoft, Harbinger, 3Com, Intuit, CSC, Commerce One, and . The eCo working group is building on CBL as the foundation for a variety of electronic commerce solutions. We anticipate that a number of products and systems supporting CBL will become available from the members of the eCo working group and other vendors.

This means implementors have a range of choices. Pilot projects can be undertaken with very small investments. Then as the project is proven, higher end systems can be brought in to support scaling needs. And when necessary, 3^rd party and public domain tools can be used to solve difficult integration problems. The choices of the final vendor and of the base technology are separated. This means a company can focus on the business services it will provide and the ways it will work with partners initially. Then during implementation, the company and its partners can make independent final vendor choices. This is in marked contrast to the other proprietary approaches, where all tools must be provided by the core systems vendor and all business partners must make the same choice of vendor and approach.

CBL has a wider range of applicability than any of the other approaches we've examined. CBL can be used to support long term and tightly coupled relationships via its built in extensibility. CBL can also be used to support more dynamic and loosely coupled relationships due to the low cost for entering into a new relationship. In addition, CBL allows organizations to focus on the high-value and differentiating parts of their offer, rather than spending their time on low-value electronic business mechanics. Finally, CBL makes an appropriate foundation for implementing other specialized electronic business protocols.

In order for CBL to be successful, it must be widely adopted and multiple vendors must provide support for it. The formation of the eCo working group by CommerceNet is an encouraging sign indicating the likelihood of widespread support for CBL. This widespread support is not certain: existing proprietary solutions may achieve sufficient market penetration and provide sufficent functionality to counter the need for CBL solutions. However, CBL has important technical advantages over the other approaches we have examined, and unlike any of the other approaches, is designed to allow multiple vendors to offer interoperable CBL-based products. Organizations intending to deploy CBL systems can begin today by defining the business documents they will interchange and building those on top of CBL. As vendors release products supporting CBL, organizations can begin deploying those and be guaranteed of interoperability with organizations that have deployed different products.



Previous: Approaches: XML Middleware		Next: Conclusion