El modelo de comunicaciones DCPS

El modelo de comunicaciones DCPS Autor: Jose 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.3 Fecha: 10 de noviembre de 2009 El modelo de comunicaciones DCPS 3 de 47 Contenidos 1 Introducción............................................................................................................. 7 1.1 Resumen...................................................................................................................... 7 1.2 Historial de revisiones ............................................................................................... 7 1.3 Objetivos del documento........................................................................................... 7 1.4 Alcance y audiencia ................................................................................................... 7 1.5 Organización del documento ....................................................................................7 2 El modelo de comunicaciones DCPS...................................................................... 8 2.1 Ámbito ........................................................................................................................ 8 2.2 Modelo ........................................................................................................................ 9 2.3 Componentes............................................................................................................ 11 2.3.1 Modelo conceptual .............................................................................................................11 2.3.2 Modelo formal....................................................................................................................13 2.4 Características.......................................................................................................... 14 2.4.1 Sistema de comunicaciones................................................................................................15 2.4.2 Soporte a eventos condicionales.........................................................................................15 2.4.3 Soporte a las comunicaciones.............................................................................................15 3 Políticas de calidad de servicio.............................................................................. 16 3.1 Gestión de meta datos..............................................................................................16 3.1.1 UserDataQoSPolicy, TopicDataQoSPolicy, GroupDataQoSPolicy...................................16 3.2 Aspectos temporales ................................................................................................ 17 3.2.1 DurabilityQoSPolicy ..........................................................................................................17 3.2.2 DurabilityServiceQoSPolicy...............................................................................................18 3.2.3 DeadlineQoSPolicy ............................................................................................................19 3.2.4 LatencyBudgetQoSPolicy...................................................................................................21 3.2.5 LivelinessQoSPolicy ..........................................................................................................22 3.2.6 TimeBasedFilterQoSPolicy................................................................................................24 3.2.7 LifespanQoSPolicy.............................................................................................................25 3.3 Gestión del flujo de datos........................................................................................ 26 3.3.1 PresentationQoSPolicy.......................................................................................................26 3.3.2 ReliabilityQoSPolicy..........................................................................................................28 3.3.3 TransportPriorityQoSPolicy...............................................................................................29 3.3.4 DestinationOrderQoSPolicy...............................................................................................30 3.3.5 HistoryQoSPolicy...............................................................................................................31 3.3.6 ResourceLimitsQoSPolicy..................................................................................................33 3.3.7 OwnershipQoSPolicy .........................................................................................................35 3.3.8 OwnershipStrengthQoSPolicy............................................................................................36 3.4 Gestión de los componentes .................................................................................... 37 3.4.1 PartitionQoSPolicy.............................................................................................................37 3.4.2 EntityFactoryQoSPolicy.....................................................................................................38 3.4.3 WriterDataLifecycleQoSPolicy..........................................................................................39 3.4.4 ReaderDataLifecycleQoSPolicy.........................................................................................39 4 Análisis................................................................................................................... 41 4.1 Resumen de las políticas de calidad de servicio de DDS ...................................... 41 El modelo de comunicaciones DCPS 4 de 47 4.2 Métodos de los elementos de comunicación........................................................... 43 5 Conclusiones.......................................................................................................... 46 6 Referencias............................................................................................................. 47 El modelo de comunicaciones DCPS 5 de 47 Figuras Figura 1. Elementos del modelo de comunicaciones DCPS de DDS. ........................................................11 Figura 2. Componentes del modelo UML del DCPS de DDS. ...................................................................13 Figura 3. Componentes del modelo UML del DCPS de DDS. ...................................................................14 Figura 4. UML de UserDataQoSPolicy, TopicDataQoSPolicy y GroupDataQoSPolicy. .........................17 Figura 5. UML de DurabilityQoSPolicy. ...................................................................................................17 Figura 6. UML de DurabilityServiceQoSPolicy. .......................................................................................18 Figura 7. UML de DeadlineQoSPolicy. .....................................................................................................19 Figura 8. Comportamiento de Deadline dentro en los componentes DCPS. .............................................20 Figura 9. UML de LatencyBudgetQoSPolicy.............................................................................................21 Figura 10. Comportamiento de la LatencyBudgetQoSPolicy. ...................................................................21 Figura 11. UML de LivelinessQoSPolicy...................................................................................................22 Figura 12. Comportamiento de los componentes de LivelinessQoSPolicy. ...............................................23 Figura 13. UML de TimeBasedFilterQoSPolicy........................................................................................24 Figura 14. Comportamiento de los componentes de TimeBasedFilterQoSPolicy. ....................................25 Figura 15. UML de LifespanQoSPolicy.....................................................................................................26 Figura 16. UML de PresentationQoSPolicy. .............................................................................................26 Figura 17. UML de ReliabilityQoSPolicy. .................................................................................................28 Figura 18. Comportamiento de los componentes de ReliabilityQoSPolicy................................................29 Figura 19. UML de TransportPriorityQoSPolicy. .....................................................................................30 Figura 20. UML de DestinationOrderQoSPolicy. .....................................................................................30 Figura 21. Comportamiento de los componentes de DestinationOrderQoSPolicy....................................31 Figura 22. UML de HistoryQoSPolicy.......................................................................................................32 Figura 23. Comportamiento de los componentes de HistoryQoSPolicy. ...................................................33 Figura 24. UML de ResourceLimitsQoSPolicy..........................................................................................33 Figura 25. Comportamiento de los componentes de ResourceLimitsQoSPolicy. ......................................35 Figura 26. UML de OwnershipQoSPolicy. ................................................................................................35 Figura 27. UML de OwnershipStrengthQoSPolicy....................................................................................36 Figura 28. Comportamiento de los componentes de OwnershipStrengthQoSPolicy. ................................37 Figura 29. UML de PartitionQoSPolicy. ...................................................................................................37 Figura 30. Comportamiento de los componentes de PartitionQoSPolicy..................................................38 Figura 31. UML de EntityFactorytQoSPolicy............................................................................................39 Figura 32. UML de WriterDataLifecycleQoSPolicy..................................................................................39 Figura 33. UML de ReaderDataLifecycleQoSPolicy.................................................................................39 Tablas Tabla 1. Organización en sistemas de los módulos de DDS ......................................................................15 Tabla 2. Resumen de las características de las políticas de calidad de servicio. ......................................42 Tabla 3. Resumen de los parámetros en las funciones de las políticas de calidad de servicio. .................42 Tabla 4. Métodos de los componentes “Publisher” y “Subscriber”..........................................................44 Tabla 5. Métodos de los componentes “DataWriter” y “DataReader”.....................................................44 Ecuaciones Ecuación 1. Orden de precedencia de la propiedad “kind” en la política de QoS Durability. .................18 Ecuación 2. Relaciones entre los periodos de deadline ofrecidos y solicitados.........................................20 Ecuación 3. Coherencia en los periodos de deadline y la separación temporal entre mensajes. ..............21 Ecuación 4. Relación entre las dureaciones de latencia ofrecidas y solicitadas en la política de calidad de servicio LatencyBudgetQoSPolicy. ............................................................................................................22 Ecuación 5. Orden de comparación de la propiedad “kind” en la política de calidad de servicio Liveliness....................................................................................................................................................24 Ecuación 6. Condición de compatibilidad entre las políticas de calidad de servicio TimeBasedFilter y Deadline. ....................................................................................................................................................25 El modelo de comunicaciones DCPS 6 de 47 Ecuación 7. Condiciones para la coherencia en la política de calidad de servicio Presentation..............27 Ecuación 8. Orden de prioridad de la propiedad “access_scope” empleado en la ecuación 7. ...............27 Ecuación 9. Condición de coherencia de “coherente_access” en la política de calidad de servicio Presentation. ..............................................................................................................................................27 Ecuación 10. Relacion entre las propiedades “coherent_access” solicitados y ofrecidos en la política de calidad de servicio Presentation. ...............................................................................................................27 Ecuación 11. Condición de coherencia de “ordered_access” en la política de calidad de servicio Presentation. ..............................................................................................................................................27 Ecuación 12. Relacion entre las propiedades “ordered_access” solicitados y ofrecidos en la política de calidad de servicio Presentation ................................................................................................................27 Ecuación 13. Orden jerárquico de las categorías de la política de calidad de servicio Reliability. .........28 Ecuación 14. Relación entre los valores ofrecidos y solicitados de la propiedad “kind” de la política de calidad de servicio Reliability....................................................................................................................29 Ecuación 15. Compatibilidad de valores de la propiedad “kind” de la política de calidad de servicio DestinationOrderQoSPolicy.......................................................................................................................31 Ecuación 16. Orden de tipos que se aplica en la fórmula 15.....................................................................31 Ecuación 17. Fórmula que define la consistencia en la política de calidad de servicio History. ..............32 Ecuación 18. Condición de coherencia de la política de calidad de servicio ResourceLimits. .................34 Ecuación 19. Condición de coherencia entre las políticas de calidad de servicio ResourceLimits e History........................................................................................................................................................34 El modelo de comunicaciones DCPS 7 de 47 1 Introducción 1.1 Resumen De entre la gran cantidad de modelos de comunicaciones existentes, el modelo DCPS propuesto por la OMG es uno de los más completos en lo que el soporte a la calidad de servicio. Es por ello que se hace recomendable revisar con detalle los componentes y características del modelo. En el presente documento se revisan las características del modelo DCPS. El modelo DCPS es un modelo de comunicaciones basado en el paradigma de publicación – subscripción. Sin embargo, en lo que más destaca el modelo es especialmente por el soporte a la calidad de servicio. En el documento se detallan todas las políticas de calidad de servicio organizadas en cuatro áreas: meta datos, aspectos temporales, gestión de flujo de mensajes y gestión de componentes. 1.2 Historial de revisiones Nº revisión Fecha Comentarios 0.0 2007-10 Inicio del documento 0.1 2007-12 Inclusión de las políticas de calidad de servicio. 0.2 2008-04 Análisis del modelo DCPS 0.3 2009-07 Revisión global del documento. 1.3 Objetivos del documento El objetivo principal del documento es ofrecer una visión detallada del modelo DCPS centrándose especialmente en lo respectivo a las políticas de calidad de servicio que éste modelo cubre. 1.4 Alcance y audiencia El documento presenta una visión de los componentes del modelo DCPS, además se presentan con gran detalle, tanto conceptual como formal de las políticas de calidad de servicio. El documento está dirigido a aquellas personas que quieran conocer el modelo DCPS y especialmente conocer con detalle las políticas de calidad de servicio que el modelo propone. 1.5 Organización del documento El capitulo 2 ofrece una visión del modelo DCPS desde diversos puntos de vista, tanto la visión general del modelo como la especificación formal en UML. El siguiente capítulo, el 3, se centra en los detalles de las políticas de calidad de servicio organizadas en cuatro áreas generales (metadatos, aspectos temporales, gestión del flujo de mensajes y gestión de los componentes). A continuación, en el capítulo 4 se realiza un análisis de las funciones del modelo DCPS. Finalmente se exponen las conclusiones. El modelo de comunicaciones DCPS 8 de 47 2 El modelo de comunicaciones DCPS 2.1 Ámbito El paradigma de comunicaciones que posiblemente ofrece mejor infraestructura a los sistemas distribuidos de control inteligente es el de publicación-suscripción. Además del paradigma de comunicaciones, también se ha comprobado que el soporte a la calidad de servicio es cada vez más necesario en un sistema de comunicaciones que ejerza de middleware en un sistema distribuido. Por tanto, es necesario buscar modelos ya existentes con soporte a la calidad de servicio. En los sistemas, y arquitecturas de comunicaciones expuestas anteriormente, la calidad de servicio, no es uno de los aspectos más tratados. Esto no sorprende cuando se trata de sistemas de comunicaciones basados en paso de mensajes, ya que el empleo de colas de mensajes o el uso de servidores y servicios en los nodos permiten llevar un control de diversos aspectos de la comunicación orientados a obtener unos parámetros de rendimiento que permitan ofrecer una calidad en las comunicaciones que cumpla los requisitos de los usuarios. A medida que se van haciendo más complejos los middlewares y se avanza en la arquitectura de los mismos van apareciendo diversos soportes a la calidad de servicio, en la medida en que actúan dichos middlewares [Aurrecoechea et al., 1998] Una primera evaluación, más conceptual que orientada a indicadores, se puede encontrar en [Matteucci, 2003], donde se evalúan los middlewares basados en el modelo de publicación-suscripción en el ámbito de la robótica, pero extensible a los sistemas distribuidos de control inteligente. Este análisis es especialmente interesante en cuanto que conecta los indicadores de calidad de servicio vistos anteriormente, con las políticas de calidad de servicio que se verán posteriormente. De tal forma que definen unas áreas que las calidades de servicio deberán cubrir y que son las siguientes. • Soporte a la entrega (delivery support). o Mejor esfuerzo (best effort) o Entrega garantizada (guaranteed delivery) o Entrega ordenada (ordered delivery) • Soporte a la prioridad (priority support) • Soporte a la movilidad (movility support) • Soporte al tiempo real (real-time support). No necesariamente esta aproximación es ideal, ya que ciertos aspectos como la seguridad o la redundancia en la información, no son contemplados en ésta aproximación. De entre los sistemas de comunicaciones, basados en el modelo de publicación-suscripción, con soporte a la calidad de servicio el basado en el modelo DDS de OMG es posiblemente, el que proporciona más soporte a poder establecer políticas de gestión de calidad de servicio con garantías a los componentes [Matteucci, 2003] El modelo de comunicaciones DCPS 9 de 47 2.2 Modelo El modelo Data Distribution Service (DDS) es una especificación para sistemas de distribución de datos basada en el modelo de publicación-subscripción propuesto por el Object Management Group (OMG) para las comunicaciones con soporte a la calidad de servicio [Pardo-Castellote, 2003]. Éste modelo cubre sistemas de comunicaciones con necesidades de tiempo real estricto (aunque dependiente del soporte de comunicaciones que se tenga por debajo) hasta sistemas sin necesidades de calidad de servicio [OMG, 2005]. El modelo se basa en el paradigma de publicación-suscripción que conecta a productores de información (publicadores) con consumidores de información (suscriptores) desacoplándolos en tiempo, espacio y flujo [Houston, 1998] con la comunicación basada en la negociación y gestión de las calidades de servicio. DDS se divide en dos capas el Data-Centric Publish-Subscribe (DCPS) que es el responsable de la distribución de los datos, y el Data Local Reconstruction Layer (DLRL) que es la capa responsable de adaptar los datos a las aplicaciones locales. En un sistema DDS la capa DCPS es obligatoria, mientras que la capa DLRL es opcional dependiendo de la necesidad de adaptación de la información que tengan los componentes que se encuentren por encima del middleware. La primera versión de DDS, la 1.0, data de diciembre de 2004, mientras que a fecha de hoy la versión más reciente es la 1.2 de marzo de 2007, en el resto del apartado se analizarán los detalles de la última versión. Actualmente hay diversos proyectos que implementan parte o la totalidad del modelo DDS, estos proyectos son los siguientes. • Código abierto. Proyectos públicos o de investigación de código libre o con fines no comerciales. o OpenDDS. Es un producto de la compañía Object Computing Inc. Se puede ampliar información u obtener el código desde la Web de la compañía: www.ociweb.com. o RTjDDS: son las siglas de “DDS on High-Assurance Java”. Es un proyecto de código abierto, financiado por “Iniziativa Software” y desarrollado por “Vincenzo Caruso”. Es posible obtener los detalles en la Web: http://sourceforge.net/projects/rtjdds • Productos comerciales o RTI NDDS: de la compañía Real-Time Innovations, Inc. Es posiblemente el producto basado en DDS más extendido. Contienen una amplia documentación en su Web: www.rti.com o OpenSplice DDS: Es un producto de la compañía Prism Tech. Junto con NDDS es uno de los más empleados. Se puede obtener más información en la Web: www.prismtech.com. o MilSOFT DDS: de la compañía turca MilSoft, los detalles del sistema se pueden obtener de la Web: dds.milsoft.com.tr o CoreDX: Es una implementación de DDS centrada en el DCPS, los detalles se obtienen de: http://www.twinoakscomputing.com/coredx.php o Component-Based CORBA+DDS: Un sistema integrado basdo en CORBA y DDS. Algunos detalles se pueden obtener de la Web: http://www.pocomatic.com/docs/whitepapers/corba/. El modelo de comunicaciones DCPS 16 de 47 3 Políticas de calidad de servicio En el modelo DCPS de DDS, las políticas de calidades de servicio se implementan como una lista de calidades de servicio que debe cumplir el componente al que se asocie. Como se ve en la figura , las calidades de servicio son objetos derivados de una clase base “QoSPolicy” asociada a la clase base “Entity” de DCPS, lo que supone que todos los componentes de la comunicación (excepto “Listener” y los relacionados con las condiciones) pueden tener una serie de calidades de servicio asociadas. El hecho de que todos los componentes de comunicaciones puedan tener asociada una política de calidad de servicio hace que se puedan especificar restricciones en todos los niveles de la comunicación, desde el acceso a un “Topic” específico por parte de un “DaaWriter”o “DataReader” hasta el conjunto de todos los componentes de comunicación de un nodo. Esta jerarquización hace muy flexible los puntos de la comunicación donde se desee aplicar una política de calidad de servicio. Se debe tener en cuenta que las calidades de servicio que se solicitan por parte de un “Subscriber”, deben ser cumplidas por un “Publisher". Para la negociación se sigue el patrón “Subscriber” solicita y “Publisher” ofrece. Bajo este tipo de patrón, desde el punto de vista del subscriptor, se puede solicitar un valor, y el publicador también podrá ofrecer un valor. El servicio será quien determinará si los requerimientos son compatibles. Los servicios ya negociados pueden ser cambiados aun ya establecida la conexión, pero solo algunos de ellos. De cada política de calidad de servicio, se describirán los elementos del modelo DDS a los que concierne, la característica solicitado/ofrecido que determinará si se debe dar alguna condición entre la calidad solicitada y la ofrecida, y finalmente se debe determinar si alguna de las características de las políticas de calidad de servicio pueden ser cambiadas cuando la comunicación ya se ha establecido. Es posible organizar las políticas de calidad de servicio en grupos, atendiendo a la funcionalidad que ofrecen o el ámbito de la comunicación que ofrecen. A continuación se describen las políticas de calidad de servicio del DCPS del modelo DDS. 3.1 Gestión de meta datos 3.1.1 UserDataQoSPolicy, TopicDataQoSPolicy, GroupDataQoSPolicy Estas tres políticas de calidad de servicio, son muy similares, la única diferencia es el elemento del modelo DDS sobre el que se aplican. Todas ellas se emplean para enviar información del usuario, del “Topic”, o del “Group” al resto del sistema. Se puede emplear como cadena de bytes con contenido libre. En lo que respecta a la relación entre los valores solicitados y ofrecidos, en este caso, no es necesario que coincidan, ni existe ninguna relación entre ellos. Los diagramas de clases se pueden ver en la figura 4. El modelo de comunicaciones DCPS 17 de 47 Figura 4. UML de UserDataQoSPolicy, TopicDataQoSPolicy y GroupDataQoSPolicy. El valor por defecto es una cadena vacía. Esta característica de la calidad de servicio sólo es informativa al resto del sistema acerca del usuario, del “Topic” o del “Group”. El propósito de esta calidad de servicio es permitir a la aplicación adjuntar o asociar información adicional a una “Entity” que se haya creado. Cuando una aplicación descubra cualquiera de los objetos heredados de “Entity”, puede acceder a esta calidad de servicio para obtener información que pueda ser interpretada. Un ejemplo del uso de esta calidad de servicio es asociar las credenciales de seguridad a un objeto, que permita a una aplicación poder identificar correctamente al componente DCPS de que se trate. Además de la seguridad, cualquier uso está permitido para esta calidad de servicio. 3.2 Aspectos temporales 3.2.1 DurabilityQoSPolicy El desacoplamiento entre el “DataWriter” y el “DataReader” que implica el paradigma “Publish-Subscribe”, debe permitir a una aplicación poder escribir datos sin que se encuentren lectores en la red que los consuman. Además un “DataReader” que se una a la red en un momento concreto puede estar interesado en los valores más recientes, pero también en algunos valores pasados o históricos. Para cubrir la posibilidad de que un componente de la comunicación pueda especificar el tipo de durabilidad, o ámbito de duración temporal, que tiene la información se tiene esta política de calidad de servicio que expresa el tiempo que debe sobrevivir un dato. Esta política de calidad de servicio afecta a los “Topic”, los “DataReader” y los “DataWriter”. Tienen restricciones acerca de los valores solicitados y ofrecidos que se detallará más adelante. Finalmente los valores no pueden cambiar una vez se ha establecido la comunicación. El diagrama de clase se puede ver en la figura 5. Figura 5. UML de DurabilityQoSPolicy. La propiedad “kind” puede tomar diversos valores: El modelo de comunicaciones DCPS 18 de 47 • VOLATILE. Valor por defecto. Significa que el Publisher sólo proporciona la información del dato a los Subscribers que existan en ese momento. • TRANSIENT_LOCAL. TRANSIENT. Estos dos modos consisten en mantener algunas muestras para poder ser transmitidas a posteriores conexiones de un DataReader. Las características de estas muestras dependen de algunos otros parámetros de calidad de servicio. En el modo local (TRANSIENT_LOCAL), esta información permanece sólo en el lado del DataWriter, con las características de supervivencia que tenga el DataWriter. En el caso no local (TRANSIENT), permanece en memoria y no en soporte local. • PERSISTENT. El dato se mantiene almacenado, por lo que sobrevive a toda la sesión. Implícitamente hay un orden de precedencia en el valor de la propiedad “kind”, desde la menor precedencia “VOLATILE” hasta la máxima “PERSISTEN”, este orden puede verse en la ecuación 1, e implica que, por ejemplo, configurar a “PERSISTENT” ésta calidad de servicio, implícitamente incluye a las anteriores. Ecuación 1. Orden de precedencia de la propiedad “kind” en la política de QoS Durability. VOLATILE < TRANSIENT_LOCAL < TRANSIENT < PERSISTENT (1) Se debe tener en cuenta que en el modo TRANSIENT, los datos permanecen en memoria, pero en el PERSISTENT permanecen por encima de la sesión de comunicación, lo que implica que ciertos mensajes pueden sobrevivir por encima de las sesiones de conexiones de comunicaciones. 3.2.2 DurabilityServiceQoSPolicy La política “DurailityQoSPolycy” puede tener algunos efectos colaterales con otras políticas de calidad de servicio, esto hace que sea necesario definir algunos parámetros y las relaciones de la política DurabilityQos con las afectadas. Ésta política define la durabilidad del servicio, en este caso se aplica a los modos TRANSIENT o PERSISTENT de la política de calidad de servicio “DurabilityQoSPolicy”. El diagrama de clases es el que se muestra en la figura 6. Figura 6. UML de DurabilityServiceQoSPolicy. Los valores y el significado de sus propiedades son los siguientes El modelo de comunicaciones DCPS 19 de 47 • service_cleanup_delay. Controla cuando el servicio debe eliminar toda la información de una instancia de un dato, por lo que contiene la duración del mismo. • Dos propiedades relacionadas con la política de calidad de servicio “HistoryQosPolicy”. o history_kind: es una propiedad del tipo “HistoryQosPolicy”, o lo que es lo mismo es una “política de calida de servicio”. Controla la calidad de servicio del historial de mantenimiento. El valor por defecto es KEEP_LAST. o history_depth. Es un entero que especifica la profundidad de los datos que se almacenan en la política anterior. El valor por defecto es 1 • Tres valores relacionados con la política de la calidad de servicio “ResourceLimitsQoSPolicy”. Estos valores los debe implementar el DataReader que almacena el dato o max_samples. o max_instances. o max_samples_per_instance. Esta política sirve de puente en las configuraciones de las políticas afectadas por los valores definidos en la política DurabilityQoSPolicy. 3.2.3 DeadlineQoSPolicy Esta política de calidad de servicio, define el límite o plazo, que puede tener un elemento, afecta a un “Topic”, a los “DataReader” y a los “DataWriter”. Los valores ofrecidos y solicitados deben cumplir ciertos requisitos, que se detallarán más adelante. Puede cambiar a lo largo de la sesión de comunicación, siempre que los requisitos entre los valores ofrecidos y solicitados se cumplan. El diagrama de clase se puede observar en la figura 7. Figura 7. UML de DeadlineQoSPolicy. Como propiedades, tiene tan solo la característica de duración o “period”. El “DataReader”, espera una nueva muestra actualizada al menos una vez cada plazo indicado en el “deadline”. Debido a la importancia de ésta política de calidad de servicio, se muestra on detalle el funcionamiento en la figura 8. El modelo de comunicaciones DCPS 20 de 47 Figura 8. Comportamiento de Deadline dentro en los componentes DCPS. Esta política de calidad de servicio es muy útil cuando un “Topic” espera tener cada instancia actualizada periódicamente. Desde el punto de vista del “Publisher”, esta característica establece un contrato que la aplicación debe conocer. En el lado del “Subscriber”, la característica establece un mínimo requerimiento que se espera que los “Publishers” remotos puedan cumplir. Se debe tener en cuenta que cuando se ajustan los parámetros de calidad de servicio de un DataWriter y un DataReader, se evalúan cuáles son las características que pueden entrar en conflictos, y resolver las posibles incompatibilidades. Asumiendo que el “Reader” y el “Writer” finales de la comunicación tienen características compatibles, el servicio debe supervisar si esto se cumple en todo momento, para evitar que algún cambio altere estos cumplimientos. El valor que se ofrezca, deberá ser compatible con el valor solicitado, sí y sólo sí se cumple la desigualdad de la ecuación 2 se evalúa a TRUE. Ecuación 2. Relaciones entre los periodos de deadline ofrecidos y solicitados. “periodo ofrecido de deadline <= periodo solicitado de deadline” (2) El valor de la calidad de servicio “DEADLINE” debe ser coherente con el que se tenga en la calidad de servicio “TIME_BASED_FILTER”, la coherencia está cumplir la desigualdad que se muestra en la ecuación 3. El modelo de comunicaciones DCPS 21 de 47 Ecuación 3. Coherencia en los periodos de deadline y la separación temporal entre mensajes. deadline period >= minimun_separation (3) Deadline es una política de calidad de servicio básica sobre la que se asienta el soporte a tiempo real que proporciona DDS. 3.2.4 LatencyBudgetQoSPolicy Esta política de calidad de servicio, trata de los tiempos que la aplicación aprecia o solicita para el envío de mensajes. Los elementos a los que afecta son los “Topic”, los “DataReader” y los “DataWriter”. Los valores ofrecidos y solicitados deben cumplir ciertos requisitos que se detallarán más adelante. El diagrama de clase es el de la figura 9. Figura 9. UML de LatencyBudgetQoSPolicy. Esta política de calida de servicio, tiene tan solo una propiedad: “duration”. Ésta propiedad especifica el máximo aceptable de retraso desde el momento en que el dato es escrito hasta que el dato se escribe en la caché del receptor y el receptor es avisado. El valor por defecto es cero, lo que indica que el retraso debe ser minimizado. Gráficamente se puede ver cómo actúa en la figura 10. Figura 10. Comportamiento de la LatencyBudgetQoSPolicy. Esta política de calidad de servicio proporciona a la aplicación una manera de indicarle al “middleware” la urgencia de las comunicaciones de los datos. Con estos parámetros se puede ajustar las operaciones de comunicaciones. Esta política se considera aconsejable, aunque no se especifica la forma en la que se debe implementar. El valor ofrecido se considera compatible con el solicitado, sí y sólo sí se cumple la desigualdad de la ecuación 4. El modelo de comunicaciones DCPS 22 de 47 Ecuación 4. Relación entre las dureaciones de latencia ofrecidas y solicitadas en la política de calidad de servicio LatencyBudgetQoSPolicy. “duration” ofrecida <= “duration” solicitada (4) Al igual que la política “Deadline”, “LatencyBudget” es una política de calidad muy vinculada a un parámetro de calidad de servicio, en este caso la latencia. 3.2.5 LivelinessQoSPolicy Esta política de calidad de servicio controla el mecanismo y los parámetros necesarios por medio del cual el servicio se asegura que las entidades de la red que lo requieran (las que hayan negociado la política de calidad de servicio) se encuentran activas. Afecta al “Topic”, “DataReader” y “DataWriter”. En lo que respecta a los valores ofrecidos y solicitados, deben cumplir algunos requerimientos que más adelante se tratarán. Los valores no pueden variar a lo largo de la comunicación. El diagrama de clases es el de la figura 11. Figura 11. UML de LivelinessQoSPolicy. Las características que pueden tener son las siguientes. • kind. Determina el mecanismo y parámetros usados por la aplicación para determinar qué entidad (Entity) está activa. Se emplea para mantener la propiedad de una instancia en combinación con las características de la calidad de servicio OWNERSHIP. Puede tomar los siguientes valores. Los modos manuales son los que automáticamente es la aplicación la que toma la iniciativa de señalizar el valor de “liveness”. o AUTOMATIC. La infraestructura automáticamente señalizará el “liveliness” para los “DataWriters” a los requerimientos de “duration”. o MANUAL_BY_PARTICIPANT. El servicio asumirá hasta cuando al menos una entidad dentro de un DomainParticipant ha asumido su propio “liveliness”. o MANUAL_BY_TOPIC. El servicio sólo asume el “liveliness” del DataWriter si la aplicación ha impuesto liveliness en el DataWriter ella misma. • duration. Duración propiamente dicha a la que se ha hecho referencia en los casos anteriores. El valor por defecto es infinito. Esta calidad de servicio puede afectar a la calidad OWNERSHIP (Propiedad), por lo que los efectos colaterales deberán tenerse en cuenta. El comportamiento de esta El modelo de comunicaciones DCPS 23 de 47 política de calidad de servicio, puede representarse gráficamente como se ve en la figura 12. Figura 12. Comportamiento de los componentes de LivelinessQoSPolicy. Esta política de calidad de servicio tiene varias propiedades que deben soportar los objetos que se estén comunicando, que son actualizadas periódicamente o esporádicamente en el caso de cambios. Esto permite la personalización o adaptación a las aplicaciones de los requerimientos en términos de los tipos de fallos que se detecten por medio del mecanismo de ésta calidad de servicio. Si la propiedad “kind” tiene el valor AUTOMATIC, es adecuado para aplicaciones que sólo necesiten detectar fallos a nivel de proceso, pero no para errores lógicos dentro de un proceso. En este modo, el servicio toma la responsabilidad de renovar los contratos para que los componentes que participen en la comunicación tengan la certeza de que están todos activos. Este modo es el que produce una sobrecarga mínima. El modo MANUAL (tanto el modo MANUAL_BY_PARTICIPANT, como el MANUAL_BY_TOPIC) requiere que la aplicación, en el lado del “Publisher”, se responsabilice a afirmar periódicamente la vivacidad antes de que el contrato realizado expire a la entidad correspondiente (Participant, o Topic). Esta acción puede realizarse explícitamente por medio de la operación “assert_liveliness” o implícitamente por medio de una operación de escritura. Los dos modos, controlan la “granularidad” con la que se debe reafirmar la situación de vivo el elemento. El modo MANUAL_BY_PARTICIPANT, consiste en que con que sólo una “Entity” dentro del “Publisher” confirme su “liveliness”, se deduce que el resto de “Entities” dentro del mismo DomainParticipant están todavía vivos. El modo MANUAL_BY_TOPIC requiere que al menos una instancia dentro del DataWriter sea la que afirme su vivacidad. El valor ofrecido, se considera compatible con el valor solicitado, sí y sólo sí las siguientes condiciones se dan: “kind ofrecido >= kind solicitado” Para esta desigualdad se considera el orden para la comparación el mostrado en la ecuación 5. El modelo de comunicaciones DCPS 24 de 47 Ecuación 5. Orden de comparación de la propiedad “kind” en la política de calidad de servicio Liveliness. AUTOMATIC < MANUAL_BY_PARTICIPANT < MANUAL_BY_TOPIC (5) Los cambios deben ser detectados por el servicio con una granularidad temporal mayor o igual que la “lease_duration”. Esto asegura que el valor de “LivelinessChangedStatus” se actualiza al menos una vez durante cada “lease_duration” y los “Listeners” y “WaitSets” sean notificados dentro de “lease_duration”. 3.2.6 TimeBasedFilterQoSPolicy Esta política de calidad de servicio determina un filtro que permite a un “DataReader”, especificar que está interesado sólo (potencialmente) en un subconjunto de valores de los datos. Esta política de calidad se refiere únicamente a los “DataReader”, en lo que a calidad ofrecida y solicitada, no es necesario que sea la misma en ambos lados de la comunicación. Las propiedades de esta política de calidad de servicio pueden variar a lo largo de la comunicación. El diagrama de clase es el mostrado en la figura 13. Figura 13. UML de TimeBasedFilterQoSPolicy. Esta política de calidad de servicio, tiene una única propiedad llamada “miminum_separation”. El filtro establece que el DataReader no quiere recibir más de un valor cada “minimun_separation”, a pesar de lo rápido que ocurran los cambios. Es inconsistente para un DataReader tener un “minimun_separation” mayor que su periodo DEADLINE. Por defecto, el valor de “minimun_separation” vale 0, lo que indica que el DataReader está interesado en todos los valores. En la figura 14, se muestra una descripción gráfica de ésta política de calidad de servicio. Esta política permite a un DataReader indicar que no es necesario observar todas las muestras de cada instancia que sean publicadas en un Topic. Para ello se puede solicitar un dato cada “minimun_separation”. Esta calidad de servicio, se aplica separadamente a cada instancia. La utilidad de esta calidad de servicio es muy elevada, ya que permite a un DataReader, desacoplarse de un DataWriter en el caso de que las redes puedan variar su tiempo de transmisión. El hecho de solicitar esta calidad de servicio (poniendo un valor mayor de cero en la propiedad “minimun_separation” no la hace incompatible (es decir, es compatible) con las calidades de servicio HISTORY y RELIABILITY. TIME_BASED_FILTER especifica las muestras en las que está interesado el DataReader. Las calidades HISTORY y TIME_BASED_FILTER afectan al comportamiento del “middleware”, con respecto a las muestras se haya determinado que son interesantes para el DataReader, es decir, estas dos calidades de servicio se aplican después de que se haya aplicado el TIME_BASED_FILTER. El modelo de comunicaciones DCPS 25 de 47 La propiedad “minimun_separation” debe ser compatible con la propiedad “period” de la calidad de servicio DEADLINE. Para que se considere compatible, se debe verificar la desigualdad de la ecuación 6. Ecuación 6. Condición de compatibilidad entre las políticas de calidad de servicio TimeBasedFilter y Deadline. period >= minimun_separation (6) Las comprobaciones de la compatibilidad de las dos calidades de servicio deben hacerse en el momento en que sean instanciadas. Figura 14. Comportamiento de los componentes de TimeBasedFilterQoSPolicy. 3.2.7 LifespanQoSPolicy Ésta política de calidad de servicio, especifica la máxima duración de validez del dato escrito por el DataWriter. El valor por defecto es infinito. Esta política afecta al “DataWriter” y al “Topic”. A la hora de negociarse, se debe negociar en el “Publisher” o el “Subscriber”, pero no en ambos. El valor puede variar a lo largo de la sesión de comunicaciones. El diagrama de clases se muestra en la figura 15. El modelo de comunicaciones DCPS 32 de 47 Figura 22. UML de HistoryQoSPolicy. Esta política de calidad de servicio tiene dos propiedades, que son las siguientes. • kind. Tipo de Historia que se mantiene en las entidades correspondientes. o KEEP_LAST. En el lado del Publicador, el servicio sólo se encargará de mantener un número determinado de muestras de cada dato, indicado por el parámetro “depth” gestionadas por el DataWriter. En el lado del Suscriptor, el DataReader deberá mantener las últimas “depth” muestras de cada instancia (identificadas por sus “key”). El valor por defecto del tipo (kind) es éste, con un “depth” de 1. Estas muestras permanecen hasta que se hace una lectura por medio de “take”. o KEEP_ALL. En el Publicador el servicio deberá mantener todas las muestras (representando cada valor escrito) de cada instancia de los datos (identificada por su “key”) gestionados por el DataWriter. En el lado del Subscriptor indica que deben mantenerse todas las instancias de los datos (identificadas por sus “key”) gestionadas por su DataReader. Estas muestras se mantienen mientras hasta que se lean por medio de una operación “take”. El valor de depth no se tiene en cuenta. Esto último supone que el valor será LENGTH_UNLIMITED. • depth. Profundidad de muestras que deben ser mantenidas. La configuración del valor “depth” de la calidad de servicio HISTORY, debe ser consistente con el valor de la propiedad “max_samples_per_instance” de la política de servicio RESOURCE_LIMITS de tal manera que debe constatarse la desigualdad mostrada en la fórmula 17. Ecuación 17. Fórmula que define la consistencia en la política de calidad de servicio History. “depth” <= “max_smples_per_instance” (17) Un ejemplo del comportamiento en los componentes por parte de esta política de calidad de servicio, puede verse en la figura 23. El modelo de comunicaciones DCPS 33 de 47 Figura 23. Comportamiento de los componentes de HistoryQoSPolicy. 3.3.6 ResourceLimitsQoSPolicy Esta característica de la calidad de servicio especifica los recursos que el Servicio puede consumir de acuerdo con la QoS que se haya determinado. El diagrama de clases es el que se muestra en la figura 24. Figura 24. UML de ResourceLimitsQoSPolicy. Las propiedades que tiene esta política de calidad de servicio son las siguientes. • max_samples. Determina el número máximo de instancias de datos, que un DataWriter o un DataReader pueden gestionar de entre todas las instancias asociadas con él. Representa el máximo número de muestras que el middleware puede almacenar. Es inconsistente para este valor que sea menor que el número max_samples_per_instance. • max_instances. Representa el máximo número de instancias que un DataWriter puede gestionar. El modelo de comunicaciones DCPS 34 de 47 • max_samples_per_instance. Representa el máximo número de muestras de cualquier instancia. Esta política de servicio controla los recursos que el servicio puede o debe usar para cumplir con los requerimientos que la aplicación u otras políticas de calidad de servicio soliciten. En el caso de que los objetos DataWriter estén enviando datos más rápido de los que el DataReader puede recibir, el “middleware” puede, eventualmente, ir en contra de algunas de las limitaciones de recursos impuestas por algunas de las calidades de servicio. El comportamiento, en estos casos, depende de la calidad de servicio RELIABILITY, si está configurada como BEST_EFFORT, entonces se le permite al servicio perder muestras. Si está configurada como RELIABLE, el servicio bloqueará al DataWriter o descartará muestras en el DaraReader, para no perder muestras. La cantidad de muestras que se pueden mantener en un DomainParticipant (especialmente en lo que concierne al DataWriter y sobre todo al DataReader). En DDS se especifica una constante: LENGTH_UNLIMITED que se puede emplear para indicar la ausencia de límites particulares en los parámetros de ésta calidad de servicio. Las condiciones que deben darse para que ésta calidad de servicio sea coherente son las siguientes. La propiedad max_samples debe ser coherente con max_samples_per_instance tal que se cumpla la ecuación 18. Ecuación 18. Condición de coherencia de la política de calidad de servicio ResourceLimits. “max_samples” >= “max_samples_per_instance” (18) El valor de la propiedad “max_samples_per_instance” debe ser coherente con el valor “depth” de la calidad de servicio HISTORY, verificándose que se cumple la desigualdad definida en 19. Ecuación 19. Condición de coherencia entre las políticas de calidad de servicio ResourceLimits e History. depth <= max_samples_per_instance (19) Es importante que cuando se configure esta calida de servicio, se comprueben los valores para que sean consistentes. Un ejemplo gráfico del comportamiento de la política de calidad de servicio se puede observar en la figura 25. El modelo de comunicaciones DCPS 35 de 47 Figura 25. Comportamiento de los componentes de ResourceLimitsQoSPolicy. 3.3.7 OwnershipQoSPolicy Esta política de calidad de servicio, controla si el servicio permite a varios objetos “DataWriter” actualizar la misma instancia. El diagrama de clase es el mostrado en la figura 26. Figura 26. UML de OwnershipQoSPolicy. La propiedad que tiene es “kind”, que puede tomar los siguientes valores, que especifican si se permite a muchos DataWriters escribir la misma instancia • SHARED. Indica que el propietario es compartido para cada instancia. Esto implica que múltiples escritores tienen permitido escribir sobre la misma instancia, y todas las actualizaciones serán accesibles por parte de los lectores. Lo que es lo mismo, no hay un concepto de propiedad para las instancias. Este valor es por defecto si la calidad de servicio no puede soportar esta característica. • EXCLUSIVE. Indica que cada instancia es propietaria de un DataWriter. Aunque el propietario puede variar dinámicamente. La selección del propietario es controlada por la política de calidad OWNERSHIP_STRENGTH. El modelo de comunicaciones DCPS 36 de 47 Esta calidad de servicio se utiliza para “capturar” una instancia (identificada por el binomio: Topic+Key) de un objeto de datos. Cuando se activa, sólo unos DataWriters concretos podrán escribir en las instancias de datos. Esta calidad de servicio restringirá por tanto a los DataWriters que también empleen la calidad de servicio OWNERSHIP_STRENGTH que es la que determina el orden de preferencia de escritura en los posibles conflictos de DataWriters que pueden aparecer. Por tanto ambas calidades de servicio están estrechamente relacionadas. 3.3.8 OwnershipStrengthQoSPolicy Esta política de calidad de servicio especifica la “fuerza” que tiene un “DataWriter” a la hora de negociar algunos aspectos en el envío de mensajes. El diagrama de clase correspondiente es el expuesto en la figura 27. Figura 27. UML de OwnershipStrengthQoSPolicy. Esta política de calidad de servicio tiene una única propiedad, “value” que especifica el valor de potencia de propiedad de los objetos “DataWriter”. Se emplea para arbitrar entre múltiples “DataWriters” cuando desean escribir en la misma instancia. En la figura 28, se puede ver con detalle cómo funciona esta política. El modelo de comunicaciones DCPS 37 de 47 Figura 28. Comportamiento de los componentes de OwnershipStrengthQoSPolicy. El valor de cada OWNERSHIP_STRENGTH se emplea para aportar una prioridad de escritura frente al resto de los “DataWriter”. El arbitraje de la calidad de servicio la realiza el “DataReader”. 3.4 Gestión de los componentes 3.4.1 PartitionQoSPolicy Esta política de calidad de servicio, permite introducir el concepto de la partición lógica de componentes dentro de una partición física de componentes. Ésta partición está inducida por medio de un dominio. El diagrama de clase es el mostrado en la figura 29. Figura 29. UML de PartitionQoSPolicy. Esta política de calidad contiene una sola característica: “name”. Esta propiedad es un conjunto de cadenas de caracteres que introduce una partición lógica entre los Topics visibles por el Publisher y el Subscriber. Un DataWriter dentro de un Publisher sólo se comunicará con un DataReader en un Subscriber en el caso de que el Publisher y el Subscriber tengan en común el partition name. El modelo de comunicaciones DCPS 38 de 47 Para que un DataReader pueda ver los cambios hechos en una instancia de un DataWriter, no sólo debe coincidir el Topic, sino también deben compartir una “Partition” común. Cada “string” en la lista definida en una QoS, define el nombre de una partición. Los errores en el “matching” de esta calidad de servicio, no se considera una incompatibilidad (lógicamente). Esta política es variable. Un cambio en esta política, puede potencialmente modificar el “matching” de un DataReader ya existente, o de las QoS de un DataWriter ya existente. Los nombres de las particiones, pueden ser expresiones regulares, que incluyan caracteres comodines, tal como se define en POSIX API (1003.2-1992 sección B.6). Una Entity puede pertenecer sólo a un dominio, pero puede estar en múltiples particiones. En lo que concierne al servicio DDS, cada instancia única de un dato se identifica por la t-upla (domainId, Topic, Key), esto implica que las particiones van a aislar ciertos datos. En la figura 30, se pueden ver gráficamente éstos aspectos. Figura 30. Comportamiento de los componentes de PartitionQoSPolicy. 3.4.2 EntityFactoryQoSPolicy Esta política de calidad de servicio, controla el comportamiento de una entidad, cuando actúa como factoría de otras entidades. En otras palabras, controla los efectos de las funciones de creación y eliminación de entidades. El diagrama de clases es el mostrado en la figura 31. El modelo de comunicaciones DCPS 39 de 47 Figura 31. UML de EntityFactorytQoSPolicy. La única propiedad que tienes es “autoenable_created_entities” y especifica si la factoría habilita automáticamente cada entidad que crea. 3.4.3 WriterDataLifecycleQoSPolicy Define el comportamiento del DataWriter tendrá sobre las instancias de dato que gestiona. El diagrama de clases es el mostrado en la figura 32. Figura 32. UML de WriterDataLifecycleQoSPolicy. La única propiedad que tiene es “autodispose_unregistered_instances”, esta propiedad indica que las instancias no registradas de DataWriters también están dispuestas a funcionar. 3.4.4 ReaderDataLifecycleQoSPolicy Especifica el comportamiento del DataReader de acuerdo con el ciclo de vida de las instancias de datos que gestiona. El diagrama de clases de la política es el mostrado en la figura 33. Figura 33. UML de ReaderDataLifecycleQoSPolicy. Esta política contiene dos propiedades, que son las siguientes. El modelo de comunicaciones DCPS 40 de 47 • autopurge_nowriter_samples_delay. Indica la duración que el DataReader debe mantener o retener la información de las instancias que tengan en instance_state en modo NOT_ALIVE_NO_WRITERS. • autopurge_disposed_samples_delay. Indica la duración que el DataReader debe mantener o retener la información de las instancias que tengan en instance_state en modo NOT_ALIVE_DISPOSED. El modelo de comunicaciones DCPS 41 de 47 4 Análisis 4.1 Resumen de las políticas de calidad de servicio de DDS Las políticas de calidad de servicio especificadas en el DCPS del modelo DDS propuesto por OMG, son muy variadas, por lo que parece aconsejable ofrecer una visión general de todas las políticas. Para ello se han organizado en la tabla 2, en la que se exponen las políticas de calidad de servicio en filas, y en columnas las características de cada política de calidad de servicio. • Columna con los elementos del modelo DCPS sobre los que se aplica la política de calidad de servicio concreta. Estos elementos son los siguientes: o DP = Domain Participant o DR = Data Reader o DW = Data Writer o Tp. = Topic o Pb. = Publisher o Sb. = Subscriber • Columna RxO (Requested/Offered) con las características de negociación de los valores de las políticas de calidad de servicio, esta columna puede tomar los siguientes valores. o Sí. Indica que la política de calidad de servicio debe estar tanto en el “Publishing” 1 como en el “Subscriber” y la combinación de valores de los elementos implicados debe ser compatible. o No. Indica que la calidad de servicio debe estar tanto en el “Publishing” y en el “Subscriber”, pero los dos valores pueden ser independientes. Esto implica que todas las posibles combinaciones son compatibles. o N/A. Indica que la política puede estar tanto en el lado del “Publishing” como del “Subscriber”, pero no en ambos. No se aplica ninguna comprobación de compatibilidad. • Columna Ch, (Changeable) que muestra la variabilidad de la política de calidad de servicio. Esta columna indica si la calida de servicio puede ser alterada después de que la Entidad a la que se está aplicando la calidad de servicio esté activada, o lo que es lo mismo en funcionamiento. En la tabla, se ha creído conveniente escribir los nombres de las políticas de calidad de servicio con la misma denominación que tienen como clases en el modelo de clases que propone OMG para el DCPS. 1 Sería interesante determinar si usar los términos en inglés o las traducciones en castellano. Quizás emplear el término en inglés sea más sencillo, ya que no hay que complicarse con la traducción (muy adecuado en casos como “middleware”.