Friday, December 05, 2003


Who Gets to See BPEL?

Here's an interesting question that probably provokes a debate depending where you come at the problem from (developer centric or business analyst centric) or what your current product offering is or is going to be: How should BPEL as a language be presented to users - be they developers or business process integrators? Do they get to see BPEL at design time or is it only a construct used under the covers?

On one hand, there are folks who live and breath BPEL - they can write it in their sleep. I've been in meetings where folks happily write out BPEL scenarios on the whiteboard. These folks simply need an validating schema editor that lives off the BPEL XSD (for example, JDeveloper lets you register XSD's for inline instance document validation/code insight as well as providing a built-in XSD modeller).

Then there are ordinary mortals like myself who who prefer to have some sort of visual environment beyond a validating XML schema editor. As a start, re-arranging some of the property and component palettes in JDeveloper, you could easily use its XML editor as a hierarchical BPEL editor (actually it will do this for any XSD bound instance document). IBM has prototyped something similar though prettier in Eclipse. The main downside, given a large BPEL document, is that this approach might get cumbersome because ultimately you are still editing raw XML.

Next up on the list of sophistication would be a modelling tool where partners, variables, activities, events, faults and so on would have some sort of visual representation. Here there are lots of folks experimenting - Smartdraw.com's VisualScript, Collaxa's BPEL designer, IBM's UML prototype, Bindstudio's Web Services Orchestration tool and lots of BPM/Workflow vendors.

While modelling the base standard will help understandability immeasurably, particularly with the newness of BPEL, representing each BPEL construct will likely again become unwieldy with larger BPEL scenarios - better than raw XML but still one can see another level of abstraction will be needed.

It certainly isn't clear if any one notation will be adopted widely, primarily because the BPEL UI problem domain is not well understood yet. Though I suppose folks may try to formalize it - the topic has been raised in the BPEL TC mailing list. It is clearly early days.

Just the simple problem of BPEL editing is interesting (assuming a file based approach) - it's a complex multi-file synchronization problem - WSDL, BPEL, deployment configuration, XML schemas and more. It's kind of like synchronizing the all the different EJB artifacts in a Java IDE - home, interface, bean, ejb-jar.xml, -ejb-jar.xml, ear etc. A non-trivial problem but one to which tooling can add a lot of value.

The question right now many folks are facing, given the early days of BPEL, is: Is the right approach to start from an abstraction level where BPEL appears only under the covers, or be up front about it and make BPEL the construct the user sees? Regardless of approach, somehow, at some point during design time, enough information has to be provided, inferred or magically found to enable the BPEL language constructs to be fully populated so the process is executable.

I think it is reasonably clear that initially, the latter, BPEL centric approach may be most common primarily because of the pull of "we must obey, demonstrate conformance and be slave to standards" though the former will become predominant as BPEL matures and folks focus more on getting the job done. An analogy can be made to how J2EE has evolved from strident calls to build theoretically correct architectures in 1999/2000 to the emergence of practical design patterns and approaches for common architectural issues in 2001/2002/2003.

Over time, I believe some sort of abstraction will be/must be provided on top of BPEL by most vendors (maybe visual metaphors on BPEL itself) to make it more consumable by the business users. Choreography, as discussed here previously, could be another approach to this - maybe some sort of abstract CDL to facilitate business analyst modelling - though, again, at some point enough information has to exist to make the BPEL itself executable.



comment []
10:51:07 PM