Java versus 4gl en .NET

Lichtgewicht applicatieraamwerken maken J2EE productiever

Tijdens de Development Tools 2005 wedstrijd (voorheen RAD race) bereikte een team van Xebia de derde plaats dankzij het gebruik van open source Java-ontwikkeltools en een lichtgewicht J2EE-applicatieraamwerk. Een bijzondere prestatie in een veld dat gedomineerd werd door teams met krachtige vierde-generatie talen. Het toont aan dat Java met lichtgewicht J2EE-applicatieraamwerken zich kan meten met 4gl (vierde-generatietalen) en .NET.

Het Java-team scoorde tweemaal zoveel punten als het .NET-team. Dit was voor velen een verrassing omdat Java geen al te beste naam heeft op het gebied van productiviteit. Menig it-manager heeft zich na afloop van een alweer moeizaam verlopen J2EE-project afgevraagd of .NET misschien toch geen betere keuze was geweest.
Java 2 Enterprise Edition (J2EE), zoals dat door Sun en anderen geïntroduceerd is aan het eind van de jaren negentig, is een platform voor het ontwikkelen van gedistribueerde applicaties. In de afgelopen jaren is het platform volwassen geworden. Tegenwoordig dient het als de basis voor een groot deel van alle webapplicaties. Vrijwel elke Nederlandse bank bijvoorbeeld gebruikt J2EE als platform voor internetbankieren.
De bouw van J2EE-applicaties blijkt in de praktijk vaak moeizaam te verlopen en veel complexiteit met zich mee te brengen. Hiervoor zijn drie belangrijke oorzaken aan te wijzen: de onnodige distributie van applicatielogica, het overdadige gebruik van J2EE-modellen en een overvloed aan technische implementatievormen.

Technisch loodgietwerk

De mogelijkheid om met J2EE gedistribueerde applicaties te bouwen op basis van EJB's (Enterprise Java Bean) heeft ertoe geleid dat dit eerder regel is dan uitzondering. Er worden gedistribueerde applicaties gebouwd terwijl dat vaak niet nodig is. Het distribueren van de applicatielogica leidt tot extra complexiteit tijdens de bouw. Er moet bijvoorbeeld veel extra code geschreven worden voor het lokaliseren van applicatiecomponenten en het afhandelen van fouten als zo'n component niet beschikbaar is. Het gevolg daarvan is dat J2EE-ontwikkelaars vaak meer bezig zijn met technisch loodgietwerk dan met het bouwen van functionaliteit waar een gebruiker wat aan heeft.
Als argument voor het ontwikkelen van een gedistribueerde applicatie wordt vaak de behoefte aan schaalbaarheid genoemd. Dat is een slechte argument. De extra communicatie tussen de verschillende applicatiecomponenten die inherent is aan distributie, vermindert in de praktijk namelijk de prestatie. Dat werkt de schaalbaarheid juist tegen. Het is daarom niet verbazingwekkend dat gedistribueerde applicaties vanwege de extra kosten die distributie met zich meebrengt, of om prestatieredenen, uiteindelijk vaak toch weer op één server gedraaid worden. De vermeende schaalbaarheidsvoordelen worden dan per definitie niet behaald, terwijl de realisatie wel een langere doorlooptijd en hogere kosten met zich meebrengt.
Een andere veelgenoemd argument is het hergebruik van componenten. Al snel valt dan de term soa (service oriented architecture), meestal onterecht. Hoewel hergebruik een valide reden kan zijn voor het distribueren van applicatiecomponenten, moet daar wel zakelijk mee worden omgegaan. Het distribueren van applicatielogica is in dit geval een investeringsbeslissing waarvan de kosten moeten worden terugverdiend. De meeste commerciële bedrijven gaan voor een willekeurige investering uit van een terugverdientijd van maximaal 1,5 jaar. Een dergelijk economisch uitgangspunt wordt slechts sporadisch toegepast op soa's. Als er op voorhand niet meer dan twee klanten voor een component of service verwacht worden, is een investering in een (hopelijk) generieke dienst vaak niet te verantwoorden. Vanuit het oogpunt van complexiteit verdienen goedkopere alternatieven, zoals gedeelde libraries, in dergelijke gevallen de voorkeur.

Te veel keuze

De tweede factor die de J2EE-productiviteit negatief beïnvloedt, is het overdadig gebruik van J2E-modellen (patterns). Dat zijn raamwerkoplossingen die gebruikt kunnen worden bij het aanpakken van problemen met vergelijkbare karakteristieken. Hoewel op veel van de J2EE-modellen weinig valt aan te merken, betreft het vaak oplossingen voor problemen die juist veroorzaakt worden door een te complexe, gedistribueerde architectuur. Modellen bestrijden daarom meestal symptomen en zijn zelden gericht op de te realiseren functionaliteit.
Daarnaast is het toepassen ervan ook een modeverschijnsel. Rod Johnson, de geestelijk vader van de lichtgewicht J2EE-stroming, spreekt zelfs van een 'patterns disease'. Modellen zijn nuttig, maar moeten wel zoveel mogelijk in een applicatieraamwerk verankerd worden, waardoor ook een gewone ontwikkelaar ze - onbewust - gebruikt en van de voordelen profiteert.
De derde factor die de productiviteit met J2EE remt, is de grote keuzevrijheid die ontwikkelaars bij de bouw hebben. Ze kunnen kiezen uit letterlijk honderden alternatieve libraries, raamwerken en toolkits. Dat is vaak oss (open source software), waardoor het ook nog eens niets lijkt te kosten. Waar een .NET-ontwikkelaar vaak maar uit één alternatief kan kiezen, dat van Microsoft, komt de J2EE-ontwikkelaar om in de keuzemogelijkheden. Het gevolg is dat veel J2EE-ontwikkelaars de verleiding niet kunnen weerstaan en een nieuwe technologie gebruiken, ook al is er binnen hun bedrijf al ervaring met een technologie die hetzelfde kan. Hoewel dit misschien de innovatie stimuleert, is een ongewenst neveneffect dat een J2EE-ontwikkelaar op een bepaald technologisch deelgebied zelden de status van expert zal bereiken en dus niet optimaal productief is.

Vaste structuur

De nadelen van de traditionele J2EE-benadering worden meer en meer onderkend. Binnen de oss-wereld heeft dat geleid tot lichtgewicht J2EE-applicatieraamwerken. Deze raamwerken bieden een vaste structuur voor het bouwen van een applicatie en leveren standaard oplossingen voor de problemen die in elke toepassing terugkeren. Dat neemt de eerder genoemde oorzaken van de lage productiviteit van J2EE weg.
Ten eerste wordt het distribueren van applicatiecomponenten vermeden, waardoor de complexiteit van applicaties vermindert. Indien het toch nodig blijkt om componenten te distribueren, maken lichtgewicht applicatieraamwerken dit eenvoudig door ook hiervoor standaardcomponenten aan te bieden. Ten tweede zijn de raamwerken zelf gebaseerd op J2EE-modellen, waardoor de ontwikkelaars zich daar veel minder mee bezig hoeven te houden. Ten derde ligt met het gebruik van de raamwerken de technische implementatievorm in hoge mate vast. Om deze redenen kunnen ontwikkelaars zich meer richten op het bouwen van functionaliteit voor eindgebruikers in plaats van het oplossen van allerlei technische problemen.

Minder fouten

Bij de Development Tools 2005 wedstrijd heeft het Java-team het leidende lichtgewicht J2EE-applicatieraamwerk gebruikt: Spring (os Spring Java/J2EE Framework). Spring is een raamwerk waarmee volwassen applicaties te bouwen zijn, waarbij het technisch loodgietwerk achterwege kan blijven. Ontwikkelaars kunnen transparant gebruikmaken van diverse handige componenten die het raamwerk biedt op het gebied van onder meer data-integratie, EJB-ondersteuning en berichtenuitwisseling.
Uit het wedstrijdresultaat blijkt dat Spring een goede basis vormt voor productieve softwareontwikkeling. Verder blijkt uit de inzet van Spring op diverse projecten dat het niet alleen de productiviteit verhoogt maar ook bijdraagt aan de kwaliteit van het eindproduct. Een met Spring ontwikkelde applicatie kent, bij gelijkblijvende functionaliteit, aanzienlijk minder regels code en losse componenten, en daardoor ook minder fouten. Tijdens projecten waarbij een bestaande J2EE-applicatie is omgezet naar Spring is gebleken dat codereducties van tientallen procenten geen uitzondering zijn. Tot slot verhoogt Spring ook de testbaarheid van applicaties doordat applicatiecomponenten voor een groot deel buiten een applicatieserver te testen zijn. Dit scheelt tijd in de ontwikkelfase van een project.

Eenvoud

It-managers zullen zich terecht afvragen of het gebruik van oss binnen hun eigen projecten verstandig is. Er wordt al jarenlang geen Java-applicatie meer gemaakt zonder dat daar oss aan te pas komt. Zelfs de grote leveranciers van applicatieservers maken in hun producten flink gebruik van oss. Veel innovatie op J2EE-gebied komt namelijk juist uit de os-hoek. Dat blijkt bijvoorbeeld uit het feit dat ideeën uit os-projecten als Spring in de nieuwe versie van diverse J2EE-specificaties worden opgenomen. Het zelf ontwikkelen van een dergelijk raamwerk is dan ook geen alternatief. Daarvoor zijn zoveel tijd en vaardigheden nodig dat dit in de praktijk onhaalbaar is. Gebruikmaken van een raamwerk van een it-leverancier creëert een 'vendor lock-in' die ook niet gewenst is. Os-raamwerken zijn daarom een aantrekkelijk alternatief.
Lichtgewicht applicatieraamwerken brengen de eenvoud terug in de J2EE-applicatieontwikkeling en resulteren in een productiviteit die in lijn ligt met de beste 4gl's en .NET. De exponent hiervan, Spring, is de afgelopen jaren uitgegroeid tot een volwassen product waarmee complete zakelijke applicaties te realiseren zijn.

 
Winfried Scheulderman, senior consultant Xebia IT Architects, Richard Swart, senior consultant Xebia IT Architects