[ebBP] 6/17/2004: Monitoring and Events

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Everyone,
Recently there was a side discussion related to business process 
monitoring, events and dialogs. I've included a snippet that may be 
relevant for tomorrow's meeting (as we also seem to have been including 
begins-endsWhen and pre-post conditions). Recognize this discussion 
spans both v2.0 and v3.0. Thanks.

> Yunker: Thus you still need a state model at the BPSS, but instead of 
> the state model "driving" the collaboration, the state model both 
> "monitors" the collaboration and "specifies event visibility" of the 
> service layer model.  Thus the BPSS state model and its expression 
> become incredibly simple (enumeration of the semanitic business 
> events), and the complexity is forced onto the mapping of service 
> events (the swarm of technical events) onto business events (semantic 
> business occurances).  This decoupling is extremely powerful as 
> incremental improvements in both service and business layer are linear 
> in their implementation cost, plus additional technical 
> implementations have a simple binding to the business layer.  

Tell: It seem to be a two way street.
at runtime the Events progress two kinds of state-of-affairs:
   1.  businss dialog or constrained bpss
   2.  businss entities or constrained businss objects such a resource, 
commitments, obligation, etc. at design time / contract signing time the 
business requirements expressed in business dialog, bpss, cpa, tpa, bla 
drive the service level implementationand required features.
 an example: the definition of DataMessage::Reach::Event may stipulate 
that this event may not be generated unless condition a,b,c has been 
fullfilled and validation checks such as completness testing, 
verification of sender identify, etc.