Implementing SOA: Total Architecture in Practice

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 96%)
Other sellers (Paperback)
  • All (17) from $1.99   
  • New (9) from $50.67   
  • Used (8) from $1.99   

Overview

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 you’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.

Read More Show Less

Product Details

  • ISBN-13: 9780321504722
  • Publisher: Addison-Wesley
  • Publication date: 4/25/2008
  • Series: TIBCO Press Series
  • Edition description: New Edition
  • Pages: 699
  • Product dimensions: 7.00 (w) x 9.24 (h) x 1.34 (d)

Meet the Author

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.
Read More Show Less

Read an Excerpt

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 a 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.

In Succeeding 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 an 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 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 offunctionality (which I hesitate to call services) that will retard rather than promote enterprise evolution. You don't want to end up there. Implementing SOA will 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.

  1. 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 call total architecture. Thus, building your service-oriented architecture is not just a technical exercise, it is also a business exercise that requires the active participation of the business side of the house.
  2. 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.
  3. 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.
  4. 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 business process availability and fault tolerance, securing your information, and monitoring and managing both business processes and services. The requirements driving your solution choices stem from the needs of the business processes involved and are thus tied in with business process design as well as systems design. As before, solutions to these problems require consistent approaches across all of your projects.

At the end of the day, your challenge as an architect is to organize your enterprise's collaboration between business processes, people, information, and systems, and to focus it on achieving your enterprise's goals.About the Book

Implementing SOA is a comprehensive guide to addressing your architectural challenges. It shows you how to smoothly integrate the design of both business processes and business systems. It will tell you how to evolve your existing architecture to achieve your SOA objectives, maintaining operational support for the enterprise during the transition. It demonstrates how to use a proactive enterprise architecture group to bring a consistent and forward-looking architectural perspective to multiple projects. Finally, it shows you how to address the full spectrum of distributed system design issues that you will face.

This book is organized into nine parts. Part I presents the fundamental concepts of architecture, services, and the total architecture synthesis methodology. Parts II through VIII discuss a series of architectural design issues, ranging from understanding business processes to monitoring and testing your architecture. Part IX then builds on these discussions to address the large-scale issues associated with complex business processes and workflow, concluding with a summary discussion of the workings of the enterprise architecture group.

In Parts II through VIII, each of the architecture topics is discussed from two perspectives: the project perspective and the enterprise architecture perspective. Each part first discusses the design issues as though the project architect were creating the entire architecture from scratch. The last chapter in each part then addresses the realities of a multiproject environment and the role that the enterprise architecture group must play to ensure that the design issues are appropriately addressed throughout the total architecture. This separation highlights the relative roles of the project and enterprise architects as well as the manner in which they need to collaborate. The enterprise architecture group chapter in Part IX then summarizes the activities of this group.

The book as a whole, and each individual chapter, can be approached in two ways. One way is prescriptive. The book presents a structured approach to tackling individual projects and managing the overall enterprise architecture. The other way is to use the book as a review guideline. Each chapter discusses a topic and concludes with a list of key questions related to that topic. Use the questions as a self-evaluation guide for your current projects and enterprise architecture efforts. Then use the content of the individual chapters to review the specific issues and the various ways in which they can be addressed. Either way, you will strengthen your enterprise architecture.

Implementing SOA is a comprehensive guide to building your enterprise architecture. While the emphasis is clearly on SOA, SOA is just a style of distributed system architecture. Real-world enterprise architectures contain a mixture of SOA and non-SOA elements. To reflect this reality, the discussions in this book extend beyond SOA to cover the full scope of distributed business systems architecture.

The pragmatic approach of Implementing SOA will guide your understanding of each issue you will face, your possible solution choices, and the tradeoffs to consider in building your solutions. The key questions at the end of each chapter not only provide a convenient summary, but also serve as convenient architecture review questions. These questions, and the supporting discussions in each chapter, will guide you to SOA success.

Read More Show Less

Table of Contents

Preface xxvii

Part I: Fundamentals 1

Chapter 1: SOA and the Enterprise 3
The Challenge 4
The Concept of Total Architecture 5
Architecture Is Structure for a Purpose 6
Constant Changes 7
Total Architecture Synthesis 8
Making Total Architecture Work in Your Enterprise 9
Key Overview Questions 10

Chapter 2: Architecture Fundamentals 11
Structural Organization 11
Functional Organization 15
Collaborative Behavior 20
Total Architecture 26
Nonfunctional Requirements 27
Refinement 28
The Role of the Architect 29
Enterprise Architecture 30
Summary 34
Key Architecture Fundamentals Questions 35
Suggested Reading 36

Chapter 3: Service Fundamentals 37
What Is a Service? 37
Operations 38
Service Interfaces 47
The Rationale Behind Services 54
Summary 58
Key Service Fundamentals Questions 59
Suggested Reading 60

Chapter 4: Using Services 61
Service Interaction Patterns 61
Service Access 67
Access Control 72
Service Request Routing 76
Service Composition 80
Locating Services 85
Enterprise Architecture for Services 86
Summary 87
Key Service Utilization Questions 88
Suggested Reading 89

Chapter 5: The SOA Development Process 91
What Is Different about SOA Development? 91
The Overall Development Process 92
Architecture Tasks 94
Architecture in Context 96
Total Architecture Synthesis (TAS) 97
Beware of Look-Alike Processes! 105
Manage Risk: Architect Iteratively 106
Summary 108
Key Development Process Questions 108
Suggested Reading 109

Part II: The Business Process Perspective 111

Chapter 6: Processes 113
Triggers, Inputs, and Results 114
Related Processes 115
Process Maturity 116
Continuous Processes 119
Structured Processes 120
Summary 121
Key Process Questions 122
Suggested Reading 122

Chapter 7: Initial Project Scoping 123
Assembling the Business Process Inventory 124
Conducting Interviews 125
Documenting the Inventory 128
Ranking Business Processes 141
Organizing the Remaining Work 147
Summary 149
Key Scoping Questions 150

Chapter 8: The Artifice of Requirements 151
Differentiation 153
Characterizing Processes 159
Patterns of Interaction 163
Interaction Patterns Characterize Participants 171
Requirements Reflect Design 172
Summary 175
Key Requirements Questions 177
Suggested Reading 178

Chapter 9: Business Process Architecture 179
Results 180
Participants and Their Roles 182
Activities and Scenarios 186
Modeling Scenarios 191
Modeling Interactions 198
How Much Detail Is Enough? 204
Guidelines for Using Activity Diagrams 206
Summary 207
Key Business Process Architecture Questions 208
Suggested Reading 209

Chapter 10: Milestones 211
Basic Process Milestones 211
Variations in Milestone Sequences 214
Grouped Milestones 215
Recognizing Milestones Requires Design 216
Using Milestones to Reduce Inter-Process Coupling 217
Summary 218
Key Milestone Questions 219

Chapter 11: Process Constraints 221
Business Process Constraints Drive System Constraints 222
Performance Constraints 224
High Availability and Fault Tolerance 231
Security 238
Reporting, Monitoring, and Management 240
Exception Handling 242
Test and Acceptance 243
Compliance Constraints 245
Summary 246
Key Process Constraint Questions 247
Suggested Reading 248

Chapter 12: Related Processes 249
Identifying Services 252
Triggering Events 258
Summary 264
Key Related Process Questions 265

Chapter 13: Modeling the Domain 267
UML Class Notation 269
ATM Example Domain Model 274
Reverse Engineering the Domain Model 276
Domain Modeling Summary 277
Key Domain Modeling Questions 279
Suggested Reading 279

Chapter 14: Enterprise Architecture: Process and Domain Modeling 281
Process and Domain Modeling Responsibilities 282
Establishing Standards and Best Practices 283
Managing Process and Domain Knowledge Transfer 285
Reviewing Project Models 286
Maintaining the Business Process and Domain Model Repository 287
Defining Business Process Patterns 288
Defining Common Data Model Representations 288
Summary 289
Key Enterprise Process and Domain Modeling Questions 290

Part III: The Systems Perspective 291

Chapter 15: Systems Architecture Overview 293
The Challenge of Architecting Distributed Systems 294
Learning from the CORBA Experience 294
Efficiently Exploring Architectures 300
Summary 303
Key Systems Architecture Overview Questions 304

Chapter 16: Top-Level Systems Architecture 305
First-Cut Structure 305
Initial Evaluation 307
Communications and Modularization 309
Service Identification and Performance 312
Modeling System Interactions 312
Modeling Deployment 318
Addressing Performance 322
Early Architecture Evaluation 325
Key Top-Level Systems Architecture Questions 327
Suggested Reading 328

Part IV: Communications 329

Chapter 17: Transport 331
Transport Technology 332
Selecting Transports 336
Messaging Server Topology 340
Capacity 345
Point-to-Point Interaction Patterns 347
Point-to-Point Intermediaries 348
Transport-Supplied Services 350
Summary 351
Key Transport Questions 351
Suggested Reading 352

Chapter 18: Adapters 353
API-Based Adapters 354
Database-Based Adapters 355
Combining API and Database Approaches 356
File-Based Adapters 357
Protocol-Based Adapters 357
Documenting Adapter Usage 358
Summary 359
Key Adapter Questions 360

Chapter 19: Enterprise Architecture: Communications 361
Defining a Communications Strategy 361
Interaction Standards 362
Standardizing Adapters 363
Summary 364
Key Enterprise Architecture Communications Questions 364

Part V: Data and Operations 367

Chapter 20: Data Challenges 369

Chapter 21: Messages and Operations 371
Message Semantics and Operation Names 371
Transport Destinations and Operation Bundling 374
Content Representation 377
Content Transformation 378
Reference Data in Content Transformation 380
Summary 381
Key Messages and Operations Questions 381

Chapter 22: Data Consistency: Maintaining One Version of the Truth 383
Approaches to Maintaining Data Consistency 384
Cached Data with a Single System of Record 385
Coordinated Updates via Distributed Transactions 390
Edit Anywhere, Reconcile Later 390
Dealing with Data Inconsistencies 391
Data Management Business Processes 393
Summary 394
Key Data Consistency Questions 394
Suggested Reading 395

Chapter 23: Common Data Models (CDM) 397
What Is a Common Data Model? 397
CDM Relationship to the Domain Model 402
The Need for Multiple CDM Representations 405
Planning for CDM Changes 407
When to Use Common Data Models 411
Summary 415
Key Common Data Model Questions 416

Chapter 24: Identifiers (Unique Names) 417
Identity (Unique Name) Authorities 418
Hierarchical Identifiers 419
Coping with Identity Errors 423
Mapping Identifiers 429
Summary 433
Key Identifier Questions 434

Chapter 25: Results Validation 435
Checking Enumerated Values 436
Where and When to Validate 437
Summary 438
Key Data Validation Questions 439

Chapter 26: Enterprise Architecture: Data 441
Naming Schemes 441
Architecting Content Transformation 443
Systems of Record 445
Common Data Models 446
Identifiers 447
Data Quality Management 448
Summary 449
Key Enterprise Architecture Data Questions 450

Part VI: Coordination 451

Chapter 27: Coordination and Breakdown Detection 453
Activity Execution Management Patterns (AEMPs) Involving Interactions 454
Coordination Pattern Styles 456
Fire-and-Forget Coordination Patterns 457
Request-Reply Patterns 460
Delegation 465
Delegation with Confirmation 467
Summary 468
Key Coordination Questions 469

Chapter 28: Transactions: Coordinating Two or More Activities 471
Two-Phase Commit Distributed Transactions 472
Limitations of Two-Phase Commit Protocols 475
Compensating Transactions 476
Working around the Limitations of Compensating Transactions 476
Summary 478
Key Transaction Questions 479
Suggested Reading 479

Chapter 29: Process Monitors and Managers 481
Process Monitoring 483
Minimizing the Impact of Monitoring Breakdowns 484
The Process Manager as a Monitor 485
Process Management Limitations 486
Summary 488
Key Process Monitoring and Management Questions 488

Chapter 30: Detecting and Responding to Breakdowns 489
Selecting Coordination Patterns to Improve Breakdown Detection 489
Responding to Breakdowns 493
Summary 504
Key Breakdown Detection and Recovery Questions 505

Chapter 31: Enterprise Architecture: Coordination 507
Preferred Coordination Patterns 507
Breakdown Recording 509
Breakdown Annunciation 510
Recovery Processes 511
Summary 511
Key Enterprise Coordination Questions 512

Part VII: High Availability, Fault Tolerance, and Load Distribution 513

Chapter 32: High Availability and Fault Tolerance Fundamentals 515
Fault Tolerance Strategies 516
Failure Detection Strategies 517
Failover Management 519
Redirecting Clients 520
Summary 522
Key High-Availability and Fault Tolerance Questions 523

Chapter 33: Stateless and Stateful Failover 525
Stateless and Stateful Components 525
Stateless Failover 525
Saving Work in Progress through Coordination 526
Stateful Failover 528
Storage Replication 530
Summary 540
Key Failover Questions 541
Suggested Reading 541

Chapter 34: Multiple Component Failover 543
Intra-Site versus Inter-Site Failover 543
Clustering: An Intra-Site Failover Technique 545
Coordinating Peer Application Failover with Asynchronous Replication 546
Making a Business Process Fault-Tolerant 548
Summary 550
Key Multi-Component Failover Questions 551

Chapter 35: Workload Distribution 553
Work Assignment Strategies 553
Distribution Management and Work Completion 554
The Sequencing Problem 556
Access to Shared Persistent State 557
Geographic Workload Distribution 558
Summary 558
Key Workload Distribution Questions 559

Chapter 36: Enterprise Architecture: Fault Tolerance, High Availability, and Load Distribution 561
Business Process Categorization 563
Information Storage 565
Individual Component and Service Failover Patterns 565
Composite Patterns for FT and HA Services 566
Composite Patterns for FT and HA Business Processes 568
Summary 568
Key Enterprise Fault Tolerance, High-Availability, and Load Distribution Questions 569
Suggested Reading 569

Part VIII: Completing the Architecture 571

Chapter 37: Process Security 573
Security Information Classification 574
Identity and Authentication 574
Authorization 576
Encryption 579
Digital Signatures 580
Other Security-Related Requirements 580
Reference Data Servers and Performance 581
Trust Zones 582
Channel Enforcement 583
Zone Enforcement and Policy Agents 585
Multi-Zone Security 586
Summary 587
Key Security Questions 588
Suggested Reading 589

Chapter 38: Process Monitoring 591
Performance Monitoring 592
Monitoring Process Status 594
Supervisory Processes 595
The Impact of Monitoring on Performance 596
Summary 596
Key Process Monitoring Questions 597

Chapter 39: Architecture Evaluation 599
Usability 600
Performance 600
Cost and Schedule Feasibility 612
Observability 613
Ability to Evolve 613
Ability to Handle Stress Situations 614
Summary 615
Key Architecture Evaluation Questions 616
Suggested Reading 617

Chapter 40: Testing 619
Unit Testing, Test Harnesses, and Regression Testing 620
Integration Testing and Order of Assembly 621
Environments for Functional and System Testing 622
Performance Testing 623
Failure Mode Testing 627
Summary 628
Key Testing Questions 628

Part IX: Advanced Topics 631

Chapter 41: Representing a Complex Process 633
Eliding Communications Detail 634
Eliding Participant Activity Details 634
Eliding Supporting Participants 636
Abstracting Subprocesses 638
Summary 639
Key Complex Process Representation Questions 639

Chapter 42: Process Management and Workflow 641
Process Management 642
Styles of Work Assignment 647
Initiating Workflow 649
Making the Management Process Fault Tolerant 649
Human Interfaces 656
Related Processes 660
Prioritized Work 663
Dynamic Work Assignments 665
Dynamic Result and Process Definitions 666
Summary 668
Key Process Management and Workflow Questions 669
Suggested Reading 670

Chapter 43: The Enterprise Architecture Group 671
Half a Group Is Better than None—But Not Good Enough 672
Best Practice Development 672
Knowledge Transfer 673
Governance 675
Designing with Evolving Requirements 675
Summary 681
Key Enterprise Architecture Group Questions 682

Afterword 683
Focus Your Work 683
Seek the Expertise of Others 684
Be Pragmatic, But Consider the Long View 685

Index 687

Read More Show Less

Preface

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 a 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.

In Succeeding 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 an 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 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 SOA will 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.

  1. 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 call total architecture. Thus, building your service-oriented architecture is not just a technical exercise, it is also a business exercise that requires the active participation of the business side of the house.
  2. 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.
  3. 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.
  4. 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 business process availability and fault tolerance, securing your information, and monitoring and managing both business processes and services. The requirements driving your solution choices stem from the needs of the business processes involved and are thus tied in with business process design as well as systems design. As before, solutions to these problems require consistent approaches across all of your projects.

At the end of the day, your challenge as an architect is to organize your enterprise's collaboration between business processes, people, information, and systems, and to focus it on achieving your enterprise's goals.

About the Book

Implementing SOA is a comprehensive guide to addressing your architectural challenges. It shows you how to smoothly integrate the design of both business processes and business systems. It will tell you how to evolve your existing architecture to achieve your SOA objectives, maintaining operational support for the enterprise during the transition. It demonstrates how to use a proactive enterprise architecture group to bring a consistent and forward-looking architectural perspective to multiple projects. Finally, it shows you how to address the full spectrum of distributed system design issues that you will face.

This book is organized into nine parts. Part I presents the fundamental concepts of architecture, services, and the total architecture synthesis methodology. Parts II through VIII discuss a series of architectural design issues, ranging from understanding business processes to monitoring and testing your architecture. Part IX then builds on these discussions to address the large-scale issues associated with complex business processes and workflow, concluding with a summary discussion of the workings of the enterprise architecture group.

In Parts II through VIII, each of the architecture topics is discussed from two perspectives: the project perspective and the enterprise architecture perspective. Each part first discusses the design issues as though the project architect were creating the entire architecture from scratch. The last chapter in each part then addresses the realities of a multiproject environment and the role that the enterprise architecture group must play to ensure that the design issues are appropriately addressed throughout the total architecture. This separation highlights the relative roles of the project and enterprise architects as well as the manner in which they need to collaborate. The enterprise architecture group chapter in Part IX then summarizes the activities of this group.

The book as a whole, and each individual chapter, can be approached in two ways. One way is prescriptive. The book presents a structured approach to tackling individual projects and managing the overall enterprise architecture. The other way is to use the book as a review guideline. Each chapter discusses a topic and concludes with a list of key questions related to that topic. Use the questions as a self-evaluation guide for your current projects and enterprise architecture efforts. Then use the content of the individual chapters to review the specific issues and the various ways in which they can be addressed. Either way, you will strengthen your enterprise architecture.

Implementing SOA is a comprehensive guide to building your enterprise architecture. While the emphasis is clearly on SOA, SOA is just a style of distributed system architecture. Real-world enterprise architectures contain a mixture of SOA and non-SOA elements. To reflect this reality, the discussions in this book extend beyond SOA to cover the full scope of distributed business systems architecture.

The pragmatic approach of Implementing SOA will guide your understanding of each issue you will face, your possible solution choices, and the tradeoffs to consider in building your solutions. The key questions at the end of each chapter not only provide a convenient summary, but also serve as convenient architecture review questions. These questions, and the supporting discussions in each chapter, will guide you to SOA success.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing 1 Customer Reviews
  • Anonymous

    Posted May 9, 2008

    large set of patterns for distributed systems

    Brown's book is a sign that the field of SOA is maturing. The book's heft is because it is a collection of the most significant design patterns in SOA. The early chapters give an overview of SOA and what Brown calls Total Architecture Synthesis. A wholistic view of people, processes, information and (hardware) systems. But it may be best to treat the book from a top-down classification of patterns. Where the top level has the sections Collaboration, Communication, Data, etc. There is an abundance of patterns. Which in itself might address some of you sceptical about the entire field of SOA. Sure, it has its buzzwords and jargon. However, the set of patterns and their subgroupings might make SOA more applicable to your situation, rather than just having nice high level statements of vague generality. Many readers might [should] already be familiar with patterns, if you come from a programming background. This will indeed help when reading the book, for several terms and concepts will be familiar. Note however a key qualitative difference between the book's patterns and those of [eg] Refactoring: Improving the Design of Existing Code (The Addison-Wesley Object Technology Series). Fowler's patterns refer to code that often all sits in one machine, or perhaps in a group of machines co-located in the same server room. So bandwidth and latency are not issues. With SOA, these often arise as vital considerations. SOA refers to spatially distributed systems maybe over large distances.

    Was this review helpful? Yes  No   Report this review
Sort by: Showing 1 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)