CORBA® BASICS
If you want to
understand CORBA, this is the place to start!
You can either read straight down the
page, or click on a question to go straight to a topic that interests
you.
|
Does your company have a networking
strategy, to ensure interoperability and control costs? |
I’m totally new to CORBA.
This page will get you started. We haven't assumed that you know anything
about CORBA. We did, however, assume that you know something about computing in
general, and distributed (that is, networked) computing in particular - at
least what you want to use it for, although not necessarily what you
have to do to get it to work.
Some of the points in our discussion are aimed at management, while others
are aimed at technical folks, but it's too soon to diverge. Don't worry about
point of view; by clicking on the topics that look interesting, you'll pick
the path that's best for you.
|
UML, another OMG standard, may be even more
widely used than CORBA. |
What is CORBA? What does it do?
CORBA is the acronym for Common Object Request Broker
Architecture, OMG's open, vendor-independent
architecture and infrastructure that computer applications use to work
together over networks. Using the standard protocol IIOP, a CORBA-based
program from any vendor, on almost any computer, operating system, programming
language, and network, can interoperate with a CORBA-based program from the
same or another vendor, on almost any other computer, operating system,
programming language, and network.
Some people think that CORBA is the only specification that OMG produces,
or that the term "CORBA" covers all of the OMG specifications.
Neither is true; for an overview of all the OMG specifications and how
they work together, click here. To continue with CORBA, read on.
|
Some large companies are embedding CORBA
in networked devices for finance and medical applications. |
What is CORBA good for?
CORBA is useful in many situations. Because of the easy way that CORBA
integrates machines from so many vendors, with sizes ranging from mainframes
through minis and desktops to hand-helds and embedded systems, it is the
middleware of choice for large (and even not-so-large) enterprises. One of its most important, as well most
frequent, uses is in servers that must handle large number of clients, at high
hit rates, with high reliability. CORBA works behind the scenes in the
computer rooms of many of the world's largest websites; ones that you probably
use every day. Specializations for scalability and fault-tolerance support
these systems. But it's not used just for large applications; specialized
versions of CORBA run real-time systems, and small embedded systems.
|
The four keys to object orientation are
* Encapsulation
* Polymorphism
* Inheritance
* Instantiation
In CORBA, client and object may be written
in different programming languages! |
How about a high-level technical
overview?
CORBA applications are composed of objects, individual units of
running software that
combine functionality and data, and that frequently (but not always) represent
something in the real world. Typically, there are many instances of an
object of a single type - for example, an e-commerce website would
have many shopping cart object instances, all identical in functionality but
differing in that each is assigned to a different customer, and contains data
representing the merchandise that its particular customer has selected. For
other types, there may be only one instance. When a legacy application, such
as an accounting system, is wrapped in code with CORBA interfaces and opened
up to clients on the network, there is usually only one instance.
For each object type, such as the shopping cart that we just mentioned, you define an interface in OMG
IDL. The interface is the syntax part of the contract that the server object
offers to the clients that invoke it. Any client that wants to invoke an
operation on the object must use this
IDL interface to specify the operation it wants to perform, and to marshal the
arguments that it sends. When the invocation reaches the target object, the same
interface definition is used there to unmarshal the arguments so that the object
can perform the requested operation with them. The interface definition is then
used to marshal the results for their trip back, and to unmarshal them when they
reach their destination.
The IDL interface definition is independent of programming
language, but maps to all of the popular programming languages via OMG standards: OMG has standardized mappings
from IDL to C, C++, Java, COBOL, Smalltalk,
Ada, Lisp, Python, and IDLscript.
For more on OMG IDL, click here.
This separation of interface from implementation, enabled by OMG
IDL, is the essence of CORBA - how it enables interoperability, with all of
the transparencies we've claimed. The interface to each object is defined
very strictly. In contrast, the implementation of an object - its
running code, and its data - is hidden from the rest of the system (that is, encapsulated)
behind
a boundary that the client may not cross. Clients access objects only through
their advertised interface, invoking only those operations that that the object
exposes through its IDL interface, with only those parameters (input and output) that are
included in the invocation.
Figure 1 shows how everything fits together, at least within a single
process: You compile your IDL into
client stubs and object skeletons, and write your object (shown on the right)
and a client for it (on the left). Stubs and skeletons serve as proxies for
clients and servers, respectively. Because IDL defines interfaces so
strictly, the stub on the client side has no trouble meshing perfectly with the
skeleton on the server side, even if the two are compiled into different
programming languages, or even running on different ORBs from different
vendors.
In CORBA, every object instance has
its own unique object reference, an identifying electronic token. Clients
use the object references to direct their invocations, identifying to the ORB
the exact instance they want to invoke (Ensuring, for example, that the books
you select go into your own shopping cart, and not into your neighbor's.) The client
acts as if it's invoking an operation on the object instance, but it's actually
invoking on the IDL stub which acts as a proxy. Passing through the stub on the client side,
the invocation continues through the ORB (Object Request Broker), and the skeleton on the implementation
side, to get to the object where it is executed.
|
The CORBAservices provide standard ways of
passing object references around your network of CORBA objects.
Location Transparency keeps your
applications flexible. |
How do remote invocations work?
Figure 2 diagrams a remote invocation. In order to invoke the remote object
instance, the client first obtains its object reference. (There are many ways to
do this, but we won't detail any of them here. Easy ways include the Naming
Service and the Trader Service.) To make the remote invocation,
the client uses the same code that it used in the local invocation we just
described, substituting the object reference for the remote instance. When
the ORB examines the object reference and discovers that the target object is
remote, it routes the invocation out over the network
to the remote object's ORB. (Again we point out: for load balanced servers, this
is an oversimplification.)
![Figure 2](https://webarchive.library.unt.edu/eot2008/20081106022636im_/http://www.omg.org/images/logos/diagram-orb_to_orb.gif)
How does this work? OMG has standardized this process at two key levels:
First, the client knows the type of object it's invoking (that it's a shopping
cart object, for instance), and the client stub and object skeleton are
generated from the same IDL. This means that the client knows exactly
which operations it may invoke, what the input parameters are, and where they
have to go in the invocation; when the invocation reaches the target, everything
is there and in the right place. We've already seen how OMG IDL accomplishes
this.
Second, the client's ORB and object's ORB must agree on a common protocol
- that is, a representation to specify the target object, operation, all
parameters (input and output) of every type that they may use, and how all of
this is represented over the wire. OMG has defined
this also - it's the standard protocol IIOP. (ORBs may use other protocols
besides IIOP, and many do for various reasons. But virtually all speak the
standard protocol IIOP for reasons of interoperability, and because it's
required by OMG for compliance.)
Although the ORB can tell from the object reference that the target object is
remote, the client can not. (The user may know that this also, because of other
knowledge - for instance, that all accounting objects run on the mainframe at
the main office in Tulsa.) There is nothing in the object reference token that
the client holds and uses at invocation time that identifies the location of the
target object. This ensures location transparency - the CORBA principle
that simplifies the design of distributed object computing applications.
|
OMG's best support for server-side
scalability comes from the CORBA Component Model. |
That ORB/Skeleton Architecture on the Server side doesn't look very scalable. What did you leave
out?
Almost everything. Figure 1 doesn't show any of CORBA's mechanisms for
load balancing, resource control, or fault tolerance on the server side. We
deliberately kept the figure simple to demonstrate how CORBA interoperability
works.
For technical details on the ORB, click here. This
technical page includes more detail about how the ORB works, and the
interfaces it bears, including resource control and load balancing.
This FAQ continues with a description of the CORBA specifications.
|
The over 500 attendees at each OMG meeting
make it a happening as well as an occasion to advance the OMG
specification suite. |
What is CORBA 2? CORBA 3? What does the version number mean,
anyhow?
As we've already pointed out, CORBA is a suite of specifications issued by
the OMG.
We've put details of the specification process in their own part of this
tutorial. To jump to details about how OMG members work together to define new
specifications, click here.
Formally, CORBA 2 and CORBA 3 refer to complete releases of the entire
CORBA specification. However, because OMG increments the major release number
only when they make a significant addition to the architecture, these phrases
become a sort of shorthand for just the significant addition. So, "CORBA 2"
sometimes refers to CORBA interoperability and the IIOP protocol, and "CORBA
3" sometimes refers to the CORBA Component Model (even though the term
CORBA 3 really refers to a suite of ten specifications!). It's easy to tell, from the context,
which meaning an author intends.
To learn about how to download specifications, click
here. To skip the
download tutorial and go straight to the download page, click
here.
|
Do you have a CORBA success story? Email
us: scovert@omg.org |
Who is using CORBA already?
Thousands of sites rely on CORBA for enterprise, internet, and other
computing. The Object Management Group maintains an entire website
devoted to user design wins and success stories. At last count, there were over 300 stories on
the site. Click here and we'll take you there for a look.
|
|