ebxml-tp message


OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: RE: Sanity check needed for struggling TPA participant


Dear all,

	in a previous message I proposed to "include" the ROLE definition as part
of the CollaborationProtocol tag.

In this view, if a CPP would need to support two roles for the same BP
("buyer" and "seller"), then I would end up in having two dinstinct
CollaborationProtocol tags, each of them referring to the same BP but to a
different ROLE.

I try to play using the assumption of ROLE as a qualifier for the
CollaborationProtocol.
What happens if I try to compose a CPA from two CPPs structured in such a
way?

    CPP_1                            CPP_2
      CollaborationProtocol_1_1        CollaborationProtocol_2_1
          The_BP                           The_BP
          Buyer_Role                       Buyer_Role
      CollaborationProtocol_1_2        CollaborationProtocol_2_2
          The_BP                           The_BP
          Seller_Role                      Seller_Role
      DeliveryChannel_1_1              DeliveryChannel_2_1
          CollaborationProtocol_1_1        CollaborationProtocol_2_1
          Transport_alfa                   Transport_beta
      DeliveryChannel_1_2              DeliveryChannel_2_2
          CollaborationProtocol_1_2        CollaborationProtocol_2_2
          Transport_beta                   Transport_alfa

(I did not use tabs, so the schema should be readable)

I think that the match needs to be done against the DeliveryChannel tags for
composing the CPA.
In this case, since the Transport characteristics of the DeliveryChannels
differ (Transport_alfa and Transport_beta), then the match would be
automatic (more or less) producing TWO DIFFERENT CPAs:

    CPA_result_1                       CPA_result_2
      Party_1                            Party_1
        DeliveryChannel_1_1                DeliveryChannel_1_2
           CollaborationProtocol_1_1         CollaborationProtocol_1_2
           Transport_alfa                    Transport_beta
      Party_2                            Party_2
        DeliveryChannel_2_2                DeliveryChannel_2_1
           CollaborationProtocol_2_2         CollaborationProtocol_2_1
           Transport_alfa                    Transport_beta

In this case, CPA_result_1 implies Party_1 being the BUYER and Party_2 being
the SELLER. And CPA_result_2 is the viceversa.

Now, let's suppose the case where the Transports are identical:

    CPP_1                            CPP_2
      CollaborationProtocol_1_1        CollaborationProtocol_2_1
          The_BP                           The_BP
          Buyer_Role                       Buyer_Role
      CollaborationProtocol_1_2        CollaborationProtocol_2_2
          The_BP                           The_BP
          Seller_Role                      Seller_Role
      DeliveryChannel_1_1              DeliveryChannel_2_1
          CollaborationProtocol_1_1        CollaborationProtocol_2_1
          Transport_alfa                   Transport_alfa
      DeliveryChannel_1_2              DeliveryChannel_2_2
          CollaborationProtocol_1_2        CollaborationProtocol_2_2
          Transport_alfa                   Transport_alfa

How the composition could happen? Since the Transport is no more a
discriminant, the software will be required to go "drilling" into the
CollaborationProtocol. The software would be instructed to drill down into
the CollaborationProtocol and:
	- verify if the BP reference is the same
	- in case teh BP is the same, then to verify that the ROLEs are DIFFERENT

Again, follwoing this logic, we would arrive to the same result as before,
such as :

    CPA_result_3                       CPA_result_4
      Party_1                            Party_1
        DeliveryChannel_1_1                DeliveryChannel_1_2
           CollaborationProtocol_1_1         CollaborationProtocol_1_2
           Transport_alfa                    Transport_alfa
      Party_2                            Party_2
        DeliveryChannel_2_2                DeliveryChannel_2_1
           CollaborationProtocol_2_2         CollaborationProtocol_2_1
           Transport_alfa                    Transport_alfa

In this case, CPA_result_3 implies Party_1 being the BUYER and Party_2 being
the SELLER. And CPA_result_4 is the viceversa.


If I haven't missed some obvious issue, it proves that the idea of having
the ROLE as a qualifier of the CollaborationProtocol is not only more clear
but would also have an advantage in the CPA composition process.

BTW, an additional advantage (referring to another thread) is the having the
ROLE as a qualifier of the CollaborationProtocol would make the ROLE
UNAMBIGUOUS.

Best regards

/Stefano




 -----Original Message-----
 From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
 Sent: 19 January 2001 03:17
 To: christopher ferris
 Cc: Moberg, Dale; Christopher Ferris; ebxml-tp@lists.ebxml.org
 Subject: Re: Sanity check needed for struggling TPA participant



 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








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC