10. Taller de Formación Java empresarial. Ing. Laura González Ing. Guillermo Roldós Ing. Juan Herman

10. Taller de Formación Java empresarial Ing. Laura González Ing. Guillermo Roldós Ing. Juan Herman

Instalación de Entorno de Trabajo Qué herramientas tenemos que instalar? Las herramientas que vamos a usar para el desarrollo de aplicaciones bajo la plataforma JEE durante el curso son las siguientes: Java Developmet Kit (JDK): Conjunto de herramientas para el desarrollo de aplicaciones JAVA. http://www.oracle.com/technetwork/java/javase/downloads/jdk-6u25-download-346242.html PostgreSQL: Sistema de Gestión de Base de Datos (del inglés DBMS - DataBase Managment System). http://www.enterprisedb.com/products-services-training/pgdownload#windows JBoss Application Server (JBoss AS): Servidor de Aplicaciones JEE. http://sourceforge.net/projects/jboss/files/jboss/jboss-6.0.0.final/jboss-as-distribution-6.0.0.final.zip/download Eclipse: Entorno de Desarrollo Integrado (del ingés IDE Integrated Development Environment). http://www.eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/heliossr2 JBoss Tools: http://sourceforge.net/projects/jboss/files/jbosstools/jbosstools3.2.x/ jbosstools-3.2.0.ga.aggregate-update-2011-02-16_18-30-44-h329.zip/download?use_ mirror=ufpr Qué pasos debemos seguir? 1. Para empezar, debemos copiar la carpeta Herramientas, que se encuentra en el DVD entregado para el desarrollo del curso, en algún directorio local al cual llamaremos en adelante %TF_JEE%. 2. Instalamos la JDK: %TF_JEE%\Herramientas\1.Java\jdk-6u25-windows-i586.exe siguiendo los pasos del wizard de instalación. 631

3. Instalamos PostgreSQL: %TF_JEE%\Herramientas\2.PostgreSQL\postgresql- 9.0.4-1-windows.exe siguiendo los pasos del wizard de instalación. 4. Instalación de JBoss AS: Lo único que debemos hacer es descomprimir el archivo %TF_JEE%\Herramientas\3.JBoss\jboss-as-distribution-6.0.0.Final.zip. 5. Instalación de Eclipse: Al igual que con JBoss solo debemos descomprimir el archivo entregado %TF_JEE%\Herramientas\4.Eclipse\eclipse.zip. La versión de eclipse entregada corresponde a la versión Helios-SR2 con los siguiente plugins de JBossTools ya instalados: a. Hibernate Tools b. JBoss Tools RichFaces c. JBoss WebServices Tools d. JBossAS Tools Opcionalmente, se entrega el instalador de Firefox 5, ya que es perfectamente compatible con las herramientas que utilizaremos para el desarrollo WEB. El instalador se encuentra en %TF_JEE%\Herramientas\5.Extras\Firefox Setup 5.0.1.exe Cómo integramos Eclipse con JBoss? El plugin JBossAS Tools (ya instalado en la versión entregada) nos brinda la posibilidad de manejar la configuración del JBoss desde el propio IDE, además de la posibilidad de iniciarlo (en modo normal o debug), reiniciarlo, detenerlo y republicar los proyectos sin necesidad de copiar carpetas, archivos o utilizar comandos por consola. Veamos paso a paso como realizar dicha integración: 1. Sobre la vista Servers damos click derecho -> New - > Server. 632

2. Elegimos JBoss AS 6.0. 3. Seleccionamos como Home Directory la ruta donde descomprimimos JBoss \ jboss- 6.0.0.Final. Configuración default y presionamos Finish. 4. El paso 3 agregará un nuevo ítem en la vista de Servers, si damos doble click sobre él podemos ver la siguiente pantalla de configuración. 633

Vemos, además, que se activan los siguientes botones: 634

1 Introducción Taller de Formación Java EE Tema: Introducción a componentes de negocio (EJB) 1 era Parte Cuando se va a desarrollar un Sistema de Información de cierto tamaño (o que se espera que pueda crecer en el futuro), es necesario tener en cuenta varios aspectos para su diseño como, por ejemplo, el manejo de la seguridad, acceso a Bases de Datos y gestión de transacciones, escalabilidad, posibilidad de distribuir la instalación en múltiples servidores, etc. Las especificaciones JEE [1] resuelven esta problemática a través de la creación de componentes de negocio llamados EJB, que simplifican muchísimo el desarrollo. La idea está basada en el uso de un contenedor de EJB (o EJB Container) que se encarga de gran parte de las tareas mencionadas antes, dejando al desarrollador la implementación de la lógica de negocio particular de cada servicio. De esta forma, se cumple con el principio de que cada componente de software resuelve la parte de la que es responsable en un sistema débilmente acoplado. 1.1 Qué son y para qué sirven los EJB Los EJB (por las siglas en inglés de Enterprise Java Beans, o Componentes de Negocio Java), también llamados Enterprise Beans, son componentes de software escritos en Java que encapsulan las complejidades relacionadas con todos los servicios de base necesarios para una aplicación de mediano o gran porte, permitiendo que el desarrollador se concentre en 635

implementar lo realmente importante. Estos componentes no son capaces de ejecutarse por sí solos, sino que necesitan de un servidor que los contenga y les brinde todos los servicios necesarios (el Contenedor). En una arquitectura en capas tradicional, los EJB se encuentran en la capa lógica y, eventualmente, en la capa de persistencia, como puede verse en la Figura 1. 1.2 Cómo funcionan los EJB Cuando se desarrolla un componente EJB, lo que se escribe realmente es una clase POJO junto con determinados annotations 1 que indican las características y propiedades de dicho componente. Estas propiedades son leídas e interpretadas por el Container y permiten a éste decidir cómo controlar cada instancia del EJB y su ciclo de vida. En un contenedor pueden existir diferentes EJBs, los que pueden formar parte de la misma aplicación o de más de una. Existen diferentes tipos de EJB, los que serán vistos más adelante, cada uno de los cuales tiene un fin específico y es manejado por el contenedor de forma diferente. Es el contenedor 636 el que crea y destruye las instancias de los EJB de acuerdo a sus necesidades, así como gestiona el ciclo de vida de cada instancia. Esto no es controlable por el desarrollador. Cuando un cliente (sea éste una aplicación Java o una página JSP o JSF) desea ejecutar un servicio provisto por un EJB, debe primero solicitar una instancia del mismo y toda la interacción es a través del Container, como se observa en la Figura 2. 2 Contenedor de EJB Como ya se mencionó antes, un Contenedor de EJB es una aplicación que cumple con una serie de especificaciones para ejecutar componentes EJB. Las especificaciones JEE son provistas por Sun (ahora Oracle) y pueden ser implementadas por más de un proveedor, cada uno de los cuales implementa su propia versión de las mismas. Existen servidores gratuitos o pagos, cada uno puede brindar mayor o menor funcionalidad pero todos deben cumplir con las especificaciones oficiales. En la Figura 3 se observa un diagrama que muestra cómo los EJB son ejecutados dentro de un EJB Container, y éste es parte de un Application Server. Una de las ventajas de esto es que los EJB son multiplataforma, es decir, que son desarrollados una vez y no es necesario modificarlos si se cambia de proveedor del Container. 1 Las annotations sirven para expresar metadata acerca de una clase, método o atributo de forma integrada con el código de la misma.

Algunos de los contenedores de EJB comúnmente usados son: JBoss AS [2] es un servidor de aplicaciones completo donde no solo se ejecutan EJBs sino también aplicaciones Web, portales, etc. Es muy utilizado debido a que es un producto open-source de excelente calidad, robusto y con muchos años en el mercado. GlassFish [3] fue desarrollado por Sun como un producto open-source, si bien es más reciente que JBoss está muy extendido actualmente. A partir de la adquisición por parte de Oracle, Sun forma parte del paquete Middleware de Oracle. WebLogic Server [4] fue desarrollado por BEA Systems y adquirido recientemente por Oracle, es un producto comercial muy robusto. WebSphere [5], producto comercial desarrollado por IBM, se integra fácilmente con otros productos de la compañía. Las responsabilidades principales de un Contenedor son las siguientes: Manejo del ciclo de vida de las instancias de EJB. Pool de instancias de cada EJB, donde debe equilibrar la cantidad de instancias necesarias para responder rápidamente sin consumir recursos excesivamente. Gestión de transacciones para que sea transparente para el desarrollador, éste solamente debe declarar unas directivas. Seguridad a nivel de usuarios y roles. Inyección de dependencias, lo que permite la invocación remota de otros EJB sin que el desarrollador deba especificar su ubicación. Soporte para Web Services, que brindan la posibilidad de interactuar con servicios alojados en otras plataformas o tecnologías. Timer para ejecutar eventos cada determinada cantidad de tiempo. 3 Tipos de EJB Existen dos tipos principales de EJB, los que se verán en este capítulo. Este tipo debe especificarse como una anotación en la clase Java que lo implementa. 3.1 Session Beans Son componentes que contienen lógica de negocios, pueden verse como servicios expuestos para ser consumidos por los clientes, tanto local como remotamente (luego se verá con mayor profundidad este concepto). Cuando un cliente desea ejecutar una operación de un determinado EJB el servidor (Container) le provee una instancia del mismo para que ejecute el método deseado sobre ella. 637

Existen, a su vez, tres tipos de Session Beans, determinados por cómo son manejadas las instancias con respecto a los clientes que consumen sus servicios. 3.1.1 Stateless Session Beans Estos EJB no mantienen información acerca de los clientes que atienden, incluso es posible que un mismo cliente sea atendido por diferentes instancias del mismo EJB. Cuando un cliente desea ejecutar una operación pide una instancia al Container, éste toma una instancia de dicho EJB de un pool de instancias disponibles, ejecuta el método solicitado y devuelve la instancia al pool sin que quede registrada ninguna información de la operación que realizó. Esto se observa más claramente en la Figura 4 (más adelante se explicará el concepto de Proxy que aparece en la figura). Son los más utilizados, su principal ventaja es que consumen pocos recursos ya que las instancias son reaprovechadas y un mismo servidor puede atender a mayor cantidad de clientes. Esto brinda mayor escalabilidad a la aplicación. Para crear un EJB de este tipo debemos agregar la anotación @Stateless, como se ve en el ejemplo de la Figura 5. A esta manera de especificar las dependencias declarativamente se le llama dependency injection, ya que el Container inyecta las definiciones necesarias. 3.1.2 Stateful Session Beans 638 A diferencia de los anteriores, en este caso, cada instancia de un EJB atiende a un único cliente, por lo que puede guardar información acerca de su estado. Este tipo de componentes son utilizados en casos en que se necesite mantener una relación conversacional entre el cliente y el servidor. El ejemplo más común es el carrito de compras, en el que el servidor debe conocer los ítems que el cliente ha ido comprando. En la Figura 6 se muestra este concepto.

Claramente estos EJB consumen mayor cantidad de recursos que los anteriores, ya que por cada cliente es necesario contar con una instancia del EJB con lo cual, a mayor cantidad de clientes crecerán los requerimientos para el servidor. Esto resta escalabilidad a la aplicación. Del mismo modo que en el caso anterior, para crear un EJB de este tipo es necesario especificar la anotación @Stateful. 3.1.3 Singleton Session Beans En este caso, una única instancia del EJB es creada para toda la aplicación, por lo que todos los clientes compartirán dicha instancia y ésta mantiene el estado entre una invocación de un cliente y otra. En los casos anteriores (Stateless y Stateful), el container asegura que ninguna instancia estará sirviendo a más de un cliente en un momento dado. Sin embargo, en este caso sí puede darse esa situación y la misma instancia puede estar siendo accedida por más de un cliente al mismo tiempo. Por lo tanto, es necesario tener esto en cuenta y sincronizar las partes del código que no puedan ejecutarse concurrentemente. 3.2 Message Driven Beans Este tipo de EJB (también llamados MDB) no son invocados directamente por clientes, sino que los mismos envían mensajes asincrónicamente a un sistema de mensajería JMS (Java Message Service) para que sean tomados de allí y procesados por estos EJB. Esto se observa mejor en la Figura 7. 639

Hasta la versión 2.0 la especificación JEE soportaba solamente JMS, 2 pero a partir de la versión 2.1 se extendió a cualquier sistema que soporte JCA 3 (Java Connector Architecture). 4 Ejemplo de EJB A efectos de clarificar los conceptos vertidos en este documento se muestra la implementación de un servicio ofrecido por un EJB, incluyendo el acceso a los datos. Se describe un servicio para ingresar libros a una Base de Datos para lo cual existen dos EJB de tipo 640 Stateless: Uno que ofrece servicios de alto nivel será el que el cliente invoque para realizar la operación, cuyo código se observa en la Figura 8. Otro que brinda servicios de persistencia, que será usado por el anterior para acceder a los datos. El código es el que se muestra en la Figura 9. De esta forma, se logra encapsular la responsabilidad de cada componente, lo que favorece la extensibilidad de la aplicación. Como se puede ver en este ejemplo, el primer servicio actúa como cliente del segundo. Lo primero que hay que notar es que nunca se crea una instancia de LibroDAO, sino que directamente se usa, eso es porque el Container se encarga de inyectar las dependencias necesarias. En cuanto a LibroDAO, se declara el contexto de persistencia a través de una referencia a librounit (también se usa dependency injection aquí). Este contexto indica información acerca de la Base de Datos (su ubicación, usuario y contraseña, etc.) y debe estar declarado en forma externa a la aplicación. Puede ser declarado en un archivo llamado persistence.xml 2 JMS es un servicio brindado por Java para aplicaciones basadas en mensajes, es decir, que la comunicación entre cliente y servidor es asincrónica a través de colas de mensajería. 3 JCA es un concepto más amplio que JMS y refiere a todo lo relativo a conectividad entre servidores o entre cliente y servidor.

o a través de un DataSource (es decir, una definición de fuente de datos que se realiza directamente en el Servidor de Aplicaciones). 5 Bibliografía Java Community Process, Java EE 6 Specification http://jcp.org/aboutjava/communityprocess/final/jsr316/index.html JBoss Application Server http://www.jboss.org/jbossas/ GlassFish Server http://glassfish.java.net Oracle WebLogic Server http://www.oracle.com/technetwork/middleware/weblogic/overview/index.html IBM WebSphere http://www-01.ibm.com/software/websphere/ 641

Taller de formación Java EE Tema: Introducción a componentes de negocio (EJB) 2 da Parte 1 Introducción Como se vio en la primera parte de este curso introductorio, los EJB son componentes de software que ofrecen servicios a nivel de lógica de negocios y persistencia. Éstos no tienen entidad por sí mismos sino que deben ejecutarse en un Container, que es quien provee todos los servicios de base que el EJB necesita. Como se mostró, es posible a través de esta tecnología la implementación de sistemas de mediano y gran porte sin tener que implementar todas las complejidades que esto implica, como control de concurrencia, transaccionalidad, seguridad, etc. En esta segunda parte se profundizará en los distintos tipos de interfaces que ofrecen los EJB, así como en dos conceptos importantes a la hora de implementar una solución basada en JEE: manejo de transacciones y seguridad. 642 2 Cómo exponer un EJB Una vez desarrollado el componente EJB, se debe decidir cómo será expuesto, es decir, cómo es ofrecido este servicio para ser consumido por los clientes. Para esto existen tres opciones, las que se desarrollarán en este capítulo, que básicamente determinan la visibilidad que se le desea dar al servicio. 2.1 Interfaz Remota Una interfaz remota podrá ser accedida por cualquier cliente, tanto sea otro EJB que esté corriendo dentro del mismo Container como una aplicación externa, incluso el cliente puede estar ubicado en otra máquina física. Ya que una interfaz de este tipo puede ser accedida tanto remota como localmente, es común que las interfaces se definan como remotas en general. Además, si bien esto puede agregar un overhead del lado del Container, a futuro puede otorgar más flexibilidad a la aplicación. Téngase en cuenta que, aunque un sistema puede pensarse que va a ejecutar siempre en un único Container, es probable que en el futuro se decida (por razones de escalabilidad) distribuir en más de un servidor.

Si el cliente que consume un EJB remoto está ejecutando dentro del Container puede referenciarlo usando injection pero, si es una aplicación externa, debe buscar y obtener una referencia al servicio usando JNDI (Java Naming and Directory Interface). Para declarar una interfaz remota se anota como se observa en la Figura 1, y en la Figura 2 puede observarse el código de un cliente externo para ejecutar un EJB. 2.2 Interfaz Local Una interfaz de este tipo será accedida solamente por clientes que ejecuten dentro del mismo Container, es decir, que el servicio no es expuesto para ser consumido públicamente sino solamente por otros componentes conocidos o controlados. Si bien un cliente local es más eficiente que uno remoto, en general se considera que las interfaces locales generan un mayor acoplamiento en la aplicación ya que no permiten que la misma se distribuya en más de un servidor. Para declarar una interfaz local se usa la anotación @Local, como se observa en la Figura 3. 2.3 Sin interfaz Existe la posibilidad de que un EJB no implemente ninguna interfaz, ni local ni remota. En este caso se declara implícitamente una interfaz local con todos los métodos públicos. 2.4 Referencias a objetos remotos Como se observa en la Figura 4, cuando un cliente remoto interactúa con un EJB lo hace en realidad a través de una interfaz remota y usando los servicios provistos por el Container. Pero, qué sucede con los objetos que se pasan como parámetros o con el valor que puede retornar un método del EJB? Como se recordará, en Java cuando un método retorna un objeto está devolviendo, en realidad, una referencia a un objeto que se encuentra en el Heap. 1 Cómo se supone que el cliente remoto pueda acceder a un objeto si no tiene acceso al Heap en el que se encuentra dicho objeto? Nuevamente el Container se encarga de esto, para que lo que se devuelva al cliente no sea una referencia al heap local sino un proxy al objeto original, llamado stub. Este proxy actúa como si fuera el objeto original, pero cada vez que se le solicita algo envía la solicitud al objeto remoto original. 643 1 El Heap es un espacio de memoria utilizado por la JVM para almacenar objetos.

Para que todo esto funcione correctamente, tanto los parámetros como los valores devueltos por los métodos de las interfaces remotas deben ser serializables. 2 Esto es debido a que en cada invocación los objetos deben ser serializados para ser enviados remotamente. 3 Persistencia En la gran mayoría de los sistemas de información la persistencia es uno de los aspectos más importantes y donde hay que prestar más atención durante el desarrollo. En JEE existen dos conceptos básicos que simplifican mucho la gestión de la persistencia, los que se describen a continuación. 3.1 Transacciones El control de transacciones es un servicio importante brindado por el Container, ya que a través de una simple anotación éste se encarga de inyectar todo el código necesario para el manejo de transacciones, tanto desde el inicio de las mismas hasta el commit o rollback en caso de producirse excepciones. Como se sabe, una transacción es una unidad de trabajo formada por uno o más accesos a los datos. Esta unidad de trabajo debe ejecutarse exitosamente en su totalidad o no se ejecuta, no se permite que se ejecute parcialmente ya que esto generaría inconsistencias en la base de datos. En JEE las transacciones se definen a nivel de métodos de negocio, ya que son éstos los que corresponden al concepto de unidad de trabajo, aunque se puede definir también a nivel de EJB haciendo que todos sus métodos posean el mismo atributo. Para indicar al Container cómo debe manejar el inicio y fin de las transacciones se utiliza la anotación @TransactionAttribute, que puede tener uno de los valores indicados a continuación. 3.1.1 Required Si al invocar al método ya existe una transacción abierta se usa ésta (caso -a- en la Figura 5), en caso contrario se crea una nueva (la cual es cerrada una vez finalizada la ejecución del método, caso -b-). 644 2 Un objeto es serializable cuando es posible convertirlo a bytes para ser enviado a través de la red.

Este es el valor por defecto que toma el atributo @TransactionType en caso de no definirse ningún valor. 3.1.2 Requires_New Si al invocar el método ya existe una transacción abierta ésta queda en suspenso y crea una nueva. El método invocado utiliza esta nueva transacción y, al finalizar, vuelve a retomarse la anterior. 3.1.3 Mandatory Indica que el método necesita una transacción abierta por el llamante. En caso de que no haya una transacción abierta arroja una excepción. 3.1.4 Supports En caso de que exista una transacción abierta se utiliza y, en caso contrario, ninguna transacción es creada. 3.1.5 Not_Supported 645 En caso de que exista una transacción abierta ésta se suspende mientras se invoca a este método y, una vez finalizado, se retoma dicha transacción. Si no existe una transacción no es creada ninguna tampoco.

3.1.6 Never Si no existe una transacción no se crea tampoco una. Si ya existe una transacción abierta se arroja una excepción. En el cuadro de la Figura 11 se resumen las posibles situaciones según el atributo @TransactionType definido para el método invocado. 646 3.2 Entidades persistentes Las bases de datos relacionales no están orientadas a objetos sino a tablas relacionadas a través de dependencias funcionales, por lo que debe realizarse un mapeo entre las entidades que forman una aplicación (el modelo de dominio), y las tablas que van a persistir sus atributos. Este mapeo se especifica a través de las anotaciones que definen la Java Persistence API (JPA), la cual será estudiada en profundidad en otro documento. 4 Seguridad La seguridad en JEE es manejada tanto declarativamente como programáticamente en los casos que no es suficiente con la primera. Está basada en roles, es decir, que los usuarios pueden pertenecer a uno o más roles y sobre éstos se realizan los controles de acceso a los métodos de los EJB. Existen tres conceptos importantes para determinar si un acceso está permitido para ejecutar determinada operación: Autorización: permite o deniega la ejecución de determinada operación o método de un EJB. Está basada en la identificación y en la autenticación. Identificación: permite reconocer el usuario que está intentando ejecutar el método.

Autenticación: es el proceso de validación o verificación de que el usuario es realmente quien dice ser. En general, en una aplicación JEE el procedimiento de autenticación implica los siguientes pasos: Se le pide al usuario que ingrese su id y contraseña a través de una página web o de una aplicación de otro tipo. Estas credenciales son validadas contra un proveedor JAAS (Java Authentication and Authorization Service). Si la autenticación es válida, el cliente recibe un objeto llamado token (o principals), el cual será usado en forma transparente en cada invocación a métodos de EJB para indicarle al Container quién es el usuario que está realizando la operación y que el mismo está autorizado. En base a dicho token el Container también obtendrá el o los roles a los que pertenece el usuario y, en base a eso, determinará si puede o no ejecutar los métodos invocados. Como se puede ver, la validación de usuario y contraseña se realiza a nivel de la capa Web, y el EJB recibe ya un objeto que indica que el usuario es válido (aunque todavía no ha decidido si dicho usuario puede invocar al método solicitado). 4.1 Seguridad declarativa Como se mencionó, la especificación de los permisos para ejecutar los métodos de los EJB se realizan a nivel de roles autorizados para eso. Esto se hace a través de la anotación @RolesAllowed, la cual se puede utilizar tanto en métodos como en toda la clase (en este caso indica que los roles especificados pueden acceder a todos sus métodos). En la Figura 12 puede verse un ejemplo de un EJB en el que se especifica esta restricción. Además de las anotaciones mencionadas, es posible especificar @PermitAll para indicar que un método es accesible a todos los roles o @DenyAll para indicar que un método no es accesible a ningún rol. 647

4.2 Seguridad programática En algunas ocasiones no son suficientes las anotaciones mencionadas para permitir o denegar el acceso a un método. En estos casos es necesario utilizar programación para obtener más información. Si bien el uso de esta metodología excede el alcance de este documento en la Figura 13 se observa un ejemplo de uso del API de seguridad de JEE a efectos ilustrativos. 648

Introducción a Java Server Faces (JSF) 1 era Parte 1 Introducción 1.1 Aplicaciones Web Una aplicación Web es una aplicación que es capaz de interactuar con un cliente que se ejecuta en un navegador de Internet (como Firefox, Chrome o Internet Explorer). Estas aplicaciones generan contenido HTML dinámicamente a través de la invocación por parte de los clientes de pedidos HTTP (HTTP Request), los que son atendidos por un Web Container (como Tomcat) que es el entorno de ejecución de las aplicaciones Web. En la Figura 1 se observa más claramente el funcionamiento de una aplicación Web tradicional. Los servlets son simples clases Java capaces de atender pedidos HTTP y retornar una respuesta. Muchas veces, parte del contenido de una aplicación Web es estático (como por ej. imágenes), estos archivos son retornados directamente por el Container sin intervención de ningún servlet. 1.2 Java Server Faces 1.2.1 Descripción Java Server Faces (o JSF, [1]) es un framework provisto por la plataforma Java EE para desarrollar aplicaciones Web y está compuesto por dos grandes módulos: Librerías de tags para agregar componentes a páginas Web. Una API para manejar el estado de los componentes, escuchar eventos, realizar validaciones, etc., a través de los llamados managed beans (también llamados backing beans). 649

Una aplicación JSF está, entonces, compuesta por los siguientes elementos: Una o más páginas HTML, utilizadas generalmente como contenedores de las páginas JSF. Un conjunto de páginas JSF, que son las que contienen los tags. Un conjunto de managed beans, componentes del lado del servidor que mantienen el estado de los componentes representados en las páginas, entre otras tareas. Un archivo descriptor de la aplicación (llamado web.xml). Archivos de recursos, como imágenes, javascripts, css, etc. Opcionalmente, es posible incluir un archivo llamado faces-config.xml, donde se especifican componentes personalizados de validación, conversiones, etc. 1.2.2 Facelets Es un lenguaje [2] expresado como un conjunto de tags que permite construir páginas a través de la composición de otras páginas, formando árboles jerárquicos donde las páginas se anidan unas dentro de otras. Es común utilizar tags facelets para organizar las páginas JSF, de forma de simplificar el desarrollo y facilitar la reutilización de componentes. Por ejemplo, es posible definir una plantilla formada por un cabezal, un cuerpo y un pie, haciendo que el cabezal y pie se mantengan a lo largo de la aplicación y cambiando solamente el cuerpo de la misma. 1.2.3 Ejemplo A efectos de clarificar los conceptos antes de continuar profundizando aspectos teóricos, en la Figura 2 se muestra parte de una página JSF, mientras que en la Figura 3 se observa parte del código del managed bean correspondiente. 650

2 Patrón Model-View-Controller (MVC) 2.1 MVC Model-View-Controller (o MVC, [3]) es un patrón de diseño de aplicaciones que permite la separación (desacoplamiento) entre los componentes de la misma de acuerdo a sus responsabilidades: Model: contiene los datos o interactúa directamente con el componente encargado de obtenerlos. View: muestra los datos al usuario de una aplicación y permite su interacción. Un modelo puede tener asociadas más de una vista, dependiendo de cómo se quieran mostrar los datos en cada caso. Controller: es el que recibe los pedidos del usuario, invoca a las operaciones del modelo necesarias y retorna una nueva vista. De esta forma, se simplifica el desarrollo y mantenimiento de la aplicación, ya que cada componente tiene claramente delimitado su campo de acción. En la Figura 4 se muestra un diagrama de este patrón de diseño. 2.2 MVC aplicado a JSF Java Server Faces fue diseñado de acuerdo al patrón MVC, por lo que respeta claramente la separación entre modelo, vista y controlador, como se observa en la Figura 5. Cuando un usuario solicita una página JSF, este pedido es capturado por el FacesServlet (Controller), 651

obtiene la información necesaria de los Managed Beans (Model) y arma la respuesta en base a la página JSF (View) que corresponda. FacesServlet es el servlet provisto por el framework de JSF para atender todas las solicitudes de los clientes. Es esta clase la que se encarga de iniciar el ciclo de vida de cada solicitud. El concepto de ciclo de vida se estudia con más detalle en el capítulo siguiente. 3 Ciclo de vida Es importante comprender el ciclo de vida de un request a una aplicación JSF para poder entender mejor la forma en que se vinculan los elementos de la aplicación. A través del ciclo que se explicará en esta sección, se ejecutan todas las tareas que, de otra forma, debería escribir el desarrollador como ser validaciones, actualización del modelo de datos, etc. De todas formas, es posible intervenir o modificar cada uno de los pasos del ciclo de vida, si es necesario modificar el comportamiento para adaptarlo a alguna necesidad específica. En la Figura 6 se observa el diagrama de los eventos que ocurren en cada invocación a una página JSF, los que se describirán brevemente en esta sección. En [4] puede ver una descripción más detallada de lo que ocurre en las fases de conversión y validación. 652 1. Restore View (recuperar vista) Se crea una estructura (llamada component tree) conteniendo todos los elementos de la vista y se guarda en un objeto llamado FacesContext, el cual está disponible durante todo el ciclo de vida. 2. Apply Request Values (aplicar valores de la petición) Para cada elemento del component tree se obtiene su estado (o sea, su valor en el formulario enviado) y se guarda en el FacesContext. Si ocurren errores durante la conversión de datos (por ejemplo, se ingresaron valores alfanuméricos en un campo numérico), se generan errores y se salta directamente al paso 6 para generar la respuesta. 3. Process Validations (procesar validaciones) Se realizan todas las validaciones especificadas en los componentes contra los valores obtenidos en la fase anterior. Si hay componentes que no pasan la validación se generan errores y se salta directamente al paso 6 para generar la respuesta. Las condiciones de validación son expresadas en los componentes en forma declarativa, como se observa en la Figura 7.