[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] installing compensation handlers for faulted scopes
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]