Espacio Espacio Session EJB's (Stateful y Stateless) (Siguiente) Espacio

Razón de ser.

Enterprise Java Beans es el componente principal del grupo de especificaciones J2EE ( http://java.sun.com/j2ee ) definidas por Sun, a través de EJB's se define una estructura ("Framework") en la cual es posible manipular e interactuar con procesos e información que residen en diversos ambientes computacionales desde "MainFrames" hasta Bases de Datos. Estos componentes (EJB's) contemplan diversas características esperadas de una aplicación empresarial como: Control de Transacciones, Seguridad, Threading, Propagación de Transacciones, y otras funcionalidades más.

Dichos componentes son ejecutados dentro de un Application Server de los cuales existen aproximadamente 10 en el mercado, además cabe mencionarse que actualmente existen tres tipos principales de EJB's los cuales serán explorados a fondo en el resto de este curso.

Java Application Servers.

Un Java Application Server (ya denominado Application Server) proporciona el ambiente necesario para ejecutar EJB's; como fue mencionado anteriormente, ya existen cerca de 10 en el mercado y su estructura es la siguiente:

Java Application Server

Los dos componentes principales de un Application Server son el "Servlet Engine" (Web-Container) y "Enterprise Bean Engine" (Bean-Container) (aunque no sean comercializados como tal). Dentro del "Servlet Container" residen y se ejecutan JSP's y Servlet's, mientras en el "Enterprise Bean Container" se ejecutan EJB's.

Dentro de estos productos existen aquellos denominados "Fully J2EE Compliant", lo cual implica que cumplen con todas las especificaciones dictadas por Sun en J2EE, algunos productos "Fully J2EE Compliant" son:

En estos "Application Servers" no existe una clara distinción (al menos para el programador final) entre el "Servlet Engine" y el "EJB Engine" por lo que la ejecución de componentes se lleva acabo de una manera relativamente transparente. Para este curso se hará uso de "JBoss" el cual es únicamente un "EJB Container", sin embargo, integrado en la distribución de "JBoss" se encuentra un "Servlet Engine" denominado "Jetty" empleado en la ejecución JSP's/Servlets.

Aunque sean empleados estos dos componentes por separado, debido a la funcionalidad ofrecida por Java, será posible ejecutar estos mismos componentes desarrollados a lo largo de este curso en cualquier otro "Application Server"("Servlet Engine"/"EJB Container") con modificaciones mínimas de configuración.

Tipos de EJB's.

Session EJB's

Un Session EJB permite realizar cierta lógica solicitada por un cliente ya sea un JSP/Servlet, Applet e inclusive otro EJB. Existen dos tipos de Session EJB's:

Stateless (Session) EJB's

Este tipo de EJB como su nombre lo indica no mantiene estado(Stateless) en el "EJB Container", estos EJB's son utilizados para realizar tareas rutinarias que no requieren identificar o rastrear al cliente (JSP/Servlet) como : operaciones matemáticas complejas, búsquedas generales u otra tarea.

Statefull (Session) EJB's

A diferencia de Stateless (Session) EJB's este tipo de EJB's permiten mantener la sesión del cliente en el "EJB Container", de esta manera el cliente (JSP/Servlet/Applet) puede trabajar con cierto juego de datos especifico administrado por el "EJB Container", la aplicación ideal para este tipo de EJB es un componente de compra ("Shopping Cart") el cual puede identificar artículos e información personal del cliente a través de un lapso de tiempo extenso (Session).

Entity EJB's

Un Entity Bean a diferencia de un Session Bean trabaja en conjunción con un depósito de información (generalmente una Base de Datos), esto permite que el EJB manipule información residente en sistemas ajenos al "EJB Container"; en un Statefull (Session) EJB si ocurre una falla en el "EJB Container" se pierde toda información, mientras si se utiliza un Entity EJB aún permanecerá esta información en el sistema aledaño . En otras palabras, un Entity EJB manipula una copia | reflejo de información que reside en otro sistema.

Al igual que Session EJB's existen dos tipos de Entity EJB's:

(Entity) Bean Managed Persistence

Este tipo de Entity Bean requiere que la lógica necesaria para accesar el sistema de información ( Base de datos ) sea definida manualmente, por lo general esta lógica se encuentra en JDBC y define: como y cuando debe ser accesada|actualizada|guardada la información entre el EJB y la Base de Datos.

(Entity) Container Managed Persistence

Este Entity Bean como su nombre lo indica es manejado por el "EJB Container", a diferencia de un Bean Managed EJB donde se requiere definir lógica de acceso manualmente, en un Container Managed EJB el "EJB Container" genera toda lógica de acceso para el sistema de información ( Base de Datos ).

Aparentemente el Bean Managed EJB mencionado anteriormente, no tiene mucha razón de ser al existir un Container Managed EJB, sin embargo, hay casos donde es empleada lógica de acceso sumamente compleja la cual no es posible generar a través del "EJB Container", además de esto existen otras razones que serán exploradas en su sección correspondiente.

Messaging EJB's

Un Messaging EJB ofrece las funcionalidades de (valga la redundancia) sistemas "Messaging" como: MQSeries de IBM o Rendez-Vous de Tibco. A muy grandes rasgos un sistema "Messaging" ofrece el funcionamiento de intermediario para recibir y publicar mensajes ("Messages"), una de las ventajas de un "Messaging System" es que opera en forma asincrónica ("asynchroynous") o "non-blocking".

"Messaging System" ?

"Asynchronous" o "non-blocking" implica que un cliente (emisor) pueda publicar un mensaje sin la necesidad que el receptor se encuentre activo, esencialmente el "Messaging System" funciona como un agente ("broker") para facilitar el intercambio de mensajes.Las aplicaciones clásicas para un "Messaging System" son aquellas utilizadas por sistemas financieros, en donde la pérdida de mensajes es intolerable o ampliamente distribuida.

Cuando ocurre una transacción financiera generalmente esta atraviesa por un "Messaging System", lo cual garantiza que aunque el consumidor final (receptor) este desactivado el cliente(emisor) pueda continuar con sus acciones sin la necesidad de esperar confirmación, a esto último se le llama "non-blocking".

Otra aplicación financiera que utiliza "messaging" son los denominados "tickers financieros" donde constantemente aparecen los valores de acciones, en este tipo de sistema existe un cliente(emisor) que publica el mensaje ("valor de acciones") al "Messaging system", y cientos o miles de consumidores (receptores) "tickers financieros" toman este mensaje del "messaging system" para ser desplegado en pantalla.

Estructura de un EJB.

Un EJB esta compuesto de 4 partes (con la excepción de Messaging EJB's) las cuales son:

  • "Enterprise Bean Class"
  • "Home Interface"
  • "Remote Interface"
  • "Deployment Descriptor"
"Enterprise Bean Class"

Esta clase es el componente medular de un EJB, en esta clase se encuentran definidas toda las funciones utilizadas por un EJB, ya sean procedimientos rutinarios (operaciones matemáticas) o con lógica hacia bases de datos (JDBC). En esta clase reside todo el código funcional que realiza operaciones en Java, desde la activación del EJB hasta su destrucción incluyendo las funciones de negocios para el que éste fue diseñado.

"Home Interface"

Esta Interfase (como cualquier otra en Java) solo define un esqueleto para funciones utilizadas en el "Enterprise Bean Class", las funciones que deben ser declaradas en un "Home Interface" son aquellas necesarias para la creación-activación de un EJB, algunas de estas son: create, passivate, activate.

Una de las razones de esta interfase se debe al diseño distribuido de EJB's (RMI), cuando un cliente(JSP/Servlet/Applet) desea interactuar con un EJB éste no se comunica directamente con el "Enterprise Bean Class", sino con el "Home Interface" del EJB en cuestión.

Es de suma importancia recordar que esta interfase (como cualquier otra en Java) no define ningún tipo de lógica o código fuente, solo es una declaración o "esqueleto" de funciones, la lógica o código se encuentra dentro del "Enterprise Bean Class".

Finalmente cabe enfatizar que el "Home Interface" solo contiene las declaraciones para funciones necesarias en la creación-activación de EJB's, las declaraciones de funciones de negocios se encuentran en otra interfase mencionada a continuación.

"Remote Interface"

Esta interfase contiene las declaraciones para funciones de negocios definidas en el "Enterprise Bean Class", y al igual que toda interfase, solo contiene el "esqueleto" de las funciones. El número de declaraciones dependerá de las funciones declaradas en el "Enterprise Bean Class".

"Deployment Descriptor"

Un "Deployment Descriptor" es un archivo en XML que cumple varias funciones.

La primera es parametrizar el código Java del "Enterprise Bean Class", esto es, definir parámetros que varían dependiendo del ambiente; por lo general todo EJB contiene algún tipo de lógica que dependerá del ambiente de ejecución como: nombres de Bases de Datos, Servidores de Paginas, Usuarios privilegiados u otros detalles. Es a través del "Deployment Descriptor" que estos parámetros pueden ser modificados sin la necesidad de modificar el código fuente, inclusive para aquellos EJB's adquiridos de 3eros los cuales no distribuyen su código fuente es la única manera de "ajustar" este tipo de parámetros.

Además de lo anterior , el "Deployment Descriptor" también indica al "EJB Container": el tipo de EJB ("Session,Entity,Messaging"), el esquema de seguridad que posee el EJB, en caso de ser un "Container Managed Entity EJB" las funciones para las que se generará lógica, y otras funcionalidades más.

Terminos Legales de Contenido ©2000-2011 Osmosis Latina

Diseñado bajo estándares : XHTML   CSS  

webmaster@osmosislatina.com