De strijd tussen .net en J2EE-technologieën

De strijd tussen .NET en J2EE – Sofie Van Hoecke

Inleiding

Begin de jaren negentig gebruikten bedrijven als computersystemen vaak de client-server architectuur. Hierbij had de werknemer een computer (client) waarop de software liep, terwijl de bedrijfsinformatie in een centrale databank (server) gestockeerd werd.

Ervaring leerde echter dat het bouwen en instandhouden van een systeem met deze architectuur heel moeilijk was. Zo moest bijvoorbeeld een upgrade op elke client uitgevoerd worden, wat een zeer omslachtige manier van werken is.

Als oplossing hiervoor kwam het meerlagenmodel waarbij een server gebruikt wordt met daarop de software. Nu staat de software niet langer op de computer van de werknemer, maar surft hij via Internet Explorer of Netscape naar de software op de server. Wanneer er bijgevolg dus upgrades nodig zijn, kunnen deze op één plaats uitgevoerd worden in plaats van op elke client.

Op dit moment zijn er op de markt twee kandidaten voor de implementatie van deze computerarchitectuur. Aan de ene kant heeft men Microsoft met .NET, terwijl men aan de andere kant J2EE (Java 2 Enterprise Edition) heeft.

Eén van de meest gedebateerde vragen in de industrie handelt dan ook over de keuze voor .NET of J2EE. Aangezien beide technologieёn sterk op elkaar lijken, brengt een pure vergelijking van de specificaties niet echt grote verschillen aan het licht.  Bijgevolg werd in dit afstudeerwerk een evaluatie en vergelijkende prestatiestudie gemaakt van deze twee principes en technologieёn. Hierbij ging de aandacht vooral naar databanktoegang via webapplicaties. Maar ook andere domeinen werden verkend.

Studie van de basistechnologieёn: .NET en J2EE

Beide platformen voor gedistribueerd software-ontwerp zijn opgebouwd uit een drielagenmodel bestaande uit een clientlaag (de computers van de werknemers), een laag met daarop de software en een databanklaag. Om een vergelijking tussen beide platformen te verkrijgen, werden beide technologieёn laag per laag onderzocht en vergeleken.

Prestatie

Aangezien webapplicaties met databanktoegang interactieve programma’s zijn, is de antwoordtijd een belangrijke prestatiemaat. Om de twee verschillende platformen te vergelijken aan de hand van zo uniform mogelijke prestatietesten, werd gebruik gemaakt van de Grinder. Hierbij voeren meerdere simultane clients een stress-test uit: er wordt dan naar het punt van overbelasting gezocht.

Er kunnen echter verschillende methodes gebruikt worden om de prestatie van applicaties met databanktoegang te verbeteren. De belangrijkste hieronder zijn connection pooling en caching:

Alvorens een zoekopdracht op de databank uitgevoerd kan worden, moet er eerst een connectie met deze databank gemaakt worden. Soms echter is het creёren en sluiten van deze connectie tijdrovender dan het uitvoeren van de zoekopdracht zelf. Om deze reden worden connection pools gebruikt waardoor connecties gewoon vanuit dit reservoir gebruikt worden. Alhoewel connection pooling voor beide technologieёn geïmplementeerd is, wordt er niet overal automatisch gebruik van gemaakt en zijn extra serverconfiguraties vereist alvorens connection pooling optreedt. Deze serverconfiguratie verdient zeker extra aandacht.

Naast connection pooling, kan ook gebruik gemaakt worden van caching om de prestatie te verbeteren. Caching kan in het drielagenmodel op meerdere niveaus gebeuren.

Back-end caching: Op de databanklaag treedt caching op in de databank zelf. Wanneer eenzelfde zoekopdracht meerdere malen opgevraagd wordt, zal de databank via caching maken dat de antwoordtijden voor het leveren van dit zoekresultaat afnemen.

Front-end caching: Bij front-end caching maakt men gebruik van de caching mogelijkheid binnen het HTTP-protocol (de zogenaamde expiration date). Front-end caching heeft het voordeel dat de webserver zowel als eventuele achterliggende applicatielaag en databank ontlast worden.

Opstellen van de testen

Alvorens tot de effectieve experimenten over te kunnen gaan, moesten eerst de webapplicaties met databanktoegang ontworpen worden. Deze software moet zo ontwikkeld worden dat de werknemers via het internet naar deze applicatie op de server kunnen surfen. De functionaliteit van deze software bestaat er in gegevens op te vragen uit een databank. Naast het variёren in verschillende types applicatieservers en drivers, werden er bij de testen ook telkens twee databanken (MySQL en MS SQL) vergeleken. Al deze verschillende combinaties werden getest en met elkaar vergeleken.

Resultaten

De geteste omstandigheden brachten geen verrassingen aan het licht.

MySQL is een opensource, of vrije, databank. Aangezien J2EE ook opensource is, leverde de J2EE-applicatie (servlet), zoals verwacht, de kleinste antwoordtijd op voor MySQL.

MS SQL is echter een Microsoft databank. De Microsoft .NET driver is dan ook speciaal ontwikkeld voor optimalisatie met deze databank. Bij MS SQL heeft dus .NET de kleinste antwoordtijd.

-->

-->

(ART = Average Response Time = Gemiddelde antwoordtijd)

Tijdens dit afstudeerwerk is echter duidelijk geworden dat het niet eenvoudig is een eenduidige prestatievergelijking te maken tussen J2EE en .NET aangezien de prestatie door meerdere factoren beïnvloed wordt:

Het al dan niet gebruiken van connection pooling beïnvloedt de prestatie.

De keuze voor één bepaalde databankdriver heeft een rechtstreekse invloed op de prestatieresultaten.

Bij .NET heeft men slechts één applicatieserver. Maar bij J2EE is de verscheidenheid aan applicatieservers groter. De prestatie van een applicatie hangt af van de gebruikte server.

Kijkt men naast prestatieresultaten ook naar de leercurve, dan komt .NET naar voren als winnaar. Beide technologieёn vereisen ongeveer eenzelfde programmeercapaciteit, maar bij J2EE drijft de nodige configuratie van de server de complexiteit de hoogte in.

Conclusie

De vraag of een ontwikkelaar met het oog op de toekomst het beste voor .NET of voor J2EE kan kiezen, kan dus niet eenduidig beantwoord worden. Deze keuze zal een afwegen worden van de verschillende factoren. Er wordt verwacht dat het grootste deel van Microsofts marktaandeel gedomineerd zal worden door de SMBs (small and midsize businesses), aangezien deze bedrijven hun infrastructuur geconcentreerd is rond één enkel platform. Hierbij is .NET aantrekkelijker. Grote bedrijven zullen echter de eerste jaren zowel Microsoft als Java technologieёn blijven ondersteunen. Doordat de infrastructuur bij grote bedrijven bestaat uit een variёteit aan hardware en software, zullen deze bedrijven echter meer gaan investeren in J2EE. Maar ondanks dat zullen ook Microsoft technologieёn gebruikt worden. Daarom is het nodig dat strategieёn voor integratie van software ontwikkeld worden die interoperabiliteit tussen de beide technologieёn klaarspelen.

Een mogelijke oplossing om deze interoperabiliteit te creёren bestaat in het gebruik van Web services waarbij data uitgewisseld wordt in de vorm van XML, een nieuwe en open standaard. De IBCN-groep van de vakgroep INTEC aan de Universiteit Gent is actief bij dit onderzoek betrokken.