Intermediary Discussion

Mark, 

> So, you're saying that using in-message routing is an alternative
> form of targetting? 
> 

Yes, although this isn't the best way to do it.  Ideally we shouldn't
necessarily have to "open the envelope" so to speak in order to do message
routing to intermediaries, but it is an option.

> Also, isn't it plausable that an intermediary could be located by a
> serivce URI (say, thorugh client configuration, etc.), while the
> following intermediary could be located by in-message routing? I
> guess I'm wondering why it's necessary to tie block targetting to
> message routing.
> 
> 

This is an absolutely plausible and most likely occurrence.   One question
that needs to be answered is this: in the above case, does the client even
have to know anything about the second intermediary?  In which case, from
the Clients point of view, the first intermediary IS the service.  

Lots of worms in this can: the primary point that I want to make here is
that this working group (of which sadly I am not a member :-( ...) needs to
spend some serious thought time on defining the following areas:

   1. Message Path definition (is the message path determined by the message
or the message processor)
   2. Addressing/Identification of Intermediaries
   3. Supported Intermediary Interaction Patterns

For Apache Axis (SOAP version 3.0), we've pretty much decided that the SOAP
actor attribute is a tag identifier only, not a intermediary locator.  It is
up to some mechanism in the Axis engine (I'll spare the details) to
determine what exactly that tag identifier is pointing to.  The path of
intermediaries that a message path flows through is determined at service
development/deployment time and is basically hardwired into the service.  

- James

> 
> -- 
> Mark Nottingham, Research Scientist
> Akamai Technologies (San Mateo, CA)
>

Received on Wednesday, 7 February 2001 15:52:47 UTC