|By JP Morgenthal||
|October 16, 2000 12:00 AM EDT||
Two standards are emerging that could very well impact the way we conduct e-business in the future. These are ebXML (electronic business XML) and UDDI (Universal Description, Discovery, and Integration), the former a UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business)/OASIS- sponsored initiative whose charter it is to create a single global electronic market. UDDI, however, is a vendor-sponsored initiative led by IBM, Microsoft, and Ariba.
Let's explore each of these efforts individually and then examine their overlaps and gaps.
UN/CEFACT is the same group responsible for EDIFACT, one of the electronic commerce standards more heavily used throughout the European and Pacific continents (the U.S. primarily uses its own version, called X12). Hence, it's my belief that if this work can meet some modicum of maturity and gain a modest following, it's clearly in line for promotion to the throne of e-commerce. That said, this effort is clearly understaffed and the work completed to date seems to illustrate a rudimentary understanding of e-commerce without having actually been part of a real solution.
When complete, Version 1.0 of the specification will consist of six key areas:
- Technical Architecture
- Repository and Registration
- Transport, Routing, and Packaging
- Business Processes
- Core Components
- Global ebXML Definition Dictionary
The second most complete body of work is the Repository and Registration (R&R). This specification will provide a framework for the automated registration, storage, and retrieval of business object descriptions. These descriptions deal primarily with the interactions between application services, such as query, messaging, and transformation applications, and the overall core architecture.
Additionally, the Repository and Registry will leverage the work completed on the eCo Framework under the leadership of CommerceNet. It details how businesses can interact dynamically through the exploration and discovery of publicly documented services. The eCo Framework discusses the need for multiple types of registries, such as Market, Business, Service, Interaction, Document, and Information types.
Currently, the specification available from the R&R Working Group discusses a framework for a generic repository. Although descriptions of business objects are critical to enabling e-business components to communicate, the generality of this framework will come at considerable cost for development and find little support from off-the-shelf tools, a critical component in the adoption of any new technology. Focusing on the eCo Framework types is an excellent way to constrain this work and provide more utility faster.
The ebXML Proof of Concept (POC) Working Group focuses on demonstrating how available technology can be used to implement each of the technical specifications. So far, the only demonstrable technology has come from groups having reliable and secure messaging products illustrating their support of the TRP specification.
However, relative to conducting e-business, the three most critical components are far behind in development: Core Components, Business Processes, and Trading Partner Agreements.
The Core Components Working Group will provide the specifications for business object elements and the methodology for creating new business objects. With regard to the focus of enabling e-business, these are the lifeblood of the system. Without definition of the Core Components, this group will have provided yet another framework for the transport and delivery of empty containers.
The effort undertaken by RosettaNet illustrates how important it is to provide both the specification of the messages themselves and the processes for exchange of documents over a network. The Business Processes Working Group will provide detailed workflows that need to be implemented to exchange documents in an ebXML network. In ebXML, data and processes are viewed as two sides of the same coin, that is, both are needed to enable global trading.
Most recently, IBM turned over to the ebXML initiative its work on Trading Partner Agreements Markup Language (TpaML). TpaML specifies a grammar that captures the metadata of a trade relationship between two trading partners. Examples of this metadata include business contact information, transport facilities, message formats, security protocols, and message vocabularies. Since some of this information already resides in the metadata captured as part of the eCo Framework, adoption of any part of TpaML will require further analysis and assimilation.
In an interesting aside, the ebXML effort relies heavily on a centralized repository model to enable discovery, integration, and automation of its global e-business market. However, experience has shown that attempts to use centralized repositories that support multiple metamodels in real time often won't produce the responsiveness needed by a real-time, transaction-oriented environment. I believe this will cause considerable redesign midstream as implementation efforts by the POC bring this to the forefront.
The September 6, 2000, press announcement of support for the UDDI.org group caused quite a stir among those participating in the formation of ebXML. Of most concern was how the formation of UDDI will impact ebXML.
UDDI is designed to implement a naming and directory service for Web-based business services. By design, companies can provide, as part of their Web sites, a descriptive document that details what services they offer, the transport method to communicate with those services, and the input and output parameters required for exchange. UDDI, however, doesn't provide details or designs for building a facility for initiating a service, an important factor in deciphering its place in the e-business market.
UDDI is based on SOAP (Simple Object Access Protocol), which essentially defines how to create an XML document that will invoke a process on a remote machine and return a particular type of response. SOAP is transport method-agnostic, which means that a SOAP message can be delivered over a number of transport protocols, but is used primarily in tandem with HTTP.
Cause for Concern?
Thirty-six companies, most of considerable size and wealth, have come out in favor of the UDDI specification. In addition, many of them are participating in ebXML, the strongest support for both coming from IBM. What does this mean for areas of ebXML and UDDI that overlap?
First, ebXML is based on SOAP, which is already in opposition to the direction of ebXML's TRP specification. Indeed, those heading up this particular specification find SOAP sorely lacking as a messaging protocol for e-business, and it doesn't look as though they'll accept it anytime in the near future. Therefore, for a minimum of interoperability to occur, it appears that UDDI will have to make the first accommodating move. However, if the business community as a whole accepts SOAP, it may not matter that it isn't the best protocol, and ignoring SOAP could prove to be a liability for ebXML.
Second, UDDI competes with many tenets of the eCo Framework. As I mentioned earlier, the eCo Framework underlies much of the work of the ebXML R&R specification. However, the work completed to date by the R&R working group could easily support either UDDI or the eCo Framework. Interoperability between these two efforts will require some effort to be made on the part of the R&R group.
In many ways UDDI is architecturally superior to ebXML. First, the UDDI repository is a peer-based architecture, which is finally catching on, thanks in part to people's hunger for free MP3 music on the Web (all great technologies need a killer app). Second, the cost of building a global services repository using UDDI is shared by all who would participate, not just one organization spending millions to build a similar centralized version.
UDDI isn't attempting to own the world of e-business, but simply trying to put a consistent face on all Web-based services for query and introspection. By creating this interface, and through the appearance of off-the-shelf software to support it, the industry gains a worldwide repository of Web-based services by default. On the other hand, EDI (electronic data interchange) has proved the need for a global e-business standard, such as ebXML. However, creating a standard of this size and magnitude takes time and patience, which the industry either can't afford or chooses not to provide at this time.
Therefore, to analogize this as a horse race, UDDI is clearly ahead at this time, but ebXML is favored to win. The only thing that could hinder it is ignoring the fact that UDDI is rising in popularity and not overtaking it through adoption. The last thing the world needs right now is another bout with splintered standards.
- Technology of the Year for 2016 | @CloudExpo #IoT #AI #FinTech #Blockchain
- The Two Faces of #Microservices | @CloudExpo @JPMorgenthal #AI #DevOps
- Cloud Operating Model | @CloudExpo @JPMorgenthal #IoT #PaaS #AWS #Azure #OpenShift
- Tail Wagging the Dog | @CloudExpo #CloudFoundry #AI #IaaS #PaaS #DevOps
- Eliminating Redundancy in XML Using ID/IDREF
- A Conversation with Adam Bosworth
- What's the Best Definition of SOA?
- Web Services for Enterprise Application Integration
- Building End-to-End Palm Applications Using Java
- Comparing ebXML And UDDI
- Vivek Kundra, Cash-for-Clunkers & Cloud Architecture
- Conquering the E-Commerce Landscape with XML
- SOAP: Cross Platform Web Service Development Using XML
- CORBA 3.0 Update