141.

  

Transaction Manager and Other Activatable Services

The Jini distribution includes a transaction manager called mahalo . This uses the new activation methods of RMI in JDK 1.2. Without worrying about any other arguments, the call to run this transaction manager is

 java -jar mahalo.jar 

( assuming the jar file is in the CLASSPATH ). The transaction manager is a Jini service and will need class definitions to be uploaded to clients . The class files are in mahalo-dl.jar , and will come from an HTTP server. The location of this jar file is specified in the first command-line argument. For example, to access it from the HTTP server on my laptop, jannote , I would issue the following command:

 java -jar mahalo.jar http://jannote.dstc.edu.au/mahalo-dl.jar 

The transaction manager is a Jini service, and so should set a security policy. This security policy should allow the transaction manager to register with a lookup service, and allow client access to it. In addition, the transaction manager needs to maintain state about transactions in permanent storage. To do this, it needs access to the file system, and since it has a security manager installed, this access needs to be granted explicitly. This is done using the normal java.security.policy property:

 java -Djava.security.policy=policy.txn \      -jar mahalo.jar http://jannote.dstc.edu/au/mahalo-dl.jar 

This will allow the service to be registered and uploaded, and also will allow access to the file system.

A suitable policy to set up the permissions discussed earlier and grant file system access could be as follows :

 grant {     // rmid wants this     permission java.net.SocketPermission "127.0.0.1:1098", "connect,resolve";     // other RMI calls want these, too     permission java.net.SocketPermission "127.0.0.1:1024-", "connect,resolve";     permission java.net.SocketPermission "130.102.176.153:1024-",                                          "connect,resolve";     // access to transaction manager log files     permission java.io.FilePermission "/tmp/mahalo_log", "read,write";      permission java.io.FilePermission "/tmp/mahalo_log/-", "read,write,delete";     // properties used by transaction manager     permission java.util.PropertyPermission "com.sun.jini.mahalo.managerName",                                             "read";     permission java.util.PropertyPermission "com.sun.jini.use.registry", "read"; }; 

The new activation system of JDK 1.2 takes a little getting used to and causes confusion to Jini newcomers, because Sun implementations of major Jini services (such as mahalo ) use activation. An activatable service like mahalo hands over responsibility for execution to a third party, an activation service. This activation service is usually rmid , and is used by reggie as well as mahalo .

A service (e.g., mahalo ) starts, registers itself with this third-party service (e.g., rmid ), and then exits. The third-party service ( rmid ) is responsible for fielding calls to the service ( mahalo ), and either awakening it or restoring it from scratch to handle the call. There is a subtlety here: the service ( mahalo ) begins execution in one JVM, but promptly delegates its execution to this third-party service ( rmid ) running in a different JVM! Thus, there are two JVMs involved in running an activatable service, and so there are two security policies ”one for each of the JVMs.

The first security policy is used when the service is first started (say by a user ). This uses the command line argument -Djava.security.policy= and is used to register the service ( mahalo ) with the activation service ( rmid ). This startup service then exits. Some time later, the activation service will try to restart the registered service ( mahalo ) and will need to know the security policy to apply to it. This second security policy must be passed from the original startup through to the activation service, and this is specified in an additional command-line argument, policy.actvn .

 java -Djava.security.policy=policy.txn -jar mahalo.jar \       http://jannote.dstc.edu.au/mahalo-dl.jar \       policy.actvn 

The policy file just discussed is suitable for starting the mahalo service. A suitable activation policy for actually running the mahalo service from the activation server could be as follows:

 grant {     // rmid wants this     permission java.net.SocketPermission "127.0.0.1:1098", "connect,resolve";     // other RMI calls want these, too     permission java.net.SocketPermission "127.0.0.1:1024-", "connect,resolve";     permission java.net.SocketPermission "130.102.176.153:1024-",                                          "connect,resolve";     // access the transaction manager log files     permission java.io.FilePermission "/tmp/mahalo_log", "read,write";     permission java.io.FilePermission "/tmp/mahalo_log/-", "read,write,delete";     // properties used by transaction manager     permission java.util.PropertyPermission "com.sun.jini.mahalo.managerName",                                             "read";     permission java.util.PropertyPermission "com.sun.jini.use.registry", "read";     // needed for activation     permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve";     permission java.io.FilePermission "/tmp/mahalo_log/-", "read";     permission java.util.PropertyPermission "com.sun.jini.thread.debug", "read";     permission java.lang.RuntimePermission "modifyThreadGroup";     permission java.lang.RuntimePermission "modifyThread";     // for downloading mahalo-dl.jar from HTTP server     permission java.net.SocketPermission "*:8080", "connect,accept,resolve";     permission net.jini.discovery.DiscoveryPermission "*"; };