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
|
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
|
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:
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.
