Teoría Workshop de EJB 2.0
Imprimir

Índice

Tabla de contenidos

Introducción

HOY, los desarrolladores pueden construir aplicaciones distribuidas, transaccionales, seguras y confiables basadas en la tecnología de servidores de aplicación (server-side tecnology). Cada vez, las aplicaciones deben ser diseñadas, construidas y producidas por menos dinero, a más velocidad y utilizando menor cantidad de recursos y profesionales.

Para reducir costos y acelerar el proceso de desarrollo, Java 2 Platform Enterprise Edition (J2EE) provee un enfoque basado en componentes para el diseño, ensamblaje e instalación de aplicaciones. La plataforma J2EE provee un modelo de aplicación multicapa, componentes reutilizables, un modelo de seguridad unificado, control flexible de transacciones, soporte de Web Services a través de intercambio de datos integrados por estándares y protocolos abiertos XML.

Las soluciones basadas en componentes de la plataforma J2EE son desarrollados en forma independiente de la implementación, por lo tanto no se encuentran asociadas a los productos particulares y a las APIs de los proveedores; llegando en algunos casos a perder el soporte debido a la falta de actualización de la versión del producto.

Historia de los Servidores de Aplicación

En el pasado los desarrolladores al construir una aplicación, no solamente se enfrentaban a los problemas de negocios a resolver, sino que siempre debían lidiar con los mismos problemas de la capa de middleware (middleware tier), transacciones, persistencia, distribución de objetos, administración de conexiones, escalabilidad, redundancia, tolerancia a fallos, seguridad, etc. Para resolver estos problemas comunes a todos los desarrollos, las empresas construían sus propios entornos de trabajo (frameworks). Estos entornos de trabajo solían ser muy complejos de construir y mantener, y requerían conocimiento experto, que muchas veces poco tienen que ver con el negocio central de la compañía.

Otra opción era comprar las soluciones de middleware y construir la aplicación sobre el entorno de trabajo del proveedor. El problema con las soluciones propietarias pasaba porque la aplicación quedaba atada a la implementación y a las APIs del proveedor.

El servidor de aplicación (aplication server) nace para resolver estos problemas. Provee servicios comunes de middleware como persistencia, transacciones, distribución de objetos, administración de conexiones, etc. Los proveedores implementan estas interfaces estándares para integrar proveer los servicios a sus productos mediante el servidor de aplicaciones. Por lo tanto los desarrolladores ahora pueden centrarse en la problemática central de negocio, o los requerimientos funcionales, que debe resolver la aplicación utilizando APIs estándares y para invocar al middleware y decidiendo luego que implementaciones específicas utilizar para resolver mejor los requerimientos de tipo no funcionales.

Basándose en los servidores de aplicación, las soluciones son desarrolladas independientemente de la plataforma, pueden correr en cualquier servidor de aplicación y pueden ser integradas en forma transparente e independiente con los productos de los proveedores que brinden los servicios del servidor de aplicaciones.

Un ejemplo concreto puede ser el típico caso en que la aplicación debe guardar información en una base de datos. Los desarrolladores pueden utilizar distintas estrategias estándares dentro del conjunto de especificaciones J2EE para persistir sus datos, como por ejemplo: JDBC, EJB CMP o BMP, etc. Luego es necesario configurar el servidor de aplicación para indicarle que implementación debe utilizar para conectarse con la base de datos. De esta manera, la aplicación conoce el servicio estándar del servidor de aplicaciones para utilizar la base de datos, y el servidor de aplicaciones conoce el nombre de la base de datos, donde se encuentra y cuál es el proveedor. Esta aplicación puede correr en cualquier servidor de aplicaciones que implemente J2EE. Además de la independencia que provee esta separación de capas permite a los administradores de la aplicación cambiar el nombre de la base de datos donde se encuentra o directamente cambiar de proveedor de base de datos sin necesidad de modificar otra cosa que la configuración del servidor de aplicación. Por lo tanto la configuración de los servicios también recaen en el servidor de aplicación, evitando a los desarrolladores construir soluciones ad-hoc tales como el uso de archivos para las configuraciones.

Aplicaciones distribuidas

Aplicaciones distribuidas multicapas

La plataforma J2EE utiliza un modelo de aplicación distribuida multicapa. La lógica de la aplicación es dividida en componentes según su función, los distintos componentes que integran la aplicación J2EE, pueden ser instalados en distintas máquinas dependiendo a la capa que pertenezcan. La Figura 1 muestra dos aplicaciones multicapa J2EE y los componentes que perteneces a cada capa.

• Componentes de la capa Cliente (Client-tier) corren en la maquina cliente.

• Componentes de la capa Web (Web-tier) corren en un servidor J2EE.

• Componentes de la capa de negocios (Business-tier) corren en un servidor J2EE.

• Software de sistemas de información (EIS-tier) corren en un servidor EIS.

Una aplicación J2EE puede consistir en las 3 o 4 capas mostradas en la Figura 1, distribuidas en tres diferentes sitios: las máquinas cliente, las máquinas con los servidores J2EE, y las máquinas con la base de datos o sistemas legados (legacy).

Componentes J2EE

Las ampliaciones J2EE se encuentran integradas por componentes. Un componente J2EE es una unidad funcional de software auto contenida, que es ensamblada en una aplicación J2EE con sus clases y archivos conectados lógicamente, y que es capaz de comunicarse con otros componentes.

• Aplicaciones clientes y applets son componentes que corren en el cliente. • Java Servlets y Java Server Pages (JSP) son Componentes Web que corren en el server. • Enterprise Java Beans (EJB) son “Componentes de Negocio” que corren en el server.

Los componentes J2EE son escritos en el lenguaje de programación Java y son compilados en el mismo modo que cualquier programa del lenguaje. La diferencia entre componentes J2EE y las clases corrientes de Java es que los componentes J2EE son ensamblados en una aplicación J2EE, verificados según la especificación y puestos en producción donde son corridos y administrados por el servidor J2EE. Página: 1 Son estándares y respetan una interfaz clara bien conocida. Por eso son componentes.

Clientes J2EE

Un cliente J2EE puede ser un Cliente Web o una Aplicación Cliente.

Clientes Web

Un cliente web consiste de dos partes: páginas web dinámicas que contienen varios lenguajes de hipertexto (HTML, XML, etc.), que son generados por los componentes Web que corren en la capa de web, y un navegador web que interpreta las páginas web recibidas por el cliente.

Los clientes web delegan las operaciones complejas a los componentes enterprise beans que se encuentran corriendo en el cliente, donde pueden basarse en la seguridad, velocidad, servicios y confiabilidad provistas por el servidor J2EE.

Applets

Una página web dinámica generada desde la capa web puede incluir una applet embebida. Una applet es una pequeña aplicación escrita en Java que ejecuta la Java Virtual Machine (JVM) instalada en el navegador web. Los clientes necesitan el Java Plug-in y un archivo de políticas de seguridad para que la applet se ejecute exitosamente en el navegador.

Sin embargo los componentes web (Servlet y JSP) son la manera más limpia y modular de diseñar programas clientes web, ya que pueden ejecutarse en cualquier cliente y proveen formas de separar la programación de la aplicación del diseño de la página web.

Aplicaciones Clientes

Una aplicación cliente J2EE corre en una Java Virtual Machine en la máquina del cliente y provee funcionalidades para realizar tareas que requieren una interfaz de usuario más compleja de la que puede ser provista por un lenguaje de hipertexto. En general poseen una interfaz gráfica de usuario (GUI) creada por las APIs de Swing o AWT.

Las aplicaciones cliente acceden directamente a los enterprise beans corriendo en la capa de negocios.

JavaBeans™ Component Architecture

Las capas cliente y servidor pueden incluir componentes basados en la arquitectura JavaBeans Component Architecture para administrar el flujo de datos entre aplicaciones clientes o applets y componentes corriendo en el servidor J2EE. Los componentes JavaBeans no son considerados componentes J2EE por la especificación J2EE.

Según la especificación, los JavaBeans tienen variables de instancia con sus respectivos métodos get y set, y deben cumplir las convenciones de nombre indicadas en la JavaBeans Component Architecture.

J2EE Server Communications

El cliente se comunica con la capa de negocios corriendo en el servidor J2EE, directamente o, en el caso de que el cliente corra en un navegador web, a través de los componentes JSP o Servlet corriendo en la capa de web. En el caso de utilizar aplicaciones clientes, más funcionalidades quedan del lado del cliente, logrando una mejor interfaz para el usuario. Los clientes basados en navegadores delegan la mayor cantidad de funcionalidades al servidor, por lo tanto la aplicación será más fácil de distribuir, administrar y poner en producción. La figura 2 muestra los elementos que pueden componer la capa cliente.

Componentes Web

Los componentes web J2EE pueden ser servlets o JSP pages. Los Servlets son clases de java que procesan dinámicamente requerimientos http (http-request) y construyen respuestas http (http-responses). Las páginas JSP son documentos basados en texto que se ejecutan como servlets pero permiten un enfoque más natural para crear contenido estático.

Las páginas HTML estáticas, las applets, y las clases utilitarias pueden ser ensambladas en la aplicación junto con los componentes web, pero no son consideradas componentes web por la especificación J2EE.

La capa de web puede optar por incluir componentes JavaBeans para administrar la información proveniente del cliente y enviarla como entrada a los enterprise beans en la capa de negocios para ser procesada. La Figura 3 muestra la comunicación entre las capas cliente, web y negocios.

Componentes de Negocios

El código de negocios es lógica que resuelve las necesidades particulares de un dominio de negocios, y es tratado por los enterprise beans corriendo en la capa de negocios. La capa de negocios recibe datos de los clientes, los procesa y los envía a la capa de sistemas de información para almacenamiento de datos. También recibe datos de la capa de sistemas de información, la procesa y envía de vuelta al cliente. Existen 3 tipos de enterprise beans:

Session Beans: Representa un conversación temporal con un cliente, cuando termina la ejecución, el Session Bean y su información dejan de existir.

Entity Beans: Representa datos persistentes almacenados en una base de datos, cuando termina la ejecución o se apaga el servidor, los servicios de garantizan que la información del Entity Bean se encuentran almacenadas en la base de datos.

Message-driven Beans: Combina las características de un Session Bean y una cola de mensajes Java Message Service (JMS), permitiendo al componente de negocios recibir mensajes JMS en forma asincrónica.

Capa de Sistemas de Información

La capa de Sistemas de información (Enterprise Information System EIS-tier) permite a los componentes de la aplicación J2EE, comunicarse a los sistemas de información e infraestructura como bases de datos, transacciones a mainframes, y otros sistemas legados. La figura 4 muestra la interacción de las capas cliente, web, negocios y sistemas de información.

Contenedores J2EE

La arquitectura J2EE basada en componentes es independiente de la plataforma facilita la construcción de aplicaciones organizando la lógica de negocios en componentes reutilizables. El servidor J2EE provee los servicios en la forma de un contenedor (container) para cada tipo de componente. Al no tener que preocuparse por estos servicios, el desarrollador puede concentrarse en resolver los problemas de negocios.

Servicios del Contenedor

El contenedor es la interfaz entre los componentes y los niveles mas bajos específicos de la plataforma que los soportan. Antes de que un componente web o un enterprise bean, pueda ser ejecutado, debe ser ensamblado en una aplicación J2EE e instalados (deployed) en el contenedor.

El proceso de ensamblaje de la aplicación involucra especificar configuraciones del contenedor para cada componente en la aplicación J2EE y para la aplicación misma. Las configuraciones del contenedor personalizan el soporte de las capas de bajo nivel provisto por el servidor J2EE, los cuales incluyen seguridad, administración de transacciones, servicios de búsqueda de nombres y directorios, y conectividad remota.

• El modelo de seguridad J2EE permite configurar los componentes web o enterprise beans, para que sólo puedan ser utilizados por usuarios autorizados y autenticados mediante JAAS.

• El modelo de transacciones J2EE permite especificar relaciones entre los métodos que conforman una transacción para que todos ellos sean tratados como una única unidad.

• Los servicios de búsqueda de nombres y directorios (JNDI lookup) proveen una interfaz unificada para que los componentes de la aplicación puedan acceder a servios de nombres y directorios.

• El modelo de conectividad remota J2EE administra las comunicaciones a bajo nivel entre clientes y enterprise beans. Luego de que un enterprise bean es creado, el cliente puede invocar métodos de manera transparente como si se encontraran en la misma máquina virtual.

El hecho que la arquitectura J2EE provea servicios configurables significa que los componentes de una misma aplicación pueden comportarse en diferente forma de acuerdo a como fueron instalados (deployed).

Tipos de Contenedores

El proceso de instalación o deploy, instala una aplicación J2EE en los contenedores J2EE.

J2EE server

Es el ambiente de corrida de un producto J2EE. Un servidor J2EE provee el container WEB y el

Enterprise JavaBeans (EJB) container

Administra la ejecución de los enterprise beans para las aplicaciones J2EE. Los enterprise beans y el contenedor EJB corren en un servidor J2EE.

Web container

Administra la ejecución de las páginas JSP y los servlets para las aplicaciones J2EE. Los componentes web y el contenedor web corren en el servidor J2EE.

Application client container

Administra la ejecución de los componentes de la aplicación cliente. Las aplicaciones clientes y sus contenedores corren en el cliente.

Applet container

Administra la ejecución de las applests. Consiste en el navegador web y el Java Plug-in corriendo en el cliente.

La figura 5 muestra los componentes en el servidor J2EE, el contenedor WEB y el contenedor EJB.

Empaquetamiento y ensamblado

Una aplicación J2EE es empaquetada y ensamblada en un Archivo enterprise (EAR). Un EAR es un archivo estándar java (JAR) con una extensión “.ear” que contiene módulos J2EE. Usando archivos EAR y módulos J2EE es posible ensamblar múltiples diferentes aplicaciones J2EE usando componentes en común.

Un módulo J2EE consta de uno o mas componentes J2EE para el mismo tipo de contenedor y un descriptor de instalación o deployment-descriptor de ese tipo. Un deployment-descriptor es un documento XML con extensión “.xml” que describe la configuración de instalación para los componentes.

Como los descriptores de instalación definen las configuraciones de los componentes en forma declarativa, éstas pueden ser cambiadas sin necesidad de modificar o recompilar el código. En tiempo de ejecución (runtime), el servidor J2EE lee el descriptor y actúa sobre el componente de manera acorde.

Un módulo J2EE puede ser instalado sin descriptor cuando no necesite correr dentro de un contenedor (módulo stand-alone). Existen 4 tipos de módulos J2EE.

  • Módulos Enterprise JavaBeans (EJB), contienen las clases para los enterprise beans y el descriptor EJB. Los módulos EJB son empaquetados en un archivo JAR.
  • Módulos Web, contienen archivos JSP, las clases de los servlets, archivos GIF, HTML, etc., para el diseño web y el descriptor WEB. Los módulos WEB son empaquetados en un archivo WAR.
  • Módulos para adaptación de recursos, contienen todas las interfaces y clases java, librerías nativas y otra documentación con el adaptador de recursos (Resource Adapter). Estos archivos implementan la Arquitectura Conector J2EE (J2EE Connector Architecture) para un EIS particular. Los módulos para adaptación de recursos son empaquetados en un archivo RAR.
  • Módulos de aplicaciones clientes, contienen las clases y el descriptor cliente. Los módulos de aplicaciones clientes son empaquetados en un archivo JAR.

Enterprise Java Beans

Enterprise Beans

Un enterprise bean es un componente de software que corre del lado del servidor y puede ser instalado en un entorno multicapa. Un enterprise bean puede componer uno o mas objetos, ya que un componente puede ser más que un objeto solamente. Mas allá de la composición de un componente, los clientes pueden tratar con una única interfaz expuesta por el componente. Esta interfaz y el mismo enterprise bean, deben cumplir con la especificación EJB. La especificación requiere que los beans expongan algunos métodos requeridos que permitan al contenedor EJB administrar los beans de manera uniforme.

La especificación EJB 2.0 define 3 tipos de Beans para representar el modelo de negocios:

  • Session Beans: Representan los procesos del modelo de negocios. Son como verbos, porque modelan acciones.
  • Entity Beans: Representan los datos del modelo de negocios Son como sustantivos, porque modelan objetos de datos.
  • Message-driven Beans: Son similares a los session beans en que representan procesos del modelo de negocios, y modelan acciones. La diferencia es que solamente pueden ser invocados enviando mensajes en forma asincrónica.

Objetos distribuidos

Los componentes EJB se basan en la tecnología de objetos distribuidos. Un objeto distribuido es básicamente un objeto que puede ser invocado en sistemas remotos. Las invocaciones pueden provenir desde un cliente dentro del mismo proceso, un cliente fuera del mismo proceso, o un cliente en algún lugar a través de una red. La figura 6 muestra la llamada de un cliente a un objeto distribuido. Los siguiente puntos explican el diagrama:

1. El cliente invoca el método de un objeto remoto mediante su stub, que es el apoderado del objeto del lado del cliente (client-side proxy object). El stub es el responsable de encapsular las comunicaciones de red en el cliente, y es quién conoce como realizar la invocación y el envió de parámetros a través de la red, mediante sockets.

2. #El stub se comunica a través de la red con el skeleton, que es el apoderado del objeto del lado del servidor (server-side proxy object). El skeleton es el responsable de encapsular las comunicaciones de red en el servidor, y es quién conoce como recibir invocaciones y parámetros a través de la red, mediante sockets.

  1. El skeleton delega la invocación al objeto distribuido, quien realiza su trabajo y devuelve el control al skeleton, quien retorna el control al stub, quien finalmente devuelve el control al cliente.

Los objetos distribuidos permiten partir una aplicación a través de la red en forma transparente, encapsulando las comunicaciones y permitiendo al desarrollador centrarse en resolver la lógica de negocios y no en los servicios comunicaciones de bajo nivel. En general para resolver la lógica de negocios de una aplicación basada en objetos distribuidos, serán necesarios servicios de como transaccionalidad, persistencia o seguridad. Existen dos formas invocar el middleware, en forma explícita o implícita.

Middleware en forma explícita

En la programación tradicional de objetos distribuidos, eran escritas en el código las llamadas a las APIs de middleware del proveedor. Este enfoque se conoce como explícito porque para invocar el middleware (para servicios de transaccionalidad, seguridad o persistencia), es necesario invocar a una API. La figura 7 muestra la llamada de un cliente a un objeto distribuido invocando explícitamente el middleware.

En este enfoque la lógica de negocios se encuentra junto con los llamados a la API para invocar el middleware. Las principales desventajas que trae este enfoque son:

  • El código es difícil de escribir: La lógica para resolver los problemas del modelo de negocios se entremezclan con llamadas a las APIs de middleware.
  • El código es difícil de mantener: Si es necesario cambiar el comportamiento de los servicios de middleware, es necesario modificar el código.

Middleware de forma implícita

La diferencia más significativa entre los sistemas del pasado y las nuevas tecnologías basadas en componentes, es que se pueden invocar las APIs de middleware en las aplicaciones sin escribir las invocaciones. La figura 8 muestra la llamada de un cliente a un objeto distribuido invocando implícitamente el middleware.

Para poder invocar el middleware en forma implícita deben seguirse los siguientes pasos.

Escribir el objeto distribuido incluyendo solamente la lógica para resolver los problemas del modelo de negocios. No hace falta invocar a ninguna API de middleware.

Declarar los servicios de middleware requeridos por el objeto distribuido en un archivo descriptor separado.

Correr la herramienta provista por el proveedor del middleware, que toma como entrada el archivo descriptor y genera un objeto llamado interceptor de invocaciones.

El interceptor de invocaciones, intercepta las invocaciones realizadas por el cliente, invoca el middleware requerido por el objeto (como transaccionalidad, persistencia, o seguridad), y finalmente delega la invocación al objeto distribuido.

Las principales ventajas que trae este enfoque son:

  • El código es fácil de escribir: Solamente se escribe la lógica para resolver los problemas del modelo de negocio. No se escriben llamadas a las APIs de middleware.
  • El código es fácil de mantener: Si es necesario cambiar el comportamiento de los servicios de middleware, solamente es necesario modificar el archivo descriptor sin necesidad de modificar el código.

Una vez entendida la intercepción de invocaciones, es posible entender mejor que constituye exactamente un enterprise bean. Un componente enterprise bean está compuesto por múltiples archivos que trabajan en conjunto.

La Clase Enterprise Bean

La primera parte de un bean es la implementación misma, que contiene la lógica para resolver los problemas del modelo de negocios, llamada enterprise bean class. Esta es una simple clase de java que cumple con una interfaz definida y obedece ciertas reglas necesarias para que el bean pueda correr en cualquier contenedor EJB. Una enterprise bean class contiene detalles de la implementación:

  • En los Session Beans, la implementación contiene lógica para resolver procesos del modelo de negocios.
  • En los Entity Beans, la implementación contiene lógica para administrar los datos del modelo de negocios.
  • En los Message-driven Beans, la implementación contiene lógica orientada a mensajes.

La especificación EJB define algunas interfaces estándares que las enterprise bean class deben implementar. Estas interfaces fuerzan al enterprise bean a exponer ciertos métodos comunes a todos beans, como define el modelo de componentes EJB. El contenedor EJB invoca estos métodos requeridos para administrar los beans y alertarlo de eventos significativos.

La interfaz básica que deben implementar todos los tipos de enterprise bean class (session, entity, y message-driven) es la javax.ejb.EnterpriseBean. Dicha interfaz indica que la clase es serializable y no define comportamiento alguno, solamente actúa como una marca para indicar que la clase es una enterprise bean class.

Los session beans, entity beans, y message-driven-beans deben implementar cada uno su interfaz específica, javax.ejb.SeesionBean, javax.ejb.EntityBean, y javax.ejb.MessageDrivenBean respectivamente, que extienden la interfaz javax.ejb.EnterpriseBean.

El Objeto EJB

Los enterprise beans no son estrictamente objetos remotos. Cuando un cliente necesita utilizar una instancia de una clase enterprise bean, el cliente nunca invoca el método directamente en la instancia real. La invocación es interceptada por el contenedor EJB y delegada a la instancia del enterprise bean. Interceptando las invocaciones, el contenedor EJB puede realizar en forma automática las invocaciones de middleware en forma implícita. Por lo tanto el desarrollador de componentes no necesita escribir, corregir o mantener invocaciones a las APIs de middleware. Algunos de los servicios que se pueden obtener en forma implícita mediante la intercepción son:

  • Administración implícita de transacciones distribuidas. Las transacciones permiten realizar operaciones en forma robusta y determinística en ambientes distribuidos. El contenedor EJB provee un servicio de transacciones, que consta de una implementación a bajo nivel de administración de transacciones a bajo nivel. El servicio de transacciones debe ser expuesto a través de la API de alto nivel JTA. JTA es una interfaz de alto nivel que permite controlar las transacciones.
  • Seguridad implícita. La seguridad suele ser una consideración importante para el desarrollo de aplicaciones multicapa distribuida. La plataforma Java 2 edición estándar (J2SE), define un servicio de seguridad robusto que permite autorizar y autenticar usuarios, asegurando los componentes instalados. EJB agrega a este concepto la noción de seguridad transparente o declarativa, que permite obtener los beneficios de seguridad sin necesidad de escribir las invocaciones a la API de JAAS. (java autorization and authentication service).
  • Administración implícita de recursos y ciclos de vida de los componentes. El contenedor EJB administra implícitamente los recursos utilizados por los enterprise beans, como threads, sockets o conexiones a la base de datos. El ciclo de vida de los enterprise beans también es administrado, permitiendo al contenedor EJB reutilizar las instancias de los enterprise beans cuando sea necesario.
  • Persistencia implícita. La persistencia de datos es un requerimiento de cualquier aplicación que requiere almacenamiento permanente. EJB ofrece asistencia para almacenar los datos persistentes de los objetos en las capas subyacentes de almacenamiento y luego obtener esa información.
  • Acceso remoto implícito. La clase enterprise bean no puede ser invocada a través de la red directamente porque es una clase sin soporte para redes. El contenedor EJB soporta invocación remota mediante el encapsulamiento de los beans en objetos con soporte para red. Los objetos con soporte para red reciben invocaciones desde el cliente y las delegan a las instancias correspondientes de los beans. Esto ahorra al programador tener que preocuparse por temas referidos al uso de redes.
  • Soporte implícito. Los contenedores EJB automáticamente reciben invocaciones concurrentes de los clientes. El contenedor EJB provee soporte de threads, instanciando las múltiples copias necesarias de los componentes, instanciando múltiples enterprise beans y alojando las instancias en threads. De esta forma se obtiene concurrencia robusta sin necesidad de escribir código multithread.
  • Transparencia de ubicación de componentes en forma implícita. Los clientes de los componentes se encuentran desacoplados de la ubicación específica del componente que se encuentra siendo utilizado.
  • Monitoreo implícito. El contenedor EJB puede realizar un seguimiento de los métodos invocados y recopilar información estratégica para optimización y balance de carga inteligente.

El contenedor EJB actúa como una capa de indirección entre el código del cliente y el del enterprise bean. Esta capa de indirección se manifiesta como un objeto con soporte de red llamado objeto EJB (EJB object) que actúa como el interceptor de invocaciones.

El objeto EJB es un objeto que conoce sobre redes, transacciones, persistencia y más. Tiene la inteligencia para saber como realizar la lógica intermedia que el contenedor EJB requiere antes de la invocación a la instancia de la clase enterprise bean. El objeto EJB replica y expone todos los métodos de negocios expuestos por el enterprise bean y delega todas las invocaciones del cliente a los enterprise beans. La figura 8 muestra la función de los objeto EJB.

El Objeto EJB puede pensarse como una parte física del contenedor. Todos tienen código específico del container dentro. Cada contenedor puede manejar internamente el middleware en forma diferente, el proveedor del contenedor (vendor) genera las clases para los objetos EJB en forma automática. Existen varias estrategias para la generación de los EJB Object.

La interfaz remota

Como fue mencionado previamente, los clientes invocan métodos en los objetos EJB en lugar de en las instancias de las clases enterprise bean. Es por eso que los objetos EJB deben clonar todos los métodos de negocios que las clases enterprise bean exponen. Para clonar los métodos de lógica de negocios los objetos EJB utilizan una interfaz especial, que provee el desarrollador de los enterprise beans, y duplica todos los métodos de negocios que la clase enterprise bean expone. Esta interfaz es llamada interfaz remota, y debe cumplir con las reglas definidas en la especificación EJB. Esta interfaz es llamada javax.ejb.EJBObject. Al ser una interfaz contiene las firmas de los métodos y no la implementación, que es auto generada en el objeto EJB por el contenedor.

El código cliente que necesite trabajar con un componente enterprise bean, deberá invocar los métodos en el javax.ejb.EJBObject. El código del cliente puede ser de: aplicaciones clientes, applets, servlets, JSPs o mismo de otros enterprise beans.

Objetos EJB y RMI-IIOP

La interfaz javax.ejb.EJBObject extiende la interfaz java.rmi.Remote, la cuál es parte de RMI-IIOP (Remote Method Invocation over the Internet Inter-ORB Protocol). Cualquier objeto que la implemente puede ser invocado desde distintas máquinas virtuales java. Esta es la manera de invocar métodos remotos en java. El objeto EJB provisto por el contenedor implementa la interfaz remota, por lo tanto indirectamente también implementa javax.rmi.Remote. Por lo tanto los objetos EJB son objetos con soporte de red RMI-IIOP, capaces de ser llamados desde otra máquina virtual java en la máquina local o desde cualquier otra ubicada en algún lugar de la red.

Las interfaces remotas son también interfaces RMI-IIOP, por lo tanto además de respetar las definiciones de EJB, deben respetar también las de RMI-IIOP. Es importante que cada método invocable a través de distintas máquinas virtuales deben arrojar una excepción especial llamada excepción remota. Dicha excepción es una java.rmi.RemoteException o una subclase de ésta. Son utilizadas para indicar la ocurrencia de algo inesperado en la red, mientas se realizaba una invocación entre máquinas virtuales.

Las interfaces remotas deben respetar las convenciones de pasaje de parámetros definidas por RMI-IIOP. No cualquier tipo puede ser enviado por la red en una invocación entre máquinas virtuales. Los parámetros en las firmas de los métodos deben ser tipos primitivos, objetos serializables, o objetos remotos RMI-IIOP.

El Objeto Home

El código cliente debe tratar con los objetos EJB y nunca con las instancias de las clases enterprise directamente. Pero para poder trabajar con los objetos EJB, primero deben obtener una referencia a ellos. Por un lado, los clientes no pueden instanciar un objeto EJB directamente, ya que el mismo puede existir en una máquina diferente a la del cliente. Por otra parte, EJB promueve la transparencia de ubicación, por lo que el cliente nunca debe saber donde reside el objeto EJB.

Para adquirir una referencia a un objeto EJB, el cliente debe pedir una referencia a una fábrica de objetos EJB (EJB object factory). Esta fábrica es la responsable de instanciar y destruir los objetos EJB. La especificación EJB da el nombre de objeto home (home object) a esa fábrica.

Las principales responsabilidades del objeto home son las siguientes:

  • Crear los objetos EJB.
  • Encontrar objetos EJB (para los entity beans).
  • Destruir objetos EJB.

Como los objetos EJB, los objetos Home, son propietarios y específicos de cada contenedor EJB. Pueden contener lógica específica del contenedor como balance de carga etc. Como los objetos EJB pueden pensarse como una parte física del contenedor y son generados en forma automática por las herramientas del proveedor del container.

La Interfaz Home

El objeto home es una fábrica de objetos EJB generada automáticamente por el contenedor, pero el contenedor no conoce como se deben crear, buscar o destruir los objetos EJB. El contenedor necesita esta información para generar los objetos EJB. El desarrollador le provee al container la información mediante la definición de una interfaz home (home interface). La interfaz home define las firmas de los métodos para crear, buscar o destruir los objetos EJB. El contenedor se encarga de crear el objeto EJB que implementa esos métodos. La figura 9 muestra el rol de la interfaz y el objeto home.

La especificación define métodos requeridos por todas las interfaces home. Estos métodos requeridos se encuentran definidos en la interfaz javax.ejb.EJBHome y todas las interfaces home deben extenderla. La interfaz javax.ejb.EJBHome extiende a java.rmi.Remote, lo que implica que los objetos home son objetos con soporte de red RMI-IIOP, que pueden ser invocados entre máquinas virtuales, por lo tanto los métodos definidos en las interfaces home, deben cumplir con la especificación RMI-IIOP.

Las Interfaces Locales

Un importante problema de performance que se presenta al administrar enterprise beans a través de la interfaz home, es que puede ser muy costoso en tiempo y procesamiento por el soporte que utilizan los objetos distribuidos. Lo mismo sucede cuando se invoca un enterprise bean a través de la interfaz remota. Cada vez que se invoca un objeto EJB mediante la interfaz remota, ocurren los siguientes pasos:

  1. El cliente invoca al stub local.
  2. El stub codifica los parámetros para enviarlos por la red.
  3. El stub se comunica a través de la red con el skeleton remoto.
  4. El skeleton decodifica los parámetros a su tipo Java original.
  5. El skelenton invoca al objeto EJB.
  6. El objeto EJB invoca el middleware necesario.
  7. Una vez que el Objeto EJB invoca la instancia de la clase enterprise bean, y esta hace su trabajo, cada uno de los pasos debe ser repetido para de regreso para retornar el control al cliente.

Estos pasos significan una sobrecarga (overhead) importante. EJB 2.0 permite invocar a los enterprise beans en una forma veloz y eficiente, a través de invocaciones a sus objetos locales (local object) en lugar de los EJB objects. Los objetos locales implementan una interfaz local (local inteface) en lugar de la interfaz remota, por lo tanto no tienen soporte de red RMI-IIOP, y no pueden ser invocados a través de máquinas virtuales. Los objetos permiten invocar de manera performante a los enterprise beans. Cada vez que se invoca un objeto local mediante la interfaz local, ocurren los siguientes pasos:

  1. El cliente invoca al objeto local.
  2. El objeto local invoca el middleware necesario.
  3. Una vez que el objeto local invoca la instancia de la clase enterprise bean, y esta hace su trabajo, retorna el control al objeto local, que retorna el control al cliente.

De esta manera se evitan los pasos del stub, el skeleton, la red, y la codificación / decodificación de parámetros. También pueden administrarse los enterprise beans en forma veloz y eficiente utilizando la interfaz home local (local home interfaz) en lugar de la interfaz home, la cual es implementada por el contenedor mediante el objeto home local (local home object). Las interfaces locales son opcionales, y pueden ser utilizadas como reemplazo o complemento de las interfaces remotas.

Cuando se escribe una interfaz local, ésta debe extender javax.ejb.LocalObject, y cuando se escribe una interfaz home local, ésta debe extender javax.ejb.EJBLocalHome.

Descriptores de Deploy

Para informarle a la capa de middleware las necesidades de la aplicación, el desarrollador de los enterprise beans, debe declarar los requerimientos de servicios de middleware para los componentes en un archivo descriptor (deployment descriptor). El contenedor EJB inspecciona el descriptor para cumplir los requerimientos especificados. El descriptor es la clave para invocar el middleware en forma implícita.

En el descriptor se pueden especificar los siguientes requerimientos para los enterprise beans:

Administración de enterprise beans y requerimientos de ciclos de vida: Indican al contenedor sobre cómo administrar los enterprise beans. Permite especificar el nombre de la clase enterprise bean, el tipo de bean, la interfaz home, y el nombre de la interfaz remota.

  • Requerimientos de persistencia (solamente para enterprise beans): Indican al contenedor sobre como el enterprise bean administra la persistencia.
  • Requerimientos de transacciones: Indican los requerimientos del enterprise bean para correr en transacciones.
  • Requerimientos de seguridad: Indican al contenedor los roles de seguridad autorizados y los permisos para invocar métodos de los enterprise beans.

En EJB 2.0, un descriptor es un archivo XML llamado ejb-jar. Como proveedor de los enterprise beans, el desarrollador es el responsable de crear el descriptor. Una vez instalados los enterprise beans, otras partes pueden modificar estas configuraciones. Esto es posible porque el descriptor declara como los enterprise beans utilizan el middleware, en lugar de escribirlo en el código. Declarar en lugar de programar, permite a actores sin conocimiento de Java o sin acceso al código a personalizar los componentes luego del desarrollo. Este paradigma se transforma en necesidad absoluta cuando se compran componentes EJB a una tercera parte. Teniendo por separado un descriptor personalizable, es posible optimizar fácilmente los componentes para ambientes específicos sin modificar el código.

Archivos específicos del proveedor

Como todos los proveedores de servidores EJB son diferentes, cada uno tiene funcionalidades propietarias con valor agregado. La especificación EJB no incluye funcionalidades como, configuración de balance de carga, redundancia, tolerancia a fallas, etc. Es por eso que cada proveedor de servidores EJB requiere archivos adicionales específicos para configurar estas funcionalidades.

Archivo Ejb-jar

Una vez creadas las clases enterprise bean, las interfaces home, la interfaces remotas y los descriptores, es necesario empaquetarlos en un módulo EJB mediante un archivo Ejb-jar con extensión “.jar”.

Una vez construido el archivo Ejb-jar, el enterprise bean está completo, y es una unidad instalable en cualquier servidor de aplicación J2EE. Una vez instalado, las herramientas provistas por el proveedor del contenedor EJB son las responsables de descomprimir, leer, y extraer la información contenida en el archivo Ejb-jar. Luego el instalador realiza tareas específicas del proveedor, como generar los objetos EJB, los objetos home, importar el enterprise bean dentro del container, y configurarlo. El soporte para los archivos Ejb-jar es un estándar y es una funcionalidad requerida por todas las herramientas EJB.

Es importante destacar que más de un enterprise bean pueden estar contenidos en un mismo archivo Ejb-jar, permitiendo empaquetar módulos o aplicaciones enteras en un solo archivo.

El ecosistema EJB

Para hacer exitosa una instalación y una puesta en producción de una aplicación multicapas EJB son necesarios más que un servidor de aplicación y componentes. De hecho, EJB promueve la colaboración de mas de 6 partes diferentes. Cada una es estas partes es experta en su propia área y es responsable de una parte clave del éxito. Como cada parte es especialista, el tiempo total requerido es reducido significativamente. Juntos, estos actores conforman el ecosistema EJB.

  • El proveedor de los enterprise beans o desarrollador: proporciona los componentes de negocios o enterprise beans. Los enterprise beans no son aplicaciones completas, sino componentes instalables que pueden ser ensamblados en soluciones completas.
  • El ensamblador de la aplicación: es el arquitecto de toda la aplicación. Esta parte es responsable de entender como todos los componentes encajan juntos y escribe componentes de la aplicación que combinan todos los componentes. Los componentes no suelen funcionar juntos mágicamente para solucionar problemas de negocios. El ensamblador de aplicación es el consumidor de los enterprise beans proporcionados por el proveedor y puede realizar algunas de las siguientes tareas:
    • Desde el conocimiento del problema de negocios, decidir que combinación de los componentes existentes y nuevos enterprise beans son necesarios para proveer una solución efectiva; En esencia, planificar el ensamblaje de la aplicación.
    • Proveer una interfaz de usuario (Swing, AWT, servlet/JSP, aplicación/applet, etc.)
    • Escribir nuevos enterprise beans para resolver problemas específicos del negocio.
    • Escribir las invocaciones a los componentes aportados por el bean provider.
    • Escribir código para integración que corresponda datos entre los componentes de diferentes proveedores de enterprise beans.
  • El instalador EJB (EJB-deployer): Luego de que la aplicación se encuentra ensamblada, debe ser instalada en un ambiente operacional. Con frecuencia el ensamblador de la aplicación (que puede ser un desarrollador o un analista de sistemas) no se encuentra familiarizado con estos temas. El instalador EJB debe resolver requerimientos operacionales específicos, y para ello entender como configurar los servidores de aplicación y personalizar los enterprise beans según el ambiente específico de instalación. Algunos desafíos a enfrentar en esta etapa incluyen:
    • Proteger la instalación tomando medidas de seguridad.
    • Integración con servidores LDAP para listas de seguridad.
    • Elegir el hardware que provea los niveles requeridos de performance.
    • Proveer hardware redundante y otros recursos de confiabilidad y tolerancia a fallas.
    • Puesta a punto y optimización del sistema.
  • El administrador del sistema: Una vez que la instalación se encuentra corriendo, es el encargado de supervisar la estabilidad de la solución operacional. Es el responsable del monitoreo del sistema instalado.
  • El proveedor del contenedor: proporciona un contenedor EJB (el servidor de aplicación). Este es el ambiente en el corren los enterprise beans. El contenedor proporciona servicios de middleware a los enterprise beans y los administra.
  • El proveedor de herramientas: Para facilitar el proceso de desarrollo de componentes, debe existir una forma estandarizada para construir, administrar, y mantener componentes. El proveedor de herramientas proporciona elementos para resolver estos problemas y asistir el desarrollo, el testing, y el modelaje de componentes.

La figura 10 muestra la colaboración de los distintos roles del ecosistema EJB.

Bibliografía

  • Mastering Enterprise JavaBeans second edition, Ed Roman, Scott Ambler, Tyler Jewel (Wiley Computer Publishing).
  • The J2EE™ 1.4 Tutorial, Eric Armstrong, Jennifer Ball, Stephanie, Bodoff, Debbie Carson, Ian Evans, Maydene Fisher, Dale Green, Kim Haase, Eric Jendrock (Sun Microsystems, Inc.).

Contribuyentes a esta página: gerardoo3533 puntos  , bernardoc y Quirón19322 puntos  .
Page last modified on Miércoles 12 de Julio, 2006 17:34:03 EDT by gerardoo3533 puntos .
El contenido de esta página esta licenciado bajo los términos del http://creativecommons.org/licenses/by-sa/2.5/legalcode.

Usuarios en línea

61 usuarios en línea