In the wizard API, the client is the user interface. The user interface includes the panels that manipulate the configuration of the wizard, as well as the structure that supports those panels. The WizardConsole, WizardTreeManager, IteratorLayout, navigation panel, and the image panel are all pieces of the wizard client. These objects must not directly perform any action that would not be permitted within a Java-enabled web browser. For example, these objects cannot create an instance of a File object that will be used to read a file, create a file, check the length of a file, or check the existence of a file. This would result in a security exception if the wizard were to be operated remotely.
The server in the wizard API is everything but the user interface. This includes the WizardState, all Sequence objects and the Task objects they contain, and all data that is written into the WizardState either at build time or at run time. The server has permission to do anything the operating system will allow. This includes creating and deleting files, assuming the server is running with proper permissions.
The client and server communicate between the WizardTreeManager object on the client side and the root WizardState object on the server side. The WizardTreeManager maintains a reference to the WizardState object. Through that reference it can call WizardState methods. Likewise, the root WizardState object maintains a reference to the WizardTreeManager object so it can call client object methods.
When working remotely, one other object is used to facilitate this communication. This object, RemoteWizardConsoleState, is used to communicate with the WizardState object through Remote Method Invocation (RMI). The RemoteWizardConsoleState follows the Proxy design pattern, which converts direct WizardState messages from the WizardTreeManager object into RMI calls. The RemoteWizardConsoleState also accepts messages from the WizardState object, whose target is the WizardTreeManager. The RemoteWizardConsoleState implements the WizardState interface, to complete messages from the client to the server, and forwards messages being sent from the server to the client.
The RMI scheme requires at least one server object to register itself with an RMI object registry. This is the lookup mechanism that enables an object to obtain a reference to a remote object. The GenericRemoteWizardState object registers itself. This object implements the WizardState interface and is actually subclassed from GenericWizardState, which defines the behavior of the WizardState interface for local use. The subclass registers itself on the RMI registry and catches the RemoteException for methods that communicate between the server and the client.
A single point of contact between the server and the client provides an easy way to achive remote operation without tying the entire design to RMI. This Remote operation of wizards was a chief goal in the design of the wizard application framework. This contributes to the platform independence of wizards. RMI requires TCP/IP to be installed and working. Some operating systems do not install TCP/IP unless a network card is installed. If RMI were required for all wizards to operate, wizards could never be platform independent. This would severely limit the audience for any particular wizard.
Last modified: Fri Nov 25 16:48 PDT