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.
Pages
-
Recent Posts
Archives
- January 2021
- December 2020
- November 2020
- February 2014
- January 2013
- December 2012
- June 2012
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
- February 2006
- January 2006
- December 2005
- November 2005
- October 2005
- September 2005
- August 2005
- July 2005
- June 2005
- May 2005
- April 2005
- March 2005
- February 2005
- January 2005
- December 2004
- November 2004
- October 2004
- September 2004
- August 2004
- July 2004
- June 2004
- May 2004
- April 2004
- March 2004
- February 2004
Meta