-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Michael,
[some food for thought]
> -----Original Message-----
> From: Michael Brennan [mailto:]
>
> The default should be the approach that is most useful and
> applicable to the broadest number of use cases. I'm inclined
> to believe the overwhelming majority of use cases will be
> about exchanging structured information, not documents.
> Forcing these applications to always have to deal with 2
> document formats (MIME multipart and XML) even when they are
> only deriving benefit from one does not make sense to me.
Reducing mean time to failure doesn't make sense to me. What you're
saying adds up in a point to point system, not one that allows
intermediary actors, and error reporting backtraces over the
network. I feel very comfortable saying that enabling http
multipart is trivial having worked both SOAP and MIME solutions.
MIME's not asking much (complexity easily amortized by SOAP
itself), mostly it's free given http and SMTP machinery. I think
the trade is worth it, considering applications will have trouble
even looking at the headers if the body is busted.
So this thing:
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<soap-env:Envelope
xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"
soap-env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<soap-env:Header>
<t:Transaction xmlns:t="some-URI"
soap-env:mustUnderstand="1">5</t:Transaction>
</soap-env:Header>
<soap-env:Body>
<m:GetLastTradePrice xmlns:m="Some-URI">
<symbol>DEF</symbol>
</m:GetLastTradePrice>
</soap-env:Body>
</soap-env:Envelope>
goes roughly to this:
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
Cache-Control: no-cache
SOAPAction: "Some-URI"
Content-Type: Multipart/Related; boundary=MIME_boundary;
type=text/xml;
start="<>"
Content-Description: This is the optional message description.
<soap-env:Envelope
xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"
soap-env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<soap-env:Header>
<t:Transaction xmlns:t="some-URI"
soap-env:mustUnderstand="1">5</t:Transaction>
</soap-env:Header>
</soap-env:Envelope>
- --MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <>
<soap-env:Body
xmlns:soap-env="http://schemas.xmlsoap.org/soap/body/" />
<m:GetLastTradePrice xmlns:m="Some-URI">
<symbol>DEF</symbol>
</m:GetLastTradePrice>
</soap-env:Body>
- --MIME_boundary--
Multipart can be nested arbitrarily; the body aspect of the outer
multipart can contain its own multipart, which would allow the
cases that the current SOAP with attachments caters for. The outer
multipart will only ever have two pieces; the envelope and the
body. Btw FIPA has a http binding for agent messages which works
along these lines
<http://www.fipa.org/specs/fipa00084/XC00084C.html>. It seems sane
enough given FIPA has the requirement that a payload can be
arbitrary data (i.e. in a form other than XML), so opacity is baked
in.
> I just don't see that MIME should be dictated to those
> applications that derive no benefit from it. I certainly
> wouldn't try to shoehorn every solution into an XML envelope,
> though. I think developers should have the flexibility to use
> the solution that best suits the problem at hand.
Applications will never see the stuff. Maybe I don't understand
you. In naïve API terms the difference is this; assuming you follow
the XML structure you go from a nest:
Envelope e = SOAPMessage.getEnvelope();
Headers h = e.getHeaders();
Body b = h.getBody();
to a flattened list:
Envelope e = SOAPMessage.getEnvelope();
Headers h = e.getHeaders();
Body b = SOAPMessage.getBody();
but in fact you can keep either API, as this is a detail about
serialization.
> Well, so long as I can use XML to model the individual
> components of information, it doesn't stop me. But it adds
> extra complexity while providing no benefit. Unless the SOAP
> envelope approach can be demonstrated to be harmful, I don't
> see any compelling reason to force my application to have to
> deal with 2 document formats (MIME multipart and SOAP), when
> one will do just fine.
I believe Elliote had outlined the harm. If its catchment area is
tiny, I guess they'll have to tough it out.
> Perhaps I'm simply biased by
> my own experiences, but I find this vision of web services to
> be a bit dubious. I can't help but think that coordination
> between web services will be managed by applications that
> process entire message envelopes, and based on that
> information construct specific messages targeted at other
> services, not handing the entire envelope around the network
> like a baton.
Granted. I take your point, but insistence on a single document I
suspect is an artefact of 'XML for documents' seeping into 'XML for
messaging'. Maybe I'm wrong. Certainly I question the value of
making the body a special kind of header.
> I think there are some fairly well-defined requirements,
> here. My requirement is to exchange structured information
> over the web. MIME does not accomodate that. MIME just models
> opaque documents.
Payloads are best modelled as opaque to their carriers. Putting
payloads /inside/ Envelopes on the wire seems like taking a
metaphor too literally: you don't need to open and parse the
contents of a real envelope to read what the envelope says. It may
be a good metaphor for application developers and API design. I
don't believe this has been thought out, i.e., only one document is
axiomatic in SOAP, but I'm happy to be convinced otherwise.
Given that SOAP is going to become the de facto standard to send
data around, then thinking this stuff through is worthwhile. Choose
shame and get war: I guess that's my point.
Bill de hÓra
-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4
iQA/AwUBPM6JmuaWiFwg2CH4EQKiLQCglzbYr1ysmOdmYQjkn3coGjrfvSQAn0bb
pgTo1nrJT7sfwrF6CxRZV5Fx
=BGdW
-----END PGP SIGNATURE-----
