The fundamental notions behind Web service implementations are not new. In fact, many people would argue that their existing Internet RPC systems are Web services. What is different is the use of XML, and XML messaging structures based on SOAP, to control and support these services. This provides a consistent, open means of interaction that is easy to understand and assimilate; and this is what drove the original HTML content revolution and the birth of the Web itself.

Consistent business interactions are the very essence of what the ebXML specifications are all about (www.ebxml.org) and provide the means for simple and ubiquitous global commerce through the use of affordable XML-based infrastructure. Given the level of commitment from significant industry groups and government sponsors, the adoption of ebXML will reach critical mass during 2002. A key factor in this is organizations needing to adopt open, mature, and stable XML technology that will position them not just for current requirements but for long-term future needs. Providing the basis of this are the ebXML messaging services known as TRP (Transport, Routing, and Packing) that ensure consistent and dependable exchange of content and services.

When these ebXML message handling service (MHS) specifications were developed, keen eyes immediately saw a broader relevance for the enveloping and SOAP-based interchanges than just replacing old-style EDI package services. Indeed, Web service-based implementations of ebXML MHS can already be seen at sites such as www.catXML.org, where catalogue information consolidation and remote querying are available using ebXML-compliant SOAP messaging systems as the basis for a dynamic query/ response system.

As people implement Web service interfaces and seek to contribute them to the overall body of the Web, they realize that they need to define details about those services. If the service is e-business related, then the natural place for this is ebXML. The foundation of the ebXML process itself is fundamentally built around another key piece of the puzzle: registry services. When you consider the needs of messaging services, you quickly see the key role that a registry provides to a community of interest within industry or trading partner networks. The registry serves up consistent and reliable exchange information on definitions, content, process steps, and participants' profiles that allow smooth and efficient business processes to be built and deployed. These are vital facets of long-term, sustained, and dependable Web services.

While XML provides the means to have consistent exchanges, this is not enough by itself. The semantics and meaning of the actual content, and how and where the Web service interface functions are, are required prerequisites to consistent interoperability.

The ebXML specifications provide all of the artifacts needed to enable e-business systems within the context of Web services. In fact. an excellent example is the bootstrap for registry services themselves. The ebXML registry services also use the ebXML MHS system to provide direct machine services. Within this context, you can define the support the registry provides, its own profile of standard queries and responses it implements, and then the means to bootstrap the registry so that machine-addressed interfacing to the registry can be configured. A typical implementation is showcased at http://registry.xmlglobal.com; this software represents the first commercially available ebXML registry system. Other ebXML registries are available as code bases from Sun and IBM, and at least two more software vendor companies are working on their own commercial product releases as well.

The other major player in the arena of directories of Web services is the UDDI initiative. The UDDI approach to this integration puzzle is the use of tModel definitions. Work is underway to make tModel and ebXML specification definitions for common e-business artifacts interoperable. The goal is to align the ebXML and UDDI work on directories. UDDI adds significant value above an ebXML-based system by providing the business directory of Yellow and Green pages definitions. The ebXML system itself provides the robust e-business interchange mechanisms and open standards across industries and platforms that are required for the physical XML-based application-to-application (A2A) and business-to-business (B2B) low-level couplings. This includes such things as business process and information transformation scripting. Vendors are now scrambling to differentiate their existing EAI (Enterprise Application Integration) toolsets and promote enhanced XML and ebXML processing capabilities to augment their existing suite of tools. One of the first to announce this was iWay Software (www.iwaysoftware.com), an Informaton Builders company, who released their XML Transformation Server (XTS) as part of their Enterprise Integration Suite in November 2001. XTS embeds XML Global's (www.xmlglobal.com) data transformation engine, which includes Web services and registry interfaces.

The whole area of supporting Web services and providing rich and consistent interoperability specifications for these is only just beginning. Key players such as ebXML can immediately provide value in this arena, and work is already underway to enhance the registry specifications to provide augmented tools specifically for Web services. More information on this work is available from the registry development team Web site at http://www.oasis-open.org/committees/regrep.

Larger businesses and government departments can be expected to take advantage of the opportunities that consistent specifications provide to roll out enabling business interfaces for their larger communities of customers. Providing reliable, controllable, and consistent interfaces will be key factors for them. In this context, ebXML will clearly play a key role in allowing businesses to offer return on the their investments in XML-based technology infrastructure.