Een gedistribueerde applicatie biedt een aantal voordelen boven een traditionele client/server-applicatie, bijvoorbeeld op het gebied van schaalbaarheid, interactiviteit en beheer. Een software-engineer van Inforay belicht aandachtspunten en problemen bij het schrijven van een gedistribueerde applicatie.
Gedistribueerde of multi-tier applicaties bestaan uit tenminste drie lagen. De gebruikersinterfacelaag bevat alleen schermelementen. Omdat deze laag geen ‘businesslogica’ bevat is deze erg dun en leent zich goed voor implementatie in een Internet-omgeving. Voor het uitvoeren van de daadwerkelijke functionaliteit maakt de gebruikersinterfacelaag gebruik van de tweede en middelste laag, de applicatielaag. De opslag van de gegevens die in die applicatielaag worden gebruikt en gegenereerd, wordt verzorgd in de derde laag, de datalaag.
Het onderscheid tussen een gebruikersinterface- en een applicatielaag is het belangrijkste verschil tussen een gedistribueerde applicatie en een traditionele client/server-applicatie. Dit onderscheid biedt een aantal belangrijke voordelen.
Schaalbaarheid. Bij een groeiende behoefte aan verwerkingscapaciteit kunnen meerdere instanties van dezelfde gedistribueerde component worden ingezet. De capaciteitsbehoefte kan dan over die verschillende instanties worden verdeeld.
Beheer. De ‘dikke’ client van een client/server-applicatie wordt geïnstalleerd op de desktop-machine van iedere individuele gebruiker. De dunne gebruikersinterfacelaag van een gedistribueerde applicatie kan op een centrale locatie in het netwerk worden opgeslagen. Als er voor de verbinding tussen de client en de overige gedistribueerde componenten dan ook nog eens gebruik wordt gemaakt van Internet-technologie, kan de applicatie op een eenvoudige manier zowel door werknemers op kantoor als ‘onderweg’ worden gebruikt.
Interactiviteit. De applicatielaag kan actief nieuwe informatie doorsturen naar de gebruikers van de applicatie. In de bedrijfsregels in die laag kan worden vastgelegd dat bepaalde situaties directe aandacht van één of meer gebruikers vergen. Dit maakt het mogelijk een informatiesysteem te implementeren dat een snelle reactie op gebeurtenissen in een dynamische organisatie mogelijk maakt. Met een client/server-applicatie is dit lastiger te realiseren. De gemeenschappelijke component in zo’n applicatie is immers een database. Databases zijn ontworpen om een query van een gebruiker te beantwoorden, niet om op eigen initiatief nieuwe informatie en interessante informatie met die gebruiker uit te wisselen.
Integriteit. Referentiële integriteitsregels in de database zijn een middel om de correctheid en integriteit van de informatie in die database te bewaken. De uitdrukkingskracht van deze regels is niet erg hoog (‘een debiteur die voorkomt in de factuurtabel dient ook opgenomen te zijn in de klantentabel’). In de centrale applicatielaag van een gedistribueerde applicatie kunnen veel complexere regels worden vastgelegd en gehandhaafd (‘een klant verdient het predikaat ‘platinum’ indien hij vorig jaar tenminste 1000 exemplaren heeft afgenomen en geen betalingsachterstand heeft’). Een gedistribueerde applicatie biedt meer mogelijkheden voor het garanderen en bewaken van de beheerde informatie.
Ook bij Inforay hadden we deze voordelen voor ogen toen wij besloten om de nieuwste versie 3.x van onze gelijknamige applicatie als gedistribueerde applicatie te ontwerpen. Deze versie is begin 1999 gereed gekomen. De basis voor de gedistribueerde versie werd gevormd door de client/server versie 2.x van Inforay.
Hergebruik van bestaande code
Bij het migreren van een bestaande client/server-applicatie naar een gedistribueerde applicatie wordt de bestaande client-code uitgesplitst in een gebruikersinterface- en een applicatie-laag. Dit wordt bemoeilijkt door de sterke verwevenheid van de businesslogica en de afhandeling van de schermelementen in de gebruikersinterface. Meestal zijn de berekeningen die door de applicatie worden uitgevoerd direct uitgeprogrammeerd in de event-handlers voor de knoppen, invulvakken, keuzelijstjes en andere schermelementen van de gebruikersinterface.
Zelfs als het ontwerp van de client/server-applicatie een goede modulaire opzet heeft, blijft die verwevenheid parten spelen. De afzonderlijke bedrijfsregels zijn dan in aparte objecten of modules uitgewerkt. De gebruikersinterfacecode blijkt dan echter als een ‘lijmlaag’ voor die bedrijfsregels te fungeren. Ook die lijm zou een onderdeel van de applicatielaag moeten zijn en moet dus alsnog worden losgeweekt uit de gebruikers-interfacecode.
Een voorbeeld kan dit illustreren. In een client/server-applicatie zijn de regels voor de beoordeling van een hypotheekaanvraag en de feitelijke verwerking van die aanvraag netjes in afzonderlijke componenten geïmplementeerd. De aansturing van de tweede component op basis van de resultaten van de eerste (‘accepteer’ of ‘nadere beoordeling’), blijkt geprogrammeerd in de schermafhandeling van de gebruikersinterface.
Het is duidelijk dat een volledige uitsplitsing van de bestaande code een grote inspanning vergt.
Als die uitsplitsing dan echter gereed is, ontstaat een eerste gedistribueerde versie van de applicatie. Alle applicatie-code is verplaatst naar een aparte module en in de gebruikersinterfacecode vervangen door een functie- of methodeaanroep naar die module. De afhandeling van de functieaanroepen verloopt synchroon. Zo hebben we een gedistribueerde applicatie gemaakt met servercomponenten die vooral druk zijn met het wachten op elkaars resultaten. De potentiële voordelen van schaalbaarheid en interactiviteit van een gedistribueerde applicatie komen dan niet echt uit de verf.
De asynchrone communicatie die nodig is, kunnen we niet zomaar in de applicatie inbouwen. Omdat dit voor de client/server-applicatie helemaal geen issue was, is hiermee bij het ontwerpen van die applicatie geen rekening gehouden.
De synchrone functieaanroepen zijn niet zomaar te vervangen door hun asynchrone tegenvoeters. Daar is de applicatie helemaal niet op ontworpen. Op plaatsen waar de delen van de applicatie wel op elkaar moeten wachten, moeten expliciet synchronisatiepunten worden ingebouwd.
Al met al zijn er bij de splitsing van gebruikersinterfacecode en applicatiecode zoveel extra inspanningen vereist, dat we praktisch de hele applicatie herschrijven. De voordelen van een gedistribueerde applicatie worden op dit punt dus duur betaald.
De gelegenheid kan echter worden aangegrepen om een herontwerp van de gebruikersinterface uit te voeren. Zeker als wordt gedacht aan een migratie van een Windows- of zelfs DOS-desktop- naar een Internetbrowserinterface is dit een zeer welkome gelegenheid. De structuur van zo’n interface is immers heel anders. Al met al is dit een grote inspanning, waarmee echter twee vliegen in één klap zijn te slaan.
Gedeelde informatie
In een client/server-applicatie delen clients informatie via de database in de server-applicatie. Dit is, in een gedistribueerde applicatie, natuurlijk nog steeds mogelijk. De kracht van een gedistribueerde applicatie is echter dat ook informatie die in de applicatielaag wordt bewaard, wordt gebruikt door verschillende clients. Op deze manier kunnen processen waarbij meerdere clients zijn betrokken, worden geïmplementeerd.
Een goede implementatie ligt niet voor de hand. Als delen van de applicatielaag crashen, gaat informatie, omdat die (nog) niet in de database is opgenomen, verloren. Er zijn extra maatregelen nodig om de applicatie voldoende robuust te maken.
Het bewaren van ’toestand’ in de applicatielaag kan ook negatieve gevolgen hebben voor de schaalbaarheid van de applicatie. Het oorspronkelijke idee was immers dat meerdere servers kunnen worden opgestart om aan een groeiende capacititeitsbehoefte te voldoen. Door de aanwezigheid van toestand zijn verschillende exemplaren van dezelfde server echter niet zonder meer uitwisselbaar.
Door deze problemen met toestand in de applicatielaag richten bestaande ontwikkelomgevingen en middlewareproducten voor gedistribueerde applicaties zich sterk op het bewaren van de toestand van de gehele applicatie in de database-laag. Dit applicatiemodel is ook een erfenis uit de client/server-historie van de meeste van deze gereedschappen.
Om de beloftes van interactiviteit en schaalbaarheid van de gedistribueerde applicaties uit de verf te laten komen, is een goede ondersteuning van gedeelde toestand in de applicatielaag echter essentieel. In de recente ontwikkelingen in de programmeeromgevingen en middleware-producten van leveranciers zoals Microsoft, Sybase en Oracle, wordt dit overigens onderkend.
Zolang deze ontwikkelingen nog niet volwassen zijn, is er nog veel eigen programmeerwerk verbonden aan een robuuste implementatie van een applicatielaag met toestand, waar we bij het ontwikkelen van een client/server-applicatie veel meer cadeau krijgen van de ontwikkelomgeving.
Internettechnologie
Een van de voordelen van een te dunne gebruikersinterfacelaag in een gedistribueerde applicatie is dat bij de implementatie gebruik kan worden gemaakt van webbrowsers en aanverwante technologie. Dit maakt de distributie van de applicatie naar de gebruikers zeer eenvoudig. Als de gebruiker toegang heeft tot een browser, kan hij of zij de applicatie gebruiken. Ingewikkelde installatie- en ‘upgrade’-procedures behoren tot het verleden. Bovendien is de browser-applicatie op verschillende platformen te gebruiken.
Aan het gebruik van Internet- en browser-technologie zijn echter wat haken en ogen verbonden. Juist de ‘dunne’ gebruikers-interfacelagen van een gedistribueerde applicatie vragen om ‘dikke’ netwerkverbindingen. Na iedere actie van de gebruiker vindt immers communicatie met de applicatielaag plaats. In een client/server-systeem gebeurt de verwerking veel meer lokaal, waardoor minder beslag op netwerkbronnen wordt gelegd.
Ook de nog lang niet uitgevochten browser-oorlog tussen vooral Microsoft en Netscape is een handicap voor de ontwikkelaar van een browser-applicatie. De twee bedrijven beconcurreren elkaar met niet-standaarduitbreidingen van hun producten, die daardoor niet onderling uitwisselbaar zijn. Dit komt de platformonafhankelijkheid van browsersoftware niet ten goede. Het vergt een extra inspanning van de ontwikkelaars om een applicatie te schrijven die zonder problemen binnen alle standaardbrowsers te gebruiken is. De ontwikkelaars dienen zich in ieder geval te beperken tot de grootste gemene deler van de mogelijkheden van de verschillende browsers.
De mate waarin de twee hier genoemde problemen een rol spelen, is echter sterk afhankelijk van de omgeving waarin de applicatie toegepast gaat worden. Indien de applicatie slechts via het lokale netwerk van de gebruikersorganisatie beschikbaar moet zijn, vormt de benodigde bandbreedte vaak geen bezwaar. De beschikbare capaciteit op zo’n intranet is vaak vele male groter dan op het ‘echte’ Internet.
De browser-incompatibiliteiten spelen op een intra- of extranet een wat minder belangrijke rol. De besloten groep van gebruikers, meestal eigen werknemers, maken gebruik van de door het bedrijf als standaard gekozen browser.
De grootste uitdaging ligt in een applicatie die zowel via een intranet als via Internet gebruikt wordt. Voorkomen moet worden dat door de beperkingen, opgelegd door het gebrek aan bandbreedte en kennis over de gebruikte browser, de mogelijkheden van de intranetgebruikers afnemen, Dit is te bereiken door het functioneren van de applicatie afhankelijk te maken van de locatie van de gebruiker.
Duco Fijma, software engineer bij Inforay
