[jmix]

Section 1.1 starts out by listing some "principles": availability, reliability, cost, etc. None of these are principles.

At a higher level, the main point of the book, a Service Oriented Architecture composed of independent, separable, small components, doesn't really make sense: many of the critical concerns in distributed systems are cross-cutting. E.g. if you're using Mongo as a storage component, you will be doomed to the morass of eventual consistency throughout your application. Cross cutting concerns require end-to-end thinking.

Now, SOA is a meaningless term and one can redefine it to mean anything, so don't defend the book by redefining critical terms. I am not arguing that componentized designs don't make sense. I am arguing that you cannot componentize in the manner described in the book, without constant concern for the whole. Yes, you can bolt crap together into a bigger pile (of crap), but it'll stink as badly as the weakest, stinkiest component.

[jyu]

Can you recommend other resources for learning the right way to construct SOA?