245450494.

doc 1 od 257
Integration Patterns

Integration Patterns
patterns & practices Library
Shop for patterns and practices books online
Principal Authors: David Trowbridge, Microsoft Platform rchitect!re "!idance# $lrich %o&b!rgh, Microsoft
Service Line rchitect '!stralia(# "regor )ohpe, Dragos Manolesc!, Tho!ght*orks, +nc,# -, ", .adhan, -DS,
Contributing Authors: *ard /!nningham, Microsoft Platform rchitect!re "!idance# %amk!mar
0othandaraman, Microsoft Developer and Platform -vangelism rchitect!re Strategy Team# 1ill McDonald,
%obert Miles, scenti!m /orporation# 2avier Mariscal, Two /onnect, +nc,# %aymond Laghaeian, +mplement,/om,
Microsoft /orporation
2!ne 3445
Summary
Integration Patterns e&plains how patterns were !sed to design and b!ild an integration architect!re within a
representative c!stomer scenario, The g!ide incl!des a catalog of 67 common integration patterns incl!ding
implementations that !se the Microsoft platform,
Download
/lick here to download the PD8 version of this g!ide from Microsoft Download /enter,
Contents
+ntrod!ction
*ho Sho!ld %ead This "!ide
*hat +s in This "!ide
/omm!nity
8eedback and S!pport
/ontrib!tors
245450494.doc 2 od 257
Introduction
This g!ide is the third patterns release in the pattern & practices series from Microsoft, 1!ilding on the
application patterns presented in Enterprise Solution Patterns Using Microsoft .NET, this g!ide applies patterns
to solve integration problems within the enterprise,
The design concepts in this g!ide incl!de implementations on the Microsoft platform that !se 1i9Talk Server
3445, )ost +ntegration Server 3445, SP,.-T, :is!al St!dio, :isio 344; and the ,.-T 8ramework,
The scenario is an online bill payment application in the banking ind!stry, To meet the needs of this scenario,
the team !sed a pattern<based approach to b!ild and validate a baseline architect!re, 1eca!se a well<designed
architect!re m!st be traceable to the needs of the b!siness, the g!ide also incl!des a set of artifacts that trace
from high<level b!siness processes down to code,
Who Should Read This Guide
This g!ide is for readers in one or more of the following categories:
/hief technology officers, architects, designers, and developers who are new to integration patterns
/hief technology officers, architects, designers and developers who are already e&perienced in !sing
integration patterns to integrate enterprise sol!tions
/hief information officers and +T managers responsible for integrating m!ltiple systems
What Is in This Guide
Chapter 1 Integration and Patterns
This chapter introd!ces the "lobal 1ank scenario that is !sed thro!gho!t this g!ide and briefly disc!sses how
patterns can help development teams find workable answers to integration challenges,
Chapter ! "sing Patterns to Design the Integration #aseline Architecture
This chapter !ses the lang!age of patterns to e&plore the decisions and tradeoffs that the members of the
"lobal 1ank architect!re team made while designing and implementing their bill payment system,
Chapter $ Integrating %ayer
This chapter describes the different strategies for designing an integration layer and the tradeoffs involved in
choosing an alternative, n integration layer can a!tomate comple& b!siness processes or provide !nified
access to information that is scattered across many systems,
This chapter includes the &ollowing patterns
-ntity ggregation
Process +ntegration
+mplementing Process +ntegration with 1i9Talk Server 3445
Portal +ntegration
245450494.doc 3 od 257
Chapter ' System Connections
This chapter b!ilds on /hapter ; by describing how to connect individ!al systems, -ach system allows certain
types of access and restricts others, This chapter presents a series of related patterns that will help yo! analy9e
the alternative methods and the tradeoffs to consider when yo! choose yo!r system connections,
This chapter includes the &ollowing patterns
Data +ntegration
8!nction +ntegration
Service<=riented +ntegration
+mplementing Service<=riented +ntegration with SP,.-T
+mplementing Service<=riented +ntegration with 1i9Talk Server 3445
Presentation +ntegration
Chapter ( Integration Topologies
This chapter b!ilds on previo!s chapters by describing overall integration topologies, This chapter presents a
series of related patterns that help yo! analy9e the alternative methods and the tradeoffs to consider when yo!
choose between integration topology alternatives,
This chapter includes the &ollowing patterns
Message 1roker
+mplementing Message 1roker with 1i9Talk Server 3445
Message 1!s
P!blish>S!bscribe
Chapter ) Additional Integration Patterns
This chapter presents two important patterns: Pipes and Filters and Gateway, Many integration architect!res
are based on a pipe and filter approach and on gateways, "ateways are !sef!l design elements that
encaps!late access to enterprise reso!rces s!ch as mainframes, This chapter e&plains both patterns and then
traces them to implementations that !se the Microsoft platform,
This chapter includes the &ollowing patterns
Pipes and 8ilters
+mplementing Pipes and 8ilters with 1i9Talk Server 3445
"ateway
+mplementing "ateway with )ost +ntegration Server 3445
Chapter * Pro+ect ,oteboo-
This chapter takes a broader view of the "lobal 1ank scenario by showing the link between b!siness and
technology viewpoints, +t starts with an overview of the "lobal 1ank b!siness environment, and then describes
245450494.doc 4 od 257
the viewpoints of five key b!siness stakeholders, The chapter then presents a series of models that the "lobal
1ank team prod!ced as they designed the baseline architect!re based on b!siness re?!irements, These models
trace a path from the /hief -&ec!tive =fficer to the technical sol!tion and show how the team !sed patterns
d!ring the design process,
Appendi. %ist o& Patterns and Pattlets
ppendi&, @List of Patterns and Pattlets,@ presents a list of patterns and pattlets that this g!ide mentions, b!t
that it does not disc!ss in detail, Pattlets are act!al patterns that this book refers to# however, the book does
not disc!ss them in detail,
#ibliography
Community
+n 2an!ary 344A, patterns & practices a!thors !nveiled a new online patterns comm!nity called
PatternShare,org, PatternShare,org is a *iki site that aims to increase pattern sharing, dialog, and !sage by
bringing together people who want to learn proven sol!tions to common problems from people who have solved
them before, The pattern format combined with the fle&ibility and comm!nity ownership of the *iki make the
site ideal for this kind of comm!nity,
To view and participate in this comm!nity, go to http:>>patternshare,org,
/eedbac- and Support
B!estionsC /ommentsC S!ggestionsC 8or feedback on this g!ide, please send e<mail to
pnppatfbDmicrosoft,com,
The patterns doc!mented here are designed to E!mp<start the architect!re and design of systems integration,
Patterns are simple mechanisms that are meant to be applied to the problem at hand and are !s!ally combined
with other patterns, They are not meant to be pl!gged into an application, -&ample code is provided @as is@ and
is not intended for prod!ction !se, +t is only intended to ill!strate the pattern, and therefore does not incl!de
e&tra code s!ch as e&ception handling, logging, sec!rity, and validation, ltho!gh this deliverable has
!ndergone testing and review by ind!stry l!minaries it is not s!pported like a traditional Microsoft prod!ct,
Contributors
Thanks to the following contrib!ting a!thors: *ard /!nningham, Microsoft Platform rchitect!re "!idance#
%amk!mar 0othandaraman, Microsoft Developer and Platform -vangelism rchitect!re Strategy Team# 1ill Mc
Donald, %obert Miles, scenti!m /orporation# 2avier Mariscal, Two /onnect, +nc,# %aymond Laghaeian,
+mplement,/om,
Many thanks to the following reviewers who provided inval!able assistance and feedback: 2ohn S!llivan,
Tho!ghtworks# %alph 2ohnson, $niversity of +llinois at $rbana</hampaign# -ddie )!lme, -DS# Dave Swift, /hief
245450494.doc 5 od 257
rchitect, F!rich 8inancial Services# %!pert D,-, 1rown, /T= Team %e!ters# $nited 0ingdom rchitect /o!ncil G
Patterns *orking "ro!p# %ichard Sears, Sears and ssociates# /olin 1ird, /onchango plc# Michael Platt, Scott
*oodgate, Satish Thatte, Phil Teale, le& *einert, Marc Levy, $lrich )omann, Dave "reen, Pa!l Larsen, 2ack
"reenfield, 0eith Short, David Lavigne, /hris )o!ser, nil 1alakrishnan, Shawn )enretty, Do!g /arrell, 2oe
Sharp, Miles $lrich, Steve Smaller, Shank! .iyogi, *oEtek 0o9ac9ynski, 2onathan *anagel, 2ason )ogg, 2im
.ewkirk, -d Lafferty, Sandy 0ha!nd, 0en Perilman, Ma!ro %egio, Microsoft /orporation,
Thanks also to the many contrib!tors who assisted !s in the prod!ction of this book, in partic!lar: Matt -vans,
Larry 1rader, Microsoft Platform rchitect!re "!idance# bhiEit Somalwar, 2!de H!varaE, n!radha
Sathyanarayana, +nfosys Technologies Ltd# Tyson .evil, S!san 8ilkins, -ntirenet# /la!dette +ebbiano, /+ Design
St!dio# SanEeev "arg, Satyam /omp!ter Services# 1laine *astell, scenti!m /orporation
Summary This chapter introd!ces the "lobal 1ank scenario that is !sed thro!gho!t this g!ide and briefly
disc!sses how patterns can help development teams find workable answers to integration challenges,
Contents
The Problem of +ntegration
The "lobal 1ank Scenario
Patterns
Patterns at "lobal 1ank
.e&t /hapter
@The significant problems we face cannot be solved at the same level of thinking we were at when we created
them,@Ilbert -instein
8ew enterprise applications e&ist in isolation, Most are connected to other applications and services by data
feeds and common reference data, =thers are connected thro!gh elaborate integration networks, +f yo! look
above the level of single applications and foc!s on an enterpriseJs whole software portfolio, yo! often see a
comple& collection of silo applications, heterogeneo!s platforms, and islands of sometimes d!plicated data and
services that are interconnected by messages, obEects, file transfers, batch feeds, and h!man interactions,
t the same time, b!sinesses consider information technology '+T( to be a key element of both operational
efficiency and competitive advantage, There are high e&pectations of technical investments despite rapidly
changing b!siness conditions and operating environments, /ompo!nding this problem is the rate of change in
technology, as innovations s!ch as *eb services emerge, ltho!gh adopting this new technology promises a
new level of interoperability between systems and enterprises, it also demands that practitioners devise an
integrated, enterprise<level approach to b!ilding applications and services,
245450494.doc 6 od 257
"iven todayJs comple& technical and b!siness environment, how do yo! create an integrated portfolio of
applications and services for yo!r enterpriseC
This g!ide disc!sses known good ways to integrate systems, and it !ses patterns to describe them, To gro!nd
the disc!ssion in something tangible, the g!ide:
Describes a representative scenario in detail
1!ilds o!t a performance<tested, baseline architect!re to validate the approach
$ses the vocab!lary of patterns to describe important design tradeoffs
Traces the patterns to an implementation that !ses the MicrosoftK platform
The g!ide does not:
Describe a feat!re<complete or f!lly sec!re implementation
ssert that there is only one right answer when it comes to design
Promote patterns as a silver b!llet for solving all design problems
The Problem o& Integration
Many enterprises create overly comple& integration architect!res in very predictable ways, 1!siness !nits within
the enterprise often have a strong b!siness case for an +T capability, They f!nd and staff proEects to provide
this capability, while tracking primarily the delivered f!nctionality, )owever, they often have little regard for the
technical architect!re !nderneath, ss!ming the b!siness case is so!nd, this is often in the best interest of the
b!sinessIat least in the short r!n,
+n the long r!n, however, b!ilding b!siness capabilities witho!t caref!l consideration of an enterprise<wide
technical architect!re can lead to a high cost for +T operations, an infle&ible portfolio of applications and
services, and a high cost for new application development, -ven worse, the enterprise will be at a distinct
disadvantage with respect to other competitors that have b!ilt well<factored, agile, and well<integrated
applications and services, This is especially tr!e in ind!stries where information has a high economic val!e and
new b!siness models emerge ?!ickly, posing real economic threats,
The balance between these b!siness and technology forces is delicate, Moving too fast to enable b!siness
capabilities can res!lt in a gl!t of architect!rally incompatible applications, which likely will need to be
rationali9ed and integrated later at a high cost to the enterprise, =n the other hand, !nchecked ind!lgence of
the nat!ral engineering tendency to st!dy the problem deeply before acting can lead to long and costly
enterprise architect!re engagements, .ot only do these efforts take significant time to e&ec!te 'at a high
opport!nity cost(, b!t, if not caref!lly managed, they risk prod!cing little more than a set of binders that sit
!n!sed on a shelf,
Integration Architecture
245450494.doc 7 od 257
n enterpriseJs integration architect!re balances the re?!irements of the b!siness and the re?!irements of
individ!al applications, +nside this integration architect!re, yo! often find an overwhelming ma9e of systems,
connections, and channels, +f yo! st!dy eno!gh of these, yo! see common combinations of integrated systems
s!ch as portals, networks of connections s!ch as message brokers, b!ses, and point<to<point connections, and
n!mero!s individ!al connections and channels, To !nderstand the ma9e, it is helpf!l to !nderstand how many
of these integration architect!res evolveIone application at a time,
Many developers and architects start by designing and b!ilding stand<alone applications, They then progress to
more comple& enterprise applications, s applications re?!ire connections to shared enterprise reso!rces, it is
nat!ral to create abstractions and wrappers that encaps!late these reso!rces from an applicationcentric point
of !iew. fter all, it is E!st one more connection to the enterprise reso!rce, 8!rther enterprise<level work is
often o!t of scope for the application proEect,
ltho!gh this approach works well from the perspective of a single application, connecting all applications in
this way is !nlikely to prod!ce a well<ordered set of applications, +nstead, yo! need a logical design at the
integration level, E!st like yo! need a logical design at the application level, To think clearly abo!t an integrated
portfolio of applications and services at the enterprise level, yo! m!st invert yo!r viewpoint, Ho! m!st first
consider the needs of the enterprise as an integrated whole and then consider how to e&pose shared
f!nctionality thro!gh networked applications, This kind of thinking is ?!ite different from traditional monolithic
application development or n<tier development, +t begs the ?!estion: what is an application anywayC
Applications
Most software<related definitions describe applications as @any part of a software system !sed to deliver end<
!ser f!nctionality@ L8iresmithMAN or @a comp!ter program designed to help people perform a certain type of
work@ LMicrosoft43<;N, +f yo! think of design from a traditional application<centric point of view, yo! !s!ally
e&pect to encaps!late f!nctionality into one or more e&ec!table files and then deploy them to necessary
servers, Ho! do not e&pect to !se e&isting services to any large degree, )owever, if yo! approach this same
problem from an integration architect!re perspective, the ideal application is a thin layer of presentation that
cons!mes shared f!nctionality or data at the enterprise level, +deally, m!ch of this f!nctionality already e&ists
and is accessible at a level of gran!larity that is meaningf!l to the b!siness, nd if new f!nctionality m!st be
b!ilt, it is designed not to stand alone, b!t to be shared with other enterprise applications and services,
To show how this kind of thinking might be practically applied, the remainder of this g!ide !ses some of these
concepts in an interesting, yet challenging, online bill payment scenario called "lobal 1ank, This scenario
introd!ces eno!gh comple&ity to ill!strate the design tradeoffs witho!t introd!cing too many details,
The Global #an- Scenario
ltho!gh talking abo!t architect!re and design at a concept!al level helps to set g!iding principles, there is
nothing like b!ilding o!t an act!al system against re?!irements to gain common !nderstanding at a more
245450494.doc 8 od 257
technical level, That is why the a!thors of this g!ide have developed an e&ec!table baseline architect!re
against a concrete scenario: "lobal 1ank, Later chapters of this g!ide describe the design and implementation
details of the sol!tion, b!t first, letJs look at some of the conte&t and re?!irements of this scenario,
Conte.t
"lobal 1ank is a midsi9e, traditional bank that has ac?!ired a complete range of financial services capabilities
thro!gh a series of ac?!isitions, +t has a limited online banking presence that is fragmented across its vario!s
divisions, s part of its strategy to e&pand with the limited cash it has available, "lobal 1ank has decided to
innovate in the online banking market by providing a host of val!e<added services in addition to a f!lly
integrated financial management capability,
,ote This chapter contains an intentionally brief overview of "lobal 1ankJs b!siness conte&t and approach to
b!ilding integration architect!re, 8or more detailed information, see /hapter O, @ProEect .otebook,@
The chief e&ec!tive officer '/-=( decided the first step was to immediately add an electronic bill payment
capability to the c!rrent online banking system, This wo!ld allow c!stomers to sched!le electronic payments
online from their checking acco!ntsIa high demand feat!re providing greater c!stomer convenience, The /-=
believed this added convenience wo!ld have an immediate impact !pon c!stomer satisfaction and loyalty, while
demonstrating tangible progress to his board of directors, To initiate this effort, the /-= bro!ght in his chief
technical officer '/T=( and the vice president for cons!mer banking and asked them to deliver this capability
before the end of the fiscal year, )e e&pected ro!gh<order<of<magnit!de '%=M( cost and sched!le estimates
within si& weeks,
Re0uirements
The /T= immediately involved a senior program manager to create a proEect aro!nd this initiative, The program
manager formed a team to b!ild a high<level proEect plan and to start gathering re?!irements, $nlike many
proEects, the /T= e&pected to not only gather re?!irements from the cons!mer banking division, b!t to also
negotiate re?!irements with the cons!mer banking division based on the overall needs of the b!siness,
s he reflected on the overall initiative, the /T= felt confident that the b!siness wo!ld contin!e to invest in
additional financial services for its c!stomer base and that additional ac?!isitions were likely to follow, This was
clearly not an isolated initiative# rather, it reflected a longer<term strategy for the company, )e reali9ed it was
important to have a well<conceived technical architect!re at the enterprise level that wo!ld smoothly s!pport
these corporate goals,
1eyond the f!nctional re?!irements that wo!ld emerge, he wanted a solid technical fo!ndation that wo!ld allow
him to meet operational re?!irements as well, )e p!lled together an architect!re team and asked them to
create a baseline architect!re that wo!ld s!pport this initiative and f!t!re initiatives, s a first appro&imation,
he started with the following high<level re?!irements and constraints:
1!ild a baseline architect!re for a *eb<based online banking portal that allows c!stomers to pay bills
online from their checking acco!nts,
245450494.doc 9 od 257
ll acco!nt<related transactions will !se the c!rrent system, which resides on an +1M mainframe
'=S;M4( !sing /!stomer +nformation /ontrol System '/+/S( based transactions,
The online bank system will reside in the corporate data center in Seattle, *ashington, +t will be
connected to an ac?!ired bankJs data center in Los ngeles, /alifornia tho!gh a private leased line,
Loan information will be p!lled from the ac?!ired bankJs loan systems, which reside on systems that
are based on +1M *ebSphere 23--,
ll c!stomer profile information will !se the c!rrent /!stomer %elationship Management '/%M(
system,
Domestic electronic payments will !se the c!rrent payment system, and international electronic
payments will !se S*+8T<based transactions thro!gh an e&ternal payment gateway, Payees that cannot
receive electronic payments will be paid !sing electronic transactions to a man!al f!lfillment center, which
will then make the payments man!ally thro!gh the $,S, mail,
-&cept for the systems previo!sly identified, the system will be based on the Microsoft platform,
The systemJs overall transaction rates, conc!rrent !sers, and response time m!st meet the first yearJs
proEected !sage pl!s an engineering safety factor of ;& 'or three times the first yearJs proEected !sage( to
handle b!rst load,
The system m!st meet or e&ceed the service level agreement 'SL( for o!r c!rrent online system,
,e.t Steps
+f yo! were part of this architect!re team, how wo!ld yo! proceedC +f yo! were fort!nate, someone on this
team wo!ld have b!ilt a system like this before and wo!ld apply those e&periences and lessons learned to this
effort, This wo!ld be optimal, b!t is not probable, +t is more likely that members of yo!r team are very
proficient with a set of technologies that might solve part of this problem, 8or e&ample, they might be proficient
with obEect<oriented design, message<oriented middleware, integration servers, or distrib!ted obEect systems,
.at!rally, team members want to apply the tools they have !sed before to solve f!t!re problems, b!t how do
yo! know which technology is appropriate for which area of the design and whenC *hen the problem and the
technology align, yo! can move ?!ickly and effectively to b!ild the sol!tion, )owever, we have all seen familiar
technology applied in !nfamiliar areas for which it is s!boptimal,
*o!ldnJt it be great to be able to break this problem down into relatively atomic decision points and !nderstand
the design alternatives available to yo! at each pointC 8or each alternative, wo!ldnJt yo! want to know how
others have implemented similar choices and what the res!lting advantages and disadvantages wereC ltho!gh
yo! may not have the l!&!ry of an e&perienced person to disc!ss this with, the ne&t best alternative is a
catalog of best practices that are doc!mented as patterns, 1efore contin!ing with the "lobal 1ank scenario,
letJs disc!ss the concept of patterns at a very high level and how they might apply to software development,
,ote %ather than repeat the introd!ctory material from Enterprise Solution Patterns Using Microsoft .NET or
from a formal pattern description fo!nd in an introd!ctory patterns book, this chapter rela&es the formal
pattern description and provides some e&amples from everyday life, This is an effort to make the pattern idea
more approachable, The chapter then shows the res!lts of applying pattern<based thinking to an integration
scenario, Later chapters e&plain specific patterns in more detail,
Patterns
People think in patterns, +t is the way we nat!rally comm!nicate ideas related to comple& s!bEect areas s!ch as
m!sic, science, medicine, chess, and software design, Patterns are not new, *e all !se them int!itively as part
of the learning process witho!t really thinking abo!t it, nd beca!se o!r minds nat!rally !se patterns to
perform comple& tasks, yo! can find patterns nearly everywhere,
245450494.doc 10 od 257
Patterns in Sports
/onsider what happens d!ring a soccer game or an merican football game,
/igure 11 Patterns in soccer
/igure !1 Patterns in American &ootball
+ndivid!als who are acting according to predetermined patterns move ?!ickly and decisively against targeted
opponents, -ach individ!alJs pattern of movement is also part of a larger pattern of orchestration where each
player has clear responsibilities and scope, +n addition, the entire team is in a binary stateIeither offense or
defense, *itho!t patterns in sports, the games wo!ld not be as rich and interesting, /an yo! image how long
the h!ddle wo!ld be in an merican football game witho!t the lang!age of plays 'patterns(C
,ote Software patterns are significantly more comple& than these simple e&amples, The e&amples are
intended to make the notion of software patterns more approachable at the e&pense of being less technically
rigoro!s, 8or more rigoro!s introd!ctions to patterns, see the bibliography section,
245450494.doc 11 od 257
+f yo! look closer at patterns, yo! will find relationships between them, +n sports, for e&ample, teams have
certain plays for offense and certain plays for defense# the patterns that describe two playersJ actions m!st fit
into a larger pattern that the team is following, +n this sense, patterns can be described in terms of hierarchies,
Patterns in 2usic
nother e&ample of how people think in patterns is the patterns fo!nd in m!sic, s!ch as rock and roll, +n rock
and roll, a rhythm g!itar player !s!ally repeats a pattern of chords in a specific key, gainst this backdrop, a
lead g!itarist plays a freeform series of notes from a candidate pattern of notes that correspond to the chord
progression being played, 8ig!re ; shows a pattern chart that lead g!itarists !se to learn the correct finger
positions on a g!itar neck,
/igure $1 Pentatonic scale patterns in the -ey o& A
The root note in 8ig!re ; indicates the key that the song is in, *ithin the songJs key, the lead g!itar player is
free to improvise, altho!gh most of the notes he or she plays will correspond to the pattern chart in 8ig!re ;,
The order and se?!ence of the notes may vary according to artist, style, and song, b!t the pattern of act!al
notes played remains, +f the key changes, the scale pattern moves to a different place on the g!itar neck that
corresponds to the songJs new key, +nterestingly eno!gh, this notion of one layer of patterns constraining
another is e&actly what happens when yo! apply pattern<based design methods, This is E!st as tr!e in software
design as it is in other design disciplines,
Pattern Structure
Patterns have a nat!ral relationship with each other, Perhaps the most often !sed e&ample is the interplay
between patterns for designing towns, which in t!rn, contain patterns for designing cl!sters of b!ildings and
roads, The b!ilding cl!ster and road patterns, in t!rn, contain patterns for designing b!ildings, 8ig!re 5 shows
these relationships,
245450494.doc 12 od 257
/igure '1 3ierarchy o& patterns
Pattern4#ased Design
*hile pattern<based design is relatively new in the field of software development, ind!strial technology has
!sed pattern<based design for decades, perhaps even cent!ries, /atalogs of mechanisms and standard
config!rations provide design elements that are !sed to engineer a!tomobiles, aircraft, machine tools, and
robots, pplying pattern<based design to software development promises the same benefits to software as it
does to ind!strial technology: predictability, risk mitigation, and increased prod!ctivity,
5.perience is 6ey
=f co!rse, pattern<based design alone is no g!arantee of s!ccess in either software design or ind!strial
technology, 0nown good mechanisms can be !sed to b!ild planes that do not fly, cars that do not handle well,
and applications that do not scale, There is simply no s!bstit!te for the skill and e&perience of designers and
engineers in any s!bEect area, and software is no e&ception, ltho!gh patterns help by offering manageable
portions of design knowledge, they are not complete sol!tions by themselves, They still re?!ire yo!r skill and
e&perience to tailor them to yo!r specific re?!irements,
Applying Patterns
pplying patterns to a specific scenario !s!ally involves an iterative design process, s a g!iding principle, yo!
want to keep yo!r design as @simple as possible and no simpler,@ as lbert -instein once said, ltho!gh yo! can
!se patterns to solve design problems, make s!re that yo! have a legitimate problem first before applying a
pattern, Do not !se patterns E!st for the sake of !sing them,
245450494.doc 13 od 257
ltho!gh design g!idelines and process are related topics 'and worthy of dedicated works(, this book foc!ses
on the tangible o!tp!ts of the design process, +t foc!ses in partic!lar on the role of patterns as they are applied
to problems, To e&amine the concrete artifacts prod!ced by a pattern<based design process, letJs go back to
"lobal 1ank and see what came o!t of the design sessions as the team worked on the baseline architect!re,
Patterns at Global #an-
The architect!re team analy9ed the high<level re?!irements and constraints provided by the /T= and reviewed
e&isting technical architect!re models of the enterprise, The architect!re team also designated several
members of the team to do a b!ild<vers!s<b!y analysis of related commercial off<the<shelf software '/=TS(
packages that might meet the re?!irements,
1ased on the b!ild<vers!s<b!y analysis, the team decided to b!ild a c!stom e&tensible portal by !sing
commercial platform infrastr!ct!re components s!ch as *eb servers and database servers, b!t not to !se
packaged portal applications, 8ig!re A shows their initial appro&imation of the server types in a network
diagram,
245450494.doc 14 od 257
/igure (1 Initial networ- diagram with ser7er types
8or each key !se case, the team determined the se?!ence of system interactions that m!st occ!r to f!lfill the
stated re?!irements, They described these interactions in terms of server types and message se?!ences, 8ig!re
P shows the :iew Sched!led Payments !se case reali9ation in the form of a collaboration diagram,
/igure )1 8iew Scheduled Payments collaboration diagram
The flow of the !se case in 8ig!re P is:
6, c!stomer navigates to the online bill payment application,
3, The *eb server prompts the c!stomer for a !ser name and password,
;, The *eb server a!thenticates the c!stomer by !sing information retrieved from the directory server,
5, The *eb server sends an asynchrono!s re?!est to the integration server asking for related loans,
A, The *eb server retrieves the c!stomerJs mainframe acco!nt n!mber from the payment server,
P, The *eb server retrieves c!stomer profile information from the /%M server,
O, The *eb server retrieves acco!nt balance information from the mainframe,
7, The *eb server retrieves a list of sched!led payments from the payment server,
M, The *eb server checks the integration server to see whether any loan information has been retrieved,
64, The *eb server b!ilds the presentation, which displays acco!nt balance, sched!led payments, and
c!stomer profile information,
66, +f loan information is available, it appends this optional information onto the presentation,
63, The *eb server ret!rns the presentation code back to the browser,
6;, The browser renders the view,
245450494.doc 15 od 257
This !se case reali9ation is a representative sample of the bill payment applicationJs significant !se cases, The
team took a similar approach to analy9e other !se cases, identify server types, and design message
interactions, To create these !se case reali9ations, the team cond!cted a series of iterations, each beginning
with a design session !sing class<responsibility<collaboration '/%/( style techni?!es, ltho!gh similar in nat!re
to /%/ sessions, these sessions were not limited to class<level abstractions, =ften these sessions involved
s!bsystems, server types, processes, and channels as well,
The teamJs goal, as they considered the necessary collaborations between elements, was to design the simplest
system that wo!ld satisfy all c!rrent re?!irements and acco!nt for system constraints, *hile working thro!gh
the alternatives, they relied on the lang!age of patterns to provide a common vocab!lary for the team, Patterns
were also !sef!l as a concise way to comm!nicate the conte&t, forces, and tradeoffs involved in each design
decision, t times, they reali9ed that certain patterns only added comple&ity to the design, so they eliminated
those patterns,
s they completed each iteration, they created a pattern model of the system to record their decisions, The
model from the last iteration is shown in 8ig!re O, This pattern model represented the simplest system that
reali9ed the target !se cases and constraints, To keep their models simple, they represented patterns as circles
and added other high<level design elements to the model to comm!nicate the overall design,
245450494.doc 16 od 257
/igure *1 Patterns and design element model
The ne&t chapter capt!res some of the pattern<based disc!ssion that occ!rred d!ring the design process, 8or
now, E!st notice how the patterns connect key design elements s!ch as the c!stomer and the mainframe
system,
,ote 1eca!se architects and developers are the primary a!dience for this g!ide, this disc!ssion moved
?!ickly into applying patterns to a specific scenario, 8or a more detailed disc!ssion of pattern<based design, see
/hapter O, ProEect .otebook,
The ne&t step was to map these patterns to an implementation technology and to iterate again, +n this case,
many of the platform decisions were already made, and these platform decisions constrained the design
choices, Sometimes, the implementation constraints forced the team to reconsider their design, and they
adE!sted accordingly, *hen they finished, they prod!ced the platform<level implementation diagram shown in
8ig!re 7,
/igure 91 Pattern diagram mapped to implementation technology
8ig!re 7 shows that the "lobal 1ank integration architect!re is composed of n!mero!s pattern<based design
elements implemented on the Microsoft platform, To trace the implementation of these elements down to
r!nning bits, refer to the appropriate implementation pattern later in this g!ide, 8or e&ample, to !nderstand
245450494.doc 17 od 257
how to implement the gateway to the mainframe, refer to +mplementing "ateway with )ost +ntegration Server
3445, This pattern incl!des the details associated with connecting "lobal 1ankJs ,.-T 8ramework portal
application with their e&isting /=1=L<based /+/S transactions,
,e.t Chapter
This chapter introd!ced the "lobal 1ank scenario that is !sed thro!gho!t this g!ide and briefly disc!ssed how
patterns can help development teams find workable answers to integration challenges, The ne&t chapter !ses
the lang!age of patterns to e&plore the decisions and tradeoffs that the "lobal 1ank architect!re team made
while designing and implementing their bill payment system,
"sing Patterns to Design the #aseline Architecture
Summary This chapter !ses the lang!age of patterns to e&plore the decisions and tradeoffs that the "lobal
1ank architect!re team made while designing and implementing their bill payment system,
Contents
Meeting the %e?!irements of "lobal 1ank
Designing the "lobal 1ank 1aseline rchitect!re
.e&t /hapter
@+tJs all talk !ntil the code r!ns,@I*ard /!nningham
The last chapter introd!ced a banking scenario that posed many technical integration challenges, +t also
presented patterns as an effective means of comm!nicating design decisions, This chapter walks tho!gh the
application of integration patterns in the conte&t of the "lobal 1ank scenario,
ltho!gh the scenario is a fictitio!s story for conveying design decisions, it is important to note that the a!thors
act!ally b!ilt and performance tested this design in the patterns & practices lab at Microsoft, The design team
consisted of field<e&perienced practitioners with access to the latest prod!ct b!ilds, The decision points in the
story correspond to real decision points in the lab, altho!gh this description shapes them into a more readable
story than the act!al effort, lso, the act!al development process was more iterative than the story might
s!ggest# some portions of the system evolved incrementally, Later in this g!ide, yo! will find that the
implementation patterns contain e&tracts of the code !sed to r!n the "lobal 1ank baseline architect!re, Ho! will
also find more detailed e&planations of the patterns mentioned in this chapter,
2eeting the Re0uirements o& Global #an-
t the end of the last chapter, the "lobal 1ank architect!re team applied a pattern<based design approach to its
bill payment systemJs re?!irements and arrived at an initial technical architect!re bl!eprint, t this point, the
team felt fairly satisfied abo!t the initial design, at least on paper, The members of the team knew the val!e of
245450494.doc 18 od 257
creating these design models, b!t they also knew that they wo!ld learn other things only from the r!nning
code, They were an&io!s to validate their models with e&ec!table bits,
To validate their thinking, the members of the "lobal 1ank team b!ilt a baseline architect!re in the test lab and
implemented five of the most architect!rally significant !se cases, They chose these partic!lar !se cases to help
define and validate the most important mechanisms in the design, They did not intend the !se cases to be
f!nctionally completeIthat wo!ld come later when the f!nctional re?!irements firmed !p, t this point, they
wanted to refine the riskiest parts of their design down to the level of e&ec!table code, the most concrete form
of design,
s they implemented this baseline architect!re, members of the team also performance tested many parts of
the system to validate their design ass!mptions and tradeoffs, This helped them to f!rther !nderstand the
overall scalability of their sol!tion as they considered the impact of additional !sers over time, ll of this
implementation and testing contrib!ted to their overall confidence in the patterns they had selected,
The b!lk of this chapter e&plores the decisions and tradeoffs that the "lobal 1ank architect!re team made
d!ring the design and implementation process, and it takes a closer look at the implemented system, The
disc!ssion !ses the lang!age of patterns to convey these decisions and tradeoffs, as well as the intentions
behind them, as discrete and comprehensible decision points, Thro!gho!t the disc!ssion, pattern names appear
in title capitali9ation and italic 'for e&ample, Portal Integration(, This treatment of pattern names emphasi9es
the b!ilding of a pattern vocab!lary and signals that the concepts are e&plained as patterns later in this g!ide,
"sing Patterns to Communicate Design Decisions
-ach pattern clearly limits the scope of its problem and sol!tion to a discrete and comprehensible, or @mind<
si9ed,@ decision point, 1y considering relatively small atomic design decisions one at a time, yo! are better
prepared to manage the overall comple&ity of the system, s yo! b!ild a comple& system, yo! aggregate these
small design decisions together to event!ally form a larger hierarchy, or frame, of decisions,
=f co!rse, changes at the top of the hierarchy may affect the elements below, and it is !nrealistic to e&pect
yo!r first design to be E!st right, Most likely, yo! will need to iterate, )owever, having a set of discrete decision
points makes it easier to iterate when yo! need to,
%emember, in comple& environments, there is often no single right answer for a given problem, 8or any set of
re?!irements, each gro!p of designers may arrive at different, yet e?!ally valid, designs, $s!ally, the difference
reflects a different set of tradeoffs and priorities, *hat is most important to !nderstand abo!t the design
process is that:
series of technical decisions m!st be made,
-ach design decision involves tradeoffsIboth advantages and disadvantages,
Tradeoffs made at one level constrain the decisions at other levels,
The s!m of these design decisions m!st res!lt in an architect!re that meets both the f!nctional and
nonf!nctional re?!irements of the system,
245450494.doc 19 od 257
*ith these g!idelines in mind, the architect!re team set o!t to b!ild a baseline architect!re,
The Role o& a #aseline Architecture
baseline architect!re is a thin e&ec!table slice thro!gh the overall system that is designed to implement the
most architect!rally significant !se cases, s yo! implement these key !se cases, yo! want to define the key
mechanisms and components in the system and retire the most serio!s technical risks early, +f yo! do this well,
the baseline architect!re does not become a prototype to be thrown away, +nstead, it becomes the skeletal
str!ct!re of the system, The baseline provides s!fficient stability so that s!bse?!ent iterations can smoothly
evolve the r!nning system into one that meets all of the f!nctional and nonf!nctional re?!irements, The
baseline architect!re is intentionally incomplete,
)ow do yo! act!ally design a baseline architect!reC To answer this ?!estion, letJs trace the architect!re teamJs
steps d!ring the design sessions,
Designing the Global #an- #aseline Architecture
s the team dissected the high<level re?!irements of the chief technology officer '/T=(, the members of the
team arrived at the following !se cases:
Sched!le Payments
:iew Sched!led Payments
-&ec!te Sched!led Payment
%eceive Payment %esponse
dd Payee
The first !se case they disc!ssed was the :iew Sched!led Payments !se case, This !se case involved a portal
that allowed !sers to see their acco!nt information, incl!ding their c!rrent acco!nt balance and a list of
sched!led payments, To b!ild this portal, the team wo!ld need to connect to m!ltiple back<end systems and to
aggregate the res!lts in a single view, +mplementing this !se case wo!ld re?!ire the team to resolve several
key technical iss!es, LetJs look now at the !se case in more detail and !nderstand the teamJs thinking as they
approached the problem,
8iew Scheduled Payments "se Case
To implement :iew Sched!led Payments, the portal wo!ld have to display the following information:
cco!nt information from the mainframe
Profile information s!ch as name and address from the /!stomer %elationship Management '/%M(
system
Sched!led payment information from a payment system
=ptionally, the portal wo!ld have to display any other loans the c!stomer might have with newly ac?!ired
banks so that the c!stomer co!ld s!bmit electronic payments toward these loans,
245450494.doc 20 od 257
+nitially, members of the team had slightly different opinions of what a portal was, )owever, they event!ally
agreed that a portal is a single view into many back<end systems that are integrated @at the glass,@ or, in other
words, at the !ser presentation level, Th!s, Portal +ntegration is a type of integration that looks like 8ig!re 6,
/igure 11 Portal integration to multiple bac-4end systems
The members of the "lobal 1ank team needed to make individ!al connections to many different kinds of
systems to make Portal Integration work, They considered each connection individ!ally to determine e&actly
how they were going to connect to the system,
,ote t this point in the story, the payment system does not e&ist, +t is, however, incl!ded in 8ig!re 6 as a
placeholder to !se for planning p!rposes,
System Connections
s the members of the team tho!ght more abo!t this problem, they debated the kinds of connections they
co!ld make, The disc!ssion was f!ll of overloaded terms and individ!al biases toward the methods that each
member was most familiar with, To make matters worse, the team did not share a common design vocab!lary
beca!se some members of the team had never worked together before,
8inally, the members of the team reali9ed they had to narrow the disc!ssion to a few practical choices for each
system, To do so, they wo!ld have to tighten their frame of reference when they compared their connection
options, They finally agreed to approach the problem from the perspective of integrating by !sing a Three<
Layered Services pplication LTrowbridge4;N, s shown in 8ig!re 3, a T"ree#ayered Ser!ices $pplication
defines three distinct logical layers: data, %usiness logic 'f!nctional(, and presentation,
245450494.doc 21 od 257
/igure !1 Three4%ayered Ser7ices Application
They also agreed that altho!gh not every system was designed as a T"ree#ayered Ser!ices $pplication, !sing
these three logical layers wo!ld give them a common way to reason abo!t other systems, $sing these layers to
shape their disc!ssion, they began to disc!ss the relative tradeoffs between each connection alternative,
,ote To present an overview of the design, this chapter disc!sses tradeoffs between design alternatives at a
high level only, 8or more detailed information regarding these tradeoffs, see the pattern chapters '/hapters ;
thro!gh P(, +f yo! want to see a vis!al model of all of these patterns and their relationships, see /hapter O,
ProEect .otebook,
8irst, they co!ld !se Data +ntegration to connect at the logical level of data, making the same data available to
more than one application, This approach worked well when there was very little b!siness logic to re!se across
applications, 8or other applications, they knew that raw data was not eno!gh# they wanted to re!se the
f!nctionality of a given application, This f!nctionality often contained b!siness logic, process, or calc!lated
val!es, +n this case, they wo!ld need to !se 8!nctional +ntegration to connect at the b!siness logic layer. nd
altho!gh they preferred to connect to systems directly to share either f!nction or data, they acknowledged that
sometimes the only practical way to integrate with a system was thro!gh Presentation +ntegration, also known
as screen scraping, Moving away from a p!re systems perspective, they also disc!ssed h!man integration as a
means to integrate with a system, )owever, beca!se they were foc!sed on b!ilding a baseline architect!re,
they considered h!man integration to be o!t of scopeIat least for the moment,
.ow that they agreed on an approach to the alternatives before them, the members of the team ret!rned to
the set of individ!al connection decisions they had to make, The first system to connect to was the payment
system,
Connecting to the Payment System
The members of the team knew they wo!ld need a system to hold all the sched!led payments along with
related information, They decided the simplest thing to do was to b!ild a payment system that persisted this
information in a database with *eb<based administrator screens to manage the data, They decided to !se Data
+ntegration to connect the portal to the payment system beca!se no additional system f!nctionality or behavior
seemed important to share,
245450494.doc 22 od 257
Connecting to the CR2 System
The ne&t system to connect to was the e&isting /%M system, The members of the team analy9ed the system
architect!re and reali9ed there was only one practical choice: 8!nctional +ntegration, That is beca!se the
software vendor !sed a highly abstracted schema within a relational database to store information and
recommended against &ata Integration, +nstead, the vendor provided a f!nctional *eb services interface to
encaps!late access to the data, This was the same kind of encaps!lation at a system level that good obEect<
oriented designers perform at a class level when they create private instance variables and p!blic accessor
methods,
ltho!gh encaps!lation is generally a good thing, in this case the members of the team marked it as a technical
risk, They marked it as a risk beca!se the vendorJs implementation was effectively @black bo&,@ or !nknown to
the "lobal 1ank team, The members of the team also knew from e&perience how diffic!lt it is to b!ild high
performance abstract interfaces, 8!rthermore, beca!se profile information from the /%M was re?!ired with
each :iew Sched!led Payments re?!est, performance was critical, They decided to mark this interface as a key
test point and to stress test it early to discover the point where additional load wo!ld compromise system
performance, They needed this information soon so they co!ld consider compensating design alternatives, if
necessary,
Connecting to the 2ain&rame
+ntegrating with the mainframe was critical beca!se it was the system of record for all acco!nt information,
=ver the years, the organi9ation had invested significantly to develop solid /!stomer +nformation /ontrol
System '/+/S( transactions, ny integration with the acco!nt system wo!ld need to !se this f!nctionality#
therefore, the team chose Functional Integration b!t deferred the connection details !ntil later,
The team created the diagram in 8ig!re ; to record the design decisions made so far, The team !sed s?!ares to
represent design elements, circles to represent patterns, and lines to indicate relationships between the
patterns and other design elements,
245450494.doc 23 od 257
/igure $1 Connecting the payment: CR2: and main&rame systems to a portal
Connecting to %oan Systems
The final connections to consider were the connections to the ac?!ired bank systems that were located in a
remote data center, This optional part of the !se case involved finding all loans a c!stomer might have with
these banks so that the c!stomer co!ld sched!le payments toward them, This re?!irement presented many
challenges, 8irst, &ata Integration wo!ld be comple& beca!se of the many different data formats, The many
different data formats wo!ld re?!ire m!ltiple transformations, .e&t, beca!se more ac?!isitions were likely, the
team wanted to minimi9e the cost of integrating additional systems into this consolidated loan information
re?!est, The team decided to !se Functional Integration in the form of re?!est and response messages and to
e&pect each system involved in this collaboration to provide the appropriate response, This decentrali9ed
approach wo!ld make it easier to integrate new systems in the f!t!re,
s the members of the team tho!ght more abo!t the connections to the remote data center, they reali9ed there
was another complication with these connections, ll of the links between previo!s connections were reliable
connections within the same enterprise 'near lin's(, The connection to the remote data center spanned m!ltiple
enterprises and was not considered reliably connected 'a far lin'(, 1ased on previo!s e&perience, they
preferred to !se a message ?!e!e or message<oriented middleware, to b!ffer connections between far links to
improve reliability, They also knew that there were more iss!es than the reliability of the far link connections,
*ith this in mind, they decided to consider their growing network of connection points more caref!lly,
Integration Topology
ltho!gh the team was making progress toward determining the best way to connect to each system, choosing
the right topology to link these connection points seemed less clear, s the members of the team disc!ssed
245450494.doc 24 od 257
alternatives, they arrived at three possible ways to connect three or more systems together: PointtoPoint
(onnection, Message )ro'er, and Message )us,
The easiest way to connect the systems was to !se the PointtoPoint (onnection pattern, as shown in 8ig!re 5,
/igure '1 Connecting &our systems through point4to4point connections
PointtoPoint (onnection is effective and simple for a small n!mber of systems, liability of this approach,
however, is that each system m!st have information abo!t each endpoint that it connects to, The members of
the team knew that as they added more systems to their integration architect!re, it wo!ld become more and
more comple& to add each additional system, making it e&pensive to e&tend and manage,
The team considered inserting a Message )ro'er to act as an intermediary between senders and receivers, as
shown in 8ig!re A,
/igure (1 Connecting &our systems by using a message bro-er
The advantage of !sing a Message )ro'er is that it deco!ples the receiver from the sender, +nstead of sending
the message to a specific endpoint, the sender can send messages to the broker, The broker then ro!tes the
245450494.doc 25 od 257
message to the proper recipients, +n addition, the broker often transforms the messages from one format to
another to resolve the incompatible message formats between endpoints,
8inally, the team considered connecting m!ltiple systems by !sing a Message )us, Message )us 'see 8ig!re
P( re?!ires each system on the b!s to share a common data format, a common set of command messages, and
a common infrastr!ct!re, system sends a message to the Message )us, and the Message )us then transports
the message to the other systems by way of the common infrastr!ct!re,
The members of the team liked the fact that after a Message )us is b!ilt, the cost of adding another system to
the message b!s is negligible to the e&isting systems, s they tho!ght f!rther abo!t implementation, they
disc!ssed different ways the common infrastr!ct!re might be b!ilt and soon fo!nd themselves in a heated
debate over s!ch iss!es as broadcast and Pu%lis"*Su%scri%e +pu%*Su%,, They agreed to postpone f!rther
disc!ssion of these iss!es !ntil or !nless they decided to incorporate a Message )us into the act!al design,
/igure )1 /our systems connected with a message bus
.ow that the members of the team had brainstormed alternative integration topologies, they bro!ght their
attention back to the :iew Sched!led Payments !se case, They knew there were many kinds of systems
providing loan information to this !se case, They also knew it was likely that the bank wo!ld ac?!ire even more
financial services companies in the f!t!re, These potential ac?!isitions represented even more so!rces of loan
information to be integrated, They wanted the system to be fle&ible in its ability to handle these kinds of
changes,
Adding a 2essage #ro-er &or the %oan Systems
They decided to employ a Message )ro'er between "lobal 1ankJs data center and the remote data center
ho!sing the other loan systems, They intended to send a loan information re?!est message to the broker, and
the broker wo!ld then forward it to other systems interested in this type of message, s these systems
responded with loan information, the broker wo!ld p!ll the information together and make it available as a
consolidated whole,
1y !sing a message ?!e!e to implement Message )ro'er, they wo!ld also create the kind of b!ffer they wanted
between their data center and the far link that connected it to the remote data center,
245450494.doc 26 od 257
8ig!re O shows how the members of the team modified their original diagram to incl!de the message broker
connecting the portal to the remote data center,
/igure *1 Connecting the portal to the remote data center
To show the dynamic nat!re of the system and to doc!ment how the system wo!ld reali9e the :iew Sched!led
Payments !se case, the team drew the collaboration diagram that is shown in 8ig!re 7,
245450494.doc 27 od 257
/igure 91 8iew Scheduled Payments collaboration diagram
The following is the flow of the !se case that is shown in 8ig!re 7:
6, c!stomer browses to the online bill payment application,
3, The *eb server prompts the c!stomer for a !ser name and password,
;, The *eb server a!thenticates the c!stomer by !sing information retrieved from the directory server,
5, The *eb server sends an asynchrono!s re?!est to the integration server asking for related loans,
A, The *eb server retrieves c!stomer profile information from the /%M server,
P, The *eb server retrieves the c!stomerJs mainframe acco!nt n!mber from the payment server,
O, The *eb server retrieves acco!nt balance information from the mainframe,
7, The *eb server retrieves a list of sched!led payments from the payment server,
M, The *eb server checks the integration server to see whether any loan information has been retrieved,
64, The *eb server b!ilds the presentation, which displays acco!nt balance, sched!led payments, and
c!stomer profile information,
66, +f loan information is available, it appends this optional information to the presentation,
63, The *eb server ret!rns the presentation code back to the browser,
6;, The browser renders the view,
So far, the members of the team had a pattern<based design model and a collaboration diagram that showed
how the system wo!ld reali9e the :iew Sched!led Payment !se case, They wanted one more model that
showed the static nat!re of their system with well<defined high<level bo!ndaries, To portray this view, they
!sed a portandwire model as shown in 8ig!re M, The o!tgoing ports are depicted as black s?!ares, and the
incoming ports are depicted as white s?!ares,
245450494.doc 28 od 257
/igure ;1 8iew Scheduled Payments message &low
ltho!gh all the details were certainly not worked o!t for this !se case, the members of the team felt that the
!se case was at a s!fficient level of detail to proceed to the ne&t !se case, They wo!ld ret!rn to refine the
design later, after e&ploring whether parts of this design wo!ld reali9e other !se cases as well,
5.ecute Scheduled Payment "se Case
The ne&t !se case they considered was the -&ec!te Sched!led Payment !se case, To implement this !se case,
the system wo!ld:
Start !p at a system<defined interval,
%etrieve the set of payments to be made on or before the c!rrent date,
8or each payment, the system wo!ld verify that there were s!fficient f!nds in the payment acco!nt
and then debit the acco!nt for the payment amo!nt,
Send the payment to an appropriate payment channel,
245450494.doc 29 od 257
There were fo!r kinds of payment channels c!rrently in scope: domestic payments thro!gh a clearing ho!se,
electronic payment gateways !sing Society for *orldwide +nterbank 8inancial Telecomm!nication 'S*+8T(
transactions, electronic payments to a man!al f!lfillment ho!se, and acco!nt<to<acco!nt transfers within the
bankJs internal system,
/ocusing on the #aseline Architecture
s the members of the team talked tho!gh this !se case, they tried to avoid disc!ssing domain<specific details
that had more to do with b!siness logic than technical architect!re, ltho!gh they knew these details were
important, they also reali9ed that the p!rpose of the baseline architect!re was to mitigate technical risk, not to
f!lly refine the b!siness re?!irements, They knew the re?!irements team was on track to do e&actly that Eob,
so they foc!sed on the items that worried them the most from a technical perspective, They also deemphasi9ed
some of the !se case areas that did not represent top technical challenges,
Payment Channels
=ne area of concern was the S*+8T payment Gateway,
,ote The Gateway pattern abstracts access to an e&ternal reso!rce by presenting a single interface to the
integrated applications while hiding the e&ternal reso!rce interface, 8or more information, see @"ateway@ later
in this chapter,
The members of the team knew the re?!irements wo!ld incl!de making international transactions to s!pport
their wealthiest clients, and for this they wo!ld !se S*+8T transactions, They also knew there wo!ld be
re?!irements for domestic payments, and for those payments they wo!ld !se the e&isting system, +t wo!ld be
too e&pensive to pay a S*+8T transaction fee for domestic payments, especially when they already had an
e&isting payment system,
The e&isting payment system was technically straightforward, +t !sed a leased sec!re line for PointtoPoint
(onnection with a clearing ho!se and sec!re file transfer, The bank and the clearing ho!se e&changed files that
contained both o!tgoing and incoming data records, This was a simple form of &ata Integration that the bank
had !sed for years, The team wo!ld !se this system for domestic transfers, 1eca!se they !nderstood it well,
there was little reason to b!ild and test this system early, so these details were omitted from the initial !se
case,
)owever, the S*+8T payment Gateway was a very different story, They wo!ld need to package the transaction
sec!rely in an QML message and !se *eb services to send it to the payment Gateway over the +nternet,
1eca!se this part of the !se case was new to the team and presented many technical risks, it was one of the
top priorities for the baseline architect!re, They wanted to b!ild it early and test it,
"sing Domain 6nowledge to Guide Design Decisions
1eca!se many members of the team had been in banking for years, they nat!rally bro!ght their b!siness
knowledge into the design sessions, ltho!gh this b!siness knowledge was inval!able, the team had to sort o!t
what was relevant for the baseline architect!re and what was not, This sorting was, of co!rse, a E!dgment call,
b!t it was necessary for the team to stay foc!sed on mitigating the most important technical risks first,
245450494.doc 30 od 257
8or e&ample, the members of the team knew that any time the bank wo!ld initiate a payment thro!gh an
e&ternal party s!ch as a clearing ho!se or a payment Gateway, the confirmation wo!ld be delayed, The r!les of
do!ble entry acco!nting wo!ld not allow f!nds to be in limbo d!ring this period, Therefore, a holding acco!nt
wo!ld have to be credited at payment initiation and debited !pon payment confirmation, This wo!ld keep the
system in balance at all times,
ltho!gh implementing a holding acco!nt was critical to the final !se case, it was not critical for the early
baseline architect!re, The team was proficient at enlisting debits and credits in the same transactions across
most of the systems in the bank, They did not consider this to be a technical risk, Therefore, the team decided
to defer the implementation of this logic !ntil after the re?!irements team defined the specific holding acco!nts
to !se,
"sing SWI/T Gateway &or the #aseline Architecture
The r!les to determine the right payment channel were straightforward, *hen a c!stomer sched!led a
payment, the c!stomer co!ld select either a domestic or an international payment, +f the payment were
domestic, the c!stomer wo!ld provide an merican 1ankers ssociation '1( ro!ting n!mber for the intended
payee, +f this field were left blank, the system wo!ld send an electronic payment to a company that speciali9ed
in paper check writing and mailing services 'a man!al f!lfillment ho!se(, +f the field were not blank, the system
wo!ld check the ro!ting n!mber against a list of internal banks, +f the n!mbers matched, the system wo!ld
make a payment by transferring money internally from one acco!nt to another, +f the ro!ting n!mber were
valid b!t did not match the internal banks, the standard domestic payments system wo!ld make the payment
by sec!re file transfer, 8inally, payments marked as international wo!ld !se the S*+8T payment Gateway,
1eca!se the system wo!ld send the payment to an appropriate channel, there wo!ld be a system<based
acknowledgment that the message was received,
To simplify the initial !se case, the members of the team omitted any ro!ting to their domestic payment system
and instead ro!ted these payments thro!gh the S*+8T Gateway for test p!rposes, This e&ercised the S*+8T
Gateway by !sing the test data, The test data was based on domestic acco!nts instead of international
acco!nts, +t wo!ld be easy to add international ro!ting and test data later, b!t they wanted to press!re test the
Gateway payment mechanisms early,
s they contin!ed to walk tho!gh the !se case flow, the members of the team reali9ed that a key element was
missing, /!rrently, the system wo!ld receive an acknowledgment that the payment message was sent, b!t how
wo!ld the system know if the payment was received by the intended payeeC *hat wo!ld happen if the payment
Gateway or man!al f!lfillment ho!se co!ld not pay the payeeC These ?!estions led them to the %eceive
Payment %esponse !se case,
Designing &or 5.ecute Scheduled Payment and Recei7e Payment Response
The %eceive Payment %esponse !se case described the behavior of the payment Gateway and the man!al
f!lfillment ho!se after they processed the payment re?!est, +n this !se case, these payment channels ret!rned
245450494.doc 31 od 257
the res!lt of their processing to "lobal 1ankJs system, +f the payment was s!ccessf!l, the payment stat!s and
transaction +D were !pdated in the payment system, +f the payment failed, a compensating transaction to
credit the acco!nt was first iss!ed to the mainframe and then stat!s and +D fields were !pdated accordingly in
the payment system,
1eca!se of the close relationship between -&ec!te Sched!led Payments and %eceive Payment %esponse, the
team decided to eval!ate Process Integration for both !se cases,
Process Integration
Process +ntegration adds a layer of software on top of other applications and services to coordinate the
e&ec!tion of a long<r!nning b!siness f!nction, as shown in 8ig!re 64,
/igure 1<1 Process Integration: a coordinating layer abo7e other applications and ser7ices
The members of the team knew they wo!ld need a layer like this to coordinate the two !se cases, and they
disc!ssed the best way to design it, Some members of the team s!ggested an integration server, +ntegration
servers often incl!de orchestration tools for this p!rpose, =ther members of the team wanted to b!ild a c!stom
coordinating layer by encaps!lating process and activity components, They tho!ght the integration server was
e&cessive, fter some debate, they decided to choose the integration server approach, They reasoned it was
likely that the bank wo!ld contin!e to add more financial services and e&ternal partners in the f!t!re, and that
these services and partners wo!ld need Process Integration capabilities also, nd altho!gh the !se of an
integration server might initially cost them some time for installation and training, the cost wo!ld be more than
repaid thro!gh the red!ced development time and overall fle&ibility of the system,
The members of the team !pdated their design model to incorporate Process Integration, as shown in 8ig!re
66, .otice that process integration needs to comm!nicate with the message broker and the payment systems,
b!t it does not need to connect directly to the portal,
245450494.doc 32 od 257
/igure 111 Incorporating Process Integration into the baseline architecture
2essage #ro-er &or Payment Channels
ltho!gh Process Integration wo!ld handle the orchestration needs of long<r!nning transactions, the members
of the team knew that each payment channel was likely to need a different message format, th!s re?!iring
transformation code, They wo!ld need a S*+8T<compliant QML schema in the case of the payment Gateway
and a more generic QML schema in the case of the man!al f!lfillment ho!se, *orse, they anticipated that the
bank wo!ld add more e&ternal partners who wo!ld !se more message formats in the f!t!re, To avoid
d!plicating this transformation logic across the system and to take advantage of transformation tools, they
decided to !se a Message )ro'er as an intermediary between "lobal 1ankJs system and their trading partnersJ
systems,
Like the other Message )ro'er in this design, the ?!e!e<based message broker implementation wo!ld b!ffer
the somewhat !nreliable connections between systems,
2essage #ro-er "sing /unctional Integration with S=I
-ven tho!gh they decided to !se a message broker to comm!nicate with trading partners, they still had to
decide how to connect the Message )ro'er to the target system, Message )ro'ers can !se &ata Integration to
connect at the logical data layer, 8or e&ample, Message )ro'ers can connect at the logical data level by sending
245450494.doc 33 od 257
files by !sing 8ile Transfer Protocol '8TP(, =r, Message )ro'ers can !se Functional Integration to connect at the
b!siness logic layer, 8or e&ample, they can connect by !sing *eb services,
The members of the team knew there were many ways to share f!nctionality, The three most common methods
are distrib!ted obEects ',.-T 8ramework remoting, /=MR, /ommon =bEect %e?!est 1roker rchitect!re
'/=%1((, %emote Method +nvocation '%M+(# proprietary message<oriented middleware, and *eb services,
Some of the team members came from large enterprises where they had b!ilt logical services on top of
proprietary message<oriented middleware, This approach had had worked well for them in the past, )owever,
all the members of the team were intrig!ed by the possibility of !sing *eb services beca!se of the potential
interoperability between platforms and the s!pport of maEor platform vendors, .ot s!rprisingly, they decided to
connect with partners by !sing a kind of Functional Integration based on *eb services: Service<=riented
+ntegration 'S=+(,
To record their design decisions, the members team modified their design model to incl!de an additional
message broker and the !se of Ser!ice-riented Integration, as shown in 8ig!re 63, They also rationali9ed the
comm!nication lines with a common b!s to make the model more readable,
/igure 1!1 Incorporating 2essage #ro-er and Ser7ice4=riented Integration &or connections with
trading partners
245450494.doc 34 od 257
2odels &or 5.ecute Scheduled Payment and Recei7e Payment Response
+n addition to the pattern<based design model, the team decided to create a collaboration diagram for the
-&ec!te Sched!led Payment !se case, as shown in 8ig!re 6;,
/igure 1$1 5.ecute Scheduled Payment collaboration diagram
The following is the flow of the !se case that is shown in 8ig!re 6;:
6, system sched!ler in the integration server initiates this !se case and begins to e&ec!te the payment,
3, The integration server re?!ests the list of payments to make from the payment system,
;, 8or each payment, the integration server checks the acco!nt balance in the mainframe, The integration
server debits the acco!nt if s!fficient f!nds e&ist,
5, The integration server retrieves the appropriate sec!rity credentials for the message e&change,
A, The integration server sets the ro!ting information, transforms the message to the format !nderstood
by the recipient, and then sends the message,
To show a static view of the system with bo!ndaries, they created a port<and<wire drawing, as shown in 8ig!re
65,
245450494.doc 35 od 257
/igure 1'1 5.ecute Scheduled Payment use case reali>ation
1eca!se the %eceive Payment %esponse !se case was related to the :iew Sched!led Payments !se case, the
team created a collaboration diagram for this !se case, as shown in 8ig!re 6A,
/igure 1(1 Recei7e Payment Response collaboration diagram
The following is the flow of the !se case that is shown in 8ig!re 6A:
6, The precondition for this !se case is that a payment message has been sent to one of the payment
recipients: the S*+8T payment gateway, the man!al f!lfillment partner, or an ac?!ired bank,
245450494.doc 36 od 257
3, fter processing the payment re?!est, the payment recipient sends a payment response to the
integration server,
;, The integration server correlates the response to the originating re?!est,
5, +f the payment failed, the integration server credits the c!stomer acco!nt on the mainframe,
A, The integration server !pdates the payment record in the payment system with stat!s and transaction
+D,
2!st as they did for the previo!s !se case, the members of the team also prod!ced a port<and<wire diagram for
%eceive Payment %esponse, as shown in 8ig!re 6P,
/igure 1)1 Recei7e Payment Response use case reali>ation
Accessing Account Ser7ices on the 2ain&rame
s the members of the team reviewed the %eceive Payment %esponse !se case, they reali9ed there was still a
key iss!e to resolve, 1oth this !se case and the :iew Sched!led Payments !se case needed to access the
mainframe by !sing Functional Integration, altho!gh e&actly how that was going to be done was still !nclear,
There were clear differences in application programming and potential differences in network protocols that had
245450494.doc 37 od 257
to be resolved, not to mention sec!rity and transactions, )ow wo!ld the team manage this comple&ity and not
let it overcomplicate the designC =ne team member s!ggested a Gateway,
Gateway
Gateway is a design element that encaps!lates o!tbo!nd access to an e&ternal system, There are Gateways
at the application level that are !s!ally implemented as classes, 8or more information, see -nterprise Sol!tion
Patterns $sing Microsoft ,.-T LTrowbridge4;N or Martin 8owlerJs Patterns of Enterprise $pplication $rc"itecture
L8owler4;N, There are also Gateways at the integration level that are !s!ally implemented as processes or
s!bsystems, 1ased on the /T=Js constraints, the members of the team knew that the system platform wo!ld be
based on Microsoft technology, while the mainframe was based on an +1M /+/S system, They decided to
employ a Gateway to bridge the comm!nication and programming model between these different technologies,
ltho!gh the team decided to !se a Gateway to bridge technologies, the team needed to decide how to connect
the application to the Gateway, =ne method was to connect the *eb server directly to the mainframe Gateway,
res!lting in the least n!mber of network hops, while placing a mainframe connection in the perimeter networ'
'also known as DMF, demilitari9ed 9one, and screened s!bnet(, ltho!gh this direct connection was likely to be
fast, it wo!ld re?!ire deploying the connection to every *eb server !sed for this p!rpose, +t also made the
team nervo!s that a hacked *eb server co!ld be !sed to gain mainframe access,
nother choice was to wrap the mainframe Gateway with a Service +nterface LTrowbridge4;N by !sing *eb
services and to then have the SP,.-T page from the *eb servers make the call to the Ser!ice Interface, The
Ser!ice Interface wo!ld then access the mainframe thro!gh the Gateway, The additional network hops and
seriali9ation wo!ld have performance implications, b!t this approach wo!ld also have the advantage of
e&posing the mainframe f!nctionality 'Functional Integration( to other applications in the enterprise by !sing a
platform<independent connection 'Ser!ice-riented Integration(, To sec!re this connection, the members of the
team considered a *eb Services Sec!rity '*S<Sec!rity( implementation, b!t they reali9ed there wo!ld be a
performance tradeoff for the necessary encryption and decryption ro!tines,
/apt!ring the design decisions made so far, the members of the team modified their design model to reflect the
Gateway and Ser!ice Interface patterns shown in 8ig!re 6O,
245450494.doc 38 od 257
/igure 1*1 Incorporating the Gateway and Ser7ice Inter&ace to communicate with the main&rame
Per&ormance 7s1 5.tensibility Tradeo&&
The team knew that the acco!nt system on the mainframe was a key system to the enterprise and that many
other systems and services wo!ld need to !se it, 1eca!se so many systems depended on it, they also knew
that performance was important,
1ased on these considerations, the members of the team created test re?!est and response messages with
realistic payloads, and they created three test points that were designed to meas!re relevant performance,
The first test point ran from the *eb server directly to the Gateway system, The second test point ran from the
*eb server to a *eb servicesGbased Ser!ice Interface, The Ser!ice Interface then !sed a Gateway system to
call the mainframe, 8inally, the last test point ran the same *eb servicesGbased Ser!ice Interface b!t
implemented *S<Sec!rity, They stressed the system to find o!t where the transaction rates, conc!rrent !sers,
and response times flattened, They wo!ld need to know this information to compare it to the operational
re?!irements being capt!red by the proEect team, $sing the act!al performance against the re?!irements
wo!ld help them determine how to best meet the re?!irement for the system to handle !p to three times the
anticipated load, $ltimately, it wo!ld help them make the tradeoffs in performance and fle&ibility that they
needed to make,
245450494.doc 39 od 257
t this point, the team felt they had worked o!t most of the necessary reso!rce connections and
comm!nication mechanisms to meet the c!rrent !se cases, They now t!rned their attention to the portal *eb
application itself,
The Portal Web Application
To refine the portal application, the team needed to decide the identification, a!thentication, and a!thori9ation
mechanisms the *eb application wo!ld !se to identify a c!stomer and a!thori9e access, They decided to !se
+ntercepting 8ilter and the ctive DirectoryK directory service,
8ollowing the steps of the :iew Sched!led Payments !se case, a c!stomer !ses a *eb browser to go to the
"lobal 1ank *eb site where an Intercepting Filter intercepts the *eb re?!est and prompts the !ser for a !ser
name and password, The *eb server re?!ests the !serJs credentials from the directory server, a!thenticates
the !ser, associates the !ser with a role, and then ret!rns a set of credentials to the *eb server,
8ig!re 67 shows how the members of the team modified their pattern<based design model to doc!ment these
decisions,
245450494.doc 40 od 257
/igure 191 Adding Intercepting /ilter and Directory Ser7ices to the design model
%efining the portal application re?!ired the !se of other related patterns that solve other problems beyond
integration, These problems appear almost any time yo! want to b!ild a *eb<based application,
Application 7s1 Integration Patterns
The Intercepting Filter pattern E!st introd!ced into the "lobal 1ank design is not part of this Integration
Patterns g!ide, .either are the Ser!ice Interface or class<level gateways, s!ch as Ser!ice Gateway, that also
become part of the design later in this chapter, These other patterns are from -nterprise Sol!tion Patterns
$sing Microsoft ,.-T, which is a recommended prere?!isite to this g!ide, dditionally, the &ata Integration
pattern later in this g!ide refers to Data Patterns, which is another previo!s patterns g!ide, 8ig!re 6M shows
the relationship between these three g!ides,
/igure 1;1 Relationship between Integration Patterns and other 2icroso&t patterns guides
8or more information abo!t previo!sly released patterns, refer to the g!ides and their references, .ow letJs
ret!rn to the "lobal 1ank scenario,
Global #an- Portal Application
+n the :iew Sched!led Payments !se case, after the *eb server obtains and validates sec!rity credentials, the
*eb server !ses these credentials to iss!e an asynchrono!s re?!est for loan information from within a
synchrono!s method, This approach is the .alf Sync"*.alf $sync" pattern, .e&t, the *eb server !ses a
Gateway obEect to access the mainframeJs Gateway s!bsystem and retrieve an acco!nt balance,
,ote The Gateway in this case is a class<level or obEect<level Gateway, whereas the Gateway that translates
network and programming model calls to the mainframe is a s!bsystem<level Gateway, 8or information abo!t
class<level Gateways, see Service "ateway in Enterprise Solution Patterns for Microsoft .NET and &ata Ta%le
Gateway in Martin 8owlerJs Enterprise $pplication $rc"itecture, +nformation abo!t s!bsystem<level gateways is
contained later in this g!ide,
245450494.doc 41 od 257
The *eb server then !ses a Gateway obEect to call the /%M system, The /%M system has encaps!lated its
f!nctionality with a *eb servicesGbased Ser!ice Interface, 8inally, the *eb server checks to see whether the
asynchrono!s re?!est has ret!rned a loan information response, fter all this data is retrieved, the *eb server
then b!ilds a presentation that displays all the re?!ested information, +f the loan system re?!est ret!rned any
entries, the presentation appends this information to the display as optional information,
8ig!re 34 shows how the members of the team !pdated the pattern<based design model to doc!ment these
decisions,
/igure !< Adding Gateways to the design model
Implementing the Global #an- Scenario
+f yo! consider all of the patterns in 8ig!re 34 as high<level design elements '!nbo!nd( and walk thoro!gh the
!se cases presented so far, yo! can see how these elements collaborate at an abstract level to reali9e these !se
cases, To refine this design f!rther, yo! m!st map these patterns to an implementation platform, Doing so
!s!ally re?!ires additional iterations across the design beca!se the chosen implementation may constrain or
enable certain pattern<based design decisions,
245450494.doc 42 od 257
8or e&ample, some of the implementation decisions will be constrained by decisions that the enterprise has
already made, To !nderstand these constraints, yo! need to !nderstand the c!rrent technical architect!re
within yo!r enterprise and make an intelligent initial allocation of f!nctionality to server types, The members of
the "lobal 1ank team did this for their scenario and arrived at the model of their technical architect!re that is
shown in 8ig!re 36,
/igure !11 Initial Global #an- networ- diagram with ser7er types
To refine this model more, the members of the team needed to decide the platform or platforms to b!ild their
system on, "iven the /T=Js constraints, some of the platform infrastr!ct!re decisions were easy, 8or e&ample,
the acco!nt information of record wo!ld reside on the mainframe, The mainframe is based on an +1M =S>;M4
operating system, The ac?!ired banks ran on systems based on *ebSphere 2ava 3 -nterprise -dition '23--(,
The rest of the systems wo!ld be based on the Microsoft platform, as shown in 8ig!re 33,
245450494.doc 43 od 257
/igure !!1 2apping the baseline architecture and patterns to technologies
.otice the mi& of Microsoft and third<party technologies, as well as the ?!estion mark associated with the
Microsoft /%M system, The ?!estion mark indicates that the "lobal 1ank team is still testing whether this
system meets its re?!irements, The team will compare the performance test res!lts with the act!al operational
re?!irements obtained from the proEect team to see if this implementation meets its performance needs,
Later in this book, yo! will find these patterns described in detail, with matching implementation patterns to
Microsoft technologies,
,ote The preview release of this g!ide does not doc!ment all the patterns that appear in 8ig!re 33, 8or
e&ample, only some architect!re and design patterns have matching implementation patterns, )owever, some
patterns have m!ltiple implementation patterns, s!ch as +mplementing Service<=riented +ntegration with
SP,.-T and +mplementing Service<=riented +ntegration with 1i9Talk Server 3445,
,e.t Chapter
This chapter showed how the "lobal 1ank team applied patterns to design their baseline architect!re, The
description moved ?!ickly over a wide range of patterns and technical challenges, The ne&t chapter is the first
of three pattern cl!ster chapters that describe these patterns in greater detail, /hapter O, @ Lang!age of
Patterns,@ !ses a vis!al model to tie these patterns and their relationships together and to e&plain how the
"lobal 1ank team !sed this vis!al model to g!ide them thro!gh their design choices,
245450494.doc 44 od 257
Integrating %ayer

Summary This chapter describes the different strategies for designing an integration layer and the tradeoffs
involved in choosing an alternative, n integration layer can a!tomate comple& b!siness processes or provide
!nified access to information that is scattered across many systems,
Contents
Level of !tomation
Level of bstraction
Maintaining State
/o!pling
Semantic Dissonance
/hoosing an +ntegration Layer Type
+ntegration Layers Patterns
@ny problem in comp!ter science can be solved with another layer of indirection,@IDavid *heeler 'chief
programmer for the -DS/ proEect in the early 6MA4s(
s described in /hapter 6, connecting m!ltiple systems re?!ires an infrastr!ct!re that moves data between the
systems, )owever, yo! often want the sol!tion to do more than E!st pass data aro!nd, Ho! want to add an
additional layer of f!nctionality on top of the f!nctional assets that reside inside the e&isting applications, This
layer can a!tomate comple& b!siness processes or provide !nified access to information that is c!rrently
scattered across many systems,
)ow sho!ld s!ch an integrating layer be designed, and what choices do yo! haveC $nfort!nately, there is no
single right answer for all enterprise architect!res, This chapter disc!sses some of the key considerations to
help yo! to !nderstand the tradeoffs associated with the vario!s alternatives and to find the most s!itable
approach,
%e7el o& Automation
f!lly integrated enterprise seems to be any /+=Js idea of perfection, /omple& interactions between systems
are orchestrated thro!gh precisely modeled b!siness process definitions, ny data format inconsistencies are
resolved thro!gh the integration layer, %elevant s!mmary data is presented to e&ec!tive dashboards with !p<
to<the<min!te acc!racy, S!ch visions are s!rely enticing, b!t sho!ld every enterprise set o!t to b!ild s!ch a
comprehensive and inherently complicated sol!tionC
245450494.doc 45 od 257
+t is not likely that anyone wo!ld b!ild s!ch a sol!tion beca!se of the time and money it takes to b!ild a
comple& enterprise integration sol!tion, Therefore, deciding how far to go is an important step when planning
an integration sol!tion, !tomation brings efficiency and can help eliminate inconsistencies in c!rrent b!siness
practices, )owever, complete a!tomation can re?!ire an enormo!s !pfront effort that delays the tangible
benefits to the b!siness, simpler sol!tion might only achieve a portion of the b!siness benefit, b!t it achieves
that benefit m!ch sooner and with m!ch less risk, 8or e&ample, displaying information from m!ltiple systems in
a single screen that is divided into individ!al panels can increase prod!ctivity, and it does not re?!ire the
system to resolve all the differences between e&isting systems,
%e7el o& Abstraction
=bEect<oriented design principles teach the benefits of abstraction, bstracting one systemJs internals from
other systems allows yo! to change one system witho!t affecting the other systems, This ability to limit the
propagation of changes is a key consideration for integration sol!tions where connections can be plentif!l and
making changes to applications can be very diffic!lt,
Ho! achieve abstraction in a n!mber of ways, 8or e&ample, yo! can achieve abstraction by passing self<
contained doc!ments between systems, Passing a doc!ment does not instr!ct another system to perform a
specific f!nction, b!t it leaves that choice to the receiving system, Th!s, if the receiving application processes
the doc!ment in a different way, the originating system is not affected,
2aintaining State
Most integration sol!tions aim to streamline b!siness processes s!ch as placing an order or making a payment,
These processes rely on the coordinated completion of a series of steps, *hen an order arrives, the order has
to be validated, the inventory has to be checked, the sales ta& has to be comp!ted, and an invoice has to be
generated, This type of integration re?!ires some mechanism to track the c!rrent state of an order, 8or
e&ample, the mechanism might indicate whether the order has been validated yet and which step sho!ld be
completed ne&t, This state mechanism can be implemented in three ways:
2anually, State can reside in the !serJs head or in a man!al on the !serJs desk, 1ased on the
information gathered, a !ser can decide which step sho!ld be performed ne&t, This approach is less
efficient and less reliable than more a!tomated sol!tions, b!t it is also very fle&ible and easy to implement,
Inside e.isting applications, The state can be kept inside e&isting applications, 8or e&ample, after
the inventory application has verified the n!mber of items on hand, it can be programmed to send a
message to the financial system to comp!te the sales ta&, The financial system in t!rn might send a
message to the f!lfillment system to ship the goods, This approach is more efficient b!t also ties the
applications more closely to each other,
In an integration layer, Ho! can insert a new integration layer to orchestrate the activities across
m!ltiple applications and to keep track of state, S!ch a layer is likely to re?!ire additional effort, b!t it
manages all interactions from a central point witho!t applications re?!iring information abo!t each other,
Coupling
245450494.doc 46 od 257
Loose co!pling has become the standard of distrib!ted applications, Loose co!pling makes integrated systems
less dependent on each other and allows them to evolve independently, )owever, loose co!pling is not a
panacea, Loosely co!pled systems can often be diffic!lt to !nderstand and deb!g,
Semantic Dissonance
=ne of the key diffic!lties in b!ilding integration sol!tions is the notion of semantic dissonance, This term
describes a sit!ation where data that appears to be the same may not necessarily mean the same thing, 8or
e&ample, one system might treat a monetary fig!re for ann!al reven!es as if it incl!des sales ta&, while
another system treats the monetary fig!re as if it does not incl!de any ta&es, Likewise, one system might
define the *estern %egion, in the conte&t of reven!e breakdown, to incl!de the state of /olorado, Meanwhile,
another system may define /olorado as part of the /entral %egion, These types of semantic dissonance can be
very diffic!lt to detect and reconcile, Some rather elegant types of integration rely on the complete resol!tion of
semantic dissonance, which might not be feasible in real<life sit!ations, =ther simpler forms of integration, s!ch
as Portal +ntegration, can accommodate ambig!ity, b!t they do it at the e&pense of precision, 8or an in<depth
disc!ssion of data modeling and the perils of semantic dissonance, see &ata and /eality, by *illiam 0ent
L0ent44N,
Choosing an Integration %ayer Type
1ased on these considerations, this g!ide identifies three approaches towards integrating layers, -ach approach
is presented as a pattern 'see 8ig!re 6(:
Entity $ggregation
Process Integration
Portal Integration
/igure 11 Three integration approaches
The following paragraphs briefly describe each approach to integration, in order from least to most comple&,
Portal Integration
Portal +ntegration connects systems to provide a !nified view to a !ser, Portal Integration can dramatically
increase prod!ctivity beca!se !sers no longer have to access m!ltiple applications independently, +nstead, they
receive a comprehensive view across all systems in a vis!ally consistent format that is ill!strated in 8ig!re 3,
245450494.doc 47 od 257
More sophisticated versions of Portal Integration also allow the !ser to make !pdates to individ!al systems or
even across m!ltiple systems,
/igure !1 Portal Integration pro7ides a uni&ied 7iew across systems
Portal Integration is often easier to implement than other, more a!tomated alternatives, The disadvantage of
the simplicity is that m!ch of the b!siness process and many of the r!les still reside in a !serJs head as
opposed to in a system, .evertheless, Portal Integration is often a good first step towards integration,
5ntity Aggregation
The main limitation of Portal Integration is that it aggregates information only for end !sers b!t not for
applications, -ntity ggregation addresses this shortcoming by providing a !nified data view to applications, as
ill!strated in 8ig!re ;,
/igure $1 5ntity Aggregation pro7ides uni&ied data access across systems
Entity $ggregation provides a logical representation of !nified data entities across m!ltiple data stores,
pplications can interact with this representation as if it were a single data so!rce, Th!s, Entity $ggregation
greatly simplifies the development of applications that need to access data across m!ltiple data stores, The
245450494.doc 48 od 257
tradeoff for this increased integration is that the integration layer m!st now resolve any instances of semantic
dissonance between the individ!al systems, %esolving s!ch semantic dissonance and creating a !nified data
layer can be a maEor !ndertaking,
Process Integration
Process +ntegration foc!ses on the orchestration of interactions between m!ltiple systems, as ill!strated in
8ig!re 5, s mentioned earlier, a!tomated b!siness processes s!ch as straight<thro!gh processing often drive
integration initiatives, +t is often advisable to model these processes o!tside of the applications to avoid
co!pling the applications to each other, Ho! can achieve this modeling by adding a Process Integration layer
that manages the interaction across applications, This layer tracks the state of each b!siness process instance
and also enables centrali9ed reporting, 8or e&ample, this layer enables the 1!siness ctivity Monitoring '1M(
feat!re of Microsoft 1i9TalkK Server,
/igure '1 Process Integration orchestrates acti7ities across systems
The three integration layer types are not m!t!ally e&cl!sive, n integration sol!tion might !se Portal
Integration for some portions of the sol!tion and Process Integration for others, Management reporting
f!nctions may be accomplished by !sing Entity $ggregation, ll the approaches may be !sed in parallel,
Integration %ayers Patterns
The following table s!mmari9es the three patterns E!st disc!ssed and shows the corresponding implementation
patterns,
Table 1 Integration %ayers Patterns
Pattern Problem Associated implementations
-ntity ggregation )ow can enterprise data that is
red!ndantly distrib!ted across
m!ltiple repositories be effectively
maintained by applicationsC

Process +ntegration )ow do yo! coordinate the
e&ec!tion of a long<r!nning
b!siness f!nction that spans
m!ltiple disparate applicationsC
+mplementing Process +ntegration
with 1i9Talk Server 3445
245450494.doc 49 od 257
Portal +ntegration )ow can !sers efficiently perform
tasks that re?!ire access to
information that resides in
disparate systemsC

5ntity Aggregation

Contents
/onte&t
Problem
8orces
Sol!tion
-&ample
%es!lting /onte&t
Testing /onsiderations
Sec!rity /onsiderations
=perational /onsiderations
0nown $ses
%elated Patterns
Conte.t
-nterprise<level data is distrib!ted across m!ltiple repositories in an inconsistent fashion, -&isting applications
need to have a single consistent representation of key entities which are logical gro!ps of related data elements
s!ch as /!stomer, Prod!ct, =rder, or cco!nt, Moving data between these repositories may not be a viable
option,
Problem
)ow can enterprise data that is red!ndantly distrib!ted across m!ltiple repositories be effectively maintained by
applicationsC
/orces
The following forces have to be considered in this conte&t:
245450494.doc 50 od 257
There may be m!ltiple systems of record for the same entity, 1!siness r!les and processes co!ld
dictate the manner in which the system of record is determined for a given entity, 8or e&ample, an
employee entity is !s!ally defined in h!man reso!rce management system ')%MS( applications, in payroll
applications, and in benefits applications, as well as in other systems, -ach system defines its own view of
an employee, )owever, if yo! are b!ilding an employee self<service portal, yo! need to have a complete
view of what constit!tes an employee and not E!st the bits and pieces,
=ften, semantic dissonance e&ists between the data val!es represented within the same entity across
repositories, The same data element may not represent the same information in m!ltiple repositories, 8or
e&ample, the data element .!mber=fDays%emaining for a proEect task might incl!de all days incl!ding
holidays in one repository, b!t it might incl!de only workdays in another repository,
-ven when the data elements are semantically consistent, the information they represent might vary
across parallel instances of the data element, +n s!ch cases, it may be diffic!lt to determine which instance
of the data element is acc!rate, 8or e&ample, in a financial instit!tion where there are dedicated
repositories for vario!s c!stomer comm!nication channels, the vailable 1alance entity in one repository
may not be the same as the vailable 1alance in another repository, 8or e&ample, the vailable 1alance in
the TM database may not be the same as the vailable 1alance in the repository serving the online
banking channel,
+nvalid data might have crept in thro!gh other entry points into the repositories, ll the entry points
may not enforce all the b!siness and data validation r!les in a consistent fashion, This is typical of
mainframe systems where the validation logic enforced in the screens may be o!tdated and therefore not
enforced in the enterpriseJs newer applications,
%eferential integrity of data across m!ltiple repositories may have been violated, This happens d!e to
absent or malf!nctioning data synchroni9ation processes, +n a man!fact!ring environment, it is critical that
the prod!ct data management 'PDM( system always be conc!rrent with the order management system,
=rders entered in the order management system that have an invalid reference to a prod!ct can violate
the referential integrity of the prod!ct data across the respective repositories,
pplications may need logical s!bsets of the data elements that may not be available in a single
repository, Therefore, b!siness logic may have to be applied to properly gro!p the data elements into the
logical s!bset, 8or e&ample, a banking c!stomer maintains different kinds of information across vario!s
repositories, Personal information is stored in the c!stomer information file repository# acco!nt balance is
stored in a financial application repository# and loan information is stored in the mortgage lending
repository, *hen the c!stomer accesses the online banking site, the nat!re of the c!stomerJs re?!est
determines the s!bset of the information to be presented, n address change re?!est needs data from the
c!stomer information file repository, b!t an in?!iry on the o!tstanding balance for all acco!nts and loans
re?!ires specific data from all three repositories,
Data synchroni9ation processes may already e&ist between repositories that permit one repository to
act as a front end to the other, +n these cases, the synchroni9ation mechanism is better left !nto!ched,
This is typical where database replication is !sed across two separate database instances that !se the
same !nderlying technology,
Solution
+ntrod!ce an Entity $ggregation layer that provides a logical representation of the entities at an enterprise level
with physical connections that s!pport the access and that !pdate to their respective instances in back<end
repositories,
This representation is analogo!s to the Portal +ntegration pattern, which presents to the end !ser a !nified view
of information that is retrieved from m!ltiple applications, Similar to the portal layer that provides this view for
the application front ends, the Entity $ggregation layer provides a similar view across the data in the back<end
repositories as shown in 8ig!re 6,
245450494.doc 51 od 257
/igure 11 5ntity Aggregation
-stablishing Entity $ggregation involves a two<step process:
6, Defining the enterprise<wide representation that provides a consistent !nified representation of the
entity,
3, +mplementing a physical bidirectional connection between this representation and its respective
instances in the back<end repositories,
The following e&ample e&plains this process in more detail,
/igure !1 5n7ironment without 5ntity Aggregation
8ig!re 3 shows two applications that access their respective back<end repositories for information abo!t the
Phone .!mber entity within two different enterprises: $,S, -nterprise and the -!rope, Middle -ast, and sia
'-M-( -nterprise, 1oth applications maintain the information abo!t the phone n!mber within their respective
repositories,
245450494.doc 52 od 257
-ach application follows the respective domestic convention for representing phone n!mbers in its back<end
repository, The $,S, representation of the entity incl!des the area codes, the e&changes, and the n!mbers, The
-M- representation, on the other hand, represents the same information !sing the co!ntry code, the city
code, the e&change, and the n!mber,
s part of a merger and ac?!isition e&ercise, these enterprises merge to form a new logical enterprise, 1oth
applications have to access the information in both repositories, Therefore, the phone n!mber now has to be
represented at an enterprise<wide level that incl!des both the $,S, and the -M- b!siness !nits,
/igure $1 5n7ironment with 5ntity Aggregation
8ig!re ; shows the manner in which Entity $ggregation can facilitate the seamless representation of the Phone
.!mber entity across both repositories,
The first step in establishing this layer involves defining the enterprise<wide representation of the Phone
.!mber entity,
The Phone .!mber entity within the Entity $ggregation layer incl!des attrib!tes that are !ni?!e to each
enterprise, The Phone .!mber entity also incl!des attrib!tes that are common across both enterprises, Th!s,
/o!ntry /ode is incl!ded beca!se it is an attrib!te !ni?!e to the -M- enterprise, Similarly, beca!se -&change
and .!mber are common attrib!tes across both repository instances, they are also incl!ded, -ven tho!gh rea
/ode and /ity /ode are !ni?!e to each enterprise, their basic representation and p!rpose is identical,
245450494.doc 53 od 257
Therefore, the Entity $ggregation layer representation chooses to incl!de the rea /ode while !sing this field to
store the /ity /ode information from the -M- repository,
The ne&t step involves b!ilding the physical connections between the Entity $ggregation layer and the back<end
$,S, and -M- repositories, The technology driving these connections depends on the repository being
accessed,
Approach
There are two architect!ral approaches to implementing Entity $ggregation:
Straight<thro!gh processing
%eplication
Depending on the architect!ral characteristics of the entity instances to be integrated, a combination of these
approaches may be re?!ired,
Straight4Through Processing
straight<thro!gh processing approach fetches information from the respective back<end repositories in real
time and correlates the information into a single !nified view, This implies that the Entity $ggregation layer has
real<time connectivity to the repositories and sho!ld be able to associate the disparate instances of the entity,
Replication
The replication of entities for !se by the Entity $ggregation layer is re?!ired when the following conditions are
tr!e:
%eal<time connectivity to the repositories is absent,
/omplicated Eoins across m!ltiple instances of the same entity across vario!s repositories is re?!ired
to provide a consistent representation,
)igh performance is vital to the sol!tion,
This approach re?!ires a separate physical repository within the Entity $ggregation layer that stores data
conforming to the enterprise<wide representation of the entity, The data in each back<end repository is
replicated into the Entity $ggregation repository, This replication re?!ires the implementation of s!pporting
processes to enforce the b!siness r!les that validate the data being replicated, %eplication sho!ld be performed
both ways between the back<end repositories and the Entity $ggregation repositories,
+n many respects, this approach offers capabilities very similar to those s!pported by a data wareho!se, Data
wareho!ses originally were b!ilt with the intent of s!mmari9ing transactional data that co!ld be !sed for
b!siness intelligence and trends analysis, +n many large enterprises today, data wareho!ses have transformed
into yet another repository within the enterprise, They do not always serve as the enterprise<wide !nified
representation of the data, )owever, s!ch data wareho!ses have a good baseline definition for enterprise<level
entities, and the enterprise<wide representation of an entity can be b!ilt on top of this definition,
245450494.doc 54 od 257
Design Considerations
-ffective design of an Entity $ggregation layer re?!ires several iss!es to be given d!e consideration, These
iss!es may be broadly classified as follows:
Data representation, Data representation incl!des entity representation and sc"ema reconciliation,
-ntity representation is the definition of the enterprise<wide representation of the entity with its attrib!tes
and key relationships to other entities, Schema reconciliation involves reconciling the varied definitions of
the !nderlying schema across repositories, +n addition to the data representation being defined, the format
in which the representation is stored m!st be established as well,
Data identi&ication, +ntrod!ction of a new layer of data representation re?!ires the establishment of
an appropriate mechanism that !ni?!ely identifies each entity across all repositories, incl!ding the Entity
$ggregation layer itself, n entity reference is one s!ch mechanism,
Data operation, Data operation incl!des the manner in which transactional operations are performed
on the data, This incl!des /reate, %ead, $pdate, and Delete '/%$D( actions, and it incl!des any
compensatory meas!res thereof, 8or more information abo!t this consideration, see @+n?!iry vs, $pdate@
later in this pattern,
Data go7ernance, Data governance involves establishing ownership of ongoing maintenance and
establishing c"ange management processes to direct the ongoing maintenance of entities and their data
elements, These processes also help refine the integration re?!irements by rationali9ing the n!mber of
data repositories, if necessary,
-ach of these iss!es is o!tlined in the following sections,
5ntity Representation
There are several approaches that co!ld be adopted to defining the enterprise<wide representation of the entity,
-ntity representations may have to be c!stom developed to address the specific needs of the enterprise as
whole, This may be the only viable option !nder the following circ!mstances:
-&isting representations within the enterprise represent only a small portion of the enterprise<wide
representation of the entity and are not readily e&tensible to accommodate the needs of the enterprise,
/haracteristics that are !ni?!e to the enterprise cannot be properly reflected within any e&ternal
representations of the entity,
)owever, c!stom representations are not always a financially viable option beca!se they re?!ire a regeneration
of the e&isting entities and their relationships,
+nstead, a representation that is foreign to all the applications within the enterprise may be a viable approach
as long as it still conforms to the core b!siness processes, Ho! co!ld also !se c!rrent representations that are
specific to certain ind!stries for this p!rpose, +n other words, embracing an e&ternal representation does not
necessarily entail the additional e&pense of proc!ring an application,
+n other cases, yo! co!ld choose the representation s!pported by one of the e&isting applications within the
enterprise, -%P and /%M applications that s!pport and drive the b!siness processes for the enterprise are
prime candidates for this approach,
*hile Entity $ggregation is all abo!t having a single view of entities across the enterprise, entity
representations within this layer might have to be adE!sted to represent the n!ances of individ!al b!siness
245450494.doc 55 od 257
!nits, This is especially tr!e for large international conglomerates that have been forced into being a logical
enterprise thro!gh ac?!isitions and mergers of other enterprises that operate as a!tonomo!s b!siness !nits,
%eaching a consens!s on the representation within any one of these !nits can be a challenge, Therefore,
reaching a similar consens!s across all of these !nits can be an ambitio!s goal, if not an impossible one, +n
these cases, m!ltiple representations 'one for each operating !nit( might be a more realistic and practical
approach,
Schema Reconciliation
-ven if the enterprise reaches consens!s on the entity representation, the representation within each instance
of the entity may still vary across different repositories, Different repositories can hold different schemas for the
same entity, The Entity $ggregation layer m!st harmoni9e the s!btle differences between these schemas in the
following ways:
-ntity ggregation m!st acco!nt for the representation of all entities held within the different
repositories,
-ntity ggregation m!st define a !nified schema for all entities which represents a logical consolidation
of all the views,
-ntity ggregation m!st effect transformations between each repositoryJs schema and the !nified
schema,
,ote Sometimes, the term canonical schema is !sed instead of !nified view, This pattern !ses the latter term,
beca!se canonical schema implies that all the representations share the same schema, which is not always
necessary,
8ig!re 5 shows an e&ample of c!stomer information that is represented in more than one repository, ltho!gh
the contact repository defines the contact information for a c!stomer, the financial repository defines the credit
card details for the c!stomer, The Entity $ggregation layer defines a !nified schema that contains all the
attrib!tes re?!ired for representing the c!stomer entity, The Entity $ggregation layer also defines the mapping
between the !nified schema and those schemas held by the individ!al repositories,
245450494.doc 56 od 257
/igure '1 Schema reconciliation
Re&erences
-ntity reference is the information re?!ired to !ni?!ely identify an entity, %epositories that store instances of a
given entity tend to maintain their own !ni?!e identifiers for their respective instances to ens!re they have f!ll
control over internal data consistency, The Entity $ggregation layer sho!ld acco!nt for this and sho!ld be able
to map references that point to a single instance, part from references that are held by other repositories, the
Entity $ggregation layer might create its own reference for an entity instance, The idea here is that the Entity
$ggregation layer maintains its own reference to an entity instance and maps this reference to the individ!al
repositoryJs reference, This red!ces the co!pling between the Entity $ggregation layer and individ!al
repositories beca!se new repositories can be introd!ced witho!t affecting the Entity $ggregation layerJs !nified
view,
2aster Re&erence
Entity $ggregation layer !ni?!ely identifies an entity instance by !sing a reference known as a master
reference, master reference co!ld be:
reference held by one of the repositories, 8or e&ample, yo! can designate the reference held by a
/%M repository as the master reference for a c!stomer entity,
new reference that the Entity $ggregation layer creates for the entity instance and maps to other
references held by different repositories,
245450494.doc 57 od 257
In0uiry 7s1 "pdate
The technological sol!tions available today are more rob!st for in?!iring than they are for !pdating data in the
back<end repositories, $pdating has the inherent challenges of maintaining the synchrony of data across
repositories,
,ote +n the conte&t of this pattern, deleting an entity is considered to be a form of !pdate,
n !pdate re?!est !s!ally contains two elements: a reference that !ni?!ely identifies the instance and an
!pdate payload that contains information abo!t the !pdated attrib!tes and their respective val!es,
The Entity $ggregation layer !ses entity references across all the repositories to perform the in?!iries and
!pdates, ltho!gh the Entity $ggregation layer maintains the entity reference0 the references that are !ni?!e to
each repository have to be determined before the !pdate is made to the back<end repositories, 8or more
information, see @%eferences,@
Compensation
The process of performing a compensating action can be man!al or a!tomatic, 1!siness process owners have a
strong infl!ence on the manner in which compensating actions sho!ld be implemented,
+f one of the systems fails to handle the !pdate re?!est, the Entity $ggregation layer sho!ld be able to handle
this b!siness e&ception by !sing one of the following approaches:
%e?!est a rollback on all the other !pdates that have already been made,
%!n a compensating transaction to reverse the effects of the s!ccessf!l !pdates that were already
completed,
=wnership
ltho!gh the Entity $ggregation layer represents the !nified view of an entity, it is certainly possible to store
different fragments of an entity in different systems, Therefore, the system of record is not the same for all
fragments,
8or e&ample, employee information co!ld be distrib!ted across the payroll and benefits repositories, +t is also
possible that some information may be owned by m!ltiple systems, 8or e&ample, attrib!tes s!ch as Last.ame
and 8irst.ame are probably represented in more than one system, +n this case, the Entity $ggregation layer
sho!ld designate a system as an aut"oritati!e source for attrib!tes that are represented in more than one
system,
This has several implications for the behavior that occ!rs d!ring in?!iries and !pdates, ttrib!tes will always be
fetched from the a!thoritative so!rce, +f the same attrib!te is represented by another system, those val!es will
be ignored by the Entity $ggregation layer, $pdates, on the other hand, have different semantics, *hen the
Entity $ggregation layer receives an !pdate re?!est for an entity, the !pdates sho!ld be propagated to all the
constit!ent systems of record,
245450494.doc 58 od 257
Change 2anagement
Processes have to be p!t in place to coordinate changes across all the repositories and the Entity $ggregation
layer, +n addition to ens!ring active participation from the different b!siness process owners and information
technology '+T( representatives for each repository, a key step in this process is to ens!re that the integrity of
the enterprise<wide representation of the entity is not compromised,
Three types of changes to the !nderlying repositories can directly and significantly affect the Entity $ggregation
layer:
Con&iguration, The repository config!ration co!ld !ndergo changes, This wo!ld incl!de redeployment
of the repository to a new physical location or to a different server, /onfig!ration parameters s!ch as the
sched!led downtime for maintenance co!ld affect connectivity to the Entity $ggregation layer as well, +n
an ideal environment, only the Entity $ggregation layer is directly affected by this change beca!se
connections between repositories !s!ally do not e&ist, )owever, the other repositories co!ld be indirectly
affected by these changes thro!gh their connectivity to the Entity $ggregation layer,
Data model, The data model co!ld !ndergo changes within the repository, The enterprise<wide
representation of entities s!pported by the Entity $ggregation layer is significantly affected by these
changes, =ther repositories that store information in the same domain are affected also,
Data 7alues, /hanges to transactional data in a repository have the least impact, if any, on the Entity
$ggregation layer and on other repositories, )owever, changes to reference data that spans repositories or
to reference data that is !sed by the Entity $ggregation layer have a significant impact,
5.ample
8ig!re A shows a scenario where the Stock Trade entity is partitioned across systems based on geographical
constraints, pplications that analy9e the trends in a given ind!stry re?!ire a complete view of the trades
across geographical bo!ndaries and systems,
The Entity $ggregation layer consolidates the view across geographical bo!ndaries so that the partitioning of
data across the repositories is transparent to the applications that perform trends analysis,
/igure (1 Stoc- trades scenario
Resulting Conte.t
245450494.doc 59 od 257
Entity $ggregation has the following benefits and liabilities:
#ene&its
Consensus, Entity $ggregation forces consens!s across b!siness and f!nctional !nits on the manner
in which entities are represented at an enterprise<level,
Single 7iew, Entity $ggregation enables a single view of key b!siness entities s!ch as /!stomer,
cco!nt, Prod!ct, and 'in the case of healthcare( Patient,
Impro7ed access to in&ormation, n enterprise<level view of key b!siness entities enables
applications to have immediate access to the information pertinent to these entities, ccess to information
is not constrained by the repositories that ho!se them,
Reduced semantic dissonance, Entity $ggregation eliminates semantic dissonance across e&isting
applications that work on the same data elements from m!ltiple repositories,
Central location, Entity $ggregation s!pports a central location for validating data that is pop!lated
into the repositories,
Reduced change impact, Entity $ggregation red!ces the potential impact of changes to the back<
end repositories, Depending on the nat!re of the changes being made, the Entity $ggregation layer can
contin!e to serve the needs of the applications while these changes are in progress,
%iabilities
Additional layer, Entity $ggregation introd!ces an additional architect!ral layer that co!ld adversely
affect end<to<end performance of the sol!tion,
Consensus, Entity $ggregation re?!ires consens!s across b!siness !nits on the definition of the
enterprise<wide representation of entities,
Reengineering applications, -&isting applications that are tightly co!pled to a given set of
repositories wo!ld have to be reengineered to accommodate the new architect!ral layer, dditionally, it is
not always possible to reengineer some applicationsIespecially packaged sol!tions,
Testing Considerations
The following testing considerations apply when adding an Entity $ggregation layer:
Depending on the degree to which the Entity $ggregation layer is adopted, all valid combinations of
applications and their back<end repositories wo!ld have to be regression tested,
-&isting test cases may have to be revised to reflect the b!siness r!les being e&ercised in the Entity
$ggregation layer,
Test data available within a given repository m!st be rep!rposed to accommodate the enterprise<wide
representation of entities in the Entity $ggregation layer,
Sim!ltaneo!s connectivity from the Entity $ggregation layer to all the back<end repositories has to be
tested, +n the absence of Entity $ggregation, connectivity wo!ld have been a re?!irement only between
the vario!s application<repository pairs,
Security Considerations
The Entity $ggregation layer is effective at providing access to information that is pertinent to b!siness entities
at an enterprise level, )owever, applications might be able to obtain access to repositories that may not have
been available prior to the introd!ction of the Entity $ggregation layer, -ven tho!gh applications might still
operate on the same data elements, they might access new repositories thro!gh the Entity $ggregation layer,
ccess privileges for vario!s roles within these applications have to be managed at the Entity $ggregation layer,
=perational Considerations
245450494.doc 60 od 257
There are two separate operational aspects to the Entity $ggregation layer:
The Entity $ggregation layer has to be operated and monitored as a repository that ho!ses the
enterprise<wide representation of entities, Less maintenance of the !nderlying data in the Entity
$ggregation layer is re?!ired for the straight<thro!gh processing sol!tion than for the replication sol!tion,
+n the replication sol!tion, the operational aspects that apply to the data in the repositories also apply to
the Entity $ggregation layer, +n either case, similar operational aspects apply if the Entity $ggregation layer
maintains the entity references that are e&ternal to all the repositories,
.etwork connectivity between the applications and the Entity $ggregation layer and network
connectivity between the Entity $ggregation layer and the repositories are critical components of the
overall sol!tion, The straight<thro!gh processing sol!tion, in partic!lar, re?!ires conc!rrent connectivity to
all the repositories,
6nown "ses
-nterprise +nformation +ntegration is another ind!stry term that is !sed to identify the enterprise<wide
representation of a logical data model that ho!ses the key b!siness entities that have bidirectional physical
connections to the back<end repositories where data is stored,
Some companies provide a logical metadata modeling approach that allows enterprises to re!se models and
data for real<time aggregation and caching with !pdate synchroni9ation, These companies initially provided
?!ery<only capability, b!t they are slowly beginning to s!pport bidirectional transfer of data between the Entity
$ggregation layer and the back<end repositories,
Related Patterns
"iven that the Entity $ggregation layer provides a view of data that is distrib!ted across repositories, Data
+ntegration is closely related to this pattern,
Process Integration

Contents
/onte&t
Problem
8orces
Sol!tion
-&ample
%es!lting /onte&t
Testing /onsiderations
%elated Patterns
245450494.doc 61 od 257
cknowledgments
Conte.t
Ho! have m!ltiple disparate systems, and each of those systems is part of an overall b!siness f!nction, 8or
e&ample, a b!siness f!nction s!ch as processing an incoming order may re?!ire the participation of the
c!stomer management system, the inventory system, the shipping system, and one or more financial systems,
The b!siness co!ld operate more efficiently if the systems co!ld be integrated so that the b!siness f!nction
co!ld be completed a!tomatically,
Problem
)ow do yo! coordinate the e&ec!tion of a long<r!nning b!siness f!nction that spans m!ltiple disparate
applicationsC
/orces
To solve this problem, yo! have to balance the following considerations and forces:
To implement the overall b!siness f!nction, yo! co!ld have one system directly call the system that
performs the ne&t step, as defined in the b!siness f!nction, )owever, this approach encodes the se?!ence
of interactions into the individ!al systems, /reating this dependency in each system makes changing the
se?!ence more error<prone and also limits yo!r ability to re!se systems in m!ltiple conte&ts,
The change and maintenance cycle of a comple& b!siness f!nction is likely to be different from the
change cycle of the individ!al b!siness f!nctions that reside inside the applications, 8or e&ample, financial
f!nctions s!ch as comp!ting sales ta& or posting reven!es are typically s!bEect to infre?!ent, b!t
mandatory, legal or reg!latory changes, +n contrast, the overall e&ec!tion of a b!siness f!nction might be
changed m!ch more fre?!ently based on b!siness and marketing strategies,
/omple& b!siness f!nctions can often take days or weeks to complete, )owever, most f!nctions that
are available in e&isting applications are synchrono!s# that is, the caller has to wait while the application
performs the re?!ested f!nction, This type of synchrono!s interaction is not well<s!ited to long<r!nning
b!siness f!nctions beca!se one application co!ld spend a significant amo!nt of time waiting for another
application to complete the re?!ested f!nction,
longer time span of e&ec!tion increases the likelihood that an application might fail d!ring the
e&ec!tion of the b!siness f!nction, +f one application fails, portions of the overall f!nction may have to be
reverted so that all systems can be ret!rned to a consistent state,
1eca!se a comple& b!siness f!nction can take a long time to e&ec!te, it is likely that a new re?!est
will arrive while the previo!s one is still being serviced, To improve response times, the sol!tion sho!ld be
able to handle m!ltiple conc!rrent e&ec!tions of the f!nction, Many applications are not designed for this
type of conc!rrent e&ec!tion,
Modeling b!siness processes inside a software component can be diffic!lt if the processes are not well
!nderstood or doc!mented, +n many b!sinesses, !sers make decisions based on e&perience rather than
doc!mented b!siness r!les,
Solution
Define a b!siness process model that describes the individ!al steps that make !p the comple& b!siness
f!nction, /reate a separate process manager component that can interpret m!ltiple conc!rrent instances of this
model and that can interact with the e&isting applications to perform the individ!al steps of the process,
245450494.doc 62 od 257
/igure 11 Process Integration with a process manager component directing applications according to
a process model
8or each incoming re?!est for the b!siness f!nction, the process manager creates a new process instance
based on the process model, -ach instance maintains the c!rrent state of the process pl!s any additional
information that is needed for the b!siness process to contin!e, /reating individ!al process instances allows the
process manager to e&ec!te many b!siness f!nctions in parallel,
fter one application completes its b!siness f!nction, the process manager determines which f!nction to
e&ec!te ne&t based on the state of the process instance, Therefore, each participating application can operate
individ!ally witho!t any knowledge of the se?!ence of steps defined in the process model,
The process manager maintains this state even if a specific application is temporarily !navailable, s a res!lt,
the overall e&ec!tion of the b!siness f!nction is not stopped if a specific application is temporarily !navailable,
+nstead, the b!siness f!nction can contin!e after the application is back online,
The process manager interacts with the individ!al applications by way of Data +ntegration, 8!nctional
+ntegration0 or Presentation +ntegration, depending on the nat!re of the interaction and the architect!re of the
application, Therefore, Process Integration resembles a composite application b!ilt on top of e&isting b!siness
f!nctions that reside in e&isting applications,
Process Integration provides a clean separation between the definition of the process in the process model, the
e&ec!tion of the process in the process manager, and the implementation of the individ!al f!nctions in the
applications, This separation allows the application f!nctions to be re!sed in many different processes,
245450494.doc 63 od 257
The separation of process model and process manager also allows the process manager to be domain
independent beca!se it only has to interpret the basic constr!cts that form a process model, These constr!cts
manage the parallel e&ec!tion of m!ltiple steps, and they typically comprise se?!ences, decision points, forks,
and Eoins, $sing these constr!cts, enterprises can create a model at the b!siness level witho!t having to
!nderstand the internals of the process manager or the individ!al applications,
Process Integration involves collaboration between the components that are described in Table 6,
Table 1 Process Integration Components
Component Responsibilities Collaborations
Process model Defines the se?!ence of steps that make !p the
b!siness f!nction,
The process manager interprets the
process model in separate process
instances,
Process manager < Manages m!ltiple instances of the process
model and their c!rrent state,
< Maps the steps defined in the process model
to the b!siness f!nctions that reside in the
applications,
< +nterprets the process model,
< Directs applications thro!gh steps
according to the process model,
pplication -&ec!tes a specific b!siness f!nction, .one,
The process manager typically e&poses an e&ternal interface so that the b!siness process defined by the
process model can be initiated by a !ser, by b!siness partners, or by another application, /orrespondingly, the
interface can take the form of a !ser interface or the form of an application programming interface 'P+( that
can be made available to other applications by !sing Functional Integration0 making it essentially
indisting!ishable from a simple application, Therefore, this b!siness process can be !sed as part of another
overarching b!siness process that is defined !sing a higher<level process model, s a res!lt, process managers
and applications can be linked in a rec!rsive fashion, 8ig!re 3 shows a hierarchy of process managers and
applications,
245450494.doc 64 od 257
/igure !1 3ierarchy o& process managers and applications
Implementation Details
t first glance, the process manager resembles a traditional application that implements b!siness logic, The
only difference is that the process manager takes advantage of f!nctions implemented in e&isting systems,
)owever, the fact that the e&ec!tion of the b!siness f!nction can take ho!rs or days places specific
re?!irements on the process manager, Specifically, a process manager typically m!st be able to:
/orrelate messages from e&ternal systems with the instance of the b!siness process they are intended
for,
S!pport long<r!nning transactions,
)andle e&ceptions raised by individ!al steps in the b!siness process, and take appropriate action in
the event of these e&ceptions,
Provide compensation logic to !ndo actions committed earlier in the b!siness process if a fail!re occ!rs
in the b!siness process,
Correlating 2essages and Process Instances
=rchestration of processes involves messages sent to e&ternal systems and received from e&ternal systems,
These e&ternal systems implement the actions that make !p the b!siness process, t any time, there are likely
to be many instances of the b!siness process r!nning at once, and any message that is received m!st be
correlated with the correct instance of the b!siness process that it was intended for,
Transactions
Transactions provide encaps!lation of individ!al atomic actions, transaction is an action or a series of actions
that transform a system from one consistent state to another, *hen dealing with long<r!nning b!siness
245450494.doc 65 od 257
f!nctions, it is !sef!l to disting!ish between two kinds of transactions: atomic transactions and long<r!nning
transactions, *hen yo! !se Process Integration0 yo!r design m!st s!pport both kinds of transactions,
tomic transactions are the same kind of transactions as those fo!nd in databases, They adhere to a set of
properties, commonly called the tomicity, /onsistency, +solation, and D!rability '/+D( properties, This type of
transaction re?!ires transactional reso!rces, s!ch as a database !pdate or the sending of a message, that
permit yo! to a!tomatically roll back changes if the transaction is stopped, tomic transactions are s!ited only
for short<r!nning portions of the overall process,
Long<r!nning transactions are !sed when one or more of the following conditions are tr!e:
The transactions m!st occ!r over an e&tended time period, and the transaction cannot be s!pported
by atomic transactions,
The actions involved in the transaction are not themselves transactional, b!t yo! want to gro!p these
actions into more gran!lar atomic !nits of work that can e&ist across time, organi9ations, and applications,
=ther transactions are gro!ped within a transaction, 1oth atomic and long<r!nning transactions may
be gro!ped in a long<r!nning transaction, b!t other transactions cannot be gro!ped in an atomic
transaction,
8or long<r!nning transactions, yo! m!st allow the !ser to stop the process mid<stream, *hen the process
stops, the system will persist data regarding the completed actions and the intermediate states, fter the
process restarts, the application will reload this intermediate state to allow the process to contin!e from the
point where it stopped,
3andling 5.ceptions and Compensating Transactions
*hen e&ternal applications are invoked to implement a specific action, a variety of errors can occ!r, These
errors ca!se error codes to be sent in messages that are ret!rned by the e&ternal systems, and these errors
ca!se e&ceptions to be thrown,
Stat!s code errors can be handled by conditional logic inside the process model, This approach is nat!ral, b!t
can lead to an !nwieldy control flow if all possible error conditions have to be covered, -rrors in the form of
e&ceptions can be handled by e&ception handlers attached to the scope in which the e&ception occ!rred, This
scope can be the entire process model, or it can be a specific s!bsection, +f an e&ception occ!rs within this
scope, the e&ception handler is a!tomatically invoked witho!t the process designer having to e&plicitly model
each individ!al error condition,
Some of these errors re?!ire the application to revert the transaction state to the state before the long<r!nning
transaction started, *hen these errors occ!r, the application iss!es a compensating transaction,
5.ample
Process Integration is commonly !sed to streamline the e&ec!tion of a se?!ence of tasks, =ne pop!lar
application in the financial ind!stry is the notion of straight<thro!gh processing 'STP(, STP describes the
a!tomated end<to<end processing of transactions s!ch as trades from inception to settlement,
245450494.doc 66 od 257
s described in the sol!tion section, Process Integration can also be !sed to provide an aggregate service to
other applications, 8or e&ample, consider a service that makes conc!rrent !pdates to m!ltiple data so!rces as
defined in -ntity ggregation, The implementation of s!ch a service re?!ires Process Integration internally to
manage transactional integrity, partial fail!re sit!ations, and compensation actions,
Process Integration is s!ch a common need that standards committees and working gro!ps are defining
standard lang!ages to describe process models, -&amples of s!ch lang!ages are:
1!siness Process Modeling Lang!age '1PML(
1!siness Process -&ec!tion Lang!age '1P-L(
*eb Services /horeography +nterface '*S/+(
Resulting Conte.t
Process Integration res!lts in the following benefits and liabilities:
#ene&its
2aintainability, /reating a separate process integration layer allows !sers to define and maintain the
b!siness process independent from the implementation of the individ!al f!nctions, This increases
maintainability and red!ces the skill set re?!irements for the personnel who maintain the process
definition,
Reusability, 1eca!se the e&isting applications are not dependent on the process management layer,
the f!nctions inside these applications can be re!sed in m!ltiple process definitions,
/le.ibility, The process manager can s!pport a variety of config!rations that wo!ld be diffic!lt to
implement in many traditional programming models, 8or e&ample, parallel e&ec!tion of m!ltiple tasks,
synchroni9ation points, timeo!ts, and escalations are all config!rations that wo!ld be diffic!lt to implement
in a traditional programming model, S!pporting a variety of config!rations gives the process manager the
fle&ibility to adapt to many different b!siness re?!irements,
Reporting capability, 1eca!se the process instances are maintained centrally, it becomes feasible to
e&tract statistical information that spans m!ltiple process steps and process instances, S!ch reports can
provide answers to ?!estions s!ch as @)ow long does it take on average to f!lfill an orderC@ or @)ow many
orders are on hold d!e to ins!fficient inventoryC@ This type of reporting can be instr!mental in making
informed b!siness decisions,
%iabilities
Potential bottlenec-, Managing a large n!mber of process instances in a central process manager
component can present a r!n<time bottleneck, )owever, in most cases, the parallel e&ec!tion of m!ltiple
process manager instances can alleviate this threat while maintaining the benefit of central config!rability,
Temptation to o7eruse, This liability is the flip side of the fle&ibility inherent in Process Integration
sol!tions, 1eca!se Process Integration can be !sed to solve nearly any integration problem, some people
take this as an indication that each and every integration problem sho!ld be solved !sing Process
Integration, This is not tr!e, $sing Process Integration frivolo!sly can lead to overarchitected and
sometimes inefficient sol!tionsIfor e&ample, in cases where a Message )ro'er wo!ld be perfectly
appropriate to address the re?!irements,
Comple.ity, generic process manager can be diffic!lt to b!ild beca!se it has to deal with
conc!rrency, checkpoints, and recoverability, 8or these reasons, a commercial process manager sho!ld be
!sed whenever possible, +f a commercial component is not available, the cost of b!ilding the process
manager sho!ld be caref!lly weighed against the cost of making changes to the process model,
Testing Considerations
245450494.doc 67 od 257
Separating the process definition from the f!nctions provided by the applications allows yo! to test each
f!nction individ!ally by creating a simple test driver that only calls one specific f!nction and that verifies the
res!lts, as shown in 8ig!re ;,
/igure $1 Test dri7er
Likewise, yo! can test the process manager by creating placeholder implementations, or stu%s, of the act!al
services while providing test triggers to the process manager 'see 8ig!re 5(,
/igure '1 "sing stubs to test the process manager
Related Patterns
8or more information, see the following related patterns:
+mplementing Process +ntegration with 1i9Talk Server 3445, This pattern !ses the "lobal 1ank
scenario to show how yo! can !se 1i9Talk Server 3445 to implement Process +ntegration,
Process Manager pattern L)ohpe45N, Process Manager describes the internal f!nction and
implementation of the process manager component,
Ac-nowledgments
245450494.doc 68 od 257
L)ohpe45N )ohpe, "regor# 1obby *oolf, Enterprise Integration Patterns1 &esigning0 )uilding0 and &eploying
Messaging Solutions, ddison<*esley, 3445,
L%!h46N %!h, *illiam, Enterprise $pplication Integration. $ 2iley Tec" )rief, *iley, 3446,
Implementing Process Integration with #i>Tal- Ser7er !<<'
Contents
/onte&t
1ackgro!nd
+mplementation Strategy
-&ample
%es!lting /onte&t
Testing /onsiderations
Sec!rity /onsiderations
=perational /onsiderations
%elated Patterns
cknowledgments
Conte.t
Ho! are developing new sol!tions that re!se f!nctionality provided by e&isting applications and systems in yo!r
enterprise, The individ!al mechanisms to integrate with each of these applications have already been defined,
so now yo! !se Microsoft 1i9Talk Server 3445 to implement Process +ntegration to coordinate and manage the
overall interaction between all these systems,
#ac-ground
"lobal 1ank is developing new banking sol!tions, incl!ding an electronic bill payment system, "lobal 1ank
wants to enable c!stomers to sched!le payments from their acco!nts, These sched!led payments will be batch<
processed daily by the bankJs systems,
The application to be b!ilt, which processes the c!stomerJs sched!led payments '-&ec!te Sched!led Payments
!se case(, will re!se f!nctionality s!pplied by vario!s bank systems incl!ding the Microsoft SBL Server
database, vario!s *eb services, and the Microsoft )ost +ntegration Server interface to the bank mainframe 'see
245450494.doc 69 od 257
Implementing Gateway wit" .ost Integration Ser!er 3445(, The -&ec!te Sched!led Payments application will
also interact with internal, e&ternal, and man!al payment systems,
"lobal 1ank has already defined the individ!al integration mechanisms for each of these applications and
systems, .ow "lobal 1ank wants to !se 1i9Talk Server 3445 orchestration to manage interactions across all the
systems that constit!te the composite electronic bill payment b!siness process,
1i9Talk Server orchestration is a good choice for describing comple& process models, =rchestration is a ,.-T
8ramework lang!age, E!st like /S and Microsoft :is!al 1asicK ,.-T, =rchestration provides programming
constr!cts s!ch as loops, decision statements, program scope, transactions, and e&ception processing
semantics, =rchestrations are compiled to prod!ce ,.-T 8ramework common lang!age r!ntime '/L%( libraries
that are hosted by the 1i9Talk Server r!ntime, The 1i9Talk Server r!ntime essentially acts as an application
server for long<r!nning b!siness applications,
Implementation Strategy
"lobal 1ank developers have already implemented the individ!al integration mechanisms re?!ired to interact
with each of the systems that are involved in the -&ec!te Sched!led Payments sol!tion, Ho! now define a
process model that describes the se?!ence of steps that make !p the overall application, This process model is
defined and implemented as a 1i9Talk Server orchestration, 8ig!re 6 shows the relationship between the
orchestration 'the process model(, the e&isting systems, and the 1i9Talk Server r!ntime 'the process manager(,
/igure 11 #i>Tal- Ser7er orchestration directing applications according to a process model
To develop the -&ec!te Sched!led Payments application, yo! !se 1i9Talk =rchestration Designer to define the
process model, =rchestration Designer presents a vis!al design and development environment that defines the
245450494.doc 70 od 257
process flow separately from the implementation of the individ!al steps in the process, Ho! then link each
action in the process flow with the implementation of that action, The implementation is !s!ally represented as
an interaction with an application that is e&ternal to the orchestration itself,
-ach incoming re?!est to e&ec!te a payment creates a new instance of the -&ec!te Sched!led Payments
orchestration, These orchestration instances r!n in parallel, maintain their own state, and maintain any
additional information that is needed for e&ec!tion, The orchestration engine !ses the orchestration to
determine the e&ternal applications to invoke and the se?!ence in which to call them, The e&ternal applications
are invoked synchrono!sly or asynchrono!sly depending on the nat!re of the interaction and the architect!re of
the e&ternal application, 8or e&ample, an e&ternal application is invoked synchrono!sly when !pdating stat!s
information in the database and asynchrono!sly when sending payment re?!ests to e&ternal systems,
To completely model a process, an orchestration m!st do more than invoke each of the e&ternal applications in
se?!ence, The orchestration m!st be able to do the following:
/orrelate messages from e&ternal systems with the instance of the b!siness process they are intended
for,
S!pport long<r!nning application instances,
)andle e&ceptions raised by individ!al steps in the application and take appropriate action when these
e&ceptions occ!r,
Provide compensation logic to !ndo actions committed earlier in the b!siness process if a fail!re
occ!rs,
1i9Talk Server orchestration provides f!nctionality to s!pport each of these re?!irements, as described in the
following sections,
Correlating 2essages and Process Instances
=rchestration of processes s!ch as -&ec!te Sched!led Payments involves messages sent to e&ternal systems
and received from e&ternal systems, These e&ternal systems implement the actions that make !p the b!siness
process, t any time, there are likely to be many instances of the b!siness process r!nning at the same time,
-ach instance maintains its own state, and any message that is received m!st be correlated with the correct
instance of the b!siness process that it was intended for, 8or e&ample, -&ec!te Sched!led Payments receives a
payment acknowledgment message from a payment a!thority to indicate that a specific payment has been
processed, 8or more information, see, @Step P: Sending the Payment and %eceiving an cknowledgment,@ in
the @-&ample@ section,
To set !p correlation within an orchestration, yo! start by defining a correlation type that specifies one or more
message properties, The combination of these properties is g!aranteed to be !ni?!e across all instances of the
b!siness process, These properties map to fields in the o!tgoing and incoming messages, 8or e&ample, SS.
co!ld be a property that occ!rs in both the o!tgoing message and the incoming message, albeit in a different
location in each message,
245450494.doc 71 od 257
To map the properties to fields in the o!tgoing message, yo! create an instance of this correlation type called a
correlation set, This correlation set is then initiali9ed '!ni?!e val!es are assigned to the properties in the
correlation type( by specifying this correlation set as the Initiali>ing Correlation Set for a Send shape in the
orchestration, This means that when a message is transmitted by way of this Send shape, the correlation set
will be initiali9ed !sing the correct fields in the message 'SS., for e&ample(,
Lastly, yo! config!re the matching Recei7e shape to !se this correlation set as the /ollowing Correlation
Set, This means that when a message is sent back to the orchestration, the message will be passed to the
instance of the orchestration that has a correlation set with properties that match the properties in the
message,
%ong4Running Transactions
long<r!nning transaction contains persistence points that are also restart points if a fail!re occ!rs, 1i9Talk
Server 3445 implements transactions, compensation, and e&ception handling within a Scope shape, The Scope
shape s!pports both atomic and long<r!nning transactions, 8or more information abo!t atomic and long<
r!nning transactions, see @Transactions@ in the Process Integration pattern,
The -&ec!te Sched!led Payments orchestration !ses long<r!nning transactions to handle long<lived interactions
with e&ternal systems that may fail or time o!t, 8or more information, see @Step P: Sending the Payment and
%eceiving an cknowledgment@ in the @-&ample@ section,
3andling 5.ceptions and Compensating Transactions
*hen e&ternal applications are invoked to implement a specific action, a variety of errors can occ!r, These
errors may ca!se e&ceptions to be thrown, 8or e&ample, when an orchestration calls a *eb service, the *eb
service can raise an e&ception that is passed back to the 1i9Talk orchestration process, -&ceptions are handled
by e&ception handlers that are attached to the scope within which the e&ception occ!rred, The o!termost scope
in a 1i9Talk orchestration is that of the orchestration itself, dditional scopes can be nested within an
orchestration by !sing the Scope shape,
-&ception handling logic can be defined for the entire orchestration as a separate e&ec!tion flow within the
=rchestration Designer, +t is also possible to encaps!late vario!s action shapes within a Scope shape and to
define an e&ception handling bo!ndary aro!nd these shapes so that the shape has its own !ni?!e e&ception
handling properties, n e&ample of this is shown in @Step 5: )andling -&ceptions,@
*hen an error occ!rs, an orchestration may need to reverse the effects of transactions that occ!rred earlier in
the orchestration, and that have already been committed, To achieve this, the orchestration e&ec!tes a
compensation block, which specifies how the transaction can be reversed, /ompensation also reverses actions
that are not transactional, s!ch as sending a message,
245450494.doc 72 od 257
8or e&ample, an orchestration contains a scope with an atomic transaction that commits and writes changes to
a database, This first scope is followed by another scope with a long<r!nning transaction, *hen an error occ!rs
in this second scope, the error aborts the long<r!nning transaction and then starts e&ception handling logic for
the long<r!nning transaction, )owever, the effects of the first atomic transaction cannot be rolled back, beca!se
they have already been committed, +nstead, a compensating transaction 'series of actions which compensate
for the original transaction( is re?!ired to remove the changes from the database,
Implementing the 5.ecute Scheduled Payments =rchestration
The following steps form the general g!idelines for implementing and deploying an orchestration like the
-&ec!te Sched!led Payments orchestration:
6, Designing the orchestration, Ho! !se 1i9Talk =rchestration Designer to lay o!t the se?!ence of
actions that define the -&ec!te Sched!led Payments application, .o implementation is specified at this
stage,
3, Designing the schemas used by the orchestration, Ho! !se the 1i9Talk Schema -ditor in :is!al
St!dio ,.-T to define schemas for all messages received or sent by the orchestration so that the
message can be read or written by the orchestration,
;, Adding implementation to actions in the orchestration, Ho! !se 1i9Talk =rchestration Designer to
link the steps in the orchestration with the implementation of those steps, This may involve sending
and receiving messages by !sing Send and Recei7e shapes to and from e&ternal systems, =r, it may
involve sending and receiving messages by specifying small code segments in 5.pression shapes,
5, Adding error and e.ception handling, Ho! add error and e&ception handling by !sing Decision
shapes or by !sing 5.ception blocks that are attached to Scope shapes,
A, #uilding and deploying the orchestration, n orchestration has to be deployed to the global
assembly cache and to the 1i9Talk Management database before it can be e&ec!ted, The orchestration
is deployed by !sing the 1i9Talk Deployment *i9ard,
P, Setting up send and recei7e ports, 1efore the orchestration can be started, yo! !se 1i9Talk
-&plorer from within :is!al St!dio ,.-T to create 1i9Talk receive and send ports, and to bind them to
the logical port definitions referenced by the orchestration,
O, Setting up the recei7e adapter, The SBL Server adapter is config!red to periodically e&ec!te a
stored proced!re that ret!rns QML records to the orchestration based on a specified ?!ery, The SBL
Server dapter is typically config!red by !sing the 1i9Talk -&plorer from within :is!al St!dio ,.-T,
7, Starting the orchestration, Starting the orchestration ca!ses it to actively listen to incoming
messages, The service is now live and e&ec!tes an instance of the orchestration for each message that
is delivered by the SBL Server dapter,
5.ample
This e&ample follows a "lobal 1ank developer thro!gh the process of creating the -&ec!te Sched!led Payments
scenario and describes the specific config!rations that are necessary to meet "lobal 1ankJs re?!irements,
245450494.doc 73 od 257
/igure !1 3igh4le7el 7iew o& the 5.ecute Scheduled Payments business process
To implement the -&ec!te Sched!led Payments process, the "lobal 1ank developer starts by designing the
process model that describes the sol!tion, 8ig!re 3 shows a high<level sketch of the process flow for this
sol!tion, The developer !ses this process model design to develop the -&ec!te Sched!led Payments
orchestration in the 1i9Talk Server =rchestration Designer, +nitially, the developer E!st specifies the process flow
in the orchestration and then links the actions in the orchestration to the implementation of those actions, 8or
e&ample, actions may be implemented by a call to an e&ternal *eb method,
The following steps describe in detail how the -&ec!te Sched!led Payments orchestration implements the
process model, They also describe how the completed orchestration is compiled and deployed in the "lobal
1ank environment,
,ote ltho!gh the following steps adhere to the general implementation and deployment g!idelines presented
earlier in @+mplementing the -&ec!te Sched!led Payments =rchestration,@ the order and n!mber of the steps
vary slightly, The sample steps that follow reflect both the order in which the developer creates the
orchestration in 1i9Talk Server and the order in which 1i9Talk Server presents the orchestration in the !ser
245450494.doc 74 od 257
interface, The developer also performs some steps s!ch as error handling m!ltiple times, according to accepted
practices,
Step 1 Recei7ing a Payment Re0uest
The first shape in the orchestration is a Recei7e shape, which receives payment messages 're?!ests(, This
Recei7e shape is linked to an orchestration port called Recei7ePaymentRe0uest 'see 8ig!re ;(,
/igure $1 The &irst stage in the orchestration is recei7ing the Payment message
*henever a payment re?!est message is received, a new instance of the orchestration is created and the
message is received by this port, 8or information abo!t how these messages are generated, see @Step 64:
Setting $p the SBL Server dapter,@
Step ! Designing the Payment 2essage Schema
The developer needs to specify an QML schema that describes the payment message so that it can be
processed by the orchestration, .ormally, a developer wo!ld !se the 1i9Talk Schema -ditor to design a schema,
)owever, in this case, the payment messages are generated by !sing a SBL ?!ery to create an QML record set
'see @Step 64: Setting $p the SBL Server dapter@(, The developer can !se the SBL Server dapter *i9ard to
a!tomatically generate a schema that is appropriate for this ?!ery, 8ig!re 5 shows the "lobal 1ank payment
schema as viewed in the 1i9Talk Schema -ditor,
245450494.doc 75 od 257
/igure '1 The generated payment schema in the #i>Tal- Schema 5ditor
*hen the SBL ?!ery is e&ec!ted, m!ltiple payment records are typically ret!rned, The payment records m!st
be split into separate records so that each payment can be handled individ!ally, The developer !ses the 1i9Talk
Schema -ditor to create another schema that is known as an envelope schema, The envelope schema
represents the set of payments, *hen the receive port is config!red to !se these schemas, the QML recordset
that is generated is a!tomatically split into individ!al QML records,
Step $ Calling a Web Ser7ice to Debit the Account
.e&t, the c!stomerJs acco!nt is checked to ens!re that it has s!fficient f!nds to pay the bill, The appropriate
amo!nt is then debited from the acco!nt, The f!nctionality for these steps e&ists on the mainframe and has
been e&posed as a *eb service thro!gh )ost +ntegration Server 'see Implementing Gateway wit" .ost
Integration Ser!er 3445(,
To implement this part of the orchestration, the developer !ses the dd *eb %eference *i9ard to add a *eb
reference to the proEect, E!st as he or she wo!ld add a *eb reference to any other ,.-T 8ramework application,
dding the *eb reference creates an orchestration port that is bo!nd to the *eb service, 8ig!re A shows the
res!lts of adding a *eb reference to an orchestration# the DebitPort is the port bo!nd to the *eb service, and
Chec-#alanceAndDebit and CreditAccount represent some of the *eb methods that this *eb service
implements,
+n addition, the dd *eb %eference *i9ard generates QML schemas that represent the re?!est<response
messages for each of the *eb methods e&posed by the *eb service, The dd *eb %eference *i9ard also
245450494.doc 76 od 257
creates corresponding orchestration message types, The developer then creates instances of the orchestration
message types /heck1alancendDebitTre?!est and /heck1alancendDebitTresponse, These instances are
called Debit%e?!est and Debit%esponse respectively,
/igure (1 Preparing and sending a message to a Web method ?Clic- the image to enlarge it@
The Debit%e?!est message is initiali9ed !sing a Trans&orm shape called Trans&ormPayment!DebitRe0uest
'see 8ig!re P(, This shape applies an -&tensible Stylesheet Lang!age for Transformations 'QSLT( transformation
to the incoming Payment message and initiali9es the Debit%e?!est message,
The Debit%e?!est message is then sent to the *eb method Chec-#alanceAndDebit by the
SendDebitRe0uest shape, which ens!res the acco!nt has s!fficient f!nds, The appropriate amo!nt is then
debited from the acco!nt, The *eb method ret!rns the Debit%esponse message to the
Recei7eDebitResponse shape, This message has fields that contain the new acco!nt balance and the stat!s
of the debit action,
Step ' 3andling 5.ceptions
$nder some circ!mstances, the Chec-#alanceAndDebit Web method may ret!rn an e&ception, 8or e&ample,
an e&ception is generated if a re?!est to Chec-#alanceAndDebit specifies an invalid acco!nt n!mber, The
orchestration m!st handle this e&ception by providing an e&ception handler that specifies an appropriate action
!nder these conditions,
-&ception handling can be set at vario!s levels of scope within the orchestration, +n this instance, the *eb
method re?!est and response are enclosed by a Scope shape, The Scope shape has specific e&ception
handling code attached 'see Catch S=AP 5.ception in 8ig!re A(,
+n this e&ample, the e&ception handling is simple, The code in the Set 5rror Status 5.pression shape sets
the val!e of the errorStat!s orchestration variable to 6, to indicate that a *eb service e&ception has occ!rred,
This val!e is checked later in the orchestration 'see @Step A: /hecking for -rrors@(,
,ote This e&ample ass!mes that if an e&ception is generated, no debit occ!rs, Therefore, no compensation
logic is re?!ired in this case, 8or an e&ample that re?!ires compensation logic, see @Step O: /ompensating for
Payment -rrors,@
Step ( Chec-ing &or 5rrors
245450494.doc 77 od 257
Step 5 described how the *eb method can throw e&ceptions, and how these e&ceptions are ca!ght and
handled, dditionally, the *eb method response message 'Debit%esponse( ret!rns a stat!s code that may also
indicate an error s!ch as ins!fficient f!nds in the acco!nt,
-&ceptions and error stat!s messages differ in their recoverability, n e&ception is reserved for sit!ations where
a f!ndamental error has occ!rred that is not likely to be recoverable, Step 5 provides an e&ample of an
e&ception being thrown for an invalid acco!nt n!mber, This sit!ation may indicate a significant problem 'a data
error( that is not likely to be recoverable,
n error stat!s message is reserved for an error stat!s that is ret!rned by a *eb method and that indicates a
b!siness error occ!rred where the b!siness error is likely to be recoverable, n e&ample of a b!siness error
that is likely to be recoverable is an attempt to e&ec!te a payment when there are ins!fficient f!nds in the
acco!nt,
*hen the *eb method ret!rns a response message, the response message contains a 1oolean stat!s field, The
orchestration checks the val!e of this field to determine if the *eb method call was s!ccessf!l, +n this case, the
*eb method call is s!ccessf!l if the appropriate amo!nt was debited from the acco!nt, To check the val!e of
the field, a Decide shape is !sed to test the val!e of the stat!s field as shown in 8ig!re P,
/igure )1 Chec-ing the status in the Web method response
The following is the e&pression in the Decide shape,
(DebitResponse(ExecutePaymentSchemas.success) == true) && (errorNo == 0)
.otice that the Decide shape also checks the val!e of the global orchestration variable, errorStatus, which is
set to 6 if an e&ception occ!rs, ss!ming that both of these conditions are met, no error has occ!rred, so the
orchestration proceeds to @Step P: Sending the Payment and %eceiving an cknowledgment,@
245450494.doc 78 od 257
+f either of the conditions is not met, an error occ!rs, and the orchestration writes stat!s information back to
the database, Specifically, the orchestration writes stat!s information to the Status field of the appropriate
record in the Payment table, The orchestration then terminates by !sing the Terminate shape, The Terminate
shape sets an error message that which appears in the operations view of the 1i9Talk Server )ealth and ctivity
Tracking ')T( console,
Step ) Sending the Payment and Recei7ing an Ac-nowledgment
fter the acco!nt has been checked for s!fficient f!nds and the f!nds have been debited, a payment message
is sent to the appropriate payment a!thority based on the val!e that is specified in the f!lfillmentType+d field in
the payment, To simplify this process and to avoid having to change the -&ec!te Sched!led Payments b!siness
process whenever the payment a!thorities make changes, the payment message is sent to a Message )ro'er,
Message )ro'er is implemented with 1i9Talk Server also, 8or additional information, see Implementing Message
)ro'er wit" )i6Tal' Ser!er 3445,
Message )ro'er selects the appropriate payment a!thority based on the f!lfillmentType+d field, transforms the
message to the appropriate format for that payment a!thority, and then sends the message, This series of
events is shown in 8ig!re O,
/igure *1 Sending the payment re0uest and recei7ing a response
fter the payment message is sent to the payment a!thority thro!gh the Message )ro'er, the payment
a!thority sends an acknowledgement back to the Recei7ePaymentResponse port, *hen these
acknowledgement responses arrive, they need to be correlated to the correct instance of the payment
orchestration for which they are intended,
To correlate the response message with the orchestration instance, the developer creates a correlation type that
specifies certain fields in the message, These fields are g!aranteed to be !ni?!e across all instances of the
orchestration# this e&ample !ses the Payment+d field, The developer creates an instance of this correlation type
called a correlation set, The correlation set is be initiali9ed with the act!al val!e of the Payment+d from the
Payment%e?!est message when that message is sent o!t the SendPaymentRe0uest orchestration port,
245450494.doc 79 od 257
Lastly, the developer config!res the Recei7e Payee Response shape to wait for an acknowledgment message
that matches this correlation set,
.ow, when the payment a!thority sends an acknowledgment back, the acknowledgment incl!des the
Payment+d, The 1i9Talk orchestration engine a!tomatically passes the acknowledgment to the instance of the
%eceivePayment%esponse port with a correlation set that e?!ates to this Payment+d,
Step * Compensating &or Payment 5rrors
t this stage in the orchestration, the following errors co!ld have occ!rred:
,o response was recei7ed &rom the payment authority, This error co!ld occ!r either beca!se the
payment a!thority never received the Payment message or beca!se of some fa!lt with the payment
a!thority system,
The response indicated that payment could not be processed, This error co!ld occ!r for a
n!mber of reasons, s!ch as invalid payee details or incorrect payment details,
-&ceptions and errors are handled in the same way as in steps 5 and A, =ne or more e&ception handlers catch
e&ceptions, and a Decide shape checks the stat!s fields in the response messages,
,ote The Send Payment Re0uest T. scope shape can have a timeo!t attached so that if no response is
received within a certain time, the orchestration a!tomatically generates an e&ception,
/ompensation processing is also needed at this point, /ompensation processing reverses the effects of earlier
transactions that have occ!rred in the b!siness process, +n this e&ample, the c!stomer acco!nt is debited
before the payment re?!est is sent to the payment a!thority, +t is not possible to roll back this transaction
beca!se it has already been committed and the money has been ded!cted from the c!stomerJs acco!nt
balance, 1eca!se the bill has not been paid, the compensation processing m!st reverse the effects of this
transaction by crediting the money back to the acco!nt,
/igure 91 Compensation logic &or &ailed payments ?Clic- the image to enlarge it@
8ig!re 7 shows how the compensation is added to the Scope shape that sends the payment re?!est message,
The compensation logic transforms the payment message to create a *eb method re?!est that can be sent to
the CreditAccount *eb method,
,ote real<world scenario wo!ld re?!ire additional error handling aro!nd the compensation code, b!t this
has been e&cl!ded in this e&ample for simplicity,
Step 9 Deploying the =rchestration
245450494.doc 80 od 257
The orchestration, schemas, and maps now m!st be compiled to a ,.-T 8ramework assembly, and then the
assembly m!st be deployed to the 1i9Talk Server /onfig!ration database and to the global assembly cache, To
deploy to the global assembly cache, the assembly m!st be signed with a strong name,
1efore b!ilding the assembly, create a key file by !sing the following command at the command prompt,
>snk ExecutePayment.snk
/opy the file to the proEect folder, and then enter the file name in the Assembly 6ey /ile name property in the
proEect properties, .e&t, b!ild and deploy the sol!tion,
,ote The developer can also !se the scripts that ship with the 1i9Talk Server 3445 Software Development 0it
'SD0( to perform these actions,
Step ; Setting "p Send and Recei7e Ports
s well as the two sets of S=P ports that are a!tomatically negated when the orchestration is deployed, the
orchestration has the following ports:
Recei7ePaymentRe0uest, This port receives messages from the SBL Server dapter and initiates a
new instance of the orchestration for each message that is received,
SendPaymentRe0uest, This port sends the payment message to the Message )ro'er, The Message
)ro'er then sends it to the payment a!thority,
Recei7ePaymentResponse, This port receives a payment response from the payment a!thority,
physical 1i9Talk receive or send port is created for each of these and is bo!nd to the appropriate orchestration
port, The developer !ses 1i9Talk -&plorer inside :is!al St!dio ,.-T to create these ports, fter the physical
ports are set !p, the orchestration is bo!nd to these ports in 1i9Talk -&plorer, The developer can also !se the
1TSdeploy command line !tility and a binding file, The binding file is created by !sing the 5.port #i>Tal-
assembly binding to &ile option in 1i9Talk Deployment *i9ard to bind ports,
,ote The %eceivePayment%e?!est port is config!red to !se the SBL Server dapter to periodically e&ec!te a
SBL ?!ery, This is covered in more detail in the ne&t section, @Step 64: Setting $p the SBL Server dapter,@
Step 1< Setting "p the SA% Ser7er Adapter
+n this step, the developer creates a 1i9Talk Server receive port that is config!red with the SBL Server dapter,
The SBL Server dapter is config!red to periodically e&ec!te a ?!ery that ret!rns all payments to be processed
as an QML recordset, 8ig!re M shows how the SBL Server dapter is config!red to periodically call this ?!ery
and to ret!rn the individ!al QML records,
245450494.doc 81 od 257
/igure ;1 Con&iguring the SA% Ser7er recei7e adapter
The following ?!ery ret!rns all payments that need to be r!n now as an QML recordset that is based on
sched!led time 'payment1dateTo2a-e( and stat!s 'payment1status(,
SEE!" payment.#$transaction%&' payment.amount' payment.&ate#a&e'
payment.&ate"o#ake' payment.(re)uency' payment.status' Payee.#$Payee%&'
Payee.(u*(i**ment"ype%&' Payee.payeeName' Payee.accountNumber'
customer+ccount.customer+ccount%&' customer+ccount.#$accountNumber'
customer.(irstName' customer.mi&&*eName' customer.*astName $R,# payment'
Payee' customer+ccount' customer -.ERE payment.payee%& = Payee.Payee%& +ND
payment.customer+ccount%&=customer+ccount.customer+ccount%& +ND
customer+ccount.customer%&=customer.customer%& +ND payment.status=/sc/ +ND
payment.&ate"o#ake 0 1et&ate() $,R 2# +3",' EE#EN"S
s described in steps 6 and 3, the record set ret!rned is split into individ!al payment messages by !sing an
QML envelope schema, and each of these messages creates a new instance of the orchestration,
Step 11 Starting the =rchestration
8inally, the developer !ses 1i9Talk -&plorer to bind the physical receive and send ports created in steps M and
64 to the ports in the orchestration, The developer then starts the orchestration, .ow, the SBL Server dapter
sho!ld e&ec!te the SBL ?!ery every si& ho!rs, and one instance of the orchestration sho!ld be created for each
245450494.doc 82 od 257
payment record that is ret!rned, These orchestrations e&ec!te the sched!led payment as described and
terminate !pon completion,
Resulting Conte.t
This implementation of Process Integration res!lts in the following benefits and liabilities,
#ene&its
2aintainability, /reating a separate process integration layer allows !sers to define and maintain the
b!siness process independent from the implementation of the individ!al f!nctions, This increases
maintainability and red!ces the skill set re?!irements for the personnel who maintain the process
definition, 1i9Talk Server orchestration s!pports this by defining the b!siness process flow independently of
the binding to individ!al actions that make !p that flow,
Reusability, 1eca!se the e&isting applications are not dependent on the process management layer,
the f!nctions inside these applications can be re!sed in m!ltiple process definitions,
/le.ibility, 1i9Talk orchestration s!pports a variety of config!rations that wo!ld be diffic!lt to
implement in many traditional programming models, 8or e&ample, 1i9Talk orchestration s!pports parallel
e&ec!tion of m!ltiple tasks, synchroni9ation points, timeo!ts, and escalations, S!pporting a variety of
config!rations gives the process manager the fle&ibility to adapt to many different b!siness re?!irements,
Reporting, 1eca!se the process instances are maintained centrally, it becomes feasible to e&tract
statistical information that spans m!ltiple process steps and process instances, S!ch reports can tell yo!
the average length of time it takes to f!lfill an order and the n!mber of orders that are on hold beca!se of
ins!fficient inventory, 1i9Talk Server provides e&tensive real<time reporting, and in addition, it !ses SBL
Server nalysis Services to provide comprehensive reporting across aggregated b!siness res!lts,
%iabilities
Potential bottlenec-, Managing a large n!mber of process instances in a central process manager
component may present a r!n<time bottleneck, )owever, 1i9Talk Server provides mechanisms to manage
the lifetime of a large n!mber of conc!rrently r!nning orchestrations, These mechanisms incl!de
dehydration and rehydration of b!siness processes that are c!rrently blocked,
Temptation to o7eruse, This liability is the flipside of the fle&ibility inherent in Process Integration
sol!tions, 1eca!se 1i9Talk orchestration can be !sed to solve nearly any integration problem, the
temptation is to apply 1i9Talk orchestration to all integration problems, This can lead to overarchitected
sol!tions and sometimes to inefficient sol!tions, 8or e&ample, many developers might be tempted to !se
Process Integration in cases where Message )ro'er wo!ld be perfectly appropriate to address the
re?!irements,
Testing Considerations
Separating the process definition from the f!nctions provided by the applications means that yo! can test each
b!siness f!nction 'service( individ!ally by creating simple test drivers that call the f!nctions and verify the
res!lts, 8or e&ample, yo! can test the "ateway *eb service by !sing a,.-T 8ramework application to call the
*eb service, by s!pplying vario!s test parameters, and by validating the responses,
The advantage of !sing a commercial process manager s!ch as 1i9Talk Server 3445 is that it is designed to
handle comple& iss!es that are related to thro!ghp!t, threading, transactions, locking, and performance
bottlenecks, This means that yo! only need to perform minimal testing of these aspects of the application, This
also means that more testing effort can concentrate on the !nit tests of the individ!al steps of the b!siness
process and on the integration of these steps into a complete b!siness process,
Security Considerations
245450494.doc 83 od 257
pplications b!ilt !sing 1i9Talk Server orchestration typically access m!ltiple b!siness systems that encaps!late
the individ!al steps of the b!siness process, These b!siness systems often provide their own a!thentication
mechanism, !s!ally a !ser name and password, common re?!irement when !sing 1i9Talk orchestration to
access these systems is for the orchestration to s!pply credentials for the !ser who is represented by this
instance of the b!siness process,
8or e&ample, a b!siness process may be initiated by many !sers filling o!t a Microsoft =ffice +nfoPathU form
and sending it in a S=P message to 1i9Talk Server, The messages initiate a new instance of the orchestration
for each !ser, These instances then access b!siness systems s!ch as an -nterprise %eso!rce Planning '-%P(
system by !sing the !serJs credentials for that system, 1eca!se it is not practical to re?!est the credentials
from the !ser, credentials are either encoded in the message itself or accessed by 1i9Talk from a sec!re store,
1i9Talk Server provides the enterprise single sign<on 'SS=( system to store credential information, SS=
provides a sec!red store, which is based on the !serJs sec!rity conte&t, and stores sec!rity and state
information that is pertinent to that sec!rity conte&t, +n the earlier e&ample, the sec!rity conte&t of the !ser
filling o!t the +nfoPath form can be !sed to retrieve the !ser name and password for the -%P system from SS=,
The orchestration can then access the -%P system on that !serJs behalf,
=perational Considerations
1i9Talk Server orchestrations are bo!nd to a 1i9Talk Server host, 1i9Talk Server host is an engine for
messaging and orchestration, n instance of a 1i9Talk Server host can be created on each 1i9Talk Server
comp!ter in the 1i9Talk Server gro!p, which res!lts in the creation of a process on a comp!ter thro!gh a
*indows service, The process then e&ec!tes instances of the orchestration,
Ho! can !se the 1i9Talk Server dministration console to create additional hosts, Ho! can then bind the
additional hosts to orchestrations and map to servers in the 1i9Talk Server gro!p, This allows orchestrations to
be deployed to any combination of servers in the 1i9Talk Server gro!p, Therefore, the b!siness application can
be distrib!ted across the servers in yo!r enterprise as needed,
Related Patterns
Process Manager L)ohpe45N describes the internal f!nction and implementation of the process manager
component,
Ac-nowledgments
L)ohpe45N )ohpe, "regor and 1obby *oolf, Enterprise Integration Patterns1 &esigning0 )uilding0 and &eploying
Messaging Solutions, ddison<*esley, 3445,
L/hapell4;N David /happell, /happell & ssociates, 7Understanding )i6Tal' Ser!er 3445.7 Microsoft
/orporation, 344;, vailable at http:>>go,microsoft,com>fwlink>CLink+dV36;6;,
245450494.doc 84 od 257
Portal Integration

Integration Patterns
Contents
/onte&t
Problem
8orces
Sol!tion
-&ample
%es!lting /onte&t
Conte.t
Many b!siness f!nctions re?!ire !sers to access information that resides in m!ltiple disparate systems, 8or
e&ample, a c!stomer might call a service representative to place a new order, )owever, before the service
representative accepts a new order, he or she has to verify the c!stomerJs payment history in the acco!nting
system to ens!re that the c!stomer is in good standing, Switching between systems makes the service
representativeJs work tedio!s and error<prone,
Problem
)ow can !sers efficiently perform tasks that re?!ire access to information that resides in m!ltiple disparate
systemsC
/orces
To solve this problem, yo! need to consider the following forces:
+t is still very common for an end !ser to have to man!ally copy information from one system to
another, This type of integration is often referred to h!moro!sly as @swivel chair integration@ beca!se the
!ser has to access m!ltiple systems, often from m!ltiple terminal screens, The !ser views the information
on one screen and then swivels to another screen to enter data based on the information from the first
screen, =bvio!sly, this type of man!al integration is very inefficient and error prone,
Process +ntegration can a!tomate tasks that combine data and f!nctions from m!ltiple systems,
thereby alleviating the need for !sers to access m!ltiple systems directly, )owever, Process Integration
re?!ires a good !nderstanding of the b!siness process so that the b!siness process can be acc!rately
represented in a process model, This is often not the case beca!se !sers make improvised decisions based
on the information they see,
245450494.doc 85 od 257
-ntity ggregation allows m!ltiple systems to share data, which enables the !ser to access all re?!ired
information from a single point, )owever, Entity $ggregation is often impossible or not economical d!e to
strong semantic dissonance between the individ!al systems and lack of a common vocab!lary between
systems and people,
%eading data from an application is generally simpler and less risky than !pdating information, This is
especially tr!e in cases s!ch as Data +ntegration, which directly accesses application data and bypasses the
b!siness and validation logic,
Solution
/reate a portal application that displays the information retrieved from m!ltiple applications in a !nified !ser
interface, The !ser can then perform the re?!ired tasks based on the information displayed in this portal,
/igure 11 Portal Integration
Portal Integration is a comparatively simple form of integration, +t is pop!lar beca!se it is typically m!ch easier
to implement and less intr!sive than more sophisticated types of integration, s!ch as Process Integration, *ith
Portal Integration, the b!siness process that describes the se?!ence of tasks does not have to be represented
in a precise process model, b!t instead resides in the !serJs head, This enables the end !ser to compensate for
mismatches in semantics between the individ!al systems and to make a case<by<case decision, This approach is
nat!rally less efficient than Process Integration, b!t it gives the !ser fle&ibility and it is typically m!ch faster to
implement, +n many cases, Portal Integration can be !sed as an intermediate sol!tion !ntil b!siness processes
are better !nderstood and can be incorporated into a process model, th!s enabling the transition to Process
Integration,
245450494.doc 86 od 257
The portal engine shown in 8ig!re 6 interacts with the individ!al applications !sing &ata Integration, 8!nctional
+ntegration, or Presentation +ntegration, 1eca!se the primary p!rpose of the portal is the display of
information, Portal Integration works partic!larly well with simpler forms of connectivity, s!ch as &ata
Integration or Presentation Integration,
Portal Integration comes in a variety of flavors from very simple to fairly comple&, The following list categori9es
the different variants:
Display4only, The simplest form of Portal Integration simply displays data in different areas of the
screen, +nformation from each application is mapped to a rectang!lar area of the screen, also referred to
as a pane, This display allows the !ser to view information retrieved from m!ltiple applications on a single
screen, .o other f!nctionality is provided,
Simple post4processing, +nstead of presenting the data received from each individ!al system, many
portals add simple r!les that help the !ser make decisions, 8or e&ample, if the billing system reports that a
c!stomer payment is overd!e, the portal wo!ld list this as an e&ception in bold red letters at the top of the
screen instead of showing the history of all payments received, This type of f!nctionality helps t!rn raw
data into !sef!l information for the !ser,
Single application interaction, This variant displays data in different areas of the screen, b!t it also
allows the !ser to iss!e commands to one system at a time, This e&tra f!nctionality enables the !ser to
view information from m!ltiple systems and !se the res!lting data to perform a b!siness f!nction that is
limited to a single system,
Cross4pane interacti7ity, +n many cases, the information to be displayed in one pane depends on a
!ser selection in another pane, 8or e&ample, a list of c!stomers might be retrieved from the c!stomer
relationship management '/%M( system, *hen the !ser selects a c!stomerJs name from the list, the portal
retrieves the selected c!stomerJs payment history from the billing system and displays it in a separate
pane, To a!tomate these steps, basic interaction between different portal panes is re?!ired, This type of
portal speeds !p the !serJs tasks witho!t re?!iring f!ll integration between systems, )owever, this type of
portal does re?!ire the availability of common keys, s!ch as a c!stomer identifier '+D(, that f!nction across
m!ltiple systems, *ith this type of portal, the development of the interaction is often diffic!lt to test and
re!se,
The Portal Integration sol!tion relies on interplay between the sol!tion components that are described in Table
6,
Table 1 Portal Integration Solution Components
Component Responsibilities Collaborators
Portal engine < -&tract information from e&isting applications
< %ender information into a !nified !ser interface
pplications
pplication )ost relevant b!siness data .one
5.ample
Many c!stomer service f!nctions re?!ire access to a range of c!stomer data, 8or e&ample, a c!stomer may call
to place a new order, check whether a payment has been received, and change his or her phone n!mber, =ften,
this type of information is stored in many different systems, s!ch as the order management system, the billing
system, or the complaint system, "iving a c!stomer service representative a !nified view of the vario!s records
for a c!stomer can be enormo!sly helpf!l in providing efficient and effective service to the c!stomer, similar
or red!ced version of the portal co!ld also be presented directly to the cons!mer on the companyJs *eb site,
Resulting Conte.t
245450494.doc 87 od 257
Portal Integration res!lts in the following benefits and liabilities:
#ene&its
,on4intrusi7eness, 1eca!se its primary f!nction is the retrieval and display of information, Portal
Integration can typically be added to e&isting systems witho!t dist!rbing the e&isting f!nctionality, This is
partic!larly tr!e if Portal Integration !ses &ata Integration for the retrieval of data from the individ!al
systems,
Speed o& implementation, dding a portal to e&isting applications can often be accomplished in a
matter of days or weeks, whereas a f!ll integration of the systems co!ld take many months, Many vendors
offer Portal Integration platforms in combination with a s!ite of prefabricated panes that integrate with
many pop!lar enterprise applications and data so!rces,
/le.ibility, 1eca!se the !ser makes the decisions, Portal Integration can be !sed in sit!ations where
b!siness r!les are not well !nderstood or not agreed !pon,
%iabilities
Ine&&icient, Portal integration is best s!ited to the a!tomation of simple tasks and processes beca!se
it still re?!ires man!al interaction by the !ser, 8or e&ample, beca!se most portals allow the !ser to interact
with only one application at a time, the !ser might have to perform m!ltiple man!al actions in se?!ence to
complete a comple& b!siness f!nction, This makes Portal Integration !ns!itable for high<vol!me
applications, +n these sit!ations, Process Integration is generally a better sol!tion beca!se the se?!ence of
steps can be encoded in a process model and r!n a!tomatically by the process manager,
5rror4prone, *hen !sing Portal Integration0 the !ser makes b!siness decisions and determines the
se?!ence of tasks to be performed, *hile this provides fle&ibility, it also introd!ces the risk of h!man error,
Therefore, Portal Integration is not well s!ited to integrations that re?!ire strict repetition of a defined
b!siness process, Process Integration is generally a better choice in those scenarios,
System Connections

Integration Patterns
May 3445
Summary This chapter b!ilds on /hapter ; by describing how to connect with individ!al systems, -ach system
allows certain types of access and restricts others, This chapter presents a series of related patterns that will
help yo! analy9e the alternative methods and the tradeoffs to consider when yo! choose yo!r system
connections,
Contents
/onnecting to Layered pplications
Data +ntegration
Presentation +ntegration
8!nctional +ntegration
245450494.doc 88 od 257
System /onnection Patterns
The previo!s chapter described different strategies for the design of an integration layer and the tradeoffs
involved in choosing an alternative, fter yo! decide to !se an integrating layer, yo! m!st then decide e&actly
how yo! are going to connect each system that yo! intend to integrate,
s yo! consider how to connect to different information systems, yo! will enco!nter a mi& of technical
architect!res, -ach technical architect!re is designed to allow certain types of access and to restrict others,
These access restrictions constrain the set of integration options that are available to yo!, This chapter
disc!sses a series of related patterns that will help yo! analy9e the alternative methods and the tradeoffs to
consider when yo! choose yo!r system connections,
Connecting to %ayered Applications
*hen trying to find connection points to an e&isting application, yo! need to st!dy the way these applications
are str!ct!red, The prevailing architect!ral style for b!siness applications is Layered pplication, Many
applications fall into the more specific form of the Three<Layered Services pplication pattern LTrowbridge4;N,
The components of this pattern are shown in 8ig!re 6,
/igure 11 A three4layered ser7ices application
This architect!ral style defines three distinct layers:
Presentation layer, The presentation layer displays information to the end !ser and allows for !ser
inp!t,
1!siness logic layer, The b!siness logic layer contains b!siness f!nctions that act on the b!siness data
Data layer, The data layer stores data persistently in a data store, This layer is also known as the
reso!rce layer,
-ach application layer presents an opport!nity for an application to interact with the integration layer, as shown
in 8ig!re 3,
245450494.doc 89 od 257
/igure !1 2ultiple choices when connecting an application
1eca!se each layer has different re?!irements and p!rposes, yo! face different challenges when connecting to
each layer, Similarly, there are three primary patterns yo! can !se to connect an application to an integration
layer:
Presentation +ntegration, The integration layer can e&tract information from the applicationJs !ser
presentation layer thro!gh a techni?!e known as screen scraping,
8!nctional +ntegration, The integration layer can interact with the b!siness logic layer thro!gh
application or service interfaces,
Data +ntegration, The integration layer can move data in and o!t of the data layer,
To make an informed choice abo!t which pattern to !se, yo! m!st know the options that are viable, and yo!
m!st eval!ate their impact on the overall integration architect!re, This chapter describes each pattern and
elaborates on the benefits and liabilities of each one,
s in other chapters, this chapter !ses vis!al models to show the associations between the patterns, 8ig!re ;
shows the patterns as circles and simple associations between them as lines, s the disc!ssion progresses,
more comple& pattern relationships b!ild !pon this basic diagram,
245450494.doc 90 od 257
/igure $1 System connection patterns
The first kind of integration to consider is &ata Integration,
Data Integration
Many applications keep large vol!mes of data in data stores s!ch as flat files and relational, hierarchical, and
obEect<oriented databases, =ther applications that need this information can access it directly from these data
stores,
/onnecting applications thro!gh the data store is relatively simple, $s!ally, yo! !se 8TP, sched!led batch files,
database management system 'D1MS( !tilities, e&tract transform and load '-TL( tools, and integration servers,
+f yo! decide to integrate at the data layer, there are three patterns that represent the three types of data
integration to consider: S"ared &ata%ase L)ohpe45N, Maintain &ata (opies LTeale4;N, and File Transfer
L)ohpe45N, These patterns are shown in 8ig!re 5,
/igure '1 Three -inds o& data integration
8ig!re 5 introd!ces a new pattern relationship to the vis!al model from 8ig!re ;, The triangle indicates
refinement between the base pattern 'Data +ntegration( and the derivative patterns 'S"ared &ata%ase,
Maintain &ata (opies, and File Transfer(, More precisely, this relationship is defined as follows:
@ specific pattern refines a more abstract pattern if the specific patternJs f!ll description is a direct e&tension of
the more general pattern, That is, the specific pattern m!st deal with a speciali9ation of the problem the
general pattern addresses, m!st have a similar 'b!t more speciali9ed( sol!tion str!ct!re, and m!st address the
same forces as the more general pattern, b!t may also address additional forces, To make an analogy with
obEect<oriented programming W the refines relationship is similar to inheritance,@ L.obleM7N
pplying this relationship to the problem of data integration means that if yo! decide to integrate systems at
the data layer, yo! m!st f!rther refine yo!r decision by choosing one of three alternatives, Ho! co!ld share a
single instance of a database between m!ltiple applications by !sing the S"ared &ata%ase pattern, as shown in
8ig!re A,
245450494.doc 91 od 257
/igure (1 2ultiple applications sharing the same data store
nother approach is to create m!ltiple copies of a database and distrib!te them thro!gho!t yo!r enterprise
according to the Maintain &ata (opies pattern, +f yo! do this, yo! m!st then maintain these separate copies,
which introd!ces synchroni9ation and replication, 8ig!re P shows the Data %eplication pattern, which refines
Maintain &ata (opies,
/igure )1 Data Replication: a re&inement o& 2aintain Data Copies
Het another approach is to !se File Transfer, +n this pattern, one application prod!ces a file and transfers it so
that other applications can cons!me it, 8iles can then be prod!ced at reg!lar intervals to synchroni9e two or
more systems,
The &ata Integration pattern, later in this chapter, describes these alternatives in detail and provides the
benefits and liabilities of each approach, This disc!ssion sho!ld help yo! choose the kind of data integration
that is appropriate for yo!r re?!irements,
245450494.doc 92 od 257
$sing &ata Integration is made easier by the ab!ndance of tool s!pport provided by many companies, )owever,
in spite of the low cost and the mat!rity of the tools, accessing the data store is not viable in some cases,
less invasive way of connecting applications is to connect thro!gh the presentation layer,
Presentation Integration
*hen applications that have !ser interfaces Eoin an integration architect!re, other applications can connect to
them thro!gh the presentation byte stream as shown in 8ig!re O,
/igure *1 Connecting to an application through the presentation layer
Presentation connectivity represents the least invasive way of connecting applications beca!se the other
applications appear to the host application as h!mans who are interacting thro!gh the !ser interface,
Therefore, this form of integration does not re?!ire any changes to the host, The disadvantage is that
sim!lating !ser interaction is c!mbersome and inefficient, +t re?!ires parsing the data or f!nctionality o!t of the
byte stream, which effectively reverses the transformations performed by the presentation logic, +n addition,
applications that connect thro!gh the presentation layer can only access what is also available to a h!man !ser,
The gran!larity of the e&posed data and f!nctionality is very coarse# b!rying potentially<rich P+s,
=ne advantage of Presentation +ntegration is that it can be an ine&pensive way to integrate applications,
ltho!gh the connection is ine&pensive, it is also easily disr!pted, 1y its very nat!re, presentation integration is
tightly co!pled to the host applicationJs presentation, +f the applicationJs presentation changes, the presentation
integration sol!tion m!st also change,
+nstead of sharing data or parsing thro!gh a byte stream to access a systemJs f!nctionality, it is often
preferable to access a systemJs b!siness logic directly thro!gh Functional Integration,
245450494.doc 93 od 257
/unctional Integration
1y connecting directly to the b!siness logic layer, 8!nctional +ntegration enables other applications and services
to take advantage of the b!siness logic that is encaps!lated in other systems, as shown in 8ig!re 7,
/igure 91 Integrating applications and ser7ices at the business logic layer
Functional Integration connects applications thro!gh interfaces and specifications, $nfort!nately, not all
applications in an integration architect!re have interfaces and specifications, B!ite often, the applications that
have P+s do not e&pose their data and f!nctions at a gran!larity level that is s!itable for integration,
Functional Integration can be very effective in the right circ!mstances, good e&ample of when to !se
Functional Integration is for a credit scoring application or service,
Credit Scoring 5.ample
Many financial applications re?!ire a credit score to ?!alify an applicant for a specific loan, Salespeople often
want a ?!ick and acc!rate response from a credit scoring system so they can ?!ickly pre?!alify c!stomers and
steer them to an affordable alternative, +n addition, credit scores depend on a n!mber of dynamic factors,
which means that credit scores can ?!ickly become o!t of date,
1eca!se credit scores are calc!lated val!es, sharing data means relying on credit scores that might be o!t of
date or d!plicating raw inp!t data and forcing each application to implement the credit scoring algorithm
independently, better sol!tion is to share the b!siness logic encaps!lated in the credit scoring system and to
then e&pose it thro!gh some type of f!nctional interface that other systems can cons!me, 8or this level of
integration, yo! need Functional Integration,
6inds o& /unctional Integration
fter yo! choose to !se Functional Integration0 yo! m!st f!rther refine yo!r decision by choosing one of the
three alternatives:
245450494.doc 94 od 257
&istri%uted -%8ect Integration, &istri%uted -%8ect Integration is also known as instance<based
collaboration beca!se it e&tends the model of obEect<oriented comp!ting to distrib!ted sol!tions, =bEects
inside one application interact with obEects in another remote application in the same way they wo!ld
interact locally with another obEect,
Message-riented Middleware Integration, Message-riented Middleware Integration connects systems
by !sing asynchrono!s message ?!e!es that are based on proprietary message<oriented middleware, The
connected systems then comm!nicate thro!gh messages that contain small packets of data, 1eca!se the
comm!nication is asynchrono!s and d!rable, there is little chance that the messages will be lost d!ring a
network or system fail!re,
Service<=riented +ntegration, Ser!ice-riented Integration connects systems by enabling them to
cons!me and provide QML *eb services, This type of integration !ses standards to provide both a portable
type system and an e&tensible messaging framework that is not co!pled to a proprietary implementation
or transport, +n addition, Ser!ice-riented Integration recommends the *S<+ 1asic Profile to ens!re
interoperability between endpoints, The *S<+ 1asic Profile is a caref!lly chosen s!bset of QML, S=P, )TTP,
and other standards,
,ote: The term service is !sed in many different ways in the conte&t of software engineering, +t is also !sed in
at least seven levels of scope: operating system, process, obEect, distrib!ted obEect, proprietary message<
oriented middleware, logical, and QML *eb services, This g!ide !ses the term service to mean QML *eb
services !nless indicated otherwise,
8ig!re M shows these three alternatives as distinct derivatives, or refinement patterns, of Functional
Integration,
/igure ;1 Three -inds o& /unctional Integration
Later in this chapter, the Functional Integration pattern describes these alternatives in detail and disc!sses the
benefits and liabilities of each approach, This disc!ssion sho!ld help yo! choose the kind of f!nctional
integration that is appropriate for yo!r re?!irements,
System Connection Patterns
Data, presentation, and f!nctional integration represent ways in which seasoned integration architects connect
applications, 1!t given yo!r specific re?!irements, how do yo! connect applications within yo!r integration
architect!reC
Sometimes the applications yo! are integrating limit yo!r choices, +f there is more than one way yo! can
connect them, yo! m!st eval!ate the tradeoffs associated with each potential choice, The &ata Integration,
Presentation Integration, and Functional Integration patterns later in this chapter distill the knowledge re?!ired
to make an informed decision,
245450494.doc 95 od 257
Two general points are worth noting, 8irst, an application that !ses one style of connection can comm!nicate
with another application that !ses a different style, 8or e&ample, Presentation Integration may be the only way
to e&tract data from a pree&isting application, b!t yo! can still insert this data into the target application !sing
&ata Integration, Second, despite sometimes similar names, a specific integration layer pattern can be !sed
with any system connection pattern, 8or e&ample, a Portal Integration sol!tion can e&tract data from e&isting
applications by !sing Presentation Integration, Functional Integration0 or &ata Integration,
8ig!re 64 shows three system connection patterns, with derivative patterns and associations,
/igure 1<1 System connection patterns and their relationships
Table 6 s!mmari9es these patterns and provides the problem>sol!tion pairs they represent,
Table 1 System Connections Patterns
Pattern or pattlet Problem Solution Associated
implementations
Data +ntegration )ow do yo! integrate
information systems
that were not designed
to work togetherC
+ntegrate applications at the
logical data layer, $se a S"ared
&ata%ase, File Transfer, or
Maintain &ata (opies,

S"ared &ata%ase
L)ohpe45N
)ow can m!ltiple
applications work
together and e&change
informationC
)ave m!ltiple applications store
data in a single database,
Define a schema that handles
the needs of all relevant
applications,

Maintain &ata (opies
LTeale4;N
)ow can m!ltiple
applications work
together and e&change
informationC
)ave m!ltiple applications
access m!ltiple copies of the
same data, Maintain state
integrity between copies,

File Transfer L)ohpe45N )ow can m!ltiple
applications work
together and e&change
informationC
t reg!lar intervals, have each
application prod!ce files that
contain the information that the
other applications m!st
cons!me, fter yo! create it, do
not maintain the file,

8!nctional +ntegration )ow do yo! integrate
information systems
that were not designed
+ntegrate applications at the
logical b!siness layer, $se
&istri%uted -%8ect Integration,

245450494.doc 96 od 257
to work togetherC 'proprietary( Message-riented
Middleware Integration, or
Ser!ice-riented Integration,
&istri%uted -%8ect
Integration 'see also
/emote Procedure
In!ocation L)ohpe45N(
)ow do yo! integrate
applications at the
logical b!siness layerC
Develop systems that have
obEect interfaces that can be
cons!med remotely by other
systems,

Message-riented
Middleware Integration
'see also Messaging
L)ohpe45N(
)ow do yo! integrate
applications at the
logical b!siness layerC
$se proprietary message<
oriented middleware to send
messages asynchrono!sly,

Service<=riented
+ntegration
)ow do yo! integrate
applications at the
logical b!siness layerC
$se *eb services to e&pose
interfaces that can be
cons!med remotely by other
systems,
+mplementing Service<
=riented +ntegration with
SP,.-T, or
+mplementing Service<
=riented +ntegration with
1i9Talk Server 3445,
Presentation +ntegration )ow do yo! integrate
information systems
that were not designed
to work togetherC
ccess the applicationJs
f!nctionality thro!gh the !ser
interface by sim!lating a !serJs
inp!t and reading data from the
screen display,

Data Integration

Integration Patterns
Contents
/onte&t
Problem
8orces
Sol!tion
-&ample
%es!lting /onte&t
Testing /onsiderations
Sec!rity /onsiderations
%elated Patterns
245450494.doc 97 od 257
cknowledgments
Conte.t
-nterprise information systems are comprised of a variety of data storage systems, which vary in comple&ity
and in the ways they access internal data, n e&ample of a simple data storage system is a flat file, n e&ample
of a far more comple& data storage system is a Database Management System 'D1MS( server farm,
Problem
)ow do yo! integrate information systems that were not designed to work togetherC
/orces
Most enterprises contain m!ltiple systems that were never designed to work together, The b!siness
!nits that f!nd these information systems are primarily concerned with f!nctional re?!irements rather than
technical architect!res, 1eca!se information systems vary greatly in terms of technical architect!re,
enterprises often have a mi& of systems, and these systems have incompatible architect!res,
Many applications are organi9ed into three logical layers: presentation, b!siness logic, and data,
*hen yo! integrate m!ltiple systems, yo! !s!ally want to be as noninvasive as possible, ny change
to an e&isting prod!ction system is a risk, so it is wise to try to f!lfill the needs of other systems and !sers
while minimi9ing dist!rbance to the e&isting systems,
Likewise, yo! !s!ally want to isolate applicationsJ internal data str!ct!res, +solation means that
changes to one applicationJs internal str!ct!res or b!siness logic do not affect other applications, *itho!t
isolated data str!ct!res, a small change inside an application co!ld ca!se a ripple effect and re?!ire
changes in many dependent applications,
%eading data from a system !s!ally re?!ires little or no b!siness logic or validation, +n these cases, it
can be more efficient to access raw data that a b!siness layer has not modified,
Many pree&isting applications co!ple b!siness and presentation logic so that the b!siness logic is not
accessible e&ternally, +n other cases, the b!siness logic may be implemented in a specific programming
lang!age witho!t s!pport for remote access, 1oth scenarios limit the potential to connect to an
applicationJs b!siness logic layer,
*hen making !pdates to another applicationJs data, yo! sho!ld generally take advantage of the
applicationJs b!siness logic that performs validations and data integrity checks, Ho! can !se Functional
Integration to integrate systems at the logical b!siness layer,
Direct access to an applicationJs data store may violate sec!rity policies that are fre?!ently
implemented in an applicationJs b!siness logic layer,
The availability of commercial tools can infl!ence the integration strategy between applications,
/ommercial tools !s!ally carry a lower risk and e&pense when compared to a c!stom sol!tion,
Solution
+ntegrate applications at the logical data layer by allowing the data in one application 'the so!rce( to be
accessed by other applications 'the target(, as shown in 8ig!re 6,
245450494.doc 98 od 257
/igure 11 Integrating applications at the logical data layer
To connect applications at the logical data layer, !se one or more of the following patterns:
S"ared &ata%ase, ll applications that yo! are integrating read data directly from the same database,
Maintain &ata (opies, Maintain copies of the applicationJs database so that other applications can read
the data 'and potentially !pdate it(,
File Transfer, Make the data available by transporting a file that is an e&tract from the applicationJs
database so that other applications can load the data from the files,
*hen yo! are implementing &ata Integration, yo! !s!ally have to consider the following design tradeoffs:
%atency tolerance, Some forms of data integration imply a delay between !pdates to the data that is
!sed by m!ltiple applications, 8or e&ample, in the Data %eplication pattern LTeale4;N, the data is e&tracted
from the so!rce system, and it is transported over a network, The data might then be modified, and then it
is inserted in a target database, This delay means that one system may have access to data that is more
!p to date than another system, This latency in propagating data can play an important role in integration,
Push 7ersus pull, *hen accessing a data so!rceJs database, a system can either p!ll the data from
the database or let the database itself p!sh the data when a change occ!rs, P!ll approaches are generally
less intr!sive, while p!sh approaches minimi9e latency,
Granularity, "etting a larger ch!nk of information at one time is generally more efficient than
propagating each small change by itself, This re?!ires an !nderstanding of the cohesion between m!ltiple
data entities, +f one entity changes, are other entities also likely to be affectedC
2asterBsubordinate relationships, +f !pdates are made only to one applicationJs data, propagating
these changes is relatively simple, )owever, if m!ltiple applications are allowed to !pdate the information,
yo! can r!n into diffic!lt synchroni9ation iss!es, 8or a more detailed description of synchroni9ation iss!es,
see the Master<Master %eplication pattern LTeale4;N,
Synchroni>ation logic 7ersus latency, 8or geographically dispersed applications, sharing a single
database may ca!se e&cessive network latency, To overcome this problem, yo! can !se distrib!ted
databases that contain copies of the same data, )owever, distrib!ted databases add the additional
comple&ity of synchroni9ation and replication logic,
5.ample
245450494.doc 99 od 257
There are many real<life e&amples of &ata Integration, 8or e&ample, an order entry application may store a
copy of prod!ct codes that reside in the -nterprise %eso!rce Planning '-%P( system, +f prod!ct codes do not
change very fre?!ently, the data from the so!rce 'the -%P system( may be synchroni9ed daily or weekly with
the data on the target 'the order<entry application(,
Resulting Conte.t
fter yo! decide to !se &ata Integration0 yo! m!st then choose a partic!lar kind of data integration that is
appropriate for yo!r sit!ation, Ho!r choices are s!mmari9ed by the following patterns:
S"ared &ata%ase
Maintain &ata (opies
File Transfer
Shared Database
The S"ared &ata%ase approach is shown in 8ig!re 3, S"ared &ata%ase aims to eliminate latency by allowing
m!ltiple applications to access a single physical data store directly, This approach is more intr!sive beca!se yo!
!s!ally have to modify some applications to !se a common schema,
/igure !1 Shared Database
%eading data directly from a database is generally harmless, b!t writing data directly into an applicationJs
database risks corr!pting the applicationJs internal state, ltho!gh transactional integrity mechanisms protect
the database from corr!ption thro!gh m!ltiple conc!rrent !pdates, they cannot protect the database from the
insertion of bad data, +n most cases, only a s!bset of data<related constraints is implemented in the database
itself, =ther constraints are likely to be contained in the b!siness logic, This distrib!tion of data constraints
allows other applications to leave the database in a state that the application logic considers to be invalid, 8or a
more detailed description, see Martin 8owlerJs S"ared &ata%ase pattern in )ohpe and *oolfJs Enterprise
Integration Patterns L)ohpe45N,
2aintain Data Copies
245450494.doc 100 od 257
+nstead of sharing a single instance of a database between applications, yo! can make m!ltiple copies of the
database so that each application has its own dedicated store, To keep these copies synchroni9ed, yo! copy
data from one data store to the other,
This approach is common with packaged applications beca!se it is not intr!sive, )owever, it does imply that at
any time, the different data stores are slightly o!t of synchroni9ation d!e to the latency that is inherent in
propagating the changes from one data store to the ne&t, 8ig!re ; shows the &ata /eplication pattern, which is
a derivative of Maintain &ata (opies,
/igure $1 Data Replication
The mechanisms involved in maintaining these copies are comple&, &ata Patterns disc!sses these mechanisms
in a cl!ster of 63 data movement patterns LTeale4;N that !se Maintain &ata (opies as a root pattern, The other
patterns in the g!ide incl!de the following:
Mo!e (opy of &ata
&ata /eplication
MasterMaster /eplication
MasterSla!e /eplication
MasterMaster /ow#e!el Sync"roni6ation
MasterSla!e Snaps"ot /eplication
(apture Transaction &etails
MasterSla!e Transactional Incremental /eplication
Implementing MasterMaster /ow #e!el Sync"roni6ation Using S9# Ser!er
Implementing MasterSla!e Snaps"ot /eplication Using S9# Ser!er
MasterSla!e (ascading /eplication
8or more details abo!t these patterns, see &ata Patterns on MSD.
'http:>>msdn,microsoft,com>architect!re>patterns>defa!lt,asp&Cp!llV>library>en<!s>dnpatterns>html>Dp,asp(,
/ile Trans&er
+n the File Transfer pattern, one application prod!ces a file and transfers it so that other applications can
cons!me it, 1eca!se files are a !niversal !nit of storage for all enterprise operating systems, this method is
245450494.doc 101 od 257
often simple to implement, The disadvantage of this method is that two applications can lose synchroni9ation
with each other beca!se each one is changing the file independently, 8or more information, see Martin 8owlerJs
File Transfer pattern L)ohpe45N,
Choosing #etween Alternati7es
There are many factors to consider when yo! choose the kind of data integration that is best for yo!r partic!lar
re?!irements, Some of those factors incl!de:
Tolerance for data that is not c!rrent 'stale data(
Performance
/omple&ity
Platform infrastr!ct!re and tool s!pport
fter yo! p!ll data from a transactional system, the data is effectively stale, *hen yo! attempt to modify the
data, yo! enco!nter potential contention and conflict resol!tion logic, +f yo!r conflict resol!tion logic is simple,
and if yo! can accommodate relatively long time intervals with stale data, File Transfer may be the best way to
integrate data,
+f yo!r conflict resol!tion logic is more comple&, and if yo! have less tolerance for stale data, consider S"ared
&ata%ase or Maintain &ata (opies, 1efore deciding on one or the other, consider yo!r performance needs,
+f yo!r applications and databases are located in the same data center, then S"ared &ata%ase enables yo! to
!se transaction managers to enforce data consistency, $sing transaction managers to enforce data consistency
limits stale data, )owever, if yo! have too many applications accessing the same data, the database may
become a performance bottleneck for yo!r system,
Maintaining m!ltiple copies of the same data red!ces the performance bottleneck of a single database, b!t it
creates stale data between synchroni9ations, lso, if yo!r application is geographically distrib!ted, sharing one
single database creates e&cessive network latency and affects performance, Maintain &ata (opies also presents
its own operations challenges, )owever, yo! can red!ce the effort associated with maintaining m!ltiple copies
by !sing the synchroni9ation and replication capabilities that are b!ilt into many D1MSs,
s yo! can see, each form of data integration has advantages and disadvantages, /hoosing the right kind of
data integration depends on the factors that are most important to yo!r organi9ation and on achieving the right
balance among the tradeoffs,
#ene&its
%egardless of the type of data integration yo! choose, the benefits are as follows:
,onintrusi7e, Most databases s!pport transactional m!lti!ser access, ens!ring that one !serJs
transaction does not affect another !serJs transaction, This is accomplished by !sing the +solation property
of the tomicity, /onsistency, +solation, and D!rability '/+D( properties set, +n addition, many
applications permit yo! to prod!ce and cons!me files for the p!rpose of data e&change, This makes &ata
Integration a nat!ral choice for packaged applications that are diffic!lt to modify,
245450494.doc 102 od 257
3igh bandwidth, Direct database connections are designed to handle large vol!mes of data,
Likewise, reading files is a very efficient operation, )igh bandwidth can be very !sef!l if the integration
needs to access m!ltiple entities at the same time, 8or e&ample, high bandwidth is !sef!l when yo! want
to create s!mmary reports or to replicate information to a data wareho!se,
Access to raw data, +n most cases, data that is presented to an end !ser is transformed for the
specific p!rpose of !ser display, 8or e&ample, code val!es may be translated into display names for ease of
!se, +n many integration scenarios, access to the internal code val!es is more !sef!l beca!se the codes
tend to more stable than the display val!es, especially in sit!ations where the software is locali9ed, lso,
the data store !s!ally contains internal keys that !ni?!ely identify entities, These keys are critical for
rob!st integration, b!t they often are not accessible from the b!siness or !ser interface layers of an
application,
2etadata, Metadata is data that describes data, +f the sol!tion that yo! !se for data integration
connects to a commercial database, metadata is !s!ally available thro!gh the same access mechanisms
that are !sed to access application data, The metadata describes the names of data elements, their type,
and the relationships between entities, ccess to this information can greatly simplify the transformation
from one applicationJs data format to another,
Good tool support, Most b!siness applications need access to databases, s a res!lt, many
development and deb!gging tools are available to aid in connecting to a remote database, lmost every
integration vendor provides a database adapter component that simplifies the conversion of data into
messages, lso, -&tract, Transform, and Load '-TL( tools allow the manip!lation of larger sets of data and
simplify the replication from one schema to another, +f straight data replication is re?!ired, many database
vendors integrate replication tools as part of their software platform,
%iabilities
%egardless of the type of data integration yo! choose, the liabilities are as follows:
"npublished schemas, Most packaged applications consider the database schema to be !np!blished,
This means that the software vendor reserves the right to make changes to the schema at will, sol!tion
based on &ata Integration is likely to be affected by these changes, making the integration sol!tion
!nreliable, lso, many software vendors do not doc!ment their database schemas for packaged
applications, which can make working with a large physical schema diffic!lt,
#ypassed business logic, 1eca!se data integration accesses the application data store directly, it
bypasses most of the b!siness logic and validation r!les incorporated into the application logic, This means
that direct !pdates to an applicationJs database can corr!pt the applicationJs integrity and ca!se the
application to malf!nction, -ven tho!gh databases enforce simple constraints s!ch as !ni?!eness or
foreign key relationships, it is !s!ally very inefficient to implement all application<related r!les and
constraints inside the database, Therefore, the database may consider !pdates as valid even tho!gh they
violate b!siness r!les that are encoded in the application logic, $se Functional Integration instead of &ata
Integration if yo! need the target application to enforce comple& b!siness r!les,
,o encapsulation, ccessing an applicationJs data directly provides the advantage of immediate
access to raw data, )owever, the disadvantage is that there is little or no encaps!lation of the applicationJs
f!nctionality, The data that is e&tracted is represented in the format of an application<internal physical
database schema, This data very likely has to be transformed before other applications can !se it, These
transformations can become very comple& beca!se they often have to reconcile str!ct!ral or semantic
differences between applications, +n e&treme scenarios, the data store may contain information in a format
that cannot be !sed by other systems, 8or e&ample, the data store might contain byte streams
representing seriali9ed b!siness obEects that cannot be !sed by other systems,
Simplistic semantics1 s the name s!ggests, &ata Integration enables the integration of data only,
8or e&ample, it enables the integration of data contained in entities s!ch as @/!stomer QHFJs ddress,@ +t is
not well<s!ited for richer command or event semantics s!ch as @/!stomer QHF Moved@ or @Place =rder,@
+nstead, !se Functional Integration for these types of integration,
Di&&erent storage paradigms, Most data stores !se a representation that is different from the
!nderlying programming model of the application layer, 8or e&ample, both relational databases and flat<file
formats !s!ally represent entities and their relationships in a very different way from an obEect<oriented
application, The difference in representation re?!ires a translation between the two paradigms,
Semantic dissonance, Semantic dissonance is a common problem in integration, -ven tho!gh yo!
can easily resolve syntactic differences between systems, resolving semantic differences can be m!ch more
diffic!lt, 8or e&ample, altho!gh it is easy to convert a n!mber into a string to resolve a syntactic
difference, it is more diffic!lt to resolve semantic differences between two systems that have slightly
different meanings for the Time, /!stomer, and %egion entities, -ven tho!gh two databases might contain
a /!stomer entity, the semantic conte&t of both entities might be dramatically different,
Testing Considerations
245450494.doc 103 od 257
Testing data integration sol!tions can be diffic!lt for a n!mber of reasons, incl!ding the following:
The direct access to the data so!rce and destination does not allow isolation of a specific f!nction, 8or
e&ample, !sing a test st!b or mock obEect does not allow isolation of a specific f!nction, +f the data
e&change !ses a file to transfer data, yo! can !se test files to test the data insertion,
+nserting data directly into the target database bypasses all or most b!siness logic, Therefore, testing
the insert itself may not be very meaningf!l beca!se it is likely to s!cceed, -ven if the data is inserted
s!ccessf!lly into the database, the data may violate another applicationJs b!siness logic, s a res!lt, the
complete application may have to be regression tested after yo! insert data directly into the application
data store,
1eca!se &ata Integration p!ts few constraints on the data to be inserted into an applicationJs data
store, a large data set may be re?!ired to provide appropriate coverage of all test cases,
Security Considerations
&ata Integration presents potential sec!rity iss!es that are worth considering:
Coarse4grained security, 1eca!se &ata Integration bypasses the application logic, it also bypasses
any sec!rity r!les that are enforced by the application logic, Many databases manage access privileges at
the table level, t the table level, a !ser either has access to the /!stomer table or the !ser does not have
access, Most applications enforce sec!rity at an obEect level, t the obEect level, a specific !ser has access
only to those c!stomer records that are associated with the !ser,
Pri7acy policies may not be en&orced, Many corporate databases are s!bEect to privacy policies
that are based on corporate or legal g!idelines, Directly accessing these data stores may be in violation of
these policies beca!se it is diffic!lt to control the ways the retrieved data may be !sed, +n comparison,
Functional Integration can offer restricted access to sensitive data to only allow ?!eries that do not e&pose
individ!al data, 8or e&ample, a f!nctional interface may allow the !ser to ?!ery the average compensation
in a specific region b!t not individ!al compensation,
Data may be encrypted, Data inside the database may be encrypted so that it is not accessible for
data integration !nless the integration sol!tion obtains the key to decrypt the data, Providing the key to
the data integration sol!tion co!ld present a sec!rity risk !nless the key is properly protected,
Related Patterns
8or more information, see the following related patterns:
8!nctional +ntegration, &ata Integration is !sed to e&tract data from or insert data into an e&isting
application, +f direct access to the data so!rce m!st be avoided, !se Functional Integration instead,
Functional Integration interfaces with an applicationJs b!siness logic,
&ata (onsistency Integration L%!h46N, +n cases where inserting data into an application is tied to
specific b!siness r!les and validations, straight data integration might not be the best sol!tion beca!se the
b!siness logic has to be re<created for the data insert operation, +n these cases, consider !sing Functional
Integration to achieve data consistency,
Ac-nowledgments
L1ritton46N 1ritton, /hris, IT $rc"itectures and MiddlewareGStrategies for )uilding #arge0 Integrated Systems,
ddison<*esley, 3446,
L)ohpe45N )ohpe, "regor, and 1obby *oolf, Enterprise Integration Patterns1 &esigning0 )uilding0 and
&eploying Messaging Solutions, ddison<*esley, 3445,
L%!h46N %!h, *illiam, Enterprise $pplication Integration. $ 2iley Tec" )rief, *iley, 3446,
245450494.doc 104 od 257
LTeale4;N Teale, Philip# /hristopher -t9, Michael 0iel, and /arsten Feit9, @Data Patterns,@.NET $rc"itecture
(enter, 2!ne 344;, vailable at: http:>>msdn,microsoft,com>architect!re>patterns>defa!lt,asp&,
/unctional Integration

Integration Patterns
Contents
/onte&t
Problem
8orces
Sol!tion
%es!lting /onte&t
Testing /onsiderations
Sec!rity /onsiderations
cknowledgments
Conte.t
-nterprise information systems contain a variety of applications that provide levels of interaction that range
from simple to comple&, The f!nctions that are incl!ded in these systems offer a variety of capabilities and
levels of access, from !ndoc!mented f!nctions and silo applications to f!lly developed composite applications,
+n addition, the mechanism for invoking a f!nction differs from one system to another,
Problem
)ow do yo! integrate information systems that were not designed to work togetherC
/orces
To correctly solve this problem, yo! need to consider the following forces:
Most enterprises contain m!ltiple systems that were never designed to work together, The b!siness
!nits that f!nd these information systems are primarily concerned with f!nctional re?!irements rather than
technical architect!res, 1eca!se information systems vary greatly in terms of technical architect!re,
enterprises often have a mi& of systems, and these systems have incompatible architect!res,
245450494.doc 105 od 257
Many applications are organi9ed into three logical layers: presentation, b!siness logic, and data,
Most commercial b!siness applications developed in the last decade provide stable doc!mented
programming interfaces to allow access to the b!siness f!nctionality that is incorporated in the application,
Software vendors provide these P+s specifically to s!pport integration with e&ternal software,
The f!nctional interfaces provided by an application typically abstract from the !nderlying data
representations so that they are more stable than the internal representations, 8or e&ample, while a
database schema might change in a new version of the software, the vendors keep the p!blic P+s
compatible with the previo!s version so that e&ternal applications accessing the P+ do not break,
ccessing a f!nction that resides in another application provides a nat!ral e&tension of the application
programming model that developers are !sed to, The semantics of accessing an e&ternal f!nction that
resides in another application are similar to making a local method call, This allows for nat!ral integration
with e&isting applications,
Making direct !pdates to another applicationJs data store thro!gh Data +ntegration bypasses all
b!siness and validation logic incorporated in the applicationJs b!siness logic layer, s a res!lt, the risk of
corr!pting an applicationJs data store is high,
-&changing messages between applications that incl!de both data and behavior can provide for a more
powerf!l conversation between systems, +nstead of sending a message that only contains a c!stomerJs
address, one system can instr!ct the other system to perform a specific f!nction, 8or e&ample, one system
can instr!ct another system to validate the c!stomerJs address or to !pdate a c!stomer record with the
c!stomerJs new address, More powerf!l conversations also allow an application to more specifically
describe the f!nctions and services it can provide to other applications,
Many programming interfaces are programming lang!age<specific and are not available remotely
!nless they have been developed on top of a specific remoting technology, s!ch as Microsoft ,.-T
8ramework remoting or /ommon =bEect %e?!est 1roker rchitect!re '/=%1(,
Solution
+ntegrate applications at the b!siness logic layer by allowing the b!siness f!nction in one application 'the
so!rce( to be accessed by other applications 'the target(, as shown in 8ig!re 6,
/igure 11 Integrating applications at the business logic layer
8or an e&ternal application to integrate with the so!rce application thro!gh Functional Integration, the following
two conditions m!st be met:
The b!siness f!nction that yo! want m!st be available inside the so!rce applicationJs b!siness logic,
The P+ of the so!rce application m!st be accessible remotely,
+f the desired b!siness f!nction is not available, yo! have to modify the so!rce application to make the f!nction
available, +f modifying the so!rce application is not feasible, yo! sho!ld add the new f!nction o!tside the
245450494.doc 106 od 257
so!rce application and then comm!nicate with the application thro!gh another form of integration, s!ch as
&ata Integration or Presentation +ntegration, This approach has fewer side effects and is generally available for
most types of applications,
Many applications only e&pose their b!siness f!nctions as a local P+ that is dependent on a specific
programming lang!age s!ch as /RR or /S, +n those cases, a local adapter or middleware interface has to be
created that translates incoming messages from other applications into local P+ calls, Likewise, res!lts from
P+ calls are translated back into messages, +n most cases, s!ch an adapter can be generic eno!gh to s!pport a
variety of different f!nctions witho!t having to be modified for each individ!al f!nction that yo! want to make
available e&ternally,
Functional Integration is very versatile beca!se many different operations can be performed tho!gh an P+,
f!nctional interface can retrieve data, !pdate data entities 'change an address(, or perform b!siness f!nctions
'validate a credit card(, +n fact, one common !se of Functional Integration is to ens!re data consistency
between applications L%!h46N,
Functional Integration is based on the interaction between the components that are described in Table 6,
Table 1 /unctional Integration Components
Components Responsibilities Collaborators
1!siness logic -&ec!tes local b!siness f!nctions Middleware interface
Middleware interface < /onverts incoming messages into
method invocations of f!nctions
that reside in the b!siness logic
< /onverts ret!rn data back into
messages that can be transported
across the network
1!siness logic and remote application
%emote application /ons!mes f!nctions that reside in
the application
Middleware interface
Resulting Conte.t
fter yo! decide to !se Functional Integration0 yo! m!st choose a partic!lar kind of integration that is
appropriate for yo!r sit!ation, Ho!r choices are s!mmari9ed by the following patterns:
&istri%uted -%8ect Integration
Message-riented Middleware Integration
Ser!ice-riented Integration 'thro!gh QML<based *eb services(
Distributed =b+ect Integration
&istri%uted -%8ect Integration is also known as instance<based collaboration beca!se it e&tends the model of
obEect<oriented comp!ting to distrib!ted sol!tions, =bEects inside one application interact with obEects in
another remote application in the same way that they wo!ld interact locally with another obEect, This implies
245450494.doc 107 od 257
that the interaction occ!rs with a specific obEect instance and that the client application often manages the
lifetime of the obEect it is accessing, This type of interaction !s!ally seems nat!ral to application developers,
b!t it can res!lt in a comple& and tightly<co!pled interaction model between the components, This tight
co!pling is not a problem as long as the components are part of a single distrib!ted application, )owever, it is
generally not a good choice when integrating m!ltiple stand<alone applications,
"reat e&amples of distrib!ted component middleware are technologies s!ch as ,.-T remoting, /=MR, or
/=%1, 8or more information, see the /emote Procedure In!ocation pattern L)ohpe45N or the @Distrib!ted
Systems@ chapter in -nterprise Sol!tion Patterns $sing Microsoft ,.-T LTrowbridge4;N,
2essage4=riented 2iddleware Integration
Message-riented Middleware Integration connects systems by !sing asynchrono!s message ?!e!es that are
based on proprietary message<oriented middleware, The connected systems then comm!nicate by !sing
messages that contain small packets of data, 1eca!se the comm!nication is asynchrono!s and d!rable, there is
little chance of the messages being lost d!ring network or system fail!re,
To share re?!est>response type f!nctionality, the cons!ming system m!st create a re?!est message and send it
by way of the message ?!e!e to the system that provides the f!nctionality, The provider then takes the
message from the ?!e!e, interprets it as a re?!est, and processes it, $pon completion, the provider creates a
response message and sends it back to the f!nctional cons!mer by way of the message ?!e!e, =f co!rse, not
all f!nctionality is shared by !sing a re?!est>response style collaboration, b!t similar principles apply, 8or more
information, see the Messaging pattern L)ohpe45N,
Ser7ice4=riented Integration
Service<=riented +ntegration connects systems by enabling them to cons!me and provide QML<based *eb
services, The interfaces to these systems are described thro!gh *eb Services Definition Lang!age '*DSL(
contracts, Systems interact with each other by !sing S=P messages, S=P messages are !s!ally conveyed
thro!gh )TTP by !sing QML seriali9ation,
,ote The term ser!ice is !sed in many different ways in the conte&t of software engineering, +t is also !sed in
at least seven levels of scope: operating system, process, obEect, distrib!ted obEect, proprietary message<
oriented middleware, logical, and QML *eb services, This g!ide !ses the term ser!ice to mean QML *eb
services !nless indicated otherwise,
Service +nterface LTrowbridge4;N e&poses f!nctionality as a *eb service, and, a Service "ateway
encaps!lates the logic necessary to cons!me services 'see 8ig!re 3(,
245450494.doc 108 od 257
/igure !1 "sing a ser7ice gateway and ser7ice inter&ace to connect a Web ser7ice consumer and
pro7ider
$sing Ser!ice-riented Integration increases interoperability by !sing QML and QML Schema as the basis of
message e&change and by !sing S=P as an e&tensible messaging framework, QML Schema provides for a type
system that is portable between disparate technical architect!res, +n contrast, S=P can be bo!nd to a n!mber
of different transport mechanisms, 8or more information, see Ser!ice-riented Integration,
Choosing #etween Alternati7es
There are many factors to consider when choosing the kind of Functional Integration that is best for yo!r
partic!lar re?!irements, Some of these factors incl!de:
%eliability and latency of the network between endpoints
+nterfaces e&posed by yo!r c!rrent systems
.eed for interoperability between disparate technical architect!res
Performance
8ragility, if incompatible !pdates are introd!ced to any participant
-&pertise of the technical team
-&isting infrastr!ct!re
Choosing Distributed =b+ects
+f yo!r team is proficient with obEect<oriented development and if yo! !se a platform infrastr!ct!re that offers a
1roker s!ch as ,.-T 8ramework remoting, &istri%uted-%8ect Integration can be fairly simple to implement,
ltho!gh the remote interface is almost as easy to manip!late as the local interface, yo! m!st always consider
network latency, network fail!re, and distrib!ted systems fail!res, Ho! m!st develop a significant amo!nt of
error detection and correction logic to anticipate these impacts, *ith high<latency network ro!nd trips, yo!
want to avoid a large n!mber of fine<grained method invocations, Therefore, !se /emote Facade L8owler4;N
and Data Transfer =bEect LTrowbridge4;N to optimi9e call gran!larity and payload si9e,
This kind of integration works best when the systems that yo! want to connect are located in the same data
center and when those systems have fairly reliable and high<speed connections, This kind of integration does
not work well across slow and !nreliable connections, incl!ding any connection that !ses the +nternet, This kind
of integration is fragile if incompatible !pdates are introd!ced to any of the participants, =f co!rse, if the target
system yo! want to integrate with only e&poses obEect<based P+s, yo! m!st !se this method or an adapter to
connect,
Choosing 2essage4=riented 2iddleware Integration
Message-riented Middleware Integration is an e&cellent choice when systems are not reliably connected
beca!se there is the potential for network fail!re or distrib!ted systems fail!re, 1eca!se Message-riented
Middleware Integration works by placing messages asynchrono!sly into a d!rable ?!e!e, there is little chance
that the messages co!ld be lost d!ring a system or network fail!re, +n addition, !sing asynchrono!s
comm!nication deco!ples the sender from the receiver, The application that sends the messages will contin!e
245450494.doc 109 od 257
to f!nction even if the receiver fails, and the failed message receiver will contin!e processing messages from
the ?!e!e after the receiver is restored,
The sender and the receivers are also deco!pled from each other beca!se they !se a common message format,
This makes it easier to separate the message from the set of intended receivers in the enterprise, fter a
message is sent from a so!rce, yo! can design an integration network that !ses the Message )ro'er pattern,
the Message )us pattern, the Pu%lis"*Su%scri%e pattern, or a host of other message receivers witho!t
modifying the original message sender, This allows the so!rce, distrib!tion, and cons!mption of the message to
vary independently, th!s improving fle&ibility,
=f co!rse, there are tradeoffs involved with !sing Message-riented Middleware, ltho!gh the programming
model is fairly simple for &istri%uted-%8ect Integration, the programming model becomes m!ch more comple&
for Message-riented Middleware, Messages arriving at endpoints become events# therefore, the programming
model is event driven, +n addition, these events arrive across networks that may be !nreliable and that do not
have implicit correlation between them, The order of message arrival is not necessarily g!aranteed and there
may be d!plicate messages, Sometimes, processing d!plicate messages 'also known as idempotent messages(
does not adversely affect yo!r system, =ther times, processing d!plicate messages is a serio!s flaw, for
e&ample, when yo! are transferring money, The sec!rity conte&t of the message m!st be established, policies
m!st be applied, and tr!st bo!ndaries m!st be established, Ho!r partic!lar re?!irements m!st anticipate and
E!stify this additional comple&ity, +n addition, !sing proprietary message<oriented integration binds yo! to a
partic!lar message<oriented middleware implementation, +t m!st be installed on the endpoint yo! want to
comm!nicate with, which may not always be the case inside yo!r enterprise or between trading partners,
Ser7ice4=riented Integration
Most enterprises have heterogeneo!s technical architect!res and want to take advantage of system<based
collaboration over the +nternet, The most competitive enterprises want fle&ible and a!tomated b!siness
processes that may re?!ire technology independence, ll of these factors contrib!te to an !rgent re?!irement
for interoperability between different technical architect!res, The best way to design for interoperability is by
!sing Service<=riented +ntegration,
Like Message-riented Middleware Integration, Ser!ice-riented Integration !ses messages to comm!nicate
between senders and receivers, $nlike Message-riented Middleware, Ser!ice-riented Integration !ses QML
Schema and S=P to transport and resolve messages, These two standards provide a portable type system and
an e&tensible messaging framework that is not co!pled to any proprietary implementation or transport, +n
addition, Ser!ice-riented Integration recommends the *eb Services +ntegration '*S<+( 1asic Profile to ens!re
interoperability between endpoints,
Ser!ice-riented Integration enables interoperability and allows yo! to send both synchrono!s and
asynchrono!s messages 'for more information, see the Ser!ice-riented Integration pattern(, s a res!lt, yo!
can have the same kind of comple& programming model as Message-riented Middleware, +n addition, yo!
245450494.doc 110 od 257
have the comple&ity of a new and still emerging set of standards to !nderstand and comply with, Therefore,
make s!re yo!r re?!irements E!stify this level of comple&ity,
fter yo! b!ild these interoperable systems, there is one more tradeoff to consider: performance, $sing QML
inc!rs the cost of seriali9ing, deseriali9ing, and parsing QML doc!ments, +n addition, QML doc!ments are often
m!ch larger than their binary e?!ivalents beca!se they contain metadata, This can increase the si9e of the
payload that m!st be processed d!ring message e&changes, )owever, beca!se processing power is relatively
ine&pensive and beca!se processors get faster every year, the iss!e of payload si9e can be addressed tho!gh
hardware, lso, yo! can selectively trade interoperability for performance by !sing binary encoding inside yo!r
S=P message as needed, 8inally, given the s!pport of maEor vendors, it is likely that new platform
infrastr!ct!re will evolve in a way that will optimi9e *eb servicesGbased performance,
Combining Distributed =b+ects: 2essage4=riented 2iddleware: and Ser7ices
+t is likely yo! will !se some combination of all three types of integration in yo!r enterprise, Start by identifying
services at a level of gran!larity that is meaningf!l to the b!siness, s!ch as steps within a b!siness process,
This will help yo! define service bo!ndaries where interoperability is important, 8or interactions across these
bo!ndaries, !se Ser!ice-riented Integration, 8or an e&ample of service identification, see /hapter M,
@+ntegration -&amples,@ To implement a service within these bo!ndaries, yo! may want to !se &istri%uted
-%8ect Integration, Message-riented Middleware Integration, or Ser!ice-riented Integration, +f yo! need to
do two<phase commits across distrib!ted databases, !sing &istri%uted-%8ect Integration permits yo! to take
advantage of platform infrastr!ct!re that s!pports two<phase commits across distrib!ted databases, 2!st
ens!re that yo! keep these transactions inside yo!r service bo!ndaries,
ny time yo! connect with systems and networks that yo! consider to be !nreliable, consider !sing Message
-riented Middleware to provide a d!rable b!ffer between connected systems, $sing messages as yo!r means of
comm!nication, either thro!gh Message-riented Middleware or Ser!ice-riented Integration, permits yo! to
constr!ct more advanced integration architect!res that !se Message )ro'er and Message )us to comm!nicate,
s needed, yo! can always connect these integration architect!res by !sing obEect<based P+s as described by
the $dapter pattern L"ammaMAN,
%egardless of the kind of Functional Integration yo! !se, yo! will enco!nter the following benefits and liabilities,
#ene&its
/le.ibility, Functional Integration is very fle&ible, The abstraction, in the form of a f!nction call,
permits many different types of interchanges, s!ch as data replication, shared b!siness f!nctions, or
b!siness process integration, This also implies that a generic mechanism for Functional Integration can be
!sed in many different integration scenarios,
5ncapsulation, f!nctional interface provides an abstraction from an applicationJs internal workings,
This isolates !sers of the programming interface from variations in the applicationJs internal workings or
data representations,
Robust, -&ec!ting a f!nction thro!gh an applicationJs b!siness logic layer ens!res that only well<
defined f!nctions can be e&ec!ted, +t also ens!res that all validations b!ilt into the application logic are
e&ec!ted, This ens!res that other applications cannot perform invalid f!nctions or corr!pt the applicationJs
internal state,
245450494.doc 111 od 257
/amiliar programming model, Functional Integration provides a programming model that is more
aligned with widespread application programming models, Functional Integration is therefore familiar to
most application developers, =ther styles of integration, s!ch as &ata Integration or Presentation
Integration, re?!ire developers to learn a new style of development,
%iabilities
Tighter coupling, =ne application that sends a command directly to another application res!lts in
tighter co!pling compared to p!blishing data to a common Message )us beca!se the re?!esting application
re?!ires information abo!t the location of the application that is providing the service, )owever, inserting a
Message )ro'er can alleviate this type of co!pling,
Re0uires business layer to be e.posed, .at!rally, Functional Integration is limited to scenarios
where the affected applications e&pose a s!itable f!nctional interface, This is the case for most
contemporary b!siness applications, b!t it may not be tr!e for older monolithic applications or for *eb
applications hosted by e&ternal entities, +n those cases, Presentation Integration may be the only option,
%imited to a7ailable &unctions, +n most cases, Functional Integration is limited to the f!nctions that
are already implemented in the applicationJs b!siness logic, -&tending the applicationJs logic with new
f!nctions !s!ally involves significant development and may o!tweigh the other benefits of Functional
Integration, +n s!ch cases, implementing the new f!nction e&ternally might be a more efficient approach,
Ine&&icient with large datasets, -&isting f!nctional interfaces are generally designed to e&ec!te
individ!al f!nctions, This typically makes them inefficient for the transmission of large datasets beca!se
many individ!al re?!ests m!st be made,
Programming4language speci&ic, Many f!nctional interfaces are tied to a specific programming
lang!age or technology beca!se the stronger semantics of the conversation re?!ire a more detailed
contract that incl!des the representation of method names, comple& data str!ct!res, ret!rn val!es,
e&ceptions, and other elements,
Testing Considerations
Functional Integration is easier to test than other integration approaches for the following reasons:
The additional abstraction provided by the separation of the e&posed f!nctional interface and the
internal e&ec!tion of the f!nction permits the creation of mock obEects and test st!bs, These constr!cts
work with the e&ternal applications in the same way the f!ll application does beca!se they implement the
same interface, )owever, the test st!b or mock obEect !s!ally does not perform act!al b!siness f!nctions
that may be slow or that may re?!ire many e&ternal reso!rces, +nstead, the st!b fabricates response data,
or it logs data into a logging mechanism that can be monitored by the test tools,
1eca!se Functional Integration is based on the same programming model as the application itself,
tests of the integration are easier to tie to the testing of the application itself, This type of testing is also
generally well<s!pported by test tools s!ch as .$nit that target application testing,
)owever, yo! m!st consider the following considerations, Ho!r ability to test depends on how well the f!nctional
interface of the e&isting application is str!ct!red, +f the interface e&poses f!nctions that are well<defined and
that are free of side effects free, testing sho!ld be relatively easy, +f the f!nctional interface consists of a bl!r of
poorly defined f!nctions that are f!ll of side effects, then testing will be diffic!lt,
Security Considerations
The richer semantics of Functional Integration allow for a more finely grained sec!rity model, Many applications
enforce sec!rity r!les based on !ser identity, and they control permissions on an obEect level, 8or e&ample, a
!ser is only allowed to access the acco!nts that belong to that !ser and to access related acco!nts, This type of
permission checking is typically not available with &ata Integration,
245450494.doc 112 od 257
The disadvantage of this more comple& sec!rity model is that the integration sol!tion has to ac?!ire the proper
!ser credentials to access data or to invoke f!nctions, 1eca!se other applications are generally !naware of the
sec!rity conte&t !sed in another application, the sec!rity conte&t has to be established by the middleware, Ho!
can establish the sec!rity conte&t either by !sing a fi&ed !ser or by !sing an e&plicit translation of sec!rity
conte&ts between applications,
Ac-nowledgments
L)ohpe45N )ohpe, "regor, and 1obby *oolf, Enterprise Integration Patterns1 &esigning0 )uilding0 and
&eploying Messaging Solutions, ddison<*esley, 3445,
LLinthic!m45N Linthic!m, David, Ne:t Generation $pplication Integration, ddison<*esley, 344;,
L%!h46N %!h, *illiam, Enterprise $pplication Integration. $ 2iley Tec" )rief, *iley, 3446,
LTrowbridge4;N Trowbridge, David# Dave Mancini, Dave B!ick, "regor )ohpe, 2ames .ewkirk, and David
Lavigne, Enterprise Solution Patterns Using Microsoft .NET. Microsoft Press, 344;, lso available on the MSD.
rchitect!re /enter at: http:>>msdn,microsoft,com>architect!re>patterns>defa!lt,asp&Cp!llV>library>en<
!s>dnpatterns>html>-sp,asp,
L*;/45N @*eb Services rchitect!re *;/ *orking Draft 66 8ebr!ary 3445,@ vailable on the *;/ *eb site at:
http:>>www,w;,org>T%>3445>.=T-<ws<arch<34454366>
Ser7ice4=riented Integration

Integration Patterns
Contents
/onte&t
Problem
8orces
Sol!tion
-&ample
%es!lting /onte&t
245450494.doc 113 od 257
Sec!rity /onsiderations
%elated Patterns
cknowledgments
Conte.t
Ho!Jve decided to !se the 8!nctional +ntegration pattern to integrate information systems that were not
designed to work together, Ho! need interoperability among systems b!ilt with different technical architect!res,
+n addition, the systems that yo! want to integrate may not be reliably connected,
Problem
)ow do yo! integrate applications at the b!siness logic layerC
/orces
+ntegrating systems at the b!siness logic layer involves balancing the following forces:
2achine boundaries are important, The idea that yo! can take a local obEect interface and e&tend
it across machine bo!ndaries to create location transparency is flawed, ltho!gh it is tr!e that both the
remote obEects and the local obEects have the same interface from the perspective of the calling process,
the behavior of the called interface is ?!ite different depending on location, 8rom the client perspective, a
remote implementation of the interface is s!bEect to network latency, network fail!re, and distrib!ted
system fail!res that do not e&ist with local implementations, significant amo!nt of error detection and
correction logic m!st be written to anticipate the impacts of !sing remote obEect interfaces,
Coupling a&&ects interoperability, +ntegrating at the logical b!siness layer involves sharing
f!nctionality, Sharing f!nctionality implies some level of co!pling between the cons!mer and the provider
of the f!nctionality, There are many forms of co!pling, These forms of co!pling incl!de the following:
Temporal coupling, Temporal co!pling occ!rs d!ring the re?!est for f!nctionality, +f the
re?!est is synchrono!s, the calling system m!st wait for the provider to finish processing the re?!est
before it can contin!e, +f the re?!est is asynchrono!s, the calling system can contin!e processing
after it makes the re?!est while the providing system independently contin!es to process the re?!est,
+n terms of time, the asynchrono!s call is more loosely co!pled than the synchrono!s call,
Type4system coupling, Type<system co!pling occ!rs when a process m!st associate the
name of a type with its binary representation on the host comp!ter, This association may be as simple
as an integer, meaning a big<endian 5<byte primitive on one comp!ter and a 3<byte little<endian
primitive on another, =f co!rse, !ser<defined types s!ch as a c!stomer obEect become m!ch more
comple&, *hen two systems interoperate, they m!st share a common type representation# in this
sense they are co!pled together, Most implementation platforms do not share the same type
representation,
Dependency coupling, Dependency co!pling occ!rs when one e&ec!table depends on other
e&ec!tables to r!n, +f the e&ec!table cannot resolve its dependencies at r!n time, the e&ec!table fails,
+n this sense, the e&ec!table and its dependencies are co!pled together,
To integrate disparate systems, yo! m!st resolve potential differences in type systems and e&ec!tion
dependencies, Ho! m!st also decide whether yo! want the calling thread of e&ec!tion to block when
making a re?!est to the provider,
Coupling and Inter&ace De&inition %anguage, -ven when the type system is described !sing an
+nterface Definition Lang!age '+DL(, platform infrastr!ct!re code m!st be installed on the host comp!ter
that interprets the +DL, 8or e&ample, if yo! are !sing /ommon =bEect %e?!est 1roker rchitect!re
'/=%1(, infrastr!ct!re s!ch as an =bEect %e?!est 1roker '=%1( m!st be installed on the host comp!ter
for a system to resolve the /=%1 +DL types, Two /=%1<based systems that are installed on different
245450494.doc 114 od 257
hardware platforms and operating systems can interoperate, b!t they both remain co!pled to the /=%1
type specification and binary mappings,
Coupling and message4oriented middleware, Type<system co!pling also occ!rs when !sing
proprietary message<oriented middleware, To resolve message formats, each endpoint m!st contain an
installation of the appropriate message<oriented middleware, ltho!gh a partic!lar message<oriented<
middleware prod!ct may be ported to m!ltiple platforms, any endpoint yo! want to comm!nicate with
m!st also have the same message<oriented middleware prod!ct installed,
Portable type system, Most enterprise systems can process QML, 8rom the perspective of type<
system co!pling, the only primitive that m!st be agreed !pon is a string, fter the incoming byte stream is
interpreted as a string b!ffer, the string can be parsed according to QML specifications, incl!ding QML
schema, +n t!rn, the schema provides a type system that is highly portable between disparate hardware
and operating systems,
Contracts, /ontracts have proven to be an e&cellent means of specifying behavior between a
cons!mer and a provider of services,
Solution
To integrate applications at the b!siness logic layer, enable systems to cons!me and provide QML<based *eb
services, $se *eb Services Description Lang!age '*SDL( contracts to describe the interfaces to these systems,
-ns!re interoperability by making yo!r implementation compliant with the *eb Services family of specifications
'for e&ample, the *eb Services Sec!rity L*S<Sec!rityN specification(, 8or more information abo!t the *eb
Services specifications, see @Specifications@ in the *eb Services Developer /enter on MSD.
'http:>>msdn,microsoft,com>webservices>!nderstanding>specs>defa!lt,asp&(, *henever possible, !se the
doc!ment message style and literal seriali9ation 'see @$se Doc!ment>Literal S=P Styles and -ncoding@ later in
this pattern(,
,ote The term ser!ice is !sed in many different ways in the conte&t of software engineering, +t is also !sed in
at least seven levels of scope: operating system, process, obEect, distrib!ted obEect, proprietary message<
oriented middleware, logical, and QML *eb services, This g!ide !ses the term ser!ice to mean QML *eb
services !nless indicated otherwise,
To e&pose e&isting f!nctionality as a *eb service, !se the Service +nterface pattern LTrowbridge4;N, To
encaps!late the logic necessary to cons!me services, !se the Service "ateway pattern LTrowbridge4;N, 8ig!re 6
shows the design elements involved in this interaction,
/igure 11 "sing Ser7ice Gateway and Ser7ice Inter&ace to connect a Web ser7ice consumer and
pro7ider
+n addition to following the *eb Services specifications, yo! sho!ld also refer to the *eb Services
+nteroperability '*S<+( profiles when yo! design and b!ild *eb services, 8or more information abo!t *S<+, see
the *eb Services +nteroperability =rgani9ation *eb site 'http:>>www,ws<i,org(, 8or g!idance abo!t how to b!ild
*eb services that are compliant with the *S<+ basic profile, see )uilding Interopera%le 2e% ser!ices1 2SI
245450494.doc 115 od 257
)asic Profile ;.4 on MSD. 'http:>>msdn,microsoft,com>library>defa!lt,aspC!rlV>library>en<
!s>dnsvcinter>html>wsi<bpTmsdnTlandingpage,asp(,
Web Ser7ices
*hat e&actly is a *eb serviceC ccording to the *orld *ide *eb /onsorti!m '*;/(,
@a *eb service is a software system designed to s!pport interoperable machine<to<machine interaction over a
network, +t has an interface described in a machine<processable format 'specifically *SDL(, =ther systems
interact with the *eb service in a manner prescribed by its description !sing S=P<messages, typically
conveyed !sing )TTP with an QML seriali9ation in conE!nction with other *eb<related standards,@ L*;/45N
+n terms of interaction, two systems !se *eb services to comm!nicate when a re?!esting application creates
an QML doc!ment in the form of a message and sends it over the network to a provider of *eb services,
=ptionally, the provider sends a reply to the re?!ester in the form of an QML doc!ment, *eb services standards
specify the interface that the message is sent to, the format of the message, the mapping of the message
contents to service implementations, the optional headers, and the means by which services can p!blish and
discover other *eb services,
Resol7ing the /orces
)ow does !sing *eb services to integrate systems resolve the forces mentioned earlierC 8irst, basing yo!r
messages on QML and QML Schema definition lang!age 'QSD( res!lts in a highly portable type system as
e&plained earlier, portable type system dramatically red!ces type<system co!pling, Type<system co!pling is a
maEor impediment to cross<platform integration, )owever, to take f!ll advantage of this portable type system,
yo! m!st !nderstand S=P styles and encoding,
"se DocumentB%iteral S=AP Styles and 5ncoding
The *SDL 6,6 specification identifies two message styles 'doc!ment and %emote Proced!re /all L%P/N( and two
means of seriali9ing the message onto the transport mechanism 'S=P encoding and QML Schema(, /hoosing
the right combination of style and seriali9ation have maEor impact on the interoperability of yo!r *eb service,
The doc!ment message style indicates that the message body contains an QML doc!ment, +t is !p to the
service cons!mer and the service provider to agree on the doc!ment e&changed, The %P/ style indicates that
the message body will contain an QML representation of an %P/,
To seriali9e the message data, the QML SchemaGbased seriali9ation simply !ses the definitions contained in the
QML Schema specification, 1eca!se !sing QML Schema res!lts in a highly portable type system, the messages
are highly interoperable, )owever, the S=P<encoded seriali9ation !ses encoding r!les that re?!ire %P/<style
comm!nication, Since the details of %P/ comm!nication can vary significantly between implementations, the
res!lting messages are not as easily interoperable,
s a res!lt of these interoperability concerns, !se doc!ment<style messages with literal encoding 'doc>literal(
whenever possible, 8or more information abo!t this topic, see @$nderstanding Soap@ on MSD.
245450494.doc 116 od 257
'http:>>msdn,microsoft,com>webservices>!nderstanding>webservicebasics>defa!lt,asp&Cp!llV>library>en<
!s>>dnsoap>html>!nderstandsoap,asp(,
Combine Synchronous and Asynchronous #eha7ior to Address Temporal Coupling
To address temporal co!pling, it is possible to invoke *eb services both synchrono!sly and asynchrono!sly, To
!nderstand how to do this in the conte&t of *eb services, yo! m!st !nderstand parts of the *SDL, S=P, and
*eb Service rchitect!re specifications,
To abstract comm!nication away from implementation notions s!ch as synchrono!s and asynchrono!s calls,
*SDL !ses the concept of message e&change patterns 'M-P( to describe generic patterns of message e&change
between endpoints, There are fo!r kinds of M-P described in *SDL 6,6, as shown in Table 6,
Table 1 /our 6inds o& 2essage 5.change Patterns ?25P@
25P name Description Type
%e?!est<response The endpoint receives a message
and then sends a correlated
message,
Synchrono!sX
=ne<way The endpoint receives a message, synchrono!s
Solicit<response The endpoint sends a message and
then receives a correlated
message,
Synchrono!sX
.otification The endpoint sends a message, synchrono!s
C This 25P emulates synchronous beha7ior with 3TTP P=STBG5T S=AP binding1
S=P provides an e&tensible one<way messaging framework between sender and receiver, To implement S=P,
however, yo! m!st bind it to a specific protocol, )TTP P=ST>"-T is the most common protocol, 1eca!se )TTP is
a synchrono!s protocol, if yo! !se the S=P>)TTP binding, yo! get the synchrono!s>asynchrono!s behavior
shown in 8ig!re 3,
+n cases where there are long<r!nning transactions across enterprises, a *eb service e&changes messages
synchrono!sly while the larger b!siness process that it r!ns within e&ec!tes asynchrono!sly, 8or e&ample,
consider the "lobal 1ank scenario,
Global #an-Ds Asynchronous #usiness Process
+n the -&ec!te Sched!led Payment !se case 'see /hapter 3 for more details(, "lobal 1ank sends international
payments thro!gh a Society for *orldwide +nterbank 8inancial Telecomm!nication 'S*+8T( payment gateway
by !sing *eb services over the +nternet, The message sent is an QML doc!ment containing the information
necessary for the payment gateway to electronically pay the payee identified in the doc!ment, This message is
sent synchrono!sly thro!gh )TTP, and the response only acknowledges a s!ccessf!l transmission, *hen the
s!ccessf!l transmission occ!rs, the payment gateway processes the message, and the calling system does not
wait for a response, fter the payment gateway has finished processing the payment, it sends another message
245450494.doc 117 od 257
to "lobal 1ank confirming the payment stat!s, This message is a synchrono!s )TTP re?!est>response, and the
response information only acknowledges a s!ccessf!l message transmission,
/igure !1 SWI/T payment gateway combining synchronous e.changes to simulate asynchronous
beha7ior
+n the -&ec!te Sched!led Payment !se case, two synchrono!s message e&changes participate in an
asynchrono!s b!siness collaboration, This effectively deco!ples the systems,
Recogni>e 5.plicit #oundaries
1eca!se *eb services pass doc!ments instead of %P/ calls, there is no attempt to consider that the location of
the service is transparent, +ndeed, the bo!ndary between the two services is e&plicitly recogni9ed, *ith e&plicit
bo!ndaries, the connection is not treated as reliable and available, as it wo!ld be treated with &istri%uted
-%8ect Integration, Ho! can !se other patterns s!ch as Server /l!stering, Load<1alanced /l!ster, and 8ailover
/l!ster LTrowbridge4;N to meet operational re?!irements when traversing these bo!ndaries,
Treat Ser7ices as Autonomous
*hen !sing services to integrate systems, yo! sho!ld consider two key elements: service interfaces and service
implementations, Service interfaces describe the f!nctionality, messages, and res!lts that the cons!mers of the
service can e&pect, /ontracts provide these interfaces in the form of *SDL files, Service implementations
contain the software that implements the service and all its e&ec!tion dependencies, with the possible
e&ception of other services,
245450494.doc 118 od 257
/ollaborations thro!gh service interfaces facilitate a high degree of interoperability in yo!r enterprise, The
services sho!ld be capable of being independently versioned, managed, and deployed, s these services are
deployed, all the appropriate e&ec!tion dependencies 'e&cept other services( sho!ld be deployed with the
service and contained within the service bo!ndary,
5.ample
8or detailed e&amples, see +mplementing Service<=riented +ntegration with SP,.-T and +mplementing Service<
=riented +ntegration with 1i9Talk Server 3445,
Resulting Conte.t
s a res!lt of implementing the Ser!ice-riented Integration pattern, the following tenets apply L1o&45N:
#oundaries are e.plicit, /rossing service bo!ndaries can be costly, 8or e&ample, yo! may need to
span geography, tr!st bo!ndaries, or e&ec!tion environments,, Ho! sho!ld therefore e&plicitly opt into
service orientation by formally passing defined messages between services, The e&plicit bo!ndaries allow
yo! to formally e&press implementation<independent interaction so that yo!r interactions do not depend on
the different platform, middleware, or coding lang!age choices !sed to implement other services,
Ser7ices are autonomous, There is no presiding a!thority in a service<oriented environment,
Services are independently deployed, versioned, and managed, The topology in which a service e&ec!tes
evolves over time, The service sho!ld e&pect that peer services will fail and that it will receive malformed
or malicio!s messages, The services sho!ld be b!ilt by !sing techni?!es s!ch as red!ndancy and failover
so that the services do not fail,
Ser7ices share schema and contract: not class, Services interact solely on their e&pression of
str!ct!res thro!gh schemas and behaviors thro!gh contracts, The serviceJs contract describes the
str!ct!re of messages and ordering constraints over messages, The formality of the e&pression allows
machine verification of incoming messages, Machine verification of incoming messages allows yo! to
protect the serviceJs integrity, /ontracts and schemas m!st remain stable over time, so b!ilding them
fle&ibly is important,
Ser7ice compatibility is based on policy, Services e&press their capabilities and re?!irements in
terms of a machine readable policy e&pression, Policy assertions are identified by a stable, globally !ni?!e
name, +ndivid!al policy assertions are opa?!e to the system as a whole# services m!st simply be able to
satisfy each otherYs policy re?!irements,
#ene&its
The key benefit of !sing Ser!ice-riented Integration is interoperability between disparate technical
architect!res, +nteroperability at the level of technical architect!re helps to deco!ple an enterpriseJs b!siness
architect!re from its information technology, This deco!pling gives an enterprise a great deal of fle&ibility in
terms of how it implements specific b!siness capabilities,
ltho!gh an enterprise contains processes, reso!rces, goals, b!siness r!les, and relationships L-riksson44N, it is
the b!siness processes that define how work act!ally is done, Technical architect!res enable work to be done
efficiently by incorporating b!siness processes,
*itho!t interoperable systems, the cost of process change is relatively high beca!se it may involve crossing
technology bo!ndaries, *hen !sing interoperable systems, however, the cost of process change is dramatically
lowered, This is especially tr!e when services are designed at a level of gran!larity that is meaningf!l to the
b!siness, s!ch as steps within a process, 1!sinesses that have interoperable systems and that !se services that
245450494.doc 119 od 257
are relevant to b!siness process are in a better position to sense and respond to market changes and
opport!nities, These b!sinesses become more agile as a res!lt of creating interoperable systems and !sing
services that are relevant to b!siness practices,
%iabilities
The key liability of !sing Ser!ice-riented Integration is the performance cost of seriali9ing, deseriali9ing, and
parsing QML doc!ments, +n addition, QML doc!ments are m!ch larger than their binary e?!ivalents beca!se
they contain metadata, This increases the si9e of the payload that m!st be processed d!ring message
e&change,
Security Considerations
Sec!rity is critical to services, "iven its comple& and technology<specific nat!re, yo! m!st consider sec!rity
individ!ally for each implementation,
Related Patterns
8or more information, see the following related patterns:
+mplementing Service<=riented +ntegration with SP,.-T
+mplementing Service<=riented +ntegration with 1i9Talk Server 3445
)ro'er L1!schmannMPN, To discover and p!blish services, *eb services !se an implementation of the
$niversal Description, Discovery, and +ntegration of *eb Services '$DD+( specification, $DD+ is an
implementation of the Indirect )ro'er pattern, The Indirect )ro'er is a speciali9ed kind of )ro'er
L1!schmannMPN, Indirect )ro'er enables one endpoint to locate another, fter the other endpoint is
located, the two endpoints comm!nicate directly with each other, +n comparison, &irect )ro'er also helps
make the initial connection, b!t it maintains central control over the comm!nication, 8or an e&ample of a
&irect )ro'er, see Message )ro'er,
Service "ateway LTrowbridge4;N, This pattern contains the code that implements the cons!mer portion
of the contract into its own Ser!ice Gateway component,
Service +nterface LTrowbridge4;N, This pattern designs an application as a collection of software
services, -ach software service has a service interface that cons!mers of the application can interact
thro!gh,
Ac-nowledgments
L1o&45N 1o&, Don, @/ode .ame +ndigo: "!ide to Developing and %!nning /onnected Systems with +ndigo,@
MS&N Maga6ine, 2an!ary 3445, vailable from the MSD. *indows /ode<.amed @Longhorn@ DeveloperJs /enter
at: http:>>msdn,microsoft,com>longhorn>!nderstanding>pillars>indigo>defa!lt,asp&C
p!llV>msdnmag>iss!es>45>46>+ndigo>defa!lt,asp&,
L1!schmannMPN 1!schmann, 8rank# %egine Me!nier, )ans %ohnert, Peter Sommerlad, and Michael Stal,
Pattern-riented Software $rc"itecture0 <olume ;1 $ System of Patterns, 2ohn *iley & Sons Ltd, 6MMP,
L-rikkson44N -riksson, )ans<-rik, and Magn!s Penker, )usiness Modeling wit" UM#1 )usiness Patterns at 2or',
2ohn *iley & Sons, +nc,, 3444,
245450494.doc 120 od 257
L.ewcomer43N, .ewcomer, -ric, Understanding 2e% Ser!ices1 =M#0 2S&#0 S-$P0 and U&&I, ddison<*esley,
3443,
LSkonnard4;<3N Skonnard, aron, @$nderstanding S=P,@ MS&N 2e% Ser!ices &e!eloper (enter, March 344;,
vailable at: http:>>msdn,microsoft,com>webservices>!nderstanding>webservicebasics>defa!lt,asp&C
p!llV>library>en<!s>>dnsoap>html>!nderstandsoap,asp,
LTrowbridge4;N Trowbridge, David# Dave Mancini, Dave B!ick, "regor )ohpe, 2ames .ewkirk, and David
Lavigne, -nterprise Sol!tion Patterns $sing Microsoft ,.-T, Microsoft Press, 344;, lso available on the MSD.
rchitect!re /enter at: http:>>msdn,microsoft,com>architect!re>patterns>defa!lt,asp&Cp!llV>library>en<
!s>dnpatterns>html>-sp,asp
L*;/45N @*eb Services rchitect!re *;/ *orking Draft 66 8ebr!ary 3445,@ vailable on the *;/ *eb site at:
http:>>www,w;,org>T%>3445>.=T-<ws<arch<34454366>
L*anagel4;N *anagel, 2onathan, et al, @1!ilding +nteroperable *eb Services: *S<+ 1asic Profile 6,4,@ MS&N
#i%rary, !g!st 344;, vailable at: http:>>msdn,microsoft,com>library>defa!lt,aspC!rlV>library>en<
!s>dnsvcinter>html>wsi<bpTmsdnTlandingpage,asp,
Implementing Ser7ice4=riented Integration with ASP1,5T

Integration Patterns
Contents
/onte&t
1ackgro!nd
+mplementation Strategy
-&ample: 1!ilding an SP,.-T *eb Service to ccess the Mainframe "ateway
%es!lting /onte&t
Testing /onsiderations
Sec!rity /onsiderations
cknowledgments
245450494.doc 121 od 257
Conte.t
Ho! are connecting two systems by !sing Service<=riented +ntegration so that one system can cons!me
f!nctions provided by the other, The service provider is implemented by !sing the Microsoft ,.-T 8ramework,
#ac-ground
+n the "lobal 1ank scenario, the *eb application server accesses the mainframe comp!ter thro!gh a gateway
service to retrieve a c!stomerJs acco!nt balance, 8ig!re 6 ill!strates how the interaction between the two
systems is implemented as Ser!ice-riented Integration by !sing Microsoft SP,.-T *eb services,
/igure 11 Two applications using Ser7ice4=riented Integration to access the gateway
This implementation describes how to e&pose f!nctionality that resides on a mainframe comp!ter as a *eb
service so that it can be accessed thro!gh Ser!ice-riented Integration, The gateway is a c!stom /S
application that connects to the banking mainframe comp!ter thro!gh Microsoft )ost +ntegration Server ')+S(,
The mainframe comp!ter manages the acco!nt balances for the c!stomer acco!nts and provides f!nctions s!ch
acco!nt balance retrieval, acco!nt credits, and acco!nt debits,
,ote This implementation foc!ses on the interaction between the *eb server and the Gateway component,
8or a more detailed description of the interaction between the Gateway and the mainframe comp!ter, see
Implementing Gateway wit" .ost Integration Ser!er 3445,
The mainframe gateway e&poses a n!mber of different methods to get acco!nt balances, to credit and debit
acco!nts, and to perform other f!nctions, This implementation describes only the !se of the GetAccountIn&o
method to ret!rn the name and balance of an acco!nt,
Implementation Strategy
245450494.doc 122 od 257
s already mentioned, the strategy is to enable Ser!ice-riented Integration by e&posing mainframe
f!nctionality as an SP,.-T *eb service, 1efore disc!ssing detailed steps, it is helpf!l to review the concept of
Ser!ice-riented Integration as well as some details abo!t SP,.-T *eb services,
Ser7ice4=riented Integration
Ser!ice-riented Integration connects applications thro!gh the e&change of doc!ments, !s!ally in the form of
QML doc!ments, 8ig!re 3 shows Ser!ice-riented Integration passing doc!ments between a service cons!mer
and a service provider,
/igure !1 Document e.change in Ser7ice4=riented Integration
The doc!ment e&change in 8ig!re 3 does not imply interaction with a specific instance of a remote obEect,
+nstead, when the doc!ment is passed from the cons!mer to the provider, it triggers the e&ec!tion of a specific
f!nction or service that is self<contained and stateless, This is an important difference between Ser!ice
-riented Integration and &istri%uted -%8ect Integration 'also known as instance<based integration(, which
allows the client to manage the lifetime of a specific remote obEect instance,
The following e&ample shows an QML doc!ment passed inside a S=P envelope,
45xm* 6ersion=78.07 enco&in1=7ut(9:750 4soap;En6e*ope
xm*ns;xsi=7http;<<===.=>.or1<?008<2#Schema9instance7
xm*ns;xs&=7http;<<===.=>.or1<?008<2#Schema7
xm*ns;soap=7http;<<schemas.xm*soap.or1<soap<en6e*ope<70 4soap;@o&y0
4Aet+ccount%n(oRe)uest xm*ns=7http;<<ms&n.microso(t.com<patterns<70
4+ccount%D xm*ns=770123456784<+ccount%D0 4<Aet+ccount%n(oRe)uest0
4<soap;@o&y0 4<soap;En6e*ope0
ASP1,5T Web Ser7ices
*hen yo! !se SP,.-T to implement a *eb service, the f!nction that processes the incoming doc!ment is
implemented as a method of a ,.-T 8ramework class, The ,.-T 8ramework manages the instantiation of a
specific instance of that class,
The ,.-T 8ramework does ?!ite a bit of work behind the scenes when it receives an incoming S=P re?!est, as
shown in 8ig!re ;, $nderstanding the f!nctions that the ,.-T 8ramework performs internally is not strictly
necessary, b!t it is very helpf!l when designing SP,.-T *eb services, +t also gives yo! a good appreciation of
the amo!nt of f!nctionality that resides in the ,.-T 8ramework,
245450494.doc 123 od 257
/igure $1 ASP1,5T Web ser7ices handling
*hen a doc!ment reaches a specified endpoint, the server has two main pieces of information to work with:
the contents of the doc!ment and the $%L of the endpoint, *ith those two pieces of information, the server has
to complete the following steps:
6, Determine the ,.-T 8ramework class that sho!ld handle the re?!est,
3, Determine the method to invoke inside that class,
;, +nstantiate data transfer obEects to pass data from the incoming doc!ment to the method,
5, +nvoke the method,
A, %et!rn the res!lts,
+nternet +nformation Services '++S( !ses the file e&tension of the incoming $%L to map re?!ests to the
appropriate +nternet Services P+ '+SP+( handler, SP,.-T *eb services endpoints carry an ,asm& e&tension in
the $%L, The ,asm& e&tension in the $%L ca!ses ++S to map the re?!est to the standard ,.-T 8ramework )TTP
pipeline, 1ased on defa!lt comp!ter config!ration settings, the ,.-T 8ramework )TTP pipeline hands control
over to a WebSer7ice3andler, The WebSer7ice3andler in t!rn determines the ,.-T 8ramework class that is
associated with the $%L by reading the ,asm& file referenced by the $%L, +n 8ig!re 5, the "ateway,asm& file
specifies the class Gateway as the class servicing re?!ests, This class is defined inside a code<behind page
named "ateway,asm&,cs,
245450494.doc 124 od 257
The *eb service handler still has to determine the method to invoke for the incoming doc!ment, 1y defa!lt, it
determines the method to invoke based on the val!e of the S=Pction field that is part of the )TTP header,
The following is a sample of that part of an )TTP header,
S,+P+ction; 7http;<<ms&n.microso(t.com<patterns<Aet+ccount%n(o7
fter the *eb service handler has determined the method to invoke, it parses the incoming QML doc!ment and
creates an instance of the matching ,.-T 8ramework obEects to be passed to the method, This step is referred
to as deseriali9ation and is performed by the ,.-T 8ramework QML Seriali9er, The method performing the
f!nction does not even have to know that the parameters were originally passed as an QML doc!ment wrapped
inside a S=P envelope, Lastly, the *eb service handler creates an instance of the class that implements the
service f!nction and invokes the appropriate method, passing instances of the applicable data transfer obEects,
8or a more detailed description of SP,.-T *eb service internals, see @)ow SP,.-T *eb Services *ork@ on
MSD. 'http:>>msdn,microsoft,com>library>defa!lt,aspC!rlV>library>en<!s>dnwebsrv>html>howwebmeth,asp(
LSkonnard4;N,
#uilding an ASP1,5T Web Ser7ice
QML *eb services e&pose the service contract to potential cons!mers as a *eb Services Description Lang!age
'*SDL( doc!ment, To simplify development of *eb services, the ,.-T 8ramework offers a variety of
capabilities, incl!ding the a!tomatic generation of *SDL doc!ments based on a service implementation, s a
res!lt, yo! have a n!mber of options when creating a new service interface:
De7elop the code &irst, *rite the service implementation code first, and then let the ,.-T
8ramework create the *SDL doc!ment from the code,
Speci&y the E2% schemas &irst, Develop message schemas as QML Schema definition lang!age
'QSD( schemas first, generate code from the schemas, and then let the ,.-T 8ramework create the *SDL
doc!ment,
De7elop the WSD% &irst, Develop the *SDL definition first, and then let the ,.-T 8ramework
generate skeleton code matching the definition,
-ach approach has advantages and limitations, "enerally, the choice is among the amo!nt of control yo! need,
the effort re?!ired, and the ease of integrating with other platforms,
De7eloping the Code /irst
The easiest way to e&pose code as a *eb service is to label a ,.-T 8ramework class with the FWebSer7iceG
attrib!te and to label the affected method with a FWeb2ethodG attrib!te, The ,.-T 8ramework then takes
care of all the details, 8or e&ample, it generates the *SDL doc!ment to give potential clients a description of
the service, To perform this conversion witho!t any additional information, the ,.-T 8ramework derives the
names of S=P body elements from the name of the method and its arg!ments, The advantage of this
approach is clearly its simplicity, *ith two lines of e&tra @code,@ a method can become a *eb service that can
be invoked remotely, The limitation lies in the fact that the service interface e&actly resembles the code,
incl!ding variable names, The ,.-T 8ramework allows yo! to override the defa!lt naming choices by specifying
245450494.doc 125 od 257
additional attrib!tes, b!t the specification for the service still resides in application code, This can be
!ndesirable, for e&ample, if an enterprise wants to keep a global repository of all message definitions
independent of the platform that implements a partic!lar service, nother potential pitfall, however, is that this
approach can generate a service that will not f!nction properly, 8or e&ample, if a method ret!rns a non<
seriali9able obEect, any service invocation will fail even tho!gh the code compiled witho!t errors,
Speci&ying E2% Schemas /irst
*eb services call typically re?!ires two separate messages: a re?!est message and a response message,
These messages play roles similar to the roles played by the parameters and the ret!rn val!e of a reg!lar
method, 2!st as defining the signat!re of a method is an important first step in the creation of a new method,
defining the re?!est and ret!rn message formats is a logical first step in the creation of a *eb services
interface, fter the message format has been specified, it can be compiled into a /S classes a!tomatically
witho!t inc!rring additional effort, t r!n time, the ,.-T 8ramework still renders the *SDL doc!ment and
eliminates the need for hand<coding,
QML *eb services !se QSD doc!ments to define message formats, Defining these doc!ments by !sing a
standard format s!ch as QSD has advantages over generating them from the code, QSD doc!ments are
platform<independent and can be !sed to define message formats independent of the technology implementing
the service, whether it is the ,.-T 8ramework, the 2ava 3 Platform, 2ava 3 -nterprise -dition '23--(, or any in a
range of other technologies, This makes it feasible to keep a global repository of all message types in an
enterprise, /reating QML schemas also gives the interface designer e&act control over the look of S=P
messages that are sent to and from a partic!lar service,
Potential disadvantages of developing the QSD schemas first incl!de the fact that a new specification lang!age
'QML Schema( and tool has to be !sed, )owever, many modern development environments, incl!ding Microsoft
:is!al St!dio ,.-T, incl!de powerf!l and easy<to<!se QML Schema editors, /reating QSD doc!ments first also
re?!ires additional development and b!ild steps beca!se the QSD doc!ment first has to be converted into /S
classes, This step has to be repeated whenever the QSD doc!ment changes, presenting the risk that the
doc!ment and the implementation of the service can get o!t of synchroni9ation,
De7eloping WSD% /irst
The specification of a service contract depends on factors other than E!st the format of inbo!nd and o!tbo!nd
messages, 8or e&ample, to be accessible, the service has to be bo!nd to a port that can be addressed by !sing
a specified $niform %eso!rce +dentifier '$%+(, *SDL doc!ment specifies these additional contract terms, s!ch
as ports and binding, Starting with the creation of a *SDL doc!ment ens!res that all details of the service
contract 'at least to the e&tent that they are s!pported by *SDL( can be specified directly and in a technology<
ne!tral manner, The biggest drawback of starting with a *SDL doc!ment is that the verboseness of *SDL
makes the man!al creation tedio!s,
5.ample #uilding an ASP1,5T Web Ser7ice to Access the 2ain&rame Gateway
245450494.doc 126 od 257
s described in the "lobal 1ank scenario, the *eb application server accesses the mainframe comp!ter thro!gh
a gateway service to retrieve a c!stomerJs acco!nt balance, This e&ample creates an SP,.-T *eb service that
accesses the gateway to the mainframe,
The SP,.-T page framework s!pports the development of both service providers and service cons!mers, This
implementation begins with the design and development of the service provider, +n the e&ample, the mainframe
gateway is the service provider, 8ort!nately, most of the work that the ,.-T 8ramework performs is hidden from
the developer of an SP,.-T *eb service, The developerJs main task is to create the interface definition of the
service and to fill o!t the implementing code with the correct attrib!tes to config!re the behavior of the
SP,.-T internals,
s mentioned in the previo!s section, there are several approaches to developing a *eb service by !sing
SP,.-T, This implementation begins by defining QSD doc!ments for the re?!est and response messages, This
approach gives yo! good control over the p!blished service interface while sparing yo! from having to hand<
code f!ll<blown *SDL doc!ments,
To e&pose an e&isting f!nction as an SP,.-T *eb service, follow these steps:
6, Develop an QSD doc!ment for the re?!est and the response message,
3, "enerate data transfer classes from the schema,
;, Define the operations that the service e&poses,
5, /onnect the service interface to the service implementation,
A, 1!ild and r!n the service,
P, /reate a test client that invokes the *eb service,
8ig!re 5 ill!strates this process, -ach n!mbered step is e&plained in detail in the sections that follow,
245450494.doc 127 od 257
/igure '1 #uilding an ASP1,5T Web ser7ice
Step 1 De7elop ESD Documents
The first step is to define the format of the re?!est and response messages by creating two QSD files, The
following are the QSD files for the GetAccountIn&o method generated !sing the Microsoft :is!al St!dio ,.-T
QSD -ditor, To ens!re ma&im!m interoperability between the gateway service and the cons!mers, this
implementation !ses only standard data types and avoids !sing ,.-T 8rameworkGspecific data types s!ch as
DataSet,
The QML schema for the re?!est message '"etcco!nt+nfo%e?!est,&sd( looks like the following e&ample, 'To
improve readability, the namespace declarations have been omitted,(
4xs;schema B 0 4xs;e*ement name=7Aet+ccount%n(oRe)uest70 4xs;comp*ex"ype0
4xs;se)uence0 4xs;e*ement name=7+ccount%D7 type=7xs;strin17 <0
4<xs;se)uence0 4<xs;comp*ex"ype0 4<xs;e*ement0 4<xs;schema0
Ho! will notice that the doc!ment for the re?!est is ?!ite simple# it contains only a single string data element
named ZAccountID[,
The following sample is what the QML schema response '"etcco!nt+nfo%esponse,&sd( looks like,
4xs;schema B 0 4xs;e*ement name=7Aet+ccount%n(oResponse70 4xs;comp*ex"ype0
4xs;se)uence0 4xs;e*ement name=7+ccount%D7 type=7xs;strin17 <0 4xs;e*ement
245450494.doc 128 od 257
name=7@a*ance7 type=7xs;&ecima*7 <0 4xs;e*ement name=7Name7
type=7xs;strin17 <0 4xs;e*ement name=7Description7 type=7xs;strin17 <0
4<xs;se)uence0 4<xs;comp*ex"ype0 4<xs;e*ement0 4<xs;schema0
fter creating the QSD files, the ne&t step is to generate the data transfer classes,
Step ! Generate Data Trans&er Classes
The QML Schema Definition tool '&sd,e&e( in the ,.-T 8ramework can create a ,.-T 8ramework class from an
QSD file, To create the data transfer files, r!n the following commands from the command prompt in the
directory where the QSD files reside:
xs& <n;Aate=ay-S <c Aet+ccount%n(oRe)uest.xs& xs& <n;Aate=ay-S <c
Aet+ccount%n(oResponse.xs&
These commands generate the "etcco!nt+nfo%e?!est,cs and "etcco!nt+nfo%esponse,cs files, $sing the
Bnamespace option 'or the short form, Bn( enables yo! to specify the namespace to be !sed for the
generated class, =therwise, the global namespace is !sed as the defa!lt namespace, which co!ld lead to
conflicting namespaces,
The generated class file "etcco!nt+nfo%e?!est,cs is shown in the following sample,
namespace Aate=ay-S C usin1 System.2m*.Seria*iDationE B pub*ic c*ass
Aet+ccount%n(oRe)uest C FSystem.2m*.Seria*iDation.2m*E*ement+ttribute
($orm=System.2m*.Schema.2m*Schema$orm.3n)ua*i(ie&)G pub*ic strin1
+ccount%DE H H
The attrib!te in front of the cco!nt+D field instr!cts the QML Seriali9er that no namespace ?!alifier is re?!ired
in the QML string for this element,
The generated class has no f!nctionality, b!t rather it is a simple data holder class that acts as a Data Transfer
=bEect LTrowbridge4;N between the ,.-T 8ramework and the service implementation, This class is the ,.-T
8ramework representation of the QML doc!ment that is embedded in a S=P re?!est to the gateway service, s
described previo!sly, at r!n time the QML Seriali9er parses the incoming S=P doc!ment, creates an instance
of this obEect, and pop!lates all fields with the val!es from the incoming S=P QML doc!ment,
Step $ De&ine the =perations That the Ser7ice 5.poses
.ow that yo! have data transfer obEects, yo! can define the methods and operations that the service is going
to e&pose, s described in @SP,.-T *eb Services@ earlier in this pattern, an SP,.-T *eb service endpoint is
created from the combination of an ,asm& file and an associated code<behind page that contains the act!al
class definition, 1eca!se the :is!al St!dio ,.-T tool set generates the ,asm& file for yo!, yo! can foc!s on the
Gateway class itself, which is contained in the file "ateway,asm&,cs, This implementation follows the Service
+nterface LTrowbridge4;N approach and separates the p!blic service interface from the implementation,
The class Gateway inherits from the base class WebSer7ice, To keep things simple, the class e&poses only a
single method, GetAccountIn&o, as a service,
245450494.doc 129 od 257
namespace Aate=ay-S
C F-ebSer6ice(Namespace=7http;<<ms&n.microso(t.com<patterns<7)G pub*ic
c*ass Aate=ay ; System.-eb.Ser6ices.-ebSer6ice C B F-eb#etho&G
FSoapDocument#etho&(ParameterSty*e=SoapParameterSty*e.@are)G pub*ic
Aet+ccount%n(oResponse Aet+ccount%n(o( Aet+ccount%n(oRe)uest
Aet+ccount%n(oRe)uest) C return nu**E H H H
8or now, leave the method body empty and only ret!rn a n!ll val!e, Ho! will tie this method to the service
implementation in the ne&t step,
.ote that both the method and the class are encoded with special attrib!tes, The FWeb2ethodG attrib!te of
the GetAccountIn&o method makes the method accessible as part of the *eb service, The additional
FSoapDocument2ethod?H@Gattrib!te c!stomi9es the way the QML Seriali9er parses incoming S=P
messages, 1y defa!lt, the QML Seriali9er e&pects method parameters to be wrapped inside an additional
element, which is in t!rn contained in the Zsoap#ody[ element, /hanging the ParameterStyle setting to
SoapParameterStyle1#are makes these method parameters appear immediately !nder the Zsoap#ody[
element, rather than encaps!lated in an additional QML element,
The following e&ample shows a S=P message that ca!ses the GetAccountIn&o method of the "ateway,asm&
*eb service to be invoked,
4soap;En6e*ope xm*ns;xsi=7http;<<===.=>.or1<?008<2#Schema9instance7
xm*ns;xs&=7http;<<===.=>.or1<?008<2#Schema7
xm*ns;soap=7http;<<schemas.xm*soap.or1<soap<en6e*ope<70 4soap;@o&y0
4Aet+ccount%n(oRe)uest xm*ns=7http;<<ms&n.microso(t.com<patterns70
4+ccount%D xm*ns=77012345674<+ccount%D0 4<Aet+ccount%n(oRe)uest0
4<soap;@o&y0 4<soap;En6e*ope0
The Zsoap#ody[ element contains a ZGetAccountIn&oRe0uest[ element, This element corresponds to the
single parameter that the GetAccountIn&o method receives,
*itho!t the ParameterStyle setting, the S=P re?!est for the same method wo!ld look like the following
sample, .ote that an additional GetAccountIn&o node beneath the Zsoap#ody[ element wraps the method
parameters,
4soap;En6e*ope xm*ns;xsi=7http;<<===.=>.or1<?008<2#Schema9instance7
xm*ns;xs&=7http;<<===.=>.or1<?008<2#Schema7
xm*ns;soap=7http;<<schemas.xm*soap.or1<soap<en6e*ope<70 4soap;@o&y0
4Aet+ccount%n(o xm*ns=7http;<<ms&n.microso(t.com<patterns<70
4Aet+ccount%n(oRe)uest xm*ns=7http;<<ms&n.microso(t.com<patterns70
4+ccount%D xm*ns=77012345674<+ccount%D0 4<Aet+ccount%n(oRe)uest0
4<Aet+ccount%n(o0 4<soap;@o&y0 4<soap;En6e*ope0
1eca!se the method receives all the necessary data elements inside a single data transfer obEect, the additional
wrapping is not re?!ired and makes the S=P message !nnecessarily verbose, Therefore, set the
ParameterStyle to #are,
Step ' Connect the Ser7ice Inter&ace to the Ser7ice Implementation
245450494.doc 130 od 257
.ow that yo! have b!ilt the service interface and have encoded it with the necessary *eb service attrib!tes,
yo! need to link the still<empty GetAccountIn&o method to the act!al service implementation, =ne option is to
insert the code that implements the service into the GetAccountIn&o method of the Gateway class, )owever,
this approach has a n!mber of drawbacks,
8irst, the Gateway class inherits from the WebSer7ice base class, That means that the class cannot be part of
a separate inheritance tree that the service implementation may re?!ire,
Second, tying together the *eb service interface and the implementation makes it harder to test the
implementation o!tside the *eb services conte&t,
Third, the f!nctions that the service implementation provides may not e&actly match the service interface
definition, 8or e&ample, the service implementation may re?!ire m!ltiple calls to fine<grained methods,
whereas the *eb service interface sho!ld e&pose coarse<grained f!nctions, =r, the service implementation may
!se ,.-T 8rameworkGspecific data types, s!ch as DataSets, that yo! are seeking to avoid in the p!blic *eb
service interface, s a res!lt, the service may need to contain logic to arbitrate between the p!blic *eb service
interface and the internal implementation,
8inally, tying the *eb service directly to the implementation means that the *eb service can be f!nctional only
when the service implementation is r!nning and is available, That may not always be the case if the act!al
service implementation resides in an e&isting system, 8or e&ample, many mainframe systems have offline times
when they are not available for online re?!ests, s the *eb service is weaved into a larger sol!tion, these
o!tages co!ld hinder testing, 8or testing p!rposes, it wo!ld be very convenient to be able to replace the service
implementation with a d!mmy implementation witho!t affecting the service interface,
ll these problems can be solved with a combination of well<known design patterns that is shown in 8ig!re A,
The first step is to separate the interface of the service f!nctionality from the implementationIfor e&ample, the
mainframe access, Ho! can do so by applying the Separated Interface pattern L8owler4;N, The interface
IGlobal#an- is a generic interface that represents the f!nctions provided by the mainframe system, b!t it has
no dependency on the server r!nning )+S, The class Global3IS implements the methods specified in this
interface by connecting to the mainframe thro!gh )+S,
245450494.doc 131 od 257
/igure (1 Separating the ser7ice implementation &rom the ser7ice inter&ace
fter yo! have separated the interface from the implementation, yo! can create a Ser!ice Stu% L8owler4;N,
service st!b is a d!mmy implementation of an e&ternal service that red!ces e&ternal dependencies d!ring
testing, The GlobalStub service st!b implements the same IGlobal#an- interface b!t does not act!ally
connect to the mainframe comp!ter, +nstead, it sim!lates the mainframe f!nctions internally,
.ow that yo! have two implementations, yo! have to decide which one to !se, Ho! want to be able to switch
between the d!mmy implementation and the real implementation witho!t having to change any code or having
to recompile, Therefore, this e&ample !ses a Plugin L8owler4;N, Plugin links classes d!ring config!ration rather
than compilation, Ho! implement the Plugin inside the GlobalPlugIn/actory class, The factory class reads the
name of the implementing class from a config!ration file so that yo! can switch between GlobalStub and
Global3IS at r!n time by changing the application config!ration file,
*hat is left for the Gateway class to doC +t has to call the GlobalPlugIn/actory class to obtain a reference to
an implementation of the IGlobal#an- interface, .e&t, it has to invoke the appropriate method in the
interface, The names and types of the parameters of the service implementation may differ from the QML
schemas that yo! created, so the Gateway class may have to perform simple mapping f!nctions between the
two data representations,
-ven tho!gh the implementation of these e&tra classes is not strictly necessary to create a working *eb
service, these patterns simplify testing tremendo!sly and are well worth the additional coding effort, +t t!rns
o!t that the implementation of each class is act!ally ?!ite simple, The implementation involves the following
steps:
6, /reate an interface,
3, /reate service implementations,
;, /reate the pl!g<in factory,
5, +mplement the *eb service method,
LetJs walk thro!gh these steps one by one,
245450494.doc 132 od 257
Step '11 Create an Inter&ace
8irst, create an interface for the service implementation, The following code is from the +"lobal1ank,cs file, The
code references the AccountIn&o class, The AccountIn&o class is !sed by the service implementation, .ote
that this interface and the data transfer class have no dependency on a specific service implementation,
pub*ic inter(ace %A*oba*@ank C << "hro=s +r1umentException i( account &oes
not exist. +ccount%n(o Aet+ccount%n(o (strin1 +ccount%D)E H pub*ic c*ass
+ccount%n(o C pub*ic strin1 account%DE pub*ic strin1 nameE pub*ic strin1
&escriptionE pub*ic &ecima* ba*anceE pub*ic +ccount%n(o(strin1 account%D'
strin1 name' strin1 &escription' &ecima* ba*ance) C this.account%D =
account%DE this.name = nameE this.&escription = &escriptionE this.ba*ance =
ba*anceE H H
Step '1! Create the Ser7ice Implementations
.e&t, create two implementations of the interface as shown, /reate one that is a simple st!b, and create
another one that connects to the mainframe system thro!gh )+S,
The two implementation classes are named Global3IS and GlobalStub, Global3IS connects to the e&ternal
system, +n the e&ample, the mainframe gateway is the e&ternal system, The class implements the
IGlobal#an- interface,
pub*ic c*ass A*oba*.%S ; %A*oba*@ank C B pub*ic +ccount%n(o
Aet+ccount%n(o(strin1 account%D) C &ecima* ba*ance = 0.00mE strin1 name =
77E obIect FG context+rray = nu**E "!PJink"R#JNE".A*oba*@ank bank = ne=
"!PJink"R#JNE".A*oba*@ank ()E bank.ce&rbank (re( name 're( account%D 're(
ba*ance' re( context+rray)E +ccount%n(o in(o = ne= +ccount%n(o(account%D'
77'77' ba*ance)E return in(oE H H
The GlobalStub class provides another implementation of the IGlobal#an- interface b!t is a simple st!b
witho!t any dependency on e&ternal systems, +t !ses an internal accounts collection to sim!late acco!nt
balances, 8or testing p!rposes, the class constr!ctor initiali9es this collection by !sing hard<coded val!es,
pub*ic c*ass A*oba*Stub ; %A*oba*@ank C static %Dictionary accounts =
(%Dictionary) ne= .ashtab*e()E pub*ic A*oba*Stub() C i( (accounts.!ount ==
0) C accounts.+&&(78?>7' ne= +ccount%n(o(78?>7' 7"est+ccount7'
7"estDescription7' KKK.8?m))E H H pub*ic +ccount%n(o Aet+ccount%n(o(strin1
account%D) C i( (Laccounts.!ontains(account%D)) thro= ne=
+r1umentException(7+ccount &oes not exist7)E return
(+ccount%n(o)accountsFaccount%DGE H H
Step '1$ Create the Plug4in /actory
.ow that yo! have created two implementations of the IGlobal#an- interface, yo! need to decide the
implementation that yo! want to !se at r!n time, This is the p!rpose of the Global#an-PlugIn/actory class,
The class reads the name of the class to be !sed from the config!ration file and then creates an instance of that
class, +t ret!rns a reference to the newly created obEect to the service interface, b!t the reference is cast to the
IGlobalStub interface, This way the service interface is not dependent on the implementation that was chosen,
pub*ic c*ass A*oba*@ankP*u1%n$actory C static strin1 1*oba*@ank%mp*Name =
System.!on(i1uration.!on(i1urationSettin1s.+ppSettin1sF7A*oba*@ank%mp*7GE
static pub*ic A*oba*@ank.%A*oba*@ank AetA*oba*@ank%mp*() C "ype
245450494.doc 133 od 257
1*oba*@ank%mp*"ype = "ype.Aet"ype(Aet%mp*ementation!*assName())E i(
(1*oba*@ank%mp*"ype == nu**) thro= ne= "ypeoa&Exception(7!annot *oa& type
7 M 1*oba*@ank%mp*Name)E A*oba*@ank.%A*oba*@ank bank =
(A*oba*@ank.%A*oba*@ank)+cti6ator.!reate%nstance(1*oba*@ank%mp*"ype)E
return bankE H static pub*ic strin1 Aet%mp*ementation!*assName() C i(
(1*oba*@ank%mp*Name == nu**) 1*oba*@ank%mp*Name = 7A*oba*@ank.A*oba*Stub7E
return 1*oba*@ank%mp*NameE H H
8or the Plugin class to be f!nctional, yo! need to add the following entry to the *eb,config file,
4appSettin1s0 4a&& key=7A*oba*@ank%mp*7 6a*ue=7A*oba*@ank.A*oba*Stub7<0
4<appSettin1s0
Step '1' Implement the Web Ser7ice 2ethod
.ow that yo! have defined the implementation classes, yo! can finally fill in the implementation code to the
GetAccountIn&o method of the "ateway,asm& *eb service as follows,
F-eb#etho&G FSoapDocument#etho&(ParameterSty*e=SoapParameterSty*e.@are)G
pub*ic Aet+ccount%n(oResponse Aet+ccount%n(o( Aet+ccount%n(oRe)uest
Aet+ccount%n(oRe)uest) C A*oba*@ank.%A*oba*@ank bank =
A*oba*@ank.A*oba*@ankP*u1%n$actory.AetA*oba*@ank%mp*()E
A*oba*@ank.+ccount%n(o 1*oba*+ccount%n(o =
bank.Aet+ccount%n(o(Aet+ccount%n(oRe)uest.+ccount%D)E return
@ui*&+ccount%n(o(1*oba*+ccount%n(o)E H pri6ate Aet+ccount%n(oResponse
@ui*&+ccount%n(o(A*oba*@ank.+ccount%n(o 1*oba*+ccount%n(o)
C Aet+ccount%n(oResponse response = ne= Aet+ccount%n(oResponse()E
response.+ccount%D = 1*oba*+ccount%n(o.account%DE response.@a*ance =
1*oba*+ccount%n(o.ba*anceE response.Name = 1*oba*+ccount%n(o.nameE
response.Description = 1*oba*+ccount%n(o.&escriptionE return responseE H
The preparation yo! have done pays off, The implementation of the *eb service interface method now consists
of three easy steps:
6, =btain a reference to the IGlobal#an- interface,
3, +nvoke the service implementation by !sing the reference,
;, /onstr!ct the correct response format to ret!rn to the cons!mer,
-ach step can be implemented in a single line of code, Step ; is implemented in a
#uildAccountIn&oResponse private helper method, +n this contrived e&ample, it might appear !nnecessary to
!se separate str!ct!res for GetAccountIn&oResponse and Global#an-1AccountIn&o beca!se they are
essentially identical, )owever, each str!ct!re is likely to !ndergo a different change cycle over time, +ncl!ding
this translation step allows the gateway to accommodate changes to either the )+S interface or to the gateway
interface witho!t affecting both interfaces,
Step ( #uild and Run the Web Ser7ice
.ow yo! are ready to b!ild and r!n the *eb service, +n :is!al St!dio ,.-T, click the #uild men!, and then click
#uild Solution, :is!al St!dio then compiles the *eb service, 1rowse the *eb service by typing the $%L in the
Microsoft +nternet -&plorer ddress bar, 8or the e&ample, the $%L is
http:>>localhost>"ateway*S>"ateway,asm&,
245450494.doc 134 od 257
key aspect of a service is the service contract, QML *eb services !se *SDL doc!ments to describe the
contract between a service cons!mer and the provider, *SDL doc!ment is ?!ite comprehensive, 8ort!nately,
the ,.-T 8ramework a!tomatically renders the *SDL doc!ment that describes the service, The following
e&ample shows the definitions section of the *SDL doc!ment,
45xm* 6ersion=78.07 enco&in1=7ut(:750 4&e(initions B0 4types0B4<types0
4messa1e name=7Aet+ccount%n(oSoap%n70 4part name=7Aet+ccount%n(oRe)uest7
e*ement=7s0;Aet+ccount%n(oRe)uest7<0 4<messa1e0 4messa1e
name=7Aet+ccount%n(oSoap,ut70 4part name=7Aet+ccount%n(oResu*t7
e*ement=7s0;Aet+ccount%n(oResu*t7<0 4<messa1e0 4port"ype
name=7Aate=aySoap70 4operation name=7Aet+ccount%n(o70 4input
messa1e=7tns;Aet+ccount%n(oSoap%n7<0 4output
messa1e=7tns;Aet+ccount%n(oSoap,ut7<0 4<operation0 4<port"ype0 4bin&in10B
4<bin&in10 4ser6ice name=7Aate=ay70 4port name=7Aate=aySoap7
bin&in1=7tns;Aate=aySoap70 4soap;a&&ress
*ocation=7http;<<*oca*host<Aate=ay-S<Aate=ay.asmx7<0 4<port0 4<ser6ice0
4<&e(initions0
The other maEor sections of the *SDL doc!ment incl!de the following:
Types
Messages
1indings
Service
,ote 8or the sake of clarity, some sections of the doc!ment have been condensed here# they are disc!ssed in
more detail later in this chapter,
Types
The Ztypes[ element specifies the re?!est and response messages, The content of the element reflects the
QSD doc!ments that yo! created in step 6,
4types0 4s;schema e*ement$ormDe(au*t=7)ua*i(ie&7
tar1etNamespace=7http;<<ms&n.microso(t.com<patterns70 4s;e*ement
name=7Aet+ccount%n(oRe)uest7 type=7s0;Aet+ccount%n(oRe)uest7<0
4s;comp*ex"ype name=7Aet+ccount%n(oRe)uest70 4s;se)uence0 4s;e*ement
min,ccurs=707 max,ccurs=787 (orm=7un)ua*i(ie&7 name=7+ccount%D7
type=7s;strin17<0 4<s;se)uence0 4<s;comp*ex"ype0 4s;e*ement
name=7Aet+ccount%n(oResu*t7 type=7s0;Aet+ccount%n(oResponse7<0
4s;comp*ex"ype name=7Aet+ccount%n(oResponse70 4s;se)uence0 4s;e*ement
min,ccurs=707 max,ccurs=787 (orm=7un)ua*i(ie&7 name=7+ccount%D7
type=7s;strin17<0 4s;e*ement min,ccurs=787 max,ccurs=787 (orm=7un)ua*i(ie&7
name=7@a*ance7 type=7s;&ecima*7<0 4s;e*ement min,ccurs=707 max,ccurs=787
(orm=7un)ua*i(ie&7 name=7Name7 type=7s;strin17<0 4s;e*ement min,ccurs=707
max,ccurs=787 (orm=7un)ua*i(ie&7 name=7Description7 type=7s;strin17<0
4<s;se)uence0 4<s;comp*ex"ype0 4<s;schema0 4<types0
2essages
The ne&t section of the *SDL doc!ment specifies the operations that the service s!pports, 8or each operation,
the re?!est and response message format is specified thro!gh the types declared in the Ztypes[ section of the
*SDL doc!ment, s yo! can see in the condensed *SDL listing, the *eb service yo! are b!ilding provides a
single operation named GetAccountIn&o, The operation takes a GetAccountIn&oRe0uest as an arg!ment
245450494.doc 135 od 257
and ret!rns a message of type GetAccountIn&oResult, The ,.-T 8ramework derives the name of the
operation directly from the name of the method that implemented it,
#indings
The third maEor section of the *SDL doc!ment defines the binding of the operation to a transport protocol and
a message format, The style attrib!te of the Zsoapbinding[ element is set to document, indicating that the
operation is doc!ment<oriented and not remote proced!re callGoriented, The FsoapActionG attrib!te of the
Zsoapoperation[ element specifies the action string to be !sed in the S=Pction )TTP header, s e&plained
in @SP,.-T *eb Services,@ the ,.-T 8ramework !ses this string to determine the method to e&ec!te,
The soapbody elements describe that the message format will be literal, meaning that the body portion of an
incoming S=P re?!est looks e&actly as specified in the types section of the doc!ment witho!t any additional
wrapping or encoding, The specified style of S=P message e&change is also referred to as docBliteral,
4bin&in1 name=7Aate=aySoap7 type=7tns;Aate=aySoap70 4soap;bin&in1
transport=7http;<<schemas.xm*soap.or1<soap<http7 sty*e=7&ocument7<0
4operation name=7Aet+ccount%n(o70 4soap;operation sty*e=7&ocument7
soap+ction=7http;<<ms&n.microso(t.com<patterns<Aet+ccount%n(o7 <0 4input0
4soap;bo&y use=7*itera*7<0 4<input0 4output0 4soap;bo&y use=7*itera*7<0
4<output0 4<operation0 4<bin&in10
Ser7ice
The last part of the *SDL doc!ment specifies an address for the service, The service in the e&ample is available
thro!gh the $%L http:>>localhost>"ateway*S>"ateway,asm&,
s yo! can see, yo! can save a significant amo!nt of work by having the ,.-T 8ramework generate the *SDL
doc!ment for yo! rather than coding it man!ally,
Step ) Create a Test Client
.ow that the service is available online and it is properly described by a service contract in the form of a *SDL
doc!ment, yo! are ready to create a client application that cons!mes the service,
To create a test client that accesses the *eb service, create a new SP,.-T proEect, $se the dd *eb %eference
*i9ard in :is!al St!dio ,.-T Sol!tion -&plorer to create a reference to the gateway *eb service, Ho! can also
!se the *eb Services Description Lang!age tool '*sdl,e&e(, This command<line tool creates pro&y classes from
*SDL, /ompiling this pro&y class into an application and then calling the method of this pro&y class ca!ses the
pro&y class to package a S=P re?!est across )TTP and to receive the S=P<encoded response,
Ho! can !se these pro&y classes later to generate a!tomated test cases by !sing test tools s!ch as .$nit
'http:>>www,n!nit,org(,
Resulting Conte.t
245450494.doc 136 od 257
-val!ate the following benefits and liabilities to decide whether yo! sho!ld implement and !se Ser!ice-riented
Integration with SP,.-T,
#ene&its
5&&icient, SP,.-T does a lot of the work involved in e&posing f!nctions as *eb services,
/le.ible, +f yo! want, yo! can still control the e&act behavior declaratively thro!gh the !se of
attrib!tes, This approach provides a good combination of simplicity witho!t being !nnecessarily restrictive,
+f yo! need even finer<grained control, yo! can replace the standard WebSer7ice3andler with a c!stom
class,
%iabilities
Geared towards custom applications, -ven tho!gh the ,.-T 8ramework does a lot of the *eb
service coding and config!ration, yo! still have to code the service implementation in /S or :is!al 1asic
,.-T by hand, SP,.-T does not offer b!ilt<in s!pport for process modeling and orchestrations that might
be needed for the creation of more comple& composite services, +f this type of f!nctionality is re?!ired,
consider !sing +mplementing Service<=riented +ntegration with 1i9Talk Server 3445 instead,
Synchronous interaction, 1y defa!lt, this approach s!pports only synchrono!s interaction, The
client has to wait !ntil the service completes, +n distrib!ted service<oriented environments, asynchrono!s
comm!nication is often the preferred approach,
Testing Considerations
Two design decisions significantly improve yo!r ability to test the service provider in this implementation:
The separation of the service interface from the service implementation
The !se of a pl!g<in to dynamically s!bstit!te a service st!b for the implementation
Ser7ice Inter&ace Separation
The separation of the service interface from the service implementation makes it easy to test the service
implementation witho!t having to deal with the *eb service aspect of the gateway component, Ho! can create
!nit test cases as yo! wo!ld for any application, Do this by creating test cases for the service implementation
and by circ!mventing the service interface, as shown in 8ig!re P(,
/igure )1 "nit testing o& Ser7ice4=riented Integration
245450494.doc 137 od 257
!tomating the !nit test cases has a very desirable side effect: yo! can apply the same test cases to both the
real implementation and the d!mmy implementation, pplying the same test cases ens!res that the
GlobalStub class is a tr!e rendering of the mainframe f!nctionality, +t also allows yo! to !se the st!b
implementation to r!n all f!nctional tests with confidence,
Ser7ice Stub
The service st!b, in combination with the pl!g<in factory, allows yo! to switch between the real service
implementation and a d!mmy implementation at r!n time by changing a config!ration file, This allows yo! to
test cons!mers of the service more easily, reliably, and ?!ickly beca!se yo! eliminate any dependencies to the
mainframe service 'see 8ig!re O(,
/igure *1 Replacing the implementation o& the gateway &or testing
Ho! can be ass!red that the switch does not affect the behavior of the gateway beca!se both the d!mmy 'st!b(
implementation and the )ost +ntegration Server interface have been !nit<tested by !sing the same s!ite of !nit
tests,
Security Considerations
The *eb service implementation presented here does not incorporate any sec!rity considerations, This may be
!ndesirable beca!se the *eb service e&poses sensitive acco!nt data that resides in the bankJs mainframe
comp!ter, -ven tho!gh the *eb service resides behind the firewall, yo! wo!ld not want anyone with :is!al
St!dio ,.-T and a little programming skill to create a client to this service to retrieve c!stomersJ acco!nt
balances,
Sec!rity has been widely recogni9ed as a critical element for the s!ccess of *eb services, Microsoft has
partnered with +1M and :eriSign to develop the *eb Services Sec!rity '*S<Sec!rity( specification, This
specification describes how S=P messages can be a!gmented with sec!rity certificates, The *S<Sec!rity
specification is c!rrently implemented by *eb Services -nhancements '*S-( for Microsoft ,.-T,
Ac-nowledgments
245450494.doc 138 od 257
L8owler4;N 8owler, Martin, Patterns of Enterprise $pplication $rc"itecture, ddison<*esley, 344;,
LSkonnard4;N Skonnard, aron, @)ow SP,.-T *eb Services *ork,@ MS&N #i%rary, May 344;, vailable at:
http:>>msdn,microsoft,com>library>defa!lt,aspC!rlV>library>en<!s>dnwebsrv>html>howwebmeth,asp,
LTrowbridge4;N Trowbridge, David# Dave Mancini, Dave B!ick, "regor )ohpe, 2ames .ewkirk, and David
Lavigne, Enterprise Solution Patterns Using Microsoft .NET, Microsoft Press, 344;, lso available on the MS&N
$rc"itecture (enter at: http:>>msdn,microsoft,com>architect!re>patterns>defa!lt,asp&Cp!llV>library>en<
!s>dnpatterns>html>-sp,asp,
Implementing Ser7ice4=riented Integration with #i>Tal-
Ser7er !<<'

Integration Patterns
Contents
/onte&t
1ackgro!nd
+mplementation Strategy
-&ample
%es!lting /onte&t
Testing /onsiderations
Sec!rity /onsiderations
=perational /onsiderations
cknowledgments
Conte.t
Ho! are connecting two or more systems by !sing Service<=riented +ntegration, The service implementation
re?!ires the orchestration of m!ltiple f!nctions,
#ac-ground
245450494.doc 139 od 257
+n the "lobal 1ank scenario, the c!stomer can view his or her balances for all acco!nts, incl!ding loan
acco!nts, on a single page, To provide this f!nction, the *eb application server interacts with m!ltiple systems
to retrieve the re?!ired information, The loan acco!nts may reside on m!ltiple e&ternal loan systems that are
operated by s!bsidiaries that were ac?!ired over time, 8ig!re 6 shows how the *eb application server interacts
with the m!ltiple systems to display the acco!nt information in the c!stomerJs *eb browser,
/igure 11 Aggregated account balances &rom multiple ban-s
To hide the comple&ity of interacting with e&ternal loan systems, yo! want to design a service that the *eb
application server can easily access by !sing a single "et=therLoans re?!est,
Implementation Strategy
This pattern implements a Microsoft 1i9Talk Server 3445 orchestration and e&poses it as a *eb service, 1efore
disc!ssing detailed steps, it is helpf!l to review the concept of Ser!ice-riented Integration and to review some
details abo!t 1i9Talk Server orchestrations,
Ser7ice4=riented Integration
Ser!ice-riented Integration connects applications by e&changing doc!ments, +n many cases, these doc!ments
are represented in QML format, The following code shows a doc!ment passed in a S=P envelope,
45xm* 6ersion=78.07 enco&in1=7ut(9:750 4soap;En6e*ope0 4soap;@o&y0
4oan@a*anceRe)uest0 4#aster!ustomer%D08?>NOPK:4<#aster!ustomer%D0
4!orre*ation%D08800???4<!orre*ation%D0 4<oan@a*anceRe)uest0 4<soap;@o&y0
4<soap;En6e*ope0
245450494.doc 140 od 257
Ser!ice-riented Integration hides the comple&ity of the !nderlying service very well, 8or e&ample, the service
might e&ec!te a comple& process internally that has many parallel threads of activity, )owever, the comple&
internal process does not affect the service interface at all 'see 8ig!re 3(,
/igure !1 Comple.ity hidden behind a ser7ice4oriented inter&ace
5.posing a #i>Tal- =rchestration as a Web Ser7ice
Ho! can !se 1i9Talk Server 3445 to model comple& processes by !sing the 1i9Talk =rchestration Designer,
1i9Talk orchestrations interact with the o!tside world thro!gh logical ports as shown in 8ig!re ;, n
orchestration can interact with logical ports thro!gh send and receive ports that are incorporated into the
orchestration graph, Messages received from a receive port can start a new instance of an orchestration or
interact with an e&isting orchestration instance, n orchestration can send messages to any o!tp!t port thro!gh
the send port, sent message can either be the response to a previo!sly received message or to a standalone
message,
245450494.doc 141 od 257
/igure $1 An orchestration in7o-ed by a Web ser7ice call
Logical ports can be bo!nd to physical ports at design time or at deployment time, Physical ports specify a
transport type, s!ch as 8ile, 8ile Transfer Protocol '8TP(, )TTP, or S=P, Physical ports also specify a physical
location, s!ch as a directory name or a $%L, This separation of logical and physical ports allows yo! to create
and re!se orchestrations witho!t being tied to specific directory names or $%Ls, Ho! can specify a physical *eb
port by selecting the S=P transport protocol and by specifying a $%L,
fter yo! design an orchestration in 1i9Talk Server, yo! can e&pose it as a *eb service to be invoked from other
applications, The 1i9Talk *eb Services P!blishing *i9ard s!pports this task, generating both a physical port
definition and an SP,.-T *eb service that invokes the orchestration when it receives a S=P re?!est, 8or a
more detailed description of SP,.-T *eb services, see +mplementing Service<=riented +ntegration with
SP,.-T,
The following steps are necessary to create a 1i9Talk orchestration and to e&pose it as a *eb service to be
cons!med by other applications, To ill!strate this proced!re, all steps here are performed man!ally, )owever,
yo! can a!tomate some steps by scripting to the 1i9Talk *indows Management +nstr!mentation '*M+(
interface,
To e.pose a #i>Tal- orchestration as a Web ser7ice
6, De&ine the message schemas &or inbound and outbound messages, The message schemas
define the format of the messages that the orchestration receives and sends, $ltimately, the *eb
245450494.doc 142 od 257
Services Description Lang!age '*SDL( doc!ment generated by the SP,.-T *eb service !ses these
message schemas to specify the re?!ired format for inbo!nd and o!tbo!nd S=P messages,
3, De&ine logical re0uest4response ports, logical port is re?!ired so that the orchestration can
receive and send messages, re?!est<response port is a port that receives a re?!est message and
that sends a response within the same interaction,
;, De&ine the orchestration and connect it to the logical port, The orchestration encaps!lates the
tasks that the service needs to e&ec!te internally, /onnecting to the logical port starts a new instance
of the orchestration every time a new message arrives on the port,
5, #uild and deploy the orchestration, n orchestration has to be b!ilt and deployed to the global
assembly cache and to the 1i9Talk Management database before it can be e&ec!ted, Ho! !se the
1i9Talk Deployment *i9ard to deploy the orchestration,
A, Run the #i>Tal- Web Ser7ices Publishing Wi>ard, The wi9ard creates and compiles a Microsoft
:is!al St!dio proEect for an SP,.-T *eb service, +f yo! select the Create #i>Tal- Recei7e %ocation
option, the wi9ard also creates a physical port definition in the 1i9Talk config!ration database,
P, #ind the orchestrationDs logical port to the physical port, 1efore yo! can start the orchestration,
yo! m!st bind the logical port definition referenced by the orchestration to a physical port, To do this,
yo! !s!ally !se 1i9Talk -&plorer from within Microsoft :is!al St!dio ,.-T, +n this case, yo! bind the
logical port to the physical port that the *eb Services P!blishing *i9ard created,
O, Start the orchestration, *hen yo! start the orchestration, it begins to actively listen to incoming
messages, +n this case, the incoming messages are S=P re?!ests, The service is now live and
e&ec!tes the orchestration for each incoming S=P re?!est,
7, Create a test client that in7o-es the Web ser7ice, The SP,.-T *eb service generated by the
*eb Services P!blishing *i9ard renders the necessary *SDL doc!ment that describes the p!blic
service contract, This means that yo! can !se the *eb Services Description Lang!age tool '*sdl,e&e(
or :is!al St!dio ,.-T to easily create applications that cons!me the newly created *eb service,
5.ample
The following e&ample e&plains the architect!ral decisions involved and the steps performed in b!ilding the
"lobal 1ank sol!tion,
Asynchronous Interaction
+n the "lobal 1ank scenario, c!stomers can view their acco!nt balances, incl!ding loan balances, on a single
page, The loan balances, however, m!st be retrieved from e&ternal systems that may not always be available or
that may have slow response times, $sers indicated that ?!ick response times for the *eb site were more
important than complete information, Therefore, given that the system cannot g!arantee ?!ick response times,
the !ser re?!irements state that loan balances are optional for display on the :iew Sched!led Payments page,
This optional !ser re?!irement is reflected in the sol!tion architect!re by making the re?!est for the loan
balances asynchrono!s, This means that the *eb application server re?!ests the loan balances first, and then it
retrieves data from the mainframe and payment systems, fter all other data has been retrieved, the
application server checks whether the loan balances were retrieved, +f so, they are incorporated into the page
display, +f not, the page is rendered witho!t the loan balance portion, 8ig!re 5 shows the conc!rrent action in
$nified Modeling Lang!age '$ML(, The interaction between 1i9Talk Server and the individ!al loan systems is not
shown,
245450494.doc 143 od 257
/igure '1 Asynchronous interaction between the Web application ser7er and #i>Tal- Ser7er
Implementing Asynchronous Web Ser7ices
To make the interaction between the *eb application server and 1i9Talk Server asynchrono!s, yo! have three
implementation choices, The three implementation choices are ill!strated in 8ig!re A,
245450494.doc 144 od 257
/igure (1 Implementation choices &or asynchrony between the Web application ser7er and #i>Tal-
Ser7er
The three implementation choices from 8ig!re A can be s!mmari9ed as follows:
6, Client4side asynchrony, The *eb server iss!es a single S=P re?!est by !sing the asynchrono!s
*eb service P+, This P+ permits the client 'in this case, the client is the *eb application server( to
contin!e with other processing and to read the res!lts of the re?!est at a later time, This approach
permits the client to operate asynchrono!sly while the interaction with 1i9Talk Server is synchrono!s,
3, Asynchronous interaction with polling, The *eb server makes two S=P re?!ests to 1i9Talk
Server, =ne of the S=P re?!ests initiates the re?!est for loan information, This first re?!est only
initiates processing on the 1i9Talk Server side and ret!rns immediately, S!bse?!ently, the *eb server
iss!es a second S=P re?!est to poll for the res!lts, 1i9Talk Server ret!rns the res!lts if they are
available or ret!rns a blank message if they are not yet available, 1i9Talk Server discards the loan
balance res!lts if they become available after the *eb server polled for them,
;, Asynchronous interaction with callbac-, The *eb server iss!es a single S=P re?!est to initiate
the retrieval of loan information, s with option 1, control is ret!rned immediately to the *eb server,
The *eb server then goes on to other work, fter 1i9Talk Server has retrieved the loan information, it
sends a S=P re?!est back to the *eb server to pass the loan information, +t is important to note that
for this part of the interaction, the *eb server has to be able to service incoming S=P messages,
Therefore, the *eb server has to act as the server, The *eb server stores the loan information in a
global cache that is accessible to the threads that generated the re?!ests, 1efore the *eb server
renders the )TML page, it checks the global cache to see whether any loan information has arrived
while it was interacting with the mainframe and the /!stomer %elationship Management '/%M(
systems,
To choose the best option, yo! need to eval!ate the advantages and disadvantages of each option, Table 6
compares the different options,
245450494.doc 145 od 257
Table 1 Comparison o& the Implementation Choices &or Asynchronous Interaction
=ption A client4side
asynchrony
=ption # asynchronous
interaction with polling
=ption C asynchronous
interaction with
callbac-
/lient<side
implementation effort
Low Medi!m )igh
Server<side
implementation effort
Low Medi!m Medi!m>low
.etwork traffic Low )igher )igher
-fficient !se of reso!rces Poor 'for long<r!nning
interactions(
"ood "ood
*here state is kept /onnection Server /lient
s yo! can see, each option has its advantages and disadvantages, Therefore, yo! m!st make yo!r decision
based on the priorities that yo! assign to the individ!al criteria,
ltho!gh option may be the easiest to constr!ct, it is essentially a synchrono!s S=P interaction that E!st
appears to be asynchrono!s to the client code beca!se the connection between the client and the service
remains active thro!gho!t the whole interaction, The !se of long<standing connections can ?!ickly deplete
system reso!rces and can be one of the biggest impediments to a sol!tionJs scalability, 1eca!se the loan
balance service has to access e&ternal loan systems over slow and !nreliable connections, the interaction can
definitely be long r!nning, Therefore, yo! sho!ld eliminate option ,
The choice between option 1 and / is more diffic!lt and depends on whether yo! want to maintain the state on
the client 'the *eb application server( or on the server r!nning 1i9Talk Server, 1oth servers are m!ltithreaded
and ?!ite efficient at keeping state for many conc!rrent re?!ests, The choice also depends on where yo! want
to allocate the additional development effort, Do yo! prefer to p!t additional effort into the SP,.-T code on
the *eb server or into the orchestration design on the server r!nning 1i9Talk ServerC =ption 1 re?!ires a little
e&tra work on the 1i9Talk Server to ens!re proper correlation and to allow the conc!rrent servicing of m!ltiple
re?!ests, =ption / re?!ires additional coding effort in the *eb server to maintain and to clear the global cache,
=verall, option 1 offers the best res!lts for the smallest amo!nt of development effort and is the first choice,
)owever, this disc!ssion highlights that architect!ral decisions are not only based on technical considerations
alone b!t also on development reso!rce constraints and skills preferences,
#uilding the Solution
1ased on the tradeoffs disc!ssed in the previo!s section, "lobal 1ank decided to !se option 1, asynchrono!s
interaction with polling, The ne&t step was to start b!ilding the sol!tion, The rest of this e&ample shows yo! the
steps re?!ired to b!ild the "lobal 1ank sol!tion, D!e to the large n!mber of steps involved in creating the
sol!tion, some steps are not covered in f!ll detail,
245450494.doc 146 od 257
Step 1 De&ine the 2essage Schemas &or Inbound and =utbound 2essages
To define the format of the re?!est and response messages, create two QML Schema 'QSD( files in the :is!al
St!dio ,.-T QSD -ditor, The QSD schema for the Loan1alance%e?!est,&sd re?!est message looks like the
following schema, To improve readability, the namespace declarations are omitted,
4xs;schemaB0 4xs;e*ement name=7oan@a*anceRe)uest70 4xs;comp*ex"ype0
4xs;se)uence0 4xs;e*ement min,ccurs=787 max,ccurs=787
name=7#aster!ustomer%D7 type=7xs;strin17 <0 4<xs;se)uence0
4<xs;comp*ex"ype0 4<xs;e*ement0 4<xs;schema0
The doc!ment specifies a single Master/!stomer+D data field for the re?!est message, The Master/!stomer+D
field is common across all systems and can be !sed to locate all the c!stomerJs acco!nts,
+n response to the re?!est, the application ret!rns the following acknowledgement 'ck,&sd(,
4xs;schemaB0 4xs;e*ement name=7+ck70 4xs;comp*ex"ype0 4xs;se)uence0
4xs;e*ement name=7!orre*ation%D7 type=7xs;strin17 <0 4<xs;se)uence0
4<xs;comp*ex"ype0 4<xs;e*ement0 4<xs;schema0
The only field in this schema is a !ni?!e correlation identifier, The orchestration assigns an +D to this field and
!ses it later to match 'or correlate( the re?!est and response messages across the asynchrono!s
comm!nication, 8or more information, see the (orrelation Identifier pattern in Enterprise Integration Patterns
L)ohpe45N,
fter receiving the acknowledgment response from the orchestration, the client polls the orchestration for the
res!lt,
The client application copies the correlation identifier ret!rned in the acknowledgment message 'ck,&sd( into
Poll%e?,&sd, Poll%e?,&sd has only one field '/orrelation+D(, as shown in the following schema,
4xs;schemaB0 4xs;e*ement name=7Po**Re)70 4xs;comp*ex"ype0 4xs;se)uence0
4xs;e*ement name=7!orre*ation%D7 type=7xs;strin17 <0 4<xs;se)uence0
4<xs;comp*ex"ype0 4<xs;e*ement0 4<xs;schema0
The QSD code for the Loan1alance%esponse,&sd response message looks like the following,
4xs;schema B0 4xs;e*ement name=7oan@a*anceResponse70 4xs;comp*ex"ype0
4xs;se)uence0 4xs;e*ement name=7oan70 4xs;comp*ex"ype0 4xs;se)uence0
4xs;e*ement name=7Name7 type=7xs;strin17 <0 4xs;e*ement name=7+ccount%D7
type=7xs;strin17 <0 4xs;e*ement name=7+mount7 type=7xs;&ecima*7 <0
4<xs;se)uence0 4<xs;comp*ex"ype0 4<xs;e*ement0 4<xs;se)uence0
4<xs;comp*ex"ype0 4<xs;e*ement0 4<xs;schema0
The response message schema defines a list of acco!nt names and balances, This list is filled in by the *eb
service 'thro!gh the orchestration(, The completed message is then sent back to the client,
Step ! De&ine %ogical Re0uest4Response Ports
+n 1i9Talk =rchestration Designer, add a port to the orchestration, and then !se the Port /onfig!ration *i9ard
to config!re a p!blic re?!est<response port, 8ig!re P indicates the Re0uest4Response option,
245450494.doc 147 od 257
/igure )1 "sing the #i>Tal- Port Con&iguration Wi>ard to add a re0uest4response port
+n addition to selecting the Re0uest4Response setting, yo! m!st change the Access Restrictions setting to
PublicGno limit,
Step $ De&ine the =rchestration and Connect It to the %ogical Port
s described in @+mplementing synchrono!s *eb Services,@ the interaction between the *eb server and the
1i9Talk Server orchestration consists of two parts:
The *eb server re?!ests loan information from 1i9Talk Server,
The *eb server polls for res!lts, The 1i9Talk Server orchestration ret!rns a response immediately with
the res!lts it retrieved !p to that point,
1ased on "lobal 1ank re?!irements, the orchestration m!st:
6, Recei7e the initial re0uest &rom the Web ser7er, The orchestration creates a new instance of the
orchestration for each re?!est,
3, Generate a uni0ue correlation identi&ier to pass bac- to the client, The orchestration ret!rns
the correlation identifier back to the *eb server so that it can !se this identifier to poll later for the
res!lts,
;, Re0uest the loan balance &rom multiple bac-end loan systems, These re?!ests can be made
conc!rrently, The res!lts from each loan system have to be combined into a single message, +n this
e&ample, both loan systems are accessible thro!gh preb!ilt *eb services,
5, Ser7ice the polling re0uest, The orchestration has to be able to receive a polling re?!est from the
*eb server at any time, *hen it receives a polling re?!est, the orchestration ret!rns the loan balances
if they have been obtained already, =therwise, the orchestration ret!rns a blank res!lt, The polling
re?!est can arrive at any time after the initial re?!est,
245450494.doc 148 od 257
A, Time out, +f the orchestration does not receive a polling re?!est after an e&tended period of time 'for
e&ample, P4 seconds(, the orchestration is terminated, This f!nction keeps orchestration instances
from staying active indefinitely while they are waiting for a polling re?!est,
8ig!re O shows these tasks modeled inside a 1i9Talk Server orchestration,
/igure *1 The #i>Tal- Ser7er orchestration &or loan balances ?Clic- the image to enlarge it@
.ow, letJs e&amine the orchestration tasks in more detail, The letters in the following list correlate to the letters
in 8ig!re O,
A Recei7e the Initial Re0uest &rom the Web Ser7er
+n the "lobal 1ank scenario, the SP,.-T client sends a re?!est for a c!stomerJs loan balances '"et=therLoans(
to 1i9Talk Server, Loan1alance%e?!est,&sd defines the format of the re?!est, The re?!est contains only the
Master/!stomer+D field 'see @Step 6: Define the Message Schemas for +nbo!nd and =!tbo!nd Messages@(,
The re?!est is received thro!gh the Recei7eRe0 port in the orchestration 'see 8ig!re O(, fter the message is
received, the port forwards it to the Recei7eRe0 Recei7e shape, The Acti7ate property of the Recei7eRe0
Recei7e shape is set to True, which activates the orchestration,
# Generate a Correlation Identi&ier and Send Ac-nowledgment
fter the SP,.-T client sends the initial re?!est to 1i9Talk Server, it receives an acknowledgment message
'ck,&sd(, This message contains the /orrelation+D field, The /orrelation+D field identifies the orchestration
instance associated with the initial re?!est, This field g!arantees that incoming messages are associated with
the correct instance of the orchestration,
To create the correlation +D, yo! can !se a c!stom /S class that !ses System1Random to generate and ret!rn
an +D, That +D is assigned to the /orrelation+D field of the ck,&sd message, and it is ret!rned to the client,
lternatively, yo! can assign one of the 1i9Talk Server message conte&t properties '#TS12essageID( as a
!ni?!e +D to the /orrelation+D field of the ck,&sd message, This is accessible within an 5.pression shape in
the orchestration,
8or the /orrelation+D field to be accessible to the code in the -&pression -ditor window, yo! m!st !se the
1i9Talk Schema -ditor to promote it, as shown in 8ig!re 7,
245450494.doc 149 od 257
/igure 91 Promoting a schema &ield
fter the acknowledgment response is created, the SendIAc- send shape sends the response to the receive<
re?!est port, and the receive<re?!est port then ret!rns it to the client, The Send shape sho!ld be config!red to
initiali9e the orchestration correlation set, To accomplish this, add a correlation type and a correlation set in the
=rchestration :iewer, and then set the Initiali>e Correlation property of the Send shape to the new
correlation type yo! created, *hen the orchestration sends the message to the client, the correlation set is
a!tomatically initiali9ed with the val!e in the /orrelation+D field,
C Re0uest the %oan #alances
The initial re?!est from the client activated the orchestration, The orchestration then synchrono!sly ret!rned an
acknowledgment containing the /orrelation+D to the client, .ow, to retrieve the c!stomerJs loan balance, the
orchestration needs to call the e&ternal systems that are implemented as two *eb services,
"et=therLoans6,asm& and "et=therLoans3,asm&, The re?!est and response messages to these *eb services
are fairly simple, -ach takes a c!stomer +D as a re?!est and ret!rns the loan information that corresponds to
that c!stomer +D, This is shown in the following selection from the "et=therLoan6,asm& e&ternal *eb service
re?!est schema,
45xm* 6ersion=78.07 enco&in1=7ut(98P7 5 0 4xs;schema ..0 4xs;e*ement
name=7Re)uest70 4xs;comp*ex"ype0 4xs;se)uence0 4xs;e*ement
name=7!ustomer%&7 type=7xs;strin17 <0 4<xs;se)uence0 4<xs;comp*ex"ype0
4<xs;e*ement0 4<xs;schema0
,ote The namespace information in these e&amples is omitted here for brevity,
t this stage, the clientJs re?!est m!st be transformed into the message format that the e&ternal *eb services
re?!ire, -ach e&ternal *eb service can have a different schema, altho!gh both schemas are identical in this
e&ample, The following is the key portion of the "et=therLoans6,asm& e&ternal *eb service response schema,
245450494.doc 150 od 257
45xm* 6ersion=78.07 enco&in1=7ut(98P7 5 0 4xs;schema B0 4xs;e*ement
name=7Response70 4xs;comp*ex"ype0 4xs;se)uence0 4xs;e*ement name=7Name7
type=7xs;strin17 <0 4xs;e*ement name=7+mount7 type=7xs;strin17 <0
4xs;e*ement name=7+ccountNo7 type=7xs;strin17 <0 4<xs;se)uence0
4<xs;comp*ex"ype0 4<xs;e*ement0 4<xs;schema0
To transform one schema into another, Trans&orm shapes in /onstr!ct*ST%e?6 and /onstr!ct*ST%e?3 map
the /!stomer+d fields of the two schemas, Ho! !se the 1i9Talk Mapper to map the Master/!stomer+D field of
Loan1alance%e?!st,&sd to the /!stomer+d field of the *eb serviceJs re?!est schema 'see 8ig!re M(,
/igure ;1 "sing #i>Tal- 2apper to map re0uest &ields ?Clic- the image to enlarge it@
.ow that the *eb servicesJ re?!est messages have been constr!cted, the response messages have to be
parsed and cons!med, +n 1i9Talk Sol!tion -&plorer, open the *eb serviceJs %eference,&sd file, $sing the
Promote option, disting!ish the ,ame, Account,o, and Amount elements of the *eb service response
schema 'see 8ig!re 7(, Disting!ishing these fields allows the code in the Add%oan1 and Add%oan!
5.pression shapes to reference their val!es and !se them to constr!ct the response doc!ment,
.e&t, yo! !se the response from each *eb service to constr!ct a Loan1alance%esponse,&sd response that is
ret!rned to the client, To accomplish this, Add%oan1 and Add%oan! 5.pression shapes !se a c!stom /S
class '%oanIn&oCollection( to collect the res!lts ret!rned by each *eb service, -ach *eb service ret!rns the
,ame, Account,o, and Amount for the c!stomerJs loan, The c!stom class aggregates the responses into an
QML doc!ment which is ret!rned to the polling client as the Loan1alance%esponse,&sd response, The following
is the code from the 5.pression property of Add%oan1,
oan%n(o!o**ection.+&&oan( ms1-ebSer68JResp.Aetoan%n(oResu*t.Name'
ms1-ebSer68JResp.Aetoan%n(oResu*t.+mount'
ms1-ebSer68JResp.Aetoan%n(oResu*t.+ccountNo)E
1eca!se all three branches of the parallel action !se the %oanIn&oCollection class, the Add%oan1 and
Add%oan! 5.pression shapes are inside synchroni9ed blocks 'ScopeI%oanIn&o1 and ScopeI%oanIn&o!
respectively(, The Transaction Type property of the synchroni9ed blocks is set to Atomic to protect the class
from conc!rrent access, 8or more information abo!t transactions in 1i9Talk Server, see +mplementing Process
+ntegration with 1i9Talk Server 3445.
245450494.doc 151 od 257
D Ser7ice Polling Re0uest
t this point, the response message has been constr!cted and is ready to be delivered to the client, The client
polls the orchestration by sending a S=P message to 1i9Talk Server, The message contains the correlation +D
that identifies the instance of the orchestration that is associated with this re?!est,
The PollRe0Resp port is linked to the Recei7ePollRe0 receive shape, The Recei7ePollRe0 receive shape has
an important property, /ollowing Correlation Sets, This property is set to the correlation type created earlier
in step 1, and it allows 1i9Talk Server to associate the polling re?!est to the correct instance of this
orchestration,
The re?!est message is then assigned the loan information gathered from *eb services by the
%oanIn&oCollection class within the Construct Response shape of ScopeICreateResponse,
s the final step, the SendPollResp Send shape sends the constr!cted response message that is mentioned
earlier to the PollRe0Resp port, The PollRe0Resp port then sends the constr!cted response message to the
polling client,
5 Time =ut
*ith respect to the polling re?!est, there are two potential scenarios that yo! have to design the orchestration
to handle properly, +n the first scenario, the client may poll too early, before the orchestration has received a
response from e&ternal *eb services and constr!cted the response message, +n the second scenario, the client
may not poll at all, +f the client does not poll at all, the orchestration instance is left in an active state forever,
To handle early polling, yo! m!st allow the client to poll again if no res!lts are ret!rned, To accomplish this, yo!
add a loop and set it to r!n indefinitely, +n this case, add a PollI%oop, .ote, however, that the loop is limited
by the Timeout property val!e of the orchestration,
To set the Timeout val!e for the orchestration, set the Transaction Type property to %ong Running, and set
the Timeout property val!e to )< seconds or another appropriate val!e, This allows the client eno!gh time to
poll for the res!lt and eliminates the possibility that an orchestration co!ld r!n indefinitely,
Step ' #uild and Deploy the =rchestration
1efore yo! b!ild the orchestration, create an assembly key file by typing snG- S=Iwith#i>Tal-1sn- at the
command prompt, /opy the file to the proEect folder, and then enter the file name in the Assembly 6ey /ile
name property of the proEect properties,
,ote Ho! need to b!ild the %oanIn&oCollection assembly that is referenced by the proEect by !sing a strong
name assembly key file, Ho! then m!st deploy it to the global assembly cache,
8rom the :is!al St!dio ,.-T men!, b!ild the sol!tion, This creates a ,.-T 8ramework assembly called
S=Iwith#i>Tal-, Ho! then deploy the S=Iwith#i>Tal- assembly by !sing the 1i9Talk Server Deployment
*i9ard or by !sing the scripts that are incl!ded with the 1i9Talk 3445 SD0,
245450494.doc 152 od 257
Step ( Run the #i>Tal- Web Ser7ices Publishing Wi>ard
To e&pose the S=Iwith#i>Tal- assembly that yo! deployed in step A as a *eb service, r!n the 1i9Talk *eb
Services P!blishing *i9ard, The wi9ard creates the S=+with1i9talkTPro&y *eb service, The
S=+with1i9talkTPro&y *eb service e&poses *eb services corresponding to the Recei7eRe0 and PollRe0Resp
ports,
Step ) #ind the =rchestrationDs %ogical Port to the Physical Port
The *eb Services P!blishing *i9ard that yo! ran in step 5 also created two receive ports for the Recei7eRe0
and PollRe0Resp ports, which yo! can access thro!gh 1i9Talk -&plorer,
,ote The Recei7e Pipeline property of these ports sho!ld be set to EmlRecei7e, To set this property in
1i9Talk -&plorer, select the port, right<click the port name, and then click 5dit on the conte&t men!,
.e&t, yo! need to add two send ports for the Get=ther%oan1 and Get=ther%oan! *eb ports, The Recei7e
Pipeline properties of these ports also sho!ld be set to EmlRecei7e instead of the defa!lt PassThrough
setting,
fter yo! set !p the physical ports, bind the orchestration to these ports in 1i9Talk -&plorer, .ote that there are
two inbo!nd ports and two o!tbo!nd ports in the Port 1inding Properties window of the orchestration, Ho! can
also !se the 1TSDeploy command line !tility and a binding file to bind ports, $se the 5.port #i>Tal-
assembly binding to &ile option in 1i9Talk Deployment *i9ard to create the binding file,
Step * Start the =rchestration
fter binding the logical ports to physical ports, start the orchestration in 1i9Talk -&plorer,
Step 9 Create a Test Client That In7o-es the Web Ser7ice
To test the orchestration, yo! need to create a client that cons!mes the *eb service created from the
orchestration in step 5, s yo! saw in step 5, the wi9ard created two *eb services that correspond to the two
re?!est<response ports of the orchestration, The following code shows part of the *SDL file for
Poll%e?%esp,asm&, 8or the sake of clarity, some parts of the file are not shown here,
4types0 M 4s;schema e*ement$ormDe(au*t=7)ua*i(ie&7
tar1etNamespace=7http;<<ms&n.microso(t.com<soi70 9 4s;schema
e*ement$ormDe(au*t=7)ua*i(ie&7
tar1etNamespace=7http;<<S,%=ith@iDta*k.Po**Re)70 4s;e*ement name=7Po**Re)7
type=7s8;Po**Re)7 <0 9 4s;comp*ex"ype name=7Po**Re)70 4s;se)uence0
4s;e*ement min,ccurs=707 max,ccurs=787 (orm=7un)ua*i(ie&7
name=7!orre*ation%&7 type=7s;strin17 <0 4<s;se)uence0 4<s;comp*ex"ype0
4<s;schema0 9 4s;schema e*ement$ormDe(au*t=7)ua*i(ie&7
tar1etNamespace=7http;<<S,%=ith@iDta*k.Po**Resp70 4s;e*ement
name=7Po**Resp7 type=7s?;Po**Resp7 <0 9 4s;comp*ex"ype name=7Po**Resp70 9
4s;se)uence0 4s;e*ement min,ccurs=707 max,ccurs=787 (orm=7un)ua*i(ie&7
name=7oans7 type=7s?;+rray,(Po**Respoan7 <0 4<s;se)uence0
4<s;comp*ex"ype0 9 4s;comp*ex"ype name=7+rray,(Po**Respoan70 9
4s;se)uence0 4s;e*ement min,ccurs=707 max,ccurs=7unboun&e&7
(orm=7un)ua*i(ie&7 name=7oan7 type=7s?;Po**Respoan7 <0 4<s;se)uence0
4<s;comp*ex"ype0 9 4s;comp*ex"ype name=7Po**Respoan70 9 4s;se)uence0
4s;e*ement min,ccurs=707 max,ccurs=787 (orm=7un)ua*i(ie&7 name=7+mount7
type=7s;strin17 <0 4s;e*ement min,ccurs=707 max,ccurs=787
(orm=7un)ua*i(ie&7 name=7Name7 type=7s;strin17 <0 4s;e*ement min,ccurs=707
245450494.doc 153 od 257
max,ccurs=787 (orm=7un)ua*i(ie&7 name=7+ccountNo7 type=7s;strin17 <0
4<s;se)uence0 4<s;comp*ex"ype0 4<s;schema0 4<types0 M 4messa1e
name=7Po**Re)RespSoap%n70 M 4messa1e name=7Po**Re)RespSoap,ut70 M 4port"ype
name=7S,%=ith@iDta*kJS,%=ith@iDta*kJ,rchestrationJPo**Re)RespSoap70 M
4bin&in1 name=7S,%=ith@iDta*kJS,%=ith@iDta*kJ,rchestrationJPo**Re)RespSoap7
type=7s0;S,%=ith@iDta*kJS,%=ith@iDta*kJ,rchestrationJPo**Re)RespSoap70 9
4ser6ice name=7S,%=ith@iDta*kJS,%=ith@iDta*kJ,rchestrationJPo**Re)Resp70
4&ocumentation0@iD"a*k assemb*y 7S,%=ith@iDta*k' Qersion=8.0.0.0'
!u*ture=neutra*' Pub*icRey"oken=cPNSOa8a:Nc(:a&>7 pub*ishe& =eb
ser6ice.4<&ocumentation0 9 4port
name=7S,%=ith@iDta*kJS,%=ith@iDta*kJ,rchestrationJPo**Re)RespSoap7
bin&in1=7s0;S,%=ith@iDta*kJS,%=ith@iDta*kJ,rchestrationJPo**Re)RespSoap70
4soap;a&&ress
*ocation=7http;<<*oca*host<S,%=ith@iDta*kJProxy<S,%=ith@iDta*kJS,%=ith@iDta
*kJ,rchestrationJPo**Re)Resp.asmx7 <0 4<port0 4<ser6ice0 4<&e(initions0
The test client is a *indows 8orm application that !ses the .$nit test tool, 8or more information abo!t this
tool, see www,n!nit,org, The following test case sends a re?!est to 1i9Talk Server, waits, and then polls for the
res!lt,
F"estG pub*ic 6oi& "estRe)uest+n&Po**ater()
C Re)uest-S.S,%=ith@iDta*kJS,%=ith@iDta*kJ,rchestrationJRecei6eRe) =s = ne=
"estS,%=ith@iDta*k.Re)uest-S.S,%=ith@iDta*kJS,%=ith@iDta*kJ,rchestrationJRe
cei6eRe)()E Re)uest-S.Re)uest re) = ne= Re)uest-S.Re)uest()E
re).#aster!ustomer%D = 78?>N7E Re)uest-S.+ck resp = =s.%nitia*Re)uest(re))E
strin1 cor%& = resp.!orre*ation%&E <<=ait (or externa* ser6ices to return
response System."hrea&in1."hrea&.S*eep(P000)E <<po** (or resu*t
Po**-S.S,%=ith@iDta*kJS,%=ith@iDta*kJ,rchestrationJPo**Re)Resp po**=s = ne=
"estS,%=ith@iDta*k.Po**-S.S,%=ith@iDta*kJS,%=ith@iDta*kJ,rchestrationJPo**R
e)Resp()E Po**-S.Po**Re) po**re) = ne= "estS,%=ith@iDta*k.Po**-S.Po**Re)()E
po**re).!orre*ation%& = cor%&E Po**-S.Po**Resp po**resp =
po**=s.Po**Re)Resp(po**re))E +ssertion.+ssertE)ua*s(?'
po**resp.oans.en1th)E <<test resu*ts
Qa*i&ateoanEntry(po**resp.oansF0G)E Qa*i&ateoanEntry(po**resp.oansF8G)E
H pri6ate 6oi& Qa*i&ateoanEntry(Po**-S.Po**Respoan entry) C << note; the
responses &o not ha6e to be in or&er i( (entry.+ccountNo.E)ua*s(78?>N7))
C +ssertion.+ssertE)ua*s(780007' entry.+mount)E H e*se i(
(entry.+ccountNo.E)ua*s(7OPK:7)) C +ssertion.+ssertE)ua*s(7?0007'
entry.+mount)E H e*se C +ssertion.$ai*(7-ron1 account number7)E H H
Resulting Conte.t
This implementation of Ser!ice-riented Integration res!lts in the following benefits and liabilities:
#ene&its
Power&ul, Ho! can !se 1i9Talk Server 3445 to model comple& processes comprising m!ltiple parallel
interactions, Ho! can even b!ild a hierarchy of orchestrations where one orchestration invokes other
orchestrations, 1i9Talk Server also imports important concepts that are critical when developing
asynchrono!s, event<driven sol!tions, These sol!tions incl!de correlation, synchroni9ation, timeo!ts, long<
r!nning transactions, and compensating actions,
Integrated de7elopment tools, The 1i9Talk Server 3445 vis!al modeling tools are integrated into
:is!al St!dio ,.-T, This greatly enhances the development e&perience for mi&ed development consisting of
act!al /S or :is!al 1asic ,.-T code and vis!al models from maps and orchestrations,
=perational support, Monitoring and operating *eb services sol!tions can be diffic!lt, 1i9Talk Server
3445 incl!des sophisticated tools to monitor the flow of messages and the e&ec!tion of orchestrations
thro!gh the )ealth and ctivity Tracker ')T( tool,
245450494.doc 154 od 257
%iabilities
Comple.ity, ltho!gh 1i9Talk Server 3445 provides many !sef!l feat!res, it also introd!ces a series
of new concepts, a large n!mber of moving parts, and a different development environment than what
developers are !sed to, This can increase the learning c!rve for application developers,
Testing Considerations
There are several possible options available when testing this implementation, 8irst, the *eb service as a whole
can be tested by writing a test client in the ,.-T 8ramework, To create the test client, create a new /S console
application, and !se the Add Web Re&erence command in :is!al St!dio Sol!tion -&plorer to create a
reference to the orchestration *eb service, Ho! can then write test code that invokes the *eb service,
S!bse?!ently, yo! can add a!tomated test cases to this test client by !sing test tools s!ch as .$nit,
fter r!nning the test client, yo! can !se the =rchestration Deb!gger to e&amine traces of the orchestration
e&ec!tion, Ho! can access the =rchestration Deb!gger from the )T tool and !se the =rchestration Deb!gger in
two modes: reporting mode and interactive mode, %eporting mode tracks the e&ec!tion of each shape in the
orchestration as it occ!rs, +n reporting mode, yo! can replay the steps or set breakpoints on the class of
orchestration so that yo! can then deb!g new instances in interactive mode, +nteractive mode enables yo! to
deb!g a c!rrently r!nning instance, To deb!g a process interactively, set a breakpoint within an orchestration
while in reporting mode, and then s!bmit a new message 'create a new instance of an orchestration(, The
orchestration will stop at the breakpoint, and yo! can then attach the orchestration deb!gger to that instance,
Security Considerations
The *eb service implementation presented here does not address sec!rity considerations, ppropriate sec!rity
meas!res are essential in this scenario beca!se the *eb service e&poses sensitive acco!nt data that resides in
the bankJs mainframe comp!ter, -ven tho!gh the *eb service resides behind the firewall, yo! wo!ld not want
!na!thori9ed !sers to create a client to this service to retrieve c!stomersJ acco!nt balances,
Sec!rity is implemented at m!ltiple levels when e&posing an orchestration as a *eb Service:
Transport security, The 1i9Talk *eb Services P!blishing *i9ard creates an SP,.-T virt!al directory
like any other SP,.-T *eb service, S=P messages sent to this virt!al directory can be sent by !sing
)TTPS 'encrypted(, dditionally, the virt!al directory can be config!red to re?!ire basic a!thentication,
.TLM a!thentication, or even client certificates,
S=AP security, Microsoft has partnered with +1M and :eriSign to develop the *eb Services Sec!rity
'*S<Sec!rity( specification, The *S<Sec!rity specification describes how S=P messages can be
a!gmented with sec!rity certificates, The *S<Sec!rity specification is c!rrently implemented by *eb
Services -nhancements '*S-( for Microsoft ,.-T, The c!rrent version of the S=P adapter does not
s!pport *S<Sec!rity, b!t this f!nctionality can be s!pported by !sing c!stom pipeline components in the
1i9Talk receive and send pipelines,
Recei7e adapter security, The S=P adapter is r!n by a 1i9Talk Server +solated )ost instance within
a specific Microsoft *indows sec!rity conte&t, +f the 1i9Talk +solated )ost was installed as tr!sted, then the
!ser that ac?!ires a!thentication when r!nning the *eb service m!st be a member of the 1i9Talk +solated
)ost $sers gro!p 'this is often the +$S%Tcomputer name acco!nt(, +f the 1i9Talk +solated )ost was not
installed as tr!sted, the SP,.-T acco!nt m!st be a member of the 1i9Talk +solated )ost $sers gro!p,
Recei7e port security, Ho! can config!re the receive port to re?!ire messages to be a!thenticated
before they are processed, Messages are a!thenticated in the %esolveParty stage of the receive pipeline by
245450494.doc 155 od 257
!sing a client certificate or by !sing a Sec!rity +dentifier 'S+D(, Messages that are not a!thenticated can
either be dropped or saved, b!t they are not processed,
=perational Considerations
Many of the 1i9Talk receive adapters, incl!ding the )TTP and the S=P adapters, perform batching to optimi9e
thro!ghp!t and server reso!rce !tili9ation by minimi9ing polling, The defa!lt batch si9e is 64, and there is a
delay between polls of one second, This means that a single synchrono!s )TTP post or S=P call is processed,
b!t beca!se it is not a complete batch, the adapter waits for one second before polling again, Therefore,
s!ccessive calls may be delayed, This is appropriate behavior in high<transaction sit!ations, b!t it is not
appropriate behavior for a highly responsive system,
To make the )TTP and S=P adapters more responsive, yo! can set the registry 3ttp#atchSi>e s!bkey
DW=RD val!e in the 36%2JCurrentControlSetJ#tsS7c $1<J3ttpRecei7e registry key to 1, Setting this
val!e to 1 affects the ma&im!m thro!ghp!t that the adapter is capable of handling,
Ac-nowledgments
L)ohpe45N )ohpe, "regor, and 1obby *oolf, Enterprise Integration Patterns1 &esigning0 )uilding0 and
&eploying Messaging Solutions, ddison<*esley, 3445,
Presentation Integration

Integration Patterns
Contents
liases
/onte&t
Problem
8orces
Sol!tion
-&ample
%es!lting /onte&t
Testing /onsiderations
245450494.doc 156 od 257
Sec!rity /onsiderations
cknowledgments
Aliases
Screen scraping
Conte.t
Ho! have m!ltiple independent applications that are organi9ed as f!nctional silos, -ach application has a !ser
interface,
Problem
)ow do yo! integrate information systems that were not designed to work togetherC
/orces
To correctly solve this problem, yo! need to consider the following forces:
*hen integrating m!ltiple applications, yo! sho!ld minimi9e changes to e&isting systems beca!se any
change to an e&isting prod!ction system represents a risk and might re?!ire e&tensive regression testing,
1eca!se many comp!ter systems are designed according to the Layered pplication pattern, some of
the layers are typically deployed in physical tiers that are not e&ternally accessible, 8or e&ample, sec!rity
policy may re?!ire the database tier of an application to reside on a separate physical server that is not
directly accessible to other applications, Most *eb applications allow e&ternal access only to the !ser
interface and protect the application and database tiers behind firewalls,
Many applications feat!re little or no separation between b!siness and presentation logic, The only
remote components of these applications are simple display and inp!t devices, These display terminals
access the central mainframe comp!ter, and the central mainframe comp!ter hosts all b!siness logic and
data storage,
The b!siness logic layer of many applications is programming<lang!age specific and is not available
remotely, !nless it was developed on top of a specific remoting technology s!ch as D/=M or /ommon
=bEect %e?!est 1roker rchitect!re '/=%1(,
Directly accessing an applicationJs database layers can ca!se corr!ption of application data or
f!nctionality, +n most applications, important b!siness r!les and validations reside in the b!siness logic,
and they often reside in the presentation layer also, This logic is intended to prevent erroneo!s !ser entry
from affecting the integrity of the application, Making data !pdates directly thro!gh the data store
bypasses these protection mechanisms and increases the risk of corr!pting the applicationJs internal state,
Solution
ccess the applicationJs f!nctionality thro!gh the !ser interface by sim!lating a !serJs inp!t and by reading
data from the screen display, 8ig!re 6 shows the elements of a sol!tion that is based on the Presentation
Integration pattern,
245450494.doc 157 od 257
/igure 11 Presentation Integration connects to an e.isting application through the presentation
layer
The Presentation Integration pattern is sometimes disparagingly called screen scraping beca!se the middleware
collects 'or scrapes( the information from the information that is displayed on the screen d!ring a !ser session,
/ollecting information from the screen of the !ser session tends to be the simpler part of the integration, The
more diffic!lt part tends to occ!r when the middleware has to locate the correct screen in the application in the
same way a h!man !ser has to,
To sim!late !ser interaction, the integration sol!tion has to !se a terminal em!lator that appears to the
application as a reg!lar terminal, b!t that can be controlled programmatically to sim!late !ser inp!t, S!ch a
terminal em!lator is !s!ally specific to the e&act type of !ser interface device that is s!pported by the
application, 8ort!nately, in the mainframe world, +1MJs ;3O4 terminal standard is so widespread that many
commercial ;3O4 terminal em!lators are available, +nstead of displaying information to the !ser, these
em!lators make the screen data available thro!gh an P+, +n the case of ;3O4 em!lators, a standard P+ e&ists
that is called the )igh Level Lang!age pplication Program +nterface ')LLP+(, The em!lator can send data to
the application to sim!late keystrokes that a !ser wo!ld make on a real ;3O4 terminal, 1eca!se the terminal
em!lator mimics a !serJs actions, it !s!ally does not depend on the specific application that it is interacting
with, dditional middleware logic m!st encode the correct keystrokes and e&tract the correct fields from the
virt!al screen,
The widespread trend of e?!ipping applications with *eb<based interfaces has revived interest in !sing
Presentation Integration as a vital integration approach, *eb applications are easily accessible over the
+nternet, )owever, the only accessible portion is the !ser interface that is accessed thro!gh the relatively
245450494.doc 158 od 257
simple )TTP protocol, *eb applications transmit presentation data in )TML, 1eca!se )TML is relatively easy to
parse programmatically, Presentation Integration is a pop!lar approach,
$nfort!nately, the ease of collecting information from a providerJs *eb page over the +nternet has ca!sed some
application providers to intentionally e&ploit the biggest weakness of Presentation Integration: brittleness,
1eca!se Presentation Integration !s!ally depends on the e&act geometric layo!t of the information, rearranging
data fields can easily break a Presentation Integration sol!tion, The graphical nat!re of )TML allows a provider
to easily modify the )TML code that describes the layo!t of the information on the screen, The layo!t changes
then block any attempt to collect information from the *eb page,
Presentation Integration is based on the interaction between the components that are described in Table 6,
Table 1 Presentation Integration Components
Component Responsibilities Collaborators
Presentation layers < %ender a vis!al presentation to be
displayed on a !ser terminal
< ccept !ser inp!t and translate it into
commands to be e&ec!ted by the b!siness
logic
Terminal em!lator
Terminal em!lator < +mpersonates a !ser session to the
presentation layer
< Makes screen information available
thro!gh an P+
< llows other applications to iss!e
commands to the presentation tier
Presentation layer and other
applications
=ther applications < /ons!me application data
< +ss!e commands
Terminal em!lator
5.ample
big challenge faced by government agencies is the lack of integrated data across m!ltiple state agencies, 8or
e&ample, integrated data gives an income ta& agency a more holistic view of a b!siness beca!se the integrated
data might show the n!mber of employees that the b!siness has and the amo!nt of sales ta& that the b!siness
reports, if any, This type of information can be !sed to identify b!sinesses where there is a difference between
the ta& owed and the ta& act!ally collected# this common iss!e is referred to as a ta: gap, )owever, integrating
information from m!ltiple state agencies is often constrained by political and sec!rity concerns, +n most cases,
it is easier for an agency to obtain end<!ser access to another agencyJs data as opposed to obtaining direct
database access, +n these sit!ations, yo! can !se Presentation Integration to gain end<!ser access to a remote
data so!rce in the conte&t of an a!tomated integration sol!tion,
Resulting Conte.t
Presentation Integration is almost always an option and has certain advantages, b!t also s!ffers from a n!mber
of limitations:
#ene&its
245450494.doc 159 od 257
%ow4ris-, +n Presentation Integration, a so!rce application is the application that the other
applications e&tract data from, +t is !nlikely that the other applications that access the so!rce application
can corr!pt it beca!se the other applications access the data the same way that a !ser accesses the data,
This means that all b!siness logic and validations incorporated into the application logic protect the internal
integrity of the so!rce applicationJs data store, This is partic!larly important with older applications that are
poorly doc!mented or !nderstood,
,on4intrusi7e, 1eca!se other applications appear to be a reg!lar !ser to the so!rce application, no
changes to the so!rce application are re?!ired, The only change that might be re?!ired is a new !ser
acco!nt,
Wor-s with monolithic applications, Many applications do not cleanly separate the b!siness and
presentation logic, Presentation Integration works well in these sit!ations beca!se it e&ec!tes the complete
application logic regardless of where the logic is located,
%iabilities
#rittleness, $ser interfaces tend to change more fre?!ently than p!blished programming interfaces
or database schemas, dditionally, Presentation Integration may depend on the specific position of fields
on the screen so that even minor changes s!ch as moving a field can ca!se the integration sol!tion to
break, This effect is e&acerbated by the relative wordiness of )TML,
%imited access to data, Presentation Integration only provides data that is displayed in the !ser
interface, +n many cases, other applications are interested in internal codes and data elements s!ch as
primary keys that are not displayed in the !ser interface, Presentation Integration cannot provide access to
these elements !nless the so!rce application is modified,
"nstructured in&ormation, +n most cases, the presentation layer displays all data val!es as a
collection of string elements, M!ch of the internal metadata is lost in this conversion, The internal
metadata that is lost incl!des data types, constraints, and the relationship between data fields and logical
entities, To make the available data meaningf!l to other applications, a semantic enrichment layer has to
be added, This layer is typically dependent on the specifics of the so!rce application and may add to the
brittleness of the sol!tion,
Ine&&icient, Presentation Integration typically goes thro!gh a n!mber of !nnecessary steps, 8or
e&ample, the so!rce applicationJs presentation logic has to render a vis!al representation of the data even
tho!gh it is never displayed, The terminal em!lation software in t!rn has to parse the vis!al representation
to t!rn it back into a data stream,
Slow, +n many cases, the information that yo! want to obtain is contained in m!ltiple !ser screens
beca!se of limited screen space, 8or e&ample, information may be displayed on s!mmary and detail
screens beca!se of limited screen space, This re?!ires the em!lator to go to m!ltiple screens to obtain a
coherent set of information, "oing to m!ltiple screens to obtain information re?!ires m!ltiple re?!ests to
the so!rce application and slows down the data access,
Comple., -&tracting information from a screen is relatively simple compared to locating the correct
screen or screens, 1eca!se the integration sol!tion sim!lates a live !ser, the sol!tion has to a!thenticate
to the system, change passwords reg!larly according to the system policy, !se c!rsor keys and f!nction
keys to move between screens, and so on, This type of inp!t typically has to be hard<coded or man!ally
config!red so that e&ternal systems can access the presentation integration as a meaningf!l b!siness
f!nction, s!ch as @"et /!stomer ddress,@ This translation between b!siness f!nction and keystrokes can
add a significant amo!nt of overhead, The same iss!es of comple&ity also affect error handling and the
control of atomic b!siness transactions,
Testing Considerations
=ne advantage of !sing Presentation Integration is that most !ser interfaces e&ec!te a well<defined and
generally well<!nderstood b!siness f!nction, This can be an enormo!s advantage when dealing with monolithic
systems that might be poorly doc!mented or !nderstood,
$nfort!nately, this advantage is often offset by the fact that testing !s!ally depends on the ability to isolate
individ!al components so that they can be tested individ!ally with a minim!m of e&ternal dependencies, S!ch a
testing approach is generally not possible when !sing Presentation Integration,
Security Considerations
245450494.doc 160 od 257
Presentation Integration !ses the same sec!rity model as an end !ser who logs into the application, This can be
an asset or a liability depending on the needs of the applications that are participating in the integration
sol!tion, n end<!ser sec!rity model typically enforces a fine<grained sec!rity scheme that incl!des the specific
data records or fields that a !ser is permitted to see, This makes e&posing the f!nctions thro!gh presentation
integration relatively sec!re,
The disadvantage of the fine<grained sec!rity scheme is that it can be diffic!lt to create a generic service that
can retrieve information from a variety of data so!rces, +n those cases, a special !ser acco!nt has to be created
that has access rights to all the data reso!rces that are needed by the e&ternal applications,
Ac-nowledgments
L%!h46N %!h, *illiam, Enterprise $pplication Integration. $ 2iley Tec" )rief, *iley, 3446,
Integration Topologies

Integration Patterns
2!ne 3445
Summary This chapter b!ilds on previo!s chapters by describing overall integration topologies, This chapter
presents a series of related patterns that help yo! analy9e the alternative methods and the tradeoffs to
consider when yo! choose between integration topology alternatives,
Contents
Point<to<Point /onnection
1roker
Message 1!s
P!blish>S!bscribe
More Detailed Look at Topologies
$sing Topologies Together
+ntegration Topology Level Patterns
@lways design a thing by considering it in its ne&t larger conte&tIa chair in a room, a room in a ho!se, a
ho!se in an environment, an environment in a city plan,@I-liel Saarinen, a 8innish<merican architect and city
planner
245450494.doc 161 od 257
-arlier chapters covered integration layers and the vario!s approaches !sed to connect layered applications,
Making these connections and creating integration layers are important parts of yo!r integration design, -?!ally
important, however, is the larger conte&t that these connections and layers form as yo! Eoin them together, The
design of this integration conte&t sho!ld specify the locations, str!ct!re, and channels that yo! !se to connect
these elements together to form a coherent whole, This conte&t is called an integration topology,
s yo! consider integration designs, yo! will notice key differences between designing for conventional
applications and designing for integration, D!ring application design, yo! are !s!ally in control of synchrono!s
re?!est and reply interactions, message flow, and the m!ltiplicities of messages, Ho! have a fairly
straightforward programming model that yo! can !se to coordinate elements, e&ceptions, and retries, This is
not always tr!e when yo! design for integration,
s yo! design for integration, yo!r application becomes a comp!tational reso!rce that provides and cons!mes
services as part of a larger integration architect!re, nd while yo!r system may be simply connected point<to<
point with another service, yo!r system may also be a provider or p!blisher of b!siness events to other
systems, +f yo!r system is a provider or p!blisher, yo!r event message might be sent to a message broker or to
a message b!s, These components may then send copies of the message to many other s!bscribed applications
or systems, =ther systems may be connected or removed from these message brokers or message b!ses
witho!t any modifications to yo!r system, +n fact, yo!r system may not have any direct knowledge of these
other systems at all,
To !nderstand how to design systems as service providers and cons!mers, it is important to have a working
knowledge of integration topologies, These topologies cover the flow of messages tho!gh an integration
architect!re, and they introd!ce elements s!ch as message brokers and message b!ses, ltho!gh topics like
physical topologies may seem !nimportant at this level of abstraction, it t!rns o!t that some integration
elements, s!ch as message b!ses, are tightly co!pled to lower<level topologies, Therefore, it is important to
!nderstand how these lower levels work in order to f!lly !nderstand the higher<level topologies,
This chapter starts, as many integration architect!res do, by considering a basic PointtoPoint (onnection
pattern, +t then progresses to a more comple& integration patternGthe 1roker 'and its variants(, $nlike the
co!pled endpoints in a PointtoPoint (onnection, the )ro'er deco!ples the so!rce from the target by inserting
intermediaries, fter the )ro'er, the ne&t pattern is the Message 1!s, The Message )us pattern f!rther
deco!ples endpoints by !sing agreed<!pon message schemas, command messages, and shared infrastr!ct!re,
8inally, the chapter e&amines another pattern !sed by all three of the previo!s patterns to notify interested
s!bscribersGP!blish>S!bscribe, fter describing these fo!r patterns, the chapter takes a more detailed look at
logical and physical topologies to help yo! better !nderstand the collaborations within the PointtoPoint
(onnection, the )ro'er, and the Message )us patterns.
Point4to4Point Connection
245450494.doc 162 od 257
Many integration proEects start with the need to connect two systems, and the easiest way to do so is to !se
the PointtoPoint (onnection pattern, point<to<point connection ens!res that only one receiver receives a
partic!lar message, 8or this to work, the sending system m!st know the location of the receiving node, The
sending system often m!st translate the message into a format that the receiving system !nderstands,
*hen yo! !se point<to<point connections, each system determines the address of all the other nodes that it
needs to comm!nicate with, *hen target addresses or protocol details change, all the systems that
comm!nicate with the target server m!st be !pdated, s the si9e of yo!r integration network grows and as the
fre?!ency of change increases, the operational cost associated with this approach becomes significant,
Most integration scenarios re?!ire yo! to transform the data between the so!rce system and the target
systems, dditionally, in many scenarios, developers want to take advantage of some conditional logic when
they config!re message ro!ting, +f yo! !se point<to<point connections, this logic is often d!plicated on each
server that re?!ires transformation and ro!ting, D!plicate code is e&pensive to write, and it is diffic!lt to
maintain, to e&tend, to test, and to manage,
The strength of the PointtoPoint (onnection pattern is how simple it is to implement, The weakness of the
PointtoPoint (onnection pattern is the d!plication of transformation and ro!ting code between systems, and
the high config!ration cost of endpoint address changes, To minimi9e these weaknesses, yo! can add another
layer of indirection between endpoints that contains a broker,
#ro-er
The )ro'er pattern and its variants are often !sed in both application design and integration design, The
fo!ndation work for this pattern is contained in Pattern-riented Software $rc"itecture0 <olume ;1 $ System of
Patterns L1!schmannMPN, The original pattern presented in this work is rather large in scope and contains fo!r
themes of partic!lar interest for integration:
/reating client<side pro&ies, server<side pro&ies, and the related infrastr!ct!re to encaps!late the
comple&ities of distrib!ted comm!nication
Providing a means for systems to register services with a broker so they can be cons!med by other
systems
Providing a means for systems to locate necessary services
Describing how brokers and endpoints can collaborate !sing both direct and indirect comm!nication
+n the first work in this pattern series, Enterprise Solution Patterns using Microsoft .NET LTrowbridge4;N, )ro'er
is disc!ssed in the conte&t of client pro&ies and server pro&ies !sing &istri%uted -%8ect Integration, )owever,
that disc!ssion did not emphasi9e direct and indirect comm!nication or naming services, This chapter breaks
the primary )ro'er pattern down to a hierarchy of speciali9ed patterns where each speciali9ed pattern has
partic!lar responsibilities that refine the responsibilities of the primary )ro'er pattern,
The intent of a broker is to deco!ple so!rce systems from target systems, +n the conte&t of &istri%uted -%8ect
Integration, the so!rce system may send a marshaled set of parameters when the so!rce system re?!ests a
245450494.doc 163 od 257
method invocation from the target system, +n the conte&t of Service<=riented +ntegration, the so!rce system
may send a message that re?!ests a service from a target system, *hile the conte&ts vary significantly, both
!se a )ro'er pattern to deco!ple the so!rce systems and the target systems,
broker deco!ples so!rce systems and target systems by ass!ming responsibility for coordinating
comm!nication between endpoints, There are three responsibilities that are involved in comm!nication, These
three responsibilities incl!de the following:
Routing, %o!ting involves determining the location of a target system, and it is performed by !sing
direct and indirect comm!nication,
5ndpoint registration, -ndpoint registration is the mechanism that a system can !se to register itself
with the )ro'er so that other systems can discover that system,
Trans&ormation, Transformation is the process where an element is converted from one format to
another,
+n this case, the so!rce element is the message that is sent by the so!rce system, and the target element is
the message that is received by the target system, 8ig!re 6 shows the )ro'er pattern and the three related
patterns that refine the basic )ro'er pattern1 &irect )ro'er, Indirect )ro'er, and Message )ro'er L)ohpe45N.
/igure 11 #ro-er and related patterns
245450494.doc 164 od 257
direct broker establishes initial comm!nication between endpoints, fter the initial comm!nication, the two
endpoints comm!nicate directly by !sing client<side and server<side Pro:ies L"ammaMAN, 8ig!re 3 ill!strates a
&irect )ro'er implementation,
/igure !1 Se0uence diagram &or a Direct #ro-er implementation
+n contrast, an indirect broker is a middleman, and all the comm!nication between endpoints passes thro!gh it,
$sing an indirect broker allows a sender to be !naware of target details and provides central control of the
message flow, +n this way, Indirect )ro'er is similar to Mediator L"ammaMAN, Mediator @keeps obEects from
referring to each other e&plicitly, and it lets yo! vary their interaction independently@ L"ammaMAN, 8ig!re ;
shows how an indirect broker acts as a mediator between so!rce systems and target systems,
/igure $1 Se0uence diagram &or an Indirect #ro-er implementation
*hile the Indirect )ro'er pattern is !sef!l when yo! need to control comm!nications, &irect )ro'er offers
better performance, especially when an additional intermediary is not needed for all comm!nications,
245450494.doc 165 od 257
The Message )ro'er pattern is a speciali9ed version of the )ro'er pattern L1!schmannMP, Trowbridge4;N,
message broker comm!nicates e&cl!sively by !sing messages and indirect comm!nication, The Message )ro'er
is an important and fre?!ently !sed integration pattern, +t is often referred to as a "u%andspo'e architect!re,
LetJs e&amine several )ro'er implementations to see how this pattern and its variations work in practice,
#ro-er 5.amples
To ill!strate how the )ro'er pattern is !sed, letJs look at the following five e&amples of the )ro'er pattern in
action:
Microsoft Distrib!ted /ommon =bEect Model 'D/=M(
Microsoft ,.-T 8ramework %emoting
/ommon =bEect %e?!est 1roker rchitect!re '/=%1(
$niversal Description Discovery and +ntegration '$DD+(
Microsoft 1i9Talk Server 3445
DC=2
MicrosoftJs Distrib!ted /ommon =bEect Model 'D/=M( is an e&ample of &istri%uted -%8ect Integration that !ses
a direct broker, *hen a calling application on a so!rce server wants to create and !se an obEect on a target
server, D/=M coordinates comm!nications between these endpoints, To coordinate this comm!nication, D/=M
first locates the target server by !sing config!ration information that is stored in the registry, D/=M then
creates a client pro&y on the so!rce system and a server pro&y 'st!b( on the target system, S!bse?!ent
comm!nication occ!rs directly between the client pro&y and the server pro&y 'st!b( !sing point<to<point
connections as shown in fig!re 5,
245450494.doc 166 od 257
/igure '1 Se0uence diagram showing DC=2 acting as a direct bro-er
1,5T /ramewor- Remoting
,.-T 8ramework remoting is another e&ample of &istri%uted -%8ect Integration that !ses &irect )ro'er. The
collaboration is the same as the collaboration that is shown in 8ig!re 5, )owever, !nlike D/=M, ,.-T
8ramework remoting does not retrieve the server location from the registry, +nstead, the $%L for the server is
passed as a parameter to the Acti7ator1Get=b+ect?@method call, This call then sets !p comm!nication
between pro&ies, fter the channels are registered and the pro&ies have been set !p, s!bse?!ent
comm!nication occ!rs directly between pro&ies by !sing a point<to<point connection, This implementation !ses
the server and client pro&iesJ portion of the )ro'er pattern, b!t does not directly !se a naming service to
register and to locate endpoints,
The programming model for both the client and the server is very straightforward, 8or more information, see
+mplementing 1roker with ,.-T %emoting $sing Server<ctivated =bEects LTrowbridge4;N and +mplementing
1roker with ,.-T %emoting $sing /lient<ctivated =bEects LTrowbridge4;N,
245450494.doc 167 od 257
C=R#A
The /ommon =bEect %e?!est 1roker rchitect!re '/=%1( is a specification that has m!ltiple implementations,
*hile these implementations vary in practice, this section foc!ses on an implementation that !ses &istri%uted
-%8ect Integration with a direct broker,
$pon start!p, an obEect re?!est broker '=%1( acting as a client sends a $ser Datagram Packet '$DP( broadcast
on its local s!bnet to find a naming service, The =%1 then stores the location of the first naming service that
responds to this re?!est, 1eca!se this is a broadcast, the comm!nication !ses a b!s<based logical topology,
'See the topology section later in this section for more information abo!t topologies,(
$sing this naming service, the =%1 re?!ests the location of the target server on behalf of the client, ss!ming
the server has previo!sly registered with the naming service, the naming service then ret!rns the server
location to the =%1, fter the =%1 obtains the server location, it sets !p a client pro&y and a server pro&y
'skeleton(, ll s!bse?!ent comm!nication occ!rs directly between the client pro&y and the server pro&y by
!sing a point<to<point connection.
"DDI
The $niversal Description Discovery and +ntegration '$DD+( specification defines a S=P<based *eb service for
finding and registering *eb services, $DD+ is also a p!blicly accessible set of implementations of the
specification, These implementations enable b!sinesses to register and to discover *eb services, $DD+
implementations can be either private or p!blic,
t r!n time, a $DD+ server can act as a &irect )ro'er between two *eb services, The interaction starts with the
cons!ming service, The cons!ming service then contacts the $DD+ server, The $DD+ server locates the target
service and ret!rns it to the cons!ming service, fter receiving the targetJs location in the $DD+ binding
template and after receiving the targetJs config!ration, the cons!ming service comm!nicates directly with the
providing service,
8or more information abo!t how to !se $DD+ at r!n time, see @$sing $DD+ at %!n Time, Part +@ and @$sing
$DD+ at %!n Time, Part ++@ by 0arsten 2an!s9ewski L2an!s9ewski46, 2an!s9ewski43N,
#i>Tal- Ser7er !<<'
1i9Talk Server 3445 is a versatile platform infrastr!ct!re component that yo! can config!re in many different
ways, Most importantly, yo! can !se 1i9Talk Server 3445 as the component that implements Message )ro'er.
$nlike the previo!s e&amples that !sed direct brokers, Message )ro'er is a refinement of the Indirect )ro'er
pattern, Systems that !se Indirect )ro'er do not comm!nicate directly with each other, +nstead, they
comm!nicate thro!gh a middlemanIthe indirect broker, The so!rce system comm!nicates the logical name of
the target to the indirect broker, The indirect broker then looks !p the target system that is registered !nder
the logical name and passes the comm!nication to the target system, message broker is a speciali9ed type of
indirect broker that comm!nicates by !sing messages, 8or a detailed e&ample, see +mplementing Message
1roker with 1i9Talk Server 3445,
245450494.doc 168 od 257
The preceding five e&amples demonstrate that the )ro'er pattern and its variants are fre?!ently !sed for
systems integration, /ompared to PointtoPoint (onnection, it effectively deco!ples so!rce systems and target
systems by adding another level of indirection, There are sit!ations, however, that call for even greater
deco!pling, +n these sit!ations, yo! often want a data format and a message str!ct!re that are common across
m!ltiple systems, Ho! also want a shared infrastr!ct!re that can comm!nicate these common messages to any
interested system, t this point, it is time to consider Message )us,
2essage #us
The notion of a b!s originated in the field of electrical engineering where a common b!s is !sed to carry c!rrent
of a specific voltage and fre?!ency, This notion is e&tended with the b!ses that are fo!nd in comp!ter hardware
systems so that it incl!des not only common voltages, b!t also agreed<!pon messages s!ch as a data b!s and
an address b!s, message b!s e&tends this concept to provide a common comm!nication mechanism between
disparate systems, To provide this common mechanism, the systems m!st have three elements:
set of agreed<!pon message schemas
set of common command messages L)ohpe45N
shared infrastr!ct!re for sending b!s messages to recipients
This shared infrastr!ct!re can be achieved either by !sing a Message /outer L)ohpe45N or by !sing a
Pu%lis"*Su%scri%e mechanism, +n this book, the foc!s is on message b!ses that !se Pu%lis"*Su%scri%e
mechanisms, 8or details on how to design a message b!s that !ses message<oriented middleware and a
message ro!ter, see Enterprise Integration Patterns1 &esigning0 )uilding0 and &eploying Messaging Solutions
L)ohpe45N,
8ig!re A shows a Message )us associated with a Pu%lis"*Su%scri%e implementation,
/igure (1 2essage #us associated with a PublishBSubscribe pattern implementation
245450494.doc 169 od 257
The Pu%lis"*Su%scri%e pattern describes a collaboration where one system s!bscribes to change messages or to
event messages that are prod!ced by another system, +n the Message )us conte&t, a system can s!bscribe to
b!s messages, fter the system s!bscribes, the system is then sent all the messages that are addressed to this
common b!s, ltho!gh message b!ses often !se Pu%lis"*Su%scri%e implementations, these implementations
are !sed by other topologies as well, 8or e&ample, PointtoPoint (onnection and Message )ro'er can also !se
Pu%lis"*Su%scri%e collaborations,
The advantage of a message b!s is that once it is established, the cost of adding new applications is minimal,
new application can s!bscribe to b!s messages witho!t affecting other s!bscribers, 1eca!se all systems,
incl!ding the new system, !nderstand common message schemas and command messages, there is no need
for additional translation, )owever, as yo! add a new system to the b!s, it may be !sef!l to !se an $dapter
L"ammaMAN to encaps!late any translation needed to initially connect with the message b!s,
The disadvantage of a message broker is the significant amo!nt of work that is involved in creating common
message schemas, command messages, and shared infrastr!ct!re within an enterprise, 1eca!se these systems
typically cross organi9ational bo!ndaries and systems, gaining agreement on these key areas may be e&tremely
diffic!lt, time cons!ming, or impossible,
Message )us implementations vary significantly depending on the kind of Pu%lis"*Su%scri%e mechanism they
employ, 1eca!se a Pu%lis"*Su%scri%e mechanism is s!ch an integral part of a Message )us implementation, the
ne&t section looks at this pattern more closely,
PublishBSubscribe
t a high level, the Pu%lis"*Su%scri%e L1!schmannMPN pattern helps keep cooperating systems synchroni9ed by
one<way propagation of messages beca!se one p!blisher sends a message to any n!mber of intended
s!bscribers, )owever, there are significant differences in the ne&t level of design within the pattern, These
differences lead to three refinements of the Pu%lis"*Su%scri%e pattern: #ist)ased Pu%lis"*Su%scri%e,
)roadcast)ased Pu%lis"*Su%scri%e, and (ontent)ased Pu%lis"*Su%scri%e,
%ist4#ased PublishBSubscribe
#ist)ased Pu%lis"*Su%scri%e pattern advises yo! to identify a s!bEect and to maintain a list of s!bscribers for
that s!bEect, *hen events occ!r, yo! have the s!bEect notify each s!bscriber on the s!bscription list, classic
way to implement this design is described in the =bserver L"ammaMAN pattern, *hen yo! !se this pattern, yo!
identify two classes: s!bEects and observers, ss!ming yo! !se a p!sh model !pdate, yo! add three methods
to the s!bEect: Attach?@,Detach?@, and ,oti&y?@, Ho! add one method to the observerI"pdate?@,
To !se an observer, all interested observers register with the s!bEect by !sing the Attach?@method, s changes
occ!r to the s!bEect, the s!bEect then calls each registered observer by !sing the ,oti&y?@method, 8or a
detailed e&planation of the -%ser!er pattern, see &esign Patterns1 Elements of /eusa%le -%8ect-riented
Software L"ammaMAN,
245450494.doc 170 od 257
n observer works fine if yo! have created instances of obEects that reify all yo!r observers and s!bEects, n
observer is especially well s!ited to sit!ations where yo! have one<to<many relationships between yo!r s!bEects
and yo!r observers, )owever, in the conte&t of integration, yo! often have many observers that are linked to
many s!bEects, which complicates the basic -%ser!er pattern, =ne way to implement this many<to<many
relationship is to create many s!bEects and to have each s!bEect contain a list of observers,
+f yo! !se this obEect str!ct!re to implement Pu%lis"*Su%scri%e, yo! m!st write these relationships to persistent
storage between process e&ec!tions, To do so within a relational database, yo! m!st add an associative table to
resolve the many<to<many dependencies between s!bEect and observer, fter yo! write this information to
persistent storage in a set of tables, yo! can directly ?!ery the database for the list of s!bscribers for a topic,
Maintaining lists of p!blished topics 's!bEects( and s!bscribers 'observers( and then notifying each one
individ!ally as events occ!r is the essence of #ist)ased Pu%lis"*Su%scri%e implementations, very different
means of achieving the same res!lt is a )roadcast)ased Pu%lis"*Su%scri%e implementation,
#roadcast4#ased PublishBSubscribe
*hen yo! !se a )roadcast)ased Pu%lis"*Su%scri%e approach LTanneba!m46, =kiM;N, an event p!blisher
creates a message and broadcasts it to the local area network 'L.(, service on each listening node inspects
the s!bEect line, +f the listening node matches the s!bEect line to a s!bEect that it s!bscribes to, the listening
node processes the message, +f the s!bEect does not match, the listening node ignores the message,
S!bEect lines are hierarchical and may contain m!ltiple fields that are separated by periods, Listening nodes
that are interested in a partic!lar s!bEect can s!bscribe to these fields by !sing wildcards, if re?!ired,
ltho!gh this )roadcast)ased Pu%lis"*Su%scri%e implementation is an effective method for deco!pling
prod!cers from cons!mers, it is sometimes !sef!l to identify partic!lar topic s!bscribers, To identify topic
s!bscribers, a coordinating process sends a message that asks listening nodes to reply if they s!bscribe to a
partic!lar topic, %esponses are then ret!rned by each listening node to the provider to identify the s!bscribers,
1eca!se all messages are sent to all listening nodes, and beca!se each node is responsible for filtering
!nwanted messages, some a!thors refer to this as a p!blish>s!bscribe channel with reactive filtering
L)ohpe45N,
Content4#ased PublishBSubscribe
1oth )roadcast)ased Pu%lis"*Su%scri%e implementations and #ist)ased Pu%lis"*Su%scri%e implementations
can be broadly categori9ed as topic<based beca!se they both !se predefined s!bEects as many<to<many
channels, Pu%lis"*Su%scri%e implementations have recently evolved to incl!de a new formI(ontent)ased
Pu%lis"*Su%scri%e, The difference between topic<based and content<based approaches is as follows:
+n a topic<based system, processes e&change information thro!gh a set of predefined s!bEects 'topics( which
represent many<to<many distinct 'and fi&ed( logical channels, /ontent<based systems are more fle&ible as
s!bscriptions are related to specific information content and, therefore, each combination of information items
245450494.doc 171 od 257
can act!ally be seen as a single dynamic logical channel, This e&ponential enlargement of potential logical
channels has changed the way to implement a p!b>s!b system, L1aldoniN
The practical implication of this approach is that messages are intelligently ro!ted to their final destination
based on the content of the message, This approach overcomes the limitation of a broadcast<based system,
where distrib!tion is co!pled to a m!lticast tree that is based on Transmission /ontrol Protocol 'T/P(, +t also
gives the integration architect a great deal of fle&ibility when deciding on content<based ro!ting logic,
A 2ore Detailed %oo- at Topologies
To f!lly !nderstand how collaborations that are based on PointtoPoint (onnection, )ro'er, and Message )us
work together with other parts of yo!r technical architect!re, it is !sef!l to view yo!r systemJs topologies from
three discrete topology levels: physical, logical, and integration,
,ote This section disc!sses low<level layers of the =pen Systems +nterconnection '=S+( stack, +t then moves
on to disc!ss the top layer 'pplication(, bypassing many important layers, This is intentional beca!se this
section only disc!sses the relationship between these low<level layers and the integration topology pattern
choices, +t does not mean that these layers are not important, )owever, they are not architect!rally significant
for this partic!lar disc!ssion,
Topology %e7els
1eca!se the terms point<to<point, b!s, and h!b were first defined at the physical level, this section starts with a
review of the physical network topology level, +n addition to a physical connection, yo! also need a logical
comm!nication protocol, That logical comm!nication protocol also implies a topology, fter logical and physical
topology levels are established, it is possible to establish patterns of comm!nication between the collaborating
nodes, These patterns of comm!nication and collaboration form an integration topology level that is described
by the PointtoPoint (onnection, the )ro'er, and the Message )us patterns,
+n some cases, the topology !sed at the integration topology level and the topology !sed at the physical
topology level may be the same topology, +n other cases, a system may !se different topologies at the
integration topology level, the logical topology level, and the physical topology level, +t therefore is !sef!l to
separate topologies from topology levels to avoid potential conf!sion, This section disc!sses the physical,
logical, and integration topology levels in more detail,
,ote The term topology is !sed within the ind!stry to refer to both the arrangement of nodes within a
network 'for e&ample, b!s or h!b( and to the physical and logical network levels of elements, )owever, the
remainder of this chapter !ses the following convention, Topology describes the arrangement of elements 'for
e&ample, b!s or h!b(, Topology le!el is !sed to indicate the levels of elements, s!ch as the physical vers!s the
logical levels, This convention permits clarity if, for e&ample, the chapter refers to a system that !ses a b!s<
based topology at the physical topology level,
Physical Topology %e7el
The first level to consider is the physical topology, The physical topology level describes the way that each
system node physically connects to the network, The topology choices are point<to<point, b!s, h!b, and ring,
These fo!r topologies are ill!strated in 8ig!re P,
245450494.doc 172 od 257
/igure )1 /our physical topologies
Ho! can determine the topology that is !sed at the physical topology level of any set of hardware nodes by
observing the arrangement of the network cables and the devices that connect the nodes, Logical network
protocols !se this topology to facilitate comm!nication between the nodes, 1eca!se these protocols ass!me a
partic!lar se?!ence of comm!nication and a logical str!ct!re between nodes, these collaborations form
topologies at the physical topology level,
%ogical Topology %e7el
logical topology level describes the means, the se?!ence, and the protocol that physical nodes !se to
comm!nicate, The most pop!lar network protocol today is the -thernet standard '+--- 743,;(, -thernet !ses a
b!s<based topology at the logical topology level, -thernet is b!s based beca!se the original protocol was
designed so that all packets on a network or on a s!bnetwork were sent to all nodes on the same network
segment, This config!ration re?!ires each listening node to filter !nwanted packets, The protocol provides for
collisions that may occ!r if more than one node transmits sim!ltaneo!sly, Since the original protocol was
developed, advances in network hardware have enabled devices to ro!te messages to selected nodes to
improve performance, =ne s!ch advance is the development of switches, The -thernet protocol also has
evolved to take advantage of these developments, b!t it still s!pports a b!s<based logical topology,
less<!sed network protocol is token passing '+--- 743,A(, Token passing !ses a ring<based topology at the
logical topology level, *ith this topology, each node connects to the ne&t node in the ring and passes a
message in a circ!lar fashion !ntil it arrives at the intended destination,
s shown in 8ig!re O, the topology of the logical topology level and the topology of the physical topology level
correspond e&actly in some cases,
245450494.doc 173 od 257
/igure *1 Direct mapping o& topologies at the logical and physical topology le7els
8or e&ample, a set of nodes that are connected with a b!s<based topology at the physical topology level might
also be connected with a b!s<based topology at the logical topology level, This topology is the topology that
often e&ists when yo! !se the -thernet protocol, =r, a set of nodes that are connected with a ring<based
topology at the physical topology level might also be connected with a ring<based topology at the logical
topology level, This is the topology that e&ists when yo! !se token passing, )owever, it is important to
!nderstand that the topologies !sed at the physical and logical topology levels do not have to be the same, +n
practice, they are often different,
8or e&ample, m!ltiple nodes might be connected in a h!b<based topology '6441ase<T( at the physical topology
level, and a b!s<based topology '-thernet( might be !sed at the logical topology level, +n this case, an
incoming packet is broadcast to all the nodes that are physically connected to the h!b, and the h!b effectively
acts as a b!s, -ach listening node is then responsible for filtering the !nwanted messages, 8ig!re 7 shows a
b!s<based topology at the logical topology level, The b!s<based topology is mapped to both a b!s<based
topology and to a h!b<based topology at the physical topology level,
/igure 91 A bus4based topology at the logical topology le7el mapped to both a bus4based topology
and a hub4based topology at the physical topology le7el
nother e&ample of different topologies at the logical and physical topology levels is a ring<based topology at
the logical topology level that r!ns on top of a b!s topology at the physical topology level, This config!ration is
described in +--- 743,5, +n this config!ration, messages are passed in the logical topology level thro!gh a ring
of nodes, b!t the nodes are connected by !sing a b!s<based or a h!b<based topology at the physical topology
level,
s yo! analy9e a set of connected systems in detail, it is !sef!l to clarify the topology level yo! are referring to,
This helps to separate the logical iss!es from the physical iss!es, bove the logical level, the integration
topology level describes the arrangement of integrated systems,
245450494.doc 174 od 257
Integration Topology %e7el
The integration topology level describes the arrangement of channels, collaborations, and mechanisms that
different systems and services !se to comm!nicate, This topology level consists of different combinations of
three patterns: PointtoPoint (onnection, )ro'er, and Message )us, These patterns, along with the related
Pu%lis"*Su%scri%e pattern, are ill!strated in 8ig!re M by !sing circles,
/igure ;1 Integration patterns related to topologies
.ow letJs look at how integration topologies interact with logical and physical topologies in more detail,
"sing Topologies Together
To design an integration architect!re, yo! m!st decide on high<level collaborations in the integration topology
level, These collaborations !se other combinations of collaborations and topologies in the logical topology level,
+n t!rn, these collaborations !se, and in some sit!ations are constrained by, the topologies !sed in the physical
topology level, .ote that each level has its own set of concerns and responsibilities, LetJs now look at these
collaborations in more detail,
Point4to4Point Connection
8ig!re 64 shows how to implement the PointtoPoint (onnection pattern, "iven the pop!larity of -thernet,
point<to<point connections are often connected by a b!s in the logical topology level, $sing common network
devices like ro!ters, h!bs, and switches, the physical topology level is !s!ally either h!b based or b!s based,
245450494.doc 175 od 257
%egardless of the topologies !sed at the physical and logical topology levels, from an integration pattern
perspective, the nodes are !sing a PointtoPoint (onnection pattern if both of the following are tr!e:
-&actly one message is sent to and received by one target node,
The responsibility for determining the target location and protocol lies with the sender,
/igure 1<1 Topologies stac- &or a Point4to4Point Connection integration pattern
1reaking these topologies into discrete levels lets yo! ?!alify topology disc!ssions by !sing a frame of
reference, 8or e&ample, !sing the config!ration that is shown in 8ig!re 64, yo! might have a PointtoPoint
(onnection topology at the integration topology level that is connected to a b!s topology at the logical topology
level and to a b!s or h!b topology at the physical topology level,
#ro-er
The collaboration described in the )ro'er pattern !ses a combination of many other topologies, 8or e&ample,
letJs review the /=%1 direct broker e&ample that is disc!ssed earlier in this chapter,
@$pon start!p, an obEect re?!est broker '=%1( acting as a client sends a $DP broadcast on its local s!bnet to
find a naming service,@
)ere, a broker !ses a b!s topology at the logical topology level to send a broadcast to all the systems that are
connected to its s!bnet, +n this case, the topology !sed at the physical topology level is irrelevant, b!t it is
likely to be h!b based or b!s based d!e to the !bi?!ity of -thernet, .ote that the naming service m!st be
located on the same s!bnet as the =%1 for this scheme to work,
@$sing this naming service, the =%1 re?!ests the location of the target server on behalf of the client,@
245450494.doc 176 od 257
This is a standard broker collaboration, The main re?!irement here is that the so!rce system be able to connect
point<to<point with the naming service, Therefore, the topologies !sed at the logical and physical topology
levels are less important, gain, d!e to the !bi?!ity of -thernet, the topology !sed at the logical topology level
is likely to be b!s based, b!t the topology !sed at the physical topology level is likely to be either h!b based or
b!s based,
@ll s!bse?!ent comm!nication occ!rs directly between the client pro&y and the server pro&y by !sing a point<
to<point connection. @
gain, the main re?!irement is that the so!rce system be able to connect point<to<point to the target, This also
is likely to be a b!s topology at the logical topology level and a h!b or b!s topology at the physical topology
level,
ltho!gh the )ro'er collaboration may have some amo!nt of co!pling to !nderlying topologies at both the
physical and logical topology levels, the amo!nt of co!pling is m!ch more prono!nced when yo! !se Message
)us in conE!nction with a Pu%lis"*Su%scri%e implementation,
2essage #us and PublishBSubscribe
Message )us implementations can vary greatly depending on the Pu%lis"*Su%scri%e mechanism that they
employ, .ow letJs e&amine the practical implications of !sing the three Pu%lis"*Su%scri%e variations together
with Message )us,
2essage #us with #roadcast4#ased PublishBSubscribe
To !se a Message )us implementation that contains a )roadcast)ased Pu%lis"*Su%scri%e implementation, a
system sends a command message to the message b!s, The message b!s broadcasts the message to all the
nodes that are listening to the b!s, The message b!s makes no attempt to determine the appropriate
s!bscribers, +nstead, each listening node filters any !nwanted messages and processes only the messages that
it is interested in, ny data associated with the messages is in a common format so that all systems can
interpret the command message and the data, and then respond appropriately,
8rom a topology perspective, this combination of the Message )us pattern and the Pu%lis"*Su%scri%e patterns
!ses a b!s<based topology at the logical topology level '-thernet( to make a b!s<based broadcast
comm!nication from the message b!s to all the listening nodes, The physical topology at this point is irrelevant,
b!t it is !s!ally either h!b based or b!s based,
2essage #us with %ist4#ased PublishBSubscribe
To !se a message b!s that contains a #ist)ased Pu%lis"*Su%scri%e implementation, a system sends a
command message to the message b!s, The message b!s then looks !p all interested b!s s!bscribers and
sends each one a copy of the original message, ny data associated with the message is in a common format
so that all systems can interpret the command message and the data, and then respond appropriately,
245450494.doc 177 od 257
8rom a topology perspective, this combination of the Message )us and Pu%lis">Su%scri%e patterns is likely to
!se 'b!t not to be co!pled to( a b!s topology at the logical topology level '-thernet( to make point<to<point
connections from the message b!s to the s!bscribing nodes, as shown in 8ig!re 66, t this point, the topology
!sed at the physical topology level is irrelevant, b!t it is !s!ally either h!b based or b!s based,
/igure 111 A message bus using a bus topology at the logical topology le7el and a bus or hub
topology at the physical topology le7el
2essage #us with Content4#ased PublishBSubscribe
To !se a Message )us pattern that contains a (ontent)ased Pu%lis"*Su%scri%e implementation, a system sends
a command message to the message b!s, fter the message b!s receives the message, it is responsible for
matching the message against a set of s!bscribers, The message b!s then forwards the message to each of the
appropriate s!bscribers,
To match the message against a set of s!bscribers, the message b!s m!st determine if there are any
s!bscribers interested in this partic!lar message, +f an interested s!bscriber e&ists, the s!bscriber matches a
partic!lar message field or fields and a set of val!es, +f a match e&ists between the message content and a
s!bscriber, the message is then forwarded to each matching s!bscriber,
fter a s!bscribing system receives a b!s message, the s!bscribing system is able to process the message
beca!se the message contains the common command message and the agreed<!pon message schemas,
ltho!gh the Message )us using #ist)ased Pu%lis"*Su%scri%e and the Message )us using (ontent)ased
Pu%lis"*Su%scri%e patterns both check for s!bscriptions before forwarding messages, there are key differences,
245450494.doc 178 od 257
The list<based approach matches s!bscriptions on s!bEects, The content<based approach allows yo! to identify
one or more fields in the message and to identify a set of acceptable val!es for each field, s a res!lt, yo! can
create very intelligent ro!ting capabilities, This makes the content<based approach more fle&ible than the list<
based approach,
To make (ontent)ased Pu%lis"*Su%scri%e work, yo! need a high performance infrastr!ct!re component that
can read each message, ?!ery a set of potential s!bscribers, and efficiently ro!te the message to each
s!bscriber, +n practice, yo! can think of this as a message switch, This is e&actly how Microsoft 1i9Talk Server
3445 is designed,
8ig!re 63 shows the Message )us pattern !sing a Pu%lis"*Su%scri%e pattern or one of the Pu%lis"*Su%scri%e
variants,
/igure 1!1 2essage #us using a PublishBSubscribe pattern
Integration Topology %e7el Patterns
245450494.doc 179 od 257
The following table s!mmari9es the integration patterns that are disc!ssed in this chapter,
Table 1 Integration ,etwor- Patterns
Pattern Problem Associated implementations
Message 1roker )ow do yo! integrate applications
witho!t enforcing a common
interface and also allow each
application to initiate interactions
with several other applicationsC
+mplementing Message 1roker with
1i9Talk 3445
Message 1!s s an integration sol!tion grows,
how can yo! lower the cost of
adding or removing applicationsC

P!blish>S!bscribe )ow can an application in an
integration architect!re only send
messages to the applications that
are interested in receiving the
messages witho!t knowing the
identities of the receiversC
2essage #ro-er

Integration Patterns
Contents
liases
/onte&t
Problem
8orces
Sol!tion
-&ample
%es!lting /onte&t
Testing /onsiderations
Sec!rity /onsiderations
=perational /onsiderations
245450494.doc 180 od 257
0nown $ses
:ariants
%elated Patterns
cknowledgments
Aliases
.u% and Spo'e
Conte.t
Ho! have an online store that integrates several systems, s!ch as the *eb<based front<end system, the credit
card verification system, the retail system, and the shipping system, The control flow !s!ally originates in the
front end, 8or e&ample, a c!stomer placing an order ca!ses the online store to send a re?!est message to the
credit card verification system, +f the credit card information is validated, the online store sends re?!est
messages to the vario!s retail systems, depending on the ordered items, n order for books translates into a
p!rchase order message for the book retailer# an order for electronics translates into a p!rchase order message
for the electronics retailer# and an order for gardening s!pplies translates into a p!rchase order message for
the home and garden s!pplier,
The control flow co!ld also originate in a retail or shipping system, 8or e&ample, when a retailer !pdates a
catalog, the retail system sends catalog !pdate messages to the store so that the store can display the new
items, *hen a shipper changes the shipping rates, the shipping system sends a rate !pdate message to the
store so that the store can comp!te the correct shipping charges, Similarly, when a shipper changes pick!p
times, the shipping system sends !pdate messages to all the retailers the system serves so that they can have
the shipments ready in time,
Problem
)ow do yo! integrate applications witho!t enforcing a common interface and also allow each application to
initiate interactions with several other applicationsC
/orces
To integrate applications witho!t changing their interfaces, yo! m!st balance the following forces:
Point<to<point integration re?!ires a large n!mber of connections between applications, Many
connections !s!ally translate into many interfaces,
Message 1!s integration facilitates adding new applications, b!t it re?!ires a common b!s interface,
1eca!se integration sol!tions !s!ally involve applications that have proprietary interfaces provided by
m!ltiple vendors, Message )us integration is diffic!lt,
%!n<time control of ?!alities s!ch as availability and performance may re?!ire dynamic
reconfig!ration,
245450494.doc 181 od 257
The applications in an integration sol!tion co!ld have conflicting ?!ality of service 'BoS( re?!irements,
The applications in an integration sol!tion co!ld belong to different sec!rity realms,
Solution
-&tend the integration sol!tion by !sing Message )ro'er, message broker is a physical component that
handles the comm!nication between applications, +nstead of comm!nicating with each other, applications
comm!nicate only with the message broker, n application sends a message to the message broker, providing
the logical name of the receivers, The message broker looks !p applications registered !nder the logical name
and then passes the message to them,
/omm!nication between applications involves only the sender, the message broker, and the designated
receivers, The message broker does not send the message to any other applications, 8rom a control<flow
perspective, the config!ration is symmetric beca!se the message broker does not restrict the applications that
can initiate calls, 8ig!re 6 ill!strates this config!ration,
/igure 11 A message bro-er mediating the collaboration between participating applications
The message broker can e&pose different interfaces to the collaborating applications, and it can translate
messages between these interfaces, +n other words, the message broker does not enforce a common interface
on the applications,
Prior to !sing a message broker, yo! m!st register the applications that receive comm!nications so that the
message broker can dispatch re?!ests to them, The message broker may provide its own registration
mechanism, or it may rely on an e&ternal service s!ch as a directory,
Placing the message broker between the sender and the receiver provides fle&ibility in several ways, 8irst, the
message broker allows the integration sol!tion to dynamically change its config!ration, 8or e&ample, if an
application m!st be sh!t down for maintenance, the message broker co!ld start ro!ting re?!ests to a failover
application, Likewise, if the receiver cannot keep !p with the incoming messages, the message broker co!ld
start load balancing between several receivers,
245450494.doc 182 od 257
Second, the message broker can choose between applications that have different BoS levels, This resembles
the dynamic config!ration, b!t the message broker selects the application based on specified criteria, 8or
e&ample, an application for premi!m acco!nts may f!lfill re?!ests ?!ickly, b!t an application for general !se
may have a longer processing time,
Third, the message broker allows the sender and the receiver to reside in different sec!rity realms, +n other
words, the message broker can reside on the bo!ndary between two sec!rity realms and bridge re?!ests
between those two realms, Table 6 shows the responsibilities and collaborations of a message broker,
Table 1 2essage #ro-er Responsibilities and Collaborations
Responsibilities Collaborations
G%eceive message GSenders: applications that send messages to the
message broker,
GDetermine the message recipients and perform the
ro!ting
G%eceivers: applications that receive messages from
the message broker
G)andle any interface<level differences
GSend the message to the recipients
5.ample
/onsider an online store that allows shoppers to browse a variety of retail catalogs and to place orders, *hen
an order is placed, the online store gro!ps the shopping cart items by retailer and places appropriate orders
with each retailer, s each retailer f!lfills and ships the order, it sends the online store a tracking n!mber, The
online store !pdates its records so that this information is presented on the /heck =rder Stat!s page, +f the
c!stomer has config!red e<mail alerts, the store also sends an e<mail message that contains the tracking
information,
The online store that is ill!strated in 8ig!re 3 !ses a message broker to comm!nicate with the individ!al
retailers, The broker knows how to reach each retailer and how to place orders, to cancel orders, and to check
the order stat!s, Likewise, the retailers comm!nicate with the broker when they send tracking n!mbers, -ach
retailer m!st know how to reach the broker and how to send the tracking n!mber, +n other words, both the
store side and the retailer side can initiate a comm!nication, and the data flows in both directions,
245450494.doc 183 od 257
/igure !1 =nline store communicating with retailers through a message bro-er
Resulting Conte.t
The decision to !se a message broker for integration entails balancing the benefits of removing inter<application
co!pling against the effort associated with !sing the message broker, $se the following benefits and liabilities to
eval!ate the balance:
#ene&its
Reduced coupling, The message broker deco!ples the senders and the receivers, Senders
comm!nicate only with the message broker, and the potential gro!ping of many receivers !nder a logical
name is transparent to them,
Impro7ed integrability, The applications that comm!nicate with the message broker do not need to
have the same interface, $nlike integration thro!gh a b!s, the message broker can handle interface<level
differences, +n addition, the message broker can also act as a bridge between applications that are from
different sec!rity realms and that have different BoS levels,
Impro7ed modi&iability, The message broker shields the components of the integration sol!tion from
changes in individ!al applications, +t also enables the integration sol!tion to change its config!ration
dynamically,
Impro7ed security1 /omm!nication between applications involves only the sender, the broker, and
the receivers, =ther applications do not receive the messages that these three e&change, $nlike b!s<based
integration, applications comm!nicate directly in a manner that protects the information witho!t the !se of
encryption,
Impro7ed testability, The message broker provides a single point for mocking, Mocking facilitates
the testing of individ!al applications as well as of the interaction between them,
%iabilities
Increased comple.ity, /omm!nicating thro!gh a message broker is more comple& than direct
comm!nication for the following reasons:
The message broker m!st comm!nicate with all the parties involved, This co!ld mean
providing many interfaces and s!pporting many protocols,
The message broker is likely to be m!ltithreaded, which makes it hard to trace problems,
Increased maintenance e&&ort, 1roker<based integration re?!ires that the integration sol!tion
register the applications with the broker, 1!s<based integration does not have this re?!irement,
Reduced a7ailability, single component that mediates comm!nication between applications is a
single point of fail!re, secondary message broker co!ld solve this problem, )owever, a secondary
245450494.doc 184 od 257
message broker adds the iss!es that are associated with synchroni9ing the states between the primary
message broker and the secondary message broker,
Reduced per&ormance, The message broker adds an intermediate hop and inc!rs overhead, This
overhead may eliminate a message broker as a feasible option for sol!tions where fast message e&change
is critical,
Testing Considerations
mock message broker can receive re?!ests and send back canned responses, +n effect, the mock message
broker allows system testers to verify individ!al applications witho!t removing the individ!al applications from
the integration sol!tion,
Likewise, a mock message broker that em!lates some of the message brokerJs f!nctionality allows testers to
verify and to profile the interplay between a few applications, for e&ample, a s!bset of the integration sol!tion,
+n other words, a mock message broker allows yo! to test individ!al applications and to test s!bsystems,
8ig!re ; shows these config!rations# the shading indicates the areas !nder test,
/igure $1 "sing a moc- message bro-er to test applications and subsystems
Security Considerations
+ntegration by !sing a message broker places a component between senders and receivers, =n one hand, this
config!ration accommodates management of the sec!rity conte&t thro!gh consolidation as well as
impersonation, =n the other hand, the message broker represents a central point of attack, /ompromising the
message broker compromises the comm!nication between all the applications that !se it,
=perational Considerations
The message broker can dynamically change the config!ration, +t can direct messages to a failover application
if necessary or perform load balancing between applications, or the message broker can do both,
6nown "ses
245450494.doc 185 od 257
1roker<based integration prod!cts s!ch as Microsoft 1i9Talk Server 3445 e&tend the traditional broker
f!nctionality with additional feat!res, 8or e&ample, 1i9Talk Server 3445 provides orchestration services,
messaging services, and other feat!res associated with these services s!ch as b!siness activity monitoring,
transaction and e&ception handling, correlation, and graphic editing,
8ariants
message broker variant trades ease of integration for performance, The performance<optimi9ed message
broker looks !p the receiver and then connects it to the sender, th!s allowing the sender and the receiver to
comm!nicate directly, The direct connection eliminates the performance penalty that is associated with an
intermediary between the comm!nicating parties, )owever, this performance optimi9ation only works if the
sender and the receiver have the same interface,
Related Patterns
8or more information, see the following related patterns:
)ro'er L1!schmannMPN, +n a distrib!ted setting, the )ro'er pattern tries to make distrib!tion
transparent, /lient<side and server<side pro&ies mediate between the broker and the clients and server,
Implementing Message )ro'er wit" )i6tal' Ser!er 3445, This pattern !ses the "lobal 1ank scenario to
show how yo! can !se 1i9Talk Server 3445 to implement Message 1roker,
(lient&ispatc"erSer!er L1!schmannMPN, The (lient&ispatc"erSer!er pattern is a )ro'er variant
that !ses the direct comm!nication optimi9ation mentioned earlier in @:ariants,@
(ontent)ased /outer L)ohpe45N, The (ontent)ased /outer pattern is a )ro'er variant that
speciali9es in ro!ting comm!nications to different applications based on the content of the comm!nication,
Mediator L"ammaMAN, The Mediator pattern separates obEects so that they are only aware of the
mediator b!t not each other, The )ro'er deals with similar concerns, b!t it can only be !sed in the conte&t
of enterprise applications,
Ac-nowledgments
L1!schmannMPN 1!schmann, 8rank# %egine Me!nier, )ans %ohnert, Peter Sommerlad, and Michael Stal,
Pattern-riented Software $rc"itecture0 <olume ;1 $ System of Patterns, 2ohn *iley & Sons Ltd, 6MMP,
L"ammaMAN "amma, -rich# %ichard )elm, %alph 2ohnson, and 2ohn :lissides, &esign Patterns1 Elements of
/eusa%le -%8ect-riented Software, ddison<*esley, 6MMA,
L)ohpe45N )ohpe, "regor, and 1obby *oolf, Enterprise Integration Patterns1 &esigning0 )uilding and &eploying
Messaging Solutions, ddison<*esley, 3445,
LTrowbridge4;N Trowbridge, David# Dave Mancini, Dave B!ick, "regor )ohpe, 2ames .ewkirk, and David
Lavigne, Enterprise Solution Patterns Using Microsoft .NET, Microsoft Press, 344;, lso available on the MS&N
$rc"itecture (enter at: http:>>msdn,microsoft,com>architect!re>patterns>defa!lt,asp&Cp!llV>library>en<
!s>dnpatterns>html>-sp,asp,
Implementing 2essage #ro-er with #i>Tal- Ser7er !<<'

245450494.doc 186 od 257
Integration Patterns
Contents
/onte&t
1ackgro!nd
+mplementation Strategy
-&ample
%es!lting /onte&t
Testing /onsiderations
Sec!rity /onsiderations
=perational /onsiderations
:ariants
%elated Patterns
cknowledgments
Conte.t
Ho!r application is interacting with m!ltiple other applications thro!gh a Message 1roker so that each
application only needs to comm!nicate with the Message )ro'er, rather than all the other applications, The
Message )ro'er is implemented by !sing Microsoft 1i9Talk Server 3445,
#ac-ground
"lobal 1ank is implementing an -&ec!te Sched!led Payment b!siness process that c!stomers can !se to
sched!le payments, -ach payment is transacted thro!gh a payment a!thority, The payment a!thority is
determined when that payee is first config!red, /!rrently, there are three different payment a!thorities:
There is an internal payment a!thority that "lobal 1ank !ses to handle payments itself,
There is an e&ternal payment a!thority where payment re?!ests are sent to an e&ternal bill payment
a!thority,
There is a man!al payment a!thority where payment re?!ests are handled man!ally,
245450494.doc 187 od 257
1ank growth, ac?!isitions, and mergers may increase the n!mber of payment a!thorities,
To implement the -&ec!te Sched!led Payment b!siness process, "lobal 1ank chose to !se Microsoft 1i9Talk
Server 3445 as an implementation of the Message )ro'er pattern, s 8ig!re 6 shows, re?!ests for payment are
sent directly to the message broker, and the message broker then sends the re?!est to the correct payment
a!thority,
/igure 11 #i>Tal- Ser7er !<<' as 2essage #ro-er in Global #an-
part from sending any message received to the appropriate recipient, the Message )ro'er implementation also
m!st do the following:
The implementation m!st parse the message to determine where to send it,
The implementation m!st convert the message from the so!rce format to the destination format,
The implementation m!st allow receivers 'applications( to register with the broker so that the broker
can send messages to them,
Implementation Strategy
1i9Talk Server 3445 !ses a P!blish>S!bscribe messaging architect!re that can easily be !sed to implement
Message )ro'er, 1i9Talk Server 3445 !ses Pipes and 8ilters for the message transformation,
245450494.doc 188 od 257
/igure !1 #i>Tal- Ser7er !<<' internal publish4subscribe architecture
8ig!re 3 shows how 1i9Talk Server 3445 receives, processes, ro!tes, and sends messages, client application
'the p!blisher( sends a message to a receive port thro!gh a predefined protocol, 8or e&ample, the p!blisher
may send a message to the message broker by writing a file into a directory on the server, The message is
received by the receive adapter, The following two types of adapters are available:
Transport adapters, Transport adapters receive messages by !sing standard transport mechanisms,
1i9Talk Server 3445 incl!des many standard transport adapters s!ch as )TTP, Simple Mail Transfer Protocol
'SMTP(, 8ile, and 8ile Transfer Protocol '8TP(,
Application adapters, pplication adapters connect with common b!siness applications, Ho! !s!ally
p!rchase these adapters from a vendor, or yo! develop them yo!rself,
The receive adapter passes the message to a receive pipeline, and the receive pipeline then parses and
converts the incoming message to QML 'e&cept when !sing the pass<thro!gh pipeline(, QML is the format that
1i9Talk Server 3445 !ses internally, s the receive adapter receives the message and as the receive pipeline
processes it, additional data abo!t the message is collected, This message metadata incl!des information abo!t
the transport the message was received on, s!ch as the original name of the file in the case of a file transport,
+t also incl!des information from each of the components in the pipeline, 8or e&ample, the Party %esol!tion
component stores information it receives from a digital certificate attached to the message, This metadata is
known as the conte:t properties,
The receive pipeline !ses an QML schema that the developer created, This schema disassembles and converts
the message to QML and then validates the message against the schema specification, The schema describes
the type, the cardinality, and the other attrib!tes of every record and every field that is contained in the
message, s the receive pipeline parses the message, it collects data from within the message itself, To do this,
245450494.doc 189 od 257
the developer creates a second schema that is known as a property sc"ema, The property schema allows
specific portions of the message to be promoted as additional metadata, This metadata is known as the
promoted properties, 8or an e&ample of how promotion occ!rs, see the @-&ample@ section later in this pattern,
fter preprocessing in the receive pipeline, the message is s!bmitted to the Message1o& database complete
with all additional metadata,
The Message1o& database sends the message to the message recipients by !sing a message s!bscription, To
implement a message s!bscription, the developer creates a send port that represents the message recipient,
send port !s!ally consists of a send pipeline for post<processing of the message, a send adapter that transmits
the message to its destination, and a filter e&pression that defines whether the message will be sent thro!gh
this send port, The filter e&pression is a ?!ery against the conte&t properties of messages in the Message1o&
database, copy of the message is only sent to this send port if there is a match between the filter e&pression
and the conte&t properties, 8or e&ample, the filter e&pression on the send port might state, @send all
documents t"at are of type E:ecutePayment.Payment0 w"ere t"e fulfillmentTypeId is e>ual to ;. @
The Message1o& database sends a copy of the messages to each send port that has a filter e&pression that
matches the conte&t properties, The message is received by the send port 'the s!bscriber process(, processed
by the send pipeline, and then transmitted thro!gh the send adapter, The send adapter can be a transport
adapter s!ch as 8ile, 8TP, )TTP, 1i9Talk Message B!e!ing 'MSMBT(, SMTP, S=P, or MBSeries, =r, the send
adapter can be an application adapter that connects directly to the destination application,
To implement the Message )ro'er, the "lobal 1ank developer m!st do the following:
6, The developer m!st define the format of the message sent by the so!rce application to the Message
)ro'er,
3, The developer m!st define the formats of the messages sent from the Message )ro'er to each of the
e&ternal systems and specify how the so!rce message is translated to the formats that are re?!ired by
the e&ternal systems,
;, The developer m!st define how messages are sent from the Message )ro'er to each e&ternal system,
5.ample
8ig!re ; shows the "lobal 1ank Message )ro'er implementation based on 1i9Talk Server 3445, The n!mbers
mark the areas that the following implementation steps foc!s on,
245450494.doc 190 od 257
/igure $1 Global #an- 2essage #ro-er implementation with #i>Tal- Ser7er !<<'
Step 1 Create the Recei7e Port and De&ine 2essage Schemas
The first step in the implementation of the Message )ro'er is to create the receive port in 1i9Talk -&plorer, This
receive port defines the location that the client application will send messages to so that the messages are
p!blished to the message broker, :irt!ally any transport can be !sed to send messages from the client to the
message broker, This e&ample !ses the 1i9Talk Message B!e!ing 'MSMBT( adapter beca!se MSMBT provides
g!aranteed delivery,
To create the recei7e port &or the message bro-er
6, /reate a receive port called Payment 1roker %P,
3, /reate a receive location on this receive port called Payment 1roker %L,
;, Set the transport for the receive location to MSMBT with a ?!e!e named Payments,
5, Specify the 1i9TalkServerpplication as the receive handler, and specify QML %eceive as the receive
pipeline,
A, fter following the remaining steps to implement the message broker, enable the receive location,
This completes the creation of the receive port,
.e&t, the payment messages sent by "lobal 1ank and the messages going to each of the three payment
channels have to be defined, The payment messages are marked 6a in 8ig!re ;, and the payment channels are
marked 6b, 1i9Talk Server !ses these definitions 'QML schemas( to parse and to convert messages into QML if
they are not already in QML, disassembler component in the receive pipeline parses and converts these
messages,
245450494.doc 191 od 257
8or the -&ec!te Sched!led Payment implementation, the schema is act!ally generated a!tomatically by the SBL
Transport Schema "eneration *i9ard 'see +mplementing Process +ntegration with 1i9Talk Server 3445(, 8ig!re
5 shows the generated schema in the 1i9Talk Server Schema -ditor,
/igure '1 The Payment schema in the #i>Tal- Ser7er !<<< Schema 5ditor
Ho! can also create a special second schema that is known as a property sc"ema, This property schema defines
one or more fields that are linked to specific fields in the message schema, Linking fields in this way is known
as promoting properties, This link between the message schema and the property schema is established in the
Promote Properties dialog bo& in the 1i9Talk Server Schema -ditor, +n 8ig!re 5, the !ni?!e symbol ne&t to
the f!lfillmentType+d field denotes a promoted property field,
8ig!re A shows the Promote Properties dialog bo& where yo! promote the f!lfillmentType+d field that is in the
payment message, The val!e of the f!lfillmentType+d field is !sed later to determine the payment a!thority that
the message is sent to,
245450494.doc 192 od 257
/igure (1 Creating a promoted property &ield ?Clic- the image to enlarge it@
The format of the message that is sent to the message broker is specified by the QML schema shown in 8ig!re
5, The format of the messages for each of the payment a!thorities is likely to be different from the so!rce
format, The format of the messages is also likely to vary between different payment a!thorities, Therefore,
schema definitions for each of the o!tgoing message formats also have to be b!ilt, 8or brevity, these schema
definitions are not presented here,
Step ! De&ine 2aps to Con7ert #etween 2essage /ormats
8or each of the destination message formats specified in the previo!s section, an QSLT map m!st be developed,
This QSLT map specifies how the so!rce message format is translated to the destination message format
'n!mber 3 in 8ig!re ;(, These message format translations may be merely str!ct!ral, 8or e&ample, converting
an QML message to a comma<separated<val!es '/S:( message is str!ct!ral, =r, the translation may re?!ire the
generation of new message content, 8or e&ample, the so!rce message may not contain any information abo!t
the time or date that the message was sent, b!t this information may be re?!ired in the destination format,
.ew message content also has to be generated when a field in the so!rce message is !sed as a key to a
specific row in a database table, and fields in the destination message are filled from fields in this database row,
This is a common re?!irement,
/igure )1 Payment authority map in the #i>Tal- 2apper ?Clic- the image to enlarge it@
Ho! can !se the 1i9Talk Mapper to create the QSLT maps, The 1i9Talk Mapper provides a graphical view of
so!rce and destination schemas and of the conversion from one to the other, The o!tp!t from the 1i9Talk
245450494.doc 193 od 257
Mapper is the QSLT map, 8ig!re P shows the development of a payment a!thority map from the so!rce QML
schema in the 1i9Talk Mapper, Three separate maps are created, one for each of the payment a!thorities:
Payment%e?!est3+nternalPayee,btm is created for the internal payee,
Payment%e?!est3-&ternalPayee,btm is created for the e&ternal payee,
Payment%e?!est3Man!alPayee,btm is created for the man!al payee,
Step $ Create Subscriptions to 2essages
To config!re the 1i9Talk Server message broker for the -&ec!te Sched!led Payment scenario, three send ports
m!st be config!red, -ach send port is config!red with its own specific transport type and transport address,
send pipeline, and 1i9Talk map 'n!mber ;a in 8ig!re ;(, +n addition, the port filter has to be specified
appropriately on each send port to set !p the correct s!bscription for this payment a!thority to the Message1o&
database 'n!mber ;b in 8ig!re ;(,
To con&igure one o& the send ports ?Internal Payment@
6, /reate a new send port that is called +nternalPayeeTSP,
3, Select S=AP ?Web Ser7ices@ for the transport type, $se the following as the transport address 'the
$niform %eso!rce +dentifier L$%+N(:
http:>>-+Payee>+nternalPayee>Payee,asm&
Depending on the transport chosen, different transport address information can be specified,
;, Specify E2% Pipeline as the send pipeline, The send pipeline defines the post<processing that is
performed on the message E!st before the message is sent, s!ch as attachment of a digital signat!re
to the message,
5, Specify PaymentRe0uest!InternalPayee1btm as the QSLT map to be applied to the so!rce
messages,
A, Specify the filters for this send port, These filters define the s!bscription for this send port in the
Message1o& database, and they control the criteria that the Message1o& database !ses to determine
the messages that are sent to this port, 8or the -&ec!te Sched!led Payment scenario, the filter
specifies the following two criteria as shown in 8ig!re O:
ll messages of type http:>>"lobal1ankSpayment,
Messages that have a promoted &ul&illmentTypeId property that is e?!al to 6 'internal
f!lfillment(,
245450494.doc 194 od 257
/igure *1 Speci&ying the &ilter ?subscription@ &or a send port
*ith this config!ration, all messages of type http:>>"lobal1ankSpayment that have a
&ul&illmentTypeId property that is set to 6 'internal f!lfillment( are sent to this send port, This send
port is config!red to transmit the payment a!thori9ation to the internal payment application by !sing a
S=P call,
P, /onfig!re the remaining ports in a similar way, -ach port has its own !ni?!e transport address and its
own !ni?!e QSLT map, +n addition, the filters on these two ports specify a different val!e for the
&ul&illmentTypeId property1 val!e of 3 denotes e&ternal f!lfillment, and a val!e of ; denotes
man!al f!lfillment,
O, 8inally, enlist and then start each of the send ports,
Resulting Conte.t
The implementation of the Message )ro'er pattern with 1i9Talk Server 3445 res!lts in the following benefits
and liabilities:
#ene&its
2essage routing is determined at run time, Destination applications can be added or deleted from
the system at r!n time witho!t affecting the so!rce application or other destination applications,
2essage trac-ing and archi7ing, ll messages transmitted thro!gh the message broker can be
a!tomatically tracked and archived, The tracking, archiving, and reporting f!nctionalities are implemented
only once, and they are shared by all applications that !se the message broker, +n 1i9Talk Server 3445,
these f!nctionalities are provided by the 1i9Talk Server )ealth and ctivity Tracker ')T(,
Centrali>ed management, The messaging for an application is config!red and managed from a
central location and is not coded into the applications,
%iabilities
245450494.doc 195 od 257
Additional message processing steps, This Message )ro'er implementation adds e&tra steps in the
processing of a message, These e&tra steps co!ld prevent some f!lly synchrono!s messaging scenarios
from being implemented, and they co!ld lead to higher latency than a straight<thro!gh processing sol!tion,
1i9Talk Server 3445 has an alternate message processing mechanism that is known as a re?!est<response
port, The re?!est<response port is specifically designed to solve problems ca!sed by these synchrono!s
messaging scenarios,
Routing rules are not centrali>ed, Decentrali9ed ro!ting r!les are an inherent weakness in this
Message )ro'er sol!tion, The ro!ting r!les are spread between all the send port config!rations in the filter
r!les that are specified, Therefore, config!ration errors are harder to deb!g, and the config!ration is more
comple& to manage,
Testing Considerations
Ho! can !se several strategies to test the Message )ro'er implementation:
/reate a mock destination application 'in other words, set !p a send port( that s!bscribes to all
messages of a specific type sent to the message broker, These messages are written to a test directory,
This process allows the message schemas and message maps to be validated,
-nable or disable send ports to test individ!al s!bscribers in isolation,
$se the )T to track all incoming and o!tgoing messages, to analy9e the message flow thro!gh the
Message1o& database, to report e&ception conditions, and to analy9e message thro!ghp!t,
$se the Microsoft :is!al St!dio ,.-T environment to test schemas and maps by validating sample
doc!ments, or !se the schemas and maps to generate sample message instances,
Security Considerations
The following sec!rity considerations apply when implementing Message )ro'er:
Controlling the 7isibility o& messages in the message bro-er, +f many different gro!ps in an
organi9ation are !sing the message broker, it may be necessary to implement access sec!rity to control
who can view messages that are sent to the message broker and to control who can set !p s!bscriptions to
messages, %emember that these messages may all be tracked and held in the Microsoft SBL Server
database, 1i9Talk Server 3445 provides a very detailed sec!rity model that allows this type of access
sec!rity to be enforced, 8or e&ample, message traffic can be partitioned across m!ltiple host instances,
where each host instance r!ns by !sing different sec!rity credentials,
Passing digitally signed messages, +n a point<to<point processing scenario, a message originator
may digitally sign and encrypt a message by !sing a certificate iss!ed by the receiver of the message,
)owever, if this message is transmitted thro!gh a message broker, the message broker !s!ally cannot
decrypt the message, To overcome this problem, the encrypted message can be wrapped in a clear te&t
envelope, The envelope contains metadata abo!t the message, s!ch as the address, The metadata allows
the message broker to pass the message to the intended recipient,
8alidating senders and recei7ers, $nder some circ!mstances, the message broker may need to
validate the p!blishers or the s!bscribers, This means the message broker m!st be able to validate a
message that has been digitally signed and then attach a digital signat!re to a message, 1i9Talk Server
3445 provides these capabilities,
=perational Considerations
The following operational considerations apply when implementing Message )ro'er:
Dynamic con&iguration, =ne of the big benefits of the Message )ro'er pattern is that it is easy to
config!re dynamically at r!n time, .ew p!blishers can easily be added at r!n time, and s!bscribers can be
added or removed easily,
%oad4balancing and &ault tolerance, s Message )ro'er becomes central to an organi9ationJs
integration sol!tion, it is essential for the message broker to be fa!lt<tolerant and for the message
processing workload to be spread across m!ltiple nodes, 1i9Talk Server 3445 works in conE!nction with
Microsoft SBL Server 3444 so that all the config!ration information, the messages, and the tracking data
are held within SBL Server 3444, 1i9Talk Server 3445 also works in conE!nction with Microsoft SBL Server
245450494.doc 196 od 257
3444 so that all processing is distrib!ted across all the servers r!nning 1i9Talk Server 3445 that are part of
the same 1i9Talk Server 3445 gro!p, ' 1i9Talk Server 3445 gro!p is a gro!p of servers that share the
same set of SBL Server tables(,
Store and &orward, %ather than send a message immediately, some message brokers can hold onto
a message !ntil a s!bscriber re?!ests it, This is !sef!l in sit!ations where s!bscribers are not connected all
the time, or where network iss!es ca!se problems, 1i9Talk Server 3445 does not provide this f!nctionality
directly, altho!gh it can easily be implemented by !sing database staging tables or Microsoft Message
B!e!ing 'MSMB(,
8ariants
$sing promoted properties in the message and !sing filters on the send port is the simplest way to implement a
message broker by !sing Microsoft 1i9Talk Server 3445, )owever, other more comple& implementations may be
preferable in certain circ!mstances,
#usiness Rule 5ngine
+n some sit!ations, the logic !sed to determine where the message is sent is more sophisticated than the
simple e&ample !sed here, or the logic is s!bEect to fre?!ent change, 8or e&ample, a b!siness may !se a
n!mber of s!ppliers, The b!siness may determine which s!pplier to send a p!rchase order to based on the
c!rrent relationship of the b!siness with that s!pplier, 8or e&ample, the b!siness might select the s!pplier
based on the level of disco!nts, This cannot be calc!lated by !sing information in the message, so b!siness
logic has to be written to determine this, This logic co!ld be coded in a Microsoft ,.-T 8ramework assembly and
referenced from a map, b!t if the b!siness r!le is s!bEect to fre?!ent change, each time the r!les change a new
version of the b!siness component m!st be deployed,
1i9Talk Server 3445 solves this iss!e by providing a 1!siness %!les -ngine, The 1!siness %!les -ngine enables
a !ser to define a vocab!lary that is based on information contained in the message and in a database, and
that is held in ,.-T 8ramework components, This vocab!lary may then be !sed to define a series of b!siness
r!les, These r!les can implement sophisticated b!siness logic, and this b!siness logic can then be changed and
deployed easily,
Roles and Parties
s the n!mber of p!blishers and s!bscribers increases, it becomes increasingly diffic!lt to manage and to
maintain the receive ports, the send ports, and the s!bscriptions, +n a scenario where there are tho!sands of
potential s!bscribers for a message, 1i9Talk Server 3445 !ses roles and parties, 8or e&ample, yo! may have
config!red tho!sands of s!bscribers 's!ppliers( to send p!rchase orders to in yo!r order processing system,
8or this e&ample, the S!pplier role is created, and a port type is associated with this role, +n this case, that is
the P!rchase=rderToS!pplierType port type, The o!tgoing message is then sent to an abstract
P!rchase=rderToS!pplierType port type,
+ndependently of this, parties are created to represent individ!al s!ppliers, fter parties are created, a party
can be enlisted in a role, 8or e&ample, a party called .orthwind Traders may be created and then enlisted in the
245450494.doc 197 od 257
S!pplier role, *hen this is done, a physical port of type P!rchase=rderToS!pplier m!st be config!red to send
the doc!ment to the act!al s!pplier,
The roles and parties implementation is more comple& and re?!ires the message broker to !se 1i9Talk
=rchestration instead of !sing 1i9Talk Messaging, )owever, when many potential message recipients are
involved, it provides a m!ch simpler mechanism for maintaining the recipients in the system,
Related Patterns
=f partic!lar note among related patterns, Enterprise Integration Patterns L)ohpe45N e&amines the difference
between the Pu%lis"*Su%scri%e implementation 'reactive filtering( and a content<based ro!ter, content<based
ro!ter e&amines the message and sends it to a recipient by !sing a process that is known as predicti!e routing.
8or more information, see the following patterns:
1roker L1!schmannMPN, +n a distrib!ted setting, the )ro'er pattern tries to make distrib!tion
transparent, /lient<side and server<side pro&ies mediate between the broker and the clients and server,
(ontent)ased /outer L)ohpe45N, The (ontent)ased /outer pattern is a )ro'er variant that
speciali9es in ro!ting comm!nications to different applications based on the comm!nicationJs content,
Mediator L"ammaMAN, The Mediator pattern separates obEects so that they are only aware of the
mediator b!t not each other, The )ro'er deals with similar concerns, b!t it can only be !sed in the conte&t
of enterprise applications,
Ac-nowledgments
L1!schmannMPN 1!schmann, 8rank# %egine Me!nier, )ans %ohnert, Peter Sommerlad, and Michael Stal,
Pattern-riented Software $rc"itecture0 <olume ;1 $ System of Patterns. 2ohn *iley & Sons Ltd, 6MMP,
L"ammaMAN "amma, -rich# %ichard )elm, %alph 2ohnson, and 2ohn :lissides, &esign Patterns1 Elements of
/eusa%le -%8ect-riented Software, ddison<*esley, 6MMA,
L)ohpe45N )ohpe, "regor, and 1obby *oolf, Enterprise Integration Patterns1 &esigning0 )uilding0 and
&eploying Messaging Solutions, ddison<*esley, 3445,
2essage #us

Integration Patterns
Contents
/onte&t
Problem
245450494.doc 198 od 257
8orces
Sol!tion
-&ample
%es!lting /onte&t
Sec!rity /onsiderations
=perational /onsiderations
%elated Patterns
cknowledgments
Conte.t
Ho! have an integration sol!tion that consists of applications that are provided by different vendors, These
applications r!n on a variety of platforms, Some of these applications generate messages and many other
applications cons!me the messages,
8or e&ample, consider a financial application that integrates trading tools, portfolio management applications,
modeling and risk analysis tools, trend indicators, and tickers, Market activity ca!ses interaction between these
systems, 8or e&ample, a trading system comm!nicates the completion of a sell transaction by sending a
message to all other trading applications, The trading system co!ld have individ!al connections to each trading
application, This works well for a few applications, b!t becomes a b!rden as the n!mber of applications
increases, Managing the addition or removal of trading applications sho!ld not interfere with processing trades,
Problem
s an integration sol!tion grows, how can yo! lower the cost of adding or removing applicationsC
/orces
dding an application to an integration sol!tion or removing an application from an integration sol!tion entails
balancing the following forces:
/omm!nication between applications !s!ally creates dependencies between the applications, The
sender m!st comm!nicate with the receivers, The receiver m!st recogni9e the messages from all the
senders, These dependencies translate into co!pling between the participants,
+n a config!ration where point<to<point connectivity e&ists, the co!pling has a ?!adratic 'or -?n3@(
growth with the n!mber of applications L/handra4;, Levine4;N, 8or e&ample, three f!lly connected
applications need three connections, b!t 64 applications need 5A connections, This ?!adratic growth
hampers maintainability, modifiability, and integrability,
$s!ally, the applications of an integration sol!tion have different interfaces, /hanging the interfaces of
proprietary applications is diffic!lt, -ven if yo! change the interface of one application, it is not feasible to
change the interface for all the applications of yo!r integration sol!tion,
245450494.doc 199 od 257
Some integration sol!tions consist of a fi&ed set of applications, n integration sol!tion that has low
e&tensibility and modifiability re?!irements typically does not need to accommodate new applications,
Solution
/onnect all applications thro!gh a logical component known as a message b!s, message b!s speciali9es in
transporting messages between applications, message b!s contains three key elements:
set of agreed<!pon message schemas
set of common command messages L)ohpe45N
shared infrastr!ct!re for sending b!s messages to recipients
*hen yo! !se a message b!s, an application that sends a message no longer has individ!al connections to all
the applications that m!st receive the message, +nstead, the application merely passes the message to the
message b!s, and the message b!s transports the message to all the other applications that are listening for
b!s messages thro!gh a shared infrastr!ct!re, Likewise, an application that receives a message no longer
obtains it directly from the sender, +nstead, it takes the message from the message b!s, +n effect, the message
b!s red!ces the fan<o!t of each application from many to one,
$s!ally, the b!s does not preserve message ordering, +nternal optimi9ations, ro!ting, b!ffering, or even the
!nderlying transport mechanism might affect how the messages travel to the receiving applications, Therefore,
the order in which messages reach each receiver is nondeterministic, Preserving the order of messages re?!ires
additional logic, This additional logic can be provided by the participating applications, 8or e&ample, the sending
application co!ld insert se?!ence n!mbers into the o!tgoing messages, and the receivers co!ld !se those
n!mbers to reorder the incoming messages, The logic co!ld also be provided by the b!s, and the logic co!ld
therefore be transparent for the participating applications, )owever, this additional logic is not re?!ired,
8ig!re 6 shows an integration sol!tion that !ses a message b!s, n application that sends messages thro!gh
the b!s m!st prepare the messages so that the messages comply with the type of messages the b!s e&pects,
Similarly, an application that receives messages m!st be able to !nderstand 'syntactically, altho!gh not
necessarily semantically( the message types, +f all applications in the integration sol!tion implement the b!s
interface, adding applications or removing applications from the b!s inc!rs no changes,
/igure 11 Applications communicating through a message bus
245450494.doc 200 od 257
The shared infrastr!ct!re between a message b!s and the listening applications can be achieved by !sing a
Message /outer L)ohpe45N or by !sing a P!blish>S!bscribe mechanism, This book foc!ses on message b!ses
that !se Pu%lis"*Su%scri%e mechanisms, 8or details on how to design a message b!s that !ses message<
oriented middleware and a Message /outer, see Enterprise Integration Patterns L)ohpe45N,
8ig!re 3 shows the Message )us pattern associated with the Pu%lis"*Su%scri%e pattern,
/igure !1 The 2essage #us pattern associated with the PublishBSubscribe pattern
The kind of Pu%lis"*Su%scri%e implementation that yo! decide to !se with a partic!lar message b!s has a
profo!nd impact on the message b!s architect!re, There are three types of Pu%lis"*Su%scri%e implementations:
#ist)ased Pu%lis"*Su%scri%e, )roadcast)ased Pu%lis"*Su%scri%e, and (ontent)ased Pu%lis"*Su%scri%e,
,ote ltho!gh the Pu%lis"*Su%scri%e pattern is an important part of a message b!s, Pu%lis"*Su%scri%e
implementations are also !sed independently of message b!ses, 8or e&ample, Pu%lis"*Su%scri%e mechanisms
are !sed with the PointtoPoint (onnection and Message 1roker patterns, See the Pu%lis"*Su%scri%e pattern
for more details,
2essage #us with %ist4#ased PublishBSubscribe
Maintaining lists of p!blished topics 's!bEects( and s!bscribers 'observers( and then notifying each one
individ!ally as events occ!r is the essence of #ist)ased Pu%lis"*Su%scri%e implementations,
To !se a message b!s that contains a #ist)ased Pu%lis"*Su%scri%e implementation, a system sends a
command message to the message b!s, The message b!s then looks !p all interested message b!s s!bscribers
and sends each message b!s s!bscriber a copy of the original message, ny data that is associated with the
message is in a common format so that all systems can interpret the command message and the data, and
then respond appropriately,
2essage #us with #roadcast4#ased PublishBSubscribe
245450494.doc 201 od 257
To !se a Message )us implementation that contains a )roadcast)ased Pu%lis"*Su%scri%e implementation, a
system sends a command message to the message b!s, The message b!s broadcasts the message to all the
nodes that are listening to the b!s, The message b!s makes no attempt to determine the appropriate
s!bscribers, +nstead, each listening node filters any !nwanted messages and processes only the messages that
it is interested in, ny data that is associated with the message is in a common format so that all systems can
interpret the command message and the data, and then respond appropriately,
2essage #us with Content4#ased PublishBSubscribe
To !se a Message )us pattern that contains a (ontent)ased Pu%lis"*Su%scri%e implementation, a system sends
a command message to the message b!s, fter the message b!s receives the message, it is responsible for
matching the message against a set of s!bscribers and then forwarding the message to each of the appropriate
s!bscribers, To match the message against a set of s!bscribers, the message b!s m!st determine if there are
any s!bscribers interested in this partic!lar message, +f an interested s!bscriber e&ists, the s!bscriber matches
a partic!lar message field or fields and a set of val!es, +f a match e&ists between the message content and a
s!bscriber, the message is then forwarded to each matching s!bscriber,
fter a s!bscribing system receives a b!s message, the s!bscribing system is able to process the message
beca!se the message contains the common command message and the agreed<!pon message schemas,
*hile the Message )us using #ist)ased Pu%lis"*Su%scri%e and the Message )us using (ontent)ased
Pu%lis"*Su%scri%e patterns both check for s!bscriptions before forwarding messages, there are key differences,
The list<based approach matches s!bscriptions on s!bEects, )owever, the content<based approach is m!ch more
fle&ible, 1eca!se the content<based approach allows yo! to identify one or more fields in the message and a set
of acceptable val!es for each field, yo! can create very intelligent ro!ting capabilities,
To make (ontent)ased Pu%lis"*Su%scri%e work, yo! need a high<performance infrastr!ct!re component that
can read each message, ?!ery a set of potential s!bscribers, and efficiently ro!te the message to each
s!bscriber, +n practice, yo! can think of this as a message switch, This is e&actly how Microsoft 1i9Talk Server
3445 is designed,
8ig!re ; shows the Message )us pattern !sing a Pu%lis"*Su%scri%e pattern or one of the Pu%lis"*Su%scri%e
variants,
245450494.doc 202 od 257
/igure $1 2essage #us pattern using a PublishBSubscribe pattern or one o& the PublishBSubscribe
7ariants
Table 6 shows the responsibilities and collaborations that are associated with the message b!s,
Table 1 2essage #us Responsibilities and Collaborations
Responsibilities Collaborations
GProvides a common set of message formats to the
participating applications,
GTransports messages from the sender to the other
applications that are connected to the b!s,
GSenders tag o!tgoing messages and pass them to the
b!s,
G%eceivers inspect the incoming messages and discard
the messages that are of no interest to any
application,
/hoosing a message b!s for comm!nication between the components of an integration sol!tion lowers the
co!pling, b!t it introd!ces other problems, The following are some ?!estions yo! sho!ld ask when considering a
message b!s for an integration sol!tion:
245450494.doc 203 od 257
1!s latency, )ow long does it take the message b!s to deliver a message to all the applications that
are connected to itC *hat happens if a sender tries to pass a message to the b!s before the b!s completes
message deliveryC
1!s contention, )ow do yo! prevent some applications from monopoli9ing the message b!sC +f some
applications monopoli9e the message b!s, other applications cannot !se it,
1!s arbitration, )ow do yo! deal with m!ltiple applications that want to pass messages to the
message b!s at the same timeC
5.ample
/onsider an integration sol!tion that integrates two trading systems, a portfolio manager, a risk analysis
application, a modeling application, a trend indicator, and a stock ticker, The trading systems comm!nicate with
each other whenever they process a transaction, They also send !pdates to the other applications,
point<to<point config!ration re?!ires individ!al connections between each trading system and all si&
applications, +n other words, integrating the participating applications involves 66 connections between the
participating applications, 8ig!re 5 shows this topology 'top( and the connections that are re?!ired to e&tend
the sol!tion to incl!de an additional trading system 'bottom(, The dotted lines represent the new connections,
/igure '1 Trading applications that use point4to4point connecti7ity
message b!s red!ces the n!mber of connections between the trading applications# 8ig!re A 'top( shows this
topology, s yo! can see from the fig!re, each trading application has a single connection to the b!s, -ach
trading system is !naware of how many applications are interested in its transactions, *ith this topology
245450494.doc 204 od 257
'bottom(, adding a new trading system re?!ires a single connection and does not affect the e&isting
applications,
/igure (1 Trading systems communicating through a message bus
Resulting Conte.t
*hen considering integration thro!gh a message b!s, yo! sho!ld weigh the following benefits and liabilities
that are associated with it:
#ene&its
Impro7ed modi&iability, -ach application has a single connection to the message b!s instead of
m!ltiple dedicated connections to each of the other applications, dding or removing an application has no
impact on the e&isting applications, +n addition, !pgrading the b!s interface does not re?!ire changing any
applications as long as the messages remain compatible with e&isting ones, 8or e&ample, this is the case
when yo! add new message types,
Reduced application comple.ity, The message b!s transports messages between senders and
receivers, Senders no longer interact with all the receivers that they need to send messages to,
+mproved performance, There are no intermediaries between the comm!nicating applications,
/omm!nication latency depends only on how fast the message b!s can move messages,
+mproved scalability, dding applications has a constant low cost, +n addition, yo! can add applications
to the message b!s !ntil the message b!s is sat!rated, message b!s is sat!rated when it cannot keep !p
with the data that it has to move between applications,
%iabilities
245450494.doc 205 od 257
Increased comple.ity, +ntegrating thro!gh a message b!s increases the comple&ity of the
integration sol!tion for the following reasons:
Architectural mismatch, The applications of an integration sol!tion typically make
conflicting architect!ral ass!mptions L"arlanMAN, Designing the message b!s interface and solving the
mismatch aro!nd the data model is a diffic!lt endeavor,
2essage bus access policies, /omm!nication thro!gh a shared reso!rce s!ch as a
message b!s re?!ires yo! to implement policies that ens!re fair access and that resolve conc!rrency
conflicts,
%owered modi&iability when the bus inter&ace brea-s compatibility, /hanging the message b!s
interface in a way that breaks compatibility typically affects all the applications that !se the b!s, +n other
words, the b!s interface represents an e&treme e&ample of a p!blished interface, Designing it re?!ires
foresight,
%owered integrability, ll the applications that are hooked to the message b!s m!st have the same
message b!s interface, pplications that have incompatible interfaces cannot !se the message b!s,
1eca!se the message b!s interface incl!des a common set of command messages, message schemas, and
shared infrastr!ct!re, these elements together define a common s!bset that may somewhat restrict the
operation of the participating applications,
%owered security, message b!s that !ses the )roadcast)ased Pu%lis"*Su%scri%e pattern reaches
all the applications that are connected to the b!s, regardless of the applications that the message is
intended for, 1roadcasting to all participants may not be acceptable if the messages contain sensitive data,
%ow tolerance &or application una7ailability, The receiver m!st be able to process messages when
the sender passes the messages to the b!s, This sol!tion does not tolerate receiver downtime, +n addition,
it does not provide direct s!pport for disconnected operation,
Security Considerations
1efore yo! !se a message b!s that !ses )roadcast)ased Pu%lis"*Su%scri%e, yo! sho!ld consider whether this
config!ration meets yo!r sec!rity re?!irements, The applications that are connected to the b!s receive every
message that goes thro!gh the message b!s, Participants that re?!ire a private conversation m!st encrypt
their comm!nication, lso, applications that comm!nicate thro!gh the message b!s do not have intermediate
components between them, +n other words, no physical component e&ists for mapping between different
sec!rity conte&ts, /onse?!ently, this config!ration is appropriate when the sec!rity conte&t is managed thro!gh
impersonation,
=perational Considerations
*hen a message b!s becomes sat!rated, message delivery may take a long time or even fail, Sat!ration co!ld
occ!r after yo! add new applications or after yo! make changes to the comm!nication profile of e&isting
applications, 8or e&ample, changes to the comm!nication profile incl!de changes in the message si9e and rate,
1eca!se both sit!ations are common in b!s<centered integration sol!tions, it is important to prevent sat!ration,
This translates into monitoring the operation of the message b!s and proactively keeping the message vol!me
below the ma&im!m capacity of the message b!s,
Related Patterns
8or more information, see the following related patterns:
Pu%lis"*Su%scri%e. This pattern helps keep cooperating systems synchroni9ed by one<way propagation
of messages# one p!blisher sends a message to any n!mber of intended s!bscribers,
Message )us $rc"itecture L)ohpe45N, This pattern revolves aro!nd a messaging infrastr!ct!re, and it
relies on a canonical data model and a common command set that is mentioned earlier in @Liabilities,@
245450494.doc 206 od 257
)lac'%oard L1!schmannMPN, The )lac'%oard pattern describes a shared storage area that the
components of the pattern !se to comm!nicate, /ons!mer components monitor the blackboard and grab
the data that matches their interest, Prod!cers p!t their o!tp!t on the blackboard so that it becomes
available to the others, Typically, integration applications s!ch as r!le engines and e&pert systems !se this
pattern,
Ac-nowledgments
L1!schmannMPN 1!schmann, 8rank# %egine Me!nier, )ans %ohnert, Peter Sommerland, and Michael Stal,
Pattern-riented Software $rc"itecture0 <olume ;1 $ System of Patterns, 2ohn *iley & Sons Ltd, 6MMP,
L/handra4;N /handra, David# nna Li!, $lrich %o&b!rgh, ndrew Mason, -,",.adhan, Pa!l Slater, Guidelines
for $pplication Integration0 Microsoft Patterns & Practices, December 344;, vailable on MSD. at:
http:>>msdn,microsoft,com>library>defa!lt,aspC!rlV>library>en<!s>dnpag>html>eappint,asp,
L"arlanMAN "arlan, David# %obert llen, and 2ohn =ckerbloom, @rchitect!ral Mismatch: *hy %e!se +s So
)ard,@ in IEEE Software, :ol!me 63, +ss!e P, .ovember 6MMA: 6O<3P,
L)ohpe45N )ohpe, "regor and 1obby *oolf, Enterprise Integration Patterns1 &esigning0 )uilding0 and &eploying
Messaging Solutions, ddison<*esley, 344;,
LLevine4;N Levine, %!ssell, @The Myth of the Disappearing +nterfaces,@ in )usiness Integration Aournal,
.ovember 344;,
PublishBSubscribe

Integration Patterns
Contents
liases
/onte&t
Problem
8orces
Sol!tion
-&ample
%es!lting /onte&t
245450494.doc 207 od 257
Testing /onsiderations
Sec!rity /onsiderations
=perational /onsiderations
%elated Patterns
cknowledgments
Aliases
Pu%*Su%
Conte.t
Ho! have an integration architect!re consisting of several applications, comm!nication infrastr!ct!re connects
these applications in a b!s, broker, or point<to<point topology, Some applications send m!ltiple message types,
=ther applications are interested in different combinations of these types,
8or e&ample, consider a financial system where several applications maintain c!stomer information, /!stomer
%elationship Management '/%M( application holds the master c!stomer information, )owever, a typical
sit!ation for integration scenarios e&istsIc!stomer information also resides in other systems that perform their
own c!stomer information management f!nctions, c!stomer<facing application generates !pdate messages
for changes to c!stomer information, s!ch as changes to c!stomer addresses, The messages m!st reach the
/%M application as well as the other applications that manage c!stomer information, )owever, this message
type is meaningless to the integrated applications that do not manage c!stomer information,
Problem
)ow can an application in an integration architect!re only send messages to the applications that are interested
in receiving the messages witho!t knowing the identities of the receiversC
/orces
+ntegrating applications so that they receive only the messages they are interested in involves balancing the
following forces:
The applications in an integration architect!re cons!me different message types, 8or e&ample,
applications that manage c!stomer information are interested in c!stomer information !pdates, Trading
applications are interested in b!y and sell transactions, pplications that participate in two<phase commit
transactions are interested in commit messages,
n application in an integration architect!re may send several message types, 8or e&ample, the
application may send c!stomer information messages and operational messages abo!t its stat!s, 'Stat!s is
also referred to as "ealt" in this conte&t(, Likewise, an application in an integration architect!re is !s!ally
interested only in a s!bset of the messages that are sent by the other applications, 8or e&ample, a
portfolio manager is interested only in the financial transactions that affect the stocks that it manages,
245450494.doc 208 od 257
The e&tent to which applications let yo! add information to their messages varies widely, 8i&ed binary
messages !s!ally provide no fle&ibility or limited fle&ibility in this area, +n contrast, it is !s!ally easy to
e&tend S=P messages thro!gh envelope elements,
Most integration architect!res integrate proprietary applications, These applications often make strong
ass!mptions abo!t the messages that they !se to comm!nicate with other applications in the environment,
-ven with a fle&ible message format, it may be diffic!lt to insert or to process message elements that the
application does not know abo!t,
Solution
-&tend the comm!nication infrastr!ct!re by creating topics or by dynamically inspecting message content,
-nable listening applications to s!bscribe to specific messages, /reate a mechanism that sends messages to all
interested s!bscribers, The three variations of the Pu%lis"*Su%scri%e pattern yo! can !se to create a
mechanism that sends messages to all interested s!bscribers are #ist)ased Pu%lis"*Su%scri%e, )roadcast
)ased Pu%lis"*Su%scri%e, and (ontent)ased Pu%lis"*Su%scri%e,
%ist4#ased PublishBSubscribe
#ist)ased Pu%lis"*Su%scri%e pattern advises yo! to identify a s!bEect and to maintain a list of s!bscribers for
that s!bEect, *hen events occ!r, yo! have the s!bEect notify each s!bscriber on the s!bscription list, classic
way to implement this design is described in the =bserver L"ammaMAN pattern, *hen yo! !se this pattern, yo!
identify two classes: s!bEects and observers, ss!ming yo! !se a p!sh model !pdate, yo! add three methods
to the s!bEect: Attach?@,Detach?@, and ,oti&y?@,Ho! add one method to the observerI"pdate?@,
To !se an observer, all interested observers register with the s!bEect by !sing the Attach?@method, s changes
occ!r to the s!bEect, the s!bEect then calls each registered observer by !sing the ,oti&y?@method, 8or a
detailed e&planation of the -%ser!er pattern, see &esign Patterns1 Elements of /eusa%le -%8ect-riented
Software L"ammaMAN,
n observer works fine if yo! have created instances of obEects that reify all yo!r observers and s!bEects, n
observer is especially well s!ited to sit!ations where yo! have one<to<many relationships between yo!r s!bEects
and yo!r observers, )owever, in the conte&t of integration, yo! often have many observers that are linked to
many s!bEects, which complicates the basic -%ser!er pattern, =ne way to implement this many<to<many
relationship is to create many s!bEects and to have each s!bEect contain a list of observers,
+f yo! !se this obEect str!ct!re to implement Pu%lis"*Su%scri%e, yo! m!st write these relationships to persistent
storage between process e&ec!tions, To do so within a relational database, yo! m!st add an associative table to
resolve the many<to<many dependencies between s!bEect and observer, fter yo! write this information to
persistent storage in a set of tables, yo! can directly ?!ery the database for the list of s!bscribers for a topic,
Maintaining lists of p!blished topics 's!bEects( and s!bscribers 'observers( and then notifying each one
individ!ally as events occ!r is the essence of #ist)ased Pu%lis"*Su%scri%e implementations, very different
means of achieving the same res!lt is a )roadcast)ased Pu%lis"*Su%scri%e implementation,
#roadcast4#ased PublishBSubscribe
245450494.doc 209 od 257
*hen yo! !se a )roadcast)ased Pu%lis"*Su%scri%e approach LTanneba!m46, =kiM;N, an event p!blisher
creates a message and broadcasts it to the local area network 'L.(, service on each listening node inspects
the s!bEect line, +f the listening node matches the s!bEect line to a s!bEect that it s!bscribes to, the listening
node processes the message, +f the s!bEect does not match, the listening node ignores the message,
S!bEect lines are hierarchical and may contain m!ltiple fields that are separated by periods, Listening nodes
that are interested in a partic!lar s!bEect can s!bscribe to these fields by !sing wildcards, if re?!ired,
ltho!gh this )roadcast)ased Pu%lis"*Su%scri%e implementation is an effective method for deco!pling
prod!cers from cons!mers, it is sometimes !sef!l to identify partic!lar topic s!bscribers, To identify topic
s!bscribers, a coordinating process sends a message that asks listening nodes to reply if they s!bscribe to a
partic!lar topic, %esponses are then ret!rned by each listening node to the provider to identify the s!bscribers,
1eca!se all messages are sent to all listening nodes, and beca!se each node is responsible for filtering
!nwanted messages, some a!thors refer to this as a p!blish>s!bscribe channel with reactive filtering
L)ohpe45N,
Content4#ased PublishBSubscribe
1oth )roadcast)ased Pu%lis"*Su%scri%e implementations and #ist)ased Pu%lis"*Su%scri%e implementations
can be broadly categori9ed as topic<based beca!se they both !se predefined s!bEects as many<to<many
channels, Pu%lis"*Su%scri%e implementations have recently evolved to incl!de a new formI(ontent)ased
Pu%lis"*Su%scri%e, The difference between topic<based and content<based approaches is as follows:
+n a topic<based system, processes e&change information thro!gh a set of predefined s!bEects 'topics( which
represent many<to<many distinct 'and fi&ed( logical channels, /ontent<based systems are more fle&ible as
s!bscriptions are related to specific information content and, therefore, each combination of information items
can act!ally be seen as a single dynamic logical channel, This e&ponential enlargement of potential logical
channels has changed the way to implement a p!b>s!b system, L1aldoni4;N
The practical implication of this approach is that messages are intelligently ro!ted to their final destination
based on the content of the message, This approach overcomes the limitation of a broadcast<based system,
where distrib!tion is co!pled to a m!lticast tree that is based on Transmission /ontrol Protocol 'T/P(, +t also
gives the integration architect a great deal of fle&ibility when deciding on content<based ro!ting logic,
Applying PublishBSubscribe
8ig!re 6 shows an integration sol!tion that consists of fo!r applications, The sender 'also called a pu%lis"er(
!ses a topic<based approach to p!blish messages to topic and to topic 1, Three receivers 'also called
su%scri%ers( s!bscribe to these topics# one receiver s!bscribes to topic , one receiver s!bscribes to topic 1,
and one receiver s!bscribes to both topic and to topic 1, The arrows show messages flowing from the
p!blisher to each s!bscriber according to these s!bscriptions,
245450494.doc 210 od 257
/igure 11 Subscription to topics controls the message types that reach each subscriber
+mplementing Pu%lis"*Su%scri%e !s!ally affects the messages, the integrated applications, and the
comm!nication infrastr!ct!re,
8irst, yo! m!st identify the topics or the content of interest to the receiving applications, This translates into
partitioning the set of message types into different s!bsets, 8or e&ample, consider the types of messages that
are sent by a trading system, Some trading applications track b!y transactions, some track sell transactions,
and other applications track both types of transaction, Separating the message by creating a b!y topic and a
sell topic partitions the trading system messages into s!bsets aimed at these applications,
.e&t, yo! m!st add information to the messages that indicates the topic or that identifies specific content
information, Sometimes yo! can store the topic<related information in an !n!sed message field, lternatively,
yo! may be able to add a new field for the topic, 8or e&ample, yo! may be able to insert a new element in a
S=P header, +f yo! can neither !se an e&isting field nor add a new one, yo! m!st find other ways to encode
the topic into the message, or yo! m!st !se a content<based approach instead,
Ho! m!st then e&tend the comm!nication infrastr!ct!re so that it delivers messages according to each
s!bscriberJs s!bscription, The approach that yo! !se depends on the topology of the integration sol!tion, 8or
e&ample, consider the three common topologies, 8or b!s integration, yo! can implement the s!bscription
mechanism in the b!s interface, 8or broker integration, yo! can implement the mechanism thro!gh s!bscription
lists to the broker, 8or point<to<point integration, yo! can implement the mechanism thro!gh s!bscription lists
in the p!blisher,
8inally, yo! m!st modify the integrated applications, The p!blisher m!st add the topic<related information to
each message that it p!blishes, 8or e&ample, if the topic is encoded as a header element, the p!blisher m!st
insert the topic<related information into the appropriate element, Likewise, the s!bscriber m!st specify the
topics of interest,
245450494.doc 211 od 257
S!bscriptions can be either fi&ed or dynamic, *ith fi&ed s!bscriptions, the integration architect sets the topics
that an application s!bscribes to, pplications have no control over their s!bscriptions, $s!ally, the
s!bscriptions are specified when each application is added to the integration sol!tion, 8ig!re 3 shows a fi&ed
s!bscription to Topic ,
/igure !1 PublishBSubscribe with &i.ed subscription
+n contrast, dynamic s!bscriptions enable applications to control their own s!bscriptions thro!gh a set of
control messages, pplications can remove e&isting s!bscriptions by sending messages to the comm!nication
infrastr!ct!re that remove the application from the s!bscription list, pplications can add new s!bscriptions by
sending messages to the comm!nication infrastr!ct!re that add the application to a s!bscription list, Most
comm!nication infrastr!ct!res that have Pu%lis"*Su%scri%e capabilities provide this feat!re, )owever,
s!pporting dynamic s!bscriptions is not a re?!irement,
245450494.doc 212 od 257
/igure $1 PublishBSubscribe with dynamic subscriptions
8ig!re ; shows how dynamic s!bscriptions f!nction, The top part of 8ig!re ; shows the initial s!bscription to
topic , The application then sends a message that removes it from the s!bscription list for topic , The
application then sends two messages that s!bscribe the application to topic 1 and topic /, The bottom part of
8ig!re ; shows the final s!bscription after these control messages are sent,
Related Decisions
fter yo! decide to !se Pu%lis"*Su%scri%e, yo! m!st make the following decisions:
Initial subscription, Ho! m!st decide how s!bscribers comm!nicate their s!bscriptions to the
comm!nication infrastr!ct!re when they are first added to the sol!tion,
Wildcard subscriptions, Ho! m!st decide if yo!r p!blish>s!bscribe mechanism needs to s!pport
wildcard s!bscriptions, *ildcard s!bscriptions enable s!bscribers to s!bscribe to m!ltiple topics thro!gh
one s!bscription,
Static or dynamic subscriptions, Ho! m!st decide if the applications in yo!r integration sol!tion
need to change their s!bscriptions dynamically,
Topic disco7ery, Ho! m!st decide how s!bscribers discover the available topics if the sol!tion
s!pports dynamic s!bscriptions,
Responsibilities and Collaborations
Table 6 s!mmari9es the responsibilities and collaborations of the parties involved in Pu%lis"*Su%scri%e,
245450494.doc 213 od 257
Table 1 Responsibilities and Collaborations Among PublishBSubscribe Components
Components Responsibilities Collaborations
/omm!nication
infrastr!ct!re
GMaintains the s!bscribersJ s!bscriptions,
G+nspects the topic<related information or the
content information that is incl!ded in each
p!blished message,
GTransports the message to the s!bscribed
applications,
GThe p!blisher p!blishes messages,
GThe s!bscriber s!bscribes to topics
and receives messages,
P!blisher G+nserts topic<related information or content
information in each message,
GP!blishes the message to the comm!nication
infrastr!ct!re,
GThe comm!nication infrastr!ct!re
transports messages to s!bscribers,
S!bscriber GS!bscribes to one or more topics or message
content types,
G/ons!mes messages p!blished to the
s!bscribed topics,
GThe comm!nication infrastr!ct!re
transports p!blished messages from
the p!blisher,
5.ample
Microsoft 1i9Talk Server 3445 !ses the Pu%lis"*Su%scri%e pattern internally to receive, to ro!te, and to send
messages, 1i9Talk Server receives messages thro!gh inp!t ports and stores them in the Message1o& database,
=rchestration ports and send ports cons!me messages from this database based on their s!bscriptions, 8ig!re
5 ill!strates this arrangement,
245450494.doc 214 od 257
/igure '1 PublishBSubscribe in #i>Tal- Ser7er !<<'
Resulting Conte.t
$sing Pu%lis"*Su%scri%e has the following benefits and liabilities, -val!ate this information to help yo! decide
whether yo! sho!ld implement Pu%lis"*Su%scri%e:
#ene&its
Lowered co!pling, The p!blisher is not aware of the n!mber of s!bscribers, of the identities of the
s!bscribers, or of the message types that the s!bscribers are s!bscribed to,
+mproved sec!rity, The comm!nication infrastr!ct!re transports the p!blished messages only to the
applications that are s!bscribed to the corresponding topic, Specific applications can e&change messages
directly, e&cl!ding other applications from the message e&change,
Impro7ed testability, Topics !s!ally red!ce the n!mber of messages that are re?!ired for testing,
%iabilities
+ncreased comple&ity, Pu%lis"*Su%scri%e re?!ires yo! to address the following:
Ho! have to design a message classification scheme for topic implementation,
Ho! have to implement the s!bscription mechanism,
Ho! have to modify the p!blisher and the s!bscribers,
+ncreased maintenance effort, Managing topics re?!ires maintenance work, =rgani9ations that
maintain many topics !s!ally have formal proced!res for their !se,
Decreased performance, S!bscription management adds overhead, This overhead increases the
latency of message e&change, and this latency decreases performance,
Testing Considerations
The topics of a Pu%lis"*Su%scri%e implementation facilitate the testing of an integration sol!tion, S!bscriptions
provide isolation by segmenting the message space, 1y s!bscribing only to the topics or to the content of
interest, testers and testing tools have fewer messages to sift thro!gh, Likewise, by s!bscribing to other topics
or content, testers can catch messages that are p!blished to the wrong topic,
Security Considerations
n integration sol!tion that !ses Pu%lis"*Su%scri%e can restrict the participants of a message e&change, th!s
enabling applications to have private message e&changes, Depending on the topology, the messages may still
be physically transported to all the applications in the integration architect!re, 8or e&ample, all the messages
are transported to all the applications if yo!r integration sol!tion !ses the Message )us using )roadcast)ased
Pu%lis"*Su%scri%e pattern, )owever, the interface between the comm!nication infrastr!ct!re and the application
enforces filtering according to each applicationJs s!bscriptions,
=perational Considerations
Many integration sol!tions that !se Pu%lis"*Su%scri%e have topics or content that is dedicated to messages
abo!t the applicationsJ health, This separation facilitates yo!r ability to monitor vario!s operational parameters
and to control the applications in the integration sol!tion,
245450494.doc 215 od 257
Related Patterns
8or more information abo!t Pu%lis"*Su%scri%e, see other similar patterns:
Message 1!s and Message 1roker describe two common integration topologies,
=bserver L"ammaMAN provides a mechanism for deco!pling dependencies between applications,
Pu%lis"erSu%scri%er L1!schmannMPN facilitates state synchroni9ation between cooperating
components,
Pu%lis"Su%scri%e ("annel L)ohpe45N provides a way to broadcast events to all the receivers
's!bscribers( that s!bscribe to a specific topic,
Ac-nowledgments
L1aldoni4;N 1aldoni, %,# M, /ontenti, and , :irgillito, @T"e E!olution of Pu%lis"*Su%scri%e (ommunication
Systems.7 Future &irections of &istri%uted (omputing. Springer :erlag L./S :ol, 3A75, 344;,
L1!schmannMPN 1!schmann, 8rank# %egine Me!nier, )ans %ohnert, Peter Sommerlad, and Michael Stal,
Pattern-riented Software $rc"itecture0 <olume ;1 $ System of Patterns. 2ohn *iley & Sons Ltd, 6MMP,
L"ammaMAN "amma, -rich# %ichard )elm, %alph 2ohnson, and 2ohn :lissides, &esign Patterns1 Elements of
/eusa%le -%8ect-riented Software, ddison<*esley, 6MMA,
L)ohpe45N )ohpe, "regor, and 1obby *oolf, Enterprise Integration Patterns1 &esigning0 )uilding and &eploying
Messaging Solutions, ddison<*esley, 3445,
L=kiM;N =ki, 1,# M, Pfl!egel, , Siegel, and D, Skeen, @The +nformation 1!s < n rchitect!re for -&tensive
Distrib!ted Systems,@ Proceedings of t"e ;BBC $(M Symposium on -perating Systems Principles, December
6MM;,
LTanneba!m46N Tanneba!m, ndrew, Modern -perating Systems. 3nd ed, Prentice<)all, 3446,
Additional Integration Patterns

Integration Patterns
2!ne 3445
Summary This chapter presents two important patterns: Pipes and Filters and Gateway, This chapter e&plains
both patterns and then traces them to implementations that !se the Microsoft platform,
Contents
Pipes and 8ilters
245450494.doc 216 od 257
"ateway
+ntegration Layers Patterns
This chapter completes this investigation of integration patterns by e&ploring the Pipes and 8ilters pattern and
the "ateway pattern, 1oth patterns are simple b!t val!able for resolving integration problems,
-ven tho!gh this chapter completes this disc!ssion, yo! can obtain information abo!t additional integration
patterns in the ppendi&,
Pipes and /ilters
Pipes and Filters provides a sol!tion for moving the o!tp!t of one system into another system, The pipe is the
portion of the code that is connected to the so!rce system and to the sink or the receiving system, The filter is
the portion of the code that transforms the data so that the sink program can process it,
This pattern is !sef!l when yo! need to transform the data from one system into a different format to integrate
that data into another system, simple e&ample is the conversion of data from S/++ to -&tended 1inary
/oded Decimal +nterchange /ode '-1/D+/( that occ!rs when data moves from a desktop comp!ter to a
mainframe,
8ig!re 6 shows a so!rce system integrated with a sink system, The so!rce system !ses m!ltiple filters to
transform the data to the format that the sink system re?!ires,
245450494.doc 217 od 257
/igure 11 A source system integrated with the sin- system through Pipes and /ilters
+n the "lobal 1ank scenario, the Pipes and Filters pattern is !sed to handle the comm!nication between
Microsoft 1i9Talk Server 3445 and e&ternal payment channels,
Gateway
The Gateway pattern abstracts the access to an e&ternal system to a single interface, The pattern eliminates
the need for m!ltiple systems to !nderstand how to connect to the e&ternal system, Therefore, the Gateway
pattern simplifies the development and maintenance processes that are related to accessing e&ternal systems,
/ommon !ses for the Gateway pattern incl!de accessing mainframe programs and processing credit card
transactions, 8or each of these common !ses, the gateway replaces direct access to the e&ternal reso!rce or
system, as shown in 8ig!re 3,
/igure !1 Gateway replaces direct access to the e.ternal resource
+n the "lobal 1ank scenario, the Gateway pattern is implemented by !sing Microsoft )ost +ntegration Server
3445, )ost +ntegration Server 3445 provides the sol!tion for integrating the mainframe to the enterprise,
Additional Integration Patterns
The following table s!mmari9es the two patterns E!st disc!ssed and shows the corresponding implementation
patterns,
Table 1 Additional Integration Patterns
Pattern Problem Associated implementations
"ateway )ow can yo! make the applications
of an integration sol!tion access an
e&ternal system witho!t
introd!cing many<to<one co!pling
between the applications and the
e&ternal systemC
+mplementing "ateway with )ost
+ntegration Server 3445
245450494.doc 218 od 257
Pipes and 8ilters )ow do yo! implement a se?!ence
of transformations so that yo! can
combine and re!se them
independentlyC
+mplementing Pipes and 8ilters with
1i9Talk Server 3445
Pipes and /ilters

Integration Patterns
Contents
liases
/onte&t
Problem
8orces
Sol!tion
-&ample
%es!lting /onte&t
Testing /onsiderations
0nown $ses
%elated Patterns
cknowledgments
Aliases
&ata Flow $rc"itecture
Conte.t
Ho! have an integration sol!tion that consists of several financial applications, The applications !se a wide
range of formatsIs!ch as the +nteractive 8inancial -&change '+8Q( format, the =pen 8inancial -&change '=8Q(
format, and the -lectronic Data +nterchange '-D+( formatIfor the messages that correspond to payment,
withdrawal, deposit, and f!nds transfer transactions,
245450494.doc 219 od 257
+ntegrating these applications re?!ires processing the messages in different ways, 8or e&ample, converting an
QML<like message into another QML<like message involves an QSLT transformation, /onverting an -D+ data
message into an QML<like message involves a transformation engine and transformation r!les, :erifying the
identity of the sender involves verifying the digital signat!re attached to the message, +n effect, the integration
sol!tion applies several transformations to the messages that are e&changed by its participants,
Problem
)ow do yo! implement a se?!ence of transformations so that yo! can combine and re!se them independentlyC
/orces
+mplementing transformations that can be combined and re!sed in different applications involves balancing the
following forces:
Many applications process large vol!mes of similar data elements, 8or e&ample, trading systems
handle stock ?!otes, telecomm!nication billing systems handle call data records, and laboratory
information management systems 'L+MS( handle test res!lts,
The processing of data elements can be broken down into a se?!ence of individ!al transformations,
8or e&ample, processing QML messages typically involves a series of QSLT transformations,
The f!nctional decomposition of a transformation f+:, into g+:, and "+6, 'where f?:@Dg?:@E"?6@( does
not change the transformation, )owever, when separate components implement g and "0 the
comm!nication between them 'that is, passing the o!tp!t of g?:@ to "?6@( inc!rs overhead, This overhead
increases the latency of a g+:,E"+6, implementation compared to an f+:, implementation,
Solution
+mplement the transformations by !sing a se?!ence of filter components, where each filter component receives
an inp!t message, applies a simple transformation, and sends the transformed message to the ne&t
component, /ond!ct the messages thro!gh pipes LMc+lroyP5N that connect filter o!tp!ts and inp!ts and that
b!ffer the comm!nication between the filters,
The left side of 8ig!re 6 shows a config!ration that has two filters, so!rce application feeds messages thro!gh
the pipe into filter 6, The filter transforms each message it receives and then sends each transformed message
as o!tp!t into the ne&t pipe, The pipe carries the transformed message to filter 3, The pipe also b!ffers any
messages that filter 6 sends and that filter 3 is not ready to process, The second filter then applies its
transformation and passes the message thro!gh the pipe to the sink application, The sink application then
cons!mes the message, This config!ration re?!ires the following:
The o!tp!t of the so!rce m!st be compatible with the inp!t of filter 6,
The o!tp!t of filter 6 m!st be compatible with the inp!t of filter 3,
The o!tp!t of filter 3 m!st be compatible with the inp!t of the sink,
245450494.doc 220 od 257
/igure 11 "sing Pipes and /ilters to brea- processing into a se0uence o& simpler trans&ormations
The right side of 8ig!re 6 shows a single filter, 8rom a f!nctional perspective, each config!ration implements a
transfer f!nction, The data flows only one way and the filters comm!nicate solely by e&changing messages,
They do not share state# therefore, the transfer f!nctions have no side effects, /onse?!ently, the series
config!ration of filter 6 and filter 3 is f!nctionally e?!ivalent to a single filter that implements the composition
of the two transfer f!nctions 'filter 63 in the fig!re(,
/omparing the two config!rations ill!strates their tradeoffs:
The two<filter config!ration breaks the transformation between the so!rce and the sink into two
simpler transformations, Lowering the comple&ity of the individ!al filters makes them easier to implement
and improves their testability, +t also increases their potential for re!se beca!se each filter is b!ilt with a
smaller set of ass!mptions abo!t the environment that it operates in,
The single<filter config!ration implements the transformation by !sing one speciali9ed component, The
one hop that e&ists between inp!t and o!tp!t and the elimination of the interfilter comm!nication translate
into low latency and overhead,
+n s!mmary, the key tradeoffs in choosing between a combination of generic filters and a single speciali9ed
filter are re!sability and performance,
+n the conte&t of pipes and filters, a transformation refers to any transfer f!nction that a filter might implement,
8or e&ample, transformations that are commonly !sed in integration sol!tions incl!de the following:
/onversion, s!ch as converting -&tended 1inary /oded Decimal +nterchange /ode '-1/D+/( to S/++
245450494.doc 221 od 257
-nrichment, s!ch as adding information to incoming messages
8iltering, s!ch as discarding messages that match a specific criteria
1atching, s!ch as aggregating 64 incoming messages and sending them together in a single o!tgoing
message
/onsolidation, s!ch as combining the data elements of three related messages into a single o!tgoing
message
+n practice, the transfer f!nction corresponds to a transformation that is specific eno!gh to be !sef!l, yet
simple eno!gh to be re!sed in a different conte&t, +dentifying the transformations for a problem domain is a
diffic!lt design problem,
Table 6 shows the responsibilities and collaborations that are associated with pipes and filters,
Table 1 Responsibilities and Collaborations o& Pipes and /ilters
Responsibilities Collaborations
G filter takes a message from its inp!t, applies a
transformation, and sends the transformed message
as o!tp!t,
G filter prod!ces and cons!mes messages,
G pipe transports messages between filters, 'So!rces
and sinks are special filters witho!t inp!ts or o!tp!ts,(
G pipe connects the filter with the prod!cer and the
cons!mer, pipe transports and b!ffers messages,
5.ample
/onsider a *eb service for printing ins!rance policies, The service accepts QML messages from agency
management systems, +ncoming messages are based on the /=%D QML specification, an ins!rance ind!stry
standard, )owever, each agency has added proprietary e&tensions to the standard /=%D transactions, print
re?!est message specifies the type of doc!ment to be generated, for e&ample, an )TML doc!ment or a Portable
Doc!ment 8ormat 'PD8( doc!ment, The re?!est also incl!des policy data s!ch as client information, coverage,
and endorsements, The *eb service processes the proprietary e&tensions and adds the E!risdiction<specific
information that sho!ld appear on the printed doc!ments, s!ch as local or regional re?!irements and
restrictions, The *eb service then generates the doc!ments in the re?!ested format and ret!rns them to the
agency management system,
Ho! co!ld implement these processing steps as a single transformation within the *eb service, ltho!gh viable,
this sol!tion does not let yo! re!se the transformation in a different conte&t, +n addition, to accommodate new
re?!irements, yo! wo!ld have to change several components of the *eb service, 8or e&ample, yo! wo!ld have
to change several components if a new re?!irement calls for decrypting some elements of the incoming
messages,
n implementation that is based on Pipes and Filters provides an elegant alternative for the printing *eb
service, 8ig!re 3 ill!strates a sol!tion that involves three separate transformations, The transformations are
implemented as filters that handle conversion, enrichment, and rendering,
245450494.doc 222 od 257
/igure !1 Printing Web ser7ice that uses Pipes and /ilters
The printing service first converts the incoming messages into an internal vendor<independent format, This first
transformation lowers the dependencies on the proprietary /=%D QML e&tensions, +n effect, changing the
format of the incoming messages only affects the conversion filter,
fter conversion, the printing service retrieves doc!ments and forms that depend on the E!risdiction and adds
them to the re?!est message, This transformation encaps!lates the E!risdiction<specific enrichment,
*hen the message contains all the information that comprises the final electronic doc!ment, a doc!ment
generation filter converts the message to )TML or PD8 format, style sheet repository provides information
abo!t the appearance of each doc!ment, This last transformation encaps!lates the knowledge of rendering
legally binding doc!ments,
+n this e&ample, the Pipes and Filters implementation of the printing *eb service has the following benefits that
make it preferable to implementing the *eb service as a single monolithic transformation:
Separation o& concerns, -ach filter solves a different problem,
Di7ision o& labor, /=%D QML e&perts implement the conversion of the proprietary e&tensions into
an internal vendor<independent format, People who speciali9e in dealing with the intricacies of each
E!risdiction assist with the implementation of the filter that handles those aspects, 8ormatters and layo!t
e&perts implement doc!ment generation,
245450494.doc 223 od 257
Speciali>ation, Doc!ment<rendering is /P$ intensive and, in the case of a PD8 doc!ment, !ses
floating point operations, Ho! can deploy the rendering to hardware that meets these re?!irements,
Reuse, -ach filter encaps!lates fewer conte&t<specific ass!mptions, 8or e&ample, the doc!ment
generator takes messages that conform to some schema and generates an )TML or PD8 doc!ment, =ther
applications can re!se this filter,
Resulting Conte.t
$sing Pipes and Filters res!lts in the following benefits and liabilities:
#ene&its
+mproved re!sability, 8ilters that implement simple transformations typically encaps!late fewer
ass!mptions abo!t the problem they are solving than filters that implement comple& transformations, 8or
e&ample, converting a message from one QML encaps!lation to another encaps!lates fewer ass!mptions
abo!t that conversion than generating a PD8 doc!ment from an QML message, The simpler filters can be
re!sed in other sol!tions that re?!ire similar transformations,
+mproved performance, Pipes and Filters sol!tion processes messages as soon as they are received,
Typically, filters do not wait for a sched!ling component to start processing,
%ed!ced co!pling, 8ilters comm!nicate solely thro!gh message e&change, They do not share state and
are therefore !naware of other filters and sinks that cons!me their o!tp!ts, +n addition, filters are !naware
of the application that they are working in,
Impro7ed modi&iability, Pipes and Filters sol!tion can change the filter config!ration dynamically,
=rgani9ations that !se integration sol!tions that are s!bEect to service level agreements !s!ally monitor
the ?!ality of the services they provide on a constant basis, These organi9ations !s!ally react proactively
to offer the agreed<!pon levels of service, 8or e&ample, a Pipes and Filters sol!tion makes it easier for an
organi9ation to maintain a service level agreement beca!se a filter can be replaced by another filter that
has different reso!rce re?!irements,
%iabilities
+ncreased comple&ity, Designing filters typically re?!ires e&pert domain knowledge, +t also re?!ires
several good e&amples to generali9e from, The challenge of identifying re!sable transformations makes
filter development an even more diffic!lt endeavor,
Lowered performance d!e to comm!nication overhead, Transferring messages between filters inc!rs
comm!nication overhead, This overhead does not contrib!te directly to the o!tcome of the transformation#
it merely increases the latency,
+ncreased comple&ity d!e to error handling, 8ilters have no knowledge of the conte&t that they operate
in, 8or e&ample, a filter that enriches QML messages co!ld r!n in a financial application, in a
telecomm!nications application, or in an avionics application, -rror handling in a Pipes and Filters
config!ration !s!ally is c!mbersome,
+ncreased maintainability effort, Pipes and 8ilters config!ration !s!ally has more components than a
monolithic implementation 'see 8ig!re 3(, -ach component adds maintenance effort, system management
effort, and opport!nities for fail!re,
+ncreased comple&ity of assessing the state, The Pipes and 8ilters pattern distrib!tes the state of the
comp!tation across several components, The distrib!tion makes ?!erying the state a comple& operation,
Testing Considerations
1reaking processing into a se?!ence of transformations facilitates testing beca!se yo! can test each component
individ!ally,
6nown "ses
245450494.doc 224 od 257
The inp!t and o!tp!t pipelines of Microsoft 1i9Talk Server 3445 revolve aro!nd Pipes and Filters, The pipelines
process messages as they enter and leave the engine, -ach pipeline consists of a se?!ence of transformations
that !sers can c!stomi9e, 8or e&ample, the receive pipeline provides filters that perform the following actions:
The filters decode M+M- and S>M+M- messages,
The filters disassemble flat files, QML messages, and 1i9Talk 8ramework '1T8( messages,
The filters validate QML doc!ments against QML schemas,
The filters verify the identity of a sender,
The 1i9Talk Pipeline Designer allows developers to connect and to config!re these filters within the pipeline,
8ig!re ; shows a pipeline that consists of Pre<ssemble, ssemble, and -ncode filters, The toolbo& shows the
filters than can be dropped into this config!ration,
/igure $1 A 2icroso&t #i>Tal- Ser7er!<<' send pipeline in Pipeline Designer ?Clic- the image to
enlarge it@
Many other integration prod!cts !se Pipes and Filters for message transformation, +n partic!lar, QML<based
prod!cts rely on QSL processors to convert QML doc!ments from one schema to another, +n effect, the QSL
processors act as programmable filters that transform QML,
Related Patterns
8or more information abo!t Pipes and Filters, see the following related patterns:
+mplementing Pipes and 8ilters with 1i9Talk Server 3445, This pattern !ses the "lobal 1ank scenario to
show how yo! can !se 1i9Talk Server 3445 to implement Pipes and 8ilters,
245450494.doc 225 od 257
Pipes and Filters LShawMP, 1!schmannMP, )ohpe4;N,
+ntercepting 8ilter LTrowbridge4;N, This version of Intercepting Filter disc!sses the pattern in the
conte&t of *eb applications b!ilt !sing the Microsoft ,.-T 8ramework, Developers can chain filters to
implement preprocessing and post<processing tasks s!ch as e&tracting header information and rewriting
$%Ls,
In%and and -utof%and Partitions LManolesc!MON, This pattern remedies the lack of a component that
has a global conte&t in Pipes and Filters systems, The o!t<of<band partition is conte&t<aware# therefore, it
can config!re the filters and handle errors,
Ac-nowledgments
L1!schmannMPN 1!schmann, 8rank# %egine Me!nier, )ans %ohnert, Peter Sommerland, and Michael Stal,
Pattern-riented Software $rc"itecture, 2ohn *iley & Sons Ltd, 6MMP,
L)ohpe45N )ohpe, "regor and 1obby *oolf, Enterprise Integration Patterns1 &esigning0 )uilding0 and &eploying
Messaging Solutions, ddison<*esley, 3445,
LManolesc!MON Manolesc!, Dragos, @ Data 8low Pattern Lang!age,@ in Proceedings of t"e 5t" Pattern
#anguages of Programming, September 6MMO, Monticello, +llinois,
LMc+lroyP5N The fl!id<flow analogy dates from the days of the first $.+Q systems and is attrib!ted to Do!glas
Mc+lroy# see http:>>cm,bell<labs,com>cm>cs>who>dmr>mdmpipe,html,
LTrowbridge4;N Trowbridge, David# Dave Mancini, Dave B!ick, "regor )ohpe, 2ames .ewkirk, and David
Lavigne, Enterprise Solution Patterns Using Microsoft .NET, Microsoft Press, 344;, lso available on the MS&N
$rc"itecture (enter at: http:>>msdn,microsoft,com>architect!re>patterns>defa!lt,asp&Cp!llV>library>en<
!s>dnpatterns>html>-sp,asp,
LShawMPN Shaw, Mary, and David "arlan, Software $rc"itecture1 Perspecti!es on an Emerging &iscipline,
Prentice )all, 6MMP,
Implementing Pipes and /ilters with #i>Tal- Ser7er !<<'

Integration Patterns
Contents
/onte&t
1ackgro!nd
+mplementation Strategy
245450494.doc 226 od 257
-&ample
%es!lting /onte&t
Testing /onsiderations
Sec!rity /onsiderations
=perational /onsiderations
cknowledgments
Conte.t
Ho! are implementing Pipes and 8ilters by !sing Microsoft 1i9Talk Server 3445,
#ac-ground
The "lobal 1ank scenario incl!des the -&ec!te Sched!led Payment !se case, This !se case permits "lobal 1ank
to transfer f!nds from a c!stomerJs acco!nt to a specified target acco!nt, The target acco!nt can reside in one
of three systems:
n internal banking system that !ses an internal "lobal 1ank payment channel,
n e&ternal banking system that !ses encrypted and signed e<mail messages to transfer f!nds, =ne
s!ch system is the Society for *orldwide +nterbank 8inancial Telecomm!nication 'S*+8T( payment
channel,
n e&ternal banking system that cannot accept an electronic f!nds transfer and therefore has to
receive a paper check, This is an e&ternal man!al payment channel,
This pattern describes how to implement the -&ec!te Sched!led Payment !se case in the "lobal 1ank scenario
by !sing the Pipes and Filters pattern that is described earlier in this g!ide. This implementation !ses 1i9Talk
Server 3445 to transform and to ro!te f!nds to the target acco!nts by !sing the correct channel, as shown in
8ig!re 6,
245450494.doc 227 od 257
/igure 11 #i>Tal- Ser7er!<<' as Pipes and /ilters
Specifically, this pattern foc!ses on how to implement 1i9Talk Server 3445 to send payment information to
target acco!nts thro!gh channels s!ch as the S*+8T bank payment channel, The comm!nication on the
e&ternal payment channel sends confidential information across p!blic networks# that information sho!ld be
protected against !na!thori9ed !se, To address this iss!e, the b!siness re?!irements re?!ire yo! to encrypt the
messages to avoid eavesdropping by third parties, The b!siness re?!irements also re?!ire yo! to add a
certificate to ens!re the a!thenticity of messages, certificate prevents third parties from generating false
messages that are designed to credit bank acco!nts,
This implementation !ses the S>M+M- protocol and the Triple Data -ncryption Standard 'D-S;( encryption
algorithm, Signing and encrypting the messages for the e&ternal payment channel involves applying a pair of
transformations to the message data, =ne transformation digitally signs the message by comp!ting a
checks!m, nother transformation !ses a 6P7<bit secret key to encrypt the message,
Implementation Strategy
*hen 1i9Talk Server 3445 receives a message, the incoming data can be processed by a receive pipeline before
it enters the Message1o& database, as shown in 8ig!re 3, The typical f!nctions that are performed in a receive
pipeline incl!de the following:
Decoding and parsing of incoming data s!ch as an QML file or a flat file
:alidation# for e&ample, verifying the incoming data against an QML schema
Party resol!tion
Likewise, any message s!bscriber can config!re a send pipeline to preassemble the message data before it is
transferred o!t on the physical send port, Typical f!nctions that are performed in a send pipeline incl!de the
following:
:alidation
ssembly of an QML doc!ment
-ncoding
Digital signing
/igure !1 #i>Tal- Ser7er !<<' 2essage#o. database architecture
-ven tho!gh all the filters 'transformation components( in a pipeline have the same interface, some filters
f!nction independently and do not depend on other filters, 8or e&ample, a filter may be !sed to transform data
245450494.doc 228 od 257
or to filter for a cons!ming service, +n contrast, some filters inherently depend on other filters, 8or e&ample, in
some cases a message cannot be decoded by a filter !ntil it has been encoded by another filter first, To make it
easier to manage the semantic dependencies between filters, 1i9Talk Server 3445 defines stages for each
pipeline, stage is the portion of a pipeline that is dedicated to a certain type of work, -ach available filter is
assigned to a specific stage of the pipeline, receive pipeline consists of the following stages:
Decode
Disassemble
:alidate
%esolve Party
send pipeline contains the following stages:
Pre<ssemble
ssemble
-ncode
.at!rally, decoding the message is the first step that is performed in the receive pipeline, and encoding is the
last step that is performed in the send pipeline, This design ens!res that all other filters in the pipeline can work
on messages that are not encoded,
1i9Talk Server 3445 s!pplies defa!lt pipelines for fre?!ently rec!rring needs, s!ch as parsing an incoming QML
message, +f yo! need a more tailored f!nctionality, yo! have the following options:
Ho! can config!re a c!stom pipeline by !sing the pipeline components 'also known as filters( that are
s!pplied in 1i9Talk Server 3445,
Ho! can config!re a c!stom pipeline by writing c!stom filters in /S or Microsoft :is!al 1asic ,.-T,
This pattern foc!ses on the first option beca!se the standard 1i9Talk Server 3445 pipeline components provide
the f!nctionality that is re?!ired for the "lobal 1ank scenario witho!t any c!stom coding, To assemble a c!stom
pipeline that !ses the pipeline components that are incl!ded in 1i9Talk Server 3445, yo! have to complete the
following steps:
6, Create a custom send pipeline,
8irst, yo! have to define a new pipeline, pipeline definition is stored as a separate proEect file in
Microsoft :is!al St!dio ,.-T,
3, Assign and con&igure the &ilters,
The Pipeline Designer in 1i9Talk Server 3445 enables yo! to drag filters into the new pipeline, Ho! can
config!re each filter by !sing the properties editor,
;, #uild and deploy the pipeline,
245450494.doc 229 od 257
Pipeline definitions are compiled into a ,.-T 8ramework assembly, 1efore yo! can config!re a send
port or a receive port by !sing the c!stom pipeline definition, yo! have to deploy the assembly,
5, Assign a certi&icate to #i>Tal- Ser7er !<<',
This step is needed beca!se the b!siness re?!irement incl!des signing the o!tbo!nd message with a
certificate, S!ch a certificate is !s!ally obtained from an o!tside certificate a!thority and is loaded into
the certificate store of the local operating system, fter the certificate is loaded, the certificate
t"um%print has to be entered into the 1i9Talk dministration console, The th!mbprint is a !ni?!e
identifier,
8or a detailed description of certificates, see @/ertificate Stores@ in 2indows =P Professional Product
&ocumentation LMicrosoft45N,
A, Con&igure the send port to use the custom pipeline,
fter the c!stom pipeline is deployed, yo! can reference the c!stom pipeline in the config!ration
settings of a send port,
5.ample
To make the comm!nication on "lobal 1ankJs e&ternal payment channel sec!re, yo! m!st create a c!stom send
pipeline that signs and encrypts the o!tbo!nd messages, This pipeline is !sed in conE!nction with the Message
)ro'er described in +mplementing Message 1roker with 1i9Talk Server 3445,
1ased on the implementation strategy, yo! have to complete the following steps to implement the new c!stom
pipeline by !sing 1i9Talk Server 3445,
Step 1 Create a Custom Send Pipeline
Pipeline definitions are created in :is!al St!dio ,.-T and are compiled into a,.-T 8ramework assembly by !sing
the Pipeline Designer, 8irst, create a new 1i9Talk Server 3445 sol!tion in :is!al St!dio ,.-T, .e&t, select Send
Pipeline in the item list, and then add it to the sol!tion, This opens the Pipeline Designer,
Step ! Assign and Con&igure the /ilters
+n this step, yo! !se the Pipeline Designer to drag predefined filter components from the Toolbo. into the
pipeline, as shown in 8ig!re ;,
245450494.doc 230 od 257
/igure $1 #i>Tal- Ser7er !<<' Pipeline Designer and Toolbo.
send pipeline has three predefined stages: Pre<ssemble, ssemble, and -ncode, The "lobal 1ank sol!tion
re?!ires only the ssemble and -ncode stages, so leave the Pre<ssemble stage empty, The ssemble stage
contains filters that convert message data from the 1i9Talk Server 3445 internal format to an e&ternal format,
s!ch as a flat file str!ct!re or an QML doc!ment, 1eca!se yo! want to send QML messages to the e&ternal bank
payment system, add the QML assembler filter to this stage, Ho! can !se the defa!lt config!ration for this filter,
The encryption and signing occ!rs in the -ncode stage, This stage is the last stage, dd a M+M->SM+M- encoder
filter to this stage so that yo! can config!re the encryption properties, /onfig!re the properties as shown in
Table 6,
Table 1 Properties &or the 2I25BS2I25 5ncoder /ilter
Property 8alue
-nable encryption Tr!e
-ncryption algorithm D-S;
dd signing certification to message Tr!e
Signat!re type 1lobSign
The filter has b!ilt<in capability for D-S; and enables yo! to sign the message simply by selecting True for the
Add signing certi&ication to message property, The #lobSign val!e means that a signat!re is appended to
245450494.doc 231 od 257
the message and that the signat!re is encoded, *hen a message passes thro!gh this pipeline, the
M+M->SM+M- encoder !ses the certificate to sign the message,
Step $ #uild and Deploy the Pipeline
Save the pipeline definition, Then, b!ild and deploy the proEect from :is!al St!dio ,.-T to make the pipeline
definition available for port config!ration,
Step ' Assign Certi&icates to #i>Tal- Ser7er !<<'
1i9Talk Server 3445 !ses two distinct certificate stores in this scenario, certificate store is the system area
where certificates are stored, To sign o!tgoing doc!ments, 1i9Talk Server 3445 !ses certificates from the
Personal certificate store, 8or a detailed description of how to import certificates, see @/ertificate Stores@ in
2indows =P Professional Product &ocumentation LMicrosoft45N, -ach certificate has a th!mbprint that is
generated by r!nning a hash algorithm across the p!blic key portion of the certificate,
8irst, view the th!mbprint on the Details tab in the Certi&icate dialog bo& for the certificate, as shown in
8ig!re 5,
/igure '1 A certi&icate thumbprint
245450494.doc 232 od 257
.e&t, config!re the server r!nning 1i9Talk Server 3445 with the certificate th!mbprint, To do so, start the
1i9Talk dministration console, Then, config!re the signing certificate th!mbprint on the General tab in the
2icroso&t #i>Tal- Ser7er !<<' ?%ocal@ Properties dialog bo&, as shown in 8ig!re A,
/igure (1 #i>Tal- Ser7er !<<' properties
$se the same certificate to sign o!tgoing messages for all servers in the 1i9Talk Server 3445 gro!p,
To encrypt o!tgoing messages, 1i9Talk Server 3445 !ses the Local Machine\=ther People certificate store, This
certificate store holds p!blic key certificates, M!ltiple certificates can be stored and then !sed to encrypt
messages to specific parties, The certificate !sed to encrypt the message is specified in the send port
config!ration,
Step ( Con&igure the Send Port to "se the Custom Pipeline
.ow that the c!stom pipeline definition is deployed in a global assembly, yo! can !se it in the config!ration of
the send port, as shown in 8ig!re P,
245450494.doc 233 od 257
/igure )1 #i>Tal- Ser7er !<<' send port properties
Ho! can now connect the new send port to the Message1o& database as described in +mplementing Message
1roker with 1i9Talk Server 3445,
Resulting Conte.t
$sing Pipes and Filters with 1i9Talk Server 3445 res!lts in the following benefits and liabilities:
#ene&its
/ilter reuse, 1i9Talk Server 3445 !sers can re!se both the pipeline definitions and the set of pipeline
filters across different ports, 8or e&ample, the M+M->SM+M- encoder filter is s!itable for any application
that needs to send M+M- or S>M+M- messages,
Amenable &or graphical tools, Programming the pipeline involves connecting and config!ring filters
by dragging components rather than by writing so!rce code,
De7eloper speciali>ation, Pipes and Filters fosters the division of labor between different types of
!sers, 8or e&ample, /S developers b!ild filters by !sing the Microsoft Small 1!siness /!stomer Manager
8ilter SD0, 1!siness !sers and developers who !se 1i9Talk Server 3445 can assemble them witho!t any
programming,
%iabilities
Restricts the &ilter types, 1i9Talk Server 3445 pipelines !se filters that have a single inp!t and a
single o!tp!t, This implementation of Pipes and Filters cannot accommodate filters that do not fit within
this constraint,
=7erhead cost, 1i9Talk Server 3445 pipelines are very powerf!l when there are b!siness r!les and
other types of processes on the data, )owever, the b!siness r!les and processes on the data are overhead
if all that is re?!ired is a simple pipe between applications,
Testing Considerations
245450494.doc 234 od 257
There are two main test scenarios when yo! !se 1i9Talk Server 3445 to implement Pipes and Filters. The test
scenario that applies to yo! depends on the c!stomi9ation option that yo! choose as yo!r implementation
strategy:
Con&igure a custom pipeline by using the &ilters that are supplied with #i>Tal- Ser7er !<<',
+n this case, yo! b!ild the c!stom pipeline and config!re the filters by !sing the Pipeline Designer, Ho! then
create a test config!ration that !ses this c!stom pipeline in either a receive port or a send port, Ho! can
then s!bmit test messages and validate the res!lting o!tp!t,
Con&igure a custom pipeline by writing custom &ilters in CK or 8isual #asic 1,5T, +n this case,
yo! can test the pipeline component by creating a test config!ration that !ses the component in a c!stom
pipeline as described earlier, Ho! can also !se Microsoft :is!al St!dio ,.-T to review the pipeline
component code,
Security Considerations
+n addition to sec!rity feat!res that are provided by the transports, s!ch as encryption when !sing )TTPS,
1i9Talk Server 3445 provides sec!rity at the message level, 1i9Talk Server 3445 can receive decrypted
messages and validate digital signat!res that are attached to these messages, Similarly, 1i9Talk Server 3445
can encrypt messages and attach digital signat!res to messages before sending them, Ho! can also p!rchase or
develop c!stom sec!rity components as re?!ired,
,ote The 1i9Talk Server 3445 host instance r!ns the send pipelines and the receive pipelines within a specific
sec!rity conte&t, Therefore, any processing that the pipeline components perform operates within this sec!rity
conte&t, This sec!rity conte&t may impose constraints on the way that the c!stom component accesses a
database, The sec!rity conte&t may also impose constraints on the location in the certificate store that the
component can access a digital signat!re from,
=perational Considerations
1i9Talk Server 3445 provides e&tensive s!pport for application monitoring, $sers can monitor the messages
that are going thro!gh each pipeline, $sers can therefore also monitor the ports the pipeline !ses, 1i9Talk
Server 3445 !sers can config!re each send port or receive port to track messages, as shown in 8ig!re O,
245450494.doc 235 od 257
/igure *1 #i>Tal- Ser7er !<<' port4le7el trac-ing
The )ealth and ctivity Tracker ')T( tool in 1i9Talk Server 3445 provides access to port<level tracking
information that allows yo! to see what is happening in the system, +t also allows yo! to e&amine archived data
for patterns or trends,
Ac-nowledgments
LMicrosoft45N Microsoft /orporation, @/ertificate Stores,@ 2indows =P Professional Product &ocumentation,
vailable from Microsoft,com at
http:>>www,microsoft,com>reso!rces>doc!mentation>windows>&p>all>proddocs>en<!s>sagTcm!ncertstor,msp&,
Gateway

Integration Patterns
Contents
/onte&t
Problem
8orces
245450494.doc 236 od 257
Sol!tion
-&ample
%es!lting /onte&t
Testing /onsiderations
Sec!rity /onsiderations
=perational /onsiderations
%elated Patterns
cknowledgments
Conte.t
Ho! have an integration sol!tion that consists of several applications that are provided by different vendors and
that r!n on a variety of platforms, Some applications !se an e&ternal reso!rce and therefore have to
comm!nicate with it,
8or e&ample, consider the software that ins!rance carriers !se to rate ins!rance policies, ltho!gh many
carriers have !pgraded to client<server or service<oriented architect!res, some still rely on mainframe code for
lines of b!siness and for E!risdictions where the !pgrade is not feasible, 8or e&ample, ?!oting !ses mainframe
rating code to ?!ote premi!ms, -ndorsing !ses the mainframe rating code to endorse policies, %enewal also
!ses the mainframe rating code to renew policies, +n other words, several applications m!st integrate with the
mainframe code,
Problem
)ow can yo! make the applications of an integration sol!tion access an e&ternal system witho!t introd!cing
many<to<one co!pling between the applications and the e&ternal systemC
/orces
ccessing an e&ternal reso!rce from an integration sol!tion involves balancing the following forces:
ll applications that comm!nicate directly with the e&ternal reso!rce m!st have intimate knowledge of
comm!nication details s!ch as application protocols, messaging protocols, and comm!nication protocols,
-ach connection to the e&ternal reso!rce adds dependencies between the integration sol!tion and the
reso!rce,
The e&ternal reso!rce may !se a different comm!nication protocol than the comm!nication protocol
that the applications s!pport natively, +mplementing comm!nication protocols and protocol translators is
diffic!lt and error<prone,
Testing the integration sol!tion involves both the e&ternal reso!rce and the internal applications,
)owever, beca!se the e&ternal reso!rce may not be accessible from the testing environment, it may not be
245450494.doc 237 od 257
possible to involve the e&ternal reso!rce in tests, lso, incl!ding the e&ternal reso!rce in tests may prevent
testing error or bo!ndary conditions,
Solution
dd a Gateway component that abstracts the access to the e&ternal reso!rce, The gateway presents a single
interface to the integrated applications while hiding the e&ternal reso!rce interface, +n addition, the gateway
encaps!lates any protocol translation that may be necessary to comm!nicate with the e&ternal reso!rce,
8ig!re 6 shows the gateway replacing direct access to the e&ternal reso!rce, The applications that collaborate
with the gateway and with the e&ternal reso!rce are highlighted in bl!e, and the shapes at the end of the
connectors denote different interfaces,
/igure 11 Gateway abstracting access to the e.ternal resource
The applications that need to comm!nicate with the e&ternal reso!rce do so by sending messages to the
gateway interface, The gateway handles any protocol translation that is needed and then passes the message
to the e&ternal reso!rce, +n effect, the gateway encaps!lates all access to the e&ternal reso!rce, /onse?!ently,
the applications do not re?!ire information abo!t what it takes to comm!nicate with the e&ternal reso!rce,
The gateway also catches errors signaled by the e&ternal reso!rce, The gateway may be able to handle errors
s!ch as comm!nication timeo!ts and retries internally, =therwise, it passes any errors that it cannot handle
locally to the appropriate application, +n effect, the gateway centrali9es some error processing, b!t it probably
does not centrali9e all that error processing, This frees applications from dealing with these errors, Moving the
error handling logic from applications to the gateway g!arantees consistency,
The comm!nication thro!gh the gateway is asymmetric, The control flows from the applications to the e&ternal
reso!rce, +n other words, the gateway only provides a point thro!gh which applications call the e&ternal
reso!rce, The gateway does not s!pport inbo!nd access to the applications, Table 6 shows the responsibilities
and collaborations of the gateway,
Table 1 Gateway Responsibilities and Collaborations
245450494.doc 238 od 257
Responsibilities Collaborations
GTo provide an internal interface thro!gh which the
applications access the e&ternal reso!rce,
Gpplications send re?!ests addressed to the e&ternal
reso!rce,
GTo perform message transformations 'if any(, G-&ternal reso!rce f!lfills re?!ests coming from the
applications,
GTo relay the message to the e&ternal reso!rce and to
ret!rn the reply message to the sending application 'if
there is a reply message(,

GTo handle errors signaled by the e&ternal reso!rce or
to pass them to the appropriate component,

fter yo! decide to !se a gateway, yo! have to decide where the gateway will reside, The following are two
possibilities:
Internal gateway &or enterprise integration, n internal gateway resides in the same E!risdiction
as the applications, Therefore, e&ternal applications do not !se the gateway, and yo! have f!ll control over
it,
5.ternal gateway &or business4to4business ?#!#@ integration, n e&ternal gateway serves other
enterprise applications, n e&ternal gateway may even be provided by a third party, s!ch as the reso!rce
owner, This config!ration, which is shown in 8ig!re 3, means that yo! no longer have to implement the
gateway, )owever, !sing an e&ternal gateway adds a dependency on an o!tside component,
/igure !1 An e.ternal gateway that resides outside system boundaries ?#!# integration@
n internal gateway provides the most fle&ible sol!tion, Ho! make the decisions abo!t its interface, abo!t the
protocol translations it performs, and abo!t the errors it handles, +f yo! have an e&ternal gateway, and yo!
want to red!ce the co!pling with it, yo! can !se an internal gateway and regard the e&ternal gateway as the
reso!rce, This config!ration is known as gateway c"aining, 8ig!re ; ill!strates this config!ration,
245450494.doc 239 od 257
/igure $1 Gateway chaining remo7ing dependencies between applications and an e.ternal gateway
"ateway chaining translates into f!nctional composition, +f yo! have several gateways, and each gateway is
speciali9ed to handle a different aspect s!ch as protocol translation or encryption, yo! can chain them together
to create a composite gateway that handles each aspect se?!entially, /haining gateways might be complicated
if the gateways make conflicting ass!mptions abo!t tasks in the environment s!ch as error handling,
5.ample
/onsider a property and cas!alty system where separate applications implement policy management, general
ledger, acco!nts payable, billing, and claims f!nctionalities, The policy management, the claims, and the billing
applications connect thro!gh sockets to an e&ternal print system to print policies, claims, and statements, This
config!ration is ill!strated in 8ig!re 5,
/igure '1 Property and casualty system without a gateway
245450494.doc 240 od 257
+n 8ig!re 5, the billing, claims, and policy management applications access the print system directly, The ro!nd
connectors denote a socket<based interface, Print system !pgrades, s!ch as replacing the socket<based
interface with a *eb service interface, re?!ire !pgrading three systems: the policy management system, the
claims system, and the billing system, These changes are e&pensive, dditionally, if the print system belongs to
a different organi9ation, the owners of the property and cas!alty system cannot control the timing of the
!pgrade, n !pgrade d!ring the peak renewal season wo!ld have a negative impact on the b!siness,
8ig!re A shows the property and cas!alty system modified to !se a gateway, The billing, claims, and policy
management applications no longer access the print system directly, +nstead, the billing, claims, and policy
management applications access the print system thro!gh a gateway, The ro!nd connectors denote a socket<
based interface, and the s?!are connectors denote a *eb services<based interface, This config!ration red!ces
the costs that are associated with a print system !pgrade,
/igure (1 Property and casualty system with a gateway
Resulting Conte.t
$sing a gateway to provide a single point of access to an e&ternal reso!rce has the following benefits and
liabilities:
#ene&its
%ed!ced co!pling1 The gateway encaps!lates access to the e&ternal reso!rce, pplications that !se the
reso!rce no longer re?!ire information abo!t how to access that e&ternal reso!rce,
%ed!ced application comple&ity, +ndivid!al applications do not have to implement the comm!nication
protocols re?!ired to comm!nicate with the e&ternal reso!rce, +n addition, the gateway can implement
some of the error handling that each application wo!ld otherwise have to perform,
+mproved integrability, The gateway provides a single point of access for the e&ternal reso!rce, This
facilitates integration with e&ternal reso!rces s!ch as an -nterprise %eso!rce Planning '-%P( system, a
/!stomer %elationship Management '/%M( system, or another similar system,
+mproved sec!rity, single point of access represents a single point of control, Ho! can !se this single
point of access to implement sec!rity policies and to bridge between different sec!rity realms, +t also
allows yo! to meter access to the e&ternal reso!rce and to implement b!siness r!les that control access,
245450494.doc 241 od 257
+mproved performance thro!gh optimi9ation, The gateway provides a logical place to optimi9e the
comm!nication protocol for !se with the e&ternal reso!rce, =ptimi9ation might incl!de batching similar
re?!ests or caching res!lts,
%iabilities
%ed!ced performance thro!gh overhead, The gateway replaces direct comm!nication, adding an
intermediate layer, This translates into increased latency compared to direct comm!nication,
Increased maintainability e&&ort, gateway e&tends yo!r integration sol!tion with another
component, This translates into additional implementation, config!ration, testing, deployment, and
management work,
Dependency o& the gateway inter&ace, Designing the gateway re?!ires foresight abo!t the
interactions between the applications and the e&ternal reso!rce, +f yo! have to change the gatewayJs
interface in a way that breaks compatibility, yo! have to change all the applications that access it,
%ed!ced availability, ll access to the e&ternal reso!rce passes thro!gh the gateway, 8rom an
availability perspective, the gateway represents a single point of fail!re,
Testing Considerations
$sing a gateway improves testability on both sides in the following ways:
pplications access the e&ternal reso!rce solely thro!gh the gateway, mock gateway can receive
messages, ret!rn predefined responses, and e&ercise error handling logic, +n other words, yo! can test the
system witho!t accessing the e&ternal reso!rce,
1eca!se the e&ternal reso!rce receives re?!ests from the gateway, yo! can test the gateway by
relaying re?!ests to the e&ternal reso!rce independent of the applications,
8ig!re P shows these test areas, The top diagram shows a mock gateway for testing the interaction with the
applications, The bottom diagram shows a mock gateway for testing the interaction with the e&ternal reso!rces,
The shaded arrows indicate the test areas,
/igure )1 "sing a moc- gateway &or testing
245450494.doc 242 od 257
gateway also facilitates load testing, Testers can !se the gateway to insert test loads into the integration
sol!tion to meas!re the e&ternal reso!rceJs performance,
Security Considerations
ccessing an e&ternal reso!rce thro!gh a gateway has the following sec!rity implications:
single point of access facilitates enforcement of a !niform sec!rity policy, )owever, it also represents
a central point of attack,
gateway allows bridging between different sec!rity realms, 8or e&ample, a gateway can mi& different
sec!rity conte&t management policies, s!ch as impersonation on one side and consolidation on the other,
)owever, the gateway only provides a place where the mapping between the two can be handled, Ho!
m!st implement the mapping separately,
=perational Considerations
gateway represents a single point of access and may ca!se contention among the applications that
comm!nicate with the e&ternal reso!rce, Ho! sho!ld monitor access to the e&ternal reso!rce and act
proactively when the first signs of contention appear, This single point of access also helps yo! to meter access
to the e&ternal reso!rce, to monitor the e&ternal reso!rce, and to a!dit the e&ternal reso!rce,
Related Patterns
The Gateway pattern described here relates to the following patterns:
+mplementing "ateway with )ost +ntegration Server 3445 This pattern !ses the "lobal 1ank scenario
to show how yo! can !se )ost +ntegration Server 3445 to implement Gateway,
Gateway L8owler4;N, Martin 8owler disc!sses Gateway in the conte&t of enterprise applications, )e
also covers the relationship with FaFade and $dapter L"ammaMAN, 8owlerJs Gateway is fine<grained at the
obEect level, )owever, in the conte&t of integration, Gateway is coarse<grained at the platform level,
Messaging Gateway L)ohpe45N, Messaging Gateway wraps message<specific method calls, e&poses
domain<specific methods, and encaps!lates access to the messaging system, )ohpe and *oolf also e&plain
how to create composite gateways by !sing gateway chaining, composite gateway permits yo! to !se a
gateway that encaps!lates a single aspect together with other gateways to deal with several aspects,
/emote Pro:y L1!schmannMPN. Gateway can be regarded as a refinement of the /emote Pro:y
pattern, /emote Pro:y deals with distrib!ted components in the general sense and provides the
interprocess comm!nication '+P/( mechanisms for comm!nication with remote obEects, Gateway is
designed for integration sol!tions and therefore ass!mes that the integration infrastr!ct!re is available,
Service +nterface LTrowbridge4;N, Ser!ice Interface e&poses f!nctionality as a service and provides an
entry point for inbo!nd re?!ests, +n effect, the control flows in the opposite direction compared to
Gateway,
Ac-nowledgments
L1!schmannMPN 1!schmann, 8rank# %egine Me!nier, )ans %ohnert, Peter Sommerlad, and Michael Stal,
Pattern-riented Software $rc"itecture0 <olume ;1 $ System of Patterns. 2ohn *iley & Sons Ltd, 6MMP,
L8owler4;N 8owler, Martin, Patterns of Enterprise $pplication $rc"itecture, ddison<*esley, 344;,
L"ammaMAN "amma, -rich# %ichard )elm, %alph 2ohnson, and 2ohn :lissides, &esign Patterns1 Elements of
/eusa%le -%8ect-riented Software, ddison<*esley, 6MMA,
245450494.doc 243 od 257
L)ohpe45N )ohpe, "regor, and 1obby *oolf, Enterprise Integration Patterns1 &esigning0 )uilding0 and
&eploying Messaging Solutions, ddison<*esley, 3445,
LTrowbridge4;N Trowbridge, David# Dave Mancini, Dave B!ick, "regor )ohpe, 2ames .ewkirk, and David
Lavigne, Enterprise Solution Patterns Using Microsoft .NET, Microsoft Press, 344;, lso available on the MS&N
$rc"itecture (enter at: http:>>msdn,microsoft,com>architect!re>patterns>defa!lt,asp&Cp!llV>library>en<
!s>dnpatterns>html>-sp,asp,
Implementing Gateway with 3ost Integration Ser7er !<<'

Integration Patterns
Contents
/onte&t
1ackgro!nd
+mplementation Strategy
-&ample
%es!lting /onte&t
Tests
Conte.t
Most medi!m<si9ed to large<si9ed organi9ations rely on a distrib!ted environment where b!siness logic
operates on many different comp!ting technologies, To the dismay of the software developers in these
organi9ations, two of the most commonly !sed technologies can be diffic!lt to integrate, These technologies are
the Microsoft ,.-T 8ramework and the +1M /!stomer +nformation /ontrol System '/+/S( application
s!bsystem, +mplementing the "ateway pattern allows developers to overcome incompatibility iss!es by
integrating e&isting mainframe b!siness logic into ,.-T 8ramework applications witho!t having to redevelop the
code that already e&ists in /+/S,
Ho! have decided to implement the Gateway pattern by !sing Microsoft )ost +ntegration Server 3445 and its
Transaction +ntegrator 'T+( feat!re to enable ,.-T 8ramework applications to invoke mainframe transactions, to
pass the proper inp!t parameters to the transactions, and to finally receive the o!tp!t parameters that are
ret!rned from the e&ec!ting transactions,
245450494.doc 244 od 257
#ac-ground
The "lobal 1ank infrastr!ct!re integrates applications that r!n on several platforms, The acco!nt management
system r!ns on a mainframe, cco!nt management operations s!ch as /reate cco!nt, /heck 1alance and
Debit, /redit cco!nt, Delete cco!nt, and "et cco!nt +nformation are implemented as /+/S transactions, The
integration sol!tion m!st be capable of e&ec!ting these transactions from the Microsoft *indows operating
system, "lobal 1ank decided to !se Microsoft )ost +ntegration Server 3445 and its Transaction +ntegrator 'T+(
feat!re as a Gateway implementation to invoke the individ!al /+/S transactions incl!ded in the mainframe
acco!nt management system, $sing T+ to call mainframe programs from a ,.-T 8ramework application is
known as 2indowsinitiated processing,
8ig!re 6 depicts a high<level view of this config!ration,
/igure 11 Global #an- implementation o& Gateway
ltho!gh it does not apply in the case of "lobal 1ank, a mainframe application developer can also !se T+ to
access ,.-T 8ramework applications from a mainframe application, $sing T+ in this manner is known as "ost
initiated processing,
,ote The T+ feat!re of )ost +ntegration Server 3445 was named /=M Transaction +ntegrator for /+/S and +MS
'/=MT+( in previo!s releases of Microsoft )ost +ntegration Server,
Implementation Strategy
$sing )ost +ntegration Server 3445 to implement Gateway typically re?!ires the e&pertise of many different
people, incl!ding a ,.-T 8ramework developer, a Microsoft network infrastr!ct!re engineer, a mainframe /+/S
developer, and a mainframe systems administrator, E!st to name a few, +t is important for all personnel involved
to clearly !nderstand the )ost +ntegration Server 3445 components and the implementation steps that are
re?!ired to s!ccessf!lly deploy this Gateway implementation,
245450494.doc 245 od 257
)ost +ntegration Server 3445 incl!des the following components that are re?!ired to access mainframe /+/S
transactions:
TI 2anager, T+ Manager is the administrative component that allows developers to config!re T+
options, +n a *indows<initiated processing scenario, these options incl!de config!ring the mainframe
transactionJs operating environment, This operating environment is known as the remote en!ironment,
These options also incl!de config!ring *indows<initiated processing obEects that are !sed to associate the
metadata file with the remote environment, The metadata file is addressed later in this pattern,
TI Designer, T+ Designer is a Microsoft :is!al St!dio ,.-T pl!g<in that developers can !se to b!ild T+
client obEects, T+ client obEects are !sed to specify the methods to invoke on the mainframe transactions
and to specify the inp!t and o!tp!t parameters to !se with those methods,
TI run4time component, The T+ r!n<time component intercepts the method calls to and from the
mainframe and !ses the information in the T+ metadata file to perform the act!al conversion and
formatting of the method parameters,
1eca!se the implementation strategy relies primarily on the T+ feat!re of )ost +ntegration Server 3445, most of
the strategy involves config!ring T+, To properly config!re T+, follow these steps:
11 Select the TI programming model, T+ programming model determines the method !sed to access
and to integrate host transactions, Ho! m!st determine which of the eleven available programming
models yo! need to !se to access the transactions,
!1 Con&igure the main&rame en7ironment, -ns!re that the mainframe environment is properly
config!red to allow access by T+,
$1 Con&igure the TI metadata &ile, The T+ metadata file defines the methods, parameters, and data
type mappings that are !sed when mainframe transactions are invoked,
'1 Con&igure networ- protocol connecti7ity, Ho! m!st implement the appropriate network protocol to
provide network comm!nications between T+ and the mainframe, Ho! can !se Systems .etwork
rchitect!re 'S.( Logical $nit P,3 'L$ P,3( or Transmission /ontrol Protocol>+nternet Protocol
'T/P>+P(,
(1 Con&igure a TI remote en7ironment, remote environment is a collection of properties that
describes a region on the mainframe, Ho! m!st config!re a remote environment,
)1 Add a 2icroso&t Internet In&ormation Ser7ices ?IIS@ 7irtual directory, This virt!al directory is
the virt!al directory where the T+ re?!est is processed, The virt!al directory is !sed to store the
*indows<initiated processing obEect that yo! config!re in the ne&t step,
*1 Con&igure a Windows4initiated processing ob+ect, *indows<initiated processing obEect
establishes a relationship between the metadata file, the ++S virt!al directory, and the remote
environment, Ho! m!st config!re a *indows<initiated processing obEect,
91 Implement a 1,5T /ramewor- client application to in7o-e the TI client inter&aces, 8inally,
after all the T+<specific config!ration is finished, yo! m!st implement the ,.-T 8ramework applications
that !se T+ to invoke the mainframe transactions,
The following paragraphs describe these implementation steps in greater detail,
Step 1 Select the Programming 2odel
T+ programming model determines the method !sed to access host transactions and the T+ config!ration
re?!irements, Ho! m!st coordinate with the mainframe /+/S developer and with the mainframe systems
administrator to select the appropriate programming model,
The first decision to make when selecting a T+ programming model is to determine which of the three s!pported
transactionsI/+/S, +nformation Management System '+MS(, or S>544Iis being accessed, T+ s!pports eleven
programming models, Si& of these models are !sed to access the /+/S mainframe transactions that are the
s!bEect of this implementation, The si& programming models !sed to access /+/S transactions are the
following:
245450494.doc 246 od 257
L$ P,3 Link
L$ P,3 $ser Data
T/P>+P -nhanced Listener Mode '-LM( Link
T/P>+P -LM $ser Data
T/P>+P Transaction %e?!est Message 'T%M( Link
T/P>+P T%M $ser Data
The other five models are !sed for accessing +MS transactions or =S>544 transactions, They are not disc!ssed
here,
The ne&t critical decision in selecting the programming model is to choose the network protocol to !se, T+ can
!se either the T/P>+P network protocol or the L$ P,3 network protocol to comm!nicate between the mainframe
environment and the ,.-T 8ramework environment, L$ P,3 is the recommended protocol to !se with T+ for the
following reasons:
/+/S transactions r!n more efficiently in an L$ P,3 environment than they do in a T/P>+P environment,
/+/S transactions r!n more efficiently beca!se of the costly task<swapping techni?!es that /+/S employs
for e&ec!ting transaction programs initiated by T/P>+P,
+t is easier to config!re L$ P,3 on the mainframe than it is to config!re T/P>+P,
The L$ P,3 protocol s!pports two<phase commit transactions# the two<phase commit protocol is
re?!ired to allow transactions to e&ec!te in a distrib!ted environment across m!ltiple systems, Two<phase
commit transactions are only s!pported when the T+ metadata file 'addressed later in this pattern( is
config!red to !se a /omponent =bEect Model '/=M( type library,
L$ P,3 s!pports the +1M Parallel Sysple& technology for network red!ndancy, Parallel Sysple& provides
a mechanism that allows mainframe sessions to be reestablished a!tomatically across a different ro!te
when an established ro!te is interr!pted,
Ho! can !se L$ P,3 over an e&isting T/P>+P network as long as the -nterprise -&tender is deployed on
the mainframe, The -nterprise -&tender is a feat!re of +1M mainframes that s!pports r!nning L$ P,3 over
the T/P>+P protocol, This config!ration also s!pports two<phase commit transactions when !sing /=M type
libraries,
The two programming models that s!pport the L$ P,3 protocol are L$ P,3 Link and L$ P,3 $ser Data, The key
difference between these two programming models is how each handles data comm!nications between T+ and
the /+/S transactions, The L$ P,3 Link is the only one of the two models that !ses the /=MM%-, The
/=MM%- is a feat!re of /+/S that allows /=1=L transactions to pass data between them witho!t re?!iring
developers to incorporate the data comm!nication logic into their code, +np!t and o!tp!t parameters are easily
passed in and o!t of the /=MM%-, *hen the /=MM%- is not in !se, all data e&changed between
transactions m!st be e&plicitly handled in the transaction code, 1eca!se many of the e&isting /+/S transactions
that are deployed in mainframe prod!ction environments are already coded to !se the /=MM%-, !sing the
/=MM%- is the simplest way for a T+ developer to access /+/S transactions, Therefore, L$ P,3 Link is the
recommended programming model for !sing T+ to access /+/S transactions,
,ote +f the e&isting /+/S transactions are not coded to !se the /=MM%-, or if they contain code that is
!sed for something other than for processing b!siness logic, the /+/S developer m!st modify the transaction
code to !se the /=MM%-, The /=MM%- limits the amo!nt of data that can be passed in and o!t of
invoked transactions to ;3 kilobytes '01(,
245450494.doc 247 od 257
%" )1! %in- 2odel Components
The L$ P,3 Link model relies on a n!mber of critical r!n<time components that s!pport its f!nctionality, 8ig!re 3
depicts the T+ r!n<time environment and components for the L$ P,3 Link programming model, 8ollowing the
fig!re are descriptions of each of these components,
/igure !1 TI run4time en7ironment &or the %" )1! %in- model
The L$ P,3 Link model !ses the following components, as shown in 8ig!re 3, to access mainframe transactions:
1,5T /ramewor- application, The ,.-T 8ramework application invokes the T+ client obEect for access
to mainframe transactions,
TI client ob+ect, The T+ client obEect contains the necessary data and logic re?!ired to comm!nicate
with the /+/S transactions,
TI run4time pro.y, The T+ r!n<time component is !sed to establish the connection between the T+
client obEect and the /+/S mainframe transaction at r!n time,
TI remote en7ironment, The T+ remote environment component is !sed to specify host connection
parameters s!ch as the network address, the sec!rity settings, and the comm!nications model to !se for
accessing host transactions,
245450494.doc 248 od 257
Distributed Program %in- ?DP%@ %" )1!, DPL is the protocol that T+ !ses to comm!nicate with
/SM+,
2irror TP CS2I, The mirror /+/S transaction is a special /+/S transaction that acts as a gateway
between transactions r!nning in different /+/S regions, The mirror transaction allows the transactions in
the different regions to e&change data thro!gh the /=MM%-, T+ takes advantage of this standard
method of comm!nication between /+/S transactions to access mainframe transactions, The /+/S
transaction +D for the mirror transaction is /SM+, /SM+ handles all L$ P,3 and transactional properties
re?!ired on the comm!nication,
C=22AR5A, The /=MM%- is an area of the mainframe transaction code that many /+/S
transactions that are written in /=1=L !se to e&change data, *hen !sing this model, T+ appears to the
mainframe transaction as a /+/S transaction that e&changes data thro!gh the /=MM%-,
CICS lin-4to4program, The /+/S link<to<program is the /+/S transaction that T+ invokes on behalf of
the client application, +t contains the b!siness logic being e&ec!ted and is identified by its link<to<program
name in the T+ method call,
D#!B8SA2, /+/S !s!ally !ses the +1M SBL database that is named D13 or the older :irt!al Storage
ccess Method ':SM( as the data storage mechanism for storing the data that is !sed by /+/S
transactions,
"sing a 2odel =ther Than %" )1! %in-
+f yo! cannot !se the recommended L$ P,3 Link model beca!se yo!r e&isting environment does not allow yo!
to !se it, yo! can select one of the other five models to access /+/S transactions:
%" )1! "ser Data, ltho!gh this model !ses the efficient L$ P,3 protocol, it does not !se the
/=MM%-, +t therefore is more comple& to implement, This model is best for sit!ations where the
mainframe transactions are not coded to !se the /=MM%- and where the transaction code does contain
comm!nication handling data and b!siness logic data, 1eca!se this model does not !se the /=MM%-, it
is not s!bEect to the ;3<01 /=MM%- limit, +nstead, it s!pports an !nlimited amo!nt of data,
TCPBIP 5nhanced %istener 2ode %in-, This model is similar to the L$ P,3 Link model beca!se it
!ses the /=MM%-, )owever, it !ses T/P>+P instead of L$ P,3, The model also employs the mainframeJs
-nhanced Listener Mode '-LM(, Ho! wo!ld !se this model when L$ P,3 is not config!red for access to the
mainframe and when /+/S transactions are coded to !se the /=MM%-,
TCPBIP Transaction Re0uest 2essage %in-, This model is similar to the T/P>+P -LM Link model,
The only difference is that it does not implement the -LM, -LM is preferred over Transaction %e?!est
Message 'T%M(# however, the newer -LM f!nctionality may not be implemented in older versions of /+/S,
TCPBIP 5%2 "ser Data, This model is similar to the L$ P,3 $ser Data model beca!se it does not !se
the /=MM%-, +t therefore is more comple& to implement, This model is best for sit!ations where
mainframe transactions are not coded to !se the /=1=L /=MM%- and where the mainframe only
s!pports T/P>+P access,
TCPBIP TR2 "ser Data, This model is similar to the T/P>+P -LM $ser Data model, The difference is
that it does not implement the -nhanced Listener Mode,
The remainder of this implementation foc!ses on the L$ P,3 Link model when programming models are
mentioned, 8or more information abo!t other programming models, see the )ost +ntegration Server 3445
prod!ct doc!mentation,
Step ! Con&igure the 2ain&rame 5n7ironment
Mainframes are often already config!red with everything that T+ re?!ires to gain access to the transactions,
beca!se most of what T+ re?!ires is !sed for internal integration between mainframe programs, The mainframe
systems programmer and the /+/S developer m!st make any changes that are re?!ired, ,.-T 8ramework
developers are rarely capable of performing s!ch config!rations themselves, The following are the minim!m
/+/S versions that m!st be installed on the mainframe to s!pport T+ in specific mainframe operating system
environments:
+1M /+/S for M:S version ; release ;, or later, to s!pport an S. L$ P,3 network connection
245450494.doc 249 od 257
+1M /+/S Transaction Server for :S->-S version 3 release 6, or later, to s!pport an S. L$ P,3
network connection
+1M /+/S Transaction Server for =S>;M4 version 6, or later, to s!pport an S. L$ P,3 or T/P>+P
network connection
+1M /+/S Transaction Server for 9>=S version 3, or later, to s!pport an S. L$ P,3 or T/P>+P network
connection
+1M /+/S Transaction Server for 9>=S version 3 release 3, or later, to s!pport -nhanced Listener Mode
for a T/P>+P network connection
8or more information abo!t how to properly config!re the mainframe for this or other programming models,
see the )ost +ntegration Server 3445 doc!mentation,
Determine I& Changes Are Re0uired to the 5.isting Transactions
+n some cases, /+/S transactions may re?!ire some modification before yo! can !se T+ to access them, +n the
case of the L$ P,3 Link model, transactions that are not coded to !se the /=MM%- m!st be modified by the
/+/S developer, dditionally, any embedded terminal<handling code m!st be removed before !sing T+ with L$
P,3 Link,
Step $ Con&igure the TI 2etadata /ile
The T+ metadata file is !sed to specify the methods, parameters, and data type mappings that are !sed when
mainframe transactions are invoked, Ho! m!st gather the pertinent information that is re?!ired to config!re the
file, This information is typically provided by the mainframe systems programmer, the mainframe /+/S
developer, and the ,.-T 8ramework developers who invoke the mainframe transactions,
The metadata file can be config!red as a /omponent =bEect Model '/=M( component library or as a ,.-T
8ramework client library by !sing the T+ Designer pl!g<in for :is!al St!dio ,.-T,
To con&igure the TI metadata &ile
6, Create a 8isual Studio 1,5T pro+ect, *hen yo! create the :is!al St!dio ,.-T proEect, choose 3IS
as the proEect type and TI Pro+ect as the template,
3, Add a 1,5T /ramewor- client library or a C=2 client library, Ho! !se either the dd ,.-T /lient
Library *i9ard or the dd /=M /lient Library *i9ard to add the client library, *hen !sing a wi9ard to
add either a ,.-T 8ramework client library or a /=M client library, yo! m!st specify the following
properties for the remote environment that this library will be associated with:
8endor, Specify the vendor for this remote environment, +n the "lobal 1ank scenario, the
vendor is Microsoft,
Protocol, Specify the protocol !sed to access the remote environment, This co!ld be either
T/P>+P or L$ P,3, +n this scenario, the protocol is L$ P,3,
Target 5n7ironment, Specify whether the target environment is /+/S, +MS, or S>544, +n
this scenario, the target environment is /+/S,
Programming 2odel, Specify the programming model to !se, +n this scenario, the
programming model is L$ P,3 Link,
;, De7elop the inter&ace methods, method in the T+ metadata file has a direct correlation to a /+/S
transaction program on the mainframe, Ho! m!st define a n!mber of method properties, =ne
important method property is Return Type, The Return Type property enables yo! to specify
whether the method has a ret!rn val!e and, if so, to specify the data type for the val!e, *hether a
method has a ret!rn val!e or not depends on the e&isting /=1=L program and on how yo! want to
handle the o!tp!t data, nother important method property is Tran ID, The Tran ID method property
enables yo! to specify the link<to<program name of the mainframe transaction, The link<to<program
name is how /+/S identifies this transaction in its tables, /+/S !ses this name to invoke the
transaction for e&ec!tion,
245450494.doc 250 od 257
5, Con&igure method parameters, Ho! m!st config!re the parameters for the method, The parameters
are the inp!t and o!tp!t val!es that the method !ses when comm!nicating with the mainframe
transaction, 1efore config!ring the parameters, yo! m!st identify the inp!t and o!tp!t parameters in
the e&isting /=1=L so!rce code, Ho! m!st then determine the data type to !se for each parameter,
Determining the TransactionDs %in-4to4Program ,ame
/+/S transactions are !s!ally invoked !sing their link<to<program name, Ho! m!st cons!lt with the mainframe
developer to obtain the names of the transactions that yo! want to invoke,
Importing C=#=% by "sing the C=#=% Import Wi>ard in TI Designer
Ho! can !se the /=1=L +mport *i9ard in the T+ Designer to import /=1=L so!rce code to config!re a method,
s yo! move thro!gh the pages of the wi9ard, yo! e&tract the data declarations specified in the /=MM%-,
The data declarations describe the inp!t that is sent to the mainframe transaction and the o!tp!t that is
received from the mainframe transaction, The wi9ard !ses the parameters specified in the /=MM%- and
ignores all other content in the so!rce file, *hen the wi9ard finishes, a new method is added to yo!r client
library, The method !ses the parameters specified in the so!rce fileJs /=MM%-,
Step ' Con&igure ,etwor- Protocol Connecti7ity
ss!ming that the physical network that connects the server r!nning )ost +ntegration Server 3445 T+ and the
mainframe is in place, the first step to establish connectivity is to config!re the protocol yo! are !sing to access
the mainframe, Ho! can !se either L$ P,3 or T/P>+P,
Con&iguring %" )1! Access
The L$ P,3 protocol is based on +1M Systems .etwork rchitect!re 'S.( < dvanced Program<to<Program
/omm!nications 'PP/( protocol for network comm!nications, *hen !sing L$ P,3 to access the host
applications, yo! m!st config!re )ost +ntegration Server 3445 for L$ P,3 access to the proper /+/S region,
ltho!gh a f!ll description of how to config!re )ost +ntegration Server 3445 for L$ P,3 access to the /+/S
region is not part of this pattern, it is important to know the following when config!ring L$ P,3 access:
The name of the local PP/ L$ that is config!red on )ost +ntegration Server 3445 for access to the
/+/S region corresponds to the independent L$ P,3 config!red on the :irt!al Telecomm!nications ccess
Method ':TM( P$ definition for that )ost +ntegration Server 3445 connection,
The name of the remote PP/ L$ config!red on the )ost +ntegration Server 3445 connection to the
mainframe corresponds to the PPL+D as config!red on the :TM PPL definition for the /+/S region,
The PP/ mode config!red for the L$ P,3 comm!nications m!st correspond to the mode config!red on
the :TM L$ definition for the local PP/ L$ and on the mode !sed by the PPL definition in :TM, The
PP/ mode typically specifies parameters s!ch as the n!mber of parallel sessions s!pported and the
comm!nication partner that is the contention winner,
,ote 8or more information abo!t the steps to config!re )ost +ntegration Server 3445 for L$ P,3 access to a
mainframe comp!ter, see the )ost +ntegration Server 3445 prod!ct doc!mentation,
Con&iguring TCPBIP Access to 2ain&rame Transactions
+f yo! are !sing T/P>+P, yo! m!st determine the T/P>+P address and the port n!mber to !se to access the
proper /+/S region, Ho! m!st specify the T/P>+P address of the mainframe yo! want to access and the port
n!mber of the /+/S region yo! want to access, T/P>+P port n!mber is associated with a /+/S region on the
mainframe, The port statement is !sed to define this relationship, The +1M<s!pplied /onc!rrent Listener
245450494.doc 251 od 257
'program -F/+/43, transaction +D /S0L( binds a socket to the port specified for a given /+/S region and then
waits for a client re?!est on that port, *hen a client makes a re?!est on a port associated with that /+/S
region, T/P>+P forwards the connection re?!est to the /onc!rrent Listener in that /+/S region,
Step ( Con&igure a Remote 5n7ironment
remote en!ironment is a collection of properties that describes a region on the mainframe, Ho! m!st
config!re a remote environment to specify the programming model to !se with a T+ component, to specify the
protocol !sed to access the mainframe, and to specify other connectivity properties, Ho! !se the %emote
-nvironment *i9ard in T+ Manager to create a remote environment,
The wi9ard allows yo! to specify val!es for the following properties:
Remote en7ironment name, Specify a name for this remote environment,
,etwor- protocol to use, Specify L$ P,3 or T/P>+P, +n this scenario, the protocol is L$ P,3,
Target host, Specify whether this remote environment is !sed to access /+/S, +MS, or =S>544
transactions, The target host is the name of the "lobal 1ank mainframe,
Programming model, Specify one of the eleven programming models to !se with this remote
environment, +n this scenario, the programming model is L$ P,3 Link,
%ocal %" alias, Specify the name of the local PP/ L$ that corresponds to the independent L$ P,3
config!red on the :TM P$ definition for the )ost +ntegration Server 3445 connection,
Remote APPC %" alias, The remote PP/ L$ corresponds to the PPL+D as config!red on the :TM
PPL definition for the /+/S region,
2ode name, The PP/ mode config!red for L$ P,3 comm!nications m!st correspond to the mode
config!red on the :TM L$ definition for the local PP/ L$, and it m!st correspond to the mode !sed by
the PPL definition in :TM,
,ote 8or specific instr!ctions on how to create a remote environment, see the )ost +ntegration Server 3445
prod!ct doc!mentation,
Step ) Add an IIS 8irtual Directory
The ++S virt!al directory is !sed to store the *indows<initiated processing obEect config!red in the following
step, This ++S virt!al directory is associated with *indows<initiated processing and with the remote
environment, The ++S virt!al directory is then made available to ,.-T 8ramework applications that !se this T+
config!ration to access mainframe transactions,
Step * Con&igure a Windows4Initiated Processing =b+ect
*indows<initiated processing obEect is !sed to establish a relationship between the metadata file developed
!sing the :is!al St!dio ,.-T T+ designer pl!g<in, the ++S virt!al directory, and the remote environment
config!red in the T+ manager,
The .ew *+P =bEect *i9ard allows yo! to specify val!es for the following properties:
Path, Specify the path to the metadata file yo! created in step ;,
/ile, Specify the name of the metadata file,
8irtual directory, Specify the virt!al directory where this obEect is stored,
Remote en7ironment, Specify the name of the remote environment,
245450494.doc 252 od 257
Step 9 Implement a 1,5T /ramewor- Client Application to In7o-e the TI Client
Inter&aces
t this point, T+ has been config!red to provide access to the /+/S mainframe transactions, ll that is left is to
develop the ,.-T 8ramework client application that invokes the mainframe transactions,
5.ample
The "lobal 1ank scenario disc!ssed in this pattern serves as a perfect e&ample of how to deploy T+ into
prod!ction, The following e&ample describes the specific f!nctions and config!rations that are re?!ired to meet
"lobal 1ankJs needs, The steps in the e&ample follow the same implementation strategy described earlier and
e&plain the decisions yo! wo!ld make along the way if yo! were act!ally deploying T+ into prod!ction,
"lobal 1ank needs a sol!tion that enables its ,.-T 8ramework applications to invoke b!siness logic that resides
on mainframe /+/S transactions, The /+/S transactions are !sed for handling typical banking operations, s!ch
as obtaining acco!nt balances and processing debits and credits, This e&ample ill!strates how the T+ *indows<
initiated processing feat!res can be implemented to meet "lobal 1ankJs re?!irements,
Components
To deploy T+ into prod!ction, the following components m!st be available:
)ost +ntegration Server 3445 with T+ installed
:is!al St!dio ,.-T with the T+ Designer pl!g<in installed
n SP,.-T *eb application !sed by bank staff to manage acco!nts
Mainframe /+/S transactions that can be !sed to implement the re?!ired acco!nt management
f!nctions
/unctions
The b!siness logic implemented in the /+/S transactions performs the following f!nctions:
+t creates acco!nts,
+t obtains acco!nt details,
+t obtains lists of acco!nts,
+t deposits f!nds into e&isting acco!nts,
+t withdraws f!nds from e&isting acco!nts,
This e&ample ill!strates how the f!nctionality c!rrently implemented in mainframe /+/S transactions can be
invoked for e&ec!tion from a ,.-T 8ramework application environment,
The following are the steps re?!ired for config!ring T+ for this e&ample,
Step 1 Select the Programming 2odel
245450494.doc 253 od 257
To access the mainframe applications for "lobal 1ank, yo! m!st first select the appropriate programming
model, The first thing to determine is whether the /+/S transactions that yo! want to access !se the
/=MM%-, Ho! then have to determine whether to !se the L$ P,3 or the T/P>+P protocol for comm!nications,
fter conferring with the /+/S developer, yo! learn that each of these transactions is coded to !se the
/=MM%-, Ho! also learn from the mainframe systems programmer that L$ P,3 is config!red for access to the
/+/S region on the mainframe, 1ased on this information, which yo! collected from the mainframe personnel,
yo! determine that it is best to !se the L$ P,3 Link programming model for access to the transactions,
Step ! Con&igure the 2ain&rame 5n7ironment
ltho!gh this step is cr!cial to the s!ccessf!l deployment of a T+ sol!tion, it !s!ally cannot be performed by the
,.-T 8ramework developer, Ho! m!st rely on the mainframe personnel to properly config!re the mainframe
environment, 8ort!nately, the software re?!ired by T+ is !s!ally already installed in most mainframe
environments, The mainframe systems programmer only needs to give yo! access to the transactions,
*hen contacting the mainframe personnel, yo! learn that they were able to review the )ost +ntegration Server
3445 doc!mentation and verify that all mainframe components are properly config!red to allow access to the
/+/S transactions by !sing T+,
Step $ Con&igure the TI 2etadata /ile
Ho! now have to develop the T+ metadata file, +n this case, yo! will implement the metadata file as a ,.-T
8ramework client library beca!se the sol!tion is being implemented in the ,.-T 8ramework, and yo! do not
have a re?!irement to provide two<phase commit capabilities, To develop the T+ metadata file, yo! m!st
complete the following steps:
11 Create a 8isual Studio 1,5T pro+ect, *hen yo! create the proEect, choose 3IS as the proEect type
and TI Pro+ect as the template, .ame the proEect "lobal1ank,
!1 Add a new 1,5T /ramewor- client library, dd a ,.-T 8ramework client library to the "lobal1ank
proEect and !se the parameters specified in the following steps:
a, =n the Library page of the .ew ,.-T /lient Library *i9ard, type Global#an- as the interface
name, and then type a description for the interface,
b, =n the %emote -nvironment page of the wi9ard, select the following information regarding the
host environment:
8endor: Microsoft
Protocol: L$ P,3
Target en7ironment: /+/S
Programming model: Link
a, =n the ne&t %emote -nvironment page, type CS2I in the Transaction ID bo&, and then type
2STE in the Source bo&,
The new client library appears in the :is!al St!dio ,.-T main pane, The wi9ard !ses the parameters
yo! specified to create the defa!lt interface,
$1 Add the methods &or the e.ample, fter adding the ,.-T 8ramework client library, yo! can add the
methods to the new library, The methods hold a one<to<one relationship with the /+/S transactions
being invoked, Table 6 lists all the transactions available to the client thro!gh *indows<initiated
245450494.doc 254 od 257
processing and the corresponding method name, Ho! m!st config!re one method for each of the
transactions that appear in this table, ll the transactions have an integer ret!rn val!e that is an error
code,
To add a method, follow these steps:
6, +n the :is!al St!dio ,.-T main pane, e&pand the Global#an- component, and then select the
Global#an- interface,
3, %ight<click the Global#an- interface, and then click Add 2ethod,
The Method6 method appears,
;, /onfig!re the method properties for this first method and for the other methods !sed in this
e&ample,
The following table lists the property val!es to !se for each method, Ho! can accept the defa!lt val!e
for any of the properties not incl!ded in Table 6,
Table 1 Transactions A7ailable to the Client Through Windows4Initiated Processing
2ethod nameB
transaction name
?,ame Property@
CICS
transaction
lin-4to4
program name
?%in-4to4
Program
,ame
Property@
Input parameters =utput
parameters
Description
CreateAccount "1/%-// cco!nt.!mber
cco!nt.ame
.one /reates an acco!nt
with a 9ero balance,
GetAccountDetails "1"-T// cco!nt.!mber cco!nt.ame
1alance
%etrieves details of a
single acco!nt,
GetAccount%ist "1//LST Total/o!nt%eceived rray of
cco!nt.!mber,
cco!nt.ame, and
1alance
"ets list of acco!nts,
Deposit "1D-P cco!nt.!mber
mo!nt
.e"1alance Deposits money in
the acco!nt,
Withdraw "1*DL cco!nt.!mber
mo!nt
.e"1alance *ithdraws money
from the acco!nt if
the f!nds are
available,
8ig!re ; shows the way that the "lobal 1ank client obEect sho!ld appear after yo! config!re the interface and
all its methods,
/igure $1 Global #an- client ob+ect with methods con&igured ?Clic- the image to enlarge it@
6, Add the method parameters, The method parameters establish a mapping between the parameter
types in the ,.-T 8ramework environment and the /=1=L data types in the mainframe environment,
dd the method parameters for each transaction according to the information in Table 3,
245450494.doc 255 od 257
Table ! Global #an- 2ethod Parameters
Transaction Input parameters InputB
output
1,5T /ramewor-
data type
C=#=% data type
/reatecco!nt cco!nt.!mber +np!t Decimal P+/ SM'n(:M'n(
/=MP<;
/reatecco!nt cco!nt.ame +np!t String P+/ Q'n(
"etcco!ntDetails cco!nt.!mber +np!t Decimal P+/ SM'n(:M'n(
/=MP<;
"etcco!ntDetails cco!nt.ame =!tp!t String P+/ Q'n(
"etcco!ntDetails 1alance =!tp!t Decimal P+/ SM'n(:M'n(
/=MP<;
"etcco!ntList Total/o!nt%eceived +np!t +nteger P+/ SM'n( /=MP
"etcco!ntList rray of cco!nt.!mber,
cco!nt.ame, and
1alance
=!tp!t Decimal, String,
Deciman
P+/ SM'n(:M'n(
/=MP<;, P+/
Q'n(,P+/ SM'n(:M'n(
/=MP<;
Deposit cco!nt.!mber +np!t Decimal P+/ SM'n(:M'n(
/=MP<;
Deposit mo!nt +np!t Decimal P+/ SM'n(:M'n(
/=MP<;
Deposit .ew1alance =!tp!t Decimal P+/ SM'n(:M'n(
/=MP<;
*ithdraw cco!nt.!mber
mo!nt
+np!t Decimal P+/ SM'n(:M'n(
/=MP<;
8ig!re 5 shows the way that the "lobal 1ank client obEect sho!ld appear after yo! config!re the method
parameters,
/igure '1 Global #an- client ob+ect with parameters con&igured ?Clic- the image to enlarge it@
Step ' Con&igure ,etwor- Protocol Connecti7ity
Ho! have already learned that L$ P,3 comm!nications to the "lobal 1ank mainframe are available and that the
mainframe systems programmer has config!red the proper mainframe applications to allow access to /+/S
245450494.doc 256 od 257
transactions, The mainframe systems programmer also informed yo! that yo! sho!ld set yo!r local PP/ L$
name to Local and yo!r remote PP/ L$ name to "1/+/S6, The mode name is PP3T0.$, $sing this
information, yo! config!re L$ P,3 comm!nications by !sing )ost +ntegration Server 3445, 8or more information
abo!t how to config!re L$ P,3 comm!nications, see the )ost +ntegration Server 3445 doc!mentation,
Step ( Con&igure a TI Remote 5n7ironment
$se the T+ Manager to implement the remote environment for "lobal 1ank, +n the %emote -nvironment *i9ard,
specify the val!es for the properties according to Table ;, ccept the defa!lt val!es for any properties that are
not listed in the table,
Table $ Global #an- Property 8alues
Property 8alue
.ame "lobal 1ank )ost
.etwork type L$ P,3
Target host /+/S
Programming model Link
Local L$ alias Local
%emote L$ alias "1/+/S6
Mode name PP3T0.$
Step ) Add an IIS 8irtual Directory
The ++S virt!al directory is !sed to store the *indows<initiated processing obEect that yo! config!re in the ne&t
step, This ++S virt!al directory is associated with the *indows<initiated processing obEect and with the remote
environment, +t is then made available to ,.-T 8ramework applications that !se this T+ config!ration to access
mainframe transactions, +n this e&ample, yo! create an ++S virt!al directory named "lobal1ank in the
/1GInetpu%G2wrootGGlo%al)an' physical directory.
Step * Con&igure a Windows4Initiated Processing =b+ect
/omplete the following steps to config!re a *indows<initiated processing obEect, +n the T+ Manager, add a
*indows<initiated processing obEect by !sing the parameters and val!es listed in Table 5,
Table ' Windows4Initiated Processing =b+ect Property 8alues
Property 8alue
Path /:\"lobal1ankSo!rce\"lobal1ank\Dot.etT+=bEects
8ile Server*+P,dll
:irt!al directory Defa!lt*ebSite>"lobal1ank*+P
%emote environment "lobal 1ank )ost
Step 9 Implement a 1,5T /ramewor- Client Application
245450494.doc 257 od 257
t this point, T+ has been config!red to provide access to the /+/S mainframe transactions, ll that is left is to
develop the ,.-T 8ramework client application that invokes the mainframe transactions,
Resulting Conte.t
The Gateway implementation described here res!lts in the following benefits and liabilities:
#ene&its
Reduced comple.ity, The gateway encaps!lates data and protocol translations re?!ired to !se the
acco!nt management system,
Reduced rede7elopment e&&orts, 1!siness logic that already e&ists on the mainframe transactions
does not have to be redeveloped in the ,.-T 8ramework environment,
Reduced need &or retraining, ,.-T 8ramework developers do not have to become familiar with /+/S
or /=1=L to !se the e&isting mainframe transactions,
%iabilities
Increased maintenance e&&ort, )ost +ntegration Server 3445 is an additional system that m!st be
maintained,
%ac- o& support &or two4phase commit transactions when using 1,5T /ramewor- client
libraries1 The ,.-T 8ramework client library !sed in this scenario does not s!pport two<phase commit
transactions, Many organi9ations rely on two<phase commit transactions for day<to<day operations, so this
config!ration may not s!it them, +nstead, they wo!ld have to !se a /=M type library that does s!pport
two<phase commit transactions,
Tests
To f!lly test the deployment of T+ in this scenario, yo! m!st have access to a mainframe comp!ter that is
r!nning the proper /+/S transactions, )owever, yo! can !se the T+ host<initiated processing capabilities to
sim!late this access, 8or instr!ctions on how to config!re this sim!lation, see the )ost +ntegration Server 3445
online doc!mentation at http:>>www,microsoft,com>hiserver>techinfo>prod!ctdoc>defa!lt,asp,