Contents

11.1 The Implementation Repository

11.2 Activation Modes

11.2.1 Primary Activation Modes

11.2.2 Secondary Activation Modes

11.2.3 Further Registration Options

11.2.4 Implementation Repository Entries

11.3 The OrbixWeb putit Utility for Server Registration

11.3.1 Examples of using putit

11.3.2 Using the Orbix putit Utility for OrbixWeb Server Registration

11.4 Additional Registration Commands

11.5 Further Mode Options: Activation and Pattern Matching

11.6 Persistent Servers and impl_is_ready()

11.7 Unregistered Servers

11.8 Activation Issues Specific to IIOP Servers

11.8.1 Comparison of IIOP Servers with Orbix Protocol Servers

11.9 Security Issues for OrbixWeb Servers

11.9.1 Identity of the Caller of an Operation

11.9.2 Security of Servers

11.9.3 UNIX: Effective uid/gid of Launched Servers

11.10 Activation and Concurrency

11.11 Activation Information for Servers

11.12 IDL Interface to the Implementation Repository

In this chapter we will outline the full functionality supported by the OrbixWeb Implementation Repository. We will describe aspects of registration and activation which affect servers which communicate over either the CORBA Internet Inter-ORB Protocol (IIOP) or the Orbix protocol. We will also discuss aspects of server activation which are specific to IIOP servers; these servers only need to be registered in the Implementation Repository under specific circumstances, and this can be advantageous in a Java environment.

11.1 The Implementation Repository

If the server is not running, it will be automatically launched by OrbixWeb when a client binds to one of the server's objects, or when a client invokes an operation on an object reference which names that server. The OrbixWeb daemon launches a Java server by invoking the Java interpreter on the bytecode specified in an Implementation Repository entry.

To allow the daemon to correctly locate and invoke the Java interpreter, it is important that the values IT_JAVA_INTERPRETER and IT_DEFAULT_CLASSPATH are assigned correctly in the OrbixWeb configuration file, Orbix.cfg. The configuration of these values is described in Chapter 3, "OrbixWeb Configuration" of the OrbixWeb Reference Guide.

Whenever a client first communicates with an object, OrbixWeb uses the Implementation Repository to identify an appropriate server to handle the connection. This search can occur in the following circumstances:

• During a call to _bind() if pinging is enabled¹; otherwise, on the first invocation on an object reference returned by _bind().
  
• During a call to the method ORB.string_to_object() (invoked on the _CORBA.Orbix object).
  
• When an object is used for the first time after being received as a parameter or return value via an intermediate server.
  

11.2 Activation Modes

11.2.1 Primary Activation Modes

Shared Activation Mode

In this mode, all of the objects with the same server name on a given machine are managed by the same process on that machine. This is the most commonly used activation mode.

If the process is already launched when an operation invocation arrives for one of its objects, then OrbixWeb will route the invocation to that process; otherwise OrbixWeb will launch the process (using the Implementation Repository's mapping from server name to class name and class path).

In this mode, individual objects of a server are registered with the Implementation Repository. All invocations for an individual object are handled by a single process. This server process is activated by the first invocation of that object. Thus, one process is created per active registered object. Each object managed by a server can be registered with a different Java class, or any number of them can share the same class.

In this mode, individual operation names are registered with the Implementation Repository. Inter-process calls can be made to these operations–and each invocation will result in the creation of an individual process. A process is created to handle each individual operation call, and the process is destroyed once the operation has completed. A different Java class can be specified for each operation, or any number of them can share the same class.

Per-client

In this mode, activations of the same server by different end-users ("principals") will cause a different process to be created for each such end-user.

In this mode, activations of the same server by different client processes will cause a different process to be created for each such client process.

In this mode, activations of the same server by different end-users will share the same process, in accordance with whichever fundamental activation mode is selected. This is the default.

Launching servers in this way is useful for a number of reasons. Some servers take considerable time to initialise themselves, and therefore it is sensible to launch such servers before any client wishes to use them. Also, during development, it may be clearer to launch a server in its own window, allowing its diagnostic messages to be more easily seen.

Manually launched servers, once they have called impl_is_ready(), behave in a similar way to shared activation mode servers. If a server is registered as unshared or per-method, then, in line with the CORBA specification, impl_is_ready() will fail if the server is launched manually (see section 11.6).

A shared server may be registered such that it may only be launched manually–that is, OrbixWeb will not launch the server when an operation invocation arrives for one of its objects. This is explained in section 11.7.

Usually, clients are not concerned with the activation details of a server or aware of what server processes are launched. To a client, a server is viewed as a single unit; an object in a server can be bound to and communicated with without considering activation mode details.

Although servers are registered in the Implementation Repository, individual objects do not need to be registered. Only those objects for which OrbixWeb should launch a process (if an appropriate process is not already running) should be registered.

11.2.4 Implementation Repository Entries

• The server name. Server names may be hierarchical so the Implementation Repository supports (possibly nested) directories.
  
• The primary activation mode (shared, unshared, or per-method).
  
• The secondary activation mode–that is, whether activation is per-client, per-client-process or multiple-client.
  
• Whether the server is a persistent-only server–that is, whether it can only be launched manually.
  
• The server owner–the user who registered the server.
  
• Permissions specifying which users have the right to launch the server and which users have the right to invoke operations on objects in the server.
  
• A set of activation orders specifying a marker or method and a launch command for that marker or method. For the shared or unshared activation modes, a number of activation orders may exist for different markers. For the per-method activation mode, a number of activation orders may exist for different methods.
  

11.3 The OrbixWeb putit Utility for Server Registration

Here, we will give some examples of common uses of putit. A full description of putit and its switches is given in Chapter 1, "The OrbixWeb Utilities" of the OrbixWeb Reference Guide.

The putit command is mostly used in one of the following forms:

 putit serverName -java 
 	-classpath classPath className
 
 putit serverName -java
 	-addpath partialClassPath className

The first of the above command forms indicates that the server is to be registered with the specified complete class path, independent of any configuration settings, and with the specified class name. The second indicates that the specified class path should be appended to the value of IT_DEFAULT_CLASSPATH in the Orbix.cfg file, when the daemon attempts to launch the server.

By default, putit uses the shared activation mode: therefore, on any given host, all objects with the specified server name will be controlled by the same process. Also by default, putit registers a server in the multiple-client activation mode: that is, all client processes will bind to the same server process.

For example:

 putit BankSrv -java -addpath 
 	/usr:/users/chris/banker idl_demo.BankServer

Server names may be hierarchically structured, in the same way as UNIX file names. For example:

 putit banks/BankSrv -java -addpath
 		/usr:/users/chris/banker idl_demo.BankServer 

11.3.1 Examples of using putit

• The -unshared switch registers a server in the unshared activation mode:
  

putit -unshared NationalTrust -java -classpath

/classes:/jdk/classes:/tmp/bank bankPackage.BankServer

This command registers an unshared server called "NationalTrust" on the local host, with the class name and full class path. Each activation for an object will go to a unique server process for that particular object. All end users accessing a particular object share the same server process.

• A marker may be specified to the putit command to identify an object to which the putit applies:
  

putit -h alpha -marker Boston NationalBank -java -addpath

/bank/classes:/local/classes bankPackage.BankServer

This command registers a shared server called "NationalBank", with the specified class name and partial class path. However activation will only occur for the object whose marker matches "Boston". There will be at most one server process resulting from this registration request; although other -marker registrations can be issued for server NationalBank for other objects in the server. All end users accessing the "Boston" object share the same server process.

The -h switch specifies the host name on which to execute the putit command.

A simple program which supports this is supplied with OrbixWeb; this program is called jrunit and is installed by default in the OrbixWeb bin directory. By using jrunit, an Orbix programmer can register an OrbixWeb server in the Orbix Implementation Repository.

To register an OrbixWeb server in the Orbix Implementation Repository, the Orbix putit command (which currently does not support the -java switch) should be used as follows:

 putit serverName "jrunit -classpath 
 	classPath className commandLineArgs"

The following Orbix putit command:

 putit BankSrv "jrunit -classpath 
 	/usr:/users/chris/banker idl_demo.BankServer"

 putit BankSrv -java -classpath 
 	/usr:/users/chris/banker idl_demo.BankServer

11.4 Additional Registration Commands

11.5 Further Mode Options: Activation and Pattern Matching

Since objects can be named, the various activation policies can be instructed to use pattern matching when seeking to identify which server process to communicate with. In particular, when a server is registered, it is possible to specify that it should be launched if any of a set of its objects are invoked. This set of objects is specified by registering a marker pattern which uses wildcard characters. If no pattern is specified, invoking on any of a server's objects will cause the server to be launched (if it is not already launched).

Patterns may also be specified for methods so that operation names matching a particular pattern will cause a particular server to be launched.

11.6 Persistent Servers and impl_is_ready()

Other interactions with OrbixWeb such as calling an operation on a remote object, or using the locator, also cause difficulties if they occur in a persistent server before impl_is_ready() is called.

Persistent servers, once they have called impl_is_ready() behave as shared activation mode servers. In line with the CORBA specification, if a server is registered as unshared or per-method, then impl_is_ready() will fail if the server is launched manually.

11.7 Unregistered Servers

A disadvantage of this approach is that an unregistered server will not be known to the daemon so the daemon will not be able to automatically invoke the Java interpreter on the server bytecode when a client binds to or invokes an operation on one of its objects. The server must be launched in advance of a client invocation, if that invocation is to succeed.

In a Java context, a more significant disadvantage of this approach is that the OrbixWeb daemon is involved in initial communications between the client and server, even though the server is not registered in the Implementation Repository. This restriction applies to all OrbixWeb servers which communicate over the standard Orbix communications protocol and limits such servers to running on hosts where an Orbix or OrbixWeb daemon process is available.

11.8 Activation Issues Specific to IIOP Servers

Unregistered IIOP servers are important in a Java domain, as they can be completely independent of any supporting processes which may be platform specific. In particular, any server which relies on the OrbixWeb daemon to establish initial connections will depend on the availability of the daemon on specific platforms. An OrbixWeb unregistered IIOP server is completely self-contained and platform independent.

However, an IIOP server suffers from an important disadvantage. The TCP/IP port number on which a server communicates is embedded in each IOR that a server creates. If the port is dynamically allocated to a server process on start-up, then the port may differ between different processes for a single server. This may invalidate IORs created by a server if, for example, the server is killed and relaunched. OrbixWeb addresses this problem by allowing IIOP server programmers to assign a well-known IIOP port number to the server.

These issues are discussed in detail in Chapter 9, "ORB Interoperability".

11.8.1 Comparison of IIOP Servers with Orbix Protocol Servers

All Orbix protocol servers require an Orbix or OrbixWeb daemon process to establish client-server communications. As the OrbixWeb daemon is not currently implemented in Java, these servers cannot be deployed in a completely platform-independent manner.

Servers which communicate using IIOP and which are not registered in the Implementation Repository require no contact with a daemon in order to communicate with clients (although a which uses the _bind() method to contact an IOR will need to contact the daemon). These servers do not rely on any non-Java applications and can be deployed on any platform supported by Java. They can also maintain consistent IORs between server processes, if configured correctly. However, these servers must be launched manually.

Servers which communicate using IIOP and which are registered in the Implementation Repository are dependent on the availability of an Orbix or OrbixWeb daemon at the server host. These servers cannot be deployed independently of the platforms supported by the daemon. However, they combine an ability to interoperate with applications implemented using other ORBs, with an ability to be launched automatically and an ability to maintain consistent IORs between server processes.

11.9 Security Issues for OrbixWeb Servers

11.9.1 Identity of the Caller of an Operation

 // Java
 // In package IE.Iona.Orbix2.CORBA,
 // in class BOA.
 
 public String get_principal 
 		(IE.Iona.Orbix2.CORBA._ObjectRef oref)
 		throws SystemException;

11.9.2 Security of Servers

The entries in the access control list can be either user names or group names. There is also a pseudo group name called all, which can be used to implicitly add all users to an access control list. The owner of an Implementation Repository entry is always allowed to launch it and invoke operations on its objects.

The chmodit command can be used to modify the two access control lists.

The group system is determined by the underlying operating system. For example, on UNIX, group membership of a user is determined using the user's primary group as well as the user's supplementary groups (as specified in the /etc/group file).

Only the owner of an Implementation Repository entry can call the chmodit command on it. The original owner is the user who calls the putit command; subsequently, the ownership can be changed using the chownit command.

11.9.3 UNIX: Effective uid/gid of Launched Servers

1. If orbixd is not running as the root (super-) user, then the uid and gid of every activated server process will be that of orbixd itself.


2. If orbixd is run as root, then it will attempt to activate a server with the uid and gid of the, possibly remote, principal attempting to activate the server.


If the principal is unknown (that is, is not a registered user) at the local machine on which orbixd is running, then, orbixd will attempt to run the new server with uid and gid of a standard user "orbixusr".


3. If there is no such standard user "orbixusr", then orbixd will attempt to run the new server with uid and gid of a user "nobody".


If there is no such user "nobody", then the activation will fail and an exception will be returned to the caller.

11.10 Activation and Concurrency

11.11 Activation Information for Servers

In a server, this information can be found by invoking the following methods–defined in class BOA–on the _CORBA.Orbix object:

• To find the marker name of the activation object that caused this server to be launched (this is null for a persistent server):
  

   public String myMarkerName ()
   	throws SystemException;
  

• To find the method name used to launch this server (this is null for a persistent server):
  

   public String myMethodName ()
   	throws SystemException;
  

• To find the marker pattern that caused this server to be launched:
  

   public String myMarkerPattern ()
   	throws SystemException;
  

• To find the server's name (for a persistent server this will be some unspecified string until impl_is_ready() is called):
  

   public String myImplementationName ()
   	throws SystemException;
  

• To find the activation mode under which the server is registered:
  

   // Server activation modes
   // (defined in IE.Iona.Orbix2.CORBA.BOA).
   static final short perMethodActivationMode  = 0;
   static final short unsharedActivationMode   = 1;
   static final short persistentActivationMode = 2;
   static final short sharedActivationMode     = 3;
   static final short unknownActivationMode    = 4;
   
   public short myActivationMode ()
   	throws SystemException;
  

11.12 IDL Interface to the Implementation Repository

Note that the UNIX utilities (putit, catit, and so on) and the Orbix Server Manager (available under Windows 95 and Windows NT) are implemented in terms of the daemon's IDL interface.