Erl:
"Its popularity to date is largely the result of vendors advertising SOA support or capability as part of their product lines. Because SOA has been so vendor-driven, its meaning has been somewhat divergent, skewed by proprietary technology that is...identified with common characteristics that transcend proprietary boundaries."
and
"Vendors...have published numerous papers, blueprints, and even frameworks. Most such document serve the dual purpose of educating readers about SOA while marketing related products or services. This is nothing new...However, because a core expectation of SOA is its ability to harmonize and streamline diverse technical environments, preserving an abstract viewpoint is required to achieving its potential." (emphasis mine)
He talks a bit about Service Orientation (SO) and Object Orientation - they are tantamount in pursuing "separation of concerns," but with different approaches. In describing SO's approach, he describes 8 common principles of SO that should be considered and encouraged when designing systems on any platform, regardless of vendor/language. (Sun/J2EE, MS/.NET, Zend/PHP, etc)
I hate that vendors often prattle on about SOA without actually saying anything. But Erl may be too much on the other extreme - describing SOA in such idealistic technical terms that it escapes any relation to real down-to-earth, or in-the-trenches, programming. his first book was okay in providing example situations and scenarios, but he never seems to go into any run-time code detail, instead focusing only on the XML syntax of the various WS-* techs.
when I create my uber-l33t service-oriented system, I'll be sure to write an entire book/dissertation/case-study on it down to the code level. hopefully I will show the link between the SO common principles and the SO code. that is, as soon as I write and master the SO code. here's hoping...</div>
