Jakarta Enterprise Beans

Jakarta Enterprise Beans

Tipus	component-based software engineering (en) i especificació tècnica
Versió estable	4.0.1 (4 maig 2022)
Llicència	Eclipse Public License 2.0 GPL linking exception
Part de	Java EE
Característiques tècniques
Plataforma	Java EE
Equip
Creador/s	IBM
Desenvolupador(s)	Fundació Eclipse
Fonts de codi  Codi font Codi font
Més informació
Lloc web	projects.eclipse.org… (anglès)
Stack Exchange	Etiqueta

Jakarta Enterprise Beans (EJB; anteriorment Enterprise JavaBeans) és una de les múltiples Java APIs per la construcció modular de programari empresarial. És un component de la part servidora que encapsula la lògica de negoci de la part servidora. Un contenidor web EJB proveeix un entorn d'execució per components de programari relatius a l'entorn web, incloent-hi la seguretat informàtica, gestió del cicle de vida de Java Servlets, processat de transaccions i altres serveis web. L'especificació EJB és un subtipus de l'especificació Jakarta EE.^[1]

L'especificació EJB va ser desenvolupada inicialment el 1997 per IBM i adoptada posteriorment per Sun Microsystems (EJB 1.0 i EJB 1.1) el 1999.^[2] i millorada sota la Java Community Process com JSR 19 (EJB 2.0), JSR 153 (EJB 2.1), JSR 220 (EJB 3.0), JSR 318 (EJB 3.1) i JSR 345 (EJB 3.2). L'especificació EJB pretén aportar una manera estàndard d'implementar el codi de negoci de la part servidora (back-end), típicament trobat a les aplicacions d'empresa, en oposició al codi d'interfície d'usuari (front-end). Aquest codi es trobava molt sovint resolent els mateixos tipus de problemes i es va trobar que solucions a aquests problemes es programaven de forma repetida pels programadors. Els Jakarta Enterprise Beans intentaven gestionar qüestions tan habituals com la persistència, integritat transaccional i seguretat, de manera estàndard, alliberant els programadors perquè es concentressin en el problema que els ocupava realment.

L'especificació EJB detalla com un servidor d'aplicacions aporta:

• Persistència, integrada a la Java Persistence API
• Processament Transaccional
• Control de la concurrència
• Programació orientada a events, usant Java Message Service i Java Connectors
• Invocació asíncrona de mètodes
• Planificació de tasques
• Anomenament i serveis de directori (JNDI)
• Comunicació entre processos usant RMI-IIOP i Serveis Web
• Seguretat (Java Cryptography Extension (JCE) i JAAS)
• Implantació de components de software en un servidor d'aplicacions
• Desplegament de components de programari en un servidor d'aplicacions

Addicionalment, les especificacions d'Enterpise JavaBean defineix els rols que juga el contenidor EJB i els EJBs i també com implantar els EJB en un contenidor. Noteu que l'especificació EJB no detalla com un servidor d'aplicacions proveeix persistència (una tasca delegada a JPA), sinó que detalla com la lògica de negoci pot ser integrada fàcilment als serveis de persistència oferts pel servidor d'aplicacions.

Aquesta visió que va ser convincentment presentada pels promotors d'EJB, qui principalment eren IBM i Sun Microsystems, de manera que els Enterprise JavaBeans foren ràpidament adoptats per grans empreses. Tanmateix, els problemes no van tardar a aparèixer i conseqüentment la fama d'EJBs va començar a deteriorar-se. Pels novells, les APIs de l'estàndard foren prou més complexes del que els desenvolupadors estaven acostumats a trobar. Una abundància en la gestió d'excepcions, interfícies requerides i la implementació de la classe bean com una Classe abstracta, eren poc habituals i menys intuïtives per molts programadors. Vist això, els problemes als que l'estàndard EJB pretenia adreçar-se com el mapeig d'objectes relacional i la integritat transaccional, són complexos. Finalment molts programadors van trobar que les APIs eren massa complicades, escampant-se així la percepció que els EJBs introduïen complexitat sense aportant beneficis reals.

A més, les empreses van trobar que usar EJBs per encapsular lògiques de negoci, penalitzava el rendiment. Això és degut al fet que l'especificació original només permetia que les invocacions de mètode remot es fessin amb CORBA (i opcionalment d'altres protocols), encara que la gran majoria d'aplicacions de negoci, de fet, no requerien la funcionalitat de computació distribuïda. L'especificació EJB 2.0 s'adreçava a aquest problema afegint el concepte d'interfícies locals que podien ser cridades directament sense penalitzar el rendiment per aplicacions que no eren distribuïdes per diversos servidors.

La qüestió de la complexitat, tanmateix, continuava obstaculitzant l'acceptació dels EJBs. Tot i que les noves eines de gran qualitat que van aparèixer per donar suport al desenvolupament van facilitar la creació i l'ús dels EJBs automatitzant la majoria de tasques repetitives, aquestes eines no ajudaven a entendre l'ús de la tecnologia. Més encara, una contramaniobra va emergir de soca-rel entre els programadors. Els principals productes d'aquest nou escenari eren els anomenats "lleugers" (és a dir, en comparació dels EJBs) i tecnologies com Hibernate (per la persistència i el mapeig d'objectes relacional) i Spring Framework (que proveeix una alternativa i menys feixuga manera de codificar la lògica de negoci). A pesar de les seves mancances davant els avantatges dels EJBs en termes de grans negocis, aquestes tecnologies van créixer en popularitat i van ser adoptades cada cop més per sectors desencantats amb EJBs.

Gradualment un consens en la indústria va anar fent emergir que la virtut primera dels EJBs -habilita integritat transaccional sobre aplicacions distribuïdes- tenia l'ús limitat per la majoria de les aplicacions empresarials. La funcionalitat oferta per entorns més senzills com Spring i Hibernate era més útil per aplicacions d'empresa. D'acord amb això, l'especificació EJB 3.0 (JSR 220) era un punt de partida radical respecte als seus predecessors, seguint aquest nou paradigma. Aquí s'aprecia una clara influència respecte Spring, el seu ús de POJOs i el seu suport a la injecció de dependència per simplificar la configuració i la integració de sistemes heterogenis. Gavin King, el creador d'Hibernate, va participar en el procés d'EJB 3.0 i se'l considera una veu lliure en defensa d'aquesta tecnologia. Moltes funcionalitats d'Hibernate van ser incorporades a la Java Persistence API, el substitut dels Entity Beans a EJB 3.0. L'especificació dels EJB 3.0 usa fortament les anotacions (meta dades), una funcionalitat afegida al llenguatge Java en la seva versió 5.0, per habilitar un estil de programació molt menys feixuc.

D'acord amb això, en termes pràctics, EJB 3.0 és bastant una API completament nova, semblant-se molt poc a les especificacions prèvies d'EJB.

Un contenidor d'EJB pot representar tres categories de beans principals:

• Session Beans (beans de sessió)
  • Stateless Session Beans (sense estat)
  • Stateful Session Beans (amb estat)
• Entity Beans (beans d'entitat)
• Message Driven Beans (MDBs o Message Beans)

Stateless Session Beans (beans de sessió sense estat) són objectes distribuïts que no tenen estat associat a ells, de manera que s'hi pot accedir concurrentment. Els continguts de variables de cada instància no garanteixen ser preservades entre diferents crides. La manca de càrrega addicional per mantenir una conversa amb el programa cridant els fa menys intensius en recursos que els beans amb estat.

Stateful Session Beans (beans de sessió amb estat) són objectes distribuïts que tenen estat, es mantenen al corrent de quin programa que els crida és el que estan tractant durant una sessió. Per exemple, la comprovació en una botiga web podria ser gestionada per un bean de sessió amb estat, que usaria el seu estat per estar al corrent de quin client és el que està al procés de comprovació. Per altra banda, enviar un e-mail a atenció al client podria ser gestionat per un bean sense estat, donat que és una operació puntual i no és part d'un procés de diferents passes. L'estat dels beans de sessió amb estat hauria de ser persistent, però l'accés a la instància del bean està limitat només a un client.

Entity Beans són objectes distribuïts que tenen un estat persistent. L'estat persistent pot ser gestionat pel mateix bean o no ser-ho. En el primer cas, els beans són Bean-Managed Persistence (BMP). En el segon cas, on és el contenidor qui se'n cuida de la seva persistència, són Container-Managed Persistence (CMP).

Message Driven Beans són objectes distribuïts que es comporten de manera asíncrona. És a dir, gestionen operacions que no requereixen resposta immediata. Per exemple, un usuari d'un lloc web que clica el botó "mantingueu-me informat de futures actualitzacions" podria disparar una crida a un Message Driven Bean per afegir l'usuari a una llista a la base de dades de l'empresa. Aquesta crida és asíncrona, ja que l'usuari no necessita esperar a ser informat del seu bon o mal funcionament). Aquest beans se subscriuen a cues de missatges JMS (Java Message Service) o temes que envien missatges. Els MDB van ser afegits a l'especificació 2.0 per permetre processos dirigits per events dintre dels contenidors EJB. A diferència d'altres tipus de beans, els MDB no tenen una perspectiva de client (interfícies Remote/Home), és a dir, els clients no poden visitar una instància d'MDB. Simplement escolten qualsevol missatge entrant d'una cua JMS (o tema) i els processa automàticament.

Hi ha proposats altres tipus d'Enterprise Beans. Per exemple, Enterprise Media Beans (JSR 86) pensats per la integració d'objectes multimèdia en aplicacions J2EE.

Els EJB estan implantats en un contenidor EJB al marc d'un servidor d'aplicacions. L'especificació descriu com un EJB interacciona amb el seu contenidor i com el codi del client interacciona amb la combinació contenidor/EJB. Les classes EJB usades per aplicacions estan incloses al package javax.ejb. (El paquet javax.ejb.spi és una interfície proveïdora de serveis usada només per implementacions de contenidors EJB).

Amb la versió EJB 2.1 i les anteriors, cada EJB havia d'oferir una classe d'implementació i dues interfícies (Java). El contenidor EJB creava instàncies per la classe d'implementació per proveir la implementació de l'EJB. Les interfícies eren usades pel codi del client de l'EJB.

Ambdues interfícies, anomenades interfícies Home i Component, especificaven les signatures dels mètodes remots de l'EJB. Els mètodes es dividien en dos grups:

Mètodes de classe No lligats a una instància específica, com ara aquells usats per crear una instància EJB ( mètode factoria) o trobar una entitat EJB existent (vegeu tipus d'EJB, a dalt). Aquestes eren declarades per la interfície Home.

Mètodes d'instància És a dir, mètodes lligats a una instància específica. Estan situats a la interfície Component.

Com que aquestes són simplement interfícies Java i no classes concretes, el contenidor EJB ha de generar classes per aquestes interfícies que actuaran com un proxy al client. El codi del client invoca un mètode als proxies generats, que al seu lloc, empaqueten els arguments en un missatge i l'envien al servidor EJB.

L'especificació EJB requereix que els contenidors EJB suportin accedir als EJBs usant RMI-IIOP. Els EJBs poden ser accedits des de qualsevol aplicació CORBA o proveir Serveis web.

Els contenidors EJB han de suportar tant les transaccions ACID gestionades pel contenidor com les transaccions manejades pel bean. Les transaccions manejades pel contenidor usen una sitaxi declarativa per especificar transaccions al descriptor de la implantació (deployment descriptor).

El JMS és usat per enviar missatges dels beans al obejctes clients, per deixar que el client rebi missatges asíncrons des d'aquests beans. Els MDB poden ser usats per rebre missatges d'aplicacions client de forma asíncrona usant cues JMS o un Topic (tema).

Els clients dels EJB posen l'objecte de la implementació de la Interfície Home usant JNDI. La interfície Home també pot ser trobada usant el servei de noms de CORBA. Des de la interfície de Home, el codi del client pot trobar beans d'entitat i també crear i eliminar EJBs existents.

El contenidor EJB és responsable d'assegurar que el codi de client té prou privilegis sobre un EJB.

L'especificació EJB també defineix un mecanisme que permet els EJB ser implantats de manera similar sense tenir en compte la plataforma específica EJB triada. La informació sobre com el bean hauria de ser implantat (com ara el nom de les interfícies Home o Remota, si i com cal emmagatzemar el bean a una base de dades, etc.) són especificades al descriptor de la implantació.

El Descriptor de la Implantació és un document XML que té una entrada per cada EJB a implantar. Aquest document XML especifica la informació següent, per cada EJB:

• Nom de la interfície Home
• Classe java pel Bean (objecte de negoci)
• Interfície Java per la interfície Home
• Interfície Java per l'objecte de negoci
• El gestor encarregat de la persistència (només per Entity Beans)
• Rols de seguretat i permisos

Els contenidors EJB per diversos fabricants requereixen més informació de la implantació que als de l'especificació EJB. Requeriran la informació addicional com fitxers XML a part, o altres formats de fitxer de configuració. Un fabricant de plataforma EJB generalment proveeix les seves pròpies eines que llegiran aquest descriptor de la implantació i possiblement generen un conjunt de classes que implementaran les interfícies Home i Remote.

Des d'EJB 3.0 (JSR 220), el descriptor és substituït per un conjunt d'anotacions Java a la implementació de l'Enterprise Bean (a nivell codi font), si bé encara és possible usar un descriptor XML en lloc seu.

Jakarta Enterprise Beans 4.0, com a part de Jakarta EE 9, era una versió d'eines que principalment movia els noms de paquets de les APIs dejavax.ejb ajakarta.ejb.^[3]

Altres canvis incloïen l'eliminació d'APIs descontinuades que no tenia sentit que foren mogudes al nou paque i l'eliminació de característiques que depenien d'altres característiques que eren eliminades de Java o qualsevol altre lloc de Jakarta EE 9. Les APIs eliminades foren:

• mètodes basats en java.security.Identity que foren eliminats a Java 14.
• mètodes basats en Jakarta XML RPC per reflectir l'eliminació de l'XML RPC a la plataforma Jakarta EE 9.
• mètodeEJBContext.getEnvironment() descontinuat.
• "Suport per Interoperabilitat Distribuïda" per reflectir l'eliminació de CORBA a Java 11 i la plataforma Jakarta EE 9.

Altres canvis menors incloïen marcar l'API Group d'Enterprise Beans 2.x com "Opcional" i fer l'anotacióSchedule repetible.

Els Jakarta Enterprise Beans 3.2, ja com part de Jakarta EE 8 i, malgrat usar encara l'abreviatura "EJB", han estat reanomenats oficialment com "Jakarta Enterprise Beans" per l'Eclipse Foundation per no trepitjar la marca registrada "Java", propietat d'Oracle.

JSR 345. Enterprise JavaBeans 3.2 era una versió relativament menor que principalment contenia clarificacions de l'especificació i aixecava algunes restriccions que imposava anteriorment però al cap i a la fi no servia cap propòsit real. Unes poques característiques completes d'EJB foren també demandades per ser a EJB 3 lite i funcionalitats que eren proposades per ser fetes opcionals, ho van acabar sent en aquesta versió.

Les característiques següents foren afegides:

• La passivització d'un Bean amb estat pot ser desactivada via l'atribut @Stateful (passivationCapable = false)
• TimerService pot obtenir tots els cronòmetres actius al mateix mòdul
• Els mètodes de cicle de vida (p.e. @PostConstruct) pot ser transaccional per beans de sessió amb estat usant l'anotació @TransactionAttribute ja existent
• La interfície Autocloseable implementada per un contenidor incrustat

JSR 318. El propòsit de l'especificació de les Enterprise JavaBeans 3.1 és simplificar encara més l'arquitectura EJB, reduint la seva complexitat des del punt de vista dels desenvolupadors i, al mateix temps, afegint una nova funcionalitat en resposta a les necessitats de la comunitat:

• Visió local sense interfície
• Empaquetat en .war del components EJB
• EJB Lite: definiciód'un subtipus d'EJB
• EJB Global JNDI Names portables
• Singletons
• Inicialització d'aplicacions i finalització d'Events
• Millores en l'EJB Timer Service
• Simple Asynchrony (@Asynchronous per beans de sessió)

JSR 220 - Canvis principals: Enrere queden les tasques feixugues, ja és fàcil escriure EJBs. Simplement cal entendre bé les anotacions. No hi ha més interfície Home, interfície Remota i fitxer ejb-jar.xml. Ja només cal la interfície de negoci i un bean que implementa aquesta interfícies.

JSR 153 - Canvis principals

• Suport a Serveis web (novetat) : beans de sessió sense estat que poden ser invocats sobre SOAP/HTTP. També, un EJB pot fàcilment accedir un Servei Web usant la referència del nou servei.
• Servei de temps EJB (novetat): mecanisme basat en events per la invocació d'EJBs en moments específics.
• Els Message-driven beans accepten missatges d'altres fonts que no siguin només JMS.
• Destinacions de missatges (la mateixa idea que les referències EJB, referències de recursos, etc.) hi han estat afegides
• Afegits al llenguatge de queries d'EJB (EJB-QL) : ORDER BY, AVG, MIN, MAX, SUM, COUNT i MOD
• XML Schema és usat per especificar descriptors de la implantació, en lloc dels DTDs

JSR 19 - Canvis majors: objectius generals:

• L'arquitectura estàndard de components per construir aplicacions distribuïdes de negoci orientades a objectes en Java
• Fer possible construir aplicacions distribuïdes combinant components desenvolupats usant eines de fabricant diferents
• Fer fàcil escriure aplicacions (d'empresa): els desenvolupadors de l'aplicació no hauran d'entendre les transaccions de baix nivell i els detalls de la gestió de l'estat, multi-threading, pooling de connexions i d'altres APIs de baix nivell complexes
• Seguirà la filosofia Escriu un cop, executa arreu de Java. Un Bean d'empresa pot ser desenvolupat un cop i llavors implantat sobre múltiples plataformes sense recompilació o modificacions del codi font
• S'adreça al desenvolupament, implantació i aspectes propis del temps d'execució dintre del cicle de vida d'una aplicació de negoci
• Defineix els contractes que permeten a les eines de fabricants diferents per desenvolupar i implantar components que interoperen en temps d'execució
• Compatibilitza amb plataformes servidores existents. Els fabricants podran millorar els seus productes ja fets per suportar EJBs
• Compatibilitza amb altres APIs de Java
• Aporta interoperabilitat entre Beans d'empresa i components Java 2 Enterprise Edition (J2EE) així com aplicacions fetes en altres llenguatges de programació, diferents de Java
• Compatibilitza amb els protocols de CORBA (RMI-IIOP)

Canvis majors:

• Descriptors de la implantació, en XML
• Contextos JNDI per defecte
• RMI sobre IIOP
• Seguretat dirigida pel rol, no pel mètode
• Suport al bean d'entitat obligatori, no opcional

Objectius per la versió 1.1:

• Aporta millor suport per l'ensamblatge d'aplicacions i la implantació
• Especifica en més gran detall les responsabilitats pels rols individuals d'EJB

Anunciada a la JavaOne de 1998, el tercer aplec de desenvolupadors de Java. Objectius per la versió 1.0:^[4]

• Definició dels distints "Rols EJB" que són assumits per l'arquitectura de components
• Definició de la vista de client de Beans d'empresa
• Definició de la vista del desenvolupador pels Beans d'empresa
• Definició de les responsabilitats d'un Contenidor EJB i servidor; junts munten un sistema que suporta la implantació i execució de Beans d'empresa

• Plana principal del producte EJB de Sun
• API de J2EE 1.4
• API d'EJB 3.0