The Artima Developer Community
Sponsored Link

The Cyberspace Project
Jini Place API Draft Specification
Version 0.4


This is an outdated version of the specification.

For the latest version of the specification, see:

Revision History

1. Introduction

A new computer is on the horizon, a meta-computer made of up every computer connected to every other computer. As embedded devices with high bandwidth network connections become increasingly common, this new meta-computer may gradually supplant the desktop PC as the primary computer people use. The coming change in the hardware status quo provides an opportunity to rethink the basic user-interface metaphors by which people use software. This Jini Place API proposes a simple "space metaphor" by which users could relate to and use the services offered by the emerging meta-computer.

Two fundamental metaphors currently dominate most people's experience of software: the desktop metaphor and the web metaphor. The abstraction that plays the starring role in both of these metaphors is the file.

The personality of a desktop computer is its hard disk, and the desktop metaphor primarily helps users manage files on disks. Users are told that some of those files are applications, the rest are documents. All files are represented by icons. If you double click on an application's icon, the application launches. If you double click on a document icon, an application is launched that opens the clicked-upon document.

Each document on the desktop is associated with an application. The application, which is the behavior that knows how to use the document's data, can be thought of as the document's type. The type of a document is usually indicated in some manner external to the document file contents. On Windows, for example, the document type is indicated by the three-character extension of the filename. The filename (and its extension) is known to the file system, but is not generally an intrinsic part of the file itself.

The World Wide Web popularized hypertext, a user-interface metaphor distinctly different from the desktop. Yet on the web, the fundamental unit is still the file. Rather than helping users manage files on nearby disks, however, the web helps people use files delivered by servers on in internet. Most files, but not all, show up as HTML web pages. As on the desktop, each file on the web has a type, which is external to the contents of the file itself. When an HTTP server sends a file, it includes a MIME type header that indicates the type of the file. The browser uses the file type to decide how to present the file to the user.

The browser understands certain MIME types, such as text/html. For such types, the browser itself is the behavior that knows how to use the file's data. If the browser receives a file with a MIME type it doesn't understand, it looks around for a plug-in that understands the type. If it finds a suitable plug-in, it passes the file to the plug-in, and the plug-in decides what to do. In this case, the plug-in is the behavior that understands how to use the file. In either case, the software that represents the behavior for a particular file type must already reside on the client side, either in the browser itself or as a plug-in.

1.1. Jini Service Objects and Service UIs

In contrast to the desktop and web metaphors, where the fundamental abstraction is the file, the fundamental abstraction in the space metaphor is the object. In Jini, network-delivered services are represented by network-mobile objects. Each object has a class, which represents its type. In contrast to files, whose types in general external to the files themselves, the types of objects are intrinsic to the objects. The type is intrinsic because objects are a bundles of behavior. Many objects carry data in instance variables, but most objects keep that data private and use it to decide how to behave when their methods are invoked. The fundamental character of an object is its behavior.

To present the behavior of a service object to a human user, a user interface (UI) object can be inserted between the user and the service object. If the client has prior knowledge of the object's type, the UI object can be provided by the client. Alternatively, the UI object can be delivered across the network with the service. Such network-delivered UIs are called service UIs, because they are provided by the service. Here's a diagram from the Jini Service UI specification, which defines a standard way to associate UIs with Jini services. This diagram shows a user using a Jini service via a service UI:

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

1.2. Objects in Places

Although the service UI standard shows how users can interact with any individual service, it doesn't address how users will interact with the set all the services offered by the emerging meta-computer. The purpose of the Jini Place API is to address this second question: to provide users with a metaphor by which they interact with the meta-computer as a whole.

In the metaphor established by the Place API, all services are represented by objects. Objects are organized into places. To do something on the meta-computer, users go to a place and use an object. This "objects in places" metaphor encourages users to think of the meta-computer as a space.

Most users of the World Wide Web already tend to think in spatial terms. You might hear someone say, " is the main Jini web site." Or, " is now easier to navigate." Or, "If you want to start a Jini project, go to" The italicized words -- site, navigate, go to -- demonstrate the tendency for users to form their own ad hoc space metaphor when thinking about the World Wide Web. The Place API formalizes this space metaphor.

1.3. A Graph of Objects

Place is a Jini service interface that will enable service objects, in addition to whatever other services they provide via their interface, to offer a "collection of links" service. Thus, the conceptual objects and places that users interact with are both implemented as network-mobile Jini service objects. To be a conceptual place, a Jini service need only implement the Place interface.

In the sense that they offer a "collection of links" service, Place services are similar to web pages. Two main characteristics distinguish a web page from a traditional page, such as a page from a book or magazine. First, a web page is delivered across a network. Second, a web page contains links to other resources on the network, primarily other web pages. Both web pages and traditional pages offer information services, but a web page also offers a "collection of links" service in addition to its information service.

The following diagram depicts the organization of the current World Wide Web. Each rectangle is a web page, which offers both an information service and a collection of links service. The links are depicted as arrows drawn from one web page to another.

Figure 2. The web is a graph of files.

Like web pages, Jini service objects offer network-delivered services. Whereas an individual web page offers primarily an information service, a collection of links service, and perhaps a form service, a Jini service object is more generic. A Jini service object offers the types of service inherent in the object's class. The services themselves are available via the object's interface. Any type of service for which an interface can be defined, therefore, could be delivered across the network as a Jini service object.

The Place interface enables service objects, in addition to whatever other services they provide via their interface, to offer a "collection of links" service. The aim of Place is to enable the set of all services to be organized into a graph, as depicted in the following diagram. In this diagram, the circles are Jini service objects, arrows show links from one object to another.

Figure 3. The space is a graph of objects.

The space metaphor says that everything is a conceptual "object." Conceptual objects are implemented as network-mobile service objects, accessed by users via network-mobile service UIs. Every object has an intrinsic class, which defines the types of services offered by the object. Users and service providers organize objects by placing links to those objects in places. The existence of places on the network continues the "everything is an object" metaphor, because a place is just another type of object -- an object used to organize user relationships to other objects. As objects link to other objects, the graph organization shown in Figure 3 emerges.

1.4. A Seamless User Experience

One of the motivations of the Place API is to give users a more seamless experience than is possible with the web. Because the web is file-based, users must already have installed behavior that understands the type of a network-mobile file. Because objects are behavior, network-mobile objects can provide users with a more seamless experience of interacting network-delivered services. Users needn't worry about installing plug-ins. They can just use the objects.

Given that the World Wide Web is rather popular, however, the Place API includes a way to wrap files in objects. Instead of plug-ins, files can be viewed with network-mobile service UIs. The space metaphor subsumes the web metaphor, because in the space metaphor, web pages become a special kind of document object.

Figure 4. The space subsumes the web.

2. The Place Interface

The interface contains only one method, getLinkMap(), which takes no parameters and returns a LinkMap object, an object that implements the interface. A LinkMap object is a collection of links to resources on the network. Jini services of any type can, in addition to other services they offer through their interface, offer a "collection of links" service through their interface by implementing

Here's the Place interface:


import java.rmi.RemoteException;
import java.rmi.Remote;

public interface Place extends Serializable, Remote {

    LinkMap getLinkMap() throws RemoteException;

(Note: If we can convince the Jini community, we'd like to ultimately place Place in the package.)

3. The LinkMap Interface

A LinkMap holds a collection of links to resources on the network. The methods declared in interface allow clients to access, but not change those links. Interface ModifiableLinkMap, a subinterface of LinkMap described later in this specification, allows clients to modify the links contained in a LinkMap. The links contained in a DynamicLinkMap, yet another subinterface of LinkMap described later in this specification, may asynchronously change while the client is using the DynamicLinkMap.

LinkMap is called a map because each link contained in a LinkMap is associated with an Object key. Clients can obtain an unmodifiable java.util.Set of all keys via the keySet() method. In addition, clients can obtain an unmodifiable java.util.Collection of all the links contained in the LinkMap via the values() method. To obtain the link value for a particular key, clients can invoke the get() method, which takes an Object key as its only parameter and returns a LinkItem. LinkItem is described in the next section of this specification.

Here's the LinkMap interface:


import java.rmi.RemoteException;
import java.util.Set;
import java.util.Collection;

public interface LinkMap extends Serializable {

    LinkItem get(Object key) throws RemoteException;

    boolean containsKey(Object key) throws RemoteException;

    boolean containsValue(LinkItem value) throws RemoteException;

    boolean isEmpty() throws RemoteException;

    Set keySet() throws RemoteException;

    int size() throws RemoteException;

    Collection values() throws RemoteException;

4. LinkItem, Link, and ResourceInfo

The object returned by LinkMap's get() method is an instance of LinkItem is a simple container for two other objects, a and a The Link object represents the actual link to a resource on the network. The ResourceInfo object provides information, suitable for presentation to users, about the resource referenced by the Link.

The motivation for having a LinkItem that associates a ResourceInfo with a Link, rather than allowing Links themselves to contain a ResourceInfo, is that the information stored in the ResourceInfo belongs to the Place, not to the Link or the service it references. Just as current users of the World Wide Web bookmark pages they want to return to, users of a web of objects may want to copy Links to resources to their own modifiable home places. They may then wish to change the name, description, and/or icons associated with that copied and saved Link. By keeping Link and ResourceInfo separate, each client can change the ResourceInfo associated with their own copies of Links.

Note: It just occurred to me that the security manager probably won't let most copied ResourceInfo's go out and load JAR files that contain icon images. Therefore, we should investigate having a SelfContainedResourceInfo that stores its names and descriptions in Strings and icons in byte arrays, all referenced from the SelfContainedResourceInfo. Another possibility is adding a service context interface that will grab icons and strings out of property files for the service. Seems grabbing an icon or a string across the network and passing that back to the client shouldn't be a security risk.

Here are the public portions of LinkItem:



public class LinkItem implements Serializable {

    public LinkItem(Link link, ResourceInfo resourceInfo) {...}

    public Link getLink() {...}

    public ResourceInfo getResourceInfo() {...}

    public boolean equals(Object o) {...}

    public int hashCode() {...}

4.1. The Link Interface

An object that implements interface represents a link to a resource on the network. In the current World Wide Web, links to resources are expressed in terms of URLs, a string that represents an address or unique name of a resource. Links are intended to serve the same purpose as URLs, but Links a distinctly different from URLs.

Although like URLs, Links represent links to resources on the network, Links are not just wrappers for URLs. Link is an attempt to raise the level of abstraction of URLs. A URL is data. You can send a URL across the network to a client, but for the client to use the URL, the client needs code already existing on the client side that knows how to interpret the URL data. In particular, the client needs to know the protocol indicated in the first portion of the URL. What's more, the person doing the sending of the URL needs to know the host and port number where the resource is available, in addition to the name of the resource.

By contrast, a Link is not a chunk of data like the URL, a Link is an object. You can send a Link across the network to the client, just as you can send a URL across the network. But in the case of a Link, you are not sending data across the network, you are sending behavior. To follow a Link, you ask the Link to get the resource for you. The behavior determining how the resource is retrieved does not reside in client side code, but is contained in the code that defines the Link's class, code that is sent across the network as part of the Link object. To retrieve a resource, the Link can do anything it wants (so long as it is allowed by the local security policy) to retrieve the resource.

Here's the Link interface:


import java.rmi.RemoteException;

public interface Link extends Serializable {

    LinkActivation activate(ActivationClient ac) throws RemoteException;

One of the motivations of raising the level of abstraction of a URL is that a Link will be able to do fancy things with Jini lookup services that would be very difficult to express in a URL. For example, a Link could do multicast discovery to get references to nearby Jini lookup services. It could then perform lookups by type and attributes in those lookup services, and sort through multiple responses using some algorithm that is also part of the network-delivered code of the Link. One of the goals for Link is to provide an abstraction that everyday users can understand that enables those users to access the functionality of the ServiceRegistrar interface.

More discussion of link activation is given later in this specification.

4.2. The ResourceInfo Interface

Accompanying each Link in a LinkItem is an object that implements ResourceInfo allows clients to retrieve information, suitable for presentation to users, about the resource referenced by the Link. ResourceInfo encapsulates three basic kinds of information, a name, a description, and icons. Names and descriptions are returned as Strings. Icons are returned either as pointing to image data, or as containing the actual image data. Icons can be requested in the four flavors available from java.beans.BeanInfo or via the net.jini.lookup.entry.ServiceType entry:

All information retrieved from a ResourceInfo can either be requested for a specific locale or allowed to adapt to the default locale. A method, getSupportedLocales() allows clients to get an array of all locales supported by the ResourceInfo. The ability to query for supported locales and retrieve information for specific locales is actually targetted at search engine spiders, which will likely be interacting with ResourceInfo objects retrieved from entries, not from LinkItems. Class SpiderFodder is described later in this document.

Here's the ResourceInfo interface:


import java.util.Locale;

public interface ResourceInfo extends Serializable {

    int ICON_COLOR_16x16;
    int ICON_COLOR_32x32;
    int ICON_MONO_16x16;
    int ICON_MONO_32x32;

    Locale[] getSupportedLocales();

    String getName();

    String getName(Locale locale);

    String getDescription();

    String getDescription(Locale locale);

    URL getIconImageFile(int iconKind);

    InputStream getIconImageFileAsStream(int iconKind);

    URL getIconImageFile(Locale locale, int iconKind);

    InputStream getIconImageFileAsStream(Locale locale, int iconKind);

Of course, ResourceInfo only defines the minimum kind of user-presentable information that can be associated with a Link. Other kinds of informatoin, such as for example compressed view icons or sound bites, could be made available via the class that implements ResourceInfo, or via Place service UIs.

Not sure get methods that return a URL make sense. If the icon is sent in the state of the ResourceInfo, then there is no URL.

5. Activating Links

When the activate() method is invoked on a Link, the Link will attempt to retrieve the referenced Jini service. Here's the signature of the activate() method:

    LinkActivation activate(ActivationClient al) throws RemoteException;

5.1. The ActivationClient Interface

The activate() method accepts a single parameter, an object that implements The ActivationClient passed to activate() is notified when a link activation completes, either with success, failure, or as a result of being aborted. Only one of the methods in this interface will be invoked (only once) for each link activation. This enables clients to indicate to users that an activation is in progress. For example, a client could show an animation while the activation is in progress, then stop the animation after the activation completes.

Here's the ActivationClient interface:


public interface ActivationClient {

    void activationSucceeded(ServiceItem serviceItem);

    void activationFailed(String message, Throwable exception);

    void activationAborted();

The result of every successful link activation is a Jini ServiceItem, which is passed to the activationSucceeded() method. The String message passed to the activationFailed method contains a localized message that may be displayed to users. (A localized message is chosen first, then that message is passed to the activationFailed() method.) If some exception caused the activation to fail, it may be handed to the client in the The Throwable passed to the activationAborted() method.

5.2. The LinkActivation Interface

The activate() method returns an object that implements the interface. The activate() method should never block until the activation completes. Rather, activate() should return promptly. The LinkActivation object returned by activate() represents the ongoing activation to the client. The LinkActivation object allows the client to abort the activation via the abort() method. The object may optionally implement other interfaces, such as ProgressEventGenerator and StatusEventGenerator, or include other methods in its class, which allow other kinds of client interaction. ProgressEventGenerator and StatusEventGenerator are described later in this specification.

Here's the LinkActivation interface:



public interface LinkActivation extends Serializable {

    void abort();

5.3. The ProgressEventGenerator Interface

The LinkActivation object returned from activate() may optionally implement the interface, which enables clients to register interest in receiving progress updates, expressed in terms of percent complete, during the course of the activation. Here's the ProgressEventGenerator interface:

public interface ProgressEventGenerator {

    void addProgressListener(ProgressListener pl);

    void removeProgressListener(ProgressListener pl);

The methods of ProgressEventGenerator accept an object that implements the interface. ProgressListener contains one method, progressUpdated(), which is invoked when the progress of an activation has changed. Progress is reported as percent complete. Although users would expect that the percent complete reported would in general increase over time, the actual progress events need not report consecutive percentages, or even increasing percentages.

Here's the ProgressListener interface:


public interface ProgressListener {

    void progressUpdated(ProgressEvent pe);

To notify a ProgressListener of a change in percentage complete, the event generator passes a to the ProgressListener's progressUpdated() method. The ProgressEvent contains an int percent complete, which may be communicated to users via a explicit percentage number, a progress bar, or other means.

Here's the public portions of the ProgressEvent class:

import java.util.EventObject;

public class ProgressEvent extends EventObject {

    public ProgressEvent(ProgressEventGenerator source,
        int percentComplete) {...}

    public int getPercentComplete() {...}

ProgressEvents indicate the overall activation progress (major progress), not the the progress of each individual activity (minor progress). Thus, the progress should not snap from zero to 100 percent quickly and repetitively during the lifetime of the activation. Progress should in general move from zero to 100 percent once for each activation.

Could make the ProgressEvent constructor private, and declare a public static factory method that returns a ProgressEvent object for a passed percentage. This would allow these to be instantiated lazily, then cached and shared by everyone.

5.4. The StatusEventGenerator Interface

The LinkActivation object returned from activate() may optionally implement the interface, which enables clients to register interest in receiving status updates, expressed as localized Strings suitable for display to users, during the course of the activation. Here's the StatusEventGenerator interface:

public interface StatusEventGenerator {

    void addStatusListener(StatusListener sl);

    void removeStatusListener(StatusListener sl);

The methods of StatusEventGenerator accept an object that implements the interface. StatusListener contains one method, statusUpdated(), which is invoked when the status of an activation has changed.

Here's the StatusListener interface:


public interface StatusListener {

    void statusUpdated(StatusEvent se);

To notify a StatusListener of a new status message, the event generator passes a to the StatusListener's statusUpdated() method. The StatusEvent contains a String status message, which may be communicated to users via a status bar or other means. A localized String message should be selected first, then passed to the StatusEvent constructor.

Here's the public portions of the StatusEvent class:

import java.util.EventObject;

public class StatusEvent extends EventObject {

    public StatusEvent(StatusEventGenerator source, String status) {...}

    public String getStatus() {...}

6. The ModifiableLinkMap Interface

Service providers can use Place services to present multiple services to users. In such Places, links will be controlled by the service provider. Users will be allowed to activate links at those Places, but not add, delete, or change the links. But some Place services will be provided to users, so that the users can organize their own links to resources on the network. At this kind of Place, links will be controlled by the user.

The interface enables users to maintain links to their favorite resources. Regardless of whether the links at a Place are intended to be controlled by the service provider or user, the service object implements the same interface, In either case, clients obtain a LinkMap by invoking getLinkMap() on the Place service object. The returned object definitely implements LinkMap, but may also implement ModifiableLinkMap, which is a subinterface of LinkMap. If the object is a ModifiableLinkMap, the client will be able to add, delete, and change links contained in the LinkMap via the methods declared in ModifiableLinkMap interface. The changes requested via the ModifiableLinkMap interface are persistent with respect to the Place. The next time a user visits the same Place, the users will see all the changes made the previous visit.

With a ModifiableLinkMap, a client can add a new LinkItem to a Place via the put() method, can remove a LinkItem via the remove() method, and can associate a new ResourceInfo with an existing Link via the update() method. Here's the ModifiableLinkMap interface:


import java.rmi.RemoteException;

public interface ModifiableLinkMap extends LinkMap {

    void clear() throws RemoteException;

    LinkItem put(Object key, LinkItem value) throws RemoteException;

    LinkItem update(Object key, ResourceInfo resourceInfo) throws RemoteException;

    void putAll(LinkMap map) throws RemoteException;

    LinkItem remove(Object key) throws RemoteException;

7. The DynamicLinkMap Interface

A DynamicLinkMap represents a dynamic map of links to resources on the network. The map is "dynamic" because it may asynchronously change while the client using it. For example, a Place service may provide a client with links to the Jini services registered in a particular lookup service that match a particular template. As matching services arrive and depart the lookup service, links to those services will be dynamically added and removed from the Place's LinkMap.

The DynamicLinkMap interface contains methods that enable the client to register and unregister itself as an interested listener for events that describe changes to the map. A LinkMap implementation class can optionally implement ModifiableLinkMap and/or DynamicLinkMap. A class that implements both ModifiableLinkMap and DynamicLinkMap will notify LinkMapListeners of all changes to the LinkMap, including changes resulting from the client invoking methods declared in ModifiableLinkMap.

Here's the DynamicLinkMap interface:


import java.rmi.RemoteException;
import java.util.Set;
import java.util.Collection;

public interface DynamicLinkMap extends LinkMap {

    void addLinkMapListener(LinkMapListener lml);

    void removeLinkMapListener(LinkMapListener lml);
The linkMapChanged() method of all registered LinkMapListeners are invoked when one or more links in a DynamicLinkMap are altered, added, and/or removed. Here's the LinkMapListener interface:

public interface LinkMapListener {

    void linkMapChanged(LinkMapEvent lme);

A LinkMapEvent indicates a change in the contents of a DynamicLinkMap. This event will only be fired if at least one link was altered, added, or removed. On the other hand, a single LinkMapEvent may be used to report multiple alterations, additions, and/or removals. Each alteration, addition, or removal of a particular DynamicLinkMap is reported in one and only one LinkMapEvent.

Each get method in LinkMapEvent returns an array of Object keys for those links that have been either altered, added, or removed. Here's the public portions of LinkMapEvent:

import java.util.EventObject;

public class LinkMapEvent extends EventObject {

    private Object[] keysAltered;
    private Object[] keysAdded;
    private Object[] keysRemoved;
    private static Object[] emptyKeyArray = new Object[0];

    public LinkMapEvent(DynamicLinkMap source, Object[] keysAltered,
        Object[] keysAdded, Object[] keysRemoved) {...}

    public Object[] getKeysAltered() {...}

    public Object[] getKeysAdded() {...}

    public Object[] getKeysRemoved() {...}

8. Convenience Implementations

The package contains a handful of convenience implementations of interfaces also declared in

8.1. The URLFactoryLink Class

URLFactoryLink is an implementation of the Link interface that produces a Jini ServiceItem that contains a URLFactory service and null references in the service id and attribute sets fields. Here are the public portions of URLFactoryLink:


import net.jini.core.lookup.ServiceItem;
import net.jini.core.lookup.ServiceID;
import net.jini.core.entry.Entry;

public final class URLFactoryLink implements Link {

    public URLFactoryLink(String url) throws MalformedURLException {...}

    public LinkActivation activate(ActivationClient al) {...}

The URLFactory Jini service interface has just one method, getURL(), which returns a Here's the URLFactory interface:



public final class URLFactory implements Serializable {

    public URLFactory(String url) throws MalformedURLException {...}

    public URL getURL() throws MalformedURLException {...}

URLFactory is used to wrap existing file-based resources, such as web pages. Instead of plug-ins that must be installed at the client by the user, a network-mobile service UI can automatically provide a user access to the file-based resource. If a URLFactory doesn't contain a suitable UI for a file with a MIME type, a client could conceivably pass a MIME type to a Jini service that returns a set of UIDescriptors describing UIs for that kind of MIME type.

8.2. The ServiceURLLink Class

Represents a URL-based link to a Jini service on the network. This class assumes that the MIME type of the resource refered to by the URL passed to the constructor is application/x-serviceui. The two kinds of URLs that will work initially are the http: and jini: Jini service URLs described later in this specification.

Here are the public portions of the ServiceURLLink class:


import net.jini.core.lookup.ServiceItem;
import net.jini.core.lookup.ServiceID;
import net.jini.core.entry.Entry;

public final class ServiceURLLink implements Link {

    public ServiceURLLink(String url) throws MalformedURLException {...}

    public LinkActivation activate(ActivationClient al) {...}


8.3. The PropertyFileResourceInfo Class

9. Jini Service URLs

Although Places are collections of Links, not URLs, for resources on the existing web to link into the web of objects, objects will need to be accessible via URLs.

9.1 HTTP: URLs

To enable Jini services and service UIs to be referenced via HTTP: URLs, the following MIME type is proposed: application/x-serviceui. (This could be application/x-jini, if Sun were to agree. Another possibility is application/x-service.) A file delivered via this MIME type should be a serialized java.rmi.MarshalledObject, that contains a marshalled net.jini.core.lookup.ServiceItem.

An HTTP server could product the file in any way. A servlet could, for example, do a lookup in a Jini lookup service, marshal the resulting ServiceItem, serialize the marshalled object, and return it to the client. Alternatively, an HTTP service could just grab a file that already contains a serialized marshalled ServiceItem, and return that file. This specification recommends using .serviceui (this could be .jini, if Sun were to agree. Another possibility is .service.) as the standard extension for such files.

9.2 JINI: URLs

The jini: URL as currently defined identifies a Jini lookup service. The host name or IP address specifies the host on which the lookup service is running, such as:

If no port number is given, as shown in the previous examples, the default port number for Jini services, 4160, is implied. As with all URLs, if you need to address a lookup service at a different port besides the default, you can specify the port explicitly, as in:
Although URLs often have a fourth component after the protocol, host, and port number, jini: no fourth component is currently defined for jini: URLs. This specification proposes that the Jini Community define that fourth component to mean a Jini service that is registered within the Jini lookup service identified by the host and port number of the URL.

A Jini service can be uniquely identified inside a lookup service is by its service ID. This specification proposes that the jini: protocol indicate a service ID of a Jini service registered at the indicated host and port. For example:


To locate a service referenced by a jini: URL with a fourth component, the Jini client that is handed the URL first checks to see if it already has a ServiceRegistrar for the lookup service identified by the host and port number specified in the URL. If not, the client attempts to perform unicast discovery on that lookup service. If successful, the client instantiates a net.jini.core.lookup.ServiceID of the same value represented in the file portion of the URL. The client places this ServiceID in the serviceID field of a ServiceTemplate, and makes a lookup() query. If no service matches the query, then the service identified by the URL is not available. Otherwise, the matching service is selected and returned.

10. Spidering a Web of Objects

The Jini lookup service is designed to help software, not users, find network-delivered services. Nowadays, when users are looking for a network-delivered service, they go to search engines. Many search engine databases are constructed by autonomous robots, which "spider" the web. A spider visits a page, places information about that page into its search engine database, then follows links from that page to other pages.

Once Jini services and service UIs begin to participate in the web, users will want to be able to find them via search engines. The Place API includes a new entry that contains information for search engine spiders. Instances of class can be placed in the attribute sets of a Jini service item. (SpiderFodder means "food for spiders.") When a spider retrieves a Jini service, it can look for SpiderFodder entries, extract information from them, and place the information in its search engine database. If the service is a Place, the spider can follow the Links contained in the Place to discover still more resources, some of which may be more Jini services.

Here's the SpiderFodder class:


import net.jini.entry.AbstractEntry;

* A bundle of information that search engines spiders can
* use to record information about this service in their database.
public class SpiderFodder extends AbstractEntry {

    * ResourceInfo object that provides localized name, description,
    * and icons for this service, suitable for presenting to users.
    public ResourceInfo resourceInfo;

    * KeywordInfo object that provides localized keywords,
    * suitable for presenting to users, with which search engine spiders may
    * wish to use when recording information about this service in their
    * database.
    public KeywordInfo keywordInfo;

    * Constructs a SpiderFodder with all fields set to null.
    public SpiderFodder() {

    * Constructs a SpiderFodder with fields set to passed values.
    public SpiderFodder(ResourceInfo resourceInfo, KeywordInfo keywordInfo) {

        this.resourceInfo = resourceInfo;
        this.keywordInfo = keywordInfo;

The KeywordInfo object allows Jini services to offer a list of keywords that search engine spiders can use when entering information about the service in their database. The keywords are intended to serve the same purpose as the keywords that appear in the keywords META tag in HTML files. Here's the KeywordInfo interface:


import java.util.Locale;

public interface KeywordInfo extends Serializable {

    String[] getKeywords();

    String[] getKeywords(Locale locale);

11. The Service Presenter

Class ServicePresenter contains a static method that allows Place service UIs to request that the service host present a service to the user.

Because the passed Link is activated by the host, the host can give the user feedback about the activation progress in a uniform way. The host can, for example, show an animation, status messages, progress bar, etc., during the activation of the Link. The host can provide this feedback in the same manner for every link activation, yielding a more uniform experience for the user.

The presentService() method can wrap its activate() method invocation on any URLFactoryLinks and ServiceURLLinks in a doPrivileged() invocation, so that those trusted Link implementations can make socket connections, create class loaders, etc. Untrusted code that invokes presentService() won't get a reference to the resulting service item, but the user will be able to interact with the service via a service UI. If untrusted code invokes activate() directly on a ServiceURLLink() or URLFactoryLink, it may get a security exception.

Because a URLFactoryLink always returns a ServiceItem that contains no attribute sets, no UIDescriptors will be available. If the presentService() method can get a MIME type from the URL, however, the method can go look up a batch of UIDescriptors given the MIME type. It can have its own repertiore of UIDescriptors, and can also possible consult a "UI descriptor service" over the network. This UI descriptor service is kind of like Netscape Navigator giving you information about potential plug-ins that will let you view some content, but in this case the information about each service UI "plug-in" is encapsulated in a UIDescriptor, a form that will allow the client code to decide on a UI and seamlessly "install" it. Thus, besides granting users access to the space of Jini services on the network, this architecture attempts to give users a more seamless experience when using web resources than is possible with existing web browsers.


import java.rmi.RemoteException;

public class ServicePresenter {

    public static void presentService(Link link) throws RemoteException {...}
ServiceUI is a trademark of Artima Software, Inc.

Sponsored Links

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us