Modeling Web Services using OO and moving on

Here we go again. I started writing this as a comment-response to Enric‘s comment in my ‘OO Sucks’ post but it got too long so I thought of posting it as a separate entry.

I have no problem with OO but I am always in favour of using the right tool for the right job. In fact, all my PhD work was done with C++ and all my work here in Microsoft is done with C#. OO is great as an implementation technology for services (although I really like functional programming as well). The ‘OO Sucks’ post was just a reference to something funny. Don’t take it too seriously Enric.

I don’t want to start another long discussion on this but I may not be able to avoid it. It’s probably already known to most of you that I personally don’t think the application of the principles of object-orientation at large-scale works. Please note that I am talking about the true object-oriented paradigm and not doing service-orientation using OO technologies. CORBA and DCOM started introducing ‘services’ because those involved realised they had to go coarse-grained at some point if they wanted to scale; they started introducing registry services, dynamic binding, brokers, etc. Garbage collection doesn’t work at large-scale. One can’t just make all of the entities in the system network-addressable (the pure OO way) because of the resulting fine-grained interactions over the network. One has to start passing things by-value at some point if scalability and loose-coupling are important properties of the architecture. The more coarse-grained one becomes, the less assumptions one makes about the partners in the interaction, the closer they are to the service-oriented paradigm.

And then, we start thinking about the network and whether we should hide it behind programming abstractions like methods or procedures, we start thinking about the coupling of messages in request-response patterns (remote method invocations) and whether we truly need them in all situations, we start considering whether a common type system is better than a common information model (i.e. XML), etc. We are thinking of the Web and the “software as a service” approach to contemporary distributed application design and then it hits us… distributed OO is so 90s 🙂 Also, we shouldn’t confuse the programming model used to implement Web Services and the architectural paradigm used to implement service-oriented solutions. We should all worry when we start seeing any programming abstractions leaking into the architecture. I think that’s bad ™ 🙂

I had a look at Enric‘s slides. The word ‘transparent’ appeared many times. Waldo tried to tell us something about that 🙂 IMHO, I think there are other things that are not accurate in Enric’s presentation but I’ll leave it for others to comment.

Finally, I feel that we’ve exhausted the OO vs Service-Orientation topic. It’s time to move on to other, more interesting things. Here’s an idea or two… We have embraced the Web as a way to make information available to the world. We have built search, retrieval, and presentation solutions for that information. We are now using the Web to build service-oriented solutions. We are already starting to see examples of the Web – as a platform – being embraced within the enterprise. Here are few questions for all of us to consider… How can we support the next generation of application lifecycle in this new, Web-driven technology world? How can we design, build, test, deploy, maintain applications in this new world of distributed services? How can we enable the next generation of service-integration (e.g. mash-ups). Can we do this using declarative means? Can we use domain-specific vocabularies to declarative describe contracts (e.g. SSDL, WSDL), policies (WS-Policy), other things? How can we combine REST (resource-orientation) and MEST (service-orientation) to support new, interesting distributed applications? These are the topics we should be discussing in the blogosphere and not what would have happened if MS had supported CORBA.