Summary
Earlier in this tutorial, we talked about service-oriented architecture, SOAP, UDDI, WSDL, and now, briefly, about ebXML. So, what is the value proposition of ebXML today? This will be easier to understand if we step back and take a look at the kinds of Web services that exist. These can be grouped into two broad categories:
-
Procedure-based. A business app invokes a service and gets something back-for example, it sends a purchase order and receives a response.
- Message-conversation-based. A business app invokes a service that could respond asynchronously, and both sides exchange multiple messages to form a conversation-for example, it sends a purchase order and receives a response, after which the app receives an invoice and processes a payment.
Procedure-based Web services use the WSDL-UDDI-SOAP technologies (WUST) stack to realize the publish-find-bind scenarios outlined in . The requirements of the send category inherently impose a level of complexity on the apps. As discussed earlier in this chapter, ebXML has really come into existence to address the requirements of the collaborating businesses and seeks to solve a bigger problem.
Even though SOAP, WSDL, and UDDI are important Web services standards in themselves, they do not address some of the issues ebXML seeks to address. For example, how do businesses describe their capabilities and processes and store them in a central place? How can the businesses engage in reliable, secure messaging? ebXML is a community effort in which many organizations are contributors. As Table 7.1 shows, some of the specifications have evolved beyond version 2, with vendor as well as open source implementations.
|
Version |
Status | |
|---|---|---|
|
Registry |
2.0 |
Approved standard |
|
Messaging |
2.0 |
Approved standard |
|
CPP-CPA |
2.0 |
Approved standard October 2002 |
|
BPSS |
1.01 |
Public review v. 1.05 closed June 2002 |
|
Core components |
1.85 |
Public review closed November 22, 2002 |
Open source implementations of the registry as well as the messaging service can be found at www.freebxml.org.
If ebXML is so powerful, why are few organizations actually embracing it? The issues are twofold. First is the business issue, where organizations want to wait for others to take the risk of trying out evolving technologies. The second, larger, issue is more political. For example even though Microsoft is a member of OASIS, it does not support the ebXML initiative per se, and some of its proposals overlap ebXML functionality. ebXML has its share of issues too. Despite the success of the initiative as a consortium in defining specifications widely agreed upon, the reality is that adoption of the specification is left to vendors and implementers, which are but a handful and only in some areas (e.g., registries and messaging). We have looked at the evolution of the ebXML effort, its high-level architecture in terms of the business process model, the agreements, the registry, and the messaging systems. Our intent has not been to position ebXML or other technologies as better (or not) but to provide the lay of the land in the ebXML world. We have not touched upon some areas of ebXML (e.g., core components and UN/CEFACT modeling methodology), because they are still evolving. We have chosen to present what is possible with ebXML today, so that architects can make an informed choice when designing apps and solutions.