The Artima Developer Community
Sponsored Link

First Steps in Cyberspace
A Cyberspace Demo
By Bill Venners

Advertisement

Summary
In this document I give a brief description of the Cyberspace demo I gave at the Jini Community Meeting on Monday, June 5, 2000. I also provide links to JavaDoc documentation for the code, as well as some description of the API. Lastly, I give some hints at where I'd like the Cyberspace project to go.


In my Jiniology article, A Walk Through Cyberspace, I described a "Place" service - collection of links to resources on the network that establish create a space metaphor for the web. At the Jini Community meeting on Monday, June 5, 2000 in San Fransisco, I gave a demo of some Place services in action.

During the demo, I showed Jini services and service UIs being delivered via HTTP. In other words, rather than grabbing Jini services and service UIs from a Jini lookup service, I grabbed them from a web server. With a web server running locally on my laptop, a new MIME type (application/x-serviceui), and a new browser plug-in, I'll showed how Jini services could be integrated with the World Wide Web. During my demo, I clicked on a link in a web page and, Poof!, up popped a Jini service and service UI.

During the demo I showed how Jini services could be integrated with artima.com using a local copy of the artima.com web site. I didn't use a live connection to the internet. But everything I showed also works across the internet from artima.com, where I installed seven Jini services with service UIs: five "place" services, a calculator service, and the Artima ColorSchemer service. (I give screen shots of each of these services later in this article.) Here are links to each of the seven services installed at artima.com. You won't be able to run them without the Cyberspace plug-in, but if you click on the links, you'll see they are served up with the MIME type, application/x-serviceui.

The Cyberspace Protocol

In my A Walk Through Cyberspace article, I suggested we needed a Jini Name server and a "cyberspace protocol" that defines a standard way to request Jini services and service UIs from the Jini name server. In the time since I wrote that article last fall, I downloaded and read much of the HTTP specification, and realized that the cyberspace protocol could simply be composed of HTTP, one or more new MIME types, and the meanings of those MIME types. In recent months, Jan Newmarch posted to JINI-USERS that we define a MIME type for Jini services as: application/x-jini. One of the goals of the Cyberspace project will be to propose what the MIME type or types should be called and what those MIME types will mean. Given that "Jini" is a trademark, I didn't use "Jini" in the MIME type I enabled on artima.com. Instead, I just used: application/x-serviceui.

Here's a graphical depiction of the Cyberspace Protocol as implemented in the demo:

The Cyberspace Protocol

Running .serviceui Files

To create a .serviceui file for a Jini service, I first place two JAR files on artima.com: one JAR file containing the class files for the service object and one JAR file containing the class files for the service UI and its UI factory. I then run a Java application that instantiates the factory for the service UI using a class loaded from the service UI JAR file that I placed at artima.com. The application then instantiates the Jini service object itself, using a class loaded from the service object JAR file from artima.com. I marshal the UI factory and place the marshalled factory in a UIDescriptor. I place the UIDescriptor and service object into a ServiceItem, marshal the ServiceItem, and serialized the marshalled ServiceItem into a file. I give the file a .serviceui extension and place it on artima.com.

To run a .serviceui file on the client during the demo, I start a CyberspaceConsole application, which will launch each service and service UI into its own VM. When the console receives instructions to launch an Jini service, either by being passed a URL or the actual bytes of a .serviceui file, it System.exec's an ObjectLauncher application that serves as a host to the Jini service and service UI. When the ObjectLauncher unmarshals the marshalled ServiceItem, the RMIClassLoader retrieves the service object JAR files from artima.com. The ObjectLauncher then selects a best fit UI using the process defined in the Jini Service UI specification. When it unmarshals the factory for the chosen UI, the RMIClassLoader retrieves the service UI JAR file from artima.com.

To enable Jini services to be launched from web browsers, I configured the artima.com web server so that any requested files that have the extension .serviceui extension will be delivered across the network with the MIME type application/x-serviceui. When the browser sees the application/x-serviceui MIME type, it looks for a plug in that can handle the MIME type, and finds the Cyberspace Plug-In. The browser creates an new instance of the Cyberspace Plug-In, and passes the bytes of the .serviceui to the plug-in. The plug-in merely passes those .serviceui file bytes to the CyberspaceConsole, which fires them up in an ObjectLauncher.

Place Services

During the demo, I showed five basic Place services that are installed at artima.com. As mentioned previously, a Place service is a collection of links to resources on the network. Each resource is represented by a Link object. The service UI for the five place service in the demo looks vaguely reminiscent of the Macintosh Finder: named icons upon which you can click. Each icon represents a a Link object contained in the place. If you click on an icon, the Place service activates the corresponding Link (by invoking runServiceWithUI on the Link). In the demo, each link contains a URL of either a web page or a Jini service also at artima.com. When you click on an icon, you'll either get a web page or a Jini service. Here are screen shots of the five place services at artima.com:

Artima.com - A Resource for Java and Jini Developers

Jini Corner at Artima.com

Java Corner at Artima.com

Object Design Corner at Artima.com

JVM Corner at Artima.com

Calculator and ColorSchemer

During the demo I also showed two other Jini services that are installed at artima.com: a calculator and the Artima ColorSchemer. I pointed out that the ColorSchemer is also a Place service, because its service object implements the Place interface. If you click on the Colors item of the ColorSchemer's menu, you'll get a list of 12 menu items, one for each of 12 color tables available as web pages on artima.com. When you select a menu item, the ColorSchemer service UI activates the corresponding Link in the service object, and the web page containing the requested color table pops up in a browser window.

Here are screenshots of those two services:

Artima Calculator

Artima ColorSchemer

As I described in my A Walk Through Cyberspace article, the basic goal of the Place API will be to create a space metaphor for the network. Currently the dominant user interface metaphor for the network is that of a massive hypertext document. To do something on the network currently, you go to a page and interact with the page. The Place API propose a new metaphor that subsumes the old: to do something on the network, you go to a place and use an object. This metaphor subsumes the old metaphor (the web), because web pages become a special kind of document object in cyberspace.

Due to time constraints, I was unable provide more details in this article before the demo. I'll continue to flesh this article out over time, and will notify JINI-USERS and the cyberspace mailing list when I'm done.

Please feel free to browse the JavaDoc Documentation for the Place API I used in the demo. In addition, I've posted JavaDoc documentation for the implementation classes I used in the demo. (Actually, I updated these JavaDoc files on July 27, 2000, with my latest and greatest version, which the latest incarnation of the cyberspace demo uses.)

A Web of Objects

To help you understand what I'm trying to get at with the Place API, I think it is useful to compare cyberspace to the existing web. The typical web page (such as this very web page) offers two basic services: (1) an information service, and (2) a collection of links service. What makes a web page a page is that it offers an information service, much like a page of a book or page of a magazine. What makes a web page a web page, as opposed to some other kind of page, however, is that a web page also provides a collection of links to relevant resources.

A Jini service object represents an alternative way to deliver a service across the network compared to a web page. My current mini-series of Jiniology articles compares the advantages and disadvantages objects versus documents. (See Object versus Document: Part I.) One of the nice things about the service object is that is is very generic. All the Jini specifications say about the Jini service object is that is some subclass of java.lang.Object that implements java.io.Serializable. That's it. So a Jini service object is simply a network mobile object. It can be anything, so long as its Serializable. What I want to do with the cyberspace project is enable these network mobile objects to link to each other and to other resources on the network (such as legacy web pages), much like web pages link to each other currently. So, for example, a Jini Blender service object could offer a Blender service and a collection of links service.

The main purpose of the Place API, therefore, is to establish a standard interface that allows any service object to offer links to other resources on the network. Interface Place has one method, getLinkMap(), which returns a LinkMap object. The LinkMap is a map (but not a java.util.Map) of Object keys to Links. Each Link object represents a link to some resource on the network.

The Purpose of Link

A Link is not just a wrapper for a URL however (otherwise I could probably have used java.net.URL.) A Link is a deliberate attempt to raise the level of abstraction of a URL. 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, the client asks the Link to get the resource on the client's behalf. 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.

So you ask a Link to get a resource for you. The Link can to anything it wants (so long as it is allowed by the local security policy) to retrieve the resource. There are two ways to ask a Link to get a resource for you: (1) the activate() method and (2) a resource factory.

The activate() method is intended to be used when the Link is being activated on behalf of a user. Thus, the process of activating the link should produce some kind of new UI that allows the user to interact with the resource. In my cyberspace demo, every Link is actually a URLLink, whose activate() method passes a URL to the runResourceWithUI() method of PlaceContext. The PlaceContext method is something that already exists on the client side, which is able to open a socket connection to anywhere to retrieve a resource. Each Jini service and service UI that it retrieves (such as all the services whose screen shots are shown earlier in this article), are placed into a different virtual machine. So the Place service in which the Link was activated can't interact at all with the retrieved resource.

If the resource being retrieved is sitting on the same host from which the Place came, then the Link code will likely be allowed to open a socket connection back to that host to retrieve the resource directly, without going through PlaceContext. This allows a Link to retrieve and run a Jini service and service UI in the same virtual machine. By grabbing services and running them all in the same virtual machine, those services can be tightly integrated. An example of this that I'd like to prepare for a future demo is a Place that looks like a floating toolbar for an office suite, where each button activates a Link that goes back to the same host and grabs a word processor, spreadsheet, calendar service, etc.. All those services in the same office suite would run in the same virtual machine, which would allow the word processor, spreadsheet, and calendar to know about and interact with each other on the client side.

The resource factory mechanism, by contrast, is intended to allow software to follow links in the absence of a user. The client code (such as a search engine robot), would invoke getResourceFactory() to get a resource factory object. That resource factory would implement one or more interfaces, such as the interfaces defined in the net.artima.place.factory package. The client can figure out what interfaces the object implements by using instanceof or reflection on the factory object. It can cast the factory to one of those interfaces and then invoke a factory method to get an Object that represents the resource. The three interfaces I currently have defined in net.artima.place.factory allow client code to get a Jini service object (ServiceFactory), a Jini service item (ServiceItemFactory), or a file via an input stream (InputStreamFactory).

One last comment about Link that I'd like to make is that Links 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. You could, for example, allow a user to activate a link to a nearby restaurant recommendation service. The Link could discovers nearby lookup services and selects some service that implements the well-known RestaurantRecommender interface, select a UI and show it to the user. The user could then select and get directions to some nearby restaurant where he or she could fill his or her tummy with delicious, affordable viddles. One of the goals I have for Link is to provide an abstraction that regular non-computer-savvy individuals can understand that enables those users to enjoy the benefits of using the ServiceRegistrar interface.

On the Drawing Board

Other pieces that I believe we need to flesh out include the following items:

All these things are just ideas in their initial stages. They need to be thought about, tried out, and scrutinized heavily by security experts. But to get Jini services to be practical across the internet, we really need to make download as efficient as possible.

Selling Cyberspace

Once a Place API has been defined, what I would imagine we'll want to do is create some kind of free product (for various platforms) that includes a browser plug-in, that enable people with web sites to start adding Jini services and service UIs to their web sites. This product should be smart about caching. I expect it to act a bit like Marimba Castinet or the Java Webstart plug-in, but instead of requiring users to subscribe to channels (as in Marimba Castinet) or install applications (as in Java Webstart), this product would allow users to access Jini services (which would be "cached" rather than installed). The advantage offered by this product is that because of the separation of functionality and UI inherent in the Service UI API, such services should be accessible from any kind of device that may come along in the future.

In addition, cyberspace could be used in the absence of a web browser. The reason there is a plug-in is not because you have to have a web browser to use Jini services, but because I think that's a great way to market cyberspace (or even Jini). The way Java was successfully marketed was by hooking it to the web via the Java applet. I think the same will hold true for Jini, because people are still very focused on the world wide web. But what this product would really represent is a stand-alone Jini client, that on desktops is integrated with a nearby web browser. On future cyberspace clients, such as cell phones or car dashboards, it may not make sense to also have a web browser around, because web pages don't travel well to those kinds of devices. And later, as Jini lookup services become commonplace, services could be pulled out of lookup services more and more in addition to being retrieved from web servers.

I don't want to go into the plug-in business, so I'm thinking that I'd like to make the free product that includes the plug-in some kind of open source project. I'm not quite sure yet how such an open source project would work out (what license to use, etc.), but that's what I'm picturing.

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.

ServiceUI is a trademark of Artima Software, Inc.

Sponsored Links



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