This chapter delves into some of the more complex things that can happen with Jini applications.
Clients, servers and service locators can use code from a variety of sources. Which source it uses can depend on th structure of a client and a server. This section looks at some of the variations that can occur.
A service may require information about a client before it can
(or will) proceed. For example, a banking service may require
a user id and a PIN number. Using the techniques already discussed,
this could be done by the client collecting the information and
calling suitable methods such as void setName(String name)
in the service (or more likely, in the
service's proxy) running in the client.
public class Client {
String getName();
}
class Service {
void setName(String name);
}
A service may wish to have more control over the setting of names and passwords than this. For example, it may wish to run verification routines based on the patter of keystroke entries. Or more mundanely, it may wish to set time limits on the period between entering the name and the password. Whatever, the service proxy may wish to perform some sort of input processing on the client side before communicating with the real service. This section explores what happens when the service proxy needs to find extra classes in order to perform this processing.
A standalone application to get a user name might use a GUI interface such as
package complex;
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
/**
* NameEntry.java
*
*
* Created: Sun Mar 28 23:47:02 1999
*
* @author Jan Newmarch
* @version 1.0
*/
public class NameEntry extends JFrame {
public NameEntry() {
super("Name Entry");
addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent e) {System.exit(0);}
public void windowOpened(WindowEvent e) {}});
JLabel label = new JLabel("Name");
JTextField name = new JTextField(20);
Container content = getContentPane();
content.add(label, BorderLayout.WEST);
content.add(name, BorderLayout.CENTER);
name.addActionListener(new NameHandler());
pack();
}
public static void main(String[] args) {
NameEntry f = new NameEntry();
f.show();
}
} // NameEntry
class NameHandler implements ActionListener {
public void actionPerformed(ActionEvent evt) {
System.out.println("Name was: " + evt.getActionCommand());
}
}
The classes used in this are
JFrame, JLabel, JTextField,
ActionListener, ActionEvent, BorderLayout, Container,
WindowEvent, System
.
NameEntry, NameHandler
.
In moving to a Jini system, we have already seen that different components may only need access to a subset of the total set of classes. The same will apply here, but it will crtically depend on the how the application is changed into a Jini system.
We don't want to be overly concerned about program logic of what is done with the user name once it has been entered, as the interesting part in this section is the location of classes. All versions will need an interface definition, which we can make simply as
package complex;
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
/**
* NameEntry.java
*
*
* Created: Sun Mar 28 23:47:02 1999
*
* @author Jan Newmarch
* @version 1.0
*/
public class NameEntry extends JFrame {
public NameEntry() {
super("Name Entry");
addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent e) {System.exit(0);}
public void windowOpened(WindowEvent e) {}});
JLabel label = new JLabel("Name");
JTextField name = new JTextField(20);
Container content = getContentPane();
content.add(label, BorderLayout.WEST);
content.add(name, BorderLayout.CENTER);
name.addActionListener(new NameHandler());
pack();
}
public static void main(String[] args) {
NameEntry f = new NameEntry();
f.show();
}
} // NameEntry
class NameHandler implements ActionListener {
public void actionPerformed(ActionEvent evt) {
System.out.println("Name was: " + evt.getActionCommand());
}
}
Then the client can call upon an implementation to simply show
itself and collect information in whatever way it chooses.
The first version of an implementation is