Jakarta EE: verschil tussen versies

'''Java 2 Enterprise Edition''' ''(J2EE)'' is een ontwikkelplatform van het [[software]]bedrijf [[Sun Microsystems]]. HetJ2EE biedt een componentgebaseerde aanpakmethode voor het ontwerpen, ontwikkelen, samenstellen en gebruiken van bedrijfsapplicaties. Het platform biedt een [[multitiermulti-tier, gedistribueerd model]], herbruikbare componenten, een beveiligingsmodel, flexibel transactiebeheer en ondersteuning voor [[webservice]]s door middel van een geïntegreerde data-uitwisseling gebaseerd op [[XML]].

Bij het gebruik van [[programmeertaal Java|Java]]programma's op (web)[[server]]s, wordt vaak J2EE gebruikt. J2EE is een uitbreiding van de [[J2SDK]], Java 2 -standaardeditie, met bibliotheken die een groot aantal klassen bevatten voor het programmeren van (web)serverapplicaties, het communiceren met [[databasedatabank]]sen (''databases'') en het gebruik van allerlei generieke diensten.

De Java 2 Enterprise Edition is een uitbreiding opvan de standaard -[[J2SDK]] die erop gericht is het makkelijker te maken om [[Distributed computing|gedistribueerde applicaties]] te schrijven in [[Programmeertaal Java|Java]]. Om dit te bereiken is J2EE opgetrokken rond het principe van het uitbreiden van de al bestaande, "normale" Java-taal met [[Application Programming Interface|API's]] die een aantal zaken toevoegen die noodzakelijk zijn om gedistribueerde applicaties te schrijven voor een zakelijke omgeving. Tot de zaken die J2EE toevoegt, behoren onder andere:

* Ingebouwde ondersteuning voor gelijktijdig gebruik door meerdereverscheidene gebruikers

* Ingebouwde ondersteuning voor ''naming services''

J2EE 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 ''business logica''). Deze opzet volgt het principe van de [[Model-View-Controller-model|Model-View-Controller]] -architectuur en het hele J2EE-concept is gebaseerd op de schaalbaarheid van deze architectuur.

Kleinere, lichtere applicaties in J2EE worden over het algemeen opgetrokken uit een ''view-tier'' aan de voorkant bestaande uit webpagina's (een combinatie van [[HyperText Markup Language|HTML]] en [[JSP|Java Server Pages]]) en een ''model-tier'' of ''database-tier'' aan de achterkant, al dan niet in combinatie met een ''controller-tier'' opgebouwd uit [[servlet]]s er tussenin.

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/JSPsJSP'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 meerdereverscheidene presentatievormen of JSPsJSP's te combineren met dezelfde data zoals aangeleverd door een servlet) en betere onderhoudbaarheid en schaalbaarheid (door het verdelen van taken over meerdereverscheidene, losse onderdelen en het vermijden van de spaghetti-structuur die pure websites met een enkele ''tier'' eigen is).

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 meerdereverscheidene mensen (transactionaliteit e.d. zijn bij servlets en JSPsJSP's niet ingebakken).

Anders is dit als er gebruik wordt gemaakt van [[Enterprise JavaBeans]] (min of meer het kroonstuk van de J2EE). EJBsEJB's zijn bedoeld als een laatste laag tussen de servlets (of JSPsJSP's) en de model-laagmodellaag. EJBsEJB'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. EJBsEJB's maken het voor een ontwikkelaar makkelijk om te abstraheren van database en database-structuur, van specifieke server-infrastructuur en indeling. En EJBsEJB'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 J2EE-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 applicatie-serverapplicatieserver 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 en dergelijkeenzovoort. De precieze werking van de poort is zelf geen strikt programmeerwerk, maar hoortbehoort tot het domein van de declaratieve ontwikkeling -- dit gedrag wordt volledig bepaald door configuratie-bestandenconfiguratiebestanden, niet door code.

EJBsEJB'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 configuratie-werkconfiguratiewerk vergt en wellicht ook extra netwerk-communicatienetwerkcommunicatie (dus langzamer is). Gebruik is dusdaarom alleen een realistische optie voor zware, zakelijke applicaties die veel klanten kunnen verwachten of zeer betrouwbaar moeten zijn.

Hoewel J2EE als platform ongetwijfeld het meest bekend is om zijn component-technologieën ([[Enterprise JavaBeans|EJB]] en [[servlet]]s 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 J2EE als ontwikkelplatform niet direct in de aanwezigheid van deze component-technologieën.

Veel belangrijker dan de aanwezigheid van de componenten zelf is ongetwijfeld dat J2EE de component-technologie combineert met [[Application Programming Interface|API's]] om een aantal zaken te regelen, en niet alleen dat, maar ook deze API's op een dusdanigdusdanige 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 J2EE -platform behoren: de JTA ([[Java Transaction API|JTA]] API), om interactie met databases en andere systemen transactioneel te laten verlopen; de API [[JDBC]] API, 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]] API, die het mogelijk maakt om allerhande zaken binnen een server en netwerk snel terug te kunnen vinden middels een soort "telefoonboek"; de API [[JMS]] API, die het mogelijk maakt om data uit te wisselen met zeer uiteenlopende applicaties en zo ''legacy ''-systemen te ontsluiten; de API [[JAAS]] API, die in een uniforme beveiliging voor toegang tot applicaties voorziet; en ingebouwde, zeer uitgebreide ondersteuning voor netwerk-communicatienetwerkcommunicatie.

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

De J2EE-specificatie geeft een uitgebreide opsomming van de faciliteiten die een J2EE-omgeving moet bieden, inclusief APIsAPI's en andere technieken. Door nu alleen maar te kijken naar de specificatie, kan een ontwikkelaar applicaties ontwikkelen voor een generieke J2EE-omgeving en zou moeten kunnen verwachten dat die applicatie verder vlekkeloos draait in iedere J2EE-omgeving die de specificatie ondersteunt. J2EE 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.

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 J2EE 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 J2EE 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.

Het belangrijkste nadeel van J2EE 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 werkendfunctionerend systeem op te leverenverkrijgen. ZekerDit geldt zeker als gebruik wordt gemaakt van EJBsEJB's.

HetBij isde danoverweging ookJ2EE vanen belangEJB's omte gaan gebruiken, bijis het overwegendaarom ofvan J2EE en EJBs gebruikt gaan worden,belang goed na te gaan of de complexiteit van het systeem opweegt tegen de voordelen die het biedt. J2EE is op zich geschikt voor hetde ontwikkelenontwikkeling van alle soorten van gedistribueerde applicaties, maar zeker het inzetten van een EJB-architectuur is door de complexiteit eigenlijk voorbehouden voor de zwaardere toepassingen, waar redelijkeheel hoeveelhedenwat geld achter zittenzit.

Om een J2EE-applicatie te kunnen gebruiken is een J2EE-applicatieserver nodig. De applicatieserver implementeert de door de J2EE-specificatie beschreven APIsAPI's. Een J2EE-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:

*[[JBoss]], [[Opensourcesoftware|Open sourceOpensource]] -applicatieserver.

*[[Apache (webserver)|Apache]], Open source Opensource-applicatieserver in ontwikkeling.

*Orion Application Server, Application applicatie-server geschreven in Java