Why We Need SO Tooling

An interesting discussion is underway at the Yahoo SOA Forum about the relevance of object oriented (OO) tools to service orientation (SO).
This kind of discussion illustrates why we sponsor the SOA Tools Platform Project at Eclipse, working together with IBM, Sybase, and others to create tooling better suited for SOA than tools based on UML and MDA.
One of the participants in the discussion, Stefan Tilkov, and I have discussed this previously in earlier blog posts (ref1 and ref2). And one of the forum participants, Lukas Barton, referenced a thesis he wrote about MDA in his post, including some perspective about the disconnect between OO and SO with respect to tooling.
Some things have changed since the original discussion, but as far as I can tell UML and MDA still have not been adapted away from object orientation toward service orientation. It still looks to me as if the UML and MDA based tools want you to derive your WSDLs, XML Schemas, and SOAP messages from objects rather than the other way around.
Certainly you can use UML to create services – as has been mentioned many times you can really use any technology, including procedure oriented technologies such as COBOL or PL/I or stored procedures, or asynchronous messaging systems. And SO is abstract enough to encompass them all, which is one of its main benefits. You lose some of that when you tie SO too closely to OO.
For IT software, OO concepts can often create more problems than they solve. (Implementing services using objects, procedures, queues, etc. is ok but let’s not design them that way.) It is much better to model, design, and develop using services natively since they map more cleanly to business functions. If you have to design and model your functions first as things (i.e. objects) you are introducing unnecessary complexities, and often the industry ends up trying to resolve unnatural and impossible mappings such as OO-Relational and OO-XML (impossible to do automatically or transparently I mean).
Software tools need to improve the level of abstraction. MDA and UML do not really do this since they expect us to first learn how to reinterpret the world of functions into objects with methods and only then think more abstractly about services. What we need is a good set of contract-first SO tools specifically designed for SOA that natively support the service abstraction, whether the implementation is OO or not.

Advertisements

One response to “Why We Need SO Tooling

  1. Is SCA to SML what SOA is to ITIL?

    I very much agree with

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s