CORPORACION UNIVERSITARIA MINITO DE DIOS

FACULTAD DE INGENIERIA DE SISTEMAS – PROGRAMA INGENIERIA DE

SISTEMA
DESARROLLO BASADO EN PLATAFORMAS
EJB java Beans Enterprise
ÍNDICE
Introducción
Aspectos generales de EJB
Ventajas de EJB
Servicios (middleware)
División de trabajo
Diversos vendedores
EJB y sus desventajas
Tiempo de desarrollo
Amplio conocimiento de Java
Tipos de EJB
Session EJB
Introducción a Java Persistence API
Persistencia en el nivel web
Persistencia en el nivel EJB
Entornos de ejecución EJB
Servicios que brinda un contenedor EJB
Tipos de beans enterprise
Java Persistence Query Language
Bibliografía
 INTRODUCCION
En la actualidad, distintas aplicaciones realizan operaciones con el objetivo de
almacenar y recuperar grandes cantidades de datos. A pesar de todas las
tecnologías disponibles para la gestión de almacenamiento, los desarrolladores de
aplicaciones normalmente luchan para realizar operaciones que tengan un
rendimiento altamente eficiente.
Para esto, existen lenguajes de programación que facilitan la generación de
soluciones eficientes y, de igual manera, económicas. Una de ellas es Java, que si
bien requiere de grandes cantidades de código, la carga, en los momentos de
interactuar con bases de datos, se reduce considerablemente, debido a sus
recursos y propiedades enmarcadas en la filosofía de la programación orientada a
objetos.
ASPECTOS GENERALES DE EJB
Siglas de Enterprise Java Bean. Es un componente que debe ejecutarse en un
contenedor de EJB y se diferencia bastante de uno tipo Java Bean. Es decir, no se
puede acceder a él directamente, sino a través de un objeto que haga las veces de
intermediario. Principalmente se encarga de agrupar funcionalidades para
determinada aplicación, aun así, si un Java Bean es comparado con este, un EJB,
se puede definir como un deployable component, es decir, requiere que exista un
escenario de ejecución como parte de un Java Application Server.
Ventajas de EJB
A través de un contenedor, un EJB brinda diferentes funcionalidades y servicios que
no están disponibles normalmente en un Java Bean, las siguientes son algunas de
ellas.
Servicios (middleware)
Cuando un componente de software es diseñado, deben definirse múltiples
servicios para que funcionen correctamente, entre ellos se encuentran:
• Al generarse un error ¿cuál es el procedimiento adecuado que debería
ejecutarse?
• ¿Cuál es la alternativa, en caso de que la base de datos definida y asignada
se encuentre desactivada?
• En caso de no lograr cumplir con éxito los procedimientos establecidos, ¿se
debe intentar nuevamente ejecutar las transacciones pendientes?
Es importante tener en cuenta que los servicios tienden a ser requeridos, al igual
que la lógica que se encuentra inmersa en los principales componentes, aun así,
los EJB se pueden ofrecer a través del uso de un contenedor del mismo tipo, en el
cual se agrega la lógica de negocio, definiendo y generando componentes para ello.
División de trabajo
Es posible dividir componentes principales (EJB) de servicios (EJB Container) ya
que facilita la identificación de una división de trabajo, es decir, un diseñador de
componentes logra centrar su esfuerzo en la lógica de proceso, sin que el diseño
de servicios o middleware le preocupe. De igual forma, este último deberá estar
pendiente y centrarse en su área.
Sin embargo, dicha división de trabajo genera una pregunta: ¿cómo se alcanza la
interoperabilidad? La operabilidad interna entre componentes y servicios se debe
principalmente a la existencia de definiciones para EJB, dichas características han
de especificar los requisitos para un contenedor EJB y los requerimientos para un
EJB.
Diversos vendedores
Usar especificaciones propias de EJB hace que existan múltiples proveedores tanto
de contenedores, que están incluidos en un Java Application Server, así como
Enterprise Java Beans, los cuales se encargan de resolver algún tipo de lógica.
Lo anterior garantiza que cualquier EJB independiente del EJB Container se pueda
ejecutar, esto quiere decir que puede adquirirse un conjunto de EJB producidos por
Inprise o incluso desarrollarlos en la empresa y estos podrían ser ejecutados en un
contenedor EJB de IBM, JBoss o Inprise.
Al hacer mención en cuanto a las distinciones existentes entre calidad y costo, por
lo general, estas dependen bastante de las funcionalidades que van más allá de las
especificaciones EJB. El contenedor EJB, definido y generado por IBM, brinda una
integración más eficaz con sus productos como DB2 o Domino, mientras Inprise
puede desarrollar su contenedor, enfocado hacia entornos financieros, Oracle
continúa haciéndolo hacia la manufactura y sus productos en bases de datos.
EJB y sus desventajas
Tiempo de desarrollo
Construir un sistema usando EJB es bastante complejo, sin embargo, para algunas
organizaciones puede llegar a representar una gran solución, debido a la relación
entre el tiempo, la complejidad y el costo que para diversas instituciones suele ser
una solución económica frente a los grandes beneficios que esta le genera.
Amplio conocimiento de Java
EJB es el principal componente de J2EE, debido a esto, depende en gran medida
de otras partes de J2EE: RMI, JNDI y JDBC.
Inprise Hace referencia a un servidor de herramientas de desarrollo para entornos
distribuidos.
RMI Es un paquete de Java que permite manejar objetos (y sus respectivos
métodos) de manera remota, con el fin de utilizar los recursos de un servidor de
manera transparente para el usuario local (Departamento de Electrónica
Universidad Técnica Federico Santa María, 2005).
JNDI Es una interfaz de programación de aplicaciones (API) que proporciona
funciones de nomenclatura y directorio para aplicaciones escritas utilizando el
lenguaje de programación Java TM. Se define como independiente de cualquier
implementación de servicio de directorio específico. Por lo tanto, se puede acceder
a una variedad de directorios (nuevos, emergentes y ya implementados) de una
manera común (CODE Q&A, s.f.).
JDBC Es una API que permite la ejecución de operaciones sobre bases de datos
desde el lenguaje de programación Java, independientemente del sistema operativo
donde se ejecute o de la base de datos a la cual se accede, utilizando el lenguaje
SQL del modelo de base de datos que se utilice (ajpdsoft.com, s.f.)
Tipos de EJB
Session EJB
Estos permiten realizar cierta lógica que ha sido solicitada por un cliente ya sea un
JSP Servlet, Applet o incluso otro EJB. Pueden mencionarse los dos tipos de
Session EJB .
Stateless (session) EJB
Como su nombre indica, no se encarga de mantener estados (stateless) en el
contenedor EJB, estos son utilizados para la realización de actividades rutinarias
que no necesitan rastrear o identificar al cliente. Dentro de los EJB de este tipo
puede mencionarse: búsquedas generales y operaciones matemáticas complejas.
Stateful(session) EJB
A diferencia de los EJB descritos anteriormente, los stateful facilitan mantener la
sesión del cliente en el contenedor EJB, de esta manera, puede trabajar con cierto
grupo de datos específicos gestionados por el contenedor. La aplicación apropiada
para este tipo de EJB es uno cuyos componentes son de tipo shopping cart o
compra, los cuales facilitan la identificación de productos e información de índole
personal del cliente mediante un lapso amplio (session).
Entity EJB
Estos suelen trabajar en conjunto con un repositorio de información (por lo general
una base de datos administrada bajo una arquitectura relacional), esto hace que el
EJB administre la información que se encuentra almacenada en sistemas diferentes
al contenedor EJB; en los stateful session, de ocurrir un inconveniente en el
contenedor, es probable que se pierda la información, en cambio, si se usa un Entity
EJB los datos podrán permanecer en el sistema más cercano. Dicho de otra forma,
los Entity EJB administran una copia exacta de la información que se encuentra en
un sistema diferente. De igual manera que Session EJB existen tres tipos de Entity
EJB:
Bean Managed Persistence
Estos necesitan que la lógica requerida para ingresar al sistema de información (por
lo general conectado a una base de datos), esté claramente definida de forma
manual. Casi siempre esta lógica se puede encontrar en JDBC en la que se define
cuándo y cómo debe ser accesada, modificada y resguardada la información entre
la base de datos y el EJB.
Container Managed Persistence
Este Entity Bean es administrado por el contenedor EJB, diferente al que posee un
Bean Managed EJB, donde es necesario definir una lógica puntual para el acceso
manual. En los Container Managed EJB el contenedor se encarga de generar toda
la lógica necesaria para acceder al sistema de información.

Messaging EJB
Este Entity Bean brinda un conjunto de funcionalidades de aplicaciones tipo
messaging como Rendez-Vous de Tibco o MQSeries de IBM. De forma general, un
sistema messaging funciona como un intermediario para poder recibir y hacer parte
de la publicación de mensajes. Dentro de las ventajas de un sistema de mensajes
es que su operación es de forma asincrónica también conocida como non-blocking.
Introducción a Java Persistence API
Java Persistence API o JPA es el estándar de Java que se encarga de automatizar
la persistencia de los objetos contenidos en una base de datos. Aun así, en un nivel
básico, logra generar dudas a quienes lo desarrollan. También puede definirse como
un conjunto de clases y métodos que per-sistentemente almacenan gran cantidad
de información en un repositorio de datos.
ClasesEs la definición de las características concretas de un determinado tipo de
objetos. Es decir, cuáles son los datos y los métodos de los que van a disponer
todos los objetos de esa clase (devjoker .com, s.f.).
En otras palabras, JPA es un frameworkque forma parte de Java y ofrece un
conjunto de interfaces y API para resolver el problema del almacenamiento de los
obje-tos en una base de datos relacional. JPA no es una implementación en sí
misma, sino que brinda interfaces para ser luego implementadas por distintos
proveedores. De esta manera, en el código se usa el API de JPA, que luego será
implementado por la librería que más convenga .
De forma muy simple, una tabla (en base de datos) se debe mapear contra una
clase y cada columna (atributo) contra un atributo de esa clase. Usaremos anotacio-
nes de JPA para indicar estas relaciones. Por eso la implementación con JPA se
deberá encargar del ocultamiento de la compleji-dad del acceso de datos y de
exponer obje-tos. Idealmente, una solución de softwarecon JPA, no requiere
generar Query SQL para interactuar con los datos (no tiene contacto directo con la
base de datos).
JPA ofrece:
Un conjunto de anotaciones (del pa-quete javax .persistence) para ano-tar nuestros
objetos e indicar cómo se realiza el mapeo a la base de da-tos .
• Un lenguaje de consultas llamado JPQL (Java Persistence Query Lan-guage) que
es utilizado para consul-tar los objetos de tipo Persistence.
Persistencia en el nivel web
En este punto, se hace supremamente necesario asociar componentes de bases de
datos de tipo relacional a objetos Java, con el fin de ser administrada a través de
las aplicaciones. Esto generó la aparición de la persistencia de objetos que
abstractamente es representada por una capa adicional en la debida arquitectura
de una aplicación. Por esto es importante tener en cuenta que, al desarrollar
soluciones de software en Java, debe resolverse en primera instancia si existe una
correcta integración con determinada base de datos, esto en pro de facilitar las
tareas de almacenamiento, actualización y recuperación de información. Se llama
persistencia de los objetos a la capacidad que existe para guardar y recuperar
información desde un medio de almacenamiento . Por ejemplo, la persisten-cia en
bases de datos relacionales se suele implementar a través del desarrollo de fun-
cionalidades específicas, haciendo uso de la tecnología JDBC o a través de
frameworksque automatizan y simplifican el proceso a partir de mapeos (conocidos
como Object Relational Mapping, ORM) en los que el uso de herramientas como
Hibernate facilita en gran medida la tarea.

Persistencia en el nivel EJB

En las soluciones de software, tareas como guardar y recuperar información obli-
gan a que exista una constante comunica-ción con una o varias bases de datos de
tipo relacional. Esto, en múltiples situaciones, representa un problema para los
desarro-lladores ya que en ocasiones los ejemplares orientados a objetos y el
diseño de datos tie-nen estructuras bastante distintas al interior de sus
correspondientes ambientes.
Las bases de datos relacionales suelen estar definidas con una estructura tabular,
mientras que los componentes orientados a objetos, por lo general se encuentran
asociados en forma de árbol. Esa distinción de impedancia hace que quienes
desarrollan múltiples tecnologías intenten construir un puente entre el mundo
orientado a objetos y los ambientes relacionales. La filosofía de trabajo Enterprise
Java Beans (EJB) brinda un método eficiente para minimizar esa distancia.
Entornos de ejecución EJB
Los EJB son objetos Java que exponen ciertas interfaces y permanecen ejecután-
dose al interior de un componente conocido como contenedor EJB. Estos no pueden
existir si se encuentran fuera de un contenedor de este tipo. De hecho, la relación
entre un Java Bean y su correspondiente contenedor se conoce como el principio
de Hollywood o inversión de control (no se pre-ocupe por llamar, nosotros lo
llamamos). Dicho contenedor hace referencia a un entorno de ejecución para tener
control sobre los enterprise beans . Este los guarda y administra de igual forma que
lo hace un motor servlet, alojando un servlet de Java. Aquí, el contenedor EJB ejerce
control sobre el bean enterprise para brindarle servicios de bajo nivel .Cuando las
aplicaciones tipo cliente desean interactuar con un EJB, este no accesa de forma
directa a él . En su lugar, el bean se encuentra aislado de la aplicación cliente
haciendo uso del contenedor.
Servicios que brinda un contenedor EJB
Una persona que quiera desarrollar las interfaces y las clases a partir del uso de
objetos bean enterprise, podrá acceder con facilidad a los servicios de bajo nivel
que se describen a continuación.
• Manejo de las transacciones.
• Seguridad.
• Persistencia.
• Acceso remoto.
• Control del correspondiente del ciclo de vida del componente.
• Repositorio de conexiones a la base de datos.
• Repositorio de ejemplares.
Debido a que el contenedor EJB administra los paquetes de servicios en términos
de los EJB y su infraestructura, un desarrollador podría, simplemente concentrarse
en crear la lógica de negocio de dicho objeto.
Tipos de beans Enterprise
EJB ha definido los beans enterprise en tres tipos diferentes, estos son:
• Beans dirigidos a través de mensajes.
• Beans de sesión.
• Beans de entidad.
Los beans de entidad y de sesión son llamados sincrónicamente a través de un
cliente tipo BE (bean enterprise). Los beansque se dirigen a través de mensajes
(MDB) son llamados a través de contenedores de mensajes, como un común
publicar/subscribir.
Beans orientados por mensaje
Estos hacen referencia a BE que admi-nistran de manera asincrónica los mensajes
entrantes. Por lo general, un componente de MDB se comporta como un oyente de
los mensajes que se han enviado, desde la perspectiva publicar/subscribir. Los MDB
son capaces de recibir mensajes que son compatibles con JMS. Los contenedores
EJB administran el ciclo de vida de los MDB pero a diferencia de los beans de
entidad y sesión, las aplicaciones clientes no suelen direccionarse al MDB con el
llamado de métodos. En lugar de eso, el respectivo MDB recibe los mensajes de
una fuente definida para ello mediante métodos de retrollamadas tipo Onmessage.
Beans de sesión
Estos representan un solo cliente que no se ha de compartir entre ellos. Por lo
general un cliente se encarga de llamar a los métodos que corresponden al bean de
sesión, los cuales se direccionan a través del contenedor EJB hacia el BE. El
encargado de realizar la lógica de negocio para el cliente es el bean de sesión.
Posteriormente el contenedor retorna el control al cliente.
Los beans de sesión no persisten entre diversas sesiones y se pueden encontrar
tres tipos:
Beans de sesión con estado
Los beans de sesión con estado man-tienen estados conversacionales con los
respectivos clientes durante el tiempo que dure la sesión. Esto hace que estos pue-
dan mantener diversos tipos de variables a través de llamadas desde un único
cliente entorno a una sola sesión, en el momento en que el cliente finaliza su
interacción con el contenedor EJB y el bean enterprise cul-mina la sesión del bean
y elimina los datos de estado del respectivo bean.
Beans de sesión sin estado
Este tipo de beans se caracterizan por no mantener estados conversacionales para
cada cliente. Cada vez que un bean de sesión sin estado es llamado, se considera
como una solicitud a un elemento nuevo, ya que sin importar el estado que exista
de las correspondientes variables, este se perderá.
El contenedor EJB no mantiene los beans de sesión sin estado en el
almacenamiento secundario; por esto un desarrollador debe tener claro que los
datos son temporales entre las llamadas de un cliente. La naturaleza temporal de
los beans de sesión sin estado facilita que un contenedor EB reutilice ejemplares de
beansy, por ende, optimice su rendimiento.
Beans de entidad
Estos componentes están pensados para que representen la lógica de negocio de
una entidad existente en un almacenamiento persistente, como una base de los
datos. Los beans de entidad pueden compartir algunas cualidades que se podrían
encontrar en una base de datos bajo un modelo relacional, por ejemplo:
Los beans de entidad suelen ser persistentes: el estado de un componente de este
tipo existe más allá del ciclo de vida de la aplicación en la que se ha generado,
incluso muchas veces, más allá del ciclo de vida del contenedor. Esto se traduce en
que el contenedor EJB tiene la capacidad de restaurar el bean de entidad a su
correspondiente estado original.
• Un bean de entidad permite compartir accesos: podría compartirse entre varios
clientes, haciendo que la concurrencia la maneje el contene-dor.
• Un bean de entidad posee claves primarias: existen clases primary key para la
identificación de un ejemplar de un bean de entidad. La clave primaria suele
contener toda la información requerida para ubicar uno almacenado.
De ser necesario, un bean de entidad podría participar en relaciones: existen
proyectos en los que se definen interfaces locales para el manejo de las relaciones
entre múltiples beans.
• Un bean de entidad puede participar en transacciones: debido a que varios clientes
pueden acceder y cambiar los datos, es relevante para los beans de entidad definir
los atributos transaccionales para su interacción. Una propiedad de transacción se
especifica en descriptores de despliegue. De igual manera los lími-tes de
transacción los administra el contenedor
La tarea de mapeo objeto-relacional que existe implícitamente en los beans de
entidad requiere que estos sean responsables de la inserción, actualización,
selección y eliminación de datos dentro de la correspondiente fuente. El proceso del
manejo de la comunicación entre la fuente de datos y el componente se conoce
como persistencia. Dicho de otra forma, se puede definir la persistencia como el
proceso donde se escribe la información en una fuente de datos externa. Existen
dos tipos de persistencia para los beans de entidad:
BMP (persistencia manejada por el bean)
Con BMP, el desarrollador es el responsable de escribir al interior del bean el código
que le permita acceder a la respectiva fuente de datos. Esta persistencia le ofrece
mayor flexibilidad a quien desarrolla, ya que puede controlar todos los accesos a la
fuente descrita anteriormente .• CMP (persistencia manejada por el
contenedor)Aquí, es el propio contenedor EJB el que maneja los accesos a la base
de datos que requiere el bean de entidad . Como resultado, el código de acceso a
los datos del bean no se encuentra acoplado a una fuente de datos definida. Esto
hace que el desarrollador se libere de escribir el código de acceso a los datos y
permite que el bean de entidad pueda ser desplegado en distintos contenedores y/o
contra diferentes fuentes de datos.
Java Persistence Query Language
También conocido como JPQL, hace referencia al lenguaje desarrollado para crear
consultas contra entidades para administrar información en una base de datos
relacional. Aquí se hace uso de las ya conocidas sentencias select, insert,updatey
delete .
Estructura de una consulta
La sintaxis JPQL es muy similar a la sin-taxis de SQL . Tener esto como referencia
es una ventaja, ya que la estructura de ese lenguaje es simple y es ampliamente
utili-zado en el entorno de las bases de datos, puesto que trabaja directamente
contra la base de datos relacional tablas, registros y campos; sin embargo, JPQL
trabaja con Java de clases e instancias .

Funciones escalares y agregadasLas funciones escalares devuelven valores

resultantes basados en los valores de entrada. Funciones de agregado devuelven
los valores resultantes mediante el cálculo de los de entrada .
Figura 3 . Ejemplo de funciones escalares y agregadas explicadas en claseFuente:
propia
Between and like: palabras clave
Between (entre), and (y) y like (como) son las palabras clave principales de JPQL.
Estas palabras clave se utilizan después de where, cláusula en una consulta.
Figura 4. Ejemplo de palabras clave explicadas en una clase Fuente: propia
Ordenar
Para ordenar los registros en JPQL, se utiliza la cláusula ORDER BY. El uso de esta
cláusula es igual que en SQL, pero se trata de entidades. El ejemplo siguiente
muestra cómo utilizar la cláusula ORDER BY

Figura 5. Ejemplo del uso de la cláusula ORDER BY explicada en una clase Fuente:
propia
Llamado a consultasUna anotación @NamedQuery se define como una consulta
con una cadena de pre-definida que es inmutable. En contraste con consultas
dinámicas pueden mejorar la organización del código al separar las cadenas de
consulta JPQL de POJO. También pasa con los parámetros de consulta en lugar de
incrustar los literales dinámicamente en la cadena de consulta y, por lo tanto,
produce más consultas eficientes.
Figura 6. Ejemplo de llamado a consultas explicado en una claseFuente: propia
Figura 7. Ejemplo de llamado a consultas explicado en una claseFuente: propia
Perezoso y ansioso por buscar
El concepto más importante de JPA es hacer una copia duplicada de la base de
datos en la memoria caché. Mientras se tramita con una base de datos, la JPA
primero crea un duplicado de los datos y solo cuando se ha comprometido con una
entidad, los cambios se realizan en la base de datos. Allí existen dos maneras de
obtener los registros de la base de datos.
Fetch ansioso
Al buscar ansiosos relacionados con objetos secundarios estos se cargan
automáticamente con el fin de encontrar un registro concreto.
Lazy fetch
Al recuperar el perezoso, objetos relacionados no se cargan automáticamente a
menos de que usted lo solicite específicamente para ellos. En primer lugar, se
comprueba la disponibilidad de objetos relacionados y notifica. Más tarde, si se
llama a cualquiera del método Getter de esa entidad, recupera todos los registros.
Un fetch perezoso es posible cuando se intentan buscar los registros por primera
vez. De esa manera, una copia del registro ya está almacenada en la memoria
caché . Para temas de rendimiento, es preferible este tipo de tarea. Es allí donde se
vislumbra la rea-lidad y la importancia de conocer algunas de las herramientas de
desarrollo de softwarepara brindar verdaderas soluciones web y móviles a las
diferentes problemáticas que se presentan en las áreas del conocimiento, la
industria y el hogar.

Referencias
IBM Knowledge Center. (2015). Creating entity beans with bean-managed
persistence Recuperado de https://www.ibm.com/support
/knowledgecenter/SSRTLW_9 .5 .0/com .ibm .j2ee .doc/topics /tebmpb .htmlOracle
. (2013). The Java EE 6 Tutorial. Recuperado de https://docs.oracle
.com/javaee/6/tutorial/doc/bnabo.htmlPavón, J . (2013). Java EE – Enterprise Beans
(EJB). Recuperado de https://www.fdi.ucm .es /profesor/jpavon/web/45-
ejb.pdfProgramación.net. (s.f.). Persistencia de objetos Java utilizando EJB.
Recuperado de https://programacion .net
/articulo/persistencia_de_objetos_java_utilizando_ejbs_301