axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <>
Subject Re: RE: SOAPAction
Date Thu, 08 Feb 2001 13:08:52 GMT
James wrote:
>Out options for dispatching messages to services include:
>1. Dispatching based on URI of service listener
>2. Dispatching based on HTTP SOAPAction header or similar transport layer
>specific mechanism
>3. Dispatching based on the namespace of the body entry.
>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.

Ya know - I think I agree with you and I think this stinks - to be blunt.
Either the spec writers were so forward thinking that they left things
wide open for lots of different really cool choices, or they blew it and
by leaving things so wide open have in essence defined nothing at all.
I'm leaning more towards the 2nd one.  8-)

>So let's look at the pro's and con's of the three and compare:
>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
>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
>the SOAP specification.  This is a highly scalable solution.

I don't think this is doable for all T/L's - not all will have a URI to
look at.  That said - we might need to take the approach that it's up to
the transport listener to figure out what that URI is - even if it means
parsing the SOAP envelope.  What if we took the approach that it's the
T/L's job to set the "Target" field in the MessageContext object before
calling invoke() - where the "Target" is the URI of the target service.
How the T/L goes about figuring this out is up to it - maybe it's the
URL, maybe it's the dir for ftp, maybe it's the SOAPAction, maybe it even
has to scan the message - but whatever the method, that's the T/L's job.
If someone decides to set-up their system so that *all* services use
the same URL and the service distinguishing field is in the SOAP Body, then
that's their problem - they should have used the SOAPAction header or used
different URLs.


View raw message