Jakarta EE: verschil tussen versies
Verwijderde inhoud Toegevoegde inhoud
k linkfix |
k Linkfix ivm sjabloonnaamgeving met AWB |
||
Regel 1:
{{
'''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|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 [[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.
Regel 34:
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 J2EE). 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 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 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.
Regel 50:
==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.
Regel 62:
Om een J2EE-applicatie te kunnen gebruiken is een J2EE-applicatieserver nodig. De applicatieserver implementeert de door de J2EE-specificatie beschreven API'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:
* [[Oracle Corporation|Oracle]]
* [[BEA Systems]]
* [[Sun Microsystems]]
* [[Borland]]
* [[IBM]]
* [[Macromedia]]
* [[Novell]]
* [[JBoss]], [[Opensourcesoftware|Opensource]]-applicatieserver
* [[Apache (webserver)|Apache]], Opensource-applicatieserver in ontwikkeling
*Orion Application Server, applicatieserver geschreven in Java
| |||