Diff btw a Corba object and a servant

I have been perplexed by the concepts of Corba object and servant. Finally after a lot of reading, things are falling into place. The following articles give a good explanation of the same:

http://www.javaworld.com/javaworld/jw-09-2002/jw-0927-corba_p.html
http://www4.informatik.uni-erlangen.de/~geier/corba-faq/poa.html

Excerpt from the above articles:

In the CORBA world, an object is a programming entity with an identity, an IDL (interface definition language)-defined interface, and an implementation. An object is an abstract concept and cannot serve client requests. To do so, an object must be incarnated or given bodily form—that is, its implementation must be activated. The servant gives the CORBA object its implementation. At any moment, only one servant incarnates a given object, but over an object's lifetime, many (different) servants can incarnate the object at different points in time.
The terms creation and destruction apply to objects, while the terms incarnation and etherealization apply to servants.
Once an object is created, it can alternate between many activations and deactivations during its lifetime. To serve requests, an object must:
1)Be activated if it is not active.
2)Be associated with a servant if it does not already have one. Just because an object is active does not mean that it has an associated servant. You can configure/program the POA to use a new servant upon request.

A client views a CORBA object as an object reference. The fact that a client has an object reference does not mean that a servant is incarnating the object at that time. In fact, the object reference's existence does not indicate an object's existence. If the object does not exist (that is, it has been destroyed), the client will receive an OBJECT_NOT_EXIST error when it tries to access the object using the object reference. However, as noted above, if the object is in a deactivated condition, it will activate, a process transparent to the client.

Servant: A programming language entity that exists in the context of a server and implements a CORBA object. In non-OO languages like C and COBOL, a servant is implemented as a collection of functions that manipulate data (e.g., an instance of a struct or record) that represent the state of a CORBA object. In OO languages like C++ and Java, servants are object instances of a particular class.

The POA distinguishes between the CORBA object reference (IOR) and the implementation object that does the work. This implementation object is called a servant. A BOA-based approach has the IOR and servant existing at the same time. A POA-based approach can support this, but can also support IORs existing without being associated with servants, and also servants existing without being associated with IORs.

Obviously, the association between an IOR and a servant has to be made at some point, to make the servant a useable CORBA object. But this association can be done on-demand. Consider the following example scenarios to motivate the advantages of on-demand association:

• A pool of servants can be instantiated, and then associated in turn with IORs, as needed.
• A set of IORs can be created for the purposes of publishing the references to the Name Service, without going through the work to actually instantiate the servants.

Moreover, the POA allows a single servant to simultaneously support several IORs.
All of the above significantly contribute to scalable applications.

HOW DOES THE POA MAKE THE ASSOCIATION BETWEEN SERVANTS AND CORBA OBJECTS?

This is where the Object ID and and POA Active Object Map come in. So, for a given POA, the Object ID identifies a specific CORBA object, which is used in the Active Object Map to identify the servant.