SOA Patterns is Published!
My book on Service Oriented Architecture patterns is finally published. You can get the ebook on manning’s site. The printed version will be available Sept 7 (can be preordered on Amazon) and the Kindle version/ePub versions will be available on Sept 20th.
I also prepared pages for all the pattern on my site (you can click on the pattern map) which holds a brief description of each pattern and is meant to use as a quick reference. There are a few thing I still need to do there like add the page number for each pattern, provide links to the first and last chapters (which are available for free on Manning’s site), add the anti-pattern etc. but most of the work is done.
What’s really amazing is that Gregor Hohpe agreed to write the forward to the book and what is even more amazing is what he actually wrote:
When Bobby Woolf and I wrote Enterprise Integration Patterns…we decided to focus on messaging patterns first, with the hope of covering service patterns in the future. Alas, we never managed to complete that formidable task, so we are doubly thankful to Arnon—not only did he document the significant body of knowledge on SOA, he also filled in an important gap that we had left. Well done.
Anyway, here’s the whole forward:
Building distributed yet integrated systems remains a difficult problem to solve. First, it requires a solid understanding of the individual components to be connected. Next, we have to connect these components in a way that balances loose coupling against system-wide requirements, such as latency and security. Last but not least, the resulting system has to be monitored and managed. Over time, a number of approaches have set out to solve these challenges: distributed components, EAI messaging, and, more recently, service-oriented architectures (SOA). While these approaches and tools have been a tremendous help, there is still no easy step-by-step recipe for balancing potentially opposing requirements into a coherent solution.
This is why design patterns are such a critical resource for building successful SOA solutions. Patterns encode knowledge and experience in a way that can be applied in a variety of contexts and technologies. They are not a one-size-fits-all silver bullet, but they do present forces and counterforces that steer us toward a reusable, well-balanced solution. At the same time, they form an important vocabulary that allows us to communicate our design decisions succinctly and precisely.
Arnon has harvested design decisions from years of building SOA solutions and has encoded his knowledge and experience in this book. He presents a conceptual framework of an SOA, which serves as the roadmap through various aspects of SOA design. For each aspect, he shares actionable guidance and examples from real-world project experience. At the end, he pulls all the pieces together in a real-world case study.
Rather than compiling a tome of every possible pattern that could be relevant to an SOA, Arnon selected and documented a core set of patterns and arranged them in a logical fashion. He discusses the trade-offs and design decisions involved in applying each pattern in detail, down to actual code examples. Like most tools, SOA patterns can be used, but also abused or overused. That’s why Arnon takes care to warn us of the temptation to SOA-ify every architectural nail with our newfound “SOA hammer.”
When Bobby Woolf and I wrote Enterprise Integration Patterns, Web Services had just entered the technology arena, and there was little knowledge and experience on how to turn individual services into a full-fledged service-oriented architecture. So, we decided to focus on messaging patterns first, with the hope of covering service patterns in the future. Alas, we never managed to complete that formidable task, so we are doubly thankful to Arnon—not only did he document the significant body of knowledge on SOA, he also filled in an important gap that we had left. Well done.
Enterprise Integration Patterns
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)