Review: Pulier & Taylor. Understanding Enterprise SOA.

In re: http://www.manning.com/pulier/

I understand it, enough already! The content of the first half of the book could have been done in twenty pages, and I'm not convinced there's much in there that isn't already in Wikipedia. The authors admit to having committed hype in their past, and their hyping of SOA is still more obvious in the book then they would have liked. Their inclusion of a "Savvy Manager" paragraph to point out problems with SOA is a conscious attempt to redress this bias, but it doesn't go very far.

Ironically, the most concretely useful stuff in the book comes in what should be the fluffiest -- not Part 1, which is supposed to be the technology of SOA but is repetitive hype, but Part 2, which is the business use case study. Not that it couldn't have been done in 20 pages as well, but the contextualisation in a case study and the specific guidelines are welcome. Ch. 13 for example goes through the lumping together of services into a service map, by domain (services associated with a major functional area of the business), and by actor (which processes will the same actor be invoking --- group all of these together in a portal, rather than implementing the separate applications as standalones). Identifying recurring services turns out as expected to be a compelling argument for cutting costs.

To my surprise, there is even a technical point nestled within the business case study: Ch 15.2 --- programming with SOA means you have to concentrate ahead of time on reusability (which is the point of the modularity). (This is natch antithetical to Agile programming, where you don't introduce features you don't immediately need --- like reusability.) This even leads to a revision of the software requirements process: after drafting the software reqs, brainstorm alternative use cases with stakeholders, and spec a web service that will cover these alternatives as well; *then* proceed to develop. ("Developing web services takes longer than developing traditional software. There is simply no way around that.") So to make the service reusable, you incorporate potential uses from stakeholders along with the concrete requirements you already know of from your client.

This is a book for management rather than techos, and it shows. (I miscalculated in the purchase, because the books I was familiar with from Manning's Ottoman Costume series were programming manuals.) Half the book is taken up with the case study narrative, and the beginning half gets very repetitive in going through scenarios hey-presto resolved through SOAs, with virtually no specifics of how it all happens. The book is antithetical to _Mastering your Organisation's Processes_: that book also does case studies, is addressed to management, and evangelises for a solution to business process problems --- but it is hard-hatted, with lots of specifics and concrete guidelines, and real scepticism where appropriate. This book does a little of that in the second half, but still not quite enough to measure up to the other.

In all, services oriented architecture is not that revolutionary an approach --- just modularity writ large, with open-standards SOAP glue rather than proprietary Enterprise Application Integration. I can still envision the specific standards being advocated --- the HTTP protocol, the SOAP, the monitoring of services through SOAP interceptors --- being a transitory matter rather than the thousand-year enterprise solution the book stumbles over itself for. The benefit of service oriented *approaches* to systems design lies only in their emphasis on services as modules, and the protocols for them to interact; what these modules look like, and even whether they remain truly modular, or glued over the web, is incidental. Or at least, contingent. In that regard, e-Frameworks has chosen its emphasis prudently.

(Yet again, a point lost in the first half of the book, and made in the second, Ch. 16: not only must a real-world SOA deployment prioritise which functions to turn into services first, but there are some functions that it makes no sense to turn into services --- they'll never get reused, they're working just fine, they're too tangled up in the current business logic. In fact, implicit in the criteria proposed for which functions to prioritise for SOA --- migration likelihood, isolation from other functions, flexibility and reusability --- there is an underlying criterion implicit, though its correlation is not 100%: complexity. Or as the authors put it, simple business logic functionality. The more tangled a function is, especially in terms of program logic, the less easy it will be to pull out into a *reusable* module, the less flexible it will be to disparate use contexts, and the less likely anyone is going to want to reimplement the whole thing as a migration in the first place. Which has a bearing on establishing the granularity of services: they won't be 2 + 2 level, but they will still be more fine-grained than the minimum.)

The book does have one cautionary note it sounds enough: security concerns make everything more difficult, and SOA is not at a stage yet where that will take care of itself.

The performance hit of packing and unpacking XML is also non-negligible, and something I've seen first hand with my attempt to insist on the X(ml) of AJAX in my interface to the Thesaurus Linguae Graecae lemmatiser. (XML decoding brings Safari to its knees for a big or complex enough chunk of XML; writ large the same can happen in an enterprise, and Robby Robson's scenario of a new identifier minted per microsecond is not going to fly with real-time SOAP.) A web service can be all things to all comers with a transparent WSDL; but there needs to be a business case to be made that it should be, since there are penalties for opening things up like that: not just performance, but accountability as a maintainer --- managing an Open Source toolkit is no sinecure.

And since I'm not immune to style --- a thousand times the Very British, martini-dry humour of _Mastering your Organisation's Processes_, over the Dorothy Dixers in the starting paragraphs of each chapter here.