Alex Antonov explains why Orbitz needed to ditch Jini and Java serialization in favor of REST and Protocol Buffers. Most of the presentation contains a demo of a sample application using these technologies to handle client-server requests/responses.
Alex joined Orbitz LLC in 2004 and is responsible for providing technical leadership and guidance in the development of foundational technologies, core libraries and APIs for the enterprise-wide use, as well as establishing and maintaining common design principles and standards used within the company and integration of new software development practices within the development community.
SpringOne 2GX is an annual event; it includes a technical exploration of the Spring ecosystem along with the latest developments in the Groovy/Grails space. As a participant, you will have the opportunity to attend two great events at one venue. Whether you're a Spring enthusiast, Tomcat user, Groovy/Grails fan, or just interested in open source development, you'll find valuable content in sessions presented here.
Source code URL?
RE: Case Study: RESTful Web Services at Orbitz
Not really REST though. Fielding's thesis is mentioned but with a take-it-with-a-grain-of-salt caveat. However Fielding's the one that defines REST! Lets just call it an SOA.
Still too much plumbing code seems to be required. My exprience with WSDL based services seems a lot simpler programming wise - the entire plumbing code can be generated by tooling from metadata. Protocol Buffers define the data format only - the service interface is not part of it.
Protocol Buffers' speed and versioning is impressive.
Doing versioning with XML schema is an acquired skill - it does not come naturally.
I wonder if Protocol Buffers will work well where a large complex and complex vocabulary needs to be developed/used as in a large enterprise - I could not find any references to name scopes (namespaces).
nice decisions and versioning
Just a small question on versioning: the example shows how compatibility issues are handled when a new field is added. What is the usual approach to information removal: changing what a client expected to receive. How would clients behave if I simply remove the field from the description? How could it cope with it? Any suggestions?
Its a really nice presentation, because it focuses on why and how.