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

//Look for device in Rooms Earth and HAL. This must

//locate at least one device because we earl ier changed

//the location of the first device to Room Earth.

cout < "Looking for devices in Earth and HAL." < endl; CCS::Controller::SearchSeq ss;

ss.length(2); ss[0].key.loc(CORBA::string_dup("Earth")); ss[1].key.loc(CORBA::string_dup("HAL")); ctrl->find(ss);

// Show the devices found in that room.

for (CORBA::ULong i = 0; i < ss.length(); i++)

//Increase the temperature of all thermostats

//by 40 degrees. First, make a new list (tss)

//containing only thermostats.

cout < "Increasing thermostats by 40 degrees." < endl; CCS::Controller::ThermostatSeq tss;

for (CORBA::ULong i = 0; i < list->length(); i++) { tmstat = CCS::Thermostat::_narrow(list[i]

);

if (CORBA::is_nil(tmstat))

continue; // Skip thermometers len = tss.length();

tss.length(len + 1); tss[len] = tmstat;

}

// Try to change all thermostats. try {

ctrl->change(tss, 40);

}

} catch (const CORBA::Exception & e) {

cerr < "Uncaught CORBA exception: " < e < endl; return 1;

} catch (...) { return 1;

}

return 0;

}

8.8 Summary

We have come a long way since we first started to discuss the C++ mapping in Chapter 6. Much of the code we showed in this chapter may still seem complex to you. However, consider the following.

Much of the code (such as initialization and helper functions) is boilerplate, and you can write it once and forget about it thereafter.

310

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

Much of the complexity in the client stems not from CORBA but from the fact that we have chosen to use complex nested data structures to illustrate the details of the C++ mapping for the various IDL data types. If you were to use similar nested data structures using ordinary C++ or STL containers, the complexity would be at a comparable level.

On the other hand, consider that even though this client is fully distributed, when writing the client we enjoyed the following advantages.

The code never had to specify anything like a machine name or port number. The client will correctly find the server no matter where the server is physically located. The client is ignorant of whether the server is linked into the client binary, runs as a separate process on the same machine, or runs on a machine on the other side of the world.

The code never comes close to using something like a socket or a file descriptor.

The code is completely shielded from the underlying transport layer and communication protocols.

Connection management is transparent, and interactions appear connection-less. There is no need to obtain something like a session handle or to negotiate quality-of-service parameters such as time-outs.

Client and server correctly communicate with each other regardless of implementation language and hardware architecture. A client written in C++ will correctly interact with a server written in Smalltalk, and a client running on a big-endian CPU will correctly work with a server on a little-endian CPU. Things such as differing alignment restrictions and padding rules for complex data are irrelevant to both client and server.

The server need not be running when the client makes a call. As you will see in Chapter 14, you can arrange for the ORB to automatically start the server on demand when the client uses it and to shut down the server again some time later.

The source code is remarkably free from distribution artifacts. Remote invocations look like ordinary method calls, and even error handling is no more complex than for local function calls that can throw exceptions.

Servers can migrate from machine to machine. We will discuss the details of this in Chapter 14. For now, you should simply note that the same controller reference will continue to work for the client even if the server is started on one machine today and on a different machine tomorrow. In other words, CORBA allows you to create references that (unlike URLs) do not break if the physical location of a server is changed.

The server can be implemented in Java today and can be replaced by a C++ implementation tomorrow. The same client code can continue to use the same reference to the controller.

311

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

The client is not concerned with maintaining type safety. All interactions are compiletime type-safe.

The ORB transparently takes care of things such as loss of connectivity during interactions with the server. If connectivity is lost, a high-quality ORB will attempt to reconnect to the server before propagating a communication failure to the client application code.

As you can see, the list of advantages is quite long and by no means trivial. If you have ever written interprocess communication code yourself—for example, using sockets or even simple things such as UNIX pipes—you know that to achieve any degree of reliability and portability, you must expend a lot of effort. Writing such low-level communication code is difficult and time-consuming, and it would likely take you years to bring it to the level of convenience offered by CORBA. In our opinion, CORBA provides the most cost-effective way in existence for writing distributed applications. To put it more bluntly, a CORBA remote procedure call is likely to be the easiest portable remote procedure call you have ever written.

So what about all the complexity of the C++ mapping? As you continue reading the remainder of this book, you will rapidly become familiar with the mapping. You will quickly absorb things as background knowledge that seem complicated now. After a week or two of writing CORBA code, you will seldom notice things such as memory management rules. After you are a little more familiar with it, the C++ mapping actually makes it easy to write correct code and makes it difficult to write incorrect code. We see this as CORBA's most compelling advantage: you are free to focus on application semantics without continually getting distracted by infrastructure concerns.

312