Gevaarlijk speelgoed

Enterprise Java Beans (EJB’s) zijn hot! EJB’s zijn een hype! Een cv zonder EJB’s stelt niks voor! Softwareontwerpers en vele anderen bezwijken dagelijks voor dit soort kreten en besluiten om EJB’s als standaardoplossing in te zetten voor multitier-systemen. Gewapend met dikke pillen over EJB’s en ‘design patterns’ gaan ze met frisse moed aan de slag.

Maanden na het verstrijken van de deadline is het project nog niet af. Iedereen is in paniek: programmeurs begrijpen nog steeds niks van het ontwerp, bugs op de productieserver zijn niet te reproduceren op de ontwikkelserver en de klant dreigt weg te lopen. Hoe heeft het zover kunnen komen?

Los van de redenen waarom softwareontwerpers EJB’s gebruiken, komt dit soort problemen bij velen bekend voor. De ontwerper wil een component maken met (ongetwijfeld) prachtige functionaliteit, maar aangezien het een EJB moet zijn, wordt hij in een keurslijf gedwongen dat niets met de gewenste functionaliteit te maken heeft.

Het begint al met de parameteroverdracht: de invoer van de component. In plaats van de vier losse parameters die nodig zijn, moet het design pattern ‘Transfer Object’ toegepast worden, zodat alle parameters in een verzamelobject worden ingepakt. Dit is alleen maar om het netwerkverkeer te verminderen, terwijl al duidelijk is dat deze component lokaal zal worden gebruikt. De specificaties spreken echter over een potentieel netwerk.

Aan de andere kant van de ‘lijn’ in de component moet de ontwerper alles weten over ‘Home-interface’, ‘Remote-interface’ en ‘Abstract EJB-classes’. Daarmee maakt hij dan een laag om de feitelijke component heen. Deze laag wil hij wellicht helemaal niet, maar is wel verplicht. Om vervolgens de complexiteit weer te verdoezelen, wordt een ‘Business Delegate’ gemaakt. De gebruiker van de component kan deze dan ‘eenvoudig’ gebruiken. Om precies te zijn, nog net iets minder eenvoudig dan wanneer er geen EJB-technieken waren toegepast, vanwege het Transfer Object-gedeelte.

De belofte van Java om zonder aanpassingen in diverse omgevingen uitgevoerd te worden – write once, run everywhere – is redelijk ingelost voor serverapplicaties. Voor EJB’s geldt dat helaas een stuk minder. De EJB-specificaties zijn zo onduidelijk en incompleet dat elke applicatieserver een specifieke configuratie nodig heeft om de component te laten werken. Het is behoorlijk naïef om te denken dat een werkende EJB zomaar op een applicatieserver van een andere fabrikant kan worden geïnstalleerd. Daarbij komt nog eens dat een softwareontwerper zich bindt aan een leverancier door te kiezen voor EJB’s.

Waarom EJB’s?

De meestgebruikte argumenten om EJB’s te gebruiken zijn schaalbaarheid, transactiemanagement en ‘connection pooling’. Dat zijn inderdaad waardevolle zaken, maar het gebruik van EJB’s is niet de enige manier om die te realiseren.

EJB-technologie biedt volgens de folder alles om een schaalbaar systeem mogelijk te maken. De belangrijkste component in het systeem, de database, echter slechts met veel moeite schaalbaar te maken. De meestgebruikte oplossing om een database te versnellen, is dan ook snellere hardware in plaats van EJB’s.

De ‘beans’, eventueel verspreid over meerdere machines, praten allemaal met dezelfde database. ‘Entity Beans’ – of althans de containers waarin ze draaien – moeten op de hoogte zijn van elkaars wijzigingen. Dat is dus helemaal niet schaalbaar en veroorzaakt een explosie van netwerkcommunicatie.

Bij transactiemanagement denken velen wellicht aan transacties die verdeeld zijn over meerdere systemen. Een kreet als ‘two fase commit’ hoort daarbij.

De ontwerper heeft dat echter niet vaak nodig. Als hij het bij de hand heeft gehad, ging het waarschijnlijk om een database en een ander systeem, bijvoorbeeld een Customer Information Control System (CICS) op een mainframe. Bestaan er eigenlijk wel ontwerpers die een wijziging op beide systemen in één transactie hebben verwerkt in een EJB?

De ontwikkelaar kan zelf heel goed bepalen of een ‘method’ in een transactie kan meedoen, of dat een transactie zelfs verplicht is. Dat zou achteraf door niemand veranderd mogen worden. Bij EJB’s moet dat echter wel gebeuren en dat is erg onhandig. Een belangrijk ‘gratis’ aspect van EJB-containers is ‘connection pooling’. Dit zorgt ervoor dat de softwareontwerper snel een reeds geopende ‘connection’ krijgt, in plaats van er telkens opnieuw één te openen. Dit is een belangrijk voordeel dat een EJB-container biedt. Hieronder wordt bekeken of de containers daarin uniek zijn.

Alternatieven

Wie meer dan bovenstaande argumenten kan bedenken om EJB’s te gebruiken, moet wellicht doorgaan langs deze moeizame weg. Mocht dit niet het geval zijn dan is er een aantal eenvoudige alternatieven.

Om te beginnen is er de schaalbaarheid, die in de meeste gevallen prima bereikt kan worden door het aantal webservers uit te breiden. Hiervoor is al beschreven dat we helemaal niet gelukkig zijn met de manier waarop je de transactieverwerking moet instellen. Ontwerpers kunnen heel goed zelf bepalen wanneer een transactie begint en wanneer deze eindigt. Een JDBC Connection biedt al ondersteuning voor de databasetransactie.

Voor de pooling van connections zijn er meerdere (open source-) oplossingen, zoals de Apache DBCP (http://jakarta.apache.org/commons/dbcp/). Kijk ook eens naar het Spring framework (http://www. springframework.org) dat steeds populairder lijkt te worden. Dit framework maakt zaken als transactie en beveiliging volledig transparant zonder gebruik te maken van ingewikkelde EJB-constructies.

Conclusie en aanbeveling

Indien er een herkansing wordt aangeboden voor een nieuw multitier-project door een leidinggevende geven wij als aanbeveling om deze in Plain Old Java Object (POJO) te bouwen en in te zetten als webapplicaties. Het systeem kan dan simpel worden opgeschaald door deze webapplicaties over meerdere webservers te verspreiden.

Kortom, EJB’s veroorzaken in de meeste gevallen meer problemen dan dat ze oplossingen bieden. Kies ook eens voor de pragmatische aanpak, in plaats van architectonische wangedrochten en ‘design pattern overloads’. Gebruik alleen EJB’s als het echt niet anders kan en overleg vooraf met ervaren rotten in het vak. Immers, EJB’s zijn gevaarlijk speelgoed!

Jan-Jaap Zijlstra en René Bouw, Ordina SI&D DC Java