Re: Sanity check needed for struggling TPA participant

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

I put this out to the TP list for more input.

It may be too late at night to parse this stuff properly but I think I
agree with most of it.

I'm not quite sure that it does the case that I brought up.  I have a CPP
for collaboration protocol A with, say, buyer and seller roles.  Using the
same CPP, I want to express that I can act as "buyer" with some partners
and as "seller" with others.  Based on Chris' proposal below, I would
define two role tags under my Party tag.  One would be for "buyer" and the
other for "seller".  The associated service binding tags would both point
to the same collaboration protocol tag.  This seems OK.

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:

   1. Admit that this case requires negotation after composition.

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