A chapter from The Architecture of Open Source Applications. The complete text of which is available from here:

http://www.aosabook.org/en/index.html

Looks interesting. No I haven't read it.

I've read a few bits and they're all great one way or the other, primarily because chapters on specific projects are written by their primary authors. A couple of good ones

Nginx: http://www.aosabook.org/en/nginx.html LLVM: http://www.aosabook.org/en/llvm.html Sendmail: http://www.aosabook.org/en/sendmail.html

Although this means there's no consistent style across chapters, it's really something else to hear about the architectural and design decisions that the author made, and how they look back at those decisions now (esp. in the Sendmail article).

I have been finding more and more interesting eBooks for purchase online. But I don't buy them for a few reasons.

First, without ratings by people with good reputation I have no idea whether the book is good or bad. In this case, Grady Booch gave it a thumbs up, but I would still like to see more endorsements / reviews. I know Amazon can be rigged, but for certain genres I've found individuals I trust.

Second, my experience with self published books is that they are often pretty poor in terms of eBook production, even by good authors. I have books by good authors who have gone the traditional route and then tried self publishing; the difference is often night and day.

Last, when I purchase an eBook, I like that it is stored permanently in some place online, so I can refresh it at will. When new formats become available, I want the option to download it for free. I'm not paying for separate PDFs and ePubs. Both OReilly and Informit allow this, and when new formats become available, its easy to get them.

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.

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

Please support AOSA by buying a copy... Money goes to charity, but it shows these books are appreciated. I bought pdfs lastvyear and the epubs last month as my yearly new year's charity.

This chapter surely is a good one, but the books contain a lot of good suggestions.