[ebBP] Tell 5/26/2004: Effective Use of Business Event Mechanisms

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

Anders,
In our recent discussions, we've touched on two items I would like to 
investigate further to ensure we meet your business requirements for 
events-dispatch-reach in v2.0: Business and/or external events may 
impact the process or specify conditions have been met. For example, 
you've discussed effects and dispatch-reach (transfer of responsibility, 
for example). If we look at the models you have created (some on the 
list, others not) and the Common Behaviors in UML v2.0, the events (You 
called them business events - such as dispatch, reach) are associated to 
message exchange. It appears these events may be outside of the message 
exchange but they provide an external effect on the collaboration 
itself. Let's take a bit of what John Yunker said,

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

And Dale's followup,

"The implication of this for monitoring is that collaboration 
communities seeking to have complete visibility of state will need to 
“broadcast” business event information about document and BTA statuses 
to their collaboration community to arrive at global transparency. There 
is nothing that BPSS can itself do to overcome this limitation as far as 
I can see. The remedy is in creating services or distributed event 
communities that keep all collaboration members informed about the 
agreed upon relevant document exchange and transaction status events. 
Eventually coordination and transaction services may be harnessed as 
sources of monitoring information supporting verification of global 
highly nested processes."

For v2.0, we add a semantic element called 'reach' mapped to the 
date/time create for the signed acknowledgement. Dispatch could be 
designed or exiting your system or entering another one. Does dispatch 
need to be explicit as an element as well or could we use a business 
event type? Do we need any other event based mechanisms in ebBP to 
support this as I see your working model includes dispatch and reach 
with a reference AND underlying criteria? I am not certain if we just 
point ot the reference and let the criteria be transparent to ebBP or 
not. Perhaps you can tell me if I am thinking about this correctly. If 
you look at UML v2.0, this is separate (events from the behavior and the 
objects involved).

As we have discussed and if you agree, this could bring us closer to the 
capability to support legal enforceability at the appropriate layer of 
abstraction. That way we could add more validation checks or 
extensibility to allow validation mechanisms to be used. [1]

In v3.0, we, as discussed, can add the new contract formation business 
transaction pattern, consider the impact of making Acceptance 
Acknowledgement a business message, and how to accommodate reach 'past 
'the desk. :-D

Your thoughts would be appreciated.

[1] I believe we discussed it could be possible that BPSS could have a 
binding that points to an implementation - create date in SOAP header 
(Would like to know how this would work though).