W3C home > Mailing lists > Public > xml-dist-app@w3.org > June 2011

Re: SOAP and Cacheability

From: Graham Klyne <GK-lists@ninebynine.org>
Date: Thu, 16 Jun 2011 20:56:08 +0100
Message-ID: <4DFA5FD8.60207@ninebynine.org>
To: Yves Lafon <ylafon@w3.org>
CC: Dan Brickley <danbri@danbri.org>, Noah Mendelsohn <nrm@arcanedomain.com>, Unmesh Joshi <unmeshjoshi@gmail.com>, xml-dist-app@w3.org
FWIW, I've just spent a day at a meeting of scientific workflow users, and I was 
mildly surprised at how much emphasis there still is on WSDL-described services, 
which I think tends to mean SOAP or SOAP-like.  In this context, the typefulness 
of SOAP-style exchanges still seems to offer some advantages.

#g
--

Yves Lafon wrote:
> On Tue, 19 Apr 2011, Dan Brickley wrote:
> 
>> On 19 April 2011 16:56, Noah Mendelsohn <nrm@arcanedomain.com> wrote:
>>> My impression is that the major vendors aren't doing a whole lot to 
>>> enhance
>>> their SOAP stacks at this point, but I could be wrong about that. 
>>> More to
>>> the point, they seem not to have been convinced that the RESTful 
>>> variant was
>>> worth the trouble then, and since then there's been a lot of 
>>> deployment that
>>> just uses POST.
>>>
>>> Frankly, I think a lot of the use cases where one might have 
>>> considered use
>>> of RESTful SOAP are now JSON, and I'd be disinclined to fight that 
>>> trend.
>>> The pros and cons are ultimately somewhat subtle in principle (e.g.
>>> documents vs. just data), but in practice this is where everyone is 
>>> going,
>>> and mostly works, and for the data-only cases it's convenient. So, I'm
>>> doubtful much is going to happen on the SOAP side.
>>
>> Thanks, that lines up with my impression too, but I don't follow SOAP
>> so closely. A lot of the noise and excitement has moved on elsewhere,
>> but there must still be a lot of SOAP around... ...not to mentions
>> lessons to be learned.
> 
> We tried to provide real endpoints serving SOAP/1.2 using GET, namely 
> validators, see [1],[2], along with WSDL2 definitions. I know that it 
> has been used by third party tools, like browser extensions, but I would 
> bet that those are not using WS toolkits and are using the SOAP output 
> as plain XML. It amounts to roughly 70khits/day for the CSS validator.
> 
> [1] http://validator.w3.org/docs/api.html
> [2] http://jigsaw.w3.org/css-validator/api.html
> 
>> One reason to ask is that in the new RDF WG we have a chartered
>> deliverable around JSON (http://www.w3.org/2011/rdf-wg/wiki/TF-JSON)
>> and it's reminding me of the discussions from a while back around SOAP
>> Encoding, since both that and JSON provide a kind of quick and
>> convenient way of dumping and restoring programmatic objects without a
>> formal schema. Some of the same issues crop up: if Web services are
>> using JSON (or SOAP encoding) to talk to each other, how are those
>> structures best defined and documented?
> 
> Most toolkits are generating stubs from the XML schema type definition, 
> more than validating input in messages, and it led to discrepancy 
> between implementations and language used (see 
> http://www.w3.org/TR/xmlschema-patterns/ )
> There will be corner cases as well in the JSON world, even if it is 
> schema-less, but it might be easier to identify and fix discrepancies 
> than if there are toolkits involved.
> 
>> But I'm offtopic from the original query. Nice to see some traffic on
>> xml-dist-app though, http://lists.w3.org/Archives/Public/xml-dist-app/
>> plots the rise and fall of discussions -- things were last in double
>> figures monthly in July 2007...
>>
>> cheers,
>>
>> Dan
>>
>>
> 
Received on Thursday, 16 June 2011 22:16:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 16 June 2011 22:16:44 GMT