InformationWeek

The spec also identifies steps for identifying common and industry-unique processes and components that aren't yet included in an ebXML-compliant registry. The methodology should also identify cross-references to tools for performing discovery and analysis such as modeling techniques and the analysis process conducted by a cross-industry group.

A shared registry and repository will provide a mechanism to let companies find each other, agree to establish business relationships, and conduct business. The repository will let companies register and discover each other's business services via partner profile information. It will also support the definition of and agreement on a formal collaboration protocol agreement. Finally, it will provide business-process models and related message structures.

A registry is a mechanism where relevant documents and metadata about them can be registered and pointers can be created to indicate their location. All the metadata associated with a registry entry can be retrieved as the result of a query.

A repository is a location or a set of distributed locations where documents reside and from which they can be retrieved by conventional means, perhaps with additional authentication and permissions to ensure security. The ebXML registry and repository will support a network of registries and repositories that can intercommunicate via the interfaces specified by ebXML.

In realization of what it will take to get ebXML accepted by the global business community, the group working on registry issues is designing a registry and repository architecture that can be established by an industry group. It realizes that the concept of a single repository isn't scalable and doesn't promote the idea of a global Web.

If the ebXML specifications are to live beyond the initial 18-month time frame, someone will have to maintain responsibility for ebXML technical specifications, ebXML workgroup deliverables, and ebXML glossaries in an ebXML-supported repository.

However, if the decision is made that ebXML won't exist after the initial set of deliverables, or that ebXML won't maintain or support its own repository, then the member organizations will determine if repository oversight responsibilities for ebXML technical specifications should transition to the United Nations' information technology bodies, XML.ORG, BizTalk, or some other XML business-standards organization.

Security must be a fundamental consideration for any kind of information exchange, particularly one dealing with potentially sensitive business data. Current ebXML designs call for security at either a session layer--for the duration of a network session in which data is exchanged--or applied to a single, standalone document instance. Such application of security to a particular exchange or document instance must be determined by business needs and must allow unrestricted and unsecured interchanges as the default.

Several major security requirements must be addressed for ebXML to be accepted:

• Confidentiality: Only the sender and receiver can interpret a document's contents;
• Authentication of sender: Assurance of the sender's identity;
• Authentication of receiver: Assurance of the receiver's identity;
• Integrity: Assurance that the message contents haven't been altered while en route;
• Nonrepudiation of origin: The sender cannot deny having sent the message;
• Nonrepudiation of receipt: The receiver can't deny having received the message; and
• Archiving: It must be possible to reconstruct the semantic intent of a document several years after the creation of the document.

The biggest challenge of ebXML is to create a framework for automating trading-partner interactions that's both generic enough for implementation across the entire range of business processes and expressive enough to be more effective than ad hoc implementations between trading partners.

The ebXML specification for the application of XML-based assembly and context rules describes how business rules are formed. Given that companies around the world operate in many different ways, it's unlikely that any single standard could possibly incorporate those many variations.

This specification tackles two aspects of the task, assembling core component schemas into full business document schemas and modeling core components for business documents that provide useful building blocks for real-world trading scenarios. This is a complex task, in no small part because of the need for organizations to communicate business documents effectively with the least amount of human intervention.

One of the complexities of this process is context--a framework for adapting generic core components to specific business needs, while keeping the transformation process transparent so that the processing engine can find a useful set of common information usable by different trading partners. Having context rules tries to alleviate problems that result when trading partners in different countries have contradictory requirements.

The assembly and context rules specification group is the first to release an XML-based spec that describes how core components can be assembled into a useful business object, such as a simple purchase or-der or more complex transactions.

EbXML is in the very earliest stages of development, and its future is in no way assured, even if the results of all the work proves to be solid technology. But it has some industry heavyweights behind it. Oasis provides solid technical credentials and the United Nations Economic Commission for Europe's Centre for Trade Facilitation and Electronic Business gives it credibility in the international business community.

Sun Microsystems is one of the dominant companies behind ebXML, and representatives from IBM and Oracle figure prominently on several of the committees. But one name is noticeably absent: Microsoft. This isn't surprising because its BizTalk initiative is a direct competitor of ebXML, and BizTalk has the lead with shipping technologies.

A recurrent theme throughout the draft ebXML specifications is the need to interoperate with other interchange technologies, and BizTalk is always included in the list. However, it remains to be seen just how well that interoperability works in the final specifications.

Another issue is which organization will be the guardian of ebXML once the specifications are developed. The initial working group pulled together an impressive group of people and organizations, but there are signs that Oasis and the Economic Commission for Europe's Centre for Trade Facilitation and Electronic Business are unenthusiastic about continuing that work. If that's the case, Oasis would be a logical choice to take over ebXML.

It also remains to be seen how complex it will be to implement these technologies and whether small businesses will be able to take advantage of this work. There will also be many cultural hurdles to clear in order to make this work globally.

No matter where ebXML heads after May, there will be some useful designs for global business interchange. Even if ebXML fizzles, it will have been a useful exercise that can make the world even smaller than it already is.