De paradox van standaarden

De wereld van ICT bestaat uit standaarden. Standaarden die integratie tussen diverse platformen mogelijk en makkelijk maken. Met de Java/J2EE standaard moet een naadloze aansluiting en integratie van web services op platformen als JBoss, Websphere, Sun Application Server of SAP Netweaver eenvoudig te realiseren zijn. In de praktijk blijkt dit echter tegen te vallen. Dat ondervond ook Aia Software bij het ontwikkelen van de web applicatie ITP/OnLine Server.

ITP is een server-gebaseerd document-compositiesysteem, waarmee documenten zowel in batch als on-demand kunnen worden geproduceerd. In dat laatste geval kan er tijdens het samenstellen van het document nog interactie met een gebruiker nodig zijn. ITP/OnLine Server voorziet in deze behoefte. Een belangrijk deel van ITP/OnLine Server bestaat uit een webcomponent, die XForms-gebaseerde berichten vertaalt naar HTML-formulieren. Hiermee is de brug naar de werkplek geslagen, terwijl het samenstellen van het document toch een server-gebaseerd proces blijft.

Een eerste implementatie van de webcomponent draaide op Internet Information Services van Microsoft. Het porteren van deze implementatie naar J2EE leek een eenvoudige opdracht. Dat bleek in de praktijk toch tegen te vallen. Het idee was uiteraard om één product uit te leveren, dat zonder aanpassingen zou draaien op JBoss, WebSphere, Sun Application Server en SAP Netweaver – allemaal gebaseerd op de J2EE standaard.

J2EE standaard?

Dat laatste is uiteraard ook het idee achter het definiëren van een standaard. De ontwikkelaar kan zich beperken tot de standaard en hoeft zich niet druk te maken over de details van de verschillende implementaties van die standaard. In de praktijk blijkt dit een utopie te zijn. Zolang er ontwikkeld wordt in een project voor één enkele klant is er geen vuiltje aan de lucht. Het ontwikkelteam kan zich volledig focussen op de webserver die bij de klant ingezet zal worden. Als de oplossing daarop draait, is de klant blij. En tegen de tijd dat de klant migreert naar een andere webserver is het project allang verleden tijd. De uitdaging bij het porteren van ITP/OnLine Server zat er met name in, dat het hier niet ging om een project, maar om een product. Bij de ontwikkeling ervan moest een generieke klant voor ogen gehouden worden en dus ook een generieke webserver. Kortom: de Standaard met een grote letter S.

Een grote letter S?

ITP is altijd al een op integratie georiënteerde oplossing geweest. Dat geldt zeker ook voor ITP/OnLine Server. De HTML-formulieren die door ITP/OnLine Server worden uitgestuurd kunnen als losse module worden aangeboden, maar worden veel vaker geïntegreerd in bestaande applicaties. Deze applicaties bestrijken een breed spectrum - van portals tot fat clients. Het voorkomen en het gedrag van ITP/OnLine Server moeten dan ook per opstelling aangepast kunnen worden en dat brengt veel configuratie met zich mee. Deze configuratie bestaat uit meer dan alleen een paar settings: cascading stylesheets, xsl-transformaties en zelfs complete jsp-pagina’s moeten kunnen worden aangepast. Juist deze configuratie leverde binnen J2EE een extra complicatie op. Tenminste: als het product wordt uitgeleverd als één enkel enterprise archive dat door elke klant uitgerold kan worden. Configuratie op het niveau dat ITP/OnLine Server vereist zou eigenlijk moeten plaatsvinden bij het packagen van de ear-file en niet na het deployen ervan. En toch is dat laatste wat ontwikkelaars eigenlijk willen – want van alle klanten vragen of ze zelf hun eigen ear-file willen samenstellen, dat kan toch niet?

Architectuur ITP/online

Om met dit probleem om te gaan is het concept van een ITP/OnLine application geïntroduceerd. Dit is een configuratiecontext, die onder andere bestaat uit: een configuratiebestand, een set cascading stylesheets en eventueel een aantal xsl-transformaties en jsp-pagina’s. Deze bestanden worden buiten de context van de web server opgeslagen, op een locatie die binnen de context van de web server geconfigureerd dient te worden. Een sessie op ITP/OnLine Server draait binnen de context van één zo’n application en gebruikt de bijbehorende bestanden (dus ook de jsp-pagina’s). Zo kan ITP/OnLine Server zich als een kameleon aanpassen aan de omgeving, zonder dat er daarvoor aanpassingen aan de ear-file nodig zijn.

Naast de bovengenoemde uitdaging vanuit de J2EE-standaard zelf, kwamen er veel problemen voor die het gevolg waren van de verschillende implementaties van de J2EE-standaard. ’The beautiful thing about standards is that there are so many of them’ – en dat ging hier zeker op. De moeilijkheid schuilt hierbij vaak in de details:

Probeer maar eens een EJB-gebaseerde web service te maken met één deployment descriptor die zowel op WebSphere als op JBoss draait.
Probeer maar eens NTLM-authenticatie te implementeren door in te haken in de FilterChain. Dit zou probleemloos moeten kunnen - ook op Sun Application Server 8.
Probeer JBoss maar eens zo te configureren dat een op een EJB-gebaseerde web service de caller via client certificates kan authenticeren. En dat dan bovendien door simpelweg de Principle uit te vragen. Via JAAS zou het moeten kunnen.
Probeer maar eens een web service te ontwikkelen, terwijl de WSDL al tot in de punten en komma’s gespecificeerd is.

Van IT-gestuurd naar IT-gecontroleerd

In de financiële dienstverlening gebruiken organisaties als banken en verzekeringsmaatschappijen al jaren gespecialiseerde Document Output Management (DOM)-systemen om hun polissen, contracten, voorwaarden, brieven, facturen en acceptgiro’s geautomatiseerd aan te maken, te printen en te versturen. Voor het samenstellen van deze bedrijfsdocumenten wordt het ITP platform gebruikt. Dit platform werd vroeger op werkplekken geïnstalleerd en later werd overgeschakeld op gebruik van een server om onderhoud te beperken. Deze vroegere serverversie was een IT-gestuurd document compositie systeem dat werkt als een black box, een engine die op de achtergrond draait en van afstand bediend wordt door medewerkers van organisaties. IT-gestuurd betekende dat medewerkers van de verkoop-, marketing- of facturenafdeling geen invloed konden uitoefenen, anders dan hun wensen kenbaar te maken aan de IT-afdeling en te wachten tot de gewenste mutatie door de IT-afdeling was uitgevoerd. Met het nadeel van conflicterende belangen van de verschillende afdelingen.

Organisaties kregen echter sterk de behoefte om snel in te kunnen spelen op de markt en op wet- en regelgeving. Eindgebruikers van ITP wilden zelf aan het stuur zitten om de content van de documenten aan te passen en om een nieuwe documenten samen te stellen. Om onder meer die reden is ITP/Server aangevuld met de webgebaseerde oplossing ITP/OnLine Server.

Als het niet kan zoals het moet...

...dan moet het maar zoals het kan. Een aantal van de bovenstaande problemen is dan ook opgelost door in arren moede branches te maken in het product. Met een slimme build procedure en een goed versiebeheer-systeem is dat prima te realiseren, maar helemaal zonder pijn in het hart gaat het toch niet. In andere gevallen is het probleem simpelweg niet opgelost en is er een andere weg gekozen. In plaats van het gebruik van client certificates kan de authenticatie ook elders in de keten geregeld worden.

In het geval van het porteren van de web service zit het probleem in de tools die beschikbaar zijn voor het genereren van een web service. Deze zijn allemaal sterk georiënteerd op het vertalen van een Java-klasse naar een WSDL. De andere kant op, gegeven een WSDL een Java-klasse genereren, levert in de praktijk niet altijd het gewenste resultaat. Gevolg is dat elke tool> in feite een eigen standaard voorschrijft. Hoe meer tools, hoe meer standaarden. En hoe minder Standaard. Dit geldt uiteraard niet voor degene die bereid is om de tools links te laten liggen. Dat laatste is echter een weinig vruchtbare houding als het gaat om het bouwen aan en vermarkten van een product in een zich snel ontwikkelende markt. De enige mogelijke oplossing die dan rest ligt in het “verzachten” van de specificatie. Dan maar een iets andere WSDL. Uiteraard één die vervolgens wel weer terug te porteren is naar de oorspronkelijke implementatie, zodat er uiteindelijk toch door beide implementaties een standaard-interface geboden wordt. Met een grote letter S.

Conclusie

Zonder standaarden heeft de moderne ICT-er geen leven. Toch toont het bovenstaande aan dat er nog veel te winnen valt in de praktijk van de standaarden. In de meeste gevallen is er wel een min of meer elegante oplossing te bedenken. Vaak betekent dat helaas wel dat er onevenredig veel tijd verloren gaat aan pietluttigheden. Pietluttigheden waar je eigenlijk niet over na zou hoeven denken als de standaard net even iets meer Standaard was geweest.

Johan Roos is Senior Software
Engineer bij Aia Software

Lees meer over Aia Software

Ga terug naar We Love IT uitgave 5 - 2008

Advertentie