Tom Nolle has over 30 years of experience as a private consultant and is a prolific writer
and blogger on all things IT. His recent experiences with the ExperiaSphere project have leant Nolle an
in-depth understanding of the pain points application architects face when working with Web
In this three-part interview, Tom Nolle discusses where SOA came from, where it stands today and where it's going tomorrow. Discussing standards and requirements for SOA, Nolle went into detail about how these important aspects play into application development for new technologies like mobile devices. Here, he explains more about the effect that mobile devices are having on the realm of RESTful Web services. In the third installment, Nolle introduces the "chubby client", which has emerged as an alternative to the traditional thin client versus thick client paradigm when he discusses what is still to come for SOA.
SearchSOA.com: Where will development be going in the next few years, in terms of small devices? Will the developer's life change because of it?
All of my experience with RESTful interfaces in ExperiaSphere is based on the exchange of an xml payload.
Tom Nolle, chief strategist at ExperiaSphere,
Tom Nolle:I think that the typical developer's life has
already changed in the sense that if you're an application developer, you're effectively a business
person that is necessarily tied into what the current hot problem set is. And I would argue that
the traditional Web services/SOA problems now tend to be the province of big companies so there may
be a lot of people sitting around Microsoft, IBM and Oracle worrying about this stuff.
Right at the moment the single largest unsolved problem is not backend Web server integration where it was ten years ago. The largest unsolved problem is tablets and iPhones.
If you're going to do applications for tablets and iPhones the normal mechanism for those applications from the first has been RESTful rather than Web services. There are factors that people are learning and that are somewhat more complicated. If you look at the applications ten years ago, the way in which transactional behavior was established was through server-side stateful behavior, which is to say that when you were executing a transaction, the server that you were talking with knew where you were in the process. It maintained state and so there was a requirement for the server to know and understand the relationship between it and every client as a discreet session with a discreet status or state that needed to be understood.
Now that process is intrinsically not scalable to very large volumes of devices, which is why the Web developed a different approach from the beginning. The Web approach – RESTful – should probably be considered an alternative to stateful, meaning that in a RESTful approach, a transaction is broken up into a number of exchanges and those exchanges carry state explicitly in the transaction, so a Web server doesn't have to remember what this device did in its prior exchange like it does in traditional stateful behavior.
SearchSOA.com: So as we look to do more REST, we're not starting from square one.
Tom Nolle:No, were' not and what I've seen over the last five years is sort of a hybridization of the two concepts. For example, if you look at the descriptions of html programming in the very early days, what you found was a strong presumption of simple, basic html get/post behavior. Which means it was a highly simplistic kind of interface. It wasn't really delivering complex data models. If you look at Google's, Yahoo's, or Facebook's API today, what you're going to see is the RESTful delivery of an xml payload. What we've done is taken Web principals at the RESTful level where a function is represented by a URL rather than a session represented by an application URL. We've translated that to the function being more complex than just processing a Web page, so we've added xml to it. All of my experience with RESTful interfaces in ExperiaSphere for example, is based on the exchange of an xml payload, even if it's RESTful.
This was first published in October 2010