InfoQ

Presentation

Recorded at:
Recorded at

WS-* vs. REST: Mashing up the Truth from Facts, Myths and Lies

Presented by Sanjiva Weerawarana on Jan 10, 2009 08:00 AM

Community
SOA
Topics
Web Services ,
WS Standards ,
REST
Tags
SOAP ,
HTTP ,
QCon ,
Debate ,
QCon San Francisco 2007
[image]
The next QCon is in San Francisco Nov 18-20, Join us!
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.

11 comments

Watch Thread Reply

SOA innovation by John Harby Posted Jan 16, 2009 10:38 AM
Re: SOA innovation by Sanjiva Weerawarana Posted Jan 17, 2009 12:08 AM

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!

Back to top

SOA innovation

Jan 16, 2009 10:38 AM by John Harby

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.

Back to top

Re: SOA innovation

Jan 17, 2009 12:08 AM by Sanjiva Weerawarana

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

Educational Content

Hooking Stuff Together - Programming the Cloud

Gregor Hohpe of Google discusses software as connecting services and components, describes the constraints of connected systems design, and presents common design patterns to solve those constraints.

Neil Bartlett on OSGi

Neil provides answers to questions ranging from "what is OSGi" to the future of OSGi in enterprise scale applications. A comparison of OSGi with .Net modularization is also discussed.

Hard Rock: Behind the Music with Silverlight 2

Scott Stanfield presents the Hard Rock Memorabilia web site demoing Silverlight’s Deep Zoom. He also shows other projects to underline some of the Silverlight’s capabilities.

Haskell and the Arts

This presentation explores the use of Haskell as an art mediumm, specifically the question of whether or note the elegance of functional programming is a good match for the aesthetics of art?

Book Review: Facilitator's Guide to Participatory Decision Making

One of the responsibilities of self-organizing teams is to take decisions that respect everyone’s opinion. This book has some examples in coaching the team to navigate through difficult discussions.

Erlang Concurrency, What’s The Fuss?

Erlang is built on 3 components: language, OTP, and VM. Francesco Cesarini explains the role played by each component in order to ensure Erlang’s highly successful concurrency model.

Bindings, Platforms, and Innovation

This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.

Orchestrating Long Running Activities with JBoss / JBPM

This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.


You are viewing a mobilized version of this site...
View original page here

Mobilized by Mowser Mowser
Mobilytics