Sponsored Link •
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,
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
Here's a graphical depiction of the Cyberspace Protocol as implemented in the demo:
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
and serialized the marshalled
ServiceItem into a file. I give the file a
extension and place it on artima.com.
To run a
.serviceui file on the client during the demo, I start a
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
ObjectLauncher application that serves as a host to the Jini
service and service UI. When the
ObjectLauncher unmarshals the marshalled
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
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
file bytes to the
CyberspaceConsole, which fires them up in an
Placeservices that are installed at artima.com. As mentioned previously, a
Placeservice is a collection of links to resources on the network. Each resource is represented by a
Linkobject. 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
Linkobject contained in the place. If you click on an icon, the
Placeservice activates the corresponding
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:
ColorSchemeris also a
Placeservice, because its service object implements the
Placeinterface. If you click on the
Colorsitem 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
ColorSchemerservice UI activates the corresponding
Linkin 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:
As I described in my
A Walk Through Cyberspace article, the basic goal of the
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.)
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
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
has one method,
getLinkMap(), which returns a
LinkMap object. The
LinkMap is a map (but not a
Link object represents a link to some resource on the
Link is not just a wrapper for a
URL however (otherwise I could probably have
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
across the network to the client, just as you can send a URL across the network. But in the case of a
you are not sending data across the network, you are sending behavior.
To follow a
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
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
to get a resource for you: (1) the
activate() method and (2) a resource factory.
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
passes a URL to the
runResourceWithUI() method of
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
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
Link code will likely be allowed to open a socket connection back to that host to
retrieve the resource directly, without going through
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
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
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
that represents the resource. The three interfaces I currently have defined in
allow client code to get a Jini service object (
ServiceFactory), a Jini service item
ServiceItemFactory), or a file via an input stream (
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
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
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
Other pieces that I believe we need to flesh out include the following items:
application/x-serviceui, which I used in the demo)
RMIClassLoaderto be more efficient about downloading Jini services across the internet, or come up with some alternative to
RMIClassLoaderthat is more efficient. The efficiencies that I think we should aim for include:
Cacheservice interface, and think about how JAR files and marshalled service items can be cached securely.
Permissionclasses, that represent permission for a client to actually get a resource via a resource factory.
activate()to find out whether or not the link was successfully activated. Then, we need to figure out just how many different kinds of
activate()there should be. I.e., should there be an activate with a timeout? Should there be an activate with an asynchronous callback?
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.
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.
To discuss the ideas presented in this article please post to the firstname.lastname@example.org mailing list, or visit:
For a more in-depth explanation of the cyberspace project, please see the A Walk Through Cyberspace article.