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.
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)
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.
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.
|
|
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.
|
|
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
|
|