Advertisement

The first incarnation of the Service UI API and specification included eight UI factory interface types that enable Swing and AWT UIs to be associated with Jini services. These UI factory interfaces assume the Swing and AWT UI objects will exist in the same address space as the Jini service proxy. The user interacts with the UI object; the UI object interacts with the service proxy. This architecture is shown graphically in Figure 1.

Figure 1. A user interacts with a service via a UI object.

In effect, a UI object adapts the Java interface of the service proxy into a user interface accessible to humans. As a result, a Jini service UI object is sometimes referred to as a user adapter.

The service UI architecture enables more than one UI object to be associated with the same service proxy. Client devices differ in their user interface capabilities and users differ in their preferences. Service providers can define and associate with their services multiple service UIs, each geared for a different set of client capabilities and user preferences. Third parties can define their own UI objects to supplement those provided by the service provider. This architecture enables users to access the same service from many different kinds of Jini-enabled computers and devices.

Devices that Use Surrogates

Not all devices, however, are Jini-enabled. Some devices have a Java virtual machine, but do not include the Jini APIs. Other devices have no Java virtual machine at all. The surrogate architecture enables such non-Jini devices to participate in the Jini world. A non-Jini device discovers a nearby surrogate host, which is a Jini-enabled Java virtual machine. The device sends Java class files to the surrogate host, which instantiates from those class files an object called a surrogate. The surrogate, which interacts with the device via a network protocol, represents the non-Jini device to the Jini federation. On behalf of the device, the surrogate can offer or consume Jini services.

Providing service UIs for devices that use surrogates is desirable by both users and service providers. If a device that uses a surrogate has a user, that user may want to access Jini services via some kind of user interface defined by the service provider. Service providers, to extend the reach of their services, may want to provide user interfaces for their services that will work with devices that user surrogates. In both the serviceui and surrogate projects at jini.org, we have been discussing how to accomplish this. This document is an attempt to capture the current state of that discussion.

Service UIs for non-Jini Devices

First of all, we seem to agree that a service UI for a non-Jini device would itself be a distributed entity made up of two parts:

• A protocol adapter, a Java object that runs in the surrogate host
• A device UI, which runs on the non-Jini device

The protocol adapter interacts with the device UI across some kind of network via a network protocol. The name protocol adapter was chosen because this object plays an role similar to the user adapters described earlier. A user adapter object adapts the interface of a Jini service proxy to some user interface understandable by human users. A protocol adapter object adapts the interface of a Jini service proxy to some network protocol understood by the device UI.

The device UI may be a client UI, which already exists on the non-Jini device. For example, the device could include code that understands WAP/WML or HTTP/HTML. In this case, the service UI would consist only of a protocol adapter that speaks the appropriate protocol (such as WAP/WML). The surrogate would instantiate the protocol adapter in the surrogate host and connect the protocol adapter to the device over the network. The protocol adapter would talk to the device via WAP/WML, HTTP/HTML, or some other protocol.

On the other hand, if the device is Java-enabled (but not Jini-enabled), then the device UI could be a mobile object defined as part of the service UI and downloaded into the device. For example, the device UI could be an AWT Panel or a MIDlet. In this case, the service IU would consist of the protocol adapter and the device UI objects (such as the MIDlet). When a surrogate selects such a service UI, the surrogate would instantiate the protocol adapter in the surrogate host and send the device UI to the device. The device would instantiate the newly arrived device UI object, and establish some connection between the device UI and the protocol adapter in the surrogate host. This architecture is shown in Figure 2.

Figure 2. A non-Jini device uses a service UI.

We were hoping we could abstract away the type of network that forms the connection between surrogate host and device by simply passing input and output streams to the protocol adapter and, if the device UI is a Java object sent to the device, to the device UI. I.e., protocol adapters and device UIs (when they are included as part of the service UI) wouldn't have to worry about the underlying network. They would just read bytes from InputStreams and write bytes to OutputStreams.

Using UIDescriptor

We seem to agree that what we primarily need to do to make the architecture shown in Figure 2 a reality is define some new UI factory interfaces and their semantics. This would enable service UIs for devices that use surrogates to be described by a UIDescriptor, which is how service UIs for Jini-enabled clients are described. The rest of UIDescriptor would be filled in as follows:

• role - filled in the same as in regular service UIs, but in this case, the protocol adapter implements the role interface. (I'm not sure this makes sense, because in roles defined in the future, there may be methods in those interfaces. I'm not sure if it will always make sense that the surrogate can sensibly invoke those methods.)
• factory - want to separate the codebases of the ServiceItem and the protocol adapters and device UIs, if any. So have a marshalled UI factory that, when unmarshalled, would produce an object that implements UI factory interfaces. The methods in those UI factory interfaces produce the protocol adapter and device UIs, if any.
• toolkit - a string defined when we define the new factory interfaces.
• attribute:
  • RequiredPackages attribute - describes packages required by the protocol adapter
  • UIFactoryTypes attribute - describes the interfaces implemented by the UI factory object
  • Locales attribute - describes the locales offered by the conceptual service UI.
  • Accessible attribute - says whether or not the conceptual service UI is accessible. (This probably only makes sense in Swing service UIs.)
  • DeviceRequiredPackages attribute - describes packages required by the device UI (or device UIs). This would be a new attribute that we define in addition to the new UI factory interfaces.

Here are some rough sketches of what the UI factory interfaces could look like:

public interface MIDletDeviceUIFactory {

// Could put something special into the toolkit
// string to differentiate between MIDlet UIs for
// devices with surrogates and MIDlet UIs for
// full-blown Jini clients. I.e., could be
// "javax.microedition.midlet Device UI".

    TOOLKIT = "javax.microedition.midlet";

// I grabbed these from your (Greg's) previous post.
// I'm not sure how the surrogate would want to get
// the JAR file.

    URL getMIDletURL();
    byte[] getMIDletJar() throws IOException;

    Object getProtocolAdapter(Object roleObject,
        InputStream in, OutputStream out);
}

First the surrogate would grab the JAR file via get MIDletJar(), send the JAR file to the device. The device would instantiate the client side MIDlet UI, passing it some IO streams. The surrogate, meanwhile, would invoke getProtocolAdapter(), passing it the other end of those IO streams. Voila. Or for Panels:

public interface PanelDeviceUIFactory {

// Could put something special into the toolkit string
// to differentiate between AWT UIs for devices with
// surrogates and AWT UIs for full-blown Jini clients
// I.e., could be "java.awt Device UI".
    TOOLKIT = "java.awt";

    URL getPanelURL();
    byte[] getPanelJar() throws IOException;

    Object getProtocolAdapter(Object roleObject,
        InputStream in, OutputStream out);
}

Or, for device UIs that already exist on the device, the UI factory interface would only need to describe the network protocol spoken by the protocol adapter:

public interface WAPWMLFactory {

    TOOLKIT = "java.io";
    Object getWAPWMLProtocolAdapter(Object roleObject,
        InputStream in, OutputStream out);
}

public interface HTTPHTMLFactory {

    TOOLKIT = "java.io";
    Object getHTTPHTMLProtocolAdapter(Object
       roleObject, InputStream in, OutputStream out);
}

ServiceUI is a trademark of Artima Software, Inc.