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.
Tracking change and innovation in the enterprise software development community
Presented by Sanjiva Weerawarana on Jan 10, 2009 08:00 AM
Comprehensive Threat Protection for REST, SOA, and Web 2.0 Applications
Intel® SOA Expressway Performance Comparison to IBM® DataPower XI50
Agile Development: A Manager's Roadmap for Success
The Agile Business Analyst: Skills and Techniques needed for Agile
Would you join a LinkedIn group: "SOASocial"? http://www.linkedin.com/groups?gid=1947576&trk=hb_side_g
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
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 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.
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.
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?
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 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.
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.
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
11 comments
Watch Thread Reply