Orbix Programming Guide

1.2 Introduction to Distributed Programming

A distributed computing system is a set of co-operating software components running in a number of computers connected by a network. These components may be standard components, often shared by a number of applications; and an application may include a number of application specific components. A simple case is where an application consists of one process, which interacts with a number of shared components. End users interact with applications, which may interact with and use any of the software components available throughout the network. Each such component, in turn, may itself use some of the other software components to carry out its tasks.

A distributed program is the combination of application specific software and the (possibly remote) components it uses. The application specific software can be made up of application-specific components that run on one or more machines.

In Orbix, the components of a distributed program are objects–which have well defined interfaces and which may be communicated with from any node in the distributed system. Each object is associated with a server–a server manages a set of objects with the same or with different interfaces. Each Orbix object internally has a unique system wide identifier, which can be used to locate it within the distributed system. Each server can have any number of clients that communicate with its objects.¹

In a conventional, non-distributed, program the usual mechanism to connect different components of the program together is the function, or procedure, call. This mechanism is well understood; thus, it is reasonable to expect that a facility for programming distributed applications should also allow function and procedure calls to be used to connect components together. In distributed program, the various components may be remote from where they are used: hence, it should be possible to request remote procedure and function calls, in which the caller is (possibly) in a separate machine or process from the called component.

Since Orbix is an object-oriented system, objects rather than isolated procedures are the components of distribution. A C++ program running on Orbix can invoke functions on an object running on any node in a distributed system. This is achieved with a high degree of transparency because a C++ programmer can make a normal C++ function call to invoke a remote object. This means that familiar programming paradigm and syntax can be used to write distributed programs.

As is normal in object-oriented systems, an application is constructed by specifying types (these are known as interface definitions in Orbix), implementing these types, and then creating objects of these types.

1.2.1 Defining Interfaces

In a distributed program, it is possible to implement different objects in different programming languages. In order to assist and enable interaction between such objects, it is common to abstract the functionality provided by each object by clearly defining its interface. The Interface Definition Language (IDL) is a standard language, defined by OMG, for defining such interfaces. IDL is a simple language, since it is used just for defining interfaces, rather than for writing programs.

Having defined the interface to some object in IDL, the programmer is then, in principle, free to implement the object using any suitable programming language. Correspondingly, the programmer who wishes to use that object can, in principle, employ any programming language to make remote requests to the object. In particular, the programming language used to implement an object may differ from that used to implement a client using that object.

Orbix allows the C++ programming language to be used in conjunction with IDL both to implement objects and to make requests of them. Orbix also supports Ada and Java as well as OLE-enabled programming and scripting languages, such as Visual Basic (see section 1.5.1).

1.2.2 Clients and Servers

A distributed software system consists of objects running within clients and servers. Servers provide objects for use by clients and by other servers. When one object calls an operation on another, the former is frequently referred to as the client object, and the latter as the server or target object. The calling object can, in fact, be within a server; in other words, a server can make operation calls and thereby act as a client for the duration of the call. (Sometimes the term servient is used to refer to a server that makes operation calls on objects remote to it–that is, a server that acts as a client. However, since it is, in fact, normal for servers to make requests to remote objects, the term servient is not used here.)

A server will be activated (launched) if it is dormant when one of its objects is used. To facilitate this, all servers must be registered with Orbix.

A client can contain objects, and any of these objects can be made known to other clients and servers and subsequently used by them.² Typically, this will happen because, in a previous operation call, the client passed a reference to one of its objects to a server. The difference is that a client must already be running: there is no automatic launching of clients. Clients cannot be registered with Orbix.

Objects are implemented as language level objects (for example, when using C++, objects are just C++ objects) and they are contained within clients or servers.

Although it is, strictly speaking, inaccurate, an object is considered remote to the caller if it is in another address space on the same machine. The term is defined in this way because many of the same rules apply to inter-address-space and inter-machine operation calls (although inter-address-space calls are optimized).

The term service is sometimes used to refer to a facility provided to the rest of the system by the objects in one or more servers. For example, each of a set of servers may provide an object that can handle the same calls from different clients, and clients would typically use the server closest (in some sense) to them. Another example is that the set of objects, of the same or different interfaces, in a single server provide some overall service to their clients.

¹ As we will see, it is also possible for Orbix clients to contain Orbix objects. This provides a number of advantages–it allows the client to pass references to one or more of these objects to some other component of the system. It also means that the client can, at some future time, be split into a number of co-operating processes.

² Such clients must however be linked with the Orbix server library, rather than the client library.