Architecturen voor de Integratie van Legacy Systemen Martijn Kooreman Universiteit Twente, Nederland
[email protected] 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.
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.
1. INTRODUCTIE
2. DOEL
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].
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.
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
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 verantwoordelijkheid welke de wrapper heeft; deze bijvoorbeeld verantwoordelijk zijn voor het maken connecties met alle andere systemen, of dit overlaten een ander deel van de architectuur [Mec01].
van kan van aan
•
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].
•
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.
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.
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. Client
Browser
Information system – provider Web server
Presentation layer
adapter
Application Logic Layer client
Wrapper
legacy
client
Wrapper
legacy
client
Andere EAI Middleware
Wrapper
legacy
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.
Client Web service (organisatie x)
Composite web service (organisatie e)
Organisatie a Web service interface Access to internal sys.
Composite web service (organisatie d)
Web service middleware Service interface Integration logic
Composite Web service (organisatie c)
Web service (organisatie b)
Middleware (met middleware services)
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 Point-to-Point
Middleware
EAI Platform
Web service
Composite web service
Scope
Weinig objecten / binnen afdeling
Binnen afdeling
Intra organisatorisch
Inter organisatorisch
Inter organisatorisch
Communicatie mogelijkheden
1-1
1-1, 1-*
1-1, 1-n, 1-*
1-1, 1-n, 1-*
1-1, 1-n, 1-*
Complexiteit wrapper
Hoog
Laag
Laag
Laag
Laag
Dynamische veranderingen
Zo goed als onmogelijk
Laag
Door publisher/subscriber model
Component moet dezelfde interface hebben
Component moet dezelfde interface hebben
Gewenste Heterogeniteit
Homogeen
homogeen
homogeen
heterogeen
heterogeen
Integratie gemak
Laag bij veel nodes, anders hoog
Integratie logica verborgen voor programmeur
Makkelijk nieuwe stukken op aan te sluiten, veel werk bij weinig systemen
Veel werk overgelaten aan lagere middleware lichtgewicht
Veel werk overgelaten aan lagere middleware lichtgewicht
Kosten
Erg laag bij weinig objecten
Hoog bij weinig objecten
Laag per systeem (vaak veel objecten)
Laag door standaardisatie, wel middleware nodig
Laag door standaardisatie, wel middleware nodig
Ondersteunende functionaliteiten
Nee
Ja (afhankelijk van implementatie)
Ja (afhankelijk van implementatie)
Door onderliggende middleware
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
Overhead door standaard formaat
Uitbreidbaarheid
Erg laag
Laag
Goed
Hoog
Hoog
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.
[Ber96] P.A. Bernstein, “Middleware”, Communications of the ACM, Vol 39, No. 2, feb. 1996
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.
[Chi01] C. C. Chiang, “Wrapping legacy systems for use in heterogeneous computing environments”, Information and Technology, 2001 (vol. 43, issue 8), 2001, p 497507
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
[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-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 Ebusiness 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
