CEP vs WSDL + SCA + BPEL
Posted by Paul Vincent
Apart from classic Complex Event Processing (event abstraction across time, source, type and attribute) applications for situation-awareness type problems, TIBCO BusinessEvents is also finding uses in sophisticated / dynamic event-driven processes that cannot be fitted easily / entirely within representations such as BPMN, BPEL, etc. Of course, there are many other ways of deploying complex processes across services: consider the wsper project, for example, that aims to exploit and combine WSDL, SCA and BPEL [*1]. Their provided example, interestingly, also maps very nicely onto an EDA using a combination of state model + rules, which have the added advantage of declarative rules that can handle any out-of-process (i.e. complex exception) event [*2] - something BPEL can’t handle [*3].
Notes:
[1] I don’t agree with the wsper metamodel (documented here), which defines an “event” as a subclass of operation, and “state” as an attribute only of event. This seems far too restrictive, although it might fit wsper’s SOA perspective.
[2] Consider the (unfortunate) case whereby, in the supplied HR example, your job candidate “expires” (RIP) in the middle of this process. You would not want your business process to attempt communication with the dead - you need some flexible, declarative, cross-process exception mechanism. This is typically handled by a “rule”…
[3] On the topic of BPEL we also note one effort looking at retrofitting “event processing” constructs into BPEL. Why not event-driven COBOL, too, one wonders? A more interesting project would surely be standardize the event modeling level (e.g. extend BPMN for CEP, or map CEP to BPDM), rather than trying to force event processing into BPEL (insert here visions of pigs in party frocks). No doubt this topic will come up for some (lively) discussion at the EPTS meeting on CEP standards next month…
BPM, Complex Event Processing (CEP), EDA, SOA, Standards | 19 August 2008 |
2 Comments
Other Links to this Post
RSS feed for comments on this post. TrackBack URI
By Opher Etzion, August 20, 2008 @ 00:02
Hi Paul.
Let’s discuss in Stamford.
The attempt is not to force event processing inside BPEL, but enable BPEL engines to easily serve as consumers and producers to event processing - somewhat different things.
cheers,
Opher
By vincent, August 21, 2008 @ 01:11
Hi Opher - thanks for the clarification (see note [3]) - adding event production (and to some extent, consumption, normally through invocation), makes perfect sense for BPEL, although I’m surprised its not already there.
See you in Stamford!
Cheers