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

NoFactory, InvalidCriteria, CannotMeetCriteria

);

};

};

The create_object operation can be used to implement a factory that can create any type of object given appropriate parameters. We can supply an unlimited amount of information to create_object (because the name-value sequence passed in the_criteria is unbounded) to guide the operation in how to create the new object. A likely implementation would be that create_object would not directly create a new object but instead would use the parameters to decide how to delegate the invocation to a more specific factory that actually knows how to create the object.

Because create_object must be able to return references to arbitrary types of objects, the return type is Object.

The supports operation should return true if the generic factory could create a new object if passed the same key. It returns false otherwise.

12.5 A Critique of the Life Cycle Service

It is instructive to examine a few of the design decisions made in the Life Cycle Service and the consequences of these decisions.

12.5.1 Generality of Design

By necessity, the Life Cycle Service is very general. The service must provide IDL interfaces that permit clients to control the life cycle of objects without knowing anything about the types or the semantics of the objects in question.

The design of the service clearly reflects this requirement for generality. For object creation, you can either use the GenericFactory interface or follow one of the factory design patterns discussed in Section 12.3. If you choose the GenericFactory interface, you must supply the parameters to the factory as namevalue pairs. As you will see in Chapter 15, values of type any are extremely flexible and powerful, but they are not nearly as easy to use as strongly typed values are. Moreover, even though type any is type-safe at run time, it is by necessity not type-safe at compile time. In other words, using type any replaces static compile-time type safety with dynamic run-time type safety. As a result, type mismatches are not detected until run time and are detected only if they actually occur. (In other words, they are detected only if we happen to have a test case that exposes the type mismatch.)

Specific create operations, such as the create_thermometer operation you saw in Section 12.3, do not suffer from these problems. The object reference returned from a

494

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

specific factory operation can be strongly typed, whereas a generic factory must by necessity return the reference as type Object. The generic return type forces the receiving client to narrow the reference to its actual type, something that is inconvenient and not statically type-safe.

The copy and move operations present the same trade-offs as the generic factory. Parameters are not statically type-safe, and the return value from copy is weakly typed (LifeCycleObject instead of a specific interface type, such as Thermometer).

12.5.2 Date of Publication

The Life Cycle Service was one of the first services to be defined and published by the OMG and, in some ways, is showing its age. For example, the FactoryFinder interface provides a generic hook to implement a selection mechanism that can choose one or more factories that are suitable to create the required object. Although this approach is valid, the problem is that it is too generic. In addition, creating an even halfway sophisticated factory finder can be as much work as building an entire application. As a result, we must make do with a simple factory finder unless we are prepared to expend a lot of effort.

More recently, in 1997, the OMG published an updated version of the CORBAservices specification [21]. This document defines the OMG Trading Service, which provides a powerful and flexible object discovery mechanism. A trader can (among many other things) act as a generic factory finder. The significant advantage of the trader is that you do not have to implement it yourself. It also provides interfaces that are far more powerful and flexible than a simple generic factory, yet they do not compromise type safety to the same degree. We discuss the OMG Trading Service in detail in Chapter 19.

12.5.3 Problems with the move Operation

The move operation presents two types of problems. One type of problem is conceptual, and the other is technical.

Conceptual Problems with move

The move operation is intended to enable object migration. In other words, a client can use it to direct an object to disappear from one server and to reappear in another. Even assuming that we have supplied sufficient information in the the_criteria parameter as to where and how the object should move, there are still serious conceptual issues associated with the idea of migration.

The notion of object migration does not rest easy with the CORBA object model. One of the central features of CORBA, as we point out in Chapter 2, is the notion of location transparency. In fact, CORBA does not embody the concept of object location in its

495

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

object model at all. Instead, CORBA goes to great lengths to hide the location of an object from clients and provides a notion of object identity that, together with an object's location, is encapsulated inside object references. Attempts by application code to look inside an object reference to find out "where" it points to are illegal.

This raises the question of whether an operation such as move even makes sense within the object model. If the object model has no sense of "here" and "there," why would clients, who are also part of the object model, want to move an object? To impart meaning to the idea of object location, we must step out of the system and look at it from a different level of abstraction. In other words, it is probably better to treat object location as an administrative aspect of CORBA rather than try to deal with it from inside the object model.

The server to which an object is moved may support the same protocol as the original server, but the client that instructs an object to move itself may not support the target server's protocol. In other words, to guarantee that after a move the client will not lose connectivity to the object, the client would have to have knowledge of both the original server's and the target server's protocols. However, making that knowledge available to the client destroys the protocol transparency of the CORBA object model.

The object to be moved may have persistent state in a database. Assuming that you can redirect the reference to the object to now denote an object in a different server, the question remains of how the persistent state for the object can be moved. Unless the source and the target server share a common data-base, it is difficult to see how this could be achieved without manual intervention.

You can treat the move operation as a logical copy of the physical object state, but you must be careful about its semantics. The CORBA object model requires that a particular object reference must denote the same object throughout the object's lifetime. After an object is destroyed, all its references must become permanently non-functional. This means that an object's identity must not change during the move, and that the fact of its moving must be undetectable to all clients in the system as far as the object's semantics are concerned. If you are not extremely careful, you might unwittingly violate this rule if some small detail of the object's state that is visible to clients is affected by the move.

The move operation raises the issue of object identity. This topic is full of pitfalls and is very difficult to define precisely. Object identity periodically becomes the subject of raging debate in the OMG, and it seems unlikely that agreement will ever arise from these discussions.

The issue is similar to a vexing identity question examined by philosophers (and science fiction writers!). If we were to record the complete physical makeup of all the matter in a person (in other words, completely capture the state of a person), we could destroy the person and keep only a recording of the person's state. Assuming that later, by some miracle of technology, we could completely rebuild the state of the person so that the

496

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

person comes back to life, does the reconstructed person have the same identity as the destroyed person? If so, where was that person's identity while the person was destroyed? Clearly, the topic of identity has strong metaphysical and religious connotations, so we will not pursue it further here. Suffice it to say that object identity is under application control and can therefore mean whatever is most suitable to the application. For an outstanding treatment of these and related questions, see [6].

Technical Problems with move

Apart from conceptual issues, there are also a number of technical problems with move. Because of CORBA's implementation and language transparency, when a client moves an object, the server at the original location and the server at the target location might use different CPU architectures or implementation languages. This raises the question of how the object could physically move in this case. At the very least, the source and the target server would have to have made prior arrangements for object migration by providing equivalent implementations of the object's behavior that happen to use different platforms and languages. This point illustrates that object migration is limited to precise and prearranged circumstances.

The specification of move requires that the object reference for the moved object remain functional (that is, that it "follow" the object to its new location). As you will see in Chapter 14, many ORBs are physically incapable of moving a single object from one location to another without also invalidating the object's reference. Even if an ORB supports migration of a single object, the feature presents serious challenges with respect to an ORB's performance and scalability. The implication is that move is unimplementable in at least the general case.

12.5.4 Interface Granularity

Recall from Section 12.4 that the way to support life cycle operations is to inherit from the LifeCycleObject interface, which provides the copy, move, and remove operations. The problem with this design is that if we inherit from LifeCycleObject at all, we inherit all three operations. For our thermostats and thermometers, that is bad news, because these devices support neither copy nor move semantics.

The specification states that if a particular operation, such as copy, does not apply to an object, the operation can raise either the NotCopyable exception or the NO_IMPLEMENT system exception. However, why would an object offer an operation if that operation always and unconditionally raises an exception when a client calls it? It is far preferable in most cases not to provide the operation in the first place because then type checking can take place at compile time.

The problem created by LifeCycleObject is that the granularity of the object model is too coarse. It would have been better to define three abstract interfaces, such as Removable, Copyable, and Movable, so that applications could use them as mix-in interfaces to compose the required functionality. A tempting approach to address the

497

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

deficiency of LifeCycleObject would be to add the three mix-in interfaces to the CosLifeCycle module and to change the definition of LifeCycleObject to inherit from the three mix-ins:

module CosLifeCycle { // Hypothetical IDL only!

// ...

interface Removable {

void remove() raises(NotRemovable);

);

};

interface LifeCycleObject : Removable, Copyable, Movable { // Empty

}; // ...

};

Unfortunately, the CORBA type system does not allow this. You cannot make any change to the definition of an existing IDL type even if you were to change its repository ID. After an IDL definition is published, it becomes immutable. The reason is that any change, no matter how innocuous, can break existing client code. For example, if you were to build a client that uses the preceding hypothetical IDL and then were to recompile the client using a different ORB that provided the original version, the code would not compile. Because of the lack of a versioning mechanism in CORBA, IDL deficiencies are difficult to address except by creating new definitions in a different module.

12.5.5 Should You Use the Life Cycle Service?

The Life Cycle Service has a number of deficiencies. Some of them, such as weak type safety, are a necessary consequence of the service's generality. Other deficiencies, such as

498