La tecnología Enterprise JavaBeans es la propuesta del mundo Java (Sun y un amplio grupo de empresas colaboradoras entre las que no se encuentra, evidentemente, Microsoft) para el desarrollo de aplicaciones de empresa. Entendemos por aplicaciones de empresa las aplicaciones informáticas de gestión que se implantan en grandes corporaciones con múltiples oficinas distribuidas por toda la geografía nacional (o internacional). Suelen ser aplicaciones distribuidas, usadas por múltiples clientes, que hacen un uso intensivo de transacciones, bases de datos y políticas de seguridad.
La arquitectura Enterprise JavaBeans es el núcleo de un conjunto de tecnologías Java que recibe el nombre de J2EE (Java 2 Enterprise Edition) y hace uso intensivo de librerías incluidas en esta plataforma. Algunos ejemplos de APIs Java usados por la arquitectura EJB son los siguientes:
La tecnología Enterprise JavaBeans esta siendo apoyada por la mayor parte de las empresas de informática que se orientan al mundo de la empresa (IBM, ORACLE, SUN,...) y también por los clientes de estas empresas, que valoran de forma muy positiva, entre otros aspectos, el carácter abierto de la arquitectura.
En este tema veremos una introducción a las distintas arquitecturas que se han ido proponiendo para las aplicaciones de empresa, y situaremos en este contexto la propuesta de arquitectura Enterprise JavaBeans. Comentaremos las características principales de la propuesta, dando algunos ejemplos prácticos de componentes Enterprise JavaBeans (EJB). Como parte práctica, explicaremos cómo realizar un despliegue de componentes EJB en el servidor de aplicaciones Weblogic.
Las aplicaciones de empresa han sufrido una transformación extensa. La primera generación de aplicaciones de empresa consistían en aplicaciones centralizadas usando computadores mainframes. A finales de 1980 y comienzos de 1990, la mayoría de las nuevas aplicaciones de empresa se construyeron siguiendo una arquitectura de dos capas (también conocida como arquitectura cliente/servidor). Después, las aplicaciones de empresa evolucionaron a arquitecturas de tres capas, después a arquitecturas basadas en Web. El estado de evolución actual está representado por la arquitectura de aplicaciones J2EE.
El párrafo anterior se aplica a países con un alto grado de desarrollo tecnológico (léase Estados Unidos, y poco más). En países como España nos encontramos en la mayoría de los casos todavía usando aplicaciones cliente/servidor, y comenzando a implantar soluciones basadas en Web.
Con una aplicación de dos capas, un sistema de negocio se estructura como un conjunto de aplicaciones a nivel de sistema operativo que se ejecutan en la máquina cliente, típicamente un PC. Las aplicaciones se comunican a través de la red con el servidor de bases de datos, que almacena la información corporativa y que es el que implementa el manejo de transacciones y la seguridad. La comunicación entre las aplicaciones y el servidor de base de datos se realiza normalmente usando el lenguaje SQL.
Las aplicaciones cliente implementan uno o varios procesos de negocio, junto con la interfaz de usuario que proporciona la lógica de presentación que realiza la interacción entre el usuario y el proceso de negocio. El concepto de proceso de negocio encapsula una interacción del usuario con alguna información de la empresa.
Figura 1: arquitectura de aplicaciones de dos capas.
Entre las ventajas de esta arquitectura se encuentra la facilidad de desarrollo debido a que la presentación y la lógica de negocio residen en la misma aplicación. Los inconvenientes son mucho más numerosos. Entre ellos destacan :
El avance fundamental de las arquitecturas de tres capas es la separación de la lógica de presentación de la lógica de negocio. Para ello se introduce una capa intermedia que se encarga específicamente de la lógica de negocio y de la gestión de transacciones y de seguridad. Se introducen monitores de procesamiento de transacciones (TP, transaction processing, monitors) como CICS o Tuxedo que dan soporte a esta capa intermedia. La mayoría de los sistemas ERP* (Enterprise Resource Planning) usan esta arquitectura.
*ERP (Enterprise resource planning) es un término de la industria para un amplio conjunto de actividades soportadas por software de aplicación que facilitan a un fabricante o a otro negocio manejar partes importantes de su negocio, incluyendo planificación de productos, compra de material, mantenimiento de inventario, interacción con suministradores, servicios al cliente y seguimiento de pedidos. Los ERP también incluyen módulos de aplicación para los aspectos de finanzas y de recursos humanos del negocio. Normalmente, un sistema ERP usa o está integrado con una base de datos relacional. El despliegue de sistemas ERP obliga normalmente a realizar un considerable análisis de los procesos de negocio, así como la formación de los empleados y nuevos procedimientos de trabajo. Entre las empresas que desarrollan y despliegan ERP se encuentran SAP o Peoplesoft. (definición cortesía de whatis.com).
Figura 2: Arquitectura de aplicaciones de tres capas
Aunque esta arquitectura elimina algunos de los inconvenientes de la arquitectura de dos capas, todavía sufre de inconvenientes:
Los sistemas de componentes distribuidos representan un enfoque más moderno a la arquitectura de tres capas. Estos sistemas definen objetos o componentes que se ejecutan en la capa intermedia y que están disponibles para servir a otros procesos a través de proxies remotos. Estos proxies remotos comunican peticiones a los componentes distribuidos a lo largo de la red. Ejempo de sistemas de componentes distribuidos son RMI, CORBA y DCOM.
Figura 3: Arquitectura de tres capas con componentes distribuidos
Los componentes distribuidos son más reusables y flexibles que las aplicaciones basadas en procedimientos usadas en los monitores TP tradicionales, debido a que pueden ser ensamblados en una gran variedad de combinaciones para el desarrollo de aplicaciones de negocio, pero pueden ser complicados de programar y carecen de la infraestructura robusta que ofrecen los monitores TP.
La introducción de la Web lo cambió todo. El modelo simplificado de funcionamiento consiste en incorporar extensiones a los servidores Web. Estas extensiones invocan programas en el servidor que construyen dinámicamente documentos HTML a partir de la información almacenada en la base de datos corporativa. Además, estas extensiones en el servidor también introducen cambios en las bases de datos corporativas a partir de la información de formularios HTML.
Un ejemplo de estas extensiones son los scripts cgi-bin. Aunque estos mecanismos han permitido a los desarrolladores corporativos construir aplicaciones Web simples, el enfoque no escala bien para aplicaciones de empresa más complejas por las siguientes razones:
(hacer una pequeña ronda de debate sobre qué tipo de sistemas da cada una de las clases conocen los alumnos).
J2EE es una arquitectura estándar orientada específicamente hacia el desarrollo y el despliegue de aplicaciones de empresa orientadas a Web usando el lenguaje de programación Java. Las empresas y los vendedores independientes de software (ISV, en inglés) pueden usar la arquitectura J2EE tanto para el desarrollo y despliegue de aplicaciones intranet, sustituyendo de esta forma las aplicaciones de dos capas y de tres capas, y para el desarrollo de aplicaciones Web, sustituyendo el enfoque basado en cgi.
La siguiente figura ilustra el modelo de programación propuesto por J2EE para el desarrollo de aplicaciones cliente/servidor. La Máquina Virtual Java hace de Contenedor de Aplicaciones Cliente.
Figura 4: Modelo de programación cliente/servidor de las aplicaciones J2EE
La siguiente figura ilustra el modelo de programación propuesto por J2EE para el desarrollo de aplicaciones de tres capas.
Figura 5: Modelo de programación de tres capas de las aplicaciones J2EE
La siguiente figura ilustra el modelo de programación para las aplicaciones basadas en Web:
Figura 6: Modelo de programación de aplicaciones J2EE para aplicaciones basadas en Web.
La plataforma J2EE consiste en cuatro entornos de programación, llamados contenedores:
En módulos anteriores del curso hemos estudiado las partes de J2EE que configuran una aplicación Web. Vamos a centrarnos en este modulo en el estudio de los componentes enterprise beans y de los contenedores EJB.
La arquitectura de componentes Enterprise JavaBeans (arquitectura EJB) es el núcleo de la plataforma J2EE. Esta arquitectura de componentes combina lo mejor de los monitores de procesamiento de transacciones y de los componentes distribuidos, proporcionando un entorno al estilo de los monitores de transacciones orientado a componentes distribuidos. La arquitectura EJB está constituida por un conjunto de componentes software llamados enterprise beans y un contenedor EJB que da soporte de ejecución a estos componentes.
En este apartado realizaremos una breve introducción a las características generales de la arquitectura.
En Marzo de 1998 Sun Microsystems propone la especificación 1.0 de la arquitectura Enterprise JavaBeans. Esta especificación comienza con la siguiente definición:
La arquitectura Enterprise JavaBeans es una arquitectura de componentes para el desarrollo y despliegue de aplicaciones de empresa distribuidas y orientadas a objetos. Las aplicaciones escritas usando la arquitectura Enterprise JavaBeans son escalables, transaccionales y seguras para multi usuarios. Estas aplicaciones pueden escribirse una vez, y luego desplegarse en cualquier servidor que soporte la especificación Enterprise JavaBeans.
Aunque se han introducido nuevas versiones de la especificación, que incorporan muchas mejoras a la propuesta inicial, la definición de la arquitectura sigue siendo la misma. La siguiente tabla muestra las distintas revisiones que ha sufrido la especificación de la arquitectura EJB.
|
Espeficiación EJB |
Fecha |
Principales novedades |
|
EJB 1.0 |
Marzo 1998 | Propuesta inicial de la arquitectura EJB. Se introducen los beans de sesión y los de entidad (de implementación opcional). Persistencia manejada por el contendedor en los beans de entidad. Manejo de transacciones. Manejo de seguridad. |
| EJB 1.1 | Diciembre 1999 | Implementación obligatoria de los beans de entidad. Acceso al entorno de los beans mediante JNDI. |
| EJB 2.0 | Agosto 2001 | Manejo de mensajes con los beans dirigidos por mensajes. Relaciones entre beans manejadas por el contenedor. Uso de interfaces locales entre beans que se encuentran en el mismo servidor. Consultas de beans declarativas, usando el EJB QL. |
| EJB 2.1 | Agosto 2002 | Soporte para servicios web. Temporizador manejado por el contenedor de beans. Mejora en el EJB QL. |
Tabla 1: Evolución de las especificaciones de la arquitectura Enterprise JavaBeans
Entre los objetivos que se enumeraban en ese primer documento de especificación 1.0 se encuentran los siguientes:
La arquitectura EJB define seis papeles principales. Brevemente, son:
Los enterprise beans (que también se denominan beans) son componentes software que se ejecutan en un entorno especial denominado contenedor EJB. El contenedor hospeda y maneja un enterprise bean de la misma forma que un servidor web Java hospeda un servlet o un navegador hospeda un applet. Un enterprise bean no puede funcionar fuera de un contenedor EJB. El contenedor EJB maneja cualquier aspecto del bean en tiempo de ejecución, incluyendo acceso remoto al bean, seguridad, persistencia, transacciones, concurrencia y acceso y pooling de recursos. El contenedor EJB también suele proporcionar servicios relacionados con la escalabilidad de la aplicación, como son la definición de clusters de contenedores, el balanceo de carga o la tolerancia a fallos.
Figura 7: El contenedor EJB captura la petición del cliente y realiza servicios de bajo nivel antes y después de pedir al bean que ejecute la lógica de negocio de la petición.
El contenedor aisla el enterprise bean del acceso directo de las aplicaciones cliente. Cuando una aplicación cliente invoca un método remoto en un enterprise bean, el contenedor intercepta la invocación para asegurar que la persistencia, transacciones y seguridad se aplican correctamente. De esta forma, el desarrollador de beans puede concentrarse en encapsular correctamente la lógica de negocio, mientras que el contenedor se encarga de todo lo demás.
El contenedor EJB se ejecuta a su vez en una máquina virtual Java, con lo que tiene acceso a toda la infraestructura proporcionada por este lenguaje de programación.
Los contenedores manejan muchos beans simultáneamente, en la misma forma que un servidor web Java maneja muchos servlets. Para reducir el consumo de memoria y el procesamiento, los contenedores almacenan (pool) los recursos y los ciclos de vida de los beans de forma muy cuidadosa. Cuando un bean no está siendo usado, el contenedor lo colocará en un almacén para ser reusado por otro cliente, o lo eliminará de la memoria y sólo lo recuperará cuando sea necesario. Debido a que las aplicaciones clientes no tienen acceso a los beans, la aplicación cliente desconoce completamente las actividades de manejo de recursos del bean. Por ejemplo, un bean que no está siendo usado puede ser eliminado de la memoria, mientras que su referencia remota en el cliente permanece intacta. Cuando el cliente invoca un método sobre la referencia remota, el contenedor simplemente recupera el bean para dar servicio a la petición. La aplicación cliente no se da cuenta de todo este proceso.
Un enterprise bean depende del contenedor para todo lo que necesita. Si un enterprise bean tiene que acceder a una conexión JDBC o a otro enterprise bean, lo hace a través del contenedor; si un enterprise bean tiene que acceder a la identidad de su llamador, obtener una referencia a él mismo, o acceder a propiedades, lo hace a través del contenedor.
En las próximas sesiones veremos cómo se implementa todo este funcionamiento. Veremos cómo el contenedor EJB intercepta las llamadas y cómo los beans pueden acceder a los servicios que proporciona el contenedor.
Los componentes enterprise bean encapsulan típicamente un proceso o una entidad de negocio. Un enterprise bean, por ejemplo, podría calcular los pagos de interés de un préstamo, o encapsular la información sobre una cuenta bancaria que se encuentra físicamente en una base de datos relacional. Un cliente que necesita información llama a los métodos de negocio en el bean y esta llamada provoca una invocación remota que llega al contenedor EJB.
Hay tres tipos de enterprise beans: beans de sesión, beans de entidad y beans dirigidos por mensajes. En la siguiente sesión los presentaremos con más detalle. Por ahora, vamos a adelantar sólo algunas de sus características
En la especificación 2.0 de la arquitectura EJB se definen tres tipos de beans: beans de sesión, beans de entidad y beans dirigidos por mensaje:
El cliente que usa los beans es una aplicación Java independiente, un servlet o una página JSP. En cualquier caso se trata de código Java que tiene acceso a las interfaces definidas para cada bean. También lo veremos con más detalle en la próxima sesión, pero adelantemos que existen dos tipos de acceso a los beans:
La arquitectura EJB proporciona beneficios a todos los papeles que hemos mencionado previamente (desarrolladores, ensambladores de aplicaciones, administradores, desplegadores, fabricantes de servidores). Vamos en enumerar las ventajas que obtendrán los desarrolladores de aplicaciones y los clientes finales.
Las ventajas que ofrece la arquitectura Enterprise JavaBeans a un desarrollador de aplicaciones se listan a continuación.
Entre las ventajas que aporta esta arquitectura al cliente final, destacamos la posibilidad de elección del servidor, la mejora en la gestión de las aplicaciones, la integración con las aplicaciones y datos ya existentes y la seguridad.