Desarrollo de Aplicaciones Web con JSP y XML

• Parte IV: Usar los Servicios de J2EE desde JSP
• Introducción a J2EE
• Etiquetas Personalizadas y J2EE
• EJBs
• Beneficios
• Componentes
• Desarrollar EJBs
• EJBs contra Servlets
• ¿Cúando usar EJBs?
• Describir y Referenciar Servicios J2EE
• Variables de Entorno
• Referencias EJB
• Referencias a Factorías de Recursos
• Conclusión

Parte IV: Usar los Servicios de J2EE desde JSP

Java 2 Enterprise Edition (J2EE) es un estándar que define un entorno para el desarrollo y despliegue de aplicaciones empresariales. Reduce el coste y la complejidad del desarrollo de aplicaciones empresariales multi-capa y proporciona un modelo de aplicación distribuida multi-capa. En otras palabras, es enteramente distribuido y por lo tanto, las distintas partes de una aplicacion se pueden ejecutar en diferentes dispositivos.

Las aplicaciones Web desarrolladas usando JavaServer Pages (JSP) podrían requerir alguna interacción con servicios J2EE. Por ejemplo, un sistema de control de inventario basado en Web podría necesitar acceder a servicios de directorio de J2EE para obtener el acceso a una base de datos. O podríamos querer usar JavaBeans Enterprise (EJB) en nuestra aplicación.

Esta página presenta una breve introducción a J2EE, y nos muestra cómo:

• Describir servicios J2EE en un Descriptor de Desarrollo Web (web.xml)
• Referenciar servicios J2EE
• Acceder o usar servicios J2EE desde JSPs

 Introducción a J2EE

J2EE es una plataforma estándar para desarrollar y desplegar aplicaciones empresariales. La arquitectura de J2EE, que está basada en componentes, hace muy sencillo el desarrollo de este tipo de aplicaciones porque la lógica de negocios está organizada dentro de componentes reutilizables y el servicio subyacente lo proporciona el J2EE en la forma de un contenedor por cada tipo de componente. Pensemos en un contenedor como un interface entre el componente y la funcionalidad de bajo-nivel que soporta el componente. Por lo tanto, antes de poder ejecutar un componente de una aplicación cliente, debe configurarse como un servicio J2EE y desplegarse dentro de su contenedor.

En la siguiene tabla se describen brevemente los servicios estándar incluidos en la versión 1.3 de la J2EE specification:

Servicio Estándar	Descripción
HTTP	Define el servicio HTTP donde el API del lado del cliente está definido por el paquete java.net, y el API del lado del servidor está definido por el API Servlet (incluyendo JSP). HTTPS, o el uso de HTTP sobre "Secure Socket Layer" (SSL), está soportado por los mismos APIs del cliente y del servidor que HTTP.
Enterprise JavaBeans (EJBs)	Un modelo de componente para desarrollo empresarial en Java.
Java Transaction API (JTA)	Un interface para componentes de aplicaciones J2EE para manejar transaciones.
RMI-IIOP	Define los APIs que permiten el uso de programación al estilo RMI que es independiente del protocolo subyacente. Las aplicaciones J2EE necesitan usar RMI-IIOP cuando acceden a componentes EJB.
Java IDL	Permite a las aplicaciones J2EE invocar a objetos CORBA usnado el protocolo IIOP.
JDBC	API para acceder a bases de datos.
Java Message Service (JMS)	API para mensajería que soporta punto-a-punto y modelos de publicación por subscripción.
Java Naming and Directory Interface (JNDI)	API para acceder a sistemas de nombres y directorios de recursos J2EE.
JavaMail	Un API estándar para enviar email.
JavaBeans Activation Framework (JAF)	Un API estándar usado por JavaMail.
Java API for XML Parsing (JAXP)	Un API estándar para analizar documentos XML. Incluye soporte para SAX y DOM.
J2EE Connector Architecture	Un API estándar para permitir la conectividad de sistemas legales y aplicaciones empresariales no-Java.
Java Authentication and Authorization Service (JAAS)	Un API estándar para permtiir que los servicios J2EE autentifiquen y fuercen el control de acceso sobre los usuarios.

J2EE promueve el desarrollo de aplicaciones multi-capa en las que el contenedor web almacena componentes web que están dedicados a menejar la lógica de presentación de una aplicación dada, y responden a las peticiones del cliente (como un navegador web). Por otro lado, el contenedor EJB, almacena componentes de aplicación que responden a las peticiones de la capa web como se muestra en la figura 1:

Figura 1: Aplicaciones Multi-capa

Las aplicaciones que usan esta arquitectura son escalables implícitamente. Esta arquitectura separa el acceso a los datos de las interacciones con el usuario final, y se asegura la reutilización del código basado en componentes. En la capa web, J2EE promueve el uso de JSPs para la creacción de contenido dinámico para los clientes web.

 Etiquetas Personalizadas y J2EE

J2EE tiene mucho que ofrecer a los desarrolladores de aplicaciones web y a los desarrolladores de etiquetas JSP personalizadas. Como hemos podido ver de la tabla anterior, tiene un rico conjunto de APIs estándars para enviar email, acceder a bases de datos, analizar documentos XML, etc. Nuestras aplicaciones Web pueden beneficiarse de etos APIs. Por ejemplo, podemos escribir una etiqueta JSP personalizada que envíe email que puede ser facilmente utilizada por desarrolladores de contenido web que no están familiarizados con Java. Si no estás familiarizado con las etiquetas JSP personalizadas, sus beneficios y cómo crerarlas, puedes volver a la página anterior Desarrollar Etiquetas JSP Personalizadas.

 EJBs

Un EJB es un componente del lado del servidor que encapsula la lógica del negocio de una aplicación. En cualquier aplicación, los beans enterprise implementan los métodos de la lógica del negocio, que pueden ser invocados por clientes remotos para acceder a los servicios importantes proporcionados por la aplicación.

 Beneficios

Los EJBs simplifican el desarrollo de grandes aplicaciones empresariales seguras y distribuidas por las siguientes razones:

• Los desarrolladores pueden concentrarse en solventar la lógica del negocio: el contenedor EJB proporciona servicos a nivel del sistema como el control de transaciones y las autorizaciones de seguridad. Por lo tanto, los desarrolladores no tienen que preocuparse de estos problemas.
• Clientes pequeños: Los desarrolladores no tienen que desarrollar código para las reglas de negocio o accesos a bases de datos; pueden concentrarse en la presentación del cliente. El resultado final es que los clientes son pequeños, y esto es especialmente importante para clientes que se ejecutan en pequeños dispositivos con recustos limitados.
• Desarrollo rápido: Los EJBs son componentes portables, y por lo tanto los ensambladores de aplicaciones pueden construir nuevas aplicaciones desde beans existentes. Las aplicaciones resultantes se pueden ejecutar en cualquier servidor compatible J2EE.

 Componentes

Hay dos tipos principales de componentes EJB : session y entity. Un EJB de sesión se usa para realizar una tarea para un cliente, y un EJB de entidad es específico del dominio y se usa para representar un objeto de entidad del negocio que existe en un almacenamiento persistente. Sin embargo, los beans de entidad y de sesión tienen algunas diferencias que podemos ver en la siguiente tabla:

EJB de Sesión	EJB de Entidad
Transitorio	Persistente
Puede ser usado por un sólo cliente.	Puede ser usadopor muchos clientes.
No tiene identidad	Tiene una identidad (como una clave primaria)

 Desarrollar EJBs

Para desarrollar EJBs, todo bean enterprise necesita:

• Un interface remoto que exponga los métodos que soporta bean enterprise.
• Un interface home que proporciona los métodos del ciclo de vida del bean enterprise.
• Una clase de implementación, incluyendo la lógica de negocio que necesite.

 EJBs contra Servlets

A primera vista, los EJBs y los Servlets son tecnologías similares porque ambos son componentes distribuidos del lado del servidor. Sin embargo, hay una diferencia importante entre los dos en el tipo de solución que ofrecen; los EJBs no pueden aceptar peticiones HTTP. En otras palabras, los EJBs no peuden servir peticiones que vienen directamente desde un navegador Web, y los servlets si pueden. Servlets y JSPs se pueden usar para implementar presentación y control web, pero al contrario que los EJBs, no pueden manejar transaciones distribuidas. Los EJBs pueden ser llamados desde cualquier cliente basado en Java.

 ¿Cúando usar EJBs?

Los EJBs son buenos para las aplicaciones que tienen alguno de estos requerimientos:

• Escalabilidad: si tenemos un número creciente de usuarios, los EJBs nos permitirán distribuir los componentes de nuestra aplicación entre varias máquinas con su localización transparente para los usuarios.
• Integridad de Datos: los EJBs nos facilitan el uso de transaciones distribuidas.
• Variedad de clientes: si nuestra aplicación va a ser accedida por una variedad de clientes (como navegadores tradicionales o navegadores WAP), se pueden usar los EJBs para almacenar el modelo del negocio, y se puede usar una variedad de clientes para acceder a la misma información.

 Describir y Referenciar Servicios J2EE

Ahora que hemos visto una introducción a J2EE y los EJBs, veremos cómo referenciar, acceder y usar dichos servicios. Afortunadamente, la especificación J2EE define una forma estándard para y usar sus sevicios. Los servicos J2EE pueden ser referenciados buscándolos de acuerdo a un nombre único en un directorio. Esta funcionalidad está soportada por el "Java Naming and Directory Interface" o JNDI. Para que esto funcione, cada sistema compatible J2EE proporciona un servicio JNDI llamado un environment (entorno) que contiene:

• Variables de entorno
• Referencias a EJBs
• Referencias a Factorías de Recursos

 Variables de Entorno

El entorno de nombrado de los componentes de la aplicación permite que estos componentes sean personalizados sin tener que acceder o modificar el código fuente de dichos componentes. Cada componente de la aplicación define su propio conjunto de entrada de entorno. Todos los ejemplares de un componente de la aplicación dentro del mismo contenedor comparten las mismas entradas. Es importante observar que no está permitido que los ejemplares de los componentes de la aplicación modifiquen su entorno durante la ejecución.

Declarar Variables de Entorno

El proveedor de componentes de la aplicación debe declarar todas las entradas de entorno accedidas desde el código del componente de la aplicación. Se declaran usando la etiqueta <env-entry> en el descriptor de despliegue (web.xml en Tomcat por ejemplo ). Los elementos de la etiqueta <env-entry> son:

• <description>: una descripción opcional de la entrada de entorno.
• <env-entry-name>: el nombre de la entrada de entorno.
• <env-entry-type>: el tipo de variable de entorno esperada. Puede ser uno de los siguientes tipos Java: Boolean, Byte, Double, Character, Float, Integer, Long, Short, String.
• <env-entry-value>: un valor para la entrada de entorno que debe corresponder con el tipo suministrado dentro de <env-entry-type>. Este valor puede modificarse posteriormente, pero si no se seecciona deberá especificarse durante el despliegue.

El código del ejemplo 1 muestra una decalración de dos entradas de entorno. Para especificar una declaración de un nuevo entorno, simplemente los añadimos a nuestro descriptor de apliación Web (web.xml).

Ejemplo 1: Declarar variables de entorno

<env-entry>
<description>welcome message</description>
<env-entry-name>greetings</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>Welcome to the Inventory Control 
   System</env-entry-value>
</env-entry>

<env-entry>
<description>maximum number of products</descriptor>
<env-entry-name>inventory/max</env-entry-name>
<env-entry-type>java.lang.Integer</env-entry-type>
<env-entry-value>27</env-entry-value>
</env-entry>

Cada etiqueta <env-entry> describe una sóla entrada de entorno. Por eso, en este ejemplo, se han definido dos variables de entorno, la primera es una llamada greetings, que es del tipo String y tiene un valor inicial por defecto de: Welcome to the Inventory Control System. La segunda entrada se llama inventory/max, y es del tipo Integer y tiene un valor inicial por defecto de 27.

Ahora, un ejemplar de componente de aplicación puede localizar la entrada de entorno usando JNDI. Crea un objeto javax.naming.InitialContext usando el constructor sin argumentos. Busca el entorno de nombrado a través del InitialContext usando el URL JNDI que empieza con java:comp/env. El ejemplo 2 muestra cómo un componente de aplicación accede a sus entradas de entorno:

Ejemplo 2: Acceder a entradas de entorno

// obtain the application component's environment
// naming context
javax.naming.Context ctx = new javax.naming.InitialContext();
javax.naming.Context env = ctx.lookup("java:comp/env");

// obtain the greetings message 
//configured by the deployer
String str = (String) env.lookup("greetings");

// use the greetings message
System.out.println(greetings);

// obtain the maximum number of products 
//configured by the deployer
Integer maximum = (Integer) env.lookup("inventory/max");
//use the entry to customize business logic

Observamos que el componente de la aplicación también podría usar las entradas de entorno usando los nombres de paths completos, de esta forma:

javax.naming.Context ctx = new javax.naming.InitialContext();
String str = (String) ctx.lookup("java:comp/env/greetings");

Este fragmento de código se puede usar en un JSP como se vé en el Ejemplo 3:

ejemplo 3: Acceder a entradas de etorno desde un JSP

<HTML>
<HEAD>
<TITLE>JSP Example</TITLE>
</HEAD>
<BODY BGCOLOR="#ffffcc">
<CENTER>
<H2>Inventory System</H2>
<%
javax.naming.Context ctx = new javax.naming.InitialContext();
javax.naming.Context myenv = (javax.naming.Context) t.lookup("java:comp/env");
java.lang.String s = (java.lang.String) myenv.lookup("greetings");
out.println("The value is: "+greetings);
%>
</CENTER>

</BODY>
</HTML>

Sin embargo, por último podrías querer acceder a entradas de entorno desde una etiqueta personalizada. Para eso, desarrollaríamos una etiqueta personalizada o una librería de etiquetas que pudiera ser reutilizada sin tener que cortar y pegar el código. Una librería personalizada puede ser fácilmente desarrollada siguiendo los pasos descritos en la página anterior Desarrollar Etiquetas JSP Personalizadas.

 Referencias EJB

Un proveedor de componentes de aplicación puede referirse a los interfaces home EJB usando nombres lógicos (llamados referencias EJB) en lugar de valores de registro JNDI. Estas son referencias espciales en el entorno de nombrado de los componentes de la aplicación. Estas referencias permiten a las aplicaciones Web acceder a los EJBs de una forma personalizada.

Declarar Referencias EJB

Una referencia EJB es una entrada en el entorno del componente de la aplicación. Sin embargo, no se debe usar <env-entry> para declararla. En su lugar, debemos declararla usando la etiqueta <ejb-ref> del descriptor de despliegue web. Los elementos de la etiqueta <ejb-ref> son:

• <description>: Una descripción opcional de la entrada de referencia EJB.
• <ejb-ref-name>: Un nombre único de referencia EJB.
• <ejb-ref-type>: Especifica el tipo esperado del EJB. El valor debe ser Session o Entity.
• <home>: Especifica el nombre completo de la clase del interface home del EJB.
• <remote>: Especifica el nombre completo de la clase del interface remoto del EJB.

El ejemplo 4 muestra una declaración de una entrada de referencia EJB. Para especificar una declaración de una nueva entrada, simplemente la añadimos a nuestro descritor de aplicación web (web.xml).

Ejemplo 4: Declarar una referencia EJB

<ejb-ref>
  <description>A reference to an entity bean to 
    access employee records</description>
 <ejb-ref-name>ejb/EmployeeRecord</ejb-ref-name>
 <ejb-ref-type>Entity</ejb-ref-type>
 <home>com.company.Employee.EmployeeRecordHome</home>
 <remote>com.company.Employee.
EmployeeRecordRemote</remote>
</ejb-ref>

Cada elemento <ejb-ref> describe una sola entrada de referencia EJB. Por lo tanto en este ejemplo, se ha definido una entrada que tiene el nombre ejb/EmployeeRecord del tipo Entity especificando que el interface home es com.company.Employee.EmployeeRecordHome y el interface remote es com.company.Employee.EmployeeRecordRemote.

Ahora, un ejemplar de componente de la aplicación puede localizar la entrada de referencia EJB usando JNDI. Crea un objeto javax.naming.InitialContext usando el constructor sin argumentos. Luego busca el entorno de nombrado a través del InitialContext usando el URL JNDI que empieza con java:comp/env/ejb. El ejemplo 5 muestra cómo un componente de aplicación obtiene el acceso a un EJB:

Ejemplo 5: Acceder a un Bean enterprise

// obtain the default JDNI context
javax.naming.Context ctx = 
new javax.naming.InitialContext();

// look up the home interface
Object obj = ctx.lookup(
"java:comp/env/ejb/EmployeeRecord");

// Convert the object to a home interface
EmployeeRecordHome = (EmployeeRecordHome) 
  javax.rmi.PortableRemoteObject.narrow(
  object, EmployeeRecordHome.class);

Podemos usar un código similar directamente en nuestros JSPs, o desarrollar una etiqueta personalizada para acceder y usar EJBs.

 Referencias a Factorías de Recursos

Las referencias de factorías de recursos permiten a las aplicaciones referirse a factorías de conexiones, o a objetos que crean conexions a recursos deseados, usando nombres lógicos como hemos visto en las dos secciones anteriores. Las referencias a factorías de recursos de conexión pueden ser conexiones JDBC, conexiones JMS, conexiones de email, etc. Las URLs JNDI empiezan con: java:comp/env/jdbc, java:comp/env/jms, y java:comp/env/mail, respectivamente.

Declarar Referencias de Factorías de Recursos

Una referencia a una factoría de recursos es una entrada en el descritor de despliegue de una aplicación web. Debe declararse usando la etiqueta <resource-ref>. Los elementos de esta etiqueta son:

• <description>: un descriptor opcional de la referencia a la factoría de recursos.
• <res-ref-name>: contiene el nombre de la entrada de entorno.
• <res-ref-type>: especifica la factoría de recursos utilizada. Algunas factorías de recursos estándars de J2EE son: javax.sql.DataSource para factorías de conexiones JDBC; javax.jms.QueueConnectionFactory y javax.jms.TopicConnectionFactory para conexiones JMS; y javax.mail.Session para factorías de conexiones JavaMail.
• <res-auth>: especifica el tipo de autentificación de recursos y cómo se debería realizar. Por ejemplo, si se selecciona a Container, el contenedor hace la autentificación usando propiedades configuradas durante el despliegue. Por otro lado, si se selecciona a Application, instruye al contenedor para permitir que la aplicación autentifique programáticamente.

El ejemplo 6 muestra una declaración de una referencia de factoría de recursos email. Para especificar una declaración para una nueva entrada, simplemente la añadimos a nuestro descriptor de aplicación web (web.xml).

Ejemplo 6: Declarar una Referencia de Factoría de Recursos

<res-ref>
 <description>email session reference 
    factory</description>
 <res-ref-name>mail/mailsession</res-ref-name>
 <res-type>javax.mail.Session</res-type>
 <res-auth>Container</res-auth>
</res-ref>

Cada elemento <res-ref> describe una sóla entrada de referencia a una factoría de recursos. Por lo tanto, en este ejemplo se ha definido una entrada con el nombre mail/session del tipo javax.mail.Session seleccionando <res-auth> al Container.

Ahora, un ejemplar de componente de aplicación puede obtener la entrada de referencia a la factoría de recursos usando JNDI. Como con las otras entradas, crea un objeto javax.naming.InitialContext usando el constructor sin argumentos. Luego busca el entorno de nombrado a través del InitialContext usando el URL JNDI para email que empieza con java:comp/env/mail. El ejemplo 7 muestra cómo un componente de aplicación obtiene una referencia a una factoría de recursos para envíar un mensaje de email:

Ejemplo 7: Obtener una Referencia a una factoriía de recursos y enviar un email.

// obtain the initial JNDI context
javax.naming.Context ctx = 
new javax.naming.InitialContext();
// perform JNDI lookup to retrieve 
//the session instance
javax.mail.Session session = 
(javax.mail.Session) 
    ctx.lookup(
"java:comp/env/mail/mailsession");
// create a new message and set the sender,
// receiver, subject, and content of msg
javax.mail.Message msg = new 
     javax.mail.internet.MimeMessage(session);
msg.setFrom("email address goes here");
msg.setRecipient(
Message.RecipientType.TO, "to email address");
msg.setSubject("JavaMail Example");
msg.setContext(
"write the content here", "text/plain");
// send message
javax.mail.Transport.send(msg);

De nuevo, este código puede usarse directamente en nuestros JSPs, o podemos desarrollar una librería de etiquetas personalizada para acceder y utilizar varias referencias a factorías de recursos.

Como otro ejemplo, el ejemplo 8 muestra una declaración de una factoría de recursos de base de datos:

Ejemplo 8: Declarar una Factoría de recursos para bases de datos

<res-ref>
  <description>database reference 
 factory</description>
  <res-ref-name>jdbc/EmployeeDB</res-ref-name>
  <res-type>javax.sql.DataSource</res-type>
  <res-auth>Container</res-auth>
</res-ref>

El ejemplo 9 muestra cómo un componente de aplicación obtiene una referencia a una factoría de conexiones a bases de datos y la usa:

Ejemplo 9: Obtener una referencia a una factoría de conexiones de bases de datos y utilizarla

// obtain the initial JNDI context
javax.naming.Context ctx = 
new javax.naming.InitialContext();
// perform JDNI lookup to 
//obtain database connection factory
javax.sql.DataSource ds = 
(javax.sql.DataSource) 
    ctx.lookup("java:comp/env/jdbc/EmployeeDB");
// Invoke factory to obtain a resource
javax.sql.Connectin conn = ds.getConnection();
// use the connection....

 Conclusión

J2EE ofrece muchos servicios que son importantes para las aplicaciones web. Estos servicios van desde la apertura de conexiones a bases de datos usando JDBC, hasta envíar email, pasando por acceder y usar beans enterprise. Esta página junto con los programas de ejemplo, nos ha mostrado cómo acceder a los servicios J2EE desde dentro de JSPs. La incorporación de EBJs dentro de nuestros JSPs puede hacerse fácilmente, creando una solución reutilizable mendiante el desarrollo de etiquetas personalizadas.

¿Por qué no accedemos a los servicios J2EE desde Servlets? Aunque es posible hacerlo, terminaríamos escribiendo mucho código no reutilizable. Si deseamos usar servicios J2EE desde JSPs, desarrollar librerías de etiquetas personalizadas proporciona una solución reutilizable que incluso puede ser usada por desarrolladores de contenido que no tienen experiencia con Java.