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.