Disclosure: I was offered a copy of this book to review by the publisher. I should also re-iterate the statement the sidebar of my blog – opinions stated here are entirely my own and do not reflect my employer’s positions or opinions.
Although I’ve been working in the SOA space for quite a few years already, I don’t read too many books about it. I guess my education in this space has been largely driven by practical experiences over a number of years with technologies like DCE, MQ and web services. I did briefly write about Sandy Carter’s book earlier in the year, but that was the last book I read on the subject.
SOA Approach to Integration from Packt Publishing is billed as “XML, Web services, ESB, and BPEL in real-world SOA projects”. There are several authors, with differing backgrounds but with experience heavily weighted towards the Java world and (looking at their bios) with a somewhat academic / research-oriented slant, although they clearly do have real-world experience too. Given the range of organisations they have worked with, I picked up the book looking forward to getting a non-IBM view of the SOA world!
The book is divided into 6 chapters. Sadly, there is an inconsistent level of approach – evident from the preface. Chapter 1 covers integration challenges, so is doing the standard scene-setting. Chapter 2 is a discussion of what SOA is, and some of the foundation technologies. However, Chapter 3 then goes on to talk about “various design anomalies that may arise while designing XML schemas”, which is a significant change of pace!
Chapters 1 and 2 are actually interesting… I was happy to read about some of the history of SOA and the way in which technology has evolved over the past 20 years. I first started out in the industry after leaving university dealing with technologies like DCE and TP monitors (discussed on page 40), so this was familiar territory for me. As a foundational discussion these are useful essays… but sadly they do feel a little like essays, rather than a book that builds a coherent message from beginning to end. A little superficial.
There are a couple of sections of the book which deserve mention. At one point the authors refer to an organisational integration architecture as being like a “city plan”, which made me smile as this was an analogy I first heard used by my colleague and good friend Richard Whyte on a project we first worked on about 5 years ago!
The XML chapter I mentioned just before is pretty advanced stuff, and really jars after the first couple of more high-level chapters. That isn’t to say that this is bad… actually I thought that the topics covered, for example the need to define a data dictionary, and some of the practical advice offered such as the suggestion of validating XML at the edge of the ESB if at all, is extremely valuable. It just felt as though it didn’t quite fit at this point in this book! It really scratches the surface – the author admits that the advice given is “meant for consideration only when you already know your system very well”, and given that the first 2 chapters provided a tentative approach to the whole SOA space, this isn’t where I’d expect the reader to be at this point!
Chapters 4 goes backwards a little to an SOA overview, and goes on to describe the IBM patterns for e-business. It also talks about interoperable WSDL, and suggests creating web service clients in multiple technologies to validate and test interoperability, which is a useful idea. Sadly, the code samples do not appear to be available on the publisher’s website, despite the statement in the book that they would be. This is a particular issue in chapter 5, where the authors take their vendor-independence so seriously that they resort to writing BPEL by hand… the chapter is filled with chunks of XML which the reader is expected to be able to read without any kind of overview diagram, when in reality most vendors provide tools to build this stuff for you.
The book talks in detail about web services and the WS-* standards. These discussions are useful, but there is no reference to other forms of interaction, notably REST (for example; NB I talked about IBM’s evolving views on REST and WOA back in April last year).
Interestingly, Nick Hortovanyi’s predictions for 2008 (recently pinged to me by a contact on del.icio.us) suggest that WS-* may be on the wane in terms of SOA usage:
Adoption of the SOA Architecture Style within enterprises will increase. However, unless machine generated, WS-* style service adoption will decrease.
I certainly believe that REST is becoming more interesting in an enterprise context. WS-* is fairly complicated to get one’s head around when you look at them from an XML level, so machine-generated documents are clearly on the increase. Nick also at least references SCA and SDO in his predictions; this book entirely fails to mention either of these important SOA concepts.
From a technology perspective, the book does cover both the JEE and .NET worlds, but is far more heavily weighted towards the former, including a detailed discussion of emerging ideas like JBI. It did discuss a bunch of ideas that were “foreign” (to me) such as itineraries, Process Oriented Architecture (POA), and others that IBM doesn’t talk about… but overall these concepts were covered in a patchwork manner that left me somewhat confused.
My final issue is that I had to submit around 20 errata to the publisher. These ranged from typos (“interactiond”, “TrasformationService”, “isdone”, “buzz-world”) to product name inaccuracies and inconsistencies, to back references that didn’t exist, to the fact that the sample code is not available. Very disappointing. Furthermore, I’m yet to receive any confirmation or acknowledgement that the errata submissions were received.
Overall, I would say that the book is aimed at architects and senior developers and is useful in a few parts… but as a whole it doesn’t hang together. It reads more like a series of extended and disconnected essays at differing levels of detail and which repeat one another. More seriously, for the cover price I would have expected slightly more effort in the proofreading and production 
Andy Piper
Google Profile
