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: service binding - tech comment v0.2 CPP/CPA


What would make my proposal NOT reusable (or less reusable than the current
one)?

/Stefano

 -----Original Message-----
 From: Chris.Ferris@east.sun.com [mailto:Chris.Ferris@east.sun.com]
 Sent: 23 January 2001 17:17
 To: Stefano POGLIANI
 Cc: ebxml-tp@lists.ebxml.org
 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



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

Powered by eList eXpress LLC