Hoofdstuk 5 – Middleware-infrastructuur
46
!" # $ % '&
In het vorige deel werd de netwerkinfrastructuur besproken. In het volgende deel zullen de applicaties besproken worden. In dit deel echter wordt de technologie besproken die gebruikt zal worden om deze verschillende componenten te integreren. In het verleden legden organisaties de nadruk op het snel uitwisselen van informatie met hun klanten, partners en leveranciers over het Internet. In de huidige wereld is dit echter niet meer voldoende. Er is behoefte aan een uniforme interface tot ongelijke systemen en een gemeenschappelijk transport van data, zowel binnen de organisatie als tussen de organisatie en het internet. Dit alles moet bovendien gebeuren op een betrouwbare en veilige wijze. De communicatie services die ontwikkelaars toelaten om de vele verschillende componenten in een e-business architectuur - zowel custom als off the shelf - samen te lijmen, noemen we middleware.
*( ,) .+ 0- ,/ .- 21 3- 5) 4 $6 8/ 7 :- ,9 $9 :; =) < ?6 !> )
Middleware kan gezien worden als het koppelingselement tussen architectuur en functionaliteiten. Het levert een uniforme interface tot ongelijke systemen en een gemeenschappelijk transport van data, zowel binnen de organisatie als tussen de organisatie en het internet, zonder dat hierbij een één op één koppeling (synchroon) tussen deze systemen tot stand wordt gebracht. Hierdoor wordt het eenvoudiger om applicaties en services te laten samenwerken zonder rekening te houden met afhankelijkheden tussen communicatie protocols, besturingssystemen en hardware platforms. Applicaties en services sluiten dan aan op de middleware-infrastructuur en laten het transport en omzetting van data afhandelen door de middleware. De term Enterprise Application Integration (EAI) wordt steeds vaker gebruikt om naar middleware te verwijzen. EAI is echter geen technologie, maar een discipline of activiteit die tot doel heeft ondernemingsbreed applicatieintegratie te bewerkstelligen met als doelstelling een optimale ondersteuning van de business processen te verwezenlijken. Middleware is hierbij natuurlijk van groot belang. EAI is geen nieuwe ontwikkeling, alleen een relatief nieuwe term voor de zojuist beschreven werkzaamheden. Transacties via Internet zijn een belangrijke drijfveer voor ontwikkelingen op het gebied van middleware. Het alternatief voor middleware is het hard integreren van applicaties en services (de zogenaamde spaghetti-architectuur). Dit betekent in de regel dat de programmacode van elk systeem toegevoegd moet worden aan elk van de te koppelen systemen en vice versa. Middleware fungeert daarentegen als 'onafhankelijke derde', als tolk tussen systemen, onafhankelijk van de omgeving waarin de middleware werkt. Applicatie A
Applicatie B
Applicatie C
…
…
Middleware Infrastructuur Service α
Netwerk Infrastructuur
Figuur 5-1: Middleware Hoewel XML (eXtended Mark-up Language) zich tracht te profileren als de oplossing voor het bekomen van interoperabiliteit, is er tot op heden nog geen algemeen aanvaarde standaard voor middleware. 46
Hoofdstuk 5 – Middleware-infrastructuur
$;0;:)$/
4 6$/87-39 9$;3) <6?>!)
47
E-business stelt hoge eisen aan de waardeketen. Informatiestromen tussen de diverse systemen van de keten moeten vlekkeloos verlopen. Integratie van de keten is het adagium. Integratie stelt hoge eisen aan de onderlinge samenwerking tussen diverse applicaties en services. Het doel van deze uitgebreide communicatiemogelijkheden tussen applicaties is het verbeteren van het reactievermogen, het versnellen van de communicatie tussen business partners en het versnellen van de interne processen van de organisatie. Dit is de rol van middleware. Vanuit procesoogpunt zijn drie belangrijke rollen voor middleware te onderscheiden: • • •
Datadeler. Vele applicaties hebben dezelfde data nodig. Voor het gebruik van centrale data door diverse applicaties is een interfacelaag nodig. Middleware is een oplossing voor uniforme communicatie met centrale databases. Procesregisseur. Veel applicaties vormen een schakel in de keten. Het opeenvolgend verwerken en vasthouden van data, en het wegschrijven in de juiste databases, is van groot belang. Middelware kan een belangrijke regisseursrol vervullen bij dit proces. Servicemakelaar. Data moet veelal gecontroleerd, opgedeeld, samengevoegd of in nieuwe formaten omgezet worden. Dit vindt veelal plaats binnen applicaties. Vaak zijn deze services nagenoeg identiek en kunnen dus ook worden losgemaakt en als middleware fungeren. In deze rol wordt middleware veelal geassocieerd met het fenomeen midoffice.
Het bepalen van bovenstaande rollen van middleware, en eventuele andere, is van belang om niet te vervallen in een reeks van middleware-oplossingen, maar het overzicht op de gehele digitale keten te bewaren. Middleware hoort een aandachtspunt te zijn bij de architectuur, bij het vertalen van de complete, veelal complexe stromen van businessprocessen naar een digitale blauwdruk. Deze rollen zullen gebruikt worden bij het bepalen van de geschiktheid van het Linux platform als middleware-infrastructuur.
4 )?> - 1
Om dit deel overzichtelijk te houden, word er getracht categorieën met verschillende types van middleware te onderscheiden. Het verschil tussen deze categorieën is echter niet altijd even duidelijk: bepaalde middleware software biedt ondersteuning voor meerdere categorieën. Zo omvat BEA Tuxedo zowel transaction processing als message queuing. Er wordt een onderscheid gemaakt tussen de volgende categorieën: • • • • •
Middleware op basis van berichten (Message Oriented Middleware - MOM) Externe Procedure-aanroepen (Remote Procedure Calls - RPC) Object Request Broker (ORB) Microsoft Component Object Model (COM) Common Object Request Broker Architecture (CORBA) Database middleware: Remote Data Access (RDA) Transaction Processing (TP) en Applicatie servers Transaction Processing Monitors (TPM) Applicatie servers
Het is belangrijk op te merken dat elk type middleware ontworpen is voor het vervullen van een specifieke opdracht. De keuze van middleware is daarom afhankelijk van de behoeften van de onderneming. Het is best mogelijk dat één onderneming meerdere middleware technologieën gebruikt. Er is geen “one size fits all” oplossing.
47
Hoofdstuk 5 – Middleware-infrastructuur
$/ $; -3)
48
Het vorige hoofdstuk toonde aan dat Linux mogelijkheden biedt tot het bouwen van een degelijke netwerkinfrastructuur met aandacht voor open standaarden. Dit is echter onvoldoende ter ondersteuning van e-business. Verschillende applicaties en services moeten kunnen samenwerken door een uniforme interface tot ongelijke systemen en een gemeenschappelijk transport van data, zowel binnen de organisatie als tussen de organisatie en het Internet. Middleware biedt hiertoe mogelijkheden. In tegenstelling tot de netwerkinfrastructuur, zijn de meeste middleware oplossingen voor Linux commercieel van aard. Meestal gebruiken deze oplossingen wel open standaarden. Recentelijk zijn er ook enkele Open Source initiatieven rond middleware gestart. Meestal zijn deze gebaseerd op Java, of vormen ze een uitbreiding van het Apache project of één van de vele Open Source programmeertalen. Een eerste type van middleware dat besproken werd was Message Oriented Middleware. Hierdoor kunnen programma's op verschillende systemen boodschappen met elkaar uitwisselen. Linux biedt ondersteuning voor berichtuitwisseling (Messaging), transformatie en monitoren van berichten, en workflow. Externe procedure-aanroepen of Remote Procedure Calls, gespecificeerd is de OSF DCE en ONC RPC Open standaarden, zijn een veel gebruikte vorm van middleware op het Linux platform, maar worden steeds meer vervangen door Object Request Brokers. Op vlak van deze Object Request Brokers zijn zowel het Microsoft Component Object Model (COM) als de OMG Common Object Request Broker Architecture (CORBA) op Linux vertegenwoordigd. Op vlak van Database Middleware beschikt Linux naast bedrijfseigen varianten, over zowel ODBC als JDBC. Deze maken het eenvoudiger om data op te vragen uit verschillende types van databases, op verschillende platformen en/of in meerdere locaties. E-business vereist soms meer dan enkel de mogelijkheid om te communiceren met een database. Er is behoefte aan database-systemen die de ACID eigenschappen ondersteunen. Transaction Processing (TP) Monitors, veelal geassocieerd met Applicatie servers, leveren een dergelijke omgeving. Het aanbod van TP Monitors is pas recentelijk op gang gekomen door de beschikbaarheid van high-end databases. De Open Source varianten richten zich vooral op Open Source databases. Linux biedt dus mogelijkheden tot het uitbouwen van een degelijke middlewareinfrastructuur, die bovendien gebaseerd is op open standaarden. Er bestaan middleware oplossingen op basis van berichten, externe procedure-aanroepen, Object Request Broker, Remote Data Access, Transaction Processing en Applicatie servers. De huidige populariteit van middleware op Linux is waarschijnlijk het gevolg van de aandacht voor open standaarden. Deze trend wordt bevestigd in een IDC marktonderzoek1 van 5 Juni 2001 dat concludeerde dat de omzet van middleware voor Linux zes maal sneller zou stijgen dan de gemiddelde omzet van Linux over de periode 2000-2005.
1
IDC, 2001 Worldwide Software Market Forecaster, 5 Juni 2001
48
Hoofdstuk 5 – Middleware-infrastructuur
49
!" #$% & ')(#+*,.-/10 Door middel van Message-Oriented Middleware (MOM) kunnen programma's op verschillende systemen boodschappen met elkaar uitwisselen. Daarbij kunnen ze wachten op antwoord (synchrone communicatie), of gewoon verder functioneren in afwachting van andere boodschappen (asynchrone communicatie). De boodschappen die bij een bepaald subsysteem aankomen, blijven opgeslagen in een wachtrij (queue) alvorens te worden verwerkt. MOM is een geschikte oplossing voor peer-to-peer-communicatie, maar ook voor client/server-systemen die gebruik maken van distributed processing. In deze thesis wordt een onderscheid gemaakt tussen ondersteuning voor berichtuitwisseling (messaging), transformatie en monitoren van berichten, en workflow. Daarnaast zal er eveneens behoefte zijn voor koppelvlakken met andere pakketten (zogenaamde adapters). Workflow Integration MOM Basis MOM Figuur 5-2: Message Oriented Middleware
2354637498;: <>=?A@ BC=>D:>E :GF!HJI IG?LK =?7ENMGOBA=: DGEPB7QRES@T@U=V E :UF Ondersteuning voor berichtenuitwisseling vormt de basis van Message Oriented Middleware en levert de mogelijkheid tot een connectieloze, asynchrone transactionele message store-enforward die dienst kan doen als de kern van een Message Brok er (zie 5.1.2). Linux biedt ondersteuning voor berichtenuitwisseling met IBM MQSeries (www.ibm.com), BEA MessageQ (www.bea.com/products/messageq), TIBCO Rendezvous (www.tibco.com) en Talarian SmartSockets (www.talarian.com). Naast deze commerciële pakketten zijn er tevens Open Source Open Source pakketten zoals XmlBlaster (www.xmlblaster.org) en Java Open Reliable Asynchronous Messaging (www.objectweb.org/joram)
2 53 64 N3 ! W X Z? Y U: G@ ,[ GI ]? ^ \ _Y `B NE = = : \ GI : PE AB I Z? = a : JH GY b : K = 7? NE M c O CB G= :
Message Brokering is het transformeren en monitoren van berichten. Dit was tot voor kort een aanpak bij het gebruik van middleware, maar is nu een product dat op eigen benen staat. Message Broker services omvatten bijvoorbeeld: message queuing, message dictionary, message warehouse, message transformation, message routing, en mogelijkheden tot systeembeheer. Velen leveren eveneens een publish-and-subscribe service. Het transformeren en monitoren van berichten op Linux kan gebeuren met IBM MQSeries Integrator (www.ibm.com), EntireX Broker (www.softwareag.com) en een combinatie van TIBCO MessageBroker en Hawk (www.tibco.be). MessageBroker levert transformatie van berichten. Hawk biedt mogelijkheden tot het monitoren en beheren van berichten. EntireX Broker levert een set van platform- en transportonafhankelijke communicatieservices die een variëteit aan gedistribueerde applicaties mogelijk maken door messaging concepten. In tegenstelling tot de meeste queuing systemen zijn er verscheidene communicatiemodellen mogelijk: synchroon of asynchroon, conversational of stateless, 49
Hoofdstuk 5 – Middleware-infrastructuur
50
request/reply of peer-to-peer. Hierdoor kan EntireX Broker voldoen aan de behoeften van elke applicatie. In multi-tier omgevingen kan asynchrone messaging hulp bieden waar synchrone messaging de performantie kan doen dalen door objecten die vast zitten tussen requests en responses.
2 53 64 3 GI ? [ NV I Q
Y : Y F G= \ G= : B
Workflow middleware is de drijvende kracht achter Business Process Management (BPM). Het ondersteunt het definiëren, creëren, ontplooien, uitvoeren, monitoren en beheren van business processen op een gestructureerde manier. Daarbij wordt het vaak toegepast bij het stroomlijnen van werkprocessen. Het is ook een bron van informatie voor toepassingen voor bedrijfsbesturing, omdat het gegevens over de bedrijfsprocessen oplevert. Het beheren van de workflow kan met behulp van Linux gebeuren door IBM MQSeries Workflow (www.ibm.com), of TIBCO InConcert en IntegrationManager (www.tibco.com). IntegrationManager ondersteunt bij het definiëren en beheren van geautomatiseerde business processen. InConcert laat de onderneming toe om klantgeoriënteerde processen, die steunen op handelingen van werknemers, te automatiseren. Het toewijzen van taken aan medewerkers met InConcert of MQSeries Workflow is flexibel. Door het vastleggen van de hiërarchische organisatie, de rollen die men kan uitvoeren, en de registratie van aan- en afwezigheid, is gegarandeerd dat taken op het juiste moment aan de juiste persoon worden toegewezen. Case voorbeeld: Kiala.com gebruikt Tibco MOM voor e-Logistics Het Belgische e-Logistics bedrijf Kiala, dat eerder reeds aan bod kwam in deze thesis voor het gebruik van Oracle op Linux, maakt gebruik van Message Oriented Middleware op basis van Linux. De basis van Kiala wordt gevormd door berichtenuitwisseling met Tibco RendezVous. Het transformeren en monitoren van berichten wordt vervolgens gedaan door Tibco Hawk. Tibco IntegrationManager wordt gebruikt om de processen binnen Kiala te beheren. Bron: www.kiala.com en www.tibco.com Door gebruik te maken van middleware componenten uit dezelfde familie, wordt het (her)inrichten van een proces relatief eenvoudig. Men hoeft zich tijdens de procesinrichting geen zorgen te maken in de koppeling met bestaande functies of toepassingen. Proces(her)inrichting begint met modelleren. De meeste middleware bevatten tools waarmee processen snel en doeltreffend gemodelleerd en geëxporteerd kunnen worden. Export naar de uiteindelijke workflow middleware is uiteraard mogelijk, maar minstens zo belangwekkend zijn de import- en simulatiemogelijkheden. Hiermee kan een bestaand model worden doorgerekend en kan het effect van wijzigingen nauwkeurig worden voorspeld. Een ideaal stuk gereedschap voor de moderne procesmanager. Workflow management staat of valt met het op de juiste plaats en tijd bij elkaar brengen van taken en resources. Hiermee heeft Workflow Middleware weinig moeite. Met de WebSphereadapters van MQSeries Workflow is het bijvoorbeeld mogelijk om standaard pakketten (ERP, CRM, HRM) te koppelen.
50
Hoofdstuk 5 – Middleware-infrastructuur
51
(%#bL & # G #+*
c0 Een variant van het basismodel voor het doorgeven van berichten is de externe procedureaanroep (Remote Procedure Call, RPC). De externe procedure-aanroep is een techniek waarbij twee programma’s op verschillende machines communiceren via een algemene syntaxis en semantiek voor procedure-aanroepen en returns. Een 'client' proces roept een functie aan bij de externe server en het proces dat de 'call' vervaardigd wacht totdat het de resultaten krijgt. Het aangeroepen programma en het aanroepende programma gedragen zich beide alsof het partnerprogramma wordt uitgevoerd op dezelfde machine. Dat wil zeggen: de procedure-aanroep wordt gebruikt voor de toegang tot externe2 diensten. Het programma dat de service aanvraagt kan dit doen zonder de netwerk details te kennen. De code roept een procedure op die zich bevindt op een extern systeem en de resultaten worden teruggegeven. RPC gebruikt het client/server model. Het programma dat de aanvraag verstuurt is de client en het programma dat de service verleent is de server. Zoals een gewone locale procedure-aanroep, is RPC een synchrone (gelijktijdige) operatie die vereist dat de aanvrager geschorst wordt totdat het resultaten van de externe procedure teruggegeven zijn. Het gebruik van lightweight processes of threads die dezelfde adresruimte delen laten echter toe dat meerdere RPC’s simultaan kunnen uitgevoerd worden. RPC’s werken goed voor kleine, eenvoudige applicaties waar de communicatie hoofdzakelijk point-to-point is (eerder dan one system to many). RPC’s zijn niet goed schaalbaar tot grote, bedrijfskritische applicaties omwille van hun synchrone aard. Bovendien laten RPC’s vele cruciale details over aan de programmeur. Voorbeelden hiervan zijn het afhandelen van netwerk- of systeemfouten, de ondersteuning van meerdere connecties, buffering en flow controle, en de synchronisatie tussen processen. De ontwikkeling van RPC standaards is de voorbije jaren niet significant, hoofdzakelijk omwille van de opkomst van Object Request Brokers (ORB). Deze worden besproken in het volgende deel.
1EN<
E : D
Het Linux platform levert twee belangrijke RPC oplossingen: OSF DCE en ONC RPC. Daarnaast zijn er nog enkele afgeleide RPC oplossingen en XML-RPC (www.xmlrpc.com), een verzameling van projecten die het RPC protocol implementeren in XML. De OSF (Open software Foundation) Distributed Computing Environment (DCE, beschikbaar op www.opengroup.org/dce) levert een RPC mechanisme, samen met IDL stub compilers; Kerberos voor het beveiligen en controleren van de toegang tot data; en een Directory server die het eenvoudiger maken om gedistribueerde bronnen te vinden. FreeDCE is een Linux versie van DCE en is beschikbaar op freedce.sourceforge.net. Het ONC RPC protocol van Sun Microsystems is eveneens beschikbaar op Linux. NFS is gebaseerd op dit protocol. ONC RPC vormt eveneens de basis voor JaRPC (www.nclabs.com), een RPC implementaie voor Java; PowerRPC (www.netbula.com), een RPC implementatie voor C/C++; en ILU (www.parc.xerox.com/istl/projects/ILU) of Inter-language Unification, een RPC implementatie voor onder andere C/C++, Python, Java, en Perl.
2
Dit is echter niet noodzakelijk: RPC werkt eveneens voor de communicatie tussen processen op dezelfde machine.
51
Hoofdstuk 5 – Middleware-infrastructuur
-/ &$(
52
c_ ( *]-
)0
Toen objectgeoriënteerde technologie belangrijker werd bij het besturingssysteemontwerp zijn ook client/server-ontwerpers deze benadering gaan toepassen. Hierbij verzenden clients en servers berichten heen en weer tussen objecten. Bij object-georiënteerde systemen wordt de scheidingslijn tussen data en programma's gesloopt: een object bevat zowel informatie als bewerkingen (insiders spreken van state en behaviour). De objectcommunicatie kan afhankelijk zijn van een onderliggende berichten- of RPC-structuur of rechtstreeks boven op de objectgeoriënteerde mogelijkheden van het besturingssysteem worden ontwikkeld. Een client die een dienst nodig heeft, verzendt een verzoek naar een object request broker (ORB), een ‘makelaar in objectverzoeken’, die werkt als een overzicht van alle externe diensten die beschikbaar zijn in het netwerk. De broker roept het juiste object aan en geeft daaraan alle relevante gegevens door. Vervolgens behandelt het externe object het verzoek en verzendt het een antwoord naar de broker, die het antwoord doorzendt naar de client. De ondersteuning van ORB in een netwerk laat de client toe om een service aan te vragen zonder te weten waar de server zich in het gedistribueerde netwerk bevindt, en/of hoe de interface tot die server er uit ziet. Componenten kunnen elkaar herkennen en interface informatie uitwisselen tijdens hun uitvoering. Het succes van de objectgeoriënteerde benadering is afhankelijk van de standaardisatie van het objectmechanisme. Helaas bestaan er op dit gebied enkele concurrerende ontwerpen. Eén daarvan is het Component Object Model (COM) van Microsoft. Deze benadering wordt ondersteund door Software AG, dat DCOM voor Linux heeft ontwikkeld. Een concurrerende benadering, die werd ontwikkeld door de Object Management Group (OMG, terug te vinden op www.omg.org), is de Common Object Request Broker Architecture (CORBA). Java’s Remote Method Invocation (RMI) kan eveneens beschouwd worden als een ORB. RMI is echter hoofdzakelijk nuttig bij het vereenvoudigen van de communicatie tussen Java programma’s en houdt zich niet bezig met andere programmeertalen, terwijl DCOM en CORBA wel andere talen ondersteunen. RMI is een manier waarop Java-objecten (software componenten) elkaar kunnen aanroepen. Hiermee is het mogelijk Java-objecten die zich op verschillende computers bevinden te laten samenwerken. RMI werkt alleen met softwarecomponenten die in Java geschreven zijn (om ook niet-Java programma’s te kunnen aanroepen moet RMI over IIOP (zie 5.3.2 Corba) worden gebruikt). Omdat Java geschikt is voor vrijwel alle hardware-platforms kan er met behulp van RMI een gedistribueerd systeem over meerdere hardware platforms worden gerealiseerd.
2 3 374 ) I \ $ I : = c : B ; 8 K = M B
I >< = V L 8
Het Microsoft Component Object Model (COM) wordt gekenmerkt door het gebruik van binaire interfaces waardoor dit model zich grotendeels taal-onafhankelijk mag noemen. Het is een component model dat de meeste OO principes goed ondersteunt, behalve overerving. Opvallend is het gebrek aan netwerk transparantie: er is locatie transparantie voor componenten onderling op een enkele computer op voorwaarde dat het Microsoft Windows platform gebruikt wordt. Tussen verschillende computers onderling is er, ondanks het RPCprotocol waarop COM communicatie steunt, geen netwerk communicatie voor COM mogelijk. Hieraan probeert men, zonder veel succes, een mouw aan te passen door middel van een uitbreiding van COM: Distributed COM (DCOM). Communicatie tussen verschillende componenten die op verschillende computers verblijven via een netwerk verbinding is nu wel mogelijk, maar van transparantie is nog altijd geen sprake.
52
Hoofdstuk 5 – Middleware-infrastructuur
53
Microsoft’s DCOM wordt beschikbaar gesteld voor Linux door Software AG via EntireX DCOM3 (www.softwareag.com/entireX). Dit product biedt een oplossing voor allerlei integratie problemen en laat toe om verschillende componentarchitecturen door elkaar heen te gebruiken. Het is bijvoorbeeld mogelijk om binnen Windows 2000 een object op te roepen op Linux. Ook het ongekeerde is mogelijk. Het DCOM gedeelte op Linux is bovendien vrij downloadbaar, en kan gecombineerd worden met CORBA via Software AG EntireX Communicator. DCOM voor Linux biedt locatie transparantie voor componenten onderling op één enkele computer. Netwerk transparantie wordt toegevoegd bij de introductie van EntireX Communicator. Dit is een tool om bestaande toepassingen te integreren als DCOM objecten. Op dit moment zijn er bijvoorbeeld diensten zoals Transactiebeheer en Object Pooling beschikbaar. De beveiliging waar COM op steunt is grotendeels platform-afhankelijk en afhankelijk van het gebruikte communicatie protocol. Net zoals in Microsoft DCOM, is de RPC die Linux DCOM gebruikt tevens verrijkt met verschillende beveiligingsniveaus en wordt secure RPC genoemd. In tegenstelling tot Microsoft DCOM, biedt Linux DCOM echter geen ondersteuning voor versiebeheer van componenten.
2 3 3NW ) I \ \ GI : ; 8 K = M B = D "= @ B L ? I = ? Z? M O E CB >= _M AB D Z? =
8
CORBA (Common Object Request Broker Architecture, beschikbaar op www.corba.org) is een architectuur en specificatie voor het maken, distribueren en beheren van gedistribueerde objecten (over verschillende computersystemen verspreide, op zichzelf staande software modules). CORBA is opgesteld door de Object Management Group (OMG), een samenwerkings-verband van meer dan 700 ICT leveranciers. Zowel de International Organization for Standardization (ISO) als X/Open hebben CORBA uitgeroepen tot de standaard architectuur voor gedistribueerde objecten. Het grote verschil met COM is dat CORBA een specificatie is en geen implementatie. CORBA gebruikt een Interface Definition Language (IDL) waarmee het de interface van componenten specificeert. Door middel van deze interface definitie kan men elke taal gebruiken voor de implementatie waarvoor de desbetreffende CORBA Object Request Broker (ORB) een ‘mapping’ voorziet. CORBA is dus grotendeels taalonafhankelijk. CORBA ondersteunt de OO (Object Oriented) principes door de IDL, inclusief overerving. Opmerkelijk is dat er ook veel CORBA mappings bestaan voor niet OO-talen. Het gebied waarin CORBA uitblinkt is de transparantie die deze kan voorzien door middel van de ORB. Netwerk transparantie evenals migratie transparantie worden goed ondersteund. De mogelijkheden om verschillende ORB’s met elkaar te laten communiceren over een netwerkverbinding breidt deze transparantie nog uit over netwerken. Standaard wordt er ook een protocol voor inter-ORB communicatie over een TCP/IP connectie gedefiniëerd, met name het Internet Inter-ORB Protocol (IIOP), afgeleid van het General Inter-ORB protocol (GIOP), een protocol waardoor ORB software van de ene leverancier kan communiceren met ORB software van een andere leverancier. Er zijn heel wat diensten beschikbaar voor CORBA, beschreven in de thesis ‘Component Based Software Development for the Internet’ (lumumba.luc.ac.be/kris/thesis) die Kris Luyten tijdens het academiejaar 2000-2001 schreef aan het Limburgs Universitair Centrum (www.luc.ac.be). Spijtig genoeg is er geen echt versie-beheer, maar wordt de verantwoordelijkheid in handen van de ontwikkelaar gegeven. CORBA ondersteund service transacties, maar geeft geen garanties voor de ondersteuning van geneste transacties. Er is zelfs een service voor licentie beheer, welke interessant is naar de praktische implementatie die gepaard gaat met deze thesis. 3
Meer documentatie is terug te vinden op http://www.softwareag.com/entirex/download/dcomlinux_611.pdf
53
Hoofdstuk 5 – Middleware-infrastructuur
54
Goede beveiliging definiëren in een specificatie is geen gemakkelijke opdracht, zeker als deze niet mag steunen op de veiligheid van het praktisch gebruik van programmeertalen of van de gastomgevingen. Een eerste vereiste voor CORBA beveiliging is de authenticatie van componenten. In het algemeen veronderstellen zowel CORBA als DCOM dat het systeem beschikt over een betrouwbare communicatielaag en houden ze zich niet bezig met de problemen die het gevolg zijn van het slecht functioneren van deze laag. Reeds vroeg besefte OMG dat CORBA’s request-reply communicatie niet geschikt was voor het bouwen van gedistribueerde bedrijfskritische applicaties. Sommige CORBA leveranciers voegden daarom eigen bedrijfseigen extensies toe aan hun producten, teneinde deze tekortkoming weg te werken. De OMG beschreef de CORBA Event Service, een set van services die zich bevinden bovenop CORBA, en die de meeste extensies die aangebracht waren door de leveranciers in het CORBA model bracht. In 1998 keurde OMG de Asynchronous Messaging Service goed. Deze service wordt echter niet veel toegepast in de hedendaagse CORBA implementaties. Case voorbeeld: www.weather.com gebruikt MICO middleware voor een 24x7 service "The Weather Channel (TWC – www.weather.com) distribueert locale weergegevens met behulp van Linux, MICO en S-Lang. Linux werd gekozen omwille van de betrouwbaarheid. MICO, eveneens Open Source, is een CORBA 2.x implementatie die dienst doet als middleware. MICO wordt onderhouden door de ‘Johann Wolfgang Goethe Universitaet – Frankfurt an Main’ (www.informatik.uni-frankfurt.de) en is beschikbaar op www.mico.org. Tenslotte wordt het geheel geconfigureerd en beheerd met behulp van S-Lang. Dit is een Open Source scripting taal die kan samenwerken met C en C++ programma’s. Weather.com levert een 24x7 service sinds 10/10/2000 en heeft gedurende haar levensduur een continue service weten te bieden. Bron: linuxpr.com/releases/2675.html Op Linux zijn er verscheidene ORBs beschikbaar. Zo levert IBM (www.software.ibm.com) Component Broker en WebSphere ORBs op basis van CORBA. Andere ORBs zijn terug te vinden bij BEA ObjectBroker (BEA Systems), Visibroker (www.inprise.com), IONA Orbix (www.iona.com), Arachne (www.arachne.org) en ORBacus (www.ooc.com) dat vroeger bekend stond als OmniBroker. Naast deze commerciële pakketten zijn er tevens Open Source pakketten zoals OmniORB (www.omniorb.org) en MICO (het acroniem mico staat voor MICO Is CORBA) dat beschikbaar is op www.mico.org. In aanvulling op de basis functionaliteit bieden deze Open Source ORBs ook een object transactie service, data persistence en mogelijkheden tot beveiliging.
54
Hoofdstuk 5 – Middleware-infrastructuur
55
$(_ $( $( & & _ G !*
0 Database middleware is een set van technologieën en standaards die het opvragen van data uit verschillende types van databases, op verschillende platformen en/of in meerdere locaties, eenvoudiger maakt. Het levert de connectie tussen een applicatie en een database. Database middleware implementeert een RDA (Remote data Access) protocol voor het zenden van data manipulation language statements naar de juiste Database server. Nadat de Database server de aanvraag verwerkt heeft wordt het resultaat teruggezonden door RDA naar het verzoekende proces. Het RDA concept maakt het mogelijk applicaties te maken die beschikbaar gesteld kunnen worden over het Internet aan een client. Database Middleware wordt gekenmerkt door het heen en weer vervoeren van SQL en database gegevens tussen de applicatie en de database. Bovendien helpt het bij het garanderen van de beveiliging en het vermijdt dat applicaties direct moeten handelen met de database server. Database middleware is beschreven door verscheidene connectivity standaards zoals Open DataBase Connectivity (ODBC), Java DataBase Connectivity (JDBC) en produkt-specifieke standaards. Vele Database verkopers leveren hun eigen bedrijfseigen (proprietary) oplossing voor toegang tot hun database. Ze verenigen eigen middleware technologie in hun producten. Deze eigen middleware technologie levert meestal snellere toegangstijden (access times) omdat het geen externe translatiemechanismen moet gebruiken. Zo levert Kylix (www.borland.com/kylix) de DataSnap tool waarmee schaalbare Web service-enabled database middleware gebouwd kan worden die door standaard Web services en XML, DCOM of CORBA, kan samenwerken met databases zoals Oracle, Informix, IBM DB2, MySQL, PostgreSQL/Red Hat Database, en Borland InterBase. Deze thesis richt zich op open standaarden, waarvan ODBC en JDBC kort toegelicht zullen worden.
2 3 _ 73 9 4 8 $ G = : _Y AB Y "Y G@ = ) G I : : >= _M `B PE H PE B
8
ODBC is een verzameling van database access middleware drivers die programma’s toegang verleent tot de data in een database. ODBC definieert enkel de client zijde van de database connectiviteit. Voor de server zijde veronderstelt ODBC de aanwezigheid van een bedrijfseigen ODBC-driver (bv: SQL*Net voor Oracle). De databaseleverancier moet hiervoor dus een extra stuk software ontwikkelen (de ODBC-driver) waarmee de gegevens extern benaderd kunnen worden. ODBC drivers transformeren ODBC calls naar leverancier-specifieke access requests en responses. Dit heeft zowel voor- als nadelen: ODBC biedt een standaard interface, maar zonder rekening te houden met de eigenschappen van de bedrijfseigen middleware. Hierdoor consumeert ODBC relatief veel geheugen en vertraagt het de toegang tot de data in een database. Open Source ODBC-drivers voor Linux worden geleverd door het FreeODBC project (www.jepstone.net/FreeODBC). De meeste databases die eerder reeds besproken werden, leveren een ODBC-driver, zoals IBM (www.ibm.com), Oracle (www.oracle.com), Sybase (www.sybase.com) en Informix (www.informix.com). Tevens zijn er ODBC implementaties in enkele Open Source databases zoals bijvoorbeeld PostgreSQL en MySQL.
2 3 _ N3 W Y JH Y Y CB Y ; "Y G@ =
GI : : = _M `B PE H E B
JDBC is een verzameling van database access middleware drivers die Java applets, servlets of andere Java applicaties toegang verleent tot data van meerdere database omgevingen zoals onder meer Oracle en Sybase. De werking van JDBC is analoog aan ODBC. JDBC implementaties voor Linux zijn terug te vinden bij onder meer: Borland (www.borland.com), IBM (www.ibm.be), Sybase Direct Connect (www.sybase.com), Sybase Open Server Connect (www.sybase.com), BEA Logic (www.bea.com) en Oracle Web Server (www.oracle.com). Op de Web site www.javasoft.com/marketing/collateral/jdbc_ds.html vindt men een actuele lijst van leveranciers van JDBC drivers. 55
Hoofdstuk 5 – Middleware-infrastructuur
56
P #c &$(] # L & G # * c0 #
L & (7P ) "
In dit laatste hoofdstuk over Linux Middleware wordt er gekeken naar Transaction Processing monitors en Applicatie servers. Deze twee middleware technologieën worden samen besproken omdat transaction processing meestal gebeurt via een Applicatie server.
23 2374 X?ZY:U@GY M B E I:
?ZI M>= @T@ E :GF
I:>EPBAI?A@ CX
In tegenstelling tot de eerder besproken middleware technologieën worden Transaction Processing (TP) monitors niet gebruikt voor algemene program-to-program communicatie. TP monitors leveren een omgeving voor transactie-applicaties die toegang hebben tot databases. TP Monitors zijn traditionele database-systemen die ontworpen zijn om vele gebruikers tegelijkertijd te woord te staan, zonder belangrijke wachttijden. TP Monitors worden aangewend op grote computers zoals IBM-mainframes. Ze worden bijvoorbeeld in bancaire toepassingen gebruikt: wanneer een klant bijvoorbeeld een overschrijving doet, wordt de database aangepast en wordt er een bevestiging gestuurd naar de klant. Deze taken zijn deel van één enkele transactie. Honderden klanten voeren dergelijke transacties uit op hetzelfde ogenblik. Een transactie wordt gekenmerkt door de vier ACID eigenschappen: Atomicity, Consistency, Isolation en Durability. Een systeem dat niet voldoet aan deze eigenschappen kan leiden tot fouten in de database, met rampzalige gevolgen voor de onderneming in kwestie. •
Atomicity: De resultaten van het uitvoeren van een transactie (een groep SQL statements) slagen ofwel allemaal, ofwel falen ze als één eenheid.
•
Consistency: Een gedeelde bron (zoals een database) wordt getransformeerd van een geldige staat naar een andere geldige staat. Dit vereist een nauwkeurig toezicht van de security en integriteit van de database.
•
Isolation: De resultaten van een transactie zijn onzichtbaar voor andere transacties tot deze transactie volledig afgehandeld is.
•
Durability: De resultaten van een transactie zijn permanent en overleven toekomstige falingen van het systeem en/of media.
Thans zijn er van deze TP Monitors ook gedistribueerde varianten verkrijgbaar. Het gaat hier om de "remote data" variant van client/server. Distributed Transaction Processing (DTP) is een vorm van Transaction Processing die toelaat dat een transactie samengesteld is door meerdere applicaties die toegang hebben tot één of meerdere databases, op één of meerdere computers verspreid over een netwerk. DTP vertegenwoordigt een evolutie in de hedendaagse bedrijfskritische applicaties. Door het gebruik van DTP kunnen bijvoorbeeld databases in het hoofdkantoor en in de regionale kantoren gesynchroniseerd worden en simultaan geactualiseerd worden. DTP vereenvoudigt eveneens transaction processing tussen meerdere ondernemingen. DTP kan bijvoorbeeld ingezet worden bij het coördineren van computers van leveranciers en fabrikanten (cfr. Supply Chain Management). De meest bekende Transaction middleware voor Linux is waarschijnlijk BEA Tuxedo (www.bea.com/products/tuxedo). Andere pakketten zijn bijvoorbeeld Tecco (www.tecco.at), Tibco TIB/ActiveEnterprise (www.tibco.com), BEA WebLogic Tengah (www.bea.com), IONA OrbixOTM (www.iona.com) en Software AG EntireX (www.softwareag.com).
56
Hoofdstuk 5 – Middleware-infrastructuur
57
Naast deze commerciële TP monitors zijn zijn er sinds kort ook Open Source varianten zoals Java Open Transaction Manager (www.objectweb.org/jotm), FTPM4 (Free Transaction Processing Monitor – www.ftpm.org) en GTS5 (GNU Transaction Server). Bovendien is er ondersteuning van transaction processing voor de meeste databases, zoals bijvoorbeeld MySQL (www.mysql.com), PostgreSQL (www.postgresql.org).
2 3 2 N3 W
V NE M Y B NE = c=? JH = A? @
Applicatie servers zijn gericht op de realisatie van front-end integratie: de bouw van nieuwe eindgebruikers functionaliteit ten behoeve van interne en externe gebruikers gebaseerd op herbruikbare componenten. Applicatie servers worden meestal gebruikt in combinatie met één of meer Web servers om zo functionaliteit te leveren voor high-level services (zoals events en activatie); schaalbare eigenschappen, meestal geassocieerd met een object-gebaseerde transactie monitor (objects en connection pooling, clustering support, session fail-over, en andere high-availability eigenschappen); en de gedistribueerde transactiemanagement capaciteit die nodig is om meerdere resource managers (databases) automatisch te kunnen actualiseren. Voorbeelden van Open Source Applicatie servers voor Linux zijn de Zope Application Server (www.zope.com) en Enhydra (www.enhydra.org). Beiden ondersteunen XML, maar Zope richt zich op Python, terwijl Enhydra zich eerder richt op Java. Case voorbeeld: Yahoo! Real Estate gebruikt Zope HomeGain, beter bekend als Yahoo! Real Estate (realestate.yahoo.com), gebruikt de Open Source Zope Applicatie server ter realisatie van haar online makelaar in onroerend goed. Naast Zope wordt eveneens gebruik gemaakt van Remote Procedure Calls (RPC) met de Python RPC bibliotheek “ILU” (www.parc.xerox.com/istl/projects/ILU) die als Open Source ter beschikking gesteld wordt door Xerox PARC. Door gebruik te maken van de open Source programmeertaal Python en Zope’s Oracle binding voor Python (DCOracle), draait HomeGain RPC servers die data uit Oracle databases vertaald naar Python objecten, waarna deze benaderd worden door ILU RPC. Bron: http://www.zope.com/CaseStudies/homegain/ Naast deze Open Source Applicatie servers zijn er ook commerciële Applicatie servers zoals: IBM WebSphere (www.software.ibm.com), Allaire JRun (www.allaire.com), BEA WebLogic (www.bea.com/products/weblogic/), iPlanet Application Server (www.iplanet.com), Oracle Application Server (www.oracle.com), Borland AppServer (Borland (Inprise)), Allaire ColdFusion (www.allaire.com), Silver Stream Application Server (www.silverstream.com), en iPortal Application Server (www.iona.com). Alternatieven voor de grote Applicatie servers worden geboden door het Jakarta project (jakarta.apache.org), waarvan Tomcat (jakarta.apache.org/tomcat) waarschijnlijk het meest bekende subproject is. Dit is een Open Source oplossing voor Java ServerPages (zie hoofdtuk 6: secundaire applicaties). Tomcat wordt onder andere gebruikt in de Java Open Application Server (www.objectweb.org/jonas), die eveneens Open Source is.
4
Free Transaction Processing Monitor (FTPM) is in een pre-alpha staat van ontwikkeling. De broncode is vrij beschikbaar onder de GNU General Public Licence (GPL). 5 GTS (GNU Transaction Server) wordt ontwikkeld door Todd Graham Lewis ([email protected]) en heeft tot op heden nog geen b ruikbare Transaction Processing Monitor opgeleverd.
57
