axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Re: SOAPAction
Date Thu, 08 Feb 2001 06:31:49 GMT
James Snell wrote:

> First, let it be acknowledged that the SOAP specification doesn't care how
> exactly messages are dispatched -- that is an implementation detail left
> completely up to the SOAP application implementor.  We can use any of the
> three above mechanisms to achieve SOAP compliance.

when we were designing SoapRMI we considered those choices,

> 1. Dispatching based on URI of service listener
>
>    The good thing about this is that dispatching to a particular service is
> really dead simple.  We just read in the URI, lookup the appropriate service
> for that URI and go from there.  A unique ID can be created for each
> deployed service by appending a Query String parameter to the end of the
> basic listener servlet.  There is nothing about this approach that violates
> the SOAP specification.  This is a highly scalable solution.

it is definitely the simplest to use so we allow the user when it is creating
web service to give it a name and it is then accessible as http://host:port/name
or if user does not specify name it will be generated automatically (as some
UID).

> 2. Dispatching based on HTTP SOAPAction header or similar transport layer
> specific mechanism
>
>    The utility of the SOAPAction HTTP header as defined by the SOAP
> specification is fuzzy at best.  There are no conventions as to how exactly
> to use it, nor are there similar mechanisms defined for other transport
> mechanisms.  While I'd say that this is a fairly simple way to dispatch, it
> opens up many possibible incongruities with other SOAP implementations that
> either choose not to fully support the SOAP Action header (leave it blank)
> or to use it in some unexpected way.  There are facilities in the SOAP
> Specification that allow a Service provider to define and enforce a use
> convention for the SOAP Actor attribute which would be a requirement in
> order to use this as an effective dispatch mechanism.  On the upside, this
> is at the very least a scalable solution.

i had similar feelings about SOAPAction so currently in our implementation we
simply ignore it :-)

> 3. Dispatching based on the namespace of the body entry.
>
>    This is not a scalable solution as it would require the parsing of every
> message received every time.  The equivalent to this would be digging
> through the contents of an HTTP POST just to figure out which script/servlet
> to post it to.

in case when at given URI is only _one_ service the body namespace can be
ignored (and it is good for performance - no need to check and for robustness -
URI name will have higher priority that namespace) however when there is more
services at the same URI then the body namespace can be used to dispatch call to
registered remote object (if any is found).

alek
--
Aleksander Slominski, LH 316, IU, http://www.extreme.indiana.edu/~aslom
As I look afar I see neither cherry Nor tinted leaves Just a modest hut
on the coast In the dusk of Autumn nightfall - Fujiwara no Teika (1162-1241)



Mime
View raw message