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:
WS-* vs. REST: Mashing up the Truth from Facts, Myths and Lies
Presented by
Sanjiva Weerawarana
on
Jan 10, 2009
Length 00:45:28
- Sections
- Architecture & Design,
- Enterprise Architecture
- Topics
- SOA ,
- REST ,
- WS Standards ,
- Web Services
- Tags
- SOAP ,
- QCon San Francisco 2007 ,
- HTTP ,
- QCon ,
- Debate
-
- The next QCon is in London March 5-9, Join us!
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
In this presentation, recorded at QCon, WSO2's CEO and WSDL co-inventor Sanjiva Weerawarana tries to address some of the myths and lies surrounding the REST-vs.-WS-* debate. He argues that while both camps claim how "easy" it is to build distributed business applications using their favorite technological approach, building distributed applications simply remains a hard problem.
Bio
Before he founded WSO2, Sanjiva Weerawarana was one of the fathers of the Web services platform while working at IBM Research. He has co-authored many WS-* specifications including WSDL, BPEL4WS, WS-Addressing, WS-RF and WS-Eventing, led the creation of IBM SOAP4J which later became Apache SOAP, and went on to architect and implement many other products, including Apache Axis, and Apache WSIF.
About the conference
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community. QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
In this presentation, recorded at QCon, WSO2's CEO and WSDL co-inventor Sanjiva Weerawarana tries to address some of the myths and lies surrounding the REST-vs.-WS-* debate. He argues that while both camps claim how "easy" it is to build distributed business applications using their favorite technological approach, building distributed applications simply remains a hard problem.
Bio
Before he founded WSO2, Sanjiva Weerawarana was one of the fathers of the Web services platform while working at IBM Research. He has co-authored many WS-* specifications including WSDL, BPEL4WS, WS-Addressing, WS-RF and WS-Eventing, led the creation of IBM SOAP4J which later became Apache SOAP, and went on to architect and implement many other products, including Apache Axis, and Apache WSIF.
About the conference
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community. QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
- 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
Couldn't agree more with the points regarding the false simplicity of REST
by
Nicolas Fonrose
Posted
Re: Couldn't agree more with the points regarding the false simplicity of R
by
JAVAID ASLAM
Posted
Re: Couldn't agree more with the points regarding the false simplicity of R
by
Maurizio Turatti
Posted
Re: Couldn't agree more with the points regarding the false simplicity of R
by
Stefan Tilkov
Posted
Re: Couldn't agree more with the points regarding the false simplicity of R
by
Stefan Tilkov
Posted
Re: Couldn't agree more with the points regarding the false simplicity of R
by
William Martinez
Posted
Re: Couldn't agree more with the points regarding the false simplicity of R
by
Maurizio Turatti
Posted
SOA innovation
by
John Harby
Posted
Re: SOA innovation
by
Sanjiva Weerawarana
Posted
-
I couldn't agree more with the points regarding the false simplicity of REST. It's obvious that considering Sanjiva's involvment in many WS-* specifications, he can only have a view biased toward this family of solutions. But the points he makes in the presentation are hard to be invalidated.
btw, funny that this video is posted now, 2 years after the talk. But the more the "REST people" are pushing REST as a replacement for WS-*, the more it's important to watch this video. REST is great, but not as a replacement of WS-* in the enterprise. -
Could have been lot better if the focus was more on the presentation rather than just answering the questions from couple of persons in the audience who could hardly be heard!
The speaker was too fast to be intelligible.
Poor style! -
I had to laugh when he mentioned the paper in the late '90s from IBM supposedly inventing SOA. The CORBA architecture and others from DEC prior were excellent examples of SOA - I don't really see where someone could have invented SOA in the late '90s.
-
Come on John, I never said IBM invented SOA - what I said is that a paper in the 90s (which I put the ref to in the slides) invented the TERM SOA.
In fact, Paul Fremantle and I wrote a CACM paper in around 2003 which showed how CICS had a services model. CICS predates CORBA by a few years :). -
My browser has daily a secure, reliable and trustful conversation with my bank account and it doesn't need any WS-*. The same when I buy books on Amazon. The ability to have real interoperable secure conversation between Java and .NET through WS-* is still very questionable even in 2009. There are of course use-cases when WS-* is very helpful, but on average the specs are abused. REST web services are much younger than SOAP WS but gaining traction mainly because they are simpler and easier to maintain. The Web itself is built on top a REST-like paradigm and it seems pretty successful... WS-* seems now even more complex than Corba, so the REST movement, which is not immune to defects, is a natural, non vendor-driven, spontaneous bottom-up response to overwhelming complexity much like opensource has been for closed source software. The fact that WS-* is nowadays successful within enterprises is another highly questionable statement, not in terms of adoption but especially in terms of TCO.
-
Maurizio
>>My browser has daily a secure, reliable and trustful conversation with my bank >>account and it doesn't need any WS-*. The same when I buy books on Amazon.
Just because it is using your browser and http it does NOT mean it is REST. I think you are getting confused between REST and something built over http. -
A D (please use your real name, BTW, thank you),
The browser is an excellent example of a (90%) RESTful client. The closer Web applications that use it are built according to REST principles themselves, the more they get out of this fact.
And in fact your client application (or service consumer, if you prefer) can be built according to the same principles, and if you do so, you'll be able to exploit the Web's features, too. -
>>The browser is an excellent example of a (90%) RESTful client.
Yes it is.
>> The closer Web applications that use it are built according to REST
>> principles themselves, the more they get out of this fact.
REST is cool but all I am saying is that it is incorrect to assume that anything served over HTTP is by default REST. I am sure you would agree that REST is *MORE* than this. -
Yes, using HTTP does not equal doing REST.
-
AD,
I agree, but the browser is just an example. From my point of view
REST is a way to implement a resource oriented architecture and the Web is the biggest example of a working ROA I can think of. Why do you think Google, Amazon and Yahoo are all deprecating their SOAP APis in favour of their REST versions? Just because of fashion?
Now we could keep believing that a bunch of vendor's representative can close themselves into a room for a year or two and come out with better specifications than the remaining of the world or, instead, we can start looking at how things actually work out there. REST is complex and ROA is still in its infancy, so nobody could honestly claim to have a full understanding of it projected into big scale projects, but really SOAP, WSDL and friends are better and simpler? Let's see what are the emerging standards within a couple of years. Recently we have all seen how the community has reacted to EJB complexity an inability to deliver by introducing new, simpler concept which are represented by the Spring Framework.
I have developed quite a faith that the open community is able to elaborate more interesting ideas and create more viable implementations than committees. -
Hello.
We can go even further. Really using REST is a lot harder than it seems! Simply read all confusion people has trying to understand Fielding's explanations of why RESTFull APIs are not RESTFull at all.
Now, WS is something and REST is another completely different thing. I'm adventured to say WS can be implemented RESTfully! The hard parts of REST are, first, understanding what it actually means, and second, dealing with standards so low level. Granurality! WS may offer more abstraction without making a REST app less REST. Problem is people thinking they are opposites with no reconciliation possibilities.
Cheers.
William Martinez Pomares.
Architect's Thoughts
11 comments
Watch Thread Reply