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?


David:
Boy, that certainly opens up a can of worms! So what you are saying is that
the payload transformation is going from a well-formed document (if we can
nail that one down) to a non-XML data type. More specifically, are you
implying that if party A and party B are both operating under "ebXML'
semantic rules, then there is no reason to reformat? Is ebXML going to
specify transformation rules into non-XML data types as well? It seems to me
that this sort of reformatting is itself an end application leaving the
ebXML world and realistically cannot be cast as a multi-hop situation.
Multi-hop sort of implies a two-way dialog meaning that the specification
would have to account for inputting an EDI document, a plain text email, or
a fax as well.
Sandy

> From: "Burdett, David" <david.burdett@commerceone.com>
> Date: Wed, 31 Jan 2001 17:38:30 -0800
> To: 'Sandy Klausner' <klausner@coretalk.net>, '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?
> 
> Sandy
> 
> Examples would include a hub that received a message in an ebXML wrapper
> then forwarded it as one of the following: an EDI document, a plain text
> email or a fax.
> 
> David
> 
> -----Original Message-----
> From: Sandy Klausner [mailto:klausner@coretalk.net]
> Sent: Wednesday, January 31, 2001 5:23 PM
> To: Burdett, David; 'Stefano POGLIANI'; Philippe DeSmedt; Martin W
> Sachs; ebxml-tp@lists.ebxml.org
> Subject: Re: Does the current CPA/CPP spec support multi-hop?
> 
> 
> 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
>>> 
>>> 
>> 
> 



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

Powered by eList eXpress LLC