Deploying an Activatable System

Naming.rebindowner, account; Each of these lines accomplishes a different task. The first line creates an object that contains enough information to create a server. In particular, when we examine the arguments passed into the constructor of ActivationDesc , we see: • The complete name, including the package, of the server class • A URL where the class file can be found or downloaded • An instance of MarshalledObject containing all the initialization information that our instance of Account requires This is enough information to create an instance of Account_Impl . Recall that the Activation Framework insists that any activatable server has a two-argument constructor that takes an instance of ActivationID and an instance of MarshalledObject . The Activation Framework will create an instance of ActivationID at launch time, invoke the constructor using the URL and classname to find the .class file, and then pass in a copy of the instance of MarshalledObject . The second line of code calls a static method, register , defined on the Activatable class. register actually makes a remote call to the activation daemon, passing it ActivationDesc ActivationDesc implements Serializable , and getting a stub in return. Since the activation daemon received a copy of the ActivationDesc , it has enough information to launch the server when necessary. Note that the returned stub is an instance of Account_Impl_Stub , which is the stub class generated by rmic . You still need to run rmic on your servers in order to use activation. The third line of code binds the stub returned by the activation daemon into the RMI registry so that the server is available to clients. This all works with our naming service as well. Nothing in the Activation Framework assumes that the naming service from which the client retrieves stubs is the RMI registry. In fact, nothing in the Activation Framework assumes that a naming service is involved at all. Theres a very nice synergy between our second implementation of factories and the Activation Framework. The application-specific factory provides client- friendly methods for lookup and adds things such as persistence and lock management. However, it delegates the actual launching of the servers to the activation daemon.

17.6.2 Deploying an Activatable System

It has been observed by many people on numerous occasions that the activation daemon takes a while to get going. Its not exactly clear whats going on while the activation daemon launches, but the best policy is to wait a while for things to settle down before registering any activatable objects. That is, do something such as the following: 1. Start the naming service. 2. Start the activation daemon. 3. Wait two minutes. 4. Create the activatable objects. In the case of our bank example, the entire launch sequence including a client application is: 1. rmiregistry -J-Djava.security.policy=java.policy . 2. rmid -C-Djava.security.policy=java.policy . 3. -J-Djava.security.policy=java.policy . 4. Wait two minutes. 5. java com.ora.rmibook.chapter17.activation.applications.ActivationLaunch er . 6. java com.ora.rmibook.chapter17.activation.applications.BankClient . The security policies are necessary. Ill explain why in Chapt er 18 . This launch sequence requires us to have at least two Java processes, the activation daemon and the registry, running in addition to our servers. Sometimes, especially in the case of smaller systems, the extra overhead of an additional Java process can be a bit annoying. If this is the case with your application, and you want to eliminate one of the processes, you can take advantage of the activation daemons internal registry. The activation daemon has a registry to enable clients to connect with it. We talked about how the activation system uses smarter stubs, and how these stubs first contact the activation daemon before connecting to the actual server. In addition, our launch code contacts the activation daemon indirectly when it registers the activation groups and descriptions. In order for this to happen, the activation daemon itself must be registered in a naming service so external code can get a stub. There are two basic possibilities: either the activation daemon registers itself in an external naming service, or it provides a naming service on a well-known port. The designers of RMI chose the second path. When you run rmid , the activation daemon creates an RMI registry on port 1098. This is a fully functional registry, created using LocateRegistry.createRegistry , and available on the network. Moreover, the activation daemons registry is fairly empty™if you examine it using the RegistryExplorer program from Chapt er 14 , youll find that only one server is bound into it. See Figur e 17- 4 . Figure 17-4. Using the RegistryExplorer program on the activation daemons registry 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