Table of Contents
Introduction
Some of you might be surprised to find an introduction to ebXML in the SOC section. As a matter of fact, ebXML might be the first architecture to be a truc service oriented architecture based on the principles of service oriented computing. I am not sure people were fully conscious of it or intended it to be that way at the time but as a matter of fact it presents all the attributes of SOC, even if "service" is not a core concept as least the way WSDL defines it. ebXML relies on coarse grain services called "Business Service Interfaces" (BSI) which offer a data centric interface (an not an operation based interface like WSDL). These data centric interfaces are expressed as "Collaborations" (BPSS & ebBP) instead of a pair of single sided WSDLs. Ultimately, I think the collaboration model will emerge side by side with the single sided WSDL model. WSDL will be relagated to define interfaces of services that are not "cooperative" interface but rather "client/server". ebXML BPSS/eBBP will be used for cooperative interfaces specifying how peers interact.
"ebXML, sponsored by UN/CEFACT and OASIS, is a modular suite of specifications that enables enterprises of any size and in any geographical location to conduct business over the Internet. Using ebXML, companies now have a standard method to exchange business messages, conduct trading relationships, communicate data in common terms and define and register business processes." (www.ebxml.org)
If I may express an opinion here, there is room for only one standard like this one. B2B is very costly at the scale of an industry (as opposed to a given company). Forcing companies to support more than one communication standard is pure nonsense. ebXML may not be perfect but it is by far the best today, and various working groups are currently (or will) fixing its bugs and shortcomings. Possible alternatives include the BizTalk Framework from ... Microsoft and the RosettaNet Implementation Framework. I cannot find many reference nor people which are using the BizTalk framework. It is so passé to think that it is even worthwhile to control the middleware specification. RosettaNet has publicly announced that they will migrate to ebXML and leave the RNIF behind. Most Business Language consortia such as OAGIS, ACORD, HR-XML, ... have all announced that they will support ebXML.
I know personally a good dozen vendors, small or large which are actively developing ebXML compliant B2B middleware. Some are big and well known, others are small and creative. This means that for most companies, there will be a large spectrum of solutions to choose from. Hopefully these solutions will all be interoperable at some level.
ebXML specifications
ebXML Specifications may be divided into design and run-time specifications. ebXML is not a business language standard, it is rather an infrastructure or middleware standard. So, yes, you can use your favorite business document formats expressed in your favorite schema language (DTD or XML Schema) ! ebXML does not forces you to use any specific business process to exchange these business documents. It merely provides a specification to define "business collaborations" (ebXML BPSS). Once you know what you want to do (document, process and transport), ebXML CPP provides you with a formal way to express your capabilities. All the message transport options may be chosen from the ones of the ebXML Messaging Service (ebXML MS) specification. One can publish its Collaboration Protocol Profile to an ebXML registry using the Reg/Rep "API". Two partners may decide to do business if they support the same documents, processes and transports. This is expressed as a CPA (Collaboration Protocol Agreement).
At run time, ebXML messages are exchanged following the ebXML MS specification.
ebXML Implementation Model
ebXML may be implemented in many ways. Implementations which support a subset of the ebXML specification maybe fairly light weight and based on open source technologies (e.g. servlet engine).
Commercial implementations should at least feature two distinct layers: a messaging service and a business service interface. The role of the messaging service is to enforce the ebXML communication protocol (envelop, security, guaranteed delivery,...) regardless of the content of the messages.
The Business Service Interface (BSI) should enforce the business collaboration protocol (ebXML BPSS). At any point in time, the BSI is able to determine if a message makes sense from a business perspective (is format correct? did it come on time? in the right sequence? ...). The BSI may be directly communicating with an application, but it is certainly wise to use a broker that will dispatch ebXML requests and responses to and from your business applications. Typically, this broker is going to be a business process management system.
Resources
ebXML Forum a lot of good news on the vibrant ebXML community
