ActivationDesc, ActivationGroupDesc, and ActivationGroup in More Detail

This means that on any server running an activation daemon, there is already a fairly empty RMI registry running on a well-known port, which you can use instead of a standalone registry.

17.6.3 ActivationDesc, ActivationGroupDesc, and ActivationGroup in More Detail

So far, weve covered the basics of how to describe a server to the Activation Framework. The objects involved are: ActivationGroupDesc Instances of ActivationGroupDesc describe a JVM, which is configured as a server JVM. Usually, this means that a security policy is set, and the RMI runtime is configured through the use of the RMI-specific flags discussed in Chapt er 16 and throughout the book. ActivationGroup This is a container class. Instances of ActivationGroup describe a related set of activatable servers. Every instance of ActivationGroup is associated with a single instance of ActivationGroupDesc , although instances of ActivationGroupDesc can be associated with more than one ActivationGroup . ActivationDesc Instances of ActivationDesc describe a single activatable server. An instance of ActivationDesc is associated with a single ActivationGroup , although instances of ActivationGroup can be associated with many instances of ActivationDesc . Youll note that our code didnt actually associate the instances of ActivationDesc we created with the instance of ActivationGroup . If an instance of ActivationDesc isnt explicitly associated with an instance of ActivationGroup , it is automatically associated with the last created ActivationGroup . To make this all a little more concrete, consider the following code example, which uses the private methods defined earlier: createActivationGroup ; createBankAccountErik, getRandomMoney ; createBankAccountEugene, getRandomMoney ; createBankAccountEarle, getRandomMoney ; createActivationGroup ; createBankAccountJim, getRandomMoney ; createBankAccountJack, getRandomMoney ; createBankAccountJulie, getRandomMoney ; This creates two instances of ActivationGroup . Each of these instances is associated with a unique instance of ActivationGroupDesc . This code creates six instances of ActivationDesc , three associated with the first instance of ActivationGroup and three with the second instance of ActivationGroup . When the system is first run, and this launch code is executed, none of the servers are running, and neither of the two JVMs has been started. Now suppose that the following client actions occur: 1. A client gets Julies account balance. 2. A client withdraws money from Earls account. 3. A client deposits money to Eugenes account. These cause the following actions by the activation daemon: 1. A client gets Julies account balance. The activation daemon checks to see whether the server associated with Julies account has been launched. It hasnt, and so the activation daemon has no stub. The daemon then checks to see whether the JVM associated with the server associated with Julies account has been started. The JVM hasnt been started either. The activation daemon starts the JVM. As part of this process, it starts an activation server an implementation of the Activator interface running within the new JVM. The activation daemon then passes in the ActivationDesc associated with Julies account to the activation server within the newly created JVM. The activation server within the newly created JVM uses the ActivationDesc to create the actual instance of Account_Impl . It then returns a stub for this newly created server to the activation daemon. The activation daemon records all of this information internally e.g., it records a map from ActivationDesc to the associated JVM, and from ActivationID to the stub for Julies account and then returns the stub to the client. 2. A client withdraws money from Earls account. Earls and Julies instances of ActivationDesc were associated with different instances of ActivationGroup , and their associated instances of ActivationGroup were themselves associated with different instances of ActivationGroupDesc . This means that the entire process must be repeated; the activation daemon must launch a JVM, connect to the activation server in the new JVM, and request that the server associated with Eugenes account be created. After this, the activation daemon records all the necessary information internally and then returns the stub to the client. 3. A client deposits money to Eugenes account. Because Eugenes and Earls instances of ActivationDesc were associated with the same ActivationGroup , the activation daemon doesnt need to create another JVM. Instead, it simply calls the activation server running in the already existing JVM, and passes it the ActivationDesc associated with Earls account. The activation server that receives the ActivationDesc creates the server for Eugenes account and returns the stub. After that, the activation daemon records all the necessary information internally and then returns the stub to the client. This isnt as complicated as it seems. Figur e 17- 5 and Figur e 17- 6 should help you keep it straight. Figur e 17- 5 illustrates the relationship between the objects created by launch code, and Figur e 17- 6 illustrates the corresponding server topology. Figure 17-5. Launch code Figure 17-6. Runtime structure

17.6.4 Shutting Down an Activatable Server