Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Free Book Offer
SOA Demystified
$40 Value
Recorded at:
Presented by Stefan Tilkov on Jan 29, 2009
Free $40 SOA Demystified Book Offer
Learning to be a Good Product Owner: Foundation Skills
Agile Development: A Manager's Roadmap for Success
Visit SOA Appliance Comparison Site
*Video Usage Model Tutorials
*Comparison to IBM DataPower X150
*Performance Benchmarks/Webinars
*Replace DataPower Program
FREE 1:1 Swap & Migration Services
This is probably the first comparison of REST Vs SOA, WS.*, SOAP that explains how they can be compared.
It would be interesting to get Stefan's opinion of Ross Altman's latest presentation. Ross is one of Sun's CTOs (for Business Integration) and he explains:
Assumption: RESTful Web services should be used instead of WS-* Web services
A case can be made for the use of RESTful services for Opportunistic applications. However, for Systematic applications, the Qualities of Service that are required would have to be built on an ad hoc basis.
As a result, the cost of RESTful services would go up and interoperability would go down
If the counterparties building a RESTful interaction have to “reinvent the wheel” of runtime governance standards, the costs and complexity of RESTful Web services would increase dramatically, undermining the attractiveness of the REST model
Since the runtime management capabilities for each RESTful Systematic application would be developed in a non-standard way, interoperability between RESTful implementations would drop drastically
When do you think we can throw darts at REST-*?
As you're asking for my opinion: No, I don't believe that WS-* will have to be re-invented for RESTful HTTP. For example, I believe that there are many, many more opportunities for runtime governance of RESTful HTTP services already, as the infrastructure has much more visibility into the messages flowing through it.
Hum... so if we take the elements of Runtime Governance for instance:
- registry / repository
- policies
- security
- change management
- event management (as in Incident / Problem resolution)
Could you explain how these pieces work in REST since there are no contracts, no boundaries, no policies, no agreed upon versioning capability, URIs are bolted on resource access operations (making it hard to deal with Change) and finally, how do you go about conducting a root cause analysis across a domain that has no autonomous boundaries (i.e. where the only explicit boundary is the network authority that owns a particular URI).
When you build a Web App, you can monitor if it's up or down, and how it is behaving. When you cover a network authority with a series of "resources" where do you start when an event/incident/problem occurs? You go straight back to the design doc? you have no impact analysis capabilities?
Sorry for noting your comment so late.
1) Are you suggesting there are widespread runtime governance standards for WS-*? Like what? UDDI? Currently, every governance product uses its own proprietary approach.
2) You are free to use XML Schema, as much as you want to, when using RESTful. If you want to base part of your governance on the evolution of schemas, nothing stops you.
3) There is no versioning support in WS-* that I'm aware of. The stuff I've read about it (including yours) talks about options for XML Schema versioning, which IMO a) still sucks b) is available for REST/HTTP if you disagree
4) While I've seen tons of articles and presentations discussing the use of policies for governance, I've never seen it applied in practice.
5) The impact analysis support I've seen in governance product requires additional metadata that has to be explicitly added, such as usage relationships between consumers and providers. This seems to be entirely orthogonal to the REST vs. WS-* discussion in my view.
6) I fail to see how URIs make it hard to deal with change - in fact I disagree strongly. They offer a workable means to support old, new and unknown clients that I've not seen in the WS-* world.
7) How are incident management and REST/WS-* related?
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
5 comments
Watch Thread Reply