Re: Intermediaries - various cases

I maybe mixing the "Routing" and "Intermediary" because I think these 
concepts are closely related.  In your first kind of intermediary, does 
"modifying the message" implies the ability to "modify the destination" 
?  I think we should have a clearer definition what are the legitimate 
things an "intermediary" can do so to distinguish them from any other nodes 
that sits on the network path at the IP level.

Regarding the set of intermediaries you described which are deployed within 
the container (which are physically attached to the requester or provider), 
do you mean something like the AXIS handler ?  From another angle, we can 
categorized into "attached intermediaries" (as what you said) and "network 
intermediaries", which is running in a separate node than both the 
requester and provider.  This two types has very different underlying 
assumptions in terms of trust relationship, unit of failure, and should be 
modeled differently.  (I'm talking about "network intermediary" in my 
previous mail)

I don't fully understand what do you mean by "transparent" at the 
application level.  I personally don't think this is a criteria to 
distinguish between "intermediary" and "choreography".  Think about a 
"credit checking intermediary" that intercepts the "loan request" send by 
the client, add an assertion about his credibility and forward the modified 
message to the "loan approver provider endpoint", which verifies the 
assertion and make its decision.  In this case, I'll consider the credit 
checking is an "intermediary" even though its existent is NON-TRANSPARENT 
to both the client and server at the application level.  In this case, the 
intermediary can implement its functionality using an orchestration 
workflow engine.

It is really about whether the node is a "TERMINATION POINT" from the 
original sender's perspective.  If the answer is yes, then it is a 
"PROVIDER", otherwise, it is an "INTERMEDIARY".  Of course, as lacking a 
more rigorous definition, this is just my personal opinion.

Best regards,
Ricky

At 09:48 AM 9/27/2002 -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:
>
>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 11:15:49 UTC