OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Process Monitoring - Common Language


Title: Process Monitoring - Common Language

Hello,

for an BPEL Implementation, it is basically simple to list all existing instances of a given process definition. It is also easy to drill into these running instances to see the current variables and link status. But if an business analyst or system operator wants to have a list-view on the running process, and filter for example:

"All process instances instantiated from business partner X where invoice-sum is bigger than USD10k"

the nit gets complicated.

I can see basically 3 ways of a business process definition to interact with the container for management and monitoring purpose:

a) fill variables, on deployment the engine knows that some variables can be printed/filtered-on for monitoring
b) provide onMessage handlers
c) invoke status update (audit/log/state) service


a) has the advantage, that it is the fastest method for a runtime engine to build a list of instances which match, and to query all their interesting attributes

b) has the advantage that complicated state calculations can be done in the onMessage handler, and the info data structure (the output message of the onMessage(staterequest) handler) is decoupled from internal (variables) state representation. Also the handler could access link state via xpath functions

c) has the advantage, that state needs only be recalculated on well defined positions (i.e. where the invoke activity is placed).


a) and b) are easily portable, and even if the engine does not support that monitoring style, the process is basically executable. c) needs support in form of an audit/log/state tracking service.

Personally I think, we should give recommendations in the specification, on how a business modeler is able to communicate state to the outside world. I would like to vote for the "exported variables" solution, because IMHO it is the only real performant way for the monitoring to list and query on the process list. The onMessage handler can be added, for query a more complex state of the process, especially it can be even used from outside tools. But it is not well suited to query the state of all currently running instances.

In addition to both, Vendors will most likely also offer Auditing/Log services. Perhaps we can even have a default extension set of useful services?


It is not critical if we define none of the above points in the spec, but it will essentially make it impossible to write portable and useful executable process specifications.

What do others think?

Mit freundlichen Grüßen
Bernd Eckenfels
Chief Architect
--
SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany
Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256
mailto:b.eckenfels@seeburger.de - http://www.seeburger.de



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]