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

Because we have explicitly provided the instantiation for this method, the C++ compiler will not instantiate the default implementation.

Although using template specialization in this manner allows for legacy code integration using tie class templates, it is probably much easier to write and maintain your own specialized tie servant classes. This is because you will likely have to specialize every single IDL method for the tie class for each different tied object class type, a task that is largely equivalent to writing your own delegating IDL method implementations. Furthermore, some C++ compilers still have trouble dealing with template specializations, so you might encounter portability problems using that approach.

Because tie classes use delegation instead of inheritance, they can be useful for applications that must avoid inheritance. Sometimes you must avoid complicated servant class inheritance because of C++ compiler bugs. However, because of the increasing quality of contemporary C++ compilers, problems related to multiple inheritance using virtual base classes (common in servant class hierarchies) do not occur as often as they once did. A more common situation in which you must avoid inheritance is when you are using an object-oriented database (OODB) to store your object implementations. When an OODB stores a C++ object, it must not only store all data members inherited by that object, it must dereference all pointers held by that object and store the values they point to as well. By breaking the inheritance bond between the tied object and the skeleton hierarchy, the OODB stores only the tied object and need not store any skeleton data members, especially those that might be pointers into the ORB implementation.

In general, the chances are slim to none that anyone has existing non-CORBA C++ classes lying around that just happen to provide the exact syntax and semantics to allow them to serve as tied objects. This means that you must perform extra work to understand, implement, and maintain tie template specializations to smooth over the inevitable mismatches between CORBA and your legacy classes. We therefore recommend that unless you are storing your C++ objects in an OODB, you avoid using tie classes and instead use your own inheritance-based servants.

9.10 Summary

We have now completed our initial coverage of the details of implementing CORBA servers. Although the examples we show in this chapter are simple compared with realworld CORBA applications, they present the fundamentals of how to use the POA and how to implement CORBA object servants in C++.

Just as with the sample client application shown in Chapter 8, you gain significant advantages by writing the server as a CORBA application.

The server is never required to work with details concerning underlying network protocols or transports. For example, you never have to determine your machine name, open a TCP socket, listen for incoming messages on a network port, or unmarshal

345

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

network messages into C++ data types. Instead, the ORB and the POA take care of these kinds of details.

Whether your clients reside on another machine on the other side of the world or within the same server process, your IDL method implementations need not vary. Memory management rules for arguments and return values are identical whether a client is remote or collocated.

You need not worry about which programming languages were used to implement your clients, nor which hardware architectures or operating systems they run on.

These advantages, as well as many others we discuss in Section 8.8, allow you to avoid worrying about details of distribution infrastructure and focus instead on implementing your applications.

This chapter also completes our presentation of the details of the C++ mapping. We show rules for how your server applications must deal with simple types, fixed-length types, and variable-length types. Naturally, these rules are only the server-side analog of the client-side parameter passing rules we explain in Chapter 7. Although they might seem complicated at first, their consistency makes them easy to learn and to use intuitively after you work with them for a short time.

Our presentation of using the POA in this chapter was intended to remain at the introductory level. We explain just enough to allow you to write simple server applications. You should not get the impression that all CORBA servers are as simple as what we have shown here. In fact, the type of POA-based application code presented here makes up only a small percentage of industrial-strength CORBA applications. As you will learn in Chapter 11, the POA has many features that make it scale well with respect to several different time/space trade-offs for many different types of applications.

346