- From: Mark Baker <distobj@acm.org>
- Date: 2002年9月27日 11:05:58 -0400
- To: Heather Kreger <kreger@us.ibm.com>
- Cc: www-ws-arch@w3.org
- Message-ID: <20020927110558.J24048@www.markbaker.ca>
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 11:05:34 UTC