[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [ebBP] Tell 5/26/2004: Effective Use of Business Event Mechanisms
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).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]