Is Java te beschouwen als een serieus platform voor het ontwikkelen van bedrijfsapplicaties? Om dat te onderzoeken werd de huidige op de markt beschikbare Java-versie op de pijnbank gelegd. De evaluatie is geen beoordeling van Java in relatie tot andere ontwikkelplatforms, maar een toetsing van het ambitieniveau, zoals in eerdere artikelen in dit blad is geformuleerd.
Bedrijfsapplicaties zijn toepassingen die meerdere kernfuncties van een organisatie ondersteunen. Ze zijn vaak van een omvang die de betrokkenheid van meerdere systeemontwikkelaars noodzakelijk maakt. Omdat de beschikbaarheid en integriteit van de kernfuncties gewaarborgd moeten zijn, is voor dergelijke applicaties een beheersbare en onderhoudbare infrastructuur nodig. Kunnen met het Java-platform dergelijke bedrijfsapplicaties worden gebouwd? Om die vraag te beantwoorden moet beoordeeld worden of Java voldoet aan een aantal algemeen aanvaarde eisen voor een professionele ontwikkelomgeving met bijbehorende programmeertaal. In het vervolg toetsen wij of Java aan de gestelde normen voldoet en gaan wij in op de beperkingen van Java.
Versiebeheer
Er zijn elf eisen geformuleerd die aan een professionele ontwikkel- en programmeeromgeving kunnen worden gesteld. De eerste eis heeft betrekking op de ontwikkel- en documentatietools. De ontwikkelomgeving behoort geautomatiseerde functies te bieden voor het definiëren en vastleggen van alle stappen in het ontwikkelingstraject. Ook moet de omgeving zich lenen voor simultane ondersteuning door meerdere ontwikkelaars. De documentatie en ondersteuning van de ontwikkelstappen moet op innerlijk consistente wijze plaatsvinden vanaf de conceptuele eisen van het systeem tot en met de programmatuur die uiteindelijk operationeel wordt gemaakt. Voor klassieke talen is dit heden ten dage (ten dele) gerealiseerd met behulp van case-tools. Bij het ontwerpen van omvangrijke applicaties, werken dikwijls meerdere ontwikkelaars aan hetzelfde ontwerp.
Ontwikkelaars van Java-applicaties hebben momenteel slechts de beschikking over debuggers, editors en compilers. Dit betekent dat multi-user ontwikkelomgevingen en omvangrijke projecten nog niet adequaat ondersteund kunnen worden. Dat geldt ook voor de aangekondigde case-tool Visual Age.
In een omgeving waarin meerdere ontwikkelaars objecten binnen dezelfde bibliotheek moeten onderhouden, dient geautomatiseerd versiebeheer (eis 2) te kunnen plaatsvinden aan een operationeel systeem. Dit is van belang om risico’s van regressie te beperken: het voorkomen dat oudere versies worden onderhouden in plaats van de meest recente modules. Daarnaast maakt geautomatiseerd versiebeheer het mogelijk om kleine aanpassingen en verbeteringen aan te brengen in applicaties zonder dat er een volledig nieuwe release moet worden uitgebracht.
Versiebeheer wordt nog niet door Java ondersteund. Daarnaast zijn er vraagtekens te plaatsen bij de mogelijkheden om kleine wijzigingen te kunnen aanbrengen zonder een geheel nieuwe release uit te brengen.
Er moet sprake zijn van standaardisatie (eis 3) van ontwikkelgereedschappen en programmeertaal. Dit dient de betreffende organisatie te beschermen tegen een te grote afhankelijkheid van één leverancier en een klein aantal experts. De continuïteit van de systemen wordt hierdoor gegarandeerd. Een breed draagvlak en weinig variatie in leveranciersafhankelijke verschijningsvormen van ontwikkeltools en programmeertaal zijn karakteristieken van de gewenste standaardisatie. Deze standaardisatie dient ondersteund en bekrachtigd te worden door erkende standaardisatie-instituten.
Er is nog geen sprake van een ‘standaard’ Java. De defacto standaard van Sun, zal voorlopig – juist door de snelle ontwikkeling van Java – geen echte standaard worden.
Onderhoudbaarheid
Een volwaardige ontwikkeltaal dient in hoge mate uitbreidbaar en onderhoudbaar (eis 4) te zijn. Dit vereist een zekere stabiliteit van de versies, uitmondend in een beheerste toevoeging van nieuwe functionaliteit en de opwaartse compatibiliteit van eerdere versies. Doordat de taal zich snel ontwikkelt moet men juist in staat zijn om nieuwe functies in de bestaande te integreren.
Daarnaast dient de code zodanig te zijn opgezet, dat de te wijzigen functionaliteit in een applicatie direct te relateren is aan programmaregels.
Het gebrek aan mogelijkheden tot objecten-beheer geeft grond aan de conclusie dat getwijfeld moet worden aan de onderhoudbaarheid van Java-applicaties op de langere termijn.
Applicaties die onder de noemer integere operationele programmatuur (eis 5) geschaard kunnen worden, moeten een bijdrage leveren aan het bereiken van de bedrijfsdoelstellingen. Dit impliceert dat het mogelijk moet zijn om de geteste en geaccepteerde programmatuur te beschermen tegen ongeautoriseerde wijzigingen. Ondermeer door de creatie van voor onbevoegden afgeschermde omgevingen en door de mogelijkheid de staat van de programmatuur te controleren. Daarnaast dient er een onderscheid te bestaan tussen de programmatuur en de data om de bevoegdheden van programmeurs op eenvoudige manier te kunnen beperken. Wanneer broncode in een productie-omgeving beschikbaar is, behoren ook buitengewoon hoge eisen aan de beveiliging van de code tegen onbevoegd wijzigen te worden gesteld.
Vanwege het interactieve karakter van het Java-platform moeten additionele eisen worden gesteld aan de omgeving waarop de virtuele machine draait ter voorkoming van ongeautoriseerde wijzigingen in de programmatuur. De mogelijkheid en kracht van Java om code te in te bouwen (embedden) in de data vergroot het beveiligingsrisico.
Ten behoeve van het ontwikkelen van een efficiënt systeem, dat wil zeggen een systeem met een acceptabele prijs/prestatie verhouding, dient het mogelijk te zijn om de prestatie van het systeem te prognotiseren (eis 6). Dit geldt met name voor online transactie-systemen.
Voor Java-applicaties is dit nog niet mogelijk. Daarnaast leidt de portabiliteit van Java tot concessies op het gebied van de prestatie. Systemen met minder hoge eisen op het terrein van hardware-onafhankelijkheid kunnen tegen lagere kosten met behulp van andere talen gerealiseerd worden.
De grafische gebruikersinterface dient eenvoudig te ontwikkelen en te onderhouden zijn (eis 7). De gui’s hebben op dit moment nog een zekere platformafhankelijkheid. De komende jfc-library zou dit probleem oplossen. Daarnaast zijn de gui’s eenvoudig te ontwikkelen en is Java bij uitstek geschikt voor het creëren van mooie input- en outputschermen.
‘Logging’
De door het platform opgeleverde applicaties moeten relatief eenvoudig geïntegreerd (eis 8) kunnen worden met reeds bestaande andere applicaties. Deze eis gaat uit van een partiële opbouw van een nieuwe applicatie-omgeving teneinde enerzijds het transformatieproces fasegewijs te kunnen uitvoeren en anderzijds Java te kunnen toepassen op de meest daarvoor in aanmerking komende functies. Naast mogelijke koppelingen met bestaande programma’s zijn database-interfaces en integratie met client/server-toepassingen gewenst.
Er bestaat een interface voor databases met jdbc en de jdbc-odbc- ‘bridge’. De client/server-integratie is oplosbaar door Corba, Rmi en sockets. Er is al aardig wat geregeld voor de koppeling met andere programma’s. Het probleem is echter nog om bestaande code op te nemen in Java-applicaties, aangezien dit snel een verlies van de gewenste portabiliteit ten gevolge zal hebben.
De installaties waarop de programmatuur draait moeten in staat zijn om een onafhankelijke (buiten de toepassingen om) en integere logging (eis 9) van de procesgangen van de programma’s te verzorgen. Logging is een vereiste om achteraf de juistheid en volledigheid van de verwerking vast te stellen. Java werkt met een virtuele machine die geen mogelijkheden biedt voor een dergelijke logging. De virtuele machine en de veel als server gebruikte PC-omgeving voldoen qua omgeving niet aan deze eis. Het niet beschikken over detectieve controle-maatregelen vormt een belangrijke beperking in het toepassingsgebied van Java.
Het moet mogelijk zijn om verschillende omgevingen te definiëren om de bevoegde personen de juiste functies te kunnen laten uitoefenen op het vereiste occurence-niveau. De enige vorm van access control (eis 10) is de controle op de reikwijdte van de functionaliteit voordat het object wordt uitgevoerd.
Er bestaat binnen de Java-omgeving geen beveiliging van de toegang tot de functionaliteit. Dit betekent dat de access control in de installatie om Java heen geregeld moet worden.
Het platform dient een beheermechanisme te bieden voor het distribueren van programmatuur over verschillende hardware platforms. Aan de eis van software-distributie (eis 13) wordt voldaan.
(On)geschikt
Uit de evaluatie blijkt dat het Java-platform niet geschikt is voor omvangrijke bedrijfskritische applicaties. Voorbeelden van dergelijke software zijn systemen die over een langere periode een grote stabiliteit en integriteit van de functionaliteit vereisen waarbij onder meer via detectieve controlemaatregelen vastgesteld moet worden dat aan de gestelde eisen voldaan is. Te denken valt aan debiteuren- en crediteurenadministraties en voorraadsystemen.
Ook systemen die zodanig van omvang zijn dat voor de ontwikkeling daarvan gedurende een langere periode een groot team van ontwikkelaars simultaan aan het systeem moet werken, kunnen moeilijk met Java worden gebouwd. Dat geldt ook voor systemen die normaliter een lange levensduur hebben en daarom ook veel onderhoud moeten kunnen verdragen. Voorbeelden van dergelijke systemen zijn personeelsinformatie- en salarissystemen en produktiebesturingssystemen.
De Java-omgeving is wel geschikt voor vele andere soorten applicaties. Dit komt met name omdat Java een snelle ontwikkeling mogelijk maakt van niet te omvangrijke functies waarbij portabiliteit, gui’s en software-distributie belangrijke vereisten zijn. De volgende toepassingsgebieden zijn dan te onderscheiden: applicaties die marketing- of verkoopfuncties ondersteunen, managementanalyses maken en processen of diensten ondersteunen, die bijvoorbeeld op basis van het marktmechanisme, een naar verwachting kortstondige levensduur hebben.
Ook vooraf gedefinieerde en niet te omvangrijke standaard toepassingen voor cliënten op afstand met verschillende hardwareplatformen, kunnen met Java worden gebouwd. Dat geldt ook voor prototypen van een nieuw systeem die even snel gebouwd moeten worden.
Voorzichtigheid geboden
Bij dit alles dienen we ons te realiseren dat door de snelle ontwikkeling van Java alles wat geschreven wordt binnen de kortste tijd achterhaald is. Wij stellen nadrukkelijk dat Java een krachtige taal is met veel toepassingsmogelijkheden voor specifieke applicaties. Voor de echte bedrijfsapplicaties schiet het Java-platform echter tekort. We hebben het dan niet alleen over mogelijke prestatieproblemen. Het is ook de vraag of geautomatiseerde kernfuncties van een bedrijf overdraagbaar of apparatuur-onafhankelijk moeten zijn. Daarnaast dient de échte toegevoegde waarde van een applicatie gebaseerd te zijn op het effectieve gebruik door de organisatie of zijn clienten. Dit heeft op zich niets te maken met een snelle en goedkope ontwikkeling. Het snel opleveren van een systeem blijkt in de praktijk ook nogal irrelevant te zijn voor de kosten. De kosten van het operationeel houden van een systeem blijken namelijk ruim vijf maal zo groot te zijn als de initiële ontwikkelingskosten. Wel is het zo dat door de ontwikkeltijd met behulp van Java te bekorten, een tijdsvoordeel ten opzichte van de concurrentie kan worden behaald. Die tijd kan ook in geld worden uitgedrukt. De werkelijke prijs/prestatie-verhouding van het Java-platform zal zich in de toekomst echter nog verder moeten bewijzen. Enige voorzichtigheid ten aanzien van de huidige overselling van Java is daarom dan ook geboden.
Als referentiebasis voor dit artikel hebben de auteurs eerdere artikelen in Computable gebruikt, met name die in de uitgaven van 25 augustus en 19 september.
Prof. M.E. van Biene-Hershey RE is IT-auditor en hoogleraar EDP-audit aan de Vrije Universiteit en bestuurslid van Norea.
Drs M.A. Bongers RE RA is Hoofd Accountantsdienst van de Kas-Associatie N.V. Hij is bestuurslid Norea en lid van de Commissie van Toezicht van de HES EDP-audit opleiding te Amsterdam.
