Revisión de los Sistemas de Comunicaciones más empleados en Control Distribuido

Revisión de los Sistemas de Comunicaciones más empleados en Control Distribuido Autor: José Luis Poza Luján Revisores: José Enrique Simó Ten Juan Luis Posadas Yagüe Instituto de Automática e Informática Industrial (ai2) Universidad Politécnica de Valencia (UPV) Versión: 0.4 Fecha revisión: 10 de noviembre de 2009 Sistemas de comunicaciones 3 de 38 Contenidos 1 Introducción............................................................................................................. 5 1.1 Resumen...................................................................................................................... 5 1.2 Historial de revisiones ............................................................................................... 5 1.3 Objetivos del documento........................................................................................... 5 1.4 Alcance y audiencia ................................................................................................... 5 1.5 Organización del documento .................................................................................... 5 2 Sistemas distribuidos ............................................................................................... 6 2.1 Características............................................................................................................ 6 2.2 El papel de la calidad de servicio.............................................................................. 8 3 Sistemas de comunicaciones ................................................................................... 9 3.1 Paradigmas de comunicación ................................................................................. 10 3.1.1 Paso de mensajes ................................................................................................................10 3.1.2 Cliente – Servidor...............................................................................................................10 3.1.3 Sistemas de mensajería.......................................................................................................12 3.1.4 Transmisión de código........................................................................................................12 3.2 Modelos de sistemas de comunicaciones................................................................ 13 3.2.1 TCX....................................................................................................................................13 3.2.2 IPT......................................................................................................................................14 3.2.3 RTC ....................................................................................................................................14 3.2.4 IPC......................................................................................................................................15 3.2.5 NML ...................................................................................................................................16 3.2.6 MPI.....................................................................................................................................16 3.2.7 ACE....................................................................................................................................16 3.2.8 CORBA ..............................................................................................................................17 3.2.9 DDS....................................................................................................................................19 3.2.10 MSMQ ...........................................................................................................................20 3.2.11 JMS................................................................................................................................22 3.2.12 MidArt ...........................................................................................................................24 3.2.13 Jini .................................................................................................................................24 3.2.14 DCE ...............................................................................................................................25 3.2.15 El caso Microsoft: DDE, OLE, COM, DCOM y .NET .................................................26 3.2.16 AMPQ............................................................................................................................27 4 Conclusiones.......................................................................................................... 28 4.1 Una visión global...................................................................................................... 28 4.2 Contextualización temporal de los modelos de comunicación............................. 29 4.3 Características de los modelos................................................................................ 30 4.4 Posibles áreas de investigación ............................................................................... 32 5 Referencias............................................................................................................. 33 6 ANEXO: Sistemas de comunicaciones analizados............................................... 37 Sistemas de comunicaciones 4 de 38 Figuras Figura 1. Necesidad de las políticas de QoS en un sistema distribuido.......................................................8 Figura 2. Paradigmas de comunicación en función del movimiento de datos y de código.........................9 Figura 3. Modelos de comunicaciones basados en paso de mensajes. ......................................................10 Figura 4. Arquitectura de comunicaciones IPT. ........................................................................................14 Figura 5. Arquitectura de comunicaciones RTC........................................................................................15 Figura 6. Arquitectura de comunicaciones IPC.........................................................................................15 Figura 7. Arquitectura de comunicaciones NML.......................................................................................16 Figura 8. Arquitectura de comunicaciones CORBA. .................................................................................18 Figura 9. Arquitectura de comunicaciones DDS. ......................................................................................19 Figura 10. Arquitectura de comunicaciones MSMQ..................................................................................21 Figura 11. Arquitectura de comunicaciones JMS. .....................................................................................22 Figura 12. Evolución comparativa de las arquitecturas de Microsoft.......................................................26 Figura 13. Esquema básico de AMPQ. ......................................................................................................27 Figura 14. Ubicación diferentes tecnologías en función del tipo de comunicación que implementan.......29 Figura 15. Ubicación diferentes tecnologías en función de los aspectos de tiempo real que cubren. .......30 Tablas Tabla 1. Tipo de comunicación en función del contenido que se transmite. ...............................................9 Sistemas de comunicaciones 5 de 38 1 Introducción 1.1 Resumen Los sistemas distribuidos basan su funcionamiento en la posibilidad de comunicación entre sus componentes. El sistema de comunicaciones cubre aspectos de diversa complejidad, ya que incluye cuestiones que van desde la conexión y direccionamiento de los mensajes hasta el formato en que se transmite el contenido de los mismos. En este documento se realiza una revisión de los sistemas de comunicaciones que dan soporte a la distribución de componentes de los sistemas distribuidos. La revisión se ha planteado desde dos puntos de vista: el de los aspectos teóricos de los paradigmas clásicos de comunicación y el de la visión práctica de los sistemas actuales de comunicación. El documento expone los sistemas separadamente para posteriormente unirlos conceptualmente y analizarlos desde una perspectiva global. 1.2 Historial de revisiones Nº revisión Fecha Comentarios 0.0 2007-02 Inicio del documento 0.1 2007-04 Separación del modelo DCPS de DDS en documento aparte. 0.2 2008-02 Final de revisión de los paradigmas de comunicación 0.3 2008-03 Separación de la calidad de servicio como documento aparte. 0.4 2009-07 Revisión global del documento. 1.3 Objetivos del documento El objetivo principal del documento es realizar un análisis de los sistemas de comunicaciones más empleados, sin dejar de lado aquellos que por su especial interés deban ser revisados, para así poder extraer las características más destacables y poder aplicarlas en la elección del modelo de comunicaciones más adecuado a un sistema de control distribuido. 1.4 Alcance y audiencia El documento cubre los sistemas de comunicaciones más empleados y conocidos en la actualidad, sin entrar en los detalles técnicos de implementación, ya que se trata de ofrecer una visión global de los mismos. El documento será de utilidad a diseñadores de sistemas distribuidos. 1.5 Organización del documento El documento se inicia con una breve revisión sobre las características de los sistemas distribuidos y el papel de la calidad de servicio en los mismos, ya que es uno de los conceptos que van adquiriendo más importancia. En el capítulo 3 se revisan los sistemas de comunicaciones. Inicialmente se revisarán los paradigmas de comunicaciones, para continuar revisando los sistemas de comunicaciones más relevantes. En el capítulo 4 se dan las conclusiones analizando los sistemas de comunicaciones revisados en el capítulo anterior por medio de una contextualización de los mismos y con una revisión de las características más deseables. Sistemas de comunicaciones 6 de 38 2 Sistemas distribuidos Un sistema distribuido se define como aquel en que los componentes localizados en computadores, conectados en red, comunican y coordinan sus acciones únicamente mediante el paso de mensajes [Coulouris et al., 2001]. Es habitual que los sistemas distribuidos se caractericen por la concurrencia de los componentes, la ausencia de un reloj común y la independencia en los fallos. La concurrencia permite que los recursos disponibles, incluidos los propios componentes, puedan ser utilizados simultáneamente. La ausencia de de un reloj común, o global, se debe a que la transferencia de mensajes entre los componentes no tienen una base temporal común sino que el factor temporal está distribuida entre los componentes. Finalmente el aislado de los fallos de los componentes implica que cada componente debe tener una independencia con respecto al resto de manera que pueda seguir funcionando aunque otro componente no se encuentre disponible. Esto último se puede matizar en la medida en que un componente dependa de otro para su funcionamiento. La coordinación de los componentes de un sistema distribuido se debe realizar para lograr varios objetivos para los que dichos componentes son necesarios. Para alcanzar dichos objetivos, los componentes deber realizar diversas tareas de manera independiente y servirse concurrentemente de los recursos que tienen a su disposición. La comunicación entre componentes obliga a que exista un intercambio de información entre los mismos. Este intercambio de información se debe realizar a través de los medios de comunicación que el sistema distribuido proporciona a cada componente y además implicará una topología de las comunicaciones. El acceso de los componentes a los medios de comunicación disponibles obliga a la existencia de uno o varios protocolos de comunicaciones, que forzosamente deberán conocer los componentes que se comuniquen a través de los mismos. El intercambio de información entre componentes supondrá que deberá existir una manera de enviar la información de manera que sea comprensible por los componentes implicados en el intercambio. Consecuentemente el contenido de los mensajes deberá disponer de un lenguaje, o al menos unas normas conocidas por los agentes que intervengan en el proceso de intercambio de información. La existencia de un lenguaje, supone la existencia de una gramática y consiguiente de una sintaxis. Estos aspectos del lenguaje de intercambio de información deberán ser tenidos en cuenta a la hora de diseñar un sistema distribuido y de intentar lograr un alto grado de estandarización del mismo [FIPA, 1997]. 2.1 Características Un sistema distribuido puede tener muchas propiedades deseables, estas enriquecerán el sistema de manera que lo hagan más eficiente. Entre las propiedades deseables de un sistema distribuido se pueden destacar las siguientes [Coulouris et al., 2001]. • Heterogeneidad. Se entiende como la variedad y la diferenciación de los componentes de un sistema distribuido. Generalmente la variación de los diversos componentes de un sistema justifica la creación de estándares que permitan a los componentes conocer las reglas de funcionamiento con un esfuerzo mínimo de adaptación. Sistemas de comunicaciones 7 de 38 • Extensibilidad. Este concepto es similar en algunos casos a la compatibilidad que el sistema puede ofrecer a nuevos componentes. La extensibilidad del sistema también justifica el uso de estándares, cuanto menos las “normas” del sistema deben ser conocidas por los componentes. También suele hablarse de sistemas abiertos cuando se refiere a sistemas extensibles. • Seguridad. Actualmente, es una de las propiedades que proporciona mayor valía a un sistema distribuido. Sobre seguridad hay tres aspectos que son importantes tener en cuenta: disponibilidad, confidencialidad e integridad. La disponibilidad se refiere a que los recursos del sistema están accesibles para aquellos componentes que lo requieran, en el instante en que sea necesario. Confidencialidad es la protección que el sistema proporciona para no ser accesible por componentes no autorizados. Asimismo la confidencialidad debe proporcionar la suficiente seguridad a un componente, que los componentes con los que está trabajando son realmente los que él requería para trabajar, es decir, además de evitar la intrusión, un sistema confiable debe proporcionar suficientes garantías para evitar la suplantación. Finalmente la integridad se refiere a la protección que el sistema suministra contra la alteración, ya sea accidental como provocada, de los datos que circulan por el sistema. • Escalabilidad. Un sistema distribuido es escalable en la medida en que se pueden aumentar sus componentes si que esto conlleve una pérdida de efectividad debida a los cambios. El objetivo final de un sistema, con respecto a la escalabilidad, es que apenas deben realizarse cambios en el mismo pese al aumento de los componentes. Normalmente es un gran logro que un sistema que se adapta a las necesidades de los componentes cuando la cantidad de estos cambia, no requiera de modificaciones. • Soporte a fallos. Los componentes de un sistema distribuido pueden fallar y es normal que esos fallos antes o después se produzcan. Un fallo en uno o varios componentes hará que el resultado del sistema sea diferente o de menor calidad que el esperado, por ello la prevención y tratamiento de los fallos es un aspecto que deberá tener muy en cuenta un sistema distribuido. Algunas características que deben tener los sistemas distribuidos con respecto a los fallos son la detección, el enmascaramiento, la tolerancia y la recuperación. La detección del fallo debe realizarse lo antes posible para evitar que los errores en el procesamiento tengan consecuencias colaterales en el resto de los componentes. Una vez detectado el fallo, éste debe enmascararse o atenuarse, es decir que aunque el fallo es conocido, los componentes no se ven afectados. La tolerancia a fallos implica que los componentes conozcan el fallo y reaccionen frente al mismo de una manera conocida y controlada. Finalmente la recuperación es la fase en la que el sistema, una vez solucionado el fallo, vuelve a funcionar según los requerimientos. • Concurrencia. La concurrencia es la capacidad que tiene un sistema para que un recurso, pueda ser utilizado simultáneamente. Realmente la simultaneidad puede no ser completa, sino a efectos de los componentes que acceden al recurso. La concurrencia supondrá el uso de diversas estrategias de acceso al recurso con el objetivo de mantener la integridad de la información. • Transparencia. La transparencia de un sistema es la ocultación al usuario de los detalles que son propios de la gestión interna del sistema. De esta manera, los usuarios de un sistema no lo perciben con más detalles que el estrictamente Sistemas de comunicaciones 8 de 38 necesario. La transparencia se logra de diversas maneras, pero fundamentalmente a partir del encapsulado de componentes y del uso de interfaces. A medida que un sistema distribuido de soporte a las propiedades anteriores sus componentes, y consiguientemente el sistema en su conjunto verán aumentada su eficiencia e incrementado su valor. Para poder proporcionar estas características, se deberá realizar un esfuerzo considerable, tanto en el diseño, como en la monitorización, gestión y control del sistema, por lo que estos aspectos deberán ser tratados con especial atención en el desarrollo del sistema. 2.2 El papel de la calidad de servicio Para lograr que un sistema distribuido cumpla unos requisitos adecuados, o lo que es lo mismo, que logre cumplir las características que se le requieren, es necesario determinar unos parámetros en los que basar las características. Estos parámetros, deben ser mesurables y representativos. En los sistemas distribuidos basados en componentes que ofrecen unos servicios a las aplicaciones que sobre ellos funcionan, los parámetros que se miden y permiten determinar el buen funcionamiento del sistema, se conocen como parámetros de calidad de servicio, se pueden observar en la figura 1. Figura 1. Necesidad de las políticas de QoS en un sistema distribuido. Los parámetros de calidad de servicio proporcionan un medio por el que poder tomar decisiones acerca de los componentes, y de los mismos servicios, del sistema. Para poder cumplir esos requisitos se debe gestionar los parámetros entre los componentes. La gestión, incluida la negociación, de los parámetros de calidad de servicio entre los componentes se realiza por medio de políticas de calidad de servicio. Sistemas de comunicaciones 9 de 38 3 Sistemas de comunicaciones La topología de las conexiones en las comunicaciones se refiere a cómo se conectan los componentes que se van a comunicar. Desde este punto de vista se pueden distinguir diversos modelos, tal como se describe en [Liu, 2004]. Para determinar el correcto ámbito en el que se puede ubicar cada uno de los paradigmas de comunicaciones, se puede atender al contenido que es comunicado, que puede ser datos, código o ambas cosas. En la tabla 1, se puede ver esta organización. Tabla 1. Tipo de comunicación en función del contenido que se transmite. Contenido de la comunicación Datos Código Tipo de comunicación No No No existe comunicación. No hay transferencia de información, consecuentemente no es un paradigma de comunicación. Sí No Comunicación clásica. El código del emisor envía la información al receptor por medio de los datos que el código del receptor procesará. No Sí Código móvil. El emisor transfiere código al receptor, generalmente posteriormente se transfieren los datos a procesar. Sí Sí Movimiento de componentes. Se transfiere el código y los datos con los que trabajar, por lo que normalmente se entiende como movimiento de procesos. Los paradigmas de comunicación que se presentan en [Liu, 2004] se pueden organizar en función del contenido en los tres grupos anteriores. El más importante es el de las comunicaciones únicas de datos, donde se pueden ubicar prácticamente todos los paradigmas clásicos de comunicación. Figura 2. Paradigmas de comunicación en función del movimiento de datos y de código. Cuando el contenido de los datos es código, entonces se pasa a hablar de movilidad. La transferencia de código precisa del soporte de comunicaciones de los paradigmas anteriores, y adicionalmente la infraestructura necesaria para la ejecución del código. En la figura 2, se puede observar la clasificación de los paradigmas más importantes de comunicaciones en función de la organización anterior. Sistemas de comunicaciones 16 de 38 IPC es una librería que requiere un servidor central al que suscribirse los módulos de comunicación de los procesos que requieren recibir los mensajes a los que se han suscrito. Además se tiene un módulo de control con diferentes funcionalidades entre las que se encuentran las de sincronización temporal, envío de mensajes para sincronización de tareas de tiempos limitados y similares. 3.2.5 NML NML (Neutral Messaging Language) es un paquete de servicios de comunicaciones basado en la información [Shackleford et al., 2000]. Está diseñado en el National Institute of Standards and Technology (NIST). En la figura 7, pueden verse los componentes básicos de funcionamiento. El componente principal es un buffer de memoria compartida, en la que los productores de información escriben sus datos y los consumidores los leen. Figura 7. Arquitectura de comunicaciones NML. En los casos en los que es posible, se emplea la tecnología de memoria compartida, mientras que si se debe realizar la transferencia de información a través de una red, se debe emplear un servidor que gestiona las lecturas y escrituras. Inicialmente se ha desarrollado para las comunicaciones entre robots basados en mensajes síncronos, aunque también tiene un soporte a los mensajes asíncronos. Actualmente se emplea en la arquitectura NASREM. El sistema permite cambios en la configuración, pero no mientras está realizando transferencias. 3.2.6 MPI Message Passing Interface (MPI) o Interfaz de Paso de Mensajes, es un protocolo estándar de paso de mensajes para ser utilizado entre procesadores con el objetivo de realizar procesamiento paralelo. El protocolo se ha extendido a otros ámbitos aparte del interior de los computadores. Se debe destacar que MPI no define una arquitectura sino un protocolo de comunicación, que básicamente considera una red de nodos iguales con intercambio de mensajes entre ellos. Entre las características más relevantes de MPI están la sencillez de los métodos, el control de tiempo real y la gran extensión ya que todos los sistemas operativos suelen dar soporte a la comunicación entre procesos por medio de ésta interfaz. Se debe destacar que MPI tiene una capacidad de portabilidad y escalabilidad muy grande, desde los sistemas multiprocesadores a los sistemas distribuidos, considerando cada nodo un sistema de procesamiento que se comunica con el resto. 3.2.7 ACE ACE (Adaptive Communication Environment, es un entorno de código abierto orientado a C++ iniciado por Douglas C. Schmidt en la Universidad de California Irvine Sistemas de comunicaciones 17 de 38 [Schmidt, 1993]. De este sistema destaca el hecho de estar basado en patrones de diseño [Gamma et al, 1994]. Los patrones de diseño son patrones de soluciones aplicables a situaciones similares en la implementación de software. Uno de los objetivos principales de los patrones de diseño es ofrecer un esquema de actuación reutilizable en diferentes situaciones a lo largo del proceso de diseño del software. Los patrones de diseño en los que se basa ACE son los siguientes. Conviene revisar la bibliografía correspondiente para comprender el funcionamiento de algunos y su inclusión en un modelo de objetos distribuidos, ya que algunos no están incluidos en los 23 patrones estándares “de facto”. • Patrones de manejo de eventos (Event Handling Patterns): Reactor, AcceptorConnector, Pro-actor, Items de finalización asíncrona (Asynchronous Completion Token) • Patrones de sincronización (Synchronization Patterns): Scoped Locking, Strategized Locking, Thread-Safe Interface, Double-Checked Locking Optimization. • Patrones de concurrencia (Concurrency Patterns): Thread-Specific Storage, Monitor Object, Active Object, Half-Synch/Half-Asynch, Leader/Follower. • Patrones de servicio de acceso y configuración (Service Access and Configuration Patterns): Component Configurator, Interceptor, Extension Interface, Wrapper Facade. ACE proporciona tipos comunes de datos y de métodos, lo que hace que pueda considerarse un sistema basado en un modelo de objetos distribuidos. Proporciona una forma estandarizada para una gran cantidad de sistemas operativos que permite, entre otros aspectos, gestionar la comunicación entre procesos, gestión de “threads” y de memoria. Actualmente es empleado en multitud de proyectos comerciales de Motorola o Boeing. 3.2.8 CORBA En los paradigmas orientados a objetos, la unidad básica sobre la que se diseña el sistema es el objeto a transmitir. En los paradigmas anteriores la base del sistema era la información, sin embargo un objeto contiene la información (atributos) y unas capacidades de procesamiento (métodos). El hecho de que los objetos encapsulen la mayor parte de su funcionalidad hace que sea más sencillo invocar una acción de un objeto que ejecutar un procedimiento como se hacía en RPC, por tanto la abstracción que debe realizar el sistema en estos casos es mucho mayor. El mejor de los referentes de estos sistemas es la arquitectura CORBA (Common Object Resource Broker Architecture) [OMG, 1991]. Sistemas de comunicaciones 18 de 38 Figura 8. Arquitectura de comunicaciones CORBA. La última de las especificaciones CORBA [OMG, 1995] ha sido desarrollada por la Organización Internacional OMG (Object Management Group). OMG se fundó en 1989 y está formada por un consorcio de 800 empresas. CORBA permite el desarrollo de software para entornos distribuidos heterogéneos separando la especificación de las aplicaciones de su implementación. Los componentes y el funcionamiento pueden observarse en la figura 8. La especificación de una aplicación u objeto constituye su interfaz (ORB interface), que es independiente del lenguaje de desarrollo e indica el conjunto de servicios ofrecidos al resto de aplicaciones u objetos y la forma de invocarlos. CORBA proporciona un lenguaje estándar para definir interfaces independiente del lenguaje de programación llamado OMG IDL o CORBA IDL (Interface Definition Language). Los procesos cliente emplean dicha interfaz para comunicarse entre ellos. Para realizar dicha comunicación se emplea un núcleo importante de la arquitectura que es el ORB (Object Request Broker) Process que es el encargado de gestionar y sincronizar todas las comunicaciones. Como arquitectura, CORBA tiene una gran variedad de implementaciones ya que se ha estandarizado como modelo de objetos distribuidos. De entre las implementaciones destacar (por orden alfabético): • Borland Visibroker [Visigenic, 1998] como sistema comercial lo inició la empresa Visigenic que posteriormente compró Borland. Existen diferentes versiones en función del lenguaje orientado a objetos que se desee emplear: “VisiBroker for Java”, “VisiBroker for C++” compatible por completo con ANSI C++, finalmente “VisiBroker Smart Agent” proporciona un sistema dinámico distribuido con servicio de nombres, directorios, soporte a tolerancia de fallos y ajuste de carga del sistema. • JacORB. Es una plataforma CORBA implementada completamente en JAVA y de libre distribución. Es de especial interés ya que implementa las políticas de calidad de servicio de DDS, modelo que se verá más adelante. La compañía PrismTech da soporte comercial a la distribución. • Orbix [Iona, 1997]. Es un producto comercial que implementa la especificación de CORBA, actualmente comercializado por la compañía IONA. • TAO [Schmidt et al., 1998] es una implementación de CORBA con soporte a tiempo real. El nombre es el acrónimo de The Ace ORB. Es la evolución de ACE, proporcionando además un inicio de calidad de servicio entre componentes. Actualmente hay versiones para diversos sistemas operativos. Sistemas de comunicaciones 19 de 38 Cabe destacar que diversos componentes de CORBA se emplean habituamente como parte de otros entornos de desarrollo de sistemas distribuidos. Como ejemplo más paradigmático de esto está “OpenFusion” que aúna parte de la implementación TAO con el enriquecimiento de módulos de CORBA y la ampliación con sistemas de calidad de servicio o de tolerancia a fallos. OpenFusion lo gestiona PrismTeche, empresa dedicada también a comercializar el modelo DDS, que se verá a continuación. 3.2.9 DDS Data Distribution Service for Real-time Systems (DDS) es una especificación de sistema de publicación y suscripción con soporte a tiempo real, que complementa a CORBA. La especificación corresponde a OMG (Object Management Group). Las primeras especificaciones provienen de 2003, y actualmente hay una versión de enero de 2007. DDS se trata de un sistema de comunicaciones basado en la información más complejo que los anteriores. El paradigma que emplea es el de productores y consumidores (figura 9), aunque no se distinguen entre ellos, y todos están encapsulados por medio de módulos. Este encapsulado hace que los productores desconozcan donde se consume la información que envían al sistema, y de manera análoga, los consumidores desconocen dónde es producida la información. Aunque el origen físico de la información se desconozca, sí que se conoce el origen lógico de la misma, ya que los consumidores se registran (o suscriben) a un agente de comunicaciones que es el encargado de gestionar las mismas. Figura 9. Arquitectura de comunicaciones DDS. La fiabilidad de las comunicaciones es responsabilidad del agente DDS. Los cambios en la topología del sistema se pueden realizar cuando este está funcionando, lo que le confiere cierta potencia en comparación con los sistemas anteriores, donde la configuración del mismo era estática a lo largo de todo el proceso. La especificación describe dos niveles de interfaces [Houston, 1998]. El más bajo, y obligatorio si se quiere cumplir con la especificación, es el DCPS (Data-Centric Publish-Subscribe), y tiene el objetivo de proporcionar la eficiencia en la entrega correcta de la información a los destinatarios. La segunda de las capas, es DLRL (Data Local Reconstruction Layer); es una capa opcional que tiene como objetivo integrar DDS en la capa de aplicación. De entre los componentes importantes de DDS cabe destacar los siguientes. • DomainParticipantFactory. Es una instancia única del punto de entrada para las aplicaciones que empleen los servicios de DDS. Sistemas de comunicaciones 20 de 38 • DomainParticipant. Es el punto de entrada de las compunicaciones para un dominio concreto. Representa a la aplicación que emplea DDS dentro de un dominio específico y proporciona los componentes de DDS necesarios para la comunicación. • Topic. Instaciación de un componente TopicDescription, que es la descripción básica de un dato que puede ser publicado y al que se pueden suscribir otros componentes. • ContentFilteredTopic o MultiTopi. TopicDescription especializados. • Publisher. Objeto responsable de la diseminación de datos cuando estos deben ser publicados. • DataWriter. Objeto que permite a una aplicación instanciar un valor de un dato para que sea publicado por un Topic. • Subscriber. Objeto responsible de la rececpción de los datos resultante de las suscripciones. • DataReader. Objeto que permite a la aplicación declarar los datos en los que está interesada recibir información (creando una subscripción usando un Topic, ContentFilteredTopic o MultiTopic) y accede a los datos recibidos usando un Subscriber asociado. Como arquitectura, DDS tiene diversas implementaciones, entre ellas destacan: • NDDS [RTI, 1999] con origen en los sistemas de tiempo real [Castellote et al., 1997], siendo actualmente uno de los entornos de desarrollo de DDS más empleados. • Proyecto Open DDS [Busch, 2007], en el que se ofrece una implementación de código abierto en C++ del modelo DDS. El soporte comercial lo ofrece la compañía Object Computing, Inc. • OpenSplice [PrismTech, 2007]. Es la distribución del modelo DDS que realiza la empresa PrismTech. El sistema que ofrecen está muy probado y se vende como sistema de comunicaciones para misiones críticas. • MilSOFT DDS [MilSOFT, 2006]. Desarrollado por la empresa del mismo nombre, es un sistema DDS con soporte para JAVA, a través de la capa JNI. Se puede apreciar que DDS tiene una difusión muy similar a CORBA, eso se debe a que DDS es un enriquecimiento de CORBA, tal como destaca la OMG en su descripción del modelo de comunicaciones. La gran ventaja sobre CORBA está en la estandarización de las políticas de calidad de servicio y en la gran simplicidad del modelo DDS frente a CORBA. 3.2.10 MSMQ MSMQ es una herramienta de Microsoft para realizar el manejo de colas de mensajes. La misma viene con Windows NT/2000 y cuenta con una interfaz que permite escribir programas en lenguaje C o utilizando componentes COM para realizar el envío y recepción de mensajes [Lewis, 1999]. MSMQ provee otras funcionalidades como ser la autenticación y el encriptado de mensajes, y el uso de transacciones externas, por ejemplo administradas por SQL Server, lo que facilita la implementación de las aplicaciones que utilizan la cola de mensajes como forma de realizar sus tareas. Además Sistemas de comunicaciones 21 de 38 se cuenta con la herramienta MSMQ Triggers que permite disparar procesos cada vez que un mensaje con ciertas características llega a la cola. La definición de los triggers permite disparar los procesos por ejemplo cuando la etiqueta o el cuerpo del mensaje contienen determinado texto; cuando la prioridad del mensaje es igual, mayor o menor a cierto valor; cuando el usuario que envía el mensaje es un usuario determinado. Los componentes y el esquema de funcionamiento pueden verse en la figura 10. Figura 10. Arquitectura de comunicaciones MSMQ. Para acceder a una cola en .NET existe una API llamada System.Messaging. Inicialmente está pensada para trabajar con MSMQ pero realmente la API es extensible para soportar otros sistemas basados en colas. System.Messaging proporciona clases que permiten conectar, supervisar y administrar las colas de mensajes en la red, así como enviar, recibir o leer mensajes. La clase principal de System.Messaging es MessageQueue. Los miembros de la clase MessageQueue incluyen diversos métodos para leer y escribir mensajes en la cola. • Send. El método Send permite a la aplicación escribir mensajes en la cola. Las sobrecargas del método permiten enviar el mensaje con una clase Message (que proporciona un control exhaustivo sobre la información enviada) o cualquier otro. • Receive. Los métodos Receive, ReceiveById, y ReceiveByCorrelationId proporcionan funciones para leer los mensajes de una cola. Al igual que el método Send, estos incluyen sobrecargas compatibles con el procesamiento de colas transaccionales. Dichos métodos ofrecen además sobrecargas con parámetros de tiempo de espera que permiten que el proceso continúe si la cola está vacía. Dado que dichos métodos son ejemplos de procesamiento sincrónico, estos interrumpen el subproceso actual hasta que haya un mensaje disponible, salvo que se especifique un tiempo de espera. • Peek. El método Peek se asemeja a Receive, aunque no quita un mensaje de la cola una vez que se haya leído. Dado que Peek no modifica el contenido de la cola, existen dos sobrecargas que admiten procesamiento transaccional. Sin embargo, como Peek y Receive leen los mensajes de la cola sincrónicamente, las sobrecargas del método permiten que se especifique un tiempo de espera para impedir que el subproceso espere de forma indefinida. Los métodos BeginPeek, EndPeek, BeginReceive y EndReceive ofrecen formas de leer los mensajes de la cola asincrónicamente. No interrumpen el subproceso actual mientras esperan a que llegue un mensaje a la cola. Sistemas de comunicaciones 22 de 38 Otros métodos de la clase MessageQueue proporcionan funciones para recuperar listas de colas según los criterios especificados y averiguar si determinadas colas existen. GetPrivateQueuesByMachine permite recuperar las colas privadas de un equipo. Los métodos derivados de Get, son GetPublicQueuesByCategory, GetPublicQueuesByLabel y GetPublicQueuesByMachine que ofrecen algunas formas de recuperar las colas públicas según unos criterios comunes. Una sobrecarga de GetPublicQueues ofrece mayor nivel de detalle para seleccionar las colas según una serie de criterios de búsqueda. Finalmente, otros métodos de la clase MessageQueue son los que crean y eliminan colas de Message Queue Server, utilizan un enumerador de mensajes para desplazarse entre los mensajes de una cola, utilizan un enumerador de cola para iterar las colas del sistema, métodos para establecer derechos de acceso o para trabajar directamente con el contenido de las colas. 3.2.11 JMS Java Message Service aparece con el objetivo de aislar de las interfaces y de la configuración del servicio de mensajería. En la especificación J2EE, JMS proporciona las interfaces para la comunicación por medio del servicio de mensajería JAVA [Hapner et al., 2002]. Figura 11. Arquitectura de comunicaciones JMS. JMS Admite tanto mensajes punto a punto, como de publicación/suscripción (figura 11). Cuando un mensaje es sólo entre un emisor y un receptor, se emplea el dominio punto a punto. En este modelo, para asegurar que un mensaje llega al receptor, aunque éste no esté disponible, se encola el mensaje en una cola FIFO para ser recibido por el destinatario cuando éste esté accesible. Cuando el mensaje puede provenir de diferentes fuentes hacia diferentes destinos se emplea el dominio de publicación/suscripción. En el modelo de publicación/suscripción se tienen varios clientes que pueden publicar información (tópicos) o eventos y otros que se suscriben a esos tópicos. Ambos modelos pueden ser síncronos mediante el método receive() y asíncronos por medio de un MessageListener que es el responsable de escuchar los posibles cambios en los tópicos a los que se suscriba un cliente. Las aplicaciones JMS constan de tres elementos principales. • Objetos administrados: Objetos JMS que gestionan la conexión y los mensajes. • Mensajes: información que intercambian los clientes JMS. Sistemas de comunicaciones 23 de 38 • Clientes JMS. Son las aplicaciones que envían o reciben mensajes empleando JMS. Los objetos administrados son los elementos que emplea JMS para enviar y recibir mensajes a través de JMS. Estos objetos son los que deben implementar las interfaces JMS y están situados en JNDI (Java Naming and Directory Interface) para que cualquier cliente pueda solicitar el uso de cualquier objeto administrado. Hay dos tipos de objetos administrados. • ConnectionFactory: Se emplea para crear una conexión al proveedor del sistema de mensajes. • Destination: Son los destinos de los mensajes que se envían y a su vez el contenedor de los mensajes que se reciben. Los mensajes están formados por tres elementos: Header (cabecera), Properties (propiedades) y body (cuerpo del mensaje). La cabecera contiene una serie de campos que permiten a los proveedores y a los clientes identificar las características generales de los mensajes con los que trabajan. Las propiedades un conjunto de características de cada mensaje en particular. Finalmente el cuerpo del mensaje es el contenedor de la información que se desea intercambiar. El cuerpo puede ser de diferentes tipos. • StreamMessage: Contiene una cadena secuencial de datos que la aplicación debe conocer. • MapMessage: Contiene campos con pares nombre-valor. • TextMessage: Contiene una cadena de caracteres. • ObjectMessage: Contiene un objeto que implemente la interfaz serializable. • BytesMessage: Contiene una cadena de bytes. Se considera clientes en JMS tanto a los componentes que suministran los mensajes, como a los que los reciben. Para poder comunicarse todos deben seguir unos pasos muy concretos. 1. Solicitar, a través de JNDI, un objeto del tipo “ConnectionFactory”. 2. Conseguir, por medio de JNDI, un destino a través de un objeto “Destination”. 3. Usar el “ConnectionFactory” para conseguir un objeto “Connection”. 4. Usar el objeto “Destination” para crear un objeto “Session”. Una vez creados los objetos, se pasa al intercambio de mensajes. Como se trata de intercambio de información entre objetos, ya no hay una aplicación que envía y otra que recibe, sino que son varias las aplicaciones que reciben los mensajes, en concreto aquellas que están suscritas a la cola a la que se envían los mensajes desde un objeto específico. JMS está ampliamente extendido ya que, como sistema muy ligado a JAVA es de gran interés cuando se busca la compatibilidad. Existen gran cantidad de productos que soportan JMS, pero entre ellos cabe destacar Active MQ de “Apache” por la importancia de la compañía y la amplia implantación como servidor. JMS se emplea como sistema de mensajería de soporte al sistema de colas. Sun Microsystems tiene su propia implementación Sun Java System Message Queue (SJSMQ). Sistemas de comunicaciones 24 de 38 3.2.12 MidArt MidArt [Mizunuma et al., 1996] es el acrónimo de “Middleware and network Architecture for distributed Real-Time systems”. MidArte trata de simplificar la complejidad inherente en CORBA, aislando a las aplicaciones de los detalles de la red y proporcionando transacciones en tiempo real. Para ello organiza el sistema en tres capas con funciones específicas. Cada capa se compone de diversos módulos. • Capa de gestión. Es la capa responsable de las interacciones entre los programas que se ejecutan en diferentes nodos, y que no precisan de soporte de tiempo real en sus transacciones. Se compone de un único módulo, Global Manager (GM), que a su vez tiene dos componentes: el Global Server (GS) y el Global Connection Admission Control (GCAC). • Capa de aplicación. Tiene un único componente, el Application Programming Interface (API), es una librería que permite a las aplicaciones invocar los servicios de MidArte. • Capa de intermediación o “middleware”. Tiene un único componente, el Local Server Process (LSP), que se compone de diversos módulos: Local Sever (LS), Real-Time Channel based Reactive Memory (RT-CRM), Selective Channels (SC), Scheduler, Fault Tolerance y Local Connection Admission Control (LCAC). MidArt se caracteriza por la simplificación y el reparto de las tareas de la comunicación de forma organizada y bien definida en módulos, componentes y capas. Las librerías de desarrollo están orientadas a objetos y los componentes que implementan las capas son objetos instanciados a partir de las clases que proporciona la librería. Por ello puede considerarse que el sistema es orientado a objetos, aunque distribuya mensajes entre ellos. 3.2.13 Jini Jini no son unas iniciales, aunque al estar relacionado con JAVA suele encontrarse alguna interpretación de las siglas. Jini es una extensión de JAVA cuyo objetivo es facilitar la integración de sistemas distribuidos. Jini se basa en el principio del ofrecimiento y uso de servicios en un sistema distribuido, entendiéndose como servicio desde un hardware hasta una aplicación concreta, pasando por el concepto clásico de servicio. Los servicios se agrupan en entidades llamadas “federaciones”, que realmente son federaciones de máquinas virtuales de JAVA. Los orígenes de JINI son similares a los de JAVA, a partir del año 1994 comienzan a ser necesarias las transacciones entre procesos con localizaciones separadas en la red. Los conceptos básicos y componentes que se encargan de proveer dichas características son los siguientes. • Servicios. Es el concepto básico de JINI, prácticamente todo se considera un servicio: dispositivos, datos, almacenamiento, procesamiento de datos como filtrado o los cálculos realizados con los datos. En definitiva, todo aquello que pueda ser útil para un usuario u otros servicios. • Servicio Lookup. Método por el que se localizan los servicios disponibles en una comunidad JINI. Es el punto de inicio y de interacción entre un servicio y un usuario de dicho servicio. Sistemas de comunicaciones 25 de 38 • RMI: Remote Method Invocation. RMI es el RPC de JAVA que trabaja a nivel de objetos. • Seguridad. Se basa en un modelo de lista de control que valida, permite accesos y supervisa las acciones de los servicios. • Asignaciones de tiempos, o métodos por los que se asigna el tiempo a los recursos de los servicios y a los servicios. En el modelo de JINI se permite la exclusividad en el uso de un recurso durante un periodo de tiempo. • Transacciones Son protocolos para el envío de mensajes entre servicios. Las operaciones entre uno varios servicios se pueden aunar en una sola transacción. • Eventos Los eventos, no podían faltar en un sistema así. En este caso además, el sistema debe ser capaz de soportar eventos distribuidos. Si un nuevo dispositivo se une a la federación Jini, si un servicio desea notificar algo a un usuario,.. en muchas circunstancias los la notificación de eventos remotos resulta indispensable. El hecho de trabajar con servicios, implica que los principales componentes de un sistema basado en JINI son el servidor, el cliente y las interacciones entre ellos. Uno de los puntos fuertes en los que se basa ésta tecnología es en la ligereza del código que implementa el núcleo de JINI, es del orden de 40KB en la versión actual. Emplear un núcleo muy sencillo tiene la ventaja de poder ser empotrado en casi cualquier dispositivo, desde grandes computadores a pequeños procesadores con capacidad muy limitada. 3.2.14 DCE Distributed Computing Environment (DCE), OSF DCE es un conjunto de servicios que puede utilizarse separadamente o en combinación, en ambientes de desarrollo de computación distribuida. Los servicios son los siguientes: • Servicio de llamada a procedimiento remoto o DCE Remote Procedure Call (DCE RPC). • Servicio de Directorios o DCE Directory Service, que permite a usuarios y aplicaciones almacenar, retener y manipular información. • Servicio de seguridad o DCE Security Service • Servicio de manejo de hilos o DCE Threads. • Servicio de tiempo o DCE Distributed Time. • Sistema de archivos distribuido o DCE Distributed File System (DCE DFS). • Servicio de soporte para computadoras sin disco local o DCE Diskless Support Service. • Servicio de integración a computadoras personales. DCE RPC es utilizado como único mecanismo de comunicación entre el cliente y el servidor en otros servicios que componen DCE que no pertenezcan al modelo. Actualmente DCE es distribuida bajo la licencia LGPL por la organización The Open Group. También existen una serie de distribuciones comerciales de DCE de IBM o HP. Sistemas de comunicaciones 32 de 38 4.4 Posibles áreas de investigación Todos los paradigmas de comunicaciones tienen sistemas que los implementan y además tienen vigencia actual, es decir, la aparición del paradigma de servicio de mensajería no excluye la posibilidad de usar el paradigma del paso de mensajes clásico. Eso hace que la investigación en los sistemas de comunicaciones no siga una línea unidimensional hacia una tendencia, sino que abarque un amplio rango. Otro de los aspectos en los que es posible desarrollar líneas de investigación es el centrado en el control temporal de las mismas. Eso implica tanto el desarrollo de sistemas con soporte a un control básico de retardos en mensajes como el soporte a l cumplimiento de plazos de tiempo real estricto. Dada la importancia del tema, la calidad de servicio se ha dejado para posteriores documentos, sin embargo es posiblemente una de las áreas más interesantes en cuanto a líneas de investigación ya que implica todos los aspectos mencionados anteriormente. En posteriores estudios se desarrollarán estas cuestiones con mayor detalle. Sistemas de comunicaciones 33 de 38 5 Referencias [Busch, 2007] Don Busch. Introduction to OpenDDS. Object Computing, Inc. (OCI) 2007. [Coulouris et al., 2001] Coulouris, G., Dollimore, J., Kindberg, T. Sistemas Distribuidos, Conceptos y diseño. Tercera Edición. Addison Wesley. Madrid. 2001. [Fedor, 1994] Fedor, C. TCX: an interprocess communication system for building robotic architectures. Technical report, Robotics Institute, Carnegie Mellon University, 1994. [FIPA, 1997] Foundation for Intelligent Physical Agents: FIPA 97 Specfication. Part 2, Agent Communication Language”, (1997). [Fong et al., 2001] Fong, T.W. C. Thorpe, and C. Baur. A safeguarded teleoperation controller. In IEEE International Conference on Advanced Robotics 2001, Budapest, Hungary, August 2001 [Fong, 1998] Fong, T.W. Fourth planet communicator. Fourth Planet Inc., 1998. [Gaddah and Kunz, 2003] Gaddah A., and Kunz, T. A survey of middleware paradigms for mobile computing. Technical Report SCE-03-16. Carleton University Systems and Computing Engineering. (2003) [Gamma et al, 1994] Gamma, e., Helm, R., Johnson, R., Vlissides, J. Design Patterns. Elements of Reusable Object-Oriented Software. Addison Wesley, 1994 [Gowdy, 1996] Gowdy, J. IPT: An Object Oriented Toolkit for Interprocess Communication. Technical report CMU-RI-TR-96-07, Robotics Institute, Carnegie Mellon University, March, 1996. [Gowdy, 2000] Gowdy, J. A Qualitative Comparison of Interprocess Communications Toolkits for Robotics. Tech. report CMURI-TR-00-16, Robotics Institute, Carnegie Mellon University, June, 2000 [Hapner et al., 2002] M. Hapner, R. Sharma, J. Fialli, and K. Stout, JMS specification, Sun Microsystems Inc., 4150 Network Circle, Santa Clara, CA 95054 USA, 1.1 edition, April 2002, http://java.sun.com/products/jms/docs.html [Houston, 1998] P. Houston. Building distributed applications with message queuing middleware – white paper. Technical report, Microsoft Corporation, 1998. Sistemas de comunicaciones 34 de 38 [Iona, 1997] IONA. Orbix 2.2 Programming guide. IONA Technologies Ltd. Mar. 1997. [Lewis, 1999] Lewis, R.: Advanced Messaging Applications with MSMQ and MQ Series. Que Publishing, 1999. [Liu, 2004] Liu, M.L., Distributed Computing: Principles and Applications. Addison-Wesley, 2004. [MilSOFT, 2006] MilSOFT, (2006), “MilSOFT DDS Middleware”, http://dds.milsoft.com.tr [Mizunuma et al., 1996] Mizunuma, I., Shen, C., Takegaki, M. 1996. ‘Middleware for distributed industrial real-time systems on ATM networks’, 17th IEEE Real-Time Systems Symposium. [OMG, 1991] Object Management Group. The Common Object Request Broker: Architecture and Specification. 1.1 ed., December 1991. [OMG, 1995] Object Management Group, The Common Object Request Broker: Architecture and Specification. 2.0 ed., July 1995. [Pardo-Castellote, 2007] Pardo-Castellote, G. Analysis of the Advanced Message Queuing Protocol (AMQP) and comparison with the RealTime Publish Subscribe Protocol (DDS-RTPS Interoperability Protocol). Real-Time Innovations, Inc. 2007. [Pedersen, 1998] Pedersen, J.D. Robust communications for high bandwidth real-time systems. Technical Report CMU-RI-TR-98-13, Carnegie Mellon University, Robotics Institute, May 1998. [Poza et al., 2009] J.L. Poza, J.L. Posadas y J.E. Simó. Arquitecturas de control distribuido. Technical Report. Universidad Politécnica de Valencia. 2009. [PrismTech, 2007] PrismTech Ltd. (2007) www.prismtech.com [RTI, 1999] Real-Time Innovations. NDDS: The Real-Time PublishSubscribe Middleware (1999). www.rti.com [Schmidt et al., 1998] D. Schmidt, D. Levine, and S. Mungee. The Design and Performance of Real-time Object Request Brokers. Computer Communications, 21(4):294–324, April 1998. [Schmidt, 1993] Schmidt, Douglas C. The ADAPTIVE Communication Environment An Object-Oriented Network Programming Toolkit for Developing Communication Software. 1993. 11thth and 12th th th Sun user group conferences. California Sistemas de comunicaciones 35 de 38 [Shackleford et al., 2000] W. Shackleford J. Michaloski, F. Proctor. The neutral message language: A model and method for message passing in heterogeneous environments. In Proceedings of the World Automation Conference, Maui, Hawaii, June 2000. [Simmons and James, 2001] R. Simmons y D. James. Inter Process Communication: A Reference Manual, February 2001. [Visigenic, 1998] Visigenic. Visibroker for C++ 3.2 Programmer’s guide. Visigenic Software Inc. Mar. 1998. Sistemas de comunicaciones 37 de 38 6 ANEXO: Sistemas de comunicaciones analizados Sistema Significado Paradigma (Modelos) Compañía Año Web .NET N/S Distributed Components Microsoft 2002 http://msdn.microsoft.com/netframework/ ACE ADAPTIVE Communication Environmet Distributed Objects Object Computing Inc 1993 http://www.cs.wustl.edu/~schmidt/ACE.html ActiveMQ Active Message Ques Message Oriented Middleware Apache 2006 www.activemq.org Borland Visibroker N/S Distributed Objects Borland 2004 www.borland.com CICS Customer Information Control System Transaction Oriented Middleware IBM 1980 www-306.ibm.com/software/htp/cics/ COM Component Object Model No es distribuido Microsoft 1988 www.microsoft.com/com CORBA Common Object Request Broker Architecture Distributed Objects OMG 1995 www.corba.org DCDT Device Communities Development Toolkit Publish/Subscribe Univ. Brescia 2001 No localizada DCE Distributed Computing Environment Client/Server OSF 1993 http://www.opengroup.org/dce/ DCOM Distributed Component Object Model Distributed Components Microsoft 1995 www.microsoft.com/com DDS Data Distribution Service Publish/Subscribe OMG 2004 portals.omg.org/dds DSOM Distributed System Object Model Distributed Objects IBM 1990 www.ibm.com ETHNOS Expert Tribe in a Hybrid Network Operating System Publish/Subscribe Univ. Genova 1999 No localizada IPC Inter Process Communication Publish/Subscribe Univ. Carnegie Mellon 1991 www.cs.cmu.edu/~IPC IPT Inter Process Toolkit Publish/Subscribe Univ. Carnegie Mellon 1996 No localizada Jacorb Java and CORBA Publish/Subscribe Varios (free) 1997 www.jacorb.org JINI N/S Servicios SUN Microsystems 1999 www.jini.org JMS Java Message Service Message Oriented Middleware SUN Microsystems 2001 java.sun.com/products/jms/ MidArt Middleware and Network Architecture for Distributed Real Time Systems Distributed Objects Mitshubishi y otros MPI Message Passing Interface Paso de mensajes MPI Forum 1994 www.mpi-forum.org MSMQ Message Queue Paso de mensajes Microsoft 1997 www.microsoft.com/windowsserver2003/technologies/msmq NDDS RTI Data Distribution Service Publish/Subscribe RTI 2001 www.rti.com NDDS Network Data Delivery Service Publish/Subscribe Univ. Stanford 1994 arl.stanford.edu/users/pardo/ndds.html NML Neutral Messaging Language Message passing NIST 2000 No localizada OpenCore N/S Message passing OpenSubsystems 2004 www.opensubsystems.org/core/ OpenDDS N/S Publish/Subscribe Object Computing Inc 2006 www.opendds.org OpenFusion N/S Distributed Objects PrismTech 2000 www.prismtechnologies.com Sistemas de comunicaciones 38 de 38 OpenSplice N/S Publish/Subscribe PrismTech 2006 www.prismtechnologies.com Orbix Distributed Objects ORiN Open Resource interface for the Network/Open Robot interface for the Network Message passing ORIN Forum 1998 www.orin.jp RTC Real-Time Communications Publish/Subscribe Univ. Carnegie Mellon 1998 No localizada SJSMQ Sun Java System Message Queue Message Oriented Middleware SUN Microsystems 2005 www.sun.com/software/products/message_queue/ SOM System Object Model No es distribuido IBM 1990 www.ibm.com SPLICE Subscription Paradigm for the Logical Interconnection of Concurrent Engines Publish/Subscribe US Navy 1993 No localizada TAO The ACE ORB Publish/Subscribe Object Computing Inc 2000 http://www.theaceorb.com/ TCX N/S Publish/Subscribe Univ. Carnegie Mellon 1990 No localizada TelRip TeleRobotics Interconnection Protocol Publish/Subscribe Univ. Rice 1992 No localizada Tibco N/S Service Oriented Middleware TIBCO 1997 www.tibco.com Tuxedo Transactions for Unix, Extended for Distributed Operations Transaction Oriented Middleware BEA Systems 1984 www.beasys.es UPnP Universal Plug&Play Message passing Microsoft 1999 www.upnp.org WebSphere MQ N/S Message passing IBM 1992 www.ibm.com/webspheremq/