Author: Timothy Edwards
Introduction
The purpose of this paper is to describe Common Object Request Broker Architecture (C.O.R.B.A.), however initially the discussion will focus on some background information on objects of distributed systems. The first provides a brief overview of an object and why an object is developed into a distributed object (or component). Next, the paper discusses what components bring to the computing world and how they fit into distributed computing. Lastly, the paper focuses on an overview of C.O.R.B.A. and the Object Management Group (OMG) Architecture.
I. Background
In order to get a better understanding of where we are going with distributed system, it is a good idea to understand where we have been and what lead up to Component Architecture.
Let’s first start off with a brief review of an object. Object technology has been around for over 20 years, but has been increasing in popularity since the late 1980’s. An object is an entity that contains data (attributes) together with operations (methods) on that data. Key concepts associated with objects and object oriented programming are encapsulation, inheritance, and polymorphism.
In object oriented languages, data and its functions are encapsulated into a single entity. All the information is stored within the object and can only be manipulated when the object is ordered to perform its operations, preventing the data from being accidentally changed by hiding the internal information structure. The designer of the object determines what data the user can and cannot change.
Inheritance is the ability to derive an object from an existing object. All the operations and the information structure of the original object (parent) will become part of the new derived object (child). Additions can be made to the child and the parent remains unchanged, but if a change is made to the parent, the change "trickles" down to all the children. If the child has children, then a hierarchy is developed. When a child inherits qualities from more than one object, it is called multiple inheritance.
Polymorphism is the ability to give many operations the exact same name and have those operations perform differently. Two objects in the same program can have operations named the exact same and perform different task; or two operations in the same object can have the exact same name as long as the parameters passed to the operation are different.
Objects promise code reuse and higher levels of software productivity through encapsulation and inheritance. The programmer is able to inherit from an existing object and then modify it to fit their particular needs. Through encapsulation, the object almost takes on "Plug and Play" capabilities because the object is self contained and not dependent on any other code. Objects map easily to the real world because an object is just a person, place or thing and the operations you want it to perform. The problem is that objects are dependent on the language, the operating system, and the compiler.
To solve this, a distributed object, or component, was invented. A component can be used like a regular object, but from anywhere on the network. "Components are standalone objects that can plug and play across networks, applications, languages, tools, and operating systems by using language-neutral client/server interaction models." With the proper packaging and infrastructure, distributed objects will help subdivide today’s monolithic client/server applications into self-managing components that can play together and roam across networks and operating systems. Component-like objects allow us to create client/server systems by assembling "live blobs of intelligence and data" in an infinite number of lego-like arrangements. "These components represent the ultimate form of client/server distribution and prepare us for a near future when millions of machines - mostly desktops- will be both client and servers." A component is not a whole program in itself, rather it is a marketable entity that can be combined with other components to form an application. It has a well specified interface that can be modified and updated in the same way an object is; through inheritance and polymorphism.
Components will let power users assemble their own personal application using off-the-shelf components and let small developers enter the software market by just building a component to an existing application. The large software developers will build large suites using off the shelf components and be able to cut their production time substantially. Vendors will be able to sell "just what the client wants"; the client will pick and choose the functionality they want the application to perform and not have to purchase functionality they do not need. If at later time they want to add functionality, all they have to do is add in a new component. If the developer wants to upgrade the application, but only a certain function needs to be upgraded, they can just send out the new component and not the whole application.
With components we can perform distributed computing. Distributed computing allows different users or computers to share information. Distributed computing can allow an application on one machine to leverage processing power, memory, or storage on another machine. It is possible that distributed computing could enhance performance of a stand alone application, but this is often not the reason to distribute an application. Some applications, such as word processing, might not benefit from distribution at all. In many cases, a particular problem might demand distribution. If a company wishes to collect information across locations, distribution is a natural fit. In other cases, distribution can allow performance or availability to be enhanced. If an application must run on a PC and the application needs to perform lengthy calculations, distributing these calculations to faster machines might allow performance to be
enhanced.
With this little background out of the way, we will proceed to learn about C.O.R.B.A..
II. C.O.R.B.A.
Overview of CORBA
"The Common Object Request Broker Architecture (CORBA), is the Object Management Group's (ORB) answer to the need for interoperability among the rapidly increasing number of hardware and software products available today. Simply stated, CORBA allows applications to communicate with one another no matter where they are located or who has designed them."
C.O.R.B.A uses the Interface Definition Language (IDL)to define the services offered by a particular distributed object. IDL is a contractual language that lets you specify a component’s boundaries and it’s interfaces with potential clients. IDL is language neutral and totally declarative. Figure 1 is an example of an IDL module with two interfaces: Dog and Cat.
{
/* Class Definition of Dog */
interface Dog:Pet, Animal
{
attribute integer age;
exception NotInterested {string explanation };
void Bark (in short how_long)
raises (NotInterested);
void Sit (in string where)
raises (NotInterested);
void Growl (in string at_whom)
raise (NotInterested);
}
/* Class Definition of Cat */
interface Cat:Animal
{
void Eat ();
void HereKitty ();
void Bye ();
}
}/* End MyAnimals */
Figure 1
The module gives a name to the group of class descriptions. The interface defines a set of methods that can be invoked by a client. Think of interfaces as class definitions, but without the implementation section. The operations(Bark, Sit, Growl, Eat, HereKitty, and Bye) are the actual methods invoked by the client. You are able to define data types in IDL similar to any other language.
Figure 2 illustrates the primary components in the OMG Reference Model architecture. Descriptions of these components are available further below.
Figure 2. OMG Reference Model Architecture
Object Services -- These are domain-independent interfaces that are used by many distributed object programs. For example, a service providing for the discovery of other available services is almost always necessary regardless of the application domain. The Object Services are:
Naming Service -- which allows clients to find objects based on names;
Event Service -- which allows clients to find objects based on their properties.
Life Cycle Service -- defines operations for creating, copying, moving, and deleting components on the bus.
Persistence Service -- provides a single interface for storing components on a variety of servers.
Concurrence Control Service -- provides a lock manager.
Transaction Service -- provides two-phase commit coordination.
Relationship Service -- provides a way to create dynamic associations between components that know nothing of each other.
Externalization Service -- provides a standard way for getting data into and out of a component.
Query Service -- provides query operations for objects.
Licensing Service -- provides operations for metering components.
Properties Service -- provides operations to let you associate named values with any component.
Common Facilities -- are collections of Interface Definition Language (IDL)-defined components that provide services of direct use to application objects. They are broken down into two categories:
towards specific application domains. They will include support for financial services, computer-integrated manufacturing, and telecommunications.
Application Interfaces (Horizontal CORBAfacilities) -- These are interfaces developed specifically for a given application. Because they are application-specific, and because the OMG does not develop applications (only specifications), these interfaces are not standardized. However, if over time it appears that certain broadly useful services emerge out of a particular application domain, they might become candidates for future OMG standardization. There are four types of Application Interfaces:
CORBA ORB Architecture
Figure 3 illustrates the primary components in the CORBA ORB architecture. Descriptions of these components are available below the figure.
Figure 3. CORBA ORB Architecture
Object Request Broker Related
Client -- This is the program entity that invokes an operation on an object implementation. Accessing the services of a remote object should be transparent to the caller. Ideally, it should be as simple as calling a method on an object, i.e., obj->op(args). The remaining components in Figure 2 help to support this level of transparency.
Object Request Broker (ORB) -- The ORB provides a mechanism for transparently communicating client requests to target object implementations. The ORB simplifies distributed programming by decoupling the client from the details of the method invocations. This makes client requests appear to be local procedure calls. When a client invokes an operation, the ORB is responsible for finding the object implementation, transparently activating it if necessary, delivering the request to the object, and returning any response to the caller.
ORB Interface -- An ORB is a logical entity that may be implemented in various ways (such as one or more processes or a set of libraries). To decouple applications from implementation details, the CORBA specification defines an abstract interface for an ORB. This interface provides various helper functions, such as converting object references to strings and vice versa, and creating argument lists for requests made through the dynamic invocation interface described below.
Object Adapter -- This assists the ORB with delivering requests to the object and with activating the object. More importantly, an object adapter associates object implementations with the ORB. Object adapters can be specialized to
provide support for certain object implementation styles (such as OODB (Object Oreinted Data Base) object adapters for persistence and library object adapters for non-remote objects).
Client Related
CORBA IDL stubs -- CORBA IDL stubs serve as the ``glue'' between the client applications and the ORB. The transformation between CORBA IDL definitions and the target programming language is automated by a CORBA IDL compiler. The use of a compiler reduces the potential for inconsistencies between client stubs and server skeletons and increases opportunities for automated compiler optimizations.
Dynamic Invocation Interface (DII) -- This interface allows a client to directly access the underlying request mechanisms provided by an ORB. Applications use the DII to dynamically issue requests to objects without requiring IDL interface-specific stubs to be linked in. Unlike IDL stubs (which only allow RPC (Remote Procedure Calls)-style requests), the DII also allows clients to make non-blocking deferred synchronous (separate send and receive operations) and one-way (send-only) calls.
Server Related
CORBA IDL skeletons -- CORBA IDL skeletons serve as the ``glue'' between the server applications and the ORB. It is similar to the CORBA IDL stub on the client side.
Object Implementation -- This defines operations that implement a CORBA IDL interface. Object implementations can be written in a variety of languages including C, C++, Java, Smalltalk, and Ada.
Dynamic Skeleton Interface (DSI) -- This is the server side's analogue to the client side's DII. The DSI allows an ORB to deliver requests to an object implementation that does not have compile-time knowledge of the type of the
object it is implementing. The client making the request has no idea whether the implementation is using the type-specific IDL skeletons or is using the dynamic skeletons.
III. Conclusion
Distributed objects (components) will let the programmer break the boundries of a specific programming language and a specific operating system by using the nuetral language IDL. IDL specifies a component’s boundaries and it’s interfaces and is the heart of CORBA. CORBA is the standard created by OMG that will let programers develop components that when combined with other components will make up a distributed application reguardless of where the component resides ar what language it was qwritten in. With components a large developer can save time by building whole applications by pulling components off the shelves. Smaller developers do not have to create large robust applications, instead they can develop components that will tie into the larger applications easier.
IV. References
Robert Orfali et al., The Essential Distributed Objects Survival Guide (John Wiley & Sons, 1996)
Richard Johnsonbaugh andMartin Kalin; Object-Oriented Programming C++(Prentice Hall, 1995)
"OpenDoc - The Grand Tour" Cross-Platform Strategies Fall 1995: 16
"OpenDoc - A Closer Look" Cross-Platform Strategies Winter 1995: 6
Andrew Watson, "The OMG after CORBA 2" Object Magazine March 1996
Thom Brando, "Comparing CORBA and DCE" Object Magazine March 1996
JavaCORBA Mail List. The e-mail address for this list is JavaCORBA@luke.org.
The OMG Home Page http://www.omg.org/