Exploring CORBA object of CORBA object life cycle

As we know, the POA specification defines a CORBA object as an abstract entity with identity, interface, and implementation. From the client's point of view, the object is represented as an object reference, the object reference encapsulates the object interface type and identity, and contains enough information to locate the object's implementation. But what about the server's point of view?

1. Servo Object

The POA specification introduces the concept of the Servo object (servant), which makes the abstract CORBA object completely separate from the concrete programming language entity that implements the object function. So from the server's point of view, the CORBA object is implemented as a servo object. Remember that CORBA is a separate architecture from the programming language. A servo object can be implemented as a C + + or Java class, or it can be implemented as a series of COBOL segments or C functions. The concept of a servo object also helps to reflect this independence from the programming language.

So how does the orb find the right servo object for a coming request? There must be some kind of binding between the CORBA object keyword and the servo object. The following discusses this binding and discusses how the application can control this binding.

2. Object Adapter

The CORBA architecture defines the object adapter concept, which is used to handle the problem of how applications and O-B interact to manage the lifecycle of servo objects and CORBA objects. A good definition of object adapters comes from Schmidt and Vinoski (1 9 9 7): "Object adapters are a CORBA component that is responsible for adapting CORBA's object concepts to the concept of a servo object in a programming language." "As discussed earlier, the CORBA object is abstract and the servo object is concrete, so this definition fully expresses this."