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

[Sandy Klausner <klausner@coretalk.net>]

David:
Your clarification is useful and I would be interested in a drill down as to
the specific requirements for a "midway" hub type. I agree that its function
would be limited to performing envelope and payload reformatting and perhaps
retransmission under a different protocol. I would question the
applicability for ebXML to get involved in protocol transport level issues
which only leaves open the reformatting function. Can you site several
concrete examples where reformatting is required?
Sandy

> From: "Burdett, David" <david.burdett@commerceone.com>
> Date: Wed, 31 Jan 2001 16:59:56 -0800
> To: 'Stefano POGLIANI' <stefano.pogliani@sun.com>, Philippe DeSmedt
> <PDeSmedt@viquity.com>, Martin W Sachs <mwsachs@us.ibm.com>,
> ebxml-tp@lists.ebxml.org
> 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
> »
> »
>