J2EE, programación de servidores de aplicaciones

¿Qué? ¿cómo andamos?

Se que dije que el siguiente post sería de XMLSchema pero voy a dejarlo pa más tarde y me dedicaré hoy a hablar un poquillo por encima de la tecnología J2EE (Java 2, Enterprise Edition). Haré una introducción teórica en este primer post de una serie de 4 post en los que trataré lo que os quiero presentar de la siguiente forma:

1. Introducción teórica a vista de pájaro de Java 2, Enterprise Edition (J2EE) y sus Enterprise Java Beans (EJB).
2. Creación de un EJB (I): Session Bean.
3. Creación de un EJB (II): Entity Bean.
4. Creación de un EJB (III): Message-Driven Bean.
   

J2EE

Si tuviéramos que, como en el colegio, hacer teoría de conjuntos y ver qué conjuntos es menor que cuál o está contenido en o chorrás desas, tendríamos que decir que:

J2ME < J2SE < J2EE

Y es que si bien J2ME no es exactamente un subconjunto de J2SE o J2EE puesto que puede tener elementos que no aparecen en éstos, sí que cuanto menos es una edición mucho más reducida del entorno de desarrollo.

Los objetivos básicos con los que surge J2EE son:

• Abstraer las tareas críticas y repetitivas mediante servicios con una interfaz uniforme.
• Preparar una infraestructura uniforme y de una arquitectura software basada en ella para aplicaciones empresariales.

La tecnología de J2EE utiliza la filosofía de la programación basada en componentes, más que la orientada a objetos. En este tipo de programación, un componente es algo más amplio que un mero objeto, y más asociado a la aplicación.

Además, una aplicación compleja basada en componentes a su vez se subdivide en niveles lógicos, de forma que cada nivel cubra un área de tareas y que pueden componer una o varias partes. Así obtenemos "Thin Clients", frente a los "Fat Clients" de la arquitectura Cliente/Servidor, ya que en los niveles intermedios se delega parte de la responsabilidad del servidor. Cada nivel se comunica sólo con los niveles contiguos mediante interfaces bien definidas.


EJB's

Pero pasemos de to este movidón teórico y metámonos en más teoría pero por lo menos un poco más próxima a la práctica. Veamos el concepto de beans. Los beans son nuestros colegas, nuestras "habichuelas", las entidades mínimas de nuestro diseño de aplicaciones...y de servidores de aplicaciones. En esencia son clases java con unas ciertas propiedades que permitirán darnos algunas prestaciones en función de nuestras necesidades, o más técnicamente son componentes que pueden ser usados para construcción de aplicaciones distribuídas y que encapsulan una parte de la lógica de negocio de una aplicación. Un EJB accede a otros gestores de recursos como bases de datos u otros EJB's y puede ser accedido por otros EJB's, aplicaciones, servlets y aplicaciones cliente. el EJB reside en un contenedor que le provee de servicios de seguridad, transacciones, gestión del ciclo de vida, gestión de concurrencia y despliegue.

Un EJB (salvo en el especial caso de los Message-Driven Beans) tiene varias partes:

• La interfaz cliente. Permite el uso síncrono por parte de los clientes de los procesos de negocio que modela el EJB. Consta de dos clases de tipo interface. La Home Interface que debe extender la clase EJBHome y controla los métodos del ciclo de vida y la Remote Interface que debe extender la clase EJBObject y controla el acceso a los métodos de negocio remotamente.
  
• La clase Enterprise Bean. Implementa el Bean en sí, su funcionamiento interno, las llamadas a las BBDD necesarias, los métodos de negocio, ciclo de vida, etc.
• El descriptor de despliegue. Proporciona al contenedor toda la información que éste necesita sobre el EJB (nombre, nombre de sus interfaces, tipo de EJB, servicios que se esperan del contenedor, etc). Se trata de un fichero XML, y debido a su complejidad y su extensión se suelen utilizar herramientas de despliegue que lo creen a partir de la selección de opciones en un interfaz gráfico por parte del desplegador.
  

Lo que nuestros coleguitas beans pretenden ayudarnos a modelar son lo que llamamos "entidades de negocio" y "procesos de negocio", que viene a ser una forma empresarial de llamar a información de nuestra aplicación y métodos de acceso y modificación de esa información. Para que nos entendamos, las entidades de negocio son las bases de datos donde los procesos de negocio son los métodos/funciones/procedimientos que acceden a esas bases de datos y leen o modifican lo que en ellas hay.

Y para eso, ¿en qué nos ayudan los beans? Pues bien, tenemos beans para cada una de nuestras necesidades en una apliación...beans a la carta. En esencia tenemos:

Beans de Sesión (Session Beans):
Se encargan de la parte del lado servidor de la lógica de negocio de una aplicación.
Se crean instancias de un Session Bean cuando se produce una petición de un cliente y su tiempo de vida es el de el proceso abierto. Podemos tenerlos de dos tipos:

• Beans de sesión sin estado (Stateless Session Beans)
  No guardan información del cliente. Todos los Stateless Session Beans instanciados tienen la misma identidad.


• Beans de sesión con estado (Statefull Session Beans)
  Presentan diferentes estados en función del cliente, estado que se pierde cuando se deja de usar el Session Bean. Como consecuencia, cada objeto Session Bean tiene distinta identidad.

Algunas propiedades

• Su estado se mantiene en memoria principal durante una transacción pero pasa a almacenamiento secundario tras desactivarse. Además su estado es inaccesible para otros programas, aunque pueda ser sincronizado para las transacciones.
  
• Sólo puede usarse por un mismo cliente, no puede ser compartida su referencia.
• Frente a fallos no se garantiza que una referencia a un objeto Session Bean siga valiendo.
  

Los Session Beans son especialmente adecuados para encargarse...
...de la lógica de sesión de una aplicación web...


...o también para encargarse de la lógica de sesión de una aplicación de tres capas.



Beans de Entidad (Entity Beans):
Este tipo de beans son los que nos modelan aquéllos conceptos u objetos de negocio cuyos datos deben ser persistentes, para lo que se suele usar una base de datos. Se pueden usar por varios clientes de forma conjunta y simultánea. Su identidad es tan simple como la clave primaria de la base de datos usada. Son tan persistentes que incluso llegan a sobrevivir a caídas de la máquina o de la máquina virtual de Java. En función de quién controle esta persistencia, se clasifican en dos tipos distintos:

• Persistencia manejada por el bean (Bean Managed Persistence)
  El programador del bean debe programar los métodos que aseguran la persistencia, que vienen a ser los métodos que guardan los datos en la base de datos, así como crear la base de datos y mapear variables con columnas de la base de datos.
  


• Persistencia manejada por el contenedor (Container Managed Persistence)
  El programador queda liberado de la tarea de programar la persistencia teniendo únicamente que indicar al contenedor qué variables van a asociadas a qué columnas de la base de datos para que éste controle la persistencia. Todo este mapeo se reflejará en el fichero xml descriptor del bean.
  

Algunas propiedades:

• El estado de un Entity Bean es mantenido en una BBDD, con caché en memoria durante una transacción. Por consiguiente, cualquier programa externo puede acceder a él mediante queries SQL. Además su estado se cambia con transacciones y se puede recuperar en cualquier momento.
  
• Un objeto Entity Bean puede ser compartido por múltiples clientes pasándose la referencia sin problemas.
• Frente a fallos, caídas del contenedor o de la máquina, las referencias a los objetos siguen siendo válidas.
  

Beans controlados por mensajes (Message-driven Beans):
Este tipo de beans permiten a las aplicaciones J2EE procesar mensajes asíncronos, lo que los diferencia de los anteriores cuya llamada era síncrona. En última instancia no son más que escuchadores de mensajes JMS. Su estructura de hecho es similar a la de los escuchadores de eventos de java, sólo que éstos lo que escuchan son mensajes.
La principal diferencia a nivel de uso de éste tipo de bean con los anteriores es que el acceso a ellos no se realiza mediante interfaces, sino por:

• Mensajes enviados por algún componente J2EE (una aplicación cliente, otro EJB o un componente web).
• Mensajes enviados por una aplicación o sistema JMS que no use la tecnología J2EE.
  

También a diferencia de los demás beans, los MDB sólo se componen de una clase java, ya que no tienen interfaces.
describamos entonces algunas de las propiedades de este tipo de EJB's:

• Una instancia a un MDB no almacena datos o estado conversacional de ningún cliente.
• Todas las instancias de MDB tienen la misma identidad, por lo que la asignación de una instancia a un cliente es indiferente de qué instancia sea.
• Un único MDB puede procesar mensajes procedentes de múltiples clientes.

Cuando un mensaje llega, el contenedor de nuestro EJB llama a su método onMessage(), que típicamente lo primero que debe tener programado es la clasificación de este mensaje según pertenezca a cada uno de los 5 tipos de mensajes JMS, para luego procesarlo según la lógica de negocio de nuestra aplicación.

Y bueno, yo creo que como introducción a J2EE y EJB's ya se ha hecho demasiao larga, pero weno, espero haberos ayudao en familiarizaros en esta tecnología. El siguiente post irá dedicao a programar y desplegar un Session Bean pa que le echéis un ojo a su código y veáis que hacerlo es más o menos sencillico aunque un poco coñazo. Además usaremos alguna herramienta de despliegue de EJBs que provee Sun. ya os contaré.

+info:
http://java.sun.com/javaee/5/docs/tutorial/doc/
http://java.sun.com/javaee/5/docs/firstcup/doc/toc.html
http://java.sun.com/javaee/index.jsp