Re: POST abuse?

Unlurking for a bit:

> SOAP could be a lot more addressability friendly if it would get rid of
> some of that magic stuff. If the SOAPAction were defined to be
> URI#methodname that would help.

The ambiguity in the SOAPAction declaration is something that has bothered
my about the SOAP spec for a while. The push here has basically been to
assume that this is an implementation detail, but realistically, I fear that
you may have with such an out the likelihood of seeing the same thing you
have with extensions in XSLT -- an inconsistent extension mechanism that in
turn reduces the interoperability of XSLT extensions. The fact that you're
seeing a movement like EXSLT emerge under the radar, so to speak, to me
speaks volumes about the fact that there really is a need for a consistent
declaration of XSLT. I think the same argument applies just as aptly to
SOAP.

> But the "cookies" and "handles" are going to be the real killer. We
> would have to strongly deprecate the use of those sorts of things if we
> want to maintain addressability.

Cookies are an attempt to push the state maintenance onto the client.
Realistically, multiple transactions in a process will need to maintain a
session token, but that session token should in all truth be passed back and
forth between transactions in the SOAP message itself. A long term
subscription services makes caching a transaction id necessary at the very
least. Still I'm not sure how such cookies or handles, if passed within the
body of the SOAP message itself, would necessarily place that much of an
onus upon addressability.

> The ResponseCache stuff is interesting. Evaluating XPath expressions
> seems quite expensive but I guess it is your business to worry about
> that, not mine. <0.5 wink>
I think this would be very  much processor dependent. I personally have been
advocating the use of XSLT as the primary router for SOAP messages. In
addition to making XPath expressions much less expensive (since you'll have
instantiated the XSLT library anyway), you can intelligently cache compiled
XSLT objects that would have a comparatively faster processing time that
un-cached XSLT, and perhaps faster than procedural languages only because
the expensive type mapping the WSDL does becomes less necessary.

-- Kurt Cagle

Received on Saturday, 25 August 2001 22:07:21 UTC