Subject: RE: Does the current CPA/CPP spec support multi-hop?
Stefano I think the type of "hub" that I'm describing lies mid-way between the following two extremes: 1. A very dumb hub that examines a message, determines the URL the message needs to be forwarded to and then forwards the message, unchanged, using the same transport protocol to a different URL address ... and 2. An intelligent hub that examines a message to understand the business process that is involved then amends/updates the detail of the payload data in the hub according the requirements of that business process as agreed between all the parties involved and finally forwards the amended/updated message to wherever it needs to go. The "mid-way" example that I am thinking of is as follows ... 3. A reasonably intelligent hub that examines the message and determines a) the format and structure of the payload and b) the party that the message needs to be forwarded to. It then determines the format envelope and payload formats that the party requires and the transport protocol that is to be used. It then reformats the message envelope/payload as required and forwards the message to the required party. The Hub is completely ignorant of any business process or rules associated with the message. In this example, the Hub does not need to know any details of the business process and only information connected with the Delivery Channel. I don't think the current CPA/CPP directly support this which is what Phillipe was saying. I hope this clarifies the use case that I was thinking of. David -----Original Message----- From: Stefano POGLIANI [mailto:stefano.pogliani@sun.com] Sent: Wednesday, January 31, 2001 2:36 PM To: Philippe DeSmedt; Burdett, David; Martin W Sachs; ebxml-tp@lists.ebxml.org Subject: RE: Does the current CPA/CPP spec support multi-hop? Philippe, David, I try to summarise what I understood of them and provide some generic comment here. - if B is NOT ebXML aware and cannot enter in a CPA with A, I do not understand how this may be a multi-hop scenario. - if the Hub needs to "convert" the message from HTTP to SMTP (or any other conversion stuff) then either this conversion is mechanical or it is another way for defining an active participation of the HUB into the Business Process. - In my modest opinion, multi hop is when the Hub really does not do anything else than acting as a middle point, without translation nor change in the protocol semantic. In my opinion what you both describe is a situation where the Hub does much more than that: at least it implements a rudimental state machine to twist things from the sender to the receiver. - I think (but this is simply me) that whenever the segments should change protocol semantic, then we do not actually think of a hub but think to a Party (which may not be very intelligent, but is anyway accountable of the minimum work that it does) This last thing is what makes me thinking my way; whenever there is some action (translation, change of protocol) we have a new actor in the chain which may become accountable of any fault. I remember that in Tokyo I tried to define the difference between a hub and a party on respect to accountability: a hub is just a technical mean which will never become accountable because it is not actually seen by the participants. Sorry if these are just brainstomring thoughts. Hope they make at least some sense. Best regards /Stefano /stefano » -----Original Message----- » From: Philippe DeSmedt [mailto:PDeSmedt@viquity.com] » Sent: 31 January 2001 20:37 » To: 'Burdett, David'; 'Stefano POGLIANI'; Martin W Sachs; » ebxml-tp@lists.ebxml.org » Subject: RE: Does the current CPA/CPP spec support multi-hop? » » » David, » » I like your suggestion to have, in the case of multi-hop messaging, a » separate CPA covering the transport aspects on each of the hops. The » business agreement between A and B can still be encoded in a CPA between » those two parties, but we do indeed need provisions (possibly as some form » of CPA) that address the specifics of the transport on each of » the hops. It may, for instance, be possible to have different transport » bindings on each hop (e.g. HTTP between A and the hub, and SMTP between B and the » hub), and I am not sure that such case is adequately covered in the current CPA spec. » Also, as you mention in your ebXML-to-EDI example, there may not be an » ebXML-compliant CPA between A and B, but we may still want to have one » between A and the hub (assuming that A speaks ebXML). » » In addition, there may also be cases where the role of the hub is more than » just a forwarding mechanism, but less than that of a full-fledged trading » partner, i.e., the hub may provide some value-added services, for instance » in the area of security. How CPAs can address that modality/topology is yet » an entirely different issue that I do not believe we have covered in CPA so » far. » » The bottomline is that we need to differentiate between CPA information that » covers the business aspects of the interactions between two partners, and » the information that is required to carry the message over possibly multiple » hops. In addition, we may want to take a closer look at what functionality » is actually provided at the intermediate points. » » -Philippe » _______________________________ » Philippe De Smedt » Architect » Viquity Corporation (www.viquity.com) » 1161 N. Fair Oaks Avenue » Sunnyvale, CA 94089-2102 » (408) 548-9722 » (408) 747-5586 (fax) » pdesmedt@viquity.com » » » -----Original Message----- » From: Burdett, David [mailto:david.burdett@commerceone.com] » Sent: Wednesday, January 31, 2001 10:51 AM » To: 'Stefano POGLIANI'; Martin W Sachs; ebxml-tp@lists.ebxml.org » Subject: RE: Does the current CPA/CPP spec support multi-hop? » » » 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 » »
Powered by
eList eXpress LLC