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.