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

Chapter 12. Object Life Cycle

12.1 Chapter Overview

This chapter covers the broad topic of object life cycle: how objects can be created, copied, moved, and destroyed. Sections 12.3 to 12.5 discuss the OMG Life Cycle Service, which provides a few design guidelines for how to define life cycle operations. Section 12.6 discusses the Evictor pattern. It is important because it permits you to limit memory consumption of servers that implement large numbers of objects. The chapter concludes with Sections 12.7 and 12.8, which discuss garbage collection strategies in a CORBA environment.

Object life cycle is one of the most challenging topics in distributed systems, and we suggest you read this chapter in detail. Much of the information presented here is essential for building scalable and reliable applications.

12.2 Introduction

The climate control system developed in Chapter 11 has one drawback: there is no apparent way for a client to connect a newly installed device to the system. The controller could automatically discover new devices as they are connected to the network, but our hypothetical instrument control protocol does not offer this functionality. So the question arises, "How can we tell the climate control system that there is a new device on the network so that the server can instantiate a new CORBA object for the device?"

This question is part of a topic generally known as object life cycle. Object life cycle addresses the issues of

Object creation Object destruction Object copying Object movement

The CORBAservices [21] Life Cycle Service addresses these issues. Unlike other OMG services, the Life Cycle Service is not a service that can be built by a vendor and simply used by clients. Instead, the Life Cycle Service describes a number of interfaces and design patterns you can choose to use for life cycle management of objects. In other words, the Life Cycle Service is largely a set of recommendations and not an implementable specification.

About two-thirds of the Life Cycle specification is composed of a number of nonnormative addenda. These addenda cover the Compound Life Cycle specification, filters, administration, and support for objects in a Portable Common Tool Environment (PCTE) [3]. However, we are not aware of significant use of these addenda in current software

468

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

development projects, so we cover only the main part of the Life Cycle specification in this chapter.

12.3 Object Factories

The OMG Life Cycle specification recommends that CORBA applications use the Factory pattern [4] to create objects. A factory is a CORBA object that offers one or more operations to create other objects. To create a new object, a client invokes an operation on the factory; the operation's implementation creates a new CORBA object and returns a reference for the new object to the client. Factory operations in a distributed system play the role of the constructor in C++. The difference is that a factory operation creates a CORBA object in a possibly remote address space, whereas a C++ constructor always creates a C++ object in the local address space. Also, you invoke factory operations on existing objects, whereas you can invoke constructors without already having an existing object.

Object creation is highly specific to the type of object being created. The actions taken by a factory vary greatly depending on whether it creates a document object, a person object, or a thermometer object. The type of object being created determines which parameters must be passed by the client. (Clearly, a client would pass different parameters to create a person object than it would to create a thermometer object.)

To make all this more concrete, we will add factories to the climate control system. Here is one possible approach:

#pragma prefix "acme.com"

module CCS {

// ...

exception DuplicateAsset {};

interface ThermometerFactory {

Thermometer create(in AssetType anum, in LocType loc) raises(DuplicateAsset);

};

interface ThermostatFactory {

) raises(DuplicateAsset, Thermostat::BadTemp);

};

};

We have added two new interfaces to the specification. ThermometerFactory offers a create operation to create a new thermometer, and ThermostatFactory offers a create operation to create a new thermostat.

469

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

If we have just installed a new thermometer in the climate control system, we inform the system of the new thermometer's existence by calling the create operation on the ThermometerFactory interface. In response, the factory creates a new object reference for the device and returns it.

Recall from Chapter 10 that the thermometer and thermostat devices have a unique asset number that is also used as the ICP network address. In addition, each device has a modifiable location attribute. We must pass these two items of information to the create operation. We pass an asset number because it informs the climate control system of the identity of the new device (that is, its network address), and we pass a location because the location is part of the initial state of the object. The implementation of create programs the location string into the new thermometer. Thermometers also have a model and a temperature attribute, but there is no point in passing values for these attributes to create. The model string is permanently programmed into the device itself and is therefore read-only. And, of course, there is no point in passing a temperature because it does not make sense to tell a thermometer what temperature it should report.

To create a thermostat, the client must supply an additional parameter: the initial temperature setting for that thermostat. Again, the implementation of the create operation takes care of programming that nominal temperature into the device.

Both create operations can raise a DuplicateAsset exception. We need this exception because if we were to permit two devices with the same asset number on the network, the controller could no longer distinguish between them. The create operation for thermostats can also raise a BadTemp exception to indicate that the requested initial temperature is out of range.

12.3.1 Factory Design Options

There are many different options for factory design, and the basic Factory pattern we showed in the preceding section is only one of them.

Combined Factory

Instead of using two separate interfaces, we can use a single factory to create both types of devices:

#pragma prefix "acme.com"

module CCS {

// ...

exception DuplicateAsset {};

interface DeviceFactory { Thermometer create_thermometer(

470

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

)raises(DuplicateAsset);

Thermostat create_thermostat( in AssetType anum, in LocType loc,

in TempType temp

)raises(DuplicateAsset, Thermostat::BadTemp);

};

};

This design is just as valid as the previous one but has different architectural consequences. With this new design, a single factory object must be able to create both thermometers and thermostats, whereas with the first design, each factory had knowledge only of a single device. The main consequence of combining the factory operations into a single interface is that it becomes harder to distribute our system over multiple server processes. For example, we might want an architecture such as the one shown in Figure 12.1.

Figure 12.1 A distributed climate control system.

This architecture could be useful, for example, if we decide to buy thermometers and thermostats from different manufacturers that use incompatible instrument control protocols. In this case, it might be necessary to split our system into server processes as shown because, for example, the libraries for the two proprietary protocols might not be available for the same platform. (This example is not as contrived as it may appear. This sort of thing happens much more often in real IT environments than anyone would like to admit.)

471

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

By combining the factory operations into a single interface, we have made it harder to implement the factory. Logically, the factory still belongs with the controller server, but physically, the factory cannot exist only in the controller server; the POA does not allow us to create an object reference to an object in another address space. As you saw in Section 11.7.1, we can create an object reference by instantiating a servant and calling the _this member function, or we can create an object reference using the POA member function create_reference_with_id. However, no matter how we create the reference, it always denotes an object in the same server process as the calling code. Looking at our factory interface, it becomes clear that a factory inside the controller server cannot create a reference to a CORBA object in the thermometer server, at least not directly.

This is not a deficiency in the POA. To create a reference in one server that denotes an object in another server, we would have to supply information that is not easily obtainable, such as the physical address of the server, the protocol (including the protocol version) to be used to communicate with the server, and the object ID of the target object. Not only is it unlikely that we would have the relevant details at hand, but also, if the POA were to allow creation of object references to another server, it would place itself firmly outside the CORBA object model. Remember that object references are opaque and application code is not allowed to see the details of the addressing and protocol information that is embedded inside object references. Moreover, the whole point of CORBA is that we do not need to worry about things such as physical network addresses and protocols, so permitting the creation of object references to other address spaces simply does not make sense.

Nevertheless, you can have a factory that effectively creates object references for objects in another address space: the factory must delegate the creation to another factory that is collocated with the object it creates. For the architecture shown in Figure 12.1, a factory in the controller server would delegate creation of thermometers to a factory implemented in the thermometer server and would delegate the creation of thermostats to a factory implemented in the thermostat server.

Combined Collection and Factory

Yet another option, a variation on the preceding one, is to add the factory operations to the Controller interface instead of using a separate factory object:

#pragma prefix "acme.com"

module CCS {

// ...

interface Controller {

exception DuplicateAsset {};

Thermometer create_thermometer( in AssetType anum,

in LocType loc

472

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

)raises(DuplicateAsset);

Thermostat create_thermostat( in AssetType anum, in LocType loc,

in TempType temp

)raises(DuplicateAsset, Thermostat::BadTemp);

// Other operations...

};

};

The actual operation definitions are identical to the preceding example, but we have moved them into the controller interface. Again, whether this is a reasonable design depends on the application and how we want to distribute it over physical server processes. By adding the factory operations to the Controller interface, we commit ourselves to implementing the factory operations and the collection-manager operations (such as list) in the same server process. This is not necessarily a bad thing; the Controller interface already acts as a collection manager for our devices, so we might as well have the device creation operations on that interface too. However, from a purist's perspective, we no longer have a clean separation of concerns. A pure object model would have separate factory and collection interfaces, and the collection interface would offer an operation to add a device to the collection.

The main point to keep in mind when designing interfaces is that you cannot split the implementation of a single interface across multiple server processes (at least not without resorting to explicit delegation). An IDL interface defines the smallest grain of distribution in the CORBA object model, and therefore the design of interfaces determines, at least in part, how a logical system can be partitioned over physical server processes.

Pure Collection and Factory

Here is the pure version of the object model:

#pragma prefix "acme.com"

module CCS {

// ...

exception DuplicateAsset {};

interface ThermometerFactory {

Thermometer create(in AssetType anum, in LocType loc) raises(DuplicateAsset);

};

interface ThermostatFactory { Thermostat create(

in AssetType anum, in LocType loc,

473

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

in TempType temp

)raises(DuplicateAsset, Thermostat::BadTemp);

};

interface Controller {

exception DuplicateDevice {}; exception NoSuchDevice {};

void add_device(in Thermometer t); void remove_device(in Thermometer t);

// Other operations...

};

};

In this design, the factories and the controller are separate interfaces. Moreover, the controller now acts as a pure collection because it provides explicit add_device and remove_device operations. This design provides better separation of concerns: factories do nothing except create devices, and the controller is simply a collection of references to these devices. This design eliminates the hidden communication between the factory and the controller that was present in the previous designs. Instead of "magically" knowing about a newly created device, the controller is explicitly informed when a new device has been added.

The downside of this design is that it places more responsibility for keeping the object model consistent on either the client or the factory. If we place the responsibility for consistency on the client, the client must both explicitly create a new device and call the add_device operation to add the device to the controller. This makes the device creation process more complex for the client and requires two remote messages instead of one. Alternatively, if we place the responsibility for consistency on the factory, the factory must call the add_device operation. This simplifies device creation for clients but adds a dependency between the factory and the controller because the factory now must somehow know which controller to add the new device to.

This kind of trade-off is typical for object models. A pure model that offers better separation of concerns usually also requires more messages to be exchanged because in a pure model, objects do not share hidden state.

Bulk Factories

In the climate control system, it is unlikely that we will need to frequently add large numbers of devices. However, for more ephemeral objects—for example, objects representing Web pages—we may find that having to send a separate message for each object to be created is too slow. In this case, we can choose to define an operation that creates objects in bulk:

module CCS {

// ...

474

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

exception DuplicateAsset {};

typedef sequence<Thermometer> ThermometerSeq;

struct InitTherm { AssetType anum; LocType loc;

};

typedef sequence<InitTherm> InitThermSeq;

interface BulkThermometerFactory { ThermometerSeq create(in InitThermSeq details)

raises(DuplicateAsset, Thermostat::BadTemp);

}; // ...

};

Instead of passing the initial state for a single thermometer to the create operation, we pass a sequence of InitTherm structures, one for each thermometer to be created. The operation creates as many CORBA objects as there are elements in the details sequence and returns their references.

The main advantage of this design is that it reduces messaging overhead and is therefore more efficient. On the downside, it makes error handling more complex. For example, if one of the InitTherm structures contains an invalid temperature, it is no longer clear which particular structure caused the problem unless we also add additional information to the data returned by a BadTemp exception. Your application may not need to distinguish the offending entry, but the example shows that bulk operations also add new failure semantics to the system that may require precise handling.

Bulk Factories without a Return Value

Yet another variation on the object creation theme is the following:

// As before...

interface BulkThermometerFactory {

void create(in InitThermSeq details) raises(DuplicateAsset, Thermostat::BadTemp);

};

The only difference between this version and the preceding version is that the create operation has no return value. The assumption built into this design is that after creating the devices, the client will use the list or find operation on the controller to acquire the device references. Again, whether this design is appropriate depends entirely on how we anticipate that the application will be used. For example, this version is appropriate if we use separate clients for the creation and the monitoring of devices. If special-purpose clients only create devices and do not monitor them, there is little point in returning object references to the clients because they would simply ignore them.

475

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

Deciding On a Factory Design

The preceding discussion of design options applies not only to factories but also to almost every object system that uses more than one type of object. If the different objects in the system need to communicate with one another, the design of the IDL interfaces has profound influence on the system's ease of use for clients as well as its reliability, its performance, and its physical architecture.

If nothing else, the preceding discussion should make it clear that it pays to think before deciding on a particular interface design. In particular, an object model that may be perfectly appropriate inside a C++ program may disappoint you if you naively translate it into its IDL equivalent. What is appropriate for C++ is not necessarily appropriate for CORBA. In particular, the cost of sending a remote message over a network is orders of magnitude larger than the cost of a C++ method invocation. As a result, not only is it important for you to choose the correct communication model between interfaces, but it is also important that you correctly distribute interface instances over physical server processes. If you implement objects that require a high message exchange rate in different servers, performance will be reduced accordingly.

In a sense, the preceding should not come as a surprise. Interface design has profound influence on system performance in most environments, and CORBA is no exception. Because this book is not about object-oriented design, we say little more about this topic in the remaining chapters. You can consult any number of books to learn more. However, we briefly return to the cost of remote messages in Chapter 22.

12.3.2 Implementing Factories with C++

For the remainder of this chapter, we use persistent objects for our climate control system. In addition, we use a servant manager to bring servants into memory on demand. These choices require a number of changes to the climate control system.

The controller must maintain a list of asset numbers on secondary storage to keep track of known devices. This is necessary because otherwise, the list operation cannot be implemented (the ICP network does not support discovery). For this simple example, we read the complete list of asset numbers from a file in the controller's constructor and write the list of asset numbers back to the file in the destructor. (A more realistic application would update the list on secondary storage immediately when a device is added or removed.) You can find the class definition for the Controller_impl servant in Section 10.11.1. Here is the code for the constructor:

Controller_impl::

Controller_impl( PortableServer::POA_ptr poa, const char * asset_file

) throw(int) : m_poa(PortableServer::POA::_duplicate(poa)), m_asset_file(asset_file)

{

fstream afile(m_asset_file, ios::in|ios::out, 0666);

476

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

if (!afile) {

cerr < < "Cannot open " < < m_asset_file < < endl; throw 0;

}

CCS::AssetType anum; while (afile >> anum)

m_assets[anum] = 0; afile.close();

if (!afile) {

cerr < < "Cannot close " < < m_asset_file < < endl; throw 0;

}

}

Note that the file name is passed to the constructor and is remembered in the private member variable m_asset_file. (We return to the purpose of the m_poa member shortly.) The constructor iterates over the input file (creating it if necessary) and inserts each asset number into the m_assets map with a null servant pointer. This action initializes the m_assets map with all known asset numbers. However, no servants are instantiated at this point. Instead, an asset number with a null servant pointer indicates that the device exists but has no servant in memory.

The controller's destructor runs when the server shuts down and writes the known asset numbers back to the file:

Controller_impl:: ~Controller_impl()

{

//Write out the current set of asset numbers

//and clean up all servant instances. ofstream afile(m_asset_file);

if (!afile) {

cerr < < "Cannot open " < < m_asset_file < < endl; abort();

}

AssetMap::iterator i;

for (i = m_assets.begin(); i != m_assets.end(); i++) { afile < < i->first < < endl;

if (!afile) {

cerr < < "Cannot update " < < m_asset_file < < endl; abort();

}

delete i->second;

}

afile.close(); if (!afile) {

cerr < < "Cannot close " < < m_asset_file < < endl; abort();

}

}

477

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

Note that the loop also deletes each instantiated servant. (If a servant pointer is null, the delete does nothing.) This technique ensures that the destructor for all instantiated servants is invoked so that servants can properly finalize their state before the server shuts down.

For this example, we are using the combined collection and factory approach we describe on page 533, in which the controller offers a creation operation for each type of device. (The implementation of the factory operations for the other options we discussed is very similar.) Here is the code for create_thermometer:

CCS::Thermometer_ptr Controller_impl::

create_thermometer(CCS::AssetType anum, const char * loc) throw(CORBA::SystemException, CCS::Controller::DuplicateAsset)

{

//Make sure the asset number is new. if (exists(anum))

throw CCS::Controller::DuplicateAsset();

//Add the device to the network and program its location. if (ICP_online(anum) != 0)

abort();

if (ICP_set(anum, "location", loc) != 0) abort();

//Add the new device to the m_assets map.

add_impl(anum, 0);

// Create an object reference for the device and return it. return make_dref(m_poa, anum);

}

The code first checks whether a device having the asset number passed in already exists. If it does, the code throws a DuplicateAsset exception. (The exists function is a simple helper function that returns true if the asset number passed to it is in the m_assets map.) The next step is to inform the ICP network of the existence of the new device and to program its location string. Next, the code adds an entry for the new device to the m_assets map, storing a null pointer to the servant. In other words, the factory does not immediately instantiate a servant for the new device but instead delays instantiation until the first operation is invoked. (You will see how this works in Section 12.6.) The final step is to call the make_dref helper function, which creates an object reference for the new device.

Here is the code for make_dref:

static CCS::Thermometer_ptr make_dref(PortableServer::POA_ptr poa, CCS::AssetType anum)

{

// Convert asset number to OID. ostrstream ostr;

ostr < < anum < < ends;

char * anum_str = ostr.str(); PortableServer::ObjectId_var oid

= PortableServer::string_to_ObjectId(anum_str);

478

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

ostr.rdbuf()->freeze(0);

//Look at the model via the network to determine

//the repository ID.

char buf[32];

if (ICP_get(anum, "model", buf, sizeof(buf)) != 0) abort();

const char * rep_id = strcmp(buf, "Sens-A-Temp") == 0

? "IDL:acme.com/CCS/Thermometer:1.0" : "IDL:acme.com/CCS/Thermostat:1.0";:

"IDL:acme.com/CCS/Thermostat:1.0";

// Make a new reference. CORBA::Object_var obj

= poa->create_reference_with_id(oid, rep_id); return CCS::Thermometer::_narrow(obj);

}

The make_dref function merely encapsulates similar code that is shown in Chapter 11. Note that we pass to make_dref an object reference to the POA for the new servant. That POA reference in turn is remembered by the controller's constructor, shown on page 543.

Looking at create_thermometer and make_dref, you can see that very little work is actually required to create a new object. The factory simply informs the network of the new device, updates the controller's notion of what devices exist, and creates an object reference for the new device.

The implementation of create_thermostat is similar. The main difference is that we must check whether the initial temperature setting is in range and that we must narrow the reference returned by make_dref to the correct type:

CORBA::SystemException,

CCS::Controller::DuplicateAsset,

CCS::Thermostat::BadTemp)

{

//Make sure the asset number is new. if (exists(anum))

throw CCS::Controller::DuplicateAsset();

//Add the device to the network and program its location. if (ICP_online(anum) != 0)

abort();

if (ICP_set(anum, "location", loc) != 0) abort();

479