Using REST and WS* Services in the Cloud
As you might have noted from its title, Tidwell's session was about using RESTful or SOAP-based web services in cloud computing. I had hoped that this was going to be an in-depth examination of coding techniques for cloud computing, perhaps one that stepped through one or more coding examples that use the API(s) for cloud computing. It wasn't. It was more of a simple introduction to REST and JAX-RS, the Java API for RESTful Web Services, with some demonstrations of when to use the REST approach versus the SOAP approach to access web services in the cloud.
That's not to say that the session was devoid of content or not worthwhile. Far from it. Here are some of the interesting things I picked up from this session:
- The cloud is a handy "whipping boy." Tidwell said at the beginning of the session "Throughout this session I will attempt to run code. Of course, if anything goes wrong, I'll blame it on the cloud."
- Twitter is as useless as I had suspected. Tidwell said that "A friend of mine says that Twitter is great because she can tell you what she had for breakfast without you having to wait for her to blog about it."
- Although there are probably as many definitions of cloud computing as there are people using or just thinking about it -- Tidwell pointed out that the definition of cloud computing in Wikipedia has been edited over 350 times -- there is a simple definition that makes a lot of sense (at least to me). Tidwell said "To me cloud computing represents less stuff that I have to know." He went on to say that "With the cloud, I can use all sorts of magical infrastructure and architecture without having to know anything about it, without having any expertise with it, and without having any control over it." The bottom line here is that with cloud computing, a developer needs to invest less effort to get the same amount done. Tidwell warned that this aspect of cloud computing needs to be well hidden from management because it let's developers do less while execting to be paid the same amount of money.
- The utility computing, pay as you go, aspect of the cloud are also important parts of what the cloud means. Tidwell added that "The idea is that I may have 5 servers today. If tomorrow I need 50, it would be nice if magically an extra 45 servers were brought online. If the day after that I only need 7, it would be nice if 43 of those magically go away. So the idea of the cloud is that machines -- virtual machines -- are there when we need it, but when we don't need it, we don't pay for it."
- Representational State Transfer (REST) is well defined -- it was precisely defined in Chapter 5 of a PHD dissertaton by computer scientist Roy Fielding, but no two people in the world agree on what REST actually is. In a backhand reference to the esoterica in Fielding's highly technical dissertation, Tidwell quipped "Personally, when my daughter was a toddler, I read Chapter 5 to her every night."
- Zealous proponents of the REST style are called RESTafarians. They mock the SOAP style as being big and bloated. I don't know what SOAP zealots are called -- SOAPheads? Perhaps they mock REST as dangerously simple and unsecure.
But perhaps the most important thing I learned in this session is the answer to the following question: Which style is better to use for web services in cloud computing, REST or SOAP? The answer according to Tidwell is, it depends. Tidwell says that you need to look at your application and figure out which of the two approaches makes better sense. Tidwell proceeded to show the audience a number of applications where one or the other approach makes sense.
A web service that returns a small amount of data is much better suited for the REST approach. The overhead imposed in conforming to the SOAP approach isn't justified if the result is small. On the other hand, if the web service needs to meet some rigorous requirements such as security standards, the SOAP approach is the way to go.
Tidwell demonstrated a number of web services that underscored these points. A service that returns Twitter entries based on a specific hash code -- this is a good candidate for REST because the ratio of input to output using REST for this service is small. A calculator service running in the cloud that divides two numbers -- again, this a good candidate for the REST approach because of the low ratio of input to output. By comparison, an application that requires authorization or encryption of input merits the SOAP approach and the WS* standards that handle things such as authorization and encryption for web services.
All in all, this was a interesting session -- one that underscored some things I already knew, educated me about a number of other things, and made me laugh more than a few times.