Enrique continua la serie de articulos sobre EJB, esta vez se adentra en el codigo y muestra como programar un StateLess Session Bean con las opereciones de una calculadora.
Juan Carlos explica todo lo que hay que saber sobre el examen de certificiacion SCJP1.4. De obligada lectura si esta pensando presentarte al examen.
Por ultimo, Martín Córdova nos eneseña todo lo necesario para instalar y configurar SAPDB 7.4, una base de datos relacionar que quizas muchos de vosotros utiliceis como soporte de persistencia en las aplicaciones java.
Copyright (c) 2003, Eneko Gonz�lez Benito. Este documento puede ser distribuido solo bajo los t�rminos y condiciones de la licencia de Documentaci�n de javaHispano v1.0 o posterior (la �ltima versi�n se encuentra en /licencias/).
Introducci�n
Todos, tarde o temprano, cometemos errores en nuestra programaci�n, que derivan en excepciones que son lanzadas en tiempo de ejecuci�n. En el caso de las p�ginas Java de servidor (JSP), existe una forma bastante simple, potente y a la vez elegante, de depurar dichas excepciones.
Para ello, vamos a hacer uso de dos directivas de p�gina, errorPage e isErrorPage, que vamos a explicar a continuaci�n.
Lanzando la excepci�n.
Para poder tratar la excepci�n lanzada en un fichero JSP, necesitamos indicar en dicho JSP la URL del fichero que va a realizar el tratamiento de dicha excepci�n. Para ello, utilizaremos la directiva errorPage. Por ejemplo, el siguiente c�digo indica que la excepci�n ser� tratada en el fichero /error.html
<%@ page errorPage = "error.html">
Antes de continuar, vamos a explicar para que sirve esa l�nea. Supongamos que tenemos un JSP llamado index.jsp[1] que contiene, entre otras, las siguientes l�neas:
<%@ page errorPage = "error.html"%> ... El n�mero recibido es <%=Integer.parseInt(request.getParameter("numero"))%>. ...
Supongamos, adem�s, que el contenido del fichero error.html es el siguiente:
<BR> Algo ha fallado <BR>
En el caso de que se produzca una excepci�n en el c�digo del fichero index.jsp, el servidor redirigir� la petici�n al fichero error.html en el punto en que haya ocurrido la excepci�n. Esto es, si la excepci�n ha ocurrido en la instruccion Integer.parseInt(), el resultado de la petici�n, que al fin y al cabo es lo que ve el usuario, ser� el siguiente:
El n�mero recibido es <BR> Algo ha fallado <BR>
En el siguiente gr�fico podemos ver f�cilmente el flujo que ha seguido el servidor para generar la respuesta.
Recogiendo la excepci�n.
Lo que hemos visto hasta ahora, no es demasiado �til, ya que solo podemos mostrar un mensaje diciendo que ha habido un error, pero poco mas. Sin embargo, �que ocurre si, en vez de lanzar las excepciones al fichero error.html, lo hacemos al fichero error.jsp[2]? El resultado es el mismo, salvo que el fichero error.jsp va a ser ejecutado como cualquier otro JSP, lo que nos da la posibilidad de hacer m�s cosas.
Para poder recoger la excepci�n, el fichero error.jsp debe incluir la directiva siguiente:
<%@ page isErrorPage = "true"%>
Ahora ya podemos recoger la excepci�n desde nuestro nuevo fichero, y mostrarla por pantalla. Para eso, el fichero JSP tiene instanciado un objeto llamado exception, de la clase java.lang.Exception, que contiene dicha excepci�n. As� pues, mostrarla por pantalla es tan f�cil como incluir en el fichero error.jsp el siguiente c�digo:
<%@ page isErrorPage = "true"%>
<% if (exception != null) { %> La excepci�n causante del error ha sido: <% exception.printStackTrace(new java.io.PrintWriter(out)); %> <% } // del if%>
Rizando el rizo.
Ahora ya sabemos, de una manera f�cil, la forma de conocer la excepci�n que ha ocurrido en nuestro programa. A continuaci�n, vamos a ver como, a�adiendo un poco m�s de c�digo a nuestro JSP, podemos mostrar gran cantidad de informaci�n �til para depurar la causa de la excepci�n.
Atributos del objeto Request: El objeto request contiene gran cantidad de informaci�n sobre la petici�n que se ha hecho al servidor, como el m�todo usado (get/post), la IP del cliente, etc. Afortunadamente, el objeto request tiene un m�todo llamado getAttributeNames() que devuelve un objeto de la clase java.util.Enumeration con el nombre de todos los atributos del objeto. As�, para obtener toda la informaci�n de dicho objeto, podemos utilizar el siguiente c�digo:
<% java.util.Enumeration enum; String atributo;
enum = request.getAttributeNames(); // Leemos todos los atributos del request
while (enum.hasMoreElements()) {
atributo = (String) enum.nextElement(); %> <%=atributo%> = <%=request.getAttribute(atributo)%> <BR> <% } // del while %>
Par�metros: Adem�s de los atributos anteriores, es muy interesante saber qu� par�metros ha recibido el JSP a trav�s del objeto request. La manera m�s sencilla de mostrarlos todos es muy similar a la anterior:
<% java.util.Enumeration enum; String parametro;
enum = request.getParameterNames(); // Leemos todos los par�metros recibidos
while (enum.hasMoreElements()) {
parametro = (String) enum.nextElement(); %> <%=parametro%> = <%=request.getParameter(parametro)%> <BR> <% } // del while %>
Objetos de sesi�n: Objetos de sesi�n: Por �ltimo, aunque no menos importante, suele ser interesante conocer el contenido de la sesi�n. Para ello, utilizamos un c�digo muy similar a los anteriores, aunque con alguna peque�a diferencia:
<% java.util.Enumeration enum; String elemento;
session = request.getSession(true); // Creamos la sesi�n, si no existe %>
<% enum = session.getAttributeNames(); // Leemos todos los objetos de sesion
while (enum.hasMoreElements()) {
elemento = (String) enum.nextElement(); %> <%=elemento%> = <%=session.getAttribute(elemento)%> <BR> <% } // del while %>
Pensando a lo grande.
Hasta ahora, hemos visto una manera de tratar las excepciones en un fichero JSP concreto, mediante la directiva errorPage. Imaginemos que, como suele ocurrir, tenemos una aplicaci�n formada por 50 ficheros JSPs. Si queremos tratar las excepciones de los 50 JSPs, tenemos dos posibilidades:
Incluir la directiva errorPage en todos y cada uno de los JSPs. Esto supone que hay que modificar los 50 ficheros, lo que puede costarnos bastante tiempo, a parte de que es muy f�cil que nos dejemos alguno sin modificar y luego nos cueste much�simo tiempo encontrarlo.
Buscar un lugar donde podamos indicar al servidor de aplicaciones que todos los JSPs en los que ocurra una excepci�n, sean tratados de la misma manera. Esta opci�n, que seguro que a todos nos parece m�s inteligente (a no ser que un JSP concreto requiera un tratamiento de errores diferente al resto, cosa que no suele ocurrir), nos obliga a hacer una peque�a modificaci�n en el fichero web.xml de nuestra aplicaci�n, a�adiendo las siguientes lineas:
Su funcionamiento es bastante sencillo. Simplemente le estamos diciendo al servidor que, cuando ocurra una excepci�n de la clase java.lang.Exception, o de una clase que herede de esta, redirija la petici�n al fichero error.jsp de la misma manera que lo hac�a con la directiva errorPage.
Una �ltima vuelta de tuerca.
Ya sabemos como mostrar la informaci�n de las excepciones ocurridas en los JSPs, para tratar de agilizar su depuraci�n. Ahora bien, si nuestra aplicaci�n est� siendo utilizada por clientes, es muy posible que no nos interese que el cliente pueda ver toda esa informaci�n, y que esta solo sea visible para los desarrolladores.
Existen varias maneras de hacer que el cliente no vea todos esos datos, sino que simplemente vea un mensaje pidi�ndole disculpas. Recordemos que la excepci�n va a ser tratada en un fichero JSP, luego podemos mostrar la informaci�n importante solo en los casos que queramos. Por poner un ejemplo sencillo, pero a la vez �til, podemos detectar la IP del cliente con el m�todo request.getRemoteAddr(), y si la IP pertenece a un desarrollador de nuestra empresa, mostramos todos los datos, y si no, mostramos solo el mensaje disculp�ndonos. Evidentemente, hay m�s formas de hacer esta discriminaci�n entre desarrolladores y clientes, y cada uno puede utilizar la que mejor se adapte a sus necesidades.
Conclusi�n
Ya hemos visto una manera bastante sencilla de depurar las excepciones de nuestros JSPs. La intenci�n de este art�culo es mostrar de una manera sencilla las posibilidades que nos ofrecen los JSPs para depurar errores, pero por si alguien cree que con esto aun no es suficiente, aqu� van un par de ideas para desarrollar:
�Qu� ocurre con los errores ocurridos en los servlets? Podemos aprovechar el JSP que hemos construido para ver tambi�n dichos errores. Lo �nico que hay que hacer es, cuando salte una excepci�n en un servlet, redirigir la petici�n al fichero error.jsp.
�Podemos conocer mas datos de, por ejemplo, los objetos que est�n en sesi�n? Claro que es posible, y posiblemente ser�a muy util, pero queda fuera del alcance de este art�culo. Utilizando el paquete java.lang.reflect, podemos obtener los valores de todas las propiedades p�blicas de los objetos que est�n en sesi�n y mostrarlos por pantalla. No solo eso, sino que tambi�n podemos obtener todos los m�todos de esos objetos, ejecutarlos, y mostrar el resultado por pantalla. Si esos m�todos son los accesores (getters) de las propiedades del objeto, podemos conocer todos los datos de un objeto. Al final, con un poco de paciencia, y utilizando la recursividad, podemos convertir nuestro JSP para el tratamiento de errores, en un inspector de objetos.
Eneko Gonz�lez Benito Eneko lleva varios a�os programando en Java, y actualmente trabaja como programador Java en una peque�a consultor�a en Bilbao. El poco tiempo libre que le deja el trabajo, se dedica a practicar deportes (senderismo, futbol, frontenis entre otros) y a leer todo lo que pasa por sus manos.
El Nuevo Examen de Certificaci�n SCJP2 para la Plataforma 1.4<br/>
El Nuevo Examen de Certificaci�n SCJP2 para la Plataforma 1.4
Fecha de creaci�n: 20.08.2003
Revisi�n 1.0 (20.08.2003)
Juan Carlos Castro Robles jcastror AT mixmail PUNTO com
Copyright (c) 2003, Juan Carlos Castro Robles. Este documento puede ser distribuido solo bajo los t�rminos y condiciones de la licencia de Documentaci�n de javaHispano v1.0 o posterior (la �ltima versi�n se encuentra en /licencias/).
Introducci�n
El prop�sito de este art�culo es servir como una breve gu�a (�til y espero que tambi�n "efectiva") para alguien que quiera presentarse al examen de certificaci�n de Sun para la plataforma Java 2 versi�n 1.4 (formalmente, para obtener el certificado Sun Certified Java Programmer for Java 2 platform 1.4, o SCJP2 1.4 a partir de ahora) - ver la p�gina de las certificaciones Java de Sun [1] para obtener una visi�n actualizada general de los diferentes niveles de certificaci�n.
El art�culo lo escribe principalmente alguien que tambi�n ha estado estudiando por cuenta propia para sacarse esta certificaci�n. Para escribir esta breve gu�a me he basado tanto en los recursos disponibles en la red (art�culos, tutoriales, etc.), como en los consejos aportados por la experiencia de gente que visita por ejemplo la web de JavaHispano [2] y de su proyecto de certificaci�n [3].
Cualquier correcci�n o experiencia propia aportada ser� de mucha utilidad, tanto en el art�culo como en el foro de discusi�n que al respecto se mantiene en JavaHispano [8] por lo que estaremos muy agradecidos si nos proporcion�is vuestros comentarios (tanto si os ha sido de utilidad el art�culo como si no ...)
Los puntos que vamos a tratar son los siguientes:
Introducci�n a la certificaci�n Java de Sun
Diferencias entre la versi�n SCJP2 1.2 y la SCJP2 1.4
C�mo prepararse para el examen
Vale la pena la certificaci�n?
Pasos a seguir para solicitar y realizar el examen
Otros recursos utilizados en la escritura de este art�culo
1. Introducci�n a la certificaci�n Java de Sun
Sun introduce la nueva versi�n del examen de certificaci�n SCJP2 1.4 en Agosto del 2002, con la intenci�n de incluir los importantes cambios que se han introducido en la versi�n J2SE 1.4 respecto a la ya antigua versi�n J2SE 1.2.
Este examen de programador (tanto para la versi�n 1.2 como la nueva 1.4) es el primer requisito a cumplir cuando nos queramos presentar para obtener certificaciones m�s avanzadas, como por ejemplo la de Desarrollador Java (ver el diagrama de la p�gina inicial del proyecto de certificaci�n de JavaHispano [3]).
Los objetivos que establece Sun para conseguir esta certificaci�n se pueden encontrar en su propia web [4].
En el siguiente punto se explican con m�s detalle las diferencias existentes entre las versiones del examen 1.2 y la 1.4, pero a partir de entonces nos centraremos en el m�s nuevo, el SCJP2 1.4
2. Diferencias entre la versi�n SCJP2 1.2 y la SCJP2 1.4
Alguien pensar� que a fecha de hoy (mediados del 2003) presentarse al examen de certificaci�n para la versi�n 1.2 ya no tiene sentido, aunque pueda ser que exista gente que realmente lo necesite. La raz�n principal de este punto es debido a que existe mucho material disponible todav�a para la versi�n 1.2 y que no debe ser desechado simplemente por centrarse en los antiguos objetivos (la mayor�a no han cambiado), si no que todo lo contrario, existe realmente material muy �til que todav�a se puede conseguir y del que s�lo es necesario saber qu� partes no har�a falta mirar y cuales son las que se deber�an ampliar.
Los cambios m�s importantes que se han producido entre las dos versiones del examen son:
La secci�n sobre AWT (Abstract Windowing Toolkit) ha sido completamente eliminada, por lo que el examen SCJP2 1.4 no incluir� ninguna pregunta respecto a la programaci�n GUI.
La secci�n sobre E/S tambi�n ha sido eliminada (nada de java.io a partir de ahora, aunque sea muy �til para la programaci�n en la "vida real").
Se ha introducido un nuevo objetivo sobre el API de Assertions, del que por cierto, pod�is encontrar en el art�culo de Emili Miedes [5] una excelente introducci�n.
Se har� m�s hincapi� que en la antigua versi�n sobre los siguientes temas:
* Clases Wrapper (las del paquete java.lang: Integer, Float, Double, Short, Byte, Boolean y Character)
* Collections (existen nuevas implementaciones, ver el API del JDK 1.4 [6])
* Los m�todos hashcode y equals (saber distinguir las implementaciones correctas de las incorrectas y cuestiones parecidas)
Otra informaci�n de inter�s sobre el examen en su versi�n SCJP2 1.4 se encuentra en la tabla siguiente (vigente en agosto del 2003):
Exam number:
CX-310-035
Prerrequisitos:
No
Tipo examen:
Multiple choice y respuestas cortas
N�mero de preguntas:
61
Pass score:
52% (32 de las 61 preguntas)
Tiempo l�mite:
120 minutos
Coste:
unos 150 $ USA (170 euros + 17 % I.V.A. en Espa�a)
Tabla 1: Informaci�n �til sobre el examen SCJP2 1.4
Para consultar una lista de los centros autorizados para realizar el examen pod�is consultar el apartado Centros de la p�gina del proyecto de certificaci�n de JavaHispano [3] o ir directamente a la web de Sylvan Prometric (www.2test.com), que es la empresa autorizada para realizarlos.
3. C�mo prepararse para el examen
Como ya hemos comentado, el art�culo se centra en intentar describir los pasos a seguir por alguien que quiere preparar el examen por su cuenta sin asistir a ning�n curso (oficial de Sun o no), por lo que no vamos a entrar en ninguno discusi�n de sobre si el realizar uno de estos cursos es imprescindible o no (a pesar de que quedan muy bien en un curr�culum ...).
Como cualquier examen de certificaci�n, es muy importante tanto la teor�a como la pr�ctica. En cuanto a teor�a nos referimos a estudiar cada uno de los objetivos marcados por Sun concienzudamente, ya que a pesar de ser un experimentado programador habr� muchos temas (como seguramente el desplazamiento de bits o las conversiones impl�citas en operaciones aritm�ticas) que no se habr�n utilizado nunca. Y dado que el examen tiene un l�mite marcado de tiempo (menos de 2 minutos por pregunta si hacemos un promedio) y que hay preguntas tanto de tipo multiple choice (con una o varias posibles respuestas) como de respuesta corta, ser� imprescindible que antes de realizar el examen hayamos realizado alguna simulaci�n de �ste para comprobar como responderemos en el momento de la verdad. Por lo tanto la parte pr�ctica es important�sima en varios aspectos, es decir, tanto a nivel de programaci�n real (seg�n Sun se recomienda que para presentarse al examen SCJP2 1.4 se tenga experiencia programando con el J2SE 1.4 de al menos unos 6 meses) como a nivel de realizar numerosos de los llamados mock exams (o ex�menes de prueba). Para este tipo de ex�menes es recomendable realizar una b�squeda de "mock exam" en cualquier buscador de la web, y nos aparecer�n multitud de ex�menes gratuitos de prueba, y muy similares al examen real. Normalmente tambi�n existen foros (uno de los m�s interesantes es el de JavaRanch [7]) donde podemos compartir experiencias y publicar nuestras consultas sobre cualquier tipo de duda que nos surja relacionada con la preparaci�n del examen (tambi�n en JavaHispano pod�is encontrar uno de estos foros [8]).
Enumeremos a continuaci�n unos cuantos recursos interesantes disponibles en la web (algunos de manera gratuita) y que sirven para prepararnos para este examen:
El tutorial de JavaHispano [9], que es una traducci�n del tutorial de Marcus Green [10].
Para consultar un listado m�s exhaustivo remitirse a la secci�n de Recursos de la web del proyecto de certificaci�n de JavaHispano [3].
Simuladores de examen (versiones de evaluaci�n de productos de pago): como Whizlabs [11] o JCertify [12].
Tambi�n existen libros que nos preparan espec�ficamente para esta certificaci�n:
"A Programmer's Guide to Java Certification: A Comprehensive Primer" de Khalid Mughal y Rolf Rasmussen (1999) [13]. Aunque basado en la versi�n del JDK 1.2, muchos de sus contenidos son v�lidos para preparar el nuevo examen; se espera una segunda edici�n antes de finalizar el 2003 (consultar su web [21] para m�s detalles).
"Complete Java 2 Certification Study Guide" de Simon Roberts y Philip Heller (2002) [14]. En su tercera edici�n ha sido actualizado para la nueva versi�n JDK 1.4, pero tambi�n se espera una cuarta versi�n antes de finalizar el 2003 (consultar su web [22] para m�s detalles).
Para m�s informaci�n sobre otros recursos y otros nuevos que vayan apareciendo pod�is consultar la secci�n Recursos del proyecto de certificaci�n de JavaHispano [3].
4. Vale la pena la certificaci�n?
Se ha hablado largo y tendido sobre este tema en multitud de lugares de la web. En este caso os dirigimos a una lista de links donde es posible consultar opiniones para todos los gustos:
Tambi�n en The Server Side se puede consultar todo tipo de opiniones al respecto en esta noticia [16]
En el weblog de Mart�n P�rez [17] tambi�n se pueden leer cosas interesantes al respecto en este post [18]
5. Pasos a seguir para solicitar y realizar el examen
Una vez ya hemos estudiado lo "suficiente" (por "suficiente" podemos entender que los resultados que ya obtenemos en los mock exams son de un 70%-80% para arriba), ya estaremos preparados para afrontar el examen con seguridad. Por lo tanto, s�lo nos faltar� pagar y elegir d�a y hora en un centro para realizar el examen; en concreto, los pasos a seguir son:
Realizar la transferencia bancaria a Sun por el importe del examen (contactar con su departamento de formaci�n para que nos faciliten este n�mero de cuenta al 902 210 412 en Espa�a)
Confirmar el pago mediante el env�o por fax del resguardo de la transferencia al departamento de formaci�n (n�mero de fax 91 767 66 67 en Espa�a). Una vez confirmado el pago se ponen en contacto con nosotros para facilitarnos el n�mero de voucher (es un documento necesario para poder realizar el examen de certificaci�n en el centro examinador).
Una vez disponemos de este voucher nos ponemos en contacto con el centro examinador a trav�s de la web de Sylvan Prometric (www.2test.com), nos damos de alta como usuarios y elegimos el centro concreto, el d�a y la hora para realizar nuestro examen (ten�is tambi�n una lista completa de estos centros en la web del proyecto de JavaHispano [3] en el apartado Centros). Se puede pedir con hasta dos d�as de antelaci�n y como mucho ocho semanas antes. Desde esta misma web de Sylvan Prometric tambi�n se pueden realizar los cambios en esta fecha del examen. A pesar de este procedimiento siempre es mejor llamar tambi�n por tel�fono al centro elegido para que tomen nota de que nos hemos registrado y que hemos elegido tal d�a y hora.
El d�a de la realizaci�n del examen hay que presentarse con media hora de adelanto sobre la hora de inicio del examen y llevar dos formas de identificaci�n (una de ellas con una fotograf�a reciente). Seg�n mi opini�n personal, el tiempo para realizar el examen es m�s que suficiente y el entorno gr�fico es muy similar al que os hab�is podido encontrar cuando realiz�is alguno de los mock exams que pueblan la red (posibilidad de marcar respuestas para su revisi�n posterior, ir adelante, ir hacia atr�s, etc.). Aun y as�, ten�is la opci�n de realizar un peque�o test de simulaci�n del entorno de unos 15 minutos (que no se restan del tiempo total que ten�is para hacer el examen). Tambi�n os piden que realic�is alguna encuesta (no obligatorias) y que acept�is los t�rminos de realizaci�n del examen (no divulgaci�n de las preguntas, etc.). Os recomiendo que no perd�is mucho tiempo con las encuestas y la lectura de las condiciones, porque este tiempo s� que resta de las 2 horas que ten�is para realizar el examen. Una vez terminado el examen ya os dan los resultados en un formato provisional. Si hemos aprobado, s�lo faltar� esperar recibir nuestro certificado en nuestro domicilio al cabo de unas semanas. Los datos de contacto que utilizar� Sun son los que hay�is puesto cuando os dais de alta en la web de Sylvan Prometric.
Suerte a tod@s!!
6. Otros recursos utilizados en la escritura de este art�culo
El art�culo de IBM DeveloperWorks que tambi�n habla sobre como prepararse para esta certificaci�n de Java 2 para la plataforma 14 [19]
Los nuevos cambios introducidos en la versi�n 1.4 sobre la versi�n 1.2 seg�n Marcus Green [20]
[13] A Programmer's Guide to Java Certification: A Comprehensive Primer (Agosto 1999), Khalid Mughal y Rolf Rasmussen , Addison-Wesley , ISBN 0201596148
[14] Complete Java 2 Certification Study Guide (3rd edition - Julio 2002), Simon Roberts y Philip Heller , Sybex , ISBN 0782140777
Juan Carlos Castro Robles Juan Carlos trabaja como desarrollador de aplicaciones para la gesti�n hospitalaria usando J2EE en una empresa de Barcelona. Actualmente es SCJP2 para la plataforma 1.4 y est� interesado en el resto de certificaciones de Java.
Enrique Rodriguez Lasterra lasterra AT javahispano DOT org
Copyright (c) 2003, Enrique Rodriguez Lasterra. Este documento puede ser distribuido solo bajo los términos y condiciones de la licencia de Documentación de javaHispano v1.0 o posterior (la última versión se encuentra en /licencias/).
Introducción
En la primera parte de esta serie de artículos se explicaban los 3 tipos de EJB existentes en la especificación.
El objetivo de este artículo es profundizar en la arquitectura EJB, mostrar como se programa un EJB y cuales son los elementos principales de los descriptores, además del funcionamiento de los SLSB.
Para el ejemplo se ha elegido la implementación de una calculadora y como servidor de aplicaciones donde realizar las pruebas JBoss 3.x.
Elementos de un EJB
Tal y como se explicó en el anterior artículo, la arquitectura de los EJB cuenta con más de un elemento. El programador de EJB debe programar una clase, dos interfaces y escribir al menos un descriptor XML Este trabajo sería en vano de no ser por el contenedor de EJB que será el encargado de procesar la información y hacer de nuestro trabajo un componente distribuido, transaccional, multihilo, etc.
Para que la relación entre código y contenedor sea posible el programador debe seguir las normas marcadas en la especificación EJB.
La clase Bean
Esta clase es el componente principal de un EJB, sobre todo desde el punto de vista del programador. Se trata de una clase Java que implementa un interfaz definido por la especificación EJB:
En el caso de un EJB de sesión será el interfaz javax.ejb.SessionBean.
En el caso de un EJB de entidad será el interfaz javax.ejb.EntityBean
En el caso de un EJB de mensajería será el interfaz javax.ejb.MessageDrivenBean
Todos estos interfaces heredan de javax.ejb.EnterpriseClass, que es un interfaz sin operaciones que hereda de java.io.Serializable. El objetivo de este es marcar a todas las clases que la implementen como una Clase EJB y además hacer que esta clase se pueda serializar, algo necesario para cualquier Objeto al que se quiera llamar a través de la red.
Ya que este artículo es sobre SLSB, nuestra Clase Bean debe implementar el interfaz SessionBean.
/** * Ejemplo de EJB de sessión sin estado. Para ello se va a implementar * una calculadora con sus cuatro operaciones básicas. * * @author lasterra AT javahispano DOT org */ public class CalculadoraBean implements javax.ejb.SessionBean
Este interfaz tiene operaciones específicas definidas para los EJB de sesión. Si nos fijamos en los JavaDoc de este interfaz [1] se puede ver que consta de 4 métodos que la clase Bean del EJB deberá implementar. Estas operaciones definen el ciclo de vida de los EJB junto con una operación no presente en el interfaz, el ejbCreate.
La operación setSessionContext es llamada por el contenedor después de la creación del EJB y recibe del contenedor la información del contexto. Esta información debe ser almacenada como dato miembro del EJB y a través de ella podemos acceder a información del contenedor.
/** * El objeto SessionContext es el encargado de interactuar con el * contenedor de EJB. A traves de él se puede acceder a información * acerca de si el cliente tiene permisos de ejecución o sobre el * estado transaccional. * * Una referencia a este objeto debe ser guardada como dato miembro * de los EJB. * * La implementación típica suele ser la siguiente * * @param sessionContext Contexto del EJB fijado por el contenedor * @throws EJBException Se lanza para avisar al contenedor que algo * ha fallado */ public void setSessionContext(javax.ejb.SessionContext sessionContext) throws javax.ejb.EJBException { this.sessionContext = sessionContext; }
Las operaciones ejbActivate y ejbPassivate son invocadas por el contenedor para llevar a cabo el proceso de pasivación del los EJB. Al ser los SLSB EJB sin estado no tienen mucho sentido estas operaciones, ya que como su nombre indica no tienen estado (sesión) y por tanto no tiene sentido que un SLSB almacene información que se pueda considerar interesante de almacenar en el caso de que el servidor necesite efectuar un proceso de pasivación.
La operación ejbRemove indica que no se van a realizar mas operaciones con EJB y por lo tanto que el contenedor puede almacenar la instancia en el pool de EJB. Esta operación puede ser invocada por el cliente o por el contenedor si se da un time out.
La operación ejbCreate es la que crea el EJB, o mejor dicho, es la que cede una instancia del EJB al usuario, ya que la instancia puede haber sido creada con anterioridad y se encuentra esperando en el pool de EJB. No aparece en la interfaz SessionBean ya que es el programador quien decide cuales son los parámetros que le deben llegar al EJB para crearse. Es necesario al menos un ejbCreate y se puede sobrecargar tantas veces como el programador lo desee. Para los SLSB no tiene sentido pasar parámetros a través del ejbCreate ya que al ser sin estado nada garantiza el poder hacer uso de esos parámetros en el futuro.
/** * Este método es llamado por el contenedor cuando el cliente llama * al metodo create de la interfaz Home. * * Debe existir al menos un ejbCreate y por cada uno de ellos tiene * que haber una operación create con los mismos parametros en la * interfaz Home. * * Este metodo se puede sobrecargar tantas veces como queramos para * así poder inicializar el EJB de distintas formas. * * En el contexto de un SLSB no tiene mucho sentido pasar * parametros en el ejbCreate, ya que al no mantenerse un sesión entre * cliente y EJB, no debemos definir como dato miembro del EJB ninguna * información relacionada con el cliente. * * @throws CreateException Se lanza para avisar al contenedor que algo * ha fallado al crearse el EJB */ public void ejbCreate() throws javax.ejb.CreateException { log.debug("Inicializando el Bean"); }
Por ultimo, es en esta clase donde se implementa la lógica de negocio del EJB. En el ejemplo de la calculadora es aquí donde se encuentra los métodos sumar, restar, dividir y multiplicar.
//métodos de negocio /Business Methods
//Todas estas operaciones deben aparecer de la misma forma en el //InterfazRemoto
/** * Operación sumar * @param op1 operando 1 * @param op2 operando 2 * @return Suma de los dos operandos * @throws EJBException Se lanza para avisar al contenedor que algo * ha fallado */ public int sumar(int op1, int op2) throws javax.ejb.EJBException { log.debug("sumar"); return op1+op2; }
Todos los métodos de la clase Bean deben lanzar la excepción javax.ejb.EJBException. El programador podrá heredar de ella o lanzar otras junto a esta.
La interfaz Remota
Los EJB además de ser componentes distribuidos implementan una serie de facilidades que hacen más simple la labor del programador. Esto es posible gracias a la interfaz remota y al EJB Object.
La interfaz remota es la vista que el cliente tiene del EJB. En ella se encuentran todas las operaciones de la lógica de negocio más las heredadas por la interfaz javax.ejb.EJBObject. [2]
/** * Interfaz Remoto del EJB calculadora. Es la vista del EJB para el * cliente. En el aparecen tanto los business methods de la clase * Bean como las operaciones del interfaz del que hereda, el * javax.ejb.EJBObject * * @author lasterra AT javahispano DOT org */ public interface Calculadora extends javax.ejb.EJBObject
El programador debe implementar una interfaz remota por cada clase Bean. Esta interfaz será implementada por el EJB Object, que es un objeto generado e instanciado por el contenedor cuya función es hacer de pasarela entre el cliente y el EJB a través del contenedor.
Al igual que la clase Bean es la parte más importante para el programador, el EJB Object es la parte más importante para el servidor. Si veis los JavaDoc del interfaz javax.ejb.EJBObject se puede observar que:
Extiende de java.rmi.Remote, por lo que nuestro interfaz remoto es también un interfaz Java RMI remoto y permite realizar llamadas a través de la red.
Tiene una operación para obtener el EJBHome: getEJBHome()
Tiene una operación para borrar el EJB, o mejor dicho, para devolverlo al pool de EJB: remove()
Una operación para saber si dos EJB son iguales: isIdentical(EJBObject obj)
Una operación para obtener la clave primaria del EJB: getPrimaryKey() (Solo aplicable a Beans de Entidad)
Una operación para obtener el "handle" del EJB: getHandle(). El javax.ejb.Handle es una referencia persistente a un EJB. Hablaremos más de ella en futuros capítulos.
El contenedor genera el EJB Object, y además de ahorrar el trabajo de la programación de los stub y skeletons RMI al programador, intercepta las llamadas entre cliente y EJB para poder efectuar el control de seguridad, el tratamiento de las transacciones, la gestión del pool de EJB y en general, todas aquellas operaciones que el contenedor quiera llevar a cabo sobre los EJB.
Para implementar la interfaz remota simplemente hay que introducir las operaciones de lógica de negocio del EJB que se encuentran en la clase Bean, con los mismos parámetros, retorno y excepciones. A estas últimas hay que añadir la excepción java.rmi.RemoteException, por ser el EJB Object un objeto de invocación remota.
/** Operación sumar * @return Suma de los dos operandos * @param op1 operando 1 * @param op2 operando 2 * @throws RemoteException Necesaria ya que el el objeto del * contenedor que implementa esta interfaz * (EJB OBject) es un Objeto Remoto RMI * @throws EJBException Se lanza para avisar al contenedor que algo * ha fallado */ public int sumar(int op1, int op2) throws javax.ejb.EJBException, java.rmi.RemoteException;
La interfaz Home
La interfaz Home es la encargada de intermediar entre el cliente y el contenedor para obtener referencias de EJB.
Al igual que el EJB Object era un objeto generado por el contenedor en base a una interfaz de la especificación y a la interfaz remota del EJB, en este caso nos encontramos con el Remote Home Object, generado en este caso en base a la interfaz Home y a la interfaz javax.ejb.EJBHome.
Esta clase implementa principalmente dos patrones de diseño:
Factory y por tanto se limita a operaciones de creación, búsqueda y destrucción de EJB.
Singleton por lo que solo hay un instancia en memoria. Esto hace que las referencias al Remote Home Object sean cacheables por el cliente al menos en entornos no distribuidos, algo muy aconsejable y que puede ahorrar un tiempo considerable.
En la interfaz Home se declaran las operaciones para crear, borrar y buscar EJB. Esta interfaz además hereda de javax.ejb.EJBHome que a su vez hereda de java.rmi.Remote, por lo que el Remote Home Object también es un objeto RMI.
/** * Interfaz Home del EJB Calculadora, a través de este interfaz * el Cliente obtiene la referencia a los EJB. * * * @author lasterra AT javahispano DOT org */ public interface CalculadoraHome extends javax.ejb.EJBHome
En la interfaz javax.ejb.EJBHome aparecen las operaciones para:
Borrado/liberación de instancias de EJB por parte del cliente, remove()
Captura de meta-información del EJB, getMetaData()
Obtener el "Handle" del objeto Home remote, getHandle()
El trabajo del programador es incluir un método Create con los mismos parámetros y excepciones por cada uno de los ejbCreate que tenga la clase Bean. Además en el caso de los Beans de entidad, hay que incluir los métodos finders, encargados de hacer las busqedas, siendo el findByPrimaryKey obligatorio. Esto lo veremos en futuros capítulos.
/** * Metodo create en el interfaz Home. Enlaza con el metodo ejbCreate * del Bean. * El cliente obtiene a traves de este método la referencia al EJB. * * @throws RemoteException Necesaria ya que el el objeto del * contenedor que implementa esta interfaz * (Home OBject) es un Objeto Remoto RMI * @throws CreateException Necesaria para todos los métodos create * @return Devuelve la referencia al EJB, es decir, * el Interfaz Remoto */ Calculadora create() throws javax.ejb.CreateException, java.rmi.RemoteException;
Transparencia de la situación física
La especificación EJB define la necesidad de que los EJB sean objetos que puedan residir en máquinas distintas del cliente. Esto es posible gracias a que tanto el interfaz Home como el interfaz Remoto son interfaces RMI pero no hay que olvidar el papel que comple el Java Native and Directory Interface (JNDI).
El JNDI es la interfaz Java de los Servicios de Directorio. Un Servicio de directorio es un repositorio de objetos, con estructura arbórea, a los que se les asocia un nombre clave. Este tipo de estrucuturas ofrece unos índices de rendimiento muy altos en operaciones de lectura. Ejemplos de Servicio de Directorio son Iplanet Directory Server, Micorsoft Active Directory o LDAP. El Interfaz Java permite poner una capa intermedia para acceder a estos servicios de directorio, es decir, cumple un papel similar al JDBC con las Bases de Datos.
El JNDI es necesario por una razon muy simple, la clases que engloban un EJB son instanciadas por el contenerdor y es necesario guardar una referencia a estas en algún lugar accesible por el cliente, para que este las pueda recuperar.
Ya que la especificación EJB indica que los EJB pueden ser accesibles desde maquinas virtuales Java diferentes de la del contenedor, el servicio de directorio también lo debe ser. Es por ello que los servidores de aplicaciones implementan servicios de directorio con interfaz JNDI para guardar referencias de los Home Objects. Algunos servidores de aplicaciones incluso implementan versiones con capacidad de distribución, es decir, que el JNDI puede delegar las peticiones a máquinas diferentes.
El servidor de aplicaciones se encarga de guardar los Home Objects en el JNDI. Una vez el cliente tiene acceso al JNDI, puede recuperarlos a traves de la interfaz Home. Lo vermos mas claro en la sección en la que se explica como programar un cliente java.
Los interfaces locales
Como se ha explicado en los puntos anteriores, tanto el EJB Object como el Home Object son objetos RMI de invocación remota. Estos objetos son accesibles a través de la red pero con el coste de la serialización y envio de los objetos a través de la red. En el caso de que un cliente quisiese acceder a un EJB que se encuentra en la misma maquina virtual antes de la especificación 2.0, era necesario realizar llamadas remotas. A partir de esta nueva especificación aparecieron los interfaces locales, con los que se soluciono este problema.
Las ventajas principales son dos:
Aumento de la velocidad al no ser necesaria la serialización y el uso del protocolo RMI/IIOP
Paso de parámetros por referencia, lo que evita la nueva creación de los objetos.
La principal desventaja es que hay que escribir dos nuevos interfaces, exactamente iguales que los anteriores pero sin que lancen la excepción java.rmi.RemoteException.
Interfaz Remoto Local
/** * Interfaz Remoto Local del EJB calculadora. A través de este * interfaz el Cliente obtiene la referencia a los EJB. * * La Unica diferencia en "programación" entre interfaces remotos * y locales es que los locales no lanzan java.rmi.RemoteException * * @author lasterra AT javahispano DOT org */ public interface CalculadoraLocal extends javax.ejb.EJBLocalObject{
/** Operación sumar * @return Suma de los dos operandos * @param op1 operando 1 * @param op2 operando 2 * @throws EJBException Se lanza para avisar al contenedor * que algo ha fallado * */ public int sumar(int op1, int op2) throws javax.ejb.EJBException; . . .
Interfaz Home Local
/** * Interfaz Home Local del EJB Calculadora. A través de este interfaz * el Cliente obtiene la referencia a los EJB. * * La Unica diferencia en "programación" entre interfaces remotos y * locales es que los locales no lanzan java.rmi.RemoteException * * @author lasterra AT javahispano DOT org */ public interface CalculadoraLocalHome extends javax.ejb.EJBLocalHome{
/** * Método create en el interfaz Home. Enlaza con el metodo * ejbCreate del Bean. El cliente obtiene a traves de este * método la referencia al EJB. * * @throws CreateException Necesaria para todos los métodos * create * @return Devuelve la referencia al EJB, * es decir, el Interfaz Remoto */ CalculadoraLocal create() throws javax.ejb.CreateException; }
Este sería el diagrama completo de todas las clases e interfaces que se han explicado.
Los descriptores
Los descriptores son archivos XML de configuración de los EJB y que el contenedor lee para saber como debe actuar. El estándar EJB solo contempla uno, el archivo ejb-jar.xml aunque los servidores de aplicaciones suelen incluir otro con configuración propia y propietaria. Esta situación hace que se puedan realizar configuraciones muy interesantes en algunos servidores pero hace más difícil la migración de un EJB de un servidor de aplicaciones a otro.
La información que contiene el ejb-jar.xml sobre un EJB se podría dividir en tres grupos:
Información sobre el EJB
El tipo de EJB, si es de sesión, de entidad o de mensajería y de que subtipo, SLSB, SFSB, etc.
El nombre del EJB, este será el nombre con el que el contenedor identifica al EJB
La clase y los interfaces que componen el EJB
El tipo de transacciones que utiliza el EJB, si son transacciones manejadas por el servidor o son gestionadas por el propio usuario.
En caso de ser un Bean de entidad, información sobre los datos miembro del Bean que se guardan en la base de datos.
Gestión de transacciones
Es en el descriptor donde se configuran las transacciones a nivel de método. Es un tema un tanto complejo y lo trataremos en profundidad en futuros capítulos.
Gestión de seguridad
Los EJB tienen un control de seguridad muy completo que permite gestionar que usuarios o roles pueden acceder a un método de un EJB. También se explicará en futuros capítulos.
<!-- Document : ejb-jar.xml Created on : 16 de junio de 2003, 0:43 Author : lasterra AT javahispano DOT org Description: ejb-jar.xml simple, es lo mínimo que exige JBoss. Se toman por defecto las transacciones, y no se especifica ningun control de seguridad --> <ejb-jar > <enterprise-beans> <session > <ejb-name>Calculadora</ejb-name> <home> org.javahispano.ejemplos.slsb.CalculadoraHome </home> <remote> org.javahispano.ejemplos.slsb.Calculadora </remote> <local-home> org.javahispano.ejemplos.slsb.CalculadoraLocalHome </local-home> <local> org.javahispano.ejemplos.slsb.CalculadoraLocal </local> <ejb-class> org.javahispano.ejemplos.slsb.CalculadoraBean </ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> </enterprise-beans> </ejb-jar>
Descriptores Propietarios:JBoss
Jboss necesita de al menos la información de un descriptor propietario para hacer el deploy de un EJB. En este descriptor, el jboss.xml, es donde informamos al servidor del nombre que van a tener nuestros EJB en el JNDI.
Otras configuraciones que se pueden hacer en este descriptor son: referencias entre EJB, configuracion del EJB para un cluster de JBoss, seguridad, configuración de EJB proxys, etc.
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE jboss PUBLIC "-//JBoss//DTD JBOSS 3.2//EN" "http://www.jboss.org/j2ee/dtd/jboss_3_2.dtd">
Para probar el EJB se ha creado un cliente para el mismo, en forma de una simple Java Main class. El cliente primero debe obtener una referencia del JNDI. Esta es el objeto InitialContext que es el nodo padre de la estructura de directorios. El valor de las propiedades que se pasan al InitialContext son especificas de cada servidor de aplicaciones, se supone el servidor JBoss3.x instalado en la misma máquina y con la configuración por defecto.(Puerto RMI =1099)
Hashtable propiedades = new Hashtable(); propiedades.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory"); propiedades.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces"); propiedades.put("java.naming.provider.url", "localhost"); long tiempoInicio = System.currentTimeMillis(); InitialContext ic = new InitialContext(propiedades);
Una vez echo esto, se obtiene del JNDI con la operacion lookup sobre el objeto InitialContext, el Home Interface a través del nombre fijado en el jboss.xml. Ya que la clase se va a ejecutar en una máquina virtual distinta, la debemos recuperar el Home Interface y no el Local Home Interface.
Con la interfaz remota se puede llamar a los métodos de negocio, por ejemplo, la operación sumar.
int resultado = calculadora.sumar(7, 3); System.out.println("Resultado de sumar 7+3 = " + resultado);
En el cliente se miden los tiempos de obtener el Contexto del JNDI, los interfaces del EJB y la operación sumar para que podais evaluar la "lentitud" de los EJB.
El ejemplo
Como se ha explicado el ejemplo cuenta con el EJB en la parte servidora y una clase Java como cliente. Para probarlo necesitamos:
Tener instalado y arrancado JBoss en su version 3.x.
Tener instalado y configurado Jakarta-ANT
Configurar el script para nuestro sistema
Ejecutar el script
Por ultimo, ejecutar el target cliente del script
Instalar JBoss
El objetivo de este artículo no es explicar la instalación de JBoss. En cualquier caso, por la sencillez de la operación se va a explicar a grandes rasgos lo necesario para instalar JBoss 3.2.x.
Descargar de la web www.jboss.org la ultima versión de la serie JBoss 3.x. Esta en formato zip y tar.gz, y disponiblo sin y con condigo fuente.
Descomprimir el archivo
Es necesario tener la varible de entorno JAVA_HOME. En windows, set JAVA_HOME=C:\j2sdk1.4.2 en consola o boton derecho en Mi PC-->Propiedades del sistema-->Pestaña Opciones Avanzadas y pulsar en Variables de Entorno. En UNIX, export JAVA_HOME=/usr/j2se.
Para comprobar que JAVA_HOME esta bien ejecutar el programa java en consola
Para arrancar JBoss, ir al directorio \bin y ejecutar el programa run. De esta forma se ejecuta JBoss con la configuración default.
Instalar Jakarta-ANT
Para instalar ANT,
Descargar de la web http://ant.apache.org la ultima versión
Descomprimir el archivo
Poner la varible de entorno ANT_HOME al directorio donde habeis descomprimido ANT. Añadir a la variable de entorno PATH el directorio bin de ANT. En windows, set PATH=%PATH%;%ANT_HOME%\bin. En UNIX, export PATH=%PATH%:%ANT_HOME%/bin
Para comprobar que ANT_HOME esta bien ejecutar el programa ant en consola
Si utilizais algun IDE para programar (Netbeans, Eclipse, JBuilde, IDEA, etc.), es bastante común que tenga un plugin de ANT, por lo que su instalación no es necesaria.
Ejecutar el script
El ejemplo cuenta con un script ANT. Es el archivo build.xml. Para ejecutar este script, solo hay que cambiar el valor de la propiedad jboss.dir al directorio donde este instalado JBoss.
<property name="jboss.dir" value="C:\jboss"/>
Los pasos a seguir son:
Descargar el ejemplo de www.javahispano.org
Descomprimir el archivo
Cambiar la propiedad jboss.dir como se ha descrito anteriormente
Si todavia no teneis JBoss arrancado, este es un buen momento ;-)
Ir al directorio donde se encuentra el script y ejecutar "ant". Automaticamente lee el archivo build.xml y realiza el deploy del EJB entre otras cosas.
Se deberian ver las siguientes trazas en la consola y ficheros del log del JBoss
19:44:52,639 INFO [MainDeployer] Starting deployment of package: file:/C:/java/jboss3/server/pruebas/deploy/org.javahispano.ejempl os.slsb.Calculadora-1.0.jar 19:44:54,232 INFO [EjbModule] Creating 19:44:54,252 INFO [EjbModule] Deploying Calculadora 19:44:54,292 INFO [StatelessSessionContainer] Creating 19:44:54,302 INFO [StatelessSessionInstancePool] Creating 19:44:54,302 INFO [StatelessSessionInstancePool] Created 19:44:54,302 INFO [StatelessSessionContainer] Created 19:44:54,302 INFO [EjbModule] Created 19:44:54,312 INFO [EjbModule] Starting 19:44:54,312 INFO [StatelessSessionContainer] Starting 19:44:54,492 INFO [StatelessSessionInstancePool] Starting 19:44:54,492 INFO [StatelessSessionInstancePool] Started 19:44:54,492 INFO [StatelessSessionContainer] Started 19:44:54,492 INFO [EjbModule] Started 19:44:54,492 INFO [EJBDeployer] Deployed: file:/C:/java/jboss3/ser ver/pruebas/deploy/org.javahispano.ejemplos.slsb.Calculadora-1.0.jar 19:44:54,512 INFO [MainDeployer] Deployed package: file:/C:/java/jb oss3/server/pruebas/deploy/org.javahispano.ejemplos.slsb.Calculadora -1.0.jar
Una vez aparece "[MainDeployer] Deployed package" podemos decir que el EJB ha sido instalado
Ejecutar el cliente
Para Ejecutar el cliente simplemente hay que ejecutar uno de los target del script ANT, el de nombre ejecutar-cliente. Para ello simplemente ejecutamos en el directorio del script ant ejecutar-cliente
Conclusión
Este artículo muestra como hacer un EJB muy simple. Explica la arquitectura de la especificación junto a su código fuente para así enseñar no solo a hacer EJB sino a entederlos.
El próximo artículo se explicará como herramientas Open Source pueden ayudar a escribir EJB. Como ejemplo, se utilizará otra calculadora, esta vez con interfaz web.
Ingeniero Informático por la Universidad de Deusto.Trabaja en la empresa bilbaína NHT-Norwick.com desde hace ya mas de dos años donde programa, como no, en Java.
lunes, octubre 6, 2003 at 6:06AM 
