axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "MURRAY,BRYAN (HP-FtCollins,ex1)" <bryan_mur...@hp.com>
Subject RE: SOAPAction
Date Wed, 07 Feb 2001 17:57:05 GMT
I don't understand why SOAPAction has anything to do with allowing the use
of a streaming parser.

SOAPAction is something defined only for the HTTP transport. It cannot be
the only mechanism used to dispatch requests. Some installations MAY want to
use SOAPAction to dispatch their requests - so have them set up their
configuration file to provide for that.

I also feel that the SOAPAction and the target URI should NOT be required to
be the same. The target URI might need to point to an intermediary, whereas
the SOAPAction might more appropriately point to the final destination. But
all of this can vary widely depending upon how someone wants to deploy their
enterprise. We should not enforce any requirements on SOAPAction besides
requiring that it exist in the HTTP headers.

Other data on which to dispatch may include any of the following and more:
	target URI
	SOAPAction
	document namespace	(different versions of SOAP)
	document tag name		(support non-SOAP protocols)
	first Body child namespace
	first Body child tag name
	URI query string
and of course all the header processing involves dispatching on SOAPActor,
header namespace and header tag name. In order to allow flexibility to the
SOAP deployer, how a message is dispatched needs to be configurable. Some
systems will want to have a single URI for all services, other systems will
want a different URI for each service - make it possible for both of these
systems to use AXIS.

Bryan Murray


-----Original Message-----
From: Steve Graham [mailto:sggraham@us.ibm.com]
Sent: Wednesday, February 07, 2001 7:24 AM
To: axis-dev@xml.apache.org
Subject: Re: SOAPAction


we may have to kiss pulled parsing goodbye, as SOAPAction header is
optional (it is required, but the content may not be reliable).  Further
for requests coming in from other transports (SMTP) we cannot rely on this
as a mechanism to lookup which type of service is being invoked.

sgg

++++++++
Steve Graham
sggraham@us.ibm.com
(919)254-0615 (T/L 444)
<<Pithecanthropus Erectus>>
Emerging Internet Technologies
++++++++

Mime
View raw message