RE: Does the current CPA/CPP spec support multi-hop?

["Burdett, David" <david.burdett@commerceone.com>]

Stefano

Although you can think of it as one business process with three parties, I
don't think this is the best way of looking at it as:
1. It would require that for every new business process between A and B,
then the Hub woould have to be involved whereas all that is required is for
the Hub to forward the new message.
2. One of the parties, e.g. Party B, may not be ebXML aware as they are
using EDI and therefore cannot sensibly enter into a CPA with Party A.

The better way to think of it,IMO, is as a two CPAs between A and the Hub,
and B and the Hub which are only concerned with the transport of messages
and not the business process.

Thoughts?

David

-----Original Message-----
From: Stefano POGLIANI [mailto:stefano.pogliani@sun.com]
Sent: Wednesday, January 31, 2001 9:13 AM
To: Martin W Sachs; ebxml-tp@lists.ebxml.org
Subject: RE: Does the current CPA/CPP spec support multi-hop?


What I think David describes here is actually a Business Process which
involves 3 parties...
...which is what I think is actually necessary but is also what we dco not
support now.

I remember some discussion I had in Tokyo on this topic.

/stefano

> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: 31 January 2001 15:41
> To: ebxml-tp@lists.ebxml.org
> Subject: RE: Does the current CPA/CPP spec support multi-hop?
>
>
> Please see the appended exchange with David Burdett.
>
> 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
> ******************************************************************
> *******************
>
> To:   Martin W Sachs/Watson/IBM@IBMUS
> cc:
> Subject:  RE: Does the current CPA/CPP spec support multi-hop?
>
>
>
> Marty
>
> Thanks for the prompt reply. I think though that there could be a mismatch
> between the TRP spec and the CPA/CPP spec if the latter does not include
> multi-hop as the TRP spec will.
>
> MWS:  I had the impression that multi-hop is still somewhat in the future.
> In any case, it is clear that the TP and TRP specs have to be in sync and
> I am depending on Chris to be the interface for that.
>
> Also the Ariba punchout (which is similar to
> Commerce One's RoundTrip) is not the situation I am thinking about. To go
> into a bit more detail consider the following example message exchange ...
>
> Party A   HUB       Party B
> Msg1-------->
> <--------Ack1
>            Msg2-------->
>            <--------Ack2
>
> In the above diagram ...
>
> 1. Msg1 and Msg2 contain the same payload. The only difference is
> that Msg1
> is sent using HTTP/S and Msg2 is sent using SMTP with S/MIME.
> 2. As far as the business process is concerned, Msg1 and Msg2 are the same
> message
> 3. Party A does not know any delivery channel information about Party B as
> it is the Hub's responsibility to figure it out.
> 4. The timeout/retry parameters for each hop would be different
>
>
> The sort of solution that might work, is if we had "Delivery Channel only"
> CPA that only covered the delivery channel/transport parts of the CPA. You
> almost have this in the current CPA as a Delivery Channel and
> Transport are
> identified as separate elements.
>
> Would it make sense if we did the following ...
>
> 1. The Delivery Channel and Transport elements of the CPP/A could
> be placed
> in a separate document and referenced by the Business Process CPP. This
> would have the additional benefit of making them re-usable.
> 2. In the TRP spec, we could then have a CPAId, as now, that was at the
> Conversation level that identified the CPA that applied to the whole
> conversation
> 3. In addition you had an optional "Delivery Channel" level CPAId that
> could
> exist in the Trace element (was the Routing Header) that identified the
> Delivery Channel and Transport to use on the particular hop which could
> over-ride anything in the Conversation Level CPA ID
>
> MWS:  I think you are saying that PartyA and PartyB each has to have a
> CPA with the hub that defines the transport and messaging interaction
> and in addition, PartyA and PartyB have a CPA with each other that defines
> the business interaction.  In principle, that should work but the
> structural
> issues are a bit more complex and need a lot more thought. Consider:
>
>    The CPAs with the hub probably have to include some kind of rudimentary
>    business process that defines the forwarding function.  Maybe the
>    forwarding itself is a never-ending conversation involving
> repetition of
>    one business transaction.  Other business transactions would relate to
>    explicit interactions between the party and the hub.  In any case, the
>    CPAs with the hub appear to be handled with the current CPP/CPA
>    definition.
>
>    The collaboration protocol between the two Parties has some parameters
>    (security and others) whose values have to be specified in the
> base CPA.
>    This is done with XLinks from various elements of the CPA. So this CPA
>    cannot be simply a link to the collaboraton protocol document, thought
>    some existing elements might have to be given cardinalities (0 or more)
>    so that this could be left out.
>
>
>
>
> Thoughts?
>
> MWS:  The bottom line is that the CPP/CPA should support multihop but the
> TP
> team is still working on much more fundamental items and formally
> speaking,
> the deadline for approval of ver. 1.0 is already past, so
> anything we don't
> in the next week (by Vancouver) has to be considered futures.  Of course,
> we
> can keep discussing.
>
> David
> PS Do you think we want to put our email exchange on the main list. Please
> reply to the list if you agree.
>
>
>
> Regards,
> Marty
> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Tuesday, January 30, 2001 3:34 PM
> To: Burdett, David
> Subject: Re: Does the current CPA/CPP spec support multi-hop?
>
>
>
> David,
>
> Other than some inconclusive discussion at the Boston F2F, the TP team has
> not considered intermediaries at all.  Based on your email, I
> added an item
> the the "Longer Term Enhancements" section of the changes document that I
> previously distributed.
>
> It is not clear to me at this point that the scenario you
> describe requires
> anything explicit about the intermediary in the CPA between Party A and
> Party C.  The IBM team that I belong to did look at the Ariba
> punchout case
> and concluded that a TPA between Parties A and C is perfectly reasonable
> and does not have to explicitly express the fact that some of the
> transport
> parameters actually refer to the Ariba network acting as a surrogate for
> the other party.
>
> In any case, we are still working through fundamentals and will have to
> leave intermediaries for later.
>
> 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
> ******************************************************************
> **********
>
> *********
>
>
>
> "Burdett, David" <david.burdett@commerceone.com> on 01/30/2001 05:28:46 PM
>
> To:   Martin W Sachs/Watson/IBM@IBMUS
> cc:
> Subject:  Does the current CPA/CPP spec support multi-hop?
>
>
>
> Marty
>
> I am sending this to you privately since I have not had the bandwidth to
> follow the TP mailing list as closely as I would have liked.
>
> My question is over the CPAs that could exist in a multi-hop
> scenario, e.g,
> if Party A sends a message to Party C via Party B, then the CPAs
> that could
> exist include:
> 1. Between Parties A and C
> 2. Between Parties A and B
> 3. Between Parties B and C
>
> The last two CPAs might be, what could be described as, "blanket"
> CPAs that
> define the delivery channel protocols that are used between A and B or B
> and
> C for all messages irrespective of the business process.
>
> This is a typical hub situation as used by Commerce One and
> Ariba. I am not
> sure that the  current spec supports this scenario and would appreciate
> your
> views.
>
> Regards
>
> David
>
> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Monday, January 29, 2001 8:01 AM
> To: ebxml-tp@lists.ebxml.org
> Subject:
>
>
> I have attached the beginnings of a list of possible changes,
> improvements,
> and enhancements to the CPA-CPP specification.
> I believe that this list has most of the important near-term items on it I
> still have to go through another large stack of email and notes for
> additional points.
>
> I suspect that this list is more than we can expect to complete
> in the time
> available for version 1.0, and certainly more than we can complete before
> Vancouver. Officially we are past deadline for approval in April.
> Therefore we will have to do some careful triaging.
>
> Please review and plan to discuss at the Jan. 31 conference call.  Early
> responses via this listserver would also help.
>
> Regards,
> Marty
>
> (See attached file: CPA-CPP-changes.doc)
>
> ******************************************************************
> **********
>
>
> *********
>
> 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
> ******************************************************************
> **********
>
>
> *********
>
>
>
>
>
>
>
>
>
>