...

The following model depicts the ACS notification channel at the highest level.

...

...

Naming Service

For a consumer to subscribe to events on a given channel it first needs a reference to that channel. While there are many different ways this reference could be obtained, the Naming Service provides the safest and cleanest manner for doing so. The following diagram depicts how remote notification channel objects will be arranged within the Naming Service:

The CORBA Naming Context id, "Channel name", is whatever name is given to the channel by the developer. The kind of the Naming Context will always be "channels" differentiating event channels from other objects registered with the Naming Service.

...

Auto

...

re-connection of suppliers and consumers

Auto reconnection re-connection functionality has been implemented in both suppliers and consumers in order to allow them to recreate and reconnect to the channel when the Notify Service has been restarted. This functionality is enabled by default but can be disabled using a setter method added in all respective classes.
To allow consumers to know when the Notify Service has been restarted, when a channel is created, it's registered twice in the Naming Service. The first entry is used to make publicly available the reference of the channel and the second one includes at the end of the channel's name its creation time and kind is set to "NCSupport". Therefore, in this way, consumers will be able to know if the Notify Service restarted by comparing the creation time registered in the Naming Service and the one they will have retrieved when they connected to the channel. When ACS launches a Notify Service it clears also all Naming Service entries that are related to this service.
The reconnection re-connection of suppliers is performed when an exception of type OBJECT_NOT_EXIST or BAD_OPERATION is thrown during the publication of an event.
Instead, reconnection re-connection of consumers is different because of their passive behavior. In this case, the implementation done adds a thread that checks the connection to the channel in a certain frequency which is 2 seconds by default. This checking process starts after waiting some time (2 seconds by default) since the last received event. Both time parameters can be changed using the respective setters added in every consumer class. Verification of the connection is performed by retrieving the channel's creation time from the Naming Service and comparing it to the creation time kept the last time the consumer connected to the channel. In case the channel's creation time couldn't be retrieved from the Naming Service, it will call the _non_existent() method of the proxy supplier in order to see if the connection is alive.
Auto reconnection re-connection of Python consumers are slightly different that the C++ and Java ones because we could reuse an already existent thread in order to perform the checking. But in this case, frequency and waiting time parameters cannot be modified so they will be always 2 seconds.
Why do we need to register the channel's creation time in the Naming Service instead of using only the _non_existent() call? This is because when the Notify Service restarts, the IDs assigned to the proxy suppliers that have been reconnected could be the same that the ones owned by suppliers that have not been reconnected so far. If this is the case, the _non_existent() call of a supplier that have not been reconnected will work because is using the same ID as one of the suppliers that have been reconnected.

...

Quality of Service and Administrative properties are what sets the Notification Service apart from the CORBA Event Service. The Notification Service specification describes various properties which control how events, suppliers, consumers, and even channels behave under various circumstances.
For your convenience, all properties are described in detail. Please note that some of these properties have not yet been implemented by TAO though (see the Known Problems section).\

Quality of Service

Administrative

...

• Channel names should be specified as constant strings in IDL. This is done to enforce agreed-upon names between suppliers and consumers.
• Prepending the subsystem name to a given channel name reduces the chances of name conflicts between subsystems. An example would be the Correlator subsystem creates the "CORRdata" channel instead of just "data".

Take special note that the Software Engineering group has made coding standards for some of these names!

Class Descriptions

Supplier (C++ and Python)

...

#pragma prefix "alma"
module FRIDGE
{
enum TemperatureStatus { OVERREF, ATREF, BELOWREF};

struct temperatureDataBlockEvent
{
	float absoluteDiff;
	TemperatureStatus status;
};
 
const string CHANNELNAME_FRIDGE = "fridge";

...

Bolded code should be adapted for the developer's particular needs. Note that all component code has been omitted and the acsexmpl module contains the example in its entirety.
ACS/LGPL/CommonSoftware/acsexmpl/ws/src/acsexmplFridgeImpl.cpp:

...

#include <acsexmplFridgeS.h>
#include <acsncSimpleSupplier.h>

nc::SimpleSupplier {}m_FridgeSupplier_p* = 0;

...

m_FridgeSupplier_p = new nc::SimpleSupplier(FRIDGE::CHANNELNAME_FRIDGE,

...

											this);

...

FRIDGE::temperatureDataBlockEvent t_data;

...

t_data.absoluteDiff = (double)0.0;

...

t_data.status = FRIDGE::ATREF;

...

m_FridgeSupplier_p-

...

>publishData<FRIDGE::

...

temperatureDataBlockEvent>(t_data);

...

if (m_FridgeSupplier_p)

...

{

...

	m_FridgeSupplier_p->disconnect();

...

	m_FridgeSupplier_p=0;

...

}

...