Let's face it: Most people out there still think of Objects and OO-RPC
over HTTP when they think about WebServices. Can't say I blame them: it makes perfect
sense if you're just use to the usual OO and procedural paradigms.
Unfortunately, I think we keep portraying this notions that help reinforce
that belief instead of dispel it; and one of those notions is the concept of a WebServices
proxy. Many tools (.NET included), put the ability to generate proxy classes from
WSDL documents as a first class notion of their WebServices support infrastructure.
Now, don't get me wrong, I believe it is a very useful abstraction,
and is certainly very practical. However, it reinforces the notion that WSDL services
map to classes (and thus to objects) and operations to methods, and thus that webservice
invocations correspond to method invocations on an object at runtime. It's hard to
look someone straight while telling them that RPC is dead and messaging is the way
to go, and then tell them how they can create proxy classes than "conveniently" hide
that aspect to make it look like you're doing RPC all over again. If it looks like
RPC and feels like RPC....
