A colleague of mine was working with a .NET client connecting to a .NET web service. The web service basically looked up images given a key value and the data was downloaded back to the client. He used a C# struct on the server side that contained the name of the image and the binary data. He also had a couple of methods defined in the struct, and he was expecting these methods to be exposed on the client end.
What can I say? In other RPC mechanisms, like CORBA and (D)COM, you can pass object references back and forth. You can invoke methods on those objects, and the architecture makes the remote call transparently. So I do not blame my colleague for thinking along the same lines.
When I explained to him that it’s the SOAP protocol that does not support object references like that, it was clear to him that he needed to adjust the structure to be plain, data-oriented structures.
The fallacy that SOAP & the web services architecture is object-oriented really bugs me. The fact is it’s about as object-oriented as the C-language. It’s just a method of RPC. Just like IIOP in CORBA, DCE-RPC in (D)COM, or RMI in EJB, but it is very verbose and clunky.
Many proponents of SOAP tout that since SOAP is XML, it can be human-readable. Why in the world would a human would want to read an RPC message? Other proponents state that SOAP can be recreated by any client, making it very usable by third parties. OK. I could have easily created a IIOP message or a DCE message in binary. The purpose of RPC architectures is to abstract all of those nitty-gritty details and let me create remoteable objects fairly quickly. I admit that the .NET framework does do that well, but XML under-the-covers still is a waste of bandwidth and processing time.
The last advantage that the SOAP gurus throw down our throats is the fact that SOAP is over HTTP and port 80, making it very web friendly. OK, I’ll admit that, but with some caveats. If I want to expose an API for third-parties to that will help integrate their products with mine, it makes sense. However, implementing web services as a middleware replacement for COM, EJB, or CORBA is simply distributed-computing suicide.