Distributed Object Computing
CORBA Defines Standard Interfaces and Services
Distributed object computing refers to a computing methodology in which applications are comprised of object-based components distributed across processes and networks. In a distributed object environment, objects communicate using message-based interfaces.
Distributed object computing is quickly becoming the preferred way to implement client/server systems. Client/server computer applications can be roughly defined as a set of systems that interoperate. In a client/server system, a process that makes a request of an object is termed a client, and the system on which the object executes is called a server. In this system, the server processes the request made by the client, and often returns a result to the client.
It is common to envision a client as a program that a human interacts with (for example, an entry system that queries a database) and a server as a program that processes requests made by the client program. However, the terms client and server are relative: the same process can both receive and make requests. For example, Figure 1 shows several client applications running workstations sending transaction requests to server processes on other systems. In turn, these servers can send database requests to a server process running on a third system; the transaction server becomes a client process to the third system.
Figure 1. Distributed Object Computing
An application model that separates the user-interface, transaction processing, and database functions is called a three-tiered architecture. Object technology is suited to many different types of application models, varying in both the types and the number of tiers.
Note: While a thorough discussion of distributed object computing and object-oriented design is beyond the scope of this documentation set, the Bibliography contains references to the third-party books, periodicals, and URLs that provide a solid background in object technology, object-oriented design, and CORBA.
NonStop DOM applications are client/server applications that run over Common Object Request Broker Architecture (CORBA) 2.0-compliant computer systems and networks. While clients and servers can be running on the same Tandem system, NonStop DOM servers can also handle remote client requests. Also, NonStop DOM clients can make requests that are fulfilled by remote NonStop DOM servers and servers on other ORBs.
NonStop DOM application servers are CORBA-compliant server processes that run on the Tandem NonStop Kernel. A NonStop DOM application server acts as a server process for clients both local and remote to the NonStop DOM system.
NonStop DOM clients are CORBA client processes that also run on the NonStop Kernel. As a CORBA client, the NonStop DOM client can reside on the same system as the NonStop DOM application server that processes its request, or it can act as a "network" or "remote client" by interoperating across a network to an application server located on another CORBA-compliant ORB.
Network clients (also called remote clients) are client processes that do not reside on the same Tandem system as the NonStop DOM application server that handles its request. Using the CORBA-compliant network protocol–the Internet InterORB Protocol (IIOP™)–network clients send requests for service to the NonStop DOM server via the ORB. Network clients can either run on other NonStop DOM systems, or they can be clients running on a different vendor's CORBA-compliant ORB.
With NonStop DOM, a network client need not be aware of where the application server is located; when a network client makes a request of an object, the NonStop DOM software transparently establishes a link with the NonStop DOM servers to handle the client's request.
The application of object-oriented technology to distributed processing offers several advantages to programmers and organizations:
These benefits of distributed object computing are discussed in the following paragraphs.
The possibility of reuse arises from the programmer's ability to design general-purpose object classes and package them as class libraries and frameworks for use by new applications. Reuse allows new software to be developed faster, at lower cost, and with higher quality than if a project required all new code and testing.
Related to reuse is the potential to construct new applications by combining off-the-shelf components from different vendors. This approach, called component-based development, allows an organization to concentrate its efforts on developing specialized functions rather than reinventing the functions common to many applications.
Inheritance is the feature of object technology that provides for evolution and specialization of services. By this principle, you can define a new class to have the characteristics of another class, with specific additions or the replacement of features (overriding) in the base or parent class.
Object inheritance lets you define an "isa" relationship between an object and its parent object. For example, suppose you have a "mammal" class. You can then create a "dog" class that inherits all the features of the mammal class. In this context, the dog class has an "isa" relationship with the mammal class; the dog isa mammal. This feature makes it possible to add discrete extensions rather than complex inline modifications to existing code. Some object-oriented programming systems and languages (including CORBA and C++) allow multiple inheritance, where a new class inherits characteristics from multiple classes.
In object-oriented systems, encapsulation and polymorphism insulate client objects from the details of the objects implemented on the server.
In object-oriented programming, encapsulation protects the data space of a server object from access by a client request. Encapsulation ensures that a client can invoke only functions that operate on an object's data; a client does not have direct access to the object's data space. With encapsulation, the implementation details and data of server objects can be made secure from the client objects that make server requests.
Polymorphism allows for a client to use the same calling sequence for functions that, although conceptually similar, must be performed differently for different types of objects. With polymorphism, a single interface is used to define different functionality. For example, imagine a function that draws different shapes based on the number of arguments given in the function call. With polymorphism, the same function can be used to draw a circle, triangle, rectangle, or polygon. The system selects the correct code to execute based on the target object type. With the draw function, the code is selected based upon the number of parameters passed to the function. In other cases, the function may be selected based on the type of parameters passed.
Through a feature called wrapping, a server developed with older technology can offer an object-oriented interface to new clients while remaining accessible to older clients through the conventional interfaces. Similarly, a set of object classes developed in one environment can be wrapped to appear as an object available to another environment.
As attractive as are the promises of distributed object computing, several practical problems have hindered the adoption of object technology for use in heterogeneous networks, online transaction processing (OLTP), and electronic commerce:
Although these are formidable challenges, the distributed object architecture defined by the Object Management Group® (OMG™) in CORBA 2.0 goes a long way toward addressing the problems unsolved in older object-oriented systems.
Since the definition of CORBA, numerous vendors have introduced Object Request Brokers (ORBs), programming tools, and runtime environments for CORBA-compliant applications. In addition to offering the standard set of ORB™ functions and services, certain products have advanced the technology of component-based development by addressing practical limitations of earlier object-oriented systems.
The common Object Request Broker Architecture (CORBA), illustrated in Figure 2, is defined by a vendor consortium called the Object Management Group (OMG). In CORBA, an architectural component called an Object Request Broker (ORB) transmits messages between clients and servers across a heterogeneous network using the Internet InterORB Protocol (IIOP), which is the protocol standardized by the OMG.
A client invokes objects in a server in either of two ways:
The server includes an object adapter. In NonStop DOM, the object adapter is an implementation of the CORBA 2.1 Portable Object Adapter (POA), which provides an interface between the ORB and the object implementations.
In addition to these components, CORBA specifies the following:
Figure 2. common Object Request Broker Architecture (CORBA)
Associated with CORBA are the common Object Services (COS), also called CORBAservices™. Examples of these services are:
Client applications and object servers that comply with the standards of the CORBAservices can seamlessly interoperate with each other; that is, clients can refer to local and remote objects without knowledge of their locations.
Note: A CORBA-compliant ORB can implement either CORBA 1.0 or CORBA 2.x. NonStop DOM implements a fully compliant CORBA 2.0 ORB. In addition, NonStop DOM also implements a Portable Object Adapter (POA) as specified by the OMG CORBA 2.1 specification.