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
»
»
»
»
»
Powered by
eList eXpress LLC