In case RMI is new to you, it's worthwhile to get a brief overview of the technology before moving into the details of using RMI with Quartz. If you're completely comfortable with RMIand, specifically, Java RMIfeel free to skip this material.
RMI is a mechanism that enables an object in one address space to communicate with objects in a different address space. These two address spaces can exist on the same machine or on entirely different ones. In general, you can think of RMI as an object-oriented Remote Procedure Call (RPC) mechanism.
RMI is not specific to Java, but Java does have its own version: Java RMI, which is released and supported by Sun (http://java.sun.com/products/jdk/rmi) as part of its Java SDK. Java RMI allows objects running in one JVM to communicate with and invoke methods on objects running in a second. These two JVMs can be running on the same machine or, more interestingly, on different ones. They might even be running on different platforms. For example, one JVM might be running on a Windows box, while the second runs on Linux. With Java RMI, it really doesn't matter. Figure 9.1 illustrates this scenario.
Figure 9.1. Java RMI enables developers to create distributed applications.
RMI is based on the principle of separation of responsibility. Interface definition is separated from the implementation. This coincides nicely with the goal of RMI: to allow a client, which is primarily concerned with the interface definition, to be separated (possibly physically) from the implementation of that interface definition. In order words, the client has an interface on which it can invoke the service call, while the implementation of that service lives on another machine. Figure 9.2 illustrates this separation within the Java programming language.
Figure 9.2. Java supports separating the service interface from the implementation.
When the RMI client invokes a method on the object, it is really invoking a method on a proxy object located in the client JVM. This proxy object knows how to communicate with the object located on the server. All communication, including values being passed to the server object and returned from it, occurs through the proxy object. This is shown in Figure 9.3.
Figure 9.3. All communication from the client to the server goes through the proxy object.
Components of a Java RMI Application
Every Java RMI application consists of three components:
The RMI Server
The RMI server is responsible for creating the server object (which the client invokes methods on) and making the object available to remote clients. The RMI server runs in a standard JVM. The server objects are also regular Java objects and can be invoked locally as well as remotely.
The RMI Client
The RMI client is a Java program that (typically) runs in a separate JVM from the server; it might be on the same physical machine as the RMI or distributed on a separate machine. The client gets a reference to the server object by looking it up in the RMI Registry.
The RMI Object Registry
The RMI Object Registry is used by both the RMI client and server. When the server wants to make an object available to remote clients, it registers the object (along with a unique name) with the Registry. After a server object has been registered, RMI clients and methods invoked on the object can look it up.
Scheduling in the Enterprise
Getting Started with Quartz
Hello, Quartz
Scheduling Jobs
Cron Triggers and More
JobStores and Persistence
Implementing Quartz Listeners
Using Quartz Plug-Ins
Using Quartz Remotely
Using Quartz with J2EE
Clustering Quartz
Quartz Cookbook
Quartz and Web Applications
Using Quartz with Workflow
Appendix A. Quartz Configuration Reference