 |
CORBA Defanged (Part
II)
by Niranjan Ramakrishnan
In any distributed system, the primary feature is the communication of commands from one participant to another. In the last article, we saw that CORBA offers a kind of backbone, called the Object Request Broker, which permits such communication. The ORB, while essential, is not all that we need to make distributed computing possible with CORBA. In this article we shall discuss some other key elements of CORBA - stubs and skeletons, and the Interface Definition Language (IDL).
The distributed gumshoe
Unlike the detective novels of the footprint-and-cigar-ash genre,
where cigarette stubs and human skeletons pop up in unexpected places to curdle
the reader's blood, stubs and skeletons in CORBA actually help take the
mystery out of distributed computing. They represent a very simple concept -
one that is used in hundreds of situations every day - abstraction. Here are
three examples of using stubs as abstractions in real life.
- When you delete a
file from your file manager (whatever your system), all you are doing is
dealing with an icon - the icon represents the actual file. As far as
you, the user, are concerned, the icon is the file. This way, you
don't have to know where the file is located on your disk, or even whether
it is on your disk. Even further, the UI icon itself likely knows nothing about
the file system. It may only merely pass on your command to another abstraction
- a file object, say, an abstraction for the real file in the file system. It
is this object that actually knows about the file system.
- When you call
someone on the phone, as far as you are concerned, they are no further than
your phone, in a sense, for the phone is their representative in your home.
Your phone (stub) communicates with their phone (skeleton).
- When countries communicate with each other, they rarely communicate directly; instead, each uses the embassy of the other(stub). The embassy passes on the message received to the appropriate department in the home country's foreign ministry or state department (skeleton).
Stubs and Skeletons
Quite simply, distributed computing means providing a representative for the server within the client, and a representative for a client within the server. These are called 'stub' and skeleton' respectively.
- Stub
- an 'outbox', whereby a client program can send a request to a server.
- Skeleton
- an 'inbox', whereby a server program can receive the request sent by the client, 'unpack' it, and invoke the appropriate methods on the server machine.
So, why stubs and
skeletons? Why not have each client call the server directly? The answer is
simple. You don't want to require each application developer to learn all
about packaging arguments or to worry about how the function call is
implemented on the server machine. Besides, this makes the program
flexible. If you want to reimplement the program, the client does not have
to change a thing as long as the stub interface does not change.
As a last example of stubs and skeletons, consider this: You operate
your TV with a remote control. The remote control has many or all of the
'commands' the TV itself provides. As far as you are concerned, the remote
control is completely equivalent to the TV's control panel. Thus, the remote
control is the stub.
On the other side, the TV has a remote receiver which responds to
commands issued by your remote control, and translates them to the
corresponding TV commands such as Volume Up, Volume Down, Mute, Channel Up,
Channel Down, etc. The receiver which takes your remote control commands is
the skeleton.
Made for each other
Stubs and skeletons are inseparable - they are
created to work with each other. Just as your remote control or garage door
opener may not work with another TV or another garage door, every stub works
with a corresponding skeleton, and vice-versa. This presages a very real
problem. In the real world we don't expect the remote control to work with
someone else's TV (many are pleasantly surprised see it work even with their
own!). In CORBA, though, interoperability is the whole purpose: we want
clients running a variety of software to be able to invoke the same program on
the server. This can be quite a challenge. How can we be sure, for example,
that a client program running C++ and one running Smalltalk can both access and
run the same program on the server machine? The answer lies once more in our
old ally - abstraction.
The Interface Definition
Language (IDL)
The OMG's Interface Definition Language (IDL) is the
Esperanto of distributed computing. It is the language you must use if
you want standardized interfaces which will run with a variety of languages,
platforms, etc. It represents an abstract mechanism to specify an interface.
But, what is an interface? An interface is the front end of a
contract. It advertises services that an object offers; no indication is
necessary (or even advisable) on how these services will be provided. In C++,
interfaces are typically provided via a header (.h) file. In Java, there is a
construct called interface, which permits only the specification of
services and prohibits any further details.
The IDL, formulated in
the age of C++ but anticipating the age of Java, combines the two. Its syntax
resembles C++, but, like Java, it permits only the listing of services, and no
details.
Every CORBA implementation comes with an IDL compiler,
which is able to compile IDL code to generate code in a programming language.
The way IDL is translated to a language by a particular CORBA implementation is
called a mapping. Thus, there is an IDL-to-Java mapping, an
IDL-to-C++ mapping, an IDL-to-Smalltalk mapping, etc. Were it only that
simple! In reality there is Vendor X's IDL-to-C++ mapping, and Vendor Y's
IDL-to-C++ mapping, Vendor Z's IDL-to-C++ mapping, etc.
Thus, CORBA
programmers write their code in IDL, and use the IDL compiler to generate code
in their language of choice. The generated code consists of several files,
including one for the stub and one for the skeleton. The stub program is
stationed on the client, and the skeleton on the server. Client code is thus
able invoke the stub, which knows how to communicate in a manner dictated by
the server.
In this discussion of stubs and skeletons and the ideal
(IDL) mystery, we can be permitted to paraphrase that old-fashioned detective
of the modern era, Lieut. Columbo: "Just one more question, ma'am.
But how does the stub or the skeleton know about the ORB?"
Snaking your way to the
ORB - the BOA
An object adaptor is glue code to interface
between the ORB and your objects. It allows an object to register itself with
the ORB, to activate a server if it is not active, etc. CORBA allows
different kinds of object adaptors, but all implementations of CORBA offer one
adaptor, called the Basic Object Adaptor (BOA). Each server must first
register itself with the BOA. Vendor implementations offer calls to initialize
and register servers with the ORB. That is to say, the BOA offers an
interface to the ORB for use by your application.
To be continued...
Top
Journal Archives |
Send Feedback
Copyright© Pantheon Systems, Inc., All rights reserved.