BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Presentations Case Study: RESTful Web Services at Orbitz

Case Study: RESTful Web Services at Orbitz

Bookmarks
01:05:44

Summary

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.

Bio

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.

About the conference

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.

Recorded at:

Jan 07, 2010

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • :)

    by Jules Jacobs,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    You seem a little nervous. But there is no need, this is an excellent presentation!

  • Source code URL?

    by Bryan Ross,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thank you for the very informative presentation Alex. I heard you mention you will put the code on Google. Can you publish the URL?

  • RE: Case Study: RESTful Web Services at Orbitz

    by Nick Hrycan,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    It is nice to see what other companies are doing. Very interesting presentation, I need to take a look at Google's protocol buffers project.

  • Good job

    by Mark Wutka,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Very interesting presentation, it is nice to hear from someone who has put this stuff into production in a high-volume system.

  • Very nice

    by Faisal Waris,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Good practical application of an SOA based on HTTP/Spring/Protocol Buffers.

    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

    by Guilherme Silveira,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I really liked the way the presentations goes on how it was a good decision to not adopt a tool if the infrastructured required to scale as much as required was already there.

    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.

    Regards

  • How about SCA?

    by Guy Pardon,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Interesting talk; I can understand the problem but I wonder to what extent something like SCA could not solve the same issues... I don't see a lot of arguments besides versioning - which has not so much to do with REST but more with Google?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT