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

RE: Intermediaries

From: Ricky Ho <riho@cisco.com>
Date: Fri, 05 Dec 2003 11:36:05 -0800
Message-Id: <>
To: "Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com>, "Francis McCabe" <fgm@fla.fujitsu.com>
Cc: www-ws-arch@w3.org

I guess what you are trying to differentiate is between "intermediary" and 
"endpoint".  And the "endpoint" in this discussion is implemented by 
composing other web services using an "orchestration".

I consider differentiating "intermediary" and "endpointByOrchestration" is 
important.  At least from the sender point of view, it needs to know 
whether the message has reached the intended destination.

Rgds, Ricky

At 12:49 PM 12/5/2003 -0600, Cutler, Roger (RogerCutler) wrote:

>Well, as I said, I was only trying to capture the sense I personally got
>of this discussion, in case those words might be a starting point for
>something.  Feel free to change, ignor or whatever.  I don't have a real
>strong opinion about any of this stuff, other than that I would like
>some sort of discussion of the issue that I can understand -- that
>explains in simple terms (if possibly loosely defined) what class of
>thingies are intermediaries and what class of other thingies are not.
>That was just my attempt to say something clear -- whether it is correct
>or not is entirely another issue about which I don't have a strong
>-----Original Message-----
>From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
>Sent: Friday, December 05, 2003 11:27 AM
>To: Cutler, Roger (RogerCutler)
>Cc: www-ws-arch@w3.org
>Subject: Re: Intermediaries
>   I don't think that it is fair to say that intermediaries are different
>to choreographies -- a case of apples and oranges.
>   A particular setup involving intermediaries etc. may be modeled as a
>choreography; or may slip under the choreography radar - depending on
>your perspective and preferences.
>   I think that the keys here are:
>1. A message is deemed to be the same message or not -- as the case may
>be. There are many real-world examples of this: a letter containing a
>purchase order may be marked up by various people as its makes its way
>-- together with the accumulating documentation of the work item --
>through an organization. Each person that reads the letter may be
>required to stamp it, or sign it, to say that he/she has read it. Is
>the letter the same or not -- after such a signature? It is, primarily
>because we say it is. The same principle applies (IMO) to electronic
>2. Once you unwrap a service into different pieces -- each piece
>dealing with a different aspect of the service -- then you can begin to
>properly account for intermediary-style processing. Without this
>unwrapping, intermediaries must be transparent -- in which case they
>don't exist from the service POV.
>3. However, this unwrapping comes at a price: we now have to also deal
>with either choreography or composition of services -- or at least
>service elements. What *is* the thing that does some of the processing
>but not all of a given message? What is the totality of it all?
>What follows is opinion:
>I happen to believe that this unwrapping is a *good thing*. I fully
>realize that it tends to  muddy the clean SOA story somewhat: because
>we can now no longer be so hard and fast about not peeking inside
>service agents - the processing of a message is also no longer a
>one-shot affair.
>That last feature is actually why I am in favor of this:
>a. Processing of significant messages is *never* one-shot anyway. b. The
>approach of well-defined elements of messages relating to
>well-defined aspects of messages seems to me to foster re-use and sound
>c. The layered message suggests a parallel layering of the semantics of
>messages; which further reduces the sticker shock associated with
>documenting semantics.
>d. A phased approach to processing/comprehension reflects natural
>realities better than the one-size-fits-all approach of pure SOAs.
>BTW, the case of the mediator service -- the one that decides which
>service agent to direct a message to -- does seem to me to be an
>extreme case of an intermediary. Consider the parallel of a
>receptionist at the front desk. He/she uses information you provide to
>direct you to the right department. Similarly, the person sorting the
>incoming mail. It is clumsy to model that scenario solely in terms of
>originating new messages all the time.
>On Dec 5, 2003, at 7:44 AM, 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
> > 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
> > 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
> >
Received on Friday, 5 December 2003 14:36:14 UTC

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