In a previous post, I said that we need to do away with object access protocols.There are two reason why I think that this is essential.
Firstly, we must recognize that network based services behave differently from objects. They suffer from different constraints. For example, it is not possible to “instantiate” a new instance of a network based service whenever the client acquires a “new” object of the service type. And there are other obvious differences; such as the expense of making method calls over a network as compared to making method calls on objects residing in local memory. Considering these sharp differences, it makes sense to me to treat “the service” as a different kind of animal altogether.
The second reason is the complexity of an all inclusive message format.
(more…)
Categories: SOAP · service orientation
This is not about SOAP vs REST. Nor am I an authority on SOAP. It’s just that I’ve been through enough pain with SOAP and I have gotten past the need to rant. This post is about where I believe SOAP went wrong.Soap stands for Simple Object Access Protocol, we know. They tell us it is simple. But they also tell us it is an object access protocol. I think that the latter contradicts the former.Now if SOAP could drop the object from it’s name, it would simplify things a lot. In fact we would get Simple Access Protocol, which is HTTP. What’s wrong with using HTTP instead of SOAP? This is an invalid question, to be answered in a few days.An object access protocol involves serializing messages and sending them to a remote object listening over a network. The object responds to those messages in some appropriate way. Everyone has his own ideas and views about how messages should be serialized. Yes. Every platform.
(more…)
Categories: SOAP · service orientation