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

Re: Intermediaries - various cases

From: Heather Kreger <kreger@us.ibm.com>
Date: Fri, 27 Sep 2002 09:48:19 -0400
To: Mark Baker <distobj@acm.org>
Cc: www-ws-arch@w3.org
Message-ID: <OF3CDCC721.5376C97E-ON87256C41.004877C5@us.ibm.com>





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:

I had always thought of intermediaries as transparent to the application.
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

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) fit more in the work flow/ choreography scenario in my mind

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...  so I"m not sure how the scenario of a requester hands out its
list of intermediearies WITH its message fits into this...  Did the
infrastructure put the list in (transparent to app) or did the app
specifify them (workflow?).

Heather Kreger
Web Services Lead Architect
STSM, SWG Emerging Technology
kreger@us.ibm.com
919-543-3211 (t/l 441)  cell:919-496-9572


Mark Baker <distobj@acm.org>@w3.org on 09/26/2002 11:15:28 PM

Sent by:    www-ws-arch-request@w3.org


To:    Ugo Corda <UCorda@SeeBeyond.com>
cc:    "'www-ws-arch@w3.org'" <www-ws-arch@w3.org>
Subject:    Re: Intermediaries - various cases




I'll give my 2c on this.  Good questions, BTW.

On Thu, Sep 26, 2002 at 02:37:41PM -0700, Ugo Corda wrote:
>  Or is the publish-and-subscribe
> node the Service Provider, which engages in separate interactions with
the
> subscriber nodes?

Yes, that one.

The pub/sub node is an intermediary, because it both sends and receives
messages.  But it's also the final-destination/service-provider.

There are different kinds of intermediaries; some will be final
destinations (gateways), and others will be routed-to (forward proxies
ala WS-Routing) or routed-from (reverse proxies, ala WS-Referral).

> Or is there no single answer to these questions, and it
> all depends on the logical view that I want to apply to the scenario?

There's definitely more than one way to design and/or execute a route of
nodes to achieve some goal.  But in each case, I believe all the roles
should be apparent.

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 09:48:55 GMT

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