The Advent of Object Request Brokers
Oracle Database Tips by Donald Burleson
In the early days of object computing
programmers recognized the benefits of having object within different
frameworks communicate with each other. Unfortunately, most objects are
tightly coupled with their procedural environment, such that it was very
difficult for a C++ object to communicate with an object implemented in
the SmallTalk language. This communications problem led the early
object programmers to create Object Request Brokers, or ORBs, to
facilitate communications between objects by providing a middleware
layer that would insulate the proprietary nature of the object from the
interface. (Figure 4.1)
Figure 4.1 - An example of an Object Request
As we can see from Figure 4.1, the ORB
communicates with three components. These three components work together to
provide a complete application environment.
- The Application Object interface is a component-based application performing
particular tasks for a user. As we know from our discussion of aggregate
objects, an application is typically built from a large number of basic objects,
and these objects may be nested and combined with other objects to create the
database object framework. The ORB is designed to communicate with these
application objects, allowing them to pass messages to other application
objects, or to any of the other object components, such as common facilities or
- Domain Interfaces are used to allow for the execution of application-specific
functions within the environment, and are generally used to allow communications
with diverse hardware and software platforms.
- Object Services are provided to create objects, to control access to objects,
to keep track of relocated objects, and to control the classes of the objects.
The purpose of object services is to make a generic environment in which single
objects can perform their tasks. The goal of Object Services is to provide a
consistent environment and hopefully improve the reusability of objects across
- Common Facilities are used to provide non-object specific services, such as
printing, e-mail and word processing. Common facilities are generic across the
environment, and are shared by all of the users of the ORB.
The idea behind an ORB was to create a framework
where they could mix and match language independent objects via a common
interface layer. At the lowest level, an ORB is a middleware software component
that communicates with objects using a well defined interface protocol. ORBs
can also communicate with other ORB's using the same common interface, thereby
creating a framework for distributed computing that can span database
architectures and hardware platforms.
This is where the Object Management Group
entered the picture. In 1991, the OMG produced a specification for standard
method for writing ORBs called the Common Object Request Broker Architecture, or
CORBA. Numerous vendors rushed to develop ORBs that complied with this
standard, most notably OBM with their Distributed System Object Model (DSOM).
Despite the early work of the OMG with their
CORBA standard there has been a huge push from Microsoft to dominate the object
market. In 1995, Microsoft entered the market with its Component Object Model
(COM). Microsoft enhanced COM to include distributed communications in their
DCOM model. DCOM has a natural advantage in the ORB marketplace because of its
tight integration with the Windows-NT operating system. (Figure 4.2)
Figure 4.2 - The Microsoft DCOM Architecture.
The DCOM architecture allows for a client object
to request an object service from any servers, both local servers as well as
remote servers. These object services may take the form of report requests for
standard report and encapsulated data that resides on other servers.
Let's take a look at the details of a DCOM
session. When a message (RPC) is received at a remote host, the stub object
acts as a listener and intercepts the RPC call. The stub object receives
incoming requests and dispatches the request to the appropriate local object on
the host. The request is then processes and passed back through the stub object
to the originating object.
DCOM has a tremendous advantage over CORBA in
that it is already available for use by anyone who is running a MS-Windows
client. To use DCOM, an applications needs only to check with the NT registry
to locate the remote ORB, where it can easily invoke a request for services to
the remote ORB. For the fast implementation of distributed database objects,
Microsoft's DCOM has another natural advantage since it is instantly available
without all of the customization that is required when creating a proprietary
Using an ORB as the central focus for
application development is not a new idea. Consider the popular client-server
products, Forte and Dynasty. Forte and Dynasty allow the developer to "balance"
the load on their client-server environment by moving process code from the
client to the server while the application is running. These products achieve
their ability to move process code in a dynamic fashion solely to their use of
an internal ORB mechanism.
As a practical matter, the use of ORB-based
application development is not very different from traditional application
development. For example, consider a University that wants to develop a student
management system, with major functional areas including student records, class
assignment, and financial aid areas. In a traditional application, the process
logic would reside in external application programs, and in an object-oriented
environment the process code would reside as methods in a class library.
With a distributed object approach, the process
logic would be defined as a part of the ORB. A separate ORB would exist for the
student records component, the class management component and the financial aid
component. (Figure 4.3)
Figure 4.3 - A sample ORB-based distributed
Here we see that the process code would be
written in the object definition language (ODL) if we were using CORBA or in the
interface definition language (IDL if we were using DCOM. Once defined, the
ORBs would be instantly accessible to all areas within the computer network that
are ORB aware. In the case of Figure 4.3, we see that the client simply
requests services from the ORB in the form of an RPC call, and the ORB receives
the call and applies the appropriate application logic to make the request to
the database, using the database's native access language. The ORB then
receives the data, format's it according to the ORB rules, and returns the data
to the requesting client. Note that all of the internals details of both the
application logic and the data are hidden from the client.