Applied soa service oriented architecture and design strategies

The book starts by discussing the expected benefits of SOA and the tectural principles needed to realize them, which lead to successful solutions.Then, it provides an overview of the pro

Applied SOA

Service-Oriented Architecture

and Design Strategies

Mike Rosen Boris Lublinsky Kevin T Smith Marc J Balcer

Wiley Publishing, Inc.

Applied SOA

Service-Oriented Architecture

and Design Strategies

Mike Rosen Boris Lublinsky Kevin T Smith Marc J Balcer

Wiley Publishing, Inc.

Wiley Publishing, Inc.

10475 Crosspoint Boulevard

Indianapolis, IN 46256

www.wiley.com

Copyright  2008 by Wiley Publishing, Inc., Indianapolis, Indiana

Published simultaneously in Canada

ISBN: 978-0-470-22365-9

Manufactured in the United States of America

10 9 8 7 6 5 4 3 2 1

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form

or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee

to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600 Requests to the Publisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4355, or online at http://www.wiley.com/go/permissions

Limit of Liability/Disclaimer of Warranty:The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose No warranty may be created or extended by sales or promotional materials The advice and strategies contained herein may not be suitable for every situation This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services If professional assistance is required, the services of a competent professional person should be sought Neither the publisher nor the author shall be liable for damages arising herefrom The fact that an organization or Website is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization

or Website may provide or recommendations it may make Further, readers should be aware that Internet Websites listed in this work may have changed or disappeared between when this work was written and when it is read.

For general information on our other products and services or to obtain technical support, please contact our Customer Care Department within the U.S at (800) 762-2974, outside the U.S at (317) 572-3993 or fax (317) 572-4002.

Library of Congress Cataloging-in-Publication Data:

Applied SOA : service-oriented architecture and design strategies / Mike

Rosen [et al.].

p cm.

Includes index.

ISBN 978-0-470-22365-9 (paper/website)

1 Web services 2 Software architecture 3 Computer network

architecture 4 Information resources management I Rosen, Michael,

1956-TK5105.88813.A69 2008

006.7
8 — dc22

2008015109

Trademarks:Wiley, the Wiley logo, and related trade dress are trademarks or registered trademarks

of John Wiley & Sons, Inc and/or its affiliates, in the United States and other countries, and may not

be used without written permission All other trademarks are the property of their respective owners Wiley Publishing, Inc., is not associated with any product or vendor mentioned in this book.

Wiley also publishes its books in a variety of electronic formats Some content that appears in print may not be available in electronic books.

Mike Rosen is chief scientist at Wilton Consulting Group, which providesexpert consulting on software architecture, SOA, and enterprise architecture.

He is also director of enterprise architecture for the Cutter Consortium andeditorial director of the SOA Institute He frequently speaks at industrysymposia and contributes to industry journals

Boris Lublinsky is lead architect at Navteq, where he is responsible forSOA and BPM implementations He is a frequent contributor to technologymagazines and a speaker at industry conferences Boris is also an SOA newseditor for InfoQ

Kevin T Smithis a technical director at ManTech MBI (formally McDonaldBradley, Inc.), where he builds highly secure and data-driven SOA solutionsfor the U.S government He is the author of many SOA technology articles

in industry magazines, such as the SOA/Web Services Journal, and has

coauthored several technology books, including The Semantic Web (Wiley, 2003), Professional Portal Development with Open Source Tools (Wrox, 2004), More

Java Pitfalls (Wiley, 2003), and Essential XUL Programming (Wiley, 2001), in

addition to the books where he has written chapters as a contributing author.Kevin has led SOA workshops and has presented at numerous industryconferences, such as the RSA Security Conference, JavaOne, the SemanticTechnology Conference, the Apache Open Source Conference, Net-CentricWarfare, the Object Management Group, and the Association for EnterpriseIntegration

Marc J Balcer is the founder of ModelCompilers.com, a provider oftools and services for realizing the power of model-based development,

and the coauthor of Executable UML: A Foundation for Model-Driven

Archi-tecture (Addison-Wesley, 2002) He has over 15 years of experience in

v

developing, deploying, and managing projects based upon executable modelsand model-driven development techniques.

As a party to many enterprise development projects, Marc has witnessedfirsthand how the precision of application and architecture models can makethe difference between spectacular success and miserable failure He hasapplied Executable UML to projects in such diverse areas as medical instru-mentation, transportation logistics, telecommunications, and financial services

vii

Well, who to thank for all the help? First, thanks to all the people who supported

me throughout this process There were many, but a few stand out for specialmention: all my friends and clients who cut me a little slack when I mighthave been slightly unresponsive during the final push to finish everything;

my friends in the travel industry who inspired the case study; everyone atCutter Consortium for constant encouragement; SOAInstitute for providing aforum to teach and discuss all things SOA; Robert Elliott at Wiley, who hadthe uncanny timing to call me during a lull in my consulting practice and ask if

I wanted to be involved in an SOA book; and Sydney Jones, our project editor,for putting up with our changes and delays I hope she wasn’t just being nicewhen she said we weren’t the worst group of authors ever Thanks to JimAmsden, a friend and colleague, who also turned out to be the best technicaleditor you could imagine; Jeroen van Tyn and Laura O’Brian for the greatBusiness Use Cases in Chapters 6 and 7 and Appendix A; my good friend KenOrr for teaching me about business architecture, processes, and semantics overthe years; my coauthors, for contributing to a collaborative project where weall learned from each other and everyone’s chapters, and the book, benefited;and most importantly, to my awesome wife, Tamar Krichevsky, who not onlyput up with it all, but who also read every single chapter of the book andcompiled and wrote the fantastic Evaluating SOA Services appendix Thanks

— Mike Rosen

I would like to thank Mike for calling me out of the blue and asking whether Iwould like to participate in this exciting project I really enjoyed collaboratingwith Mike, Kevin, and Marc It allowed me to learn more about SOA andsignificantly improved the quality of my chapters Many thanks to the peoplewhom I used to work with over the years, especially Didier Le Tien, Dmitry

ix

Tyomkin, and Deborah Shaddon, for always challenging me with tough tecture questions and pointing at deficiencies in my solutions; Jay Davidsonand Edward Kuffert for explaining to me the importance of business architec-ture and the way the insurance industry works; and Jerry Daus, Matt O’Neal,and Maria Mernandez for helping me to understand how IBM software worksand the best ways to use it I am also thankful for all of the failed and successfulprojects that I worked on, which taught me what is important and what is not,and why things fail or succeed Most importantly, to my wonderful wife, Lilia,for patiently putting up with me spending more time with my computer thanwith her Thanks.

archi-— Boris Lublinsky

I would like to thank my three talented coauthors, Mike, Boris, and Marc — ithas been a pleasure working with you on this exciting and challenging project.Mike, you did a great job of guiding us in this process, and I would especiallylike to thank Boris for his additions to the chapters on Composing Services(Chapter 8) and SOA Governance (Chapter 12) I would like to thank VaughnBullard for his suggestions on Chapter 12 and Layer7’s Toufic Boubez for hissupport of my discussion on dynamic policy adaptation (‘‘Policy ApplicationPoints’’) in Chapters 11 and 12 Special thanks to Ken and Myrtle RuthStockman for allowing me to use their nicknames in one of my examples, andthanks to my ‘‘readability editors,’’ Helen G Smith and Lois G Schermerhorn

I would like to thank my company, ManTech MBI (formerly McDonaldBradley, Inc.) in Herndon, VA, with special and sincere thanks to those whoencouraged my writing of this book on my own time — specifically, thanks toDanny Proko, Bill Pulsipher, Waymond Edwards, John Sutton, Gail Rissler,Mark Day, and Ken Bartee I would like to give my thanks (and apologies)

to my wonderful wife, Gwen, and my sweet daughters, Isabella and Emma!Thank you for putting up with me as I went into isolation for countless nightsand weekends while writing this book I would like to thank Ashland Coffeeand Tea, who once again didn’t kick me out when I camped out there for days

at a time for writing, research, and of course, caffeine

Thanks to the Washington Redskins, who thoughtfully did not have agood enough football season that it would distract me from writing onSundays Thanks to other people, places, and things that most likely affected

my writing in a positive way (in no particular order): Gavin Sutcliffe; EricMonk; Nick Duan; Sue Lee; Joanie Barr; John Medlock; Kyle Hendrickson;Tom Diepenbrock; Scooby-Doo; Jeff Phelps; Ruben Wise; Kim Gumabay; MikeHoops, the AMC Pacer, Ralph Perko, Kathleen Ferris, Brad Giaccio, KevinMoran; Mike Daconta; Leo Obrst; Fox; my community group (Russ and DebiGarber, Ed and Lori Buchanan, Steve and Ani Tetrault, Ed Hoppe); KyleRice; Thai Gourmet in Kings Charter; the Apostle Paul; Sean, Jen, Garrett, andParker Cullinan; Daniel Buckley; Ken Pratt; Adam Dean; Mike Rohan; Carl and

Sharon Smith, Emma when she sleeps past 4:00 a.m., Bill, Farron, Casey, andWill Smith, New Hanover Church, Grace Community Presbyterian Church,Mungo, and T3 Finally, all glory, laud, and honor to the one who was, who is,and who is to come.

— Kevin T SmithMany ideas emerge from the everyday work of developing real solutions

In addition to my coauthors, I would like to acknowledge the contributions,criticism, and insights from current and former colleagues, including SteveDowse of International Asset Systems, and Brian Itow, Gary Marcos, JulioRoque, and Matt Samsonoff of AZORA Technologies Most importantly, Iwould like to thank my partner, Canares (‘‘Chicho’’) Aban, for his dedicationand support during this project

— Marc J Balcer

Part One Understanding SOA

xiii

Appendix A Business Use Cases 579

Acknowledgments ix

Architectural Styles 29

3 Integrating Packaged and Legacy Systems into the Service

Specifying the Application Infrastructure Required to

Determining the Development Environment, Frameworks,

Identifying Granularity 217

Chapter 8 Composing Services 273

Layered SOA Architecture and Multitiered Application

Business Activity Monitoring 338

Enterprise Service Bus-Unified Infrastructure for Enterprise

Using Messaging Infrastructure to Implement Integration

Web Service Security Standards and Specifications 405

Applying Concepts from This Chapter — A Simple Case

Deploy-Time Governance 469

ACME’s Implementation of Integration with COM

ACME’s Implementation of Integration for J2EE-Based

ACME’s Implementation of Integration Using the Vendor’s

Business Use Case BU03 — Change Policy 585

Welcome to Applied SOA: Service-Oriented Architecture and Design Strategies.

This book is designed to fill a gap that we see in available SOA information.The current collection of SOA books and articles is rich on high-level theorybut light on practical advice At the other end of the spectrum are the WebServices books that concentrate on APIs and programming, but gloss over thearchitecture This book focuses on an area that most other books ignore, offeringthe reader a practical guide for applying design strategies to service-orientedsolutions It targets the practical application of SOA and appeals to architects,analysts, designers, and CTO/CIOs, as they roll out concrete strategies anddesigns for their organizations and projects

The book starts by discussing the expected benefits of SOA and the tectural principles needed to realize them, which lead to successful solutions.Then, it provides an overview of the process for designing services andservice-oriented solutions Each major step of the process is followed by achapter that describes the detailed practices and principles for that step, withhandy tips and techniques for applying them Of course, no SOA solutionwould be complete without integrating legacy systems and applications, pro-viding security, or having appropriate governance, so these topics are alsocovered in depth Throughout the book, the principles are demonstrated withrelevant examples Finally, the book concludes with two different extensivecase studies that illustrate the architecture and design strategies

archi-Why This Book Was Written

Service-Oriented Architecture (SOA) is the current state of the art in ITapplication architecture As a result, platforms and tools that support SOA are

xxvii

hitting the market every week Every major software vendor, including IBM,Microsoft, Oracle, and SAP has embraced SOA and is investing billions ofdollars to service-enable their product sets SOA is here to stay, and it is likely

to be the predominant architectural style for the next decade

Most SOA implementations are based on Web Service technologies, whichhave matured to the point where there are many mission-critical implemen-tations in production In addition, the training industry has ramped up toprovide considerable variety and opportunity for education in SOA and WebServices Yet, real service-oriented applications have not followed suit andthe promised benefits of SOA have not been realized for most organizations.Generally, the available literature and education fall short of providing whatcompanies really need to be successful

As we work with companies that are starting with SOA, or struggling withtheir current approach, we see several common areas of confusion:

First, what is SOA? In particular, what are the architectural aspects ofSOA compared to just Web Services or other distributed technologies?And beyond that, how should the architecture influence design?

Second, what is the relationship between business and SOA? What ishype and what is real? How does functional decomposition at the busi-ness process level translate into requirements and design for businessservices?

Third, how do you design a good service? This seems to be the mostmisunderstood aspect of SOA A meeting rarely goes by where someonedoesn’t ask, ‘‘How big should a service be?’’

Fourth, how do you effectively integrate existing applications and sources into a service-oriented solution? How can this be done whileavoiding the pitfalls of traditional EAI approaches? What does a goodintegration service look like?

re-And finally, how do services fit into overall enterprise solutions? What

is the layered and tiered structure of an SOA application architecture?Where do security, transactions, naming, and the other aspects of dis-tributed enterprise solutions fit in?

Anybody can build a service; that’s not the challenge facing IT professionalstoday In fact, the tools make it incredibly easy (often too easy) to build services,especially poorly designed ones The first challenge is to build a good service,based on solid design principles But still this is not enough The servicesmust also fit into an overall architecture that results in services that can becombined into larger business processes within the enterprise In other words,the architecture and the design process must provide an enterprise contextthat influences the design and implementation of services

The next decade will be filled with winners and also-rans Those companies

on top will have learned how to use IT as a strategic differentiator thatprovides them with a sustainable competitive advantage This will be built on

a foundation of SOA that exposes the fundamental business capabilities andinformation as flexible, reusable services These services will support a layer

of business processes that can be easily changed to provide new products andservices to keep ahead of the competition But this is easier to show in a Visiodiagram than to actually achieve The good news is that this book starts toshow you how The bad news is that it’s still hard

The goal of Applied SOA: Service-Oriented Architecture and Design Strategies

is to provide the architecture and design principles and methodology thataddress these challenges and empower the reader to develop successfulimplementations that deliver the expected benefits of SOA

Who This Book Is For

This is primarily a technical book, focused on architects, designers, businessanalysts, IT managers, and executives It is not a book about writing code; infact, there is no code in the book It is about architecture and design, what theimportant principles of SOA are, and how they should be applied It delves intoeach of the important aspects of architecture, including business, information,application, and technology, as they relate to service-oriented solutions:

Architectswill learn the relationships between architectural concerns,

enterprise context, and the SOA design process This is particularly

important in making architecture actionable As architects, you should

always remember that creating architecture itself provides little value

The value comes from using the architecture to help projects meet diate needs, but in a way that also meets the needs and longer-term goals

imme-of the overall enterprise This is critical to realizing the promise imme-of SOA

Designerswill learn a step-by-step process for the analysis and design

of services, and what the different types and styles of services are They

will come to understand what information is required from the businessfor complete service design, how that relates to process and informationmodels, and how it shows up in the different design artifacts But most

importantly, they will learn how to start thinking in terms of SOA; in

other words, how to shift their design paradigm

Business analystswill learn the relationship between business

strate-gies, goals, and objectives, and the capabilities and information that are

used to achieve them The direct link between capabilities, business vices, and business processes will be illustrated Analysts will learn how

ser-to use business process models as the link between business architectureand IT design, specifically SOA.

Managers and executiveswill get an understanding of the SOA tecture and design process that will enable them to understand, govern,plan, and manage SOA projects that deliver value to both their immedi-ate project and to the enterprise

archi-What This Book Covers

This book provides architects, designers, and analysts with the principles andtechniques necessary to create superior-quality service-oriented architecturesand solutions It enables them to go beyond building services to actuallydeliver on SOA’s promises of agility and flexibility by providing practical andactionable advice that leads directly to better architecture and design

Thus, the book is about the architecture and design of service-orientedsolutions and systems It is not a high-level overview of the benefits ofSOA, nor is it a user’s manual for the technologies and standards of SOAimplementation (i.e., Web Services) Instead, it focuses on the difficult area

in between, to provide a methodology for designing not only simple servicesbut also service-oriented solutions that incorporate legacy integration andsecurity

The book is technical in that it provides detailed, step-by-step proceduresand examples of architecture and design However, it generally does not delveinto APIs and code, except to illustrate the design implications of certaintechnologies and standards In addition, this book contains two detailed casestudies that illustrate the concepts and techniques presented throughout

How This Book Is Structured

This book is structured in three sections: an overview of the architecture,service and solution design, and case studies:

Part I : Understanding SOA — This section provides the motivation for

SOA and the architectural requirements needed to meet them, then describesSOA architecture structure and principles, and finally describes the processfor getting started with SOA in the enterprise

Chapter 1 : ‘‘Realizing the Promise of SOA’’ describes the primary

moti-vations for SOA in the industry, such as improved flexibility, reducedcosts, and competitive advantage Given these motivations and expec-tations, what is really required from IT to deliver on that promise? This

question is explored in depth and the answer presented as the

require-ments that SOA architecture must meet to achieve the promise

Chapter 2 : ‘‘SOA — Architecture Fundamentals’’ describes the SOA

ref-erence architecture and how that meets the challenges and requirementslaid out in Chapter 1 It describes the overall enterprise context, the

architectural layers and tiers, the domain-specific concepts and

abstrac-tions, and specifically what a service is and the important architectural

characteristics of a service

Chapter 3 : ‘‘Getting Started with SOA’’ describes the overall process for

initiation of SOA activities, aligning SOA with the business, identifying

and specifying services, designing service interfaces and

implementa-tions, and creating solutions

Part II : Designing SOA — This section explores the details of each step in

the design process It is roughly divided into two main areas: Chapters 4–7cover the design of services and Chapters 8–12 focus on building enterpriseSOA solutions

Chapter 4 : ‘‘Starting with the Business’’ describes a business

architec-ture approach for SOA and how to use business architecarchitec-ture and

busi-ness process modeling to define services

Chapter 5 : ‘‘Service Context and Common Semantics’’ focuses on the

overall enterprise context for SOA, specifically the common semantic

model and the service inventory It describes how to discover the

com-mon semantic model, tips and techniques for developing it, how to

cre-ate and use a service inventory, and how it fits with the semantic model

Chapter 6 : ‘‘Designing Service Interfaces’’ digs into the details of

ser-vice interface design It shows how to use the business and enterprise

contexts established in Chapters 4 and 5 in the service interface design

and discusses issues of interaction and usage style in terms of design

Then, it presents an in-depth example of the design of an interface for anautomobile insurance solution

Chapter 7 : ‘‘Designing Service Implementations’’ continues with details

on the design of the service implementation It describes the techniques

for defining the technology independent design of service operations

and the specification of schema for the documents that are the inputs andoutputs for those operations It extends the example from Chapter 6 to

illustrate the design of the service operations

Chapter 8 : ‘‘Composing Services’’ goes into detail about the important

techniques of service composition It describes the tradeoffs and

advan-tages of a variety of different approaches, addresses the role of Business

Process Execution Languages (BPEL) and Service Component tecture (SCA) in composition, provides some useful do’s and don’ts,and finishes with an example of a service composition using BPEL.

Archi-Chapter 9 : ‘‘Using Services to Build Enterprise Solutions’’ describes

the role services play in an overall enterprise solution It describes how

services fit into the classical n-tier architecture, discusses issues of service

location and discovery, exception handling, management and ing, service evolution, and the use of Enterprise Service Buses (ESBs) toimplement SOA solutions

monitor-Chapter 10 : ‘‘Designing and Using Integration in SOA Solutions’’

focuses on the difficult problem of creating services that integrate ing applications and data It starts with the architectural issues of service-based integration and then goes into details about the design and imple-mentation of integration services, providing a toolbag of techniques andtradeoffs for different integration scenarios

exist-Chapter 11 : ‘‘SOA Security’’ addresses the thorny questions of security.

Again, it starts with an architectural overview of the different types ofsecurity and the type of threats and challenges they address Then, itprovides an overview of the most common security standards in SOA.Next, it presents a set of ‘‘security blueprints’’ or guidelines for deter-mining the right security solution, and the patterns for applying them.The chapter finishes with suggestions and a game plan for the securityarchitect

Chapter 12 : ‘‘SOA Governance’’ takes up the issues of keeping your

SOA solutions and architecture running and on track It describes thelife cycle of services, and the issues of management and governancethroughout the different phases of the life cycle This includes tips andtechniques for practical SOA governance

Part III : Case Studies — This section illustrates architecture and design

principles and strategies by exploring two different case studies in depth Thefirst focuses on designing business services to support business processes.The second focuses on integrating existing applications into a service-orientedsolution

Chapter 13 : ‘‘Case Study — Travel Insurance’’ provides a case study of

an SOA implementation from the travel industry The case study startswith the business architecture and works through to the design of theservice interface and implementation, highlighting the architectural con-cerns and design strategies presented in Part II

Chapter 14 : ‘‘Case Study — Service-Based Integration in Insurance’’

provides a case study of the implementation of integration services in

the insurance industry The example illustrates the design and

imple-mentation of multiple different integration services based on existing

customer information control (CICS), commercial off-the-shelf (COTS),

Java, database, and other systems and shows how they can be used in anenterprise solution

Appendix A : ‘‘Business Use Cases’’ provides the detailed use cases for

the example used in Chapters 6 and 7

Appendix B : ‘‘Evaluating SOA Services’’ provides a handy list for

eval-uating services against the important architectural and design criteria

presented in this book

Appendix C : ‘‘Additional Reading’’ provides a list of resources on

SOA and all of the references used while researching the book

What You Need to Use This Book

Beyond a basic desire to learn about architecture and design, there are no otherrequirements for the book Many of the design and implementation examplesuse UML models, so a basic ability to read these models will help, but it is notnecessary We have tried to steer clear of complex models

Final Thoughts

This book is meant to lay out the important aspects and strategies of ture and design for SOA solutions Our challenge was not deciding what toput into the book but deciding what to cut out As it is, we went way over ouroriginal estimate for length It is not possible to cover every possible aspect ofdesign and architecture for SOA solutions in a single text We have provided

architec-a lengthy list of references architec-and other rearchitec-adings in Appendix C to supplementthe material here

But we do think that we’ve covered material that is not well served by mostother SOA books, and that is critical to SOA success We sincerely hope thatyou find it useful and are able to incorporate it into your SOA solutions

Understanding SOA

In This Part

Chapter 1:Realizing the Promise of SOA

Chapter 2:SOA — Architecture Fundamentals

Chapter 3:Getting Started with SOA

Realizing the Promise of SOA

Those who do not remember the past are condemned to repeat it.

— George Santayana

Everyone has heard the many promises and benefits of Service-Oriented tecture (SOA), and you’ve all probably heard a dozen different definitions ofwhat SOA is or isn’t We’re going to take a different approach We want

Archi-to paint a picture of what SOA can deliver and the promise of SOA, andthen describe the challenges that organizations face in realizing that promise.Together, the vision and the challenges provide a set of requirements thatthe architecture must meet to make your implementation of SOA successful

at delivering the promised benefits Throughout the book, we’ll describe thedetailed architecture, design principles, and techniques that meet those archi-tectural requirements, make the architecture actionable, and deliver results Inthis chapter, you look at:

What did and didn’t work in the past

The promise of SOA to the enterprise

The challenges of delivering on that promise

How to meet the challenge (the subject of this book)

But first, let’s start with a little story The scenario is true although the nameshave been changed

3

Once Upon a Time

Back in 1994, a major U.S bank was trying to resolve a problem with customerservice Like pretty much every bank at that time, all of the different products(i.e., different types of accounts) were implemented on different mainframesystems When you telephoned the customer service representative, you spoke

to a beleaguered person with numerous green screen terminals on his or herdesktop

If you wanted information about your checking account, the customer vice representative went to one terminal and entered your account number Ifyou wanted information about your savings account, the representative had toget a different account number from you and enter that in a different terminal.Each account system had a different interface Together, they provided a con-fusing mix of commands and interaction that necessitated expensive trainingand was error prone Customer satisfaction with problem resolution was low,employee satisfaction was low, and retention of both was problematic

ser-So what’s a bank to do? First, they set about rationalizing the interface toall of the systems into a consistent interface, on a single terminal Solutionssuch as 3270 emulators and PCs were tossed around but discarded becausethey only reduced the number of terminals, not the complexity of multipleinterfaces Instead, the bank took a gamble on a relatively new, distributedtechnology, Common Object Request Broker Architecture (CORBA)

The specific technology they chose is less important than the approach Thefirst thing they did was to create distributed objects to represent the differenttypes of accounts These objects provided an abstraction layer between the userinterface and the mainframe systems that actually implemented the accounts.Next, they wrote a new user interface, using Visual Basic (VB), that providedaccount information to the customer service representatives by accessing thedifferent systems via the CORBA objects

It took about 6 months to get the basic functions in place — a new userinterface, VB/CORBA bridging, and simple account objects — and then theywere able to start replacing some of the green screen terminals At this point,they began to understand the potential of the approach They had essentiallyimplemented the beginnings of a 3-tiered application architecture by separat-ing the presentation, business logic, and operational systems Figure 1-1 shows

a simplified view of their solutions

The next enhancement was to implement a customer relationship object inthe logic tier What this did was to take any account number or customer name,find all of the accounts that belonged to that customer, and provide that infor-mation to the customer service representative Now, the customers didn’t need

to keep track of all their different account numbers in order to do business withthe bank The next incremental improvement was to automatically look up