Re: [ebxml-bp] 1/5/2004: Late Binding ....

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

Monica,

I do NOT see any conflict here with BPEL!  Nor can BPEL claim
to have an exclusive on something - likewise BPSS of course.

BPEL is clearly Java-EAI programming as XML-scripting.
While they may take a uni-centric view of their collaboration
flows - that is not to say that's the only way BPEL works.

Similarly with BPSS - its a B2B business-process model and
worldview - that can be formalized as XML scripts.

Back to there being main and supporting processes in a
collaboration.  I see this as being a perfectly normal and
natural way to look at this.  Again - I reference the
AutoTech GM/Nissan scenarios (OK- we're getting tired
of these - but heck!) - http://drrw.net/visualscripts/#ebxml

Where you can see why part of the process is labelled MAIN
and part SUPPORTING.

The really cool thing from a BPSS perspective (and its much
harder to see how BPEL could do it - if at all - becuase of
its tight coupling to WSDL) - is that the whole BPSS from
GM/Nissan can be built-up from smaller
BPSS sets, and then one is designated as the MAIN and
the others SUPPORTING.

We're not breaking the BPSS model here - we're strengthing
the way it can be used in realworld deployments.

Cheers, DW.

----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: <ebxml-bp@lists.oasis-open.org>
Sent: Monday, January 05, 2004 8:34 AM
Subject: [ebxml-bp] 1/5/2004: Late Binding ....


> Webber: .....It's going to take some careful wording to get this all
> tied down neatly.
> We start from the binary collaboration and how that is defined by the
> CPA, and
> that context parameters and outcomes are known.  Then on to multi-party -
> where one party has to own the process - and create agreements with the
> participants.  Then - the owner will manage the controlling BPSS - that
> may involve sub-BPSS interactions.  Each participant in a sub-BPSS will
> know what their outcomes are - and have a CPA.  Overall - only the owner
> of the master BPSS will know what that does - and they could have dynamic
> runtime branching - but even they will want that locked to a
pre-determined
> path - it will not self-modify!  The control mechanisms are versioning and
> locked registry artifacts.  So if anything changes - the BPSS should
> treat that as a Fail condition - and react accordingly.
>
> mm1: David, the one-party control/view is part of BPEL rather than BPSS.
> I agree that the most relevant and known (pre-determined) paths will be
> defined
> to allow those to be used. We do need to speak further about the
boundaries
> of BPSS and CPA, and we do have a work item to do so. This is particularly
> relevant as we broaden the BPSS functionality. Let's stay focused on
> BPSS; we
> have ample participation to ensure we can attain loose coupling with CPA
and
> ebMS.
>
>
>
>