JINI & J2ME
Imagine using your J2ME device to participate in a complicated online game
– or a simple one, for that matter. You log in to a network where network
services are elements of the game. You, as a player in a massive online world,
are represented as an object, a peer of all the other game elements.
Your player object becomes the client of a map service, a service that
allows you to explore and move around while delivering necessary display
information. Your object discovers and uses other services as needed, without
prior knowledge of many of them. You meet a creature you’ve never encountered
before – is it a computer-controlled character or another player?
The criteria for finding game elements can actually be tied to real-time
game play. You may have access only to services with a notion of proximity
to your object; maybe the map service is really a group of services representing
multiple locales. As you move from location to location, you meet different
people and find different items. All this interaction occurs with your player
object, an object that is really your interface to this world, an object
you control from your J2ME device. Unfortunately, a billing service finds
you, recognizes that you’re now playing, and starts to charge you accordingly.
Jini is an ideal platform for hosting games for J2ME devices. But what
does “hosting games” mean? Jini is a technology concerned with network services:
how services interact on a network, how they discover other services, how
they handle failures, and how an ever-changing network topology is best managed.
Why not view mobile devices as extensions of the network, part of a group
of services that together perform the functions necessary for a game?
This article introduces the Jini surrogate architecture, along with
J2ME devices, as a viable platform for games. I’ll discuss the basic concepts
in the hope of provoking thought on further possibilities. In addition, I’ll
show how to get Sun’s reference implementation, Madison, up and running.
Perception is everything When Jini was introduced, it was perceived
as a technology for connecting devices to a network. This proved difficult
to implement, however, as the footprint Jini required was, and still is,
rather large. To address this, a project was started at www.jini.org
to develop a “surrogate” architecture to incorporate smaller devices. This
architecture is what I propose as a platform for J2ME games.
What Is the Surrogate Architecture?
The surrogate project defines architecture that allows devices that
normally wouldn’t be able to participate in a Jini network to do so. This
is done by bridging the device and its environment with one capable of interacting
with the Jini network. To do this, an object (or surrogate) is created to
act on behalf of the device. A device finds a surrogate host in its “native”
network environment and registers with it, providing the surrogate host with
either a JAR file or the location of a JAR file. The surrogate host instantiates
a surrogate object, which is obtained from the JAR file. The surrogate object
becomes the device’s representative on the Jini network. Communication now happens separately from the surrogate host, as the surrogate
object and the device are now responsible for their own communication.
The general architecture can be logically broken down into its components:
a surrogate host and a connector specification. The former provides a context
for the surrogate object, including an export service for distributable code,
and the necessary lookup and discovery management for the Jini network. The
connector specification is responsible for defining how the device discovers
and registers with the host. Finally, the device and surrogate object communicate
in a manner that may not be related at all to the connector used to register
the device.
What a Surrogate Brings to the Table
There are several compelling reasons to use the surrogate architecture
as a platform for J2ME games. One is that the architecture simplifies device
management. The device presents itself to the Jini network through a reference
to a surrogate object codebase. The capabilities of the device don’t need
to be determined by a back-end server; rather, they are defined within the
surrogate object code itself. A present surrogate might be programmed for
the Connected Limited Device Configuration. In the future, as different CDC devices become available, a
surrogate specific to them can be programmed. These new surrogates join the
network, just like the others, with their own inherent capabilities. The
services already on the network don’t need to know about the new device.
Wireless connections aren’t noted for their stability. With surrogate
architecture, if connections come and go, the surrogate object can remain
active, maintaining information regarding the current session and playing
an active role on behalf of the device in the Jini network. When the device
reconnects, the channel to the surrogate object can be reestablished. Often
this can be done invisibly to the device users; they may never know they
were disconnected.
Resource handling becomes easier through the use of built-in Jini features
such as leasing. The surrogate object and device are responsible for maintaining
a keep-alive for their connection. Should the device lose the connection
altogether and not reconnect, the surrogate can clean itself up after a certain
amount of time. In addition, the surrogate object may register itself with
one or more lookup services (an LUS provides the functionality to discover
and register services). This is a leased registration, and is therefore self-cleaning.
Mobile Devices as Unique Objects
Mobile devices are viewed as unique objects by the Jini network. Just
as layers of complexity are added to the device’s client software, layers
can be added to the surrogate object (through interfaces, for example). This
means that a game system can view the surrogate object as a player with various
properties. One such property might be “I want to play chess.” Another Jini
service on the network might connect players based on the games they want
to play.
Having devices as unique objects in the Jini network allows a richer
set of interaction semantics. In a portal model, device login and registration
may appear the same from the device’s point of view, but the other services
view the portal, not the individual objects. This places the responsibility
for initiating service interaction on the portal. In the surrogate architecture
model, other services can initiate interaction on many levels: to an individual
surrogate object, to a group of surrogate objects meeting some criteria (interfaces
implemented, or any other attribute), or simply as the entire group of surrogate
objects.
You might have an adventure game with a “universe” service. This service
might represent the map or playing field for the game and may wish to find
players based on a virtual locale. The locale of the player could be kept
within the surrogate object’s Jini registration criteria.
Getting Started
Before we start, if you haven’t already done so, you’ll need to download
and install Jini and the Madison project. Jini can be downloaded from www.sun.com/jini/; Madison can be found at
http://developer.jini.org/exchange/projects/surrogate/IP/
. A free membership at the Jini.org site is required for downloading.
Here are the parameters that should be set in “ENVIRONMENT.bat”:
set JAVAHOME=E:\jdk1.3\bin
set JINIHOME=E:\jini1_1
set MADISONHOME=E:\jini_surr_madi son1_0
set GROUP=the2bears
set HOST=frodo
set JPORT=8080
set MPORT=8083
First Jini…
Before starting Madison we need to have a basic Jini network running.
I won’t go into Jini in depth, as it’s beyond the scope of this article;
in addition, there are many good tutorials and books out there.
We’ll need three basic things to start: the rmid activation server,
an HTTP server for serving classes, and an LUS. A fourth application, an
LUS browser, will be started to give us a visual feedback of what is happening
in our Jini network.
The LUS requires an RMI activation daemon. Start this using the following,
which may be in a batch file:
call ENVIRONMENT.bat
%JAVAHOME%\rmid -J-Djava.security.policy=%MADISONHOME%\policy\policy.all
-J-Dsun.rmi.activation.execPolicy=none -log .\rmid
An HTTP server is also necessary because we’ll be downloading code to
different clients in our Jini network. Jini is a specification, and we’ll
use Sun’s reference implementation. It’s reasonable for a client of an LUS
to know the interface, but not necessarily the implementation. With an HTTP
server downloading classes, the client of a service can get the classes it
needs. Start the HTTP server with:
call ENVIRONMENT.bat
%JAVAHOME%\java -cp %JINIHOME%\lib\tools.jar com.sun.jini.tool.ClassServer
-port %JPORT% -dir %JINIHOME%\lib -trees -verbose
The LUS – in our case Sun’s “Reggie” – is the bootstrap service for
a Jini network. All other services need somewhere to register their proxies
and to find the proxies for other services. An LUS starts up and registers
its proxy with itself. Start the LUS with the following:
call ENVIRONMENT.bat
%JAVAHOME%\java -jar %JINIHOME%\lib\reggie.jar http://%HOST%:%JPORT%/reggie-dl.jar
%MADISONHOME%\policy\policy.all .\reggie %GROUP%
The LUS browser provides a simple interface that allows us to select
the service registrar we wish to view and the services registered with that
registrar. Upon starting the browser, you may notice that the HTTP server
(if started in “verbose” mode) logs a request for the reggie-dl.jar file.
This is the code necessary for the proxy to the service registrar. The LUS
browser can be started with:
call ENVIRONMENT.bat
%JAVAHOME%\java -cp %JINIHOME%\lib\jini-examples.jar -Djava.security.policy=%MADISONHOME%\
policy\policy.all -Djava.rmi.server.codebase=http://%HOST%:%JPORT%/jini-examples-dl.jar
com.sun.jini.example.browser.Browser -admin
Note that the order in which the files are executed is important. Each
of these files references the file ENVIRONMENT.bat, which must be edited
to reflect your system.
…Then Madison
Madison includes three pieces for us to start: Madison itself (the surrogate
host), a simulated device that implements the IPConnector protocol, and a
test client for the device. Properties for Madison are set in the file “mad-
ison.prop” (see Listing 1), which is included in the Madison download.
Madison doesn’t register as a Jini service upon startup, but it requires
the Jini network to be running. However, part of its responsibility is to
provide a context for surrogate objects so they can perform Jini lookup and
discovery. In addition, Madison provides an export service that a surrogate
object registering in an LUS must use for its code to be downloadable within
the Jini network. Finally, Madison starts the IPConnector protocol. Start
Madison with this script:
call ENVIRONMENT.bat
%JAVAHOME%\java -Djava.security.policy=%MADISONHOME%\policy\policy.all
-jar %MADISONHOME%\lib\madison-boot.jar -prop %MADISONHOME%\bin\madison.prop
The device simulator included in the Madison project is actually a small
application that makes it easy to test surrogate objects. In the simulated-device.prop
file (see Listing 2) we have specified a surrogate object to register. The
device simulator discovers Madison and registers the surrogate object using
the IPConnector. If registration is successful, the surrogate object will
now appear in the LUS. The surrogate object will register itself with the
LUS, so its code must be downloadable. We’ll use a second HTTP server for
this. Start the device simulator and the second HTTP server with these two
scripts:
call ENVIRONMENT.bat
%JAVAHOME%\java -cp %JINIHOME%\lib\tools.jar com.sun.jini.tool.ClassServer
-port %MPORT% -dir %MADISONHOME%\lib -trees -verbose
and
call ENVIRONMENT.bat
%JAVAHOME%\java -jar %MADISONHOME%\lib\madison-device.jar -prop simulated-device.prop
Finally, we start a test client for the device. The test client, upon
startup, obtains a reference to the first surrogate and allows us to make
a remote call against the surrogate’s proxy – in this case obtaining the
description. Start the client for the device:
call ENVIRONMENT.bat
%JAVAHOME%\java -Djava.security.policy=%MADISONHOME%\policy\policy.all
-Dcom.sun.jini.madison.debug=true -Djava.rmi.server.codebase=http://%HOST%:%MPORT%/madison-client-dl.jar
-jar %MADISONHOME%\lib\madison-client.jar -groups %GROUP%
The files for starting Madison are:
• lstartMadison.bat
• lstartDeviceWebServer.bat
• lstartDevice.bat
• lstartDeviceClient.bat
Two additional files must be edited: madison.prop and simulateddevice
.prop. Specifically, there are classpath properties and codebase URL properties
that must reflect your system.
Future Path
The system as we now have it consists of a surrogate host running, with
an IPConnector announcing and listening for registrations. A device simulator
sees the host’s announcement and registers a surrogate with it. This surrogate,
using the context provided by the host, is able to register itself with the
Jini network, and clients of the surrogate can invoke remote methods.
So far, though, we haven’t connected a mobile device to the Jini network.
Since our goal is to use J2ME devices with a Jini network for games, we’ll
need to define a connector to the surrogate host that they can use. Once
we accomplish this, we have an effective framework for device-to-surrogate
communication and we can start to build a game on top of this.
Author Bio
William Swaney, a software developer specializing in distributed computing, works for Valaran Corp., where he experiments with mobile devices
and Jini networks.
william.swaney@valaran.com
Listing 1: madison.prop
com.sun.jini.madison.commonCLPath=/E:/jini1_1/lib/jini-
core.jar;/E:/jini1_1/lib/jini-ext.jar;/E:/jini_surr_madison1_0
/lib/surrogate.jar;/E:/jini_surr_madison1_0/lib/IPinterconnect.jar
com.sun.jini.madison.hostCLPath=/E:/jini1_1/lib/
sun-util.jar;/E:/jini_surr_madison1_0/lib/madison-impl.jar
com.sun.jini.madison.DiscoveryManagement.groups=the2bears
Listing 2: simulated-device.prop
com.sun.jini.madison.debug=true
surrogate.0=http://frodo:8083/madison-surrogate.jar
description.0=First Surrogate (Surrogate 0)
