Servicio de distribución de datos

Este artículo contiene contenido escrito como un anuncio . Ayúdenos a mejorarlo eliminando el contenido promocional y los enlaces externos inapropiados , y agregando contenido enciclopédico escrito desde un punto de vista neutral . ( Julio de 2020 ) ( Aprenda cómo y cuándo eliminar este mensaje )

Este artículo puede basarse excesivamente en fuentes demasiado relacionadas con el tema , lo que podría impedir que el artículo sea verificable y neutral . Ayúdenos a mejorarlo reemplazándolos por citas más apropiadas de fuentes independientes, confiables y de terceros . ( Julio de 2014 ) ( Aprenda cómo y cuándo eliminar este mensaje )

El Servicio de distribución de datos ( DDS ) para sistemas en tiempo real es un estándar de máquina a máquina (a veces llamado middleware o marco de conectividad) del Object Management Group (OMG) que tiene como objetivo permitir intercambios de datos confiables , de alto rendimiento , interoperables , en tiempo real y escalables utilizando un patrón de publicación-suscripción .

DDS aborda las necesidades de intercambio de datos en tiempo real de aplicaciones dentro del sector aeroespacial, de defensa, de control de tráfico aéreo , de vehículos autónomos , de dispositivos médicos, de robótica, de generación de energía, de simulación y pruebas, de gestión de redes inteligentes , de sistemas de transporte y otras aplicaciones.

DDS es un middleware de redes que simplifica la programación de redes complejas . Implementa un patrón de publicación-suscripción para enviar y recibir datos, eventos y comandos entre los nodos . Los nodos que producen información (publicadores) crean "temas" (por ejemplo, temperatura, ubicación, presión) y publican "muestras". DDS envía las muestras a los suscriptores que declaran un interés en ese tema.

DDS se encarga de las tareas de transferencia: direccionamiento de mensajes, agrupación y desagrupación de datos (para que los suscriptores puedan estar en plataformas diferentes a las del publicador), entrega, control de flujo, reintentos, etc. Cualquier nodo puede ser publicador, suscriptor o ambos simultáneamente.

El modelo de publicación-suscripción de DDS prácticamente elimina la programación de red compleja para aplicaciones distribuidas. ^{[ cita requerida ]}

DDS admite mecanismos que van más allá del modelo básico de publicación-suscripción. ^{[ cita requerida ]} El beneficio clave es que las aplicaciones que utilizan DDS para sus comunicaciones están desacopladas. Se necesita dedicar poco tiempo de diseño a gestionar sus interacciones mutuas. En particular, las aplicaciones nunca necesitan información sobre las otras aplicaciones participantes, incluida su existencia o ubicación. DDS gestiona de forma transparente la entrega de mensajes sin requerir la intervención de las aplicaciones del usuario, lo que incluye:

• determinar quién debe recibir los mensajes
• Dónde se encuentran los destinatarios
• ¿Qué sucede si no se pueden entregar los mensajes?

DDS permite al usuario especificar parámetros de calidad de servicio (QoS) para configurar mecanismos de descubrimiento y comportamiento por adelantado. Al intercambiar mensajes de forma anónima, DDS simplifica las aplicaciones distribuidas y fomenta programas modulares y bien estructurados. ^{[ cita requerida ] DDS también maneja automáticamente el intercambio en caliente de publicadores redundantes si falla el primario. [ cita requerida ]} Los ^{suscriptores siempre} obtienen la muestra con la prioridad más alta cuyos datos aún son válidos (es decir, cuyo período de validez especificado por el publicador no ha expirado) ^{[ cita requerida ]} . También cambia automáticamente al primario cuando se recupera ^{[ cita requerida ]} .

Hay implementaciones de DDS tanto de software propietario como de código abierto . Estas incluyen interfaces de programación de aplicaciones (API) y bibliotecas de implementaciones en Ada , C , C++ , C# , Java , Python , Scala , Lua , Pharo , Ruby y Rust .

Los proveedores de DDS participaron en demostraciones de interoperabilidad en las reuniones técnicas de primavera de OMG de 2009 a 2013. ^{[1] [2] [3] [4] [5] [6]}

Durante las demostraciones, cada proveedor publicó y se suscribió a los temas de los demás utilizando un conjunto de pruebas llamado demostración de formas. Por ejemplo, un proveedor publica información sobre una forma y los demás proveedores pueden suscribirse al tema y mostrar los resultados en su propia pantalla de formas. Cada proveedor se turna para publicar la información y el otro se suscribe. Dos cosas hicieron posibles las demostraciones: el protocolo DDS-I o Real-Time Publish-Subscribe (RTPS), ^[7] y el acuerdo para utilizar un modelo común.

En marzo de 2009, tres proveedores demostraron la interoperabilidad entre los productos individuales e independientes que implementaron el protocolo de publicación-suscripción en tiempo real OMG versión 2.1 a partir de enero de 2009. La demostración incluyó el descubrimiento de los publicadores y suscriptores de cada uno en diferentes plataformas de SO ( Microsoft Windows y Linux ) y admitió comunicaciones de red de multidifusión y unidifusión . ^[1]

La demostración de interoperabilidad de DDS utilizó escenarios como:

• Conectividad básica a la red mediante el Protocolo de Internet (IP)
• Descubrimiento de editores y suscriptores
• Calidad de servicio (QoS) Compatibilidad entre solicitante y oferente
• Redes tolerantes a retrasos
• Múltiples temas e instancias de temas
• Titularidad exclusiva de los temas
• Filtrado de contenido de datos de temas, incluidos datos de tiempo y geográficos.

El desarrollo de la especificación DDS comenzó en 2001. En 2004, el Object Management Group (OMG) publicó la versión 1.0 de DDS. ^[8] La versión 1.1 se publicó en diciembre de 2005, ^[9] la 1.2 en enero de 2007, ^[10] y la 1.4 en abril de 2015. ^[11] DDS está cubierto por varias patentes estadounidenses, ^{[12] [13] [14] [15]} entre otras.

La especificación DDS describe dos niveles de interfaces:

• Un nivel inferior de publicación-suscripción centrado en datos (DCPS) que apunta a la entrega eficiente de la información adecuada a los destinatarios adecuados.
• Una capa de reconstrucción local de datos superior opcional (DLRL), que permite una integración sencilla de DDS en la capa de aplicación .

Otros estándares relacionados siguieron al documento central inicial. La Especificación del Protocolo de Interoperabilidad de Publicación-Suscripción en Tiempo Real (DDS) garantizaba que la información publicada sobre un tema utilizando la implementación DDS de un proveedor fuera consumible por uno o más suscriptores que utilicen las mismas implementaciones DDS de un proveedor o de proveedores diferentes. Aunque la especificación está dirigida a la comunidad DDS, su uso no está limitado. Las versiones 2.0 se publicaron en abril de 2008, la versión 2.1 en noviembre de 2010, la 2.2 en septiembre de 2014 y la 2.3 en mayo de 2019. ^[7]

DDS para Lightweight CCM (dds4ccm) ofrece un patrón arquitectónico que separa la lógica empresarial de las propiedades no funcionales. Una extensión de 2012 agregó soporte para transmisiones. ^[16] Un PSM de lenguaje Java 5 para DDS definió un enlace de lenguaje Java 5, conocido como un Modelo específico de la plataforma (PSM) para DDS. Especificó solo la parte de publicación-suscripción centrada en datos (DCPS) de la especificación DDS; además, abarca las API DDS introducidas por DDS-XTypes y DDS-CCM. DDS-PSM-Cxx define el enlace de lenguaje ISO/IEC C++ ^[17] PSM, conocido como un Modelo específico de la plataforma (PSM) para DDS. Proporciona una nueva API C++ para programar DDS que es más natural para un programador C++. ^[18] La especificación proporciona asignaciones para la interfaz de programación de aplicaciones (API) especificada en DDS-XTypes y el acceso a los perfiles de calidad de servicio (QoS) especificados en DDS-CCM.

Los tipos de temas extensibles y dinámicos para DDS (DDS-XTypes) proporcionaron soporte para la comunicación de publicación-suscripción centrada en datos donde los temas se definen con estructuras de datos específicas. Para ser extensibles , los temas DDS utilizan tipos de datos definidos antes del tiempo de compilación y se utilizan en todo el espacio de datos global DDS. Este modelo es deseable cuando la verificación de tipos estáticos es útil. ^[19] Un perfil de lenguaje de modelado unificado (UML) especificó los dominios y temas DDS para que sean parte del modelado de análisis y diseño. ^[20] Esta especificación también definió cómo publicar y suscribir objetos sin describir primero los tipos en otro lenguaje, como XML u OMG IDL. ^[21] Un lenguaje de definición de interfaz (IDL) se especificó en 2014 independientemente del capítulo 3 de la especificación Common Object Request Broker Architecture (CORBA). Este IDL 3.5 era compatible con la especificación CORBA 3, pero se extrajo como su propia especificación, lo que le permitió evolucionar independientemente de CORBA. ^[22]

Otros protocolos que se pueden mencionar son: DDS-XRCE (DDS for eXtremely Resource Constrained Environments), este protocolo de especificación permite la comunicación entre dispositivos de recursos limitados, como por ejemplo un microcontrolador y una red DDS. Permite publicar y suscribirse a temas a través de un servicio intermedio en un dominio DDS ^[23] y DDS-RPC (RPC Over DDS) que define llamadas a procedimientos remotos. Estas proporcionan una comunicación de solicitud/respuesta bidireccional y determinan servicios distribuidos, y se detallan mediante una interfaz de servicio. También admite la invocación de métodos tanto sincrónicos como asincrónicos. ^[24]

A partir de la versión 1.4 de DDS en 2015, la capa DLRL opcional se trasladó a una especificación separada. ^[25]

• Software intermedio
• Entorno informático de arquitectura abierta
• Object Management Group (OMG), organismo de normalización que desarrolló la especificación