> -----Original Message-----
> From: Paul Prescod [mailto:]
>
> Your report is interesting.
>
> One important thing to note: SOAP calls are not in any way guaranteed to
> be idempotent. Because XSLT is a declarative, not procedural language,
> you do not necessarily know how many times your XSLT will call the
> method. 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.
>
Actually, this is endemic to ANY mechanism that invokes code and is
fronted by an HTTP GET -- not just Didier's SOAP redirector.
He could just as easily be calling a servlet that issues JDBC calls
to update hit counters. Calling it a server bug isn't going to fix the
issue (if it's even broken). Sounds to me like Didier's work is a good
first step to redirecting HTTP requests into SOAP *and* addressing the XSLT
document load issue.
By the way, the entire ad-driven web-site industry practically depends
on a side-effect of GET -- namely modifying the log entries so it can be
counted. If one steps away from the canonical purity argument, I'm not sure
the GET vs. POST thing is worth losing much sleep over.
> 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.
>
> Paul Prescod
>
Hmm, could you elaborate on the last paragraph. I haven't heard anyone
mention anything about the short lifespan of SOAP/RPC...
Thanks,
Ramin
---
