axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <...@us.ibm.com>
Subject Re: Default values for SOAPAction
Date Wed, 20 Jun 2001 14:51:00 GMT
Seems reasonable.  Just wondering, at the transport level how will
you know whether it's an RPC message or not ?  In the non-RPC
case you can't assume that the first body entry is the "main" guy.
Actually, I guess this could be true for the RPC case as well.
It all depends on the serialization routines.  Ug, I'm sensing a
discussion on the "root" attribute coming up.  8-)
-Dug


Sam Ruby/Raleigh/IBM@IBMUS on 06/20/2001 09:42:23 AM

Please respond to axis-dev@xml.apache.org

To:   axis-dev@xml.apache.org
cc:
Subject:  Default values for SOAPAction



This note is based on the premise that default values matter, particularly
as how they influence people's first impression of interoperability.  In
particular, I've just been testing Axis against DotNet beta 2...

The first observation is that DotNet _by_default_ will set SOAPAction to
the namespace of the service concatenated with the method name.  (In WSDL
terms, definitions.targetNameSpace + "/" +
definitions.binding.operation.soapAction).

The second observation is that in WSDL terms, there seems to be an
implication that SOAPAction can vary from operation (i.e., method) to
operation, not service to service.  This makes some sense from the
perspective of a (still hypothetical to the best of my knowledge) firewall
software that might want to filter based on SOAPAction.

The final observation is that there will be a number of dispatch strategies
which will not depend on SOAPAction, so making this value reasonably
default in as painless of a way as possible is desirable.

===

The concrete proposal is to provide an overload to HTTPTransport which does
not require an action, and to dynamically compute a default if one is not
provided.  This will also be of value when a ServiceClient is created based
simply on an endpointURL.  I also propose updating a number of samples to
match.

====

Notes:

(1) I am not proposing the removal of the ability to specify the
SOAPAction, merely providing a reasonable default in the case where one is
not specified.

(2) There is no reason why the default must match Microsoft's, but their
choice of default seems reasonable to me, and I see no reason to be
gratuitously different.

(3) This poses no compatibility issues with Apache xml-soap V2 as it
largely ignores the value of SOAPAction.

- Sam Ruby




Mime
View raw message