Re: [ebxml-bp] [ebBP] Tell 5/26/2004: Effective Use of Business Event Mechanisms

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

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