As Web Services can be produced and consumed by any programming language on any platform, this enables loose coupling across heterogeneous systems. Dynamic computing is achieved through support for dynamic publication and discovery of Web Services being offered over the Internet.

The Web Services architecture comprises a number of key building blocks that combine to enable the Web Services computing model. Fundamentally, there are three distinct building block technologies:

1. Service description: For a Web service to be useful, at a minimum it must be published in a manner that allows consumers of the service to understand its function and the type of inputs and outputs the service expects, and determine the transport protocols that can be used to "talk" to the service and discern where on the Internet the service can be engaged.
2. Service Publication and Discovery: For a Web service to be useful it must first publish its availability in a manner that permits discovery by interested parties.
3. Service usage: Once a service description has been obtained via the discovery mechanism it must be possible to use that service through standard communication mechanisms.

In the remainder of this article I will explain how Electronic Business XML, or ebXML, takes the Web Services computing model and defines a standard for applying these technologies to meet real world business demands. To provide a clear frame of reference for you, I will consider more familiar Web Services technologies in parallel with our ebXML discussion while considering each of the core building blocks of the Web Services architecture in turn.

Service Description
This component of the Web Services architecture requires a mechanism that allows a meaningful description of a service to be defined. Web Services Description Language (WSDL) is a common XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. A service name combined with knowledge of the service provider may well give a WSDL-defined service some business context, but no formal business semantics associated with these types of services can be specified.

The ebXML architecture defines the Business Process Specification Schema (BP Schema). This XML Schema supports the specification of business documents and transactions and the required choreography of these transactions that comprise a complete business collaboration.

As service interactions are modeled as collaborations, either binary (two-party) or multi-party, it follows that a participating party must-agree to play one or more roles in a collaboration. When publishing a service a party selects the roles they are willing to engage in.

In essence, the BP Schema lends sufficient functionality for businesspeople to model interactions with a service applying real business context. This context is formalized through the BP Schema description and all interested parties can explicitly reference this business context at service publication.

Service Publication And Discovery
As stated earlier, for a Web service to be useful it must first publish its availability in a manner that permits discovery by interested parties. The notion of a registry is used to aid in this goal. A company submits a service description to an Internet-accessible registry, which acts as both a store for service descriptions and a means for service discovery through browsing and intelligent search utilities. Universal Description, Discovery and Integration (UDDI) is an example of a registry mechanism that can be used for Web service publication and discovery. UDDI can therefore be used, for example, to publish WSDL-defined services, making them available for discovery and usage.

To publish a "business-ready" service the service description must consider more business-critical parameters before publication. These can include the quality and level of service that can impact the execution of the service, the communication between service provider and consumer, and the ability, if any, to handle failure conditions or recovery procedures, in addition to the types and granularity of security expected among others.

The ebXML architecture defines a Collaboration Protocol Profile (CPP). A CPP is an XML document that allows a party to express both the business collaborations in which they can engage and the quality and levels of service they can support in delivering that service. A CPP therefore defines the comprehensive set of capabilities of a single party, from both a technological and a business context. A formal CPP description can be published and then universally understood by interested parties.

Publishing a CPP is achieved by posting the document to an ebXML global registry. An ebXML registry provides a set of services that enable the sharing of information between trading partners. An ebXML registry supports more than just service description publication and discovery. Catalogs of reusable business collaboration definitions and reusable busi-ness documents are also made available through the registry. A CPP can simply refer-ence a business collaboration or document defined within a registry if so desired.

I should point out here that UDDI and ebXML registry services can complement one another. In real world deployment environ-ments it is probable that UDDI will be used to discover services published in UDDI registries that link to ebXML registries for ebXML-enabled services.

Service Usage
A simple Web service can be engaged as soon as a description for that service has been found. In a business environment where two or more parties plan to engage in electronic business, the terms and conditions of engagement need to be formally agreed upon and then adhered to.

As noted in the preceding section, a CPP defines the capabilities of a single party. Agreement must therefore be negotiated between parties. The ebXML architecture defines a Collaboration Protocol Agreement (CPA). A CPA is an XML document that represents the intersection of two CPPs and is mutually agreed upon by both parties who wish to conduct electronic business.

Negotiation patterns exist that can be executed over the ebXML transport that enable CPA negotiation between business parties. A CPA is negotiated after the service discovery phase. A CPA then governs the interaction behaviors of a party by con-straining the runtime environment to a set of parameters agreed to by all parties who will execute such an agreement.

Once a CPA has been agreed upon, electronic business interaction may com-mence. While WSDL-described services per-mit transport bindings to protocols such as SOAP and HTTP, it is the ebXML messaging service that provides a standard way to exchange business messages among ebXML trading partners. The ebXML messaging service provides a secure, consistent, and reliable mechanism to exchange messages between users of the ebXML infrastructure. Maximizing the benefits of SOAP 1.1 messaging supporting MIME envelopes that permit direct attachments, the ebXML transport extends and embraces the value of what has come before. It is its ability to transport payload of any type, with sequencing of payloads in complex communications, supporting comprehensive security mecha-nisms and non-repudiation all while enforcing the "rules of engagement" as defined by the active CPA that make the usage of ebXML transport a further key component to "business-ready" Web Services.

Conclusion
I promised to explain how ebXML takes the Web Services computing model and defines a standard for applying these technologies to meet real world business demands. This article should have identified for you the business-critical demands and the technologies required to meet those demands at each level in the Web Services architecture. While there is real value in the simple Web Services of today, if Web Services are to deliver on current expectations in the business domain, I firmly believe it will be comprehensive initiatives such as Electronic Business XML that will make that happen.

Author Bio
David Russell is CTO and cofounder of Bind Systems (www.bindsys.com), a software vendor developing Web Services technologies to enable collaborative electronic business. Bind Systems develops the BindPartner Business Collaboration Platform. Russell lives and works in Bublin, Ireland
dr@bindsys.com