[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] [ebBP] Tell 5/26/2004: Effective Use of Business Event Mechanisms
Monica, I agree with Dale - to fully implement this requires a service. That service has already been fully specified in OASIS BCM as the Linking and Switching mechanism for choice points, Appendix B of the BCM specification. I have already stated that this needs to be considered for V3.0 BPSS - and I see this also as a vital piece of ebSOA. I suggest we defer this to V3 and jointly develop this between BCM, ebSOA and BPSS then. As with other aspects here - we need to limit the amount of V2.0 feature creep - when we know that in V3 we will provide a fully enabled solution. My sense is - we have more than enough in V2 now - and we need to ensure that the XSD for V2 works. I now have a couple of critical issues in that area regarding the <BinaryCollaboration> structure in V2 and its use. The recursion there looks very wrong - and the flow support needs to be clarified. Can we please resolve these first - so we know for sure the core funtionality is working here. Thanks, DW ----- Original Message ----- From: "Monica J. Martin" <Monica.Martin@Sun.COM> To: "Anders W. Tell" <anderst@toolsmiths.se> Cc: "ebXML BP" <ebxml-bp@lists.oasis-open.org> Sent: Wednesday, May 26, 2004 11:40 PM Subject: [ebxml-bp] [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]