Introducción a los Servlets

Los Servlets son clases de Java que implementan la clase HttpServlet de Java. Dichos servlets no contienen parte gráfica, por lo que su funcionamiento en el momento de recibir una petición no tiene por qué ser dar salida a código HTML en el cliente.
Un servlet se puede definir como un conjunto de acciones capturadas desde un cliente y que pueden derivar en una respuesta http o pueden realizar un flujo de trabajo.
El cliente, mediante el navegador, hace una solicitud al contenedor web, que captura dicha solicitud en un servlet mediante un request.
El servlet puede enviar una respuesta mediante un objeto response, y dicha respuesta puede ser implementada mediante un objeto PrintWriter para devolver código HTML que se generará de nuevo en el cliente.
La llamada a un servlet se debe realizar a través de contenidos estáticos HTML, tales como páginas HTML o jsp.
Las páginas JSP contienen lógica de servidor y lenguaje HTML en un mismo conjunto. Teniendo en cuenta esto, las páginas jsp contienen parte gráfica y lógica de servidor. En realidad, las páginas JSP utilizan un servlet interno al que se accede mediante etiquetas de servidor y que también implementan el diseño HTML. Las páginas JSP son la evolución de los servlets y permiten realizar acciones más dinámicas que un servlet, ya que podemos utilizar la lógica del servidor separada del diseño, pero en un mismo conjunto.

Estructura de un servlet

Los servlets heredan de la clase HttpServlet y sobreescriben el método doPost o doGet, dependiendo de si los datos han sido enviados por el método POST o GET.
Podemos realizar la misma acción tanto para peticiones GET y POST simplemente llamando a doGet desde doPost o viceversa.
Ambos métodos, doPost y doGet, ofrecen dos argumentos:
  • Un objeto HttpServletRequest: Encapsula la petición http
  • Un objeto HttpServletResponse: Encapsula la respuesta HTTP.
El objeto HttpServletRequest nos permite acceder tanto a los datos como a las cabeceras de la petición HTTP.
El objeto HttpServletResponse nos permite modificar la información de salida, como los códigos de estado HTTP o las cabeceras de respuesta.
Además podemos obtener un objeto PrintWriter sobre el que generar el contenido dinámico del documento al cliente.
Los métodos doGet y doPost pueden lanzar las excepciones ServletException e IOexception por lo que deben controlar dichas excepciones, ya sea mediante throws o mediante try-catch.

Clases principales de servlets

Para poder trabajar con servlets, debemos importar los paquetes java.io (para el PrintWriter), javax.servlet (para el HttpServlet) y javax.servlet.http (para el HttpServletRequest y HttpServletResponse).
Los objetos para la definición de servlets se encuentran divididos en dos paquetes: javax.servlet.*, que proporciona clases necesarias para crear servlets genéricos, independientes del protocolo utilizado, y javax.servlet.http.*, que proporciona las clases que definen un servlet específico para el protocolo HTTP.
Servlet define la funcionalidad básica que tiene un servlet como es su ciclo de vida (métodos init, destroy) y procesar requests (método service).
Es implementado por la clase GenericServlet.
SingleThreadModel es una interfaz utilizada para marcar los servlets que se desea que se ejecuten en forma secuencial por requests simultáneos, evitando posibles problemas de procesamiento paralelo.
HttpServlet agrega la funcionalidad para procesar los variados tipos de request HTTP (principalmente los métodos doGet, doPost para procesar formularios GET y POST, respectivamente).
HttpServletRequest proporciona información del request del cliente al servlet a través del protocolo HTTP. Se pueden obtener datos como encabezados, cookies y características genéricas como dirección del cliente y parámetros recibidos desde él (getParameter). Permite también asociar objetos (setAttribute) y acceder al objeto HttpSession.
HttpServletResponse asiste a un servlet para enviar una respuesta al cliente a través de un canal de comunicación binario o de texto (getWriter). Provee también funcionalidad específica para respuestas HTTP como enviar encabezados, cookies (addCookie) y errores con códigos numéricos como 403 (sendError).
HttpSession permite identificar un usuario a través de más de una página, para esto se le asigna un identificador único que se mantiene mientras el usuario navega en el sitio (getId). Permite asignar un tiempo máximo de inactividad y se le pueden asociar objetos para compartir entre servlets (setAttribute y getAttribute).
El código completo de cualquier servlet sería el siguiente:
 
package NOMBREPAQUETE;
import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class NewServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
        processRequest(request, response);
    } 
    @Override
    protected void doPost(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
        processRequest(request, response);
    }
}
 

Métodos de información del servidor con servlets

Los servlets pueden obtener información del servidor, ya sean datos propios del servidor o mediante el envío de información desde un formulario HTML. Tenemos los siguientes métodos:
  • Nombre del servidor: request.getServerName()
  • Número de puerto: request.getServerPort()
  • Software del servidor: getServletContext().getServerInfo()
  • Obtener la dirección IP del cliente: request.getRemoteAddr()
  • Obtener el nombre del cliente Host: request.getRemoteHost()
O mediante formularios HTML por medio de GET como una cadena añadida a la URL o POST:
El método String getParameter("nombreParámetro") devuelve el valor asociado al objeto que se ha denominado como nombreParámetro en la petición. Tenemos que tener en cuenta que se diferencia entre mayúsculas y minúsculas. Devuelve null si no aparece dicho parámetro en la petición.
  • Método getParameterValues("NombreParametros"): devuelve un array de valores. Se utiliza para capturar objetos que forman conjuntos en un formulario, como puede ser un grupo de radiobutton HTML.
  • GetParameterNames( ): devuelve una enumeración de los parámetros de petición sin ningún orden.

Conceptos Básicos en Java

Las ediciones de Java más importantes son:
* Java Standard Edition (Java SE) → Para PC
* Java Micro Edition (Java ME) → Para moviles
* Java Entreprise Edition (Java EE) → Version mas completa
* Java Card → Para tarjetas de credito con chip

Los módulos que forman una aplicación empresarial en Java pueden ser de tres tipos:
  • Archivos JAR (Java Archive): Los archivos JAR permiten agrupar distintos archivos .java en uno solo. Es el empleado para empaquetar componentes EJBs.
  • Archivos WAR (Web Application Archive): Los archivos WAR permiten empaquetar en una sola unidad aplicaciones web completas (servlets, páginas JSPs, contenido estático como imágenes y otros recursos Web).
  • Archivos EAR (Enterprise Application Archive): Los archivos EAR son archivos desplegables en servidores de aplicaciones JEE. Contienen archivos WAR y EJBs empaquetados en ficheros JAR.
Por lo que podemos decir que existen tres tipos de aplicaciones Java EE:
  • Aplicaciones Web JAVA.
  • Objetos distribuidos EJBs.
  • Aplicaciones empresariales que engloban a las dos anteriores, aplicaciones web JAVA y objetos distribuidos EJBs
La interfaz de programación de aplicaciones, abreviada como API (del inglés: Application Programming Interface), es el conjunto de subrutinas, funciones y procedimientos (o métodos, en la programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción.
Las clases en las APIs de Java se organizan en grupos distintos llamados paquetes.
Cada paquete contiene un conjunto de interfaces, clases y excepciones relacionadas con el entorno de trabajo.
 
Vamos a visualizar algunos de los servicios que provee Java EE(Enterprise Edition) y que podemos emplear en cualquier servidor de aplicaciones que siga este estándar.
  • Java Transaction API (JTA): Consta de dos partes y define las interfaces entre el manejador de transacciones y las partes involucradas en un sistema de transacciones distribuido, el manejador de recursos, el servidor de aplicaciones y las aplicaciones transaccionales.
  • Java Persistente API (JPA): Para dotar de persistencia a objetos del lenguaje.
  • Java Message Service (JMS): Sistema de mensajería, permite mensajes punto a punto y sistemas publicado suscrito.
  • Java Naming Direct Interface (JNDI): Sistema de nombrado para localizar recursos o componentes de proveedores.
  • JavaMail: Para manejo de correo electrónico.
  • Java Beans Active Framework (JAF): Manejo de datos en diferentes tipos mime, ligado al uso del correo.
  • Java API for XML Processing (JAXP): Soporte para el manejo de XML.
  • Java EE Connector Arquitectura: Permite el acceso a otro tipo de sistemas de información empresarial por medio del desarrollo de un pluggin, similar a los conectores JDBC.
  • Java Autentícation and Authorization Service (JAAS): Provee servicios de seguridad de autenticación y autorización.
  • Servicios Web (JAX-WS): Para manejo de servicios web.

Introducción a los Servidores de Aplicaciones

Como consecuencia del éxito del lenguaje de programación Java, el término servidor de aplicaciones hace referencia a un servidor de aplicaciones Java EE.
Algunos servidores certificados de JEE son los siguientes:
  • JOnAS: servidor de aplicaciones de código abierto de ObjectWeb
  • JBoss: desarrollado inicialmente por JBoss Inc y adquirido posteriormente por Red Hat. Existe una versión de código abierto soportada por la comunidad y otra empresarial.
  • Sun Java System Application Server Platform Edition 9.0: Es un servidor basado en GlassFish.
  • Oracle WebLogic Application Server 10.0: antes conocido como BEA Systems.
  • Servidor de Aplicaciones SAP NetWeaver, Java EE 5 Edition de SAP
  • JEUS 6, un Servidor de aplicaciones específico de Linux de TmaxSoft
  • Apache Gerónimo 2.0
  • IBM WebSphere Application Server Community Edition 2.0: basado en el servidor Apache Gerónimo
  • Oracle Containers for Java EE 11
  • GlassFish: un servidor de aplicaciones de código abierto de Sun
  • Apache OpenEJB vía Apache Gerónimo


Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces. Un patrón de diseño resulta ser una solución a un problema de diseño.
Los patrones de diseño se pueden dividir en tres grandes categorías basadas en su propósito, que a su vez cada una se divide en patrones de Clases y Objetos:
  • Creacionales: Los patrones creacionales tratan con las formas de crear instancias de objetos. Usan la herencia (extends).
  • Estructurales: Los patrones estructurales describen como las clases y objetos pueden ser combinados para formar grandes estructuras y proporcionar nuevas funcionalidades. Estos objetos insertados pueden ser incluso objetos simples u objetos compuestos.
  • Comportamiento: Los patrones de comportamiento ayudan a definir la comunicación y relación entre los objetos de un sistema. El propósito de este patrón es reducir el acoplamiento entre los objetos.


Modelo Vista Controlador (MVC)

En este tipo de arquitectura conocida, el cliente hace Request(solicita) a objetos de la capa de presentación (Pagina del servidor), que luego llama a su código controlador para pedirle funcionalidad, que crea una presentación como Response(respuesta) a esa solicitud.
En los frameworks MVC, las URLs se mapean directamente a clases, estas son denominadas "Controladoras" y son las que procesan los Request entrantes, manejando las entradas del usuario, sus interacciones y ejecutando la lógica apropiada para el proceso. Una clase controladora llama a una vista, la cual genera la salida HTML que se enviará como Response.
El modelo MVC permite diseñar en tres capas de negocio y no poner todo el código en las interfaces de usuario de tu sistema (IU):
Capa de presentación: Con nuestras Interfaces (páginas HTML.) y sus controles visuales (controles de formulario) junto con sus eventos.
Capa de negocio: Lógica del dominio. Aquí irá todo el código que define las reglas de negocio (cálculos, validaciones). Surge de los procesos que hemos encontrado en el análisis.
Capa de acceso a datos: El código que permite acceder a las fuentes de datos. Esencialmente trata sobre 4 operaciones básicas, llamadas CRUD (por Create-Retrieve-Update y Delete), que se realizan sobre cualquier fuente de datos.
El modelo de arquitectura Model-View-Controller (MVC) separa una aplicación en tres componentes principales: el modelo, la vista y el controlador:
Modelos. Los objetos de modelo recuperan y almacenan el estado del modelo en una base de datos. Por ejemplo, un objeto Product podría recuperar información de una base de datos, trabajar con ella y, a continuación, escribir la información actualizada en una tabla Productos de una base de datos.
Vistas. Las vistas son los componentes que muestra la interfaz de usuario de la aplicación. Normalmente, esta interfaz de usuario se crea a partir de los datos de modelo.
Controladores. Los controladores son los componentes que controlan la interacción del usuario, trabajan con el modelo y por último seleccionan una vista para representar la interfaz de usuario.

Comunicación Síncrona y Asíncrona

Síncrona. Quien envía permanece bloqueado esperando a que llegue una respuesta del receptor antes de realizar cualquier otra tarea.

Asíncrona. Quien envía continúa con su ejecución inmediatamente después de enviar el mensaje al receptor.

La mayoría de las aplicaciones Web existentes realizan la comunicación de datos con el servidor de manera síncrona. En una comunicación síncrona, se ejecutan los procesos en el siguiente orden:
  1. El cliente realiza una petición al servidor.
  2. El servidor envía los datos solicitados y el cliente comienza a recibir los datos.
  3. Una vez finalizada la recepción de los datos en la página, el usuario vuelve a tener el control.
Este proceso conduce a que cada vez que se está enviando más información al servidor, el usuario pierde el control sobre la página Web que está visitando, limitándose de esta manera a esperar que la aplicación le devuelva el control.
En una aplicación Web que se comunica asíncronamente con el servidor, los procesos son los siguientes:
  1. El cliente realiza una solicitud al servidor.
  2. El servidor envía los datos solicitados
  3. El cliente comienza a recibir los datos.
El cliente en ningún momento pierde el control de las acciones sobre la página que está visualizando y permite acciones con el usuario durante la devolución de los datos.

La tecnología más importante dentro de las llamadas asíncronas es AJAX.

AJAX. Acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML). Ajax no es una tecnología, es el conjunto de muchas tecnologías (XHTML, CSS, DOM, XML, XSLT, XMLHttpRequest, JavaScript, Jquery). Dichas tecnologías se ejecutan en el navegador de los usuarios y mantiene comunicación asíncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre la misma página sin necesidad de recargarla. En aplicaciones AJAX se pueden enviar peticiones al servidor web para obtener solamente la información necesaria y así ahorrar ancho de banda. Su desventaja sería que el cargar la página inicial, el proceso es más lento, debido a que primero tiene que cargar todo el código JavaScript y XML que hará la implementación. Las acciones de la tecnología Ajax se ejecutan en el cliente, es decir, en el navegador del usuario, y mantiene comunicación asíncrona con el servidor en segundo plano. Las tecnologías que forman AJAX son:
  • XHTML y CSS, para crear una presentación basada en estándares.
  • DOM, para la interacción y manipulación dinámica de la presentación.
  • XML, XSLT y JSON, para el intercambio y la manipulación de información.
  • XMLHttpRequest, para el intercambio asíncrono de información.
  • JavaScript, para unir todas las demás tecnologías.

Capas de arquitectura JEE

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 componentes que son parte del diseño web y su lógica en el cliente (HTML, JavaScript, css, etc.).
  • Capa Web. Intermediario entre el cliente y otras capas. Sus componentes principales son los servlets y las páginas 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.

Empaquetado de aplicaciones JEE

Existen tres tipos de empaquetados dentro de las aplicaciones JEE:

*Archivos JAR (Java Archive)

Características:
  • Permiten empaquetar diferentes archivos de java en uno solo.
  • Siguen el formato ZIP
  • Fueron incorporados en la versión 1.1 del JDK
  • Contienen clases Java y recursos que utilizan dichas clases
  • Es el empleado para empaquetar componentes EJBs respetando su estructura de directorios.

*Archivos WAR (Web Application Archive)

Características:
  • Permiten empaquetar en una sola unidad aplicaciones web java completas
  • Pueden empaquetar los siguientes elementos:
    • Java Server Pages (JSP)
    • Servlets
    • Contenido estático como css, HTML o imágenes
    • Otros recursos web

*Archivos EAR (Enterprise Application Archive)

Características:
  • Archivos desplegables en servidores de aplicaciones J2EE.
  • Contienen los siguientes elementos:
    • Archivos War
    • EJBs empaquetados dentro de ficheros jar
Una aplicación JEE se empaqueta en un archivo .ear que no es nada mas que un jar normal y corriente.
Debe contener obligatoriamente una carpeta META-INF y un fichero application.xml donde estará toda la meta-información, como su propio nombre indica.
Módulos web: ficheros .war que contienen la capa web
Módulos EJB: que contiene ficheros .jar.
Módulos de adaptadores de recursos
En la práctica, casi todo se reduce a un módulo war y pocos elementos más.
La estructura de un módulo web (empaquetado .war) es la siguiente:
/Raiz
/Raiz/WEB-INF
/Raiz/WEB-INF
/Raiz/WEB-INF/lib
/Raiz/WEB-INF/classes
/Raiz/WEB-INF/tags
El directorio Raíz contiene todos los archivos estáticos (HTML, gráficos, jsp, y los recursos estáticos de cualquier web)
El directorio WEB-INF debe contener un archivo web.xml que es la información que contendrá la meta-información de el archivo war.
El directorio WEB-INF/lib contiene las librerías de código .jar
El directorio WEB-INF/classes contendrá las clases compiladas
El directorio WEB-INF/lib contendrá las etiquetas personalizadas


Tecnologías en J2EE
La tecnología Enterprise JavaBeans (EJB) usa un modelo de componente para simplificar el desarrollo de aplicaciones de middleware (capas) con soporte automático de servicios como transacciones, seguridad y conectividad de base de datos.
*JavaMail es una API que proporciona una serie de clases abstractas que modelan un sistema de correo.
*Java Message Service (JMS) es una API que permite el desarrollo de aplicaciones portables y basadas en mensajes para la plataforma Java.
*JavaServer Faces (JSF) proporciona un modelo de programación que ayuda a crear aplicaciones Web.
*JavaServer Pages (JSP) permite que desarrolladores Web desarrollen rápidamente y mantengan fácilmente páginas Web dinámicas.
*Standard Tag Library for JavaServer Pages (JSTL) es un conjunto de etiquetas personalizadas que habilitan varias funciones comunes de Web sites en un formato estandarizado.
*Los Java Servlets amplían y mejoran el alcance de los servidores Web al proporcionar un método basado en componentes e independiente de plataforma para crear aplicaciones basadas en la Web sin las limitaciones de rendimiento de los programas CGI.
*La API Java Transaction (JTA) es una API de alto nivel, independiente de implementación y de protocolo que permite que aplicaciones y servidores de aplicaciones accedan a transacciones Java Transaction Service(JTS) especifica la implementación de un gestor de transacciones que soporta JTA e implementa la correlación entre Java y la especificación OMG.
Los componentes de software son unidades binarias de producción, adquisición y despliegue independientes, que al interactuar, forman un sistema en funcionamiento.
Un componente puede tener varias interfaces, una por cada punto de acceso: uso, administración y configuración.
Los componentes más utilizados podemos diferenciarlos entre los siguientes
  • Enterprise JavaBeans y el modelo de componentes de Java EE
  • La estructura de componentes de .NET
Un contenedor es un proceso donde se ejecutan los componentes.
Cuando un desarrollador crea un modelo de arquitectura basado en la plataforma JEE, debe especificar los siguientes elementos en el contenedor:
  • Los componentes de la aplicación
    • Servlets
    • JSPs (Java Server Pages)
    • EJBs (Enterprise Java Beans)
  • Los descriptores de despliegue
    • Ficheros XML que describen los componentes de la aplicación

Envío de información request y response HTTP

Una aplicación web es una aplicación que trabaja en un servidor y sobre la que un usuario accede desde un cliente general, como por ejemplo un navegador en un PC, un teléfono móvil o una PDA.
La comunicación en la Web gira en torno al protocolo http y sus características son las siguientes:
  • Protocolo de nivel de aplicación
  • Funciona sobre TCP
  • Usa el puerto 80 por defecto
  • Modelo petición/respuesta (request/response)
  • No tiene estado
  • Al igual que SMTP, es un protocolo ASCII, que usa MIME para transferir información no ASCII.
  • Tipos de peticiones: GET, POST, PUT, DELETE, TRACE, OPTIONS, HEAD

El formato estándar para peticiones http con el método get es la siguiente:

URL?dato1=valor1&dato2=valor2 ... &datoN=valorN
Debemos tener en cuenta los siguientes parámetros al enviar caracteres en el valor de un parámetro:
  • Caracteres ASCII alfanuméricos y signos. (punto), - (guión), * (asterisco) y _ (subrayado) son literales.
  • Debemos sustituir los espacios en blanco por el símbolo +.
  • Resto de caracteres son admitidos
Si un valor aparece repetido más de una vez en la cadena del envío, el parámetro correspondiente es recibido como un vector de valores. dato[0], dato[1], dato[2]

Modelos Enterprise Java Beans (EJB)

Un Bean es un componente software que tiene la particularidad de ser reutilizable y así evitar la tediosa tarea de programar los distintos componentes de nuevo. Se puede decir que existen con la finalidad de ahorrarnos tiempo al programar.
Un Bean se puede representar desde un botón, un grid de resultados, un panel contenedor o un simple campo de texto, hasta otras soluciones mucho más complejas como conexiones a bases de datos, etc.
Las EJB ofrecen numerosos Beans para Java.
Enterprise Java Beans (EJB) es una plataforma para construir aplicaciones de negocio portables, reutilizables y escalables usando el lenguaje de programación Java.

El contenedor EJB es un programa Java que trabaja en el servidor y que contiene todas las clases y objetos necesarios para el correcto funcionamiento de los EJBs.
El contenedor de componentes EJB está formado tanto por los beans como por los descriptores de despliegue que comunican nuestro trabajo con el contenedor. 
Un descriptor de despliegue se define mediante un fichero XML (descriptor del despliegue, deployment descriptor) en el que se definen todas las características del bean o con anotaciones.
Un descriptor de despliegue ofrece la información del componente a nuestro contenedor EJB y a nuestro entorno de trabajo (bases de datos, arquitectura de la aplicación, etc.).
 
Ejemplo de descriptor de despliegue web.xml:

 

Existen tres tipos de beans definidos, cada uno implementa unas características diferentes y permiten ser combinados entre si:

- Beans de Sesión (Session Beans)

En una aplicación típica, dividida en grandes capas (presentación, lógica de negocio, persistencia y base de datos), los Beans de Sesión viven en la lógica de negocio.
Hay dos grandes tipos de Beans de Sesión:

  • Stateless (sin estado)
  • Stateful (con estado)
Stateless no conserva el estado de ninguno de sus atributos de la invocación de un método a otro.
Stateful conserva el estado a lo largo de toda una sesión. Los Beans de Sesión Stateless son los únicos que pueden exponerse como servicios web.
 

- Message-Driven Beans (MDBs)

Viven en la lógica de negocio y los servicios que proveen son parecidos a los Beans de Sesión, con la diferencia de que los MDBs son usados para invocar métodos de forma asincrónica.
Cuando se produce la invocación de un método de un MDB desde un cliente, la llamada no bloquea el código del cliente y el mismo puede seguir con su ejecución, sin tener que esperar indefinidamente por la respuesta del servidor.
El sistema de mensajería asincrónica propone la utilización de una capa intermedia en la comunicación entre el creador y el consumidor del mensaje. En EJB 3, esta capa se llama MOM (Message-oriented Middleware). Básicamente, MOM es un software que permite funcionar como servidor de mensajería, reteniendo los mensajes del productor y enviándolos posteriormente al consumidor en el momento en que esté disponible para recibirlo.


- Beans de Entidad (Entities)


Existen dos tipos BMP y CMP según se gestione la persistencia por parte del bean o del contenedor. Los EJB de entidad están directamente relacionados con los datos de la aplicación, son objetos que mantienen en memoria los datos que maneja la aplicación, las entidades que disponen de persistencia. Los Beans de Entidad normalmente mapean (mantienen una relación en memoria) las tablas de una base de datos relacional, aunque también es posible que mantengan la persistencia de los datos en ficheros, como por ejemplo un xml.


Para poder configurar correctamente un Bean, debemos indicar al contenedor de EJB qué servicios debe proveer a nuestro Bean, y para ello disponemos de los descriptores de despliegue o de las anotaciones en las clases bean. 
 

Anotaciones básicas para los Session Beans

Vamos a visualizar las anotaciones básicas para los Session Beans.

@Stateful

Indica que el Bean de Sesión es con estado. Sus atributos son:
name: por defecto es el nombre de la clase pero se puede especificar otro nombre diferente.
mappedName: Indica si deseamos que el contenedor maneje el objeto de forma específica. Si incluimos esta opción nuestra aplicación podría no ser portable y no funcione en otro servidor de aplicaciones.
description: Indica la descripción de la anotación.

@Stateless

Indica que el Bean de Sesión es sin estado. Sus atributos son:
name: Por defecto el nombre de la clase pero se puede especificar otra diferente.
mappedName: Si deseamos que el contenedor maneje el objeto de manera específica. Al igual que @StateFul esta opción podría hacer que nuestra aplicación no sea portable y no funcione en otro servidor de aplicaciones.
Description: descripción de la anotación.

@Init

Especifica que el método se corresponde con un método create de un EJBHome o EJBLocalHome de EJB 2.1.
Sólo se podrá llamar una única vez a este método. Sus atributos son:
Value: indica el nombre del correspondiente método create de la interfaz home adaptada. Sólo se debe utilizar cuando se utiliza el bean anotado con un bean con estado de la especificación 2.1 o anterior y que disponga de más de un método create.

@Remove

Indica que el contenedor debe llamar al método cuando quiera destruir la instancia del Bean. Sus atributos son:
retainIfException: indica si el Bean debe mantenerse activo si se produce una excepción. Por defecto su valor es false.
@Local
Indica que la interfaz es local.

@Remote


Indica que la interfaz es remota.

@PostActivate

Invocado después de que el Bean sea activado por el contenedor.

@PrePassivate

Invocado antes de que el Bean esté en estado passivate.

Normalmente las anotaciones más empleadas en las aplicaciones serán @Stateless y @Stateful, para indicar el tipo de EJB que estemos utilizando. El resto de anotaciones se utilizarán en casos más particulares.


Roles de EJB dentro de las aplicaciones JEE

La especificación Enterprise JavaBeans está escrita para diferentes públicos, pero podría resumirse en dos niveles diferentes:

El desarrollador del cliente

Un cliente es cualquier usuario de un Enterprise JavaBean y podría ser cualquier aplicación Java del lado del cliente, un servlet o incluso otro EJB.
El desarrollador EJB
La principal responsabilidad del programador de un bean será escribir la lógica de empresa y acciones o propiedades:
  - Deben crearse archivos de clase primarios y un descriptor xml o bien, incluir anotaciones en las clases del bean. Todos estos archivos estarían empaquetados en un JAR.
  - Podríamos tener muchos beans dentro de un único archivo JAR, pero cada archivo JAR contendría únicamente un descriptor del bean xml.
  - El descriptor de implementación debe situarse en un directorio llamado META- INF y no podemos cambiarle el nombre, sigue una especificación estándar.


Estructura de EJB

Todo EJB está compuesto por dos capas.

  • Capa Interfaz
La capa Interfaz es un contrato que indica a las clases que consuman en el EJB los métodos y características de dicho EJB.

  • Capa Implementación
La capa de implementación es una clase que implementa la capa de Interfaz.
Una clase que hereda directamente de la interfaz del EJB e implementa los métodos que se hayan incluido en el contrato.

Custom Tags

Un Custom Tag es una etiqueta propia, personalizada, cuyo objetivo será no utilizar código java en las páginas JSP. Se necesitan múltiples ficheros para trabajar: XML y JSP
Definición de etiquetas:
  • Archivo tld es el archivo de definición de las etiquetas Custom Tags
  • Debemos indicar las características de etiquetas que habrá en todo mi proyecto.
  • El fichero Xml es la descripción de nuestro sitio web
  • El fichero class es la clase con la lógica java
  • El fichero JSP es la página para mostrar las etiquetas Custom tags.
Necesitamos un fichero descriptor de la estructura de etiquetas que contenga una serie de argumentos obligatorios para trabajar:
  • Tlibversion: Versión de la librería
  • Jspversion: Versión del jsp
  • Shortname: El nombre del programador
  • Tagclass: Nombre del paquete, nombre de la clase
  • Bodycontent: Contenido del cuerpo, si no existe contenido, se pondrá Empty
Ejemplo de tld:
<taglib>
        <tlibversion>1.0</tlibversion>
        <jspversion>2.0<jspversion>
        <shortname>Programeitor<shortname>
        <tag>
                <name>nombreetiqueta</name>
                <tagclass>nombre del paquete y de la clase</tagclass>
                <bodycontent>Es el contenido del cuerpo</bodycontent>
        </tag>
</taglib>
 
EJEMPLO 1: 
1.Abrimos NetBeans y creamos un nuevo proyecto Java Web llamado ProyectoCustomTags y eligiendo el servidor Apache Tomcat
2.Sobre la carpeta WEB-INF nos crearemos una nueva carpeta que llamaremos FolderTLD
3.Sobre la carpeta FolderTLD agregamos un objeto Tag Library Descriptor y lo llamaremos mensaje
  NewFile > Other > Web >TagLibraryDescriptor
  Escribiremos el siguiente código dentro del fichero mensaje.tld:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE taglib PUBLIC 
  "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.1//EN" 
  "http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd"> 
<taglib>
 <tlibversion>1.0</tlibversion>
 <jspversion>2.0</jspversion>
 <shortname>mensaje</shortname>
 <tag>   
  <name>primera</name>
  <tagclass>paquetecustomtags.PrimeraEtiqueta</tagclass>
                <bodycontent>empty</bodycontent>
 </tag>
</taglib>
4.Crearemos una clase llamada PrimeraEtiqueta dentro de un paquete que se llamará paquetecustomtags
  Implementamos el siguiente código dentro de la clase para, posteriormente, representarlo en una página JSP:
package paquetecustomtags;

import java.io.IOException;
import javax.servlet.jsp.*;
import javax.servlet.jsp.tagext.TagSupport;
import java.util.*;
import java.text.*;

public class PrimeraEtiqueta extends TagSupport  {
    
    @Override
    public int doStartTag() throws JspTagException
    {
        return SKIP_BODY;
    }

    @Override
    public int doEndTag() throws JspTagException
    {
        String horaactual = this.GetHora();
        try
        {
            JspWriter out = pageContext.getOut();
            out.write("<h1>Bienvenido a mi pagina Custom Tags</h1>");
            out.write("El nombre de mi clase es: ");
            out.write(getClass().getName());
            out.write("<br> y la hora es " + horaactual + "<p/>");
        }catch (IOException ex)
        {
throw new JspTagException("Excepcion al cargar el fichero TLD " +ex.toString());      
}
        return  EVAL_PAGE;
    }

    private String GetHora()
    {
            Date horaactual;
            DateFormat formato;
            String cadhora;
            horaactual= Calendar.getInstance().getTime();
            formato= DateFormat.getTimeInstance();
            cadhora=formato.format(horaactual);
            return cadhora;
    }
}
5.Ahora debemos irnos al descriptor de la aplicación web y seleccionamos el fichero web.xml dentro de la 
  carpeta WEB-INF:
  Si no existe puede crearse en NewFile > Other > Web > StandardDeploymentDescriptor
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web
Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
 <welcome-file-list>
  <welcome-file>index.jsp</welcome-file>
 </welcome-file-list>
 <taglib>
            <taglib-uri>mietiquetacustomtag</taglib-uri>
            <taglib-location>/WEB-INF/FolderTLD/mensaje.tld</taglib-location>
   </taglib>
</web-app>
6.Escribiremos el siguiente código en la página index.jsp para realizar la llamada a la librería Custom Tags 
  que hemos creado:
<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">
<%@taglib uri="mietiquetacustomtag" prefix="MiEtiqueta" %>
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <title>JSP Page</title>
    </head>
    <body>
        <h1>Pagina realizada con Custom Tags</h1>
        <MiEtiqueta:primera/>
    </body>
</html>
-------------------------------------------------------------------------------------------------------------
------------Realizar una página JSP que mostrará una tabla con los datos de los departamentos----------------
1.Creamos un nuevo proyecto Web Application llamado AplicacionCustomTags con servidor Apache Tomcat
2.Sobre la carpeta WEB-INF, nos crearemos una nueva carpeta que llamaremos EtiquetasDEPT.
4.Sobre la carpeta EtiquetasDEPT vamos a agregar un objeto Tag Library Descriptor de la carpeta Web y lo 
  llamaremos etiquetadepartamentos
5.Escribiremos el siguiente código dentro del fichero etiquetadepartamentos.tld:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE taglib PUBLIC 
  "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.1//EN" 
  "http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd"> 
<taglib>
 <tlibversion>1.0</tlibversion>
 <jspversion>2.0</jspversion>
 <shortname>etiquetadepartamentos</shortname>
 <tag>   
  <name>tabladepartamentos</name>
  <tagclass>paquetecustomtags.EtiquetaTablaDept</tagclass>
                <bodycontent>empty</bodycontent>
 </tag>
</taglib>
6.Nos crearemos una clase para poder implementar el código de la etiqueta que acabamos de realizar.

Crearemos la clase en un paquete llamado paquetecustomtags y le pondremos de nombre EtiquetaTablaDept.

Lo que debemos realizar ahora es el acceso mediante JDBC a la tabla EMP de Oracle. Para ello, debemos agregar dentro de la carpeta Libraries el conector JDBC para Oracle.

A continuación, implementaremos el código de la clase EtiquetaTablaDept

 
package paquetecustomtags;
import java.io.IOException;
import javax.servlet.jsp.*;
import javax.servlet.jsp.tagext.TagSupport;
import java.util.*;
import java.text.*;
import java.sql.*;


public class EtiquetaTablaDept extends TagSupport   {
    @Override
    public int doStartTag() throws JspTagException
    {
        return SKIP_BODY;
    }

    @Override
    public int doEndTag() throws JspTagException
    {
        try
        {
            JspWriter out = pageContext.getOut();
            DriverManager.registerDriver(new oracle.jdbc.OracleDriver());
            Connection cn = DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE", "SYSTEM", "12345");
            Statement sentencia = cn.createStatement(); //(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY);
            ResultSet rs = sentencia.executeQuery("SELECT * FROM DEPT");
            out.write("<h1>Datos de los departamentos</h1>");
            String tabla = "<table border='1'>";
            tabla += "<tr><th>Numero</th><th>Nombre</th><th>Localidad</th></tr>";
            while (rs.next())
            {
                tabla += "<tr>";
                tabla += "<td>"+rs.getString(1)+"</td>";
                tabla += "<td>"+rs.getString(2)+"</td>";
                tabla += "<td>"+rs.getString(3)+"</td>";
                tabla += "</tr>";
            }
            tabla += "</table>";
            out.write(tabla);
        }catch (Exception ex)
        {
            throw new JspTagException("Excepcion al cargar el fichero TLD " +ex.toString());
        }
        return  EVAL_PAGE;
    }
}
Ahora debemos irnos al descriptor de la aplicación web.  
Seleccionamos el fichero web.xml dentro de la carpeta WEB-INF y escribimos lo siguiente:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web
Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
    <welcome-file-list>
        <welcome-file>index.jsp</welcome-file>
    </welcome-file-list>
    <taglib>
        <taglib-uri>mietiquetacustomtag</taglib-uri>
        <taglib-location>/WEB-INF/EtiquetasDEPT/etiquetadepartamentos.tld</taglib-location>
    </taglib>
</web-app>
 

Ahora vamos a agregar una pagina JSP que dibujará los empleados que tenemos en la etiqueta Custom Tag.

Le daremos el nombre tabladepartamentos

Implementamos el código para dibujar los departamentos.

 
<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">
<%@taglib uri="mietiquetacustomtag" prefix="tagdept" %>
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <title>JSP Page</title>
    </head>
    <body>
        <tagdept:tabladepartamentos/>
    </body>
</html>