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

[christopher ferris <chris.ferris@east.sun.com>]

This has always been my thinking. Of course, what
is missing is the CPA between the intermediary that
receives messages on behalf of senders and the To party
such that the messages are correctly received by the To
party based on its capabilities.

The intermediary MAY care about the business process,
or not as the case may be, and certainly the MSH needs
to be aware that it will receive messages from an 
intermediary MSH...

Thus, a CPA need not necessarily reflect the fact
and relevant details of the MSH from which it receives
messages. However, maybe it is nessary that we 
include in the CPA spec some means of enabling a "pass-through"
DocExchange layer...

Cheers,

Chris


Martin W Sachs wrote:
> 
> Maybe it's simpler than what is described below. The following should work
> though it may require some reorientation of thinking.  It is similar to the
> Ariba punchout case.
> 
> The CPA contains the following:
> 
>    Pointer to collaboration protocol definition for the A-B business.
>    A's delivery channel identifies receive capabilities HTTP
>    B's delivery channel identifies receive capabilities SMTP
>    Both A and B specify send capabilities provided by the intermediary.
> 
>    It might confound a standard composition tool but it should work.
> 
> 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
> *************************************************************************************
> ---------------------- Forwarded by Martin W Sachs/Watson/IBM on 01/31/2001
> 09:58 AM ---------------------------
> 
> Martin W Sachs
> 01/31/2001 09:40 AM
> 
> To:   ebxml-tp@lists.ebxml.org
> cc:
> From: Martin W Sachs/Watson/IBM@IBMUS
> 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
> ****************************************************************************
> 
> *********
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