Mark Little sent me
this link
to Bill de hÓra's
blog (now subscribed). Seems the concepts Savas and I have been espousing might not be too mental after all,
although I've never really thought of being upbeat before...
Matt Garland
argues
that:
"I cannot rely on a Web Service to implement
processThis or any other verb. In order to make such a guarantee, a
spec must define the minimally-acceptable interface."
This is a classical REST position I think - and it is quite wrong
from my point of view. Web Services don't actually have operations
in the sense that a HTTP server or an object does, that's why I said
Web Services support an imaginary method called something
like "processThis" through which messages are poked, using WSDL to
constrain the messages.
I contend that WSDL describes messages and message patterns
not operations or an API. I know the nouns in WSDL look like
they are defining an API per service, but you need to see past the
legacy wording. Do people use SOAP and WSDL to do RPC-like things?
Sure they do. People also use C# to write procedural programs. It
doesn't make it right in either case.
The bindings permit a mapping of the imaginary "processThis"
operation onto a specific mechanism in the transport protocol (since
SOAP is the transfer mechanism, everything else is transport). This
is what differentiates my view from the REST camp - I see the SOAP
envelope as the fundamental transfer mechanism, and aren't
interested in how the angle brackets get moved over the wire or
mixing transfer and message semantics together.
I'm really a big fan of just sliding documents between services
which is not vastly dissimilar from REST, but I believe in
decoupling the Web from Web Services.