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.

4 responses to “Modeling Web Services using OO and moving on”

  1. enric jaen villoldo

    I like to see the advantages and disadvantages of new technologies. When I learnt about

    WSDL I asked myself: what does it have WSDL that is better than previous interface

    description languages,say CORBA IDL?… The advantages I saw is that is XML-based (from the machine perspective), and that supports multiple bindings. Regarding the interactions patterns.. IDL also supports asynchrnous interactions. But WSDL has also disadvantages: verbosity, interoperability, lack of data retrieval support, lack of application protocol information.. I think an IDL approach for modeling web services may help on this.. so. why don’t to integrate the advantages of both WSDL and IDL? That is the purspose of WSODL.. My approach is not just about web service implementation, but about web service design,

    modeling, building and deployment.. therefore I think it may of interest to the web service community.. I hope so 🙂

  2. To answer one of your “questions” in your post: “Can we use domain-specific vocabularies to declarative describe contracts (e.g. SSDL, WSDL)”

    This is exactly what we are working on at the moment. Writing a DSL for designing services. In other words describe the contract of the service and generate the WSDL for it. All of this in an early stage but more features to be added….

    edward

  3. Savas,

    This is a bit of the topic. I am interested in your take on the convergence of Grid Computing with Web Services (Grid Services) and how that relates to the REST/MEST paradigm. Do you see REST/MEST as relevant to Grid Services?

    cheers

  4. I didn’t take “OO sucks” seriously – you do a good job of putting this all into perspective.