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 Languageor
IDLof 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.
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
Brokeror
ORBand gets translated to the actual TCP/IP
request to the server
ORBwhich is handling the object to be
called. The two ORBs communicate via a protocol called the
Internet InterOrb Protocolor
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 written 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
This may seem like alot 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.