Architecturen voor de Integratie van Legacy Systemen

Architecturen voor de Integratie van Legacy Systemen
Martijn Kooreman
Universiteit Twente, Nederland
m.kooreman@student.utwente.nl
ABSTRACT
In dit paper worden verschillende mogelijke architecturen
vergeleken welke door een organisatie gebruikt kunnen worden
als leidraad voor de integratie van hun legacy systemen. Legacy
systemen komen hedendaags nog erg veel voor aangezien er
niet al te lang geleden grote investeringen in deze systemen zijn
gedaan. Geleidelijk zullen deze legacy systemen wel vervangen
worden, maar op dit moment wegen de kosten van het
vervangen nog niet op tegen de kosten van het integreren van
deze systemen. Afhankelijk van de situatie van de organisatie is
mogelijk om aan de hand van verschillende variabelen af te
leiden welke architectuur het beste past bij de organisatie.
Keywords
Legacy, integration, architecture, middleware, wrapper, web
service, enterprise application integration, composite web
service.
1. INTRODUCTIE
Er bestaan een groot aantal systemen, welke niet direct te
integreren zijn met andere systemen. Deze legacy systemen zijn
veelal business-critical voor de organisatie en te duur en te
moeilijk om te vervangen [Ber96, Cal99]. Het gaat hier dan ook
vaak om erg specifieke systemen welke het primaire
bedrijfsproces van de organisatie ondersteunen. De kosten om
een dergelijk systeem te vervangen worden vaak hoger geschat
dan de kosten om deze via andere manieren beschikbaar te
maken voor andere systemen en het web [Mec01].
Op het gebied van legacy systeem integratie is verschrikkelijk
veel literatuur beschikbaar [Alo04, Chi01, Bor97, Ser02,
Zou00, Mec01]. In deze literatuur worden veel verschillende
architecturen beschreven en met elkaar vergeleken. Een goed
overzicht van de functionaliteiten van veel voorkomende
architecturen is daarentegen niet te vinden.
In dit paper zal er gekeken worden naar vijf verschillende
architecturen op basis van literatuur. Deze architecturen zijn
gekozen op basis van hun relevantie, hun bekendheid en
verschil in scope welke ze ondersteunen. Er is voor deze
architecturen gekozen om de verschillende mogelijkheden die
ze bieden in combinatie met de hoeveelheid literatuur welke
beschikbaar is. Er wordt vanuit gegaan dat de meest
voorkomende architecturen in de literatuur relevante
architecturen zijn in deze situatie. Daarbij hebben de gekozen
architecturen een oplopende functionaliteit waardoor er een
goede vergelijking gemaakt kan worden. De gekozen
architecturen worden toegelicht en met elkaar vergeleken om zo
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies
are not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission.
3rd Twente Student Conference on IT , Enschede June, 2005
Copyright 2005, University of Twente, Faculty of Electrical
Engineering, Mathematics and Computer Science
te kijken welke architectuur het beste gekozen kan worden in
een van deze drie situaties: binnen een afdeling, binnen de
organisatie, ook wel bedrijfsproces integratie of
intraorganisatorische integratie, en tussen organisaties,
interorganisatorische integratie of supply chain integratie. Deze
vergelijking leidt tot een tabel met de eigenschappen en
functionaliteiten van de gekozen architecturen, waarmee een
software manager van een organisatie zich kan oriënteren op de
mogelijkheden omtrent een rationele keuze voor een
architectuur waarmee deze systemen kan integreren.
Om dit te realiseren wordt in paragraaf 2 eerst het doel van dit
paper uiteengezet en de variabelen waaraan de architecturen
vergeleken worden besproken. Hierna zal in paragraaf 3
ingegaan worden op algemene concepten welke in de
architecturen gebruikt worden. In dezelfde paragraaf worden
hierna de verschillende architecturen een voor een toegelicht,
waarna in paragraaf 4 de architecturen met elkaar vergeleken
worden met behulp van de variabelen in de vorm van een tabel.
2. DOEL
In dit paper wordt er gekeken naar “welke architecturen om
legacy systemen te integreren in welke situatie het beste
gebruikt kunnen worden”. Om dit te realiseren worden er in dit
hoofdstuk een aantal variabelen geïntroduceerd waaraan de
architecturen, welke in paragraaf 3 besproken worden, worden
vergeleken. Deze vergelijking vindt plaats in paragraaf 4.
In dit hoofdstuk worden eerst de verschillende situaties
toegelicht waaraan de architecturen gekoppeld worden in
paragraaf 4. Hierna worden de verschillende variabelen
toegelicht welke gebruikt worden om de architecturen de
onderscheiden.
2.1 Situaties
Er wordt bij deze vergelijking gekeken naar een aantal globale
situaties, te weten:
• binnen een afdeling - De systemen binnen een afdeling
worden in dit paper gezien als een groep systemen welke
onder de controle van deze afdeling vallen. Deze systemen
zijn vaak voor een groot deel homogeen.
• intraorganisatorisch – Afdelingen binnen een organisatie
hebben een eigen ‘set’ informatie systemen welke al dan
niet onderling geïntegreerd zijn. Deze systemen vallen
onder de jurisdictie van deze afdeling. Systemen tussen
afdelingen zijn hoofdzakelijk heterogene systemen.
• interorganisatorisch – Verschillende organisaties hebben
eigen informatie systemen, welke hoofdzakelijk
heterogeen zijn ten opzichte van de eigen organisatie. Ook
willen organisaties niet al hun informatie aan elkaar delen.
2.2 Variabelen
De hier onderstaande variabelen zijn gekozen naar aanleiding
van een aantal literatuurstukken waarvan de meest relevante
vermeld staan bij de variabele.
Er is gekozen voor deze set variabelen omdat deze gezamenlijk
voldoende informatie bevatten om de verschillende

architecturen te onderscheiden. Meerdere variabelen zijn altijd
wel te definiëren maar bieden in de context van dit paper weinig
toevoeging bij de beoordeling van de architecturen.
• Scope – De situatie, zoals hierboven beschreven, waarin de
architectuur het beste gebruikt kan worden. Door de
oplopende eisen in de situaties zijn architecturen vaak wel
in ‘lagere’ situaties te gebruiken. Zo kan een architectuur
welke intraorganisatorisch gebruikt wordt ook gebruikt
worden binnen een afdeling – waarschijnlijk met veel
overbodige functionaliteit.
• Communicatie mogelijkheden – De mogelijkheden van de
architectuur om 1 of meerdere systemen binnen de
integratie aan te spreken.
• Complexiteit van de wrapper – De mate van
verantwoordelijkheid welke de wrapper heeft; deze kan
bijvoorbeeld verantwoordelijk zijn voor het maken van
connecties met alle andere systemen, of dit overlaten aan
een ander deel van de architectuur [Mec01].
• Dynamische veranderingen – De mogelijkheden om
nieuwe systemen op te nemen of bestaande systemen te
vervangen in te integratie zonder dat andere systemen
binnen de integratie aangepast moeten worden [Zou00].
• Gewenste Heterogeniteit participerende systemen – De
mate waarin de randsystemen van de opstelling heterogeen
moeten zijn om opgenomen te worden in de integratie
[Zou00].
• Integratie gemak – Gemak waarmee een systeem in elkaar
gezet kan worden / de hoeveelheid aanpassingen welke er
door de ontwikkelaar gedaan moeten worden om het
systeem werkend te krijgen [Das99].
• Kosten – Kosten relatief ten opzichte van het aantal te
integreren systemen [Zou00, Llo99].
• Ondersteunende functionaliteiten – load balancing,
replicatie, logging, persistentie, transactie garantie,
filtering, routing, message broadcasting, security e.a..
[Alo04, Das99, Chi01-2]
• Ontwikkelingstijd – Tijd welke de ontwikkeling kost ten
opzichte van het aantal te integreren systemen [Mec01].
• Performance – De snelheid en overhead van de
architectuur [Chi01-2, Das99, Llo99, Alo04].
• Uitbreidbaarheid – Het gemak waarmee de opstelling van
de systemen aangevuld kan worden [Chi01-2].
3. ARCHITECTUREN
Aan de hand van verschillende literatuurbronnen hebben we
gekozen om vijf architecturen te vergelijken welk de integratie
van legacy systemen mogelijk maken [Alo04, Chi01, Bor97,
Ser02, Zou00, Mec01].
Bij het bespreken van de architecturen worden een aantal
termen gebruikt waarvoor in verschillende literatuur
verschillende definities gebruikt worden. In dit paper worden de
volgende definities gebruikt:
• Legacy systeem – Een systeem dat op dit moment een
significante business waarde heeft, welke veel geld gekost
heeft aan hard en software en vele jaren oud kan zijn. Het
is een business-critical systeem met een architectuur die
flexibel genoeg is om aan geanticipeerde toekomstige eisen
te voldoen [Cal99]. Een legacy systeem is niet direct te
integreren met andere systemen binnen de organisatie;
hiervoor zijn wrappers noodzakelijk.
• Wrappers – Deze bieden de functionaliteit van het
onderliggende legacy systeem aan als een nieuwe interface
[Mec01]. Deze nieuwe interface kan dan weer gekoppeld
worden aan een van de architecturen, de wrapper dient
zodanig hoofdzakelijk als ‘vertaler’, de taal van het legacy
systeem wordt vertaald naar de taal welke de architectuur
spreekt.
• Systeem lagen – Een informatiesysteem bestaat
conceptueel uit 3 verschillende lagen, welke al dan niet
gedistribueerd zijn over systemen of groepen systemen. De
resource management laag bevat de data waarmee de
informatie systemen werken, deze bestaat in dit paper uit
legacy systemen. In het midden zit de application logic
laag welke de data omvormt tot de gewenste resultaten.
Bovenaan zit de presentation laag welke deze resultaten
met externe entiteiten communiceert. [Alo04]
Als eerste er zal in subparagraaf 1 een point-to-point
architectuur besproken worden. Deze architectuur is gebaseerd
op losse connecties tussen de verschillende te integreren
systemen. Hierna zal er gekeken worden naar conventionele
middleware in subparagraaf 2. Middleware ondersteunt deze
connecties en biedt integratie logica en ondersteunende
functionaliteiten. In subparagraaf 3 wordt het EAI platform
toegelicht. Dit is een ‘opvolger’ van conventionele middleware.
Hierna worden in subparagraaf 4 web services besproken. Met
behulp van deze web services kunnen composite web services
gebouwd worden, welke beschreven worden in subparagraaf 5.
3.1 Point-to-point
Bij het integreren van een set informatiesystemen, welke ieder
een aantal connecties zullen hebben met een aantal andere
(legacy) systemen, is het mogelijk gebruik te maken van directe
connecties tussen deze systemen [Sut02]. Bij deze oplossing
worden alle objecten die met elkaar zullen communiceren direct
aan elkaar gekoppeld. Hierbij wordt alle integratie logica
opgenomen buiten het (legacy) systeem. In dit paper wordt er
vanuit gegaan dat deze logica zich bevindt binnen de wrapper
om verdere complexiteit van de figuren te limiteren. Deze
logica zou ook in een nieuwe aparte laag bovenop de wrapper
geplaatst kunnen worden, dit is niet gedaan om de figuren
overzichtelijk te houden.
Figuur 1: Point-to-point
Bij het integreren van verschillende systemen zullen alle
systemen welke elkaar nu of in de toekomst gaan gebruiken met
elkaar verbonden moeten worden. De meeste systemen in
organisaties zijn niet in staat om connecties te onderhouden met
verschillende andere systemen, de logica om deze connecties tot
stand te brengen en te onderhouden is vaak niet aanwezig. De
logica welke benodigd is om de connecties tussen de
verschillende (legacy) systemen tot stand te houden zal daarom
aanwezig moeten zijn in de wrapper. De wrapper is in deze

situatie verantwoordelijk voor de communicatie tussen de
verschillende systemen en de integratie logica die nodig is
hiervoor. De programmeur is dan ook geheel verantwoordelijk
voor alle complexiteiten met betrekking tot de implementatie
van een gedistribueerd systeem [Alo04]. Deze opstelling wordt
weergegeven in figuur 1.
De wrapper moet bijhouden met welke systemen er
gecommuniceerd moet worden en moet de gegevens omvormen
zodat het systeem aan de andere kant deze gegevens kan
gebruiken. Het interactie model, de verschillende systemen
waarmee gecommuniceerd zal gaan worden, van de
verschillende objecten in deze opstelling moet in elke wrapper
vanuit het niets opgebouwd worden [Alo04]. Doordat dit model
voor elk van de objecten vast staat, is het moeilijk nieuwe
elementen op te nemen. Om dit te realiseren zou de code van
elke wrapper, welke mogelijkerwijs een connectie zal maken
met dit nieuwe object, aangepast moeten worden. Meerdere
objecten met elkaar verbinden levert dus veel complexiteit en
overhead op.
De adapters aan de ‘rand’ van het netwerk moeten homogeen
zijn – ze moeten eenzelfde manier gebruiken om te
communiceren met andere systemen in het netwerk.
Heterogeniteit van de systemen zal door de ontwikkelaar
handmatig bij elk systeem afgehandeld moeten worden en
omgevormd moeten worden zodat alle communicatie over een
homogeen netwerk kan plaatsvinden. Om dit te realiseren moet
er een protocol opgesteld worden waarmee de gegevens, welke
de systemen met elkaar gaan delen, overgebracht kunnen
worden. Het toevoegen of wijzigen van de set te integreren
systemen brengt dus veelal een wijziging in het protocol met
zich mee.
Formule 1: Maximum Connecties tussen systemen
Om de complexiteit van grotere netwerken van systemen met
betrekking tot deze oplossing weer te geven kan gebruik
gemaakt worden van formule 1. In deze formule is x het aantal
systemen welke met elkaar geïntegreerd zullen worden, de
resulterende f(x) is het maximale aantal connecties dat er tussen
de verschillende objecten plaats kan vinden. Dit maximum
wordt bereikt als elk systeem met ieder ander systeem zou
willen communiceren, al is het maar om statusgegevens uit te
wisselen. Bij een klein aantal systemen zijn er nog niet zoveel
connecties nodig om alle objecten aan elkaar te koppelen –
voor drie systemen zijn er ook maximaal 3 connecties nodig.
Dit aantal stijgt daarentegen snel. Bij 6 systemen zijn er al
(f(6)=) 15 connecties mogelijk, bij 20 systemen al 190 en f(50)
systemen 1225!
Elke afdeling binnen een organisatie heeft verschillende
systemen. Deze systemen werken op verschillende platformen
binnen een bepaalde regelgeving binnen die afdeling. Elk van
de deze systemen opgenomen in de integratie zou een connectie
moeten kunnen maken en onderhouden met elk van de systemen
buiten de afdeling, op andere computersystemen, werkend met
andere regels. Om de regels binnen een afdeling te respecteren
zouden deze ingevoerd moeten worden in elk van de wrappers.
Daarnaast zullen deze aangepast moeten worden om heterogene
systemen aan te spreken, aangezien verschillende afdelingen
vaak met verschillende systemen werken. Om dit laatste te
realiseren zal er voor elk heterogeen systeem logica in de
wrapper opgenomen moeten worden om deze aan elk ander
heterogeen systeem te koppelen, aangezien er geen sprake is
van een algemeen geaccepteerde standaard. [Ber96]
Naast de snel groeiende complexiteit van de wrappers door het
aantal participerende systemen, wordt deze ook nog eens groter
als er gedacht moet worden aan ondersteunende faciliteiten
zoals load balancing, replicatie, logging, persistentie, transactie
garanties e.a. met betrekking tot het garanderen van de werking
en de correctheid van het systeem [Ber96, Alo04]. Veel van de
code welke nodig is om deze taken uit te voeren zal in elk van
de wrappers aanwezig moeten zijn en gecommuniceerd en
gecoördineerd moeten worden met de andere wrappers. De
grootte van deze wrapper componenten groeit hierdoor extreem
en neemt erg veel, onnodige, bandbreedte en computerkracht in
beslag.
Al met al is het maken van directe connecties tussen
verschillende systemen, met als doel deze te integreren, een
oplossing voor een klein aantal systemen. Bij een klein aantal
systemen, waarbij ondersteunende functionaliteiten zoals
replicatie, load balancing, dynamische invoeging van nieuwe
componenten en dergelijke niet nodig zijn, is deze oplossing
snel en goedkoop te implementeren. Naarmate het aantal
deelnemende systemen en hun onderlinge verbanden groeit,
neemt de complexiteit van deze oplossing exponentieel toe.
Deze complexiteit zorgt dan snel voor een onhandelbare,
onflexibele en erg dure oplossing. Daarentegen is de tijd die
nodig is voor het ontwikkelen van een simpele wrapper welke
met een klein aantal homogene systemen binnen een afdeling in
connectie staat is erg laag. De systemen hoeven door hun
homogeniteit geen complexe wrappers te hebben welke de
informatie omzet naar een leesbaar formaat. En door de
kleinschaligheid zijn zaken als load balancing en replicatie en
dergelijke nog niet van belang.
3.2 Middleware
Binnen een afdeling in een organisatie kan besloten worden
verschillende systemen met elkaar te integreren. Om dit te
bewerkstelligen kan er, naast de hiervoor besproken point-topoint
oplossing, gebruik gemaakt worden van middleware.
Legacy systemen kunnen met behulp van een wrapper
aangesloten worden op een middleware platform. De wrapper
zal in dit geval niet bij hoeven te houden welke systemen
aangesloten zijn, of transacties wel uitgevoerd worden, of er
gelogd wordt. Kortom, de ondersteunende faciliteiten en de
integratie logica bevinden zich niet meer in de wrapper. Deze
zijn in deze opstelling is in handen van het middleware
platform.
Middleware onderhoudt en faciliteert de interactie tussen
applicaties tussen heterogene computer platformen [Alo04,
Jur00, Emm00, Mon00]. Het is de eerste stap naar een oplossing
waar meerdere systemen met elkaar kunnen communiceren
zonder dat elk systeem verantwoordelijk is voor zijn eigen
connecties en integratie logica, zoals dit nodig is bij de point-topoint
architectuur. Om dit te realiseren levert middleware
abstracties welke te gebruiken zijn door de ontwikkelaar om een
gedistribueerd systeem in elkaar te zetten [Emm00].
Middleware kan de logica bevatten ten behoeve van de
ondersteunende functionaliteiten als load balancing, replicatie,
logging, persistentie, transactie garantie, filtering, routing,
message broadcasting, security e.a.. [Alo04, Das99]. Deze
functionaliteiten zijn afhankelijk van het type middleware en de
functionaliteit van een bepaald middleware pakket. Middleware
zorgt ervoor dat commando’s, welke door andere programma’s
gegeven worden, op de goede plaats aankomen. Als een
programma een gegeven wil hebben van een ander systeem,
zorgt middleware ervoor dat dit signaal in zijn geheel aankomt
– het versturende programma hoeft dus geen logica te bevatten
welke controleert wat er gebeurt met het signaal, deze kan zich
concentreren op zijn eigen taken. De legacy systemen en de

wrappers kunnen werken alsof de systemen direct op elkaar
aangesloten zijn. Het middleware platform garandeert de
correcte afhandeling van de signalen tussen de systemen.
Er zijn verschillende soorten kant en klare middleware te
verkrijgen, welke verschillen in kosten, en (ondersteunende)
functionaliteit. In deze paragraaf gaat het om de middleware
welke niet geclassificeerd wordt als Enterprise Application
Integration Platform (EAI Platform, welke in paragraaf 3.3
besproken wordt). Het gaat hier om de middleware welke
binnen een afdeling, meerdere heterogene systemen aan elkaar
kan koppelen. Denk hierbij aan basale RPC systemen (Sun
RPC, OSF DCE), TP monitoren (o.a. IBM CICS, Microsoft
MTS, BEA Tuxedo, Transarc Encina), Object Brokers (o.a.
CORBA specificatie), Object Monitors (TP monitor+Object
broker) en Message-Oriented Middleware (o.a. IBM Websphere
MQ, Microsoft MSMQ, WebMethods Enterprise, deels
CORBA). [Mon00, Ber96, Emm00] Het bespreken van deze
verschillende soorten valt buiten de context van dit paper – het
gaat hier om de functionaliteit van middleware in het algemeen.
Elke soort middleware heeft zijn eigen voor- en nadelen.
Verschillende implementaties van een middleware oplossing
implementeren bijvoorbeeld verschillende mate van
ondersteunende functionaliteiten.
Figuur 2: Standaard Middleware (aangepast uit [Alo04])
In figuur 2 wordt deze architectuur grafisch weergegeven.
Onderaan staan verschillende legacy systemen, welke door
middel van wrappers beschikbaar gesteld worden aan de laag
erboven. Deze middelste laag bestaat in dit geval uit alle logica
die nodig is om deze systemen te integreren en aan te bieden
aan de presentatie laag erboven. Deze middelste laag wordt
middleware genoemd. De dienst die deze middleware laag biedt
aan de laag erboven kan weer worden aangeboden,
bijvoorbeeld, met behulp van een web server aan een cliënt.
Om verschillende systemen aan te sluiten op (EAI) middleware
wordt er gebruik gemaakt van wrappers. Deze wrappers
verbergen de heterogeniteit van de aan te sluiten systemen en
zorgen ervoor dat de systemen op een homogene manier data
kunnen uitwisselen.
Middelware is in eerste instantie bedoeld om verschillende
systemen binnen de resource laag te integreren, deze is
daarentegen niet makkelijk in staat om te communiceren met
andere middleware systemen elders in de organisatie [Alo04].
Het is hierom, met de hierboven beschreven middleware, niet
makkelijk om een brug te vormen tussen verschillende
afdelingen, welke ieder hun eigen groepen systemen hebben.
Om hieraan te voldoen is middleware ‘uitgebreid’ om dit
mogelijk te maken. Deze uitbreiding wordt ook wel Enterprise
Application Integration (EAI) Platform genoemd.
3.3 EAI Platform
In dit hoofdstuk wordt een uitbreiding van traditionele
middleware systemen beschreven. Deze uitbreiding, onder
naam van EAI Platform, wordt afgebeeld in figuur 3.
Wrapper
legacy
client
Browser
Web server
Wrapper
legacy
Client
Information system – provider
Presentation
layer
adapter
Application Logic Layer
client
Wrapper
client
legacy
Andere EAI
Middleware
Figuur 3: EAI Platform (aangepast van [Alo04])
Zoals bij middleware worden de verschillende legacy systemen
aan het middleware platform beschikbaar gemaakt met behulp
van wrappers. Traditionele RPC gebaseerde middleware
systemen maken directe connecties tussen verschillende
applicaties en zijn hierdoor nog steeds erg inflexibel [Alo04].
Conventionele middleware ondersteunt de directe connecties
tussen 2 systemen, een EAI Platform daarentegen vangt de
berichten op en stuurt ze door naar een of meerdere systemen
welke interesse hebben in de informatie. Zoals bij middleware
kan de geïntegreerde dienst aangeboden worden aan cliënten
met behulp van de presentation laag. Het verschil in
conventionele middleware en een EAI Platform zit in de
mogelijkheid om het bedrijfsproces te integreren – het is
mogelijk om verschillende middleware implementaties aan
elkaar te koppelen. Een EAI Platform is mogelijk te koppelen
aan andere middleware en andere systemen van andere
afdelingen, om zo over de gehele organisatie het bedrijfsproces
te integreren.
In tegenstelling tot gewone middleware, is een EAI Platform
gemaakt om te koppelen aan andere EAI Platformen. Deze
koppeling maakt het mogelijk om verschillende stappen binnen
het productieproces integreren. Deze stappen bevinden zich
vaak in verschillende afdelingen van de organisatie, met ieder
eigen geïntegreerde systemen met eigen functionaliteiten die
niet direct gebruikt kunnen worden door andere systemen
waarmee geïntegreerd moet worden. Op elke stap in dit
bedrijfsproces bevinden zich waarschijnlijk systemen met
verschillende eigenschappen zoals data formaten,
beveiligingseisen, infrastructuur, functionaliteit en
besturingssystemen.
Bij EAI Platform moet er gedacht worden aan Message
Brokers. Message brokers kunnen zender en ontvanger van een
bericht ontkoppelen [Alo04]. Dit zorgt ervoor dat applicaties
welke een bericht versturen richting het platform, niet (perse)
weten waar het bericht heen zal gaan. Ontvangers hoeven niet
per se te weten waar het bericht dat ze ontvangen vandaan
komt. Dit is gerealiseerd door veel EAI Platform oplossingen
met een publisher/subscriber systeem. Een systeem kan een
bericht publiceren richting het platform en applicaties kunnen
zich inschrijven om deze of andere berichten te ontvangen. Als
er een bericht door een publisher verstuurd wordt, wordt een
kopie hiervan afgeleverd bij elke subscriber welke interesse
heeft getoond in dat type bericht. Het voordeel van een
publisher/subscriber systeem is dat nieuwe objecten zich
makkelijk kunnen registreren om berichten van anderen te
ontvangen. Zo kunnen er makkelijk nieuwe systemen gekoppeld
worden aan de middleware – er hoeft alleen aangegeven te

worden welke berichten interessant zijn om te ontvagen en
versturen. Zo kunnen ook componenten gemakkelijk verwisseld
of toegevoegd worden.
3.4 Web service
Bedrijven willen hun legacy systemen integreren om deze
beschikbaar te maken aan andere systemen binnen dezelfde
resource management laag (afdeling) (point-to-point /
middleware). Daarnaast willen organisaties systemen opnemen
in het bedrijfsproces, waardoor er integratie tussen afdelingen
ontstaat (EAI Platform). Ook willen organisaties elkanders
diensten over de gehele supply chain, van productie tot verkoop,
integreren. Het web wordt tegenwoordig gebruikt als middel om
communicatie tussen organisaties en andere organisaties en
consumenten te ondersteunen. Om dit te realiseren werden
bestaande architecturen in eerste instantie uitgebreid met een
nieuwe presentatielaag – de web server. Cliënten konden vanaf
de andere kant van de wereld gebruik maken van de
(geïntegreerde) dienst, welke door de organisatie werd
aangeboden [Zou00].
Om de integratie tussen verschillende organisaties over het web
te realiseren is voorgesteld om connecties te maken tussen
middleware platformen van de verschillende organisaties of
tussen de presentation lagen. Om integratie met behulp van
middleware, tussen organisaties over het web, te ondersteunen
werden adapters gemaakt welke het mogelijk maakten om via
het web connecties in stand te houden tussen middleware
platformen. Er zijn daarentegen meerdere problemen ontstaan
bij het direct aan elkaar verbinden van middleware over het web
[Alo04]. Ten eerste is de communicatie over het web vaak
gelimiteerd door firewalls. Daarnaast moet het data formaat en
interface definitie aan beide zijden gelijk zijn. Als laatste moet
er een directory service aanwezig zijn, welke service discovery
mogelijk maakt. Het is daarentegen niet duidelijk wie deze
onder beheer zou moeten krijgen. Veel van deze problemen zijn
opgelost met behulp van web services.
Om verschillende organisaties met elkaar te kunnen laten
communiceren met behulp van conventionele EAI Platform,
zullen al deze organisaties gebruik moeten maken van eenzelfde
soort middleware platform en een gezamenlijke naam en
directory service. Deze moet overal hetzelfde zijn om een grote
geïntegreerde keten te realiseren tussen organisaties. Aangezien
een organisatie vaak samenwerkt met meerdere organisaties,
welke ieder eigen middleware implementaties hebben, zal voor
elk van deze organisaties aparte middleware opgenomen moeten
worden om hiermee te kunnen communiceren. Ervoor zorgen
dat alle organisaties waarmee gehandeld zal worden dezelfde
middleware gebruiken is niet realistisch, er zijn teveel
verschillende implementaties. Hierdoor kan het zo uit de hand
lopen dat er binnen 1 organisatie meerdere verschillende
middleware oplossing gekoppeld moet worden aan een ‘extra’
middleware platform, om de verschillende middleware te
integreren! Hierdoor ontstaat een soort “point-to-point” situatie
als hierboven beschreven – voor elke connectie moet nieuwe
middleware opgenomen worden. Daarnaast zijn er meer
redenen dat conventionele middleware niet geschikt is voor
B2B situaties – zo zijn de connecties binnen EAI Platform vaak
van korte duur, terwijl connecties/operaties tussen organisaties
veel langer duren. EAI interacties gebeuren binnen een ‘trust
domain’ binnen de organisatie. Tussen organisaties bestaat niet
het vertrouwen om alle gegevens binnen het bedrijfsproces vrij
te geven. Er zijn veel beperkingen met betrekking tot de
gegevens die uitgewisseld mogen worden tussen organisaties.
[Alo04]
Om deze problemen op te lossen zijn web services ontwikkeld.
Een web service is een manier om de functionaliteit van
onderliggende systemen beschikbaar te maken via het web. Het
gebruik van standaarden zorgt ervoor dat de heterogeniteit
tussen systemen niet belangrijk is. Web services kunnen worden
gezien als een laag bovenop een bestaand systeem, welke de
onderliggende functionaliteit ‘wrappen’ tot een standaard
formaat, welke gebruikt kan worden door andere organisaties.
[Alo04].
Figuur 4: Web service (Aangepast van [Alo04])
Figuur 4 beschrijft een basale opstelling van twee webservices,
waarbij de rechter gebruik maakt van de dienst, welke de linker
aanbiedt. De web service zorgt ervoor dat de onderliggende
dienst, welke geleverd wordt door een of meerdere lagen (EAI)
middleware, aangeboden wordt als web service. Web service
middleware zorgt hoofdzakelijk voor het in- en uitpakken van
berichten en deze te converteren naar een formaat dat gebruikt
kan worden door de onderliggende lagen. De lagen eronder zijn
nog steeds verantwoordelijk voor de ‘normale’ middleware
taken als eerder beschreven in paragraaf 3.2 (integratie logica
en ondersteunende functionaliteiten als load balancing,
replicatie, logging, persistentie, transactie garantie, filtering,
routing, message broadcasting en security). Huidige web service
middleware is op dit moment niet in staat om deze diensten te
leveren, deze worden daarom overgelaten aan de onderliggende
lagen.
Naast het idee om de ondersteunende functionaliteiten en
integratie logica voor het grootste deel in handen te laten van
het middleware platform, is er ook voorgesteld om heterogene
legacy systemen direct beschikbaar te maken als web services
[Mec01]. Er wordt beargumenteerd dat de wrapper
componenten de legacy informatie beschikbaar kunnen maken
aan de web service en hoe verschillende web services als
componenten kunnen dienen voor een composite web
‘applicatie’. Andere literatuur argumenteert dat deze integratie
logica en ondersteunende functionaliteiten moeten worden
aangeboden door het middleware platform [Alo04]. In dit paper
wordt er vanuit gegaan dat web services gebouwd worden
bovenop een middleware platform welke deze ondersteunende
functionaliteiten en integratie logica biedt om extreme
complexiteit van de wrapper te voorkomen. Op het moment dat
deze logica niet afgehandeld wordt door een middleware
platform, ontstaat dezelfde complexiteit in de wrappers als bij
paragraaf 3.1. Om deze reden zal een organisatie, welke een
dienst aanbiedt, die bestaat uit meerdere geïntegreerde systemen
binnen een organisatie (bedrijfsproces integratie), gebruik
maken van een middleware platform om de integratie logica en
ondersteunende faciliteiten te bieden.
3.5 Composite Web service
Organisaties willen steeds complexere diensten leveren aan
cliënten en om dit te faciliteren wordt er hedendag al veel
gebruik gemaakt van web services. Om complexere web
services aan te bieden kunnen deze opgebouwd worden uit
verschillende kleine web services, welke een samengestelde
dienst kunnen leveren.

Organisatie a
Web service interface
Access to internal sys.
Web service middleware
Service interface
Integration logic
Middleware (met middleware
services)
Composite
web service
(organisatie d)
Client Web
service
(organisatie x)
Composite
web service
(organisatie e)
Web service
(organisatie b)
Composite
Web service
(organisatie c)
Figuur 5: Composite Web service
Web services kunnen direct aan elkaar gekoppeld worden ten
behoeve van het integreren van systemen. Daarnaast is het ook
mogelijk om twee of meerdere web services op te nemen in een
composite web service. Een composite web service is een web
service op zich welke functionaliteiten aanbiedt van meerdere
web services, de dienst van deze gecombineerde web service
kan weer gebruikt worden door een cliënt (cliënt web service)
of gecombineerd worden in weer een nieuwe gecombineerde
web service.
Een mogelijke architectuur van een gecombineerde web service
is afgebeeld in figuur 5. In dit figuur is een web service
uitgewerkt (organisatie a), welke samen met de web service van
organisatie b een composite web service d vormt. Hierboven
bevind zich nog een samengestelde dienst (organisatie e) en een
afnemer van de gecombineerde dienst (organisatie x). Deze
composite web services maken het mogelijk om snel complexe
diensten te creëren uit simpelere web services alsmede het
onderhoud en evolutie van de systemen te vergemakkelijken
door de simpliciteit van de losse componenten [Alo04].
4. VERGELIJKEN
De in paragraaf 2 besproken variabelen zijn, al dan niet indirect,
besproken bij de beschrijvingen van de architecturen in
paragraaf 3. Deze architecturen zijn in dit hoofdstuk tegen
elkaar uitgezet aan de hand van deze variabelen in tabel 1
(volgende pagina). In deze tabel zijn in de eerste kolom de
verschillende variabelen opgenomen, welke voor iedere
architectuur ingevuld zijn. De architecturen staan in de eerste rij
van de tabel.
In dit hoofdstuk worden de punten in deze tabel toegelicht en
besproken. De scope wordt als laatste toegelicht, aangezien
deze afgeleid is uit de andere variabelen.
4.1 Communicatie Mogelijkheden
Als er point-to-point connecties tussen verschillende systemen
opgezet wordt om deze te integreren, zijn dit allen 1 op 1
connecties – het is niet mogelijk om een bericht te versturen
naar meerdere ontvangers zonder naar al deze ontvangers een
connectie op te zetten. De verantwoordelijkheid om deze
connecties allemaal op te zetten ligt in dit geval bij de wrapper.
Middleware lost dit al op door automatisch meerdere connecties
vanuit het versturend systeem aan te maken of door middel van
broadcast berichten. Bij een EAI Platform krijgen alle systemen
welke zich ingeschreven hebben voor een bepaald type bericht,
deze berichten als ze worden verstuurd. Hetzelfde gaat het bij
web services – hier ontvangen die cliënten berichten van de
service provider waar ze bij ingeschreven staan.
4.2 Complexiteit Wrapper
De wrapper is werkzaam als adapter tussen het legacy systeem
en hun ‘buitenwereld’. Op het moment dat deze wrapper zelf
connecties moet onderhouden (paragraaf 3.1, point-to-point) zal
deze veel integratie logica moeten bevatten – de wrapper wordt
verantwoordelijk voor het onderhouden van connecties.
Afhankelijk van het aantal te integreren systemen en de
hoeveelheid gewenste logica zal de wrapper zeer snel erg
complex worden. Denk bijvoorbeeld aan broadcasting, waarbij
naar elk van de systemen een bericht gestuurd moet worden, de
wrapper zou hier verantwoordelijk zijn voor het maken van een
connectie naar elk van de systemen.
In de opvolgende architecturen worden deze integratie logica
afgehandeld door de laag boven de wrapper. De wrapper is
hierbij niet meer verantwoordelijk voor de ondersteunende
faciliteiten als beschreven in paragraaf 2 (load balancing,
replicatie, logging, persistentie, transactie garantie, filtering,
routing, message broadcasting, security e.a..). Door deze
verschuiving van logica is de wrapper is de andere architecturen
alleen nodig als vertaler.
4.3 Dynamische veranderingen
De mogelijkheid om nieuwe systemen binnen een bestaande
architectuur op te nemen, zonder dat andere componenten in de
architectuur (erg) aangepast moeten worden is niet in alle
architecturen terug te vinden.
Bij het invoegen van een nieuw systeem binnen een point-topoint
architectuur zal elke wrapper, wiens systeem
mogelijkerwijs informatie wil uitwisselen met het nieuwe
systeem, aangepast moeten worden om connecties te
onderhouden met dit nieuwe systeem. Bij conventionele
middleware zal de configuratie van de middleware applicatie
aangepast moeten worden om connecties mogelijk te maken
naar het nieuwe systeem, waardoor ook deze niet echt
‘dynamisch’ te noemen is.
Bij een EAI platform daarentegen wordt er gewerkt met een
publisher/subscriber model, waarbij nieuwe systemen zich
kunnen abonneren op berichten van andere systemen. De
veranderingen welke in dit systeem gemaakt moeten worden
beperken zich grotendeels tot het veranderen van de
abonnementen van andere systemen, welke interesse hebben in
de berichten van dit nieuwe systeem.
Een statische web service en een composite web service
communiceren door middel van standaarden. De standaard
interface van deze web services zorgt ervoor dat elk systeem
welke voldoet aan de eisen van deze standaard theoretisch aan
te sluiten is op het geheel.
4.4 Gewenste heterogeniteit
De architecturen ondersteunen een bepaalde mate van
heterogeniteit in de resource laag. Bij een point-to-point
systeem waarbij verschillende heterogene systemen
geïntegreerd moeten worden zal in de wrapper de logica
aanwezig moeten zijn om tussen deze heterogene systemen te
communiceren – de ontwikkelaar is hier verantwoordelijk voor
het opstellen van een eigen protocol.

Tabel 1: Vergelijking architecturen
Scope
Communicatie
mogelijkheden
Complexiteit
wrapper
Dynamische
veranderingen
Gewenste
Heterogeniteit
Integratie gemak
Kosten
Ondersteunende
functionaliteiten
Point-to-Point Middleware EAI Platform Web service Composite web
service
Weinig objecten
/ binnen afdeling
Binnen afdeling
Intra
organisatorisch
Inter
organisatorisch
Inter
organisatorisch
1-1 1-1, 1-* 1-1, 1-n, 1-* 1-1, 1-n, 1-* 1-1, 1-n, 1-*
Hoog Laag Laag Laag Laag
Zo goed als
onmogelijk
Laag
Door
publisher/subscriber
model
Component moet
dezelfde interface
hebben
Component moet
dezelfde interface
hebben
Homogeen homogeen homogeen heterogeen heterogeen
Laag bij veel
nodes, anders
hoog
Erg laag bij
weinig objecten
Nee
Integratie logica
verborgen voor
programmeur
Hoog bij weinig
objecten
Ja (afhankelijk
van
implementatie)
Makkelijk nieuwe
stukken op aan te
sluiten, veel werk
bij weinig systemen
Laag per systeem
(vaak veel objecten)
Ja (afhankelijk van
implementatie)
Veel werk
overgelaten aan
lagere middleware -
lichtgewicht
Laag door
standaardisatie, wel
middleware nodig
Door onderliggende
middleware
Ontwikkelingstijd Zie 4.7 Zie 4.7 Zie 4.7 Zie 4.7 Zie 4.7
Performance
Veel overhead
bij meerdere
systemen
Hoog
Overhead door
pub./subscr. sys.
Overhead door
standaard formaat
Uitbreidbaarheid Erg laag Laag Goed Hoog Hoog
Veel werk
overgelaten aan
lagere middleware -
lichtgewicht
Laag door
standaardisatie, wel
middleware nodig
Door onderliggende
middleware
Overhead door
standaard formaat
Een middleware systeem en ook de EAI platform, bevat
abstracties welke door de programmeur gebruikt kunnen
worden om de onderliggende systemen te laten communiceren,
hierbij moet de wrapper van het legacy systeem dus voldoen
aan deze standaarden, wat het al iets makkelijker maakt.
Web services communiceren door middel van standaard
interfaces welke de heterogeniteit van de onderliggende lagen
verbergt.
4.5 Gemak, Ontwikkelingstijd, Kosten
Als er binnen de organisatie weinig systemen zijn welke met
elkaar moeten kunnen communiceren, kunnen deze relatief
gemakkelijk en goedkoop direct met elkaar verbonden worden –
de benodigde integratie logica is niet al te complex en er is
weinig noodzaak voor geavanceerdere middelen welke geboden
worden door middleware. Bij grotere opstellingen neemt de
complexiteit, en hiermee ook de ontwikkelingstijd en kosten,
gigantisch snel toe (Zie hiervoor formule 1 in paragraaf 3.1).
Middleware biedt geavanceerdere logica welke voor de
programmeur, relatief ten opzichte van de geboden
functionaliteit, gemakkelijk op te bouwen is. Deze opstelling is
helaas nog wel redelijk statisch – er moeten redelijk veel
aanpassingen gedaan worden als er nieuwe systemen
aangesloten moeten worden en bij grote hoeveelheden systemen
ontstaan veel configuratie bestanden waarin vermeld staat welke
systemen hoe met elkaar communiceren. Door het
publisher/subscriber model bij EAI platformen kunnen
systemen makkelijk in elkaar gezet worden (zoals ook in
paragraaf 4.3 besproken), vooral bij grotere hoeveelheden
heterogene, over afdelingen verspreidde systemen is de
ontwikkelingstijd kort per systeem en zijn de kosten laag.
Web services zijn door hun standaardisatie heel gemakkelijk
aan elkaar te koppelen – hierdoor kunnen verschillende
configuraties gemakkelijk in elkaar gezet worden. Doordat web
services weinig integratie logica bevatten, deze bevindt zich in
de onderliggende (middleware) lagen, zijn web services erg
goedkoop, maar vereisen wel een middleware oplossing welke
de ondersteunende faciliteiten en integratie logica op zich
neemt.
4.6 Ondersteunende Functionaliteiten
Bij een ‘simpel’ point-to-point systeem zal de wrapper alle
integratie logica en alle ondersteunende functionaliteiten (load
balancing, replicatie, logging, persistentie, transactie garantie,
filtering, routing, message broadcasting, security e.a. [Alo04,
Das99, Chi01-2]) moeten bevatten. Deze functionaliteiten
zullen hier dus door de ontwikkelaar handmatig ingevoegd
moeten worden. Doordat de integratie logica gedecentraliseerd
is in een point-to-point systeem (elke wrapper is
verantwoordelijk voor de connecties met andere systemen),
zullen veel van deze functionaliteiten op zo’n manier
geïmplementeerd moeten worden dat deze met elkander (met de
andere wrappers) synchroniseren om zo gezamenlijk de
functionaliteiten aan te bieden – dit is uiteraard gigantisch veel
werk al dan niet onmogelijk bij veel systemen.
Afhankelijk van de leverancier/implementatie van een
middleware of EAI platform worden deze functionaliteiten
aangeboden deels of geheel [Ber96, Das99]. Afhankelijk van de
wensen van een organisatie zal een keuze gemaakt moeten

worden uit de verschillende middleware implementaties welke
er beschikbaar zijn (zie als voorbeeld de opsomming in 3.2) of
zal er zelf een middleware applicatie gemaakt moeten worden.
Web services bevatten zelf in principe zo min mogelijk
ondersteunende functionaliteiten, ze gebruiken de
functionaliteiten van de onderliggende middleware hiervoor
[Alo04].
4.7 Ontwikkelingstijd
De ontwikkelingstijd per systeem, welke komt kijken bij de
verschillende architecturen, heeft een zeer sterke relatie met het
aantal systemen. Zo kan een point-to-point oplossing snel in
elkaar gezet worden bij een klein aantal systemen, maar loopt
de hoeveelheid code exponentieel op bij meerdere systemen
zoals weergegeven in paragraaf 3.1.
Het installeren van een conventionele middleware oplossing
kost is het begin veel tijd door de configuratie van het geheel.
Het aansluiten van systemen op deze middleware opstelling
kost bij elk opvolgend systeem iets meer tijd, doordat de
configuratie van andere systemen aangepast moeten worden om
berichten te kunnen ontvangen en versturen naar het nieuw
aangesloten systeem. De ontwikkelingstijd neemt niet zo
dramatisch toe als bij meerdere systemen op een point-to-point
architectuur. De ontwikkelingstijd per systeem is met weinig
systemen erg hoog door de initiële configuratie, deze neemt af
als er meer systemen aangesloten worden en zal weer oplopen
als er erg veel systemen op worden aangesloten door de
additionele configuratie welke plaats moet vinden bij systemen
waar een nieuw systeem mee te maken krijgt.
Bij een EAI Platform kunnen systemen makkelijk aangesloten
worden en hoeven er erg weinig aanpassingen gemaakt te
worden als er nieuwe systemen op het platform worden
aangesloten. Bij een groot aantal systemen is de
ontwikkelingstijd daarom lager dan bij conventionele
middleware.
Web services maken gebruik van middleware voor veel van de
ondersteunende functionaliteit, waardoor de ontwikkelingstijd
van het geheel (web services + onderliggende lagen) hoog zal
liggen. Naarmate er meer organisaties connecties onderhouden
met de organisatie, en er dus door de standaardisatie van web
services geen aparte logica opgenomen hoeft te worden, neemt
de ontwikkelingstijd per systeem ten opzichte van een integratie
van losse middleware platformen tussen organisaties af.
4.8 Performance
Verschillende architecturen hebben verschillende maten van
overhead. In een poin-to-point architectuur met weinig
systemen is er alleen de overhead van een wrapper welke de
berichten van de onderliggende legacy systemen omvormt naar
een gemeenschappelijk protocol. Naarmate er meer integratie
logica en ondersteunende faciliteiten en meer systemen in de
integratie opgenomen worden loopt ook de overhead
exponentieel op.
Middleware oplossingen faciliteren deze connecties en zorgen
met behulp van ondersteunende faciliteiten als load balancing
weer voor minder bottlenecks. EAI platformen hebben door hun
publisher/subscriber aanpak meer overhead doordat het
platform alle berichtgeving tussen de systemen afhandelt.
Web services zijn geheel gebaseerd op standaard interfaces
waarbij de berichten van het onderliggende middleware
platform weer omgezet moeten worden naar deze standaard, wat
weer meer overhead levert.
4.9 Uitbreidbaarheid
De uitbreidbaarheid van de verschillende architecturen is reeds
duidelijk vertolkt door paragraaf 4.3. Hier wordt duidelijk
gemaakt dat point-to-point systemen erg slecht schaalbaar zijn.
Daarnaast zijn conventionele middleware oplossingen beter
schaalbaar, maar toch gelimiteerd doordat bij aanpassingen veel
configuratie bestanden aangepast moeten worden.
EAI Platformen zetten een stap in e goede richting door het
publisher/subscriber model, welke ervoor zorgt dat er makkelijk
nieuwe systemen toe te voegen zijn. Web services zijn
makkelijk uitbreidbaar door hun standaardisatie.
4.10 Scope
De verschillende architecturen zijn ontwikkeld om
verschillende systemen met elkaar te integreren en bezitten
hiervoor de nodige functionaliteit. Zo kan bij point-to-point
maar een erg beperkt aantal homogene systemen worden
geïntegreerd, waarbij de ontwikkelaar geheel verantwoordelijk
is voor de integratie logica en ondersteunende functionaliteiten.
De kosten lopen hoog op en de performance loopt snel terug als
er te veel systemen worden aangesloten. Hierdoor is deze het
best geschikt in een kleine scope – binnen afdelingen van een
organisatie.
Middleware kan meerdere homogene systemen integreren,
heterogene systemen worden beschikbaar gemaakt door middel
van wrappers, maar deze is ontwikkeld om de communicatie te
ondersteunen van systemen in de resource laag – welke het dus
niet standaard geschikt maakt om het bedrijfsproces te
integreren. Middleware bevat de nodige integratie logica en
ondersteunende faciliteiten om de communicatie tussen een
statische set systemen te ondersteunen. En is om deze redenen
het meest geschikt om te gebruiken binnen een afdeling.
Een EAI Platform is een uitbreiding van middleware, welke
geschikt gemaakt is om verschillende soorten middleware aan
elkaar te koppelen. Door de schaalbaarheid en de
koppelingsmogelijkheden van het EAI Platform kan deze
worden gebruikt om het hele bedrijfsproces te integreren.
Er is daarentegen een groot verschil in de manier van
communiceren tussen verschillende systemen in de organisatie
en tussen organisaties (firewalls / vertrouwen / verschillende
middleware oplossingen). Hierdoor is een EAI Platform niet de
beste oplossing voor interorganisatorische integratie. Web
services bieden een oplossing om integratie tussen organisaties
te ondersteunen door standaarden. Door de standaard interfaces
welke geboden worden door web services, kunnen organisaties
gemakkelijk de informatie uitwisselen welke ze willen. Web
services zijn daarom erg geschikt voor interorganisatorische
integratie.
Door middel van composite web services kunnen verschillende
geïntegreerde systemen als een geïntegreerd component
aangeboden worden. Hierbij kunnen verschillende organisatie
samenwerken om een geïntegreerde dienst aan te bieden.
Hierbij is er dus geen sprake van 1 cliënt en 1 provider, maar
bestaat de provider uit verschillende losse andere web services.
CONCLUSIE
In dit paper zijn vijf verschillende architecturen besproken om
al dan niet heterogene legacy systemen te integreren. Deze
legacy systemen zijn behandeld aan de hand van verschillende
variabelen, waarmee deze architecturen verdeelt zijn in hun
scope (situatie).
Een organisatie wil verschillende systemen integreren op
verschillende niveaus. Als deze dat wil doen met een beperkt
aantal systemen, welke in een enkele resource management laag
zitten (in een afdeling), dan is het vaak het voordeligste om

gebruik te maken van een point-to-point systeem. Deze kan snel
opgezet worden en biedt vaak voldoende functionaliteit voor
deze schaal. Het is daarentegen ook mogelijk om te kiezen voor
een middleware oplossing – deze oplossing biedt veel meer
uitbreidbaarheid, schaalbaarheid en ondersteunende
functionaliteit voor de organisatie. Daarbij is het mogelijk in
een later stadium gebruik te maken van nieuwe ‘lagen’ zoals
web services of eenzelfde ‘merk’ middleware om uit te breiden.
Als een organisatie verschillende afdelingen met elkaar wil
integreren (intraorganisatorische integratie, bedrijfsproces
integratie), dan kan er beter gekozen worden voor een EAI
platform. Dit platform is in staat te communiceren met andere
EAI platformen en kan door zijn publisher/subscriber logica
makkelijk uitgebreid worden. De kosten van zo’n systeem zijn
vooral laag als er vele afdelingen in een ‘workflow’
geïntegreerd moeten worden. Ook dit EAI platform is uit te
breiden met nieuwe lagen als web services en door middel van
adapters met vele middleware of EAI platformen te integreren.
Tussen organisaties gelden strikte regels omtrent de informatie
welke uitgewisseld mag worden. Daarnaast gebruiken
verschillende organisaties verschillende soorten EAI platformen
of middleware, wat ertoe zou leiden dat voor elke organisatie
waarmee geïntegreerd zou worden adapters of zelfs middleware
implementaties opgenomen moeten worden in de eigen
organisatie. Deze zouden dan weer via een omweg (een aparte
extra middleware laag) gekoppeld kunnen worden aan de
bestaande middleware. Dit zorgt uiteraard voor een grote
overhead en complexiteit. Web services standaardiseren de
communicatie tussen organisaties. Web services zijn weinig
meer dan een extra laag bovenop bestaande middleware
oplossingen, welke de ondersteunende functionaliteiten en
integratie logica bevatten, welke het mogelijk te maken om
volgens gemaakte regels te communiceren tussen organisaties.
Om deze redenen is het voor een organisatie het verstandigst
om gebruik te maken van een web service laag bij de integratie
van de supply chain.
Als organisaties gezamenlijk een gecombineerde dienst aan
willen bieden kan dit gerealiseerd worden met composite web
services. Deze maken het mogelijk om complexe diensten te
creëren welke bestaan uit losse web services van verschillende
organisaties.
In dit paper worden verschillende mogelijke architecturen
vergeleken welke door een organisatie gebruikt kunnen worden
als leidraad voor de integratie van hun legacy systemen. Legacy
systemen komen hedendaags nog erg veel voor aangezien er
niet al te lang geleden grote investeringen in deze systemen zijn
gedaan. Geleidelijk zullen deze legacy systemen wel vervangen
worden, maar op dit moment wegen de kosten van het
vervangen nog niet op tegen de kosten van het integreren van
deze systemen.
REFERENTIES
[Alo04] G. Alonso, F. Casati, H. Kuno, V. Machiraju, “Web
services – Concepts, Architectures and Applications”,
Springer, Berlin, 2004
[Ber96] P.A. Bernstein, “Middleware”, Communications of
the ACM, Vol 39, No. 2, feb. 1996
[Cal99] A. J. O’Callaghan, “Focus Issue on Legacy
Information Systems and Business Process Change:
Migrating Large Scale Legacy Systems To
Component-Based and Object Technology: The
Evolution of a Pattern Language” Comm. Of
Association for IS, Vol. 2, Article 3, July 1999
[Chi01] C. C. Chiang, “Wrapping legacy systems for use in
heterogeneous computing environments”, Information
and Technology, 2001 (vol. 43, issue 8), 2001, p 497-
507
[Chi01-2] C. C. Chiang, “A Distributed Computing
Architecture for Leveraging Software Reengineering
Systems”, SAC2001, Las Vegas, NV, 2001
[Das99] E.M. Dashofy, N. Medvidovic, R. N. Taylor, “Using
off-The-Shelf Middleware to Implement Connectors
in Distributed Software Architectures”, ICSE, Los
Angeles, 1999
[Emm00] W. Emmerich, “Software Engineering and
Middleware: A Roadmap”, Proceedings of the
Conference on The Future of Software Engineering,
Ireland, p117-129, 2000
[Jur00] M.B. Juric, I. Rozman, M. Hericko, T. Domajnko,
“Integrating legacy systems in distributed object
architecture”, ACM SIGSOFT Software Engineering
Notes, (vol. 25, issue 2), 2000, 35-39
[Lid00] S.W. Liddle, H.C. Mayr, “Conceptual modeling for E-
business and the web”, Springer, Berlin, 2000
[Llo99] A. D. Lloyd, R. Dewar, R. Pooley, “Legacy
Information Systems and Business Process Change: A
Patterns Perspective”, Comm. Of Association for IS,
Vol. 2, Article 24, December 1999
[Mec01] M. Mecella, B. Pernici, “Designing Wrapper
Components for e-services in integrating
heterogeneous systems”, The VLDB Journal, (vol. 10,
issue 1), 2-15, 2001
[Mon00] S. A. Mondal, K. D. Gupta, “Choosing a Middleware
for Web-Integration of a Legacy Application”,
Software Engineering Notes, ACM Sigsoft, Vol. 25,
No. 3, 2000
[Ser02] D. Seriain, “Middleware and enterprise application
integration : the architecture of e-business solutions”,
Springer, London, 2002, 3rd ed.
[Sut02] J. Sutherland W. v.d. Heuvel, “Enterprise Application
Integration and Complex Adaptive Systems”,
Communications of the ACM, vol. 45, no. 10, 59-64,
October 2002
[Zou00] Y. Zou, K. Kontogiannis, “Web-based specification
and integration of legacy services”, IBM Centre for
Advanced Studies Conference, Proceedings of the
2000 conference on Collaborative research, 2000, p.
17-32