New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Presentation
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Recorded at:
Case Study: RESTful Web Services at Orbitz
How would you like to view the presentation?
In case you are having issues watching this video, please follow these simple steps to help us investigate the issue:
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
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.
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.
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
:)
by
Jules Jacobs
Posted
Source code URL?
by
Bryan Ross
Posted
RE: Case Study: RESTful Web Services at Orbitz
by
Nick Hrycan
Posted
Good job
by
Mark Wutka
Posted
Very nice
by
Faisal Waris
Posted
nice decisions and versioning
by
Guilherme Silveira
Posted
How about SCA?
by
Guy Pardon
Posted
-
You seem a little nervous. But there is no need, this is an excellent presentation!
-
Thank you for the very informative presentation Alex. I heard you mention you will put the code on Google. Can you publish the URL?
-
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.
-
Very interesting presentation, it is nice to hear from someone who has put this stuff into production in a high-volume system.
-
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). -
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 -
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?
7 comments
Watch Thread Reply