Server-Side Mapping

7

7.1 Introduction

This chapter discusses how implementations create and register objects with the ORB runtime.

It will be patterned after the server framework architecture to be described by the final submission to the Server Side Portability RFP.

Issue - This chapter is subject to revision pending the outcome of the Portability RFP submission

7.2 Transient Objects

For this initial submission only a minimal API to allow application developers to implement transient ORB objects is described. We do not expect there to be major changes as a result of the Portability work.

7.2.1 Servant Base Class

For each IDL interface <interface_name> the mapping defines a Java class as follows:

// Java

public class _<interface_name>ImplBase implements <interface_name> {

}

7.2.2 Servant Class

For each interface, the developer must write a servant class. Instances of the servant class implement ORB objects. Each instance implements a single ORB object, and each ORB object is implemented by a single servant.

Each object implementation implements ORB objects that supports a most derived IDL interface. If this interface is <interface_name>, then the servant class must extend _<interface_name>ImplBase.

The servant class must define public methods corresponding to the operations and attributes of the IDL interface supported by the object implementation, as defined by the mapping specification for IDL interfaces. Providing these methods is sufficient to satisfy all abstract methods defined by _<interface_name>ImplBase.

7.2.3 Creating A Transient ORB Object

To create an instance of an object implementation, the developer instantiates the servant class.

7.2.4 Connecting a Transient ORB Object

Object implementations (object references) may be explicitly connected to the ORB by calling the ORB's connect() method (see Section 6.12, "ORB").

An object implementation may also be automatically and implicitly connected to the ORB if it is passed as a (mapped IDL) parameter to a (mapped) IDL operation that is itself not implemented as a local (Java) object. I.e., it has to be marshaled and sent outside of the process address space. Note, a vendor is free to connect such an object implementation "earlier" (e.g. upon instantiation), but it must connect the implementation to the ORB when it is passed as described above.

Note that calling connect() when an object is already connected has no effect.

7.2.5 Disconnecting a Transient ORB Object

The servant may disconnect itself from the ORB by invoking the ORB's disconnect() method (see Section 6.12, "ORB"). After this method returns, incoming requests will be rejected by the ORB by raising the CORBA::OBJECT_NOT_EXIST exception. The effect of this method is to cause the ORB object to appear to be destroyed from the point of view of remote clients.

Note that calling disconnect() when the object is not connected has no effect.

Note however, that requests issued using the servant directly (e.g. using the implementatioon's this pointer) do not pass through the ORB; these requests will continue to be processed by the servant.

7.3 Persistent Objects

Issue - dependent upon the Portability specification