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 13:38:43 UTC