Composite Materials

Ron Ten-Hove's Weblog
Monday Jul 19, 2004

The paper I never gave: XML Europe 2003 on ebXML BPSS and BPEL4WS

I occasionally get requests for a paper that I never wrote! I recently wrote the following message in response to yet another request for the non-existant paper:


Unfortunately, the paper you mentioned was never written. Due to a clerical error on the part of the XML Europe 2003 organisers, the abstract for a paper I proposed to develop was published on their web site, but in fact the paper was never accepted for presentation. Due to the organiser's lack of interest, I did not write the paper. However, I can share with you some of my observations about the current standards situation (which has changed since 2003). There are my personal opinions, and in no way are meant to represent Sun Microsystems' stance on these issues.

You are not alone in trying to untangle the world of ebXML and BPEL/WSDL/SOAP/WS-*. It is true that ebXML has not found a large following among software providers in America. The fact that Microsoft and IBM are pushing a separate initiative, known to some as the Global XML Architecture (GXA), has lead most of those software providers to conclude that ebXML is the wrong "horse" to bet on. IBM and MS have rather large coat-tails, after all.

This conclusion has not been shared by many software development groups and users outside the USA. Asia-Pacific, and to a lesser degree Europe, have embraced ebXML largely because it is royalty-free, it works, and provides many useful functions (reliable messaging via internet, interoperability, security, UMM alignment). GXA is largely a set of proprietary specs, with no implementations save for the lowest-level components (which are being slowly standardized). The really useful functions of ebXML are not yet available in the GXA world, and won't be for several years. For organisations that don't have the luxury of waiting a few years to see how GXA shapes up, this presents an interesting choice.

The BPSS vs. BPEL debate was largely the result of marketing "wars" related to the ebXML vs. GXA conflict. Comparing BPSS to BPEL is comparing apples to oranges -- they both have different functions in an e-commerce infrastructure. The emerging picture from standards-setting organisations seems to be:

  • At the lowest level, BPEL for performing orchestration of message exchanges. This is a low-level addition to WSDL 1.1, which models message exchanges from a single parties point-of-view only.
  • Above the BPEL level, a choreography language is need to properly model the "global" message exchange model between multiple parties. This is being developed by the WS-Choreography working group, and is currently named WS-CDL (choreography descripition language). WS-CDL maps to multiple instances of BPEL.
  • Above the choreography level is BPSS. This models multi-party business processes using a subset of the UMM. Such processes are mappable to one or more instances of WS-CDL.
This is the developing picture, based on increasing levels of abstraction, as well as a separation of concerns. The main point is that BPEL is in no way a substitute for BPSS, and vice versa.

In addition, the BPSS 2.0 will provide more direct support for WSDL-described services. ebXML CPP/CPA is providing direct support for WSDL as well.

All of these efforts (updated ebXML standards, and the BPEL/WS-CDL/BPSS stack) are aimed at assuring interoperability between the GXA stack and the ebXML set of standards, in places where such interoperability makes sense. Some folks in the industry question whether the GXA authors will allow such interoperability to truly be achieved, but I don't share that concern: customers have a big influence on such things. This is a Good Thing; this will help drive the important qualities of the infrastructure we are developing / standardising.

I hope this has been of some help.

Best regards,

et cetera

Monday Jul 12, 2004

Enterprise Service Bus (ESB)

At JavaOne last month, I was fortunate to receive an invitation to Dave (Sonic) Chappell's launch party for his latest book, entitled Enterprise Service Bus. I spent last week at the beach, recovering from JavaOne, and took time out from digging in the sand to read ESB. This book should be required reading for anyone involved with EAI, especially integration architects.

For those of you who may not have heard about ESB, it is a rather new approach to structuring a SOA (service-oriented architecture), using a distributed MOM infrastructure, XML messages, intelligent message routing, automatic transformation of messages, and centralized administration. The SOA approach to EAI solutions is compelling, and the alignment with JBI is clear, but it is still too early in the game to tell if ESB will take the world by storm. It has a lot of promise, and many EAI vendors are jumping onto the bandwagon that Sonic, including Dave Chappell, helped to build.

The books offers the first comprehensive definition of an ESB that I have seen, almost entirely stripped bare of vendor-specific information and sales info. I say almost, for some issues (such as app-servers vs. ESB service containers) are presented in a less vendor neutral fashion than I would like.[1] Overall, the book stays high on useful content, and low on vendor product positioning.

The books combines nicely described technical descriptions of ESB features with some high-level case studies culled from Dave's experiences in industry, or based on interviews of IT leaders that he conducted while researching the book.

The technical descriptions avoid becoming too detailed, but are sufficient to capture the essential issues encountered in integration. The diagrams, resembling Gregor-grams, are very useful, although I was a bit mystified to find a reference card for the glyphs used, tucked away in the back of the book. The diagrams are self-explanatory, IMHO.

The case studies are similarly abstract, avoiding introducing a level of detail that would cause the forest to be lost amongst the trees. At times I wished to a little more detail here, but I suspect I'm something of a glutton for punishment that way.

ESB is threatening to become something of a buzz word these days, what with IBM weighing into the ESB market. This book should help secure a rational, useful definition of Enterprise Service Bus before the marketing machines of the various integration vendors obliterate it in a storm of white papers and glossy brochures.


[1] Of course, I work for a major appserver vendor, so I may be exhibiting extra sensitivity in this arena.


Archives
Links
Referrers