September 5, 2001-- The standardization of electronic business Extensible Markup Language (ebXML) promises to revolutionize the way companies partner and conduct business. The initiative, sponsored by the standards bodies United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) and Organization for the Advancement of Structured Information Standards (OASIS), has produced a modular suite of XML specifications that enables enterprises of any size or location to conduct business over the Internet.
James Kao, a senior technology partner with The Middleware Company, a training and consulting company specializing in JavaTM technologies and XML technologies, highlighted some of the key components of ebXML: Collaboration Protocol Profile (CPP), Collaboration Protocol Agreement (CPA), Business Process and Information Modeling, Core Components, Messaging and Registry/Repository.
Collaboration Protocol Profile (CPP)
A CPP describes a company's offerings in a standard, portable way.
Specifically, it describes the message-exchange capabilities and business
collaborations that a company supports. It also describes the company's
business processes, including how partners interact with this company. An
interesting facet of a CPP is that a business collaboration includes both sides
of a two-party B2B transaction. For example, in a buyer-seller situation, the
CPP would describe not only the selling process and semantics of the seller, but also the buying process and semantics of the buyer.
Collaboration Protocol Agreement (CPA)
A CPA describes the exact requirements and mechanisms for the transactions
that two companies perform with each other. It is formed from a manually or
automatically derived intersection of their CPP's, which has been reviewed
and agreed upon by both sides. This CPA becomes a contract between the two
parties and specifies the "rules of engagement" for a particular
collaboration.
Examples of a CPP and a CPA, and details of their specifications, can be found at:
Business Process and Information Modeling
ebXML also includes specifications for describing a business process in XML.
This can include transactions, document flow, binary collaborations, data
encapsulation formats, and more. These specifications are used by authors
when constructing CPP's and are also used to describe and share business
processes or information formats.
Core Components
Another crutial part of the ebXML standard are a set of ebXML schemas, also
called components. These schemas contain formats for business data, such as
dates, taxation amounts, account owner, exchange contract, and more. They
are specific to business constructs and entities, but not aligned to any
particular vertical industry.
Messaging
EbXML messaging is a format that encapsulates a message with all the related
message-oriented middleware semantic (e.g. asynchronous/synchronous,
reliability options). In particular, an ebXML message represents the visible
part of the execution of a CPA, and has features specified to enforce the
"Rules of engagement" specified therein.
EbXML messaging is built on top of SOAP-encapsulated message-passing invocations (as opposed to RPC-style invocations). It extends the SOAP protocol by adding layered frameworks that support attachment, security and reliable delivery.
Registry/Repository
The ebXML registry/repository is a service that stores CPP's, CPA's, ebXML
core components and any other ebXML documents or fragments including WSDL
documents, JAR files with Java code and even audio and video etc.
It contains powerful query abilities to allow users to search for relevant components and potential business partners. The JAXR API can also be used to access ebXML registries. Business services defined in CPP's stored in an ebXML Registry can then be published to UDDI.
A key concept here is while UDDI provides a universal singleton source of references to web service information, an ebXML Registry is a local container for the actual information itself. ebXML provides for publishing and discovery of almost any type of artifacts including CPP, Schemas, commonly used XML components, as well as web services.
Thus in a wide-area web service discovery scenario, a potential business partner would first search for a service in UDDI, which would contain a reference to a CPP or other documentation that is actually stored in an ebXML registry. The potential business partner then uses the information in UDDI to access the ebXML Registry where they subsequently discover the CPP for a business partner. They then use the CPP to initiate a partnership agreement for subsequent B2B transactions with the partner.
Although the ebXML specifications are language and platform neutral, the JavaTM API's for XML can provide simple Java client API's for programmatic access to respective ebXML implementations. The Java API for XML Registries and Repositories (JAXR) can work with ebXML's Registry implementations and is designed specifically to make it easy for Java technology programmers to add functionality to their applications for sharing XML-related business information on the Internet. JAX-RPC enables XML Based Remote Procedure Calls (RPC). JAXM, initially code-named the M Project, is designed to enable the messaging service of both XML and non-XML business data across a number of key communications infrastructures, such as those based on HTTP, Simple Mail Transfer Protocol(SMTP), and File Transfer Protocol(FTP).
The JAXR API consists of an open and interoperable set of registry services that enable interested parties to share information. The shared information is maintained as objects in a compliant registry. All access to registry content is exposed via the interfaces defined for the registry services. Currently, numerous open standards exist for distributed registries: among them are OASIS, eCo Framework, and ebXML. In addition, industry consortia are leading efforts such as UDDI, which may eventually be provided to a standards body.
JAXR is designed to provide a uniform and standard API for accessing informationfrom these registries within the JavaTM platform. As a result, enterprises will be able to publish their business information to public registries and repositories where anyone can search for and access that information. Similarly, organizations will be able to maintain private registries and repositories for business information that they wish to maintain and share only with specific trading partners or other organizations.
Different kinds of web services require different kinds of communications models. In some cases, a document based messaging service is called for, which is the programming model for JAXM. In other cases, however, the developer is more concerned with making direct programmatic calls to a remote computing resource that is being accessed as part of the service. In order to support both programming models, the Java API for XML-based Remote Procedure Calls (RPC) will provide developers with an abstract API for implementing RPC style messaging via XML data exchange. Currently, the JAX-RPC Expert Group (EG) is working to support the RPC model in SOAP 1.1 with Attachments in the JAX-RPC. Once other XML-based RPC standards, such as the W3C's XMLP effort, become finalized, the EG may initiate support for them in JAX-RPC.
![]() ![]() |
This specification has been finalized within the Java Community ProcessSM since May, 2001. With JAXM, which supports industry-standard packaging and an asynchronous messaging model, Java technology programmers can easily and quickly build robust, reliable, and secure B2B ecommerce messaging applications.
Suppose a real estate agent wants to market a house through a local listing service. The agent could send an XML document describing all of the attributes of the house and attach a graphic. JAXM will allow the agent's application to attach the graphic and the XML document together in one message and send it out, as a Simple Object Access Protocol (SOAP) 1.1 message with an attachment.
JAXM is designed to support a variety of XML messaging methods, such as SOAP 1.1 with attachments and eventually others, determined by the expert group, as they become standardized. One such messaging method is the ebXML messaging service specification. This specification is intended to provide a global standard for simple, robust, low-cost, and reliable messaging. The specification is a joint development effort between the OASIS and UN/CEFACT. The W3C itself has also initiated an XML Protocol Working Group to define an XML messaging standard that will evolve the SOAP 1.1 specification and potentially unify some of the various XML messaging protocols into a single XML-based messaging protocol.
EbXML: Revolutionizing the Engines of Business
(http://java.sun.com/features/2001/09/ebxmlrev.html)
Enabling a Global Electronic Market: The ebXML Resource Website
(http://www.ebxml.org)
EbXML Technical Specifications
(http://www.ebxml.org/specs/index.htm)
Understanding ebXML, UDDI, XML/EDI
(http://www.xml.org/feature_articles/2000_1107_miller.shtml)
The ServerSide
(http://www.theserverside.com)
Ahead of Its Time: EbXML on Track for an Early Delivery
(http://java.sun.com/features/2000/12/ebxml.html)
United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT)
(http://www.uncefact.org)
Organization for the Advancement of Structured Information Standards (OASIS)
(http://www.oasis-open.org)
Java APIs for XML Messaging (JAXM)
(http://http://java.sun.com/xml/jaxm/index.html)
JavaTM API for XML Registries (JAXR)
(http://java.sun.com/xml/jaxr/index.html)