org.omg.dds.core.policy

Interface QosPolicy

All Superinterfaces:

DDSObject, Serializable

All Known Subinterfaces:

DataRepresentation, Deadline, DestinationOrder, Durability, DurabilityService, EntityFactory, GroupData, History, LatencyBudget, Lifespan, Liveliness, Ownership, OwnershipStrength, Partition, Presentation, QosPolicy.ForDataReader, QosPolicy.ForDataWriter, QosPolicy.ForDomainParticipant, QosPolicy.ForDomainParticipantFactory, QosPolicy.ForPublisher, QosPolicy.ForSubscriber, QosPolicy.ForTopic, ReaderDataLifecycle, Reliability, ResourceLimits, TimeBasedFilter, TopicData, TransportPriority, TypeConsistencyEnforcement, UserData, WriterDataLifecycle

@Extensibility(value=EXTENSIBLE_EXTENSIBILITY)
@Nested
public interface QosPolicy
extends Serializable, DDSObject

This class is the abstract root for all the QoS policies. It provides the basic mechanism for an application to specify quality of service parameters. All concrete QosPolicy classes derive from this root and include a value whose type depends on the concrete QoS policy. The type of a QosPolicy value may be atomic, such as an integer or float, or compound (a structure). Compound types are used whenever multiple parameters must be set coherently to define a consistent value for a QosPolicy. Each Entity can be configured with a collection of QosPolicy. However, any Entity cannot support any QosPolicy. For instance, a DomainParticipant supports different QosPolicy than a Topic or a Publisher. QosPolicy can be set when the Entity is created, or modified with the Entity.setQos(org.omg.dds.core.EntityQos) method. Each QosPolicy in collection list is treated independently from the others. This approach has the advantage of being very extensible. However, there may be cases where several policies are in conflict. Consistency checking is performed each time the policies are modified via the Entity.setQos(org.omg.dds.core.EntityQos) operation. When a policy is changed after being set to a given value, it is not required that the new value be applied instantaneously; the Service is allowed to apply it after a transition phase. In addition, some QosPolicy have "immutable" semantics meaning that they can only be specified either at Entity creation time or else prior to calling the Entity.enable() operation on the Entity. Objects of this type are immutable. Properties of QoS Policies In several cases, for communications to occur properly (or efficiently), a QosPolicy on the publisher side must be compatible with a corresponding policy on the subscriber side. For example, if a DataReader requests to receive data reliably while the corresponding DataWriter defines a best-effort policy, communication will not happen as requested. To address this issue and maintain the desirable decoupling of publication and subscription as much as possible, the specification for QosPolicy follows the subscriber-requested, publisher-offered pattern. In this pattern, the subscriber side can specify a "requested" value for a particular QosPolicy. The publisher side specifies an "offered" value for that QosPolicy. The Service will then determine whether the value requested by the subscriber side is compatible with what is offered by the publisher side. If the two policies are compatible, then communication will be established. If the two policies are not compatible, the Service will not establish communications between the two Entity objects and will record this fact by means of the OfferedIncompatibleQosStatus status on the publisher end and RequestedIncompatibleQosStatus status on the subscriber end. The application can detect this fact by means of a listener (e.g. DataReaderListener or DataWriterListener) or Conditions. The QosPolicy objects that need to be set in a compatible manner between the publisher and subscriber ends are indicated by the setting of the "RxO" (Requested/Offered) property:

• An "RxO" setting of "Yes" indicates that the policy can be set both at the publishing and subscribing ends and the values must be set in a compatible manner. In this case the compatible values are explicitly defined.
• An "RxO" setting of "No" indicates that the policy can be set both at the publishing and subscribing ends but the two settings are independent. That is, all combinations of values are compatible.
• An "RxO" setting of "N/A" indicates that the policy can only be specified at either the publishing or the subscribing end, but not at both ends. So compatibility does not apply.

The "changeable" property determines whether the QosPolicy can be changed after the Entity is enabled. In other words, a policy with "changeable" setting of "NO" is considered "immutable" and can only be specified either at Entity creation time or else prior to calling the Entity.enable() operation.

Nested Class Summary

Nested Classes

Modifier and Type	Interface and Description
static interface	QosPolicy.ForDataReader A QosPolicy interface that implements this marker interface applies to DataReader Entities.
static interface	QosPolicy.ForDataWriter A QosPolicy interface that implements this marker interface applies to DataWriter Entities.
static interface	QosPolicy.ForDomainParticipant A QosPolicy interface that implements this marker interface applies to DomainParticipant Entities.
static interface	QosPolicy.ForDomainParticipantFactory A QosPolicy interface that implements this marker interface applies to DomainParticipantFactory objects.
static interface	QosPolicy.ForPublisher A QosPolicy interface that implements this marker interface applies to Publisher Entities.
static interface	QosPolicy.ForSubscriber A QosPolicy interface that implements this marker interface applies to Subscriber Entities.
static interface	QosPolicy.ForTopic A QosPolicy interface that implements this marker interface applies to Topic Entities.

Method Summary

Methods inherited from interface org.omg.dds.core.DDSObject

getEnvironment