Arquitectura de Aplicaciones · Arquitectura de Aplicaciones Sí, una profesión muy respetable....

Arquitectura de Aplicaciones

Índice

1 Arquitectura de Aplicaciones....................................................................................... 2

1.1 Arquitectura del Software........................................................................................ 2

1.2 Rol del Arquitecto....................................................................................................5

1.3 Capas y Niveles........................................................................................................7

1.4 Requisitos No Funcionales.................................................................................... 14

1.5 Arquitectura Ágil................................................................................................... 18

1.6 Roadmap................................................................................................................ 21

2 Caché.......................................................................................................................... 24

2.1 Introducción........................................................................................................... 24

2.2 Problemas de la Caché........................................................................................... 24

2.3 ¿Cachear o No Cachear?........................................................................................25

2.4 JPA con Hibernate y la Caché............................................................................... 28

2.5 OSCache................................................................................................................ 37

2.6 Caché en la Biblioteca jTech................................................................................. 41

2.7 Para Saber Más...................................................................................................... 46

3 Arquitecturas Java EE................................................................................................ 47

3.1 Bloques Arquitectónicos........................................................................................47

3.2 Arquitectura y Java EE.......................................................................................... 52

3.3 Propuestas de Arquitecturas Java EE.....................................................................57

3.4 Para Saber Más...................................................................................................... 67

Copyright © 2008-2009 Depto. CCIA All rights reserved.

1. Arquitectura de Aplicaciones

Sí, una profesión muy respetable. Profesionales que estudian el problema antes deresolverlo. ¿Habéis visto a algún arquitecto levantar una pared antes de estudiar cual es lamejor orientación de una vivienda, estudiar si el suelo va a soportar 3 pisos en altura, si lacalidad de los materiales a emplear es inferior a la deseada por el comprador, etc... ?

Así pues, tenemos una similitud con el mundo "del ladrillo". Antes de construir cualquiercasa, se necesita un proyecto de arquitectura donde se estudian y reflejan todos loselementos de la futura edificación. ¿Por qué cuando vamos a realizar una aplicación norealizamos primero un plano de la arquitectura del software?

1.1. Arquitectura del Software

Existen muchas y diferentes definiciones de la palabra arquitectura. La Real AcademiaEspañola de la Lengua la define como el "Arte de proyectar y construir edificios".También ofrece otra entrada relacionada con la informática como la "Estructura lógica yfísica de los componentes de un computador".

El concepto de Arquitectura del Software (AS) nace a finales de los años 60, cuandoEdsger Dijkstra propuso que se estableciera una estructuración correcta de los sistemas desoftware antes de lanzarse a programar, escribiendo código de cualquiera manera.

Durante esta sesión y a lo largo del presente curso presentamos una variación de estasdefiniciones más orientada al software.

La Arquitectura del Software se refiere a la representación más abstracta de loscomponentes y comportamientos de un sistema. Se trata de la visión de más alto nivel deun sistema en partes. Idealmente, la arquitectura no contiene detalles de laimplementación (se deja para los desarrolladores). El arquitecto trata con la informacióndel problema y diseña una solución, la cual satisface los requerimientos funcionales y nofuncionales del cliente, siendo una solución flexible que evoluciona cuando losrequerimientos cambian.

Es muy útil pensar en el concepto de arquitectura como el esqueleto para construir unsistema. De este modo, la arquitectura compone un conjunto de principios, estándares,protocolos, frameworks y directivas que dirigen los diversos elementos del diseño de todaaplicación.

Pregunta¿Por qué es tan importante ahora el concepto de arquitectura, si en el pasado no existía?

Antes de la entrada de Internet, la creación de la arquitectura de un sistema era 10 vecesmás fácil que el día de hoy. Antes de la explosión de Internet, un arquitecto creaba una


2Copyright © 2008-2009 Depto. CCIA All rights reserved.

arquitectura para gestionar los usuarios internos de una compañía (alrededor de 100). Sinembargo, Internet ha abierto los recursos de la compañía a sus clientes, lo que significaque el arquitecto ahora debe crear una arquitectura de sistema que pueda gestionar a milesde usuarios con patrones de uso y comportamiento impredecibles.

Además, Internet ha facilitado la conexión de diferentes aplicaciones entre sí quecolaboran compartiendo información y realizando procesos autónomos o distribuidosentre sistemas heterogéneos.

Por lo tanto, la respuesta esta en la escalabilidad y la distribución de las aplicaciones. Lasiguiente figura muestra un ejemplo de un sistema altamente distribuido.

Sistema Altamente Distribuido

1.1.1. Crear una Arquitectura

Definir la arquitectura es un proceso creativo. Uno de los retos del arquitecto es equilibrarla creatividad con el pragmatismo mediante las tecnologías disponibles en forma demodelos, frameworks y patrones. La arquitectura puede hacer referencia a un producto (laarquitectura de un edificio), o hacer referencia a un método o estilo (la arquitectura de unrascacielos). Además, la arquitectura debe ser reconfigurable para responder tanto a unentorno dinámico como a las peticiones por parte del cliente.

Cuando creamos una arquitectura describimos la estructura del sistema a construir, ycomo dicha estructura ofrece soporte a los requisitos de negocio y a los no funcionales. Sepuede definir la estructura del sistema como el mecanismo que el sistema utiliza pararesolver problemas comunes del sistema. Un mecanismo es una capacidad que ofrecesoporte a los requisitos de negocio de un modo consistente y uniforme.

Por ejemplo, la persistencia es una mecanismo que debería utilizarse consistentemente a



lo largo del sistema. Esto significa que cada vez que el sistema utiliza la persistencia, serealiza del mismo modo. Al definir la persistencia como un mecanismo arquitectónico, seofrece un método por defecto de gestionar la persistencia que todos los diseñadores debenseguir e implementar de un modo consistente.

Los mecanismos arquitectónicos, tales como persistencia, distribución, comunicación,gestión de transacciones, y seguridad son las infraestructuras sobre las cuales seconstruirá el sistema y se deben definir en la arquitectura.

1.1.1.1. ¿Qué significa crear una arquitectura?

Significa transformar los problemas de negocio en soluciones técnicas (incluyendohardware y software), lo que implica responsabilidades tanto tecnológicas como degestión.

• Responsabilidades Tecnológicas• identificar los casos de uso significantes para la arquitectura• guiar el desarrollo de prototipos

• Responsabilidades de Gestión• ofrecer información y ayuda para la gestión de costes• gestionar las comunicaciones con el equipo de desarrollo para

• refinar y clarificar los requisitos• generar confianza en los clientes/accionistas• formar a los miembros del equipo

Significa crear una infraestructura de software que encare los requisitos no funcionalesidentificados en el sistema. Por ejemplo, si el sistema tiene requisitos que fijan que lostiempos de respuesta deben ser inferiores a 3 segundos, entonces ésta infraestructura debeasegurar que el sistema cumplirá dicho requisito.

Significa ofrecer a los desarrolladores la infraestructura que les permita diseñar ycodificar el sistema sin preocuparse en comprometer los requisitos no funcionales.

1.1.2. Arquitectura vs Diseño

Uno de los temas críticos alrededor de la arquitectura es ¿Cuando se acaba la creación dela arquitectura y cuando comienza el proceso de diseño? No existe una respuestadefinitiva para cada sistema. Este hecho se puede acotar en términos de necesidad ycontrol.

Arquitectura Diseño

Nivel de Abstracción Visión amplia y alta en pocosaspectos

Atención detallada en muchosaspectos bajos y específicos

Entregables Planos de sistema y Diseño de componentes,



subsistemas, y prototiposarquitectónicos

especificaciones de código

Área de Atención Requisitos no funcionales Requisitos funcionales

La arquitectura define qué es lo que se va a construir, y el diseño perfila cómo se va ahacer. Así pues, la arquitectura es un diseño en el nivel más alto.

La arquitectura se controla por una o pocas personas que se centran en la visión global yen cambio, el diseño por muchas personas que se centran en los detalles de cómo lograr lavisión global. Un arquitecto crea una arquitectura hasta el punto que el equipo de diseñola puede utilizar para hacer que el sistema logre todos sus objetivos. Por lo tanto, sihemos de crear una arquitectura para desarrolladores expertos, quizás no entraremos tanen detalle como si tuvieses a desarrolladores con menos experiencia.

Conforme se crea una arquitectura para satisfacer los requisitos de negocio y nofuncionales de un sistema, el presupuesto para adquirir hardware, software y recursos dedesarrollo son limitados, de modo que el sistema debe desarrollarse bajo estas premisas.Por ejemplo, ¿cómo podemos hacer que el sistema escale para lograr la demanda delcliente cuando solo tenemos un único ordenador para todos los servicios? ¿cómo crearuna arquitectura sin dinero para comprar productos software? Tarde o temprano, lasdificultades aparecen, y se deben estudiar los pros y los contra para solventar este tipo deproblemas.

Conforme se superan las dificultades evaluando el correcto equilibrio, es importante quecada decisión tomada respecto a la arquitectura quede registrada. Si tomamos unadecisión sobre instalar una base de datos Oracle para persistir la información de laaplicación, debemos documentar esta decisión justificando porqué hemos elegido Oraclerespecto a otros proveedores. Esto permite que el resto del equipo de desarrollo ointegrantes que entran en fases tardías comprendan porqué se tomaron ciertas decisiones ypreviene el tener que justificar continuamente las decisiones tomadas.

La mayoría de las decisiones tomadas al crear la arquitectura se centran en los requisitosno funcionales o mecanismos asociados a estos requisitos. La mayoría de los sistemas nodisponen de un presupuesto inicial que permita adquirir los elementos necesarios paracumplir los requisitos. Si un sistema hardware de alta disponibilidad 24x7 emplea todonuestro presupuesto, no dispondremos de suficiente dinero para comprar un servidor deaplicaciones que nos ayude a cumplir el resto de requisitos en el lado del software.Debemos ajustar la arquitectura para ceñirse al presupuesto, y estos ajustes dependentanto del sistema que estamos creando como de la relación que mantengamos con nuestrocliente.

1.2. Rol del Arquitecto

La palabra arquitecto proviene de la unión de las palabras griegas arqui - tectón (primero- obra), así pues, el rol del arquitecto es ser el primero de la obra, o máximo responsable



de una obra, y dentro del ámbito del software, el máximo responsable del desarrollo deuna aplicación.

Vitruvio, 25 ACEl arquitecto idóneo es aquella persona de letras, matemático, con estudios de historia, buenestudiante de filosofía, con gustos musicales, que no ignora la medicina, aprendiz de leyes,familiarizado con la astronomía y cálculos astronómicos.

Claramente Vitruvio no se refería a un arquitecto de software, pero la idea yace sobre lasmismas características. Un arquitecto es una persona polifacéticoa, madura, conexperiencia, educada, que aprende de forma rápida, un líder con dotes de mando y buenacomunicación, pudiendo tomar decisiones en los momentos difíciles.

Para que un arquitecto sea polifacético, debe tener conocimiento del negocio o deldominio del problema. Puede obtener este conocimiento mediante la experiencia o laformación. Además, los arquitectos deben tener un dominio alto de las tecnologías. Unarquitecto puede ser un experto en una tecnología particular (o no serlo en ninguna), peroal menos debe tener conocimientos generales de todas las tecnologías competentesrespecto a qué tecnología es mejor para tomar decisiones sobre una base sólida. Un buenarquitecto evalúa todas las posibles soluciones de un problema independientemente de latecnología a utilizar.

Realmente, ¿Qué hace el arquitecto? ¿Cual es la diferencia entre un arquitecto y undesarrollador senior? Las tareas de un diseñador están relacionadas con lo que ocurrecuando un usuario pulsa un botón de una aplicación. En cambio, un arquitecto se tieneque preocupar de lo que ocurre cuando ese mismo botón lo pulsan 10.000 usuarios. Asípues, un arquitecto reduce los riesgos técnicos (elementos desconocidos, sin probar, ...)asociados con un sistema.

Los riesgos se asocian con los requerimientos a nivel de servicios, y de modo ocasional,se asocian a requisitos de negocio. Independientemente del tipo de riesgo, es más fácilidentificar los riesgos del proyecto mientras creamos la arquitectura que hacerlo durantela fase de construcción, cuando ya existe una base de código implementada quepotencialmente tenga algún riesgo que solventar.

El arquitecto debe liderar al equipo de desarrollo asegurándose que los desarrolladores ydiseñadores construyen el sistema acorde a la arquitectura. Como líder, debe tomardecisiones sobre las dificultades del sistema. Para liderar, debe tener destreza en laescritura y ser un buen comunicador. Es responsabilidad del arquitecto transmitir elconocimiento del sistema a los desarrolladores (ya sea mediante modelos visuales oreuniones en grupo), los cuales lo van a implementar. Si el arquitecto no se comunica deun modo efectivo, casi seguro que los desarrolladores no construirán el sistemacorrectamente.

Resumiendo



Un arquitecto software tanto diseña el software como guía a otros en la creación de software.Sirve como mentor y como persona responsable de la documentación y juez entre las decisionesque tomen otros diseñadores y desarrolladores de software. Es común que el propio equipo dedesarrollo considere al arquitecto como su entrenador, formador, incluso su consultor.

Y la pregunta del millón es: ¿Cómo me convierto en arquitecto software? La clave es queel poder reside en el conocimiento, y el mejor modo de obtener conocimiento, esleyendo. Leer, leer y leer. Existen multitud de libros que tocan todas las áreas de lainformática, y además tenemos Internet. El problema de internet es la excesivainformación, y normalmente, la poca profundidad respecto a los temas. Por eso, la lecturade libros técnicos es el mejor punto de partida.

Algunas de las editoriales más emblemáticas dentro del desarrollo software son Manning(http://www.manning.com), Pragmatic Programmer (http://www.pragprog.com), O'Reilly(http://oreilly.com), Apress (http://www.apress.com) o Adisson Wesley(http://www.pearsoned.co.uk/Bookshop/subject.asp?item=225)

1.3. Capas y Niveles

Tal como hemos definido anteriormente, el término arquitectura se refiere a larepresentación abstracta de los componentes y comportamientos de un sistema. Unabuena arquitectura de sistema reutiliza componentes, ya que cada componente secompone de partes que pueden estar repetidas, y por lo tanto, reutilizadas. La abstracciónnaturalmente forma capas que representan diferentes niveles de complejidad. Cada capadescribe unas soluciones. Estas capas se integran unas con otras de modo que lasabstracciones de alto nivel se ven afectadas por las abstracciones de bajo nivel.

Para facilitar la descomposición de una arquitectura, utilizaremos los conceptos de capa(capa lógica o layer) y nivel (capa física o tier).

1.3.1. Capas (Layers)

Las capas son sistemas por sí mismos, y hacen lo mismo que todos los sistemas:interactuar con el entorno para obtener entradas y producir salidas.

Los sistemas con capas bidireccionales ofrecen servicios a sus capas superiores einferiores. En cambio, los sistemas de capa unidireccionales ofrecen servicios a las capassuperiores mientras que utilizan los servicios de las capas inferiores (por ejemplo, dentrodel mundo de las redes, el modelo ISO de 7 capas de la OSI).

En la mayoría de las disciplinas ingenieriles, especialmente dentro del software, existe unesfuerzo por construir sistemas basados en capas unidireccionales. Cada capa ofreceservicios a la capa inmediatamente superior mediante una serie de interfaces biendefinidos, permitiendo a esa capa superior trabajar con abstracciones de los serviciosinferiores. Cada capa sólo debe apoyarse en los servicios que le ofrece la capa inferior, de



http://www.manning.com/

http://www.pragprog.com/

http://oreilly.com/

http://www.apress.com

http://www.pearsoned.co.uk/Bookshop/subject.asp?item=225

modo que tenemos un diseño jerárquico donde las capas superiores ocultan a lasinferiores

Dentro de un uso estricto de las capas, las clases y objetos de una capa deberían depender,para la compilación y enlazado, de clases u objetos dentro de la misma capa o inferior.Construir una capa y sus objetos de esta manera hace posible construir las capas inferioresantes que las superiores.

Al mismo tiempo, las clases u objetos de un paquete dentro de una capa no debería tenerdependencias cíclicas con objetos de otros paquetes, tanto dentro como fuera de la capa.Esto elimina las dependencias físicas tipo spaghetti, evitando que los pequeños cambiosse propaguen a lo largo de numerosos lugares.

Descomponer un sistema en capas tiene un número importante de beneficios:

• Se puede entender una única capa como un todo coherente sin necesidad de sabernada del resto de capas. Podemos saber como construir un servicio FTP encima deTCP sin saber los detalles de como funciona una red ethernet.

• Se pueden sustituir las capas mediante implementaciones alternativas con los mismoservicios básicos. Un servicio FTP puede ejecutarse sin cambio sobre una redethernet, PPP o cualquier otra tecnología de red.

• Se minimiza la dependencia entre capas. Si la compañía de cable cambia el sistemafísico de transmisión y sigue siendo compatible con las direcciones IP, no tenemosque modificar el servicio FTP

• Las capas son un buen punto de inicio para la estandarización. TCP e IP sonestándares porque definen como deberían operar sus capas.

• Una vez una capa está construida, se puede utilizar para construir servicios de másalto nivel. De hecho, FTP, telnet, SSH y HTTP utilizan TCP/IP. Sin el uso de capa,cada uno de estos servicios debería implementar sus protocolos de bajo nivel.

Pero también tiene algunos inconvenientes:

• Las capas encapsulan la mayoría de las cosas bien, pero no todas. Como resultado, enocasiones se producen cambios en cascada. Como claro ejemplo, en una arquitecturamulticapa, añadir un campo en el interfaz de usuario, supone modificar el modelo deobjetos, la base de datos, y la lógica de negocio que trata con dicho campo einteractúa con los datos.

• Cada capa puede penalizar el rendimiento. En cada capa, la información normalmentenecesita transformarse de una representación a otra. Sin embargo, encapsular unafunción de una capa inferior normalmente compensa esta penalización.

Sin duda, la parte más difícil de una aplicación multicapa es decidir que capas tiene quehaber y las responsabilidades de cada una de estas capas.

1.3.2. Arquitectura Cliente/Servidor

A lo largo de los años 90, la mayoría de los sistemas se basaban en una arquitectura



cliente/servidor mediante un lenguaje de programación visual tipo Visual Basic,Powerbuilder o Delphi. Este tipo de aplicaciones hacían muchos accesos a los datos yaque los controles visuales que ofrecía el entorno de desarrollo (mediante drag&drop)facilitaban su uso.

Siempre y cuando este tipo de aplicaciones se dedicase únicamente a mostrar y actualizardatos de una BBDD relacional no habría problemas. Los problemas surgían con la lógicade negocio: reglas de negocio, validaciones, cálculos, etc... Este tipo de operaciones secodificaban en el cliente, lo que provocaba que los controles visuales tuviesen embebidala lógica de negocio (la cual estaba repartida en todos los usuario en los cuales estabadesplegado el cliente). Conforme se complicaba la aplicación y la lógica de negociocrecía, el código se hacía muy difícil de mantener. Al estar embebida dentro de laspantallas, había gran cantidad de redundancia, lo que provocaba que un pequeño cambioen la lógica de negocio repercutiera en muchas pantallas.

Una alternativa era colocar la lógica de negocio en la BBDD mediante el uso deprocedimientos almacenados. Sin embargo, su uso también era complejo y no permitíaestructurar bien el código.

Arquitectura cliente/servidor

Al mismo tiempo que la arquitectura cliente/servidor ganaba popularidad, emergía elmundo orientado a objetos. La comunidad OO tenia una solución para el problema dedonde situar la lógica de negocio: cambiar a un sistema de tres capas.

Tal como hemos comentado previamente, la llegada de la web fue el desencadenante dela consolidación de esta arquitectura. Con la entrada de internet, todas las empresas queriadesplegar las arquitecturas cliente/servidor en un navegador web. Sin embargo, como lalógica de negocio estaba grabada con fuego en el cliente, se tenia que volver a rehacerpara tener un interfaz web. Aquellos que ya utilizaban una arquitectura de 3 capasúnicamente tuvieron que codificar un nuevo cliente ligero.



1.3.3. Arquitectura de 3 Capas

Cuando trabajamos con la arquitectura de una aplicación, el estándar de facto es utilizaruna arquitectura de 3 capas que separe claramente las lógicas de presentación, negocio ydatos.

Arquitectura de 3 Capas

En un principio, la separación de estas 3 capas es conceptual, sin necesidad de que cadauna de las capas se separe en un nivel. Es decir, las 3 capas pueden residir sobre la mismamáquina, pero a nivel lógico, estarán separadas.

La capa de presentación es responsable de presentar la información e interactuar con lascapas inferiores, así pues, es lo que ve el usuario. Muestra el sistema al usuario, lecomunica la información y captura la información del usuario dando un mínimo deproceso (realiza un filtrado previo para comprobar que no hay errores de formato). Estacapa se comunica únicamente con la capa de negocio.

¿Quien trabaja en el interfaz de la aplicación? Diseñadores y programadores de interfacesde usuario. Los programadores que programan la interfaz, por regla general, no son losmismos que programan las capas de negocio y datos. Además, utilizan diferentesaplicaciones para hacer su trabajo. De modo que es una buena idea dejar que la gente depresentación tenga sus archivos de presentación (páginas HTML, hojas de estilo,imágenes, etc...), mientras que la gente de negocio tenga sus ficheros (fichero Java, Ant,etc...).

Ejemplos de capas de presentación pueden ser interfaces mediante lineas de comando,menús basados en texto, clientes ligeros (HTML), pesados (Swing), ...

La capa de negocio es la responsable de implementar las operaciones solicitadas por losclientes a través de la capa de presentación. Se denomina capa de negocio (e incluso delógica del negocio) porque es aquí donde se establecen todas las reglas que debencumplirse. Incluye cálculos basados en las entradas e información almacenada, validación



de toda la información que proviene de la capa de presentación, decidir que fuente dedatos utilizar y que datos recuperar/modificar dependiendo del comando recibido a travésde la capa de presentación.

Así pues, esta capa se comunica con la capa de presentación, para recibir las solicitudes ypresentar los resultados, y con la capa de datos, para almacenar o recuperar datos delSGBD.

La capa de datos es la responsable de gestionar todos los elementos de información delsistema: ficheros planos, XML, SGBD, etc... En algunas arquitecturas se considera comoparte de esta capa aquellos sistemas externos que proporcionan información: servidoresde mensajes, servicios web, etc...

El principal motivo para separar los datos, y en concreto la base de datos, es que como laspilas, se venden por separado. Es obvio que la base de datos es una parte muy importantede la aplicación, ya que si te falla la base de datos, la aplicación se cae. Además,queremos que esta información este lo más segura posible, lo que hace que sea candidataideal a separarla de la aplicación y de los clientes, con un gran cortafuegos impidiendo elacceso a extraños.

Por tanto, el flujo de comunicación entre las diferentes capas es el siguiente:

Secuencia de Comunicación de 3 Capas

1.3.4. Diseño en 3 Capas

A la hora de diseñar una aplicación mediante esta arquitectura, podemos seguir 2



planteamientos: de arriba a abajo (top-down) o de abajo a arriba (bottom-up).

En el diseño top-down se define la funcionalidad del sistema desde el punto de vista delcliente. Cada una de estas necesidades se propaga por las capas según las necesidadesidentificadas en las capas anteriores.

Ventajas Inconvenientes

Desde el principio se tienen claras lasfuncionalidades, y éstas dirigen el desarrollo delsistema

Sólo es posible aplicarlo a sistemasdesarrollados desde cero.Los componentes acaban fuertementeacoplados pues se utilizan en entornoshomogéneos

En cambio, el diseño bottom-up suele surgir más por necesidad que por elección, ya quemuchos de los sistemas de hoy en día se basan en la integración de productos existentes(legacy o heredados, entendiendo por heredado aquel sistema que es utilizado en uncontexto distinto del que en principio fue concebido). Si tenemos que integrar sistemasheredados no podemos seguir un enfoque top-down.

Por ello, el cliente definirá las funcionalidades, y dependiendo de los recursos existentes ylas funcionalidades que ofrecen, se encapsulará aquella funcionalidad existente,adaptando las salidas de la aplicación a las necesidades del cliente.

Ventajas Inconvenientes

Los componentes estan poco acoplados ypueden ser reutilizados

Viene impuesto por las necesidades del cliente

1.3.5. Niveles (Tiers)

En un entorno de múltiples niveles (también conocidos como capas físicas), las capaslógicas se reparten en uno o más niveles. Por ejemplo, el cliente implementa la lógica depresentación (cliente ligero), la lógica de negocio se implementa sobre el servidor deaplicaciones (1 o varios), y los datos residen en el servidor de base de datos (1 o varios).

Los siguientes 3 componentes definen una arquitectura multinivel:

• El componente de front-end, responsable de ofrecer portabilidad en la lógica depresentación, como puede ser un servidor web.

• El componente de back-end, responsable de ofrecer acceso a servicios dedicados,como un servidor de base de datos.

• Uno o más componentes de middle-tier, que permite a los usuarios compartir ycontrolar la lógica de negocio, aislándola de la aplicación real, como un servidor deaplicaciones.

La siguiente figura muestra una representación de una arquitectura de 3 niveles:



Capas físicas de la arquitectura

Es muy común desplegar cada una de las capas de una arquitectura de 3 capas en 3niveles, de modo que cada capa se despliega sobre su propia máquina. Dentro del mundoweb, la arquitectura física más común es una máquina para el cliente (con el navegadorweb) y otro nivel para las lógicas de presentación, negocio y datos. Además, si no nossobra el dinero, tanto el componente back-end como middle-tier convivirán en la mismamáquina, de modo que tengamos un servidor de aplicaciones (con su propio servidorweb) y un servidor de base de datos corriendo sobre el mismo procesador pero en puertosdiferentes.

Todo en unoCuando trabajamos con nuestro ordenador de sobremesa con el servidor de aplicaciones y el debase de datos trabajando en local (tal como lo hacemos en clase), realmente tenemos un úniconivel pero de forma lógica nuestra aplicaciones debe tener sus 3 capas.

Las ventajas de utilizar una arquitectura multinivel son:

• Los cambios en el interfaz de usuario o en la lógica de la aplicación sonindependientes unos de otros, lo que permite a la aplicación evolucionar fácilmentepara cumplir nuevos requisitos

• Se minimizan los cuellos de botellas debido a problemas de red, ya que la capa de laaplicación no transmite información extra al cliente; de hecho, únicamente transmiteaquella información que realmente es necesaria para realizar una tarea

• Cuando son necesarios cambios en la lógica de negocio, solo debemos actualizar elservidor. En una arquitectura de 2 niveles, debemos modificar cada cliente cuandotenemos un cambio en negocio.

• Se aísla al cliente de la base de datos y las operaciones de red. El cliente puedeacceder a los datos fácilmente sin necesidad de saber donde están los datos o cuantosservidores hay en el sistema.

• Las conexiones de base de datos se pueden reutilizar (mediante un pool deconexiones), de modo que se comparten entre varios usuarios, lo que reduce



drásticamente los costes asociados a las licencias por usuarios.• Se consigue independencia de la organización respecto a los datos, ya que la capa de

datos utiliza SQL estándar, el cual es independiente de la plataforma. De este modo,la empresa no se ata a procedimientos almacenados específicos de un determinadogestor.

1.4. Requisitos No Funcionales

Además de los requisitos de negocio del sistema, debemos satisfacer los requisitos nofuncionales, también conocidos como requisitos a nivel de servicio o requisitos deservicios de calidad (QoS). Como arquitecto, se debe trabajar junto al cliente durante lasfases de inicio (inception) y elaboración (si seguimos la metodología RUP) para definirlas métricas de calidad para cada uno de los requisitos no funcionales.

La arquitectura que creamos debe tratar los siguientes requisitos no funcionales:rendimiento, escalabilidad, confiabilidad, disponibilidad, extensibilidad, mantenibilidad,gestionabilidad y seguridad.

Como arquitecto, hay que buscar el equilibrio entre estos requisitos. Por ejemplo, si elrequisito más importante es el rendimiento de un sistema, quizás haya que sacrificar lamantenibilidad y extensibilidad del sistema para asegurar los mínimos de calidadesperados respecto al rendimiento.

1.4.1. Rendimiento

Por supuesto, sinónimo de velocidad. El rendimiento se mide en términos de tiempo derespuesta por transacción de usuario, es decir, cantidad de tiempo que necesita el sistemapara procesar una petición desde el exterior (ya sea una acción de un interfaz de usuario ouna llamada desde otro servidor).

ReceptividadLa receptividad (responsiveness) mide el tiempo que tarda un sistema en aceptar una petición, sinnecesidad de procesarla.Una mala receptividad provoca la duda del usuario y desconfianza en el sistema.Si el sistema espera durante toda la petición, la receptividad y el tiempo de respuesta serániguales. El uso de barras de progreso que informan al usuario que se está realizando una tareamejoran la receptividad de la aplicación, aunque no mejoren los tiempos de respuesta.

Otra medida es la productividad, que es el número de transacciones que se realizan en unperiodo de tiempo determinado, normalmente un segundo. Por ejemplo, si medimos loque tardamos en copiar un fichero, utilizariamos la métrica de bytes por segundo. En unaaplicación de empresa, por ejemplo, número de pédidos que se realizan en un segundo.

Otra forma de medir el rendimiento es mediante el número de usuarios simultáneos quesoporta un sistema dentro de unos tiempos de respuesta razonables, es decir, se



especifican los requisitos para X usuarios simultáneos en un tiempo máximo de respuestaY.

A pesar de las métricas, es necesario crear una arquitectura que permita a los diseñadoresy desarrolladores completar el sistema sin necesidad de considerar estas métricas derendimiento.

Para conseguir un buen rendimiento, se necesita un buen diseño y una buena codificación¿Algo más? Casi todo afecta al rendimiento. Otros factores claves son la memoria y lavelocidad del procesador de la CPU.

1.4.2. Escalabilidad

Para comprender la escalabilidad, antes se debe comprender la capacidad del sistema,definida como el número máximo de procesos o usuarios que un sistema puede manejarmanteniendo la calidad de los servicios ofrecidos. Un sistema se ejecuta a su capacidadmáxima cuando ya no puede responder a más peticiones dentro de unos tiempos derespuesta aceptables.

La escalabilidad es una medida de cómo el incremento de recursos (normalmentehardware) afecta al rendimiento. Dicho de otro modo, es la habilidad de soportar losservicios de calidad conforme la carga del sistema crece sin que el sistema se veaperjudicado y sin necesidad de modificar el mismo. Un sistema se considera escalable si,conforme se incrementa la carga, el sistema sigue respondiendo dentro de unos limitesaceptables. Si no responde dentro de los limites, que sea escalable no significa quetengamos que modificar el código. Si es escalable, con sólo instalar más hardware oinstancias de los servidores, el sistema debe recuperar los tiempos de respuesta esperados.

El hecho de incrementar la capacidad no implica incrementar el rendimiento,normalmente, al escalar una aplicación, podemos dañar su rendimiento. La dificultad yaceen encontrar el equilibrio entre el rendimiento, la capacidad y los costes económicos.

Por ejemplo, puede ser que tengamos una medida de rendimiento de un tiempo derespuesta entre 2 y 5 segundos. Si la carga del sistema crece y el sistema puede mantenerlos niveles de calidad respecto al rendimiento en tiempos de respuesta inferiores a 5segundos, entonces el sistema es escalable.

Para escalar un sistema que ha llegado a su capacidad, se debe añadir hardware adicional,ya sea vertical u horizontalmente. El escalado vertical implica añadir procesadores,memoria, o discos adicionales a la/s máquina/s actual/es. El escalado horizontal implicaañadir más máquinas al entorno, de este modo se incrementa la capacidad general delsistema.

ImportanteLa arquitectura que creemos debe manejar el escalado vertical y horizontal del hardware



Cabe destacar que el escalado vertical es más fácil de realizar que el horizontal. ¿Por qué?Añadir más procesadores o memoria normalmente no tiene un impacto en la arquitectura,pero el hecho de que la arquitectura deba ejecutarse sobre múltiples máquinas pero queparezca que sólo se ejecuta como un sistema compacto es más difícil.

Es más barato añadir hardware más potente a un servidor que modificar la arquitecturapara mejorar el rendimiento en un sistema menos potente. Igualmente, añadir másservidores es más económico que añadir más programadores (siempre y cuando el sistemasea escalable). Pero, un servidor que es el doble de rápido, cuesta más del doble !

En el caso de añadir más máquinas, vamos a depender también de la calidad de la red, yde la arquitectura física. Es decir, ¿el almacenamiento será redundante, o utilizaremos unSNA (Storage Network Area) centralizado? Nuestra red ¿qué ancho de banda tiene?

1.4.3. Fiabilidad

La Fiabilidad (reliability) asegura la integridad y consistencia de la aplicación y de todassus transacciones. Conforme crece la carga del sistema, éste debe continuar procesandolas peticiones y manejando las transacciones con la misma precisión que lo hacia antes deincrementarse la carga.

Un sistema es más fiable si es tolerante a fallos. La tolerancia a fallos es la capacidad deun sistema para seguir funcionando cuando se produce un error en parte del sistema. Paraconseguir tolerancia a fallos hay que diseñar el sistema con un alto grado de redundanciade hardware. Si se produce un error en un único componente, el componente redundanteasumirá su función sin que se produzca un tiempo de inactividad apreciable.

La fiabilidad puede tener un impacto negativo en la escalabilidad, ya que si el sistema nopuede mantener la fiabilidad conforme la carga se incrementa, entonces el sistema no esrealmente escalable. De modo que para que un sistema escale, éste debe ser fiable.

1.4.4. Disponibilidad

La disponibilidad asegura que un servicio/recurso esta siempre accesible, o parece que loestá. La fiabilidad puede contribuir a la disponibilidad, pero la disponibilidad se puedealcanzar incluso si algunos componentes fallan.

Montando un entorno de componentes redundantes en cluster y tolerantes a fallos, uncomponente puede caerse y tener un impacto negativo en la fiabilidad, pero el serviciosigue en pie gracias a la redundancia. En cuanto un componente se cae, el componenteredundante suplanta al componente caído.

La disponibilidad se define mediante el uptime (tiempo en marcha), es decir, el tiempomedio que pasa entre fallos. En contraste, el downtime define el tiempo necesario paradetectar un fallo, repararlo, realizar las tareas de recuperación, y rearrancar el sistema.Durante el periodo de uptime, el sistema responde a cada petición dentro un periodo de



tiempo determinado. Si se supera este periodo de tiempo, el usuario piensa que el sistemaestá fallando. La alta disponibilidad (HA), basicamente, es la redundancia del sistema: siun servidor falla, los otros servidores se hacen cargo de las tareas del servidor caído de unmodo transparente al usuario.

1.4.5. Extensibilidad

La extensibilidad es la habilidad para añadir funcionalidad adicional o modificarfuncionalidad existente sin tener un impacto directo en la funcionalidad del sistema.

La extensibilidad no se puede medir cuando el sistema está desplegado, sino cuando sedebe extender por primera vez. Por lo tanto, a la hora de crear la arquitectura se debentener en cuenta conceptos tan importantes como el bajo acoplamiento, el uso deinterfaces, la encapsulación y el diseño basado en patrones.

Para conseguir que la aplicación sea extensible hemos de vigilar muy de cerca el códigode la aplicación, de modo que sea siempre homogéneo y de calidad. Para esto, el equipode desarrollo debe ser un equipo y no un conjunto de individualidades, donde la calidaddel código sea un objetivo común.

1.4.6. Mantenibilidad

La mantenibilidad es la habilidad de corregir defectos en la funcionalidad existente sintener impacto en otros componentes del sistema.

Esta es otra de las cualidades del sistema que no se pueden medir a la hora del despliegue.Del mismo modo que en la extensibilidad, cuando creamos la arquitectura, para mejorarla mantenibilidad debemos tener en cuenta conceptos como bajo acoplamiento, altacohesión, modularidad y documentación.

La escalabilidad es uno de los enemigos de la mantenibilidad, ya que la complejidadasociada con los componentes distribuidos reduce la mantenibilidad.

1.4.7. Gestionabilidad

La gestionabilidad es la habilidad del sistema de asegurar la salud continua del sistemarespecto a la escalabilidad, confiabilidad, disponibilidad, rendimiento y seguridad.

La gestionabilidad se ocupa de la monitorización del sistema para mejorar los QoSdinámicamente sin modificar el sistema. La arquitectura debe tener la habilidad demonitorizar el sistema y permitir los cambios de configuración del sistema en caliente.

1.4.8. Seguridad

La seguridad es la habilidad de asegurar que el sistema no se vulnera, es decir, que todoshacen lo que deberían hacer y nadie hace lo que no debería



De lejos, la seguridad es la cualidad más difícil de conseguir. La seguridad no solo tratatemas como la confidencialidad o la integridad, sino también los ataques de denegaciónde servicio (DoS).

Crear una arquitectura cuyos componentes están separados según funcionalidades es másfácil de proteger ya que se pueden construir zonas protegidas alrededor de dichoscomponentes, ya sea mediante el uso de ACLs o cortafuegos. Además, si se ataca a uncomponente, entonces es más fácil contener la amenaza de violación a ese únicocomponente, evitando que se propague el ataque.

1.5. Arquitectura Ágil

Aunque el arquitecto debe considerar todos los requisitos del cliente, también tiene laresponsabilidad de avisar al cliente de las posibles implicaciones en el sistema que puedatener el comprometer la arquitectura para llegar a una fecha de entrega muy cercana.

Principio de OportunidadLa solución a entregar debe estar disponible dentro de un margen de tiempo que sigamanteniendo el principio de oportunidad. El principio de oportunidad normalmente rige losplazos de entrega del aplicativo, pero no por ello debe condicionar la calidad del proyecto. Encambio, el exceso de ingeniería puede penalizar la oportunidad del proyecto, entregando elproyecto tan tarde que ya no tenga ningún valor para el negocio del cliente.

Una arquitectura ágil es aquella que conserva el principio de oportunidad, apropiada paralos intereses del cliente y acelera la entrega del sistema. Dicho de otro modo, es unaarquitectura que se implementa fácil y eficientemente por el equipo de desarrollo, y dehecho, completada en un periodo de tiempo aceptable para el cliente.

En los siguientes apartados se detallan algunas opciones para conseguir este objetivo.

1.5.1. Virtudes del Equipo

Hay que tener en cuenta que los miembros de un equipo de desarrollo han adquirido unrango diverso y variado de habilidades y conocimientos durante su experiencia en laindustria del desarrollo del software. El conocer las virtudes del equipo es unaconsideración muy importante a la hora de diseñar un sistema: la arquitectura debe sacarpartido de esas virtudes.

Existen detractores que piensan que la arquitectura debe basarse en la tecnología quemejor afronte los requisitos del sistema. Es un argumento muy valido, ya que si lastecnologías se hubiesen basado siempre en los conocimientos del equipo, la mayoría delas aplicaciones continuarían implementándose en COBOL. Sin embargo, la experienciatécnica colectiva se debe tener en cuenta cuando el tiempo es un factor crítico en elproyecto.



La misma regla debe aplicarse al buscar perfiles de desarrollo con unos ciertosconocimientos para el proyecto. Si los miembros del equipo abandonan, o se debe formarun nuevo equipo, el completar dichas vacantes puede llegar a ser muy problemático si serequieren conocimientos en una tecnología desconocida.



1.5.2. Utilizar los Mejores Frameworks

JavaEE esta lleno de frameworks, tanto como extensa es la plataforma JavaEE.

Un framework de software apropiado puede reducir de forma significativa la cantidad decódigo que necesitas escribir y mejorar la calidad del diseño. Existen multitud deframeworks de código abierto para cada aspecto de una aplicación, incluyendo:

• Desarrollo web: Struts, JSF, Tapestry, Spring• Persistencia: Hibernate, iBatis, OJB• Entornos de construcción: Ant, Maven, CruiseControl• Entornos de pruebas: JUnit, Cactus, TestNG

La elección de un framework es una decisión muy importante, ya que condiciona en granparte la arquitectura y el diseño de la aplicación. A la hora de seleccionar un framework,se deben tener en cuenta las siguientes pautas:

• Conocimiento del equipo: elegir productos que han sido probados con éxito en otrosproyectos, así como aquellos en los que el equipo de desarrollo ya tenga experiencia.

• Madurez: ¿cuanto tiempo lleva utilizándose en el desarrollo de software comercial?¿Es un proyecto de código abierto mantenido por Apache, o el resultado de la tesis deun doctor? Un producto maduro ya está limado, y casi sin incidencias.

• Apto para el propósito: elegir un framework apropiado para las necesidadesespecíficas del sistema. Cuando no se encuentra una elección acertada, el desarrollode una solución propia para un área de negocio determinada puede obtener beneficiosa largo plazo.

• Herramientas de soporte: la combinación del framework junto a las herramientas dedesarrollo pueden ofrecer ganancias de productividad significativas.

• Longevidad: seleccionar aquellos framework que tendrán soporte durante el tiempode vida prevista para el proyecto. Un framework que desaparece del horizonte una vezel sistema alcanza la producción presenta graves problemas de soporte ymantenimiento.

La elección del mejor framework para el proyecto reduce los tiempos de entrega y deberíacontribuir a la calidad final del aplicativo. Por ello, para comprobar la madurez ylongevidad de un determinado framework pueden ser útiles las siguientes métricas:

• Disponibilidad de listas de correo y foros de discusión• Nivel de actividad en los foros• Tiempos de respuesta a los usuario que plantean preguntas y calidad de las mismas• Frecuencia de nuevas entregas del framework• Retroalimentación de la comunidad relativa a la calidad y usabilidad• Número de incidencias abiertas• Calidad de la documentación, libros publicados, etc...

1.5.3. Ser Previsor



El hecho de ser previsor durante el proceso de diseño facilita en gran medida la vida delos desarrollador y probadores. La necesidad de prevenir es especialmente relevante en elárea de pruebas.

Cualquier acción que tome el arquitecto para facilitar las pruebas del sistema no soloreportarán calidad al sistema, sino reducirán los esfuerzos totales en este aspecto. Elmodo de hacerlo depende de la aplicación, pero algunos puntos a tomar en consideraciónpueden ser:

• incluir esqueletos de pruebas y pruebas unitarias como parte del diseño: a la hora decodificar y seguir una técnica de desarrollo dirigido por las pruebas, se utiliza muchotiempo codificando las pruebas. Por lo tanto, si el arquitecto es previsor ydiseña/implementa los esqueletos de las pruebas, los desarrolladores sólo debencomplementarlas con la casuística de éstas.

• evitar el uso de interfaces débilmente definidos: cuando un método recibe comoparámetro un String, el cual hay que parsear para obtener la información, o un objetomuy grande, del cual más de la mitad de los atributos no son necesarios dentro delmétodo, provoca que el método sea excesivamente ambiguo, sin saber que datos tienede entrada y cuales no

Es importante destacar el cuidado que hay que tener a la hora de ser previsor en exceso,ya que un diseño pensado para una reutilización es mucho más complejo que un diseñosimple. Cuando el tiempo premia, se debe evitar la sobreingeniería y limitarse a lonecesario.

1.5.4. Aplicar un Diseño Ortogonal

Ortogonalidad es sinónimo de software bien construido, con bajo acoplamiento y altacohesión. Los componentes ortogonales son independientes, autocontenidos, y tienen unaresponsabilidad claramente definida. Los cambios en el interior de un componente notienen repercusiones en el resto de componentes del sistema

Esta independencia entre los componentes es vital para una arquitectura ágil, ya que loscambios en un componente/capa de la aplicación no tiene por que propagarse por elsistema. Además, los componentes ortogonales son fáciles de codificar, probar, ymantener gracias a su diseño

Uno de los elementos principales dentro de la OO para alcanzar un diseño ortogonal es eluso de interfaces. Si diseñamos nuestros componentes mediante interfaces, podemosutilizarlos como escudos contra los cambios de implementación de los métodos.

1.6. Roadmap

1.6.1. Puntos Destacados



• La arquitectura es una representación abstracta del comportamiento y componentesdel sistema. Una buena arquitectura tiende a reutilizar componentes porque cadacomponente se divide en partes que pueden repetirse, y por tanto, reutilizar. Laabstracción forma capas que representan diferentes niveles de complejidad.

• La principal diferencia entre los términos arquitectura y diseño es el nivel de detalle.La arquitectura opera a un nivel de abstracción alto con pocos detalles. El diseñoopera a bajo nivel de abstracción, pero con más atención en los detalles de laimplementación.

• Las capas de una arquitectura son sistemas por si mismos. Obtienen entradas de suentorno y ofrecen salidas al mismo.

• Los requisitos no funcionales o capacidades de una arquitectura incluye:• Rendimiento: habilidad de ofrecer la funcionalidad dentro de unos periodos de

tiempo asumibles por los objetivos especificados.• Disponibilidad: grado de accesibilidad de un sistema. El término 24×7 describe la

disponibilidad total. Este aspecto del sistema esta frecuentemente acoplado con elrendimiento.

• Escalabilidad: habilidad de soportar el rendimiento y la disponibilidad requeridaconforme crece la carga de transacciones.

• Confiabilidad: habilidad de asegurar la integridad y consistencia de la aplicación ysus transacciones.

• Extensibilidad: habilidad de extender la funcionalidad del sistema.• Gestionabilidad: habilidad de administrar y gestionar los recursos del sistema para

asegurar la disponibilidad y rendimiento respecto a otra capacidades.• Flexibilidad: habilidad de manejar cambios en las configuraciones hardware y

arquitectónicas sin un gran impacto en los sistema dependientes.• Capacidad: habilidad del sistema de ejecutar múltiples tareas por unidad de

tiempo.• Validez: habilidad de predecir y confirmar los resultados basados en una entrada

especificado o un gesto de un usuario.• Reusabilidad: habilidad de utilizar un componente en más de un contexto sin

necesidad de cambios internos.• Seguridad: habilidad de asegurar que no se accede ni modifica la información a no

ser que se cumplan las políticas de empresa.

1.6.2. Certificación Sun

Respecto a los contenidos estudiados, SCEA cita 2 objetivos encontrados en la sección 2(Arquitecturas Comunes):

• Reconocer el efecto de cada una de las características de una arquitectura de 2, 3 o Nniveles: escalabilidad, mantenibilidad, confiabilidad, disponibilidad, extensibilidad,rendimiento, manejabilidad y seguridad

• Dada una arquitectura definida en términos de organización de red, listar losbeneficios y posibles debilidades asociadas.



Para finalizar con los conceptos relacionados con la arquitectura J2EE, nos falta porexplicar la arquitectura Java EE y los requerimientos de cada tecnología, así como el usode los patrones de diseño dentro del marco empresarial, ubicando cada patrón en sucorrespondiente capa/nivel. Tanto la arquitectura Java EE como los patrones de diseño losestudiaremos a lo largo del curso.

1.6.3. Para Saber Más

1.6.3.1. Bibliografía

El libro por excelencia que trata estos temas es:

• Software Architecture in Practice, 2nd Edition, Addison-Wesley, de Len Bass y otros

En castellano, no existe ningún libro especifico que trate estos temas, a parte de lasbiblias de Ingeniería del Software:

• Ingeniería del Software, 7ª Edición, Addison-Wesley, de Ian Sommerville• Ingeniería del Software, 6ª Edición, McGraw-Hill, de Roger S. Pressman

Para reducir los contenidos y enfocar los conceptos, para escribir estos apuntes nos hemoscentrado en los 2 libros existentes para la preparación del examen SCEA:

• Sun Certified Enterprise Architect for J2EE Study Guide (Exam 310-051),McGraw-Hill, de Paul Allen y Joseph Bambara

• Sun Certified Enterprise Architect for J2EE Technology Study Guide, Prentice-Hall,de Mark Cade y Simon Roberts

1.6.3.2. Enlaces

• Certificación Arquitecto Sun :http://www.sun.com/training/certification/java/scea.xml



http://www.sun.com/training/certification/java/scea.xml

2. Caché

2.1. Introducción

En la actualidad, el rendimiento es un factor muy importante en una aplicación. Lostiempos de respuesta deben ser mínimos, y cuanto menores, mejor.

Gran parte del tiempo de procesamiento de una aplicación se emplea en el acceso a lafuente de datos y su consulta/manipulación. Una forma de mejorar estos accesos esevitarlos :)

En general, una caché es una solución a un problema básico: estamos empleando lamayor parte del tiempo de procesamiento en obtener datos que ya los hemos obtenidorecientemente.

Por ejemplo, si empleamos un mecanismo de "cacheo", de modo que en vez de ir a labase de datos tras cada petición realizada por el cliente, lo haga cada minuto, y mientrastanto devuelva la información que almacena en memoria, estaremos ahorrando tiempo deprocesamiento.

Pregunta¿Pero qué sucede si los datos consultados cambian durante ese minuto?

La caché reduce el tráfico entre la aplicación y la base de datos, conservando lainformación que ya ha sido cargada de la base de datos. De este modo, el acceso a losdatos solo es necesario cuando recuperamos datos que no están disponibles en la caché(bien porque es la primera vez que los recuperamos, bien porque han caducado). Laaplicación puede necesitar vaciar (invalidar) la caché de vez en cuando ya que nopodemos saber a ciencia cierta si el contenido de la caché esta realmente actualizado.

2.2. Problemas de la Caché

Cualquier caché tiene asociados una serie de problemas que afloran especialmente alaumentar la concurrencia de las aplicaciones. Estos problemas pueden llegar incluso ahacer que la caché se vuelva en nuestra contra, y que el rendimiento de las aplicacionesdecrezca de forma alarmante. Consideremos un típico caso de uso de una caché:

• La aplicación intenta recuperar una instancia de un objeto• Si el objeto está en la caché se devuelve de la misma.• Si el objeto no está en la caché, se recupera de la base de datos y se almacena en la

caché.

A partir de aquí surgen algunos problemas típicos: ¿Qué pasa si un objeto que fue



recuperado por un hilo de ejecución y guardado en la caché, es recuperado también porotro hilo de ejecución y modificado? Este problema es bastante común en todas lasaplicaciones, tanto que en muchos desarrolladores recomiendan el uso de cachés paraobjetos de solo lectura (lo cual es parcialmente correcto).

Este problema en realidad se presenta de varias formas:

1. Dos hilos utilizan la mismo caché2. Dos hilos utilizan diferentes cachés (por ejemplo una arquitectura distribuida, o un

cluster)3. Se modifica un objeto por una aplicación que no accede a la caché (ejemplo cuando se

modifica un registro en la tabla a la que esta mapeada un objeto)

Para el primer caso no tendríamos demasiados problemas, ya que los distintos hilos deejecución utilizan la misma caché, y un cambio realizado por uno estaríaautomáticamente reflejado en el segundo.

El segundo caso es más complejo de analizar, dado que cuando se utilizan cachésdistribuidas, éstas tienen además de la carga de mantener la caché, la carga de sincronizarsus contenidos con los otros nodos del cluster. Para esto existen diferentes tipos de cachésdistribuidos, como son las cachés replicadas (que copian el contenido de la caché entera atodos los nodos), cachés repartidos entre los distintos nodos (que implicarían el pedido deobjetos de un caché a otro), o simplemente cachés independientes en cada nodo, quesincronicen su contenido en periodos de tiempo definidos.

El último de los casos es el más complejo de todos. La regla general a aplicar a este caso(la cual no comparto del todo) es que "si no somos dueños de los datos, no los pongamosen un caché". Obviamente esta regla no siempre es aplicable. Un ejemplo de estos casosson tablas de referencia que todos los sistemas tienen, como son los países, que nuncacambian. Se puede tomar el compromiso de cachearlas, y en caso de que los registros semodifiquen via un proceso de backend, la aplicación que utilice la caché ofrezca algunafuncionalidad que limpie la caché de las instancias correspondientes.

2.3. ¿Cachear o No Cachear?

Cachear nos permite obtener beneficios importantes, pero requiere una comprensión delos elementos fundamentales para realizar una buena implantación de una solución (oimplementar una solución propia).

Por lo tanto, para cachear aplicaciones Java, debemos resolver los siguientes problemas:

• ¿Cuando debemos cachear? Las decisiones hemos de tomarlas basadas en los costesde operación, volatilidad de los datos almacenados, patrones de acceso al almacén dedatos y tamaño de la información almacenada.

• ¿Cómo debemos gestionar los datos actualizados? Los datos incorrectos deben serinvalidados y actualizados de un modo correcto.

• ¿Cómo debemos gestionar los datos obsoletos? A veces, los datos caducados son



aceptables, pero normalmente la estrategia a seguir debe refrescar los datos de formaregular.

• ¿Cómo debemos gestionar el acceso concurrente a nuestra caché? El accesoconcurrente puede protegerse mediante métodos sincronizados, pero este tipo deacceso puede ser demasiado restrictivo.

La implementación más sencilla de una caché es emplear un Mapa con pares (clave,valor), de modo que cada clave identifica de forma univoca a un objeto cacheado. Peroesta implementación carece de mecanismos de caducidad, concurrencia, tolerancia afaltos, etc...

En el mercado existen diferentes soluciones de cacheo para contenido estático las cualesestán bien desarrolladas e implantadas, como pueden ser servidores proxy de cacheo, olos propios servidores web que almacenan en memoria tanto imágenes como páginas webestáticas. Pero el contenido dinámico también es un centro de atención para el cacheo. Esmás, al cachear contenido dinámico es cuando vamos a obtener una productividadmucho mayor que la obtenida sin realizar el proceso de caché.

2.3.1. Comparando...

A continuación, mostramos un ejemplo visual que ilustra el impacto de una estrategia decacheo agresiva en el rendimiento de un sistema. Los datos se han obtenido de un artículode Mike Conner, descrito en el libro "Bitter Java" (Manning).

Para empezar, tenemos una arquitectura sin caché. En cada capa, se muestran los costesde cada comunicación. En las llamadas a las capas posteriores sus pesos son mayores querespecto a las anteriores, ya que el contenido estático siempre es más barato. Conformevamos hacia la derecha, el contenido se convierte más dinámico.



Aplicación sin Caché

Para contrastar, podemos observar como una política agresiva de cacheo incrementa elrendimiento de la arquitectura, decrementando de forma significativa la carga de losnodos que están protegidos por cachear anteriores. Esta arquitectura utiliza cachés endiferentes puntos, junto a Internet que tiene cachés internas que nosotros nunca vemos.



Aplicación con Caché

Dentro del mercado actual, existen múltiples alternativas ya desarrolladas, siendo las másconocidas EhCache (ehcache.sourceforge.net), JCS (jakarta.apache.org/jcs), SwarmCache(swarmcache.sourceforge.net), JBoss Cache (http://labs.jboss.com/jbosscache/) yOSCache (esta última es la que vamos a estudiar en esta sesión)

2.4. JPA con Hibernate y la Caché

JPA no ofrece ningún mecanismo para la gestión de la caché. Todo el control lo ofrecenlos proveedores, y estos son los que pueden ofrecer (o no) una caché de los objetos delservidor. Dentro de JPA, la especificación sólo obliga a los proveedores a que el procesode cacheo se realice dentro de una transacción o dentro de un contexto de persistenciaextendido para preservar la identidad del objeto, pero a lo que no obliga JPA es a soportarla caché entre diferentes transacciones o contextos de persistencia.

A lo largo de este apartado, vamos a centrarnos en Hibernate, por ser el proveedor quehemos estudiado en las sesiones de JPA.

CorrespondenciasCuando en Hibernate hablamos sobre la Session, se corresponde con el EntityManager deJPA (ambos comparten el concepto de contexto de persistencia)Del mismo modo, el SessionFactory de Hibernate corresponde conEntityManagerFactory de JPA (ambos comparten el concepto de unidad depersistencia).



http://ehcache.sourceforge.net/

http://jakarta.apache.org/jcs/

http://swarmcache.sourceforge.net/

http://labs.jboss.com/jbosscache/

Para poder acceder a la SessionFactory, desde JPA podemos acceder a la Session deHibernate mediante el método getDelegate() de la interfaz EntityManager, el cual nosdevuelve el proveedor de JPA que estamos utilizando.

Por ejemplo, si queremos caducar todos los libros de la caché de segundo nivel:

protected EntityManager entityManager;...Session session = (Session) entityManager.getDelegate();try {

SessionFactory sessionFactory = session.getSessionFactory();sessionFactory.evict(Libro.class);

} finally {session.close();

}

En el caso de Hibernate, hay dos tipos de cachés, la de primer y la de segundo nivel.

Niveles de Caché

2.4.1. Caché de Primer Nivel

Es la que mantiene automáticamente Hibernate cuando dentro de una transaccióninteractuamos con la base de datos; en éste caso se mantienen en memoria, dentro delcontexto de persistencia, los objetos que fueron cargados y si más adelante en el flujo delproceso volvemos a necesitarlos van a ser devueltos desde la caché, ahorrando accesossobre la base de datos.

Aunque parezca un poco confuso, la caché de primer nivel de Hibernate no es ni más nimenos que la Session, es decir, el contexto de persistencia de JPA. Esta caché de primernivel guarda todos los objetos y operaciones que vamos realizando durante nuestraSession con el motor de persistencia. Cada load o query que hacemos a la Session, y



por tanto, cada find y getReference que hacemos sobre el EntityManager, le permitecachear los objetos recuperados. A su vez cada save, update, saveOrUpdate, delete,etc. también se almacena en el contexto de persistencia y no se formaliza hasta que no sehace un commit o flush (este tema en realidad es bastante más complejo de analizar, yaque no siempre se espera hasta finalizar una Session/EntityManager para realizar lasoperaciones, ya que podemos crear 2 unidades de trabajo con 2 transacciones diferentesdentro del mismo contexto de persistencia).

Por lo tanto, podemos considerar la caché de primer nivel como una caché de cortaduración ya que es válida solamente entre el begin y el commit de una transacción, deforma aislada a las demás.

2.4.1.1. Hibernate y los tipos de Session

En el caso de Hibernate, este tipo de caché se utiliza por defecto, no hay que configurarnada. Si por alguna razón queremos deshabilitar o evitar el uso del caché, podemos usarun tipo especial de Session: StatelessSession, se obtiene de la clase SessionFactory

con el método openStatelessSession(). Se suele utilizar con procesos batch, porejemplo cuando hay que hacer inserts o updates masivos, así se evita que cada vez quehago el save de un objeto, el mismo se quede en memoria y en la ejecución completa delproceso se produzca un error del tipo OutOfMemoryError. La StatelessSession nointeractúa con la caché de primer nivel ni con la de segundo nivel, es decir, es casi comosi utilizáramos JDBC directamente.

La Session provee métodos explícitos para el tratamiento de la caché, como son evict yclear, que eliminan un objeto de la caché de primer nivel y la limpian, respectivamente.

El comportamiento de la caché de primer nivel de Hibernate está directamente ligado conel modelo de gestión de los contextos de persistencia que elijamos para nuestraaplicación:

• Contexto de persistencia global: Existe una sola Session para toda la aplicación. Lamás simple de todas, pero obviamente poco escalable. A su vez la que mejor uso hacede la caché de primer nivel.

• Contexto de persistencia por usuario o aplicación: Cada usuario tiene asociada unaSession durante todo el uso de la aplicación. Es también bastante simple, y el cachéde primer nivel es de mucha utilidad para cada usuario, ganando velocidad en lasoperaciones habituales de cada usuario o aplicación. Va en contra del concepto desesiones cortas (mantener la sesión abierta el menor tiempo posible), y aquícomienzan los problemas de acceso concurrente.

• Contexto de persistencia por unidad de trabajo: cada unidad de trabajo requiereuna nueva Session. Primero, hay que aclarar que no es lo mismo contexto depersistencia que "operación". Cada unidad de trabajo consta de varias operaciones, nosolo una.Es la que ofrece mayor escalabilidad, y mayor tolerancia a fallos. Las conexiones sonretornadas al pool en intervalos cortos de tiempo ya que las transacciones son cortas.



Esta solución no aprovecha NADA el caché de primer nivel.

El principal problema del caché de primer nivel es que su eficiencia está limitada a quevarios "usuarios" (o sistemas) utilicen la misma Session al mismo tiempo. Por esto surgela necesidad de contar con un caché a un nivel más alto: el segundo nivel de caché.

2.4.2. Caché de Segundo Nivel

En cambio, la caché de segundo nivel nos permite ir varios pasos más adelante en lamejora del rendimiento. La principal diferencia es que éste tipo de caché es válido paratodas las transacciones y puede persistir en memoria durante todo el tiempo en que laaplicación esté en marcha, es decir, la podríamos considerar como un caché global.

Este nivel se hace cargo de todos los fallos producidos por el caché de primer nivel,permitiendo que desaparezcan los problemas de modificación de datos concurrentes endiferentes contextos de persistencia (uno de los problemas planteados), dado que elsegundo nivel trabaja con todos los objetos recuperados y manejados por todos loscontextos de persistencia. Entonces, ahora, cuando un objeto no se encuentra en el cachéde primer nivel (la session) Hibernate lo buscará en el caché de segundo nivel (si es queesta correctamente configurado). De esta forma nos podemos ahorrar muchos (yrealmente son muchos) accesos a la base de datos.

Caché Segundo Nivel

Hay que tener en cuenta una serie de precauciones a la hora de decidirse por el uso de uncaché de segundo nivel. El problema más importante se presenta con las cachédistribuidas (en clusters o no), y uno más simple y cercano es que no todos los objetos se



verán beneficiados por el uso de un caché de segundo nivel, dependiendo del tipo deoperación que se realice con cada uno y su configuración en el motor de caché utilizado.

Por norma general, se recomienda guardar en caché datos que no cambien con frecuencia,pero esto también tiene algunas excepciones, como son los datos históricos (¿qué sentidotiene cachear información de hace 3 años si no es accedida muy frecuentemente, teniendoen cuenta el costo que supone mantener el caché con esta información?).

Tras decidir el uso de una caché de segundo nivel, se debe determinar que entidades severán beneficiadas con ésta, y tras esto, configurar la estrategia de acceso concurrentepara cada una de estas entidades.

Hibernate dispone de 4 estrategias de acceso concurrente predefinidas (que pueden serampliadas), y conforme se reduce el nivel de rigurosidad, se incrementa el rendimiento:

1. Transactional: Garantiza un nivel de aislamiento que garantiza que lo datos noestán desfasados. Es el nivel más estricto. Solamente se puede utilizar en clusters, esdecir, con cachés distribuidas.

2. Read-write: Igual que el anterior, pero para aplicaciones monolíticas, ya que nopuede utilizarse en cluster. Mantiene un aislamiento hasta el nivel de commited.

3. Nonstrict read-write: No ofrece garantía de consistencia entre la caché y la basede datos. Es una estrategia ideal para almacenar datos que no cambian habitualmentey que no sean demasiado críticos.

4. Read-only: Es la estrategia de concurrencia menos estricta. Recomendada para datosque nunca cambian, es decir, de solo lectura.

Diferentes tipos de datos requieren diferentes políticas de cacheo: el ratio delectura/escritura varía, los tamaños de las tablas varían, y algunas tablas pueden estarcompartidas con aplicaciones externas. La caché de segundo nivel es configurable desdeuna granularidad fina de una clase individual, a una granularidad gruesa para coleccionesde clases. Esto nos permite activar la caché de segundo nivel para clases de datos dereferencia y desactivarla para clases que representen datos financieros. La política decacheo implica decidir:

• Si se activa la caché de segundo nivel• La estrategia de concurrencia• Las políticas de expiración de la caché (como el timeout, LRU/FIFO...)• El formato físico de la caché (memoria, ficheros indexados, cluster replicado, ...)

2.4.2.1. Configuración

Para habilitar la caché de segundo nivel hay que realizar los siguientes pasos:

1. Seleccionar un Proveedor de Caché. En nuestro caso, OSCache.2. Agregar en persistence.xml las siguientes propiedades:

<property name="hibernate.cache.provider_class">org.hibernate.cache.OSCacheProvider

</property>



<propertyname="hibernate.cache.use_structured_entries">true</property>

3. Poner en el classpath de la aplicación el archivo de configuraciónoscache.properties, según las instrucciones que veremos a continuación.

4. Agregar en el mapping de las clases que seleccionamos como "cacheables" lasiguiente entrada:<cache usage="nonstrict-read-write" />

O en cada clase, añadir la siguiente anotación:@org.hibernate.annotations.Cache(

usage =org.hibernate.annotations.CacheConcurrencyStrategy.READ_WRITE)

Otro tema importante es definir qué entidades vamos a cachear, los candidatos naturalesson por ejemplo las clases que representan: estados, tipos, países, monedas o similares.

Hay que tener en cuenta que cuando tenemos relaciones OneToMany hacia éstas entidades,debemos configurarlas como fetch=select (lazy en JPA), no como fetch=join (eageren JPA) porque sino Hibernate va a "levantar" la relación haciendo un join en lugar deintentar obtener el objeto desde el caché.

2.4.3. Regiones de Caché

Hibernate mantiene las diferentes clases/colecciones en diferentes regiones de caché. Unregión no es más que un caché con nombre, de modo que podamos referenciar a unconjunto de clases y colecciones en el proveedor de caché y configurar diferentespolíticas de cacheo aplicables a una determinada región.

Gráficamente una región es como un cubo lleno de datos, de los cuales existen 2 tipos decubos: el primer tipo de regiones contiene las instancias de datos sin sus relaciones, y elsegundo tipo contiene sólo los identificadores de las entidades que están enlazadasmediante colecciones.

El nombre de una región en una clase es el nombre de la clase, y en el caso de unacolección, el nombre de la clase junto al de la propiedad que hace de relación. Así pues,para la clase UsuarioEntity, el nombre de la región seriaes.ua.jtech.entity.UsuarioEntity, mientras que las operaciones realizadas pordicho usuario estarían en es.ua.jtech.entity.UsuarioEntity.operaciones

En el caso de trabajar con diferentes unidades de persistencia (diferentes BBDD),necesitamos añadirle un prefijo al nombre de las regiones. Mediante la propiedadhibernate.cache.region_prefix podemos especificar un prefijo de nombres para unadeterminada unidad de persistencia (EntityManagerFactory).

2.4.4. Proveedores de Caché



Después de decidir que clases vamos a guardar en la caché de segundo nivel y como lasvamos a guardar, nos falta decidir cual va a ser nuestro proveedor de caché y como se vaa comportar. Hibernate no incluye ningún proveedor de caché de segundo nivel, pero sique soporta varios. Un proveedor de caché no es más que una librería donde seimplementan los diferentes algoritmos de la caché de segundo nivel.

Existen varios proyectos Open Source que nos ofrecen diferentes proveedores de caché desegundo nivel, y que Hibernate soporta. La tabla siguiente muestra los proveedoressoportados y su descripción.

Proveedor Adaptador Tipo Estrategias deConcurrencia

Cluster / Cachéde Querys

Hashtable (nopara uso enproducción)

org.hibernate.cache.HashtableCacheProvidermemoria read-only,nonstrict-read-write,read-write

- / si

EHCache org.hibernate.cache.EhCacheProvidermemoria, disco read-only,nonstrict-read-write,read-write

- / si

OSCache org.hibernate.cache.OSCacheProvidermemoria, disco read-only,nonstrict-read-write,read-write

- / si

SwarmCache org.hibernate.cache.SwarmCacheProvideren cluster (ipmulticast)

read-only,nonstrict-read-write

si / no

JBossTreeCache

org.hibernate.cache.TreeCacheProvideren cluster (ipmulticast),transaccional

read-only,transaccional

si / si

Existe la posibilidad de adaptar otros productos de caché simplemente implementando lainterfaz org.hibernate.cache.CacheProvider.

2.4.5. Caducando la Caché

Tal como hemos comentado antes, cada vez que pasamos un objeto a una operación desave(), update() o saveOrUpdate() y cuando recuperamos un objeto medianteload(), get(), list(), iterate() o scroll(), el objeto se añade a la caché de primernivel, interna al contexto de persistencia.

Cuando a continuación se realiza una llamada a flush(), el estado del objeto sesincroniza con la base de datos. Si no queremos que ocurra esta sincronización, o siestamos procesando un gran número de objetos, o necesitamos gestionar la memoria deuna manera eficiente, podemos utilizar el método evict() para eliminar el objeto y suscolecciones de la caché de primer nivel

ScrollableResult libros = sess.createQuery("from Libro as



libro").scroll();// un resultset con muchísimos libroswhile ( libros.next() ) {

Libro libro = (Libro) libros.get(0);operacionConLibro(libro);sess.evict(libro);

}

La Session también ofrece el método contains() para averiguar si la instancia de unobjeto se encuentra en la caché del contexto de persistencia.

Para caducar todos los objetos de la caché, utilizaremos el método Session.clear().

Para la caché de segundo nivel, existen diferentes métodos definidos en laSessionFactory (similar a la EntityManagerFactory) para caducar el estado de unainstancia de la caché, una clase entera, de una colección de instancias o una colecciónentera de clases.

sessionFactory.evict(Libro.class, idLibro); // Caduca un libro enparticularsessionFactory.evict(Libro.class); // caduca todos los libros// caduca una colección particular de capítulossessionFactory.evictCollection("Libro.capitulos", idLibro);//caduca todas las colecciones de capítulossessionFactory.evictCollection("Libro.capitulos");

2.4.6. La Caché de Consultas

La caché de consultas de Hibernate permite almacenar las consultas realizadasrecientemente, de modo que si se vuelven a realizar posteriormente, se recuperen losresultados de un modo mucho más ágil. La caché de consultas es recomendable tan sólopara aplicaciones que hagan realmente muchas consultas y, que además éstas consultas serealicen frecuentemente con los mismos parámetros. Si las operaciones de actualización,eliminación e inserción de entidades, también son muy frecuentes, entonces puede que novalga la pena utilizar una caché de consultas, ya que Hibernate invalida automáticamentelos contextos de persistencia de todas las entidades que participen en dichas operaciones.

La caché de consultas de Hibernate no almacena directamente los objetos, si no que tansólo almacena sus claves. De este modo, se reduce considerablemente el consumo dememoria que de otra manera sería excesivo. Esto tiene como consecuencia el que aunquehayamos hecho una consulta y ésta se haya almacenado en la caché de consultas, sirepetimos la misma consulta varios minutos después, es posible que aunque la consultasiga en la caché, los objetos ya no se encuentren ni en la caché de primer nivel, ni en lacaché de segundo nivel, ya que éstas dos últimas tienen la responsabilidad de gestionarsus entidades, independientemente de lo que haya en la caché de consultas. Comoconsecuencia de esto, aunque una consulta esté en la caché de consultas, puede quetengamos que acceder a la base de datos para recuperar los resultados.

Para habilitar la caché de consultas es necesario introducir en el fichero de configuración



de Hibernate la siguiente línea:

hibernate.cache.use_query_cache=true

Esta configuración provoca la creación de dos nuevas regiones de caché, una quealmacena los resultados de las consultas(org.hibernate.cache.StandardQueryCache), y otra que guarda los timestamps de lasactualizaciones más recientes sobre las tablas consultadas(org.hibernate.cache.UpdateTimestampsCache). Destacar que la caché de consultasno cachea el estado de las entidades en el resultset; cachea sólo los valores identificadoresy los resultados por tipo de valor. Así pues, la caché de consultas debería utilizarsesiempre conjuntamente con la caché de segundo nivel.

La mayoría de consultas no se benefician del uso de la caché, y por tanto, por defecto lasconsultas no se cachean. Para activar el cacheo, para cada consulta hay que llamar a:

Query.setCacheable(true)

Esta llamada permite que la consulta busque en la caché resultados existentes o añada losresultados de una consulta cuando se ejecute una.

Una vez habilitada la caché de consultas, la única forma de aprovecharla es utilizar lainterfaz Query, ya que cualquier otra forma de realizar una consulta es ignorada porHibernate en cuanto al almacenamiento en la caché de consultas. Por ejemplo:

Query queryUsuarios = session.createQuery("from User u where u.rol=:rol");queryUsuarios.setString("rol","Administrador");queryUsuarios.setCacheable(true);

Nuevamente, y para finalizar, destacar que la caché de consultas sólo la hemos de utilizarcuando vayamos a realizar accesos repetidos y similares. El código anterior, no tendríaningún sentido si no se consultasen repetidas veces los usuarios que pertenecen al rolAdministrador, porque si no se van a volver a consultar ¿para qué hemos habilitado lacaché de consultas y estamos almacenando esta última consulta?

Si necesitamos un control con granularidad fina sobre las políticas de expiración de lacaché de consultas, podemos asignarle un nombre a la región de caché para unadeterminada consulta mediante una llamada a:

Query.setCacheRegion()

Por ejemplo, en un supuesto de un blog con un máximo de 15 entradas, podriamos:

List blogs = miSession.createQuery("from Blog blog whereblog.blogger = :blogger")

.setEntity("blogger", blogger)

.setMaxResults(15)

.setCacheable(true)

.setCacheRegion("frontpages")

.list();



Si la consulta debe forzar el refresco de la región de caché, hemos de realizar la llamadaa:

Query.setCacheMode(CacheMode.REFRESH)

Esto es realmente útil en aquellos casos donde los datos pueden haber sido actualizadospor un proceso separado (es decir, no ha sido realizado mediante nuestra API), y quepermite a la aplicación refrescar un conjunto determinado de resultados de consultas. Porlo tanto, este modo es una alternativa eficiente a la caducidad de toda la región de cachéde consultas mediante SessionFactory.evictQueries()

2.4.7. Consejos

El uso de una caché puede aumentar enormemente el rendimiento de muchos sistemas,sin embargo estos no están exentos de problemas, y muchas veces estos problemaspueden ser más costosos que la ganancia obtenida por la utilización del caché. Laactualización concurrente, la elección de estrategias de acceso, el proveedor de caché, laconfiguración de cluster, el caché de consultas... son configuraciones y decisiones quellevan mucho tiempo y análisis, pero que garantizan que una vez realizadas y superadasnuestro sistema tendrá un alto porcentaje de incrementar su eficiencia.

La caché funciona mejor con entidades que no se actualizan frecuentemente o que son desolo lectura. Hemos de asegurarnos que los datos de la base de datos no se actualizan viaun proceso de backend ajeno a nuestra aplicación, ya que sino, tanto nosotros como otrossistemas que trabajen contra los mismos datos podemos llegar a trabajar con datoscaducados.

Es importante dominar el proveedor de caché de segundo nivel para saber como gestionalas entidades y las consultas. Por ejemplo, un proveedor puede que, si una entidad seactualiza dentro de una transacción, actualice dicha entidad cuando se realice el commitde la transacción, mientras que otro proveedor, en cambio, puede tomar la decisión deexpirar el contenido de la caché.

2.5. OSCache

OSCache (http://www.opensymphony.com/oscache) es una solución gratuita de cacheoque incluye una librería de tags JSP y un conjunto de clases para realizar cacheo dinámicocon granularidad fina de contenido JSP, respuestas de Servlets u objetos arbitrarios.

Esta librería ofrece cacheo persistente en disco o en memoria, lo cual permite al sitio webtener una alta tolerancia a los errores (en el caso de que ocurra un error, como pueda serque se caiga la Base de Datos, se puede mostrar la información que estaba cacheada, demodo que los usuarios puede navegar por el site casi sin notar nada extraño).

2.5.1. Problemas Resueltos



http://www.opensymphony.com/oscache

OSCache resuelve problemas fundamentales para las web dinámicas:

Problema Descripción Solución OSCache

Cacheo de ContenidoDinámico

El contenido dinámico dealgunos formularios debeejecutarse tras cada petición,pero a veces ese contenido novaría con cada petición.Cachear toda la página no esuna solución, ya que puedehaber secciones de la páginaque cambian con cada petición.

Mediante el cacheo de objetosy/o secciones de JSPs.

Cacheo de Contenido Binario Las imágenes generadas y losPDFs pueden ser muycostosos en términos de cargadel servidor.

Mediante el uso del filtroCachingFilter, el cualpuede cachear cualquier URI(ya sea una página web enterao una imagen o documentoPDF generado).

Tolerancia de Errores Si ocurre algún error en algúnlugar de una pagina dinámica,el servidor devuelve un erroraunque el 95% restante de lapágina se hubiese ejecutadocorrectamente.

Permitiendo servir el contenidocacheado si se produce unevento de error, y acontinuación, reportar el errorde forma apropiada.

2.5.2. Lista de Prestaciones

Además de las características especificas de los servlets, OSCache se puede utilizar comomecanismo de caché de aplicación para cualquier aplicación Java. Entre las prestacionesgenéricas podemos destacar:

• Cacheo de Objetos Arbitrarios - No solo podemos cachear porciones de código JSPo peticiones HTTP, cualquier objeto Java puede cachearse.

• API Comprensible - El API de OSCache ofrece un control total a nivel programativosobre todas las prestaciones.

• Cacheo Persistente - La caché puede ser almacenada en disco, permitiendo que losdatos que se producen en un proceso de arranque (con un coste computacional alto)permanezcan cacheados incluso cuando la aplicación se reinicia.

• Clustering - Ofrece soporte para clustering de datos cacheado, sin necesidad derealizar ningún cambio a nivel de código.

• Expiración de las Entradas Cacheadas - Ofrece un gran control sobre la expiraciónde los objetos cacheados, incluyendo políticas de refresco configurables.

2.5.3. Configuración

Para que nuestra aplicación pueda utilizar esta librería, el archivo oscache.jar debe



estar en la carpeta WEB-INF/lib de la aplicación web. Toda la configuración de OSCacherecae en el archivo oscache.properties el cual debe encontrarse en el classpath de laaplicación.

El archivo de muestra que obtenemos al descargar la librería es bastante autoexplicatorio(dentro de la carpeta etc). Aun así, vamos a comentar las propiedades más importantes:

• cache.memory: indica si queremos la caché en memoria (true) o en disco (false).• cache.capacity: indica el número de elementos que puede almacenar la caché, aunque

por defecto, la capacidad es ilimitada.• cache.algorithm: indica el algoritmo de caché a emplear cuando se haya especificado

un número fijo en la capacidad de la caché. Por defecto se utiliza un algoritmo LRU,aunque podemos cambiar por FIFO o implementar uno propio.

• cache.path: ruta del archivo en disco donde se almacenará la caché persistente.

En nuestra aplicación, hemos configurado que almacene hasta un máximo de 1000objetos en memoria. Para más información, podéis acceder a la documentación de laconfiguración.

2.5.4. Modo de Empleo

Tal como hemos comentado, podemos utilizar la caché a nivel de contenido dinámicomediante el uso de taglibs o filtros, o utilizar la caché a nivel de aplicación para cachearVOs de la aplicación.

En nuestro caso nos vamos a centrar en la segunda posibilidad, ya que el cacheo decontenido dinámico dentro de una arquitectura MVC no tiene mucho sentido.

Más informaciónSi queréis obtener información acerca de como cachear páginas JSP o el contenido generado porun Servlet, visitad la documentación de la librería.

El primer paso es descargar la librería (la última versión es la 2.4.1):http://www.opensymphony.com/oscache/download.action

Para poder utilizar la caché a nivel de aplicación, hemos de utilizar la clasecom.opensymphony.oscache.general.GeneralCacheAdministrator. Esta clase seencarga de cargar la configuración de la caché a partir del archivo oscache.properties.

Cada vez que queramos trabajar con un objeto candidato a estar en la caché, primerohemos de consultarle a la caché si ya tiene el objeto cacheado, mediante:

cacheAdmin.getFromCache(clave, periodoDeRefresco);

Aquí pueden pasar dos cosas:

• que el objeto esté en la caché y que su contenido no haya caducado, con lo cual lacaché nos devolverá el objeto



http://www.opensymphony.com/oscache/wiki/Configuration.html

http://www.opensymphony.com/oscache/wiki/Documentation.html

http://www.opensymphony.com/oscache/download.action

• o que el objeto no esté en la caché, o que su contenido haya caducado, con lo cual selanzará un excepción de tipo NeedRefreshException. Una vez capturada laexcepción, llega el momento de acceder al contenido real (normalmente accediendo ala Base de Datos).• Si al recuperar el objeto no se produce ningún error, actualizaremos la caché con

este nuevo objeto.cacheAdmin.putInCache(clave, valor);

• Pero si salta alguna excepción, podemos recuperar el contenido que habíacaducado, de modo que la aplicación sigue funcionando, aunque la informaciónmostrada no sea la información actualizada. Para ello:

miValor = (ClaseDeMiValor) excepcionRefresco.getCacheContent();cacheAdmin.cancelUpdate(clave);

Lo mismo pero mediante un diagrama:

Diagrama de actividad de acceso a la caché

A continuación se muestra un pequeño esquema de trabajo con OSCache.

String myKey = "myKey";



String myValue;int myRefreshPeriod = 1000;

try {// obtenemos de la caché// (admin es una instancia de GeneralCacheAdministrator)// el objeto identificado por una clave unívoca// y le indicamos el periodo de refresco (en ms)myValue = (String) admin.getFromCache(myKey, myRefreshPeriod);

} catch (NeedsRefreshException nre) {try {

// obtenemos el valor, normalmente accediendo a la bbddmyValue = "Estos son los datos obtenidos.";// Almacena el objeto identificado por la clave en la cachéadmin.putInCache(myKey, myValue);

} catch (Exception ex) {// podemos obtener el contenido "caducado"// para ofrecer tolerancia de fallosmyValue = (String) nre.getCacheContent();// Es imprescindible realizar la llamada a// cancelUpdate si no se ha recargado el contenido cacheadoadmin.cancelUpdate(myKey);

}}

Para facilitar la comprensión de este esquema, vamos a aplicar este mecanismo a laBiblioteca jTech.

2.6. Caché en la Biblioteca jTech

Con la arquitectura que tenemos preparada, que ofrece puertas de entrada mediantefactorías tanto al negocio como a los datos, podemos introducir tanto un mecanismo decacheo de aplicación en la capa de datos (y en el futuro en la de negocio), o bien, si yatenemos la capa de datos codificada con JPA podemos aprovecharnos de lascaracterísticas de Hibernate.

Para el siguiente ejemplo, vamos a plantear el uso de una caché de aplicación medianteOSCache, y en concreto, vamos a cachear el DAO del libro, de modo que mientras no semodifique ningún atributo de un libro, mantenga en caché los datos de cada libro.



UML con la Caché

2.6.1. CacheManager

Esta clase es la encargada de inicializar la caché. Por defecto, busca en el classpath elarchivo oscache.properties (en nuestro caso, en la carpeta resources del proyectoEclipse, que a posteriori, a la hora del despliegue, se copia en WEB-INF/classes).

Para evitar múltiples instancias de este gestor de caché, utilizando el patrón Singleton, nosaseguramos de que solo haya un único objeto caché en la aplicación (siempre y cuando notengamos ningún cluster).

package es.ua.jtech.proyint;

import org.apache.commons.logging.Log;import org.apache.commons.logging.LogFactory;

import com.opensymphony.oscache.general.GeneralCacheAdministrator;

public class CacheManager {

private static CacheManager me = new CacheManager();

private Log logger =LogFactory.getLog(CacheManager.class.getName());

private GeneralCacheAdministrator cache = null;



private CacheManager() {try {

cache = new GeneralCacheAdministrator();} catch (Exception e) {

logger.error("Error al inicializar la cache", e);e.printStackTrace();

}

logger.info("Cache Creada");}

public static CacheManager getInstance() {return me;

}

public GeneralCacheAdministrator getCache() {return cache;

}}

2.6.2. FactoriaDAOs

Ahora, en la factoría, en vez de instanciar un DAO concreto, creamos una nuevaimplementación que funcione como envoltorio del DAO situando la caché entre elnegocio y los datos.

public class FactoriaDAOs {

private static FactoriaDAOs me = new FactoriaDAOs();

private GeneralCacheAdministrator cache = null;

private FactoriaDAOs() {// Obtenemos la cachéthis.cache = CacheManager.getInstance().getCache();

}

public static FactoriaDAOs getInstance() {return me;

}

public IUsuarioDAO getUsuarioDAO() {// En este DAO no cacheamosreturn new UsuarioJDBCDAO();

}

public ILibroDAO getLibroDAO() {// En este DAO cacheamos

return new LibroCacheDAO();}

public IOperacionDAO getOperacionDAO() {return new OperacionJDBCDAO();

}}



2.6.3. LibroCacheDAO

Por lo tanto, necesitamos un envoltorio del DAO que haga de puente entre la caché y losdatos, de modo que a nivel de método podemos decidir que métodos cacheamos.

Podemos observar en el siguiente código como OSCache soporte el uso de diferentesregiones de cacheo. En el ejemplo, hemos creado una región GRUPO_LIBRO paraalmacenar todos los datos relativos a los libros. Podemos trabajar con las regiones tantoen la operación de colocar un objeto en la caché mediante put() que ofrece métodossobrecargados para admitir un array de cadenas, siendo cada cadena el nombre de unaregión (claramente, un objeto puede pertenecer a más de una región), como al caducar lacaché con flushGroup().

package es.ua.jtech.proyint.dao.libro;

// imports

/*** Capa de cache de datos que hace de puente con JDBC** @author $Author: amedrano $* @version $Revision: 1.12 $*/public class LibroCacheDAO implements ILibroDAO {

private static Log logger =LogFactory.getLog(LibroCacheDAO.class.getName());

private GeneralCacheAdministrator cache;private final static String GRUPO_LIBRO = "GrupoLibro";private ILibroDAO dao;

public LibroCacheDAO() {this.cache = CacheManager.getInstance().getCache();this.dao = new LibroJDBCDAO();

}

public LibroCacheDAO(GeneralCacheAdministrator laCache) {this.cache = laCache;this.dao = new LibroJDBCDAO();

}

@Overridepublic void addLibro(LibroEntity libro) throws DAOException {

dao.addLibro(libro);cache.flushGroup(GRUPO_LIBRO);

}

@Overridepublic int delLibro(String isbn) throws DAOException {

int result = dao.delLibro(isbn);cache.flushGroup(GRUPO_LIBRO);return result;

}



@Overridepublic LibroEntity getLibro(String isbn) throws DAOException {

LibroEntity result = null;String key = "getLibro(" + isbn + ")";

try {result = (LibroEntity) cache.getFromCache(key, 600);

} catch (NeedsRefreshException nre) {try {

result = dao.getLibro(isbn);cache.putInCache(key, result,

new String[] { LibroCacheDAO.GRUPO_LIBRO});

} catch (Exception ex) {logger.warn("Recuperando libro de la cache", ex);result = (LibroEntity) nre.getCacheContent();cache.cancelUpdate(key);

}}return result;

}

@Override@SuppressWarnings("unchecked")public List<LibroEntity> getLibros() throws DAOException {

List<LibroEntity> result = null;String key = "getLibros()";

try {result = (List<LibroEntity>) cache.getFromCache(key,

600);} catch (NeedsRefreshException nre) {

try {result = dao.getLibros();cache.putInCache(key, result,

new String[] { LibroCacheDAO.GRUPO_LIBRO});

} catch (Exception ex) {logger.warn("Recuperando libros de la cache", ex);result = (List<LibroEntity>) nre.getCacheContent();cache.cancelUpdate(key);

}}return result;

}

@Overridepublic int updateLibro(LibroEntity libro) throws DAOException {

int result = dao.updateLibro(libro);cache.flushGroup(GRUPO_LIBRO);return result;

}

}

El código fuente y los ficheros de configuración mostrados se pueden descargar aquí.



PreguntaEn nuestra aplicación, ¿Que sucede si un usuario realiza una reserva? ¿Debemos caducar losdatos de los usuarios? ¿Seria mejor definir una política de regiones (grupos en OSCache) congranularidad más fina?

A modo de conclusión, destacar lo fácil que es añadir una caché a una aplicación. Lo másdifícil respecto al uso de una caché es definir una buena política de cacheo ycaducidad de los datos, analizando las dependencias entre los diferentes componentes dela aplicación.

2.7. Para Saber Más

2.7.1. Bibliografía

• Java Persistence with Hibernate, de Christian Bauer y Gavin King. De loscreadores de Hibernate, en el capítulo 13 se explica con amplitud el uso de la cachécon Hibernate.

2.7.2. Enlaces

• Articulo de Martín Pérez sobre Hibernate y el uso de Cachéhttp://www.javahispano.org/articles.article.action?id=95

• Documentación de Hibernate y la Caché de Segundo Nivelhttp://www.hibernate.org/hib_docs/v3/reference/en/html/performance.html#performance-cache



http://www.javahispano.org/articles.article.action?id=95

http://www.hibernate.org/hib_docs/v3/reference/en/html/performance.html#performance-cache

3. Arquitecturas Java EE

Esta charla se enfoca partiendo de un repaso de las diferentes capas lógicas (layers) deuna aplicación, para luego centrarnos en diferentes planteamientos de arquitecturadependiendo del uso o no de un servidor de aplicaciones.

3.1. Bloques Arquitectónicos

Tal como comentamos en la primera sesión de arquitectura, los 3 bloques arquitectónicosmás importantes son:

• Capa de Servicios de Negocio. Elemento central de las aplicaciones.• Capa de Presentación. Interfaz gráfico o fachada remota.• Capa de Acceso a Datos. Objetos que acceden a un almacén persistente

(normalmente, una o más bases de datos relacionales).

3.1.1. Capa de Servicios de Negocio

La clave de una arquitectura sólida es una capa de servicios bien definida. Esta capaexpone la lógica de negocio a los clientes, como interfaces web o capas remotas. Estacapa consistirá en múltiples interfaces, cada uno con un contrato bien definido.

Una capa de servicios bien definida debería:

• Ser completa. Debería exponer todas las operaciones que necesiten los clientes.Puede que sea necesario exponer diferentes interfaces que den soporte a los diferentesclientes.

• Ser simple. No debe ser más compleja que los requisitos de negocio que ofrece.• Estar definida mediante interfaces en vez de clases, persiguiendo las buenas

prácticas de OO.• Ser orientada a objetos. Se debe minimizar el número de restricciones de los objetos

de negocio. Por ejemplo, no se debe forzar a que implementen interfaces especiales oque hereden de alguna superclase particular.

• Ser independiente de la lógica de presentación• Ser fácil de escribir, maximizando la productividad y reduciendo los costes.• Forzar la ocultación de la tecnología de acceso a datos. El acceso a datos es un

tema de bajo nivel, y por tanto, los objetos de negocio no deben tratar con tecnologíascomo JDBC ni capturar excepciones específica de este tipo de tecnologías.

• Tratar la gestión de transacciones. Los clientes de la capa de servicios de negociono se deberían preocupar sobre las transacciones.

• Ser compatible con el escalado horizontal (si fuese necesario). Nada de la capa denegocio debe impedir la realización de un cluster. Sin embargo, esto no significa quela capa de negocio ofrezca escalado horizontal. No tiene por que ser un mecanismodistribuido.



• Ser fácil de probar y estar probada a conciencia. Esto es crucial, ya que la robustezde un objeto de negocio es esencial para construir aplicaciones de calidad.

3.1.1.1. Acciones Web dentro de MVC

¿Qué sucede si no existe capa de negocio y toda la lógica de negocio residen en la capaweb dentro de un Action de Struts o un Controlador Spring, u otras clases de la capa web?

Esto suele ocurrir por la falta de una gestión de los objetos de negocio en aplicacionesJavaEE que no utilizan EJB. Las desventajas son numerosas, incluyendo:

• Atar los objetos de negocio al API de los Servlets.• Reutilización limitada de los objetos de negocio. Un framework como XWork, el cual

desacopla los Actions del API de los Servlets puede paliar este problema.• Dependiendo del framework MVC utilizado, podemos perder capacidades de OO, ya

que, por ejemplo, mediante el uso de Struts los Actions deben heredar de las clases deStruts, lo que nos priva de poder realizar herencia sobre otras clases.

• Responsabilidades difusas en la capa web. Cada clase debería tener una sola y clararesponsabilidad. Con este enfoque, las clases de la capa web al menos tienen 2responsabilidades bien diferentes.

• Ausencia de soporte para la gestión declarativa de transacciones (Spring AOP sepuede utilizar para los controladores web, o los filtros de Servlets se puede utilizapara gestionar las transacciones en una aplicación web, pero estas son soluciones tipotirita para problemas mejor resueltos de forma separada al API de los Servlets).

• La lógica de negocio es difícil de probar, causado por los elementos implícitos delcontenedor web.

3.1.1.2. Capa de Servicios en un Contenedor Ligero

La tendencia actual es utilizar una capa de servicio de negocio mediante POJOs corriendosobre un contenedor ligero, tipo Spring o PicoContainer, el cual reemplaza la estructurade los EJB con mucha menos complejidad.

En pocas palabras, un contenedor ligero:

• Gestiona el ciclo de vida de los objetos de negocio. La principal diferencia con losEJBs es que un contenedor ligero puede gestionar POJOs: no hay necesidad deimplementar contratos especiales.

• Ofrece facilidades de lookup, resolviendo la dependencia entre objetos gestionadospor el contenedor. El paradigma de Inversion Of Control (IoC) es el elemento centralde este tipo de contenedores ligeros.

• Ofrece servicios empresariales (mediante AOP) como gestión declarativa detransacciones sobre objetos corriendo dentro del contenedor, devaluando una de losprincipales defensas de EJB.

Los contenedores ligeros promueven el uso de buenas prácticas OO, como que los



clientes realicen la llamadas a interfaces y no a clases. Estos interfaces definen contratosen la capa de negocio, los cuales permiten el intercambio de diferentes implementaciones.IoC hace de esta separación interfaz/implementación una cosa sencilla.

Los objetos de negocio y los componentes de la capa de presentación que utilizan estosBOs se ejecutan en la misma máquina virtual (JVM). La escalabilidad horizontal se puedeconseguir mediante el clustering de la aplicación entera en máquinas virtualesadicionales.

A partir de una capa de servicios bien definida, los clientes de los servicios deberían sermás sencillos.

3.1.1.3. Limitaciones de Qué se Puede Exponer

Hay algunas cosas que una capa de servicio no debería exponer al resto del mundo. Porejemplo:

• Si la capa de servicios es remota, es obligatorio trabajar con parámetros y tipos deretorno Serializable. También hay que considerar la eficiencia ¿Cuanto costará queestos objetos se codifiquen (marshall) y descodifiquen (unmarshall) para viajar através de la red?

• Con algunas tecnologías de persistencia, puede ser necesario desconectar los objetosdel almacén persistente de un modo explicito.

ImportanteLa desconexión de un almacén persistente es un problema común e importante.

En la mayoría de tecnologías persistentes, existen retos en desconectar los objetospersistentes de sus almacenes. La solución pasa por:

• Utilizar una capa de Transfer Objects (TOs) para mantener los datos desconectados,incluso en aplicaciones que residen en un único nivel. Esto se suele evitar, lo cualfuerza la escritura de objetos falsos y malgasta las ventajas de una arquitecturamononivel.

• Usar un API de acceso a datos como Hibernate o JDO 2.0 que permita la desconexióny reconexión de los objetos persistentes. Como con los TOs, esto requiere materializartodas las relaciones necesarias.

• Evitar las tecnologías como los EJBs de Entidad que descartan las desconexiones.• Mantener la sesión de persistencia abierta hasta que el trabajo del cliente haya

terminado, por ejemplo, en una aplicación web, hasta que la vista pinte los datos. Aprimera vista es una opción atractiva, ya que elimina los problemas de traslado derelaciones hasta la profundidad requerida, pero en realidad es peligroso, ya que lasexcepciones relacionadas con la persistencia pueden provocar problemas en la capa depresentación.



3.1.2. Capa de Presentación

El requisito más común es exponer los servicios de negocio vía un interfaz web. En estaarquitectura, existe un línea divisoria que fuerza la distribución, la que existe entre elcliente y su navegador, y el servidor web. Sin embargo, no son necesarias más barrerasdistribuidas, ya que normalmente todo funciona mejor sin los costes asociados a losobjetos distribuidos.

Navegador-Contenedor Web

Lo que comúnmente se conoce como arquitectura JavaEE (J2EE) tradicional u ortodoxapromueve la separación física entre el nivel web (vía un Contenedor Web) y los objetosde negocio (vía un Servidor de Aplicaciones). La tendencia señala en otra dirección,donde toda la aplicación reside un único nivel y, como hemos comentado, la escalabilidadse consiga mediante el clustering de servidores.

Navegador-Contenedor Web-Servidor Aplicaciones

ConsejoColoca los objetos de negocio en el contenedor web (mononivel).Este es el enfoque más sencillo, con mejor rendimiento, y con un enfoque más OO.La separación de los BOs del nivel web es una de las falacias del mundo JavaEE.

Puede haber un línea divisoria entre el servidor web y el contenedor web. Por ejemplo, sepuede utilizar Apache como servidor HTTP, con un conector proxy el cual envíepeticiones al contenedor JavaEE. Esta distribución no afecta al código de la aplicación.Lo que varía es el efecto en el rendimiento. Normalmente este enfoque es más lento quesi el contenedor web sirve todo el contenido web, a no ser que exista un gran proporción



de contenido estático respecto al dinámico. Otra razón puede ser por cuestiones deseguridad, colocando todas las partes de la aplicación JavaEE detrás de un firewall.

3.1.2.1. Importancia de la Separación Lógica

Parece ser que por lo general, no queremos una separación física de los objetos denegocio del nivel web. Sin embargo, si queremos una separación lógica, y el hecho derechazar la separación física no implica que olvidemos esto.

El primer paso para tener una separación lógica es tener una capa de servicios de negociobien definida. Sin embargo, también debemos asegurar que el acceso a estos servicios seafácil y que no produzca una dependencia en la capa de UI o en la tecnología detrás delinterfaz de los servicios de negocio

La mayoría de las aplicaciones JavaEE contienen demasiado código dentro de la capaweb, ya sea porque pocos libros enfatizan la importancia de esta separación (se centranmás en separar la lógica de control de la vista), que los frameworks MVC tipo Struts noobligan a realizar esta separación, y al no obligar, los desarrolladores tienden a colocar lalógica de negocio en los Action, o bien porque parece que la solución más fácil seacolocar todo en el Action y evitar la creación de las diferentes capas mediante el uso deinterfaces/implementaciones desacopladas mediante factorías.

En resumen, el interfaz web debería ser ligero. Se debería construir sobre la capa deservicio y únicamente contener el código necesario para capturar los eventos del usuariosy visualizar las respuestas.

3.1.2.2. Clientes Remotos

El uso de los clientes remotos debe tratarse con cuidado. Aunque no se trata de un accesocomplejo, los servicio de negocio solo deben exponer interfaces remotos cuando seanecesario.

Aunque nuestros servicios de negocio no incluyan soporte nativo para el acceso remoto,el proceso de añadir una fachada sobre la capa de servicios es tan fácil como añadir unafachada web.

Las elecciones para acceder a servicios remotos se centran en RMI (Remote MethodInvocation), la cual es la tecnología que utilizan los EJBs para la comunicación remota delos componentes; también se pueden utilizar diferentes protocolos Hessian o Burlap víaCommons Proxy (commons.apache.org/proxy) o el uso de servicio SOAP con WebServices vía herramientas como Apache Axis/Axis2 (ws.apache.org/axis yws.apache.org/axis2)

3.1.3. Capa de Acceso a Datos

El acceso a los datos persistentes normalmente determina el rendimiento global de las



http://commons.apache.org/proxy

http://ws.apache.org/axis/

http://ws.apache.org/axis2

aplicaciones empresariales, ya que el almacén suele ser el cuello de botella. Los datospersistentes suelen almacenarse en una base de datos relacional, aunque en ocasionespodemos tener múltiples almacenes con transacciones distribuidas o aplicaciones legacy.

El concepto de capa de acceso a datos engloba una o más bases de datos, aunque elconcepto de una capa EIS (Sistema de Información Empresarial) engloba no solo a lasbases de datos, sino también sistemas legacy, los cuales también suelen sertransaccionales.

3.1.3.1. Tecnologías

Las tecnologías de acceso a datos incluidas en JavaEE son JDBC, JDO y JPA. Sinembargo, es muy común utilizar productos de terceros, y en la mayoría de las ocasiones,vale la pena.

Antes de JPA, el uso de EJBs de Entidad producía , el uso de EJBs de Entidad produceresultados no muy buenos. Esta apreciación está ampliamente aceptada dentro de lacomunidad JavaEE. ¿Qué nos queda?

• JDBC es una buena tecnología para acceso a bases de datos relacionales vía SQL. Siutilizas JDBC, hazlo indirectamente mediante una buena capa de abstracción.Frameworks como Commons DbUtils (jakarta.apache.org/commons/dbutils) y ApacheiBatis (ibatis.apache.org) facilitan y mejoran la calidad de este tipo de código.

• Hibernate es un excelente tecnología ORM• A pesar de la lenta adopción desde su lanzamiento en 2001, JDO esta emergiendo

como estándar Java de persistencia.• Alternativas comerciales como TopLink, aunque no tengan nada que los hagan muy

superiores (normalmente, asistentes gráficos y soporte por parte de las empresaspropietarias) a Hibernate o JDO.

Como ya sabemos, podemos mezclar y encajar código basado en SQL con persistenciaORM. El patrón DAO es la elección correcta, ya que oculta los detalles de lasoperaciones de persistencia tras un interfaz DAO, el cual libera a los objetos de negociode conocer que tecnología de persistencia se está utilizando.

3.2. Arquitectura y Java EE

Desarrollar aplicaciones con arquitecturas multinivel implica el uso de computacióndistribuida, lo que complica el proceso de desarrollo. Aunque la plataforma JavaEEsimplifica en gran medida el desarrollo de sistemas en tres niveles, el diseño decomponentes distribuidos es más complejo que si nos centráramos en uno o dos niveles.

Esta complejidad extra debe estar justificada por los requisitos del sistema, ya que se tratade una decisión que va a condicionar la naturaleza del proyecto.

Si podemos evitar el uso de una arquitectura distribuida para los sistemas que no lo



http://jakarta.apache.org/commons/dbutils/

http://ibatis.apache.org/

necesitan, obtendremos un diseño más simple. El hecho de evitar la complejidad nos va aayudar a cumplir un calendario apretado.

La complejidad va a:

• dificultar la comprensión del diseño y el código• alargar los tiempos de desarrollo debido a la curva de aprendizaje• encarecer el mantenimiento del software• dificultar la evaluación y aplicación de los cambios• provocar la realización de errores

A continuación vamos a evaluar las ventajas e inconvenientes de los sistemas distribuidosy considerar posibles arquitecturas que no se basen en componentes distribuidos

3.2.1. Arquitecturas de 2 Capas vs Multicapa

Antes de la entrada de las tecnologías distribuidas como JavaEE o CORBA, los sistemasde empresa normalmente utilizaban una arquitectura de 2 capas conocida comocliente/servidor, la cual se desplegaba a su vez en 2 niveles.

Bajo el modelo de cliente/servidor, la lógica de negocio se implementaba como parteintegrada de un cliente rico y pesado que accedía al servidor para obtener los datos de unabase de datos centralizada.

El modelo cliente/servidor disfrutó de un éxito considerable, ya que era fácil decomprender, fácil de probar y soportado por numerosas herramientas de desarrollo visuala alto nivel.

El problema es que la arquitectura de 2 capas/niveles tiene las siguientes limitaciones:

• Despliegue: en las grandes empresas donde existen miles de clientes, el hecho derealizar un despliegue supone un reto logístico

• Compartición de servicios: si la aplicación debe compartir servicios dentro de laempresa, y la lógica esta integrada con los clientes, tenemos una gran redundancia decódigo entre las diferentes aplicaciones.

• Pobre separación de la presentación y la lógica de negocio: este tipo dearquitectura provoca un alto acoplamiento, ya que es muy fácil mezclar ambas capas.

Debido a estas limitaciones, la comunidad de desarrollo concluyó que era necesaria unatercera capa de negocio que se colocara entre las 2 anteriores, apareciendo la necesidad deun tercer nivel.

El uso de una capa intermedia de negocio ofrece ciertos beneficios respecto al modelocliente/servidor:

• Inteligencia de negocio centralizada: al estar centralizado y accesible por un sistemaremoto, resuelve el problema de juntar presentación y negocio

• Fácil despliegue: ya no es necesario actualizar miles de cliente. Al tener el negocio



centralizado, los cambios se pueden desplegar de forma rápida y fácil con un mínimoimpacto sobre el sistema base del usuario

• Redundancia: al poder desplegar la capa de negocio en un cluster, ofrecemos unconjunto de máquinas replicadas que mantienen un entorno de alta disponibilidad

• Escalabilidad: del mismo modo, el cluster de negocio nos permite incrementar elnúmero de máquinas conforme crece la demanda de los clientes.

Estos beneficios han provocado que el modelo multicapa sea la arquitectura por defectopara las aplicaciones de empresa. La plataforma JavaEE ofrece componentes distribuidospara desarrollar sistemas mediante arquitecturas multicapa/multinivel, siendo los EJBsuna tecnología clave para los componentes de negocio distribuidos en un nivelintermedio.

3.2.2. Enterprise JavaBeans

Los EJBs permiten desarrollar aplicaciones usando una arquitectura basada encomponentes.

La arquitectura EJB define componentes, conocidos como Beans de Empresa, queencapsulan funcionalidad en módulos desplegables, los cuales están claramente definidosmediante interfaces.

Como ya sabemos, la plataforma JavaEE ofrece 3 tipos de EJBs:

• Beans de Sesión (SBs): encapsula la lógica de negocio• Beans de Entidad (EBs): mecanismo que ofrece una vista de entidades basadas en

objetos dentro de un almacén persistente de datos.• Beans dirigidos por el Mensaje (MDBs): consume mensajes entregados al servidor

via el API JMS

Una arquitectura EJB ofrece beneficios substanciales a la hora de construir una aplicaciónempresarial:

• Incrementa la productividad mediante la gestión de las transacciones y la seguridadmediante información especificada en el descriptor de despliegue.

• Ofrece escalabilidad gestionando inteligentemente los recursos y ofreciendotransparencia de estado en los componentes "con estado".

• Ofrece y hace de mediador entre los componentes de negocio y múltiples tipos decliente, tanto pesado como aplicaciones web ligeras.

• Aísla al cliente de los temas de la red mediante transparencia de localización, demodo que se pueden invocar a los componentes sin necesidad de saber donde estándesplegados.

Este último punto de transparencia de localización es de especial interés, ya que los EJBspermiten el desarrollo de arquitecturas distribuidas mediante el modelo de componentesque ofrece JavaEE.



3.2.3. Interfaces Remotos o Locales

Los clientes de un bean de sesión pueden acceder a éste mediante su interfaz remoto olocal. Si se utiliza el interfaz remoto, un cliente ejecutándose en una JVM separadaaccede a la instancia del EJB. Con acceso local, el cliente reside en la misma JVM quebean.

De forma alternativa, con la especificación de EJB 2.1, los cliente puede acceder a losbeans mediante Web Services. Esto no es más que otra forma de acceso remoto.

3.2.4. Componentes Distribuidos

El uso de EJBs con interfaces remotos permite el desarrollo de sistemas con arquitecturasdistribuidas. La plataforma JavaEE ofrece una gran ayuda para construir arquitecturascomplejas de éste tipo. Sin embargo, añadir interfaces remotos a los objetos de negocioimplica ciertos aspectos que el arquitecto debe tener en cuenta antes de decidirse por estetipo de planteamiento.

3.2.4.1. Rendimiento

La tecnología EJB se basa en el estándar RMI, él cual ofrece la transparencia necesariapara acceder a un bean a través de su interfaz remoto. Sin embargo, el proceso de ejecutaruna invocación a un método a través de una JVM o entre máquinas distintas, hace lasllamadas RMI mucho más costosas que si se hicieran a un objeto local.

Por cada llamada, RMI crea un objeto stub en el cliente que se responsabiliza de enviarlos parámetros del método y de recibir la respuesta a través de la red (marshalling). Elstub del cliente no habla directamente con el objeto del servidor, sino con el skeletonRMI. Del mismo modo, una vez ejecutado el método remoto, este skeleton se volverá acomunicar con el stub del cliente para devolver la información.

Por ello, se produce una sobrecarga en la llamada de los métodos. Por lo tanto, tenemosque cuidar el diseño de las llamadas para asegurarnos que los beneficios de latransparencia de localización no son menores que la penalización de rendimientoobtenida.

ConsejoEl paso de objetos pesados en las llamadas remotas reduce el rendimiento gravemente. Si unobjeto contiene referencias a otros objetos, entonces estos objetos miembros también sonserializados como parte de la llamada.Para reducir el tamaño de algunos objetos, se pueden excluir objetos innecesarios marcándoloscon la palabra clave transient

3.2.4.2. Complejidad



Aunque RMI puede hacer parecer que simplifica las llamadas a un bean remoto, lacomputación distribuida introduce cierta complejidad extra al desarrollador.

Se debe tener en cuenta la diferencia entre el paso de variables por valor en las llamadasremotas, y el paso por referencia en las locales. Además, los clientes remotos puedengestionar las posibles excepciones lanzadas por problemas en la red.

3.2.4.3. Impedancia Orientada a Objetos

El uso de las capacidades distribuidas de los EJBs requiere un cambio en el modo queaplicamos las prácticas de diseño orientado a objetos.

En una arquitectura no-distribuida, los desarrolladores trabajan directamente con losobjetos del modelo del dominio. Aquí, los objetos del dominio representa entidades denegocio y exponen interfaces con métodos de granularidad fina, como pueden ser losmétodos get y set de un javabean.

La penalización de rendimiento de una aplicación distribuida descarta el uso de éste tipode objetos, ya que incrementa el número de llamadas a través de la red.

Para mantener el número de viajes de ida y vuelta al mínimo, los interfaces remotos sedeben diseñar con granularidad gruesa, donde los métodos combinan la funcionalidad devarios métodos finos en una sola llamada.

Una ayuda a la hora de diseñar los métodos es el uso de los patrones de diseño, enespecial, aquellos que tratan con componentes distribuidos, como pueden ser SessionFaçade y Transfer/Value Object. Más información en Patrones para AplicacionesDistribuidas

A pesar de la existencia de los patrones, el arquitecto debe tener en cuenta lasrestricciones que ofrecen las tecnologías, y reflejarlo en las arquitecturas diseñadas. Si lastecnologías marcan el modo de diseñar el interfaz de un componente, estamoscontradiciendo las pautas de un buen diseño orientado a objetos.

3.2.5. Elección de un Diseño Apropiado

Los componentes distribuidos no son un prerrequisito para todas las arquitecturasempresariales. A menos que los requisitos del sistema dicten la necesidad de unaarquitectura distribuida, siempre se podrá implementar una aplicación más sencilla queevite el uso de las llamadas remotas.

ImportanteLa decisión arquitectural de utilizar componentes distribuidos va a condicionar la complejidad dela aplicación, y por ello, los costes (económicos y temporales) del proyecto.



http://www.jtech.ua.es/j2ee/2007-2008/restringido/pat/sesion03-apuntes.html

http://www.jtech.ua.es/j2ee/2007-2008/restringido/pat/sesion03-apuntes.html

3.3. Propuestas de Arquitecturas Java EE

3.3.1. Arquitectura Web

En los últimos tiempos, predominan los clientes web ligeros respecto a los interfaces deusuario pesados (Swing), aunque no hemos de descartarlos. Por lo tanto, las aplicacionesweb son el estándar de facto de las aplicaciones empresariales.

Estas arquitecturas, fácilmente escalables a nivel de hardware (clustering), puedenacceder al mismo tipo de APIs que los EJBS, además, se benefician de las capacidadesque ofrece el servidor J2EE, como pueden ser la gestión de transacciones y el pool deconexiones. Finalmente, también pueden utilizar todos los servicios de empresas, talescomo JMS, JDBC, JavaMail y JCA. La única tecnología a la que no puede acceder es alos Entity Beans. Por lo tanto, cubre las necesidades de la mayoría de las aplicaciones.

En este tipo de arquitectura, tanto la capa web como la de negocio se ejecutan en lamisma JVM, normalmente desplegadas sobre un contenedor web (tipo Tomcat, Resin,etc...). Sin embargo, es muy importante, que a nivel lógico si que las separemos. Uno delos mayores riesgos a la hora de diseñar una aplicación web es mezclar responsabilidadesentre componentes de presentación y de lógica de negocio.

3.3.1.1. Ventajas

El uso de arquitecturas web ofrece las siguientes ventajas:

• Velocidad. Estas arquitecturas son mínimamente penalizadas por el servidor J2EE.• Los interfaces de usuario y los componentes de negocio se ejecutan dentro de la

misma JVM, lo cual ofrece un gran rendimiento.• Al ejecutarse en una única JVM, posibilidad de hacerlo en un contenedor web, lo que

conlleva licencias más baratas y administración más sencilla.• El uso de POJOs en vez de EJBs para encapsular la lógica de negocio elimina las

configuraciones adicionales y complejidades de acceso y despliegue asociadas con latecnología EJB.

• Mayor portabilidad entre servidores de aplicaciones o contenedores web. Al habermenos configuraciones, es más fácil su portabilidad.

• Las pruebas unitarias de los objetos de negocio, en principio, son más sencillasporque no necesitamos desplegarlos en el servidor J2EE para poder probarlos.

• No se realizan llamadas RMI, por lo que se mantiene la convención de llamada porpaso de referencia.

• Los objetos de negocio pueden exponer interfaces de granularidad fina.

Un prerequisito de la mayoría de arquitecturas empresariales es la escalabilidad. Este tipode arquitectura puede escalar mediante múltiples servidores con la ayuda debalanceadores de carga que repartan las peticiones entre los diferentes nodos de servidor.



3.3.1.2. Limitaciones

Como toda solución, este tipo de arquitectura también tiene sus limitaciones, entre las quese encuentran:

• Sólo soporta interfaces web. Si fuera necesaria que un cliente pesado acceder a lacapa de negocio de forma remota, entonces necesitaríamos una capa de servicios web(por ejemplo, mediante Apache Axis) o una arquitectura EJB.

• Falta de un entorno estándar para gestionar los objetos de negocio.• Puede no existir una capa de servicios de negocio bien definida. Se puede evitar

mediante el uso de frameworks web, tipo Struts, Spring, etc...• Puede que necesitemos implementar "a mano" algún tipo de solución que los EJBs ya

ofrecen, como puedan ser la gestión de transacciones declarativas o el modelodeclarativo de seguridad, que nos toca implementarlo mediante el código de laaplicación.

• No existe un estándar de configuración de los objetos de negocio (aunque los EJBstampoco lo hacen muy bien).

• Falta de consistencia entre aplicaciones, o incluso en una misma aplicación. Cadaaplicación tiende a manejar a su modo el acceso a los objetos de negocio, suconfiguración, la gestión de transacciones, etc... Por lo tanto, cada aplicación requierede su propia curva de aprendizaje.

El mayor inconveniente que puede ser la falta de una capa de servicios claramentedefinida, se puede resolver mediante el uso consistente de interfaces de negocio y elacceso consistente a los objetos de negocio.

3.3.1.3. Implementación

En esta arquitectura, la capa de servicios de negocio consiste en un conjunto de interfacesJava implementados mediante POJOs (clases Java normales y corrientes).

Pregunta¿Sabrías identificar los elementos del siguiente gráfico con la implementación que hemosrealizado en el proyecto de integración?



Arquitectura Web

3.3.2. Arquitectura Contenedor Ligero

Por supuesto que las arquitecturas JavaEE pueden ser exitosas sin EJBs. Sin embargo, sepuede utilizar algunas de las buenas ideas de los EJBs y llevarlas a una arquitectura sinEJBs. Para ello, se utiliza una arquitectura de Contenedor Ligero.

Del mismo modo que los EJBs, se plantea una arquitectura centrada a partir de una capade servicios de negocio gestionados por el contenedor. Pero aquí se acaba la similitud. Envez de ejecutarse dentro de un contenedor EJB, los objetos de negocio corren dentro deun contenedor ligero.

Un contenedor ligero no está atado a JavaEE, por lo que puede correr en un contenedorweb, una aplicación "standalone", o incluso en un contenedor EJB (si fuese necesario).Además, tampoco esta atado al API de los Servlets, como los frameworks MVC, lo cualseria una pobre elección para gestionar los objetos de negocio.

Los contenedores ligeros tienen un coste de arranque insignificante y elimina el procesode despliegue necesario en los EJBs. Los contenedores ligeros ofrecen un modo degestionar y localizar los objetos de negocio; ya no necesitan búsquedas JNDI,localizadores de servicio o singletons, ya que ofrece un registro de los objetos deaplicación. Este enfoque es menos invasivo y más poderoso que los EJBs, siempre ycuando todo resida en la misma JVM.



En la actualidad, los contenedores ligeros más conocidos son:

• Framework Spring (www.springsource.org)• JBoss Seam Framework (seamframework.org)• PicoContainer (www.picocontainer.org)

Para ofrecer una solución completa, el contenedor ligero debe ofrecer serviciosempresariales como la gestión de transacciones. Esto normalmente se realiza medianteinvocaciones a intercepciones AOP: añadir comportamiento adicional (como la gestión detransacciones) de un modo transparente, antes y tras la ejecución de los métodos denegocio.

Los contenedores ligeros son una arquitectura reciente, hecha posible al desarrollo deframeworks open source con soporte para la IoC.

3.3.2.1. Ventajas

El uso del contenedor ligero ofrece las siguientes ventajas:

• Arquitectura simple pero potente• Permite la escalabilidad horizontal mediante el clustering del contenedor web. Las

limitaciones a la escalabilidad vendrán dadas por la gestión del estado de la sesión.• Más sencilla que una arquitectura EJB, pero más compleja que una arquitectura Web.• Servicios declarativos sofisticados mediante AOP.• No requiere un contenedor EJB• Alta portabilidad entre servidores de aplicaciones.• IoC permite al contenedor ligero conectar objetos, lo que elimina la complejidad de

búsqueda y conexión de recursos del código de la aplicación. La dependencia ycolaboración de los objetos se expresa mediante simples propiedades JavaBean oargumentos de constructor, siendo el contenedor el que las resuelve en tiempo deejecución. IoC permite que la granularidad de los BOs sea fina.

• Los BOs son más fáciles de probar fuera de un servidor de aplicaciones, y algunaspruebas de integración se pueden realizar desde pruebas JUnit (sin necesidad deCactus). Esto facilita seguir un enfoque TDD en el desarrollo.


A continuación se enumeran algunas de las desventajas de esta arquitectura:

• Igual que la arquitectura anterior, para permitir el acceso remoto de cliente esnecesaria una fachada remota (RMI, Web Services, ...) Los Web Services son unagran alternativa para esta fachada, pero solo en el caso de utilizar RMI/IIOP seránecesario el uso de EJBs.

• No existe un estándar para contenedores ligeros. Pese a que Spring esta muydifundido, es un estándar de facto, pero no forma parte de ninguna especificación deSun. Aun así, como los objetos de la aplicación no dependen de ningún API, en elcaso de querer migrar de framework, los cambios se realizan sobre ficheros de



http://www.springsource.org

http://seamframework.org

http://www.picocontainer.org

configuración y clases muy especificas.• Se trata de una arquitectura todavía desconocida para la mayoría del mercado, donde

no existen muchos desarrolladores con dominio sobre las tecnologías empleadas. Porsuerte, poco a poco, Spring suena más y mejor.


Dentro de una aplicación, todas las clases se ejecutan dentro de la misma JVM. Desde elpunto de vista del usuario, la capa web la ofrece un framework MVC, ya sea medianteStruts, o en el caso de Spring, mediante una capa web que puede ser gestionada por elcontenedor y ofrecer un integración cercana con los objetos de negocio.

Los objetos de negocio serán POJOs, ejecutándose dentro del contenedor ligero. Estospueden ser avisados vía intercepcion AOP para que ofrezcan servicios empresariales. Elacceso a los BOs ser realizará exclusivamente a través de sus interfaces, lo cual permite elintercambio de implementaciones de negocio, sin necesidad de modificar el códigollamador. En cuanto al acceso a datos, ya sea mediante un framework ORM tipoHibernate, o JDBC si la abstracción de ORM no aporta casi valor.

A parte de la ya comentada posibilidad de gestionar servicios empresariales de formadeclarativa mediante AOP, el uso de un contenedor ligero como Spring permite que sicontrolamos las transacciones mediante conexiones JDBC, sin utilizar JTA, si en unfuturo necesitamos sacar ventaja de JTA, entonces sólo habremos de cambiar laconfiguración de Spring.



Arquitectura Contenedor Ligero

3.3.3. Arquitectura JavaEE Local

Para solucionar algunos de los problemas en la arquitectura vista previamente, lasiguiente solución modifica la arquitectura para incorporar los EJBs que ofrecen una vistalocal de sus interfaces a los clientes.

Por un lado, la especificación de servlets 2.3 garantiza que los objetos de la capa webpuedan acceder a los EJBs vía sus interfaces locales si la aplicación se despliega en unservidor de aplicaciones JavaEE integrado en un única JVM. Esto nos permitebeneficiarnos de los servicios ofrecidos por el contenedor EJB, pero sin incurrir en laexcesiva complejidad ni la necesidad de hacer nuestra aplicación distribuida.

Por el otro, la especificación de EJB 2.0, introdujo los interfaces locales como respuesta ala presión de la industria respecto al rendimiento de las arquitecturas EJB. Como yasabemos, el uso de interfaces locales permite el uso de la convención de paso porreferencia, evitando la sobrecarga incurrida en las llamadas remotas.

3.3.3.1. Ventajas

El uso de arquitecturas con EJBs locales ofrece las siguientes ventajas:

• Es menos compleja que una aplicación EJB distribuida• El uso de los EJBs no altera el diseño básico de la aplicación. En este tipo de

arquitectura, podemos hacer EJBs sólo aquellos objetos que necesitan servicios delcontenedor EJB.

• Este tipo de uso de los EJBs implica una penalización de rendimiento muy pequeña(casi despreciable), ya que no realiza llamadas remotas ni serialización de los objetos.

• Ofrece los beneficios del contenedor EJB tales como la gestión de las transacciones,seguridad declarativa y gestión de la concurrencia.

• En el caso de quererlo, podemos utilizar beans de entidad


Hemos visto que esta arquitectura representa un buen uso (y valido) de la tecnología EJB,donde los requisitos del sistema pueden utilizar la seguridad declarativa y la gestión de lastransacciones. Algunas de las debilidades son:

• Es más compleja que una aplicación web pura.• Todavía no soporta otro tipo de clientes que no sean el interfaz web, a no ser que

añadamos una capa de servicios web.• Toda la aplicación corre sobre la misma JVM, lo que significa que todos los

componentes debe ejecutarse en el mismo servidor físico y no se pueden separar paradesplegarlos en servidores diferentes.

• Este tipo de EJBs son difícil de probar. Necesitamos hacerlo desde casos de prueba



que lo hagan dentro del servidor JavaEE (con Cactus).• Todavía existe la tentación de modificar el diseño de lo objetos como resultado del

uso de los EJBs. Incluso con interfaces locales, existe un pequeño ralentizacimientoen las llamadas a los métodos, lo que nos puede llevar a modificar la granularidadnatural de los objetos de negocio.

A veces podemos decidir introducir EJBs en una arquitectura, que en un principio no losnecesita. Si seguimos el enfoque XP de "haz la cosa más simple que pueda funcionar",puede que los requisitos funcionales no justifiquen la complejidad introducida por losEJBs, pero la incorporación de futuros requisitos puede aconsejar su uso.

Si adoptamos los interfaces como componentes de negocio, tal como en la arquitecturaanterior, el hecho de introducir EJBs con interfaces locales no conlleva ningún problema.Simplemente, podemos elegir que interfaces queremos hacerlos accesibles desde proxys.

Si introducimos EJBs remotos, la cosa cambia. Ya no es una cuestión de meter o no meterEJBs, sino que modifica completamente la naturaleza de la aplicación. Por ejemplo, lagranularidad de los interfaces de negocio puede necesitar ser más gruesa para evitar elmúltiple uso de llamadas remotas y conseguir un rendimiento adecuado. También puedeque queramos mover toda la lógica de negocio dentro del contenedor EJB...


En la siguiente arquitectura, la capa web es idéntica a la vista anteriormente. Losinterfaces de negocio son idénticos. La diferencia está en su implementación, lo que atañea la capa EJB. Por lo tanto, la capa de middleware se divide en dos (los interfaces denegocio corriendo en el contenedor web y los EJBs), pero ambas partes ejecutándosedentro de la misma JVM.

Así pues, hemos cambiado los objetos de negocio por beans de sesión, los cuales losdesplegamos sobre el contenedor EJB del servidor JavaEE.

Tenemos 2 posibilidades para implementar los interfaces de negocio:

• mediante un Proxy, en el cual un EJB local implementa el interfaz de negociodirectamente, y se le ofrece una referencia al interfaz del EJB local en el código delcontenedor web, sin la necesidad de realizar la búsqueda JNDI.

• mediante un Business Delegate, en el cual el la implementación del interfaz denegocio del contenedor web delega de forma explicita en el EJB apropiado. Esto tienela ventaja de soportar el cacheo y permitir a las operaciones fallidas recuperarse en ellugar apropiado.

En ninguno de los dos casos hemos de preocuparnos por capturar la excepciónjava.rmi.RemoteException, ya que no existen errores de transporte.



Arquitectura EJB Local

En esta arquitectura, a diferencia de una arquitectura que expone los interfaces remotosvía EJB, el uso de los EJBs simplemente es una elección de implementación, pero no unacaracterística fundamental de la arquitectura. Cualquiera de los interfaces de negociopuede implementarse sin usar EJBs, lo que no conllevaría ningún cambio en el diseñoglobal de la aplicación.

Por lo tanto, estamos ante una arquitectura comprometida con el rendimiento, la cual esposible gracias a las mejoras introducidas en la especificación EJB 2.0

3.3.4. Arquitectura JavaEE Distribuida

Se trata de la arquitectura clásica JavaEE. Ofrece la capacidad de partir la capa demiddleware de forma física y lógica, usando diferentes JVMs para los EJbs, de modo quelos componentes web puedan utilizarlos. Se trata de una arquitectura compleja, con unasobrecarga de rendimiento significativa.



3.3.4.1. Ventajas

El uso de arquitecturas distribuidas ofrece las siguientes ventajas:

• Soporta todos los tipos de cliente JavaEE mediante una capa de middlewarecompartida.

• Permite la distribución de componentes de aplicación a través de los diferentesservidores físicos. Esto funciona particularmente bien si la capa de EJB es "sinestado". Las aplicaciones JavaEE con capa de presentación con estado (mediante eluso del objeto Session), pero con la capa de middleware sin estado (medianteStateless Session Beans) se benefician de este tipo de despliegue y obtienen lamáxima escalabilidad posible.


Las limitaciones de esta arquitectura son:

• Se trata del enfoque más complejo de los que hemos considerado. Si los requisitos dela aplicación no obligan a esta complejidad, estaremos malgastando recursos a lolargo del ciclo de vida del proyecto, y sembrando un campo fértil para la aparición deerrores.

• Afecta al rendimiento. Las llamadas a métodos remotos pueden ser cientos de vecesmás lentas que las llamadas locales por referencia. El efecto de esta sobrecarga derendimiento depende del número de llamadas remotas necesarias.

• Las aplicaciones distribuidas son difíciles de probar y depurar.• Todos los componentes de negocio deben ejecutarse en el contenedor EJB. Mientras

esto ofrece un interfaz comprensible para los clientes remotos, es un aspectoproblemático si el EJB no puede utilizar para resolver todos los problemas impuestospor los requisitos de negocio. Por ejemplo, si el patrón de diseño Singleton es unabuena elección, será muy difícil de implementar satisfactoriamente mediante EJBs.

• El diseño OO se dificulta por el uso centralizado de RMI.• La gestión de las excepciones es más compleja en sistemas distribuidos. Se deben

controlar tanto los errores de transporte como los de aplicación.


Aunque el diagrama muestre una aplicación web, esta arquitectura soporta cualquier tipode cliente JavaEE. Por lo tanto, se trata de una arquitectura preparada para las necesidadesde las aplicaciones cliente.

Esta arquitectura utiliza RMI entre las capas de presentación (o con otros cliente remotos)y los objetos de negocio, los cuales están expuestos como EJBs (los detalles de lacomunicación RMI los abstrae el contenedor de EJBs, pero hemos de tratar con lasimplicaciones de su uso). Esto hace las invocaciones remotas un factor determinante derendimiento y una consideración central a la hora de realizar el diseño. Como vimos



anteriormente, hemos de minimizar el número de llamadas remotas (evitando las llamadas"chatty"). Además, todos los objetos enviados deben ser serializables, y debemos tratarcon requisitos de gestión de errores más complejos.

La capa web de esta arquitectura es la misma que hemos comentado antes. Sin embargo,la implementación del interfaz de negocio debe tratar el acceso remoto al EJB en el,posiblemente remoto, contenedor EJB.

De las 2 posibilidades de conectividad vistas anteriormente, solo el enfoque del BusinessDelegate es útil en este caso, ya que todos los métodos del interfaz remoto del EJB lanzanjava.rmi.RemoteException.

Al tratarse de una excepción chequeada, a no ser que utilicemos un Business Delegatepara contactar con los EJBs y envolver las excepciones RMI como excepciones deejecución o aplicación, la capa de presentación deberá capturar la excepción remota, locual la ata de forma inapropiada a la implementación del EJB.



Arquitectura EJB Remota

3.3.5. ¿Y tu qué eliges?

Tras ver las diferentes alternativas arquitecturales, podemos hacer una elección de si unanueva aplicación necesita un servidor de aplicación completo (con soporte de JTA, JCA,EJBs) o un contenedor web como Tomcat.

Existen diferentes beneficios para evitar el uso de un servidor de aplicaciones, tales como:

• Menor coste de licencia, en el caso de productos comerciales. Muchas empresas estánpagando la licencia de un producto que no necesitan.

• Arranque más rápido, lo que nos ahorra tiempo de desarrollo.• Administración más sencilla, y por lo tanto, curva de aprendizaje menor.

Las aplicaciones web que sólo utilizan una base de datos rara vez requieren un servidorde aplicaciones. Los contenedores ligeros (tipo Spring) ofrecen mejores alternativas queun contenedor EJB para gestionar los objetos de negocio en la mayoría de las aplicacionesweb. Las transacciones distribuidas, y por tanto JTA, no son necesarias cuandotrabajamos con una única base de datos.

Necesitamos un servidor de aplicaciones si:

• necesitamos transacciones distribuidas• queremos que nuestra aplicación sea remota, para lo cual los EJBs son una buena

solución. Sin embargo, los servicios web remotos ofrecen casi las mismasprestaciones (recuperación frente a caída del servidor, clustering, ...) sin necesidad deun servidor de aplicaciones para ofrecer escalabilidad y tolerancia.

Resumiendo, en las arquitectura que no son EJB, el factor crítico que se hecha en falta esla gestión de las transacciones. Por ello, debemos asegurarnos que nuestros requisitos secumplen con transacciones locales o distribuidas.

3.4. Para Saber Más

3.4.1. Bibliografía

• Expert one-on-one J2EE Design and Development , de Rod Johnson. Libro quesirvió como base del desarrollo de Spring y que destaca todos los puntos fuertes ydébiles de los EJBs, destacando cuando hacer qué y cómo hacerlo.

• Expert one-on-one J2EE Development without EJB, de Rod Johnson. Secuela delibro anterior donde se defiende la Arquitectura de Contenedor Ligero.

3.4.2. Enlaces

• Apartado del tutorial de Sun sobre JavaEE que habla de las Aplicaciones distribuidas



en múltiples niveles: java.sun.com/javaee/5/docs/tutorial/doc/bnaay.html



http://java.sun.com/javaee/5/docs/tutorial/doc/bnaay.html

Arquitectura de Aplicaciones · Arquitectura de Aplicaciones Sí, una profesión muy respetable....

Documents

Transcript of Arquitectura de Aplicaciones · Arquitectura de Aplicaciones Sí, una profesión muy respetable....