Subject: Re: service binding - tech comment v0.2 CPP/CPA
Stefano,
This alternative would certainly work. However, in the original
TPA spec, the DeliveryChannel as thought to have "reuse"
semantics. I still think that this is the case (that a delivery
channel can and probably should be "reused" in the context of a
CPP or CPA).
Cheers,
Chris
Stefano POGLIANI wrote:
>
> Chris,
>
> I try to draw a picture of your proposal:
>
> <CollaborationProtocolProfile>
> <Party>
> <PartyDetails>
> ...
> </PartyDetails>
> <Role>
> <ServiceBinding name="alfa"
> collaborationId= --------------+
> channelId= ---------+ |
> </Role> | |
> <DeliveryChannel <--------------------+ |
> transport= ---------------------+ |
> docExchange= ---------------+ | |
> <ServiceBinding href="this_BP"/> | | |
> </DeliveryChannel> | | |
> <DocExchange> <----------------------------+ | |
> ... | |
> </DocExchange> | |
> <Transport> <----------------------------------+ |
> ... |
> </Transport> |
> </Party> |
> <CollaborationProtocol href="this_BP"> <--------------+
> This_BP
> </CollaborationProtocol>
> </CollaborationProtocolProfile>
>
> Now, I would like to submit an alternative, in order to understand if it
> makes sense:
>
> <CollaborationProtocolProfile>
> <Party>
> <PartyDetails>
> ...
> </PartyDetails>
> <DeliveryChannel
> collaborationId= ------------------+
> transport= ---------------------+ |
> docExchange= ---------------+ | |
> </DeliveryChannel> | | |
> <DocExchange> <----------------------------+ | |
> ... | |
> </DocExchange> | |
> <Transport> <----------------------------------+ |
> ... |
> </Transport> |
> </Party> |
> <CollaborationProtocol href="this_BP" <--------------+
> name="This_BP">
> <Role name="the_role_name"
> href="that_role_in_this_BP">
> </Role>
> </CollaborationProtocol>
> </CollaborationProtocolProfile>
>
> I think that the advantage of this second approach would be:
> 1. It makes explicit that the DeliveryChannel is the composition
> of the "role played in a given BP" together with the technical
> infrastructure made explicit by both the Transport and the
> DocExchange
> 2. The <CollaborationProtocol> would immediately mean "the role
> played by a Party in a given BP". The meaning of such a tag
> would be more "compact"
> 3. I think that, in the context of the CPP, the CollaborationProtocol
> would not need to reference the BP in an abstract way. In the
> context of the CPP, the BP would always need to be qualified
> by the role that such Party would be able to play.
> 4. As I mentioned in one reply to Dale, it would be simpler to make
> a composition of two CPPs into a CPA. (the reference is in the
> attached email)
>
> Perhaps, in order to be more clean, a 3rd approach like the following one
> would be also to evaluate:
>
> <CollaborationProtocolProfile>
> <Party>
> <PartyDetails>
> ...
> </PartyDetails>
> <DocExchange> <-------------------------------+
> ... |
> </DocExchange> |
> <Transport> <-----------------------------+ |
> ... | |
> </Transport> | |
> </Party> | |
> <CollaborationProtocol href="this_BP" <---+ | |
> name="This_BP"> | | |
> <Role name="the_role_name" | | |
> href="that_role_in_this_BP"> | | |
> </Role> | | |
> </CollaborationProtocol> | | |
> <DeliveryChannel | | |
> collaborationId= ----------+ | |
> transport= -------------------+ |
> docExchange= ---------------------+
> </DeliveryChannel>
> </CollaborationProtocolProfile>
>
> The difference between this 3rd approach and the 2nd one is that the
> DeliveryChannel has been exported OUTSIDE the Party since it was
> referencing (in the 2nd approach) both elements INSIDE the Party and
> outside it.
>
> Does this make any sense ?
>
> /Stefano
>
> > -----Original Message-----
> > From: christopher ferris [mailto:chris.ferris@east.sun.com]
> > Sent: 22 January 2001 19:14
> > To: ebxml-tp@lists.ebxml.org
> > Subject: service binding - tech comment v0.2 CPP/CPA
> >
> >
> > All,
> >
> > One of the issues that has been discussed both on and
> > off list is the purpose and function of the ServiceBinding
> > element.
> >
> > There has been some confusion and also some concern that
> > the current draft of the CPP will make it difficult
> > at best for automated CPP+CPP->CPA mapping.
> >
> > One of the concerns was that in the current design, it is difficult
> > to determine if all of the messages for a given collaboration
> > protocol are actually "bound" to a DeliveryChannel.
> >
> > Another concern raised is how to map alternate delivery channels
> > to a given collaboration protocol, etc.
> >
> > I would therefore like to propose the attached revision to the
> > Role element that I think will make things a little clearer
> > than they are in v0.2 as well as to provide a little better
> > closure on ensuring that all messages are "bound" to
> > a delivery channel.
> >
> > This proposal also involves removing the ServiceBinding child
> > element from the DeliveryChannel, as this function is now covered
> > with the attached proposed change to the Role and ServiceBinding
> > elements.
> >
> > Comments are encouraged.
> >
> > Cheers,
> >
> > Chris
> >
>
> ----------------------------------------------------------------------------------------------------
>
> Subject: RE: Sanity check needed for struggling TPA participant
> Date: Fri, 19 Jan 2001 11:33:48 +0100
> From: Stefano POGLIANI <stefano.pogliani@sun.com>
> To: Martin W Sachs <mwsachs@us.ibm.com>,
> christopher ferris <chris.ferris@east.sun.com>,
> "Moberg, Dale" <Dale_Moberg@stercomm.com>
> CC: ebxml-tp@lists.ebxml.org
>
> 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
> »
> »
> »
> »
> »
--
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
begin:vcard n:Ferris;Christopher tel;work:781-442-3063 x-mozilla-html:FALSE org:Sun Microsystems, Inc;XML Technology Development adr:;;One Network Drive;Burlington;Ma;01824-0903;USA version:2.1 email;internet:chris.ferris@east.Sun.COM title:Sr. Staff Engineer x-mozilla-cpt:;0 fn:Christopher Ferris end:vcard
Powered by
eList eXpress LLC