Simpler is not always better

It doesn’t appear to be one of Murphy’s Laws, but it should be:

  • If a technology can be abused, it will

This of course applies to Web services as much as anything else. And perhaps more so, since they are relatively new, and you could say the industry is really still in a kind of “trial and error” period with them.
The biggest abuse of Web services tends to derive from “simply” enabling existing objects and programs. Most Web service toolkits allow you to quickly and easily generate a WSDL representation of an object or a program, but of course the tools cannot tell you whether or not that’s the right thing to do.
While I was in London the week before last I visited a former colleage, now working for an online gambling company. He was telling me about the problems they had in maintaining their Web services, since they had automatically generated them from Java beans. Although it was much simpler initially, it turned out to be more difficult in the long run since each time a change was required to a Java bean, it necessitated a regeneration of the Web service interface, typically introducing incompatibilities to the service requester.
Many articles and blogs have been written on this topic, including some great entries (and links) from Steve Vinoski here and here.
Web services are not the same as Java or CORBA or VB. They are interfacing technologies and are not executable. The debate seems to center on whether it’s better to design the object first or the interface. In reality this has to be an iterative process, but one of the most important aspects of Web services is that they are independent of execution envioronment, which gives more weight to the interface, or contract first approach.
In addition, when considering the use of an SOA, it’s of critical importance to design the services and their accompanying architecture independently of technology. The services must first of all meet the needs of the business, and second of all are the technical considerations of implementation.
If you base the design of the any language-neutral interface on a specific technology you risk losing the main benefits of interfacing them. What may be simpler for the developer is not necessarily simpler for the consumer.

Advertisements

5 responses to “Simpler is not always better

  1. Eric, This is similar with any new technology adoption. Users tend to do the quickest possible thing (for whatever reason, be it time or cost or understanding) and not absorb the idioms of nature of the new technology.
    I remember helping an Orbix customer out who had designed mapped every object in his system in a remote CORBA object. It was not fun trying to fix that problem (we used smart proxies, but that is another story;)
    plus ca change.
    however, SOAs give a great oppurtunity to designthese technology implementation independent solution, however due to a number of factors, it is difficult to design these, let alone implement and deploy them. Our toolsets and mindsets are still bound to the implementation paths.

  2. Aman,
    You are right. This is perhaps one reason to favor the REST approach since it forces the developer to deal with the XML.
    One of the reasons I support SOAP (and the WS-* stack, at least generally) is that it provides more help to developers in mapping the XML into programs and objects. It seems like REST is just too simple, and forces too much work on the developer.
    I wrote a while ago about how maybe it’s best to use the doc literal style of Web services for everything:
    http://www.iona.com/blogs/newcomer/archives/000041.html
    But maybe this doesn’t go far enough…
    Eric

  3. I was not advocating REST, by no means. The WS-* stack provides a lot more, and is addressing a different set of problems than REST.
    My main point was the fact that a lot of decisions made when implementing a web service or anything is limited outside of the technological capability of the toolkit being used or the programmers/designers implementing them (many things constrain these limitations, but to be kind, let us just admit they exist). Its similar to when OO became cool and accepted, I found a lot of people whom I spoke with and worked with had trouble with encapsulation (either making members public, or excessive use of accessors/mutators, and not getting the object to the work, they would get the caller to set the state in the used object). The other advantages of OO were not really used (like polymorphism); now, I think, encapsulation is seeping in; we may be seeing some of the other features like polymorphism and loose coupling coming to the fore.
    I think a major reason why these concepts are not readily embraced or implemented and the use of the techniques you describe are down to tool support — measuring loose coupling is hard to do through an automated tool. The closest we have is measuring technical debt, http://c2.com/cgi/wiki?EliminateTechnicalDebt . Which is what is being shown above…
    The problem with document/literal style is the subtlety — the operation name is not identified.
    I prefer explicit styles so you can see what is happening (this is one of the reasons I do not
    Like overloaded operators and overloaded function names). However, the article mentioned by
    Your posting above, is dealing with this at a wsdl and/or protocol level, which is something the
    Developers normally would not be exposed to.
    The doc/literal style has some good things and as mentioned by you and others is a good way to
    Encourage (1) loose coupling and (2) a break from the implementation. It is interesting that the problem you cite above is due to the automatic generation of the web-services interface from java beans. In my experience, it is very rare for these tools to pay off; I have not seem them to be of benefit from data mapping or idl type systems. They are fine for quick prototyping OR when used cautiously.
    Namely, the implementation of the webservice has to identify an interface layer outside of the normal objects used by the core system being developed. Then these tools pay dividends. The key is writing the interface independently of the system being exposed. That allows the benefits of growing a system or adding what is needed. Microsoft’s approach in .net of using the WebMethod attribute *http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbconcodemodelforwebservicesinmanagedcode.asp ) is a good way of doing it as it forces the developer to think about the operations being exposed and you do have reasonable toolset support.
    Interestingly, Woolfe has an entry in his blog today about (http://www.ibm.com/developerworks/blogs/dw_blog_comments.jspa?blog=392&entry=92302&ca=drs-bl ) recommending the use of stateless session beans as the way into the system, and it is pretty handy to get the java toolset to generate the web service part, similar to the asmx/WebMethod approach above.

  4. here’s an article on the badness of overloading that I meant to include above, and is applicable to the doc/literal point as well in that it is good to make things explicit, we must avoid “Syntactic Heroin”
    http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=315

  5. Yes, I agree the Microsoft approach in the new Visual Studio, to explicitly mark a program as a service, is helpful. Unfortunately they also hide the WSDL away in a subdirectory after it’s generated so the design artifact remains the program rather than the interface.
    You very eloquently make the point that the interface needs to take the leading role with the program or object as a supporting cast member.
    And while using stateless beans is indeed a step in the right direction it remains the wrong artifact to focus on. I don’t think it’s a good idea to design a service using a Java bean, a C# program, or whatever. Services need to be technology independent – they need to map to the business service first of all, and to the executable software environment second. People have to stop thinking about designing the executable environment to match the business. The business function needs to be the thing that’s reflected in the service interface, not the execution environment.
    I think it is also helpful in this context to focus on the data being exchanged – what data does the service need in order to execute? What data does it need to return to the requester? Only when this is worked out should we be even thinking about touching executable code artifacts.
    Eric