Hello Paul,
Paul said:
> One important thing to note: SOAP calls are not in any way guaranteed to
> be idempotent.
Didier replies:
And an HTTP GET also. If you access the Moreover service with an HTTP GET
and a URI containing parameters, then it is not idempotent[1]
Paul said:
> Because XSLT is a declarative, not procedural language,
> you do not necessarily know how many times your XSLT will call the
> method.
Didier replies:
It depends on how the protocol handler is implemented. If it is synchronous,
then it will wait that the document is delivered to provide the result to
the client (either a browser or an XSLT processor). Also, I am not sure if
this is what you mean and your comment confused me but for a given SOAP
call, if I invoke a SOAP server with the same URI I get the same result.
Thus, no problems of local side effect (within XSLT) since:
a) the implemented protocol handler is synchronous
b) A particular URI will leads to the same result as would do an HTTP GET
with parameters (according to the indempotent definition below, an HTTP GET
with param is not idempotent since I won't obtain the same result if I
change a param's value).
So, no problem it will work fine with an XSLT processor if based on premises
(a) and (b)
Paul said:
> If the method has side effects then depending on the engine you
> use you may find that the methods are called in different orders or even
> different numbers of times. With HTTP you know that anything that can be
> GOT is intended by the HTTP specification to have no side effects. If
> there ARE side effects that is a bug in the server, not in either your
> XSLT transformation or your XSLT engine. So in general I do not think
> that this model is really a safe way to deal with SOAP services.
Didier replies:
It is not necessarily true that an HTTP GET has no side effect if this
latter refers to an executable/script/server extension receiving parameters
and performing an action (i.e. a procedure) on the server side. And on the
other hand, it is not necesarily tru that it will lead to side effects on
the client side (i.e. XSLY processor) if implemented in such ways that the
protocol hanlder operates as a synchronous transaction (i.e. wait until task
completion). In that sense, a SOAP call is not better or worse than an HTTP
GET invoking a CGI process or a script.
So in an etherized world, an HTTP GET is idempotent (off course, if the URL
is unique with no implicit variation in the parameters) but in reality, an
HTTP GET having parameter may potentially have a high variance factor . in
the case of 4 parameters and each parameters taking 4 values you already
have a lot of possible combinations. This could be perceived as for
different resources if a resource is associated to a particular charactyer
sequence composing the URI, or could be perceived as different facets of the
same resource identified by the invariant part of the URI.
So SOAP is not more or less safe than HTTP GET based queries.
For instance the Merkaat service[2] will send you back different documents
based on the "_fl" parameter. This parameter can takes at least 6 values.
Then the following two URLs lead to a different result but may be
interpreted as an interaction with the same abstract resource (dependent on
you mental model about what is a resource).
a) http://meerkat.oreillynet.com/?_fl=rss
b) http://meerkat.oreillynet.com/?_fl=xml
Since the character sequences are different in the two last URLs we can say
that they are different and we may expect to obtain two different results.
We may also adopt a phenomenological reasoning and say that the two URLs are
two facets of the same resource. We are simply interacting with the same
object/resource with two different intentions. The resource being identified
by soap:merkaat.oreilleynet.com and the facets by _fl="rss and _fl=xml. Or
we may infer that the resource is what we obtained as result. It all depends
on our mental model about the resource concept.
On the other end, if Merkaat where to be accessible through a SOAP call we
would access it with the soap URI like:
a) soap:merkaat.oreilleynet.com/soap_service?get_document("rss")
b) soap:merkaat.oreilleynet.com/soap_service?get_document("xml")
I do not say that one is better than the other, I am just illustrating that
a soap URI could be not more or less idempotent than a URL. In fact, to
refer to Tim's existential questions about APIs, we can perceive an HTTP GET
with a URL incorporating parameters as an API interface, idem for a soap
URI. Both are hiding the sequence of operations performed on the server side
and offer an abstract view of the remote process. The URL and soap URIs are
an interface to a black box. Parnas and al. demonstrated that we reduce
complexity by using this kind of abstraction.
So, in the last two soap URIs, since the character sequence is different in
the two URIs we can adopt the same reasoning as for the URLs. a) adopt a
phenomenological reasoning and see two facet of the same resources. The
resource being identified by soap:merkaat.oreilleynet.com/soap_service and
the facets by get_document("rss") and get_document("xml"). Or we may infer
that the resource is what we obtained as result. It all depends on our
mental model about the resource concept.
If - and I said that I need to do some more work on that - the protocol
handler strip all the SOAP protocol overhead and provide to the client (i.e.
either a browser or an XSLT processor) the returned data. If this returned
data is a RSS or another xml flavored document, then the browser may display
it or the XSLT processor may process it as it would do with the URL.
See, not more or less indempotent.
Moreover, we can say that any parameter - part of a URL- could be a
process/procedure/function identifier. Since there are no conventions about
the expression of a particular process/procedure/function identification,
then we can infer that the soap URI is offering a more disciplined
indication of what is the function and what are the parameters. However,
since the soap URI inherits the characteristics of the ECMAscript function
calls, then the strict ordering of the parameters may be perceived as too
much restrictions by the creative minds :-). In that sense the URLs offer
more variance and freedom of choice in their placement within the URL. The
creative minds can even have more fun by creating a lottery named "bet which
parameter is the function call!" and even get a secondary benefit of a new
but illegal revenue stream :-) :-)
Paul said:
> Another thing is that many SOAP advocates say that most real-world SOAP
> services will NOT use the SOAP RPC conventions. This means that your URL
> construct will not work with them.
Didier replies:
No necessarily, I just demonstrated it would. this is why I created a
prototype in my lab: to discern fantasy from reality and learn more about
the 21st century virtual worlds we are creating (funny to see that
virtuality has now become reality :-). For this experiment my masters are my
Grand Pa, Karl Poper, Bacon, Edmund Husserl, my daughter (she is 6 months
old and very very curious) and Edison :-)
[1] f (f x) = f x for all x in D.
I.e. repeated applications have the same effect as one. This can be extended
to functions of more than one argument, e.g. Boolean & has x & x = x. Any
value in the image of an idempotent function is a fixed point of the
function.
[2] http://www.oreillynet.com/pub/a/rss/2000/05/09/meerkat_api.html?page=3.
