Struct Service 

pub struct Service {

    pub id: Id<InterfaceNode>,
    pub node_id: NodeId,
    pub name: String,
    pub module: Id<ModuleNode>,
    pub qualified_name: String,
    pub service_name: String,
    pub request_topic: Option<String>,
    pub reply_topic: Option<String>,
    pub qos_request_profile: Option<String>,
    pub qos_reply_profile: Option<String>,
    pub kind: InterfaceKind,
    pub bases: Vec<Base>,
    pub operations: Vec<Operation>,
    pub attributes: Vec<Attribute>,
    pub mapping: ServiceMapping,
}

One IDL interface, with everything a language binding reads off it.

Fields

id: Id<InterfaceNode>

The interface’s handle.

node_id: NodeId

Stable identity of the model node.

name: String

Its IDL name.

module: Id<ModuleNode>

The module it is declared in.

qualified_name: String

The <interface_name> of DDS-RPC 1.0 §7.4.1: “concatenation of module names separates by underscores followed by the name of the interface”.

Distinct from Self::name, and the distinction is a wire one: §7.5.1.1.6 builds the topic type names from the simple name (Calculator_Request) and §7.4.1 builds the topic names from this one (robot_Calculator_Service_Request). A binding that used one for both publishes a type nobody subscribes to.

service_name: String

The <service_name> of §7.4.1 — what @service(name = "…") supplies, or DEFAULT_SERVICE_NAME.

request_topic: Option<String>

@DDSRequestTopic(name = "…"), §7.4.2.2 — a whole topic name. “These annotations simply control the generated DDS wrapper code”, so the generator is where they are read.

reply_topic: Option<String>

@DDSReplyTopic(name = "…"), §7.4.2.2.

qos_request_profile: Option<String>

@Qos(RequestProfile = "…"), §7.10.1 — the URL of the XML QoS profile for the request endpoints.

qos_reply_profile: Option<String>

@Qos(ReplyProfile = "…"), §7.10.1 — the URL for the reply endpoints.

kind: InterfaceKind

Which interface form the IDL wrote.

bases: Vec<Base>

Base interfaces, in declaration order.

operations: Vec<Operation>

Operations, in declaration order.

attributes: Vec<Attribute>

Attributes, in declaration order.

mapping: ServiceMapping

The service mapping a binding is written for. service reads ServiceMapping::Basic, the default; a generator that writes the Enhanced mapping sets it on the services it passes down, so that the pieces shared by the two mappings — the client and the dispatcher — know which of the two they bind.

Implementations

impl Service

pub const fn is_remote(&self) -> bool

Whether this form has a remote invocation at all.

A local interface (OMG IDL 4.2 §7.4.3.2) is by definition not invocable across a boundary, so a Requester over it would be a class whose whole purpose the declaration rules out. The abstract interface and the async interface are still emitted for it — it has operations, and a caller may hold one — which is why this is a question about the endpoints and not about the whole binding.

The CCM forms (component, home, connector, porttype) have their own mapping in CCM 4.0 §6 and are not DDS-RPC services.

pub fn request_topic_name(&self, style: BindingStyle) -> String

The request topic’s name under style. DDS-RPC 1.0 §7.4.1, with §7.4.2.2’s annotation where the IDL wrote one.

The run-time layer of §7.4.2.3 is not here and cannot be: a generated header is written before there is a run time. What it carries is §7.4.2.1’s default and §7.4.2.2’s annotation, and the run time overrides both through crates/rpc/src/topic_naming.rs::TopicNameOverrides.

pub fn reply_topic_name(&self, style: BindingStyle) -> String

The reply topic’s name under style. See Self::request_topic_name.

pub fn topic_aliases(&self, style: BindingStyle, reply: bool) -> Vec<String>

§7.4.3’s topic aliases: one per parent interface, same tail.

Empty where the topic name came from an annotation — a whole name has no interface segment to vary — and empty under the request-reply binding, where the name carries none either.

pub fn all_operations(&self) -> Vec<Operation>

Every operation a binding emits: the declared ones, then the ones DDS-RPC 1.0 §7.5.1.1.3 implies from the attributes.

Rule 1: “Each attribute in an interface maps to a pair of IDL operations get_attribute_<attribute-name> and set_attribute_<attribute-name> in the same interface.” The order is declaration order of the operations followed by declaration order of the attributes, which is what fixes the discriminator values of the call union: a generator that sorted them would renumber a service that had only gained an attribute.

Trait Implementations

impl Clone for Service

fn clone(&self) -> Self

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for Service

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Eq for Service

impl PartialEq for Service

fn eq(&self, other: &Self) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl StructuralPartialEq for Service