Re: WS-Routing Intermediary

On Mon, 6 May 2002 22:11:03 +0530, in soap you wrote:

>Hi All,
>
>How is a WS-Routing Intermediary best implemented, as a Web Service or =
as a
>Soap Extension or as a Http Handler
>How is a WS-Routing Ultimate Receiver best implemented, as a Web Service=
 or
>as a Soap Extension or as a Http Handler.

I'd recommend you build intermediaries with a SOAP toolkit designed
for such, currently WhiteMesa[1] is the only one i know of with a
useful level of intermediary building support.

Given the options you list, i assume you mean within the .NET
framework ? I've built WS-Routing intermediaries in .NET using HTTP
handlers, the ASP.NET soap bits just get in the way too much
otherwise. For endpoints, i would think that  a soap extension is
probably the best way to go.

>A WS-Routing Intermediary  can act as an intermediary for a specific web
>service only or it can be an intermediary for any number arbitrarty web
>services ( not known at the time of implemntation ).

depends what the intermediary is doing, by definition they are
supposed to be providing services orthogonal to the message body, so
its likely that in most cases you want your intermediary to be able to
act on arbitrary message bodies.

>Suppose i want a loggger WS-Routing Intermediary written do i have to =
write
>a separate logger for each and every web service
>(i.e.) one for echoString, one for echoInt etc. or the same intermediary
>will do for echoString, echoInt and any other arbitrary service not =
known at
>time the Intermediary is implemented.

write just one

>If the same intermediary can be used how to forward a call to a unknown =
web
>service how can this be done in .NET code only the endpoint is known.

As a HTTP handler, run the SOAP message through a parser, apply the
WS-Routing rules to extract the next hop, and to update the rev path
if needed, then send it onto the next hop.

Cheers
Simon
www.pocketsoap.com
[1] www.whitemesa.com