Java 2 Enterprise Edition

Van Wikipedia

___	Portaal Javaplatform

Java 2 Enterprise Edition (J2EE) is een ontwikkelplatform van het softwarebedrijf Sun Microsystems. Het biedt een componentgebaseerde aanpak 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 (web)servers, 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 databases en het gebruik van allerlei generieke diensten.

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

Inhoud

1 Conceptuele basis
2 Architecturele basis
- 2.1 Kleinere, lichtere applicaties en webapplicaties
- 2.2 Zwaardere, zakelijke applicaties
3 Ondersteunende API's
4 Leverancierneutraal
5 Nadelen van J2EE
6 Verwijzingen naar J2EE-applicatieservers

[bewerk] Conceptuele basis

De Java 2 Enterprise Edition is een uitbreiding op de standaard J2SDK die erop gericht is het makkelijker te maken om gedistribueerde applicaties te schrijven in Java. Om dit te bereiken is J2EE 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 J2EE toevoegt behoren onder andere:

Ondersteuning voor de infrastructuur van een gedistribueerde, zakelijke applicatie
Ingebouwde ondersteuning voor authenticatie
Ingebouwde ondersteuning voor gelijktijdig gebruik door meerdere 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

[bewerk] Architecturele basis

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 architectuur en het hele J2EE-concept is gebaseerd op de schaalbaarheid van deze architectuur.

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

[bewerk] Kleinere, lichtere applicaties en webapplicaties

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

[bewerk] 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 meerdere mensen (transactionaliteit e.d. zijn bij servlets en JSPs niet ingebakken).

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

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

[bewerk] Ondersteunende API's

Hoewel J2EE als platform ongetwijfeld het meest bekend is om zijn component-technologieën (EJB en servlets plus JSPs) 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 API's om een aantal zaken te regelen en niet alleen dat maar ook deze API's op een dusdanig 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 API om interactie met databases en andere systemen transactioneel te laten verlopen; de 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 JNDI API die het mogelijk maakt om allerhande zaken binnen een server en netwerk snel terug te kunnen vinden middels een soort "telefoonboek"; de JMS API die het mogelijk maakt om data uit te wisselen met zeer uiteenlopende applicaties en zo legacy systemen te ontsluiten; de JAAS API die in een uniforme beveiliging voor toegang tot applicaties voorziet; en ingebouwde, zeer uitgebreide ondersteuning voor netwerk-communicatie.

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

[bewerk] Leverancierneutraal

De J2EE-specificatie geeft een uitgebreide opsomming van de faciliteiten die een J2EE-omgeving moet bieden, inclusief APIs'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. 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 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 toch weer op de loer.

[bewerk] Nadelen van J2EE

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 werkend systeem op te leveren. Zeker als gebruik wordt gemaakt van EJBs.

Het is dan ook van belang om, bij het overwegen of J2EE en EJBs gebruikt gaan worden, goed na te gaan of de complexiteit van het systeem opweegt tegen de voordelen die het biedt. J2EE is op zich geschikt voor het ontwikkelen 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 redelijke hoeveelheden geld achter zitten.

[bewerk] Verwijzingen naar J2EE-applicatieservers

Om een J2EE-applicatie te kunnen gebruiken is een J2EE-applicatieserver nodig. De applicatieserver implementeert de door de J2EE-specificatie beschreven APIs. 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 is een ruime keus aan applicatieservers beschikbaar: