Java 2 Enterprise Edition (J2EE) es una arquitectura multicapa para implementar aplicaciones de tipo empresarial y aplicaciones basadas en la Web. Esta tecnolog�a soporta una gran variedad de tipos de aplicaciones desde aplicaciones Web de gran escala a peque�as aplicaciones cliente-servidor. El objetivo principal de la tecnolog�a J2EE es crear un simple modelo de desarrollo para aplicaciones empresariales utilizando componentes basados en el modelo de aplicaci�n. En este modelo dichos componentes utilizan servicios proporcionados por el contenedor, que de otro modo tendr�an que estar incorporados en el c�digo de la aplicaci�n. Observa que esto podr�a no ser lo ideal para todos los escenarios: por ejemplo, una peque�a aplicaci�n se cubrir�a mejor utilizando una soluci�n de la tecnolog�a Java de peso ligero (por ejemplo Servlets, JSPs, etc.).
�Componentes J2EE:
Las aplicaciones J2EE est�n compuestas de diferentes componentes. Un componente J2EE es una unidad de software funcional auto-contenido que se ensambla dentro de una aplicaci�n J2EE con sus clases de ayuda y ficheros y que se comunica con otros componentes de la aplicaci�n. La especificiaci�n J2EE define los siguientes componentes J2EE:
- Las Aplicaciones CLientes y los Applets son componentes que se ejecutan en el lado del cliente.
- Los componentes Java Servlet la tecnolog�a JavaServer Pages son componentes Web que se ejecutan en el lado del servidor.
- Los Enterprise JavaBeans (beans enterprise) son componentes de negocio que se ejecutan en el servidor de aplicacion.
Todos esos componentes se ensamblan en una aplicaci�n J2EE, se verifica que est�n bien formados y que cumplen la especificaci�n J2EE, y se despliegan en el entorno de producci�n, donde se ejecutan y son controlados por el servidor de aplicaciones J2EE.
Adem�s de estos componentes principales, J2EE incluye servicios est�ndar y tecnolog�as de soporte como:
- Java Database Connectivity (JDBC) tecnolog�a que proporciona acceso a sistemas de bases de datos relacionales.
- Java Transaction API (JTA) o Java Transaction Service (JTS) proporciona soporte para transaciones a los componentes J2EE.
- Java Messaging Service (JMS) para comunicaci�n as�ncrona entre componentes J2EE.
- Java Naming y Directory Interface (JNDI) proporcionan accesos a nombres y directorios.
Nota:
Todos los componentes J2EE est�n escritos en lenguaje Java |
�Clientes J2EE
Normalmente hay dos tipos de clientes J2EE: clientes Web y aplicaciones cliente como vimos en la figura anterior.
Un cliente Web consta de dos partes, p�ginas Web din�micas que contienen distintos tipos de lenguajes de marcas (HTML, XML, y otros), que son generados por los componentes Web que se ejecutan en la capa Web, y un navegador Web, que dibuja las p�ginas recibidas desde el servidor. Otra categor�a de clientes web son los conocidos como clientes thin (peque�os). Este tipo de peque�os clientes normalmente no hacen cosas como consultas a bases de datos o ejecutar complejas reglas de negocio. Cuando se utilizan clientes peque�os, las operaciones de peso pesado como est�s las manejan los beans enterprise que se ejecutan en el servidor J2EE donde pueden tratar con la seguridad, los servicios y el rendimiento de las tecnolog�as del lado del servidor J2EE.
Una p�gina Web recibida desde la capa del cliente puede incluir un applet embebido. Un appelt es una peque�a aplicaci�n cliente escrita en Java que se ejecuta en la m�quina virtual Java instalada en el navegador Web. Sin embargo, los sistemas cliente necesitar�n el Plug-in Java y posiblemente un fichero de pol�tica de seguridad para poder ejecutar con �xito los applets en el navegador Web. Normalmente los componentes Web son el API preferido para crear programas clientes Web porque no necesitan plug-ins ni ficheros de pol�tica de seguridad en los sistemas clientes. Adem�s esto permite un dise�o m�s claro y modular de la aplicaci�n porque proporciona un significado a la separaci�n de la l�gica de la aplicaci�n del dise�o de la p�gina Web.
Una aplicaci�n cliente se ejecuta sobre una m�quina cliente y proporciona una forma para que los usuarios puedan manejar tareas que requieren un interface de usuario m�s rico que el que puede proporcionar un lenguaje de marcas. Normalmente tienen un interface gr�fico de usuario (GUI) creado con los APIs Swing o Abstract Window Toolkit (AWT). Las aplicaciones cliente acceden directamente a los beans enterprise que se ejecutan en la capa de negocio. Pero si se necesita un cliente Web pueden abrir una conexi�n HTTP para establecer comunicaci�n con un servlet que se ejecute en la capa Web.
Nota:
Si se requiere, se puede utilizar un interface de l�nea de comandos. |
�Componentes Web:
Los componentes Web de J2EE pueden ser servlets o p�ginas JSP. Los servlets son clases Java que procesan din�micamente las peticiones y construyen las respuestas. Las p�ginas JSP son documentos basados-en-texto que se ejecutan como servlets pero permiten una aproximaci�n m�s natural para crear contenido est�tico. Las p�ginas HTML y los applets se juntan con los componentes Web durante el ensamble de la aplicaci�n, pero la especificaci�n J2EE no los considera como componentes J2EE. De forma similar, las clases de utilidades del lado del servidor tambi�n se unen a los componentes Web como p�ginas HTML, pero tampoco se consideran como componentes J2EE. Abajo podemos ver la comunicaci�n entre componentes Web:
La capa Web podr�a incluir componentes JavaBeans para manejar la entrar del usuario y enviar esta entrada a los beans enterprise que se ejecutan en la capa de negocio para su procesamiento seg�n hemos visto en la figura anterior.
�Componentes de Negocio:
El c�digo de negocio, que es la l�gica que resuelve o cumple las necesidades de un negocio particular, como la banca, la venta, o la financiaci�n, se maneja mediante beans enterprise que se ejecutan en la capa de negocio.
La figura de arriba muestra la comunicaci�n entre los componentes de negocio, donde un bean enterprise recibe datos de los programas clientes, los procesa (si es necesario), y los env�a a la capa del sistema de informaci�n empresarial para su almacenamiento. Un bean enteprise tambi�n recupera datos desde el almacenamiento, los procesa (si es necesario), y los env�a de vuelta al programa cliente.
Hay tres tipos de beans enterprise: beans de sesi�n (con o sin estado), beans de entidad (manejados por el bean o por el contenedor) y beans dirigidos a mensaje. Un bean de sesi�n representa una conversaci�n temporal con un cliente. Cuando el cliente finaliza su ejecuci�n, el bean de sesi�n y sus datos desaparecen. Por el contrario, un bean de entidad representa datos persistentes almacenados en una fila de una tabla/relaci�n de una base de datos. Si el cliente se termina o si se apaga el servidor, los servicios subyacentes se aseguran de grabar el bean. Un bean dirigido-a-mensaje combina las caracter�sticas de un bean de sesi�n y de un oyente de Java Message Service (JMS), permitiendo que un componente de negocio reciba as�ncronamente mensajes JMS.
Nota:
La especificaci�n J2EE no considera como componentes J2EE a los Java Beans ya que son diferentes de los Beans Enterprise. La arquitectura de componentes JavaBeans se pueden utilizar tanto en la capa de cliente como de servidor para manejar la comunicaci�n entre una aplicaci�n cliente o un applet y los componentes que se ejecutan en el servidor J2EE o entre los componentes del servidor y una base de datos, mientras que los componentes Enterprise JavaBeans s�lo se utilizan en la capa de negocio como parte de una capa de servidor. Los JavaBeans tienen variables de ejemplar y m�todos accesores y mutadores para acceder a las propiedades del bean o digamos, acceso a los datos en las variables de ejemplar lo que simplifica el dise�o y la implementaci�n de los componentes JavaBeans. |
�La Capa del Sistema de Informaci�n Empresarial:
La capa del sistema de informaci�n empresarial maneja el software del sistema de informaci�n empresarial e incluye la infraestructura del sistema as� como los planings de recursos (ERP), procesamieno de transaciones a mainframes, sistemas de bases de datos y otros sistemas de informaci�n legales (personalizados). Los componentes de aplicaciones J2EE podr�an necesitar acceder a estos sistemas de informaci�n empresariales para conectividad con sus bases de datos.
�Contenedores J2EE:
Los contenedores J2EE proporcionan acceso a los servicios subyancentes del entorno del Servidor J2EE mediante contenedores para diferentes tipos de componentes. Tradicionalmente, los desarrolladores de aplicaciones ten�an que escribir c�digo para el manejo de transaciones, manejo del estado, multi-threads, almacenamiento de recursos, etc. Ahora el contenedor J2EE proporciona estos servicios permitiendo que te puedas concentrar en resolver los problemas de negocio.
Los contenedores son el interface entre un componente y la funcionalidad de bajo nivel espec�fica-de-la-plataforma que soporta el componente. Por ejemplo, antes de poder ejecutar un componente Web, un bean enterprise o un componente de una aplicaci�n cliente, debe ensamblarse dentro de una aplicaci�n J2EE y desplegarse dentro de su contenedor.
El proceso de ensamble implica especificar las configuraciones del servidor para cada componente de la aplicaci�n J2EE y para la propia aplicaci�n J2EE. Estas configuraciones personalizan el soporte subyacente proporcionado por el servidor J2EE, que incluye servicios como JNI, JNDI, seguridad, control de transaciones, etc.
El servidor J2EE proporciona contenedores para Enterprise JavaBeans (EJB) y para componentes Web. El contenedor EJB maneja la ejecuci�n de los beans enterprise de las aplicaciones J2EE, mientras que el contenedor Web maneja la ejecuci�n de las p�ginas JSP y los componentes servlets de la aplicaci�n J2EE. Otros contenedores distintos a estos son el contenedor de aplicaciones clientes y el contenedor de applets, que no son parte del servidor J2EE porque residen en la m�quina del cliente:
Una contenedor de aplicaciones cliente maneja la ejecuci�n de los componentes de la aplicaci�n cliente mientras que un contenedor de Applets maneja la ejecuci�n de los applets. Normalmente est�n en el JRE (Java Runtime Environment) y el navegador Web compatible con Java, respectivamente.
�Empaquetado:
Para poder desplegar una aplicaci�n J2EE, despu�s de desarrollar los diferentes componentes, se empaqueta en ficheros de archivo especiales que contienen los ficheros de las clases relevantes y los descriptores de despliegue XML. Estos descriptores de despliegue contienen informaci�n espec�fica de capa componente empaquetado y son un mecanismo para configurar el comportamiento de la aplicaci�n en el momento del ensamble o del despliegue. Estos se empaquetan en diferentes tipos de archivos seg�n los distintos componentes.
Los componentes Web se empaquetan en un archivo Web (.war) que contiene los servlets, las p�ginas JSP y los componentes est�ticos como las p�ginas HTML y las im�genes. El fichero .war contiene clases y ficheros utilizados en la capa Web junto con un descriptor de despliegue de componentes Web.
Los componentes de negocio se empaquetan en un archio Java (.jar) que contiene los descriptores de despliegue EJB, los ficheros del interface remoto y del objeto junto con ficheros de ayuda requeridos por el componente EJB.
Los ficheros de clases del lado del cliente y los descriptores de despliegue se empaquetan en un fichero Java (.jar) que crea la aplicaci�n cliente.
Una aplicaci�n J2EE se empaqueta en un archivo enterprise (.ear) que contiene toda la aplicaci�n junto con el descritor de despliegue que proporciona informaci�n sobre la aplicaci�n y sus componentes:
�Roles de la Plataforma J2EE:
La construcci�n de los diferentes componentes de una aplicaci�n J2EE implica a varios roles en el desarrollo, despliegue y control de una aplicaci�n empresarial.
- El proveedor de componentes de aplicaci�n desarolla componentes J2EE reutilizables, que pueden ser componentes Web, beans enterprise, applets, o aplicaciones clientes para utilizar en aplicaciones J2EE.
- El ensamblador de aplicaciones toma todos los bloques de los diferentes proveedores de componentes y los combina en aplicaciones J2EE.
- El desarrollador es el responsable de la instalaci�n/despliegue de los componentes en un entorno o servidor J2EE.
- El administrador del sistema es el responsable de configurar y administrar los sistemas inform�ticos en una empresa.
- El proveedor de herramientas es un vendedor utilizado para desplegar, empaquetar y desplegar aplicaciones J2EE.
Nota:
Todos los roles mencionados se pueden asiginar a personas u organizaciones. |
�La Arquitectura Distribuida en J2EE:
Todas las aplicaciones J2EE implementan una arquitectura distribuida. En �sta un objeto est� asociado con un nombre, donde los nombres los proporciona un servicio de nombres, notificando a distintos componentes y resolviendo las referencias de clientes para estos componentes de servicio como se muestra en la siguiente figura:
Como resultado de esto, las referencias de objetos se obtienen buscando un objeto por su nombre notificado, una vez encontrado, se obtiene la referencia, y se llevan a cabo las operaciones necesarias sobre ese objeto utilizando los servicios del host. Un objeto remoto notifica su disponibilidad en el servicio de nombres utilizando un nombre l�gico y el servicio de nombres lo traduce a la localizaci�n f�sica del objeto en el entorno J2EE. Una vez que la petici�n del cliente obtiene una referencia a un componente remoto, puede enviarle peticiones. El sistema de ejecuci�n maneja la comunicaci�n distribuida entre objetos remotos, lo que incluye la serializaci�n y des-serializaci�n de par�metros.
Nota:
Algunos de los sistemas de nombres utilizados en los sistemas distribuidos son RMI (s�lo para implementaciones Java), CORBA, LDAP, DNS, NIS. El servidor de aplicaciones JBOSS utiliza RMI como su servicio de nombres. |
�La Arquitectura Java Naming Directory Interface (JNDI):
J2EE utiliza el API JNDI para acceder gen�ricamente a servicios de nombrado y directorio utilizando la tecnolog�a Java. El API JNDI reside entre la aplicaci�n y el servicio de nombres y hace que el servicio de nombres subyacente sea transparente para los componentes de la aplicaci�n:
Un cliente puede buscar referencias a componentes EJB u otros recursos en un servicio de nombres como el mencionado arriba. El c�digo del cliente no se modifica, sin importar el servicio de nombres que se est� utilizando o en qu� tecnolog�a est� basado, y esto no crea ninguna diferenc�a en el modo en que los clientes localizan los objetos remotos mediante el API JNDI.