Re: SOAP and the Web architecture

> If an arbitrary limitation of the software gets in the way of meaningful
> useful real-world uses then it is lacking a feature whether we call it
> broken or not.

I don't think it's arbitrary; implementations need to protect
themselves from overflow attacks, etc. Of course, if the world
decides that longer URIs are a good and useful thing, fine. However,
one of the ideas behind having HTTP bindings for SOAP is that it will
be able to use the existing infrastructure (re-use existant HTTP
stacks, and use HTTP for routing out of the firewall). If SOAP
suddenly requires something that a good part of that infrastructure
doesn't support, we lose a lot of value.



> > I.e., it's not enough to say:
> >   http://www.example.com/service?arg1=foo&arg2=bar
> > because one can't encode the entire range of SOAP envelopes possible;
> 
> It isn't necessarily the case that we have to support EVERY SOAP
> envelope. From a purist point of view I would advocate that. But from a
> practical standpoint, I would be happy with much less. I would like to
> not have to choose between SOAP and URIs for the sorts of things URIs
> are already good at (e.g. get me a stock quote, what's the temperature,
> please convert this currency value).

From SOAP's standpoint, something that is a transport binding HAS to
support every SOAP envelope. I'm not arguing that encoding the
request in the URI isn't a good approach for some uses; it's just
that it's hard to fit doing so into SOAP's model.


> > while this encoding happens to be good enough for RPC, it isn't
> > possible to encode anything more complex. That's not to say that this
> > approach can't be done; it's just that the request isn't SOAP.
> 
> It isn't SOAP as defined today. It can easily imagine a parallel
> universe where  method=mymeth&arg1=foo&arg2=bar maps into:
> 
> <SOAP:Envelope
>   xmlns:SOAP='urn:schemas-xmlsoap-org:soap.v1'>
>  <SOAP:Body>
>   <mymeth>
>    <arg1>foo</arg1>
>    <arg2>bar</arg2>
>   </mymeth>
>  </SOAP:Body>
> </SOAP:Envelope>

I like your characterisation of this as a mapping; I don't think it
can work as a transport binding, but perhaps as a convention to be
used in conjunction with what is effectively one-way messsaging (SOAP
envelope on the HTTP response). (just thinking out loud)


> > The way to do it would be to actually serialize the XML infoset as
> > URI parameters and/or query arguments. I.e.,
> >   http://www.example.com/service?*some XML Infoset serialisation*
> > In this manner, none of the expressiveness of SOAP is lost.
>
> That's another way but now you are trading off human-readability which
> is a major advantage of both URI's and XML (that's why we don't use
> UUIDs and ASN.1!). I think a=b&c=d would be a minimized format. The
> serialization would be an expanded one.

I don't disagree that this would be impractical and unfriendly; just
staking out the space.


> > Unfortunately, doing so doesn't gain the benefits that are being
> > looked for; because there are a number equivalent ways to encode a
> > message infoset in section 5, I think we'll find that the same
> > service in fact would have a number of different URIs, based on how
> > client implementations encode the data.
> 
> Just as there is a canonical XML, canonical Unicode, etc. there should
> be a canonical section 5.

Yes; well said. I'm no section 5 expert, but this would make life a
lot easier IMHO.


Cheers,


-- 
Mark Nottingham
http://www.mnot.net/

Received on Tuesday, 28 August 2001 16:37:47 UTC