RE: SOAPAction Proposal

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I've been lurking and watching the SOAPAction threads with interest;
now seems as good a time as any to stick my oar in...

: Doug Davis:
: 
: >> I guess I'd like to know what would be 
: >> missing from SOAP if the SOAPAction 
: >> header did go away? 
:
: Noah_Mendelsohn: 
:
: In a nutshell, the ability to learn something about the message
without 
: having to crack the XML.  Now, as to exactly what that something
is, there 
: seems to be disagreement, which makes it look a bit like an answer
in 
: search of a question, but it is at least potentially of great
value.. 

I think this sums it up.

I also think that maybe a tree was an unfortunate choice for an
Envelope/Message (EM) structure. Specifically, having the body
element as special header is the underlying problem:

"4.3.1 Relationship between SOAP Header and Body While the Header and
Body are defined as independent elements, they are in fact related.
The relationship between a body entry and a header entry is as
follows: A body entry is semantically equivalent to a header entry
intended for the default actor and with a SOAP mustUnderstand
attribute with a value of "1". The default actor is indicated by not
using the actor attribute (see section 4.2.2)."

Simply, if the idea was not to crack the XML in a broker sympathetic
messaging protocol, two separate XML documents for envelope and body
are worth considering. The price for not doing this seems to be
either to "inform" the network layer carrying the SOAP message or
take a hit on opening the envelope. Having said that, it's not
altogether clear to me what the problem is with inspecting the XML.

In time it may prove to be the case that SOAPAction will not be the
only header needed to prevent a parse. Though if it is, will it not
be overloaded and extended? That hardly aids interoperability.


Consider a related problem: the design of an EM structure for message
passing software agents. The FIPA abstract architecture [1] keeps
these two elements separate; in part to enable efficient processing
and dispatch in multi-hop use cases. FIPA defines a Message
structure, essentially a map. For the wire, the Message plays the
role of an opaque Payload contained in a Transport Message, which
also contains an Envelope.  Transport Messages are marshaled by a
Transport supporting a Transform Encoding using a Transform Service.
That may sound long-winded (there's actually more to it), but it
greatly aids protocol agnosticism. When it comes to an actual
encoding in XML, FIPA has defined separate DTDs for the Envelope and
Message [3, 4]. FIPA use a multipart mime body to deliver Envelope
and Message [2] (mapping the FIPA form to SOAP will prove to be an
interesting exercise).

My question then, is this: must future SOAP specifications enforce
the nested body? Assuming a "yes": then SOAP over HTTP has the
request URI, the Content-type header and the body. These seem
sufficient to dispatch on, make decisions re the message performative
and filter. A minimum of extra code is required for HTTP machinery,
and ability of vendors to leverage the absence of clear semantics is
reduced. Hints are for best practice, not protocol design. 

regards,
Bill de hOra

- ----
Bill de hOra : InterX : bdehora@interx.com 

[1] FIPA Abstract Architecture Specification:
<http://www.fipa.org/specs/fipa00001/XC00001I.html>
[2] FIPA Agent Message Transport Protocol for HTTP Specification:
<http://www.fipa.org/specs/fipa00084/XC00084C.html>
[3] FIPA Agent Message Transport Envelope Representation in XML
Specification:
 <http://www.fipa.org/specs/fipa00085/XC00085G.html>
[4] FIPA ACL Message Representation in XML Specification: 
<http://www.fipa.org/specs/fipa00085/XC00085G.html>

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBOvm7UeaWiFwg2CH4EQJXcACfdxbR18qQUUBBaEenISsFIA5DqiQAoMkj
gqjbZyf2qLnFeiKL8RnL81Gf
=qfGm
-----END PGP SIGNATURE-----

Received on Wednesday, 9 May 2001 17:58:57 UTC