The Web Services Proxy Concept
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....
Yeah, I’ve been saying for a while that doc/lit as most people do it (i.e. the default ASP.NET stuff), is RPC is everything but name.
Have you thought about what a non-RPC programming model would look like (starting from WSDL) ?
I see your point about the temptation these tools create, but I don’t see anything fundamentally wrong with the mapping/serialization that I get with a strong development platform. Is navigating a DOM or issuing XPATH queries supposed to make me feel better? I guess I’m trying to understand what you would propose is better.
Of course I can understand your sentiments, Tomas. But perhaps – at least for the HTTP-branded moment – we should just make a difference between the messaging model and the programming model …? Doc/literal would make perfectly more sense with a real messaging infrastructure, i.e. with an asynchronous, decoupled communication layer. I like the idea of mapping SOAP over MSMQ. And then just use ‘bare’ SOAP messages ([SoapDocumentMethod(ParameterStyle = SoapParameterStyle.Bare)]
) – then we are a bit closer to what you are looking, I guess?
See url
Chris: I don’t think navigating the DOM manually is necessarily a better option, but I think something else, more closely mapped to messaging semantics, could be a better way. I’m not sure what yet, but I have some ideas I hope to explore soon!
Christian: Yes! That’s pretty much what I’m looking for!
OK, now that we are allowed to talk about it: just read Ingo’s comment on WSE 2.0
http://www.ingorammer.com/weblog/archives/001293.html
I posted some comments in my weblog here:
http://www.thearchitect.co.uk/weblog/archives/2003/06/000173.html
- Jorgen
I think proxies are still useful to invoke web services to allow an easy programming model that facilitates the serialisation and transmission of service invocations. What we must not expect is to get back an answer while the code that invoked the service is alive, i.e. the proxy should not wait for a service reply. In fact you would need to restrict the proxy possibilities to everything you are allowed to do when invoking COM+ queued components.
How than can a service consumer handle response messages? The service consumer will have to be a service himself, offering operations that the service provider can invoke to communicate back results of the original service invocation.