IT-SC book: Advanced CORBA® Programming with C++

10.9 Implementing the Controller Servant Class

The implementation of the controller consists of the helper functions and the IDL operations list, change, and find.

10.9.1 Controller_impl Helper Functions

The implementations of the add_impl and remove_impl helpers are trivial. They add and remove the specified entry from the m_assets map of servants:

Controller_impl::

add_impl(CCS::AssetType anum, Thermometer_impl * tip)

{

m_assets[anum] = tip;

}

// Helper function for thermometers and thermostats to // remove themselves from the m_assets map.

void Controller_impl::

remove_impl(CCS::AssetType anum)

{

m_assets.erase(anum);

}

10.9.2 Implementing the list Operation

The implementation of list is simple. We iterate over the map of devices and construct an object reference for each device by calling the _this member function. The return value of the operation is a sequence. Sequences are variable-length and must be dynamically allocated if they are returned from an operation, so the code allocates the return sequence by calling new. Because we know in advance how many elements will be placed in the sequence, we use the maximum constructor. Here is the source code:

// IDL list operation.

CCS::Controller::ThermometerSeq * Controller_impl::

list() throw(CORBA::SystemException)

362

IT-SC book: Advanced CORBA® Programming with C++

{

//Create a new thermometer sequence. Because we know

//the number of elements we will put onto the sequence,

//we use the maximum constructor. CCS::Controller::ThermometerSeq_var listv

=new CCS::Controller::ThermometerSeq(m_asset s.size()); listv->length(m_assets.size());

//Loop over the m_assets map and create a

//reference for each device.

CORBA::ULong count = 0; AssetMap::iterator i;

for (i = m_assets.begin(); i != m_assets.end(); i++) listv[count++] = i->second->_this();

return listv._retn();

}

10.9.3 Implementing the change Operation

The implementation of change also requires a bit of work because the ICP API does not support relative temperature changes. In addition, change must preserve the exception information returned by each failed operation, and that adds to the complexity.

To keep the code comprehensible, we take a pessimistic approach. We create an EChange exception in a local variable ec, just in case we need it. We then enter the loop that iterates over the supplied sequence of references. During each iteration, we read the current nominal temperature, add the delta value to it, and attempt to set the resulting nominal temperature. If the attempt fails, we extend the sequence of errors inside ec by one element and copy the exception details returned by the failed set_nominal operation into the new element. When the loop terminates, we look at whether the sequence of errors inside ec now has non-zero length, in which case we throw the now initialized exception. Otherwise, if no errors were encountered, change returns without throwing an exception.

// IDL change operation.

void Controller_impl:: change(

const CCS::Controller::ThermostatSeq & tlist, CORBA::Short delta

) throw(CORBA::SystemException, CCS::Controller::EChange)

{

//We cannot add a delta value to a thermostat's temperature

//directly, so for each thermostat, we read the nominal

//temperature, add the delta value to it, and write

//it back again.

363

IT-SC book: Advanced CORBA® Programming with C++

for (CORBA::ULong i = 0; i < tlist.length(); i++) { if (CORBA::is_nil(tlist[i]))

continue;

// Read nominal temp and update it. CCS::TempType tnom = tlist[i]->get_nominal(); tnom += delta;

try { tlist[i]->set_nominal(tnom);

}

catch (const CCS::Thermostat::BadTemp & bt) {

//If the update failed because the temperature

//is out of range, we add the thermostat's info

//to the errors sequence.

CORBA::ULong len = ec.errors.length(); ec.errors.length(len + 1); ec.errors[len].tmstat_ref = tlist[i]; ec.errors[len].info = bt.details;

}

}

//If we encountered errors in the above loop,

//we will have added elements to the errors sequence. if (ec.errors.length() != 0)

throw ec;

}

Note that this code calls the get_nominal and set_nominal operations:

CCS::TempType tnom = tlist[i]->get_nominal(); // ...

tlist[i]->set_nominal(tnom);

The expression tlist[i] of course denotes one of the object references passed by the client. Note that two interesting things are happening here.

The server acts as a client by invoking an IDL operation on an object reference.

In this particular case, the target object happens to be collocated in the same server as the calling code.

This is convenient: not only can a server act as a client without special effort, but it can also act as a client to its own objects. In other words, invocations are location transparent, and we don't have to worry about where the target object is implemented. (A collocated invocation is much faster than one to a remote object. Most ORBs implement a local bypass to ensure that collocated calls are nearly as fast as virtual function calls.)

10.9.4 Implementing the find Operation

364

IT-SC book: Advanced CORBA® Programming with C++

Unfortunately, the implementation of find turns out to be rather messy, due in part to its (deliberately) convoluted semantics: if a particular search key does not match a device or matches only a single device, we must overwrite the device member of the search key. However, if several devices match the same search key, the first matching device's reference overwrites the device member, but the other matching devices must extend the search sequence passed in slist.

Another reason for the excessive complexity is that we are dealing with deeply nested data structures. The find operation has a sequence as an inout parameter. The sequence elements are structures that in turn contain a data member that is a union. The level of nesting and the complexity of the data types involved is such that messy code is almost unavoidable:

// IDL find operation

void Controller_impl::

find(CCS::Controller::SearchSeq & slist) throw(CORBA::SystemException)

{

// Loop over input list and look up each device. CORBA::ULong listlen = slist.length();

for (CORBA::ULong i = 0; i < listlen; i++) {

//Assume we will not find a matching device. slist[i].device = CCS::Thermometer::_nil();

//Work out whether we are searching by asset,

//model, or location.

CCS::Controller::SearchCriterion sc = slist[i].key._d(); if (sc == CCS::Controller::ASSET) {

// Search for matching asset number.

where = m_assets.find(slist[i].key.asset_num()); if (where != m_assets.end())

slist[i].device = where->second->_this();

}else {

//Search for model or location string. const char * search_str;

if (sc == CCS::Controller::LOCATION) search_str = slist[i].key.loc();

else

search_str = slist[i].key.model_desc();

//Find first matching device (if any). where = find_if(

m_assets.begin(), m_assets.end(), StrFinder(sc, search_str)

);

//While there are matches...

365