Steve Vinoski sent over the following comment on my previous article:

… WS-* is *not* preferable to REST. WSDL creates a tight coupling between the client and service which no amount of XML versioning can hope to alleviate. Code generation is brittle, can create unnecessary data definition dependencies, and inhibits extensibility. The industry has by and large learned this well over the past few years, which is why I mentioned 2004 in my blog about this. WS-* is practically dead.

WSDL and code generation try to give distributed systems the appearance of being local, ala RPC, only for the purpose of making the developer’s life easier, but in doing they create big problems. That’s why I mentioned 1994 and pointed to the “Note on Distributed Computing” paper, which covers this quite well.

You might want to read my latest IEEE Internet Computing columns on this topic, as those who don’t know history are doomed to repeat it:

Assuming you apply it correctly, REST is far, far preferable to what you’ve described…

Here are my thoughts…

Hi Steve,

Thanks for taking the time to write back. I appreciate it. I whole-heartedly agree with each of your points:

WSDL creates tight coupling, and this is bad.

Code generation is brittle, can create unnecessary data definition dependencies, and inhibits extensibility. All bad.

I know you’ve touched upon how REST is intrinsically more scalable than WS-*. I agree.

I believe my key failing here is that I failed to adequately explain the problem I am trying to solve.

I make embedded systems. More specifically, I make a device that can remotely reboot or power control a server in the same fashion as pressing the reset or power switch on the front of the server’s chassis. The device, named the WebReboot, can also measure the temperature inside a server, and tell you if the server is powered on or off. It’s core application is the remote recovery of crashed servers.

The interface for the WebReboot is tightly coupled to the hardware. We use a relay to control the power switch or reset switch of a server. We use a thermistor to measure temperature. The hardware has remained relatively unchanged for quite a long time, largely because it is simple, reliable, and cost-effective. Since the hardware has remained relatively unchanged, the interface has remained relatively unchanged. The extent of changes are limited to adding complimentary functionality that does not affect existing functionality (for instance, if I added a humidity sensor). In this scenario, I don’t think the tight coupling forced upon you by WSDL really makes you any worse off.

Scalability is largely not a concern for this application. In practice, it is not necessary to have many folks or systems trying to reboot a crashed server or retrieve a server’s temperature simultaneously.

Since my functionality is limited to what’s implemented in relatively simple physical hardware (e.g., sensors and relays), I’ve found limited application for complicated data structures and dependencies in controlling this hardware. I’ve also found limited application for extensibility. I’ve come up with many hypothetical ways for their application, but I haven’t found a need to use them. For these reasons, I haven’t in practice found the generated code for Java, Python, PHP or .NET to be brittle.

The biggest challenge we’ve had as a small company (< 10 people) competing in a large market (IT hardware) is competing with organizations that have significantly more resources than we do (Servprise was bootstrapped, and several of my competitors are public companies). One thing I noticed was that my competitors were largely offering stove-pipe solutions that were designed only for human operators to manually use. We decided from the get-go to make ease of integration a key selling point for the solution. This selling point has been the largest contributor to our growth.

There are two main ways our customers integrate our solution:

1) The functionality is made available in a centralized system for ease of access and control (e.g., a control panel at a hosting company).

2) Monitoring solutions, such as Nagios, that can tell you whether or not a server has crashed or a server is overheating, take automated recovery steps to either correct the problem or prevent escalation of the problem by sending commands to the WebReboot.

Our customers obtain financial benefits by making the relatively simple hardware functionality of our solution accessible in larger systems such as control panels and monitoring solutions. The problem for me was enabling this integration faster and cheaper than the competition.

Our competition, for the most part, chose the route of either developing and maintaining client libraries to manage communication to and from their embedded systems in Java, PHP, Python, etc., to ease integration for their customers, or left the customer to develop solutions on their own. I did not and still do not have the resources to develop and maintain client libraries for my customers. It’s code generation that has enabled me to compete on this level.

For my application, as well as numerous other embedded applications where the interface is tightly coupled to physical hardware, where the means of control on the physical world (e.g., physical relays and sensors, embedded systems) remain largely unchanged over time (it’s very cost-prohibitive to change), where scalability is not a major concern, and where capability and ease of integration are key selling points, WSDL and SOAP may be just what the doctor ordered, even if the only reason is code generation.

Clearly, those that put forth WS-* had much grander ambitions. I firmly believe REST is better suited for obtaining those ambitions. But I also believe this approach has a real future in making it easier and more cost effective for people to bridge the gap between software and the simple embedded hardware that enables control of the physical world.