From the Mist

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.

Laten we het eerst maar draaiende krijgen, dan zien we later wel hoe we het goed kunnen doen.

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.

Automatisering is datgene doen wat je al deed, maar nu geheel of gedeeltelijk ondersteund door computers.

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.

Hoe een fabriek een auto maakt is niet belangrijk: dàt  hij het doet wel.

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.