RE: [ebxml-bp] ActionItem 26 conitnued Nested Collaboration Multiparty, Roles in HaugenFletcher multiparty

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

dwm@

The jpeg sequence diagram and synchronization points seem OK to me. But
is there a way to pull the bpss out of sdr files to view the bpss
instance? 

My question was really how we "interpolate" RequestResponse BTs within a
RequestResponse BT? This is a typical "coordination" problem, similar to
having subtransactions or subcoherences. One approach is to have BPSS
notation indicate nondeterminism on the AND - fork/join control flow,
and let it go at that. This approach is hard to explain to implementers
who want to use it to monitor flows for conformance, it seems to me.
Another is to split the interpolated BT and sandwich in BTs as needed,
marking the synchronization points as needed. This seems to give up on
reusability, but would have the dependencies marked (we could add the
xpath/documents within conditions as the problem suggests.) Other
approaches would be to add to the notation to mark the dependencies. If
we do the latter, the syntax should, in my opinion, accomodate
approaches to distributed coordination (synchronization) ranging up to
actual transaction commit protocols. These would be extensions to BPSS
coming from other specifications (not in our charter scope). The very
simple state synchronization signals of BPSS are not the final word in
treating the problem of coordination, nor should the notation lock us
into this. 

The "extra" syntax could be as an extension to the BTs. If so, these
requirements should become inputs to Martin for his refactoring of the
BT substitution family that he has been rapidly creating.  Since
OperationActivities would also be things that could be
coordinated/synchronized, we should adopt an analogous treatment for
them with respect to coordination/transaction services/messages. 

This may spill over into version 3.0 because despite having an OASIS
committee draft from the BT group, there is as yet no standards body
open coordination/synchronization spec (other than XA and earlier
stuff). There are various WS- specs on the subject which may go to open
review. There is also the WS-CAF group that has an ambition to produce
specifications in this area. Because I think they may finish after the
2.0 draft, I think we will spill over to 3.0. But we should at least
locate how the extension point will work (sort of) and mark the
syntactical place(s) it will be shoehorned into the notation. All the
above with a healthy sprinkling of IMO and as TC member.

Dale Moberg

-----Original Message-----
From: David RR Webber [mailto:david@drrw.info] 
Sent: Sunday, February 22, 2004 3:30 PM
To: Dale Moberg; ebXML BP
Subject: Re: [ebxml-bp] ActionItem 26 conitnued Nested Collaboration
Multiparty, Roles in HaugenFletcher multiparty


DRRW@

Dale,

This is also the same scenario that we did for the AutoTech demo last
August for automotive use case.

The JPEG diagram of this and VisualScript BPSS model is here:

 http://drrw.net/visualscripts/#ebXML

Much easier to see a real diagram and participants to understand how the
multiparty interactions and flows go.

I'm planning to up date this diagram to include the forks and joins on
the flow arrows (right now they are just blue lines with arrowheads
showing the direction of the flow).

If you want to change the use case - its really easy to do in
VisualScript - its just a diagram with labels - and you can change the
AIAG flavour to whatever industry and components makes sense.

Thanks, DW.

----- Original Message ----- 
From: "Dale Moberg" <dmoberg@cyclonecommerce.com>
To: "ebXML BP" <ebxml-bp@lists.oasis-open.org>
Sent: Sunday, February 22, 2004 4:01 PM
Subject: [ebxml-bp] ActionItem 26 conitnued Nested Collaboration
Multiparty, Roles in HaugenFletcher multiparty




Discussion: OASIS.ebBP.WI26-NestedCollaborationsAndRoles;
Topic|Referring,Roles,Reusability;
Point|HaugenFletcher MultipartyCollaboration use case

dwm@

Haugen-Fletcher use case is essentially a retailer, distributer,
manufacturer where the retailer orders something from the distributer,
the dietributer orders from manufacturer and when distributer receives
Response, there is a response to retailer.

I will use an abbreviated way to sketch options, using MC for
MultipartyCollaboration, BTA for BusinessTransactionActivity, BT for
BusinessTransaction, and omitting a lot of syntax.

ProbablyWrongOption #1: We just indicate a Fork over two BTs for a PO,
POConfirm Transaction. Schematically,

<BT name="POTransaction" ...>
</BT>
<!-- ununused in 1 -->
<BT name="PONotification" ...>
</BT>
<BT name="POConfirmNotification" ...>
</BT>
<Role name="Retailer" ...>
<Role name="Distributer" ...>
<Role name="Manufacturer" ...>

<!-- this is option 1 and may be wrong -->
<MC>
<Start ...>
<Fork type="AND" .../>
<BTA ... businessTransaction="POTransaction" ...>
<Performs initiating="true" bindingBy="name" inScopeRole="Retailer"
bindsToRole="Buyer"  /> <Performs bindingBy="name"
inScopeRole="Distributer" bindsToRole="Seller"  / </BTA> <BTA ...
businessTransaction="POTransaction" ...> <Performs initiating="true"
bindingBy="name" inScopeRole="Distributer" bindsToRole="Buyer"  />
<Performs initiating="true" bindingBy="name" inScopeRole="Manufacturer"
bindsToRole="Seller"  / </BTA> <Join name="J" waitForAll="true" ... />
<Success fromBusinessState=J"/> </MC>

In the above, we nondeterministically indicate that both subtransactions
need to occur.

This may be the abstraction level we want for control flow, but it
leaves a lot to implementers to guess at what would be a suitable
implementation. There really isn't anything indicating that the second
POTransaction has to complete before the first one can complete. By not
giving this information to the lower layers, the layers might produce a
deadlock, waiting to complete the first transaction before launching the
second. The advantage of nondeterminism here is that BPSS doesn't have
to worry about how to indicate a dependency at the BPSS abstraction
level. Option # 1 is at least better than just listing BTAs in a
sequence, which seems to me to be asking for a traversal "hang" when
monitoring.

Possibly better option # 2 Replace the MC part in option 1 by the
following, eliminating the nondeterministic fork/join and interpolating
a BT.

<MC>
<Start ...>

<BTA ... businessTransaction="PONotification" ...>
<Performs initiating="true" bindingBy="name" inScopeRole="Retailer"
bindsToRole="Buyer"  /> </BTA>

<BTA ... businessTransaction="POTransaction" ...>
<Performs initiating="true" bindingBy="name" inScopeRole="Distributer"
bindsToRole="Buyer"  /> <Performs initiating="true" bindingBy="name"
inScopeRole="Manufacturer" bindsToRole="Seller"  / </BTA>

<BTA ... businessTransaction="POConfirmationNotification" ...
name="BTA3"> <Performs initiating="true" bindingBy="name"
inScopeRole="Distributer" bindsToRole="Seller"  /> </BTA>

<Success fromBusinessState="BTA3"/>
</MC>

In option 2, we interpolate a request-response BT between a one-way PO
Request and a one-way PO Response. This interpolation is what is going
on, but we introduce a number of new BTs and fail to reuse a buy-sell BT
at different points in the control

Option class #3: We add on some syntactical apparatus for indicating the
dependency. For example, we nest a BTA element inside another to
indicate that the included BTA must complete before the first BTA
completes. Or, we add an attribute in the Performs binding, that points
to the BTA that needs to complete (which is probably not a good idea
because we would be limited to declaring just one BTA dependency-- what
if we had N that needed to
complete?) I am not going to throw out syntax before people indicate we
need to explore things in option class 3. Maybe there is a good way to
approach this use case other than 1 or 2 that I have just overlooked.
CollaborationActivity options-- I did not see how to use these to our
advantage in this case? Other approaches?

At least I don't think Role association needs to be a problem with this
use case.



dwm@

In the following I assume we accept Martin Robert's proposals concerning
specializations of BusinessTransaction, and also some form of JJ
Dubray's proposal that the main containers (elements) for complex flow
control include BinaryCollaboration, MultipartyCollaboration, and
possibly CollaborationActivity. BinaryCollaborations and
MultipartyCollaborations can basically have very similar content models
in JJ's view, except that the number of "locally declared Roles" will
differ. I will be discussing "references" made to the above items [the
complex flow containers] and also references to the specialization
siblings of BusinessTransaction made in BTAs.

One of the difficulties that CPPA has had with aligning with BPSS is
that CPPA needs to pick out of BPSS the BusinessTransactions that a
given party will support, and also select from the global view of BPSS
the Role perspective of one participant (party) (for a CPP). The problem
is like finding a projection of 1-dimensional curves out of some
n-dimensional model, and is a little tricky. What CPPA intends to do is,
starting with some complex flow's entry point, trace a toplevel Role's
trajectory through all the referenced complex flows to the baseline
specializations of business transasction. What CPPA needs to do is to be
able to track the Role in one flow container/businesstransaction down to
the primitive collaboration patterns (Notification, RequestResponse, and
so forth). Ideally explicit (and _uniform_) syntactical constructs,
rather than implicit semantic conventions in the BPSS text, will mark
out the "connections" through the flow constructs so that implementers
can have a reasonably simple task to trace trajectories.

BPSS, on the other hand, rightly demands that the containers it defines
be reusable, and that different complex flows can refer to (and thereby
reuse) the same syntactical units (possibly flow containers themselves
but in the simple case, the specializations of BusinessTransaction). So
reusability and reference rightly go together.

Now the problem has so far been that if we put Role trajectory
connections "in" a container, the container becomes far less reusable.
Hence there has been a tension between the design requirement from CPPA
for Role trajectories, and the design requirement from BPSS for
reusability. I think there is a resolution for these apparently
conflicting requirements that applies to all flow containers, and that
is _uniform_.

Here are the features of the proposed resolution:

1. There can be both "local" and "global" Role declarations. That is,
Role elements can occur at the toplevel and can also occur within
complex flow containers (current). The global Role elements are really
BusinessPartyType declarations that can get associated with a toplevel
flow starting container by being bound to its (local) Role values. For
uniformity, all bindings use Performs elements, so the content models at
various points will need to be expanded to allow sequences of Performs
elements. [Adding global Roles to indicate BusinessPartyTypes is
indicated by Anders recent model. It is actually an optional feature,
but one I like.)


2. The connection between Roles currently visible and those in a
referred to construct occurs where the reference is made using either
IDs or names. I think this design is, more or less, the way we currently
do it. But our current syntax is neither uniform nor does it generalize
to the MC case. Let me take some time to expand this with some unusual,
but possible use cases.

a. Suppose we want to reuse a JJ-style MC flow involving a
credit-approver, a seller, and a buyer. Suppose we want to reuse it from
a BC with a buyer and seller Role defined locally. We want the
localseller to bind to the MC seller, the local seller to the MC
credit-approver, and the local buyer to the referenced buyer. Three
Performs constructs within the BC's Transition element's content model
would accomplish assoiating local Roles with referenced Roles.
Reusability supported. If we need to indicate which is the initiating
Role, an attribute on Performs could mark that. [That allows the reused
MC container to not have a fixed initiating Role-- it always picks that
up from the Referencing context.]

b. Suppose we want to loop around a choice (XOR) over BTAs. Let the
Referencing context have two local roles, A and B, and the Referenced
BTA be in a context with two roles, counterProposer, proposalResponder.
To alternate A with B for the Role of counterProposer, we would just
alternate the Performs associations, viz.,

<Performs><Local>A</Local><Remote
initiating="true">counterProposer</Remote></Performs><Performs><Local>B<
/Local><Remote>proposalResponder</Remote></Performs>

 with

<Performs><Local>B</Local><Remote
initiating="true">counterProposer</Remote></Performs><Performs><Local>A<
/Local><Remote>proposalResponder</Remote></Performs>.

c. As these examples illustrate, the formal analogy here is that of
actual parameters and formal parameters that are used to hook up a
function invocation with a function declaration. The locally "visible"
Roles are analogous to the actual parameters in the call, and the
declared Role values in a flow container declaration are analogous to
the formal parameters. IMO, it would be nice to have an attribute on
Performs called "bindingBy" with two values, "name" or "ID" That way we
would not need to have the repetitive attributes such as "fromRoleId"
and "fromRoleName" all the time. Also, the whole "fromRole" "toRole"
attribute apparatus would disappear in 2.0. These distinctions are
inherently limited to a "BinaryFlow" perspective, and don't generalize
well to Multiparty flow control. Also while initiating is an important
property, I would like to see it placed within the content-model of
Performs.

d. Different initiator flag (to accomodate Martin's different "entry"
mode use case) e. Distributor (Haugen/Fletcher style) cases. f. Yunker
multiparty cases

[I will try to do these other use cases if I get more time this
weekend.]

One implication of the above approach is that, for example, constructs
containing a forward reference (such as, BusinessTransactionActivity,
(OperationActivity if it is added), Transition, Start,
CollaborationActivity) will have content-models expressing Role
associations, which I have assumed to be provided by sequences of
Performs, the uniform Role connection construct. The Success and Failure
states also have references pointing back. I think we could probably use
Performs here also. I think it is a separate small point that needs
investigation though. How to mark the toplevel flow constructs (use a
Start state?) is another pending item. A final issue is whether we
should dispense with CollaborationActivity in Referencing
BinaryCollaborations. Minimally, I think CollaborationActivities should
allow me to feference either a MultipartyCollaboration or
BinaryCollaboration. I am not certain what is allowed at present.


@dwm

@dwm

@DRRW
@dwm