Jakarta EE

Jakarta EE
Ontwerper(s)	Sun Microsystems
Ontwikkelaar(s)	Sun Microsystems
Recentste versie	10 (22 september 2022)
Status	Actief
Geschreven in	Java
Website	(en) Projectpagina
Portaal    Informatica Javaplatform

Jakarta EE, voorheen bekend als Java Platform, Enterprise Edition (Java EE) en Java 2 Platform, Enterprise Edition (J2EE), is een ontwikkelplatform van het softwarebedrijf Sun Microsystems. Jakarta EE biedt een methode voor het ontwerpen, ontwikkelen, samenstellen en gebruiken van bedrijfsapplicaties. Het platform biedt een multitier, gedistribueerd model, herbruikbare componenten, een beveiligingsmodel, flexibel transactiebeheer en ondersteuning voor webservices door middel van een geïntegreerde data-uitwisseling gebaseerd op XML.

Bij het gebruik van Javaprogramma's op servers, wordt vaak Jakarta EE gebruikt. Jakarta EE is een uitbreiding van de JDK, Java 2-standaardeditie, met bibliotheken die een groot aantal klassen bevatten voor het programmeren van serverapplicaties, het communiceren met databases en het gebruik van allerlei generieke diensten.

Het Jakarta EE-platform is een platformonafhankelijke, volledig geïntegreerde oplossing die een open markt creëert waarin elke leverancier kan leveren aan elke klant. Zo'n soort markt moedigt leveranciers aan om te innoveren en voorkomt dat klanten afhankelijk worden gemaakt van een eigen technologie. Op deze manier profiteren klanten meer door verbeterde producten en betere ondersteuning.

Conceptuele basis

Jakarta EE is een uitbreiding van de standaard-JDK die erop gericht is het makkelijker te maken om gedistribueerde applicaties te schrijven in Java. Om dit te bereiken is Jakarta EE opgetrokken rond het principe van het uitbreiden van de al bestaande, "normale" Java-taal met API's die een aantal zaken toevoegen die noodzakelijk zijn om gedistribueerde applicaties te schrijven voor een zakelijke omgeving. Tot de zaken die Jakarta EE toevoegt, behoren onder andere:

• Ondersteuning voor de infrastructuur van een gedistribueerde, zakelijke applicatie
• Ingebouwde ondersteuning voor authenticatie
• Ingebouwde ondersteuning voor gelijktijdig gebruik door verscheidene gebruikers
• Geautomatiseerde data-opslag
• Ingebouwde methoden om data-integriteit te garanderen
• Ingebouwde ondersteuning voor Enterprise Application Integration, om oudere applicaties mee te ontsluiten
• Ingebouwde ondersteuning voor naming services

Architecturele basis

Jakarta EE is opgetrokken rond het idee van een three-tier-applicatie: een voorkant die de interface voor de gebruiker regelt, een achterkant waarin data opgeslagen liggen (bijvoorbeeld een database) en een tussenlaag (of middle tier) waar het eigenlijke werk van de applicatie gedaan wordt (de zogeheten businesslogica). Deze opzet volgt het principe van de Model-View-Controller-architectuur en het hele Jakarta EE-concept is gebaseerd op de schaalbaarheid van deze architectuur.

Op basis van deze architectuur ondersteunt Jakarta EE de ontwikkeling van twee klassen van applicaties: lichtere applicaties of webapplicaties en de zeer zware, zakelijke applicaties.

Kleinere, lichtere applicaties en webapplicaties

Kleinere, lichtere applicaties in Jakarta EE worden over het algemeen opgetrokken uit een view-tier aan de voorkant bestaande uit webpagina's (een combinatie van HTML en Java Server Pages) en een model-tier of database-tier aan de achterkant, al dan niet in combinatie met een controller-tier opgebouwd uit servlets ertussenin.

In deze situatie bestaat de interface richting de gebruiker uit een combinatie van statische webpagina's en webpagina's die (gedeeltelijk) dynamisch opgesteld worden bij het laden vanaf de webserver -- dit laatste wordt gedaan door de JSP's (webpagina's met stukken code erin verweven) of door servlets (uitbreidingen op een webserver die in staat zijn desnoods hele webpagina's aan een stuk te genereren). De dynamische webpagina's zijn in principe in staat om direct met de achterliggende database te communiceren, in welk geval ze ook de zakelijke logica bevatten en dus feitelijk de middle tier "absorberen".

Een uitgebreidere variant van dit principe is die waarin servlets ingezet worden als een middle-tier-technologie. In deze opzet bestaat de web/JSP-voorkant alleen maar om data te presenteren aan de gebruiker, het echte werk wordt door servlets gedaan in de middle tier. Het is nu feitelijk mogelijk dat servlets ook de uiteindelijke webpagina's genereren, maar vaker wordt ervoor gekozen om data-presentatie puur in webpagina's/JSP's te gieten en de servlets alleen de data af te laten vangen.

De laatste opzet biedt een aantal voordelen boven de eerste. Deze voordelen bestaan voornamelijk uit toegenomen flexibiliteit van de applicatie (in de vorm van de mogelijkheid om verscheidene presentatievormen of JSP's te combineren met dezelfde data zoals aangeleverd door een servlet) en betere onderhoudbaarheid en schaalbaarheid (door het verdelen van taken over verscheidene, losse onderdelen en het vermijden van de spaghetti-structuur die pure websites met een enkele tier eigen is).

Zwaardere, zakelijke applicaties

Het bijzondere nadeel van de bovenstaande benadering is dat de ontwikkelaar van een dergelijke applicatie er zelf zorg voor moet dragen dat zijn applicatie zichzelf niet gaat "bijten" bij gelijktijdig gebruik door verscheidene mensen (transactionaliteit e.d. zijn bij servlets en JSP's niet ingebakken).

Anders is dit als er gebruik wordt gemaakt van Enterprise JavaBeans (min of meer het kroonstuk van de Jakarta EE). EJB's zijn bedoeld als een laatste laag tussen de servlets (of JSP's) en de modellaag. EJB's zijn bedoeld om diensten (interessante, zakelijke logica) aan te bieden aan een geïnteresseerde client-applicatie en om een abstractie te vormen van de inhoud van de database. EJB's maken het voor een ontwikkelaar makkelijk om te abstraheren van database en database-structuur, van specifieke server-infrastructuur en indeling. En EJB's bieden de ontwikkelaar de mogelijkheid om transactionaliteit van zijn applicaties voor zich geregeld te krijgen, om de hele omgang met de database automatisch te laten regelen, om op een mooie manier zijn applicaties te integreren met legacy-systemen en te communiceren met allerhande systemen.

Om dit te bereiken maakt een EJB stevig gebruik van een zogeheten decorerende proxy, in Jakarta EE-termen een container geheten. In dit systeem schrijft de ontwikkelaar min of meer alleen maar de interessante stukken van de EJB en laat hij zijn code verder door de applicatieserver inpakken in een pakket dat een poort vormt naar zijn code. Toegang tot zijn code gaat uitsluitend via de poort. En de poort kan hieraan uiteraard ook functionaliteit toevoegen, zoals transactionele communicatie met de database, gesynchroniseerde toegang tot de interessante code enzovoort. De precieze werking van de poort is zelf geen strikt programmeerwerk, maar behoort tot het domein van de declaratieve ontwikkeling -- dit gedrag wordt volledig bepaald door configuratiebestanden, niet door code.

EJB's maken het aanzienlijk eenvoudiger om betrouwbare, schaalbare applicaties te bouwen in afzienbare tijd. Het nadeel van het gebruik van dit systeem is echter dat het veel configuratiewerk vergt en wellicht ook extra netwerkcommunicatie (dus langzamer is). Gebruik is daarom alleen een realistische optie voor zware, zakelijke applicaties die veel klanten kunnen verwachten of zeer betrouwbaar moeten zijn.

Ondersteunende API's

Hoewel Jakarta EE als platform ongetwijfeld het meest bekend is om zijn component-technologieën (EJB en servlets plus JSP's) die het de ontwikkelaar mogelijk maken om een gedistribueerde, zakelijke applicatie op te bouwen uit conceptueel nette, gescheiden en herbruikbare componenten, schuilt de werkelijke kracht van Jakarta EE als ontwikkelplatform niet direct in de aanwezigheid van deze component-technologieën.

Veel belangrijker dan de aanwezigheid van de componenten zelf is ongetwijfeld dat Jakarta EE de component-technologie combineert met API's om een aantal zaken te regelen, en niet alleen dat, maar ook deze API's op een dusdanige wijze integreert dat de ontwikkelaar van in ieder geval EJB's zich nauwelijks bewust hoeft te zijn (wel kan zijn, maar niet hoeft te zijn) van de toepassing van die API's.

Tot de ondersteunende technologieën van het Jakarta EE-platform behoren: de JTA (Java Transaction API), om interactie met databases en andere systemen transactioneel te laten verlopen; de API JDBC, om toegang tot de database te abstraheren en zo applicaties te kunnen ontwikkelen die direct overgezet kunnen worden van eender welke database naar eender welke andere database; de API JNDI, die het mogelijk maakt om allerhande zaken binnen een server en netwerk snel terug te kunnen vinden middels een soort "telefoonboek"; de API JMS, die het mogelijk maakt om data uit te wisselen met zeer uiteenlopende applicaties en zo legacy-systemen te ontsluiten; de API JAAS, die in een uniforme beveiliging voor toegang tot applicaties voorziet; en ingebouwde, zeer uitgebreide ondersteuning voor netwerkcommunicatie.

Al deze API's staan de Jakarta EE ontwikkelaar ter beschikking. De ontwikkelaar van EJB's kan veel ervan vaak zelfs gebruiken zonder erbij na te hoeven denken, omdat ze verstopt zitten in de Bean-container.

Leverancierneutraal

De Jakarta EE-specificatie geeft een uitgebreide opsomming van de faciliteiten die een Jakarta EE-omgeving moet bieden, inclusief API's en andere technieken. Door nu alleen maar te kijken naar de specificatie, kan een ontwikkelaar applicaties ontwikkelen voor een generieke Jakarta EE-omgeving en zou moeten kunnen verwachten dat die applicatie verder vlekkeloos draait in iedere Jakarta EE-omgeving die de specificatie ondersteunt. Jakarta EE biedt dus in principe niet alleen een aantrekkelijk ontwikkelplatform, maar ook een mechanisme dat een gebruiker van een applicatie en ook de ontwikkelaar ervan loskoppelt van een specifieke omgeving. Dit biedt voordelen met betrekking tot toekomstige ondersteuning en toepasbaarheid van ouder wordende applicaties. De specificatie geeft echter niet aan hoe een en ander geïmplementeerd dient te worden - dat laat de specificatie over aan de maker/verkoper van de omgeving. Het gevolg hiervan in de praktijk is dat de verschillende Jakarta EE-implementaties van de diverse leveranciers niet 100% compatibel met elkaar zijn; wat op het ene platform ontwikkeld is, draait niet noodzakelijkerwijs zonder aanpassingen op de applicatieserver van een andere leverancier. Daarmee wordt ingeleverd op de ambitie van Jakarta EE om een platform te zijn waarin de omgeving voor softwareontwikkeling en die voor het gebruik van de software volledig los van elkaar staan en ligt een vendor lock-in ("koppelverkoop") toch weer op de loer.

Nadelen van Jakarta EE

Het belangrijkste nadeel van Jakarta EE is ongetwijfeld de complexiteit van het opzetten en beheren van het ondersteunende systeem. Servermachines, applicatieservers, databaseserver, instellingen van al deze onderdelen, het zijn allemaal zaken die tot in de puntjes verzorgd moeten zijn om een goed functionerend systeem te verkrijgen. Dit geldt zeker als gebruik wordt gemaakt van EJB's.

Bij de overweging Jakarta EE en EJB's te gaan gebruiken, is het daarom van belang goed na te gaan of de complexiteit van het systeem opweegt tegen de voordelen die het biedt. Jakarta EE is op zich geschikt voor de ontwikkeling van allerlei soorten gedistribueerde applicaties, maar zeker het inzetten van een EJB-architectuur is door de complexiteit eigenlijk voorbehouden voor de zwaardere toepassingen, waar heel wat geld achter zit.

Jakarta EE-applicatieservers

Om een Jakarta EE-applicatie te kunnen gebruiken is een Jakarta EE-applicatieserver nodig. De applicatieserver implementeert de door de Jakarta EE-specificatie beschreven API's. Een Jakarta EE-applicatieserver bestaat functioneel gezien uit een tweetal containers: een webcontainer en een EJB-container. De webcontainer wordt gebruikt om servlets en JSP's te draaien, de EJB-container draait de EJB's.

Er zijn allerlei applicatieservers beschikbaar:

• Oracle
• BEA Systems
• Sun Microsystems
• Borland
• IBM
• Macromedia
• Novell
• JBoss, opensource-applicatieserver
• Apache, opensource-applicatieserver in ontwikkeling
• Orion Application Server, applicatieserver geschreven in Java

Bronnen, noten en/of referenties