The Prisoner of Venda

Brian Peter Clark — Tue, 26 May 2009 21:01:40 +0100

...with apologies to Rudolf Rassendyll. First rule of blogging: think of a good title. Then think of something to say.

There are not many BPEL (Business Process Execution Language) bukes on the market: a few have BPEL as the primary topic, and some others include BPEL as a subsidiary subject of SOA. The books tell an interesting story. Take, for example, "SOA Cookbook: Master SOA Process Architecture, Modeling, and Simulation in BPEL, TIBCO's Businessworks, and BEA's Weblogic Integration". Or "BPEL Cookbook: Best Practices for SOA-based Integration and Composite Applications Development": the code in this is built on Oracle's presence in the market, the BPEL Process Manager.

A pattern emerges. Vendor tie-in. In fact, the code snippets provided by the Alfresco company as an example of how to beepellify Alfresco assume the use of Oracle's Process Manager and include proprietorial extensions to the WS-BPEL standard. Little ooffles of closed-source magic.

The propulsive force leading to extensions is almost irresistible in relation to mediation of the SOAP message. There is so much useful stuff to be be done in the nukes and crannies surrounding the BPEL standard, and so, naturally, it is done.

On top of the proprietorial problem there is also another restrictive force deriving from technology and methodology. For example, if one's SOA is based on an Enterprise Service Bus (ESB) methodology implemented by Java for Business Integration (JBI), then that is going to restrict the generality of one's efforts. Also, it makes life easier if one can take advantage of an XPath function extension to call some Java in BPEL assign statements.

So there is a little issue. While it doesn't seem difficult to restrict oneself to pure BPEL and eschew extra-beepellular moves, is it worth the effort? Where this hits home in AMSeT is the Alfresco security ticket, which has to be generated in-process and placed in subsequent SOAP message headers. This is straightforward to do in BPEL. However, it consists of adding a SOAP header message to each operation in a WSDL file which might contain over a dozen of the things. Ce n'est pas élégant. Using Web service handlers can work (eg OMII-BPEL) but this does not sit well with the Alfresco security ticket model.

For reasons that will be explained elsewhere, AMSeT is using GlassFishESB, a JBI rig. It would be perverse to use an ESB and not let it do the security headers. And so, that is the plan, NetBeans/GlassFish volente. However, versions will be provided of all the Alfresco WSDLs with SOAP security header elements along with sample workflows.

The AMSeT Project Blog

The Prisoner of Venda