La siguiente fase del dise�o de una aplicaci�n web es el dise�o de la arquitectura de alto nivel. Esto implica subdividir la aplicaci�n en componentes funcionales y particionar estos componentes en capas. El dise�o de la arquitectura de alto nivel es neutral a las tecnolog�as utilizadas.
�Arquitectura Multi-capa
Una arquitectura multicapa particiona todo el sistema en distintas unidades funcionales: cliente, presentaci�n, l�gica-de-negocio, integraci�n, y sistema de informaci�n empresarial (EIS). Esto asegura una divisi�n clara de responsabilidades y hace que el sistema sea m�s mantenible y extensible. Los sistemas con tres o m�s capas se han probado como m�s escalables y flexibles que un sistema cliente-servidor, en el que no existe la capa central de l�gica-de-negocios.
La capa del cliente es donde se consumen y presentan los modelos de datos. Para una aplicaci�n Web, la capa cliente normalmente es un navegador web. Los clientes peque�os basados-en-navegador no contienen l�gica de presentaci�n; se trata en la capa de presentaci�n.
La capa de presentaci�n expone los servicios de la capa de l�gica-de-negocio a los usuarios. Sabe c�mo procesar una petici�n de cliente, c�mo interact�ar con la capa de l�gica-de-negocio, y c�mo seleccionar la siguiente vista a mostrar.
La capa de la l�gica-de-negocio contiene los objetos y servicios de negocio de la aplicaci�n. Recibe peticiones de la capa de presentaci�n, procesa la l�gica de negocio basada en las peticiones, y media en los accesos a los recursos de la capa EIS. Los componenes de la capa de l�gica-de-negocio se benefician de la mayor�a de lo servicios a nivel de sistema como el control de seguridad, de transaciones y de recursos.
La capa de integraci�n es el puente entre la capa de l�gica-de-negocio y la capa EIS. Encapsula la l�gica para interact�ar con la capa EIS. Algunas veces a la combinaci�n de las capas de integraci�n y de l�gica-de-negocio se le conoce como capa central.
Los datos de la aplicaci�n persisten en la capa EIs. Contiene bases de datos relacionales, bases de datos orientadas a objetos, y sistemas antiguos.
�Dise�o de la Arquiectura de JCatalog
La siguiente figura muestra el dise�o de la arquitectura de alto nivel de JCatalog y c�mo se acopla en la arquitectura multi-capa.
La aplicaci�n utiliza una arquitectura multi-capa no-distribuida. La figura anterior muestra el particionamiento de las capas de la aplicaci�n y las tecnolog�as elegidas para cada capa. Tambi�n sierve como diagrama de ejemplo de despliegue de la aplicaci�n. Para una arquitectura colocada, las capas de presentaci�n, de l�gica-de-negocio y de integraci�n est�n f�sicamente localizadas en el mismo contenedor Web. Interfaces bien-definidos aislan las responsabilidades de cada capa. La arquitectura colocada hace que la aplicaci�n sea m�s simple y escalable.
Para la capa de presentaci�n, la experiencia muestra que la mejor pr�ctica es elegir un marco de trabajo de aplicaciones Web existente y probado en vez de dise�ar y construir un marco de trabajo personalizado. Hay varios marcos de trabajo de este tipo entre los que elegir: Struts, WebWork, y JSF. Nosotros utilizaremos JSF para JCatalog.
Se pueden utilizar EJB (Enterprise JavaBeans) o POJO (plain old Java objects) para construir la capa de l�gica-de-negocio. EJB con sus interfaces remotos es una mejor elecci�n si la aplicaci�n es distribuida. Como JCatalog es una aplicaci�n web t�pica que no requiere acceso remoto, se utilizar� POJO con la ayuda del marco de trabajo Spring, para esta capa.
La capa de integraci�n maneja la persistencia de los datos con la base de datos relacional. Se pueden utilizar diferentes aproximaciones para implementar la capa de integraci�n:
- JDBC puro (Java DataBase Connectivity):
Es la aproximaci�n m�s flexible; sin embargo es dif�cil trabajar con JDBC de bajo nivel, y un mal c�digo JDBC no tiene un rendimiento muy bueno. - Beans de entidad:
Un Bean de entidad con persistencia manejada por el contenedor (CMP) es una forma costosa de aislar el c�digo de acceso-a-datos y manejar el mapeo O/R (objecto-relacional) para persistencia de datos. Es una aproximaci�n centrada en el servidor de aplicaciones. Un bean de entidad no ata la aplicaci�n a un tipo particular de base de datos, pero si ata la aplicaci�n al contenedor EJB. - Marco de Trabajo de Mapeo O/R:
Un marco de trabajo de mapeo O/R toma una aproximaci�n centrada en el objeto para implementar la persistencia de datos. Una aplicaci�n de este tipo es f�cil de desarrollar y altamente portable. Existen varios marcos de trabajo bajo este dominio: JDO (Java Data Objects), Hibernate, TopLink, y CocoBase son unos pocos ejemplos. En la aplicaci�n de ejemplo se utiliza Hibernate.
Ahora discutiremos los problemas de dise�o asociados con cada capa de la aplicaci�n. Como JSF es una tecnolog�a relativamente nueva, aconsejo su utilizaci�n.
�La Capa de Presentaci�n y JavaServer Faces
La capa de presentaci�n recoge la entrada del usuario, presenta los datos, controla la navegaci�n por las p�gina y delega la entrada del usuario a la capa de la l�gica-de-negocio. La capa de presentaci�n tambi�n puede validar la entrada del usuario y mantener el estado de sesi�n de la aplicaci�n. En las siguientes secciones, discutiremos las consideraciones de dise�o y los patrones de la capa de presentaci�n, y la raz�n porque la que he elegido JSF para implementar JCatalog.
�Model-View-Controller (MVC)
MVC es el patr�n de dise�o arquitectural recomendado para aplicaciones interactivas Java. MVC separa los conceptos de dise�o, y por lo tanto decrementa la duplicaci�n de c�digo, el centralizamiento del control y hace que la aplicaci�n sea m�s extensible. MVC tambi�n ayuda a los desarrolladores con diferentes habiliades a enfocarse en sus habilidades principales y a colaborar a trav�s de interfaces claramente definidos. MVC es el patr�n de dise�o arquitectural para la capa de presentaci�n.
�JavaServer Faces
JSF es un marco de trabajo de componentes de interface de usuario del lado del servidor para aplicaciones Web basadas en Java. JSF contiene un API para representar componentes UI y manejar sus estados, manejar sus eventos, �a validaci�n del lado del servidor, y la conversi�n de datos, definir la navegaci�n entre p�ginas, soportar internacionalizaci�n y accesibilidad; y proporcionar extensibilidad para todas estas caracter�sticas. Tambi�ne contien dos librer�as de etiquetas JSP (JavaServer Pages) personalizadas para expresar componentes UI dentro de una p�gina JSP y para conectar componentes a objetos del lado del servidor.
�JSF y MVC
JSF encaja bien en la arquitectura de la capa de presentaci�n basada en MVC. Ofrece una clara separaci�n entre el comportamiento y la presentaci�n. Une los familiares componentes UI con los conceptos de la capa-Web sin limitarnos a una tecnolog�a de script o lenguaje de marcas particular.
Los beans que hay tras JSF son la capa de modelo (en una secci�n posterior hablaremos m�s de estos beans). Tambi�n contienen acciones, que son una extensi�n de la capa del controlador y delegan las peticiones del usuario a la capa de la l�gica-de-negocio. Observe, que desde la prespectiva de la arquitectura general de la aplicaci�n, tambi�n se puede referir a la capa de l�gica-de-negocio como la capa del modelo. Las p�ginas JSP con etiquetas JSF personalizadas son la capa de la vista. El Servlet Faces proporciona la funcionalidad del controlador.
��Por qu� JSF?
JSF no es s�lo otro marco de trabajo Web. Las siguientes caracter�sticas diferencian a JSF de otros marcos de trabajo:
- Desarrollo de una Aplicaci�n Web Orientada a Objetos al Estilo Swing:
El modelo de componentes UI con estado del lado del servidor con oyentes/manejadores de eventos inicia el desarrollo de aplicaciones Web orientadas a objetos. - Control de Beans-de-Respaldo:
Los beans de respaldo son componentes JavaBeans asociados con componentes UI utilizados en la p�gina. El control de beans-de-respaldo separa la definici�n de los objetos componentes del UI de los objetos que realizan el procesamiento espec�fico de la aplicaci�n y que adem�s contienen los datos. La implementaci�n de JSF almacena y maneja estos ejemplares de beans de respaldo en el �mbito apropiado. - Modelo de componentes UI extensible:
Los componentes UI de JSF son elementos configurables, reutilizables que componen los intefaces de usuario de aplicaciones JSF. Se puede extender un componentes UI est�ndar y desarrollar componentes m�s complejos, como barras de men� y �rboles. - Modelo de Renderizado Flexible:
Un renderizador separa la vista y la funcionalidad de los componentes UI. Se pueden crear y utilizar varios renderizadores para definir diferentes apariencias del mismo componente para el mismo o diferentes clientes. - Modelo de Conversi�n y Validaci�n Extensible:
Basados en los convertidores y validadores est�ndar, se pueden desarrollar convertidores y validadores personalizados, que proporcionan un mejor modelo de protecci�n.
A pesar de su potencia, JSF no esta madura a�n. Los componentes, convertidores y validadores que vienen con JSF son b�sicos. Y el modelo de validaci�n por-componente no puede manejar validaciones muchos-a-muchos entre componentes y validadores. Adem�s, las etiquetas personalizadas de JSF no se pueden integrar con JSTL (JSP Standard Tag Library) simult�neamente.
En la siguientes secciones, describiremos varios aspectos claves y decisiones de dise�o que he realizado cuando implement� JCatalog con JSF. Empezar� con una discusi�n de la definici�n de beans manejados y beans de respaldo en JSF. Luego presentar� c�mo manejar la seguridad, la paginaci�n, el cach�, la subida de ficheros, la validaci�n y la personalizaci�n de mensajes de error en JSF.
�Bean Manejado, Bean de Respaldo, objeto vista y Modelo de objeto de dominio
JSF presenta dos nuevos t�rminos: managed bean (bean manejado) y backing bean (bean de respaldo). JSF proporciona una fuerte facilidad de bean manejado. Los objetos JavaBean manejados por una implementaci�n JSF se llaman beans manejados. Un bean manejado describe como se crea y se maneja un bean. No tiene nada que ver con las funcionalidades del bean.
El bean de resplado define las propiedades y las l�gicas de manejo asociadas con los componentes UI utilizados en la p�gina. Cada propiedad del bean de respaldo est� unida a un ejemplar de un componente o a su valor. Un bean de respaldo tambi�n define un conjunto de m�todos que realizan funciones para el componente, como validar los datos del componente, manejar los eventos que dispara el componente, y realizar el procesamiento asociado con la navegaci�n cuando el componente se activa.
Una t�pica aplicaci�n JSF acopla un bean de repaldo con cada p�gina de la aplicaci�n. Sin embargo, algunas veces en el mundo real, forzar una relaci�n uno-a-uno entre el bean de respaldo y la p�gina no es la soluci�n ideal. Puede causar problemas como la duplicaci�n de c�digo. En el escenario del mundo real, varias p�ginas podr�an necesitar compartir el mismo bean de respaldo detr�s de la escena. Por ejemplo, en JCatalog, las p�ginas CreateProduct y EditProduct comparten la misma definicion de ProductBean.
Un objeto view (vista) es un objeto modelo utilizado espec�ficamente en la capa de presentaci�n. Contiene los datos que debe mostrar en la capa de la vista y la l�gica para validar la entrada del usuario, manejar los eventos, e interact�ar con la capa de l�gica-de-negocio. El bean de respaldo es el objeto vista en una aplicaci�n basadas en JSF. Bean de respaldo y objeto vista son t�rminos intercambiables en este tutorial.
En comparaci�n con la aproximaci�n ActionForm y Action de Struts, el desarrollo con beans de respaldo de JSF sigue unas mejores pr�cticas de dise�o orientado a objetos. Un bean de respaldo no s�lo contiene los datos a ver, tambi�n el comportamiento relacionado con esos datos. En Struts, Action y ActionForm contienen los datos y la l�gica por separado.
Todos hemos o�do hablar del modelo de objeto de dominio. Entonces, �cu�l es la diferenica en el modelo de objeto de dominio y un objeto vista? En una sencilla aplicaci�n Web, un modelo de objeto de dominio se puede utilizar entre capas, sin embargo, en aplicaciones Web m�s complejas, se necesita utilizar un modelo de objeto vista separado. Los modelos de objeto de dominio son como objetos de negocio y deber�an pertenecer a la capa de l�gica-de-negocio. Contiene los datos de negocio y la l�gica de negocio asociados con el objeto de negocio espec�fico. Un objeto vista contiene datos espec�ficos de la presentaci�n y el comportamiento. ProductListBean de JCatalog ofrece un buen ejemplo. Contiene los datos y la l�gica espec�fica de la capa de presentaci�n; es decir datos y l�gica relacionados con la paginaci�n. La desventaja de separar los objetos vista del modelo de objetos de dominio es que debe ocurrir un mapeo de datos entre los dos modelos de objetos. En JCatalog, ProductBeanBuilder y UserBeanBuilder usan las Commons BeanUtils para implementar el mapeo de datos.
�Seguridad
Actualmante, JSF no tiene una caracter�stica de seguridad interna. Los requirimientos de seguridad para la aplicaci�n de ejemplo son b�sicos: s�lo se necesita la autentificaci�n basada en nombre de usuario y password para que el usuario entre en la intranet de administraci�n, y no se requiere autorizaci�n.
Se han propuesto varias alternativas para manejar la autentificaci�n de usuarios en JSF:
- Usar un bean de respaldo:
Esta es una soluci�n simple. Sin embargo, ata los beans de respaldo un �rbol de herencia espec�fico. - Usar un decorador ViewHandler JSF:
De esta forma, la l�gica est� fuertemente unida a una tecnolog�a espec�fica de capa Web. - Usar un filtro servlet:
Una aplicaci�n JSF no es diferente de cualquier otra aplicaci�n Web basada en Java. Hace que un filtro sea el mejor lugar para manejar el chequeo de autentificaci�n. De esta forma, la l�gica de autentificaci�n de desacopla de la aplicaci�n web.
En la aplicaci�n de ejemplo, la clase SecurityFilter maneja la autentificaci�n de los usuarios. Actualmente, los recursos protegidos son s�lo tres p�ginas, y sus localizaciones est�n codificadas dentro de la clase Filter por simplicidad. Se pueden realizar mejoras para externalizar las reglas de seguridad y los recursos protegidos a un fichero de configuraci�n.
�Paginaci�n
La aplicaci�n de un cat�logo requiere paginaci�n. La capa de presentaci�n puede manejar la paginaci�n, lo que significa que los datos se debe recuperar y almacenar en esta capa. La paginaci�n tambi�n se puede manejar desde la capa de l�gica-de-negocio, la capa de integraci�n o incluso desde la capa de EIS. Una de las presunciones de la aplicaci�n JCatalog era que no pod�a haber m�s de 500 productos en el cat�logo. La informaci�n de todos los productos puede caber en la sesi�n de usuario. La l�gica de paginaci�n est� en la clase ProductListBean. El par�metro relacionado con la paginaci�n "product per page" se configura mediante la facilidad del bean manejado de JSF.
�Cach�
El Cach� es una las tecnicas m�s importantes para mejorar el rendimiento de las aplicaciones web. El cach� se puede conseguir en muchas capas dentro de la arquitectura de una aplicaci�n. Es m�s beneficioso cuando una capa arquitectural puede evitar llamadas a la capa de al lado. La facilidad del bean manejado de JSF hace que el cach� sea m�s sencillo en la capa de presentaci�n. Cambiando el �mbito del bean manejado, los datos que �l contiene se pueden cachear dentro de diferentes �mbitos.
La aplicaci�n de ejemplo utiliza un cach� de dos niveles. El primer nivel de cach� existe dentro de la capa de l�gica-de-negocio. La clase CachedCatalogServiceImpl mantiene un cach� de lectura/escritura para todos los productos y categor�as. Entonces, el cach� de primer nivel es un cach� de lectura/escritura en el �mbito de la aplicaci�n.
Para simplificar la l�gica de paginaci�n y as� mejorar la velocidad de la aplicaci�n, los productos tambi�n son cacheados dentro de la capa de presentaci�n en el �mbito de la sesi�n. Cada usuario mantiene su propio ProductListBean dentro de la sesi�n. Las costes de esta aproximaci�n son la memoria del sistema y datos obsoletos. Durante una sesi�n de usuario, �ste podr�a ver datos de un cat�logo obsoleto si el administrador actualiza el cat�logo. Sin embargo, basado en las presunciones, como no existen m�s de 500 productos y el cat�logo no se actualiza de forma frecuente, deber�amos poder asumir estos costes.
�Subida de Ficheros
La implementaci�n de referencia de JSF de Sun no soporta subida de ficheros. Struts tiene buenas capacidades para esto, sin embargo se necesita la librer�a de integraci�n Struts-Faces para utilizar esta caracter�stica. En JCatalog, se asocia una imagen con cada producto. Despu�s de que el usuario crea un nuevo producto, debe subir la imagen asociada con �l. La imagen es almacenada dentro del sistema de ficheros del servidor de aplicaciones. El ID del producto es el nombre de la imagen.
La aplicaci�n de ejemplo utiliza el servlet <input type="file">, y el API de subida de ficheros de Jakarta Commons, para implementar una utilidad sencilla. Esta utilidad toma dos par�metros, el directorio de im�genes de producto y la result page de la imagen subida. Los dos son configurables mediante ApplicationBean. Puede ver m�s detalles en la clase FileUploadServlet.
�Validaci�n
Los validadores est�ndar que vienen con JSF son b�sicos y podr�an no cumplir con los requerimientos del mundo real. Desarrollar sus propios validadores JSF es sencillo. Yo he desarrollado el validador SelectedItemsRange con una etiqueta personalizada en la aplicaci�n de ejemplo. Valida el n�mero de �tems seleccionados por el componente UI UISelectMany:
<h:selectManyListbox value="#{productBean.selectedCategoryIds}" id="selectedCategoryIds">
�� <catalog:validateSelectedItemsRange minNum="1"/>
�� <f:selectItems value="#{applicationBean.categorySelectItems}" id="categories"/>
</h:selectManyListbox>
�Personalizaci�n de los Mensajes de Error
En JSf, se pueden configurar paquetes de recursos y personalizar los mensajes de error para convertidores y validadores. El paquete de recursos se configura dentro de faces-config.xml:
<message-bundle>catalog.view.bundle.Messages</message-bundle>
Las parejas clave-valor de los mensajes de error se a�aden al fichero Message.properties:
#conversion error messages javax.faces.component.UIInput.CONVERSION=Input data is not in the correct type. #validation error messages javax.faces.component.UIInput.REQUIRED=Required value is missing.
�La Capa de L�gica-de-Negocio y el Marco de Trabajo Spring
Los objetos y servicios de negocio existen en la capa de l�gica-de-negocio. Un objeto de negocio no s�lo contiene datos, tambi�n la l�gica asociada con ese objeto espec�fico. En la aplicaci�n de ejemplo se han identificado tres objetos de negocio: Product, Category, y User.
Los servicios de negocio interact�an con objetos de negocio y proporcionan una l�gica de negocio de m�s alto nivel. Se deber�a definir una capa de interface de negocio formal, que contenga los interfaces de servicio que el cliente utilizar� directamente. POJO, con la ayuda del marco de trabajo Spring, implementar� la capa de l�gica-de-negocio de la aplicaci�n JCatalog. Hay dos servicios de negocio: CatalogService contiene la l�gica de negocio relacionada con el manejo del cat�logo, y UserService contiene la l�gica de manejo del usuario.
Spring est� basado en el concepto de inversi�n de control (IoC). Entre las caracter�sticas de Spring utilizadas en la aplicaci�n de ejemplo se incluyen:
- Manejo de Beans con contexto de aplicaci�n:
Spring puede organizar de forma efectiva nuestros objetos de la capa central y manejar las conexiones por nosotros. Spring puede eliminar la proliferaci�n de solitarios y facilita unas buenas pr�cticas de programaci�n orientada a objetos, por ejemplo utilizando interfaces. - Manejo de Transaciones Declarativo:
Spring utiliza AOP (aspect-oriented programming) para ofrecer manejo de transaciones declarativo sin utilizar un contenedor EJB. De esta forma, el control de transaciones se puede aplicar a cualquier POJO. El control de transaciones de Spring no est� atado a JTA (Java Transaction API) y puede funcionar con diferentes estrategias de transaci�n. En la aplicaci�n de ejemplo se utiliza el manejo de transaci�n declarativo con Hibernate. - �rbol de Excepciones de Acceso a Datos:
Spring proporciona un magn�fico �rbol de excepciones en lugar de SQLException. Para poder utilizar este �rbol de excepciones, se debe definir un traductor de excepciones de acceso a datos dentro del fichero de configuraci�n de Spring:
<bean id="jdbcExceptionTranslator" class= "org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator"> �� <property name="dataSource"> ������<ref bean="dataSource"/> �� </property> </bean>En la aplicaci�n de ejemplo, si se inserta un producto nuevo con el ID duplicado, se lanza una DataIntegrityViolationException. La excepci�n es capturada y relanzada como una DuplicateProductIdException. De esta forma, la DuplicateProductIdException se puede manejar de forma diferente a cualquier otra excepci�n de acceso a datos.
- Integraci�n con Hibernate:
Spring no nos fuerza a utilizar su potente caracter�stica de abstracci�n JDBC. Se integra bien con marcos de trabajo de mapeo O/R, especialmente con Hibernate. Spring ofrece un manejo seguro y eficiente de sesiones Hibernate, maneja la configuraci�n de la SessionFactorie de Hibernate y las fuentes de datos JDBC en el contexto de la aplicaci�n, y hace que la aplicaci�n sea m�s f�cil de testear.
�La Capa de Integraci�n e Hibernate
Hibernate es un marco de trabajo de mapeo O/R Open Source que evita la necesidad de utilizar el API JDBC. Hibernate soporta la mayor�a de los sistemas de bases de datos SQL. El Hibernate Query Language, dise�ado como una extensi�n m�nima, orientada a objetos, de SQL, proporciona un puente elegante entre los mundos objeto y relacional. Hibernate ofrece facilidades para recuperaci�n y actualizaci�n de datos, control de transaciones, repositorios de conexiones a bases de datos, consultas program�ticas y declarativas, y un control de relaciones de entidades declarativas.
Hibernate es menos invasivo que otros marcos de trabajo de mapeo O/R. Se utilizan Reflection y la generaci�n de bytecodes en tiempo de ejecuci�n, y la generaci�n del SQL ocurre en el momento de la arrancada. Esto nos permite desarrollar objetos persistentes siguiendo el lenguaje com�n de Java: incluyendo asociaci�n, herencia, polimorfismo, composici�n y el marco de trabajo Collections de Java. Los objetos de negocio de la aplicaci�n de ejemplo son POJO y no necesitan implementar ning�n interface espec�fico de Hibernate.
�Data Access Object (DAO)
En JCatalog se utiliza el patr�n DAO. Este patr�n abstrae y encapsula todos los accesos a la fuente de datos. La aplicaci�n tiene dos interfaces DAO: CatalogDao y UserDao. Sus clases de implementaci�n, HibernateCatalogDaoImpl y HibernateUserDaoImpl contienen l�gica espec�fica de Hibernate para manejar los datos persistentes.