Het grote probleem bij de invoering van Java als onderdeel van transitietrajecten van organisaties is het gebrek aan vuistregels die aangeven op welke wijze de inzet van Java tools het beste kan plaatsvinden.

Er zijn mij nog geen publicaties bekend die een architectuur uitwerken gebaseerd op thin clients, communicerend met een server die als EJB container een multi-channel wereld bediend op een object-georiënteerde manier. De schrijvers van de bestaande publicaties maken zich vooral druk om de technologische implicaties van Java, hetgeen ook wel begrijpelijk is voor een jonge technologie.

Wat ik in dit artikel wil behandelen zijn de volgende vragen:

1. Wat zijn de beperkingen van de EJB architectuur?
2. Zijn er mogelijkheden om deze beperkingen te omzeilen?
3. Wat zijn de consequenties van deze mogelijkheden voor de kosten-effectieve inzet van standaard componenten?

Daarom kan dit artikel beschouwd worden als een aanzet om te komen tot een werkbare heuristiek voor het werken met deze technologie.

Beperkingen huidige EJB architectuur

Ik baseer mij op de Enterprise JavaBeans™ 1.1 Specification. Ik verwacht dat de 2.0 Specification geen schokkende wijzigingen zal aanbrengen.

De Java bullet

De thin client architectuur zoals die in de talloze publicaties rond Java wordt voorgesteld is een component architectuur die in feite gebaseerd is op een traditionele visie op automatisering.

Deze traditionele visie op client-server computing is het samenvoegen van

• presentatielogica (windows, buttons)
• business logica (algoritmes en business rules)
• data manipulatie logica (database verbindingen en SQL queries).

De wijze waarop applicaties binnen deze visie hun ondersteuning boden was op zijn beurt weer gebaseerd op metaforen als:

• von Neumann architectuur: pak data – muteren data – zet data weer terug. Scheiding van functies en data
• lopende band model van productielijnen

Geautomatiseerde ondersteuning op deze wijze ingericht is het eenvoudigst te modelleren met procesmodellen of functionele modellen. Deze modellen kenmerken zich door een sequentieel denkmodel dat processen schetst in hapklare brokken.

Wat in multitier applicaties beoogd wordt is het verplaatsen van business logica en data manipulatie logica naar de server in de vorm van één of meer componenten. Dit heeft een groot aantal voordelen:

1. Scalability in de zin van processen, threads, database connecties, netwerk sessies
2. Redundantie – replicatie en distributie
3. Gecentraliseerd management van code, versie, enz.

De vooronderstellingen echter die aan de basis lagen van de fat-client architecturen die vaak op basis van two-tier applicaties geïmplementeerd werden, zijn niet of nauwelijks veranderd of zelfs niet geëxpliciteerd.

Ontwikkelingen in vakgebieden als cognitieve wetenschap, management wetenschap (met name procesindustrie als vliegtuigindustrie en automobielindustrie), en computerwetenschap hebben ondertussen een overweldigende hoeveelheid materiaal aangedragen waardoor dit procesdenken aan kritiek onderhevig is geraakt:

1. Modelleren van parallelle processen is moeilijk – dit verhindert de ontwikkeling van massive parallel computing en gedistribueerde systemen.
2. Eenmaal geïmplementeerde sequentiële modellen zijn moeilijk uit elkaar te trekken. Dit kan gemotiveerd zijn door overwegingen van efficiëntie, maar ook in de procesindustrie door zaken als customer intimacy waardoor bouwen-op-maat noodzakelijk werd, of de productiviteitsverhoging die ontstond als gevolg van de herinrichting van productiemethoden waarin bijvoorbeeld een team verantwoordelijk werd voor het eindproduct (automobielindustrie).
3. Wijzigingen in het proces hebben gevolgen, vaak onverwacht, op allerlei plekken in de procesketen door talloze afhankelijkheden.

De op de server aanwezige applicatiecomponenten in de EJB architectuur volgen exact dit denkmodel. Er zijn twee soorten van EJB componenten:

• Session beans – bevatten de state van de interactie met een specifieke client. Deze zijn in principe niet persistent, hoewel enige transactionele ondersteuning mogelijk is.
• Entity beans – object representatie van persistente data. Dat deze persistente in de meeste gevallen relationeel is, is niet triviaal. Dat houdt onder meer in dat de   entity beans die we meestal tegenkomen zich gedragen als niet meer dan data-containers.

Enterprise Beans hebben nog een andere eigenaardigheid, namelijk het onderscheid tussen twee interfaces:

• Home interface – eigenlijk een factory interface voor het maken, vinden en verwijderen van enterprise beans.
• Remote interface – die toegang geeft tot de methodes die de bean implementeert

Mensen die niet geschoold zijn in object-oriëntatie zien dit onderscheid al heel snel als een uitnodiging om de remote interface te beschouwen als een functioneel component, gelijk aan het loskoppelen van functies en data dat zo belangrijk was in structured programming. Het is een opmerking die ik nog wel tegenkom in deze context: “ja maar data en functies moeten toch los van elkaar?”.

EJBObject, het object dat de remote interface dient te implementeren, is volgens de specificaties ook niet daadwerkelijk een onderdeel van de bean, maar van de container op de server waarbinnen de bean draait. Het is de application server die de container aanlevert. Clients werken in werkelijkheid niet met de bean, maar met EJBObject instanties, die dus eigenlijk als een soort wrapper op de bean functioneren. Nogmaals: dit zegt alleen iets over de wijze waarop de specificatie voorschrijft hoe Enterprise Beans, EJB Containers en application servers met elkaar samenwerken. Conceptueel is er geen reden om EJBObject instanties en de EJB zelf los te zien van elkaar, zelfs integendeel, en we zullen later zien wat hiervan de consequenties voor een effectief gebruik van deze technologie.

Een mogelijke implementatie van een systeem dat gebruik maakt van deze componenten is die waarin de session bean de implementatie bevat van functionele specificaties en procesmodellen, en de entity bean niet meer is dan een wrapper op de database tabellen. Veel bestaande business rules die in (of rond) de database waren geïmplementeerd worden hier eenvoudig hergebruikt. De IT infrastructuur gaat een nieuw tijdperk in, de managers zijn tevreden (“we zijn over op Java”), en de verwachtingen rond besparingen zijn groot:

• hergebruik
• kunnen herinrichten van bedrijfsprocessen (bijvoorbeeld om nieuwe markten open te breken of op bestaande markten beter te kunnen concurreren)
• outsourcing

Dat de ontnuchtering snel zal komen is niet moeilijk te voorspellen. In feite is dit al aan het gebeuren, getuige de berichtgeving. Een boodschap die OO al jaren probeert te verkondigen, wordt namelijk schijnbaar achteloos geweld aangedaan. Men ziet het inzetten van Java technologie als een technologische oplossing waardoor deze problemen via de weg van de technologie, min of meer magisch, opgelost zullen worden. Bovendien waren de problemen misschien wel duidelijk, maar de manier waarop OO deze problemen dacht op te lossen lang niet – in feite zijn er maar weinig mensen die dit begrepen, getuige de kwaliteit van de meeste OO projecten. Een technologische oplossing is daardoor verleidelijk aantrekkelijk.

Technologische oplossingen voor een cognitief probleem moeten met groot wantrouwen bekeken worden. In de meeste gevallen zullen deze niet veel meer beogen dan het verhogen van de winst van de leverancier van de oplossing.

Ik wil in dit artikel niet uitgebreid ingaan op deze problematiek, maar verwijzen naar andere publicaties hierover.

Java, maar dan goed

Essentieel in de door mij geschetste aanpak zijn de volgende kwaliteitseisen:

1. Geheel los van de technische applicatiearchitectuur is er een OO domein model beschikbaar in UML. Voor de eisen waaraan dit model moet voldoen, zie de andere artikelen op deze site, bijvoorbeeld de artikelen over Business Centred Architecturen.
2. Op de server draait in een executable omgeving een implementatie van het OO business model. Dit zou beschouwd kunnen worden als een simulatiemodel omdat het daadwerkelijk draait. Deze applicatie noemen we in dit artikel de business server.
3. De implementatie van het business model kan e.v.t. met standaard componenten plaatsvinden. Dit is echter niet noodzakelijk. De architectuur is gebaseerd op de eis dat een transitie naar componenten transparant en incrementeel plaats kan vinden, en dat standaard componenten hier ingepast moeten kunnen worden.

Wat zijn nu de mogelijke communicatielijnen met het op de server geïmplementeerde business model of domeinmodel? Ik noem enkele voorbeelden.

1. Domein ↔ RMI (momenteel JRMP, later IIOP) ↔ Java Client.
2. Domein ↔ CORBA IDL via IIOP, of een COM/CORBA service via IIOP ↔ andere clients (bijvoorbeeld in Smalltalk geschreven).
3. Domein ↔ RMI ↔ ActiveX control dat zich gedraagt als een RMI client proxy ↔ Microsoft client.
4. Domein ↔ RMI ↔ Servlet ↔ Browsers via HTTP via de HTTP/Web server.
5. Domein ↔ (optioneel: Applicatie Server) ↔ HTTP/Web Server ↔ Servlet ↔ EJB componenten

De architectuurstandaarden schrijven voor op welke wijze deze verschillende lagen aan elkaar gekoppeld worden. Het referentie architectuurmodel is gebaseerd op het volgende schema:

Hopelijk is voldoende duidelijk geworden dat deze applicatie, die waarin het business model dus draait, centraal staat in de informatie architectuur. De koppeling met de ondersteunende systemen zoals de J2EE architectuur is niet triviaal. Er zijn twee aspecten die hierin zorgvuldig onderzocht moeten worden:

1. Niet functionele requirements zoals fail-over, clustering, load-balancing en performance, alsmede load-scalability
2. Gebruik van eenvoudige standaard adapters voor de koppeling

Niet-functionele requirements

Bij de toepassing van de architectuur zoals die in dit artikel wordt voorgesteld is het van belang om aan dit punt extra aandacht te schenken omdat de methode namelijk zo weinig mogelijk gebruik maakt van technologische oplossingen om het business model te implementeren. Hierdoor kan dit onderdeel het meest gevoelig zijn voor de eisen die in een gedistribueerde omgeving aan performance worden gesteld. De vergelijking kan gemaakt worden met de traditionele transactiemonitoren die in een periode waarin het aantal interacties met bestaande databases sneller groeide dan de software van die tijd aankon een oplossing kon bieden door software die in staat was 100 transacties per seconde te doen op te schalen naar 1000 of 10.000 transacties per seconde. Dezelfde software kon gebruikt blijven worden, alleen de transactiemonitor zat als een schil om die software heen.

Adapter-technologie voor de koppeling

Aangezien alle complexiteit in termen van business complexiteit is geïmplementeerd op de business server is er een bonus voor de aangekoppelde systemen: deze kunnen aanzienlijk eenvoudiger, en daardoor sneller en goedkoper, ontwikkeld worden dan voorheen.

Met de opkomst van de Java 2 Enterprise Edition (J2EE) van Sun is voor veel organisaties de vraag actueel of zij met deze architectuur aan het werk willen. Sommigen zullen misschien zelfs het gevoel hebben dat zij dat moeten, en dat er geen alternatieven zijn.

De situatie voor veel organisaties is immers dat er telkens momenten aanbreken voor vernieuwing van bestaande systemen. De overwegingen die dan gemaakt moeten worden zijn niet altijd gebaseerd op concrete overwegingen en zijn vaak ook gevoelsmatig.

Wat zijn de concrete overwegingen?

1. De ondersteuning voor bestaande technologie is te duur geworden.
2. De bereidheid van het personeel om met de bestaande technologie te werken is aan het verminderen (ook een gevoelsmatig argument vanuit de medewerker bekeken maar zeker een concreet argument in termen van beschikbaarheid van personeel).
3. De bestaande technologie is niet of te kostbaar in staat mee te gaan in veranderende eisen wat betreft functionaliteit en beschikbaarheid.
4. Er is een wildgroei ontstaan van oplossingen die allemaal gebruik maken van verschillende technologische middelen, en vanuit beheersmatig oogpunt is deze situatie contraproductief geworden.

Vanuit beheersmatig perspectief zijn dit argumenten die niet altijd voldoende gevalideerd worden. Er is iemand die het roept, en het klinkt wel plausibel, en wanneer een guru in het veld ook zoiets roept is het al snel een waarheid gegoten in beton. De vraag stellen of het wel waar is wordt vaak zelfs niet gewaardeerd, en afgedaan als demotiverend. Wanneer een leidinggevende zijn positie dacht te versterken door de nieuwe tools te introduceren kan het stellen van de vraag zelfs nog vervelender consequenties hebben: de criticaster wordt uit de organisatie verwijderd!

Laten we echter uitgaan van een positief scenario en aannemen dat de organisatie tot de vernieuwende impuls is gekomen door een weldoordacht en beheerst proces. Wat zijn dan de gevolgen?

Er is als het ware een vacuüm ontstaan in de organisatie. De vraag is gesteld, het antwoord moet nog worden gevonden. Zodra bestaande IT bedrijven van dit vacuüm op de hoogte geraken moet de organisatie wel heel sterk in haar schoenen staan om de stortvloed van “deskundig” advies te doorstaan en daarbij de zinnen te bewaren. Consultants verschijnen uit alle hoeken en gaten, en wie daarbij in staat is als eerste een redelijk gedegen indruk te maken heeft het fundament gelegd voor een uiterst boeiend spel van veranderingsprocessen. Mensen met een andere boodschap worden niet echt gewaardeerd, men moet immers een keus maken, en telkens een andere weg inslaan zou nergens toe leiden. Kritiek in de beginfase is ook niet echt populair. De technische mensen raken er alleen maar van slag van, worstelend als zij zijn om nieuwe kennis te verwerken, en hun managers zijn niet in staat om de argumenten te beoordelen en denken alleen maar aan hoeveel het kost en hoe de overgang zo snel en goedkoop mogelijk te doen verlopen.

In dat vacuüm valt nu J2EE. Een technologie die nog steeds het aura om zich heen heeft van Java, namelijk het is nieuw, het is sexy, en vooral: het is cool. Ieder bedrijf wil wel iets meepikken van die uitstraling toch? Bovendien heeft het verhaal van J2EE een aantal onderdelen die verdomd interessant klinken: bestaande databases kunnen gewoon gebruikt worden, bonen op de server maken deze transparant beschikbaar in een multichannel omgeving: internet, WAP, voice-respons systemen. De leverancier van de applicatieservers leveren steeds meer ondersteuning voor andere “legacy” systemen als ERP en CRM systemen en de wereld voor een IT manager begint plotseling een stuk meer licht toe te laten.

Dat er aan het verhaal een aantal onderbelichte vraagstukken kleven is, zoals ik al zei, niet populair om te roepen. Wat zijn nu die onderbelichte vragen?

1. Het is nieuwe technologie. Wat zijn hiervan de gevolgen voor stabiliteit, ondersteuning door tools, deskundigheid van de adviseurs?
2. Het lijkt op wat we al deden, in feite kunnen we gewoon doorgaan met wat we al deden. Dat klinkt aantrekkelijk maar is het dat wel? Wat waren de oorzaken van problemen in het verleden? Zijn deze oorzaken nu echt verdwenen door het sexy aura van Java?
3. De manier van toepassen van nieuwe technologie en tools is in het verleden altijd iets dat jaren nodig had om de heuristiek te ontwikkelen voor efficiënte toepassing. Deze heuristiek is er nu (nog) niet.
4. We passen de nieuwe tools toe door zoveel mogelijk te doen wat we al deden en het aan de leverancier van de tools over te laten de voordelen van de technologie transparant voor ons beschikbaar te stellen. Is dit wel de manier om nieuwe mogelijkheden te benutten?
5. Zijn de belangen van leveranciers in deze niet strijdig met die van de afnemers en maken we ons op die manier niet alleen maar nog meer afhankelijk van die leveranciers?
6. Zijn er ook alternatieven, en in hoeverre sluiten die aan op J2EE?

Het stellen van vragen is iets dat we op school geleerd hebben als een belangrijke vaardigheid, laten we bij het toepassen van nieuwe technologieën hiermee vooral doorgaan.