RE: Intermediaries - various cases

>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? 

Here is the definition from the XML Protocol Abstract Model [1]:

"XML Application:
A client or user of the services provided by the XML Protocol Layer. An XML
Protocol Application may act in the initiating or responding role with
respect to two-way request response operations and in the sending or
receiving roles with respect to one-way operations. XML Protocol
Applications may also act in an intermediary role with respect to both
two-way and one-way operations."

So it seems that the "logging or encryption or message reconciliation or
message persistence" performed along a SOAP message path might actually
belong to the application layer (even though the sending application might
not be aware of it).

Ugo

[1] http://www.w3.org/2000/xp/Group/1/08/14-am/xmlp-am.html#Sec1.1

-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net]
Sent: Friday, September 27, 2002 10:08 AM
To: Cutler, Roger (RogerCutler); 'Mark Baker'; Heather Kreger
Cc: www-ws-arch@w3.org
Subject: RE: Intermediaries - various cases



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:39:43 UTC