Tracking change and innovation in the enterprise software development community
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Recorded at:
Presented by Steve Vinoski on Jul 15, 2008
Free $40 SOA Demystified Book Offer
Right Collaboration Architecture Drives Business Transformation
Restful BPM, Pragmatic SOA, Mashups, Avoiding Failure: SOA track @ QCon London in March
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
Seems like the issue today is not so much SOAP vs. REST, but the
backlash against interface/contract based programming in general.
This
raises the issue of versioning/deprecating interfaces (or resources).
For me, I see issues with service discovery (a la WSDL) with REST, as there is no way that I can see for a consumer to learn a REST service's API without referring to human-readable documentation. With SOAP, we have the ABCs (address-binding-contract). With REST, the A and B are implicit, which leaves C.
What I'd like to see happen for REST to mature is a simple way to
describe the exchange of documents (messages), and not just serialize
objects, which is all the SOAP/WSDL/XSD mess really describes. In the
end, I guess REST is about semantics and SOAP is about syntax.
There is certainly some room for REST to "grow up" with little used HTTP 1.1 verbs such as OPTIONS, HEAD, TRACE, and CONNECT and header fields.
Thanks,
Mark
This was a very valuable presentation which I watched with great interest.
You said: "Specialized interfaces inhibit scalability" and inhibit reuse as they require custom code clients. I fully agree with that remark.
However does the need for specialized data not inhibit reuse and scalability just as much as specialized interfaces? Don't we spend far more lines of application code on setting up our specialized data structures than on calling the actual specialized interface of a service?
Does offering a uniform interface while still having specialized data structures really increase reusability and therefore scalability? I kind of question that but would like to get others opinions as well.
Hi Mark, thanks for your comments.
As I once remarked in a blog entry, I've never seen anyone develop an IDL/SOAP/WSDL-based client without referring to human-readable documentation. Nobody writes a client that simply goes out, discovers such services, and starts using them. Among other problems, the specialized interfaces required to communicate with the newly-discovered service makes this hard to do. Keep in mind that each specialized service interface is effectively a new application protocol.
IMO you have a better chance at this with REST due to the very important HATEOAS constraint: "hypermedia as the engine of application state." The representations returned by resources direct the client through the application state by giving it hyperlinks and form metadata so it knows what to do next. The client must understand the media type of the resource representation, of course, but the fact that media types are globally standard types registered with the IANA means that clients and servers can be independently developed against them. This is quite different from the specialized data types for each specialized interface that IDL/WSDL encourage, which ends up discouraging independent development of client and server.
Hi Torsten, I hope all is well and thanks for your feedback.
This is a REST frequently-asked question, and if I recall correctly it was even asked by some of the attendees (Glen and Sanjiva IIRC) during the presentation. It's such a common question that I wrote a whole column about it earlier this year: please read "Demystifying RESTful Data Coupling" as I believe it will answer your question.
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.
4 comments
Watch Thread Reply