Implementing the ebXML Registry/Repository @ XML JOURNAL

Implementing the ebXML Registry/Repository

Conducting business in an electronic manner requires the exchange of a wide range of parameters - company profiles, catalogs, business processes, schemas, et al. - for describing appropriate business documents. How can these parameters be stored and managed? How can companies locate and use trading partner information?

The ebXML initiative has defined a RegRep (Registry/Repository) as providing a shared space for one or more B2B communities. With an ebXML RegRep, companies can submit, update, deprecate, or otherwise manage the parameters required to conduct electronic business. The RegRep also defines standardized APIs to access or otherwise share these parameters across trading communities.

You may have heard about the benefits of a B2B business model, a concept that grew out of the electronic trading communities that were defined using EDI (via the X12 and EDIFACT standards). While B2B grew out of the traditional EDI space, many implementation requirements are missing or poorly understood.

What are these missing elements? The traditional B2B business model (again, based on the EDI model) assumes that trading partners have advance knowledge of each other's e-business environments, trading protocols, and procedures. The "discovery" phase is traditionally done offline via a manual process (phone calls, legal contracts, etc.). This approach limits companies to conducting business with a relatively small community of well-known trading partners. A well-defined discovery process would enable most companies to significantly expand the size of their trading communities. The current B2B model, however, doesn't support such a process, forcing trading partner configuration to be accomplished offline.

The ebXML RegRep is designed to close some of the gaps in traditional B2B business models, as B2B alone isn't enough to establish true collaborative commerce. B2B with an ebXML RegRep provides a more advanced B2B model that we call Business-RegRep-Business, or BRB. ebXML RegRep enables trade parameters to be shared among business peers, and helps to build more dynamic B2B environments based on the discovery and execution of trade agreements with ebXML-enabled trading partners.

Understanding ebXML's BRB Model
ebXML's BRB model can be clarified using a simple formula:

BRB = B2R + B2B

Trading partners perform a Business-to-RegRep, or B2R, transaction before conducting B2B transactions. ebXML provides a more dynamic mechanism for finding and conducting business with new trading partners.

The U.S. General Accounting Office recently filed a report, "Electronic Government - Challenges to Effective Adoption of the Extensible Markup Language," with the Senate Committee on Governmental Affairs (view it at www.gao.gov/new.items/d02327.pdf). In the report the GAO describes the current status of the standards for XML registries and raises some concerns regarding the maturity of XML-related technologies as well as the lack of an all-encompassing XML vocabulary. While the report would appear to be a harsh criticism of XML, it draws some exciting conclusions regarding XML-based registries.

According to the report, XML registries should be used to share information between distributed agencies in order to conduct electronic business, effectively implementing an "e-gov" program. As described by the GAO, XML registries will play a very important role in e-government as well as e-business. XML makes integration easy, and an XML registry lowers the barrier for sharing trading parameters.

Note, however, that the GAO report doesn't specifically address the use of an ebXML-compatible RegRep. The report refers to an "XML registry" without regard to its compatibility with ebXML or UDDI. The need for an XML registry in an e-government initiative reflects many of the same needs within private industry. If the ebXML RegRep Specification fulfills the requirements for an e-government initiative, the barriers to ebXML RegRep adoption by various industrial consortia will also be lowered.

ebXML Components and Relationships
ebXML provides a loosely coupled, highly modular framework for conducting e-business. On the other hand, each module is closely related to other modules (although they can also be used independently of one another). From a software perspective this means that ebXML components have high cohesion and low coupling. ebXML Working Groups have been formed to define each module, so the maturity of each component is also different. Each ebXML Working Group develops its specification according to the group's plan, and its progress depends on member participation. This means that the version numbers of each ebXML specification may be quite different. Some are up to version 2.0, while others remain at version 1.1 or 1.2.

ebXML RegRep clients can access the repository via one of two possible interfaces:

1. Simple Object Access Protocol: SOAP uses simple remote procedure calls (RPC) to send and receive XML messages. The XML messages are used to invoke a Web service and return the results of the invocation.

2. ebXML Message Handler Service: ebXML MHS is an extension of SOAP and adds functionality such as guaranteed messaging, multihop delivery, and enhanced security.

Relationship between ebXML RegRep and messaging components
ebXML MHS refers to CPA (Collaborating Protocol Agreement) for extracting useful configuration information. CPA refers to a business process specification schema for sharing a business process with trading partners. A business process needs business documents to perform business transactions. Each business document format is defined by reusing the data items in core components.

The ebXML messaging component is the most mature module in the entire ebXML framework. Organizations such as Covisint (Auto Exchange), OAG (a horizontally oriented XML initiative), PAA (Pan-Asian Alliance - an international e-business consortium), RosettaNet (XML initiatives for the electronics industry), and STAR (Standards for Technology in Automotive Retail) have already adopted the ebXML messaging plan to provide support for other ebXML modules in the near future.

The Evolution of ebXML
The most important decision in adopting ebXML is to align your adoption steps with the components of the ebXML framework you need. An example of the approach is shown in Figure 1. This alignment is required because the maturity of ebXML components may affect each adoption step. There are no organizations that can/will adopt the entire ebXML framework at the same time. A phased approach to ebXML adoption will guide you through the shortest path to successfully adopt and implement ebXML.

The most accessible component of the ebXML framework is the ebXML messaging service (sometimes referred to as TRP for Transport, Routing, and Packaging). Although the service uses CPA information, the first generation of ebXML messaging can also use an ad hoc configuration file instead of CPA (since the CPA spec is not yet completed). The ebXML messaging service payload (i.e., the "message") can use any standard business document (usually in an XML syntax). The GAO report warns that a wide variety of business document formats and vocabularies may cause barriers to interoperability. While a single, global XML standard for business vocabularies has yet to emerge, several non-XML standards (such as EDI's UN/EDIFACT and X.12) can provide guidelines for defining and processing XML-based transactions.

For the next step of ebXML adoption, a standard protocol profile should be adopted in agreement with CPP (Collaborating Protocol Profile) and CPA. For discovery and negotiation, each trading partner creates a CPP and submits it to an ebXML RegRep. When a CPP is discovered, the potential trading partners exchange CPAs and, once approved, can enter into trade agreements and begin conducting business electronically (B2B). While this scenario will be possible with future versions of the ebXML framework, the current (non-ebXML) B2B model doesn't support such dynamic agreements. The reality of B2B is that the transaction occurs between fixed trading partners. Companies may decide to implement ebXML messaging services while ignoring the entire discovery process. With this approach, potential trading partners simply exchange CPPs and CPAs via e-mail. An ebXML RegRep may be used in a later generation of ebXML adoption, providing support for the dynamic "discovery" process described earlier.

For the third generation of ebXML adoption, companies will adopt ebXML-compatible business processes. These processes may depend on the progress and overall acceptance of collaborative commerce. The automation of business processes for collaboration is the final goal of ebXML and e-business. The focus of ebXML business processes is to provide public processes for collaboration, not a company-specific private process for internal workflow. Companies may face significant challenges integrating their public and private processes.

For the fourth generation of ebXML adoption, companies will focus on reuse, leveraging prebuilt core components to construct standard business documents. The ebXML core components provide a standard dictionary for constructing e-business vocabularies. The ebXML core components data dictionary is designed to be stored within an ebXML registry.

Differences Between ebXML RegRep 2.0 and UDDI
What distinguishes ebXML RegRep from UDDI in Web services? This is one of the questions most frequently asked by companies interested in both ebXML and Web services. ebXML RegRep and UDDI repository each have a different scope and purpose.

An ebXML RegRep, which is more likely to be focused on content management, was designed to store and manage a wide range of electronic trading parameters. UDDI on the other hand was designed to manage the metadata associated with a Web service. In short, ebXML RegRep is the registry for B2B, while UDDI is the registry for Web services.

From a UDDI perspective, the UDDI initiative can provide a loosely coupled connection model with an ebXML RegRep. An ebXML RegRep's registry service specification can be published as a SOAP interface, enabling a traditional Web service that describes how to access the ebXML RegRep using a SOAP client.

From an ebXML RegRep perspective, the RegRep can include a Web services registry within an ebXML Registry Information Model (RIM). A Web services registry is realized in RIM version 2.0. The ebXML RegRep Technical Committee expanded its RIM to categorize Web services as RegRep-compatible metadata. The ebXML RegRep treats Web services as a set of metadata that B2B community members want to share with their trading partners. It is designed to support a wide variety of objects and metadata, while UDDI focuses exclusively on Web services. Table 1 summarizes the primary differences between UDDI and ebXML RegReps.

Figure 2 expands on the comparison of UDDI and ebXML by illustrating the differences in structures and metadata (note that the figure is based on ebXML Registry Information Model v2.0).

Web services is one of many possible core technologies needed to realize the goal of collaborative commerce (sometimes referred to as c-commerce). Implementing collaborative commerce requires far more than a simple SOAP/UDDI-based infrastructure.

Implementing ebXML RegRep
To implement ebXML RegRep, you must first implement the following ebXML specifications:

For overall architecture: ebXML Technical Architecture Specification
For registry: ebXML Registry Information Model and ebXML Registry Service Specification
For registry client: ebXML Messaging Service Specification
For content: ebXML CPP/CPA Specification and ebXML Business Process Specification Schema
For security: W3C XML Signature

An illustration of KTNET's ebXML RegRep implementation appears in Figure 3.

Following are some of the new features and improvements in v2.0 of the ebXML RegRep specification:

Includes metadata information model of Web services ("Service," "ServiceBinding," "SpecificationLink")
Has intramural association and extramural association, depending on the owner of source and target registry objects
Separates metadata information model of classification into "ClassificationNode" for child code and "ClassificationScheme" for root node
Has "ExternalIdentifier" that must have an attribute, "identification Scheme", that refers a "ClassificationScheme"
Has changed the name of "Package" to "RegistryPackage"
Has flatter hierarchy of Registry Information Model than v1.0
Has SOAP binding about registry service including ebXML messaging service binding
No longer provides "Browse and Drill Down Query"
Provides only W3C Schema version for registry schema (not XML DTD)
Provides two key functional interfaces, "QueryManager" and "LifeCycleManager"
Clarifies description of synchronous and asynchronous responses
Adds additional status of "LifeCycleManager" (submit, approve, update, deprecate, remove)
Clarifies registry communication bootstrapping using URL specified in WSDL for registry
Clarifies the specific error handling for LifeCycleManagement protocol

Following is a list of what's missing in ebXML RegRep v2.0:

Doesn't provide backward compatibility with v1.0
Doesn't provide content-based query
Doesn't mention the specific mechanism for cooperative registry (federated registries)
Doesn't provide specific method to store core components

The ebXML Registry Technical Committee is currently working on version 3.0 of the specification, following the release of the 2.0 versions of the RIM and RSS (ebXML Registry Service Specification) specifications. Version 3.0 is expected to resolve most (if not all) of the issues in the 2.0 specification.

ebXML RegRep Adoption
The Pan-Asian Alliance was formed in 1999 by five e-commerce service providers:

Infoshare Information Technology Development Co.: www.infoshare.com.cn (China)

Korea Trade Network (KTNET): www.ktnet.com

CrimsonLogic: www.crimsonlogic.com.sg (Singapore)

Trade-Van Information Services Co.: www.tradevan.com.tw (Taiwan)

Tradelink Electronic Commerce Ltd: www.tradelink.com.hk (Hong Kong).

This year TEDI Club (www.tediclub.com/ - Japan) joined PAA as a founding member.

Dagang Net (www.dagangnet.com/ - Malaysia) is an ordinary member.

Businesses from the participating countries can look forward to seamless cross-border trading, with the ready acceptance of cross-border trade approvals and certification policy; the secure and reliable paperless trade and transactions; and, most of all, the efficiency and convenience of working with the alliance as a single point of contact. Combined membership of the parties now exceeds 120,000 organizations, representing almost all active trading enterprises in the Asian market.

The PAA Working Group had several options for building the PAA technical architecture. Through several face-to-face working group meetings and teleconferences, the PAA WG decided to base the technical architecture on ebXML, which was admired for its interoperability, flexibility, extensibility, and reliability. The PAA WG firmly believes that ebXML will show its true merit and prove to be tremendously beneficial in due time. Figure 4 illustrates the PAA technical architecture.

During the first phase, PAA adopted three components of ebXML: messaging service (TRP), CPP/CPA, and RegRep. Security was handled by the adoption of W3C XML signature and Secure Transport (HTTPS). Figure 5 illustrates the capabilities of PAA's pilot project.

PAA's service providers are conducting test interconnections based on the ebXML messaging service 1.0 and CPP/CPA 1.0 specifications.

What's the role of the ebXML RegRep in PAA? First of all, it manages each service provider's CPP/CPA and each trading partner's CPP. If a trading partner is unable to support ebXML, the service provider creates and submits the necessary information on behalf of its customer's CPP.

PAA has developed its own business document standard using DTDs. The alliance publishes its DTDs, sample XML documents, and guidelines to the ebXML RegRep. Other materials for PAA members can also be shared and managed via the ebXML RegRep.

Conclusion
During the pilot project based on ebXML, I realized the difficulty in designing and implementing a single global standard for e-business. It takes time to guarantee conformance to the ebXML specifications and verify interoperability across the trading partners. The workload increases in a geometric progression, depending on the number of partners in the trading community. Moreover, the ebXML RegRep specification is very broad and has a number of optional features. This causes many difficulties when the goal is to reach a consensus among all partners.

While I participated in the design and development of the ebXML RegRep specifications, the level of effort needed to implement it in the "real world" was quite significant.

One more thing to keep in mind: ebXML can't change the world. Despite its popularity, companies will continue to support their legacy standards (such as EDI, XML/EDI, industry-specific standards). Integrating new technical initiatives with legacy standards/environments can pose a significant challenge. Nevertheless, for the future you're going to have to adopt ebXML, step by step as ebXML evolves.

When will the ebXML dream of a single global market for small and medium enterprises become a reality? I daresay it depends on how you adopt ebXML, coupled with a long-term strategy appropriate to your organization.

Resources
ebXML registries

Korea Trade Network: www.GXMLHub.com

DISA (Data Interchange Standards Association): www.disa.org/drive/

ebXML Registry Open Source Site: http://ebxmlrr.sourceforge.net/

Hong Kong University: www.cecid.hku.hk/Release/PR09APR2002.html