Please skip this chapter and head straight to the first examples if you are the sort of person who understands better just by example. The examples chapter can be read without reading this chapter.
This chapter is to help you get an understanding of all the different terms that are bandied about ORBs and CORBA.
CORBA is a collection of standards defined by the Object Management Group (OMG - the sole purpose of the OMG is to provide a framework for people to agree on standards for CORBA). The OMG does not provide any working implementations of the CORBA standards, and so can be impartial. Most people who use CORBA only really keep one or two of these standards in their heads, but all the standards are free to be read from the OMG web site http://www.omg.org/ . However it is good to have an idea about how all these standards fit together to provide CORBA.
The basic mechanism of CORBA is to run a method (that is a function) of an object from a separate program (in fact the program need not be separate, but don't worry about that yet). Going from one end of this to the other, this is what needs to be defined.
A definition of what methods can be called on what objects need to be provided for both the caller and callee. This is done using the Interface Definition Language or IDL of the object. The only information which is required to make a caller able to call an object on a remote server is the IDL of the object. Everything else is handled by the standards defined by the OMG.
The calling program needs to identify the (possibly remote) object somehow. This is done by something called an IOR, which can be represented as a string, and therefore used as an argument in the program. Decoding the IOR the client can tell the CORBA protocol and character encoding the server supports, beside much more details.
The calling program needs to actually call the method on the object somehow. This is done in the programming language of the caller, and the way the IDL of the maps to the programming language is standardised by the OMG. This is called the Language Mapping, and all the different ORBs provide at least one mapping. ORBit provides at the moment a C mapping.
Of course, C is a compiled language, so to write a C program which is going to make an ORBit call, one needs to compile the IDL of the object one wants to access using the orbit-idl compiler, and then write a C program which call functions that the orbit-idl compiler defines, compile this user written code along with the code generated for the client by the orbit compiler, and link it to the orbit and network libraries.
However for more dynamic languages (eg, Python), a more natural way of using CORBA is to dynamically load in the IDL definition and use it without any separate compile phase. The beauty of CORBA is that it supports both mechanisms
The function call on the client now gets handled by the Object Request Broker or ORB and gets translated to the actual TCP/IP request to the server ORB which is handling the object to be called. The two ORBs communicate via a protocol called the Internet InterOrb Protocol or IIOP, which is standard. This means that the ORBs could come from different suppliers, and never had been tested against each other, and yet still work.
On the server side, a mirror of the client process happens, translating the request from TCP/IP packets to an actual call in the programming language used to write the server. The servant object, written by whoever wrote the server then provides the return values, and the results are sent back down the ORBs to the client in reply message.
This may seem like a lot of work for a rather simple thing, but the idea about having so many standards is that some of the standards can change and adapt without everything in CORBA shifting. Learning about CORBA is usually much easier by example, so I would dip into the next chapter and come back to this one later.