McGovern / Sims / Jain Enterprise Service Oriented Architectures

Concepts, Challenges, Recommendations
1. Auflage 2006
ISBN: 978-1-4020-3705-4
Verlag: Springer Netherlands
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Englisch, 435 Seiten

Reihe: The Enterprise Series

Conventional wisdom of the 'software stack' approach to building applications may no longer be relevant. Enterprises are pursuing new ways of organizing systems and processes to become service oriented and event-driven. Leveraging existing infrastructural investments is a critical aspect to the success of companies both large and small. Enterprises have to adapt their systems to support frequent technological changes, mergers and acquisitions. Furthermore, in a growing global market, these systems are being called upon to be used by external business partners. Technology is often difficult, costly and complex and without modern approaches can prevent the enterprise from becoming agile. Enterprise Service Oriented Architectures helps readers solve this challenge in making different applications communicate in a loosely coupled manner. This classic handbook leverages the experiences of thought leaders functioning in multiple industry verticals and provides a wealth of knowledge for creating the agile enterprise. In this book, you will learn: • How to balance the delivery of immediate business value while creating long-term strategic capability • Fundamental principles of a service-oriented architecture (find, bind and execute) • The four aspects of SOA (Production, Consumption, Management and Provisioning) • How to recognize critical success factors to implementing enterprise SOAs • Architectural importance of service registries, interfaces and contracts • Why improper service decomposition can hurt you later rather than sooner • How application design and integration practices change as architects seek to implement the 'agile' enterprise About the Authors James McGovern is an enterprise architect for The Hartford. He is an industry thought leader and co-author of the bestselling book: A Practical Guide to Enterprise Architecture. Oliver Sims is a recognized leader in the architecture, design and implementation of service-oriented and component-based enterprise systems. He was a founding member of the OMG Architecture Board. He was co-author of the groundbreaking book: Business Component Factory. Ashish Jain is a Principal Architect with Ping Identity Corporation, a leading provider of solutions for identity federation. Prior to joining Ping Identity, he worked with BEA Systems where his role was to assist BEA customers in designing and implementing their e-business strategies using solutions based on J2EE. He holds several industry certifications from SUN and BEA and is also a board member for the Denver BEA User group. Mark Little is Director of Standards and SOA Manager for JBoss Inc. Prior to this, he was Chief Architect for Arjuna Technologies Ltd and a Distinguished Engineer at Hewlett-Packard. As well as being an active member of the OMG, JCP, OASIS and W3C, he is an author on many SOA and Web Services standards. He also led the development of the world's first standards-compliant Web Services Transaction product.

Autoren/Hrsg.

Mcgovern, James

Sims, Oliver

Jain, Ashish

Little, Mark

Inhaltsverzeichnis

1;TABLE OF CONTENTS;7
2;ENDORSEMENTS;11
3;ABOUT THE SERIES;13
3.1;Series Editors;14
4;FOREWORD;17
5;PREFACE;21
6;ABOUT THIS BOOK;25
6.1;Audience;26
6.2;What This Book Is Not!;26
6.3;How to Use This Book;27
6.4;Motivation for Writing This Book;28
6.5;Disclaimer;28
6.6;About the Authors;29
7;ACKNOWLEDGEMENTS;31
8;ABOUT THE REVIEWERS;33
8.1;Argentina;33
8.2;Australia;33
8.3;Belgium;33
8.4;Canada;34
8.5;Finland;34
8.6;Germany;34
8.7;India;34
8.8;Israel & Palestine;34
8.9;Pakistan;34
8.10;Scotland;34
8.11;Singapore;34
8.12;Ukraine;35
8.13;United Kingdom;35
8.14;United States;35
9;1 UNDERSTANDING SERVICE- ORIENTED ARCHITECTURE;36
9.1;1. Introducing Service-Oriented Architectures;40
9.1.1;1.1. Web Services;40
9.1.1.1;1.1.1. Enterprise IT and Web Services;41
9.1.1.2;1.1.2. WSDL and SOAP;43
9.1.1.3;1.1.3. UDDI;47
9.1.1.4;1.1.4. The Beginnings of Enterprise Service Orientation;50
9.1.2;1.2. Enterprise Service-Oriented Architecture;52
9.2;2. Service-Based Collaboration through Federation;54
9.2.1;2.1. A Federation Is …;54
9.2.2;2.2. Federation and Mature CBSE;58
9.2.3;2.3. The Federation Spectrum;59
9.2.4;2.4. The Spectrum as a Service Taxonomy;63
9.2.5;2.5. Federation Example;65
10;2 COMPONENT-BASED SERVICES;84
10.1;1. Component-Based Software Engineering ( CBSE);86
10.1.1;1.1. Understanding CBSE;87
10.2;2. A Component De.nition;90
10.2.1;2.1. The UML2 Component;91
10.2.2;2.2. The Enterprise Component;95
10.2.3;2.3. Network-Style Interfaces;96
10.3;3. Component Granularity;99
10.3.1;3.1. Distribution Domains and Tiers;100
10.3.1.1;3.1.1. Looking at the Big Picture;100
10.3.1.2;3.1.2. Distribution Domains and Tiers;102
10.3.1.3;3.1.3. The BPM Domain;104
10.3.2;3.2. Granularity Scheme;105
10.3.2.1;3.2.1. The Distributed Component (DC);106
10.3.2.2;3.2.2. The Business Component (BC);108
10.3.2.3;3.2.3. The Application Component (AC);111
10.3.3;3.3. Dependency Management;114
10.3.3.1;3.3.1. Inter-Tier Interactions;114
10.3.3.2;3.3.2. Business Function Layers;115
10.4;4. From Requirements to Design;116
10.4.1;4.1. Requirements;117
10.4.1.1;4.1.1. Business Elements;118
10.4.1.2;4.1.2. Processes and Resources;118
10.4.2;4.2. Business Element Analysis;119
10.4.2.1;4.2.1. Resource Business Element (RBE);120
10.4.2.2;4.2.2. The Service Business Element (SBE);123
10.4.2.3;4.2.3. Delivery Business Element (DBE);126
10.4.3;4.3. Mapping to Components;127
10.5;5. Summary;129
11;3 ORCHESTRATION;130
11.1;1. Work.ow and Business Process Management;132
11.1.1;1.1. Intra-Enterprise Work.ows;135
11.1.2;1.2. Interoperability Concerns;136
11.2;2. The Business Process Execution Language ( BPEL);136
11.2.1;2.1. Relationship to XPath;138
11.2.2;2.2. Variables;138
11.2.3;2.3. De.ning Business Relationships;140
11.2.4;2.4. Message Correlation;142
11.2.5;2.5. Activities;147
11.2.5.1;2.5.1. ;148
11.2.5.2;2.5.2. ;150
11.2.5.3;2.5.3. ;151
11.2.5.4;2.5.4. ;152
11.2.5.5;2.5.5. ;152
11.2.5.6;2.5.6. ;153
11.2.5.7;2.5.7. ;153
11.2.5.8;2.5.8. ;154
11.2.5.9;2.5.9. <.ow>;154
11.2.5.10;2.5.10. ;157
11.2.5.11;2.5.11. ;159
11.2.5.12;2.5.12. ;159
11.2.5.13;2.5.13. ;160
11.2.5.14;2.5.14. ;161
11.2.5.15;2.5.15. ;161
11.2.6;2.6. Transactions;162
11.3;3. A Worked Example of Web Services Orchestration;163
11.4;4. Design-Time Demonstration;164
11.4.1;4.1. Task De.nitions;164
11.4.2;4.2. The ProcessOrderApplication Flow;165
11.4.3;4.3. The PaymentAuthorization Sub-Task;167
11.4.3.1;4.3.1. Testing the Sub-Task within the Design Tool;169
11.4.4;4.4. Gluing Them Together;173
11.4.5;4.5. Fault Handling;178
11.4.6;4.6. The Entire Flow;179
11.5;5. Run-Time Demonstration;180
11.5.1;5.1. Tracking the Flow;180
11.5.2;5.2. The Audit Trail;183
11.6;6. Summary;183
12;4 WORKING WITH REGISTRY AND UDDI;186
12.1;1. Introducing the Registry;187
12.1.1;1.1. Why Do I Need It?;187
12.1.2;1.2. How Do I Use It?;188
12.1.3;1.3. Registry vs Repository;189
12.2;2. Universal Description, Discovery and Integration ( UDDI);189
12.2.1;2.1. Technical Overview;190
12.2.2;2.2. Informational Structural Model;192
12.2.2.1;2.2.1. Business Information: The BusinessEntity Element;193
12.2.2.2;2.2.2. Service Information: The BusinessService element;194
12.2.2.3;2.2.3. Specification Information: The BindingTemplate Element;194
12.2.2.4;2.2.4. Technical Fingerprint: The TModel Element;195
12.2.2.5;2.2.5. Relationships: The PublisherAssertion Element;196
12.2.2.6;2.2.6. Operations Information: The OperationalInfo Element;197
12.2.3;2.3. UDDI Keys;197
12.2.3.1;2.3.1. UUID;198
12.2.3.2;2.3.2. DomainKey;198
12.2.3.3;2.3.3. DerivedKey;199
12.2.4;2.4. Classification – Where Is My Data?;199
12.2.4.1;2.4.1. Categorization;200
12.2.4.2;2.4.2. Identifiers;202
12.3;3. Programming UDDI;204
12.3.1;3.1. Searching with UDDI;204
12.3.1.1;3.1.1. Browse Pattern;205
12.3.1.2;3.1.2. Drill-Down Pattern;206
12.3.1.3;3.1.3. Invocation Pattern;207
12.3.2;3.2. Publishing with UDDI;208
12.3.3;3.3. Subscribing with UDDI;208
12.3.3.1;3.3.1. Asynchronous Noti.cation;212
12.3.3.2;3.3.2. Synchronous Noti.cation;212
12.4;4. Internationalization;214
12.4.1;4.1. Multilingual Descriptions, Names and Addresses;214
12.4.2;4.2. Multiple Names in the Same Language;215
12.4.3;4.3. Internationalized Address Format;216
12.4.4;4.4. Language-Dependent Collation;217
12.4.5;4.5. Federation of Registries;217
12.4.6;4.6. Private Test Registry;218
12.4.7;4.7. Shared Registry;219
12.4.8;4.8. Security;221
12.5;5. Summary;222
13;5 UNDERSTANDING ENTERPRISE SECURITY;224
13.1;1. Need for a Message Level Security Solution;226
13.1.1;1.1. Point-to-Point vs End-to-End Security;226
13.1.2;1.2. Application Independence;227
13.1.3;1.3. Technology Independence;228
13.2;2. Security Concepts;228
13.2.1;2.1. Authentication – Who Is It?;229
13.2.2;2.2. Authorization – What Can They Do?;229
13.2.3;2.3. Integrity – Ensure That Information Is Intact;230
13.2.4;2.4. Con.dentiality – You Can’t Read;230
13.2.5;2.5. Non-Repudiation – You Sent It, I Got Proof;230
13.2.6;2.6. Single Signon – How Many Times Do I Have to Tell You?;231
13.2.7;2.7. Key Management – Give Me a Key Chain;231
13.3;3. Security Technologies;231
13.3.1;3.1. Authenticaton and Security Tokens;232
13.3.1.1;3.1.1. Username/Password;233
13.3.1.2;3.1.2. PKI through X.509 Certi.cates;234
13.3.1.3;3.1.3. Kerberos;234
13.3.2;3.2. Integrity and Signing;234
13.3.3;3.3. XML Signature;236
13.3.3.1;3.3.1. Generate Certi.cate;239
13.3.3.2;3.3.2. Signing;240
13.3.3.3;3.3.3. Veri.cation;242
13.3.4;3.4. Canonicalization;243
13.3.5;3.5. Con.dentiality and Encryption;244
13.3.5.1;3.5.1. Symmetric Encryption;245
13.3.5.2;3.5.2. Asymmetric Encryption;246
13.3.6;3.6. XML Encryption;247
13.3.6.1;3.6.1. Encryption;249
13.3.6.2;3.6.2. Decryption;249
13.3.7;3.7. Authorization;250
13.3.8;3.8. Extensible Access Control Markup Language ( XACML);250
13.3.8.1;3.8.1. Key Concepts;250
13.3.9;3.9. Top-Level Constructs: Policy and PolicySet;251
13.3.10;3.10. Key Management;251
13.3.11;3.11. XML Key Management Speci.cation ( XKMS);252
13.3.11.1;3.11.1. XML Key Information Service Specification ( XKISS);252
13.3.11.2;3.11.2. XML Key Registration Service Specification ( XKRSS);252
13.3.12;3.12. Single Sign-On;253
13.3.13;3.13. Identity Management;255
13.3.14;3.14. Liberty Alliance Project;255
13.3.15;3.15. Security Assertion Markup Language ( SAML);258
13.4;4. Web Services Security (WSS);260
13.4.1;4.1. Security Tokens;261
13.4.2;4.2. Signature;262
13.4.3;4.3. Encryption;263
13.5;5. WS-Policy;265
13.6;6. WS-Trust;266
13.7;7. WS-Privacy;267
13.8;8. WS-SecureConversation;267
13.9;9. WS-Federation;268
13.10;10. WS-Authorization;268
13.11;11. Summary;268
14;6 SOA MANAGEMENT;270
14.1;1. Problem Space;271
14.1.1;1.1. Management Scenarios;275
14.2;2. Systems Management;279
14.2.1;2.1. Logging;280
14.2.2;2.2. Auditing;282
14.2.3;2.3. Monitoring;283
14.3;3. Alerting;285
14.3.1;3.1. Round Trip;285
14.3.2;3.2. Transaction Size;285
14.3.3;3.3. System Fault;286
14.3.4;3.4. Trending;286
14.4;4. Provisioning;287
14.5;5. Leasing;288
14.6;6. Billing;289
14.7;7. Pricing/Chargeback Models;290
14.7.1;7.1. Per Transaction;291
14.7.2;7.2. Fixed Fee/Subscription;291
14.7.3;7.3. Lease/License;291
14.7.4;7.4. Business Partnership/Percentage of Revenue;292
14.7.5;7.5. Registration;292
14.8;8. Lifecycle Management;292
14.8.1;8.1. Routing;294
14.8.2;8.2. Versioning and Deprecation;295
14.8.3;8.3. Transformation;297
14.8.4;8.4. Provisioning;300
14.8.5;8.5. Quality Assurance;302
14.8.6;8.6. Business Processes;303
14.8.7;8.7. Message Prioritization;304
14.8.8;8.8. Business Activity Monitoring;304
14.9;9. Management Architecture;306
14.9.1;9.1. Gateways;306
14.9.2;9.2. Agents;307
14.9.3;9.3. Centralized Policies;308
14.9.4;9.4. Operational Rules;308
14.9.5;9.5. Components;310
14.9.6;9.6. Persistent Storage;311
14.10;10. Policy Architecture;312
14.10.1;10.1. Policy Execution;313
14.11;11. Framework Vendors;314
14.12;12. Summary;315
15;7 TRANSACTIONS;316
15.1;1. What Are ACID Transactions?;316
15.1.1;1.1. The Synchronization Protocol;320
15.1.2;1.2. Optimizations to the Protocol;321
15.1.3;1.3. Non-Atomic Transactions and Heuristic Outcomes;322
15.2;2. Why ACID Is Too Strong for Web Services;323
15.3;3. A Brief History of Web Services Transactions;325
15.4;4. The Coordination Frameworks;326
15.4.1;4.1. Coordination Architecture;328
15.4.2;4.2. Creating a Coordinator;329
15.4.3;4.3. The Context;330
15.4.4;4.4. Registering Participants;331
15.4.5;4.5. Terminating the Coordinator;334
15.5;5. Web Services Transactions;334
15.5.1;5.1. Atomic Transaction;336
15.5.1.1;5.1.1. Supported Protocols;337
15.5.2;5.2. Business Activity;340
15.5.2.1;5.2.1. WS-BusinessActivity;342
15.5.2.2;5.2.2. Long Running Action;342
15.5.3;5.3. Business Process Model;345
15.6;6. Security Implications;347
15.7;7. Interoperability Considerations;349
15.8;8. Summary;350
16;8 EVENT-DRIVEN ARCHITECTURE;352
16.1;1. Overview;354
16.2;2. Events;355
16.2.1;2.1. Descriptive;355
16.2.2;2.2. Prescriptive;355
16.2.3;2.3. Factual;356
16.2.4;2.4. Assumptive;356
16.2.5;2.5. Business Rules;356
16.3;3. Agents;358
16.3.1;3.1. Service Design;361
16.3.2;3.2. Pools;362
16.4;4. Threads;364
16.4.1;4.1. Thread per Request;364
16.4.2;4.2. Thread Pools;366
16.5;5. Alternative Pattern-Based Approaches;367
16.5.1;5.1. Strategy Pattern;368
16.5.2;5.2. Chain of Responsibility Pattern;368
16.5.3;5.3. Interpreter Pattern;370
16.5.4;5.4. Flyweight Pattern;371
16.5.5;5.5. Memento Pattern;372
16.6;6. Language Specific Constructs;373
16.6.1;6.1. Soft References;374
16.6.2;6.2. Forking;375
16.6.3;6.3. Non-Blocking I/O;375
16.6.4;6.4. Enterprise Service Bus;376
16.6.5;6.5. Callbacks;379
16.7;7. Finite State Machines;379
16.8;8. Event Notification;382
16.8.1;8.1. Brokered Notification;384
16.8.2;8.2. Security Concerns;385
16.8.3;8.3. Message Order Alteration;385
16.8.4;8.4. Availability Attacks;386
16.8.5;8.5. Replay Attacks;386
16.8.6;8.6. Redirection Attacks;386
16.9;9. Practical Considerations;387
16.9.1;9.1. Return on Investment;388
16.9.2;9.2. Canonical Form;388
16.9.3;9.3. Integration;389
16.9.4;9.4. Retirement;389
16.10;10. Summary;390
17;OUTTRO;392
18;APPENDIX A: UNDERSTANDING DISTRIBUTED COMPUTING;394
18.1;1. Distributed Computing;395
18.1.1;1.1. Anatomy of a Distributed Application;396
18.1.1.1;1.1.1. Understanding the Network Layer;397
18.1.1.2;1.1.2. Building the Application Layer;399
18.1.1.3;1.1.3. Operating System Components;401
18.1.2;1.2. Interprocess Communication;403
18.1.3;1.3. Communications Infrastructure;405
18.1.4;1.4. Remote Procedure Calls (RPC);406
18.1.5;1.5. Object Request Brokers (ORB);406
18.1.6;1.6. Transaction Processing Monitors;408
18.1.7;1.7. Message-Oriented Middleware ( MOM);410
18.1.8;1.8. Service Description;411
18.1.9;1.9. Versioning;412
18.1.10;1.10. Operations;413
18.1.10.1;1.10.1. One-Way;414
18.1.10.2;1.10.2. Request/Response;414
18.1.10.3;1.10.3. Solicit/Response;415
18.1.10.4;1.10.4. Noti.cation;415
18.1.11;1.11. Service Discovery;416
18.1.12;1.12. Application Services;417
18.1.12.1;1.12.1. Stateless Services;418
18.1.12.2;1.12.2. Conversational Services;418
18.1.12.3;1.12.3. Cached Services;419
18.1.12.4;1.12.4. Singleton Services;419
18.2;2. Practical Considerations;420
18.3;3. Summary;420
19;APPENDIX B: QUALITY ATTRIBUTES;422
19.1;1. System Qualities;422
19.1.1;1.1. Availability;422
19.1.2;1.2. Manageability;424
19.1.3;1.3. Performance;424
19.1.4;1.4. Scalability;425
19.1.5;1.5. Security;426
19.2;2. Design vs Run-Time;426
20;APPENDIX C: REFERENCES;430
20.1;Books;430
20.2;Magazines;432
20.3;Docs;432
20.4;Web Sites;434
20.5;Presentations;436
21;APPENDIX D: ADDITIONAL READING;438
22;APPENDIX E: UPCOMING BOOKS;440
22.1;Agile Enterprise Architecture – Fall 2006;440
22.2;Enterprise Portal Architecture – Fall 2006;441
22.3;Enterprise Open Source – Spring 2007;442
22.4;Enterprise BPM Patterns – Summer 2007;443

Leseproben

3 ORCHESTRATION (p.95-96)

None of us is as smart as all of us. 
Anonymous


Even before the advent of Web services, an increasingly large number of distributed applications were constructed by composing them out of existing applications. Enterprise Application Integration (EAI) techniques grew up from the realization that no one infrastructural technology (e.g., CORBA or DCOM) will ever be adopted by all of the software industry. Furthermore, although sourcing a solution to a problem (large or small) from a single vendor is possible in the short term, in the long term it is often the case that a corporate intranet will be running systems from a variety of vendors, not all of which will be able to interoperate. Large multi-national corporations often evolve through acquisitions of smaller companies who may have different infrastructural investments. We have often heard the statement that "It’s easier to interoperate with a different company than to talk to different divisions within the same company." Therefore it should come as no surprise to learn that large-scale applications are rarely built from scratch; rather they are constructed by composing them out of existing applications.

Providing solutions that enable disparate (heterogeneous) technologies and applications to communicate is extremely important. Without them, a company’s infrastructure would either not be able to grow (leading to islands of isolation) or would be at the mercy of a single vendor. For several years EAI solutions have made it possible to compose an application out of component applications in a uniform manner, irrespective of the languages in which the component applications have been written and the operating systems of the host platforms. Unfortunately, most EAI platforms offer solutions that are not interoperable with one another. Web services offer a potential solution to this important drawback.
The resulting applications can be very complex in structure, containing many temporal and data.ow dependencies between their constituent applications. An additional complication is that the execution of such an application may take a long time to complete and may contain long periods of inactivity (minutes, hours, days, weeks, etc.), often due to the constituent applications requiring user interactions. In a distributed environment, it is inevitable that long running applications will require support for fault-tolerance and dynamic recon.guration: machines may fail, services may be moved or withdrawn and application requirements may change. In such an environment it is essential that the structure of applications can be modi.ed to re.ect these changes. In general, composite applications are increasing in importance as companies combine off-the-shelf and homegrown Web services into new applications. Various mechanisms are being proposed and delivered to market daily to help improve this process. New "fourth generation" language development tools are emerging that are speci.cally designed to stitch together Web services from any source, regardless of the underlying implementation.

A large number of vendors are starting to sell business process management, work.ow and orchestration tools for use in combining Web services into automatic business process execution .ows. In addition, a growing number of businesses .nd themselves creating new applications by combining their own Web services with Web services available from the Internet supplied by the likes of Amazon.com and Google.com. These types of composite applications represent a variety of requirements, from needing a simple way to share persistent data to the ability to manage recovery scenarios that include various types of transactional software. Composite applications therefore represent a signi.cant challenge for Web services standards since they are intended to handle complex, potentially long-running interactions among multiple Web services as well as simple and short-lived interactions.