Services and Objects
Steve Loughran makes a “declaration”:http://www.iseran.com/Steve/blog/archives/000117.html :Autogenerating a SOAP service from implementation classes is dangerously brittle against accidental change, and misses out on the flexiblity opportunities of XML
Sort of agree, but got me thinking. I think one of the major reasons why CORBA failed to take off was the lack of tool support… it was too da’n difficult to build and test (There are other reasons, but thats probably the subject of another rant). Imagine if Visual Studio had a CORBA wizard instead of an ATL wizard. The fact that one can now wrap existing classes in almost any language, from Java or C# to Ruby as a Web Service without much effort is probably the biggest indicator that Web Services use will be widespread. So I was wondering, does the roots of WS’s success contain the seeds of its own disctruction?
I sure hope not. And thats because I don’t think this is really a object vs xml issue. Its much more a object vs service design question. When people start designing for SOA, I believe much of this will be moot. Will people mess up on the way? You bet. Will some architects continue to design traditional objects? Sure. But once most architects “get” SOA, thats when you start thinking differently, and thats when it doesnt really matter if your WSDL is compiled into a class with methods. I am pretty sure that over the next few years, different ways of implementing the WSDL “contract”:http://www.sys-con.com/story/?storyid=44354&DE=1 will be developed. We can surely access the power of the XML-Schema without having to manually parse and create XML documents. In spite of that, Web Services will be worthwhile only if one starts to design for services, as opposed to objects. That’s a shift that has to be made.