- ホーム
- > 洋書
- > 英文書
- > Computer / General
Full Description
"SOA Design Patterns is an important contribution to the literature and practice of building and delivering quality software-intensive systems."- Grady Booch, IBM Fellow"With the continued explosion of services and the increased rate of adoption of SOA through the market, there is a critical need for comprehensive, actionable guidance that provides the fastest possible time to results. Microsoft is honored to contribute to the SOA Design Patterns book, and to continue working with the community to realize the value of Real World SOA."- Steven Martin, Senior Director, Developer Platform Product Management, Microsoft "SOA Design Patterns provides the proper guidance with the right level of abstraction to be adapted to each organization's needs, and Oracle is pleased to have contributed to the patterns contained in this book."- Dr. Mohamad Afshar, Director of Product Management, Oracle Fusion Middleware, Oracle "Red Hat is pleased to be involved in the SOA Design Patterns book and contribute important SOA design patterns to the community that we and our customers have used within our own SOA platforms. I am sure this will be a great resource for future SOA practitioners."- Pierre Fricke Director, Product Line Management, JBoss SOA Platform, Red Hat "A wealth of proven, reusable SOA design patterns, clearly explained and illustrated with examples. An invaluable resource for all those involved in the design of service-oriented solutions."- Phil Thomas, Consulting IT Specialist, IBM Software Group "This obligatory almanac of SOA design patterns will become the foundation on which many organizations will build their successful SOA solutions. It will allow organizations to build their own focused SOA design patterns catalog in an expedited fashion knowing that it contains the wealth and expertise of proven SOA best practices."- Stephen Bennett, Director, Technology Business Unit, Oracle Corporation "The technical differences between service orientation and object orientation are subtleenough to confuse even the most advanced developers. Thomas Erl's book provides a great service by clearly articulating SOA design patterns and differentiating them from similar OO design patterns."- Anne Thomas Manes, VP & Research Director, Burton Group "SOA Design Patterns does an excellent job of laying out and discussing the areas of SOA design that a competent SOA practitioner should understand and employ."- Robert Laird, SOA Architect, IBM "As always, Thomas delivers again. In a well-structured and easy-to-understand way, this book provides a wonderful collection of patterns each addressing a typical set of SOA design problems with well articulated solutions. The plain language and hundreds of diagrams included in the book help make the complicated subjects of SOA design comprehensible even to those who are new to the SOA design world. It's a must-have reference book for all SOA practitioners, especially for enterprise architects, solution architects, developers, managers, and business process experts."- Canyang Kevin Liu, Solution Architecture Manager, SAP "The concept of service oriented architecture has long promised visions of agile organizations being able to swap out interfaces and applications as business needs change. SOA also promises incredible developer and IT productivity, with the idea that key services would be candidates for cross-enterprise sharing or reuse. But many organizations' efforts to move to SOA have been mired-by organizational issues, by conflicting vendor messages, and by architectures that may amount to little more than Just a Bunch of Web Services. There's been a lot of confusion in the SOA marketplace about exactly what SOA is, what it's supposed to accomplish, and how an enterprise goes about in making it work. SOA Design Patterns is a definitive work that offers clarity on the purpose and functioning of service oriented architecture. SOA Design Patterns not only helps the IT practitioner lay the groundwork for a well-functioning SOA effort across the enterprise, but also connects the dots between SOA and the business requirements in a very concrete way. Plus, this book is completely technology agnostic-SOA Design Patterns rightly focuses on infrastructure and architecture, and it doesn't matter whether you're using components of one kind or another, or Java, or .NET, or Web services, or REST-style interfaces. While no two SOA implementations are alike, Thomas Erl and his team of contributors have effectively identified the similarities in composition services need to have at a sub-atomic level in order to interact with each other as we hope they will. The book identifies 85 SOA design patterns which have been developed and thoroughly vetted to ensure that a service-oriented architecture does achieve the flexibility and loose coupling promised. The book is also compelling in that it is a living document, if you will, inviting participation in an open process to identify and formulate new patterns to this growing body of knowledge."- Joe McKendrick, Independent Analyst, Author of ZDNet's SOA Blog "If you want to truly educate yourself on SOA, read this book."- Sona Srinivasan, Global Client Services & Operations, CISCO "An impressive decomposition of the process and architectural elements that support serviceoriented analysis, design, and delivery. Right-sized and terminologically consistent. Overall, the book represents a patient separation of concerns in respect of the process and architectural parts that underpin any serious SOA undertaking. Two things stand out. First, the pattern relationship diagrams provide rich views into the systemic relationships that structure a service-oriented architecture: these patterns are not discrete, isolated templates to be applied mechanically to the problem space; rather, they form a network of forces and constraints that guide the practitioner to consider the task at hand in the context of its inter-dependencies. Second, the pattern sequence diagrams and accompanying notes provide a useful framework for planning and executing the many activities that comprise an SOA engagement."- Ian Robinson, Principal Technology Consultant, ThoughtWorks "Successful implementation of SOA principles requires a shift in focus from software system means, or the way capabilities are developed, to the desired end results, or real-world effects required to satisfy organizational business processes. In SOA Design Patterns, Thomas Erl provides service architects with a broad palette of reusable service patterns that describe service capabilities that can cut across many SOA applications. Service architects taking advantage of these patterns will save a great deal of time describing and assembling services to deliver the real world effects they need to meet their organization's specific business objectives."- Chuck Georgo, Public Safety and National Security Architect "In IT, we have increasingly come to see the value of having catalogs of good solution patterns in programming and systems design. With this book, Thomas Erl brings a comprehensive set of patterns to bear on the world of SOA. These patterns enable easily communicated, reusable, and effective solutions, allowing us to more rapidly design and build out the large, complicated and interoperable enterprise SOAs into which our IT environments are evolving."- Al Gough, Business Systems Solutions CTO, CACI International Inc. "This book provides a comprehensive and pragmatic review of design issues in service-centric design, development, and evolution. The Web site related to this book [SOAPatterns.org] is a wonderful platform and gives the opportunity for the software community to maintain this catalogue...."- Veronica Gacitua Decar, Dublin City University "Erl's SOA Design Patterns is for the IT decision maker determined to make smart architecture design choices, smart investments, and long term enterprise impact. For those IT professionals committed to service-orientation as a value-added design and implementation option, Patterns offers a credible, repeatable approach to engineering an adaptable business enterprise. This is a must read for all IT architect professionals."- Larry Gloss, VP and General Manager, Information Manufacturing, LLC "These SOA patterns define, encompass, and comprise a complete repertoire of best practices for developing a world-class IT SOA portfolio for the enterprise and its organizational units through to service and schema analysis and design. After many years as an architect on many SOA projects, I strongly recommend this book be on the shelf of every analyst and technical member of any SOA effort, right next to the SOA standards and guidelines it outlines and elucidates the need for. Our SOA governance standards draw heavily from this work and others from this series."- Robert John Hathaway III, Enterprise Software Architect, SOA Object Systems "A wise man once told me that wisdom isn't all about knowledge and intelligence, it is just as much about asking questions. Asking questions is the true mark of wisdom and during the writing of the SOA Design Patterns book Thomas Erl has shown his real qualities. The community effort behind this book is huge meaning that Thomas has had access to the knowledge and experience of a large group of accomplished practitioners. The result speaks for itself. This book is packed with proven solutions to recurring problems, and the documented pros and cons of each solution have been verified by persons with true experience. This book could give SOA initiatives of any scale a real boost."- Herbjoern Wilhelmsen, Architect and Senior Consultant, Objectware "This book is an absolute milestone in SOA literature. For the first time we are provided with a practical guide on how the principle centric description of service orientation from a vendor-agnostic viewpoint is actually made to work in a language based on patterns. This book makes you talk SOA! There are very few who understand SOA like Thomas Erl does, he actually put's it all together!"- Brian Lokhorst, Solution Architect, Dutch Tax Office "Service oriented architecture is all about best practices we have learned since IT's existence. This book takes all those best practices and bundles them into a nice pattern catalogue. [It provides] a really excellent approach as patterns are not just documented but are provided with application scenarios through case studies [which] fills the gap between theory and practice."- Shakti Sharma, Senior Enterprise Architect, Sysco Corp "An excellent and important book on solving problems in SOA [with a] solid structure. Has the potential of being among the major influential books."- Peter Chang, Lawrence Technical University "SOA Design Patterns presents a vast amount of knowledge about how to successfully implement SOA within an organization. The information is clear, concise, and most importantly, legitimate."- Peter B. Woodhull, President and Principal Architect, Modus21 "SOA Design Patterns offers real insights into everyday problems that one will encounter when investing in services oriented architecture. [It] provides a number of problem descriptions and offers strategies for dealing with these problems. SOA design patterns highlights more than just the technical problems and solutions. Common organizational issues that can hinder progress towards achieving SOA migration are explained along with potential approaches for dealing with these real world challenges. Once again Thomas Erl provides in-depth coverage of SOA terminology and helps the reader better understand and appreciate the complexities of migrating to an SOA environment."- David Michalowicz, Air and Space Operations Center Modernization Team Lead,MITRE Corporation "This is a long overdue, serious, comprehensive, and well-presented catalog of SOA design patterns. This will be required reading and reference for all our SOA engineers and architects. The best of the series so far! [The book] works in two ways: as a primer in SOA design and architecture it can easily be read front-to-back to get an overview of most of the key design issues you will encounter, and as a reference catalog of design techniques that can be referred to again and again..."- Wendell Ocasio, Architecture Consultant, DoD Military Health Systems, Agilex Technologies "Thomas has once again provided the SOA practitioner with a phenomenal collection ofknowledge. This is a reference that I will come back to time and time again as I move forward in SOA design efforts. What I liked most about this book is its vendor agnostic approach to SOA design patterns. This approach really presents the reader with an understanding of why or why not to implement a pattern, group patterns, or use compound patterns rather than giving them a marketing spiel on why one implementation of a pattern is better than another (for example, why one ESB is better than another). I think as SOA adoption continues to advance, the ability for architects to understand when and why to apply specific patterns will be a driving factor in the overall success and evolution of SOA. Additionally, I believe that this book provides the consumer with the understanding required to chose which vendor's SOA products are right for their specific needs."- Bryan Brew, SOA Consultant, Booz Allen Hamilton "A must have for every SOA practitioner."- Richard Van Schelven, Principal Engineer, Ericsson "This book is a long-expected successor to the books on object-oriented design patterns and integration patterns. It is a great reference book that clearly and thoroughly describes design patterns for SOA. A great read for architects who are facing the challenge of transforming their enterprise into a service-oriented enterprise."- Linda Terlouw, Solution Architect, Ordina "The maturation of Service-Orientation has given the industry time to absorb the best practices of service development. Thomas Erl has amassed this collective wisdom in SOA Design Patterns, an absolutely indispensible addition to any Service Oriented bookshelf."- Kevin P. Davis, Ph.D "The problem with most texts on SOA is one of specificity. Architects responsible for SOA implementation in most organizations have little time for abstract theories on the subject, but are hungry for concrete details that they can relate to the real problems they face in their environment. SOA Design Patterns is critical reading for anyone with service design responsibilities. Not only does the text provide the normal pattern templates, but each pattern is applied in detail against a background case study to provide exceptionally meaningful context to the information. The graphic visualizations of the problems and pattern solutions are excellent supplementary companions to the explanatory text. This book will greatly stretch the knowledge of the reader as much for raising and addressing issues that may have never occurred to the reader as it does in treating those problems that are in more common occurrence. The real beauty of this book is in its plain English prose. Unlike so many technical reference books, one does not find themselves re-reading sections multiple times trying to discern the intent of the author. This is also not a reference that will sit gathering dust on a shelf after one or two perusings. Practitioners will find themselves returning over and over to utilize the knowledge in their projects. This is as close as you'll come to having a service design expert sitting over your shoulder."- James Kinneavy, Principal Software Architect, University of California "As the industry converges on SOA patterns, Erl provides an outstanding reference guide to composition and integration-and yet another distinctive contribution to the SOA practice."- Steve Birkel, Chief IT Technical Architect, Intel Corp. "With SOA Design Patterns, Thomas Erl adds an indispensable SOA reference volume to the technologist's library. Replete with to-the-point examples, it will be a helpful aid to any IT organization."- Ed Dodds, Strategist, Systems Architect, Conmergence "Again, Thomas Erl has written an indispensable guide to SOA. Building on his prior successes, his patterns go into even more detail. Therefore, this book is not only helpful to the SOA beginner, but also provides new insight and ideas to professionals."- Philipp Offermann, Research Scientist, Technische Universitat Berlin, Germany "SOA Design Patterns is an extraordinary contribution to SOA best practices! Once again, Thomas has created an indispensable resource for any person or organization interested in or actively engaged in the practice of Service Oriented Architecture. Using case studies based on three very different business models, Thomas guides the reader through the process of selecting appropriate implementation patterns to ensure a flexible, well-performing, and secure SOA ecosystem."- Victor Brown, Managing Partner and Principal Consultant,Cypress Management Group Corporation In cooperation with experts and practitioners throughout the SOA community, best-selling author Thomas Erl brings together the de facto catalog of design patterns for SOA and service-orientation. More than three years in development and subjected to numerous industry reviews, the 85 patterns in this full-color book provide the most successful and proven design techniques to overcoming the most common and critical problems to achieving modern-day SOA. Through numerous examples, individually documented pattern profiles, and over 400 color illustrations, this book provides in-depth coverage of: * Patterns for the design, implementation, and governance of service inventories-collections of services representing individual service portfolios that can be independently modeled, designed, and evolved. * Patterns specific to service-level architecture which pertain to a wide range of design areas, including contract design, security, legacy encapsulation, reliability, scalability, and a variety of implementation and governance issues. * Service composition patterns that address the many aspects associated with combining services into aggregate distributed solutions, including topics such as runtime messaging and message design, inter-service security controls, and transformation. * Compound patterns (such as Enterprise Service Bus and Orchestration) and recommended pattern application sequences that establish foundational processes. The book begins by establishing SOA types that are referenced throughout the patterns and then form the basis of a final chapter that discusses the architectural impact of service-oriented computing in general. These chapters bookend the pattern catalog to provide a clear link between SOA design patterns, the strategic goals of service-oriented computing, different SOA types, and the service-orientation design paradigm. This book series is further supported by a series of resources sites, including soabooks.com, soaspecs.com, soapatterns.org, soamag.com, and soaposters.com.
Contents
Foreword...xxxviiCHAPTER 1... 41.2 Who this Book is For ... 41.3 What this Book Does Not Cover... 4Topics Covered by Other Books ...4Web Service and REST Service Design Patterns ... 5SOA Standardization Efforts... 51.4 Recommended Reading ... 61.5 How this Book is Organized... 7Part I: Fundamentals... 8Part II: Service Inventory Design Patterns... 8Part III: Service Design Patterns . . 8Part IV: Service Composition Design Patterns . . 9Part V: Supplemental. . . 10Part VI: Appendices . . . 101.6 Symbols, Figures, Style Conventions . . . 11Symbol Legend . . . 11How Color is Used 11Data Flow and Directionality Conventions . . 11Pattern Documentation Conventions . 111.7 Additional Information 11Updates, Errata, and Resources (www.soabooks.com) . . . . 11Visio Stencil (www.soabooks.com) . 12Community Patterns Site (www.soapatterns.org) . . . . . 12Master Glossary (www.soaglossary.com) 12Supplementary Posters (www.soaposters.com) 12The SOA Magazine (www.soamag.com) 12Referenced Specifications (www.soaspecs.com). . . . . 12Notification Service 13Contact the Author 13CHAPTER 2: Case Study Background . 152.1 Case #1 Background: Cutit Saws Ltd 17History 18Technical Infrastructure and Automation Environment . 18Business Goals and Obstacles. . 182.2 Case #2 Background: Alleywood Lumber Company . 19History 19Technical Infrastructure and Automation Environment . 20Business Goals and Obstacles. . 202.3 Case #3 Background: Forestry RegulatoryCommission (FRC) . . 21History 21Technical Infrastructure and Automation Environment . 21Business Goals and Obstacles. . 22PART I: FUNDAMENTALSCHAPTER 3: Basic Terms and Concepts . . . . . 25Purpose of this Introductory Chapter . . . 263.1 Architecture Fundamentals 26A Classic Analogy for Architecture and Infrastructure . 27Technology Architecture 27Technology Infrastructure . 30Software Program . 32Relationship to Design Framework . 333.2 Service-Oriented Computing Fundamentals. . . . 35Service-Oriented Computing . . . 35Service-Orientation 36Service-Oriented Architecture (SOA) . . . 37Service . . . . . 37Service Capability . 38Service Consumer. 38Service Composition . . . 40Service Inventory. . 42Service-Oriented Analysis. 43Service Candidate. 443.3 Service Implementation Mediums . . . 44Services as Components . 45Services as Web Services 45REST Services. . . . 46CHAPTER 4: The Architecture of Service-Orientation . . 47Purpose of this Introductory Chapter . . . 484.1 The Method of Service-Orientation 48Principles of Service-Orientation. 48Strategic Goals of Service-Oriented Computing. . . . . . 514.2 The Four Characteristics of SOA 52Business-Driven . . 53Vendor-Neutral . . . 54Enterprise-Centric . 58Composition-Centric . . . 594.3 The Four Common Types of SOA . 61Service Architecture . . . 62Information Hiding . . . . 64Design Standards . 64Service Contracts . 65Service Agents . . . 67Service Capabilities . . . 68Service Composition Architecture . 68Nested Compositions . . 72Task Services and Alternative Compositions . 73Compositions and Infrastructure. 74Service Inventory Architecture . . 74Service-Oriented Enterprise Architecture 76Architecture Types and Scope . . 77Architecture Types and Inheritance 77Other Forms of Service-Oriented Architecture . 78Inter-Business Service Architecture . . 78Service-Oriented Community Architecture . . 784.4 The End Result of Service-Orientation . . 79CHAPTER 5: Understanding SOA Design Patterns . 85Purpose of this Introductory Chapter . . . 865.1 Fundamental Terminology. 86What's a Design Pattern? . 86What's a Compound Pattern? . . . 88What's a Design Pattern Language? . 88What's a Design Pattern Catalog? . . . 895.2 Historical Influences 89Alexander's Pattern Language . . 90Object-Oriented Patterns . 91Software Architecture Patterns . . 92Enterprise Application Architecture Patterns . . 93EAI Patterns . 93SOA Patterns . . . . 945.3 Pattern Notation . 95Pattern Symbols . . 95Pattern Figures . . . 96Pattern Application Sequence Figures 96Pattern Relationship Figures. 96Compound Pattern Hierarchy Figures 99Capitalization. . . . 100Page Number References. 1005.4 Pattern Profiles . 100Requirement . . . . 101Icon . 101Summary . . 102Problem . . . . 102Solution . . . . 102Application . 103Impacts . . . . 103Relationships. . . . 103Case Study Example. . 1035.5 Patterns with Common Characteristics. 104Canonical Patterns . . . 104Centralization Patterns 1055.6 Key Design Considerations . . 106"Enterprise" vs. "Enterprise-wide" . . 106Design Patterns and Design Principles 106Design Patterns and Design Granularity . . 107Measures of Design Pattern Application . . 108PART II: SERVICE INVENTORY DESIGN PATTERNSCHAPTER 6: Foundational Inventory Patterns . . . 111How Inventory Design Patterns Relate to SOA DesignCharacteristics . . 113How Foundational Inventory and Service Patterns Relate . 114How Case Studies are Used in this Chapter. . 1146.1 Inventory Boundary Patterns . 114Enterprise Inventory . 116Problem . . . . 116Solution . . . . 117Application. . 118Impacts . . . . 120Relationships. . . . 121Case Study Example. . 122Domain Inventory . 123Problem . . . . 123Solution . . . . 124Application. . 125Impacts . . . . 126Relationships. . . . 127Case Study Example. . 1286.2 Inventory Structure Patterns 130Service Normalization. 131Problem . . . . 131Solution . . . . 132Application. . 132Impacts . . . . 133Relationships. . . . 133Case Study Example. . 135Logic Centralization . 136Problem . . . . 136Solution . . . . 137Application. . 137Impacts . . . . 139Relationships. . . . 140Case Study Example. . 142Service Layers 143Problem . . . . 143Solution . . . . 144Application. . 145Impacts . . . . 147Relationships. . . . 147Case Study Example. . 1486.3 Inventory Standardization Patterns 149Canonical Protocol 150Problem . . . . 151Solution . . . . 152Application. . 153Impacts . . . . 155Relationships. . . . 155Case Study Example. . 157Canonical Schema 158Problem . . . . 158Solution . . . . 159Application. . 159Impacts . . . . 159Relationships. . . . 160Case Study Example. . 161CHAPTER 7: Logical Inventory Layer Patterns . . . 163Combining Layers 164Business Logic and Utility Logic . . . 166Agnostic Logic and Non-Agnostic Logic 166Service Layers and Logic Types . . . 167Utility Abstraction . 168Problem . . . . 168Solution . . . . 169Application. . 170Impacts . . . . 171Relationships. . . . 171Case Study Example. . 173Entity Abstraction . 175Problem . . . . 175Solution . . . . 176Application. . 176Impacts . . . . 178Relationships. . . . 178Case Study Example. . 180Process Abstraction . 182Problem . . . . 182Solution . . . . 183Application. . 184Impacts . . . . 185Relationships. . . . 185Case Study Example. . 187CHAPTER 8: Inventory Centralization Patterns . . 191Process Centralization 193Problem . . . . 193Solution . . . . 194Application. . 195Impacts . . . . 196Relationships. . . . 197Case Study Example. . 198Schema Centralization 200Problem . . . . 200Solution . . . . 201Application. . 202Impacts . . . . 202Relationships. . . . 203Case Study Example. . 203Policy Centralization . 207Problems . . . 207Solution . . . . 208Application. . 209Impacts . . . . 210Relationships. . . . 211Case Study Example. . 213Rules Centralization . 216Problem . . . . 216Solution . . . . 217Application. . 217Impacts . . . . 218Relationships. . . . 219Case Study Example. . 222CHAPTER 9: Inventory Implementation Patterns . 225Dual Protocols 227Problem . . . . 228Solution . . . . 228Application. . 228Impacts . . . . 233Relationships. . . . 234Case Study Example. . 235Canonical Resources 237Problem . . . . 238Solution . . . . 238Application. . 239Impacts . . . . 239Relationships. . . . 239Case Study Example. . 241State Repository . . 242Problem . . . . 242Solution . . . . 243Application. . 244Impacts . . . . 244Relationships. . . . 244Case Study Example. . 246Stateful Services . . 248Problem . . . . 248Solution . . . . 248Application. . 250Impacts . . . . 250Relationships. . . . 250Case Study Example. . 251Service Grid . . 254Problem . . . . 254Solution . . . . 255Application. . 256Impacts . . . . 257Relationships. . . . 258Case Study Example. . 259Inventory Endpoint 260Problem . . . . 260Solution . . . . 261Application. . 262Impacts . . . . 263Relationships. . . . 263Case Study Example. . 265Cross-Domain Utility Layer 267Problem . . . . 267Solution . . . . 268Application. . 269Impacts . . . . 269Relationships. . . . 270Case Study Example. . 270CHAPTER 10: Inventory Governance Patterns . . . 273Canonical Expression. 275Problem . . . . 275Solution . . . . 275Application. . 276Impacts . . . . 277Relationships. . . . 278Case Study Example. . 279Metadata Centralization . . . 280Problem . . . . 280Solution . . . . 281Application. . 282Impacts . . . . 283Relationships. . . . 283Case Study Example. . 284Canonical Versioning 286Problem . . . . 286Solution . . . . 287Application. . 287Impacts . . . . 288Relationships. . . . 288Case Study Example. . 290PART III: SERVICE DESIGN PATTERNSCHAPTER 11: Foundational Service Patterns . . . . 295Case Study Background 29711.1 Service Identification Patterns . 299Functional Decomposition . 300Problem . . . . 300Solution . . . . 301Application. . 302Impacts . . . . 302Relationships. . . . 303Case Study Example. . 303Service Encapsulation 305Problem . . . . 305Solution . . . . 306Application. . 307Impacts . . . . 309Relationships. . . . 309Case Study Example. . 31011.2 Service Definition Patterns 311Agnostic Context. . 312Problem . . . . 313Solution . . . . 314Application. . 315Impacts . . . . 315Relationships. . . . 316Case Study Example. . 317Non-Agnostic Context 319Problem . . . . 319Solution . . . . 320Application. . 321Impacts . . . . 322Relationships. . . . 322Case Study Example. . 323Agnostic Capability324Problem . . . . 324Solution . . . . 325Application. . 326Impacts . . . . 327Relationships. . . . 327Case Study Example. . 328CHAPTER 12: Service Implementation Patterns. . 331Service Facade . . . 333Problem . . . . 333Solution . . . . 334Application. . 335Impacts . . . . 341Relationships. . . . 342Case Study Example. . 343Redundant Implementation 345Problem . . . . 345Solution . . . . 346Application. . 346Impacts . . . . 347Relationships. . . . 348Case Study Example. . 349Service Data Replication . . 350Problem . . . . 350Solution . . . . 352Application. . 353Impacts . . . . 353Relationships. . . . 353Case Study Example. . 354Partial State Deferral . 356Problem . . . . 356Solution . . . . 357Application. . 358Impacts . . . . 359Relationships. . . . 359Case Study Example. . 360Partial Validation . . 362Problem . . . . 362Solution . . . . 363Application. . 364Impacts . . . . 364Relationships. . . . 364Case Study Example. . 365UI Mediator. . . 366Problem . . . . 366Solution . . . . 367Application. . 368Impacts . . . . 369Relationships. . . . 370Case Study Example. . 370CHAPTER 13: Service Security Patterns . . . 373Case Study background 374Exception Shielding . 376Problem . . . . 376Solution . . . . 377Application. . 378Impacts . . . . 379Relationships. . . . 379Case Study Example. . 380Message Screening381Problem . . . . 381Solution . . . . 382Application . 382Impacts . . . . 384Relationships. . . . 385Case Study Example. . 385Trusted Subsystem 387Problem . . . . 387Solution . . . . 388Application. . 388Impacts . . . . 391Relationships. . . . 391Case Study Example. . 392Service Perimeter Guard 394Problem . . . . 394Solution . . . . 395Application . 395Impacts . . . . 396Relationships. . . . 396Case Study Example. . 397CHAPTER 14: Service Contract Design Patterns . 399Decoupled Contract . 401Problem . . . . 401Solution . . . . 402Application. . 403Impacts . . . . 405Relationships. . . . 405Case Study Example. . 407Contract Centralization . 409Problem . . . . 409Solution . . . . 410Application. . 410Impacts . . . . 411Relationships. . . . 411Case Study Example. . 413Contract Denormalization. . 414Problem . . . . 414Solution . . . . 415Application. . 416Impacts . . . . 417Relationships. . . . 417Case Study Example. . 418Concurrent Contracts 421Problem . . . . 421Solution . . . . 422Application. . 423Impacts . . . . 425Relationships. . . . 425Case Study Example. . 426Validation Abstraction 429Problem . . . . 429Solution . . . . 430Application. . 431Impacts . . . . 432Relationships. . . . 432Case Study Example. . 433Chapter 15: Legacy Encapsulation Patterns . . . 439Legacy Wrapper. . . 441Problem . . . . 441Solution . . . . 442Application. . 443Impacts . . . . 444Relationships. . . . 444Case Study Example. . 446Multi-Channel Endpoint . . . 451Problem . . . . 451Solution . . . . 452Application. . 453Impacts . . . . 454Relationships. . . . 454Case Study Example. . 456File Gateway . 457Problem . . . . 457Solution . . . . 458Application. . 458Impacts . . . . 459Relationships. . . . 460Case Study Example. . 461CHAPTER 16: Service Governance Patterns. . . . . 463Compatible Change465Problem . . . . 465Solution . . . . 466Application. . 466Impacts . . . . 469Relationships. . . . 469Case Study Example. . 470Version Identification 472Problem . . . . 472Solution . . . . 473Application. . 473Impacts . . . . 474Relationships. . . . 474Case Study Example. . 475Termination Notification . . . 478Problem . . . . 478Solution . . . . 479Application. . 480Impacts . . . . 480Relationships. . . . 481Case Study Example. . 481Service Refactoring484Problem . . . . 484Solution . . . . 485Application. . 485Impacts . . . . 486Relationships. . . . 486Case Study Example. . 488Service Decomposition . 489Problem . . . . 489Solution . . . . 491Application. . 492Impacts . . . . 492Relationships. . . . 494Case Study Example. . 495Proxy Capability . . 497Problem . . . . 497Solution . . . . 498Application. . 498Impacts . . . . 500Relationships. . . . 500Case Study Example. . 501Decomposed Capability . . . 504Problem . . . . 504Solution . . . . 506Application. . 507Impacts . . . . 507Relationships. . . . 508Case Study Example. . 508Distributed Capability 510Problem . . . . 510Solution . . . . 511Application. . 512Impacts . . . . 513Relationships. . . . 513Case Study Example. . 514PART IV: SERVICE COMPOSITION DESIGN PATTERNSCHAPTER 17: Capability Composition Patterns . . 519Capability Composition . . . 521Problem . . . . 521Solution . . . . 521Application. . 523Impacts . . . . 523Relationships. . . . 523Case Study Example. . 524Capability Recomposition . 526Problem . . . . 526Solution . . . . 527Application. . 527Impacts . . . . 527Relationships. . . . 529Case Study Example. . 530CHAPTER 18: Service Messaging Patterns. . 531Service Messaging 533Problem . . . . 533Solution . . . . 533Application. . 534Impacts . . . . 534Relationships. . . . 535Case Study Example. . 536Messaging Metadata 538Problem . . . . 538Solution . . . . 538Application. . 539Impacts . . . . 540Relationships. . . . 541Case Study Example. . 542Service Agent 543Problem . . . . 543Solution . . . . 544Application. . 544Impacts . . . . 546Relationships. . . . 546Case Study Example. . 548Intermediate Routing 549Problem . . . . 549Solution . . . . 551Application. . 552Impacts . . . . 553Relationships. . . . 553Case Study Example. . 556State Messaging . . 557Problem . . . . 557Solution . . . . 558Application. . 560Impacts . . . . 561Relationships. . . . 561Case Study Example. . 562Service Callback . . 566Problem . . . . 566Solution . . . . 568Application. . 568Impacts . . . . 570Relationships. . . . 570Case Study Example. . 571Service Instance Routing . . 574Problem . . . . 574Solution . . . . 576Application. . 576Impacts . . . . 578Relationships. . . . 578Case Study Example. . 579Asynchronous Queuing . . . 582Problem . . . . 582Solution . . . . 584Application. . 584Impacts . . . . 587Relationships. . . . 588Case Study Example. . 589Reliable Messaging 592Problem . . . . 592Solution . . . . 593Application. . 593Impacts . . . . 594Relationships. . . . 595Case Study Example. . 596Event-Driven Messaging 599Problem . . . . 599Solution . . . . 600Application. . 602Impacts . . . . 602Relationships. . . . 602Case Study Example. . 604CHAPTER 19: Composition Implementation Patterns . . 605Agnostic Sub-Controller 607Problem . . . . 607Solution . . . . 608Application. . 610Impacts . . . . 610Relationships. . . . 610Case Study Example. . 612Composition Autonomy . . . 616Problem . . . . 616Solution . . . . 618Application. . 619Impacts . . . . 619Relationships. . . . 620Case Study Example. . 620Atomic Service Transaction 623Problem . . . . 623Solution . . . . 624Application. . 626Impacts . . . . 626Relationships. . . . 628Case Study Example. . 629Compensating Service Transaction . . 631Problem . . . . 631Solution . . . . 633Application. . 633Impacts . . . . 635Relationships. . . . 635Case Study Example. . 636CHAPTER 20: Service Interaction Security Patterns . . 639Data Confidentiality641Problem . . . . 641Solution . . . . 643Application. . 643Impacts . . . . 644Relationships. . . . 645Case Study Example. . 646Data Origin Authentication. 649Problem . . . . 649Solution . . . . 650Application. . 651Impacts . . . . 652Relationships. . . . 653Case Study Example. . 653Direct Authentication 656Problem . . . . 656Solution . . . . 657Application. . 657Impacts . . . . 658Relationships. . . . 659Case Study Example. . 660Brokered Authentication 661Problem . . . . 661Solution . . . . 662Application. . 663Impacts . . . . 665Relationships. . . . 665Case Study Example. . 666CHAPTER 21: Transformation Patterns . . . . 669Data Model Transformation 671Problem . . . . 671Solution . . . . 672Application. . 673Impacts . . . . 674Relationships. . . . 674Case Study Example. . 677Data Format Transformation . . . 681Problem . . . . 681Solution . . . . 681Application. . 683Impacts . . . . 683Relationships. . . . 683Case Study Example. . 685Protocol Bridging . 687Problem . . . . 687Solution . . . . 688Application. . 688Impacts . . . . 690Relationships. . . . 690Case Study Example. . 692PART V: SUPPLEMENTALCHAPTER 22: Common Compound Design Patterns . . . 697"Compound" vs. "Composite" . . . 698Compound Patterns and Pattern Relationships . . . 698Joint Application vs. Coexistent Application. . . . . . 699Compound Patterns and Pattern Granularity . . . . . 700Orchestration. 701Enterprise Service Bus . 704Service Broker 707Canonical Schema Bus . 709Official Endpoint . . 711Federated Endpoint Layer . 713Three-Layer Inventory. 715CHAPTER 23: Strategic Architecture Considerations. . 717Increased Federation . 718Increased Intrinsic Interoperability . . 721Increased Vendor Diversification Options. . 723Increased Business and Technology Alignment. . . 725Increased ROI . 727Increased Organizational Agility 728Reduced IT Burden. 729CHAPTER 24: Principles and Patterns at theU.S. Department of Defense . 731The Business Operating Environment (BOE) . . . . . 733Principles, Patterns, and the BOE . . 734Incorporation of Information Assurance (IA) . . 736Adherence to Standards . 736Data Visibility, Accessibility, and Understandability toSupport Decision Makers 736Loosely Coupled Services 736Authoritative Sources of Trusted Data 737Metadata-Driven Framework for Separation fromTechnical Details . 737Support Use of Open Source Software . . . 738Emphasize Use of Service-Enabled CommercialOff-the-Shelf (COTS) Software . 738Participation in the DoD Enterprise 738Support Mobility - Users & Devices . . 738The Future of SOA and the DoD 739SOADoD.org . . 739PART VI: APPENDICESAPPENDIX A: Case Study Conclusion 743Cutit Saws Ltd. 744Alleywood Lumber Company 744Forestry Regulatory Commission (FRC) . . . 745APPENDIX B: Candidate Patterns . . 747APPENDIX C: Principles of Service-Orientation . . 749Standardized Service Contract . 751Service Loose Coupling 753Service Abstraction . 755Service Reusability . 756Service Autonomy . . 758Service Statelessness . 760Service Discoverability 762Service Composability 764APPENDIX D: Patterns and PrinciplesCross-Reference . . . 767APPENDIX E: Patterns and Architecture TypesCross-Reference . . . 775About the Author . . . 783About the Contributors . 784Index of Patterns . . . 791Index . 795
