W3C home > Mailing lists > Public > www-ws-arch@w3.org > December 2003

RE: Intermediaries

From: Ugo Corda <UCorda@SeeBeyond.com>
Date: Fri, 5 Dec 2003 10:54:53 -0800
Message-ID: <EDDE2977F3D216428E903370E3EBDDC9039587A8@MAIL01.stc.com>
To: "Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com>, "Ricky Ho" <riho@cisco.com>, <www-ws-arch@w3.org>

> It seems to me, from listening and participating in a
> certain amount of conversation trying to sharpen up the 
> concept of "same message" that this is a swamp.

That's probably correct.


> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Cutler, Roger (RogerCutler)
> Sent: Friday, December 05, 2003 10:45 AM
> To: Ricky Ho; www-ws-arch@w3.org
> Subject: RE: Intermediaries
> I'm not an expert here, and I was mostly trying to capture 
> the sense of
> a conversation.  However, I believe that several people agreed that it
> is, indeed, up to B and C to participate in this decision, 
> and that the
> "application" envisaged includes both sender and receiver.  This was
> explicitly stated, I believe, by both David Booth and at 
> least one other
> person, I've forgotten whom.
> About the messageID -- does a SOAP message necessarily have 
> one?  If the
> intermediary encrypts the message, including the ID, do you have the
> same messageID?  It seems to me, from listening and participating in a
> certain amount of conversation trying to sharpen up the 
> concept of "same
> message" that this is a swamp.
> -----Original Message-----
> From: Ricky Ho [mailto:riho@cisco.com] 
> Sent: Friday, December 05, 2003 10:49 AM
> To: Cutler, Roger (RogerCutler); www-ws-arch@w3.org
> Subject: Re: Intermediaries
> Can we use messageID to determine whether this is the "SAME" message ?
> In 
> other words, all other modification is insignificant.
> 1) Intermediary isn't the endpoint so it doesn't generate new 
> messages,
> so 
> the message it send MUST have same messageID as some previous messages
> it 
> received.
> 2) Orchestration is the endpoint which produce or consume messages, so
> the 
> message it send MUST have different messageID from previous received
> messages
> Going back to your example, it is NOT up the B and C to 
> interprete the 
> changes made by I differently.  The decision is completely 
> finalized by
> I.
> Best regards,
> Ricky
> At 09:44 AM 12/5/2003 -0600, Cutler, Roger (RogerCutler) wrote:
> >Here is some text that expresses my understanding of the 
> sense of some 
> >of the telcon conversation about intermediaries.  Please 
> use, modify or
> >ignor as seems appropriate.
> >
> >It is useful to draw a distinction between situations where messages 
> >are passed through intermediaries and choreographies.  The essential 
> >issue is that an intermediary passes along a message that is 
> >essentially, or functionally, the same as it received.  If, on the 
> >other hand, the purpose or function of the message is substantially 
> >changed one should consider the situation to be a 
> choreography.  This 
> >cannot be defined, however, in an entirely rigorous or black 
> and white 
> >way -- one person's intermediary may legitimately be considered a 
> >choreography by others. Note that since an intermediary can 
> change the 
> >message, for example by encrypting it or by adding ancillary 
> >information, it remains a judgment call whether those changes are 
> >significant and functional.  In addition, whether a service 
> that passes
> >messages is considered an intermediary depends on 
> participants in the 
> >entire chain of the message.  For example, if sender A sends 
> messages 
> >through I, which modifies the messages, to receivers B and 
> C, B might 
> >consider the modified message to be functionally unchanged whereas C 
> >might consider it to be different and take different action 
> because of 
> >the modification.  In the first case I would be considered an 
> >intermediary, in the second it would not.
Received on Friday, 5 December 2003 13:54:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:09 UTC