Along with SOA definition, I am very much interested to know how you go about describing various chapters in your book to match your definition. As often times I have seen SOA definition deviating from actual description of the content in one or the other way.
Well, I'm not sure that Uncle Bob and IBM are that far apart on this one. If I understand Uncle Bob's post, the services in a SOA are essentially the "unchangeable elements". Whereas the business processes are the "changeable elements" implemented in some business process language like BPEL.
This seems consistent with the IBM vision where the "unchangeable elements", or services, are dynamically aggregated into business processes.
My book does not provide a definition of SOA. I rely on Thomas Erl's Service-Oriented Architecture book to provide my working definition of SOA. Page 40 of his book lists the primary characteristics of what he calls a "Contemporary SOA". The most important characteristics that he lists, from my perspective, are: * Contemporary SOA is based on open standards. * Contemporary SOA fosters intrinsic interoperability. * Contemporary SOA promotes architectural composability. * Contemporary SOA promotes loose coupling throughout the enterprise.
The way that these characteristics match the material in the book is as follows:
(1) Open standards implies the emphasis in my book on WSDL, SOAP, XML Schema, and the Java Standards (i.e., JAX-WS, JAXB, and JSR-181). (2) Interoperability and composability imply the emphasis on "Start from WSDL". That is because, if you "Start from Java", the Web services that you generate will not be composable or interoperable. (3) Loose coupling implies the emphasis on document-oriented Web services.
But, I want to emphasis that my book is first and foremost a book for Java programmers who need real-world advice on how to work with Java Web Services (JWS) to implement SOA. So, I don't get too hung up on the definition of SOA. Rather, I embrace those characteristics listed above and then show how to write code using JWS that supports Erl's definition of SOA.
The characteristics from Thomas Erl's definition of Contemporary SOA seem quite pragmatic from an architectural perspective.
My main concern with IBM's definition is the requirement to support "dynamic aggregation". It is clear that "dynamic aggregation" has to be supported for flexible support of WSBPEL. However the somewhat reluctant adoption of, for example, UDDI repositories by the mainstream makes me wonder which aspects of SOA are truly needed be the majority of IT architectures/infrastructures. All the wonderful flexibility of the grand SOA vision comes at a cost.
I see some disturbing parallels to the evolution of J2EE and EJB in particular. After some time, some EJB experts came to the realization that only "10% of applications need distributed business objects" (Ron Johnson, J2EE Development without EJB) which ultimately lead to the emergence of the rebel platforms (Spring, Nano Container, Pico Container, Hibernate, Ibatis, etc.). Similarly 90% of all organizations may only a require few aspects of SOA (like the ones you outline) to maximize their "value proposition of SOA adoption" while a large part of the grand SOA vision at best fades into obscurity at worst encumbers the truly useful parts hindering widespread adoption (leading to the ultimate failure of SOA).