1

Sistemas Distribuidos - Middleware

Luis Ángel Benavides MoraUniversidad Autónoma del Caribe

luisbenavides25@outlook.com

Resumen— En este documento se va a desplegar la información sobre los sistemas distribuidos de tipo Middleware y sus diferentes componentes tales como los sockets, RMI, Web Service, RCP, entre otros. También veremos cómo ha avanzado en la actualidad desde su comienzo y los avances más importantes que este tiene.

Palabras Claves— Web, Cliente, Servidor, RPC, Java, RMI, HTTP, XML, Sockets.

I. INTRODUCCIÓN

Los sistemas distribuidos de tiempo real son cada vez más importantes para la sociedad. Su demanda aumenta y se depende de los servicios que proporcionan. Los sistemas de alta integridad constituyen un subconjunto de gran importancia. Se caracterizan por que un fallo en su funcionamiento puede causar la pérdidas de vidas humanas, daños en el medio ambiente o cuantiosas pérdidas económicas. La necesidad de satisfacer requisitos temporales estrictos, hace más complejo su desarrollo. Mientras que los sistemas empotrados se expandan en nuestra sociedad, es necesario garantizar un coste de desarrollo ajustado mediante el uso técnicas adecuadas en su diseño, mantenimiento y certificación. En concreto, se requiere una tecnología flexible e independiente del hardware.

Middleware o lógica de intercambio de información entre aplicaciones ("interlogical") es un software que asiste a una aplicación para interactuar o comunicarse con otras aplicaciones, o paquetes de programas, redes, hardware y/o sistemas operativos. Éste simplifica el trabajo de los programadores en la compleja tarea de generar las conexiones y sincronizaciones que son necesarias en los sistemas distribuidos. De esta forma, se provee una solución que mejora la calidad de servicio, así como la seguridad, el envío de mensajes, la actualización del directorio de servicio, etc.

De todas maneras el término ha sido usado desde 1968. También facilitaba el procesamiento distribuido: conexión de múltiples aplicaciones para crear una aplicación más grande, generalmente sobre una red.

II.MIDDLEWARE

El origen de la palabra middleware se remonta al año 1968, en donde la palabra fue usada durante la '1968 NATO Software Engineering Conference',2 siendo una idea de cómo conectar el nuevo software con sistemas más antiguos. Durante las décadas previas a los 90s, fue solamente descrito como un software para la gestión de conexión en redes, pero para cuando las tecnologías en redes alcanzaron una penetración y visibilidad suficiente, el software middleware' había evolucionado en un conjunto de paradigmas y servicios.

De esta forma se estaba ofreciendo una manera más fácil, robusta y controlable, para construir aplicaciones distribuidas. El tipo de integración que incluyen posee la capacidad de unirse con sistemas heterogéneos. Cada middleware posee diferentes protocolos de comunicación o formas de operar en diferente software. Los tipos de integración se pueden ver como:

Orientados a procedimiento o procesos: Los middleware que son orientados a procesos, utilizan una comunicación sincronizada (como por ejemplo el teléfono). Una de las características de estos, es que utilizan el client stub y el server skeleton.

Orientados a objetos: Soportan pedidos de objetos distribuidos. La comunicación entre los objetos puede ser sincronizada, sincronizada diferida o no sincronizada. Soportan múltiples pedidos similares realizados por múltiples clientes en una transacción. La forma de operar es:1. El objeto cliente llama a un método lógico para obtener un

objeto remoto.2. Un ORB Proxy (también conocido como stub) pone en

orden la información y la transmite a través del agente (broker).

3. El agente actúa como punto medio y contacta con diversas fuentes de información, obtiene sus referentes IDs, recolecta información y, en ocasiones, la reorganiza.

4. El proxy remoto (también conocido como skeleton) desordena la información que le llega del agente y se la pasa al objeto servidor.

5. El objeto servidor procesa la información y genera un resultado que es devuelto al cliente siguiendo los pasos inversos.

2

Orientados a mensajes (MOM, Message-oriented middleware): Se pueden dividir en dos tipos, espera y publicación/suscripción. El paso de espera se puede dividir en mensaje y espera. El paso de mensaje inicia con que la aplicación envía un mensaje a uno o más clientes, con el MOM del cliente. El servidor MOM, recoge las peticiones de la cola (Message Broker) en un orden o sistema de espera predeterminado. Los actos del servidor MOM son como un router y usualmente no interactúan con estas.

Orientados a componentes: En este caso, un componente es un programa que realiza una función específica, diseñada para operar e interactuar fácilmente con otros componentes y aplicaciones. El middleware en este caso en una configuración de componentes. Los puntos fuertes de este middleware es que es configurable y reconfigurable. La reconfiguración se puede realizar en tiempo de ejecución, lo que ofrece una gran flexibilidad para satisfacer las necesidades de un gran número de aplicaciones.

Agentes: Los agentes son un tipo de middleware que posee varios componentes:1. Entidades: Pueden ser objetos o procesos.2. Medios de comunicación: Pueden ser canales,

tuberías, etc.3. Leyes: Identifican la naturaleza interactiva de los

agentes. Pueden ser la sincronización o el tipo de esquema.

Las ventajas de los middleware agentes son que la capacidad de éstos para realizar una gran cantidad de tareas en nombre del usuario y para cubrir una amplia gama de estrategias basadas en el entorno que les rodea. Sin embargo su implementación es complicada debido a la complejidad y dificultades dadas por las operaciones que manejan.

III. SOCKETS

Un socket, es un método para la comunicación entre un programa del cliente y un programa del servidor en una red. Un socket se define como el punto final en una conexión. Los sockets se crean y se utilizan con un sistema de peticiones o de llamadas de función a veces llamados interfaz de programación de aplicación de sockets (API, application programming interface).

Un socket es también una dirección de Internet, combinando una dirección IP (la dirección numérica única de cuatro partes que identifica a un ordenador particular en Internet) y un número de puerto (el número que identifica una aplicación de Internet particular, como FTP, Gopher, o WWW).

Las propiedades de un socket dependen de las características del protocolo en el que se implementan. El protocolo más utilizado es Transmission Control Protocol; una alternativa común a éste es User Datagram Protocol.

Cuando se implementan con el protocolo TCP, los sockets tienen las siguientes propiedades: Son orientados a la conexión. Se garantiza la transmisión de todos los octetos sin

errores ni omisiones. Se garantiza que todo octeto llegará a su destino en el

mismo orden en que se ha transmitido.

Estas propiedades son muy importantes para garantizar la corrección de los programas que tratan la información.

El protocolo UDP es un protocolo no orientado a la conexión. Sólo se garantiza que si un mensaje llega, llegue bien. En ningún caso se garantiza que llegue o que lleguen todos los mensajes en el mismo orden que se mandaron. Esto lo hace adecuado para el envío de mensajes frecuentes pero no demasiado importantes, como por ejemplo, un streaming de audio.

En los orígenes de Internet, las primeras computadoras en implementar sus protocolos fueron aquellas de la Universidad de Berkeley. Dicha implementación tuvo lugar en una variante del sistema operativo Unix conocida como BSD Unix. Pronto se hizo evidente que los programadores necesitarían un medio sencillo y eficaz para escribir programas capaces de intercomunicarse entre sí.

Esta necesidad dio origen a la primera especificación e implementación de sockets, también en Unix. Hoy día, los sockets están implementados como bibliotecas de programación para multitud de sistemas operativos, simplificando la tarea de los programadores.

La interfaz socket se diferencia por los servicios distintos que proporciona. Flujo, datagrama, y raw sockets cada uno de ellos define un servicio distinto disponible para aplicaciones.

Interfaz socket de flujo (SOCK_STREAM): Define un servicio orientado a conexión confiable (sobre TCP por ejemplo). Los datos se envían sin errores o duplicación y se reciben en el mismo orden de cómo fueron enviados. El control de flujo está integrado para evitar overruns.

Interfaz socket de datagrama (SOCK_DGRAM): Define un servicio no orientado a conexión (sobre UDP por ejemplo). Los datagramas se envían como paquetes independientes. El servicio no proporciona garantías; los datos se pueden perder o duplicar y los datagramas pueden llegar fuera de orden.

Interfaz socket raw (SOCK_RAW): Permite acceso directo a protocolos de capas más bajas tales como IP e ICMP. Esta interfaz se utiliza a menudo para comprobar nuevas implementaciones de protocolos. Ejemplo de aplicación que use sockets raw es la orden ping.

3

IV. RMI.

RMI es el modelo de objetos distribuidos de Java que permite invocar un método de un objeto que estás obre otra máquina virtual. Su principal propósito es permitir el desarrollo de aplicaciones distribuidas con el mismo modelo de programación que en sistemas centralizados. RMI es una infraestructura poderosa para la construcción de aplicaciones distribuidas cliente - servidor. RMI emplea TCP / IP y serialización de objetos para serializar y deserializar los argumentos y valor de retorno de los métodos remotos. También utiliza los protocolos http y ftp para el intercambio de clases.

El servidor crea un conjunto de objetos remotos, los hace accesibles, y espera por los clientes. Normalmente, el cliente recibe una o más referencias remotas a los objetos en el servidor mediante un registro que almacena par de referencia remota - objeto remoto. Con las referencias el cliente llama a los métodos que se encuentran en el servidor. El cliente, el servidor y el registro forman la aplicación de objetos distribuidos, y RMI es el middleware que proporciona servicios para el desarrollo de aplicaciones de objetos distribuidos.

RMI es adecuado para sistemas distribuidos de tiempo real crítico dado que provee la funcionalidad requerida y puede ser analizable. Java RMI presenta algunas limitaciones en sistemas de tiempo real:

El uso de tecnologías tales como: reflexión, características OO y recursividad hacen que sea muy difícil estimar el WCET y el uso de recursos.

El modelo de memoria no es apropiado. Las hebras, las conexiones, los objetos remotos, etc. se crean dentro del montículo. Por lo tanto, la ejecución de las invocaciones remotas sufren los efectos del recolector de basura y los objetos se crean de forma dinámica.

En las actuales implementaciones de RMI las conexiones se generan de forma dinámica. Cuando un cliente quiere enviar una invocación, primero crea una nueva conexión con el servidor. Es difícil estimar el tiempo y los recursos son necesarios para establecer la conexión.

Implementaciones de RMI (por ejemplo, GNU Classpath) crean hebras dinámicamente, lo que no es adecuado en sistemas de tiempo real crítico.

Uso de algoritmos de serialización no predecibles.

El uso de recursos es completamente transparente, y por lo tanto no es configurable. RMI no permite al programador especificar los parámetros de red. En RMI no se ha teniendo en cuenta los parámetros de tiempo real.

RMI no garantiza una calidad de servicio.

V. WEB SERVICE.

Un servicio web (en inglés, Web Service o Web services) es una tecnología que utiliza un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes de ordenadores como Internet. La interoperabilidad se consigue mediante la adopción de estándares abiertos.

Las organizaciones OASIS y W3C son los comités responsables de la arquitectura y reglamentación de los servicios Web. Para mejorar la interoperabilidad entre distintas implementaciones de servicios Web se ha creado el organismo WS-I, encargado de desarrollar diversos perfiles para definir de manera más exhaustiva estos estándares. Es una máquina que atiende las peticiones de los clientes web y les envía los recursos solicitados.

Ventajas. Aportan interoperabilidad entre aplicaciones de

software independientemente de sus propiedades o de las plataformas sobre las que se instalen.

Los servicios Web fomentan los estándares y protocolos basados en texto, que hacen más fácil acceder a su contenido y entender su funcionamiento.

Permiten que servicios y software de diferentes compañías ubicadas en diferentes lugares geográficos puedan ser combinados fácilmente para proveer servicios integrados.

Inconvenientes. Para realizar transacciones no pueden compararse en

su grado de desarrollo con los estándares abiertos de computación distribuida como CORBA (Common Object Request Broker Architecture).

Su rendimiento es bajo si se compara con otros modelos de computación distribuida, tales como RMI (Remote Method Invocation), CORBA o DCOM (Distributed Component Object Model). Es uno de los inconvenientes derivados de adoptar un formato basado en texto. Y es que entre los objetivos de XML no se encuentra la concisión ni la eficacia de procesamiento.

Al apoyarse en HTTP, pueden esquivar medidas de seguridad basadas en firewall cuyas reglas tratan de bloquear o auditar la comunicación entre programas a ambos lados de la barrera.

4

La principal razón para usar servicios Web es que se pueden utilizar con HTTP sobre TCP (Transmission Control Protocol) en el puerto 80.

Dado que las organizaciones protegen sus redes mediante firewalls -que filtran y bloquean gran parte del tráfico de Internet-, cierran casi todos los puertos TCP salvo el 80, que es, precisamente, el que usan los navegadores. Los servicios Web utilizan este puerto, por la simple razón de que no resultan bloqueados.

Otra razón es que, antes de que existiera SOAP, no había buenas interfaces para acceder a las funcionalidades de otros ordenadores en red. Las que había eran ad hoc y poco conocidas, tales como EDI (Electronic Data Interchange), RPC (Remote Procedure Call), u otras APIs.

Una tercera razón por la que los servicios Web son muy prácticos es que pueden aportar gran independencia entre la aplicación que usa el servicio Web y el propio servicio. De esta forma, los cambios a lo largo del tiempo en uno no deben afectar al otro. Esta flexibilidad será cada vez más importante, dado que la tendencia a construir grandes aplicaciones a partir de componentes distribuidos más pequeños es cada día más utilizada.

Se espera que para los próximos años mejoren la calidad y cantidad de servicios ofrecidos basados en los nuevos estándares.

VI. RPC.

La Llamada a Procedimiento Remoto (del inglés, Remote Procedure Call, RPC) es un protocolo de red que permite a un programa de computadora ejecutar código en otra máquina remota sin tener que preocuparse por las comunicaciones entre ambas. El protocolo es un gran avance sobre los sockets de Internet usados hasta el momento. De esta manera el programador no tenía que estar pendiente de las comunicaciones, estando estas encapsuladas dentro de las RPC.

Las RPC son muy utilizadas dentro de la comunicación cliente-servidor. Siendo el cliente el que inicia el proceso solicitando al servidor que ejecute cierto procedimiento o función y enviando este de vuelta el resultado de dicha operación al cliente. Hoy en día se está utilizando el XML como lenguaje para definir el IDL y el HTTP como protocolo de red, dando lugar a lo que se conoce como servicios web. Ejemplos de estos pueden ser SOAP o XML-RPC.

Tipos.Hay distintos tipos de RPC, muchos de ellos estandarizados

como pueden ser el RPC de Sun denominado ONC RPC (RFC 1057), el RPC de Open Software Foundation (OSF) denominado DCE/RPC y el "Modelo de Objetos de Componentes Distribuidos de Microsoft" (Distributed Component Object Model, DCOM), aunque ninguno de estos es compatible entre sí. La mayoría de ellos utilizan un lenguaje de descripción de interfaz (Interface description

language o IDL) que define los métodos exportados por el servidor.

ONC RPC: ONC RPC, abreviación del inglés Open Network Computing Remote Procedure Call, es un protocolo de llamada a procedimiento remoto (RPC) desarrollado por el grupo ONC de Sun Microsystems como parte del proyecto de su sistema de archivos de Red NFS, algunas veces se lo denomina Sun ONC o Sun RPC. Trabaja sobre los protocolos TCP y UDP.

OSF (DCE/RPC): DCE Remote Procedure Call o bien DCE RPC es un sistema de llamada a procedimiento remoto del conjunto de software OSF DCE. DCE / RPC, la abreviatura de "Distributed Computing Environment / Remote Procedure Calls ", es el sistema de llamada a procedimiento remoto desarrollado para el entorno de la informática distribuida (DCE). Este sistema permite a los programadores escribir software distribuido como si fuera todos los que trabajan en el mismo equipo, sin tener que preocuparse por el código de red subyacente.

DCOM: El Modelo de Objetos de Componentes Distribuidos (Distributed Component Object Model, DCOM) es una tecnología propietaria de Microsoft para desarrollar componentes de software distribuidos sobre varias computadoras y que se comunican entre sí. Extiende el modelo Component Object Model (COM) de Microsoft y proporciona el sustrato de comunicación entre la infraestructura del servidor de aplicaciones COM+ de Microsoft.

Tipos de semántica.

VII. CONCLUSIONES.

Este trabajo identifica la necesidad de un middleware que permita a la tecnología Java desarrollar sistemas distribuidos de tiempo real crítico. RMI proporciona esta funcionalidad y permite la evaluación estática de los tiempos de respuesta de extremo a extremo. Las contribuciones más destacadas:

Separación de la asignación de los recursos de la ejecución: Se separa la asignación de los recursos de la ejecución para mejorar. En una fase de inicialización, todos los recursos necesarios para la siguiente fase se crean y todas las operaciones no deterministas (como la creación de conexiones) se llevan a cabo. En la fase de misión, las invocaciones remotas se realizan con los recursos asignados.

5

Referencia remotas asociadas a recursos y parámetros: Cada referencia se asocia a un conjunto específico de recursos (objetos panificables, memoria, red).

Invocaciones síncronas y asíncronas: Gestiona el modo de invocación síncrona y asíncrona. La aplicación puede elegir si el cliente tiene que esperar por una respuesta o no.

Independencia del protocolo de red: Se aísla la parte dependiente de la red. Se define una interfaz clara que permite al middleware operar sin conocer detalles del protocolo subyacente.

Serializacion predecible: Los objetos son transformados en un modo predecible.

VIII.REFERENCIAS.

Definición de Middleware http://www.alegsa.com.ar/Dic/middleware.php

Middleware -https://es.wikipedia.org/wiki/Middleware

El Middleware - https://iarmenta.wordpress.com/2009/08/24/el-middleware/#_Toc231023775

¿Qué es un socket? - https://www.masadelante.com/faqs/socket

Diferencias de Sockets - http://www.ibiblio.org/pub/linux/docs/LuCaS/Tutoriales/PROG-SOCKETS/prog-sockets/x31.html

Java Remote Method Invocation - https://es.wikipedia.org/wiki/Java_Remote_Method_Invocation

Remote Method Invocation Home - http://www.oracle.com/technetwork/articles/javaee/index-jsp-136424.html

Web Service - http://searchsoa.techtarget.com/definition/Web-services

Llamada a Procedimiento Remoto - https://es.wikipedia.org/wiki/Llamada_a_Procedimiento_Remoto