This post originated from an RSS feed registered with Java Buzz
by Chuck Hinson.
Original Post: WSEC
Feed Title: Chuck Hinson
Feed URL: http://chuckhinson.blogspot.com/atom.xml
Feed Description: Observations, questions and musings related to my life in the software industry.
So, earlier I had said that I wasn't really interested in going to the W3C Web of Services Workshop. It ended up that someone else couldn't go, and since I was curious to hear reactions to some of the stuff being presented on day 2, I decided to go ahead and go.
I'm glad I went. There was a lot of good and interesting discussion. I don't think any of the world's problems were solved and I don't think anybody changed their minds about Web Services - although there did seem to be a lot of agreement that REST is good and worth investing time in.
One of the recurring topics was the uniform interface - it seems some people get it and others don't. It always seem to end up in an argument about dispatching - either you do it at the operation level or you do it at the message type level. If I define operations, they're strongly typed and I know exactly what kind of data I'll be getting. If I only have one operation that has to handle different kinds of data, then how do I know what to do with the data - I have to write a big if-statement to figure out how to handle the data. How is that an improvement? Arent you just pushing the dispatching to a different place?
And that's the wrong thing to focus on. I stumbled on this as I was trying to explain to my very dyed-in-the-wool WS-* coworker why the uniform interface is useful. I finally made progress with the following.
Imagine I have a printer with an embedded web server. The printer makes available a web service with associated WSDL that define an operation called getPrinterStatus, and that operation returns an xml document of a type we'll just call DeviceInfo. If I'm writing a client to retrieve the printer's status, I pull in the WSDL generate the stub code and fill in the business logic. Now I can monitor the status of the printer.
Now imagine that some time later, I purchase a copy machine. This copier also has an embedded web server and makes available a web service. The web service has a number of operations, but one of them is getDeviceInfo, and that operation also happens to return an xml document that has the same format as what the printer returns - DeviceInfo.
If I now want my printer monitor client to also be able to monitor my copier, I have to modify the client's code - I have to pull in the copier's WSDL, generate the stubs for its operations and then I can get the DeviceInfo document for the copier.
Now back up and imagine that each of those devices had used HTTP GET in a RESTful way. Because my printer monitor client knows how to handle documents of type DeviceInfo, all I have to do is tell it what the appropriate URI is for each of my devices - I don't have to change any software. Now, instead of only being able to interact with my printer, my client software can interact with any resource that produces DeviceInfo documents in response to a HTTP GET. For free.
Previous Topic
