Las razones que empujan a la creación de la plataforma JEE:

• Programación eficiente. Para conseguir productividad es importante que los equipos de desarrollo tengan una forma estándar de construir múltiples aplicaciones en diversas capas (cliente, servidor web, etc.). En cada capa necesitaremos diversas herramientas, por ejemplo en la capa cliente tenemos applets, aplicaciones Java, etc. En la capa web tenemos servlets, páginas JSP, etc. Con JEE tenemos una tecnología estándar, un único modelo de aplicaciones, que incluye diversas herramientas; en contraposición al desarrollo tradicional con HTML, Javascript, CGI, servidor web, etc. que implicaba numerosos modelos para la creación de contenidos dinámicos, con los lógicos inconvenientes para la integración.



• Extensibilidad frente a la demanda del negocio. En un contexto de crecimiento de número de usuarios es precisa la gestión de recursos, como conexiones a bases de datos, transacciones o balanceo de carga. Además los equipos de desarrollo deben aplicar un estándar que les permita abstraerse de la implementación del servidor, con aplicaciones que puedan ejecutarse en múltiples servidores, desde un simple servidor hasta una arquitectura de alta disponibilidad y balanceo de carga entre diversas máquinas.



• Integración.  Los equipos de ingeniera precisan estándares que favorezcan la integración entre diversas capas de software.

La plataforma JEE implica una forma de implementar y desplegar aplicaciones empresariales. La plataforma se ha abierto a numerosos fabricantes de software para conseguir satisfacer una amplia variedad de requisitos empresariales. La arquitectura JEE implica un modelo de aplicaciones distribuidas en diversas capas o niveles (tier). La capa cliente admite diversas tipos de clientes (HTML, Applet, aplicaciones Java, etc.). la capa intermedia (middle tier) contiene subcapas (el contenedor web y el contenedor EJB). La tercera capa dentro de esta visión sintética es la de de aplicaciones 'backend' como ERP, EIS, bases de datos, etc. Como se puede ver un concepto clave de la arquitectura es el de contenedor, que dicho de forma genérica no es más que un entorno de ejecución estandarizado que ofrece unos servicios por medio de componentes. Los componentes externos al contenedor tienen una forma estándar de acceder a los servicios de dicho contenedor, con independencia del fabricante.

Algunos tipos de contenedores:

• Contenedor Web, también denominado contenedor Servlet/JSP, maneja la ejecución de los servlets y páginas JSP. Estos componentes se ejecutan sobre un servidor Enterprise Edition.
• Contenedor Enterprise JavaBeans, que gestiona la ejecución de los EJB. Esta ejecución requiere de un server EE.

Los contenedores incluyen descriptores de despliegue (deployment descriptors), que son archivos XML que nos sirven para configurar el entorno de ejecución: rutas de acceso a aplicaciones, control de transacciones, parámetros de inicialización, etc.

La plataforma JEE incluye APIs para el acceso a sistemas empresariales:

• JDBC es el API para accceso a GBDR desde Java.
• Java Transaction API (JTA) es el API para manejo de transacciones a traves de sistemas heterogeneos.
• Java Naming and Directory Interface (JNDI) es el API para acceso a servicios de nombres y directorios.
• Java Message Service (JMS) es el API para el envio y recepción de mensajes  por medio de sistemas de mensajería empresarial como IBM MQ Series.
• JavaMail es el  API para envio y recepción de email.
• Java IDL es el API para llamar a servicios CORBA.

Documento de SUN: JEE blueprints

A continuación vamos a entrar en más detalle. Para ello, hemos subrayado en el siguiente gráfico los elementos más importantes y usuales. La arquitectura de un servidor de aplicaciones incluye una serie de subsistemas:

• Servidor HTTP (también denominado servidor Web o servidor de páginas). Un ejemplo, el servidor Apache.
• Contenedor de aplicaciones o contenedor Servlet/JSP. Un ejemplo, Tomcat (que incluye el servicio anterior sobre páginas)
• Contenedor Enterprise Java Beans, que contiene aplicativos Java de interacción con bases de datos o sistemas empresariales. Un ejemplo es JBoss que contiene a los anteriores (servidor de páginas web y contenedor de aplicacione web).

Pero conviene empezar por el principio, es decir, el lenguaje básico de interconesión: el protocolo HTTP. Es un protocolo de aplicación, generalmente implementado sobre TCP/IP. Es un protocolo sin estado basado en solicitudes (request) y respuestas (response), que usa por defecto el puerto 8080:

• "Basado en peticiones y respuestas": significa que el cliente (por ejemplo un navegador) inicia siempre la conexión (por ejemplo, para pedir una página). No hay posibilidad de que el servidor realize una llamada de respuesta al cliente (retrollamada). El servidor ofrece la respueta (la página) y cierra la conexión. En la siguiente petición del cliente se abre una conexión y el ciclo vuelve e empezar: el servidor devuelve el recurso y cierra conexión.
• "Sin estado": el servidor cierra la conesión una vez realizada la respuesta. No se mantienen los datos asociados a la conexión. Más adelante veremos que hay una forma de persistencia de datos asociada a la "sesión".

¿Qué ocurre cuando un navegador invoca una aplicación? El cliente (el navegador) no invoca directamente el contenedor de aplicaciones, sino que llama al servidor web por medio de HTTP. El servidor web se interpone en la solicitud o invocación; siendo el servidor web el responsable de trasladar la solicitud al contenedor de aplicaciones.

Aspectos a considerar de forma síncrona:

• El cliente (normalmente por medio de un navegador, aunque podría ser una aplicación Swing) solicita un recurso por medio de HTTP. Para localizar el recurso al cliente especifica una URL (Uniform Resource Locator), como por ejemplo http://www.host.es/aplicacion/recurso.html. El URI (Uniform Resource Identifier) es el URL excluyendo protocolo y host. Existen diversos métodos de invocación, aunque los más comunes son POST y GET. Los veremos más adelante.
• Sobre una misma máquina podemos tener diversas instancias de un AS (Application Server), procurando que trabajen sobre puertos diferentes, para que no se produzcan colisiones (por defecto HTTP trabaja con 8080).
• Un servicio crucial es la capacidad de recibir peticiones HTTP, para lo cual tenemos un HTTP Listener (aunque puede tener listeners para otros protocolos como IIOP).
• La solicitud llega el servidor de páginas web, que tiene que descifrar si el recurso solicitado es un recurso estático o una aplicación. Si es una aplicación delega la solicitud en el contenedor web (contenedor Servlet/JSP). El contenedor web gestiona la localización y ejecución de Servlets y JSP, que no son más que pequeños programas. El contenedor web o contenedor Servlet/JSp recibe la solicitud. Su máquina Java (JVM) invoca al objeto Servlet/JSP, por tanto nos encontramos ante un tipo de aplicaciones que se ejecutan en el servidor, no en el cliente. No conviene olvidar que un Servlet o un JSP no es más que una clase Java. Lo más interesante en este sentido es que:
  • La JVM (generalmente) no crea una instancia de la clase por cada solicitud, sino que con una única instancia de un Servlet/JSP se da servicio a múltiples solicitudes HTTP. Esto hace que el consumo de recursos sea pequeño en comparación con otras opciones, como el uso de CGIs, en donde cada solicitud se resuelve en un proceso.
  • Para cada solicitud se genera un hilo (thread) para resolverla (pero con una única instancia de la clase, como hemos dicho).
• Un Application Server tendrá un servidor de administración (y normalmente un manager de las aplicación).

Otros aspectos del contenedor web:

• El contenedor necesita conectores que sirven de intermediarios para comunicarse con elementos externos. Los conectores capacitan al AS para acceder a sistemas empresariales (backends). Por ejemplo:
• El Java Message Service ofrece conectividad con sistemas de mensajeria como MQSeries.
• El API JDBC da la capacidad de gestionar bases de datos internas al AS, pero además permite ofrecer servicios como un pool de conexiones.
• Es necesario una gestión de hilos, ya que será necesario controlar la situación en la que tenemos una instancia de un componente (por ejemplo, un servlet) que da respuesta a varias peticiones, donde cada petición se resuelve en un hilo.

Para empezar a familiarizarnos con lo que es un servlet vamos a ver un pequeño ejemplo en el que se crea una página que contiene el típico "Hola mundo":

import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
import java.util.*;

public class Saludo extends HttpServlet {
   public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
      response.setContentType("text/html");
      PrintWriter out = response.getWriter();
      out.println("<html>");
      out.println("<head><title>Bienvenido al primer servlet</title></head>");
      out.println("<body bgcolor=\"#FFFF9D\"><FONT color=\"#000080\" FACE=\"Arial,Helvetica,Times\" SIZE=2>"+
		  "<CENTER><H3>Servlets</H3></CENTER>");
      Date d = new Date();
      out.println("<HR><p>¡Hola Mundo!. Fecha y hora: " + d.toString() +  ". Esto es Java.</p>");
      out.println("</body></font></html>");
   }
}

La mayoría de servlets heredan de HttpServlet. La JVM del servidor de aplicaciones recibe una solicitud, para dar la respuesta realiza una serie de tareas::

• Un hilo para cada solicitud. Normalmente se cumple que una solicitud corresponde con un hilo y todos los hilos comparten una única instancia del servlet (a menos que nuestra clase servlet herede de SingleThreadModel, que no es lo habitual). La JVM traduce la solicitud en la creación de un hilo, sobre el que se realiza una llamada a:
• Método service(), heredado de HttpServlet.
• service(), si no lo sobreescribimos, invocará al método correspondiente (si el método de invocación al servlet es GET, entonces la JVM llamara al método doGet() de nuestro servlet, si el método de invocación es POST la JVM llamará a doPost(), etc.). Más adelante veremos la diferencia de uno u otro.
• Ya hemos visto que la JVM invoca al método de entrada (doGet(), doPost(), etc). Pero además debe transferir al método de entrada dos objetos: uno es de la clase HttpServletRequest, que encapsula información diversa de la petición Http (cabecera, parámetros, etc.) y otro encapsula el stream o flujo Http de respuesta, de la clase HttpServletResponse.

Esto sólo es un pequeño anticipo de los que es un Servlet o un JSP. Los detalles del ciclo de vida de estas clase/páginas vendrán más adelante.

En el siguiente ejemplo de formulario en HTML podemos ver como se invoca al servlet anterior:

<form action="../../servlet/hola_mundo" method="get" target=_blank >
<p><input type="submit" name="Submit" value="Pulse aqui para llamar al servlet que saluda"></p>
</form>

El form en "real":

En la parte 'action' del formulario indicamos la URL o URI del recurso (en nuestro ejemplo es el servlet de saludo). Con el atributo 'method' indicamos el método de invocación. Con este método los parámetros de la solicitud aparecen explicitos, es decir, se incluyen en la URL de solicitud. Sin embargo con el método POST los parámetros quedan ocultos al cliente, ya que se transmiten en el cuerpo de la solicitud. El botón es el tipo 'submit', lo que indica que su pulsación disparará la acción (solicitud de recurso).

Para acceder a una introducción sobre servlets: JEE - Servlets - Introducción.

En la arquitectura JEE se contemplan cuatro capas, en función del tipo de servicio y contenedores:

• Capa de cliente, también conocida como capa de presentación o de aplicación. Nos encontramos con componentes Java (applets o aplicaciones) y no-Java (HTML, JavaScript, etc.).
• Capa Web. Intermediario entre el cliente y otras capas. Sus componentes principales son los servlets y las JSP. Aunque componentes de capa cliente (applets o aplicaciones) pueden acceder directamente a la capa EJB, lo normal es que Los servlets/JSPs pueden llamar a los EJB.
• Capa Enterprise JavaBeans. Permite a múltiples aplicaciones tener acceso de forma concurrente a datos y lógica de negocio. Los EJB se encuentran en un servidor EJB, que no es más que un servidor de objetos distribuidos. Un EJB puede conectarse a cualquier capa, aunque su misión esencial es conectarse con los sistemas de información empresarial
(un gestor de base de datos, ERP, etc.)


• Capa de sistemas de información empresarial.

La visión de la arquitectura es un esquema lógico, no físico. Cuando hablamos de capas nos referimos sobre todo a servicios diferentes (que pueden estar físicamente dentro de la misma máquina e incluso compartir servidor de aplicaciones y JVM)

A continuación veremos algunos de los diversos escenarios de aplicación de esta arquitectura

Es el escenario canónico, donde aparecen todas las capas, empezando en un navegador HTML/XML. La generación de contenidos dinámicos se realiza normalmente en páginas JSP. La capa EJB nos permite desacoplar el acceso a datos EIS de la interacción final con el usuario que se produce en las páginas HTML y JSP:

XML utiliza HTTP como su soporte para el trasnporte.

Una pregunta muy común es cuando usar servlets y cuando usar páginas JSP. La pregunta es lógica, al fin y al cabo ambos mecanismos permiten generar contenidos dinámicos y además las JSP son servlets generados por el servidor de aplicaciones. La norma es que la mayor parte de las interacciones con el usuario se realizarán en las JSP debido a su flexibilidad, ya que integran de forma natural etiquetas HTML, XML, JSF, etc. Los servlets serán la excepción (un ejemplo típico es usar un servlet como controlador (un controlador recibe peticiones o eventos desde el interfaz de cliente y "sabe" el componente que debe invocar).

Podemos considerar que tenemos como cliente una aplicación stand-alone, que puede ser una aplicación Java o incluso un programa en Visual Basic. La aplicación puede acceder directamente a la capa EJB o a la base de datos del EIS (esto último por medio de JDBC):

La plataforma JEE no obliga a usar en un sistema todas las capas. Lo esencial es escoger el mecanismo adecuado para el problema. En este sentido, en ocasiones no hay (ni prevemos que haya) la complejidad como para requerir una capa EJB. Se denomina escenario web-centric porque el contenedor web es el que realiza gran parte del trabajo del sistema:

En este tipo de escenario la capa web implica tanto lógica de presentación como lógica de negocio. Pero lo deseable es no mezclar todas las cosas, planteando un diseño limpio y modular. Para ello las JSP y servlets no suelen acceder de forma directa a la base de datos, sino que lo hacen por medio de un servicio de acceso a datos:

El escenario web-centric es el más ampliamente utilizado actualmente.

Es muy usual utilizar el patrón MVC como patrón arquitectónico. En este patrón ya sabemos que el modelo representa los datos y las reglas de negocio que determinan el acceso y modificación de los datos. La vista traduce los contenidos del modelo a un o unos modos de presentación. Cuando el modelo cambia, es responsabilidad de la vista mantener la consistencia de la presentación. El controlador define el comportamiento de la aplicación, es decir, asocia (map) las peticiones del usuario (captadas por botones, ítems de menú, etc.) con acciones realizadas por componentes del modelo. En una aplicación web las peticiones aparecen como peticiones HTTP que usan normalmente el método POST o GET para invocar a la capa web. El controlador es el responsable de seleccionar la vista que debe responder a la petición realizada por el usuario.

Ya dijimos en el escenario web-centric que en bastantes ocasiones las aplicaciones no requieren acceder a múltiples sistemas empresariales, es decir, la capa de lógica de negocio no requiere fuerte conectividad distribuida con sistemas empresariales. No se contemplan EJBs, pero esto no significa que desaparezcan los componentes del modelo, sino que los servicios del modelo se implementan en JavaBeans (no Enterprise JavaBeans) para ser utilizados por Servlets/JSP dentro de la capa web:

En una aplicación centrada en la capa Web sigue existiendo, aunque sea ligera, un modelo, que contiene entidades y reglas de negocio; es decir, el que no sean necesarios los EJB no implica no modularizar, mezclarlo todo y eliminar los componentes del modelo.

Nota: La especificación JEE no considera como componentes JEE a los Java Beans ya que son diferentes de los EJB (no confundirlos). La arquitectura de componentes JavaBeans se pueden utilizar tanto en la capa de cliente como de servidor, mientras que los componentes Enterprise JavaBeans sólo se utilizan en la capa de negocio como parte de los servicios del servidor.