9780321504722

Putting Service-Oriented Architecture (SOA) into Practice This book is a must-have for enterprise architects implementing SOA. Through practical examples, it explains the relationship between business requirements, business process design, and service architecture. By tying the SOA implementation directly to business value, it reveals the key to ongoing success and funding. -Maja Tibbling, Lead Enterprise Architect, Con-way, Inc. While there are other books on architecture and the implementation of ESB, SOA, and related technologies, this new book uniquely captures the knowledge and experience of the real world. It shows how you can transform requirements and vision into solid, repeatable, and value-added architectures. I heartily recommend it. -Mark Wencek, SVP, Consulting Services & Alliances, Ultimo Software Solutions, Inc. In his first book,Succeeding with SOA, Paul Brown explained that if enterprise goals are to be met, business processes and information systems must be designed together as parts of a total architecture. In this second book,Implementing SOA, he guides you through the entire process of designing and developing a successful total architecture at both project and enterprise levels. Drawing on his own extensive experience, he provides best practices for creating services and leveraging them to create robust and flexible SOA solutions. Coverage includes Evolving the enterprise architecture towards an SOA while continuing to deliver business value on a project-by-project basis Understanding the fundamentals of SOA and distributed systems, the dominant architectural issues, and the design patterns for addressing them Understanding the distinct roles of project and enterprise architects and how they must collaborate to create an SOA Understanding the need for a comprehensive total architecture approach that encompasses business processes, people, systems, data, and infrastructure Understanding the strategies and tradeoffs for implementing robust, secure, high-performance, and high-availability solutions Understanding how to incorporate business process management (BPM) and business process monitoring into the enterprise architecture Whether yours"re defining an enterprise architecture or delivering individual SOA projects, this book will give you the practical advice you need to get the job done.

Paul C. Brown is Principal Software Architect at TIBCO, a world leader in enterprise software and services (www.tibco.com). His model-based tool architectures underlie applications ranging from process control interfaces to NASA satellite mission planning. Dr. Brown’s extensive work on enterprise-scale information systems led him to develop the total architecture concept introduced in his first book, Succeeding with SOA: Realizing Business Value Through Total Architecture (Addison-Wesley, 2007). He received his Ph.D. in computer science from Rensselaer Polytechnic Institute.

Preface	p. xxvii
Fundamentals	p. 1
SOA and the Enterprise	p. 3
The Challenge	p. 4
The Concept of Total Architecture	p. 5
Architecture Is Structure for a Purpose	p. 6
Constant Changes	p. 7
Total Architecture Synthesis	p. 8
Making Total Architecture Work in Your Enterprise	p. 9
Key Overview Questions	p. 10
Architecture Fundamentals	p. 11
Structural Organization	p. 11
Functional Organization	p. 15
Collaborative Behavior	p. 20
Total Architecture	p. 26
Nonfunctional Requirements	p. 27
Refinement	p. 28
The Role of the Architect	p. 29
Enterprise Architecture	p. 30
Summary	p. 34
Key Architecture Fundamentals Questions	p. 35
Suggested Reading	p. 36
Service Fundamentals	p. 37
What Is a Service?	p. 37
Operations	p. 38
Service Interfaces	p. 47
The Rationale Behind Services	p. 54
Summary	p. 58
Key Service Fundamentals Questions	p. 59
Suggested Reading	p. 60
Using Services 61 Service Interaction Patterns	p. 61
Service Access	p. 67
Access Control	p. 72
Service Request Routing	p. 76
Service Composition	p. 80
Locating Services	p. 85
Enterprise Architecture for Services	p. 86
Summary	p. 87
Key Service Utilization Questions	p. 88
Suggested Reading	p. 89
The SOA Development Process	p. 91
What Is Different about SOA Development?	p. 91
The Overall Development Process	p. 92
Architecture Tasks	p. 94
Architecture in Context	p. 96
Total Architecture Synthesis (TAS)	p. 97
Beware of Look-Alike Processes!	p. 105
Manage Risk: Architect Iteratively	p. 106
Summary	p. 108
Key Development Process Questions	p. 108
Suggested Reading	p. 109
The Business Process Perspective	p. 111
Processes	p. 113
Triggers, Inputs, and Results	p. 114
Related Processes	p. 115
Process Maturity	p. 116
Continuous Processes	p. 119
Structured Processes	p. 120
Summary	p. 121
Key Process Questions	p. 122
Suggested Reading	p. 122
Initial Project Scoping	p. 123
Assembling the Business Process Inventory	p. 124
Conducting Interviews	p. 125
Documenting the Inventory	p. 128
Ranking Business Processes	p. 141
Organizing the Remaining Work	p. 147
Summary	p. 149
Key Scoping Questions	p. 150
The Artifice of Requirements	p. 151
Differentiation	p. 153
Characterizing Processes	p. 159
Patterns of Interaction	p. 163
Interaction Patterns Characterize Participants	p. 171
Requirements Reflect Design	p. 172
Summary	p. 175
Key Requirements Questions	p. 177
Suggested Reading	p. 178
Business Process Architecture	p. 179
Results	p. 180
Participants and Their Roles	p. 182
Activities and Scenarios	p. 186
Modeling Scenarios	p. 191
Modeling Interactions	p. 198
How Much Detail Is Enough?	p. 204
Guidelines for Using Activity Diagrams	p. 206
Summary	p. 207
Key Business Process Architecture Questions	p. 208
Suggested Reading	p. 209
Milestones	p. 211
Basic Process Milestones	p. 211
Variations in Milestone Sequences	p. 214
Grouped Milestones	p. 215
Recognizing Milestones Requires Design	p. 216
Using Milestones to Reduce Inter-Process Coupling	p. 217
Summary	p. 218
Key Milestone Questions	p. 219
Process Constraints	p. 221
Business Process Constraints Drive System Constraints	p. 222
Performance Constraints	p. 224
High Availability and Fault Tolerance	p. 231
Security	p. 238
Reporting, Monitoring, and Management	p. 240
Exception Handling	p. 242
Test and Acceptance	p. 243
Compliance Constraints	p. 245
Summary	p. 246
Key Process Constraint Questions	p. 247
Suggested Reading	p. 248
Related Processes	p. 249
Identifying Services	p. 252
Triggering Events	p. 258
Summary	p. 264
Key Related Process Questions	p. 265
Modeling the Domain	p. 267
UML Class Notation	p. 269
ATM Example Domain Model	p. 274
Reverse Engineering the Domain Model	p. 276
Domain Modeling Summary	p. 277
Key Domain Modeling Ques
Table of Contents provided by Publisher. All Rights Reserved.

What is included with this book?

The New copy of this book will include any supplemental materials advertised. Please check the title of the book to determine if it should include any access cards, study guides, lab manuals, CDs, etc.

The Used, Rental and eBook copies of this book are not guaranteed to include any supplemental materials. Typically, only the book itself is included. This is true even if the title states it includes any access cards, study guides, lab manuals, CDs, etc.

If you are an architect responsible for a service-oriented architecture (SOA) in an enterprise, you face many challenges. Whether intended or not, the architecture you create defines the structure of your enterprise at many different levels, from business processes down to data storage. It defines the boundaries between organizational units as well as between business systems. Your architecture must go beyond defining services and provide practical solutions for host of complex distributed system design problems from orchestrating business processes to ensuring business continuity. Implementing your architecture will involve many projects over an extended period, and your guidance will be required. InSucceeding With SOA, I discussed the need for an enterprise to pay close attention to its architecture, the role of its architects, and the importance of setting the right organizational context for their success. In this book,Implementing SOA, I turn to the work of the architects themselves - your work - guiding you through the process of defining a service-oriented architecture at both the project and enterprise levels. Whether you are an architect putting SOA into practice or you are an engineer aspiring to be architect and wanting to learn more, I wrote this book for you. Doing SOA well can be very rewarding. Done properly, your enterprise will comprise a robust and flexible collection of reusable business process and infrastructure services. The enterprise will be able to efficiently recombine these services to address changing business needs. On the other hand, if you do SOA poorly, your enterprise will be encumbered with a fragile and rigid set of functionality (which I hesitate to call services) that will retard rather than promote enterprise evolution. You don't want to end up there.Implementing SOAwill show you the pitfalls as well as the best practices. In short, it will guide you to doing SOA well. The SOA Architectural Challenges Doing SOA well presents you with four interrelated architectural challenges. Services define the structure of both business processes and systems. Business processes and systems have become so hopelessly intertwined that it is no longer possible to design one without altering the other. They have to be designed together---a concept I calltotal architecture. Thus building your service-oriented architecture is not just a technical exercise---it is a business exercise that requires the active participation of the business side of the house. You are not building your SOA from scratch. Your enterprise today operates using a working set of business processes and systems. You can't afford to disrupt business operations just because you want to build an SOA. Practically speaking, you need to evolve your existing business processes and systems into an SOA. During this transition, individual projects must continue to deliver tangible business value, independent of your SOA initiative. Your SOA is a vision that requires a consistent interpretation as it is put into practice. The actual implementation of your SOA will happen piecemeal, project by project. Services that are developed in today's project must satisfy future needs, and today's projects must leverage the services developed in yesterday's projects. Ensuring that existing services are appropriately used and that new services will meet future needs requires coordination and planning across multiple projects, both present and future. A service-oriented architecture is actually a distributed system. As such, your SOA must incorporate self-consistent solutions to all of the classic distributed system design problems: trading off service granularity against communications delays, coping with communications breakdowns, managing information that is distributed across services and sites, coordinating service execution and load distribution, ensuring service and

Amazon no longer offers textbook rentals. We do!

Implementing SOA Total Architecture in Practice

Implementing SOA Total Architecture in Practice

0321504720

Summary

Author Biography

Table of Contents

Supplemental Materials

Excerpts

Write a Review