Kiezen tussen .Net en J2EE: de ‘harde’ afwegingen

Vorige week werden .Net en J2EE vanuit een bedrijfsmatige invalshoek vergeleken. Deze week komen twee andere invalshoeken aan bod: die van de basis-it-en van de ontwikkelaars. Verder worden de plussen en minnen van beide platformen op een rijtje gezet.

Een overall platformvergelijking vanuit een meer basale it-invalshoek laat zich makkelijker in een stramien plaatsen dan wanneer een bedrijfsmatige invalshoek wordt gekozen. Het gaat hierbij meer om de ‘harde’ tegenstellingen.
In het geval van ‘basis-it’ wordt op geen enkele manier een directe link gelegd tussen zaken waar organisaties nu mee te maken hebben en die voor een overwogen en doorwrochte keuze zorgen. Deze invalshoek beoogt alleen maar om de verschillen wat scherper te benadrukken. In een notendop geeft de tabel ze weer; pro’s en contra’s staan hier door elkaar.

Leveranciersonafhankelijkheid

Java is strikt onderhevig aan standaardisatie (zie ook het Java Community Process). Zodra code is gecompileerd (en ook de sources zelf), dient die op alle (ontwikkel) omgevingen te draaien, anders is er geen sprake van Java. J2EE is echter minder leveranciersonafhankelijk dan aanvankelijk gedacht, doordat allerlei leveranciers eigen oplossingen hebben bedacht (BEA, IBM, SUN, …). Het simpelweg uitwisselen van oplossingen is hierdoor niet meer zonder meer mogelijk. Het gebruik van het .Net-platform is volledig afhankelijk van Microsoft, hoewel er de laatste tijd meer leveranciers een ontwikkelomgeving voor op .Net gebaseerde applicaties bieden.

J2EE Grote hoeveelheid herbruikbare componenten beschikbaar Sterke leveranciersafhankelijkheid Slechts één programmeertaal beschikbaar Overdraagbaarheid besturingssysteem Lagere operationele kosten ten opzichte van Windows, indien gebaseerd op Linux Grote en diverse ontwikkelgemeenschap

De eerste J2EE-specificaties (EJB) dateren van 1998 (bèta). De ontwikkeling van Java is gestart in 1991, en werd op 23 mei 1995 voor het eerst aangekondigd aan het publiek. De eerste .Net-grondbeginselen (MTS en vervolgens COM+) dateren van 1995 (beta). De aankoop van Colusa software in 1996 is van grote betekenis geweest voor .Net. Dit bedrijf had een omgeving ontwikkeld waarin Visual C en Visual Basic naast elkaar konden draaien.

Iiop

Het .Net platform ondersteunt uddi- en Soap-standaarden, die door meer dan honderd organisaties wordt ondersteund. Ondanks het feit dat SUN onderdeel uit maakt van de eerder genoemde honderd organisaties, zijn de uddi-standaarden niet verwerkt in J2EE. J2EE is gebaseerd op Iiop. Tegenstanders zijn niet te spreken over Iiop (gebaseerd op de wereldwijde acceptatie van Iiop of Corba, en niet toepasbaar voor transport via het internet, de huidige versie ondersteunt zelfs geen interoperabiliteit tussen de verschillende J2EE-leveranciers). IBM ondersteunt mede daarom uddi en Soap in plaats van Iiop. Java zelf is gebaseerd op open standaarden en ondersteunt Soap dus weer wel. Voor de implementatie van webservices is er gelukkig weinig verschil tussen beide; de verschillen moeten vooral gezocht worden in de verschillende aanvullende onderdelen op de frameworks (vergelijk een Apache-server met MS IIS…).

Schaalbaarheid

De nadruk ligt hierbij op de hoeveelheid transacties die verwerkt kunnen worden per tijdseenheid. Deze vergelijking is lastig; de bekendste benchmark is het TPC-C benchmark. Daarin zijn geen volwaardige J2EE-implementaties opgenomen (IBM’s Websphere-implementaties maken gebruik van de ‘oude’ transactie processor van IBM, BEA gebruikt Tuxedo; beide niet op Java gebaseerd). Bij vergelijkend, al wat gedateerd onderzoek, is uitgegaan van de ‘best mogelijke schattingen’ bij het vergelijken van J2EE en .Net. Een vergelijking van de systemen op basis van transacties per minuut (op Unix gebaseerd versus op Windows gebaseerd) laat een tienvoudig verschil in het voordeel van de op Windows gebaseerde machines zien. Dit is echter wat achterhaald; tegenwoordig zijn op Linux gebaseerde machines verkrijgbaar tegen vergelijkbare kosten. Er is een benchmark uitgevoerd op basis van de

.Net Diverse additionele producten beschikbaar Beperkt tot Windows-platformen Lagere geschatte ontwikkelkosten Lagere operationele (hardware)kosten ten opzichte van Unix-machines Mogelijkheden oom op te schalen overstijgen die van J2EE Sterke mogelijkheid tot samenwerking

zogenaamde Pet Shop-applicatie van SUN, waaruit .Net als snelste te voorschijn kwam. Men moest later toegeven dat de .Net-versie op snelheid was geoptimaliseerd door Microsoft, en de SUN-versie sample-code betrof. TCP-C is eigenlijk niet goed te gebruiken als benchmark. Het probleem is dat zowel software- als hardware-leveranciers hier specifieke optimalisaties doorvoeren om hoog te scoren. Vergelijking van een 32 cpu Power5 met een 64 cpu Itanium 2 op verschillende softwareplatformen met verschillende opslagsystemen worden hier vergeleken, dus het is moeilijk een oordeel te vellen. Misschien moeten vergelijkingen worden gemaakt op basis van dezelfde hardware, met vergelijkbare inspanningen in optimalisaties, beide op een Windows-platform (om ook verschil in besturingssystemen uit te sluiten).

Framework-ondersteuning

Het .Net-platform bevat een aantal .Net-oplossingen (commerce server, sharepoint portal server, e.a.) die naadloos kunnen worden geïntegreerd met de te ontwikkelen applicaties. De leveranciersafhankelijkheid is hierbij evident. Voor J2EE is een veelvoud van ‘off-the-shelf’ componenten en oplossingen van een veelvoud van leveranciers beschikbaar. Hierbij geldt nog steeds de restrictie zoals genoemd onder ‘leveranciersonafhankelijkheid’. En laten we niet de enorme hoeveelheid bibliotheken (libraries) over het hoofd zien …

Taal

J2EE ondersteunt Java. IBM’s Websphere en BEA’s Weblogic ondersteunen wel meerdere talen, maar niet op basis van J2EE. Het .Net- platform ondersteunt zo’n twintig talen, inclusief Java. Hierbij dient nog te worden opgemerkt dat de tarieven van de Java programmeur circa 30 procent hoger liggen dan die van een C#-programmeur, (zowel bij inhuur als bij interne krachten – opleiding is hier de belangrijkste kostenveroorzaker). Daar staat tegenover dat Java zonder meer de voorkeur verdiend, indien portabiliteit een belangrijke vereiste is.

Overdraagbaarheid

J2EE is te poorten naar vrijwel elk besturingssysteem. Het .Net-platform is alleen beschikbaar op Windows (hoewel op kleine schaal initiatieven gaande zijn op andere besturingssystemen). Gecompileerde programma’s zijn uit te voeren op elk platform waarvoor de clr (common language runtime) geïmplementeerd is; dit is nog niet wijd verspreid. Gecompileerde programma’s draaien alleen op besturingssysteem Windows. Mono (het project om .Net op Linux te laten draaien) verkeert nog niet in het alpha-stadium op het moment van schrijven van dit artikel. De BSD-oplossing (een Unix-versie) is onvolledig en ondersteunt maar een gedeelte van de software. Men zal dus specifiek hiervoor moeten schrijven – een vergelijkbare situatie als bij software voor ingebedde systemen.

Onafhankelijkheid client-apparatuur

J2EE bevat aan de client-kant veel code (de presentatielaag), waardoor het minder geschikt is voor slanke clients. Deze code is bovendien niet makkelijk op alle gewenste apparatuur te testen. Het toevoegen van een nieuw type client-apparaat vereist bovendien behoorlijke aanpassingen in de bestaande code.
Het .Net-platform gebruikt apparatuuronafhankelijke code die interactie heeft met ‘visual controls’. Die bepalen welke ’type’ Html moet worden geleverd, gebaseerd op de mogelijkheden van de apparatuur.
Beide talen hebben een webgebaseerde variant (Aspx voor .Net, JSP voor Java) en een applicatievariant (Swing voor Java, Winforms voor .Net). Hierbij geldt dat voor een applicatie met Swing minstens versie 1.2 op het client-systeem geïnstalleerd moet zijn, en voor Winforms moet het .Net-framework op het systeem geïnstalleerd zijn, als mede een Windows-besturingsysteem. (Winforms werkt niet in de BSD-omgeving, en is nog niet ondersteund in Mono).
Aspx en JSP vereisen dat de client een met Html verenigbare browser is. Het type control in Aspx wordt bepaald in de zogenaamde ‘browsercap’-definitie (browser capability), die door een extern bureau zou moeten worden bijgehouden. Helaas is dit niet gebeurd, waardoor met name de zich snel ontwikkelende browser van Mozilla, maar ook Opera ten onrechte een onvolledige en verouderde interface krijgen. Gelukkig worden veranderingen in Internet Explorer door Microsoft zelf bijgewerkt in de browsercap-file. Onbekend is of er verandering gaat komen in het beheer van browsercap.
 

De ontwikkelaarsinvalshoek

En dan nu de harde kern. Als de keuze overgelaten wordt aan de ontwikkelaars, hoe vindt de afweging dan plaats? Een eerste indruk:

• Voor slimme clients: .Net!
  
• Grote systemen met multiplatform-integratie aan de back-end: Java
  
• Ontwikkeltools en gebruikersgemak voor ontwikkelaars: .Net
  
• Een Java-systeem op een Linux- of Unix-systeem is uit veiligheidsoogpunt te prefereren boven een Windows-applicatie.

De discussie woedt juist onder ontwikkelaars al jaren stevig, en zal nog wel even voortduren.
Hoewel onderstaande informatie naar alle waarschijnlijkheid al op het moment van schrijven weer is achterhaald, wagen we er ons toch nog maar aan: de voors en tegens van .Net en J2EE. De informatie is onder andere gefilterd uit diverse discussieforums op het internet.

Pluspunten .Net

• Vermindert significant de hoeveelheid benodigde code en verhoogt de productiviteit van de ontwikkelaar;
  
• Betere, snellere ontwikkeling mogelijk;
  
• Vrijelijk hergebruik & uitbreiden van componenten in wat voor (in overeenstemming met .Net) taal dan ook geschreven;
  
• Meertalig: gebruik maken van bestaande vaardigheden is mogelijk, je kunt de taal gebruiken die het meest geschikt is is voor de uiteindelijke oplossing;
  
• Uitstekende prestatie.

Minpunten .Net

• Volledige afhankelijkheid van één leverancier;
  
• De grote overeenkomst tussen C# en Java geeft alleen maar aan dat Java al jaren superieur is;
  
• Gebruik van meerdere talen maakt ontwikkeling en onderhoud alleen maar gecompliceerder en levert minder elegante oplossingen op (dat heb je echter zelf in de hand, dus is dat wel een minpunt?)
  
• Als het niet platformonafhankelijk is, kan het nooit een industriestandaard worden;
  
• ‘Insluiting’ van een besturingssysteem, met ‘verplichte’ opwaardering – niet over het hoofd te zien, vooral bij de implementatie van systemen!

Pluspunten J2EE

• Je hoeft maar één taal te leren om overal te kunnen coderen (write once, run anywhere);
  
• Het is mogelijk om te poorten over platformen en applicatieservers heen;
  
• Een veelheid van leveranciers: scherpe prijzen, snellere verbeteringen, groter draagvlak voor innovatie;
  
• Ondersteuning van open standaarden;
  
• Zeer grote en enthousiaste gemeenschap. Hierdoor is er uitgebreide professionele ondersteuning te vinden buiten het ‘officiële’ circuit.

Minpunten J2EE

• Je ‘mag’ maar één taal gebruiken, die niet altijd de beste oplossing biedt;
  
• Kosten van cpu en J2EE-applicatieserver zijn circa drie keer zo hoog als het Windows-platform (Kosten cpu zijn gelijk, en J2EE-applicatieserver is goedkoper indien open-broncode-alternatieven als Jboss, Tomcat, My SQL en Linux worden gebruikt).
  
• Platform is ‘incompleet’, is sterk servergericht;
  
• Het duurt lang om Java onder de knie te krijgen; ontwikkelen in Java duurt nog langer;
  
• De prestatie van Java is slecht, vooral aan de client-kant

Ontwikkelingen

Een aantal ontwikkelingen kunnen we verwachten.
.Net wordt geschikt voor meerder platforms. Diverse initiatieven op dit vlak zijn gaande of al afgerond, onder andere het Mono-project (een open-broncode-implementatie van het .Net-ontwikkeling-framework). De angst bestaat wel dat Mono mogelijk door Microsoft tegengewerkt zal worden via patenten, zodra zij een bedreiging gaat vormen voor de uitrol van Windows naar serveromgevingen. (Officieel memo Microsoft: ‘Whatever you do, don’t lose to Linux’)
J2EE wordt meertalig. Er zijn al compilers die als output meerplatformige Java-bytecode opleveren; Coldfusion Markup Language is er één van. Momenteel bestaat er kritiek op het Java Community Process, omdat men bang is dat er te veel overlegd wordt en er te weinig concrete evolutie in Java zit. Er zal dus ‘iets’ gaan gebeuren. Daarnaast zijn verdere optimalisaties te verwachten voor de prestatie van Java (runtime- en compiler-ontwikkeling).< BR>
 
Freek Giele, senior consultant, Hans Baas, managing consultant, Nico Stokman, managing consultant, Tommes Snels, managing consultant. Allen werkzaam bij Cap Gemini Ernst & Young.