ebooksgratis.com

See also ebooksgratis.com: no banners, no cookies, totally FREE.

CLASSICISTRANIERI HOME PAGE - YOUTUBE CHANNEL
Privacy Policy Cookie Policy Terms and Conditions
Enterprise JavaBean - Viquipèdia

Enterprise JavaBean

De Viquipèdia

Un Enterprise JavaBean és un component de la part servidora, gestionat pel contenidor i pensat per la construcció modular d'aplicacions d'empresa. L'especificació EJB és una de les moltes APIs de Java de la Plataforma Java Enterprise Edition. EJB encapsula la lògica de negoci d'una aplicació. L'especificació EJB va ser desenvolupada inicialment el 1997 per IBM i adoptada posteriorment per Sun Microsystems (EJB 1.0 i EJB 1.1) i millorada sota la Java Community Process com JSR 19 (EJB 2.0), JSR 153 (EJB 2.1) i JSR 220 (EJB 3.0). L'especificació EJB pretèn aportar una manera estàndard d'implementar el codi de negoci del back-end, típicament trobat a les aplicacions d'empresa (en oposició al codi d'interfície d'usuari anomenat 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 Enterprise JavaBeans 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. D'acord amb això, l'especificació EJB detalla com un servidor d'aplicacions aporta:

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.


Taula de continguts

[edita] Història

[edita] Adopció ràpida seguida de crítiques

Aquesta visió que va ser convincentment presentada pels promotors d'EJB, qui principalment eren IBM i Sun Microsystems, així que els Enterprise JavaBeans foren ràpidament adoptats per grans empreses. Tanmateix, els problemes no van tardar en 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 a què 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 farragosa 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.

[edita] Reinventant els 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 els 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 farragós.

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.

[edita] Tipus 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 propi 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.

[edita] Execució d'EJBs

Els EJB estan implantats en un contenidor EJB al marc d'un servidor d'aplicacions. L'especificació descriu com un EJB interactua amb el seu contenidor i com el codi del client interactua 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 proveïr 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 (veieu 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.

[edita] Comunicació Remota

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 proveïr Serveis web.

[edita] Transaccions

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

[edita] Events

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

[edita] Naming i Serveis de Directori

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.

[edita] Seguretat

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

[edita] Implantació dels EJBs

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), encara que encara és possible usar un descriptor XML al seu lloc.

[edita] Historial de Versions

[edita] EJB 3.0, llançament final (02/05/2006)

JSR 220 - Canvis principals: Enrere queden les tasques farragoses, 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.

[edita] EJB 2.1, llançament final (24/11/2003)

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

[edita] EJB 2.0, llançament final (22/08/2001)

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)

[edita] EJB 1.1, llançament final

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 pel llançament 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

[edita] EJB 1.0 (24/03/1998)

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

  • 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

[edita] Enllaços externs


aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu -