W3C home > Mailing lists > Public > www-ws-arch@w3.org > September 2002

Re: Intermediaries - various cases

From: Jean-Jacques Moreau <moreau@crf.canon.fr>
Date: Mon, 30 Sep 2002 13:56:41 +0200
Message-ID: <3D983BF9.4070900@crf.canon.fr>
To: Anne Thomas Manes <anne@manes.net>
CC: "Cutler Roger \(RogerCutler\)" <RogerCutler@ChevronTexaco.com>, "'Mark Baker'" <distobj@acm.org>, Heather Kreger <kreger@us.ibm.com>, www-ws-arch@w3.org

It is the combination of the two. A SOAP node is the "conceptual" 
computer that either emits or processes SOAP messages. I say 
"conceptual" because the "computer" may not be just one single 
machine, but may be distributed over several physical nodes (in 
certain setups). The XMLP WG did not want to either prohibit or 
dictate implementation choices, hence the abstracted definition 
at [1]. The notion of SOAP processor was somewhat blurred, and so 
has been eliminated in favour of SOAP node.

Jean-Jacques.

[1] 
http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part1.html#concepts

Anne Thomas Manes wrote:
> So here's a question: is a SOAP node the application that makes the initial
> request or is it the SOAP message processing runtime runtime engine that
> actually sends the request over the network or is it the combination of the
> two? Likewise on the server side, is the SOAP node the application that
> receives the final request or is it the SOAP message processor that
> translates the request into a method call or is it the combination of the
> two?
> 
> The way many SOAP message processors work, you can add all kinds of extra
> middleware functionality (implemented as interceptors or header processors)
> in the SOAP message processor. For example, you can perform logging or
> encryption or message reconciliation or message persistence, etc. A lot of
> these functions can happen without the application's awareness. I view these
> interceptors and header processors as intermediaries (although Mark tells me
> that they are nodes). Physically, I'm not sending the message over the
> network between each interceptor, but conceptually I am.
> 
> Anne
> 
> 
>>-----Original Message-----
>>From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
>>Behalf Of Cutler, Roger (RogerCutler)
>>Sent: Friday, September 27, 2002 11:35 AM
>>To: 'Mark Baker'; Heather Kreger
>>Cc: www-ws-arch@w3.org
>>Subject: RE: Intermediaries - various cases
>>
>>
>>
>>>From my perspective it seems like there are two rather different types of
>>things being talked about.  Apologies for the vagueness, but ...
>>
>>1) Intermediaries that I am aware of and in fact are probably
>>services that
>>I am paying for.  Like a company that says, "give us your message and we
>>will take care of the security and reliability issues and make sure it is
>>delivered to the addressee".  Sort of like the Post Office.
>>
>>2) Intermediaries that our network or security people might be
>>aware of but
>>I am not (and so I have difficulty giving an example, but I'll
>>bet you folks
>>can).
>>
>>Incidentally, I enjoyed getting a glimpse of what you do for a
>>living, Mark.
>>
>>-----Original Message-----
>>From: Mark Baker [mailto:distobj@acm.org]
>>Sent: Friday, September 27, 2002 10:06 AM
>>To: Heather Kreger
>>Cc: www-ws-arch@w3.org
>>Subject: Re: Intermediaries - various cases
>>
>>
>>
>>Hi,
>>
>>On Fri, Sep 27, 2002 at 09:48:19AM -0400, Heather Kreger wrote:
>>
>>>I am somewhat naive in this space, but I'll weigh in with what I've
>>>heard in some discussions lately, including the management task force
>>>call:
>>
>>This is my "bread and butter", so to speak.  I build routers.
>>
>>
>>>I had always thought of intermediaries as transparent to the
>>>application.
>>
>>Some are, but not all.
>>
>>
>>>In my simple mind there were
>>> 2 kinds of intermediaries:
>>>      - those who modify the messages that flow thru them
>>>            security type ones
>>>            gateways
>>>      - those that do not modify it and pass them on
>>>            routers
>>>            store/forward
>>
>>That's one way to characterize them, sure.  But it doesn't tell the whole
>>story.  Sort of like those "there's two kinds of people in the
>>world" lines.
>>8-)
>>
>>Off the top of my head, you could also characterize them by;
>>
>>- whether it's identified as recipient of message or not.  i.e.
>>whether it's
>>a proxy or a gateway
>>- which administrative domain it's under, sender or receiver
>>
>>
>>>I guess the term 'transport' intermediary didn't fit for me because
>>>many intermediaries do 'transport' agnostic things (log, etc.),
>>>however, I can see the argument for the term because these
>>>intermediaries are invoked in the process of 'transporting' a message
>>>between a requester and provider.
>>>
>>>Intermediaries that applications are aware of (i.e. at the application
>>>layer)
>>
>>I think all intermediaries that we're talking about are application layer
>>intermediaries.  Things like TCP PEPs would be an example of a transport
>>layer intermediary.
>>
>>
>>>fit more in the work flow/ choreography scenario in my mind
>>
>>There's many kinds of choreography.  Some of them fit more with
>>
>>
>>>I had also thought that the set of intermediaries to be processed in
>>>the course of getting from requester to provider and back again would
>>>be defined in the configuration of the requester and/or provider when
>>>it was deployed...
>>
>>You mean the route isn't part of the message?  So that would have to be
>>hub-and-spoke style, with the initial message sender actually sending
>>multiple messages, one to each intermediary?
>>
>>That's certainly possible, but I wouldn't call that routing, nor would I
>>call it a good idea in general.
>>
>>
>>> so I"m not sure how the scenario of a requester hands out its list of
>>>intermediearies WITH its message fits into this...
>>
>>That's what WS-Routing does.
>>
>>
>>> Did the
>>>infrastructure put the list in (transparent to app) or did the app
>>>specifify them (workflow?).
>>
>>You can do it both ways.
>>
>>When you think about it, an intermediary is a *very* generic
>>concept; just a
>>node that sends and receives messages.  There are many ways in which a
>>message could be routed to and/or from this node.  Here are some
>>of the ways
>>that our routing platform supports;
>>
>>http://www.idokorro.com/routing.html
>>
>>MB
>>--
>>Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
>>Ottawa, Ontario, CANADA.               distobj@acm.org
>>http://www.markbaker.ca        http://www.idokorro.com
>>
>>
> 
> 
Received on Monday, 30 September 2002 07:56:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:06 GMT