HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

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.

[email protected]

	



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)

  
 

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.