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