Summary
In this document I describe the architecture of a simple Place service that was used during the Cyberspace demo at the most recent Jini Community meeting.

In the Cyberspace demo, I showed five Place services whose service UIs presented links as named icons. All five of those Place services were instantiations of the same class, BasicPlace. (Note that the GUI frame with icons did not implement Place. The GUI was a service UI. The object that implemented Place was the service object itself, not the service UI.) Here's a screenshot of the service UI for the Artima home place:

The BasicPlace Class

BasicPlace is a concrete class that implements Place. Place is a Jini service interface that contains one method, getLinkMap(), which returns a LinkMap. BasicPlace's constructor merely accepts a LinkMap and uses it to initialize an instance variable named links. When BasicPlace's getLinkMap() method is invoked, it simply returns the links reference. Here's a UML diagram for BasicPlace:

The BasicLinkMap Class

All of the LinkMaps used in the Cyberspace demo were instances of class BasicLinkMap, a concrete class that implements LinkMap. BasicLinkMap's constructor accepts a java.util.Map and uses it to initialize an instance variable named map. The Map passed to the constructor must contain all the Links contained in the Place. This entire bundle of Links, therefore, is sent across the network along with the BasicPlace. (Note that all of LinkMap's methods declare RemoteException in their throws clause, so that LinkMap implementations have the option of going out on the network to retrieve requested Links. BasicLinkMap, however, will never go out on the network to retrieve Links, because all its Links are contained in its internal Map.) Here's a UML diagram for BasicLinkMap:

A HashMap of Links

In the demo, the class files for BasicPlace and BasicLinkMap, which are members of the com.artima.cyberspace package, were sent across the network in the service's JAR file. Place and LinkMap, members of net.artima.place (the main package of the Jini Place API), were already residing on the client. The BasicPlace object contained a reference to a BasicLinkMap, which contained a reference to an HashMap. The HashMap contains all the Links associated with String keys. Here's a UML diagram showing the relationship of the BasicPlace, BasicLinkMap, and HashMap objects:

The URLLink Class

Each Link that appeared in the Cyberspace demo was an instance of URLLink. (Given that URLLink is part of the Place API, URLLink.class was not sent across the network in the Place service's JAR file. Rather, URLLink.class was already sitting on the client, as part of the client's installation of the Place API.) URLLink's constructor accepts a String URL and a ResourceInfo, and uses them to initialize instance variables url and info. URLLink's getResourceInfo() method simply returns info. When the URLLink's activate() method is invoked, it passes url to the launchResource() method (declared in interface ResourceLauncher) method of the service context object. Here's a UML diagram for URLLink:

The ConcretePropertyFileResourceInfo Class

All of the ResourceInfo objects used in the Cyberspace demo were instances of ConcretePropertyFileResourceInfo. The ResourceInfo interface provides methods that enable clients to get information about a resource represented by a Link. PropertyFileResourceInfo, a member of the Place API, enables resource information to be read in from a property file. The PropertyFileResourceInfo's constructor accepts a String base name of the property file, and an array of supported Locales. It uses these parameters to initialize instance variables baseName and supportedLocales.

PropertyFileResourceInfo is an abstract class with one abstract method, getClassLoader(). Because PropertyFileResourceInfo is part of the Place API, it will be loaded by a different class loader than the JAR file for a network mobile Place service such as BasicPlace. But the actual property files will by necesity be inside the network mobile JAR file. The getClassLoader() template method enables PropertyFileResourceInfo to get a reference to the class loader that loaded ConcretePropertyFileResourceInfo, a concrete subclass of PropertyFileResourceInfo, which happens to travel across the network in the Place service's JAR file along with the property files. PropertyFileResourceInfo attempts to load the property file named in baseName from the class loader returned from getClassLoader(). Here's a UML diagram for ConcretePropertyFileResourceInfo:

A Link and its ResourceInfo

Each BasicPlace service that appeared in the Cyberspace demo contained a BasicLinkMap, which contained a HashMap that mapped String keys to URLLink values. Each URLLink contained a reference to a String URL and a reference to a ConcretePropertyFileResourceInfo object. Here's a UML diagram showing the relationship of URLLinks to ConcretePropertyFileResourceInfos:

Discussion Forum

To discuss the ideas presented in this article please post to the cyberspace@jini.org mailing list, or visit:

http://www.artima.com/jini/jf/cyberspace/index.html

For a more in-depth explanation of the cyberspace project, please see the A Walk Through Cyberspace article.