Re: [wsbpel] installing compensation handlers for faulted scopes

[Assaf Arkin <arkin@intalio.com>]

David RR Webber - XML ebusiness wrote:

>Arkin,
>
>This sounds suspiciously like how BPSS handles this - see 
>attached diagram for repair parts ordering - where steps, 
>actions, and succeed / fail sets are linked as components.
>
>Of course in the example these are simple transition binaries,
>but I like the broader object model - instead of the procedural
>iterative one because:
>  
>
If you start with the requirement that the language should support the 
way people do business and not the other way around then there are not a 
lot of surprises. Eventually all the useful languages would do things 
quite the same way, and the variety of languages you have like BPSS, 
BPEL, BPML, XPDL etc is proof of that.

I guess the difference between BPSS and BPEL is that BPEL doesn't assume 
business users would be writing XML definitions of their processes. So 
it doesn't care what the XML language looks like, more than UML-users 
care what XMI looks like. For example some tools <shelfless promo comes 
here> let you model business processes in a way you understand them, 
which is not much different then UMM diagrams (again nothing to invent 
here). They may end up producing BPSS or BPEL or a definition in any 
number of other languages.

Indeed the smarts are in the runtime engine. The smarts are also in the 
modeling engine. And they both work together to achieve an overall 
effect that often looks like magic. A good modeling tool lets you model 
processes the way you see them regardless of how they get defined for 
the engine. Not all products are there yet, but I suspect this will be 
the growing trend in the coming years. Because the business user doesn't 
care what the language looks, neither does the language care what the 
business user looks like, it liberates the language from being an 
adequate visual representation of the process. Once you do that the 
language becomes more expressive and can do more interesting things.

This is probably not apparent from the current crop of products, but BPM 
systems would definitely move in that direction separating the XML 
definition from the visual notation, making life easier for the business 
user but allowing for powerful execution engines. Anyway, that's just my 
guess and the usual disclaimer applies ;-)

arkin

>1) Its much easier for business users to understand as it models
>     their visualization of the sequences and events and coupling
>  
>
>2) Things don't have to be sequential - they can happen in parallel
>
>3) The 'smarts' are in the runtime engine - and the user is freed from
>     the mechanics of writing procedural code.
>
>This being said - the notion of using the BPSS model as a highlevel
>design tool to orchestrate BPEL components that become 
>'choices' business users can add to their processing is definately 
>appealing.
>
>Thoughts?
>
>Thanks, DW
>  
>