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 12:31:29 UTC