SOA Patterns

Tags: SOA, SOA Patterns, IDesign Method, software architecture, REST

Here's a book I meant to read last year, but didn't get to until this year: SOA Patterns.

Last year I attended an evening presentation by IDesign architect Petar Vucetin. At the end of the insightful session, he cited the SOA Patterns book. I knew that a recommendation from an IDesign architect is not wisely ignored, so I purchased a copy.

Fast forward to now, and I'm ready to write a little about this book. First, I definitely agree with Petar. SOA Patterns is a terrific book. It will give you a lot of ideas as to how to solve real-world problems using SOA. It progresses from basic patterns such as hosting up through scalability and performance concerns, security, messaging and integration. It also covers a few service antipatterns to watch out for, demonstrates a comprehensive case study, and concludes with discussions of REST, the cloud, and big data. All of this is very practical information you'll need in order to serve in a wide-ranging architect role.

All that said, when you've learned something of the IDesign Method (you can download an overview from here), all future architecture discussion is necessarily viewed through that lens. So it should come as no surprise that as I pored over Arnon Rotem-Gal-Oz's patterns and diagrams, I thought in terms of the Method: its concepts, its elegant taxonomy and diagrams.

At various points I had a sense that SOA Patterns missed things that the Method addresses. For instance, in its concern over the nanoservice antipattern, it gave little consideration to the performance gains from utilizing in-proc services (as ServiceModelEx's InProcFactory enables). In discussing the Knot antipattern, it talked about using certain other patterns to avoid it, and this is all well and good, but defining a layered, closed architecture also plays a significant role.

At the same time, I felt that the book got most things right. The relationship of REST and SOA was well-conceived. The aggregated reporting discussion certainly educated me.

Some things in the book merely came to me as higher-level patterns that one would build on top of Method building blocks. Patterns for scaling involving queuing, for example, or using message buses. The various ways orchestration occurs were likewise well-written but I certainly appreciated viewing these from the Method's taxonomy and using volatility as the guiding design strategy.

Overall this book has something to offer most budding software architects. Whether or not you've learned about the Method, you'll find something of value here, though the Method will help you better understand the book's points, identify its weaknesses, and appreciate its strengths.

No Comments

Add a Comment