Chapter 35. Transitioning to CORBA

FAQ 35.01 What is CORBA?

CORBA stands for Common Object Request Broker Architecture. It is a standardized way for objects to communicate with one another even if the objects exist on different computers and/or if they are written in different programming languages.

CORBA is a specification rather than an implementation—the various CORBA vendors have created software that complies with (or tries to comply with) the CORBA specification. There are numerous CORBA implementations on the market and CORBA is readily available on most platforms.

FAQ 35.02 What is an ORB?

ORB stands for Object Request Broker. The ORB is the plumbing that enables member functions to be called on objects that may be remote and/or may be written in different programming languages.

A key feature of the ORB is transparency. The caller of a member function does not need to know whether the object is local or remote (location transparency), the programming language used to implement the object (implementation transparency), or the type of computer that the object is running on (hardware transparency). The overall effect is to provide seamless communication among objects that may be distributed on a heterogeneous network of computers.

FAQ 35.03 What is IDL?

IDL stands for Interface Definition Language. It allows developers to define the interfaces for distributed services along with a common set of data types for interacting with the distributed services. Syntactically, IDL looks a lot like C++, but unlike C++, IDL is a specification language rather than an implementation language (see FAQ 35.10).

FAQ 35.04 What is COS?

COS stands for Common Object Services. COS is also known as CORBA Services. These services are common components that handle things like creating objects, controlling access to objects, keeping track of relocated objects, managing objects and their relationships, and so on.

Typical CORBA Services include Naming, Event Management, Lifecycle Management, Transaction Management, Persistence, and Security. CORBA Services provide infrastructure utilities that improve application consistency and programmer productivity.

FAQ 35.05 What is OMA?

OMA stands for Object Management Architecture. It's the big picture architecture that includes the CORBA (the ORB itself), CORBA Services (COS), and CORBA Facilities. It ties all the pieces together.

FAQ 35.06 What is OMG?

OMG stands for Object Management Group. OMG is an international consortium with nearly 1000 members, including software vendors, software developers, and users. OMG is the organization that develops and standardizes the OMA.

This chapter will be deliberately loose in distinguishing between CORBA, OMA, and IDL. Technically, IDL is a proper subset of CORBA, which is a proper subset of OMA, but it is easier to speak of some IDL issues as CORBA questions than it is to use precise wording that could confuse a newcomer to the subject.

FAQ 35.07 What is the purpose of this chapter?

The purpose of this chapter is to help developers and development organizations avoid some of the common pitfalls that can occur when they first encounter distributed objects and CORBA. It is not intended to be a tutorial that provides all the details of using CORBA. Rather, this chapter skims a few of the important issues without getting into technical detail.

Entire books are devoted to using CORBA, and readers interested in the details of, for example, static versus dynamic member function invocation or the proper use of the _var and _ptr suffixes should consult them. Another good way to get general information on CORBA is to visit the Web site of the Object Management Group (OMG) by pointing the browser at http://www.omg.org.

FAQ 35.08 What is the most important message of this chapter?

CORBA is nontrivial and requires serious effort, even for experienced C++ programmers.

Because CORBA's Interface Definition Language (IDL) looks so similar to C++, many programmers assume that CORBA doesn't have a steep learning curve. This is far from the truth, and most of this chapter is dedicated to showing why there are and have to be major differences between C++ and CORBA. Most of these differences are inherent in any approach to distributed objects.

Also, it's important to understand where CORBA fits into the grand scheme of things. It offers critical middleware and useful components for developing major systems, but the technical differences between the various CORBA implementations or between CORBA and COM are usually less important than business considerations.

FAQ 35.09 What are the important concepts behind CORBA?

The key concepts are

1. Platform and language independence
2. Location transparency
3. An OO approach that includes interface inheritance within IDL
4. Interoperability between ORBs
5. A consensus-based industry standards process

CORBA uses the proxy design pattern to achieve platform and language independence. A proxy is a stand-in, or surrogate, for a “real” object and provides a client-side reference for accessing a server object that could be located anywhere. By decoupling the software architecture from the runtime environment, the software becomes more flexible and decisions such as which objects reside where can be controlled by a network administrator armed with time sensitive information that was not available to the software architects when they were designing the system.

IDL is a language for defining the interfaces for distributed objects, where the interfaces are similar to C++ abstract base classes with only pure virtual member functions. The IDL compiler converts the interface specification into the target language, which can be C, C++, Java, and so on. CORBA IDL supports interface inheritance, but since it is not an implementation programming language, it does not support inheritance of implementation (however implementation inheritance is normally used when implementing an IDL interface in an OO programming language such as C++).

ORBs from different vendors can communicate seamlessly because of the Internet Inter-ORB Protocol (IIOP), which runs over TCP/IP. The specification also supports DCE as the communications layer, but most CORBA users choose TCP/IP.

FAQ 35.10 Isn't OMG IDL pretty much the same as C++?

No.

IDL does have a C++-like syntax, and it includes these familiar features:

1. Basic data types such as short, long, float, char and others
2. Modules, which are roughly equivalent to namespaces
3. Exceptions (but see FAQ 35.13)
4. Strings, arrays, enumerations, typedefs, and so on

Despite these surface similarities, OMG IDL is not a programming language and it should not be compared as such with C++. OMG IDL is a platform-neutral specification language. OMG IDL can handle only interface issues—parameter types, return types, member function names. It cannot handle implementation issues such as member data, local variables, implementation code, and so on.

Furthermore, it is important to note that CORBA data types do not necessarily correspond to the similarly named C++ data types. For example, a long in IDL may or may not be equivalent to the C++ type long. A long in IDL corresponds to the C++ type CORBA::Long. For these reasons, C++ programmers who are implementing CORBA classes should be careful to use the CORBA data types rather than the C++ data types when necessary.

As another paradigm shift, C++ programmers who are new to CORBA tend to think of the CORBA data types (such as CORBA::Long) as aberrations that should be avoided. In reality the opposite is true: in a sense the CORBA data types are more portable than the C++ data types. For example, sizeof(CORBA::Long) is guaranteed to be 4 bytes on all hardware platforms, whereas sizeof(long) might not be exactly 4 bytes.

In addition, CORBA is responsible for transmitting data values between various machines as necessary and dealing with any data transformation issues. For example, different machines use different byte orderings for different data types (little-endian vs. big-endian), and different programming languages may represent data types differently than C/C++ does. CORBA manages all this transparently—if the communicating objects are on different machines it uses a process called marshaling to convert the source machine's binary data to the IIOP (the standard usually allows others) representation, and a reverse process called demarshaling to convert the IIOP representation at the destination machine back into the appropriate binary data format. One performance trick used by some ORBs is recognizing situations where these processes can be safely eliminated (such as when everything is on the same hardware and the networking can be avoided). Other performance tricks, such as receiver-makes-right semantics, avoid unnecessary message translations between machines using the same byte order and are part of the specification.

Finally, C++ programmers need to be aware that IDL does not support overloading, overriding, or pointers. So even though IDL looks a lot like C++, there are significant differences.

FAQ 35.11 Is the lifecycle of a CORBA object the same as the life cycle of a C++ object?

No, and this requires some mental adjustments.

C++ programmers are accustomed to objects that are known to exist because they were instantiated or known to be gone because they went out of scope or were programmatically destroyed. Reference counting (see FAQ 31.09) confuses the argument a little, but the point remains that the programmer feels that the object life cycle is under control.

But in the CORBA world, objects, particularly server objects, have much more of a life of their own. They may be brought to life once and never die because there is no scope to exit, or they may have a brief existence and commit suicide. It is also important to distinguish between a CORBA object and a servant for a CORBA object. A servant is a C++ object that provides the body of and implementation for one or more CORBA objects, and many C++ programmers stumble over this distinction. A CORBA object may have one or more servants, and a servant may represent (the proper technical term is incarnate) several CORBA objects during its lifetime. These are separate but related entities.

Emotionally, the experience for most developers is similar to the one they went through when they made the shift from procedural programming to OO. For example, programmers coming to OO (say, programming in C++) from procedural programming (say, programming in C) usually feel that they have “lost control.” The top-down command-and-control approach was part of their old programming paradigm, and an adjustment is needed. Eventually this uncomfortable feeling disappears. The shift from a traditional monolithic program to a distributed program is similar.

FAQ 35.12 Is the C++ code that interacts with the CORBA implementation portable to a different CORBA vendor?

No, but the situation has improved because of the Portable Object Adapter.

Unfortunately, the C++ code that interacts with a particular CORBA vendor's ORB is not 100% portable to other CORBA vendors. In the early days, it could be said that there was no such thing as a CORBA programmer, there was only an Orbix programmer or a VisiBroker programmer. Many of the differences between CORBA implementations could be traced to the imprecise specification of the Basic Object Adapter (BOA). In mid-1997, the OMG adopted a replacement for the BOA called the Portable Object Adapter (POA). The POA specification is voluminous as well as precise, and it introduces some unifying concepts for the CORBA paradigm. The reader is cautioned that many excellent CORBA books were written prior to POA and that BOA has been deprecated.

The net result of the POA is that conforming vendors do not have the same latitude as before and programs are much more portable than in earlier days.

FAQ 35.13 How do CORBA exceptions compare to C++ exceptions?

The same but different.

At first glance, it appears that C++ exceptions and CORBA/IDL exceptions are pretty much the same. For example the semantics of instantiating, throwing, and catching exceptions are the same as with C++. But there are also differences, some minor and some major.

As a minor difference, C++ implementations of CORBA member functions need to include CORBA::SystemException in the exception specification (either that or not have an exception specification; see FAQ 9.04). Another minor difference is that each CORBA exception must be mapped to a C++ class that inherits from the abstract base class CORBA::UserException.

A major difference is that normal C++ exceptions have both state and behavior but CORBA/IDL exceptions cannot have behavior. This is because exceptions may get transmitted to different computers (e.g., when the thrower and the catcher are on different computers), and it's easier for the implementation to copy pure data objects than to copy objects that have behavior.

IDL does not support inheritance in exception declarations, which can get quite nasty when C++ exceptions are mapped to CORBA exceptions and then thrown around the ORB. Finally, memory management is tough enough with C++ exceptions, but the issues become substantially more complex in a distributed object environment.

So don't be lulled into a false sense of security because the words sound the same. Exceptions in CORBA require a great deal of knowledge and experience that the beginner does not have and does not gain easily, no matter how familiar they are with C++ exceptions.

FAQ 35.14 Which CORBA implementation is best? Is CORBA better than COM?

The fact that these questions are being asked implies that they do not have a clear answer.

If there were one approach to distributed objects that was clearly superior in all respects, then the market would have gravitated to that solution and people wouldn't be asking, “Which is better?” But that hasn't happened, and there is probably a time and place for each alternative to shine. Many articles have been written about the technical differences between CORBA and COM, and each CORBA implementation has its voluble critics and fans. And there are intelligent technical people on both sides of these arguments.

So the only proper answer to the question is to take an open-minded approach to ORB selection, as opposed to the one-size-fits-all mentality favored by bigots. Also, it is important to recognize that, in many cases, the technical differences can be relatively small and that nontechnical issues such as pricing, vendor support, or training may dominate the decision process.