2.2.1.2.概念大纲

2.2.1.2.1.概述

图 2‑1 概述

Information flows with the aid of the following constructs[1]: Publisher and DataWriter on the sending side; Subscriber and DataReader on the receiving side.

信息通过在发送方的Publisher、DataWriter和在接收方的Subscriber、DataReader进行流动。

 

• A Publisher is an object responsible for data distribution. It may publish data of different data types. A DataWriter acts as a typed[2] accessor to a publisher. The DataWriter is the object the application must use to communicate to a publisher the existence and value of data-objects of a given type. When data-object values have been communicated to the publisher through the appropriate data-writer, it is the publisher’s responsibility to perform the distribution (the publisher will do this according to its own QoS, or the QoS attached to the corresponding data-writer). A publication is defined by the association of a data-writer to a publisher. This association expresses the intent of the application to publish the data described by the data-writer in the context provided by the publisher.
• 发布者（Publisher）是负责数据分发的对象。 它可以发布不同数据类型的数据。 DataWriter充当发布者的类型化访问者。 DataWriter是应用程序必须用来与发布者通信的对象，通信内容包括给定类型的数据对象是否存在和其值。 当数据对象值通过适当的DataWriter传送给发布者时，发布者有责任执行数据分发（发布者将根据其自己的QoS或附加到相应DataWriter的QoS来执行此操作）。一次发布由DataWriter与发布者的关联来定义。 该关联表达了应用程序在由发布者提供的上下文中发布由DataWriter描述的数据的意图。

 

• A Subscriber is an object responsible for receiving published data and making it available (according to the Subscriber’s QoS) to the receiving application. It may receive and dispatch data of different specified types. To access the received data, the application must use a typed DataReader attached to the subscriber. Thus, a subscription is defined by the association of a data-reader with a subscriber. This association expresses the intent of the application to subscribe to the data described by the data-reader in the context provided by the subscriber.
• 订阅者(Subscriber)是负责接收发布的数据并将其提供给准备接收的应用程序（根据订阅者的QoS）的对象。 它可以接收和分发指定的不同类型的数据。 要访问收到的数据，应用程序必须使用附加到订阅者的类型化的DataReader。 因此，订阅是通过数据DataReader与订阅者的关联来定义的。 该关联表达了应用程序在用户提供的上下文中订阅由DataReader的数据的意图。

 

Topic objects conceptually fit between publications and subscriptions. Publications must be known in such a way that subscriptions can refer to them unambiguously. A Topic is meant to fulfill that purpose: it associates a name (unique in the domain[3]), a data-type, and QoS related to the data itself. In addition to the topic QoS, the QoS of the DataWriter associated with that Topic and the QoS of the Publisher associated to the DataWriter control the behavior on the publisher’s side, while the corresponding Topic, DataReader, and Subscriber QoS control the behavior on the subscriber’s side.

主题对象在概念上适合发布和订阅。 发布必须以一种方式公布，以让订阅可以明确地引用它们。 主题旨在实现该目的：它将名称（域中唯一）、数据类型以及与数据本身相关的QoS相关联。 除了主题QoS之外，与该Topic关联的DataWriter的QoS以及与DataWriter关联的Publisher的QoS控制发布方的行为，而相应的Topic、DataReader和Subscriber的QoS控制订阅方的行为 侧。

 

When an application wishes to publish data of a given type, it must create a Publisher (or reuse an already created one) and a DataWriter with all the characteristics of the desired publication. Similarly, when an application wishes to receive data, it must create a Subscriber (or reuse an already created one) and a DataReader to define the subscription.

应用程序希望发布给定类型的数据时，必须创建一个Publisher（或重新使用已创建的Publisher）和一个具有所需发布的所有特征的DataWriter。 同样，应用程序希望接收数据时，必须创建Subscriber（或重新使用已创建的Subscriber）和DataReader来定义订阅。

 

 

[1] All those constructs are local to the application part. Actually they play the role of proxies to the service. 所有这些构造对应用程序部分都是本地的。 其实他们扮演着代理服务的角色。

[2] ‘typed’ means that each DataWriter object is dedicated to one application data-type. ‘类型化’意味着每个DataWriter对象专用于一个应用程序数据类型。

[3] Broadly speaking, a domain represents the set of applications that are communicating with each other. This concept is defined more precisely in 2.2.1.2.2, Overall Conceptual Model and 2.2.2.2.1, DomainParticipant Class.

1.Data-Centric Publish-Subscribe (DCPS)

1.1. 概述

This clause describes DCPS. DCPS defines the functionality used by an application to publish and subscribe to the values of data objects. It allows:

本条款描述DCPS。DCPS定义应用程序用于发布和订阅数据对象值的功能，它允许：

 

• Publishing applications to identify the data objects they intend to publish, and then provide values for these objects.
• 发布应用程序标识他们打算发布的数据对象，然后为这些对象提供值。

 

• Subscribing applications to identify which data objects they are interested in, and then access their data values.
• 订阅应用程序标识他们感兴趣的数据对象，然后访问它们的数据值。

 

• Applications to define topics, to attach type information to the topics, to create publisher and subscriber entities, to attach QoS policies to all these entities and, in summary, to make all these entities operate.
• 应用程序定义主题，将类型信息附加到主题，创建发布者和订阅者实体，将QoS策略附加到所有这些实体，并总而言之使所有这些实体都能够运行（operate）。

 

The description is organized into two sub clauses:

描述分为两个子条款：

 

• The Platform Independent Model (PIM).
• 平台无关模型（PIM）

 

• The Platform Specific Model (PSM) for the OMG IDL platform based on the PIM.
• 基于PIM的OMG IDL平台的平台相关模型（PSM）。

 

1.2. 平台相关模型（PIM）

1.2.1. 概述和设计原理

1.2.1.1.格式和约定

The purpose of this sub clause is to provide an operational overview of the DCPS PIM. To do so, it introduces many terms. Some of them are common terms whose meaning, in the context of publish-subscribe, is different from common usage. In cases where it is deemed appropriate, such terms will be italicized. Other terms are unique to publish-subscribe and/or to this specification, and are incorporated as key elements of the Class Model. The first time such terms are used, they will be formatted with Bold-italics[1]. Subsequent occurrences may not be highlighted in any way.

本小节的目的是提供DCPS PIM的操作概述。 为此，本小节引入了许多术语。其中一些是常用术语，但在发布-订阅模型方面的含义与常见用法不同。 适当的时候，这些条款将被斜体化。 其他术语是发布-订阅模型和/或本规范所独有的，并且被合并为类模型的关键元素。 第一次使用这些术语时，它们将用采用加粗斜体格式，后续出现时将可能不会以任何方式突出显示。

 

In addition to the UML diagrams, all the classes that constitute the Service are documented using tables. The format used to document these classes is shown below.

除了UML图之外，构成服务的所有类都采用表格的形式进行描述。 下面显示了用于记录这些类的格式。

 

<class name>
attributes
<attribute name>	<attribute type>
…
operations
<operation name>		<return type>
	<parameter>	<parameter type>
	…	…
…		…

 

The operation <paramter> can contain the modifier “in,” “out,” or “inout” ahead of the parameter name. If this modifier is omitted, it is implied that the parameter is an “in” parameter.

操作（operation）的参数<parameter>可以在参数名称之前包含修饰符“in”，“out”或“inout”。 如果省略此修饰符，则暗示参数是“in”（输入）参数。

 

In some cases the operation parameters or return value(s) are a collection with elements of a given <type>. This is indicated with the notation “<type>[].” This notation does not imply that it will be implemented as an array. The actual implementation is defined by the PSM: it may end up being mapped to a sequence, a list, or other kind of collection.

某些情况下，操作参数或返回值是给定<type>的元素的集合，用符号“<type> []”表示。这个表示法并不意味着它将实现为一个数组。实际的实现由PSM定义：它可能最终映射到序列、列表或其他类型的集合。

 

For example, the class named ‘MyClass’ below has a single attribute, named ‘my_attribute’ of type ‘long’ and a single operation ‘my_operation’ that returns a long. The operation takes four parameters. The first, ‘param1,’ is an output parameter of type long; the second, ‘param2,’ an input-output parameter of type long; the third, ‘param3,’ is an input parameter (the “in” modifier is implied by omission) of type long; and the fourth, ‘param4,’ is also an input parameter of type collection of longs.[2]

例如，下面名为’MyClass’的类有一个属性，名为’my_attribute’，类型为’long’，单个操作’my_operation’返回一个long。 该操作需要四个参数。 第一个参数’param1’是long类型的输出参数; 第二个参数“param2”是long类型的输入输出参数; 第三个参数“param3”是一个long类型的输入参数（省略暗含的“in”修饰符）; 而第四个“param4”也是long类型集合的输入参数。

 

MyClass
attributes
my_attribute	long
operations
my_operation		long
	out: param1	long
	inout: param2	long
	param3	long
	in: param4	long[]

 

 

At the PIM level we have modeled errors as operation return codes typed ReturnCode_t. Each PSM may map these to either return codes or exceptions. The complete list of return codes is indicated below.

在PIM级别，我们将错误建模为操作的类型为ReturnCode_t返回码。每个PSM可以将这些映射到返回码或异常。 返回码的完整列表如下所示。

 

 

Return Codes
OK	Successful return. 成功返回。
ERROR	Generic, unspecified error. 一般未指定的错误。
BAD_PARAMETER	Illegal parameter value. 非法参数值。
UNSUPPORTED	Unsupported operation. Can only be returned by operations that are optional. 未支持的操作，只有可选的操作才会返回此代码。
ALREADY_DELETED	The object target of this operation has already been deleted. 此操作的对象目标已被删除。
OUT_OF_RESOURCES	Service ran out of the resources needed to complete the operation. 服务耗尽完成操作所需的资源。
NOT_ENABLED	Operation invoked on an Entity that is not yet enabled. 在尚未启用的实体（Entity）上调用操作。
IMMUTABLE_POLICY	Application attempted to modify an immutable QosPolicy. 应用程序试图修改一个不可变的QosPolicy。
INCONSISTENT_POLICY	Application specified a set of policies that are not consistent with each other. 应用程序指定了一组彼此不一致的策略。
PRECODITION_NOT_MET	A pre-condition for the operation was not met. 操作的前提条件不满足
TIMEOUT	The operation timed out. 操作超时。
ILLEGAL_OPERATION	An operation was invoked on an inappropriate object or at an inappropriate time (as determined by policies set by the specification or the Service implementation). There is no precondition that could be changed to make the operation succeed. 在不适当的对象上或在不适当的时间调用操作（由规范或服务实现设置的策略确定）。 没有可以改变的使操作成功的先决条件。
NO_DATA	Indicates a transient situation where the operation did not return any data but there is no inherent error. 表示操作没有返回任何数据且没有固有错误的临时情况。

 

Any operation with return type ReturnCode_t may return OK, ERROR, or ILLEGAL_OPERATION. Any operation that takes an input parameter may additionally return BAD_PARAMETER. Any operation on an object created from any of the factories may additionally return ALREADY_DELETED. Any operation that is stated as optional may additionally return UNSUPPORTED. The return codes OK, ERROR, ILLEGAL_OPERATION, ALREADY_DELETED, UNSUPPORTED, and BAD_PARAMETER are the standard return codes and the specification won’t mention them explicitly for each operation. Operations that may return any of the additional (non-standard) error codes above will state so explicitly.

任何返回值类型为ReturnCode_t的操作都可能返回OK, ERROR, or ILLEGAL_OPERATION。任何有输入参数的操作另外还可能返回BAD_PARAMETER。针对由工厂创建的对象的操作还有可能返回ALREADY_DELETED。声明为可选的操作可能会额外返回UNSUPPORTED。 返回码OK，ERROR、ILLEGAL_OPERATION、ALREADY_DELETED、NSUPPORTED和BAD_PARAMETER是标准的返回代码，规范不会对每个操作明确提及它们。 可能返回上述任何附加（非标准）的错误代码的操作将明确陈述。

 

It is an error for an application to use an Entity that has already been deleted by means of the corresponding delete operation on the factory. If an application does this, the result is unspecified and will depend on the implementation and the PSM. In the cases where the implementation can detect the use of a deleted entity, the operation should fail and return ALREADY_DELETED.

应用程序使用已通过工厂上的相应删除操作删除的实体是错误的。 如果应用程序执行此操作，则结果未指定，并取决于实现和PSM。 在实现可以检测到使用已删除的实体的情况下，操作会失败并返回ALREADY_DELETED。

 

[1] In this case, the written name is exactly the one of the corresponding class, which forbids the use of the plural. In case this would lead to ambiguity, it has been followed by ‘objects’ to state that there may not be only one of these.

[2] That is, a collection where the type of each element is ‘long’.

1.概述

1.1. 介绍

The DDS specification describes a Data-Centric Publish-Subscribe (DCPS) model for distributed application communication and integration. This specification defines both the Application Interfaces (APIs) and the Communication Semantics (behavior and quality of service) that enable the efficient delivery of information from information producers to matching consumers.

DDS规范描述了支持分布式应用程序通信和集成的以数据为中心的发布订阅（DCPS）模型。 本规范定义了应用程序接口（API）和通信语义（行为和服务质量），使信息生产者能够有效地将信息传递给匹配的消费者。

 

The purpose of the DDS specification can be summarized as enabling the “Efficient and Robust Delivery of the Right Information to the Right Place at the Right Time.”

DDS规范的目的可以概括为实现“有效且稳健地将正确的信息在正确的时间传输到正确的地方。”

 

The expected application domains require DCPS to be high-performance and predictable as well as efficient in its use of resources. To meet these requirements it is important that the interfaces are designed in such a way that they:

• Allow the middleware to pre-allocate resources so that dynamic resource allocation can be reduced to the minimum,
• Avoid properties that may require the use of unbounded or hard-to-predict resources, and
• Minimize the need to make copies of the data.

预期的应用领域要求DCPS具有高性能、可预测性和高效的资源利用。为了满足这些要求，重要的是接口的设计方式应能够：

• 允许中间件预先分配资源，以便将资源动态分配降至最低，
• 避免可能需要使用无限或难以预测资源的属性，以及
• 最大限度地减少数据拷贝的需要。

 

DDS uses typed interfaces (i.e., interfaces that take into account the actual data types) to the extent possible. Typed interfaces offer the following advantages:

• They are simpler to use: the programmer directly manipulates constructs that naturally represent the data.
• They are safer to use: verifications can be performed at compile time.
• They can be more efficient: the execution code can rely on the knowledge of the exact data type it has in advance, to e.g., pre-allocate resources.

DDS尽可能使用类型化接口（typed interface，即考虑到实际数据类型的接口）。类型化的接口具有以下优点：

• 使用更简单：程序员直接操纵自然表示数据的构造。
• 类型安全：可以在编译器进行验证。
• 更高效：执行代码可以依赖于它事先确切数据类型的知识，例如预先分配资源。

 

It should be noted that the decision to use typed interfaces implies the need for a generation tool to translate type descriptions into appropriate interfaces and implementations that fill the gap between the typed interfaces and the generic middleware.

应该注意的是，使用类型化接口的决定意味着需要一个生成工具来将类型描述转换为合适的接口和实现，以填补类型化接口和中间件之间的空白。

 

QoS (Quality of Service) is a general concept that is used to specify the behavior of a service. Programming service behavior by means of QoS settings offers the advantage that the application developer only indicates ‘what’ is wanted rather than ‘how’ this QoS should be achieved. Generally speaking, QoS is comprised of several QoS policies. Each QoS policy is then an independent description that associates a name with a value. Describing QoS by means of a list of independent QoS policies gives rise to more flexibility.

QoS（服务质量）是用于指定服务行为的一般概念。通过QoS设置编程服务行为的好处是，应用程序开发人员仅指示’想要什么’，而不是’应该如何’实现这个QoS。 一般来说，QoS由几个QoS策略组成。 然后，每个QoS策略都是一个将名称与值相关联的独立描述。 通过一系列独立的QoS策略描述QoS会带来更大的灵活性。

 

This specification is designed to allow a clear separation between the publish and the subscribe sides, so that an application process that only participates as a publisher can embed just what strictly relates to publication. Similarly, an application process that participates only as a subscriber can embed only what strictly relates to subscription.

此规范旨在允许发布和订阅方之间明确分离，以便仅作为发布者参与的应用程序进程可以嵌入与发布严格相关的内容。 同样，仅作为订户参与的应用程序流程只能嵌入与订阅严格相关的内容。

1.2. 目标

Many real-time applications have a requirement to model some of their communication patterns as a pure data-centric exchange, where applications publish (supply or stream) “data” which is then available to the remote applications that are interested in it. Relevant real-time applications can be found in C4I, industrial automation, distributed control and simulation, telecom equipment control, sensor networks, and network management systems. More generally, any application requiring (selective) information dissemination is a candidate for a data-driven network architecture.

许多实时应用程序都要求将它们的某些通信模式建模为纯粹以数据为中心的交换，其中应用程序发布（提供或流）“数据”，然后（这些数据就）可用于对其感兴趣的远程应用程序。有关的实时应用可以在C4I、工业自动化、分布式控制和仿真、电信设备控制、传感器网络和网络管理系统中找到。 更一般地说，任何需要（选择性）信息传播的应用程序都是数据驱动的网络体系结构的候选者。

 

Predictable distribution of data with minimal overhead is of primary concern to these real-time applications. Since it is not feasible to infinitely extend the needed resources, it is important to be able to specify the available resources and provide policies that allow the middleware to align the resources to the most critical requirements. This necessity translates into the ability to control Quality of Service (QoS) properties that affect predictability, overhead, and resource utilization.

这些实时应用主要关注可预测的数据分布和最小的开销。 由于无限延伸所需资源是不可行的，因此能够指定可用资源并提供允许中间件将资源调整为最关键要求的策略非常重要。 这种必要性转化为控制影响可预测性、开销和资源利用率的服务质量（QoS）属性的能力。

 

The need to scale to hundreds or thousands of publishers and subscribers in a robust manner is also an important requirement. This is actually not only a requirement of scalability but also a requirement of flexibility: on many of these systems, applications are added with no need/possibility to reconstruct the whole system. Data-centric communications decouples senders from receivers; the less coupled the publishers and the subscribers are, the easier these extensions become.

以鲁棒的方式扩展到成百上千个发布者和订阅者的需求也是一个重要的要求。 这实际上不仅是可扩展性的要求，而且也是灵活性的要求：在许多这些系统中，应用程序在不需要或不可能重建整个系统的情况下被添加。 以数据为中心的通信将发送者与接收者分离; 发布者和订阅者耦合程度越低，这些扩展就越容易。

 

Distributed shared memory is a classic model that provides data-centric exchanges. However, this model is difficult to implement efficiently over a network and does not offer the required scalability and flexibility. Therefore, another model, the Data-Centric Publish-Subscribe (DCPS) model, has become popular in many real-time applications. This model builds on the concept of a “global data space” that is accessible to all interested applications. Applications that want to contribute information to this data space declare their intent to become “Publishers.” Similarly, applications that want to access portions of this data space declare their intent to become “Subscribers.” Each time a Publisher posts new data into this “global data space,” the middleware propagates the information to all interested Subscribers.

分布式共享内存是提供以数据为中心的交换的经典模型。 但是，这种模式很难在网络上高效实现，并且不具备所需的可扩展性和灵活性。 因此，另一种模型 – 以数据为中心的发布 – 订阅（DCPS）模型已经在许多实时应用中变得流行。 该模型基于所有感兴趣的应用程序都可访问的“全局数据空间”的概念。 希望为该数据空间贡献信息的应用程序可以声明成为“发布者”。同样，希望访问此数据空间部分的应用程序声明成为“订阅者”。每次发布者将新数据发布到此“全局数据空间”，中间件会将信息传播给所有感兴趣的订阅者。

 

Underlying any data-centric publish subscribe system is a data model. This model defines the “global data space” and specifies how Publishers and Subscribers refer to portions of this space. The data-model can be as simple as a set of unrelated data-structures, each identified by a topic and a type. The topic provides an identifier that uniquely identifies some data items within the global data space[1]. The type provides structural information needed to tell the middleware how to manipulate the data and also allows the middleware to provide a level of type safety. However, the target applications often require a higherlevel data model that allows expression of aggregation and coherence relationships among data elements.

任何以数据为中心的发布订阅系统的基础都是数据模型。 该模型定义了“全局数据空间”并指定发布者和订阅者如何引用此空间的某些部分。这个数据模型可以像一组不相关的数据结构一样简单，每个数据结构都由一个主题和一个类型来标识。其中主题提供了一个唯一标识全局数据空间内某些数据项的标识符。类型提供了告诉中间件如何操作数据所需的结构信息，并允许中间件提供一定级别的类型安全。 但是，目标应用程序通常需要更高级别的数据模型，以允许表达数据元素之间的聚合和一致性关系。

 

Prior to the adoption of the DDS specification there were commercially available products that implemented many of these features (among them, NDDS from Real-Time Innovations and Splice from THALES Naval Nederland); however, these products were proprietary and did not offer standardized interfaces and behaviors. The purpose of the DDS specification is to define the standardized interfaces and behaviors that enable application portability. Since DDS’ adoption, at least ten compliant implementations have been developed. See http://portals.omg.org/dds/category/web-links/vendors.

在DDS规范之前，有商用产品实现了许多这些功能（其中包括来自THALES Naval Nederland的Real-Time Innovations和Splice的NDDS）; 然而，这些产品是专有的，并没有提供标准化的接口和行为。 DDS规范的目的是定义使应用程序可移植的标准化接口和行为。 自DDS产生以来，至少已经有了十个兼容的实现。 请参阅http://portals.omg.org/dds/category/web-links/vendors。

 

This specification focuses on the portability of applications using the Data-Distribution Service. Wire-protocol interoperability between vendor implementations is covered in a different OMG specification: The Real-time Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol.”

本标准侧重于使用数据分发服务（DDS）的应用程序的可移植性。另一个OMG标准涵盖了供应商实现之间的有线协议（Wire-protocol）互操作性：实时发布 – 订阅有线协议（Wire protocol）DDS互操作性有线协议。

[1] In addition to topic and type, it is sometimes desirable for subscriptions to further refine the data they are interested in based on the content of the data itself. These so called content-based subscriptions are gaining popularity in large-scale systems. 除了主题和类型之外，有时订阅方期望能够给予数据内容进一步优化他们感兴趣的数据。 这些所谓的基于内容的订阅在大型系统中越来越受欢迎。