Re: [ebxml-bp] [ebBP] 6/17/2004: Monitoring and Events

["David RR Webber" <david@drrw.info>]

Monica,

I'm with John on this one.  The key here is to hold the line on
the conceptual model - and business abstraction of the
various component characteristics (aka transport, etc).

And then the implementation is clear, deterministic and
reliable.

I've told AIAG too this is where the sweet spot is - being
able to design without regard to WS* or ebMS vaguries - 
or any other for that matter - MQ, BizTalk, et al.

DW

----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: "ebXML BP" <ebxml-bp@lists.oasis-open.org>
Sent: Thursday, June 17, 2004 2:04 PM
Subject: [ebxml-bp] [ebBP] 6/17/2004: Monitoring and Events


> 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.
> 
>