ARQUITECTURA DE SISTEMAS DISTRIBUIDOS - PARTE II

ARQUITECTURA DE OBJETOS DISTRIBUIDOS


En el modelo cliente-servidor de un sistema distribuido, los clientes y los servidores son diferentes. Los clientes reciben servicios de los servidores y no de otros clientes; los servidores pueden actuar como clientes recibiendo servicios de otros servidores, pero sin solicitar servicios de clientes; los clientes deben conocer los servicios que ofrece cada uno de los servidores y deben conocer como contactar con cada uno de estos servidores.
Este modelo funciona bien para muchos tipos de aplicaciones. Sin embargo, limita la flexibilidad de los diseñadores del sistema ya que ellos deben decidir donde se proporciona cada servicio. También deben planificar la escalabilidad y proporcionar algún medio para distribuir la carga sobre los servidores cuando más clientes se añadan al sistema.
Una aproximación más general al diseño de sistemas distribuidos es eliminar la distinción entre cliente y servidor y diseñar la arquitectura del sistema como una arquitectura de objetos distribuidos. En una arquitectura de objetos distribuidos (figura 10), los componentes fundamentales del sistema son objetos que proporcionan una interfaz a un conjunto de servicios que ellos suministran. Otros objetos realizan llamadas a estos servicios sin hacer ninguna distinción lógica entre un cliente (el receptor de un servicio) y un servidor (el proveedor de un servicio).

fig10.png
FIG 10: Arquitectura de objetos distribuidos
Los objetos pueden distribuirse a través de varias computadoras en una red y comunicarse a través de un middleware. A este middleware se lo denomina intermediario de peticiones de objetos. Su misión es proporcionar una interfaz transparente entre los objetos. Proporciona un conjunto de servicios que permiten la comunicación entre los objetos y que estos sean añadidos y eliminados del sistema.
Las ventajas del modelo de objetos distribuidos son las siguientes:
  • Ø Permitir al diseñador del sistema retrasar decisiones sobre dónde y como deberían proporcionarse los servicios. Los objetos que proporcionan servicios pueden ejecutarse sobre cualquier nodo de la red. Por lo tanto, la distinción entre los modelos de cliente rico y ligero es irrelevante, ya que no hay necesidad de decidir con antelación donde se sitúa la lógica de aplicación de los objetos.
  • Ø Es una arquitectura muy abierta que permite añadir nuevos recursos si es necesario. Se han desarrollado e implementado estándares de comunicación de objetos que permiten escribir objetos en diferentes lenguajes de programación para comunicarse y proporcionar servicios entre ellos.
  • Ø El sistema es flexible y escalable. Se pueden crear diferentes instancias del sistema proporcionando los mismos servicios por objetos diferentes o por objetos reproducidos para hacer frente a las diferentes cargas del sistema. Pueden añadirse nuevos objetos a medida que la carga del sistema se incrementa sin afectar al resto de los objetos del sistema.
  • Ø Si es necesario, es posible reconfigurar el sistema de forma dinámica mediante la migración de objetos a través de la red. Esto puede ser importante donde haya fluctuación en los patrones de demanda de servicios. Un objeto que proporciona servicios puede migrar al mismo procesador que los objetos que demandan los servicios, en lo que mejora el rendimiento del sistema.
Una arquitectura de objetos distribuidos puede ser usada como un modelo lógico que permita estructurar y organizar el sistema. En este caso se debe pensar en cómo proporcionar las funcionalidades de la aplicación únicamente en términos de servicios y combinaciones de servicios. A continuación se debe identificar como proporcionar estos servicios utilizando varios objetos distribuidos. En este nivel, los objetos que se diseñan son normalmente de grano grueso (denominados algunas veces objetos de negocio) que proporcionan servicios específicos del dominio. Por ejemplo, en una aplicación de venta al por menor, puede haber objetos de negocio relacionados con el control de existencias, comunicaciones con el cliente, pedidos de productos y otros. Por supuesto, este modelo lógico puede llevarse a cabo como un modelo de implementación.
De forma alternativa se puede usar una aproximación de objetos distribuidos para implementar sistemas clientes-servidor. En este caso, el modelo lógico del sistema es un modelo cliente-servidor, pero tanto los clientes como los servidores se implementan como objetos distribuidos que se comunican a través de un bus software. Esto hace posible realizar cambios en el sistema de forma sencilla, por ejemplo, desde un sistema de dos capas a un sistema multicapa. En este caso, el servidor o el cliente pueden no implementarse como un único objeto distribuido, sino que puede estar compuesto por objetos más pequeños que proporcionan servicios especializados.
Un ejemplo de un tipo de sistema en el que una arquitectura de objetos distribuidos podría ser adecuada es un sistema de minería de datos que busca relaciones entre los datos almacenados en varias bases de datos (figura 11). Un ejemplo de aplicación de minería de datos podría ser un negocio de venta al por menor que tuviese, por ejemplo, tiendas de comestibles y tiendas de ferretería, y quisiera encontrar las relaciones entre compas de diversos tipos de comestibles y de ferretería. Por ejemplo, la gente que quiera comprar comida para bebe también puede comprar un tipo de concreto de papel para las paredes. Con este conocimiento, la empresa podría entonces ofrecer ofertas especificas a los clientes de comida para bebe combinadas con otras.

En este ejemplo, cada base de datos puede encapsularse como un objeto distribuido con una interfaz que proporciona acceso de solo lectura a sus datos. Los objetos integradores se ocupan cada uno de ellos de tipos específicos de relaciones, y recogen información desde todas las bases de datos para intentar deducir dichas relaciones. Podría haber un objeto integrador que se ocupara de las variaciones de ventas de comestibles de temporada y otro que se ocupara de las relaciones entre los diferentes tipos de comestibles.

fig11.png
FIG11: Arquitectura de distribución de un sistema de minería de datos
Los objetos visualizadores interaccionan con los objetos integradores para producir una visualización o un informe de las relaciones descubiertas. Debido a que se manejan grandes volúmenes de datos, los objetos visualizadores usaran normalmente representaciones graficas de las relaciones que hayan descubierto.

Una arquitectura de objetos distribuidos es adecuada para este tipo de aplicación en lugar de una aplicación cliente-servidor por tres razones:
  1. A diferencia de un sistema bancario ATM (por ejemplo), el modelo lógico del sistema no es el de provisión de servicios en el que se pueden distinguir servicios de gestión de datos.
  2. Se pueden añadir bases de datos al sistema sin mayor problema. Cada base de datos es simplemente otro objeto distribuido. Los objetos de bases de datos pueden proporcionar una interfaz simplificada que controle el acceso a los datos. Las bases de datos a las que se puede acceder pueden residir en diferentes maquinas.
  3. Permite explorar nuevos tipos de relaciones añadiendo nuevos objetos integradores. Las partes del negocio que estén interesadas en relaciones específicas pueden extender el sistema añadiendo objetos integradores que operen sobre computadoras sin requerir conocimiento de ningún otro integrador que se use en cualquier otra parte del sistema.
La principal desventaja de las arquitecturas de objetos distribuidos es que son mucho más complejas de diseñar que los sistemas cliente-servidor. Los sistemas cliente-servidor parecen ser la forma más natural de concebir a los sistemas. Estos reflejan muchas transacciones humanas en las que la gente solicita y recibe servicios de otra gente especializada en proporcionar dichos servicios. Es más difícil pensar en una provisión de servicios generales, y todavía no tenemos una gran experiencia en el diseño y desarrollo de objetos de negocio de grano grueso

COMPUTACIÓN DISTRIBUIDA INTERORGANIZACIONAL


Por razones de seguridad e interoperabilidad, la computación distribuida ha sido principalmente implementada a nivel organizacional. Una organización tiene varios servidores y reparte su carga computacional entre ellos. Debido a que dichos servidores están todos dentro de la misma organización, pueden aplicarse estándares locales y procesos operacionales. Aunque, para los sistemas basados en web, las computadoras cliente están a menudo fuera de los límites de la organización, su funcionalidad está limitada a la ejecución de software de interfaz de usuario.
Sin embargo, actualmente están disponibles modelos más recientes de computación distribuida que permiten computación distribuida interorganizacional en lugar de intraorganizacional. La computación peer-to-peer se basa en cálculos que se llevan a cabo en nodos individuales de la red. Los sistemas orientados a servicios están relacionados con los servicios distribuidos en lugar de con objetos distribuidos, y también se relacionan con estándares basados en XML para intercambio de datos.

Arquitecturas peer-to-peer
Los sistemas peer-to-peer (p2p) son sistemas descentralizados en los que los cálculos pueden llevarse a cabo en cualquier nodo de la red y, al menos en principio, no se hacen distinciones entre clientes y servidores. En las aplicaciones peer-to-peer, el sistema en su totalidad se diseña para aprovechar la ventaja de la potencia computacional y disponibilidad de amcenamiento a través de una red de computadoras potencialmente enorme. Los estándares y protocolos que posibilitan las comunicaciones a través de los nodos están embebidos en la propia aplicacion, y cada nodo debe ejecutar una copia de dicha aplicacion.
Por ejemplo, los sistemas de compartición de ficheros basados en los protocolos Gnutella y Kazaa se usan para compartir ficheros sobe PCs de usuario, y sistemas de mensajería instantánea tales como ICQ y Jabber proporcionan comunicaciones directas entre usuarios sin un servidor intermedio. SETI@home es un proyecto a largo plazo para procesar datos de radiotelescopía sobre PCs desde casa para buscar indicios de vida extraterrestre, y Freenet es una base de datos descentralizada que ha sido diseñada para hacer más fácil la publicación de información anónima y hacer que sea más difícil para las autoridades suprimir esta información.
Sin embargo, hay indicios de que esta tecnología se está utilizando de forma creciente en empresas para que las redes de PCs soporten la potencia de dichas empresas (McDougall, 2000). Intel y Boeing han implementado sistemas p2p para aplicaciones que requieren computaciones intensivas. Para aplicaciones cooperativas que soportan trabajo distribuido, ésta parece ser la tecnología más efectiva.
Se puede ver la arquitectura de las aplicaciones p2p desde dos puntos de vista. La arquitectura lógica de la red es la distribución de la arquitectura del sistema, mientras que la arquitectura de la aplicación es la organización genérica de los componentes en cada tipo de aplicación.
En prinicipio, en los sistemas peer-to-peer cada nodo en la red podría conocer cualquier otro nodo, podría conectarse con él, y podría intercambiar datos. En la práctica, por supuesto, esto es imposible, ya que los nodos se organizan dentro de “localidades” con algunos nodos que actúan como puentes a otras localidades de nodos. La Figura 12.15 muestra esta arquitectura p2p descentralizada.

[[image:Screenshot_at_2012-04-23_14:53:47.png align="center"]]
Figura 12.15. p2p descentralizado

En una arquitectura descentralizada, los nodos en la red no son simplemente elementos funcionales, sino que también son interruptores de comuniaciones que pueden encaminar los datos y señales de control de un nodo a otro. Por ejemplo, supongamos que la figura 12.15 representa un sistema de gestion de documentos descentralizado. El sistema es usado por un consorcio de investigadores para compartir documentos, y cada miembro del consorcio mantiene su propio almacén de documentos. Sin embargo, cuando un documento es recuperado, el nodo que recupera ese documento también lo hace disponible para los otros nodos. Cualquiera que necesite un documento genera un comando de búsqueda que es enviado a los nodos de esa “localidad”. Estos nodos comprueban si tienen el documento y, si es así, lo devuelven al que ha hecho la petición. Si dichos nodos no tienen el documento, encaminan la búsqueda a otros nodos; cuando finalmente se encuentra el documento, el nodo puede encaminarlo de vuelta al nodo original que hizo la petición. Por lo tanto, si n1 emite una búsqueda de un documento que está almacenado en n10, esta búsqueda se encamina a través de los nodos n3, n6 y n9 hasta llegar a n10.
Esta arqutiectura descentralizada tiene ventajas obvias en tanto que es altamente redundante, y por lo tanto es tolerante a defectos y tolerante a nodos desconectados de la red. Sin embargo, existen sobrecargas obvias en el sistema ya que la misma búsqueda puede ser procesada por muchos nodos diferentes y hay una sobrecarga significativa en comunicaciones entre iguales replicadas. Un modelo de arqutiectura p2p alternativo que parte de una arquitectura p2p pura es una arquitectura semicentalizada en la que, dentro de la red, uno o más nodos actúan como servidores para facilitar las comunicaciones entre los nodos. La igura 12.16 ilustra este modelo.

[[image:Screenshot_at_2012-04-23_15:06:27.png align="center"]]
Figura 12.16 p2p semi-descentralizada

En una arquitectura semicentralizada, el papel del servidor es ayudar a establecer contacto entre iguales en la red o para coordinar los resulados de un cálculo. Por ejemplo, si la Figura 12.16 representa un sistema de mensajería instantánea, entonces los nodos de la red se comunican con el servidor (indicado por líneas discontinuas), para encontrar qué otros nodos están disponibles. Una vez que éstos son encontrados, se pueden establecer comunicaciones directas y la conexión con el servidor es innecesaria. Por lo tanto, los nodos n2, n3, n5 y n6 están en comunicación directa.
En un sistema computacional p2p en donde un cálculo que requiere un uso intensivo del procesasdor se distribuye a través de un gran número de nodos, es normal que se distingan algunos nodos cuyo papel es distribuir el trabajo a otros nodos y reunir y comprobar los resultados del cálculo.
Si bien hay sobrecargas obvias en los sistemas peer-to-peer, éstos son una aproximación mucho más eficiente para la computación interorganizacional que la aproximación basada en servicios que se comenta en la siguiente sección. Todavía hay probelmas en el uso de las aproximaciones p2p para computación interorganizacional, ya que cuestinoes tales como protección y autenticidad siguen todavía sin resolverse. Esto significa que los sistemas p2p2 son más probables de usar en sistemas de información no críticos o bien cuando ya existen relaciones de trabajo entre las organizaciones.

Arquitectura de sistemas orientados a servicios
El desarrollo de la WWW trajo consigo que las computadoras cliente tuviesen acceso a los servidores remotos situados fuera de sus propias organizaciones. Si estas organizaciones convertían su información a formato HTML, entonces ésta podía ser accedida por estas computadoras. Sin emabrgo, el acceso se realizaba solamente a través de un navegador web, y el acceso directo a los almacenes de información por otros programas no era práctico. Esto implicaba que las conexiones oportunistas entre servidores en donde, por ejemplo, un programa solicitaba información a varios catálogos, no eran posibles.
Para solucionar este problema, se propuso la noción de un servicio web. Mediante el uso de un servicio web, las organizaciones que quieren hacer accesible la información a otros programas, pueden hacerlo definiendo y publicando una interfaz de servicio web. Esta interfaz define los datos disponibles y cómo se puede acceder a ellos. De forma más general, un servicio web es una representación estándar para cualquier recurso computacional o de información que pueda ser usado por otros programas. Por lo tanto, se podría definir un servicio de recaudación de impuestos en el que los usuarios podrían rellenar sus formularios de impuestos y éstos son automáticamente comprobados y enviados a las autoridades de hacienda.
Un servicio web es una instancia de una noción más general de un servicio, la cual se define en (Lovelock et al., 1996) como:
Un acto o realización ofertada por una de las partes a otra. Si bien el proceso puede estar asociado a un producto físico, la realización es esencialmente intangible, y no se convierte normalmente en propietaria de cualquiera de los factores de la producción.
La esencia de un servicio, por lo tanto, es que la provisión de servicio es independiente de la aplicación que usa el servicio (Turnet, et al., 2003). Los proveedores de servicios pueden desarrollar servicios especializados y ofertarlos a un cierto número de usuarios de servicios desde diferentes organizaciones. Las aplicaciones pueden construirse enlazando los servicios desde varios proveedores utilizando bien un lenguaje de programación estándar o bien un lenguaje de instrumentación de servicios tal como BPEL4WS.
Existen varios modelos de servicios, desde el modelo JINI (Kumaran, 2001) pasando por los servicios web (Stal. 2002) y servicios de rejilla (Foster et al., 2002). Conceptulmente, todas ellas operan de acuerdo con el modelo mostrado en la Figura 12.7, la cual es una generalización del modelo conceptual de servicios web descrito por Kreger (Kreger, 2001). Un proveedor de servicio oferta un servicio definiendo su interfaz y definiendo la funcionalidad del servicio. Una solicitante del servicio enlaza este servicio en su aplicacion. Esto significa que la aplicación del solicitante incluye código para llamar al servicio y procesa el resultado de la llamada al servicio. Para asegurarse que el servicio puede ser accedido por usuario externos a dicho servicios, el proveedor de servicios registra una entrada en el servicio de registro que incluye información sobre el servicio y lo que hace.
[[image:Screenshot_at_2012-04-23_15:15:18.png align="center"]]
Figura 12.17 Servicio

La diferencia entre este modelo de servicios y la aproximación de objetos distribuidos para arquitecturas de sistemas distribuidos son las siguientes:
  • Los servicios pueden ofertarse por cualquier proveedor de servicio dentro o fuera de una organización. Suponiendo que éstos cumplen ciertos estándares (analizados más adelante), las organizaciones pueden crear aplicaciones integrando servicios desde varios proveedores. Por ejemplo, una compañía de fabricación puede enlazar directamente a los servicios proporcionados por sus proveedores.
  • El proveedor de servicios hace pública la información sobe el servicio para que cuaoquier usuario autorizado peuda usarlo. El proveedor de servicios y el usuario de los servicios no necesitan negociar sobre lo que el servicio hace antes de ser incorporado en un programa de aplicación.
  • Las aplicaciones pueden retrasar el enlace de los servicios hata que éstas sean desplegadas o hasta que esen en ejecución. Por lo tanto, una aplicación que usa un servicio de precios de productos (por ejemplo) podría cambiar dinámicamente los provceeedores de los servicios mientras que el sistema se está ejecutando.
  • Es posible la construcción oportunista de nuevos servicios. Un proveedor de servicios pueden reconocer nuevos servicios que sea crean enlazando servicios existentes de fromas innovadoras.
  • Los usuarios de los servicios pueden pagar por los servicios con arreglo a su uso en vez de a su provisión. Por lotanto, en lugar comprar un componente de precio elevado que se usa muy raramente, el desarrollador de la aplicación puede usar un servicio externo por el que pagará solamente cuadno sea requerido.
  • Las aplicaciones pueden hacerse más pequeñas (lo cual es importante si tienen que estar embebidas en otros dispositivos) debido a que pueden implementar el manejo de excepciones como servicios externos.
  • Las aplicaciones pueden ser reactivas y adaptar su operación de acuerdo con su entorno enlazando con diferentes servicios a mediad que cambia éste.

Estas ventajas han sucitado un gran interés en los servicio web como base para la construcción de aplicaciones distribuidas débilmente acopladas. Sin embargo, la experiencia práctica con las arquitecturas orientadas a servicios todavía es limitada, por lo que aún no conocemos las impliaciones prácticas de esta aproximación.
La reutilización del software ha sido un tema de investigación durante muchos años; todavía quedan pendientes muchas dificultades prácticas en las reutilización del software. Uno de los principales problemas ha sido que los estándares para componentes reutilizables han sido desarrollados hace relativamente poco tiempo, y varios de estos estándares están en uso. Sin embargo, la iniciativa de los servicios web ha estado guiada por estándares desde su nacimiento, y los estándares que incluyen muchos aspectos de los servicios web están desarrollándose. Los tres estándares fundamentales que pemriten la comunicación entre servicios web son:
  1. SOAP (Simple Object Access Protocol). Este protocolo define una organización para intercambio de datos estructurados entre servicios web.
  2. WSDL (Web Services Description Language). Este protocolo define cómo pueden representarse las interfaces de servicios web.
  3. UDDI (Universal Description , Discovery and Integration). Este es un estándar de búsqueda que define cómo puede organizarse la información de descirpción de servicios, usada por los solicitantes de los servicios para encontrar servicios.
Todos estos estándares se basan en XML, un lenguaje legible por los humanos y las máquinas. Sin embargo, no es necesario conocer detalles de estos estándares para comprender el concepto de servicios web.
Las arquitecturas de aplicaciones de servicios web son arquitecturas débilmente acopladas en donde el enlace a los servicios puede cambiar durante la ejecución. Algunos sistemas se construirán solamaete usando servicios web y otros mezclarán servicios web desarrollados localmente. Para ilustrar cómo pueden organizarse las aplicaciones, considere la siguiente situación:

Un sistema de información en un vehículo proporciona dispositivos con información sobre el tiempo, condiciones del tráfico de carretera, informacion local y otras. Este se enlaza con la radio del vehículo para que la información sea proporcionada como una señal sobre un canal de radio específico. El vehículo es equipado con un receptor de GPS para descubrir su posicion y, basándose en esa posición el sistema accede a un cierto número de servicios de información. La información puede proporcionarse en el lengauje especificado del dispositivo.
[[image:Screenshot_at_2012-04-23_15:29:42.png align="center"]]


Figura 12.18 Ejemplo

La figura 12.18 ilustra una posible organización para el sistema anterior. El software del vehículo incluye cinco módulos. Estos gestionan las comuniaciones con el dispositivo, con un receptor GPS que informa de la posición del vehículo y con la radio del vehículo. Los módulos Transmisor y Receptor gestionan todas las comuniaciones con los servicios externos.
El vehículo se comunica con un servicio de información móvil proporcinado externamente que añade información desde otros servicios que proporcionan información sobre el tiempo, tráfico y facilidades locales. Diferentes proveedores en distintos lugares proporcionan este servicios, y el sistema software del vehículo usa un servicio de búsqueda para localizar el servicio de información adecuado y enlazar con él. El servicio de búsqueda también es usado por el servicio de información móvil para enlazar con los servicios adecuados de tiempo, tráfico y facilidades. Los servicios intercambian mensajes SOAP que incluyen la información de la posición GPS usada, para seleccionar la información adecuada. La información añadida se devuelve al vehículo a través de un servicio que traduce el lenguaje de información al lenguaje de del dispositivo.
Este ejemplo ilustra una de las ventajas clave de la aproximación orientada a servicios. No es necesario decidir cuándo se programa o despliega el sistema, qué suministrador de servicio debería usarse y a qué servicios específicos se debería acceder. A medida que el vehículo se mueve, el software del vehículo usa el servicio de búsqueda para encontrar el servicio de información más adecuado y enlazar con él. Debido al uso de un servicio de traducción, la información puede traspasar los límites locales y, por lo tanto, hacer que la información local esté disponible para gente que no hable el lenguaje local.
Esta visión de computación orientada a servicios todavía no es realizable con los actuales servicios web, en los que el enlazado de servicios a las aplicaciones todavía es bastante estático. No hay duda de que el modelo orientado a servicios representa una forma nueva muy importante de implementar los sistemas de computación distribuidos interorganizacionales.