axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Snell <>
Subject RE: SOAPAction
Date Wed, 07 Feb 2001 22:16:06 GMT

the only problem with this is that a SOAP Processor cannot ONLY parse and
process the headers.  Rather, a SOAP Processor is under some fairly
stringent guidelines that must be met in order for ANY part of the message
(body and headers) can be touched.  Some of these include:

   * A SOAP message MUST NOT contain a Document Type Declaration.  
   * A SOAP message MUST NOT contain Processing Instructions. [7]
   * All non-SOAP defined elements MUST be namespace qualified
   * The Body Element MUST exist

If any of these requirements is not met, then the entire message SHOULD be
tossed out before any processing of the message contents (header or body) is
done at all.  

HTTP "messages" do not have similar requirements and therefore use a
different processing model.

And as another point, it simply is not scalable to examine every message for
information about where to dispatch the message.

- James

> -----Original Message-----
> From: MURRAY,BRYAN (HP-FtCollins,ex1) []
> Sent: Wednesday, February 07, 2001 1:57 PM
> To: ''
> Subject: RE: SOAPAction
> I think Axis should be configurable enough so that a system 
> may be deployed
> as you describe. This is certainly a reasonable method for 
> dispatching,
> especially for some intermediaries.
> However, I think if we compare a SOAP message with an HTTP message the
> following hold true:
> 	SOAP headers	~are related to~	HTTP headers
> 	SOAP Body		~is related to~	HTTP contents
> and just as an HTTP processor parses the HTTP headers, a SOAP 
> processor will
> parse the SOAP headers. And just as an HTTP processor may be 
> able to do its
> job without parsing the contents, a SOAP processor may be 
> able to do its job
> without parsing the Body. Since we are working at a different 
> abstraction in
> the protocol stack, I don't think we can make a direct 
> comparison between
> SOAP and HTTP.
> Just as it should not be mandatory that the SOAP document be 
> parsed before
> identifying the end service, it also should not be mandatory 
> for the end
> service to be identified before beginning parsing - the document will
> contain the information needed.
> Bryan Murray
> -----Original Message-----
> From: James Snell []
> Sent: Wednesday, February 07, 2001 10:47 AM
> To: ''
> Subject: RE: SOAPAction
> Remember that not focusing on Routing per se, we're talking about
> dispatching an incoming message to a deployed service.  Whatever the
> deployed service does with the message (processes the SOAP 
> message, does not
> process the soap message) is irrelevant at this point.  The task of
> receiving a message, determining which service needs to 
> process that message
> and thereby forwarding the message on to the service does not require
> parsing the envelope at all, nor should we ever design the 
> system to do so
> since we can make absolutely no assumptions as to what is in 
> the contents of
> the message.  
> I should never be forced to parse a message simply to find 
> out where it
> needs to go (the equivalent to this would be a Web Server 
> being forced to
> parse the contents of a HTTP POST in order to figure out which
> script/servlet it is being posted to).
> Secondly, SOAP does not require routing information in the 
> Header to make it
> transport independent.  All the transport layer needs to know 
> is where and
> how to send the message (a URI).
> - James

View raw message