Basic CORBA

The following are a simplified description of minimal key elements required to learn CORBA programming quickly.

An Object Request Broker (ORB) is a layer of code that lets objects transparently make invocations on remote or local objects. The ORB layer of code is encapsulated in the form of an object. The ORB object is often referred to as an pseudo-object as it is only accessible to the current running process. It cannot be made accessible remotely as can a CORBA object. This ORB is also sometimes referred to as a locality constrained object.
ORBs communicate with each other using a communication protocol that abides by General Inter-Orb Protocol(GIOP). GIOP must use a connection oriented network protocol A specific example of GIOP which runs on TCP/IP networks is the Internet Inter-ORB Protocol. IIOP uses Transmission Control Protocol(TCP) for connection oriented communication.
A CORBA Object has an interface with operations and attributes. An interface is much like a C++ class with public member methods. In CORBA terms, the C++ class member methods are called as operations. Attributes are much like data members of C++ classes. But attributes correspond to nothing more than C++ mutators and accessors of the some piece of data. Calling a method on a CORBA Object is referred to as an invocation of an operation on an object.
Unlike C++ objects, CORBA objects are virtual. A CORBA object can exist with out having any real code to handle the incoming invocations. The real code, written in some language that is running to service invocation, is called a servant. In earlier OMG documentation, a servant was called an object implementation. When the servant does exist and is ready to handle the incoming invocations, the servant is said to incarnate the CORBA Object. When no servant exists to handle invocations on CORBA Object, than CORBA Object is said to be etherealized. Going from an etherealized state to an incarnated state is called servant activation. Servant deactivation is the process of an a servant going from an incarnated state to an etherealized state. A single servant may incarnate several different CORBA Objects.
A server in CORBA is any process that hosts servants(which incarnate CORBA Objects). Activation of a server is the process of converting a running server to start receiving incoming messages. , while deactivation means that the server is no longer able to receive messages..
A client is any piece of code that attempts to access a CORBA Object.
An Object Adapter(OA) is an object that is is found in the server which offers services and dispatches messages to servants. A server can have several OA's, and each OA can be responsible for forwarding messages to several servants. OA's are responsible for creation of new CORBA objects, servants, and the binding of a CORBA object to a servant.
The Basic Object Adapter (BOA) is an instance of an OA. The Original CORBA specification, which defined this OA, did not give a complete functionality through an IDL interface, and many ORB vendors extended the functionality of the BOA.
The Portable Object Adapter(POA) is a newer instance of an OA. OMG standardized the POA from the lessons learned from vendor implementations of BOA.
The POA Manager is used to control client invocation messages to one or more POAs.. For instance, the POA Manager can be used to drop all invocations to a POA.
POAs can have several policies(ie threading, persistent/transient,id generation) which dictate how it functions. The RootPOA is a POA that has a default set of policies(ie Single Threaded, Transient, POA Generated Object ID's).
An Interface Repository(IR) is an database that holds CORBA object location information. A client may use an IR to find a specific CORBA object. A client can also find complete information through the IR about an interface, its operations, and the arguments to the operations.
An Interoperable Reference(IOR) is an opaque reference to an CORBA Object which can give access to the CORBA Object's operations and attributes. The IOR gives access to the the CORBA Object irrespective of where the Object really is. An IOR is composed of several key components used to locate a CORBA Object: Protocol ID, Communication End Point, a Time Stamp, Object Adapter ID, and a Repository ID. IOR's can be converted into a string called an stringified IOR. The process is called stringification. The stringified IOR can be also turned back into an IOR This process is called objectification.
A proxy object logically embodies a CORBA Object. All the operations found on a CORBA Object are found as methods in the proxy object. An object reference variable points to a proxy object(logically it acts like it points to a proxy object). Proxy objects wrap all network communications internally.
All interfaces are defined in an implementation neutral language called CORBA IDL(Interface Definition Language). An IDL compiler for a specific language takes the IDL definitions in a file and generates server skeletons and client proxies in the language. A server skeleton is the base code with which one uses to write servant code.