WS Time Warp?
March 21st, 2008 | Published in distributed systems, REST, WS-* | 7 Comments | Bookmark on Pinboard.in
Either it’s suddenly become 2004 again, or somebody didn’t get the memo. It’s hard to choose where to begin with this one — hmm, maybe this little tidbit:
Now here’s the absolute coolest part (at least in my opinion). Armed with the WSDL document, you can use freely available, open source tools to automatically generate stub code to send requests to and receive responses from the SOAP web service in just about any modern programming language of your choosing.
For both the client and the server.
The stub code generates and parses all of the XML. As a developer working in the language of your choice, you are completely abstracted from the sending and receiving of data on the wire.
I guess I was wrong; it’s not 2004, it’s 1994.
March 21st, 2008 at 2:24 pm (#)
It’s probably a prank. The guy is called “von Wallenstein”, and everybody of course knows that Wallenstein was the General of the conservative/reactionary reconstitution of Catholic faith in the 30 years war – very much to the point ;-)
cf.
http://en.wikipedia.org/wiki/Albrecht_von_Wallenstein
http://en.wikipedia.org/wiki/Thirty_Years%27_War
March 21st, 2008 at 2:59 pm (#)
Oops! Thanks for pointing this out.
“As a developer working in the language of your choice, you are completely abstracted from the sending and receiving of data on the wire.”
Should read…
“As a developer working in the language of your choice, you are completely abstracted from THE CREATION OF THE CODE FOR the sending and receiving of data on the wire.”
Without that, you’re right! Straight back to ’94. Thanks!
March 21st, 2008 at 3:02 pm (#)
[…] the sending and receiving of data on the wire (I had a gross omission here… thanks owed to Steve Vinoski for pointing it […]
March 22nd, 2008 at 6:07 pm (#)
[…] 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. […]
March 22nd, 2008 at 6:10 pm (#)
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).
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 I’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 I 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. I decided from the get-go to make ease of integration a key selling point for my 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 physical world.
March 29th, 2008 at 12:28 pm (#)
Is it very hard for average developers to understand and implement REST instead of using WSDL in systems where everything traditionally works based on WSDL ? Seems so. It really looks like something that only experts can do. Can you prove otherwise ?
March 29th, 2008 at 2:44 pm (#)
Mohan: you ask whether can I prove otherwise? I don’t know; can you prove that what you claim above is true?
I can say that in my experience I have explained REST to a variety people who’ve never worked with IDL or WSDL, and they don’t seem to have any problem understanding it. I’ve explained it to others who have worked with IDL and WSDL, and while they don’t always get it right away, they do get it if they’re able to put aside their IDL/WSDL assumptions. The ones who can’t see past IDL or WSDL, of course, never get it, but I think one can safely argue that they don’t really try to.
Also keep in mind that “difficulty” is a concept that ranges beyond the initial work a developer has to do to write the system. It might be easier in the short term for someone to write an interface in a definition language and push a button to generate code to create a system, but the resulting generated code is brittle, hard to version, hard to scale, and hard to update across the system in a piecemeal fashion.