I just caught an interview with Stefan Tilkov in which he describes Service Oriented Architecture for the developer and highlights some of the architectural choices and implications involved in various SOA flavors, implementations, and incarnations. Check it out.
I took away a couple of points.
REST is best for exposing services at the Internet scale. Seems like common sense, but it’s a good point. If your architecture is consumer-facing it’s best to have a low-barrier, easy API for AJAX/mashup-style development.
You can’t buy a SOA. I agree, but I’m not hearing much of a marketing message around turnkey SOA. Does that message exist?
What you can buy – and vendors should supply - are SOA-friendly applications. As companies like salesforce.com blaze trail with more than application services, but service-aware platforms, I’d expect that some of the effort around evolving a service oriented ecology to be eased by third party application selection, portfolio management, and in-build product support for SOA enablement… another thing for enterprise architects to look for in the buy vs. build equation.
There’s a really cool poster available on Stefan’s company site (innoQ) that details the landscape of WS-* protocols grouped by functional area. It’s a handy visualization for seeing which vendors have authored and what problem area each specification attempts to address, useful as there are an overwhelming number of them.

GitHub
LinkedIn
Twitter
Comments on this entry are closed.