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 Broker

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.

Application Objects - 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 object services.

Domain Interfaces - 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 - 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 environments.

Common Facilities - 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 ORB.

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 object implementation

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.

 

---