Aplicaciones distribuidas

Arquitectura de aplicaciones distribuidas

Este artculo presenta una breve introduccin al diseo de las aplicaciones distribuidas.

Contenido

1. Introduccin a las aplicaciones distribuidas 1.1. Caractersticas de las aplicaciones distribuidas 1.2. Tipos de aplicaciones distribuidas 2. Arquitectura de las aplicaciones distribuidas 2.1. La capa de servidor 2.2. La capa de negocios 2.3. La capa de presentacin 2.4. Distribucin fsica de las capas lgicas

menosms Enlace CitaCorreo electrnicoImprimir FavoritoRecopilar esta pgina

1. Introduccin a las aplicaciones distribuidas

Mucho tiempo ha transcurrido ya desde que en la dcada de los ochenta la tecnologa de la informacin comenzara tmidamente a ocupar el lugar que hoy en da posee. En aquellos das, que tal vez algunos veteranos recuerden con cierta nostalgia, la mayora de los sistemas informticos estaban constituidos por enormes sistemas centrales que ejecutaban todos las aplicaciones dentro de s mismos, y en el mejor de los casos los usuarios interactuaban con esas aplicaciones mediante terminales tontos, que no eran sino simples pantallas con teclado que permitan enviar caracteres al sistema central y mostrar las respuestas, tambin basadas en caracteres, que los monstruos generaban y enviaban a travs de un cable.

El advenimiento de los ordenadores personales constituy la primera revolucin. Ahora los usuarios disponan de un procesador y de un sistema de almacenamiento autnomo, capaz de procesar datos e incluso de mostrar grficos por pantalla adems de caracteres. Surgieron multitud de aplicaciones de escritorio que independizaron a los usuarios de los grandes sistemas y el coste del hardware se redujo a niveles tan aceptables que empresas que no hubieran podido afrontar la inversin en un sistema informtico centralizado comenzaron a introducir en sus procesos de negocio la gestin informtica de los datos. Pero en el fondo los modos de ejecucin de aplicaciones no haban cambiado. De la ejecucin en un sistema centralizado se pas a la ejecucin en sistemas ms pequeos e independientes, pero al fin y al cabo las aplicaciones seguan siendo islas incomunicadas entre si, y los usuarios no podan contar ms que con las capacidades del propio ordenador para procesar los datos. Por un lado, la necesidad de compartir datos no quedaba resuelta con sistemas independientes, y la opcin de las aplicaciones centralizadas segua siendo la nica viable en entornos multiusuario. Por el otro, cuando los datos eran generados por un ordenador central no haba forma de tratarlos localmente y toda la potencia de los ordenadores personales no serva para nada. El avance en las tecnologas de redes comenz a dibujar un horizonte en el que las aplicaciones se comunicaran entre s y en el que los procesos de una aplicacin se distribuiran entre diferentes equipos, cada uno con caractersticas que les permiteran aumentar la eficacia y la disponibilidad de la aplicacin. Se comenz a separar la lgica de las aplicaciones para situarla en el nivel ms conveniente y conceptos como cliente y servidor fueron cobrando cada vez ms sentido. Tras algunos aos de indecisin, los protocolos de red se estandarizaron y hacia mediados de los aos 90 Internet se convirti en la primera revolucin autntica del siglo XXI, provocando no slo un vuelco en las relaciones sociales y econmicas sino tambin, por supuesto, un cambio completo de paradigma en la arquitectura de las aplicaciones informticas. Las aplicaciones se convierten, as, en aplicaciones distribuidas. Sin arriesgarnos a proporcionar una definicin acadmica que puede encontrarse muy fcilmente en Internet, diremos informalmente que una aplicacin distribuida es aquella cuyo objetivo final se alcanza mediante la ejecucin de diversos procesos independientes que por lo general se ejecutan en equipos diferentes y que de una forma u otra se pasan datos entre ellos mediante protocolos de comunicaciones bien establecidos. En esta primera seccin examinaremos las formas arquitectnicas (o de diseo) que adquieren las aplicaciones distribuidas. Cada una de ellas plantea ciertas ventajas e inconvenientes que ser necesario tener en cuenta a la hora de crear el cdigo para los diferentes componentes de la aplicacin.

1.1. Caractersticas de las aplicaciones distribuidas

Independientemente de su arquitectura, todas las aplicaciones distribuidas comparten ciertas caractersticas que las diferencian notablemente de las aplicaciones centralizadas y de las aplicaciones de escritorio. Conocer esas caractersticas y evaluar su impacto en las aplicaciones es primordial para escoger el diseo ms adecuado de las mismas. No es cierto que una aplicacin se pueda disear de cualquier manera. A continuacin ofreceremos una breve enumeracin de los aspectos primordiales que han de evaluarse a la hora de disear una aplicacin distribuida:

1. Concurrencia: De igual forma que en las aplicaciones centralizadas, las aplicaciones distribuidas sern utilizadas por cierto nmero de usuarios concurrentemente. Aspectos como las transacciones, los bloqueos de recursos o el uso de la CPU de los equipos a los que acceden muchos usuarios son determinantes a la hora de disear una arquitectura con la mxima eficacia. 2. Topologa de la red: A pesar de que a da de hoy los anchos de banda cada vez son ms amplios, el trfico de red puede ser un aspecto importante que condicione el tiempo de respuesta de la aplicacin. En muchos casos tambin ser necesario tener en cuenta el tipo de red (LAN o WAN), o si la aplicacin ser o no accesible a travs de Internet. La forma de distribuir los procesos de la aplicacin tendr que tomar en consideracin el tipo de red que soportar el trfico de datos. 3. Ubicacin de la lgica: Dado que en una aplicacin distribuida intervienen varios procesos, ser necesario decidir en cul de los posibles procesos fsicos se sita cada componente lgico de la aplicacin. Mientras que algunos procesos, como la presentacin de datos o la recuperacin de los mismos, tienen un sitio natural, otros, como la validacin o la navegacin, pueden ocupar diversos lugares dentro del diagrama que conforma la estructura de la aplicacin. En muchas ocasiones la ubicacin de los componentes lgicos impacta sobre el rendimiento, sobre la reutilizacin del cdigo o sobre la facilidad de programacin. 4. Homogeneidad de las plataformas: En una aplicacin distribuida los sistemas operativos involucrados o los lenguajes de desarrollo utilizados pueden ser un factor a tener en cuenta a la hora de decidir algunos aspectos importantes, como por ejemplo el modo de pasar datos entre procesos. La utilizacin de estndares puede ser muy til a la hora de crear aplicaciones distribuidas que permanezcan abiertas a diversos sistemas heterogneos, pero si las plataformas son similares es posible alcanzar mejor rendimiento sacrificando interoperabilidad. 5. Seguridad: Una aplicacin distribuida mantiene procesos que de una forma u otra estn a la escucha en una red, lo que aumenta la vulnerabilidad de la aplicacin. Ser necesario establecer polticas de seguridad que impidan el acceso no autorizado a los procesos. Pedir al usuario un nombre y una contrasea al iniciar el programa es probable que no sea suficiente.

No existe una solucin nica para todos los problemas. A pesar de que en la actualidad se priman ciertas arquitecturas sobre otras, la realidad es que la decisin final depender de todos los factores anteriormente citados, y de otros que a veces no se tienen mucho en cuenta pero que tambin poseen su importancia, como el coste total de la aplicacin o la complejidad de la solucin respecto al problema planteado. Ni es recomendable subestimar las necesidades de una aplicacin compleja, ni tampoco conviene sobredimensionar la estructura de una aplicacin sencilla que puede resolverse con medios ms asequibles.
Con las aplicaciones distribuidas el mero anlisis funcional de las caractersticas de una aplicacin ya no es suficiente y es necesario tambin considerar la distribucin y estructura de los procesos involucrados. La tarea del arquitecto de aplicaciones consistir precisamente en tomar la decisin de diseo ms adecuada para resolver el problema, ajustndose lo mejor posible a los requerimientos y tomando en cuenta todos los factores implicados.

1.2.

Tipos de aplicaciones distribuidas

Trataremos tan slo dos tipos de aplicaciones distribuidas: las que llamaremos clienteservidor, y las aplicaciones en n-capas. Algunos manuales dividen este ltimo grupo entre aplicaciones en 3 capas y aplicaciones en n-capas, pero nosotros consideraremos a ambos tipos como integrantes de un mismo conjunto de aplicaciones para simplificar las explicaciones. A continuacin desglosaremos la arquitectura de ambos tipos de aplicaciones distribuidas y comentaremos en detalle las caractersticas de ambos diseos.
1.2.1. Aplicaciones Cliente-Servidor

En las aplicaciones cliente-servidor que llamaremos tradicionales slo encontramos dos procesos principales. Uno de ellos se encarga fundamentalmente de proporcionar los datos que se le solicitan y de procesar los datos que se le envan. Llamamos servidor tanto al proceso que realiza estas funciones como al equipo en el que dicho proceso est alojado. El otro proceso, al que llamamos cliente, se ejecuta en el equipo del usuario que maneja la aplicacin, y sus funciones principales son solicitar datos al servidor, presentarlos al usuario para que este realice cierto trabajo con ellos y enviar los cambios al servidor para su reproceso si es necesario. La figura 1.1 ilustra este esquema.

Figura 1.1: Esquema de una aplicacin cliente-servidor tradicional En las aplicaciones cliente-servidor el proceso servidor es por lo general un sistema gestor de bases de datos (SGBD, o DBMS por sus iniciales en ingls, Database Management System). Los SGBD, como Microsoft SQL Server u Oracle, mantienen en el equipo servidor un servicio de red que recoge las peticiones que le llegan en forma de sentencias SQL y las transmite al verdadero proceso gestor de la base de datos, que se encarga de seleccionar los registros indicados por la peticin o bien de realizar las operaciones de actualizacin de los registros. Si la solicitud genera registros, el resultado de la consulta se transforma en datos tabulados que se envan de vuelta por la red al equipo que los ha solicitado. Los SGBD adems cumplen otras muchas funciones, como la de mantener la integridad de los datos, proporcionar seguridad, aislar al resto de la aplicacin de la localizacin de los datos, etc. Este es el punto en que entra la distribucin de procesos de una arquitectura distribuida. Los SGBD permiten incluir buena parte de la lgica de negocio de la aplicacin en forma de procedimientos almacenados, disparadores, reglas intrnsecas de la base de datos, etc. Por ejemplo, es posible realizar transacciones que cubran la actualizacin de los registros de varias tablas manteniendo la atomicidad de la operacin (es decir, que todas las actualizaciones se realicen o no se realice ninguna), mediante el uso de procedimientos almacenados. Tambin es muy habitual disponer en disparadores, que se ejecutan asociados a sentencias de actualizacin, ciertas operaciones de clculo automtico o de actualizacin en cascada. Estas operaciones, adems, suelen ser de alto rendimiento ya que los SGBD ejecutan estas operaciones de forma muy optimizada y a bajo nivel. En suma, el SGBD no es solamente un pasivo almacn de datos, sino que constituye una pieza importante en los procesos de la aplicacin distribuida. En el otro extremo de la red encontramos a las estaciones de trabajo que alojan las aplicaciones cliente. Para que las estaciones de trabajo puedan realizar peticiones al servidor es necesario que cuenten con el cliente de red adecuado al SGBD y que est

correctamente configurado. Los clientes de red son proporcionados por el fabricante del SGBD y son especficos para cada SGBD. El cliente de red sabe cmo conectarse al servicio de red del SGBD y transforma las peticiones del cliente en peticiones comprensibles por el SGDB. Esto implica que si el SGBD cambia por cualquier motivo ser necesario distribuir el nuevo cliente de red entre todas las estaciones de trabajo que accedan a l. El trabajo del cliente consiste principalmente en ofrecer al usuario un interfaz que le permita solicitar datos, visualizarlos en pantalla, trabajar con ellos y enviar las posibles actualizaciones al servidor. El programa cliente transforma la peticin del usuario en sentencias SQL que se envan al servidor. Si este devuelve datos, el cliente recoge los datos tabulados y los muestra en un formato accesible al usuario (en una rejilla de datos, en un grfico, etc.). El interfaz de usuario del programa permite al usuario manipular dichos datos, y el programa convierte esa manipulacin otra vez en sentencias SQL que se envan al servidor y que provocarn la actualizacin de los registros. A pesar de que, tcnicamente, cualquier aplicacin distribuida puede considerarse una aplicacin cliente-servidor, hemos reservado este trmino para designar la arquitectura interna de ciertas aplicaciones en las cuales los componentes lgicos de los procesos se distribuyen de la forma fsica ms sencilla posible. La aplicacin cliente incluye dentro de s misma todos los componentes de validacin, presentacin y manipulacin de los datos, y tambin incluye la conectividad con el cliente de red que permite la comunicacin con el SGBD. El servidor, por su lado, puede actuar como mero almacn de datos o incorporar reglas de negocio en forma de procedimientos almacenados o disparadores. Las aplicaciones cliente-servidor tradicionales son la forma ms bsica de aplicacin distribuida. Dada la simplicidad de su arquitectura, el coste de implementacin suele ser ms bajo que el de una aplicacin distribuida en n-capas. Tambin presenta cierta ventaja en lo que a rendimiento se refiere, ya que al existir menos capas de software entre el cliente y el servidor los datos pasan de un lado al otro ms rpidamente. Pero aqu acaban sus ventajas. El primer escollo que afrontamos en una aplicacin de este estilo es que la conectividad con el servidor se realiza desde cada una de las estaciones de trabajo. Esto genera dos problemas: en primer lugar, cada una de las estaciones de trabajo concurrentes est consumiendo recursos del servidor en forma de conexiones abiertas. En segundo lugar, la conectividad entre las estaciones de trabajo y el servidor es especfica para cada SGBD, lo que implica un mayor esfuerzo a la hora de configurar los sistemas y dificulta mucho la posibilidad de que una aplicacin sea capaz de trabajar con diferentes SGBD, ya que un cambio probablemente requerir una recodificacin de la aplicacin cliente o de alguna de sus partes, con el consiguiente problema de redistribucin. Adems, la reutilizacin del cdigo es mnima. Al incluir dentro de s misma las reglas de presentacin, actualizacin o validacin de datos, una segunda aplicacin que requiera acceder a las mismas tablas o utilizar las mismas validaciones no podr

beneficiarse del cdigo ya escrito, a no ser que est escrito en la misma plataforma y sea posible duplicarlo, mtodo que complica el mantenimiento de las aplicaciones. Un factor adicional en contra de este modelo es que requiere distribuir mucho software entre los equipos cliente. En el caso de una aplicacin de poco volumen esto quizs no sea relevante, pero cuando las aplicaciones alcanzan cierto volumen distribuir y mantener gran cantidad de software entre los equipos clientes puede ser no slo costoso sino inviable. Una aplicacin tipo ERP, por ejemplo, es un caso en el que necesariamente se ha de abandonar la arquitectura cliente-servidor tradicional. Por ltimo, este modelo arquitectnico es prcticamente inviable cuando nuestra aplicacin cliente ha de acceder al servidor mediante Internet. Los protocolos de red que utilizan los servicios y clientes de red de un SGBD suelen utilizar puertos que habitualmente estn cerrados a los cortafuegos y, a pesar de que es posible cambiar esos puertos, abrir al acceso pblico el servicio de red de un SGBD supone crear una vulnerabilidad importante.
En suma, las aplicaciones cliente-servidor tradicionales deben escogerse slo en casos muy especficos en los que el rendimiento o la simplicidad son factores determinantes. Cuando necesitamos compartir funcionalidad, mejorar la distribucin o sencillamente facilitar el mantenimiento, es necesario optar por un modelo mucho ms abierto y ms distribuido. Y, por supuesto, Internet nos aboca completamente a una arquitectura distribuida en n-capas. 1.2.2. Aplicaciones en n-capas

En una aplicacin distribuida en n-capas los diferentes procesos estn distribuidos en diferentes capas no slo lgicas, sino tambin fsicas. Los procesos se ejecutan en diferentes equipos, que pueden incluso residir en plataformas o sistemas operativos completamente distintos. Cada equipo posee una configuracin distinta y est optimizado para realizar el papel que le ha sido asignado dentro de la estructura de la aplicacin, de modo que tanto los recursos como la eficiencia global del sistema se optimicen. La figura 1.2 muestra un posible diseo de arquitectura distribuida en ncapas.

Figura 1.2: Esquema de una aplicacin distribuida en n-capas Un ejemplo posible sera una aplicacin de comercio electrnico en Internet. En primer lugar hallaramos el servidor que contiene los datos, cuyo SGBD puede incluir ciertos procedimientos almacenados o disparadores que sean globales a la lgica de la base de datos. En segundo lugar se hallara un equipo que fuera capaz de contener ciertos componentes que realicen determinadas reglas de negocio de la aplicacin, como la recuperacin de datos o la comprobacin de seguridad. Un tercer equipo podra comunicarse con este y ofrecer servicios de generacin dinmica de pginas web, como sera el caso de un servidor IIS que alojase una aplicacin web mediante ASP.NET. En el ltimo escaln estara el navegador, que podra ejecutar ciertas validaciones de usuario mediante cdigo javascript en las propias pginas. Las aplicaciones distribuidas ofrecen la solucin ms optimizada para grandes sistemas que requieren alta concurrencia o mxima reutilizacin de cdigo. Los procesos se ejecutan en mquinas dedicadas que se configuran de la manera ms adecuada para ofrecer los servicios que requiere cada parte de la aplicacin. Ciertamente, crear una aplicacin distribuida en varias capas requiere cierto sobresfuerzo en trminos de diseo y conlleva una cierta prdida de rendimiento frente a las aplicaciones clienteservidor tradicionales, pero su implantacin soluciona tantos problemas que su uso es imprescindible en sistemas muy complejos.

2. Arquitectura de las aplicaciones distribuidas

En una aplicacin distribuida en n-capas los diferentes elementos que integran la aplicacin se agrupan de forma lgica segn la funcionalidad que reciben o suministran al o desde el resto de los elementos. As, algunos elementos se limitarn a recibir peticiones de datos mientras que otros interactuarn con el usuario y su funcin ser principalmente la de solicitar a otros elementos la informacin que el usuario precisa. Atendiendo al papel que los distintos elementos juegan dentro de la aplicacin, distinguimos con claridad tres grupos lgicos en los que podemos agrupar elementos segn su funcionalidad: La capa de servidor incluye aquellos elementos que se encargan de recibir las peticiones de datos o de acceso a servicios bsicos del sistema y de suministrar a otros elementos la informacin solicitada. La capa de negocios encapsula las reglas de acceso a datos y la gestin de procesos internos de la aplicacin. La capa de presentacin se encarga de la lgica necesaria para interactuar con el usuario de la aplicacin. Una vez agrupada la funcionalidad en capas lgicas es fcil relacionar unas con otras. El usuario interactuar con la capa de presentacin, solicitando datos o desencadenando acciones. Las solicitudes sern atendidas por la capa de negocios, que se encargar de su gestin o de la traduccin necesaria para que la capa de servidor realice la tarea solicitada. Si la capa de servidor debe proporcionar datos estos se devolvern a la capa de negocios, la cual los gestionar o transmitir a la capa de presentacin. La figura 2.1 ilustra este esquema.

Figura 2.1: Esquema lgico de las capas en una aplicacin distribuida Es importante notar que el esquema que mostramos es un esquema lgico, no fsico. El modo de distribuir fsicamente las capas (en diferentes ejecutables o DLL, o en diferentes equipos) se corresponder con el esquema lgico en todo o en parte, pero no necesariamente existir una correspondencia exacta entre la distribucin lgica de los elementos y su distribucin fsica. La capa de negocios podra residir en diferentes mquinas, por ejemplo, o las entidades de negocio y la capa de servidor podran formar parte de la misma DLL. Ms adelante hablaremos de la relacin fsica entre las diversas capas lgicas y estudiaremos cmo los diferentes escenarios nos condicionarn la distribucin fsica de las capas lgicas.
Adicionalmente, en las aplicaciones distribuidas existen otras funcionalidades, como la seguridad o el registro de sucesos, que no son exclusivas de un grupo lgico ya que deben aparecer en todos los elementos de la aplicacin.

2.1.
2.1.1.

La capa de servidor
Servicios

En la capa de servidor encontraremos los procesos de la aplicacin que se encargan recibir las peticiones de las capas superiores y, si es necesario, devolver los datos solicitados. Esta funcin ser desempeada por un servicio. Los servicios son procesos que se ejecutan en los equipos servidores y que se mantienen a la escucha esperando que los procesos cliente les soliciten funcionalidad o datos. Por lo general los servicios residen en equipos dedicados cuya configuracin y caractersticas fsicas estn especialmente diseados para realizar esta funcin. Para poder realizar estas funciones los servicios han de poseer ciertas caractersticas que les diferencian claramente de una aplicacin de escritorio: 1. Ejecucin desatendida: Un servicio normalmente se mantiene ejecutndose en la memoria del equipo que lo aloja. A pesar de que algunas tecnologas, como DCOM o Remoting, permiten que el objeto que responder a la peticin no est cargado en memoria hasta que alguien realiza la peticin, en la infraestructura del servicio siempre ha de haber un elemento que se mantenga en ejecucin, listo para responder a las peticiones de los clientes. La ejecucin del servicio, por lo tanto, no precisa de la intervencin de ningn usuario. 2. Conectividad: Un servicio suele estar en un equipo dedicado, mientras que los equipos cliente acceden a l a travs de la red. Esto implica que debe existir algn mecanismo que permita que una peticin remota active la respuesta del servicio. La infraestructura de red del servicio debe estar configurada para enlazarse con algn protocolo de red, por lo general TCP/IP. 3. Concurrencia: Dado que mltiples equipos accedern al servicio simultneamente, es necesario que los servicios implementen algn mecanismo para gestionar la concurrencia de acceso. Existen dos formas bsicas de gestionar la concurrencia: a. Acceso simultneo: En el acceso simultneo los servicios crean hilos de proceso paralelos que gestionan las peticiones simultneamente. Cada hilo de proceso posee sus propias estructuras de datos independientes entre s, de modo que los datos generados por una peticin sean inaccesibles a otra peticin. En este caso nos podemos encontrar con un problema si las peticiones simultneas son muy abundantes, ya que eso crear una multitud de hilos de ejecucin simultneos que tal vez sature la capacidad de ejecucin del servidor. Sin embargo, si la capacidad de ejecucin del servidor es suficiente, los tiempos de respuesta son mejores. b. Acceso serializado: En este caso las peticiones se atienden una a una, en un nico hilo de ejecucin. El servicio dispondr de algn sistema para almacenar en colas las peticiones que vayan llegando, y las ejecutar una tras otra. En este caso es

difcil que se produzca una saturacin de los recursos del servidor, pero los tiempos de respuesta son peores si las peticiones simultneas son muy abundantes. 4. Seguridad: El servicio deber asegurarse de que la llamada est autorizada y ser necesario implementar algn mecanismo que recoja las credenciales del usuario y autorice la ejecucin.

2.1.2.

Servicios de base de datos

Los servicios de base de datos son los ms frecuentes en las aplicaciones distribuidas. Los SGBD como SQL Server u Oracle disponen de toda la infraestructura de servicios necesaria para que los equipos cliente les realicen peticiones y para responder a ellas. Se ejecutan como un servicio de forma totalmente desatendida, se enlazan al protocolo de red para escuchar peticiones de otros equipos, gestionan la concurrencia de las llamadas e incorporan mecanismos de seguridad propios o integrables con el directorio activo. Una de las caractersticas ms importantes de los SGBD es que nos permiten crear reglas de negocio. Estas reglas pueden invocarse remotamente desde los clientes y se escriben en lenguajes propios del SGBD (Transact-SQL en el caso de SQL Server, por ejemplo). Los SGBD compilan y ejecutan de la forma ms ptima posible estas reglas, de modo que su ejecucin siempre es de alto rendimiento. Podramos dividir estas reglas en tres tipos segn su modo de ejecucin: 1. Procedimientos almacenados: Los procedimientos almacenados se ejecutan como consecuencia de una llamada directa de un cliente. El lenguaje SQL posee instrucciones que permiten invocar la ejecucin de procedimientos almacenados en el servidor. 2. Disparadores: Los disparadores son procedimientos que se ejecutan como consecuencia indirecta de una sentencia SQL efectuada por el cliente. Por lo general estn asociados a sentencias de tipo INSERT, UPDATE o DELETE y disponen de medios para acceder a los registros a los cuales afecta la sentencia. 3. Procedimientos programados: Es frecuente que los SGBD dispongan de algn sistema para programar el lanzamiento de procesos segn un plan programado por calendario, de forma nica o peridica. En este caso la intervencin del cliente no es necesaria y el propio SGBD activa el proceso cuando llega el momento, de forma totalmente desatendida. Sea cual sea su modo de ejecucin, las reglas de negocio situadas en el servidor SGBD son muy recomendables en cualquier aplicacin distribuida. No solamente su ejecucin es muy rpida, sino que adems est centralizada y cualquier cliente que acceda al servicio podr beneficiarse de ellas. El coste de mantenimiento es mnimo y su modificacin interna (es decir, si slo modificamos la lgica del proceso y no sus parmetros de entrada o salida) no requerir modificaciones en las aplicaciones cliente. Adems su ejecucin es transaccional y permite el bloqueo exclusivo, lo cual facilita la atomicidad y la gestin de la concurrencia en accesos simultneos.

Un claro ejemplo de proceso que sera conveniente incluir entre las reglas de negocio de una aplicacin sera la modificacin del inventario de un almacn. El cliente realizara una peticin para la creacin de una factura a un procedimiento almacenado, el cual descontara del inventario los artculos que componen la factura. El proceso sera transaccional, de modo que si no fuera posible realizar la actualizacin del inventario la factura no se creara y el usuario recibira un error. Otro caso sera la auditora de acceso a las tablas. Es posible crear disparadores asociados a los procesos de modificacin de modo que cada vez que un usuario modifica un registro la operacin quede registrada en una tabla de auditora. Los inconvenientes que plantea la colocacin de reglas de negocio en el servidor tienen relacin con el tipo de aplicacin que se desea construir. Por ejemplo, en una aplicacin comercial es posible que no deseemos que se puedan modificar esas reglas, de modo que situar la lgica en procedimientos almacenados (accesibles, por ejemplo, al administrador del sistema), sea exponer una vulnerabilidad a la coherencia de la aplicacin. Tambin puede suceder que no deseemos exponer las reglas de negocio de la aplicacin a la curiosidad de terceros, de modo que situarlas en procedimientos del servidor no es recomendable. Desde luego, es posible restringir el acceso al cdigo fuente de estas reglas de negocio, pero eso implica una complicacin adicional en la seguridad y en el mantenimiento que tal vez en una aplicacin comercial sea contraproducente. Otro inconveniente, aunque este cada vez es menos relevante, hace referencia a la dificultad de programar estas reglas de negocio en los lenguajes propios de los SGBD. Por lo general los lenguajes propios de los SGBD no son tan potentes ni tan flexibles como los lenguajes de programacin externos. Sin embargo, SGBDs como SQL Server ya permiten escribir procedimientos almacenados en lenguajes convencionales, de modo que este inconveniente cada vez tiene menos peso. En general es recomendable el uso de reglas de negocio en el SGBD cuando la aplicacin sea corporativa o cuando su administracin pueda centralizarse. La eficiencia en la ejecucin, la facilidad en el mantenimiento y la encapsulacin respecto al resto de la aplicacin convierten a los SGBD en una muy buena opcin a la hora de situar reglas de negocio de la aplicacin.
2.1.3. Otros servicios

Aunque los servicios de datos son los ms frecuentemente utilizados en las aplicaciones distribuidas, en ocasiones requerimos otro tipo de servicios que un SGBD no puede suministrar. Por ejemplo, podra ser necesario extraer informacin de sistema de un equipo o acceder remotamente a un perifrico local. Los sistemas actuales son cada vez ms seguros, de modo que el acceso directo a travs de la red a los servicios locales no slo no es recomendable, sino que en segn qu casos puede incluso a llegar a ser tan complicado que represente un problema. En este caso el planteamiento requiere la creacin de un servicio que permita el acceso remoto a los recursos locales. Estos servicios deben cumplir con las mismas reglas que los servicios que acceden a datos, pero esta vez es probable que no dispongamos de la infraestructura que los SGBD ya incorporan, as que ser necesario implementar esas

caractersticas en nuestro cdigo. La figura 2.2 nos muestra cmo, a diferencia de los SGBD, en que los mdulos de infraestructura estn ya suministrados, en los servicios de sistema deberemos crear nuestra propia infraestructura de servicio. Por lo que se refiere a las reglas de negocio, en este tipo de servicios no suelen ser abundantes. Los servicios de sistemas por lo general ofrecen una fachada exterior a ciertas caractersticas del sistema, y su cdigo se limita a encapsular el acceso a las mismas. Si es necesario establecer alguna regla de negocio el lugar adecuado para situarla ser la capa de negocios, de la que trataremos en la siguiente seccin.

Figura 2.2: Esquema de la capa de servidor. Mientras que en el SGBD los servicios de infraestructura estn incluidos, en nuestros propios servicios deberemos implementar los mdulos de infraestructura.

2.2.

La capa de negocios

2.2.1.

Divisin de la capa de negocios

La capa de negocios representa el grueso de la lgica de funcionamiento de la aplicacin distribuida. En esta capa se sitan las normas de acceso a datos, la lgica de tratamiento de los mismos, y en general cualquier elemento de la aplicacin que pueda reutilizarse. El objetivo de la creacin de esta capa intermedia es aislar la capa de presentacin de la capa de servidor, de forma que las estructuras de datos subyacentes y la lgica que las utilizan sean independientes de la capa de presentacin. De esta forma, tambin, el mantenimiento de las normas de negocio ser ms sencillo y, sobre todo, ser reutilizable desde cualquier capa de presentacin, sea del tipo que sea. A pesar de que se suele utilizar el nombre de capa de negocios para referenciar a todos los elementos que componen esta capa intermedia de software, por lo general la capa de negocios suele dividirse en dos tipos de elementos, atendiendo a la funcin que desempean en la capa. La figura 2.3 ilustra los elementos tpicos que suelen aparecer en las capas de negocios.

Figura 2.3: Estructura tpica de una capa de negocios. Los elementos opcionales aparecen con lneas discontinuas. 2.2.2. Lgica de acceso a datos

La lgica de acceso a datos incluye los elementos necesarios para que la aplicacin se conecte a orgenes de datos y recupere estructuras de datos que sern utilizadas por el resto de la aplicacin. En una aplicacin distribuida, los nicos elementos que se conectan a la base de datos son los objetos de acceso a datos, y el resto de elementos de la aplicacin se limitan a enlazar con estos objetos para solicitar datos y enviar rdenes a los orgenes de datos. Los motivos para encapsular todo el acceso a datos en la lgica de acceso a datos son mltiples. En primer lugar, no ser necesario distribuir la informacin de conexin

por todo el sistema, ya que el nico punto desde el que se efectuar el acceso directo a los orgenes de datos ser el equipo en el que resida fsicamente la lgica de acceso a datos. Tampoco ser necesario distribuir el software cliente del SGBD por diferentes mquinas, lo que facilita el mantenimiento y la instalacin de la aplicacin. Adems, encapsular la lgica de acceso a datos permite que la aplicacin sea agnstica respecto al origen de datos, es decir, puede realizar sus tareas sin tener la necesidad de saber en qu SGBD concreto residen los datos, ni en qu punto de la red se halla el servidor, lo que facilita la configuracin del sistema. Este sistema posibilita la utilizacin de varios SGBD en una aplicacin o facilita la migracin de un SGBD a otro. Tambin permite que la aplicacin ignore la estructura real de los orgenes de datos, ya que es la propia lgica de acceso a datos la que expondr las estructuras con las que trabajar la aplicacin, acomodndolas a las necesidades de la misma. Otro factor importante es la reutilizacin. La separacin de esta lgica permite reutilizar los componentes de acceso a datos en diversas aplicaciones sin necesidad de copiar el cdigo y manteniendo la coherencia en el comportamiento del acceso a datos en todas ellas. A pesar de que otros elementos, como los que componen la lgica de negocios, son opcionales, los elementos de lgica de acceso a datos deben estar presentes en toda arquitectura distribuida que se disee, debido a las ventajas que aportan.
A continuacin desglosaremos la lgica de acceso a datos en sus dos componentes principales: las entidades de negocio y los objetos de acceso a datos. 2.2.3. Entidades de negocio

Las entidades de negocio son estructuras de datos que la aplicacin maneja y que representan a las entidades de datos definidas en los orgenes de datos. Una entidad de negocio tendr elementos que se correspondan, en todo o en parte, con los elementos de la entidad de datos a la que representan. Por lo general las entidades de negocio no poseen mtodos sino propiedades, ya que su finalidad es la de describir la entidad de negocio a la que representan. Podemos encontrar dos tipos de entidad de negocio segn la utilizacin que se haga de ellas en la aplicacin (ver figura 2.4):

Figura 2.4: Entidades de negocio y su relacin con las entidades de datos

Entidades de mantenimiento: Las entidades de mantenimiento se utilizan para leer, insertar, actualizar o eliminar registros del origen de datos. Cada una de sus propiedades reflejar un campo de la tabla subyacente, a menos que la lgica de negocio imponga que dicho campo no ha de ser manejable o visible desde las aplicaciones. Por ejemplo, una tabla Clientes del origen de datos podra tener su rplica en la entidad de negocios MaestroClientes, que tendr una propiedad por cada campo de la tabla. No obstante, en la tabla puede existir un campo FechaActualizacion que se maneje internamente desde el propio SGBD y que no sea visible desde la aplicacin, en cuyo caso la entidad de negocio no debe exponerlo. Entidades de lista: Las entidades de lista se utilizan para recuperar estructuras de datos obtenidas como consecuencia de una consulta. Por lo general no necesitarn todos los datos de la entidad subyacente, y tambin es frecuente que incluyan campos pertenecientes a entidades secundarias. Ambos casos suponen que estas entidades no son adecuadas para realizar operaciones de insercin o actualizacin, de modo que se utilizan como entidades de slo lectura. Por ejemplo, una entidad ListaClientes puede incluir algunos campos de la tabla Clientes y algn otro campo de una entidad secundaria, como quizs la descripcin del tipo de cliente.

Las entidades de negocio son manejadas por los objetos de acceso a datos para recuperar resultados de las llamadas al origen de datos, pero la arquitectura y las necesidades de la aplicacin determinarn si esas mismas entidades sern tambin manejadas por elementos superiores de la aplicacin. En el captulo 3 estudiaremos el modo en que las estructuras de datos pasan de unas capas a otras.
2.2.4. Objetos de acceso a datos

Los objetos de acceso a datos son los intermediarios entre la aplicacin y los orgenes de datos. Estos objetos y ninguno ms en la aplicacin son los encargados de conectarse con los orgenes de datos y enviarles sentencias SQL, rdenes de ejecucin de procesos o cualquier otra operacin que implique acceso a los datos de la aplicacin. Cualquier configuracin de acceso a los orgenes de datos o cualquier cambio en la forma de acceder a los mismos afectar a estos objetos y a ningn elemento ms de la aplicacin. Los objetos de acceso a datos utilizarn en su comunicacin con los orgenes de datos la forma nativa de comunicacin que dichos orgenes de datos exijan; por ejemplo, utilizarn sentencias SQL si el origen de datos es un SGBD o acceso a disco si el origen de datos es un fichero de texto. Sin embargo, los objetos de acceso a datos exponen estas operaciones al resto de elementos de la aplicacin mediante mtodos de clases. El cdigo de los objetos de datos ser el encargado de traducir a instrucciones nativas del origen de datos las llamadas que realicen el resto de elementos de la aplicacin. Los mtodos expuestos por los objetos de datos han de incluir los argumentos que precisen las llamadas a los orgenes de datos. La figura 2.5 muestra la estructura tpica de los objetos de acceso a datos.

Figura 2.5: Objetos de acceso a datos y su relacin con las entidades de datos. En este caso el objeto ConsultaClientes incorpora un mtodo de lista por cada tipo de consulta disponible.

Tambin se asume que los argumentos y los retornos de los mtodos utilizan las entidades de negocio directamente, aunque no siempre ha de ser as.

Un objeto de acceso a datos encapsula el acceso a una sola entidad de datos del origen, ya sea una tabla o un fichero individual. Si la lgica de la aplicacin precisa que varias entidades de datos sean tratadas como una nica entidad, debe implementarse un objeto de complejidad mayor en la lgica de negocios que ser el encargado de encapsular la lgica de los objetos de acceso a datos subyacentes. Un objeto de datos puede exponer tres tipos de mtodos de acceso a datos Mtodos CRUD (Create, Read, Update, Delete): Los mtodos CRUD se corresponden con las instrucciones necesarias para realizar un mantenimiento de una tabla, es decir, seleccionar, insertar, eliminar o actualizar un nico registro o un conjunto de registros pertenecientes a la misma entidad de datos del origen. Para ello utilizan las entidades de negocio de tipo mantenimiento, independientemente de si esas entidades son utilizadas o no por las capas superiores de la aplicacin. Por ejemplo, la tabla Clientes dispondr de un objeto de acceso a datos de tipo TablaClientes que expondr mtodos como SeleccionarCliente, InsertarCliente, ActualizarCliente y EliminarCliente. Estos mtodos poseern argumentos que se utilizarn en las sentencias SQL que el objeto de acceso a datos lanzar contra el SGBD en el que resida la tabla Clientes. Mtodos de lista: Un objeto de acceso a datos puede recuperar datos de slo lectura para realizar consultas sobre la entidad de datos. Normalmente un objeto de acceso a datos que utilice mtodos de lista recuperar entidades de negocio de tipo lista, independientemente de si la arquitectura permite o no que los objetos de capas superiores utilicen tambin esas entidades-lista. As, en el ejemplo anterior, dispondramos de un objeto de tipo ConsultaClientes que expondr mtodos como BuscarClientes. Dependiendo del enfoque que se le de al objeto, puede existir un solo mtodo que permita cualquier consulta o un mtodo por cada tipo de consulta, pero es frecuente que las estructuras que recuperan las consultas sean siempre las mismas, independientemente de los parmetros de la misma. Mtodos de procedimiento: Llamamos mtodos de procedimiento a las llamadas directas a procedimientos almacenados en el servidor que no devuelven estructuras de datos ni estn asociados a una entidad de datos concreta. Por ejemplo, un procedimiento podra cambiar automticamente los precios de un determinado conjunto de productos, los que pertenecen a una determinada categora o fabricante. Esta operacin implicara quizs cambios en ms de una tabla, y se tratara de una regla de negocio no asociada a una entidad concreta de datos. Los objetos de este tipo no utilizan ninguna estructura de datos, de modo que no se relacionan con ninguna entidad de negocio.

Cuando la lgica de la aplicacin implica que varias entidades de datos han de manejarse conjuntamente es necesario crear objetos de complejidad mayor. Los objetos de datos han de ser simples y directos en su funcionamiento y han de afectar a una sola entidad de datos. Asimismo, han de manejar entidades de negocio tambin simples.
2.2.5. Lgica de negocios

Cuando las aplicaciones adquieren cierto volumen o las entidades implicadas tienen cierta complejidad, la lgica de acceso a datos por s sola no es suficiente para encapsular convenientemente el acceso a las entidades de datos. En estos casos ser necesario aadir objetos ms complejos que a su vez encapsulen los objetos de acceso a datos y los expongan de forma ms sencilla a las capas superiores, facilitando su manejo. Adems, en las aplicaciones distribuidas con cierto tamao es frecuente encontrar reglas de negocio que no tienen nada que ver con el acceso a datos, sino que constituyen mecanismos aparte que de una forma o de otra es deseable extraer de la capa de presentacin para su reutilizacin o para que su mantenimiento sea sencillo. Estas necesidades implican a menudo la creacin de una capa adicional de lgica que llamaremos lgica de negocios. Los elementos de la lgica de negocios ya no se conectan a los orgenes de datos ni representan a las entidades de datos subyacentes, sino que utilizan los objetos de acceso a datos y las entidades de negocio, siendo pues una especie de cliente de la lgica de acceso a datos. A continuacin detallaremos los objetos ms frecuentes que podemos encontrar entre la lgica de negocios.
2.2.6. Objetos de negocio

Los objetos de negocio son una abstraccin de un conjunto de entidades de datos relacionadas entre s. El objetivo de estos objetos es encapsular el acceso a varios objetos de acceso a datos en un nico objeto, de modo que las capas superiores no hayan de realizar accesos a mltiples objetos para realizar una operacin. La figura 2.6 ilustra la estructura de objetos de negocio en una utilizacin tpica.

Figura 2.6: Relacin de un objeto de negocio con sus objetos de acceso a datos. Se han omitido los parmetros de las llamadas. Otro motivo para la encapsulacin en objetos de negocio hace referencia al comportamiento transaccional. Si una operacin requiere realizar actualizaciones en varias entidades de negocio, cada una de ellas gobernada por un nico objeto de datos, dicha operacin ha de ser transaccional. Para que la transaccin sea transparente a los objetos de capas superiores conviene realizar dicha transaccin desde un nico punto centralizado, no solamente por coherencia lgica sino por facilidad en la codificacin de la transaccin. Los objetos de negocio no son obligatorios, pero s recomendables. Una aplicacin sencilla quizs no requiera objetos de negocio, e incluso sera contraproducente implementarlos si el nmero de entidades fuera pequeo o la complejidad de la lgica no lo requiere, ya que el esfuerzo en implementar los objetos de negocio probablemente no compensar las ventajas. Sin embargo, en una aplicacin de cierta complejidad o cuyos requisitos pueden variar a lo largo del tiempo es recomendable crear objetos de negocio que encapsulen los objetos de acceso a datos subyacentes, aun cuando un objeto de negocio slo represente a un nico objeto de acceso a datos. La creacin de objetos de negocio nos permitir abordar con ms flexibilidad un nuevo requisito de negocios o una nueva relacin entre objetos de acceso a datos que no apareci en el anlisis inicial. 2.2.7. Fachadas de negocio

Las fachadas de negocio slo aparecen en grandes aplicaciones con muchos objetos de acceso a datos y muchos objetos de negocio. En este tipo de aplicaciones ser necesario encapsular algunos conjuntos de objetos de negocio en un objeto ms complejo que encapsule ciertas operaciones a fin de que la programacin de la capa de presentacin sea ms fcil y ms coherente.

Asimismo, un buen motivo para crear fachadas de negocio es la compartimentacin de los objetos de negocio en unidades funcionales con permisos especficos de uso. Por ejemplo, en un gran desarrollo corporativo se puede desear que los objetos de negocio relacionados con las nminas permitan tanto la consulta como la actualizacin. Sin embargo, pueden existir dos aplicaciones en la compaa que utilicen dichos objetos, y mientras que una de ellas permite a sus usuarios la actualizacin, la otra slo permite la consulta. En este escenario sera prudente encapsular los objetos de negocio en dos fachadas de negocio. En la primera de ellas dispondramos de mtodos de consulta y actualizacin de nminas, mientras que en la segunda fachada de negocio slo estaran definidas las consultas. De esta forma ser imposible que la aplicacin no autorizada pueda siquiera accidentalmente implementar un mtodo de actualizacin de nminas, ya que las aplicaciones no acceden directamente a los objetos de negocio sino a la fachada que se ha creado especficamente para la aplicacin y que no posee mtodos para actualizar nminas. La figura 2.7 muestra un caso de fachada de negocios.

Figura 2.7: Esquema de una fachada de negocio. La aplicacin de facturacin no tiene acceso directo a los objetos de negocio pero la operacin Facturar incluye los pasos necesarios de forma transparente a la aplicacin. Una operacin aadida (como podra ser una auditora)

no afectara a la capa de presentacin y slo requerira cambiar el comportamiento de la fachada.

Las fachadas de negocio tambin han de observar un comportamiento transaccional, de modo que los objetos de negocio han de poder incluir sus propias transacciones dentro de una transaccin ms amplia que pueda estar generada por una fachada de negocios.
2.2.8. Otros objetos de negocio

En la capa de negocios se hallan presentes con frecuencia otros objetos cuya finalidad no es el acceso a datos, sino cubrir otras funcionalidades de la aplicacin que de esta forma quedan encapsuladas para que sea sencillo mantenerlas o reutilizarlas. La funcionalidad de estos objetos puede ser muy diversa, y en esta seccin nos limitaremos a comentar los casos ms frecuentes. La figura 2.8 ilustra algunos de estos objetos en su contexto dentro de la solucin.

Figura 2.8: Otros objetos integrantes de la capa de negocio

Uno de los casos son los flujos de negocio. Los flujos de negocio son reglas que describen los diversos estados por los que ha de atravesar una determinada entidad de negocio. Por ejemplo, un pedido cuantioso podra requerir la confirmacin de un jefe de compras, la reserva de espacio en el almacn, etc. Durante el proceso, el pedido atravesar varios estados y entre un cambio de estado y otro podra pasar cierto tiempo, quizs incluso das. A pesar de que la definicin de los diferentes pasos de un flujo de negocio puede estar alojada en una base de datos, el propio mecanismo del flujo suele ser parte de la lgica de la aplicacin. Esto hace que la dinmica de los flujos de negocio o bien sea rgida, s en la base de datos slo se encuentra la definicin de los estados, o bien nos obligue a compilar la aplicacin cuando cambiamos algn flujo de informacin. Tambin es frecuente en las aplicaciones distribuidas el empleo de objetos de utilidades. En estos objetos suelen incorporarse determinadas funciones que no requieren el uso de instancias de clase y que proporcionan funcionalidad reutilizable por distintos objetos. Por ejemplo, una funcin que reciba una variable de cadena como argumento y extraiga de ella un determinado tipo de informacin, como un cdigo postal, podra ser una funcin que se utilice desde varios objetos de negocio. Por lo general este tipo de funciones no requieren que las clases en las que residen mantengan el estado, y adems son susceptibles de ser llamadas desde cualquier instancia de objeto, de modo que lo recomendable es disponerlas en mtodos estticos. Por ltimo podemos mencionar lo que llamaremos servicios transversales. Los servicios transversales proporcionan funcionalidades necesarias en todas las capas de la aplicacin y su implementacin no se limita a una sola capa sino que su mbito de actuacin se despliega en todas las capas de la solucin. En realidad no forman parte de la capa de negocios sino que se hallan presentes de una u otra forma en todas las capas de la aplicacin, como puede apreciarse en la figura 2.8. Un ejemplo de un servicio transversal es el de la seguridad. La implementacin de la seguridad por lo general afectar de forma transversal a toda la aplicacin, ya que ser necesario mantener contextos de seguridad en todas las capas, y tambin ser necesario que el tratamiento de la seguridad sea coherente entre ellas o por lo menos existan mecanismos de adaptacin si los sistemas de seguridad cambian en las fronteras fsicas entre capas. La implementacin de un sistema de seguridad integral para la solucin deber tener en cuenta todas las capas implicadas y probablemente estar ligada en mayor o menor medida al despliegue fsico de las capas lgicas.
Otro servicio transversal que errneamente se deja a veces en un segundo trmino es el de las infraestructuras de comunicacin. Los objetos de este tipo se encargan de establecer las comunicaciones entre las diferentes capas fsicas en las que residen las capas lgicas de la aplicacin. A pesar de que en una situacin ideal la comunicacin entre distintos sistemas fsicos no debera influir en el modo de disear la lgica de una aplicacin, en la mayora de las ocasiones las necesidades de despliegue fsico de las capas condicionan el despliegue lgico de las mismas, y por ende su diseo.

Por ltimo cabe mencionar entre los objetos frecuentes en las aplicaciones de cierto volumen a los objetos de gestin operacional. Su uso es variado y depende en gran medida de las necesidades de gestin de la propia aplicacin. Por ejemplo, es frecuente encontrar en las aplicaciones algunos objetos encargados de gestionar el registro de sucesos o la auditora.

Existen otros servicios transversales como la gestin de clsteres o el balanceo de carga pero en la mayor parte de las ocasiones estos servicios estn proporcionados por el propio sistema operativo y no suele ser necesario programarlos, de modo que no los incluiremos en nuestra descripcin de la arquitectura.

2.3.

La capa de presentacin

La capa de presentacin la constituye el software con el que el usuario interacta para operar con la aplicacin. Es probablemente la parte ms trabajosa de la misma, ya que es muy frecuente que aplicaciones cuyas reglas de negocio sean relativamente sencillas tengan en cambio un interfaz de usuario complejo y vistoso que le proporcione al usuario una experiencia de manejo fcil y agradable. Adems, mientras que en la creacin de reglas de negocio normalmente slo interviene un tipo de programacin, preferentemente basada en lenguajes, en la preparacin del interfaz de usuario suelen mezclarse varias disciplinas, como el diseo o la usabilidad. Una error frecuente en la creacin de los interfaces de usuario consiste en olvidar que las reglas de negocio no se hallan en el interfaz, sino en los objetos subyacentes que residen en las capas inferiores de la solucin. La capa de presentacin no es ms que un sistema de presentacin y manejo de datos que se obtienen y se actualizan con los objetos de negocio comunes para todas las aplicaciones que los usan. Si se olvida este aspecto se puede caer en la tentacin de colocar reglas de negocio en el interfaz de usuario, imposibilitando la reutilizacin de las mismas y complicando la distribucin y despliegue de la aplicacin. Por lo tanto, una regla de oro a observar en toda aplicacin distribuida es que la capa de presentacin ha de ser completamente independiente de las reglas de negocio, y su funcin se limitar a la presentacin y manejo de los datos de la aplicacin, que obtendr mediante el uso de los objetos de la capa de negocios comentados en la seccin anterior. Esto convierte a la capa de presentacin en una mera fachada de los procesos que son gestionados por la capa de negocios. Las capas de presentacin suelen ser delgadas, es decir, contienen pocas lneas de cdigo, ya que su funcin principal est cubierta por las caractersticas de los elementos visuales que las componen. Una tendencia creciente es la separacin entre diseo y cdigo, ya existente, por ejemplo, en las aplicaciones web dinmicas.

2.4.

Distribucin fsica de las capas lgicas

Una vez descartada la capa de presentacin como ubicacin posible para la lgica de negocio, al arquitecto que disea una aplicacin distribuida se le presenta el dilema de la distribucin fsica de cada una de las capas lgicas. Por un lado existe la posibilidad de colocar las reglas de negocio enteramente en el servidor, mediante procedimientos almacenados, disparadores y otras funciones propias del SGBD. Por el otro, la colocacin de las reglas de negocio en objetos creados mediante lenguajes

independientes de la base de datos tambin supone ciertos problemas, como la dependencia que naturalmente se crear entre los diversos mdulos fsicos en los que residan las clases. A pesar de que no existe una solucin nica para este problema, en esta seccin propondremos dos escenarios posibles muy distintos entre s a modo de ejemplo y estudiaremos los factores que nos harn decidirnos por una solucin u otra. Probablemente una solucin deber incluir elementos de ambos escenarios, as que deber ser el arquitecto el que juzgue en cada caso la manera ptima de implementar la solucin.
2.4.1. Escenario 1: Aplicacin corporativa

En una aplicacin corporativa de gran tamao los datos residen en un SGBD de cuyo mantenimiento se encarga un administrador de bases de datos. Disponemos de una gran nmero de tablas con muchos registros y la seguridad es un factor importante, ya que no todos los departamentos de la empresa pueden acceder a todos los datos. Por otro lado, en la corporacin existen diferentes aplicaciones que manejan los datos, y hay diferentes equipos de desarrollo que acceden a los mismos. Permitir que cada uno de los equipos de desarrollo establezca sus propias reglas de negocio de la empresa no es asumible, as que la gestin de los datos necesariamente ha de centralizarse. En este escenario la mayor parte de las reglas de negocio que se ocupan del tratamiento de los datos residirn en procedimientos almacenados o en reglas del propio SGBD. Esto permitir restringir el acceso a los datos a determinados departamentos, as como unificar el tratamiento de los mismos. Adems, es muy probable que se requiera acceso de alto rendimiento a los datos desde delegaciones o sedes remotas, lo que conduce a la utilizacin de mtodos ptimos para la consulta de datos. El mantenimiento de las reglas de negocio ser tarea de los administradores de la base de datos. Los desarrolladores debern exponer sus necesidades a los encargados de crear y modificar los procedimientos almacenados, de forma que el acceso directo a las tablas quedar restringido a los que poseen los permisos necesarios para ello. Las aplicaciones slo tendrn permisos para acceder a los procedimientos almacenados que utilicen. Los objetos de la capa de negocio sern delgados, ya que poseern pocas reglas de negocio. Sin embargo es ms que probable que necesitemos utilizar fachadas de negocio situadas en diferentes mdulos, ya que existirn diversas capas de presentacin (aplicaciones Windows, aplicaciones Web, acceso mediante PDA, etc.) y la reutilizacin de las funcionalidades ser un factor fundamental.
2.4.2. Escenario 2: Aplicacin comercial

Una empresa que desarrolla y vende una aplicacin de gestin comercial se encuentra con un escenario completamente distinto al planteado en la seccin anterior. Para comenzar, la aplicacin se vender a clientes en cuya infraestructura de servidores la

empresa no puede interferir. El proceso de instalacin habr de ser complejo, ya que no slo deber instalar la aplicacin en las mquinas del cliente sino que adems deber ejecutar los scripts necesarios para la creacin de la base de datos necesaria. En muchos casos se tratar incluso de bases de datos locales (por ejemplo, en Access o en SQL Server Express). En este escenario la colocacin de reglas de negocio en el servidor no es aconsejable. En primer lugar, una actualizacin de las reglas implica la modificacin de los procedimientos almacenados, lo que conlleva una dificultad aadida a la distribucin de actualizaciones. En segundo lugar, la empresa ser naturalmente celosa de sus reglas de negocio, y no desear comprometerlas situndolas en procedimientos almacenados a los que el usuario final tendr acceso. Por otro lado, mantener las reglas de negocio en los componentes (DLL) permite una mayor proteccin de la propiedad intelectual de la aplicacin. Por otro lado, estas aplicaciones tienen un mbito de ejecucin local o, en el ms optimista de los casos, restringido a una LAN. La reutilizacin de mdulos no es probable, as que la divisin en componentes separados fsicamente no ser esencial, salvo en lo tocante a la optimizacin de los recursos consumidos por la aplicacin en el equipo local. Los componentes sern este caso ms gruesos y, a pesar de que la divisin lgica seguir existiendo, es muy posible que no exista una fachada de negocios como tal y que el interfaz de usuario realice llamadas directas a los objetos de negocio o incluso a los objetos de acceso a datos.
2.4.3. Factores que influyen en la distribucin fsica

Para finalizar, enumeraremos los factores que un arquitecto de soluciones debe tener en cuenta a la hora de disear la distribucin fsica de los diferentes elementos lgicos de la aplicacin: 1. Infraestructura de comunicaciones: Las diversas capas de la aplicacin debern comunicarse entre s, traspasando datos de un lado a otro y estableciendo referencias entre ellas. Si la distribucin fsica de los equipos en los que se ejecutar la aplicacin es simple no ser necesario distribuir los componentes en varias capas fsicas separadas entre s, lo que proporcionar a la aplicacin ms velocidad y ms facilidad de instalacin y configuracin. Si la accesibilidad de los equipos es muy diversa la distribucin es un factor importante, y ha de intentarse que las capas de presentacin sean lo ms delgadas posible. En escenarios muy distribuidos lo ms recomendable es una arquitectura orientada a servicios (SOA), de la cual hablaremos en profundidad ms adelante en este mismo libro. 2. Dependencias: Cuando dos capas se comunican entre s es forzoso establecer entre ellas una cierta dependencia. Es necesario prever estas dependencias para minimizar las modificaciones que requiera el cambio en una de las capas. Distribuir los componentes mejora la escalabilidad y la reutilizacin pero complica la relacin de dependencias entre los mismos.

3. Impacto en las modificaciones posteriores: Es un axioma que cualquier aplicacin requiere mantenimiento. El arquitecto ha de contemplar el impacto de una actualizacin en la aplicacin. Si no es factible mantener los procedimientos almacenados o si se complica la distribucin de una actualizacin quizs no sea aconsejable su uso. 4. Reutilizacin: En muchas ocasiones ser necesario reutilizar reglas de negocio en varias aplicaciones. En estos casos subdividir la aplicacin en diversos componentes fsicos que cumplan funciones muy especficas ser muy til y proporcionar mucha flexibilidad a la hora de crear nuevas aplicaciones que reutilicen las mismas reglas de negocio. 5. Rendimiento: La colocacin de las reglas en el servidor o en componentes compilados puede influir en el rendimiento general de la aplicacin si las reglas utilizan grandes conjuntos de registros o clculos complicados. Utilizar mtodos de alto rendimiento puede representar un factor importante en la escalabilidad de la aplicacin. 6. Dificultad de implantacin: A pesar de las facilidades que ofrecen entornos avanzados como Visual Studio, una aplicacin muy distribuida implica una implantacin ms compleja. Ser necesario poner en marcha servicios, establecer referencias remotas y quizs atravesar fronteras de seguridad como dominios o firewalls. Si el tiempo es escaso o el equipo no posee los conocimientos suficientes la distribucin de componentes puede ser un factor de complejidad aadida.
http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/pineda_d_ay/capitulo2.pdf http://knol.google.com/k/aplicaciones-distribuidas http://www.slideshare.net/soreygarcia/aplicaciones-distribuidas-presentation

1.1.4 Aplicaciones distribuidas.

Mucho tiempo ha transcurrido ya desde que en la dcada de los ochenta la tecnologa de la informacin comenzara tmidamente a ocupar el lugar que hoy en da posee. En aquellos das, que tal vez algunos veteranos recuerden con cierta nostalgia, la mayora de los sistemas informticos estaban constituidos por enormes sistemas centrales que ejecutaban todos las aplicaciones dentro de s mismos, y en el mejor de los casos los usuarios interactuaban con esas aplicaciones mediante terminales tontos, que no eran sino simples pantallas con teclado que permitan enviar caracteres al sistema central y mostrar las respuestas, tambin basadas en caracteres, que los monstruos generaban y enviaban a travs de un cable.

El advenimiento de los ordenadores personales constituy la primera revolucin. Ahora los usuarios disponan de un procesador y de un sistema de almacenamiento autnomo, capaz de procesar datos e incluso de mostrar grficos por pantalla adems de caracteres. Surgieron multitud de aplicaciones de escritorio que independizaron a

los usuarios de los grandes sistemas y el coste del hardware se redujo a niveles tan aceptables que empresas que no hubieran podido afrontar la inversin en un sistema informtico centralizado comenzaron a introducir en sus procesos de negocio la gestin informtica de los datos.

Pero en el fondo los modos de ejecucin de aplicaciones no haban cambiado. De la ejecucin en un sistema centralizado se pas a la ejecucin en sistemas ms pequeos e independientes, pero al fin y al cabo las aplicaciones seguan siendo islas incomunicadas entre si, y los usuarios no podan contar ms que con las capacidades del propio ordenador para procesar los datos. Por un lado, la necesidad de compartir datos no quedaba resuelta con sistemas independientes, y la opcin de las aplicaciones centralizadas segua siendo la nica viable en entornos multiusuario. Por el otro, cuando los datos eran generados por un ordenador central no haba forma de tratarlos localmente y toda la potencia de los ordenadores personales no serva para nada. El avance en las tecnologas de redes comenz a dibujar un horizonte en el que las aplicaciones se comunicaran entre s y en el que los procesos de una aplicacin se distribuiran entre diferentes equipos, cada uno con caractersticas que les permiteran aumentar la eficacia y la disponibilidad de la aplicacin. Se comenz a separar la lgica de las aplicaciones para situarla en el nivel ms conveniente y conceptos como cliente y servidor fueron cobrando cada vez ms sentido. Tras algunos aos de indecisin, los protocolos de red se estandarizaron y hacia mediados de los aos 90 Internet se convirti en la primera revolucin autntica del siglo XXI, provocando no slo un vuelco en las relaciones sociales y econmicas sino tambin, por supuesto, un cambio completo de paradigma en la arquitectura de las aplicaciones informticas.

Las aplicaciones se convierten, as, en aplicaciones distribuidas. Sin arriesgarnos a proporcionar una definicin acadmica que puede encontrarse muy fcilmente en Internet, diremos informalmente que una aplicacin distribuida es aquella cuyo objetivo final se alcanza mediante la ejecucin de diversos procesos independientes que por lo general se ejecutan en equipos diferentes y que de una forma u otra se pasan datos entre ellos mediante protocolos de comunicaciones bien establecidos. En esta primera seccin examinaremos las formas arquitectnicas (o de diseo) que adquieren las aplicaciones distribuidas. Cada una de ellas plantea ciertas ventajas e inconvenientes que ser necesario tener en cuenta a la hora de crear el cdigo para los diferentes componentes de la aplicacin.

Caractersticas de las aplicaciones distribuidas.

Independientemente de su arquitectura, todas las aplicaciones distribuidas comparten ciertas caractersticas que las diferencian notablemente de las aplicaciones

centralizadas y de las aplicaciones de escritorio. Conocer esas caractersticas y evaluar su impacto en las aplicaciones es primordial para escoger el diseo ms adecuado de las mismas. No es cierto que una aplicacin se pueda disear de cualquier manera.

Aspectos primordiales que han de evaluarse a la hora de disear una aplicacin distribuida: 1. Concurrencia: De igual forma que en las aplicaciones centralizadas, las aplicaciones distribuidas sern utilizadas por cierto nmero de usuarios concurrentemente. Aspectos como las transacciones, los bloqueos de recursos o el uso de la CPU de los equipos a los que acceden muchos usuarios son determinantes a la hora de disear una arquitectura con la mxima eficacia.

2. Topologa de la red: A pesar de que a da de hoy los anchos de banda cada vez son m s amplios, el trfico de red puede ser un aspecto importante que condicione el tiempo de respuesta de la aplicacin. En muchos casos tambin ser necesario tener en cuenta el tipo de red (LAN o WAN), o si la aplicacin ser o no accesible a travs de Internet. La forma de distribuir los procesos de la aplicacin tendr que tomar en consideracin el tipo de red que soportar el trfico de datos.

3. Ubicacin de la lgica: Dado que en una aplicacin distribuida intervienen varios procesos, ser necesario decidir en cul de los posibles procesos fsicos se sita cada componente lgico de la aplicacin. Mientras que algunos procesos, como la presentacin de datos o la recuperacin de los mismos, tienen un sitio natural, otros, como la validacin o la navegacin, pueden ocupar diversos lugares dentro del diagrama que conforma la estructura de la aplicacin. En muchas ocasiones la ubicacin de los componentes lgicos impacta sobre el rendimiento, sobre la reutilizacin del cdigo o sobre la facilidad de programacin.

4. Homogeneidad de las plataformas: En una aplicacin distribuida los sistemas operativos involucrados o los lenguajes de desarrollo utilizados pueden ser un factor a tener en cuenta a la hora de decidir algunos aspectos importantes, como por ejemplo el modo de pasar datos entre procesos. La utilizacin de estndares puede ser muy til a la hora de crear aplicaciones distribuidas que permanezcan abiertas a diversos sistemas heterogneos, pero si las plataformas son similares es posible alcanzar mejor rendimiento sacrificando interoperabilidad.

5. Seguridad: Una aplicacin distribuida mantiene procesos que de una forma u otra estn a la escucha en una red, lo que aumenta la vulnerabilidad de la aplicacin. Ser necesario establecer polticas de seguridad que impidan el acceso no autorizado a los procesos. Pedir al usuario un nombre y una contrasea al iniciar el programa es probable que no sea suficiente. No existe una solucin nica para todos los problemas. A pesar de que en la actualidad se priman ciertas arquitecturas sobre otras, la realidad es que la decisin final depender de todos los factores anteriormente citados, y de otros que a veces no se tienen mucho en cuenta pero que tambin poseen su importancia, como el coste total de la aplicacin o la complejidad de la solucin respecto al problema planteado. Ni es recomendable subestimar las necesidades de una aplicacin compleja, ni tampoco conviene sobredimensionar la estructura de una aplicacin sencilla que puede resolverse con medios ms asequibles.

Con las aplicaciones distribuidas el mero anlisis funcional de las caractersticas de una aplicacin ya no es suficiente y es necesario tambin considerar la distribucin y estructura de los procesos involucrados. La tarea del arquitecto de aplicaciones consistir precisamente en tomar la decisin de diseo ms adecuada para resolver el problema, ajustndose lo mejor posible a los requerimientos y tomando en cuenta todos los factores implicados.

Arquitectura de las aplicaciones distribuidas.

En una aplicacin distribuida en n-capas los diferentes elementos que integran la aplicacin se agrupan de forma lgica segn la funcionalidad que reciben o suministran al o desde el resto de los elementos. As, algunos elementos se limitarn a recibir peticiones de datos mientras que otros interactuarn con el usuario y su funcin ser principalmente la de solicitar a otros elementos la informacin que el usuario precisa. Atendiendo al papel que los distintos elementos juegan dentro de la aplicacin, distinguimos con claridad tres grupos lgicos en los que podemos agrupar elementos segn su funcionalidad: La capa de servidor incluye aquellos elementos que se encargan de recibir las peticiones de datos o de acceso a servicios bsicos del sistema y de suministrar a otros elementos la informacin solicitada. La capa de negocios encapsula las reglas de acceso a datos y la gestin de procesos internos de la aplicacin. La capa de presentacin se encarga de la lgica necesaria para interactuar con el usuario de la aplicacin.

Una vez agrupada la funcionalidad en capas lgicas es fcil relacionar unas con otras. El usuario interactuar con la capa de presentacin, solicitando datos o desencadenando acciones. Las solicitudes sern atendidas por la capa de negocios, que se encargar de su gestin o de la traduccin necesaria para que la capa de servidor realice la tarea solicitada. Si la capa de servidor debe proporcionar datos estos se devolvern a la capa de negocios, la cual los gestionar o transmitir a la capa de presentacin. La figura 2.1 ilustra este esquema.

Figura 2.1: Esquema lgico de las capas en una aplicacin distribuida.

Es importante notar que el esquema que mostramos es un esquema lgico, no fsico. El modo de distribuir fsicamente las capas (en diferentes ejecutables o DLL, o en diferentes equipos) se corresponder con el esquema lgico en todo o en parte, pero no necesariamente existir una correspondencia exacta entre la distribucin lgica de los elementos y su distribucin fsica. La capa de negocios podra residir en diferentes mquinas, por ejemplo, o las entidades de negocio y la capa de servidor podran formar parte de la misma DLL. Ms adelante hablaremos de la relacin fsica entre las diversas capas lgicas y estudiaremos cmo los diferentes escenarios nos condicionarn la distribucin fsica de las capas lgicas. Adicionalmente, en las aplicaciones distribuidas existen otras funcionalidades, como la seguridad o el registro de sucesos, que no son exclusivas de un grupo lgico ya que deben aparecer en todos los elementos de la aplicacin.