ebxml-tp message

OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

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


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

I hope this clarifies the use case that I was thinking of.


-----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;
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
  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
  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
  minimum work that it does)

This last thing is what makes me thinking my way; whenever there is some
(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
become accountable because it is not actually seen by the participants.

Sorry if these are just brainstomring thoughts. Hope they make at least some

Best regards



 -----Original Message-----
 From: Philippe DeSmedt [mailto:PDeSmedt@viquity.com]
 Sent: 31 January 2001 20:37
 To: 'Burdett, David'; 'Stefano POGLIANI'; Martin W Sachs;
 Subject: RE: Does the current CPA/CPP spec support multi-hop?


 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
 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
 an entirely different issue that I do not believe we have covered in CPA

 The bottomline is that we need to differentiate between CPA information
 covers the business aspects of the interactions between two partners, and
 the information that is required to carry the message over possibly
 hops. In addition, we may want to take a closer look at what functionality
 is actually provided at the intermediate points.

 Philippe De Smedt
 Viquity Corporation (www.viquity.com)
 1161 N. Fair Oaks Avenue
 Sunnyvale, CA 94089-2102
 (408) 548-9722
 (408) 747-5586 (fax)

 -----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?


 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
 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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC