Service Oriented Architecture For Dummies ®, 2nd Edition
Chapter 1: Getting to Know SOA &
Chapter 7: Discovering the Main Components of SOA
ISBN: 978-0-470-37684-3
Copyright of Wiley Publishing, Inc. Indianapolis, Indiana
Posted with Permission
Contents at a GlanceIntroduction ................................................................ 1
Part I: Getting Started with SOA .................................. 5Chapter 1: Getting to Know SOA ...................................................................................... 7
Chapter 2: Are You Ready for SOA? A Self Test ........................................................... 17
Chapter 3: Making Sure SOA Happens .......................................................................... 25
Chapter 4: SOA Quick Start: Entry Points for Starting the SOA Journey.................. 35
Part II: Introducing SOA Basics .................................. 41Chapter 5: Understanding Software Architecture ....................................................... 43
Chapter 6: Working with Software Components .......................................................... 57
Chapter 7: Discovering the Main Components of SOA ............................................... 71
Chapter 8: Playing Fast and Loose: Loose Coupling and Federation ........................ 87
Chapter 9: The Collaborative Lifecycle of the Business Process .............................. 99
Part III: Nitty-Gritty SOA ........................................ 113Chapter 10: (e)Xplaining XML ...................................................................................... 115
Chapter 11: Dealing with Adapters .............................................................................. 129
Chapter 12: Discovering the Service Broker .............................................................. 139
Chapter 13: The Enterprise Service Bus ..................................................................... 147
Chapter 14: The SOA Service Manager ....................................................................... 161
Part IV: SOA Sustenance .......................................... 173Chapter 15: SOA Governance ....................................................................................... 175
Chapter 16: SOA Security .............................................................................................. 185
Chapter 17: Turning Data into Services ...................................................................... 197
Chapter 18: SOA Software Development ..................................................................... 211
Chapter 19: The Registry and the Repository ............................................................ 229
Chapter 20: Putting Quality into SOA .......................................................................... 243
02_376843-ftoc.indd vii02_376843-ftoc.indd vii 12/2/08 11:47:46 PM12/2/08 11:47:46 PM
Part V: Real Life with SOA ....................................... 251Chapter 21: Financial Services ..................................................................................... 253
Chapter 22: Government ............................................................................................... 267
Chapter 23: Healthcare ................................................................................................. 279
Chapter 24: Hospitality and Travel ............................................................................. 291
Chapter 25: Information Services ................................................................................ 299
Chapter 26: Manufacturing and Distribution ............................................................. 313
Chapter 27: Retail........................................................................................................... 319
Chapter 28: Telecommunications ................................................................................ 331
Chapter 29: Utilities and Energy .................................................................................. 341
Part VI: The Part of Tens .......................................... 351Chapter 30: Ten Swell SOA Resources ........................................................................ 353
Chapter 31: Ten SOA No-Nos ........................................................................................ 357
Glossary .................................................................. 361
Index ...................................................................... 373
02_376843-ftoc.indd viii02_376843-ftoc.indd viii 12/2/08 11:47:46 PM12/2/08 11:47:46 PM
Table of ContentsIntroduction ................................................................. 1
About This Book .............................................................................................. 1
Foolish Assumptions ....................................................................................... 2
How This Book Is Organized .......................................................................... 2
Part I: Getting Started with SOA ........................................................... 2
Part II: Introducing SOA Basics ............................................................ 3
Part III: Nitty-Gritty SOA ........................................................................ 3
Part IV: SOA Sustenance ....................................................................... 3
Part V: Real Life with SOA ..................................................................... 3
Part VI: The Part of Tens ....................................................................... 3
Icons Used in This Book ................................................................................. 4
Where to Go from Here ................................................................................... 4
Part I: Getting Started with SOA ................................... 5
Chapter 1: Getting to Know SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7Business Lib ..................................................................................................... 8
Tech Lib ............................................................................................................ 9
A SOA Case Study ............................................................................................ 9
Better Living through Reuse ........................................................................ 11
Moving in Tandem with SOA ........................................................................ 13
Sweeping Unsightly Technology under the Rug ........................................ 14
Understanding Why SOA Is Different .......................................................... 14
Chapter 2: Are You Ready for SOA? A Self Test . . . . . . . . . . . . . . . . . . .17Question 1: Is Your Business Ecosystem Broad and Complex? .............. 18
Question 2: Is Your Industry Changing Quickly? ....................................... 19
Question 3: Do You Have Hidden Gems inside Your
Software Applications? .............................................................................. 19
Question 4: Are Your Software Systems Flexible? ..................................... 20
Question 5: How Well Prepared Is Your Organization
to Embrace Change? .................................................................................. 20
Question 6: How Dependable Are the Services Provided by IT? ............. 21
Question 7: Can Your Company’s Technology Support
Corporate and IT Governance Standards? ............................................. 21
Question 8: Do You Know Where Your Business Rules Are? ................... 22
Question 9: Is Your Corporate Data Flexible,
and Do You Trust Its Quality? .................................................................. 23
Question 10: Can You Connect Your Software Assets
to Entities outside the Organization? ...................................................... 23
What’s Your Score? ....................................................................................... 24
02_376843-ftoc.indd ix02_376843-ftoc.indd ix 12/2/08 11:47:46 PM12/2/08 11:47:46 PM
Service Oriented Architecture For Dummies, 2nd Edition xChapter 3: Making Sure SOA Happens. . . . . . . . . . . . . . . . . . . . . . . . . . .25
Overcoming Fears about SOA ...................................................................... 26
Assuring a Better Quality of Service ........................................................... 27
Complying with Government Regulation .................................................... 28
Educating Rita and Peter and Raul and Ginger .......................................... 28
Choosing a Test Case Carefully ................................................................... 29
Revolutionizing IT to Work with SOA .......................................................... 30
Fostering Creativity, but with a Caveat ...................................................... 31
Banishing Blame and Working Together .................................................... 32
Documenting and Marketing Your Successes ............................................ 33
Planning for Success ..................................................................................... 33
Chapter 4: SOA Quick Start: Entry Points for Starting the SOA Journey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
Mapping Your Organization’s Business Structure .................................... 36
Picking Your Initial SOA Targets to Gain Experience
and Demonstrate Success ......................................................................... 37
Preparing Your Organization for SOA ......................................................... 38
IT developers need a different approach ......................................... 38
Business managers need to look beyond
their own departments .................................................................... 39
Finding Out Why Business Partners Are Part
of the SOA Success Story .......................................................................... 39
Getting Help with SOA ................................................................................... 40
Setting Off to the Races ................................................................................. 40
Part II: Introducing SOA Basics ................................... 41
Chapter 5: Understanding Software Architecture . . . . . . . . . . . . . . . . .43Defi ning a Service Oriented Architecture ................................................... 44
Defi ning an Architecture ............................................................................... 45
Basic architecture ................................................................................ 46
Basic service ......................................................................................... 47
Business services ................................................................................. 47
Elementary service oriented architecture ........................................ 48
Understanding Four Problems That Complicate SOA .............................. 49
Complication #1: You have to keep the business logic
and plumbing separate .................................................................... 50
Complication #2: You don’t start from scratch ............................... 52
Complication #3: Application logic creeps in to
the business layer ............................................................................ 53
Complication #4: Coordinating the components can be tricky ..... 54
Why SOA? Better Business and Better IT ................................................... 56
02_376843-ftoc.indd x02_376843-ftoc.indd x 12/2/08 11:47:46 PM12/2/08 11:47:46 PM
xi Table of Contents
Chapter 6: Working with Software Components . . . . . . . . . . . . . . . . . .57Components and Component Wannabes ................................................... 57
Understanding software components ............................................... 58
Making sure your components play nicely together ....................... 59
Building in reusability ......................................................................... 60
Web Services: The Early Days ...................................................................... 61
When Web Services Grow Up ....................................................................... 64
Defi ning Business Processes ........................................................................ 65
Understanding a business process example .................................... 66
Seeing how business processes are like production lines ............. 67
Creating New Applications from Old: Composite Applications .............. 67
Moving toward end-to-end process ................................................... 68
Adopting business processes and composite applications ........... 70
Chapter 7: Discovering the Main Components of SOA . . . . . . . . . . . . .71Making SOA Happen ...................................................................................... 71
Catching the Enterprise Service Bus ........................................................... 72
Welcome to the SOA Registry and Repository .......................................... 73
Orchestrating End-to-End Services ............................................................. 75
Introducing the business process orchestration manager ............ 75
Your friendly neighborhood service broker .................................... 76
The SOA service manager, again ....................................................... 76
Managing Business Process under SOA ..................................................... 77
BPM terminology ................................................................................. 79
BPM tools .............................................................................................. 79
Application failures: Let us count the ways ..................................... 82
Measuring service levels ..................................................................... 83
End-to-end service ............................................................................... 84
Taking just one more look at the Process Manager ........................ 85
Chapter 8: Playing Fast and Loose: Loose Coupling and Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
Understanding Software Dependencies ...................................................... 88
Loose Coupling .............................................................................................. 89
Seeing Software as a Service ........................................................................ 91
Licensing models and service ............................................................ 92
Software as a service and SOA ........................................................... 93
Implementing a Federated Software Structure .......................................... 94
SOA and federation .............................................................................. 95
Federated identity management ........................................................ 97
Federated information management ................................................. 97
Discovering the Industrialization of Software ............................................ 97
02_376843-ftoc.indd xi02_376843-ftoc.indd xi 12/2/08 11:47:46 PM12/2/08 11:47:46 PM
Service Oriented Architecture For Dummies, 2nd Edition xiiChapter 9: The Collaborative Lifecycle of the Business Process . . . .99
Fitting Enterprise Architecture with SOA ................................................. 100
Managing Business Processes ................................................................... 101
A language called BPEL ..................................................................... 101
Managing business processes:
Orchestration and monitoring ...................................................... 102
The Dawn of Unifi ed Communications ..................................................... 103
Figuring out why communications need unifying.......................... 104
Discovering the benefi ts of unifi ed communications .................... 105
Simple presence versus complex presence ................................... 105
Communications Enabled Business Processing ...................................... 107
Making Unifi ed Communications Dynamic .............................................. 109
Web 2.0 and social networks ............................................................ 110
Web 2.0 and SOA: You complete me ............................................... 112
Part III: Nitty-Gritty SOA ......................................... 113
Chapter 10: (e)Xplaining XML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115My Computer Is a Lousy Linguist .............................................................. 116
So what is XML exactly? .................................................................... 117
XML’s extensibility ............................................................................ 118
How does XML work? ........................................................................ 119
Discovering other technologies that work with XML.................... 120
A Little Bit of SOAP (And WSDL) ............................................................... 123
Name spaces ....................................................................................... 124
SOAP comes in envelopes................................................................. 124
REST..................................................................................................... 125
WSDL ................................................................................................... 126
Chapter 11: Dealing with Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129Making Connections .................................................................................... 130
In a Bind: When Software Components Get Together ............................ 132
Getting to Know Your Adapter Options ................................................... 133
Building an Adapter ..................................................................................... 135
Chapter 12: Discovering the Service Broker. . . . . . . . . . . . . . . . . . . . .139Defi ning the Central Role of the Service Broker ...................................... 140
Sitting Between Consumers and Providers .............................................. 140
Seeing the Registry and Repository as the Broker’s Partners ............... 141
Calling on the SOA registry ............................................................... 141
Collecting information for the repository....................................... 142
Brokering a Deal .......................................................................................... 143
Understanding the Service Broker’s Responsibilities ............................ 144
02_376843-ftoc.indd xii02_376843-ftoc.indd xii 12/2/08 11:47:46 PM12/2/08 11:47:46 PM
xiii Table of Contents
Chapter 13: The Enterprise Service Bus. . . . . . . . . . . . . . . . . . . . . . . . .147Discovering ESB Basics ............................................................................... 148
Finding Out What’s inside the Bus ............................................................ 151
ESB Services: Of Messages, Management, and Security ......................... 153
Messaging services ............................................................................ 153
Management services ........................................................................ 155
Interface services ............................................................................... 156
Mediation services ............................................................................. 157
Metadata services .............................................................................. 157
Security services ................................................................................ 158
Running the Enterprise Service Bus .......................................................... 159
No ESB is an island ............................................................................ 159
The ESB keeps things loose .............................................................. 160
The ESB delivers predictability........................................................ 160
Chapter 14: The SOA Service Manager . . . . . . . . . . . . . . . . . . . . . . . . .161Getting to Know the Plumbing ................................................................... 162
Cutting the IT layer cake ................................................................... 163
Looking at the plumbing service...................................................... 164
Grasping the Role of the SOA Service Manager ....................................... 168
SOA service management: The inside view .................................... 169
Getting real ......................................................................................... 170
Part IV: SOA Sustenance ........................................... 173
Chapter 15: SOA Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175Understanding SOA Governance ............................................................... 175
Governing IT ....................................................................................... 177
Figuring out the SOA wrinkle in IT governance ............................. 177
Collaborating to Meet Business Goals Gained
from Business Services ........................................................................... 178
Chapter 16: SOA Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185Seeing How the User Fits in the Security Equation ................................. 186
Deciding What the User Can Do ................................................................. 187
Identity management software......................................................... 188
Why identity management software works .................................... 190
Authenticating Software and Data ............................................................. 191
Software fi ngerprints ......................................................................... 192
Digital certifi cates .............................................................................. 193
Auditing and the Enterprise Service Bus .................................................. 195
02_376843-ftoc.indd xiii02_376843-ftoc.indd xiii 12/2/08 11:47:46 PM12/2/08 11:47:46 PM
Service Oriented Architecture For Dummies, 2nd Edition xivChapter 17: Turning Data into Services . . . . . . . . . . . . . . . . . . . . . . . . .197
When Good Data Goes Bad: Getting Clean and Consistent Data ........... 197
Discovering Dastardly Data Silos: An Example ........................................ 200
Trust Me: Integrating Data Sources ........................................................... 202
Data profi ling ...................................................................................... 203
Data quality......................................................................................... 203
Data transformation .......................................................................... 204
Data governance and auditing ......................................................... 204
Providing Information as a Service ........................................................... 205
Data control ........................................................................................ 205
Consistent data defi nitions ............................................................... 206
Ensuring quality of data .................................................................... 208
Data services ...................................................................................... 209
Data independence ............................................................................ 210
Chapter 18: SOA Software Development . . . . . . . . . . . . . . . . . . . . . . . .211Building a Business Process Map .............................................................. 212
Exploring New SOA-Specifi c Software Development Tools .................... 214
Defi ning the Software Development Life Cycle ........................................ 215
BPM tools and software development ............................................ 217
Mapping the business process......................................................... 218
Combining SOA and the Rich Interfaces ................................................... 220
The rich interface .............................................................................. 221
Cloud computing ................................................................................ 222
Discovering Mashups .................................................................................. 223
Creating Software Ecosystems ................................................................... 224
Taming Mashups, Plugins, and Downloads .............................................. 226
Chapter 19: The Registry and the Repository . . . . . . . . . . . . . . . . . . . .229Enabling the Reuse of Business Services ................................................. 229
Combining Governance and Reuse ........................................................... 231
Understanding the Registry and the Repository ..................................... 231
Introducing the Service Broker .................................................................. 232
“Signing” the Registry ................................................................................. 233
All about the repository .................................................................... 234
Reuse of business services and SLAs .............................................. 236
Working Together: Governance, the Repository, and the Registry ...... 237
The repository and internal publishing .......................................... 239
The registry and real-time governance ........................................... 240
The registry and external publishing .............................................. 240
Chapter 20: Putting Quality into SOA . . . . . . . . . . . . . . . . . . . . . . . . . . .243Grasping the Unexpected Challenges of SOA .......................................... 244
Remembering the Good Old Days of Software Quality ........................... 245
Unit testing of Web Services ............................................................. 247
Integration testing.............................................................................. 247
Stress testing and performance testing .......................................... 248
02_376843-ftoc.indd xiv02_376843-ftoc.indd xiv 12/2/08 11:47:46 PM12/2/08 11:47:46 PM
xv Table of Contents
Understanding Why SOA Quality Is Beyond Testing .............................. 248
The nature of SOA complicates testing........................................... 248
Virtual SOA testing ............................................................................ 249
Part V: Real Life with SOA ........................................ 251
Chapter 21: Financial Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .253CIGNA ............................................................................................................ 254
Business and IT collaboration .......................................................... 255
Why this approach works ................................................................. 257
Innoveo Solutions ........................................................................................ 257
Innoveo is born .................................................................................. 258
Innoveo’s approach ........................................................................... 258
Next steps ........................................................................................... 261
Jack Henry & Associates ............................................................................. 261
The business problem ....................................................................... 262
The SOA solution ............................................................................... 262
Expanding opportunities for growth with SOA .............................. 263
Creating business services ............................................................... 264
Reaping the benefi ts of SOA ............................................................. 265
Chapter 22: Government . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .267The Defense Intelligence Agency ............................................................... 268
PKI meets data composites .............................................................. 269
The next frontier: Collaboration ...................................................... 271
Hampshire County Council ........................................................................ 272
SOA and information sharing ........................................................... 272
Eliminating boundaries ..................................................................... 273
CommIT Enterprises ................................................................................... 274
Applying semantics in a service oriented architecture ................ 275
The impact of semantic models on building a SOA ....................... 276
The importance of context ............................................................... 277
SOA and ’Net-centric warfare ........................................................... 278
Chapter 23: Healthcare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .279AstraZeneca .................................................................................................. 280
AstraZeneca and SOA ........................................................................ 280
Organizational backing for SOA ....................................................... 281
Going forward ..................................................................................... 282
Independence Blue Cross ........................................................................... 283
Strategic SOA ...................................................................................... 283
Step 1: Governing SOA....................................................................... 284
Step 2: Application developers take a leap of faith ....................... 285
What’s next for IBC? .......................................................................... 286
Lessons learned ................................................................................. 286
02_376843-ftoc.indd xv02_376843-ftoc.indd xv 12/2/08 11:47:46 PM12/2/08 11:47:46 PM
Service Oriented Architecture For Dummies, 2nd Edition xvi
Partners HealthCare .................................................................................... 287
Decoupling the data from the application ...................................... 287
Working with Partners ...................................................................... 288
High Performance Medicine ............................................................. 289
Chapter 24: Hospitality and Travel . . . . . . . . . . . . . . . . . . . . . . . . . . . . .291Gaylord Hotels ............................................................................................. 292
Standardization of the Property Management System ................. 293
A new look at third-party hosted applications .............................. 294
What’s next for Gaylord hotels ........................................................ 294
InterContinental Hotels Group ................................................................... 295
Distributing key channel information ............................................. 295
SOA implementation highlights ....................................................... 296
IHG’s SOA reference architecture: A self-healing ecosystem ....... 297
Lessons learned in IHG’s journey to SOA ....................................... 298
Chapter 25: Information Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .299R.L. Polk & Co. .............................................................................................. 299
The business challenge ..................................................................... 300
The IT challenge ................................................................................. 301
Decoding a vehicle ............................................................................. 302
Data as a service ................................................................................ 303
Lessons learned after four years of SOA ......................................... 304
Redlasso ........................................................................................................ 306
How does Redlasso do it? ................................................................. 306
SOA, speed, and scale ....................................................................... 307
Moving forward .................................................................................. 307
Thomson Reuters ........................................................................................ 308
Finding a solution to improve agility and time to market ............ 309
Business units gain control of business services with SOA ......... 310
Working with the registry ................................................................. 311
A repository is added to the mix ..................................................... 312
The benefi t of SOA ............................................................................. 312
Chapter 26: Manufacturing and Distribution. . . . . . . . . . . . . . . . . . . . .313Avnet ............................................................................................................. 314
The gateway........................................................................................ 314
Questions to think about before embarking on SOA..................... 315
Cisco .............................................................................................................. 316
Transforming to SOA ......................................................................... 317
Changing the nature of partnerships with SOA ............................. 318
Chapter 27: Retail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .319Spotlight Pty Ltd. ......................................................................................... 320
Step 1: The point-of-sale system ...................................................... 321
Step 2: The ERP system and beyond ............................................... 322
02_376843-ftoc.indd xvi02_376843-ftoc.indd xvi 12/2/08 11:47:46 PM12/2/08 11:47:46 PM
xvii Table of Contents
Choosing the right technology ......................................................... 322
Best practices for fast tracking SOA ................................................ 323
The Carphone Warehouse PLC .................................................................. 324
Dealing with growth........................................................................... 324
Build or buy ........................................................................................ 325
Selecting reusable components ....................................................... 326
Dealing with organizational issues .................................................. 326
Going forward ..................................................................................... 327
Virgin Entertainment Group ....................................................................... 328
Turning data into services ................................................................ 329
Lessons learned ................................................................................. 329
Chapter 28: Telecommunications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .331Bell Aliant ..................................................................................................... 332
SOA and system interfaces ............................................................... 332
Selling the approach using ROI ........................................................ 333
What’s next? ....................................................................................... 334
Telenor Iris ................................................................................................... 334
The enterprise service bus ............................................................... 335
Scaling the service ............................................................................. 336
What’s next? ....................................................................................... 337
Cadtel Systems ............................................................................................. 337
Part 1: A business process SOA approach ..................................... 338
Part 2: How SOA helps to close the deal ......................................... 339
Chapter 29: Utilities and Energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .341Austin Energy ............................................................................................... 341
Picking the low-hanging fruit ............................................................ 342
Checking out SOA behind the scenes.............................................. 344
Delaware Electric ......................................................................................... 345
Looking to IT to solve business problems ...................................... 345
Getting some SOA help...................................................................... 346
Realizing the importance of business process .............................. 347
Part VI: The Part of Tens ........................................... 351
Chapter 30: Ten Swell SOA Resources . . . . . . . . . . . . . . . . . . . . . . . . .353Hurwitz & Associates .................................................................................. 353
SOA Consortium .......................................................................................... 353
Finding OASIS ............................................................................................... 354
The Eclipse Foundation .............................................................................. 354
SOA Modeling ............................................................................................... 355
The SOA Institute ......................................................................................... 355
Check Out the Vendors’ Sites .................................................................... 355
Some Cool SOA Blogs .................................................................................. 355
Industry Groups Are Great Information Resources ................................ 356
Enterprise Architecture and Business Process Resources .................... 356
02_376843-ftoc.indd xvii02_376843-ftoc.indd xvii 12/2/08 11:47:46 PM12/2/08 11:47:46 PM
Service Oriented Architecture For Dummies, 2nd Edition xviii
Chapter 31: Ten SOA No-Nos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .357Don’t Boil the Ocean ................................................................................... 357
Don’t Confuse SOA with an IT Initiative .................................................... 357
Don’t Go It Alone .......................................................................................... 358
Don’t Think You’re Too Special ................................................................. 358
Don’t Neglect Governance .......................................................................... 358
Don’t Forget about Business Process ....................................................... 358
Don’t Forget about Security ....................................................................... 359
Don’t Apply SOA to Everything .................................................................. 359
Don’t Start from Scratch ............................................................................. 359
Don’t Postpone SOA .................................................................................... 359
Glossary .................................................................. 361
Index ....................................................................... 373
02_376843-ftoc.indd xviii02_376843-ftoc.indd xviii 12/2/08 11:47:46 PM12/2/08 11:47:46 PM
Chapter 1
Getting to Know SOAIn This Chapter▶ Finding out why you should care about SOA
▶ Liberating business from the constraints (and tyranny) of technology
▶ Illustrating the need for SOA
▶ Saving bundles by using what you have
▶ Expanding your SOA to customers, partners, and suppliers
▶ Focusing on function
Service oriented architecture (SOA) is a hot topic being bandied about by
IT vendors across the globe. IBM, Hewlett-Packard, Software AG, Oracle,
SAP, and Microsoft (just to drop a few names) are all singing from the SOA
songbook, and hundreds of vendors are adding their tunes as we speak.
“What’s SOA?” you ask. We suspect that you’ve already skimmed a dozen
articles and read (or deleted) hundreds of e-mails from vendors pushing SOA,
but the answers you’ve gotten so far have been, well, vague and inadequate.
The short answer is that SOA is a business approach to building IT systems
that allows businesses to
✓ Leverage existing assets
✓ Create new ones
✓ Easily enable the inevitable changes required to support the business
For you impatient readers out there, we expand on this short answer in
Chapter 5. However, right now, we think the more important question is, “Why
should I care about SOA?” In this chapter, we try to answer this question.
05_376843-ch01.indd 705_376843-ch01.indd 7 12/2/08 11:50:31 PM12/2/08 11:50:31 PM
8 Par t I: Get ting Started with SOA
The promise of service oriented architecture is to liberate business from
the constraints of technology, unshackling technologists and business lead-
ers from the chains they themselves have forged. (“IT workers of the world,
unite! You have nothing to lose but your chains!” as it were.) This has major
implications both for the business and for the IT structure that supports the
business.
From our perspective, one of the most important aspects of SOA is that it’s a
business approach and methodology as much as it is a technological approach
and methodology. SOA enables businesses to make business decisions sup-ported by technology instead of making business decisions determined by or constrained by technology. And with SOA, the folks in IT finally get to say
“yes” more often than they say “no.”
We pronounce SOA to rhyme with boa (bow-uh). Stretching it out by clearly
articulating each letter (S-O-A) is perfectly acceptable but might leave you sty-
mied when we say things like, “SOA what?”
Business LibExecutives have come to rely on technology — in terms of reporting, text
analytics, projections, graphical representations, risk analysis, and other
analytical tools — to make informed decisions for their company. The day-
to-day operations of a company have slipped, little by little, into the hands
of IT. Quite simply, more and more of the activities of an organization are
supported by increasing levels of business process automation — whether
its business is to build ships, sell insurance, or manage cities — and since IT
implements the automation of business process, business decision makers
have become more dependent upon IT. While this increasing use of technol-
ogy has helped the business in so many ways, technology has also created
significant constraints. At many companies, business and IT management
operate in very separate worlds without the benefit of a common unifying
language. Unfortunately, as organizations become more diverse and complex
through mergers, acquisitions, globalization, and the need to manage lots
more data, the supporting IT infrastructure has become more cumbersome
and brittle after being stretched in so many different ways to keep up with all
the changes. This is not good for business, and neither is it good for IT.
We’re not advocating that business leaders should (or can) take control of
the technology from the hands of IT. Modern businesses are inextricably tied
to technology. No sizable business can function without IT — it’s as simple
as that. However, we are advocating a new world order. Indeed, we advocate
that business leaders and IT work together to create this new world order.
Together, business leaders and IT will communicate how the automated pro-
cesses of its business should be facilitated, and work together to make it a
05_376843-ch01.indd 805_376843-ch01.indd 8 12/2/08 11:50:31 PM12/2/08 11:50:31 PM
9 Chapter 1: Get ting to Know SOA
reality by using SOA. Together, IT and business leaders can determine a strat-
egy that both liberates business from IT and allows IT to create maintainable,
extensible, compliant systems to support the initiatives determined by
business leaders.
Tech LibJust because business has become constrained by technology, don’t think
that the folks in IT are having a jolly old time basking in their new-found
power. On the contrary, the IT staff gets to spend its time in endless meet-
ings accounting for why projects are late, explaining why applications can’t
easily be adapted to changing business conditions, and pleading for more
staff. When some clever marketer presents a new concept for selling more
widgets via the Internet or mobile devices or some other new channel, IT
management is always the wet blanket, having to explain why (despite the
company’s investment in all the latest software and hardware) it will take 18
months to implement the new plan.
With SOA, business and IT have a way to meet each other half-way and col-
laborate using a business focused approach to develop new ways to use
technology to grow the firm, help to spot new trends and opportunities, and
see new ideas to fruition. But before you go marching off to save the world,
though, we have some more explaining to do. A story will help.
A SOA Case StudyOnce upon a time, there was an insurance company called ABC Insurance
Incorporated. When ABC was born — oh, maybe 150 years ago — it began
by selling insurance policies to factories and manufacturers. In those days,
there were no computers to mess things up. The company followed business
processes that were pretty simple. A nice person sent a letter inquiring about
a policy. A smart person set a rate, sold a policy, and hoped that nothing
caught fire or blew up. ABC thrived for more than 100 years.
But then, things got complicated. Other companies started stealing ABC’s
business. Customers were asking for insurance for different kinds of risk. ABC
had to change or die.
ABC was an early user of punch-card accounting systems. In the 1960s, ABC
bought computers, hired programmers, and built software applications to
support its business. In the 1980s, it bought software packages from different
05_376843-ch01.indd 905_376843-ch01.indd 9 12/2/08 11:50:31 PM12/2/08 11:50:31 PM
10 Par t I: Get ting Started with SOA
suppliers to help it continue to compete. It bought or built business applica-
tions to solve problems all over the company — one at a time. For example,
it bought an application for the corporate finance department, created one
to handle customer claims, and procured other applications to manage
research information about what type of accidents were most common under
what circumstances.
This worked well for many years, until the 1990s, when ABC found itself
competing against financial services companies who decided they could
sell insurance, too. Suddenly, ABC needed to find new ways to compete so
it could sell a larger variety of products to current customers and also find
some new customers. Its leaders thought up exciting new solutions based on
the knowledge of their business and their customers.
In addition, management thought ABC could expand its business by acquir-
ing other insurance companies with complementary products. ABC could sell
these new products to existing ABC customers and sell ABC’s products to the
customers of the companies they acquired. These smart guys and gals under-
stood business strategy. Everyone got really excited until . . .
Management talked to IT, and IT said, “This is really, really exciting, but we
have a small problem.”
“What could it be?” asked management.
“It’s this,” said IT. “We can no longer simply buy or build more software appli-
cations to implement our innovative plans for new products and services. The
business policies and processes that we follow have become more complex.
Everything we want to do has to work in concert with what we already have.
The very running of our company depends on all the business applications
that we built and acquired over years working together smoothly — such as
the programs that tally the premiums people pay; administer the claims we
process; and make risk analysis, payroll, invoicing, and sales commission cal-
culations. When you come right down to it, our company is the aggregation
of all our programs. Everything we need to carry out our day-to-day business
functions — including information about our customers, our products, and our
risk performance — is locked inside these programs and processes.”
“Well,” said management, “You can just write new programs to tie everything
together. We’ll integrate, and we’ll all be very happy.”
And IT said, “Yes, it is possible to integrate, but integrating will take a very, very long time: at least 18 months. Maybe two years. And by then, you might
want more changes that will take another 18 months or two years. By then, it
might be too late. And,” IT continued, “it will cost lots and lots of money.”
05_376843-ch01.indd 1005_376843-ch01.indd 10 12/2/08 11:50:31 PM12/2/08 11:50:31 PM
11 Chapter 1: Get ting to Know SOA
Management and IT were very sad. They knew that ABC wouldn’t survive if
they couldn’t find a new way of thinking about business process and technol-
ogy. So they began asking everyone they knew of any way to save ABC. They
searched, and they studied, and they prayed — until one day, a package
arrived. In that package were several copies of a yellow-and-black book titled,
Service Oriented Architecture For Dummies, 2nd Edition.
Both management and IT took copies of the book and read. They were very
excited to discover that they didn’t have to throw away valuable assets and
that they could reap benefits in a short time. In the end, they came up with a
new strategy, one based on five key elements:
✓ The IT organization will partner with the business managers to create
a high-level map of the business processes, followed by each line of
business. This will help identify the similarities, differences, and
interrelationships across the business lines for the company.
✓ The IT organization will create a flexible structure that will turn key IT
software assets into reusable business services that can be used no
matter how the business changes. These business services will include
everything from business processes and best practices to consistent
data definitions to code that performs specific business functions.
✓ The IT organization will begin replacing the hundreds of redundant busi-
ness services locked in old software with these new reusable services.
✓ The IT organization will use only accepted industry standards to link
these software assets.
✓ The IT organization will use the service oriented architecture concept
described in the rest of this book to begin to create business services
that are consistent with how the business operates.
Together, management and IT began a journey. As far as we know, they are
living happily ever after. In Part V, we give you many real-life case studies
from companies you might recognize that indeed are alive and well and living
happily on their journey to SOA.
Better Living through ReuseOne of the biggest deals in the SOA world is the tenet that you don’t have to
throw away things. You take the stuff (software assets) that you use every
day — well, the best of the stuff you use every day — and package it in a way
that lets you use it, reuse it, and keep on reusing it.
05_376843-ch01.indd 1105_376843-ch01.indd 11 12/2/08 11:50:31 PM12/2/08 11:50:31 PM
12 Par t I: Get ting Started with SOA
One problem common of many large companies that have been around for a
while is that they have lots of similar programs — software applications —
representing commonly used business processes. Every time a department
wants something slightly different, that department builds its own version of
the software so that across a particular company, you might find umpteen
versions of more or less the same processes — with, of course, slight varia-
tions. Many IT shops have policies and procedures designed to prevent this
sort of thing, but when deadlines loom and budgets are tight, it’s often easier
and quicker to write something from scratch that fills the need rather than to
coordinate with other divisions. This sort of duplication becomes a nightmare
when one company acquires another and finds that they have similar (but not
identical) applications purporting to do the same thing.
These slight variations are precisely what make systems very complicated
and expensive to maintain — even one business policy change might affect
lots of different applications. In situations like this, it’s very difficult to find
every instance in every application that needs to be changed. The testing
required for this type of application change management takes time away
from more innovative development work and can inhibit businesses from get-
ting to market quickly with new products.
With SOA, these important business processes — such as creating an invoice,
calculating an interest rate, securing a reservation — become business ser-
vices. Briefly, a business service is a sealed container of software code that
describes a specific business process that can be connected to other business
processes. (We talk more about this in Chapter 5.) You end up with one single
business service for a given function that gets used everywhere in your organi-
zation. With SOA, when you need to change a business policy, you change it in
only one place. And, because the same service is used everywhere, you have
consistency throughout your organization.
For example, you know that if you decide to create a new department in your
organization, you’re not going to create new Accounting, Human Resources,
Legal, Cleaning, Training, and Travel departments to go along with it. Even if
you need to add staff, you’ll likely use your existing Accounting, HR, Cleaning,
Training, and Travel departments to service — note the word service — this
new department.
The problem is that over time, IT ends up embedding redundant function
in programs everywhere in the organization. That redundancy — just like
having separate Accounting, HR, Legal, Cleaning, Training, and Travel depart-
ments for every department — is what SOA ultimately eliminates. This lack of
redundancy gives you the same obvious benefits of scalability, consistency,
and maintainability.
05_376843-ch01.indd 1205_376843-ch01.indd 12 12/2/08 11:50:31 PM12/2/08 11:50:31 PM
13 Chapter 1: Get ting to Know SOA
With SOA, business managers work with IT to identify business services.
Together, they determine policy and best practices. These policies and best
practices become codified business services that represent honed company
business processes. No need, for example, to have 30 different variations on
an exchange rate translation application, each used by a different department
and all requiring IT time for ongoing maintenance. One business service will
do. Onward, the new world order!
Moving in Tandem with SOAIn any formal dance, from the cha-cha to the waltz, form matters. The form
is what allows you to dance with someone you’ve never met. When both
partners truly know the form, they move in tandem, are flexible, and navigate
with ease and grace.
SOA is form. It enables the business to move, change, partner, and reinvent
itself with ease and grace. In the beginning, mastering new steps requires
focus and attention. Over time, the steps become second nature.
Implicit in the notion of form is standards. Using industry standard interfaces
and creating business services without dependencies (more on that later, we
promise) allows the business vastly more flexibility than it enjoys today to
change its business model, reorchestrate itself, and partner dynamically.
Redundant reiteration, againFor any IT old-timers out there who have labored long and hard in the IT trenches, the concept of software reuse isn’t new. You’re familiar with subroutine libraries and the great theme of object orientation, and you extol the virtues of standardization. “What’s the big deal with SOA?” you ask. “Aren’t we already doing this?” Well, yes and no. Yes, because the world of SOA depends on a good understanding of reuse and on the building of reusable components. No, because SOA extends the idea of reuse not
only to Web services but also to business ser-vices. (For definitions of business services and Web services, look in Chapters 5 and 6.) In the world of SOA, the level of granularity shifts pro-foundly. No longer are we talking simply about reusable low-level components: We’re talking about reusable high-level business services. This shift, and its implementation, is no mean feat either for business managers or for IT, but the rewards for everyone are dramatic.
05_376843-ch01.indd 1305_376843-ch01.indd 13 12/2/08 11:50:31 PM12/2/08 11:50:31 PM
14 Par t I: Get ting Started with SOA
Here’s a real-world application. Electrical appliances that you plug in at home
today plug in equally well at the office or if you move across town. If you
travel abroad, though, you likely need electrical adapters. When standard
interfaces don’t agree, you must adapt. Likewise, working with industry stan-
dards set forth by standards bodies enable autonomous entities (partners,
customers, and suppliers) to dance at the ball.
Sweeping Unsightly Technology under the Rug
In the next chapter, we talk a lot about architecture. For those of you who
already know a lot about systems architecture and want more nuts and bolts,
we suggest you skim quickly through the “conceptual” chapters in Part II to
make sure you understand what we mean by the terms we use. Then dive
headlong into Part III, which we promise puts meat on the bones and gives
you a lot to chew on — metaphorically, of course.
One big reason we think business managers are going to like SOA is because
business gets to focus more on business and less on technology, SOA tech-
nology has the potential to become more invisible at the business layer, like
the plumbing in a well-designed home. In this chapter, we give you an over-
view of what the business can expect from SOA.
SOA enables business managers and IT to talk in business terms that both
sides understand. Without SOA, the IT developer and business manager typi-
cally use very different words for the same process: for example, creating
an invoice. The IT developer is concerned with APIs (application program
interfaces) and how to go about creating customer records from ten different
Oracle database tables. The business manager describes the actual business
process used to create an invoice. With SOA, a business service is a business
service is a business service. How that business service is implemented in the
technology layer is the purview of IT, and business managers need not worry
about it or its associated technical jargon.
Understanding Why SOA Is DifferentPerhaps you’re skeptical. Perhaps, for as long as you can remember, the soft-
ware industry has been promising yet another silver bullet to rid you of all
business woes. We think now’s a good time to repeat that SOA is not about
“out with the old, in with the new.” SOA is about reuse: taking what you have
05_376843-ch01.indd 1405_376843-ch01.indd 14 12/2/08 11:50:31 PM12/2/08 11:50:31 PM
15 Chapter 1: Get ting to Know SOA
and structuring it to allow you not only to continue to use it, but to use it
securely knowing that future change will be simple, straightforward, safe, and
fast. SOA is indeed a journey; it can’t be built overnight. But organizations
can begin SOA now and can benefit now. Ultimately, SOA renders a business
more flexible — and IT more reliable, sustainable, extensible, manageable,
and accountable.
We think SOA is the most important mandate facing business and IT today.
And because SOA is a joint venture between business managers and IT, we
present the basics necessary for everyone to come to the table with a good
grounding from a conceptual level.
05_376843-ch01.indd 1505_376843-ch01.indd 15 12/2/08 11:50:32 PM12/2/08 11:50:32 PM
Chapter 7
Discovering the Main Components of SOA
In This Chapter▶ Making SOA happen
▶ Leaving the driving to the ESB
▶ Introducing the SOA registry and repository
▶ Managing business process in a SOA environment
If you’ve followed this book to this point, reading all about Web services
and business processes and composite applications, you may have already
noticed (so far) that we do a pretty good job of hiding the gnarly bits of intricate
technology that make all this possible. We think, however, that you may still
need to know the critical components that make SOA SOA, so we carry on.
In this chapter, we introduce the major components of a service oriented
architecture. This is the appetizer chapter. Many components are so important
that they get entire chapters of their own, but we introduce them here to
show them in relationship to each other and to help you with the big picture.
Making SOA HappenWe show major components of a service oriented architecture in Figure 7-1.
The Enterprise Service Bus (ESB), the SOA registry and repository, the
business process orchestration manager, service broker, and SOA service
manager each have a role to play, both independently and with each other.
The ESB makes sure that messages get passed back and forth between the
components of a SOA implementation. The SOA registry and repository
contain important reference information about where the components of a
SOA are located. The business process orchestration manager provides the
technology to connect people to people, people to processes, and processes
to processes; the service broker connects services to services, which in the
end, enables the flow of business process.
12_376843-ch07.indd 7112_376843-ch07.indd 71 12/2/08 11:52:48 PM12/2/08 11:52:48 PM
72 Part II: Introducing SOA Basics
Figure 7-1: Funda-
mental SOA components.
SOARegistry
Business Process
Orchestration Manager
ServiceBroker
Business App 1
Business App 1
Business App 1
F1 F2 F3Business
Function 1
InfrastructureServices
SOA ServiceManager
Enterprise Service Bus
BusinessProcess
Layer
The role of the SOA service manager is to make sure that the technology
underneath the SOA environment works in a consistent and predictable
way. The goal is to create an environment where all these components
work together to improve the flow of business process. All these services
are required to link unrelated technology components as though they were
designed to work together. Later in this chapter, we provide additional
information on business process management (BPM) as it relates to SOA.
When all these component parts work together and sing the same tune, the
result is dependable service levels. A finely tuned SOA helps guarantee service
levels.
Catching the Enterprise Service BusIn service oriented architectures, all the different pieces of software talk to
each other by sending each other messages — a lot of messages. The messages
are critical to delivering end-to-end service. They must be delivered quickly,
and their arrival must be guaranteed. If that doesn’t happen, “end-to-end”
service quickly becomes “lack of service.”
12_376843-ch07.indd 7212_376843-ch07.indd 72 12/2/08 11:52:48 PM12/2/08 11:52:48 PM
73 Chapter 7: Discovering the Main Components of SOA
To transport the messages between software components, SOAs typically use
an ESB. The ESB is so important to SOA that some people think that you can’t
have a SOA without one. Other folks think that if you have an ESB, you have a
SOA. Neither statement is accurate. You don’t need to have an ESB to have a
SOA, but you do need a way for the services to communicate with each other.
The ESB is a reasonable and effective way to accomplish this goal. You can
read more about the ESB in Chapter 13.
An ESB is a bit like a phone system. You can think of it as a special layer that
runs on top of the network and provides a guaranteed messaging service for
the most important messages on the network, including the messages that
the components of SOA continuously send to each other.
Usually, in architecture diagrams, the ESB is represented as a separate pipe
through which information and instructions flow. (Refer to Figure 7-1 to see
what we mean.) In reality, it’s not really a pipe. Rather, the ESB is a collection
of software components that manage messaging from one software component
to another. A software component connects to the ESB and passes it a message
by using a specified format along with the address of the software component
that needs to receive the message. The ESB completes the job of getting the
message from the sending component to the receiving component.
Welcome to the SOA Registry and Repository
Somebody — or something — has to keep track of all the available
business services that you created to represent your most important
business processes. All those reusable components have to be recorded
somewhere, and that somewhere is the SOA registry.
Think of the SOA registry as a kind of electronic catalog where you store
information describing what each component does. It has two roles:
✓ One rooted in the operational environment
✓ One rooted in the world of programmers and business analysts
In the operational environment, the SOA registry provides reference
information about software components that are running or available for use.
This information is of particular importance to the service broker. (We talk a
lot more about the service broker in Chapter 12.)
12_376843-ch07.indd 7312_376843-ch07.indd 73 12/2/08 11:52:49 PM12/2/08 11:52:49 PM
74 Part II: Introducing SOA Basics
For programmers and business analysts, on the other hand, the SOA registry
acts as a reference that helps them select components and then connect
them to create composite applications that represent business processes. It
also stores information about how each component connects to other com-
ponents. In other words, the SOA registry documents the rules and descrip-
tions associated with every given component.
The SOA registry is extremely important because it acts as the central refer-
ence point within a service oriented architecture. The SOA registry contains
information (metadata) about all the components that the SOA supports. For
that reason, it defines the “domain” of the architecture.
The SOA registry is where you store definitions and other information about
your software components so that developers, business analysts, and even
your customers and business partners can find the services they need.
Business services are “published” in a registry to make them easier to find
and use.
The idea of publishing Web services is critical to SOA. You can only reuse ser-
vices that are available for reuse, which means they have to be published first.
Comparatively, the repository is like a central reference point within the
software development environment. It stores the source code and the linking
information used to build all the programs that run in the operational envi-
ronment. The SOA repository feeds the service oriented architecture with
changes and new components. The SOA repository works within the opera-
tional environment and takes on the responsible role of acting as the counter-
part of the registry within the development environment.
Simply, here’s the difference between the repository and the registry:
✓ Repository: Central reference point for all the components within the
software development environment from which services are built
✓ Registry: Central reference point for definitions, rules, and descriptions
associated with every service within a SOA environment
I never metadata I didn’t likeMetadata means “data about data:” Data that defines, for example, what a set of data items contains. For example, the metadata for a data-base of books might be author, title, publisher, and classification. When it comes to SOA registries, metadata encompasses a lot more
information: a full definition of each software component, for example, as well as the data that can be passed to it with each particular message it accepts as well as the data that it provides with each response it can give.
12_376843-ch07.indd 7412_376843-ch07.indd 74 12/2/08 11:52:49 PM12/2/08 11:52:49 PM
75 Chapter 7: Discovering the Main Components of SOA
Orchestrating End-to-End ServicesNow that we gave you an idea of the purpose of the registry and repository,
we need to show you how the business processes are orchestrated. Aside
from the registry that holds the information about individual services, three
components are involved in orchestrating an end-to-end business process:
business process orchestration manager, service broker, and service manager.
Introducing the business process orchestration managerThe business process orchestration manager is a software component
designed to connect a whole business process from end to end, flowing work
from one individual or process to another until the entire business process is
carried out. Business process development technologies provide a modeling
capability that allows you to model a business process to produce a process
flow pattern. The process flow pattern is, in effect, the set of instructions that
the orchestration manager runs.
Most major software vendors offer tools focused on business process
development, with many of these tools having been in existence for a long
time. In the 1990s, business process development tools focused around
automating workflow for document management systems. More recently,
many vendors have repositioned business process development tools as
BPM, often in connection with the process requirements of a service oriented
Mastering data takes some workIn a SOA environment, access to data becomes a service just like everything else. Enter the con-cept of master data. To avoid chaos, you have to have one common way of naming things related to your business. Here’s a quick but elegant example: Most companies have something they call a customer, right? However, each depart-ment or division of that company might call the customer by different names. In the account-ing department, a customer might be called account; in the sales department, the customer might be called customer name. Which one is
right? If the accounting department doesn’t talk to the sales department, it doesn’t matter. If the planning organization doesn’t care how much money it’s making from customers, it also doesn’t matter. But in the real world, each department needs to know that it’s properly understood when communicating informa-tion about a customer to another department. A commonly understood and unifying way to identify information about important things like customers and products is master data.
12_376843-ch07.indd 7512_376843-ch07.indd 75 12/2/08 11:52:49 PM12/2/08 11:52:49 PM
76 Part II: Introducing SOA Basics
architecture. In fact, BPM is now so closely tied to SOA that many of the SOA
software vendors have been investing heavily in new software development
or strengthening partnerships to build their BPM solutions.
Every business has process flow, be it casual or formal, efficient or disastrous.
Formalizing the process orchestration goes a long way toward documenting
business process — which is a good thing, in case you’re curious. When
using business process management, you can monitor and document how
your business actually works. We go into more detail about BPM later in this
chapter.
Your friendly neighborhood service brokerSay that your components are published in the SOA registry. The business
process orchestration manager strings together processes to make things
happen. What more could you need? You need a service broker. You’ve
probably come across some sort of broker in your life — a real estate broker,
a mortgage broker, a stock broker. The broker is the deal maker; likewise, the
service broker performs this function between components. It listens very
carefully to all the constraints and concerns on both sides of the equation to
make everyone happy.
The service broker is the component that actually makes all the connections
between components work. It acts like a needle threading one component
to the next in a business process. It uses information about the components
it finds in the SOA registry and threads together the components for the
workflow engine. The service broker gets things started and hangs in there
to ensure that all the components of one business process are threaded
together.
Service brokers are considered a middleware product, like the ESB.
Middleware is the name given to the group of software components that we
refer to as plumbing: They enable applications to be connected so that data
can pass through from one application to the next. Because most ESBs can
also act as a service broker, you often don’t need a “standalone” service
broker.
The SOA service manager, againWay back when you could barely spell SOA, we put a black box in a picture
and called it the SOA service manager (in Chapter 5, to be precise). By now,
you probably understand that there’s a ton of stuff in SOA to manage, so
this SOA service manager has a lot of important work to do. The SOA service
manager is the master conductor, the grand choreographer, the traffic cop,
and all-around central point of control responsible for all under-the-hood
12_376843-ch07.indd 7612_376843-ch07.indd 76 12/2/08 11:52:49 PM12/2/08 11:52:49 PM
77 Chapter 7: Discovering the Main Components of SOA
SOA orchestration. In essence, this type of orchestration is a form of virtual-
ization. Virtualization is the ability to abstract computing resources so that
they can be more easily used and managed in a variety of situations. The SOA
service manager abstracts the SOA services from the technology that they
run on.
Just to get a sense of who’s talking to whom, think about business function
components passing data and instructions to each other. At the same time,
the workflow engine passes around instructions and data. The SOA service
manager’s agents send information to the SOA service manager, which in
turn may communicate with plumbing services. There’s a whole lot of talking
going on. (We describe this in greater detail in Chapter 14.)
The SOA service manager interacts with the infrastructure services. If any of
the components in the end-to-end service have any performance problems,
the SOA service manager sends the details to the appropriate infrastructure
services, and the infrastructure services try to fix the problem. Aren’t you
glad that plumbing is invisible to the business?
The SOA service manager is responsible for many things, but above all, it’s
responsible for ensuring service levels. It uses reports from monitoring
agents (initiated by the service broker) to keep track of exactly what’s
happening. The monitoring agents report on the service level being achieved
at each point in the process. The SOA service manager is then in a position to
know when the service gets bad or when any part of it fails.
Managing Business Process under SOAWith all this discussion of registries, repositories, brokers, and buses,
we want to remind you that the whole point of SOA is to make a business
more manageable, more flexible, and more responsive to change. The
primary culprit when it comes to instigating change is business process: how
businesses do things.
Businesses constantly change how they do things while not necessarily
changing what they do. For example, an insurance company might change
the methods it uses to introduce new products or how it handles insurance
claims, but when all is said and done, it still sells insurance. SOA enables
business people to change business processes without having to focus on
the underlying technological plumbing. You can concentrate on designing
and improving business processes by threading together business services.
IT can build composite applications from existing business functions, adding
other functions or making changes where necessary. Together, business and
IT can determine the flow of work from one person to another (or from a
person to a process or from a process to a person) within the larger business
process.
12_376843-ch07.indd 7712_376843-ch07.indd 77 12/2/08 11:52:49 PM12/2/08 11:52:49 PM
78 Part II: Introducing SOA Basics
“But how do they do that exactly?” you may wonder. Thanks for asking. With
all these business processes to manage, the somewhat obvious solution is
business process management (BPM). BPM is the modern approach to design-
ing and managing business processes, and many business managers and
business analysts receive BPM training. All by itself, BPM has contributed sig-
nificantly to the liberation of business from technology.
While BPM focuses on designing business processes effectively, SOA is an
architecture that conveniently allows IT to align with business processes.
It’s only natural — yet very important — to successful implementation of
SOA that SOA and BPM have converged, with BPM software tools becoming
a natural part of a SOA development environment. Coupled with SOA, BPM is
doubly powerful.
In addition to the BPM methodologies and approaches being bandied about
by sharp-dressed consultants in countless corporate conference rooms,
you’ll find software tools out there that have been created specifically to help
automate business process management. They are called, oddly enough, BPM tools. BPM tools organize workflows, thread together existing business func-
tions, and create new functions.
With SOA, you want to harvest existing business functions by taking them out
of their existing application homes — applications that have provided the
“connective tissue” necessary to keep them functioning smoothly. The new
connective tissue you need to house the harvested business functions comes
in the form of either the business process itself or of a composite application.
BPM tools are critical here because they help you design and manage just
such business processes.
Business processes actually codify how a business works, and this very
codification of business processes is a critical step for any organization
subject to any kind of regulatory compliance, such as the Sarbanes-Oxley Act,
the Health Insurance Portability and Accountability Act (HIPAA), and a host of
others.
The origins of BPMWhat we call BPM today is the result of a Western adaptation of management best practices that evolved primarily from Japanese manufacturing. The closest equivalent Japanese term is Kaizen, which can be defined as “continuous improve-ment” — or, perhaps more aptly, “to take apart
and put back together in a better way.” Beyond continuous improvement, BPM embraces other management methods, such as Total Quality Management and Six Sigma.
12_376843-ch07.indd 7812_376843-ch07.indd 78 12/2/08 11:52:49 PM12/2/08 11:52:49 PM
79 Chapter 7: Discovering the Main Components of SOA
BPM enables businesses to monitor business processes, which can lead
to continuous improvement by identifying possible changes in a process
that could result in better efficiency. Over time, more and more business
processes are tied to software. When supported by SOA, continuous business
improvement becomes a lot easier because the underlying software is loosely coupled, meaning that it can be modified more easily when required. When
business needs to change to address strategic opportunities and threats, the
flexible service oriented architecture facilitates the change.
BPM terminologyIf you find acronyms and abbreviations inherently confusing, the abbreviation
BPM stands a pretty good chance of spoiling your whole day because it’s
used in three different ways:
✓ BPM is a management practice. BPM is a holistic management practice
consisting of methods for efficiently aligning an organization with the
wants and needs of clients. It promotes business efficiency but also
promotes integration with technology. It also embodies the spirit of
Kaizen. (See the sidebar, “The origins of BPM” for more on Kaizen.)
✓ BPM tools (where m is for management). If the BPM in “BPM tools” stands
for business process management, the name implies that such software tools
are built to assist in the implementation of BPM the management practice.
Such tools can be comprehensive in terms of capability involving modeling,
rules engines, workflow, process monitoring, and deployment.
✓ BPM tools (where m is for modeling). If the M in BPM stands for
modeling, we’re talking about a tool used to model business processes.
Such as software development tool carries out only a fraction of what
a business process management tool is likely to do. Nevertheless, the
term BPM is used by the vendors who sell such tools.
BPM toolsHere’s how a basic BPM tool uses the components of process management to
make use of SOA:
✓ It enables the creation of new business functions. A developer may add
whole new business functions or may simply add logic to run before or
after an existing business function. To create new business functions, the
BPM tool includes some way of specifying a software process. When a new
business function is created, the BPM tool adds the function’s details to the
SOA registry, including information about how it links to other components.
12_376843-ch07.indd 7912_376843-ch07.indd 79 12/2/08 11:52:49 PM12/2/08 11:52:49 PM
80 Part II: Introducing SOA Basics
✓ It links business functions from existing applications. The BPM
tool refers to the SOA registry to identify business functions that are
published there. It enables a developer to link them to make composite
applications or slot them in at the appropriate point in the overall
workflow. The BPM tool stores this information in the SOA registry.
✓ It programs the business process orchestration manager to carry out
the business process. Using the BPM tool, business analysts design
process flows and specify the movement of work from one person to
another within a business process, linking the applications that they
need to use for the tasks they have to carry out.
Figure 7-2 gives you a graphical representation of how a BPM tool
accomplishes these three tasks.
Meticulous readers may notice that in Figure 7-2, the BPM tool isn’t
actually “managing” anything. Rather, it’s merely creating a business process.
More needs to be done if you want to ensure that the business process is
performing effectively, from both these perspectives:
✓ The computer perspective: Does it have enough computer resources?
✓ The customer perspective: Is the customer or service receiver getting a
prompt service?
We discuss such performance issues later in this chapter.
If you’ve read Chapter 5, you may remember that we define a service oriented architecture as a software architecture for building applications that implement
business processes or services by using a set of loosely coupled black-box
components orchestrated to deliver a well-defined level of service.
The “well-defined level of service” piece comes front and center now. Service
levels, as the name implies, means that service is not so black and white. By
way of illustration, think about service in a restaurant (as we did in Chapter
5): You could have great service or lousy service or so-so service. Or it may
have started out great, but when it came to getting your check, your waiter
couldn’t be found.
Service levels in IT have become critically important in the past decade
because business has become more and more dependent upon IT.
Furthermore, IT itself has transitioned from using autonomous software
packages serving a well-defined, limited set of users to using software
delivered as a service over a network to huge numbers of users (just like
telephone service and electricity). And just as you know if you’ve ever been
caught in a power outage or experienced downed telephone lines, the lack of
IT service (depending on when it happens and how long it lasts) ranges from
somewhat inconvenient to ruinous. For many organizations, an hour of IT
downtime costs millions of dollars.
12_376843-ch07.indd 8012_376843-ch07.indd 80 12/2/08 11:52:49 PM12/2/08 11:52:49 PM
81 Chapter 7: Discovering the Main Components of SOA
Figure 7-2: A BPM tool.
SOARegistry
Business Process
Orchestration Manager
Business App 1
Business App 1
Business App 1
F1 F2 F3
BusinessFunction 1
BPMTool
CreatesCreatesCreates ProgramsProgramsPrograms
Links In Links In Links In
Publishes
Adds ToRefers To
Thus, businesses that depend on services often enter into agreements with
their service providers that guarantee a specific level of service, focused
primarily on the availability and speed of service. For example, 100-percent
uptime means that systems are available 100 percent of the time with
absolutely no downtime — a virtually impossible task.
The ability to guarantee high levels of availability and high speeds of
service usually implies higher levels of investment in computer systems,
including having redundant systems in place in case of an emergency as
well as having extra capacity should the need arise. Naturally, the higher the
level of service, the more it costs. Thus, guaranteeing service availability at a
99.999 percent level is significantly more costly than guaranteeing availability at
a 99 percent level. See the sidebar, “99.999 percent,” elsewhere in this chapter,
to find out why.
And perhaps you have gleaned, being the astute reader that you are, that a
service oriented architecture — being all about service — has the potential
to deliver variable levels of service. Will your SOA deliver good service, bad
service, so-so service, intermittent service, or unpredictable service?
Obviously, anything less than good service (or maybe even great service)
will put your entire business at risk.
12_376843-ch07.indd 8112_376843-ch07.indd 81 12/2/08 11:52:49 PM12/2/08 11:52:49 PM
82 Part II: Introducing SOA Basics
Service oriented architectures must make composite applications and busi-
ness processes available, reliable, and predictable. Although the responsibil-
ity of all the choreography needed to make and keep service levels high falls
squarely on IT, we think everybody should know the basic principles. And
understanding the basic principles can go a long way toward bettering the
communication flow between business and IT, which are jointly responsible
in the new world order.
Application failures: Let us count the waysUnderstanding service levels as they apply to application availability means
understanding how and why applications fail as well as the consequences of
the failure.
Applications can fail because the hardware they run on fails or because the
network connecting the users to the application fails. Or the application itself
can fail, or the operating system running the application can fail, or some of
the management software managing the application can fail . . . and on and on.
99.999 percentPerhaps you’re perplexed by why adding 0.999 percent of reliability and availability is so very expensive, and why 99.999 percent should cost so much more than plain old 99 percent. We’ll try to explain. (99.999, by the way, is sometimes referred to as Five Nines and is said with a great deal of awe and respect.)
Say, for example, that you have a server that’s up most of the time — it rarely crashes. Maybe it’s down three days per year. That’s roughly 99 percent available. Now if you really truly need 100 percent availability (or as close as you can get), you have to do more than just buy another server. You may have to buy multiple servers; dual up all the networking equipment; invest in failover capabilities; and guarantee that you have no single point of failure, such as the
power supply. You may need a generator. Do you begin to see the cost of being “always on”? The bigger and more complicated your system, the greater the number of vulnerabilities or points of failure there are likely to be. Ensuring availability (and extra capacity for peak loads) is not a trifling expense.
Businesses whose very livelihoods depend on their being available 24/7 go to great lengths to ensure that availability. For some Web-based businesses, an hour of downtime to business critical systems can cost more than $1 million in lost revenues. Amazon.com for example, cur-rently processes between $1–2 million per hour. So three days of downtime could mean $72 mil-lion in lost revenues. Ouch.
12_376843-ch07.indd 8212_376843-ch07.indd 82 12/2/08 11:52:49 PM12/2/08 11:52:49 PM
83 Chapter 7: Discovering the Main Components of SOA
When software components fail, it takes time to find the cause of the failure
and to get the system back into action. If finding the cause can be done
automatically, so much the better. Even so, this could take more than a
minute or two. If it isn’t automatic, it’s likely to take hours.
Not all problems cause outright failure. Some may simply slow down the
application. Just as applications can fail for many reasons, they can also slow
down for many reasons.
Measuring service levelsHere are the ways to know that an application is delivering the service
business users require:
✓ Define the service level that the business needs.
✓ Measure the application’s activity to see whether it achieves that level.
Because application interruptions are sporadic, you need to measure service
constantly and then average it over a given period of time — a day and/or a
week and/or month and/or a year to arrive at a meaningful number.
The measurement of the service level needs to be automatic, which can
present a problem. While the service level of individual components of a
business process is usually easy to measure, both in terms of availability and
response time, measuring the service level of an end-to-end process can be
complex. Fairly recent new software tools called Business Activity Monitoring
(BAM) tools have emerged to help in this area.
Here’s an example of a detailed definition of a service level for an order-
processing application:
✓ Application to be available 99.9 percent of the time every weekday from
6 a.m. to 10 p.m. EST.
✓ In the event of a failure, the application should recover within 20 minutes.
✓ The response time for order inquiries, changes to orders, and entering
new orders should average 1 second and should never take more than 2
seconds, 99.9 percent of the time.
✓ In the event of degraded service occurring and response times slowing,
normal service should be restored within 1 hour.
Defining the service level this way serves both business and IT well.
Compliance with this service level agreement would mean that the
order-processing application would be unavailable for (at worst) 4 hours, 10
12_376843-ch07.indd 8312_376843-ch07.indd 83 12/2/08 11:52:49 PM12/2/08 11:52:49 PM
84 Part II: Introducing SOA Basics
minutes during the whole year — little more than one-half of one business
day. The response time could be poor for as much as 4 hours, 10 minutes in
the year. In the worst-case scenario, the application is unavailable for 20
minutes when it does fail. And when service degrades, it’s always back to
normal within an hour.
By the way, note that what we defined here is a technical service level. A
business might also like to define a service level for specific business
processes. Thus the goal might be to fulfill a customer’s order and dispatch
it within 24 hours of receiving the order, 99 percent of the time. Ultimately,
if you have well-defined IT service levels, it becomes much easier to monitor
the service levels of business processes and improve them.
IT needs the right set of computer equipment and supporting software to
deliver a service level of this kind for the application, including the appropriate
failover capability as necessary. And if the application gets more users, IT
needs to upgrade the computers to keep pace with the resource requirements.
End-to-end serviceDelivering high levels of service for a stand-alone application isn’t so tough;
after all, you have relatively few people to make happy. However, when you
involve a network and begin to deliver services across that network, life
ceases to be simple.
With SOA, you might (and probably will) link components from different
applications. However, the service level that you want to deliver in the new
application that you create this way isn’t necessarily the same service level
delivered by each of the different applications you’re taking components
from. In fact, they could differ from each other, and your new application
could have a service level different from any of its components.
Do you have a headache yet? Consider the development of a new order-
processing application that’s very similar to an old one but that’s written
specifically to work on the Internet. You build a few new software components
and use most of the components from your old order-processing system. The
service levels for the old system might be acceptable, except for one thing:
Because this is an Internet application, it needs to run 24/7.
So why not just leave the old application running all the time? Simply put, the
old application wasn’t designed to run all the time. It was designed to allow
data backups to occur at night and for data to be extracted from the database
at night when the application wasn’t running.
12_376843-ch07.indd 8412_376843-ch07.indd 84 12/2/08 11:52:49 PM12/2/08 11:52:49 PM
85 Chapter 7: Discovering the Main Components of SOA
Of course, this isn’t an unmitigated disaster. You could just change the old
application in some way. However, changing the old application takes time,
and it will have to change again whenever your business needs change
again. The reality of most businesses is that change is the only thing that is
predictable. To support continuous change, linking software components
makes much more sense than recoding applications.
When you consider linking many software components from many
applications, a bigger issue emerges. Applications that were built to deliver
specific service levels linked end-to-end must deliver service end-to-end.
Delivering dependable service levels means controlling the end-to-end
process, which means you need the SOA service manager.
Taking just one more look at the Process ManagerTo round this chapter off, we take another look at the component we simply
refer to as the Process Manager in Chapter 6. We were making life easy for
you by representing it as a single component. In reality, the activity of process
management is carried out by three components: the SOA registry, the
workflow engine, and the service broker. (See Figure 7-3.)
Figure 7-3: Process
manage-ment.
Process Manager
SOARegistry
Business Process
Orchestration Manager
ServiceBroker
CallCenter
C4 C5 C6
CallHistory
C1 C2 C3
OrderProcessing
O4 O5 O6
O1 O2 O3
WarehouseSystem
W4 W5 W6
W1 W2 W3
Commission HR &Payroll
H4 H5 H6
H1 H2 H3
Corporate Network
12_376843-ch07.indd 8512_376843-ch07.indd 85 12/2/08 11:52:49 PM12/2/08 11:52:49 PM
86 Part II: Introducing SOA Basics
This diagram ought to look suspiciously like Figure 6-5 in Chapter 6, because
it is. The difference is that in this version, we break the component we called
the Process Manager into three separate components:
✓ The SOA registry stores information describing what each SOA component
does so that business analysts or programmers can select components and
connect components to create composite applications. The registry also
stores information about how one component connects to another.
✓ The business process orchestration manager connects a whole business
process in an end-to-end manner, flowing work from one individual or
process to another while the business process is carried out.
✓ The service broker actually makes all the connections between
components work. The service broker is a needle that threads together
all the software components of a business process by using information
it gleans from the registry.
For SOA to achieve the sophistication that we predict it can, you need to
pull together the pieces of hardware, software, services, infrastructure,
process — and even people — so they act like a single system. The greatest
benefit of SOA is that you can change the parts and still have a well-oiled
machine.
12_376843-ch07.indd 8612_376843-ch07.indd 86 12/2/08 11:52:49 PM12/2/08 11:52:49 PM