Concepto: Visión general de Java 2 Platform Enterprise Edition (J2EE)
En esta directriz se proporciona una visión general completa sobre la plataforma J2EE.
Relaciones
Elementos relacionados
Descripción principal

Introducción

En el complejo y rápido mundo de las aplicaciones distribuidas de hoy en día, es de gran importancia hacer que las aplicaciones lleguen al mercado lo más rápidamente posible. Esto significa que los equipos de proyectos no pueden permitirse el lujo de invertir tiempo en desarrollar servicios a nivel de sistema, como los relacionados con la conectividad remota, la denominación de nombres, la persistencia, la seguridad o la gestión de transacciones. El equipo de proyectos necesita desarrollar y utilizar componentes reutilizables y portables. Lo que no se desea es invertir tiempo volviendo a inventar arquitecturas sólidas y reconocidas.

La plataforma Java™ Enterprise Edition (J2EE™) satisface estas necesidades proporcionando una infraestructura basada en estándares y bien documentada para desarrollar y ejecutar aplicaciones Java distribuidas, de múltiples capas y basadas en componentes. Esta infraestructura maneja una gran parte de la complejidad de bajo nivel de las aplicaciones como, por ejemplo, la relacionada con la conectividad remota, la denominación de nombres, la persistencia, la seguridad y la gestión de transacciones, haciendo que los desarrollares sólo tengan que concentrase en la lógica empresarial de la aplicación.

La plataforma J2EE está compuesta por:

  • Un conjunto de estándares para los componentes J2EE y la plataforma J2EE en la que los componentes se ejecutan.
  • Un modelo de desarrollo de aplicaciones que describe la plataforma J2EE en detalle, que ofrece una gran robustez y proporciona información sobre la mejor manera de desarrollar aplicaciones J2EE.
  • Una implementación de referencia de la plataforma J2EE, que Sun Microsystems Inc. proporciona como un estándar con el que se pueden comparar los productos J2EE comerciales. Esta implementación de referencia incluye aplicaciones de ejemplo totalmente desarrolladas.
  • Un conjunto de pruebas de compatibilidad para probar y evaluar implementaciones J2EE comerciales en relación con los estándares J2EE.

La plataforma J2EE es análoga a los servicios que proporcionan las herramientas de programación utilizadas por el sistema operativo de su equipo, el sistema operativo proporciona servicios estándares sobre los que se desarrollan y ejecutan aplicaciones, sin tener que preocuparse de la gestión a bajo nivel en relación con el acceso en disco, memoria, salida de vídeo, red, etc. De esta forma es posible concentrarse en los detalles de la aplicación y no en los detalles del sistema que subyace bajo ella. La plataforma J2EE proporciona un sistema operativo sofisticado para aplicaciones empresariales.

Mediante la plataforma J2EE, se simplifica el esfuerzo de desarrollo de forma que el equipo de proyectos puede centrar sus esfuerzos en la verdadera lógica empresarial de la aplicación, en lugar de invertir un tiempo crítico del desarrollo en la resolución de problemas a nivel del sistema. Un equipo de proyectos que se puede centrar en lo que la aplicación realiza, en lugar de centrarse en cómo ofrecer todos los servicios subyacentes que la aplicación necesita, es mucho más probable que suministre un sistema sin errores y a tiempo que satisfaga las necesidades de sus usuarios.

Consulte la visión general de la plataforma J2EE de Sun en http://java.sun.com/ para obtener más información. Siga los enlaces Products & APIs > Java™ 2 Platform, Enterprise Edition (J2EE™) > Overview.

Desarrollo en esencia de J2EE

Desde la perspectiva del desarrollador de aplicaciones:

  • Compra una plataforma J2EE comercial, en forma de un servidor J2EE compatible. Un estándar J2EE especifica el comportamiento del servidor J2EE.
  • Desarrolla o compra componentes J2EE disponibles comercialmente.
  • Despliega y ejecuta sus componentes J2EE en su servidor J2EE compatible, que proporciona todos los servicios que los componentes J2EE necesitan.

Ejemplo

Un ejemplo sencillo de una aplicación J2EE es un sitio de comercio electrónico, en que un cliente (usuario) utiliza un navegador web para acceder de forma remota al servidor J2EE. El servidor J2EE proporciona servicios de capa web y de capa empresarial, e interactúa con una capa EIS (Enterprise Information Systems) de fondo que proporciona acceso a sistemas de gestión de bases de datos relacionales.

Por qué utilizar J2EE

Deseará utilizar una plataforma J2EE para desarrollar una aplicación empresarial o de comercio electrónico de Java si si encuentra en alguno de estos casos:

Cada uno de estos puntos se tratará en más detalle en el resto de esta sección.

Estándar y probada en el mercado

Los componentes J2EE se ejecutan en contenedores J2EE, normalmente se proporcionan como parte de un servidor J2EE compatible. Estos contenedores proporcionan un conjunto de servicios estándar (API) que utilizan los componentes J2EE. Estas API son:

  • J2SE 1.4
    • JDBC
    • Java IDL
    • RMI-IIOP (Remote Method Invocation con el protocolo Internet Inter-ORB de CORBA)
    • JNDI (Java Naming and Directory Interface)
    • JAAS(Java Authentication and Authorization Service)
  • JTA (Java Transaction API)
  • JavaMail
  • JMS (Java Message Service).
    Consulte Concepto: Java Messaging Service (JMS) para obtener más información sobre JMS.
  • JAF (JavaBeans Activation Framework)
  • EJB (Enterprise JavaBeans)
  • Servlet de Java
  • JAXP (Java API for XML Processing)
  • Java Connector (Nota: no soportado con anterioridad a J2EE 1.3).
  • JSP (JavaServer Pages)
  • Servicios web para J2EE (Nota: no soportado con anterioridad a J2EE 1.4).
  • JAX-RPC (Java API for XML-based RPC) (Nota: no soportado con anterioridad a J2EE 1.4).
  • SAAJ (SOAP with attachments API for Java) (Nota: no soportado con anterioridad a J2EE 1.4).
  • JAXR (Java API for XML Registries) (Nota: no soportado con anterioridad a J2EE 1.4).
  • J2EE Management (Nota: no soportado con anterioridad a J2EE 1.4).
  • JMX (Java Management Extensions) (Nota: no soportado con anterioridad a J2EE 1.4).
  • J2EE Deployment (Nota: no soportado con anterioridad a J2EE 1.4).
  • JACC (Java Authorization Service Provider Contract for Containers) (Nota: no soportado con anterioridad a J2EE 1.4)

Portabilidad

Las aplicaciones y componentes J2EE son portables en relación con servidores J2EE compatibles, sin que sea necesario modificar el código, de forma que es posible desplegar una aplicación en el servidor J2EE compatible que elija con tan sólo actualizar la información de despliegue específica del servidor en los archivos de descriptor de despliegue XML (eXtended Markup Language).

La estandarización de la especificación J2EE ha dado lugar a la competitividad del mercado, ahora existe la posibilidad de elegir servidores J2EE compatibles de acuerdo a sus necesidades y presupuesto.

Componentes reutilizables

Puesto que cumplen los estándares J2EE, los componentes J2EE se pueden comprar como paquetes disponibles comercialmente y adjuntarlos a su aplicación J2EE según sea necesario, ahorrando esfuerzos de desarrollo (especialmente en la depuración y las pruebas).

Si es usted quien desarrolla un componente, puede volver a utilizarlo en otra aplicación o desplegarlo en distintos servidores J2EE compatibles, si así es necesario.

Patrones de diseño y arquitectura sólida y reconocida

La plataforma J2EE define una arquitectura de aplicación de varias capas bien estructurada. Con el soporte de la arquitectura de J2EE, los desarrolladores pueden comenzar con rapidez el desarrollo de la verdadera lógica empresarial de la aplicación.

La documentación J2EE incluye:

  • Un modelo de desarrollo de aplicaciones que describe la plataforma J2EE en detalle y proporciona información sobre la mejor manera de desarrollar aplicaciones J2EE.
  • Patrones J2EE bien documentados, las mejores recomendaciones del mercado, que describen soluciones a problemas comunes de diseño y de arquitectura de J2EE.

Visite la página http://java.sun.com/ para obtener más información sobre la plataforma J2EE. Siga los enlaces J2EE > Blueprints.

Escalabilidad

J2EE da soporte a la escalabilidad para aumentar el rendimiento o para satisfacer mayores cargas de varias maneras:

  • Características mejoradas de rendimiento en el contenedor J2EE: estas características incluyen la agrupación de recursos (agrupación de conexiones de base de datos, agrupación de instancias de beans de sesión y agrupación de hebras), paso de mensajes asíncronos y una gestión de ciclo de vida de componentes más eficiente. Por ejemplo, la apertura de una conexión con una base de datos es lenta. Además, las conexiones con las bases de datos pueden ser un recurso escaso debido, por ejemplo, a restricciones de licencia. La plataforma J2EE gestiona esta situación utilizando una agrupación de conexiones de base de datos en que el contenedor J2EE mantiene una agrupación de conexiones abiertas que se pueden asignar a un componente cuando es necesario, dando lugar a conexiones más rápidas y eficientes.
  • Mediante la agrupación en clúster se puede lograr el equilibrio de carga: desplegando el mismo componente en varios servidores en distintas máquinas. A continuación, se puede equilibrar la carga de cada uno de los servidores según convenga como, por ejemplo, de acuerdo a un algoritmo cíclico de asignación fija de tiempo o de acuerdo a la carga del servidor. La especificación de la plataforma J2EE no requiere la posibilidad de equilibrio de carga en un servidor J2EE, pero sí sugiere que un servidor de gama alta debería tenerla. Los proveedores de servidores J2EE ofrecen varias soluciones con posibilidad de equilibrio de carga.
  • Particionamiento de aplicaciones: partes distintas desde el punto de vista lógico de una aplicación se pueden desplegar en distintos servidores, por ejemplo, desplegando un inventario de una aplicación de pedidos de correo electrónico y los subsistemas de contabilidad en distintos servidores.

Herramientas de desarrollo y despliegue

Los proveedores han respondido a las necesidades de herramientas J2EE proporcionando un soporte excelente para el desarrollo de J2EE en sus entornos de desarrollo integrado (IDE) de Java entre las que se incluyen:

  • Asistentes para la creación de servlets.
  • Asistentes y diálogos para el mantenimiento y creación de EJB.
  • Generación y mantenimiento de descriptores de despliegue.
  • Correlación entre bases de datos y objetos EJB (en la que se incluye la generación de información de descriptor de despliegue de las relaciones gestionadas por contenedor).
  • Integración con un contenedor web para probar los servicios web.
  • Despliegue, depuración y pruebas de forma transparente en un entorno IDE de EJB mediante la integración con un contenedor EJB de J2EE y sus herramientas de despliegue.
  • Generación automática de clientes de prueba J2EE.
  • Integración con herramientas de creación de modelos UML.

Integración de fondo

El término "de fondo" hace referencia a la capa del sistema de información de la empresa (EIS) de la aplicación. Los sistemas de fondo pueden ser por ejemplo, sistemas de gestión de bases de datos relacionales, sistemas tradicionales o sistemas de planificación de recursos de la empresa (ERP).

J2EE da soporte al acceso mediante transacciones a sistemas de gestión de bases de datos relacionales de EIS mediante la utilización de las API JTA y JDBC. Además, los contenedores EJB dan soporte a la persistencia gestionada por contenedor, en que la conexión y el acceso al sistema de gestión de bases de datos transaccionales la maneja de forma automática el contenedor.

La SPI (Service Provider Interface) de la arquitectura de conector J2EE define un estándar para conectar recursos de un EIS que no sea un sistema de gestión de bases de datos relacionales con un conector J2EE. Un adaptador de recursos específicos de un EIS (que un proveedor de un EIS proporciona) se conecta con el contenedor J2EE, ampliando las posibilidades del conector de forma que proporcione un soporte seguro y transaccional para dicho EIS. Los componentes en un contenedor pueden entonces acceder a un EIS mediante la SPI de la arquitectura de conector J2EE.

Nota: en versiones anteriores a J2EE 1.3 no se da soporte a la SPI de la arquitectura de conector J2EE.

Seguridad

J2EE proporciona unas potentes y simples características de seguridad. La información de seguridad para los componentes J2EE se define en sus descriptores de despliegue. Esta información define qué roles de seguridad están autorizados a acceder a métodos y/o URL concretos de un componente. Un rol de seguridad es simplemente un nombre lógico que se da a un grupo de usuarios, por ejemplo, a todos los miembros de un equipo de gestión de una organización se les podría asignar un rol denominado "gestores".

Puesto que la información de seguridad se declara en el descriptor de despliegue, el comportamiento de seguridad se puede cambiar sin la necesidad de un costoso ciclo de actualización-depuración-prueba con el código.

Arquitectura de varias capas

J2EE es una arquitectura de aplicaciones distribuidas de varias capas que está compuesta de una capa de cliente, una capa intermedia y una capa EIS o de fondo.

En la figura 1 se muestra la arquitectura de varias capas de la plataforma J2EE, así como los distintos contenedores J2EE que dan soporte a los componentes J2EE.

Diagrama descrito en el texto adjunto.

Figura 1: Arquitectura de varias capas de J2EE.

Capa de cliente

Los componentes de la capa de cliente se ejecutan en contenedores de cliente. La capa de cliente se puede implementar de las siguientes maneras:

  • Aplicaciones Java autónomas: normalmente corresponde a una interfaz gráfica de usuario (también recibe el nombre de "cliente pesado"). Una aplicación Java de este tipo se debe instalar en cada máquina cliente. Una aplicación Java accede a la capa EIS o intermedia mediante una API como JDBC.
  • Páginas HTML estáticas: proporcionan a una aplicación una interfaz gráfica de usuario limitada.
  • HTML dinámico: que generan las páginas JSP o los servlets.
  • Applets: se ejecutan en un navegador web. Los applets se incrustan en una página HTML y normalmente se utilizan para proporcionar una interfaz gráfica de usuario.

Capa intermedia

La capa intermedia está compuesta de una capa web y una capa empresarial. Los componentes de la capa web se ejecutan en un servidor web J2EE que proporciona un contenedor web. Los componentes de la capa empresarial se ejecutan en un servidor de aplicaciones J2EE que proporciona un contenedor EJB.

Capa web

Los componentes web incluyen servlets y páginas JSP, que se encargan de gestionar la interacción con la capa de cliente, aislando los clientes de la capa EIS y de la capa empresarial. Los clientes realizan sus solicitudes a la capa web, que procesa las solicitudes y devuelve los resultados a los clientes. Las solicitudes de cliente a los componentes en la capa web generalmente dan lugar a solicitudes de capa web a componentes en la capa empresarial, que a su vez, podrían dar lugar a solicitudes en la capa EIS.

Capa empresarial

Los componentes de la capa empresarial la forman los EJB.

  • Contienen la lógica empresarial de la aplicación.
  • Realizan solicitudes a la capa EIS de acuerdo a la lógica empresarial, normalmente como respuesta a las solicitudes que provienen de la capa web.

Capa EIS

La capa EIS representa los datos almacenados de la aplicación, a menudo en forma de un sistema de gestión de bases de datos relacionales. La capa EIS también podría estar formada por sistemas tradicionales o ERP, a los que se accede mediante la API de arquitectura de conector J2EE.

Consulte la página http://java.sun.com/ para obtener más información sobre la API de arquitectura de conector J2EE. Siga los enlaces Products & Technologies > J2EE > J2EE Connector Architecture.

Consulte la sección Concepto: configuraciones de despliegue de J2EE para obtener más información sobre las configuraciones de despliegue estándar de J2EE.

Servidores J2EE

Los servidores J2EE son productos comerciales que implementan la plataforma J2EE. Ejemplos de servidores comerciales de J2EE son BEA WebLogic, Borland Enterprise Server, IBM WebSphere e iPlanet.

El término "servidor J2EE" se utiliza a veces de forma algo ambigua. Normalmente, quiere decir que se trata de "un servidor J2EE que da soporte tanto a un contenedor web como a un contenedor EJB". Utilizando una terminología más estricta, un servidor web J2EE (como el Tomcat de implementación de servidor web de referencia de J2EE) da soporte a un contenedor Web; un servidor de aplicaciones (o EJB) J2EE que da soporte a un contenedor EJB.

Contenedores J2EE

Los componentes J2EE se ejecutan en, o los alojan, los contenedores J2EE que normalmente se proporcionan como parte de un servidor J2EE comercial. Los contenedores proporcionan un entorno de tiempo de ejecución y un conjunto estándar de servicios (API) a los componentes que se ejecutan en el contenedor, además de dar soporte a las API J2SE estándar.

J2EE define los siguientes tipos de contenedores:

Contenedor de cliente de aplicación

Un cliente de aplicación J2EE se ejecuta en un contenedor de cliente de aplicación, que da soporte a estas API J2EE: JDBC, JMS, JAXP, JAAS, JavaMail, JAF, JSR, JAX-RPC, SAAJ, J2EE Management y JMX.

Desde un punto de vista práctico, la instalación J2SE estándar comprende los contenedores de cliente de aplicación. El contenedor de cliente de aplicación debe dar soporte a la interfaz del manejador de devolución de llamada JAAS para satisfacer las restricciones de seguridad del resto de la aplicación empresarial en contenedores EJB y web.

Contenedor de applets

Un applet se ejecuta en un contenedor de applets, que da soporte al modelo de programación de applets y da soporte a las API J2SE estándar. Desde un punto de vista práctico, los contenedores de applets se proporcionan como el plug-in de Java para un navegador web.

Contenedor web

Los componentes web (páginas JSP y servlets) se ejecutan en un contenedor web que se proporciona como parte de un servidor J2EE o que se proporciona como en un servidor web J2EE autónomo. Un contenedor web da soporte a los siguientes paquetes y las siguientes API J2EE: JDBC, JMS, JAXP, JAX-RPC, JAXR, JAAS, Java Mail, JAF, arquitectura de conector J2EE, JTA, JSR, SAAJ, J2EE Management, Java Servlet y JSP.

Contenedor de EJB

Los componentes EJB se ejecutan en un contenedor EJB, que se proporciona como parte de un servidor J2EE.

Un contenedor EJB da soporte a las siguientes tecnologías y API J2EE: EJB, JDBC, JMS, JAXP, JAX-RPC, JAXR, JAAS, Java Mail, JAF, JTA, JSR, SAAJ, J2EE Management y arquitectura de conector J2EE.

Las siguientes subsecciones resumen la funcionalidad básica a la que los contenedores EJB dan soporte:

Comunicaciones remotas

Los contenedores EJB ocultan a los desarrolladores la complejidad de las comunicaciones remotas mediante la utilización de clases proporcionadas de contenedor (que generan las herramientas de contenedor al compilar el EJB, junto con las clases de apéndice RMI para que las utilicen los clientes) que implementan las interfaces EJB. Estas clases de implementación son objetos Java remotos a los que un cliente accede mediante la RMI de Java. Desde la perspectiva del cliente, el cliente simplemente llama a métodos en la interfaz EJB, sin ninguna consideración en relación con las comunicaciones remotas.

Concurrencia

Los contenedores EJB gestionan de forma transparente las solicitudes concurrentes de varios clientes. Los clientes actúan como si tuviesen acceso exclusivo al EJB. Por ejemplo, si dos clientes solicitan la misma entidad EJB, el contenedor la proporciona a cada una de ellas con su propia instancia y gestiona internamente la sincronización sin que lo sepa el cliente.

Denominación de nombres

El contenedor EJB proporciona un espacio de nombres JNDI para ubicar los EJB desplegados en el contenedor. Los clientes EJB pueden buscar EJB para obtener una interfaz inicial. La interfaz inicial de un EJB proporciona los métodos para encontrar y crear instancias de EJB. En la medida que el contexto de denominación de nombres JNDI esté disponible desde su ubicación, los clientes pueden acceder a los EJB.

Persistencia

Los desarrolladores de EJB tienen la posibilidad de elegir entre dos esquemas para almacenar los datos persistentes del EJB de entidad: CMP (Container Managed Persistence) y BMP (Bean Managed Persistence). CMP delega la responsabilidad de implementar el código de acceso de datos al contenedor, mientras que BMP deja al desarrollador de EJB la responsabilidad de implementar dicho código. CMP permite que el desarrollador de EJB utilice una implementación estándar para acceder al almacenamiento persistente simplemente con la declaración de unos campos gestionados por contenedor en un descriptor de despliegue.

Gestión de transacciones

Una transacción es una secuencia de operaciones indivisibles que finalizan con éxito o con errores, de forma que si cualquier operación de la secuencia finaliza de forma errónea, no se efectúa cambio alguno en el estado del sistema. Por ejemplo, imaginemos que hay que emitir billetes aéreos: se validaría la cuenta de la tarjeta de crédito del cliente, se cargaría en dicha cuenta y, finalmente, se emitiría el billete. Esta secuencia de operaciones debería darse en una única transacción, de forma que si cualquier operación finaliza con errores, no se debería realizar cargo alguno en la cuenta de la tarjeta de crédito del cliente ni tampoco se deberían emitir los billetes.

Los EJB pueden utilizar la demarcación de transacciones gestionada por bean o la demarcación de transacciones gestionada por contenedor, que se describen a continuación.

Demarcación de transacción gestionada por bean

En la demarcación de transacción gestionada por bean, se utiliza una API simple para demarcar los límites de la transacción. Se trata de la JTA (Java Transaction API), que sirve para controlar mediante programación la demarcación de una transacción; por ejemplo, llamando a los métodos begin(), commit() y rollback() de la interfaz UserTransaction de JTA. Corresponde al desarrollador codificar la lógica de retroacción en relación con las condiciones de excepción de la transacción, puesto que el contenedor no las maneja de forma automática.

Nota: los EJB de entidad no pueden utilizar la demarcación de transacción gestionada por bean, sólo pueden utilizar la demarcación de transacción gestionada por contenedor.

Demarcación de transacción gestionada por contenedor

En una demarcación de transacción gestionada por contenedor, no se proporciona el código para iniciar y finalizar las transacciones. En lugar de esto, se proporciona información de atributo de transacción en el descriptor de despliegue EJB para cada método del EJB. El atributo de transacción (uno entre Required, RequiresNew, NotSupported, Supports, Mandatory o Never) indica al contenedor qué ámbito de transacción hay que utilizar para el método. Por ejemplo, si un cliente está en ejecución dentro de una transacción y llama a un método del EJB en que el atributo de transacción está establecido en Required, entonces se llamará al método dentro del ámbito de la transacción existente.

Siempre que sea posible, es mejor utilizar la demarcación de transacción gestionada por contenedor en lugar de la demarcación de transacción gestionada por bean puesto que de esta forma no es necesario añadir, depurar y probar el código de la demarcación de transacción en el componente. En lugar de ello, el comportamiento de cada uno de los métodos EJB de la transacción se especifica en el momento del despliegue, en el descriptor de despliegue. Esto significa que el comportamiento de la transacción se puede cambiar sin la necesidad de un costoso ciclo de actualización-depuración-prueba con el código.

Transacciones distribuidas

Una transacción distribuida es una transacción que se debe coordinar entre varias bases de datos y/o varias aplicaciones. Esto las distingue de una transacción centralizada, como en el caso de un único servidor de aplicaciones J2EE confirmando transacciones en una única base de datos.

En las transacciones distribuidas se necesita una confirmación en dos fases como, por ejemplo, cuando se está actualizando más de una base de datos. Algunos contenedores EJB (como BEA WebLogic Server 6.0) sólo dan soporte a la confirmación en dos fases mediante el protocolo XA de Open Group. El programador de la aplicación no necesita escribir código alguno para manejar la confirmación en dos fases; el contenedor EJB se encarga de gestionarla.

Gestión de seguridad

El contenedor EJB maneja la seguridad del EJB, con la información de seguridad que hay en el descriptor de despliegue. En el descriptor de despliegue, se declara un conjunto de roles y, para cada método EJB, se declaran los roles que están autorizados a llamar al método.

En tiempo de ejecución, se asigna un rol a cada cliente del EJB, y es el contenedor EJB quien gestiona el acceso a los métodos del EJB comprobando que el rol del cliente está autorizado a llamar al método.

Puesto que la información de seguridad se declara en el descriptor de despliegue, el comportamiento de seguridad se puede cambiar sin la necesidad de un costoso ciclo de actualización-depuración-prueba con el código.

Gestión de ciclo de vida

Los EJB pasan por una serie de estados durante su ciclo de vida en respuesta a solicitudes del cliente. El contenedor EJB es el responsable de gestionar este ciclo de vida.

Al iniciar el contenedor, el contenedor crea una agrupación de instancias de EJB en una agrupación de recursos (para disminuir el tiempo de inicio cuando se necesita un recurso EJB). Cuando un cliente EJB solicita la creación de un EJB, se asigna una instancia de la agrupación. El cliente puede hacer en ese momento solicitudes al EJB. Cuando un cliente EJB solicita la eliminación de un EJB, se devuelve la instancia a la agrupación.

El contenedor notifica a una instancia EJB de distintos sucesos en el ciclo de vida del EJB, mediante un conjunto de métodos de devolución de llamada estándar, como por ejemplo:

  • ejbCreate(). El contenedor llama a este método después de crear la instancia EJB.
  • ejbRemove(). El contenedor llama a este método cuando se ha de suprimir la instancia EJB.
  • ejbActivate(). El contenedor llama a este método después de restaurar una instancia EJB desde un estado pasivo.
  • ejbPassivate(). El contenedor llama a este método cuando la instancia EJB va a pasar a un estado pasivo.
  • ejbStore(). El contenedor llama a este método cuando se va a escribir la instancia EJB en una base de datos.
  • ejbLoad(). El contenedor llama a este método después de que se carguen de la base de datos los campos de instancia EJB.

Es necesario que cada EJB implemente estas devoluciones de llamadas a pesar de que a menudo la implementación EJB del método de devolución de llamada está vacía. Por ejemplo, el contenedor llama al método ejbRemove() del EJB para notificarle que está a punto de ser eliminado (ha habido una solicitud de cliente para que se elimine el EJB). En el método ejbRemove() del EJB, se podrían codificar todas las operaciones necesarias antes de eliminar el EJB como, por ejemplo, las operaciones de liberación de todos los recursos que retiene el EJB.

Los EJB pueden pasar a un estado pasivo, la información de estado se guarda y la instancia de EJB se libera para que la utilice la agrupación de recursos, si así lo necesita el contenedor. El contenedor activará un EJB en un estado pasivo, es decir que se restaurará la información de estado, si se recibe una solicitud de cliente para dicho objeto EJB en concreto.

Agrupación de conexiones de base de datos

El proceso de abrir una conexión de base de datos es un proceso lento. Además, las conexiones con las bases de datos pueden ser un recurso escaso debido, por ejemplo, a restricciones de licencia. El contenedor EJB gestiona este gasto mediante una agrupación de conexiones de base de datos, que mantiene abiertas y que se pueden asignar y desasignar a un EJB según sea necesario, dando lugar a unas conexiones eficientes y rápidas.

Para los EJB de entidad que utilicen CMP, las conexiones de base de datos se manejan de forma automática. No es necesario escribir código SQL o de conexión, simplemente se especifica el nombre JNDI del origen de datos JDBC en el descriptor de despliegue EJB y se utilizan herramientas de despliegue específicas para generar las rutinas de conexión en lugar de hacerlo el desarrollador. El contenedor gestiona la agrupación de conexiones de base de datos.

Para los EJB de entidad que utilicen BMP o para los EJB de sesión, es necesario escribir un código de conexión para conectar con un origen de datos JDBC y escribir código SQL para acceder a la base de datos. Aún así, el contenedor gestiona el origen de datos JDBC que en realidad utiliza una agrupación de conexiones de base de datos que el contenedor mantiene.

Mensajería

Los contenedores EJB necesitan proporcionar soporte de mensajería para el intercambio asíncrono de mensajes. Los mensajes entregados por procesos EJB controlados por mensajes pueden utilizar JMS u otros tipos de mensajería. Debido a la relación de JMS con EJB, deben dar soporte a acceso transaccional desde componentes de contenedores EJB y web como, por ejemplo, servlets, páginas JSP y EJB.

Componentes J2EE

La siguiente sección proporciona una breve explicación de todos los tipos de componentes J2EE. Los componentes J2EE incluyen applets, clientes de aplicación, componentes web y Enterprise JavaBeans (EJB). Los componentes J2EE se ejecutan en contenedores J2EE.

Applets

Los applets son pequeños programas que se pueden enviar junto con una página web y que se ejecutan en un navegador web. También se pueden ejecutar en otros entornos que den soporte al modelo de programación de applets.

Los applets se utilizan fundamentalmente para implementar interfaces de usuario y pueden ampliar en gran medida las posibilidades de las páginas HTML.

Clientes de aplicación

Los clientes de aplicación son aplicaciones Java. Tienen acceso a los recursos de la capa intermedia y a la capa EIS de J2EE. Normalmente son aplicaciones de escritorio que proporcionan una interfaz de usuario. Se pueden utilizar para implementar un "cliente pesado" tal como se describe en la sección Concepto: patrones de distribución.

Componentes web

Servlets de Java

La tecnología de servlets de Java permite que un servidor web maneje las solicitudes de un cliente web y que proporcione respuestas con contenido dinámico. Un servlet de Java tiene la posibilidad de interactuar con otros componentes EJB y web para crear este contenido dinámico. El contenido que se genera puede estar en cualquier formato de documento basado en texto, incluidos HTML y XML. Los servlets de Java también se pueden utilizar como puntos finales de servicios web con la ayuda de la API JAX-RPC.

Nota: la utilización de un servlet como un punto final de servicios web es una nueva característica de J2EE 1.4 (JAX-RPC 1.1) y, por lo tanto, versiones anteriores no dan soporte a esta funcionalidad.

Consulte la página web http://java.sun.com/ para obtener más información sobre los servlets J2EE. Siga los enlaces J2EE > Blueprints.

Páginas JavaServer (JSP)

La tecnología JSP (JavaServer Pages) se basa en los servlets de Java, pero se basa en texto en lugar de basarse en el código. Una página JSP procesa solicitudes y genera respuestas como un servlet, sin embargo, su lógica está fundamentalmente orientada a la presentación. Una página JSP contiene en su mayoría código HTML estático que define el formato para presentar los datos que se obtienen de otros orígenes como, por ejemplo, EJB o JavaBeans. Un desarrollador de componentes web tiene la posibilidad de crear bibliotecas de códigos personalizados para ampliar las JSP y añadir nuevas posibilidades.

Consulte la página http://java.sun.com/ para obtener más información sobre JSP. Siga los enlaces J2EE > Blueprints.

Páginas HTML

Las páginas HTML sirven para dar soporte a interfaces de usuario. Pueden estar definidas como páginas web estáticas, o bien servlets y páginas web las pueden generar. La especificación J2EE indica que los clientes web J2EE deben dar soporte a la visualización de páginas HTML.

JavaBeans

La API de JavaBeans define una arquitectura para crear componentes reutilizables simples. Estos componentes se pueden editar y ensamblar mediante la utilización de herramientas de construcción de aplicaciones. Para implementar JavaBeans se utiliza código Java normal, de forma que la implementación sigue siendo legible para los programadores, que podrían querer utilizar estos componentes, así como a herramientas.

JavaBeans no es una tecnología J2EE, sin embargo, otras tecnologías de J2EE la utilizan. Por ejemplo, los EJB pueden utilizar JavaBeans como objetos de valor. Consulte la sección denominada Comparación entre JavaBeans y EJB para conocer las diferencias entre JavaBeans y Enterprise JavaBeans.

Consulte la sección Concepto: JavaBeans para obtener más información sobre JavaBeans.

Enterprise JavaBeans

La especificación de Enterprise JavaBeans estipula una arquitectura para el desarrollo y despliegue de aplicaciones empresariales distribuidas transaccionales y basadas en componentes.

Los componentes que define la especificación EJB se denominan Enterprise JavaBeans (EJB). Los EJB son componentes Java del lado del servidor en que se implementan las reglas empresariales de la aplicación.

Los EJB se despliegan, y ejecutan, en un entorno denominado contenedor EJB, que se ha descrito con anterioridad en la sección Contenedor de EJB, que proporciona servicios como los de gestión de transacciones, conectividad con bases de datos y seguridad. Ocultando estas complejidades, la arquitectura EJB permite que los desarrolladores de componentes se centren en la lógica empresarial.

Un Enterprise JavaBean (EJB) es el resultado de la colaboración de interfaces de Java, una clase de implementación EJB y un descriptor de despliegue XML. Las interfaces EJB y la clase de implementación deben cumplir las reglas que la especificación EJB define, como las que obligan a implementar determinadas interfaces y proporcionar determinados métodos de devolución de llamadas.

Las interfaces EJB incluyen interfaces iniciales que proporcionan métodos para buscar y crear instancias de EJB, así como interfaces de componentes que proporcionan los métodos empresariales de una instancia EJB concreta. Se pueden tratar como interfaces remotas, es decir, que se pueden invocar a lo largo de la red, o tratarse como interfaces locales, lo que significa que el interlocutor debe estar en el mismo proceso (o de forma más precisa en la misma máquina virtual Java). Las interfaces EJB las implementan clases de contenedor EJB que delegan métodos a la clase de implementación EJB. Una excepción es un método de búsqueda de EJB de entidad gestionado por contenedor que una clase de contenedor maneja.

Hay tres tipos de EJB: beans de sesión, beans de entidad y beans controlados por mensajes.

Consulte la página http://java.sun.com/ para obtener más información sobre EJB. Siga los enlaces J2EE > Blueprints.

Beans de sesión

Un componente de bean de sesión proporciona servicios que implementan lógica empresarial específica del cliente. Un único cliente puede acceder a cada instancia de un bean de sesión mediante interfaces locales o remotas. Los beans de sesión tienen la posibilidad de guardar datos en una base de datos, pero normalmente utilizan beans de entidad que representan objetos empresariales para guardar datos. Las instancias de bean de sesión tienen la capacidad de mantener un estado conversacional transitorio.

Un bean de sesión podría tener un método denominado getAllCustomers() que devuelve una recopilación de todos los clientes en la base de datos. Este bean podría obtener su información del bean de entidad Cliente y entregar los resultados al cliente.

Los beans de sesión sin estado se pueden utilizar como puntos finales de servicio tal como se define en la especificación EJB y JSR.

Nota: la utilización de beans de sesión como servicios web es una nueva característica de J2EE 1.4 (JSR 109 y EJB 2.1) y, por lo tanto, versiones anteriores no dan soporte a esta funcionalidad.

Consulte la versión 2.1 de la especificación de Enterprise JavaBeans en la página http://java.sun.com/ para obtener más información sobre los beans de sesión. Siga los enlaces Products & Technologies > J2EE > Enterprise JavaBeans.

Beans de entidad

Un componente de bean de entidad proporciona servicios que implementan lógica específica del objeto empresarial. Varios clientes pueden acceder a una instancia de un bean de entidad de forma concurrente mediante interfaces locales o remotas. Los beans de entidad guardan datos de objetos empresariales en las bases de datos de forma que los datos de persistencia pueden sobrevivir a cuelgues del cliente o el contenedor.

Un bean de entidad podría representar un cliente, que se podría almacenar como una fila en la tabla de clientes de una base de datos relacional. Es el desarrollador de EJB quien decide el método de persistencia, en este caso una base de datos relacional.

Hay dos tipos de persistencia para un bean de entidad: persistencia gestionada por bean (BMP) y persistencia gestionada por contenedor (CMP). Los beans de entidad BMP deben implementar el código de acceso a los datos, mientras que en los beans de entidad CMP es el contenedor quien tiene implementada esta capacidad. Las implementaciones de contenedor CMP normalmente se proporcionan para persistencia en bases de datos relacionales, a pesar de que otros tipos de persistencia son también posibles (como por ejemplo, persistencia basada en archivos, etc.).

Consulte la versión 2.1 de la especificación de Enterprise JavaBeans en la página http://java.sun.com/ para obtener más información sobre los beans de entidad. Siga los enlaces Products & Technologies > J2EE > Enterprise JavaBeans.

Bean controlado por mensajes

Un componente de bean controlado por mensajes proporciona un servicio que implementa una lógica empresarial específica del proceso de mensajes. Sólo el contenedor puede llamar a este servicio, el cliente no puede llamar directamente a este servicio mediante interfaces locales o remotas. Por ello, cuando un mensaje llega a un destino o punto final al que el bean da servicio, el contenedor llama a una instancia de bean controlado por mensajes asignado como MessageListener para el destino. Las instancias de bean controladas por mensajes no mantienen un estado conversacional, sin embargo, pueden mantener variables de instancia con referencias a recursos (por ejemplo, conexiones con bases de datos entre llamadas de métodos).

Nota: las versiones anteriores a EJB 2.0 no dan soporte a beans controlados por mensajes. El soporte a tipos de mensajería distintos de JMS es una nueva característica de la especificación EJB 2.1 y, por lo tanto, versiones anteriores no les dan soporte.

Consulte la versión 2.0 de la especificación de Enterprise JavaBeans en la página http://java.sun.com/ para obtener más información sobre los beans controlados por mensajes. Siga los enlaces Products & Technologies > J2EE > Enterprise JavaBeans.

Comparación entre JavaBeans y EJB

A pesar de que tienen un nombre similar, los EJB son mucho más complejos que los JavaBeans normales. Ambos definen arquitecturas para componentes reutilizables, sin embargo, los EJB añaden el soporte necesario para la creación de servicios distribuidos y para varios usuarios. Ambos tipos de componentes se pueden ensamblar con herramientas de construcción de aplicaciones, sin embargo, los EJB necesitan desplegarse en un contenedor EJB para poder ejecutarse.

Servicios (API) para componentes J2EE

Los contenedores J2EE dan soporte a todas las API estándar de J2SE, así como a un subconjunto de las API de J2EE según sea el tipo de contenedor. Los componentes que haya dentro de un contenedor pueden acceder a este subconjunto que está disponible. En la tabla que aparece a continuación se muestra una breve descripción de cada API y se muestra una lista de contenedores J2EE donde están disponibles.

Nombre
Descripción
Contenedores J2EE donde
la API está disponible

EJB 2.1

La especificación EJB define un modelo de componentes para EJB y para componentes de la capa empresarial que automáticamente da soporte a servicios como los de las comunicaciones remotas, la gestión de transacciones, la seguridad y la persistencia.

Visite la página http://java.sun.com/ y siga los enlaces Products & Technologies > J2EE > Enterprise JavaBeans para obtener más información sobre EJB.

  • EJB
  • Cliente de aplicación*
  • Web*

* Sólo API de cliente

JAAS

JAAS (Java Authentication and Authorization Service) proporciona servicios para la autenticación y la autorización de usuarios con el fin de asegurarse que tienen permisos para realizar una acción.

Visite la página http://java.sun.com/ y siga los enlaces Products & Technologies > J2SE > Core Java > Java Authentication and Authorization Service (JAAS) para obtener más información sobre JAAS.

  • Cliente de aplicación
  • Web
  • EJB

JAF 1.0

JAF (JavaBeans Activation Framework) proporciona servicios para identificar datos y crear instancias de JavaBeans para manipular dichos datos.

Visite la página http://java.sun.com/ y siga los enlaces Products & Technologies > J2SE > Desktop Java > JavaBeans > JavaBeans Activation Framework para obtener más información sobre JAF.

  • Cliente de aplicación
  • Web
  • EJB

JAXP 1.2

JAXP (Java API for XML Processing) proporciona una interfaz abstracta para el proceso de documentos XML que se puede utilizar con transformadores y analizadores compatibles que utilicen DOM SAX o XSLT.

Visite la página http://java.sun.com/ y siga los enlaces Products & Technologies > J2EE > Java API for XML Processing (JAXP) para obtener más información sobre JAXP.

  • Cliente de aplicación
  • Web
  • EJB

JAX-RPC 1.1

La especificación JAX-RPC define API de cliente para acceder a servicios web además de técnicas para implementar puntos finales de servicio web.

Visite la página JAX-RPC/font> para obtener más información sobre JAX-RPC.

  • Cliente de aplicación
  • Web
  • EJB

Servicios web para J2EE 1.1

La especificación de servicios web para J2EE (JSR-109) define las funciones a las cuales un servidor de aplicaciones J2EE debe dar soporte para el despliegue de puntos finales de servicio web.

Visite la página http://jcp.org/aboutJava/communityprocess/final/jsr109/index.html para obtener más información sobre los servicios web para J2EE.

  • Cliente de aplicación
  • Web
  • EJB

SAAJ 1.2

La API SAAJ proporciona la capacidad de manipular mensajes SOAP.

Visite la página http://java.sun.com/ y siga los enlaces Products & Technologies > J2EE > SOAP with Attachments API for Java (SAAJ) para obtener más información sobre SAAJ.

  • Cliente de aplicación
  • Web
  • EJB

JAXR 1.0

La especificación JAXR define API para acceso del cliente a registros basados en XML como, por ejemplo, registros WebXML y registros UDDI.

Visite la página http://java.sun.com/ y siga los enlaces Products & Technologies > J2EE > Java API for XML Registries (JAXR) para obtener más información sobre JAXR.

  • Cliente de aplicación
  • Web
  • EJB

JavaMail 1.3

La API JavaMail proporciona una infraestructura que se puede ampliar para construir aplicaciones de correo basadas en Java.

Visite la página http://java.sun.com/ y siga los enlaces Products & Technologies > J2EE > JavaMail para obtener más información sobre JavaMail.

  • Cliente de aplicación
  • Web
  • EJB

JDBC 3.0

JDBC (Java Database Connectivity) es una API para acceder a orígenes de datos tabulares como, por ejemplo, bases de datos SQL, hojas de cálculo y archivos sin formato.

Visite la página http://java.sun.com/ y siga los enlaces Products & Technologies > J2EE > JDBC para obtener más información sobre JDBC.

  • Cliente de aplicación
  • Web
  • EJB

JMS 1.1

JMS (Java Message Service) proporciona servicios de mensajería asíncrona para transferir datos y notificación de sucesos. Con JMS, es posible utilizar EJB controlados por mensajes para procesar de forma asíncrona los mensajes que se entregan a colas y temas JMS.

Visite la página http://java.sun.com/ y siga los enlaces Products & Technologies > J2EE > Java Message Service para obtener más información sobre JMS.

  • Cliente de aplicación
  • Web
  • EJB

JNDI

JNDI (Java Naming and Directory Interface Specification) proporciona servicios de directorio y denominación de nombres para poder registrar y realizar búsquedas de recursos y componentes distribuidos. Los clientes sólo necesitan saber el nombre JNDI registrado del componente o recurso y no necesitan saber su ubicación real en la red.

Ejemplo: los EJB se registran en el directorio de la empresa en tiempo de despliegue, mediante el campo ejb-name del descriptor de despliegue. Los clientes J2EE buscan un EJB utilizando la búsqueda JNDI. Todo lo que necesitan saber los clientes es el nombre con el que se registró el EJB en el directorio. La búsqueda JNDI devuelve una referencia al objeto inicial del EJB.

Visite la página http://java.sun.com/ y siga los enlaces Products & Technologies > J2SE > Core Java > Java Naming and Directory Interface (JNDI) para obtener más información sobre JNDI.

  • Cliente de aplicación
  • Web
  • EJB

JTA 1.0

JTA (Java Transaction API) define interfaces para la gestión de servicios de transacciones distribuidas entre el gestor de transacciones, el gestor de recursos, el servidor de aplicaciones y la aplicación.

Visite la página http://java.sun.com/ y siga los enlaces Products & Technologies > J2EE > Transactions para obtener más información sobre JTA.

  • Web
  • EJB

J2EE Connector 1.5

La SPI (Service Provider Interface) de la arquitectura de conector J2EE define un estándar para conectar recursos de un EIS con un contenedor J2EE. Un adaptador de recursos específicos de un EIS (que un proveedor de un EIS proporciona) se conecta con el contenedor J2EE, ampliando las posibilidades del conector de forma que proporcione un soporte seguro y transaccional para dicho EIS. Los componentes en un contenedor pueden entonces acceder a un EIS mediante la SPI de arquitectura de conector J2EE.

Visite la página http://java.sun.com/ y siga los enlaces Products & Technologies > J2EE > J2EE Connector Architecture.

  • Web
  • EJB

JSP 2.0

La tecnología JSP (JavaServer Pages) proporciona a los desarrolladores web la posibilidad de crear y mantener páginas web dinámicas. Las páginas JSP son páginas basadas en texto y utilizan códigos similares a los de XML para llevar a cabo la lógica empresarial y para generar contenido personalizado. La tecnología JSP permite delegar la lógica empresarial a otros componentes de forma que sólo es necesario incrustar la lógica de presentación en las páginas JSP.

Visite http://java.sun.com/ y siga los enlaces Products & Technologies > J2EE > JavaServer Pages para obtener más información sobre JSP.

Web

Servlet 2.4

Los servlets de Java amplían las posibilidades del servidor web para ayudar en la creación de aplicaciones basadas en la web. Los servlets a menudo se utilizan en aplicaciones web interactivas en las que el servidor web responde a solicitudes del usuario con contenido generado de forma dinámica que se obtiene a partir de sistemas empresariales que ya existen.

Visite la página http://java.sun.com/ y siga los enlaces Products & Technologies > J2EE > Java Servlet para obtener más información sobre los servlets de Java.

Web

RMI-IIOP

RMI-IIOP (Remote Method Invocation technology run over Internet Inter-Orb Protocol) permite que los componentes Java se comuniquen con componentes CORBA existentes que se han escrito en otros lenguajes como, por ejemplo, C++ o Smalltalk.

Visite la página http://java.sun.com/ y siga los enlaces Products and APIs > RMI-IIOP para obtener más información sobre RMI-IIOP.

  • Cliente de aplicación
  • Web
  • EJB

J2EE Management 1.0

La API J2EE Management proporciona a las API herramientas de gestión para realizar consultas a un servidor de aplicaciones J2EE con el fin de determinar su estado actual, las aplicaciones desplegadas, etc.

Visite la página http://java.sun.com/ y siga los enlaces Products & Technologies > J2EE > J2EE Management Specification para obtener más información sobre J2EE Management.

  • Cliente de aplicación
  • Web
  • EJB

JMX 1.2

La API JMX la utiliza la API J2EE Management para proporcionar parte del soporte necesario para la gestión de un producto J2EE.

Visite la página http://java.sun.com/ y siga los enlaces Products & Technologies > J2SE > Core Java > Java Management Extensions (JMX) para obtener más información sobre JMX.

  • Cliente de aplicación
  • Web
  • EJB

J2EE Deployment 1.1

La API J2EE Deployment define las interfaces entre el entorno de tiempo de ejecución de una herramienta de despliegue y los componentes de plug-in que proporciona un servidor de aplicaciones J2EE.

Visite la página http://java.sun.com/ y siga los enlaces Products & Technologies > J2EE > J2EE Deployment Specification para obtener más información sobre J2EE Deployment.

JACC 1.0

La especificación JACC define un contrato entre un servidor de aplicaciones J2EE y un proveedor de políticas de autorización.

Visite la página http://java.sun.com/ y siga los enlaces Products & Technologies > J2EE > Java Authorization Contract for Containers para obtener más información sobre JACC.

  • Cliente de aplicación
  • Web
  • EJB

Ensamblaje y despliegue

Las aplicaciones J2EE están compuestas del descriptor de despliegue de aplicación (application.xml) y uno o más módulos J2EE que forman la aplicación. Los módulos son componentes portables y reutilizables. Las aplicaciones J2EE se empaquetan en archivadores .ear.

Descriptores de despliegue

Los descriptores de despliegue son archivos XML que se utilizan en aplicaciones J2EE y módulos J2EE. Proporcionan información de configuración que el servidor J2EE lee en el momento del despliegue. Esta información de configuración permite que el servidor personalice mediante declaraciones el módulo o la aplicación J2EE sin tener que cambiar las clases o el código fuente.

Para cada tipo de módulo o aplicación J2EE hay un tipo de descriptor de despliegue genérico. Los descriptores de despliegue genéricos como, por ejemplo, el archivo ejb-jar.xml de un módulo EJB, definen información que se aplica al EJB independientemente del servidor en el que esté desplegado. Los descriptores de despliegue específicos del servidor ofrecen información que sólo es de utilidad a un determinado servidor. Los descriptores de despliegue específicos de servidor tienen nombres que reflejan el servidor al que están dirigidos.

Módulos J2EE

Un módulo J2EE está formado por un descriptor de despliegue para el módulo y una serie de elementos que forman el módulo, entre los que se incluyen:

  • Elementos no Java que se despliegan en el servidor web (páginas JSP, archivos de imágenes, páginas HTML estáticas), en otras palabras, elementos de directorios virtuales.
  • Elementos Java desplegados en un servidor web (servlets, JavaBeans, clases Java).
  • Elementos desplegados en un servidor EJB (EJB y clases Java de soporte).

Hay tres tipos de módulos J2EE:

Cliente de aplicación J2EE

Los módulos de cliente de aplicación J2EE se empaquetan en archivadores .jar y pueden estar formados por:

  • Descriptor de despliegue application-client.xml.
  • Archivos .class de implementación de cliente de aplicación.
Componente web

Los módulos de componentes web se empaquetan en archivadores .war y pueden estar formados por:

  • Descriptores de despliegue específicos del servidor y el descriptor de despliegue web.xml.
  • Páginas JSP.
  • Páginas HTML.
  • Imágenes (por ejemplo, .gif y .jpg).
  • Archivos de clase de servlet.

Si el módulo es un servicio web, el archivador .war contiene:

  • Descriptor de despliegue webservices.xml.
  • Archivos de clase de servlet.
  • Archivos WSDL.
Enterprise JavaBean

Un único archivador JAR de Enterprise JavaBean puede contener una serie de EJB, además, su información de despliegue se almacena en un conjunto de descriptores de despliegue (el descriptor de despliegue ejb-jar.xml más cualquier otro específico al servidor).

Un módulo Enterprise JavaBean estándar está formado por:

  • Descriptor de despliegue ejb-jar.xml y descriptores de despliegue específicos del servidor.
  • Archivos de clase de implementación EJB.

Un módulo de Enterprise JavaBeans de servicio web está formado por:

  • Descriptores de despliegue webservices.xml.
  • Archivos de clase de implementación EJB.

Visite la página http://java.sun.com/ para obtener más información sobre el empaquetado y despliegue J2EE. Siga los enlaces Docs & Training > J2EE Platform, Enterprise Edition > Java Blueprints Program.

Desarrollo de aplicaciones J2EE

En el proceso de desarrollo de aplicaciones J2EE se definen varias etapas y roles. En las siguientes secciones se explica cómo definir los roles de desarrollo que la especificación J2EE proporciona y las etapas de desarrollo en la que estos roles participan.

Roles en el desarrollo de aplicaciones J2EE

Los roles de desarrollo de aplicaciones se resumen en esta tabla.

Nombre de rol Descripción

Proveedor de productos J2EE

Un proveedor de productos J2EE es el suministrador de una implementación de la plataforma J2EE, que también se denomina como un producto J2EE. Entre los proveedores de productos J2EE se incluyen BEA, IBM y Sun. Estas organizaciones normalmente se orientan en los aspectos que mejor dominan a la hora de proporcionar una implementación de la plataforma J2EE. Por ejemplo, la implementación BEA se basa en Tuxedo, su supervisor de proceso de transacciones, de gran éxito. Un proveedor de productos J2EE también proporciona las herramientas necesarias para dar soporte a la gestión y despliegue de aplicaciones.

Proveedor de componentes de aplicación

Un proveedor de componentes de aplicación realmente abarca más de un rol, como por ejemplo el desarrollador EJB y el diseñador de documentos HTML. Estos roles son los responsables de producir los componentes de aplicación J2EE mediante las herramientas proporcionadas.

Ensamblador de aplicaciones

El ensamblador de aplicaciones crea una aplicación J2EE a partir de componentes de aplicación J2EE mediante las herramientas proporcionadas. La aplicación J2EE se entrega en forma de archivo EAR (Enterprise Archive). El ensamblador de aplicaciones también describe todas las dependencias externas de la aplicación J2EE. El desplegador resuelve estas dependencias en el momento de desplegar realmente la aplicación J2EE.

Desplegador

El desplegador es el responsable de desplegar una aplicación J2EE y los componentes de aplicación que la forman en el entorno operativo. La primera etapa en un despliegue corresponde a la instalación de los distintos componentes de aplicación con los contenedores J2EE que correspondan. En la segunda etapa del despliegue se configuran todas las dependencias externas que se han declarado de forma que se puedan resolver. Por ejemplo, los roles de seguridad que se hayan definido se correlacionan con cuentas y grupos de usuarios en el entorno operativo. En la tercera etapa del despliegue se ejecuta la nueva aplicación de forma que esté preparada para recibir solicitudes.

Administrador del sistema

El administrador del sistema es el responsable de la infraestructura de tiempo de ejecución, que incluye todas las aplicaciones J2EE desplegadas. Este rol utiliza las herramientas apropiadas que proporcione el proveedor de productos J2EE para lograr este objetivo.

Proveedor de herramientas

Un proveedor de herramientas proporciona las herramientas para dar soporte al desarrollo y empaquetado de componentes de aplicación. Estas herramientas a menudo corresponden a los distintos tipos de componentes de aplicación creados, e incluyen entornos de desarrollo integrado (IDE) como, por ejemplo, IBM VisualAge para Java y Borland JBuilder.

Proveedor de componentes de sistema

Un proveedor de componentes de sistema proporciona distintos componentes a nivel de sistema como, por ejemplo, adaptadores de recursos o proveedores de políticas de autorización.


Estos roles no son exclusivos entre sí y una única persona puede asumir más de uno, especialmente en equipos de desarrollo pequeños o en una situación de creación de prototipos.

Etapas en el desarrollo de aplicaciones J2EE

Esta sección describe las distintas etapas del desarrollo de una aplicación J2EE, tal como se estipula en la especificación J2EE. Las etapas del desarrollo son:

  • Desarrollo de componentes
  • Una aplicación J2EE debe estar formada al menos por un módulo J2EE, de forma que al menos una de las etapas de desarrollo de componentes es necesaria. Las dos etapas finales son siempre necesarias puesto que todas las aplicaciones J2EE se deben ensamblar y desplegar.

    En la tabla que aparece a continuación se resumen las etapas de desarrollo con las aplicaciones J2EE.

    Etapa de desarrollo de J2EE Tareas Rol de J2EE que las realiza Resultado (objeto)

    Creación de cliente de aplicación J2EE

    • Escribe código de cliente y compila clases.
    • Crea el descriptor de despliegue application-client.xml.
    • Crea un archivador de archivos JAR con los archivos XML y de clases.

    Proveedor de componentes de aplicación (desarrollador de software).

    Un archivo JAR con el cliente de aplicación J2EE.

    Creación de componentes web

    • Escribe código de servlet y compila clases.
    • Escribe páginas HTML y JSP.
    • Crea el descriptor de despliegue web.xml.
    • Crea un archivador de archivo WAR (Web Application Archive) con los archivos de clases, .jsp, .hmtl y XML.

    Proveedor de componentes de aplicación (desarrollador de software: servlets; diseñador web: páginas JSP y HTML).

    Un archivo WAR con el componente web.

    Creación de Enterprise JavaBeans

    • Escribe el código EJB y compila las clases.
    • Crear el descriptor de despliegue ejb-jar.xml y los descriptores de despliegue específicos del servidor.
    • Crea un archivador de archivo JAR con los archivos XML y de clases.

    Proveedor de componentes de aplicación (desarrollador de software).

    Un archivo JAR con el Enterprise JavaBean.

    Ensamblaje de aplicación J2EE

    • Crea el descriptor de despliegue application.xml.
    • Crea un archivador de archivo EAR con los archivos EJB (JAR), componentes web (WAR) y XML.

    Ensamblador de aplicaciones.

    Un archivo EAR con la aplicación J2EE.

    Despliegue de aplicación J2EE

    • Añade la aplicación J2EE (EAR) al entorno del servidor J2EE.
    • Edita el descriptor de despliegue application.xml con la configuración del entorno local.
    • Despliega la aplicación J2EE en el servidor J2EE.

    Desplegador

    Aplicación J2EE instalada y configurada.


    Cada etapa del proceso de desarrollo produce un resultado que se utiliza en la siguiente etapa. Los componentes que se crean en las etapas de desarrollo de componentes se utilizan en la etapa de ensamblaje para producir un archivador EAR de aplicación J2EE. En la etapa de desarrollo de aplicación J2EE, el archivador EAR se despliega en el servidor J2EE.

    Los resultados de cada etapa son portables y no es necesario que los realicen las mismas personas o incluso en el mismo entorno, siempre que el entorno satisfaga los requisitos de la plataforma J2EE.

    Visite la página http://java.sun.com/ para obtener más información sobre el empaquetado y despliegue de J2EE. Siga los enlaces J2EE > Blueprints.

    Información adicional

    En los Blueprints de J2EE de Sun encontrará información adicional referente a J2EE. Podrá acceder a ellos en http://java.sun.com/. Siga los enlaces J2EE > Blueprints > Guidelines: Designing Enterprise Applications with the J2EE Platform, Second Edition.

    Con RUP (Rational Unified Process) se incluye una copia de este documento.

    Los capítulos dentro de los Blueprints de J2EE de Sun con información sobre temas específicos se resumen en esta tabla.

    Concepto de J2EE Capítulo en Blueprints de J2EE

    Tecnologías de la plataforma J2EE

    Capítulo 2

    Enterprise JavaBeans

    Capítulo 5

    Transacciones

    Capítulo 8

    Seguridad

    Capítulo 9

    Servlets

    Capítulo 4

    Páginas JavaServer

    Capítulo 4

    Empaquetamiento y despliegue

    Capítulo 7