|
|
|
|
Sponsored Link •
|
|
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.
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:
.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 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:
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:
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.)
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.
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.
Other pieces that I believe we need to flesh out include the following items:
application/x-serviceui, which I used in the demo)
RMIClassLoader to be more efficient about downloading
Jini services across the internet, or come up with some alternative to RMIClassLoader
that is more efficient. The efficiencies that I think we should aim for include:
Cache service interface, and think about how JAR files
and marshalled service items can be cached securely.
RMIClassLoader does.
Permission classes, 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.
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.
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.
|
Sponsored Links
|