SOAP and Cacheability

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

SOAP and Cacheability

unmesh_joshi
Hi,

One of the key features of HTTP which help it scale at internet level
is ability to cache responses.
There is decent amount of caching facilities built into standard and
well understood by web infrastructure.
Because SOAP uses HTTP as one of the transport protocols, it can not
get benefit of any of these caching mechanisms.
If cacheability is to be provided, it needs to be built by application.

Was there any plan to build caching facilities at SOAP protocol level
which could be understood by SOAP processing agents?

Thanks,
Unmesh

Reply | Threaded
Open this post in threaded view
|

Re: SOAP and Cacheability

Noah Mendelsohn
The SOAP 1.2 specifications added features to allow use of
application/soap+xml as a media type with HTTP GET as well as POST;
unfortunately, those features were as far as I know not supported by the
major implementations, and so are not in practice available to users. Had
GET been supported, then HTTP caching should have worked in the normal
manner, and indeed that would be one reason for supporting and using the
feature.

Noah

On 4/15/2011 12:25 AM, Unmesh Joshi wrote:

> Hi,
>
> One of the key features of HTTP which help it scale at internet level
> is ability to cache responses.
> There is decent amount of caching facilities built into standard and
> well understood by web infrastructure.
> Because SOAP uses HTTP as one of the transport protocols, it can not
> get benefit of any of these caching mechanisms.
> If cacheability is to be provided, it needs to be built by application.
>
> Was there any plan to build caching facilities at SOAP protocol level
> which could be understood by SOAP processing agents?
>
> Thanks,
> Unmesh
>
>

Reply | Threaded
Open this post in threaded view
|

Re: SOAP and Cacheability

Dan Brickley-2
On 19 April 2011 15:13, Noah Mendelsohn <[hidden email]> wrote:
> The SOAP 1.2 specifications added features to allow use of
> application/soap+xml as a media type with HTTP GET as well as POST;
> unfortunately, those features were as far as I know not supported by the
> major implementations, and so are not in practice available to users. Had
> GET been supported, then HTTP caching should have worked in the normal
> manner, and indeed that would be one reason for supporting and using the
> feature.

You talk in the past tense; is it too late to hope that SOAP toolkits
bit get a bit more Webby?

Dan

(who always liked idea of SOAP messages as Web documents,
http://lists.w3.org/Archives/Public/xmlp-comments/2002Jul/0060.html
...)

Reply | Threaded
Open this post in threaded view
|

Re: SOAP and Cacheability

Noah Mendelsohn
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.

Noah

On 4/19/2011 9:39 AM, Dan Brickley wrote:

> On 19 April 2011 15:13, Noah Mendelsohn<[hidden email]>  wrote:
>> The SOAP 1.2 specifications added features to allow use of
>> application/soap+xml as a media type with HTTP GET as well as POST;
>> unfortunately, those features were as far as I know not supported by the
>> major implementations, and so are not in practice available to users. Had
>> GET been supported, then HTTP caching should have worked in the normal
>> manner, and indeed that would be one reason for supporting and using the
>> feature.
>
> You talk in the past tense; is it too late to hope that SOAP toolkits
> bit get a bit more Webby?
>
> Dan
>
> (who always liked idea of SOAP messages as Web documents,
> http://lists.w3.org/Archives/Public/xmlp-comments/2002Jul/0060.html
> ...)
>

Reply | Threaded
Open this post in threaded view
|

Re: SOAP and Cacheability

Dan Brickley-2
On 19 April 2011 16:56, Noah Mendelsohn <[hidden email]> 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.

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?

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

Reply | Threaded
Open this post in threaded view
|

Re: SOAP and Cacheability

Yves Lafon
On Tue, 19 Apr 2011, Dan Brickley wrote:

> On 19 April 2011 16:56, Noah Mendelsohn <[hidden email]> 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
>
>

--
Baroula que barouleras, au tiƩu toujou t'entourneras.

         ~~Yves


Reply | Threaded
Open this post in threaded view
|

Re: SOAP and Cacheability

Graham Klyne-4
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 <[hidden email]> 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
>>
>>
>