Chapter 5
Distributed Objects

5.1  Distributing Objects

5.1.1  Overview

• Application designers may take advantage of the expressiveness, abstraction, and flexibility of an object model (as described in 2.2.2 ).
  
  
• Encapsulation allows an object's implementation to be placed on any site; object placement may be done according to specific criteria such as access locality, administration constraints, security, etc.
  
  
• Legacy applications may be reused by encapsulating them in objects, using the WRAPPER pattern (2.3.3 ).
  
  
• Scalability is enhanced by distributing processing power over a network of servers, which may be extended to accommodate an increasing load.
  
  

Figure 5.1: Distributed objects

• The fragmented objects model, in which an object may be split in several parts, located on different nodes, and cooperating to provide the functionality of the object. An example of a fragmented object is a distributed binding object (3.3.2 ). An example of a system using this model is Globe [van Steen et al. 1999]. This model will not be considered further in this book.
  
  
• The replicated objects model, in which several copies, or replicas, of a given object may coexist. The motivation for replicated objects is to increase availability and to improve performance. However, the replicas of an object must be kept consistent, which entails additional cost. Replicated objects are examined in Chapter 11 .
  
  
• The migratory (or mobile) objects model, in which an object may move from one node to another one. Object mobility is used to improve performance through load balancing, and to dynamically adapt applications to changing environments.
  
  

• The calling and called objects are in the same process (e.g. objects A and B): this is a local invocation.
  
  
• The calling and called objects are executed by different processes on the same site (e.g. objects D and E): this is an out-of-process invocation.
  
  
• The calling and called objects are on different nodes (e.g. objects C and D): this is a remote invocation.
  
  

• Identifying and locating objects.
  
  
• Binding client to server objects.
  
  
• Performing method calls on objects.
  
  
• Managing objects' life cycle (creating, activating, deleting objects)
  
  

5.1.2  Remote Object Call: a First Outline

Figure 5.2: Performing non-local calls

Figure 5.3: Invoking a remote object

5.1.3  The User's View

• to describe the interfaces of the objects being used by an application, thus helping the design process, allowing consistency checks, and providing useful documentation;
  
  
• to serve as input for stub and skeleton generation, both static (before execution) and dynamic (during execution).
  
  

Figure 5.4: Object creation

5.2  Remote Object Call: a Closer View

• What information should be contained in an object reference?
  
  
• How is the remote object activated, i.e how is is associated with a process or thread that actually performs the call?
  
  
• How are parameters passed, specially if the parameters include objects?
  
  

5.2.1  Object References

Figure 5.5: Object references

• When an object is created, the object factory returns a reference to the object;
  
  
• The bind operation on the name of an object (Chapter 3 ), if successful, returns a reference to the bound object;
  
  
• As a special case of the above, looking up an object in a name server or trader returns a reference to the object (if found).
  
  

5.2.2  The Object Invocation Path

• Abstraction. The actual service described by the remote invocation interface may be provided by a variety of concrete mechanisms, which differ by such aspects as activation mode (whether a new process or thread needs to be created), dynamic instance creation (whether the target object already exists or needs to be created at run time), persistence (whether the target object survives through successive executions), etc. This results from the encapsulation principle, as presented in 2.2.2 : a service described by an abstract interface is implemented by an object whose specific (concrete) interface depends on the details of the service provision mechanism. In other words there is a distinction between a server (a site that provides a set of services to remote clients), and a servant (an object, managed by a server site, that actually implements a specific service).
  
  
• Portability and Interoperability. A distributed application may need to be ported to various environments, using ORBs provided by different vendors. An application may also involve communication between different ORBs. Both situations call for the definition of standards, not only for the interface between client and server, but for internal interfaces within the ORB.
  
  

Figure 5.6: The invocation path and its main interfaces

5.2.3  Object Adapters

• to register servant objects when they are created or otherwise installed on the server;
  
  
• to create object references for the servants, and to find a servant object using its reference;
  
  
• to activate a servant object when it is called, i.e. to associate a process with it in order to perform the call.
  
  

Figure 5.7: Invoking a remote object through an adapter

5.2.4  Parameter Passing

• Transmitting values of elementary types through a network. This is the "marshalling-unmarshalling" problem.
  
  
• Passing objects as parameters. This raises the issue of the passing mode (reference vs value).
  
  

Figure 5.8: Passing an object as a parameter

5.3  Inside an Object Request Broker

5.3.1  The Mechanics of Object Invocation

• A common format for the data being transmitted, called Common Data representation (CDR);
  
  
• A format for the messages used for invoking remote objects;
  
  
• Requirements on the underlying transport layer.
  
  

Figure 5.9: Object invocation: client side

Figure 5.10: Object invocation: server side

5.3.2  Binding in an ORB

• export: a servant object is created, directly or through a factory; it is registered by the server (possibly using an adapter), thus providing a reference. This reference is then registered for future use in a name service. Parts of the binding object (the skeleton instance, and possibly the delegates) are also created at this time.
  
  
• bind: the client retrieves a reference for the servant, either through the name service or by any other means such as direct transmission from the server. It uses this reference to generate an instance of the stub, and to set up the path from client to server by creating the end points (sessions) of the communication path (see Chapter ).
  
  

Figure 5.11: Binding for remote invocation

5.3.3  Introduction to the Case Studies

• a set of tools for stub and skeleton generation;
  
  
• a binder for the specific remote invocation model;
  
  
• a binder for the communication protocol used between client and server;
  
  
• various auxiliary tools for managing elementary resources.
  
  

Figure 5.12: The common structure of Jonathan ORBs

5.4  Case Study 1: Jeremie, an Implementation of Java RMI

5.4.1  Introducing Java RMI

• A remote interface (the interface of a remote object) is defined like an ordinary Java interface, except that it must extend the java.rmi.Remote interface, which is nothing but a marker that identifies remote interfaces.
  
  
• A call to a method of a remote object must throw the predefined exception java.rmi.RemoteException.
  
  
• Any class implementing a remote object must create a stub and skeleton for each newly created instance; the stub is used as a reference for the object. This is usually done by making the class extend the predefined class java.rmi.server.UnicastRemoteObject, provided by the RMI implementation. Details are provided in Section 5.4.3.
  
  

Figure 5.13: The RMI naming registry interface

5.4.2  Developing an RMI Application

// Hello Interface                   // Hello Implementation                              
     public interface Hello {            class HelloImpl implements Hello {    
       String sayHello();}                 HelloImpl() {   // constructor
     };                                      };
                                           public String sayHello() {
                                             return "Hello World!";
                                             }; 
                                         }
// Hello Usage
     ...                               
     Hello hello = new HelloImpl ();   
     hello.sayHello();

In the distributed version, the client and the server run on possibly different machines. In order to allow this new mode of operation, two main problems must be solved: the client must find the location of the hello object (the target object of the invocation); the client must access the target object remotely.

Here is an outline of the distributed version (some details are omitted, e.g. catching exceptions, etc.). First the interface.

   public interface Hello extends Remote {
      String sayHello() throws RemoteException;
   }

The server program contains the implementation of the Hello interface and the main program. Objects are located through a naming service (the registry), which is part of the RMI environment. The server creates the target object and registers it under a symbolic name (5.4.1). The rebind operation does this, superseding any previous associations of the name. Note that the URL prefix of the name is jrmi (for the Jeremie version of RMI)

   class HelloImpl extends UnicastRemoteObject implements Hello {
       HelloImpl() throws RemoteException {
       };
     public String sayHello() throws RemoteException {
         return "Hello World!";
     };

   public class Server {
     public static void main (...) {
       ...
       Naming.rebind("jrmi://" + registryHost + "/helloobj", new HelloImpl());
       System.out.println("Hello Server ready !");
     }
   }

The client program looks up the symbolic name, and retrieves a stub for the target object, which allows it to perform the remote invocation. The client and server must agree on the symbolic name (how this agreement is achieved is not examined here).

   ...
   Hello obj = (Hello) Naming.lookup("jrmi://" + registryHost + "/helloobj");
   System.out.println(obj.sayHello());

The registry may itself be a remote service (i.e. running on a machine different from that of the client and the server). Therefore, both the client and server use a local representative of the registry, called Naming, which locates and calls the actual registry, as described in 5.4.1. This allows the registry to be relocated without modifying the application.

The interaction diagram shown on Figure 5.14 gives a high-level view of the global interaction between the client, the server, and the registry. A more detailed view is presented in the following sections.

Figure 5.14: The "Hello World" application: overview

The actual execution involves the following steps.

1. Generate the stub and skeleton classes, by compiling the Hello interface definition on the server site, using the stub compiler provided by Jeremie.
   
   
2. Start the registry (by default the registry is located on the server site, but the system may be configured to make the registry reside on a different site).
   
   
3. Start the server.
   
   
4. Start the client.
   
   

5.4.3  The Inner Working of Jeremie

The execution of the above application proceeds as follows: on the server side, export the servant object and generate the actual stub and skeleton objects (the stub compiler has only generated the corresponding classes); on the client side, set up the binding, i.e. the actual connection between client and server, and perform the call. We examine the detail of these operations in turn.

Exporting the Servant Object

Recall that the servant object's class HelloImpl inherits from the standard class UnicastRemoteObject. The goal of this extension is essentially to enhance the creation of a remote object: when new is called on such a class, a skeleton and a stub are created in addition to the actual instance (using the classes generated by rmic), and the stub is returned as the result of new, to serve as a reference for the object. Thus the instruction

Naming.rebind("jrmi://" + registryHost + "/helloobj", new HelloImpl());

in the server program creates a new instance of HelloImpl (the servant), together with a skeleton and a stub for this servant, and returns the stub. It then registers the stub in the naming registry under a symbolic name.

Technically, the creation phase is performed by the UnicastRemoteObject (Figure 5.15), which exports the new servant object impl by calling a servant manager through an exportObject method. This manager (called AdapterContext on the figure) is essentially a driver for an object adapter; it first gets an instance of a stub factory from the ORB, and uses it to create a skeleton skel. It then registers skel into an adapter (essentially a table of objects), in which the skeleton is associated with a key. The key is then exported to the ORB, which delegates its operations to an IIOPBinder. This binder manages the IIOP protocol stack; it encapsulates the key into an object ref, of type SrvIdentifier, which includes a [host, port] pair (the port number was passed as a parameter to exportObject; if missing, an available port is selected by the binder). Thus ref is actually a reference for the servant impl. This reference is then used to create a stub (again using the stub factory), which is finally returned.

Figure 5.15: Remote Method Invocation: creating the stub and skeleton

The stub is then registered, which concludes the export phase. Note that the stub must be serializable in order to be transmitted over the network.

This framework is extensible, i.e. it identifies generic interfaces under which various implementations may be plugged in, such as the adapter interface and the binding protocol interface, which are shown on the figure.

Setting up the Binding

The client looks up the servant in the registry, using its symbolic name:

   Hello obj = (Hello) Naming.lookup("jrmi://" + registryHost + "/helloobj");

This operation apparently retrieves a "servant", but what it actually does is setting up the binding, by first retrieving a stub and then binding this stub to the skeleton, and therefore to the actual servant. We now present the details of this operation (Figure 5.16).

Figure 5.16: Remote Method Invocation: retrieving the stub on the client side

The stub object stored in the registry is returned as a result of the lookup operation. This stub is still unbound, i.e. the calling path to the remote servant is not set up. The binding operation relies on the mechanisms of object transmission in Java:

• when an externalizable object is read from an ObjectInputStream by the readObject method, this method is superseded by a specific ReadExternal method;
  
  
• after an object has been de-serialized, a readResolve method is called on this object.
  
  

The first mechanism is used when the stub delegate (here called RefImpl) is read. Recall that the delegate contains a reference to the remote servant, including its IP address, port number and key in the adapter. The call to ReadExternal creates a client endpoint (called CltId on the figure), managed by the IIOPBinder. The second mechanism invokes the bind() method on this endpoint, which in turn sets up the binding, i.e. the path to the remote object, using the IIOPBinder (to set up a TCP/IP session), and a stub factory (to put the final stub together).

Performing the Call

Finally, the call is performed by the operation

   System.out.println(obj.sayHello());

which actually invokes the sayHello() method on the stub. The skeleton is located using the reference contained in the delegate, the remote call is performed using the IIOP protocol, and the skeleton dispatches the invocation to the sayHello method of the servant. The return value is transmitted using the reverse path.

The Mechanics of Registry Invocation

Recall that the registry may be located on any node and is accessible through a local Naming interface. In order to reach the actual registry, Naming calls a LocateRegistry, giving the symbolic name under which the registry servant has been initialized (e.g. RegistryImpl).

Figure 5.17: Invoking a registry method

LocateRegistry uses a binder (here JIOP) to retrieve a stub for RegistryImpl (Figure 5.17). The binding process is identical to that described above (i.e. using IIOPBinder), and details are not shown.

When the registry server is initialized on a host, it creates a RegistryImpl servant on a specified port. A precompiled stub class for this servant (RegistryImpl_Stub, needs to be present on each site using the registry.

5.5  Case Study 2: David, an Implementation of CORBA

We present the David implementation of CORBA in the Jonathan framework. After a brief introduction (5.5.1), we illustrate the principle of application development in CORBA, through a simple example (5.5.2). We finally describe the inner working of the implementation (5.5.3).

5.5.1  Introducing CORBA

The Object Management Group (OMG) is a consortium created in 1989 with the goal of making and promoting standards in the area of distributed applications development. CORBA (Common Object Request Broker Architecture) is one of these standards, covering the area of middleware and services for applications based on distributed objects.

CORBA is intended to allow the cooperation of heterogeneous applications, using different languages and operating environments. To that end, the standard defines a common way of organizing applications based on the remote objects model, a common Interface Definition Language (IDL), and the main components of an object request broker architecture. In addition, a number of common services are specified for such functions as naming, trading, transactions, persistence, security, etc. These services are accessible through IDL interfaces.

The global organization of an ORB, as defined by CORBA, is represented on Figure 5.18.

Figure 5.18: The global organization of CORBA

The usual invocation path from a client application to a method provided by a remote servant is through a stub and a skeleton generated from an interface description. CORBA defines a generic IDL, from which stubs and skeletons may be created for different languages, using the appropriate tools. The mapping of the entities defined in the IDL to constructs in a particular language is defined by a set of binding rules. Such bindings have been defined for all usual programming languages. Thus for instance a client written in C++ may call a servant written in Java: the client stub is compiled using tools based on the IDL to C++ binding, while the skeleton is compiled using tools based on the IDL to Java binding.

The ORB itself provides interfaces to both clients and servants, in order to fulfill a number of basic functions such as a primitive name service and a tool to map object references to strings and vice-versa, in order to facilitate the interchange of references.

CORBA uses object adapters on the server side. The motivation for an adapter has been given in 5.2.3. The adapter manages servant objects, using an implementation repository. The use of adapters in CORBA is further developed in 5.6.

Finally, CORBA provides facilities for dynamically constructing the elements of an invocation path, by allowing a client application to discover a servant interface at run time (using an interface repository), and to create requests without using stub generation tools. These aspects are examined in 5.6.

5.5.2  Developing a CORBA Application

We use the same application (HelloWorld) as in Java RMI. The centralized version has been described in Section 5.4.2.

The IDL description of the interface of the remote object is:

interface Hello {
   string sayHello();
};

Since we intend to write the client and server programs in Java, this description must be compiled using an IDL to Java compiler, to generate the stub and skeleton files (_HelloStub.java and _HelloImplBase.java, respectively). The compiler also generates auxiliary programs (holders and helpers), whose function will be explained when necessary.

Here is the the program of the server.

import org.omg.CORBA.ORB;
import org.omg.CosNaming.NamingContext;
import org.omg.CosNaming.NamingContextHelper;
import org.omg.CosNaming.NameComponent;
import org.objectweb.david.libs.helpers.IORHelpers;
import idl.*;

class HelloImpl extends _HelloImplBase {

   HelloImpl() {}
   public String sayHello() {
      return "Hello World!";
   }
}

public class Server {
   public static void main (String[] args) {
      try {
         ORB orb = ORB.init(args,null);
         Hello hello = new HelloImpl();
         orb.connect(hello);
         IORHelpers.writeIORToFile(orb.object_to_string(hello),"hello_ior");
         org.omg.CORBA.Object ns_ref =
            orb.resolve_initial_references("NameService");
         NamingContext ns = NamingContextHelper.narrow(ns_ref);
         ns.rebind(new NameComponent[] { new NameComponent("helloobj","") },hello);
         System.out.println("Hello Server ready");
         orb.run();
      } catch (Exception e) {
         System.err.println("Hello Server exception");
         e.printStackTrace();
      }
   }
}

As may be expected, the program of the servant object is identical to that used in Java RMI. The difference lies in the server program.

The first instruction ORB orb = ORB.init(args,null) initializes the ORB, which is thereafter accessible as an object orb. Then an instance hello of the servant is created. The instruction orb.connect(hello) makes the servant known to the ORB for further use, by exporting it to an adapter.

The following instructions register the servant (actually a reference to it) in the CORBA name service. A reference to this service must first be retrieved, which is done using a primitive name service (resolve_initial_references) provided by the ORB. Note the use of the narrow operation performed by a "helper" program: the primitive name service returns references to type Object, and these references need to be cast to the actual type of the object. However, a language cast operation cannot be used here, because the references are not language references, but remote references managed by the ORB.

Finally, the orb.run() operations puts the server thread to sleep, waiting for client invocations.

Here is the client program.

import org.omg.CORBA.ORB;
import org.omg.CosNaming.NamingContext;
import org.omg.CosNaming.NamingContextHelper;
import org.omg.CosNaming.NameComponent;
import idl.*;

public class Client {
   public static void main(String[] args) {      
      try {
         ORB orb = ORB.init(args,null);
         org.omg.CORBA.Object ns_ref = 
            orb.resolve_initial_references("NameService");
         NamingContext ns = NamingContextHelper.narrow(ns_ref);
         org.omg.CORBA.Object obj_ref =
            ns.resolve(new NameComponent[] { new NameComponent("helloobj","") });
         Hello obj = HelloHelper.narrow(obj_ref);
         System.out.println(obj.sayHello());
      } catch (Exception e) {
         System.err.println("Hello Client exception");
         e.printStackTrace();
      }
   }
}

The ORB is initialized like in the server program. Then a reference for the servant is retrieved using the naming service. This reference must again be cast to its actual type, using the appropriate helper. Finally the remote operation is invoked.

CORBA uses a standard object reference format (Interoperable Object Reference, or IOR), defined by the IIOP specification. While these references are opaque (i.e. their contents is hidden), they may be used through primitives provided by the ORB. Thus, in the server program, the registration of the servant in the name service might be replaced by:

IORHelpers.writeIORToFile(orb.object_to_string(hello),"hello_ior_srv");

This instruction writes in the hello_ior_srv file a "stringified" form of the IOR. This string may be sent to the client (e.g. by mail), and copied in a file hello_ior_clt. The reference to the servant may then be retrieved in the client program by:

hello = orb.string_to_object(IORHelpers.readIORFromFile("hello_ior_clt"));

Executing the application involves exactly the same steps as in Java RMI: generating the stub and skeleton classes by compiling the IDL interface description; starting the name service; starting the server; starting the client.

CORBA allows additional facilities: dynamic request generation, adapter programming. These aspects are examined in Section 5.6.

5.5.3  The Inner Working of David

The compilation of the IDL interface description generates several files for each servant. For instance, from the Hello interface description, the Idl2Java compiler creates the Java source files for the following entities: HelloHelper, a class which carries auxiliary operations such as narrow (the reference casting operation); HelloHolder, a class which carries read and write operations of objects of type Hello on streams; HelloOperations, the interface of objects of type Hello; _HelloStub, the stub class; _HelloImplBase, the base class from which the servant object derives (this class extends a predefined Skeleton class).

The overall working of the CORBA ORB is similar to that described for Java RMI. The main differences are the use of the adapter on the server side, and the reflective operations described in 5.6.

The first step is to obtain a reference on the ORB as an object. This is done by the operation ORB orb = ORB.init(), which creates an ORB as an instance of a singleton class (a class with a single instance). This ORB provides a number of primitive operations, some of which are described in the rest of this section.

Exporting the Servant Object

The servant object's class HelloImpl inherits from the _HelloImplBase generated class, which itself inherits from Skeleton. This extends the servant's class constructor: when a new servant is created (an instance hello of HelloImpl), a new server delegate (5.3.1) is created and associated with that servant.

The operation orb.connect(hello) exports the new servant to the ORB. The server delegate is registered in the adapter (which returns a key to subsequently retrieve the servant), and then exported to the IIOP binder (which provides host address and port). At this stage, the IOR (containing host, port, and key) is ready, and it is actually registered in the servant itself (here, as an instance of SrvIdentifier). This is shown on Figure 5.19.

Figure 5.19: Exporting a servant in CORBA, phase 1

The next step consists in registering the servant in the name server. The name server must first be located, which is done as follows through a primitive naming service provided by the ORB:

org.omg.CORBA.Object ns_ref =
    orb.resolve_initial_references("NameService");
NamingContext ns = NamingContextHelper.narrow(ns_ref);

Retrieving a reference for the name server uses an internal association table (a context) managed by the ORB, in which a reference for the server has been initially registered. From this reference, a stub for the name server is generated, using the binding mechanism explained in the next subsection. The function of narrow (reference cast) has been explained in 5.5.2.

The servant is then registered in the name server:

ns.rebind(new NameComponent[] { new NameComponent("helloobj","") },hello);

The effect of this operation is the following (Figure 5.20).

Figure 5.20: Exporting a servant in CORBA, phase 2

The reference of the servant (i.e. the SrvIdentifier) is sent to the name server, using the encapsulation mechanism described in 3.4.5 . In this process, the identifier is unmarshalled from an ObjectInputStream, using the ReadObject operation. This operation invokes bind on the decoded identifier, in the IIOPBinder context, which in turn invokes a JStubFactory. This latter constructs a ClientDelegate (5.3.1), an access point to the servant using a generic (invoke) interface. This delegate is registered in the name server, to be later retrieved by the client, as described below.

Completing the Binding

After initializing the ORB and locating the name server (like above), the client binds to the servant by calling the name server:

ns.resolve(new NameComponent[] { new NameComponent("helloobj","") });
Hello obj = HelloHelper.narrow(obj_ref);

Like in the registration phase, the ClientDelegate is transmitted in an encapsulated form and unmarshalled through ReadObject. The IIOPBinder now constructs a stub using this delegate, using the mechanism illustrated in the lower-right quarter of Figure 5.20. The binding is now complete, including the communication path (session) between the client and the server.

Performing the Call

The call may now proceed using the object invocation scheme described in 5.3.1 and illustrated in Figures 5.9 and 5.10. The mechanics of passing objects as parameters or results by reference is again illustrated by the operation of the Naming.rebind primitive (Figure 5.20, i.e. recreating a delegate on the receiving site as the core of the object's stub.

5.6  Complements and Extensions

Currently not available (should cover reflective features, semi-synchronous invocations, etc.)

5.7  Historical Note

The historical evolution of object middleware has been outlined in the Historical Note section of the Introduction Chapter (1.5 ).

References

[OMG 2003]

OMG (2003). CORBA/IIOP Specification. Object Management Group. http://www.omg.org/technology/documents/formal/corba_iiop.htm.

[Spiegel 1998]

Spiegel, A. (1998). Objects by value: Evaluating the trade-off. In Proceedings Int. Conf. on Parallel and Distributed Computing and Networks (PDCN), pages 542- 548, Brisbane, Australia. IASTED, ACTA Press.

[van Steen et al. 1999]

van Steen, M., Homburg, P., and Tanenbaum, A. (1999). Globe: A Wide-Area Distributed System. IEEE Concurrency, pages 70-78.

[Völter et al. 2004]

Völter, M., Kircher, M., and Zdun, U. (2004). Remoting Patterns: Foundations of Enterprise, Internet, and Realtime Distributed Object Middleware. John Wiley & Sons.

[Waldo et al. 1997]

Waldo, J., Wyant, G., Wollrath, A., and Kendall, S. (1997). A Note on Distributed Computing. In Vitek, J. and Tschudin, C., editors, Mobile Object Systems: Towards the Programmable Internet, volume 1222 of Lecture Notes in Computer Science, pages 49-64. Springer-Verlag.

[Wollrath et al. 1996]

Wollrath, A., Riggs, R., and Waldo, J. (1996). A Distributed Object Model for the Java System. Computing Systems, 9(4):265-290.

Footnotes: