Service-Oriented Architecture (SOA) is not about technology, although technology is used to implement it. The principles of reliability and accommodating unexpected changes at a manageable cost can be applied equally in any programming language. However, as with most things in life, not just software development, it is easiest to use a model that is supported by tools and inter-operable (the ability of two or more systems or components to exchange information and to use the information that has been exchanged). A standards-based Service-Oriented Architecture (SOA), is such a model that enables IT infrastructure is continuously adapted to keep up with the pace of business change.
Matt Wright and Antony Reynolds have just published a book Oracle SOA Suite Developer’s Guide that provides a best practice guide to using the Oracle SOA Suite for building a real world applications. This book bridges the gap between SOA theory and the Oracle SOA Suite Manuals and is based on the experience of implementing SOA across a number of organisations in EMEA and APAC. It is a book of three parts. The first section of the book provides detailed coverage of all components of the SOA Suite, namely OSB, BPEL, Rule, BAM and OWSM. The second section addresses the common question: “What is the best way to combine / use all of these different components to implement a real-world SOA solution?”. Using a working example of an online auction site, it leads you through key SOA design considerations in implementing a robust solution that is designed for change. Though the examples in the book are based on Oracle SOA Suite 10.1.3.4 the book will still be extremely useful for anyone using 11g. The final section addresses non-functional considerations and covers the packaging, deployment, and testing of SOA applications; it then details how to use Web Service Manager to secure and administer SOA applications.
I’m sure this book will continue to be relevant in years to come to. Unlike other technical books, this one does more than just explain “how” to do A, B, and C, but goes to great lengths to explain the concepts. As a software developer it is vital to understand why we were doing what we were doing, so that we know which principles to apply in different situations.