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.               [email protected]
http://www.markbaker.ca        http://www.idokorro.com