Jakarta EE: verschil tussen versies

Verwijderde inhoud Toegevoegde inhoud
k Linkfix ivm sjabloonnaamgeving met AWB
Xqbot (overleg | bijdragen)
k robot Anders: fa:سکوی جاوا، نسخه سازمانی; cosmetische veranderingen
Regel 2:
'''Java 2 Enterprise Edition''' ''(J2EE)'' is een ontwikkelplatform van het [[software]]bedrijf [[Sun Microsystems]]. J2EE biedt een methode voor het ontwerpen, ontwikkelen, samenstellen en gebruiken van bedrijfsapplicaties. Het platform biedt een multi-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|JavaJavaprogramma]]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 [[databank]]en (''databases'') en het gebruik van allerlei generieke diensten.
 
Het J2EE-platform is een [[platformonafhankelijk]]e, 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 ==
De Java 2 Enterprise Edition is een uitbreiding van 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:
 
Regel 17:
* Ingebouwde ondersteuning voor ''naming services''
 
== 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 ''businesslogica''). 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.
 
Op basis van deze architectuur ondersteunt J2EE 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 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 [[JavaServer Pages|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.
 
Regel 31:
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).
 
Regel 40:
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 J2EE als platform ongetwijfeld het meest bekend is om zijn component-technologieën ([[Enterprise JavaBeans|EJB]] en [[servlet]]s plus [[JavaServer Pages|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.
 
Regel 49:
Al deze API's staan de J2EE-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 J2EE-specificatie geeft een uitgebreide opsomming van de faciliteiten die een J2EE-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 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]]'' ("koppelverkoop") toch weer op de loer.
 
== 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 functionerend systeem te verkrijgen. Dit geldt zeker als gebruik wordt gemaakt van EJB's.
 
Regel 72:
* [[JBoss]], [[Opensourcesoftware|Opensource]]-applicatieserver
* [[Apache (webserver)|Apache]], Opensource-applicatieserver in ontwikkeling
* Orion Application Server, applicatieserver geschreven in Java
 
[[Categorie:Java (programmeertaal)]]
Regel 84:
[[en:Java Platform, Enterprise Edition]]
[[es:Java EE]]
[[fa:جاواسکوی نسخهٔجاوا، نسخه سازمانی]]
[[fi:Java Platform, Enterprise Edition]]
[[fr:Java EE]]