Architecting Composite Applications and Services with TIBCO

“Paul Brown has done a favor for the TIBCO community and anyone wanting to get into this product set. Architecting TIBCO solutions without knowing the TIBCO architecture fundamentals and having insight to the topics discussed in this book is risky to any organization. I fully recommend this book to anyone involved in designing solutions using the TIBCO ActiveMatrix products.” —Nikky Sooriakumar, TIBCO Architect, PruHealth   “An effective primer for building composite services using TIBCO, this book provides a holistic approach to strategy integrated with implementation details. I find it tremendously useful in moving recursively from business solutions to design patterns to architecture. Tangible examples are provided that build to composite services. And advanced topics are explored that add another valuable implementation dimension. I recommend this book to software architects who need to quickly build an effective business- services-oriented environment.” —Abby H. Brown, Ph.D., Enterprise Architect, Intel Corp.  The architecture series from TIBCO® Press comprises a coordinated set of titles for software architects and developers, showing how to combine TIBCO components to design and build real-world solutions. TIBCO’s product suite comprises components with functionality ranging from messaging through services, service orchestration, business process management, master data management, and complex event processing.   In composite applications and services, multiple components collaborate to provide the required functionality. There are many possible architectures for these distributed solutions: Some will serve the enterprise well, while others will lead to dead-end projects. Architecting Composite Applications and Services with TIBCO® shows how to create successful architectures with TIBCO products for both overall solutions and individual services. This guide builds on the basic design patterns and product information presented in the first title in the series, TIBCO® Architecture Fundamentals (Addison-Wesley, 2011).   After reading this title, you will be able to Create architectures for solutions, service specifications, and service implementations Understand the intended TIBCO product roles in composite applications and services Define manageable approaches to service versioning and naming Conduct and interpret performance benchmarks Identify and select appropriate design patterns for a variety of tasks  Architecting Composite Applications and Services with TIBCO® is intended primarily for project architects defining overall solutions and specifying the supporting components and services. TIBCO developers, enterprise architects, and technical managers will also find material of interest. No specific prior knowledge of architecture is assumed.

Table of Contents:
Preface xxv Acknowledgments xxxiii About the Author xxxv Part I: Getting Started 1 Chapter 1: Components, Services, and Architectures 3 Objectives 3 Architecture Views 4 A Hierarchy of Architectures 7 Why Make These Architecture Distinctions? 11 Design Patterns: Reference Architectures 13 Solution Architecture 14 Service Architecture 17 Service Utilization Pattern 17 Composite Service Architecture 20 Service Utilization Contract 22 Component Life Cycle 22 Summary 23   Chapter 2: TIBCO® Architecture Fundamentals Review 25 Objectives 25 Products Covered in TIBCO® Architecture Fundamentals 25 ActiveMatrix Deployment Options 31 Design Patterns 33 ActiveMatrix Service Bus Policies 44 Summary 46   Chapter 3: TIBCO Products 47 Objectives 47 Hawk® 48 TIBCO® Managed File Transfer Product Portfolio 56 Mainframe and iSeries Integration 58 BusinessConnect™ 63 TIBCO Collaborative Information Manager 64 Summary 65   Chapter 4: Case Study: Nouveau Health Care 67 Objectives 67 Nouveau Health Care Solution Architecture 68 Payment Manager Service Specification 73 Payment Manager Specification: Process Overview 74 Payment Manager Specification: Domain Model 77 Payment Manager Specification: Interfaces 82 Payment Manager Specification: Processes 83 Summary 91   Part II: Designing Services 93   Chapter 5: Observable Dependencies and Behaviors 95 Objectives 95 The Black Box Perspective 96 Facets of Observable Dependencies and Behaviors 97 Example: Sales Order Service 97 Characterizing Observable Dependencies and Behaviors 111 Some Composites May Not Be Suitable for Black Box Characterization 117 Summary 119   Chapter 6: Service-Related Documentation 121 Objectives 121 Service One-Line Description and Abstract 122 Service Specification Contents 123 Example Service Specification: Payment Manager 128 Service Usage Contracts 142 Service Architecture 144 Summary 149   Chapter 7: Versioning 151 Objectives 151 Dependencies and Compatibility 152 Packages 152 OSGI Versioning 153 WSDL and XML Schema Versioning 156 Version Number Placement for WSDLs and XML Schemas 159 Backwards-Compatible WSDL and XML Schema Changes 160 Incompatible Changes 163 Rules for Versioning WSDLs and Schemas 164 Architecture Patterns for Versioning 165 Versioning SOAP Interface Addresses (Endpoints) 168 Versioning the SOAP Action 168 How Many Versions Should Be Maintained? 169 Summary 171   Chapter 8: Naming Standards 173 Objectives 173 Using This Chapter 174 Concepts 174 What Needs a Name? 182 Structured Name Design Principles 183 Applying Naming Principles 191 Complicating Realities 205 Developing Your Standard 211 Summary 212   Chapter 9: Data Structures 215 Objectives 215 Domain Models 215 Information Models 218 Data Structure Design 220 Common Data Models 224 Designing an XML Schema 227 Organizing Schema and Interfaces 233 Example Schema 235 Summary 235   Part III: Service Architecture Patterns 237   Chapter 10: Building-Block Design Patterns 239 Objectives 239 Solution Architecture Decisions 240 Separating Interface and Business Logic 240 Design Pattern: Separate Interface and Business Logic 241 Using Services for Accessing Back-End Systems 243 Rule Service Governing Process Flow 244 Rule Services and Data 250 Business Exceptions: Services Returning Variant Business Responses 252 Asynchronous JMS Request-Reply Interactions 257 Supporting Dual Coordination Patterns 261 Summary 262   Chapter 11: Load Distribution and Sequencing Patterns 265 Objectives 265 Using IP Redirectors to Distribute Load 266 Using JMS Queues to Distribute Load 266 Partitioning JMS Message Load between Servers 267 Enterprise Message Service Client Connection Load Distribution 269 Load Distribution in ActiveMatrix Service Bus 271 The Sequencing Problem 273 Patterns That Preserve Total Sequencing 275 Load Distribution Patterns That Preserve Partial Ordering 278 Summary 280   Chapter 12: Data Management Patterns 283 Objectives 283 System-of-Record Pattern 284 System of Record with Cached Read-Only Copies Pattern 285 Replicated Data with Transactional Update Pattern 286 Edit-Anywhere-Reconcile-Later Pattern 287 Master-Data-Management Pattern 288 Summary 290   Chapter 13: Composites 293 Objectives 293 What Is a Composite? 293 Specifying a Composite 294 Architecting a Composite 294 Composite Services and Applications 303 Information Retrieval Design Patterns 304 TIBCO ActiveMatrix Composite Implementation 307 Summary 308   Part IV: Advanced Topics 311   Chapter 14: Benchmarking 313 Objectives 313 Misleading Results 314 Determining Operating Capacity 316 Documenting the Test Design 317 Benchmarking Complex Components 324 Interpreting Benchmark Results 327 Using Benchmark Results 336 Summary 338   Chapter 15: Tuning 341 Objectives 341 ActiveMatrix Service Bus Node Architecture 341 ActiveMatrix BusinessWorks™ Service Engine Architecture 357 Summary 369   Chapter 16: Fault Tolerance and High Availability 371 Objectives 371 Common Terms 372 Deferred JMS Acknowledgement Pattern 373 Intra-Site Cluster Failover Pattern 374 Generic Site Failover 377 Enterprise Message Service Failover 381 ActiveMatrix BusinessWorks Failover 385 ActiveMatrix Service Bus Failover 390 An Example of a 99.999% Availability Environment for the Enterprise Message Service 391 Summary 396   Chapter 17: Service Federation 401 Objectives 401 Factors Leading to Federation 402 Issues in Federation 402 Basic Federation Pattern 403 Federation with Remote Domain Pattern 405 Distributed Federation Pattern 406 Standardizing Service Domain Technology 407 Summary 407   Chapter 18: Documenting a Solution Architecture 409 Business Objectives and Constraints 409 Solution Context 410 Business Process Inventory 410 Domain Model 410 Solution Architecture Pattern 411 Business Process 1 411 Business Process 2 411 Business Process n 412 Addressing Nonfunctional Solution Requirements 412 Component/Service A 413 Component/Service B 415 Component/Service n 415 Deployment 416 Integration and Testing Requirements 416 Appendix A: Common Data Format Specifications 417 Appendix B: Message Format Specifications 417 Appendix C: Service Interface Specifications 417 Appendix D: Data Storage Specifications 417   Chapter 19: Documenting a Service Specification 419 Service Overview 419 Service Context 420 Intended Utilization Scenarios 420 Interface Definitions 421 Referenced Components 421 Observable State 421 Triggered Behaviors 422 Coordination 422 Constraints 422 Nonfunctional Behavior 422 Deployment 423 Appendix A: Service Interface Specifications 423 Appendix B: Referenced Interface Specifications 423   Afterword 425   Appendix A: UML Notation Reference 427 Class Diagram Basics 427 Structure 432 Activity Diagrams 437 Collaborations 440 State Machines 441 Appendix B: WSDLs and Schemas from Examples 443 Sales Order Example 443   Index 453  

About the Author :
Dr. Paul C. Brown , a Principal Software Architect at TIBCO Software Inc., is the author of Succeeding with SOA (Addison-Wesley, 2007), Implementing SOA (Addison-Wesley, 2008), and TIBCO® Architecture Fundamentals (Addison-Wesley, 2011), and is a coauthor of the SOA Manifesto ( soa-manifesto.org). Dr. Brown’s extensive design work on enterprise-scale information systems led him to develop the concept of total architecture, which explains how business processes and information systems are so intertwined that they must be architected together.