RTC::CorbaPort Class Reference

RT Conponent CORBA service/consumer Port. More...

#include <CorbaPort.h>

Inheritance diagram for RTC::CorbaPort:

List of all members.


class  CorbaConsumerHolder
 The structure to be stored Consumer information.
class  CorbaProviderHolder
 The structure to be stored Provider information.
struct  unsubscribe
 Functor to release Consumer's object.

Public Member Functions

 CorbaPort (const char *name)
virtual ~CorbaPort (void)
 Virtual destructor.
void init (coil::Properties &prop)
 Initializing properties.
bool registerProvider (const char *instance_name, const char *type_name, PortableServer::RefCountServantBase &provider)
 Register the provider.
bool registerConsumer (const char *instance_name, const char *type_name, CorbaConsumerBase &consumer)
 Register the consumer.

Protected Member Functions

virtual ReturnCode_t publishInterfaces (ConnectorProfile &connector_profile)
 Publish information about interfaces.
virtual ReturnCode_t subscribeInterfaces (const ConnectorProfile &connector_profile)
 Subscribe to interface.
virtual void unsubscribeInterfaces (const ConnectorProfile &connector_profile)
 Unsubscribe interfaces.
virtual void activateInterfaces ()
 Activate all Port interfaces.
virtual void deactivateInterfaces ()
 Deactivate all Port interfaces.

Protected Attributes

coil::Properties m_properties

Detailed Description

RT Conponent CORBA service/consumer Port.

CorbaPort is an implementation of the Port of RT-Component's that provides user-defined CORBA Object Service and Consumer.

RT-Component can provide user-defined CORBA serivces, which is called RT-Serivce (Provider), through the Ports. RT-Component can also provide place-holder, which is called RT-Serivce Consumer, to use other RT-Component's service.

The CorbaPort can manage any number of Providers and Consumers, can associate Consumers with correspondent Providers when establishing connection among Ports.

Usually, CorbaPort is used like the following.

 RTC::CorbaPort m_port0; // declaration of Port
 MyService_impl m_mysvc0; // Serivce Provider that is provided by the Port
 RTC::CorbaConsumer<YourService> m_cons0; // Consumer of the Port
 // register Service Provider to the Port
 m_port0.registerProvider("MyService0", "Generic", m_mysvc0);
 // register Service Consumer to the Port
 m_port0.registerConsumer("YourService0", "Generic", m_cons0 );
 // after connect established
 m_cons0->your_service_function(); // call a YourService's function
 // in another component that is connected with the Port
 m_cons1->my_service_function(); // call a MyService's function

Registering Service Provider by registerProvider(), it can be used from other RT-Components. Registering Service Consumer by registerConsumer(), other RT-Component's services can be used through the consumer object.

PortInterfaceProfile is a one of the profile information to store Provider interface and Consumer interface information. Tools or other RTCs should call one of the Port::connect() with an appropriate ConnectorProfile.

In addition, the instance name "*" declares a special type of instance.

When the name of the PROVIDED type interface that is the provider interface is "*", Provider interface's instance does not exist at the beginning of connection sequence. The instances will be created dynamically according to the consumer interface requirement at the connection sequence. Although the instance name does not exist at the beginning of connection sequence, the created providers shall publish its references to the ConnectorProfile with interface descriptor adequately in the interface publisher phase of the connection sequence.

If REQUIRED interface name that is Consumer interface name is "*", it shows that one Consumer interface is able to connect with multiple Provider interfaces. (This feature is not implemented.)

The following describes the rules that specify interface connection between ports.

The descriptor format of interfaces associated with Ports is declared as follows. Now some of interface properties are assumed as the followings.

The interface descriptors shall be declared as follows.


When PROVIDED that is Provider interface properties are the followings,


And, when REQUIRED that is Consumer interfaces properties are the followings,

interface descriptor is as follows.


Specific instance name descriptors that are dynamically generated at the connection time are defined here.

When the "Dynamically generated" instance descriptor: "<type_name>*" is specified as interface descriptor that is required by consumers, the provider will generate a instance. If n consumers who demand a provider by the "<type_name>" descriptor exist, the following relation which processes the call from these consumers by one provider will be established.

 consumer0 ]---<
 consumer1 ]---<  O----[ provider0
 consumer2 ]---<

On the other hand, when incremental generated type instance name descriptor "<type_name>+" is specified as the provider interface descriptor whom consumers demand, provider's instances are dynamically generated for the number of the descriptors "<type_name>+". When n consumers who demand a provider by the descriptor "<type_name>+" exist the following relations in which n providers process each call from the consumers will be established.

 consumer0 ]---<  O----[ provider0
 consumer1 ]---<  O----[ provider1
 consumer2 ]---<  O----[ provider2

Describing the appropriate interface mapping specification in the ConnectorProfile::properties, selective connections between providers/consumers interface can be established at the time of connection. However, when different RTC instances of the same instance name exist in a connection, since an interface descriptor uniqueness cannot be guaranteed, this connection mapping rules cannot be used.

Here, assume that an interface descriptor is given as <if_desc0>, <if_desc1>, .... And assume that the key and the value of NVList in ConnectorProfile::properties are given as "key: value".

Now the case where the service ports of two components are connected is considered. When the service port of each component is the following,

      MyComp0                                 YourComp0
     _______ mycomp_service   yourcomp_service ______
            |                                 |
          |~~~|---O echo0         echo9 >---|~~~|
          |   |---< add0          add9  O---|   |
           ~T~                               ~T~
            |                                 |

Assume that connection between echo0 (provider) of MyComp0 component and echo9 (consumer) of YourComp0 component, and add0 (consumer) of MyComp0 and add0 (provider) of YourComp0 is established. In this case, ConnectorProfile is set up as follows.

   name: any connector name
   connector_id: empty string
   ports[]: mycomp_service's reference, yourcomp_service's reference
     <add0>: <add9>
     <echo9>: <echo0>

Please note that <add0>, <add9>, <echo0> and <echo9> are the following.

 <add0> is MyComp0.port.mycomp_service.required.add.add0
 <add9> is YourComp0.port.yourcomp_service.provided.add.add9
 <echo0> is MyComp0.port.mycomp_service.provided.echo.echo0
 <echo9> is YourComp0.port.yourcomp_service.required.echo.echo9

In the connection process, the provider and the consumer of each port carries out the following process respectively in the virtual functions such as CorbaPort::publishInterfaces() and CorbaPort::subscribeInerfaces().

A provider sets its IOR string as a value and its interface descriptor as a key in the ConnectorProfile::properties in a publishInterfaces() function. Since this interface descriptor's uniqueness is guaranteed in the current connector, the key of NameValue in the ConnectorProfile::properties is unique.

[This functionalities are not implemented] The dynamically generated provider is processed according to the following procedure. The publishInterface() function scans dynamic instance descriptors such as "<type_name>*" and "<type_name>+" in the ConnectorProfile::properties. When the dynamic generation instance descriptor "<tupe_name>*" exists, one instance of provider is generated, and its descriptor and its IOR string are set to ConnectorProfile::properties as the key and the value respectively. Simultaneously, in the ConnectorProfile::properties, all the instance descriptor with the dynamic generation instance name "<type_name>*" will be replaced with newly generated instance descriptor.

When the incremental dynamic generation instance descriptor exists, providers are generated for the number of the descriptors, and its descriptor and its IOR string are set to ConnectorProfile::properties as the key and the value respectively. Simultaneously, in the ConnectorProfile::properties, all the instance descriptor with the dynamic generation instance name "<type_name>+" will be replaced with newly generated instance descriptor.

The providers do not perform particular operation in subscribeInterfaces() function.

The consumers do not perform particular operation in publisherInterfaces() function.

On the other hand, a consumer searches a key-value pair with the key of consumer interface descriptor, and if the pair exists, it obtains provider's descriptor from the value. The consumer searches again a key-value pair with the key of provider interface descriptor, and it obtains provider's reference and the reference is set as the consumer's service object. In addition, reserved string "nil" or "null" are used not to set specific provider.

If consumer's interface descriptors does not exists in the ConnectorProfile::properties, the consumer searches a provider with same type name and instance name, and its reference is set to the consumer. This rule is for only backward compatibility, and it is not recommended from version 1.0.

The correspondence of a provider versus a consumer does not need to be one to one, and the case of one provider to n-consumers and the case of m-providers to one consumer are allowed. The one provider to n-consumers case can be realized by the above mentioned methods. The one consumer to m-provider case can be specified to set the consumer descriptor and comma-separated provider descriptors into the key and the value respectively.

The following option is available to specify the strictness of interfaces connection.

port.connection.strictness: strict, best_effort

strict: The connection is established, if only all the specified consumers are set appropriate references and narrowed successfully.

best_effort: The connection is established without any errors, even if appropriate reference does not exist or reference narrowing fails.


Constructor & Destructor Documentation

RTC::CorbaPort::CorbaPort ( const char *  name  ) 


In the ctor, a given name is set into PortBase, and the following property is added to the PortProfile::properties,

  • port.port_type: "CorbaPort"
name The name of Port
virtual RTC::CorbaPort::~CorbaPort ( void   )  [virtual]

Virtual destructor.

Member Function Documentation

virtual void RTC::CorbaPort::activateInterfaces (  )  [protected, virtual]

Activate all Port interfaces.

This operation activate all interfaces that is registered in the ports.

Implements RTC::PortBase.

virtual void RTC::CorbaPort::deactivateInterfaces (  )  [protected, virtual]

Deactivate all Port interfaces.

This operation deactivate all interfaces that is registered in the ports.

Implements RTC::PortBase.

void RTC::CorbaPort::init ( coil::Properties &  prop  ) 

Initializing properties.

This operation initializes outport's properties. If a property "connection_limit" is set and appropriate value is set to this property value, the number of maximum connection is set as this value. If the property does not exist or invalid value is set to this property, the maximum number of connection will be set unlimited.

prop properties of the CorbaPort
virtual ReturnCode_t RTC::CorbaPort::publishInterfaces ( ConnectorProfile &  connector_profile  )  [protected, virtual]

Publish information about interfaces.

This operation publishes Provider interfaces information, which is owned by this port, to the other Ports via ConnectorProfile::properties. Now it is assumed RTC instance name and other information is as follows,

  • RTC instance name: rtc_iname
  • Port name: port_name
  • Interface polarity: if_polarity
  • Interface type name: if_tname
  • Interface instance name: if_iname

the following values are stored as the "name" and the "value" of the NameValue typee element in ConnectorProfile::properties.

  • name <rtc_iname>.port.<port_name>.provided.<if_tname>.<if_iname>
  • value IOR string value of interface reference

In addition, although the following NameValue values are also stored for the backward compatibility, this will be deleted in the future version.

  • name port.<if_tname>.<if_iname>
  • value IOR string value of interface reference

These values are stored in the ConnectorProfile::properties and are propagated to the other Ports. If the Consumer interface exists that requires this Provider interface, it will retrieve reference from the ConnectorProfile and utilize it.

connector_profile Connector profile
The return code of ReturnCode_t type

Implements RTC::PortBase.

bool RTC::CorbaPort::registerConsumer ( const char *  instance_name,
const char *  type_name,
CorbaConsumerBase consumer 

Register the consumer.

This operation registers a consumer, which is a service placeholder this port requires. These are associated internally with specified instance_name, type_name and Consumer itself to the argument as service's instance name and its type name associated with Consumer. The service Provider interface' references will be set automatically to the Consumer Interface object when connections are established, according to the rules that are described at the subscribeInterface() function's documentation.

instance_name Instance name of the service Consumer requires
type_name Type name of the service Consumer requires
consumer CORBA service consumer
False would be returned if the same instance_name was registered
bool RTC::CorbaPort::registerProvider ( const char *  instance_name,
const char *  type_name,
PortableServer::RefCountServantBase &  provider 

Register the provider.

This operation registers a servant, which is provided in this Port, to the Port. The servant is associated with "instance_name" and "type_name" as the instance name of the servant and as the type name of the servant. A given servant will be stored in the CorbaPort, and this is registered as RTC::PROVIDED interface into the PortInterfaceProfile.

instance_name Instance name of servant
type_name Type name of the servant
provider CORBA servant
Return false if the same name of instance_name is already registered.
virtual ReturnCode_t RTC::CorbaPort::subscribeInterfaces ( const ConnectorProfile &  connector_profile  )  [protected, virtual]

Subscribe to interface.

Retrieve information associated with Provider matches Consumer owned by this port and set the object reference to Consumer.

Now, Consumer is registered as the following:

    instance_name = "PA10_0";
    type_name     = "Manipulator";
    polarity      = REQUIRED;

Find the object reference of Serivce Provider that is registered as the following of other ports:

    instance_name = "PA10_0";
    type_name     = "Manipulator";
    polarity      = PROVIDED;

and set to Consumer. In fact, find NameValue that is registered as the following to ConnectorProfile::properties:

 NameValue = { "port.Manipulator.PA10_0": <Object reference>=""> }

and set the object reference to Consumer.

connector_profile Connector profile
The return code of ReturnCode_t type

Implements RTC::PortBase.

virtual void RTC::CorbaPort::unsubscribeInterfaces ( const ConnectorProfile &  connector_profile  )  [protected, virtual]

Unsubscribe interfaces.

Release all Objects that was set in Consumer associated with the given ConnectorProfile.

connector_profile Connector profile

Implements RTC::PortBase.

Member Data Documentation

coil::Properties RTC::CorbaPort::m_properties [protected]


Generated on Fri Mar 11 00:00:59 2011 for OpenRTM by  doxygen 1.6.3