Conventional wisdom of the "software stack" approach to building applications may no longer be relevant. Enterprises are pursuing new ways of organizing systems and processes to become service oriented and event-driven. Leveraging existing infrastructural investments is a critical aspect to the success of companies both large and small. Enterprises have to adapt their systems to support frequent technological changes, mergers and acquisitions. Furthermore, in a growing global market, these systems are being called upon to be used by external business partners.
Technology is often difficult, costly and complex and without modern approaches can prevent the enterprise from becoming agile. Enterprise Service Oriented Architectures helps readers solve this challenge in making different applications communicate in a loosely coupled manner. This classic handbook leverages the experiences of thought leaders functioning in multiple industry verticals and provides a wealth of knowledge for creating the agile enterprise.
In this book, you will learn:
How to balance the delivery of immediate business value while creating long-term strategic capability
Fundamental principles of a service-oriented architecture (find, bind and execute)
The four aspects of SOA (Production, Consumption, Management and Provisioning)
How to recognize critical success factors to implementing enterprise SOAs
Architectural importance of service registries, interfaces and contracts
Why improper service decomposition can hurt you later rather than sooner
How application design and integration practices change as architects seek to implement the "agile" enterprise
Review By: John VanNorman 08/22/2007Enterprise Service Oriented Architecture explains service oriented architecture (SOA) both inside and outside an enterprise. It describes an overall architecture to lower-level design components of good enterprise SOA, as well as some related concepts like components and event-driven architecture. The book is well organized, starting with general concepts and then delving into more detail. Each chapter handles a general concept, provides the constituent pieces, and explains what they are, why they are needed, and, to some extent, how to implement them.
Overall, the book is easy to read and has sufficient diagrams. The book provides examples, sometimes allegorical, interspersed with definitions. While the implementation of some concepts is a bit complicated, the organization of the book helps lead the reader to a better understanding. One aspect of the book I found interesting is the quoting of famous people at the beginning of each chapter. I sometimes wondered why a particular quote was chosen, but after reading the chapter I went back and was able to see an oblique reference. That mechanism helps the reader gain a little more appreciation of the subject.
For me, the book is particularly relevant. My own organization is coping with enterprise SOA as a way to integrate legacy systems. As a manager of one of those legacy systems, I need to understand what makes good SOA, how my system will fit into the overall architecture, and, most importantly, what model mechanisms we are implementing so that I can help guide the development work. This book fits that need very well.
Testers also need to know the general concepts of how the software is supposed to fit within the overall architecture and design. Test cases need to be crafted to assure sufficient relevance to the operations of the software—in other words, does the software do what it is supposed to do and not what it shouldn't? The relevance to quality assurance is how SOA implements security, controls process flow, and assures the business functions are complete and accurate.
The book provides insight into SOA concepts by using non-IT-based concepts. The authors recognize the realities of building an SOA and provide compelling, long-term reasons to do it. The code examples are geared toward the more technically inclined. As someone not code competent, I found them tedious and chose to ignore them after a few tries. I did like that the authors do not incorporate a case study in the text, which would have been too much, but rather offer one as supplemental material for those who are interested.