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

RE: Intermediaries - various cases

From: Anne Thomas Manes <anne@manes.net>
Date: Fri, 27 Sep 2002 14:58:34 -0400
To: "Ricky Ho" <riho@cisco.com>, "Cutler, Roger \(RogerCutler\)" <RogerCutler@ChevronTexaco.com>, "'Mark Baker'" <distobj@acm.org>, "Heather Kreger" <kreger@us.ibm.com>
Cc: <www-ws-arch@w3.org>
Message-ID: <ECEDLFLFGIEENIPIEJJPIEACCIAA.anne@manes.net>

True -- but don't we also want to articulate this form of intermediary?

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Ricky Ho
> Sent: Friday, September 27, 2002 1:38 PM
> To: Anne Thomas Manes; Cutler, Roger (RogerCutler); 'Mark Baker';
> Heather Kreger
> Cc: www-ws-arch@w3.org
> Subject: RE: Intermediaries - various cases
>
>
>
> Whether the message is physically sending over the network to
> another node
> which you have no control is a significantly different model.  A "network
> intermediary" has a different security, trust, fault handling
> scenario than
> an "interceptor" which runs in the same VM of the SOAP endpoint.
>
> Rgds, Ricky
>
> At 01:07 PM 9/27/2002 -0400, 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 Friday, 27 September 2002 14:57:52 GMT

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