Re: Sanity check needed for struggling TPA participant

[Martin W Sachs <mwsachs@us.ibm.com>]

Chris,

What you say makes a lot of sense.  Since the composition and negotiation
processes themselves are out of scope for the TP team (at least before
May), as long as we have convinced ourselves that it can be done, we can
move on.

Would you be willing to collate the discussions to date and propose
whatever changes are needed to support roles and references to multiple
collaboration protocols?

If someone would also be willing to digest these discussions and write a
non-normative appendix on composition and negotation, that would also be
helpful.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



christopher ferris <chris.ferris@east.sun.com> on 01/19/2001 08:39:47 AM

To:   ebxml-tp@lists.ebxml.org
cc:
Subject:  Re: Sanity check needed for struggling TPA participant



Marty,

Please see below.

Cheers,

Chris

Martin W Sachs wrote:
>
> I put this out to the TP list for more input.
<snip/>
> to the same collaboration protocol tag.  This seems OK.

Thanks;-)

>
> However I think there is a problem both with this one and with the one
that
> I originally suggested (below).  If I try to compose a CPA from similar
> CPPs for two parties, I don't see any way for the composition software to
> figure out which party will be "buyer" and which will be "seller".  I can
> think of two ways out of this ambiguity:

I don't think that the composition software can figure out this
under any circumstances without help from the outside unless each
party plays only a single Role in any given CP. However, I don't
see this as a failing. I see this as just "the way it is" as Walter
Cronkite would say.

It would seem to me that one of the parties (A) would be initiating the
process of negotiating/establishing a CPA with a prospective party (B).
Party A would therefore *select* the CollaborationProtocol and the Role
that they want to play either as input to the process or by selecting
them in the UI that they use to create the CPA.

I think that this resolves any ambiguity. One side picks the CP and Role
within that they want to use to create a CPA with another party. The
rest
is figured out as follows:
     - examine the BPM pointed to by CP
     - get list of Roles
     - XOR selected Role with list of Roles in BPM
     - identify Role(s) in CPP of Party B that match
     - find CP in Party B's CPP that matches (so we have ID)
     - for each Role, select ServiceBinding that has IDREF matching ID
     above
     - find matching DeliveryChannel (default) for Party B's ServiceBinding
     - compare characteristics of Party B's DeliveryChannel with
Characteristics
     of Party A's DeliveryChannel for a possible match

Of course, if the CP has more than 2 Roles (as in the case I described)
then some further intervention may be needed to determine which
corresponding
Role(s) Party B should play in the context of the CPA being
"negotiated".

>
>    1. Admit that this case requires negotation after composition.

I say cry Uncle. I see no way around this;-) Of course, "negotiation"
may not be completely accurate a term. More like "intervention" or
"user input".

>
>    2. Say that this CPP is invalid and if a party wants to represent
itself
>    as capable of being either "buyer" or "seller" in different CPAs for
the
>    same process, that it should have two CPPs, one for each role.

I'd rather we didn't go here. I think that a CPP should be perfectly
valid if it lists more than one Role of a CP as being supported by a
Party.

>
> I think that the above is equivalent to the ambiguity that Chris noted at
> the bottom of his posting below. I would note that the validation process
> he mentions also to has to be sure that all the three roles are filled.
>
> Regards,
> Marty
>
>
*************************************************************************************

>
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287;  IBM tie line 863-7287
> Notes address:  Martin W Sachs/Watson/IBM
> Internet address:  mwsachs @ us.ibm.com
>
*************************************************************************************

>
> christopher ferris <chris.ferris@east.sun.com>@east.sun.com on 01/18/2001
> 03:23:16 PM
>
> Sent by:  Chris.Ferris@east.sun.com
>
> To:   Martin W Sachs/Watson/IBM@IBMUS
> cc:   "Moberg, Dale" <Dale_Moberg@stercomm.com>, Christopher Ferris
>       <chris.ferris@east.sun.com>
> Subject:  Re: Sanity check needed for struggling TPA participant
>
> Dale, Marty,
>
> There's another way to look at this issue. I certainly
> concur with all of Marty's observations and clarifications.
>
> However, I also do agree that there exists the potential for
> some "orphaned" messages that are not associated with given
> DeliveryChannel.
>
> I propose the following change, that may serve to address
> the concern raised by Dale:
>
> A CollaborationProtocol (which is a reference to a business process
model)
> has a "default" DeliveryChannel with which it is associated. It MAY also
> have alternate DeliveryChannel(s) associated. As Scott has pointed out,
> we would want to express this manner of optionality/choice in a
> consistent manner as with other aspects of choice in the model. I would
> propose that order in a sequence be treated as preference order
> (1st preference, 2nd preference, etc.)
>
> I would also propose that ServiceBinding be dropped from DeliveryChannel
> and that we augment the ServiceBinding to bind a CP (an IDREF instead of
> an xlink:locator) to a DeliveryChannel. I would then propose that
> if certain messages (or transactions) require an alternate
DeliveryChannel,
> that these be called out as children of the ServiceBinding element.
> Finally, we can capture all of this under Role.
>
> <CollaborationProtocolProfile>
> <Party>
>      ...
>      <Role roleId="" name="" certId="">
>           <!-- primary binding with "default" DeliveryChannel associated
> -->
>           <ServiceBinding collaborationId="" channelId="">
>                <!-- override "default" deliveryChannel -->
>                <Override transactionOrMessage="" channelId=""/>
>           </ServiceBinding>
>           <!-- either this is the primary binding for another
>                business process OR it is the first alternate binding for
>                one which precedes it with the same collaborationId -->
>           <ServiceBinding collaborationId="" channelId="">
>                <Override transactionOrMessage="" channelId=""/>
>           </ServiceBinding>
>      </Role>
>      ...
> </Party>
> <CollaborationProtocol id=""
>      xlink:type="locator"
>      xlink:href="">BuyAndSell</CollaborationProtocol>
> </CollaborationProtocolProfile>
>
> As to a related issue on service bindings, I disagree that there
> would be two instances of a CollaborationProcess each identifying the
> same process definition document. There should only be one that
> is referenced multiply if the Party plays multiple roles in the
> same business process. I was almost ready to say:
>      Certainly a CPA would only identify a single role
>      within a single business process for a given party.
> HOWEVER, given that there MAY be more than two roles defined
> within a business process, a party MAY fill more than one of the
> roles. This MAY lead to some confusion because it isn't quite
> deterministic.
>
> As an example: a process may be defined as having three roles:
>      buyer
>      seller
>      creditor
>
> A large company like Ford might fulfil two of the three roles (as they
have
> a financing division)
>
> e.g. seller and creditor
>
> A smaller company might only act in one of the roles (seller)
> and leave the third role to yet another CPA with yet another Party
> such as Citicorp.
>
> Hmmm... this means that a "validation" process outside of a
> DTD or schema validation would be needed to ensure that if more than
> two roles are defined for a business process that a given role
> is NOT associated with more than a single Party in a CPA.
>
> Cheers,
>
> Chris
>
> Martin W Sachs wrote:
> >
> > Dale,
> >
> > See my replies embedded below.
> >
> > Regards,
> > Marty
> >
> >
>
*************************************************************************************

>
> >
> > Martin W. Sachs
> > IBM T. J. Watson Research Center
> > P. O. B. 704
> > Yorktown Hts, NY 10598
> > 914-784-7287;  IBM tie line 863-7287
> > Notes address:  Martin W Sachs/Watson/IBM
> > Internet address:  mwsachs @ us.ibm.com
> >
>
*************************************************************************************

>
> >
> > "Moberg, Dale" <Dale_Moberg@stercomm.com> on 01/18/2001 01:26:26 PM
> >
> > To:   Martin W Sachs/Watson/IBM@IBMUS, "Christopher Ferris (E-mail)"
> >       <chris.ferris@east.sun.com>
> > cc:
> > Subject:  Sanity check needed for struggling TPA participant
> >
> > Hi
> >
> > I am trying to figure out how to include the sender transport info but
> got
> > stuck on something else on the way to it. I need to see whether my
> > observation here makes sense or I am just overlooking something. I
think
> > I am getting the hang of the XML modelling style in the cpp v0.23 and
> > how you have chosen to notate some relationships, but if I am right
> > I think something is missing.
> >
> > This is just to Marty and Chris. Following your comments, I can post
> > something to the list that sharpens the issue. I hope the following
> > is at least intelligible to you. Please ask for clarification as
needed.
> >
> > Dale
> > ===========================================================
> > Capability Capture and The Issue of Association.
> >
> > <!-- (PartyId+ , PartyDetails , Role+ ,
> > Certificate+ , DeliveryChannel+ ,
> > Transport+ , DocExchange+ )-->
> >
> > Are we capturing the associations
> > that are needed to understand
> > the capabilities enabling b2b interoperability?
> > While we have most of the most common capabilities
> > described at some level of detail, what is not so
> > clear is that we have ways of stating how these
> > capabilities are associated and are integrated
> > within a given party's software implementation.
> >
> > MWS:  We have the capability now to some extent.
> > See below.
> >
> > If we consider our representation of a party, (above)
> > and ignore PartyDetails and Certificate elements,
> > the Party element consists of a nonempty sets
> > of PartyIds, Roles, DeliveryChannels, Transports,
> > and DocExchanges.
> >
> > MWS:  one clarification:  The non-empty set conisists
> > of PartyIDs, Roles, and DeliveryChannels.  Transports
> > and DocExchanges are referenced by delivery channels,
> > so they are logically parts of the de3livery channel.
> >
> > The connection to BPs occurs
> > via the Role, and so the party element looks
> > as if it relates a party in a BP Role to its Transports
> > and DocExchange details. This is the basic
> > information that we need to know about a
> > party's capabilities for collaborating in a BP.
> > So far so good.
> >
> > MWS:  Remember:  the connection to BPs occurs in two
> > places, the service bindings tag under role and the
> > service binding tag under delivery channel.
> >
> > But next consider
> > what happens when,
> > except for PartyId,
> > each of these sets have
> > more than one element.
> >
> > Which Role goes with which Transport
> > and  which DocExchange element(s)?
> > It is certainly possible that a given
> > Role may fail to be reachable by some
> > of the transports. Likewise, only some
> > of the DocExchanges may be relevant
> > to a given Role instance. So how do
> > we tell which Role goes with which
> > Transports and which DocExchange
> > instances? This is the association
> > issue I want to raise.
> >
> > MWS:  see additional discussion at end.
> >
> > MWS:  You seem to be mainly concerned with associating
> > doc exchange and transport properties with an individual
> > role.  We need to be able to do it but I think we need
> > more work with the BP team on this.  At some point, we
> > want to be able to associate a delivery channel with a
> > role and underneath the role with specific message
> > exchanges (business transaction?) and perhaps
> > with specific messages. This is equivalent to binding
> > a delivery channel with a role but possibly a different
> > delivery channel for each business transaction. That
> > means being able to point an xlink directly at a business
> > transaction, role, or message.  I'm not sure that the
> > specification schema is crisp enough yet to do this.
> >
> > MWS:  The operative point is your next paragraph;
> > the delivery channel is important to your questions,
> > though my comment directly above is still part of
> > the discussion.
> >
> > So far you will note that I have suppressed
> > discussion of the DeliveryChannel. Will that
> > set help? In a way the DeliveryChannel
> > is itself part of the association, for a look
> > inside its structure reveals that a DeliveryChannel
> > is an association of a Transport and a DocExchange.
> > So perhaps if we focus on DeliveryChannel
> > we will find the needed information about
> > associations. However, there remains one
> > gap-- the Role, which is a view on the BP,
> > is not associated with any of the ChannelIds!
> >
> > MWS:  As I indicated above, there is an implicit
> > assocation between the delivery channel and a role
> > through the linkage between the delivery channel and
> > a specific business transaction or message, once we
> > know how to make that linkage. However maybe we
> > should make that association explicit.  Read on.
> >
> > MWS:  The delivery channel is, as you say, an
> > association between a transport and a doc exchange.
> > In addition, as I mentioned above, a delivery channel
> > is also associated with some aspect of the collaboration
> > protocol via the delivery channel service binding.
> >
> > What we need is some other element, akin to
> > DeliveryChannel, which consists of
> > pairs of the RoleId with the ChannelId.
> > In this way the associations we need
> > to capture can be expressed. Or we
> > are at least one step closer.
> >
> > MWS:  One way to directly associate a role with
> > a delivery channel is to move the role tag under
> > the delivery channel tag and allow inclusion of either
> > one or both roles there.  In that case, we could probably
> > also eliminate service binding from role since the
> > delivery channel service binding should then be sufficient
> > for both role and delivery channel.
> >
> > MWS:  What remains is your question above: "So how do
> > we tell which Role goes with which
> > Transports and which DocExchange
> > instances?". The answer to this question is that we
> > define different delivery channels with the needed
> > different combinations of transport and doc exchange
> > definitions. This capability is already defined in
> > the CPP and prior to that in the IBM tpaML proposal.
> > We can then associate each of those delivery
> > channels with the appropriate role and
> > the appropriate  business transaction
> > or message.  As long as the different combinations are at
> > the granularity of combinations of transport and doc exchange,
> > this should work fine.  If we see a need for combinations and
> > permutations at a finer level of granularity (i.e. individual
> > transport or delivery channel characteristics,  we will need
> > to consider a different representation since a
> > finer level of granularity could explode the number of
> > delivery channels needed to express it to an undesirable
> > degree.  My advice is to restrict ourselves to combinations
> > of complete doc exchange and transport definitions for now
> > and leave finer granularity for beyond version 1.0
>
> --
>                                Christopher Ferris
>     _/_/_/_/ _/    _/ _/    _/ Sr Staff Engineer - XTC Advanced
Development
>    _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
>   _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
>        _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
> _/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903