1.1.4 Aplicaciones distribuidas.

Mucho tiempo ha transcurrido ya desde que en la década de los ochenta la tecnología de la información comenzara tímidamente a ocupar el lugar que hoy en día posee. En aquellos días, que tal vez algunos veteranos recuerden con cierta nostalgia, la mayoría de los sistemas informáticos 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 permitían enviar caracteres al sistema central y mostrar las respuestas, también basadas en caracteres, que los monstruos generaban y enviaban a través de un cable.

El advenimiento de los ordenadores personales constituyó la primera revolución. Ahora los usuarios disponían de un procesador y de un sistema de almacenamiento autónomo, capaz de procesar datos e incluso de mostrar gráficos por pantalla además 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 inversión en un sistema informático centralizado comenzaron a introducir en sus procesos de negocio la gestión informática de los datos.

Pero en el fondo los modos de ejecución de aplicaciones no habían cambiado. De la ejecución en un sistema centralizado se pasó a la ejecución en sistemas más pequeños e independientes, pero al fin y al cabo las aplicaciones seguían siendo islas incomunicadas entre si, y los usuarios no podían contar más 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 opción de las aplicaciones centralizadas seguía siendo la única viable en entornos multiusuario. Por el otro, cuando los datos eran generados por un ordenador central no había forma de tratarlos localmente y toda la potencia de los ordenadores personales no servía para nada.

El avance en las tecnologías de redes comenzó a dibujar un horizonte en el que las aplicaciones se comunicarían entre sí y en el que los procesos de una aplicación se distribuirían entre diferentes equipos, cada uno con características que les permiteran aumentar la eficacia y la disponibilidad de la aplicación. Se comenzó a separar la lógica de las aplicaciones para situarla en el nivel más conveniente y conceptos como “cliente” y “servidor” fueron cobrando cada vez más sentido. Tras algunos años de indecisión, los protocolos de red se estandarizaron y hacia mediados de los años 90 Internet se convirtió en la primera revolución auténtica del siglo XXI, provocando no sólo un vuelco en las relaciones sociales y económicas sino también, por supuesto, un cambio completo de paradigma en la arquitectura de las aplicaciones informáticas.

Las aplicaciones se convierten, así, en aplicaciones distribuidas. Sin arriesgarnos a proporcionar una definición académica que puede encontrarse muy fácilmente en Internet, diremos informalmente que una aplicación distribuida es aquella cuyo objetivo final se alcanza mediante la ejecución 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 sección examinaremos las formas arquitectónicas (o de diseño) 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 código para los diferentes componentes de la aplicación.

Características de las aplicaciones distribuidas.

Independientemente de su arquitectura, todas las aplicaciones distribuidas comparten ciertas características que las diferencian notablemente de las aplicaciones centralizadas y de las aplicaciones de escritorio. Conocer esas características y evaluar su impacto en las aplicaciones es primordial para escoger el diseño más adecuado de las mismas. No es cierto que una aplicación se pueda diseñar de cualquier manera.

Aspectos primordiales que han de evaluarse a la hora de diseñar una aplicación distribuida:

1. Concurrencia: De igual forma que en las aplicaciones centralizadas, las aplicaciones distribuidas serán utilizadas por cierto número 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 diseñar una arquitectura con la máxima eficacia.

2. Topología de la red: A pesar de que a día de hoy los anchos de banda cada vez son má s amplios, el tráfico de red puede ser un aspecto importante que condicione el tiempo de respuesta de la aplicación. En muchos casos también será necesario tener en cuenta el tipo de red (LAN o WAN), o si la aplicación será o no accesible a través de Internet. La forma de distribuir los procesos de la aplicación tendrá que tomar en consideración el tipo de red que soportará el tráfico de datos.

3. Ubicación de la lógica: Dado que en una aplicación distribuida intervienen varios procesos, será necesario decidir en cuál de los posibles procesos físicos se sitúa cada componente lógico de la aplicación. Mientras que algunos procesos, como la presentación de datos o la recuperación de los mismos, tienen un sitio natural, otros, como la validación o la navegación, pueden ocupar diversos lugares dentro del diagrama que conforma la estructura de la aplicación. En muchas ocasiones la ubicación de los componentes lógicos impacta sobre el rendimiento, sobre la reutilización del código o sobre la facilidad de programación.

4. Homogeneidad de las plataformas: En una aplicación 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 utilización de estándares puede ser muy útil a la hora de crear aplicaciones distribuidas que permanezcan abiertas a diversos sistemas heterogéneos, pero si las plataformas son similares es posible alcanzar mejor rendimiento sacrificando interoperabilidad.

5. Seguridad: Una aplicación distribuida mantiene procesos que de una forma u otra están a la escucha en una red, lo que aumenta la vulnerabilidad de la aplicación. Será necesario establecer políticas de seguridad que impidan el acceso no autorizado a los procesos. Pedir al usuario un nombre y una contraseña al iniciar el programa es probable que no sea suficiente.

No existe una solución única para todos los problemas. A pesar de que en la actualidad se priman ciertas arquitecturas sobre otras, la realidad es que la decisión final dependerá de todos los factores anteriormente citados, y de otros que a veces no se tienen mucho en cuenta pero que también poseen su importancia, como el coste total de la aplicación o la complejidad de la solución respecto al problema planteado. Ni es recomendable subestimar las necesidades de una aplicación compleja, ni tampoco conviene sobredimensionar la estructura de una aplicación sencilla que puede resolverse con medios más asequibles.

Con las aplicaciones distribuidas el mero análisis funcional de las características de una aplicación ya no es suficiente y es necesario también considerar la distribución y estructura de los procesos involucrados. La tarea del arquitecto de aplicaciones consistirá precisamente en tomar la decisión de diseño más adecuada para resolver el problema, ajustándose lo mejor posible a los requerimientos y tomando en cuenta todos los factores implicados.

Arquitectura de las aplicaciones distribuidas.

En una aplicación distribuida en n-capas los diferentes elementos que integran la aplicación se agrupan de forma lógica según la funcionalidad que reciben o suministran al o desde el resto de los elementos. Así, algunos elementos se limitarán a recibir peticiones de datos mientras que otros interactuarán con el usuario y su función será principalmente la de solicitar a otros elementos la información que el usuario precisa.
Atendiendo al papel que los distintos elementos juegan dentro de la aplicación, distinguimos con claridad tres grupos lógicos en los que podemos agrupar elementos según su funcionalidad:

•La capa de servidor incluye aquellos elementos que se encargan de recibir las peticiones de datos o de acceso a servicios básicos del sistema y de suministrar a otros elementos la información solicitada.
•La capa de negocios encapsula las reglas de acceso a datos y la gestión de procesos internos de la aplicación.
•La capa de presentación se encarga de la lógica necesaria para interactuar con el usuario de la aplicación.

Una vez agrupada la funcionalidad en capas lógicas es fácil relacionar unas con otras. El usuario interactuará con la capa de presentación, solicitando datos o desencadenando acciones. Las solicitudes serán atendidas por la capa de negocios, que se encargará de su gestión o de la traducción necesaria para que la capa de servidor realice la tarea solicitada. Si la capa de servidor debe proporcionar datos estos se devolverán a la capa de negocios, la cual los gestionará o transmitirá a la capa de presentación. La figura 2.1 ilustra este esquema.

Figura 2.1: Esquema lógico de las capas en una aplicación distribuida.

Es importante notar que el esquema que mostramos es un esquema lógico, no físico. El modo de distribuir físicamente las capas (en diferentes ejecutables o DLL, o en diferentes equipos) se corresponderá con el esquema lógico en todo o en parte, pero no necesariamente existirá una correspondencia exacta entre la distribución lógica de los elementos y su distribución física. La capa de negocios podría residir en diferentes máquinas, por ejemplo, o las entidades de negocio y la capa de servidor podrían formar parte de la misma DLL. Más adelante hablaremos de la relación física entre las diversas capas lógicas y estudiaremos cómo los diferentes escenarios nos condicionarán la distribución física de las capas lógicas.

Adicionalmente, en las aplicaciones distribuidas existen otras funcionalidades, como la seguridad o el registro de sucesos, que no son exclusivas de un grupo lógico ya que deben aparecer en todos los elementos de la aplicación.