EJB's zijn gevaarlijk speelgoed

EJB's zijn hot! EJB's zijn een hype! Een CV zonder EJB's stelt niks voor!

Software-ontwerpers en vele anderen bezwijken dagelijks voor dit soort kreten en besluiten om EJB's als standaardoplossing in te zetten voor multitiersystemen. 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 ontwikkel-server en de klant dreigt weg te lopen. Hoe heeft het zover kunnen komen?

Los van de redenen waarom softwareontwerpers EJB's gebruiken, komen dit soort problemen bij velen bekend voor. De ontwerper wil een component maken met (ongetwijfeld) prachtige functionaliteit, maar aangezien het een Enterprise Java Bean (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 EJBspecificaties 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. Er komt nog eens bij dat een software- ontwerper zich bindt aan een leverancier door te kiezen voor EJB's.

Hieronder enkele URL's over dit onderwerp om aan te geven dat we nog heel lang over dit onderwerp door zouden kunnen vertellen:

http://c2.com/cgi/wiki?WhatsWrongWithEjb
(Whats wrong with EJB)
http://www.softwarereality.com/programming/ejb/index.jsp
(EJB?s 101 Damnations)

Waarom EJB's

EJB-technologie biedt volgens de folder alles om een schaalbaar systeem mogelijk te maken. Om dit voor deel te kunnen benutten moet ook de belangrijkste component in het systeem, de database, schaalbaar zijn. Een Oracle RAC cluster is een mogelijkheid als de extra licentiekosten geen bezwaar zijn. 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. Wij denken dat de ontwerper dat niet vaak nodig heeft, maar als hij het bij de hand heeft gehad, ging het waarschijnlijk om een database en een ander systeem, bijvoorbeeld 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 zou kunnen 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 software-ontwerper 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

Om te beginnen is er de schaalbaarheid, die in de meeste gevallen prima bereikt kan worden door alleen het aantal webservers uit te breiden. Hierboven 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 database transactie.

Voor de pooling van connections zijn er meerdere (open source-) oplossingen, zoals bijvoorbeeld de Apache DBCP: http://jakarta.apache.org/commons/dbcp/. Kijk ook eens naar het Spring framework (http://www.springframework.org) dat constant populairder lijkt te worden. Dit framework maakt zaken als transactie en beveiliging volledig transparant zonder gebruik te maken van de ingewikkelde EJB-constructies. Op het Oracle plat-form bieden ADF Business Components (BC) en Toplink vergelijkbare mogelijkheden, mits de JDeveloper IDE gebruikt wordt. Dat Oracle veel ziet in de combinatie Toplink en POJO?s blijkt uit het feit dat de volgende versie van de JHeadstart productiviteitsbooster naast ADF BC ook op basis van Top-link bindings een GUI kan genereren: http://www.oracle.com/technology/consulting/9iServices/JHeadstart.html.

Conclusie en aanbeveling

EJB's veroorzaken in de meeste gevallen meer problemen dan dat ze oplossingen bieden. Met Spring, Hybernate, ADF BC en Toplink kunnen schaalbare applicaties kosteneffectiever ontwikkeld worden zonder architec-tonische 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 en dienen alleen ingezet te worden als vooraf vaststaat dat de objecten Remote aangeroepen worden.

Michael Kreuwels,
Consultant ICT bij
Ordina SI&D DC Oracle.