ebXML: The Missing Ingredient for Web Services?
ebXML: The Missing Ingredient for Web Services?
Jun. 19, 2002 12:00 AM
Web services has the potential to transform e-business into a plug-and-play affair. Not only will Web services simplify how businesses interconnect, they will also enable businesses to find each other.
One reason for the increased interest in Web services is the promise of interoperability. However, complex standards are needed to achieve true interoperability, not only at the messaging and transport layer, but also at the business (application) layer. The success of Web services will depend on how easily businesses are able to engage interoperability at all levels.
There have been many efforts at standardizing Web services, but none of them provides the required features for e-business transactions. Web services standards only address the infrastructure side, but ebXML can provide the standards for interoperability at the business layer, making it the standard solution for Web business services. In other words, ebXML is the missing ingredient for Web services.
ebXML: What Is It?
The reason for the successful creation and approval of the ebXML infrastructure specifications was that nothing new was invented. The project teams evaluated proven technology to be used as the baseline for all specifications. The editing teams leveraged as much existing technology as possible, including the World Wide Web Consortium's XML Schema, XML Linking Language, and the XML Signature Syntax and Processing specification. In addition, several references from the Internet Engineering Task Force's Request for Comments were considered. New initiatives that were launched well after the ebXML project started were carefully examined, including Security Services Markup Language (SSML), Simple Object Access Protocol (SOAP), and Universal Description, Discovery, and Integration (UDDI). SOAP was successfully incorporated into the ebXML Message Service Specification.
The ebXML infrastructure as documented in the suite of approved specifications provides the only open, out-of-the-box, standards-based solution ready for use. So what sets ebXML's solution apart from the rest? Many commercial solutions are available, however, none simultaneously supports all the business verticals. Enterprises electing to use one of these commercial solutions may not be able to participate in a truly global business environment.
ebXML Infrastructure Elements
The Registry/Repository component supports all of these functions, making it a major piece of the infrastructure. The ebXML registry provides a set of distributed services that enables the sharing of information. This simplifies business process integration between business parties. The Registry provides the interfacing access services by means of the registry information model and reference system implementation, while a repository provides the physical back-end information storage. For example, an ebXML registry may retrieve configuration information for a particular business entity from the Repository in response to a query, or the repository may contain document type definitions or schemas that are retrieved by a registry query.
Collaborative Protocol Profiles (CPP) are another key element of the infrastructure. The CPP specification is based on the Trading Partner Agreement Markup Language (tpaML) work begun by IBM. The IBM work was enhanced by the efforts of the ebXML Trading Partner Agreement project team to produce a method for defining the transport, messaging, and security environment of a specific business entity. Also, the team defined methods for dynamically exchanging the CPP data between business entities and negotiating message-exchange agreements between the parties. These profiles may be maintained by the individual business entities within the ebXML business domain or may be stored within an ebXML repository.
Information packaging and transport mechanisms, specified in the ebXML Message Service Specification, are the third critical component of the ebXML infrastructure. A protocol-neutral method for exchanging electronic business messages is defined in this specification. Enveloping constructs are specified that support reliable, secure delivery of business information. These flexible enveloping techniques permit ebXML-compliant messages to contain payloads of any format type. This versatility ensures that legacy systems using traditional syntaxes (i.e., United Nations Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT); ANSI X12; or Health Level 7 (HL7)) can leverage the advantages of the ebXML infrastructure along with users of emerging technologies. Interestingly, both IBM and Microsoft were instrumental in persuading ebXML to adopt SOAP as the foundation for its message services.
The other two areas of work contributing to the ebXML framework are Business Process and Information Modeling (BPIM) and Core Components; both relate to the content and context area. The business process team defined a metamodel that described business transaction patterns used to achieve business goals. In simple terms, these atomic business processes prescribe the detailed interaction of business documents and business signals among parties, called choreographies. ebMXL processes define activities such as "order goods" or "deliver goods," as compared with traditional EDI documents that are electronic versions of paper documents such as purchase order or ship notice.
Core components are reusable data elements found in business documents. They're semantically neutral objects; their actual meaning in business documents depends on their context, provided by the business domain and industry in which they are applied. Core components can be single elements or aggregates, defined as natural collections of core elements. A telephone number, for example, may contain a country code, city or area code, and number that when strung together constitute an aggregate. Core components provide the means for industries to continue using their own terminology in business documents, and at the same time relate their terminology to common business processes and neutral identifiers provided by ebXML. As long as trading partners can relate their own terminology to neutral ebXML core components, businesses have a basis for achieving interoperability.
ebXML: Phase Two
UN/CEFACT is continuing the work started under ebXML Phase One, that is, to advance ebXML development as related to business processes, core components, and e-business architecture.
UN/CEFACT has adopted a business process and information modeling methodology, referred to as the UN/ CEFACT Modeling Methodology (UMM), that provides the framework under which the ebXML project teams concurrently develop technical specifications that fit seamlessly together with sufficient detail for ebXML-conformant implementation. An ebXML business process and information model draws from reusable components such as
The business process and information modeling and core components work carried over from ebXML Phase One has come to fruition in Phase Two with the benefit of much iteration of revisions and comments. The modeling information required to enter and determine successful execution of a business collaboration or transaction, i.e., states of business entities, is benefiting from the CC library as a reference for conceptual information entities. Business entities are then elaborated in the model of "on-the-wire" business documents as normalized business information entities.
The UN/CEFACT e-business Architecture provides the umbrella specification that covers the work of all the UN/CEFACT e-business projects. As such, it elaborates on the Phase Two ebXML projects and shows how they relate to the other e-business activity in UN/CEFACT.
Future of ebXML: What's Required for Its Success?
ebXML and Web Services Standardization
As pointed out, there are some business-critical functionalities (collaboration, security, etc.) missing from the current narrow definition of Web services (SOAP, WSDL). Without this functionality, Web services won't be used for industrial-strength and mission-critical applications. Efforts are currently under way in organizations, consortiums, and standards bodies to fill these gaps with specifications that use the same language from and are aligned with the current Web services definition. Most of those efforts compete directly with various components of ebXML. It is perplexing that some organizations start new efforts such as WS-I immediately after having contributed to a similar effort in ebXML Phase One. WS-I's founding companies were key players in that phase, but instead of acknowledging that ebXML solved most of the problems, they're trying to readdress them, ignoring their own prior work.
Since the ebXML framework is a neutral technology, why not provide mappings from the ebXML specifications to Web services technologies? Why not use the ebXML content and context work as a standard way to define the business semantics in Web services to achieve interoperability at all layers?
The ebXML framework is the missing ingredient for Web services. The ebXML development effort could fail to seize this collaborative opportunity, and Web services vendors could "standardize" on one of their preferred proprietary solutions. However, if ebXML does grab this opportunity, its vision for a global economic exchange standard will be brightened indeed. Current Web services are just a stopgap measure. However, if the ebXML work can engage Web services initiatives in a tactical alliance, the broader UN/ CEFACT objective of Web resources as business entities engaged in collaborations will be realized. Remember, the XML implementation aspect of ebXML is just the next generation of EDI. The following generation (within five years?) will likely be different from both the current Web services and ebXML.
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week