axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: SOAP 1.2, GET, and Axis
Date Sat, 06 Jul 2002 05:50:10 GMT
Vacation over, I've finally sat down and looked at the 1.2 specs. I quite
like the graphing stuff in the datatypes, but GET and URIs in general worry
me. I have a fear that they were put in at a late period to satisfy the TAG.
Anyhow, here are my thoughts, at a higher level than code changes. Overall,
I'd consider not worrying about SOAP1.2 till after Axis 1.0 ships, unless
there is some show stopper here that invalidates all the work people have
done so far.


1. I have nothing against REST; i think an object model for
things you are talking about is higher level than a pure RPC model that
XML-RPC and early SOAP offered. But I do think async message based
communications may be a better model for internet scale distributed apps
(that or tuple-space), than blocking synchronous calls, and that a way
for callbacks may be a good thing if treated with care.

2. I am still on a sabbatical from HPLabs, but I do believe in the
cooltown 'give physical objects URLs', ethos, and were I back in HPLB I
would probably not be too organisationally distant from the RDF group,
or indeed Stuart 'skw' Williams. So while I am stating my own opinions
here, nothing to do with HP's opinions, I dont want to offend people
I know either.


"RESOLVED.The TAG finds that the absence of a GET binding in SOAP is
incompatible with the architecture of the Web, in that it contravenes the
architectural principle that important information resources should have
URIs. The TAG appreciates the urgency in completing the SOAP 1.2
specifications and wants to work with those concerned to address this
problem with the least disruption possible." [1], citing something else.

Use of GET for idempotent, side effect-free queries is strongly pushed.
OK, but how to control the caching of this? We should return cache
headers to say never cache the responses, because any side-effecting
operation applied to the same object will invalidate the cached values.
And if we say cache-never, then where are the benefits of cache, eh?

The other issue with GET: how to include soap headers in the message. If
you cant then how is state handled? Its either cookies or URLs. Cookies
are clearly weak, though level routers can at least handle them. URL
based state isnt secure on its own, so you have to have cookies too.
This results in your code being tied to the transport, if you are not

...6.3 says of the SOAP Response Message Exchange Pattern

"This MEP cannot be used in conjunction with features expressed as SOAP
header blocks in the request because there is no SOAP envelope in which
to carry them"

So they know the problem, but that doesnt stop it being aggressively
pushed further up. The consequence of the adoption of GET is that a lot
of the stuff you can think of doing with SOAP headers goes out the
window. Given this comes from the W3C, perhaps they could consider
adding support for arbitrary XML headers in a GET request; then it would

Axis implementation thoughts:

 -even if support for GET gets implemented server side, we should
  strongly discourage it because it is so limited.

 -we could let people enable GET requests to their methods in the metadata,
  but require them to specify caching behaviour when they do so. Or default
to no cache.

 -if someone says GET to query, does that become the only way to make
  that request?

 -how do we describe this in WSDL?


"The specification now makes clear that information needed to identify
SOAP resources should be in URIs where practical, regardless of whether the
operation is GET or POST, or whether SOAP RPC is being used." [1]

SOAP1.2 pushes explicit use of URIs. But some of the examples here are
almost repeats of the SoapAction header issue: if content is duplicated
in the body of the message, then you have to deal with differences
between header and body. A zero duplication model is less brittle.

If the URI used to direct a SOAP call only included the endpoint, and
no extra request parameters, then there should be no duplication.

Axis implementation thoughts:
 -I dont think we should support parameters in a POST, not when they are
  also in the body. I dunno if you can do that and still be called
  SOAP1.2 conformant; it depends on the tests.

 -we need to make it easy to add and delete endpoints for a more dynamic
  model; only .NET remoting does this well today.

 -how can you describe in WSDL a method that returns a uri that acts as
  an endpoint for a known schema. I.E. can you do compile time type



View raw message