Make room for JavaSpaces, Part 3 - JavaWorld March
2000
Tutorial Details:
Make room for JavaSpaces, Part 3
Make room for JavaSpaces, Part 3
By: By Susanne Hupfer
Coordinate your Jini applications with JavaSpaces
he first article in this JavaSpaces thread presented an overview of the JavaSpaces programming model and its simple API. You'll recall that the model is based on spaces -- shared, network-accessible object storage and exchange areas -- through which processes communicate and synchronize their activities. Indeed, coordination is a crucial component of distributed programs, just as it is in any distributed activity.
Make room for JavaSpaces: Read the whole series!
Part 1. Ease the development of distributed apps with JavaSpaces
Part 2. Build a compute server with JavaSpaces
Part 3. Coordinate your Jini apps with JavaSpaces
Part 4. Explore Jini transactions with JavaSpaces
Part 5. Make your compute server robust and scalable
Consider cars speeding through an intersection, workers assembling a car, or athletes playing a basketball game: each of those real-world distributed systems requires coordination to function smoothly. So with distributed applications, the processes need to synchronize with one another to succeed at a common task. For example, distributed applications often need to mediate access to a limited set of shared resources, guarantee fair access to those resources, or prevent processes from terminating as they wait for resources that may never become available.
This month I'll show you how to use JavaSpaces to coordinate processes in a networked environment. At the same time, I'll start tying JavaSpaces and Jini closer together. If you've experimented with JavaSpaces, you already know that it is implemented on top of Jini. In fact, a new article, "The Nuts and Bolts of Compiling and Running JavaSpaces Programs" (see Resources ), can help you get your JavaSpaces programs up and running, which can be a frustrating task, given all the Jini machinery needed underneath. What may not be as clear is that JavaSpaces is a powerful tool for communication and coordination between a Jini federation's entities. In particular, space-based communication and coordination works well in the Jini networked environment, where entities may rapidly appear and disappear at will (or against their will, in the case of machine, software, or network failures).
In this article, I'll investigate how you can achieve some simple forms of distributed synchronization by using a space. To illustrate, I'll build a distributed multiplayer game, provided as a Jini service, that permits access by a limited number of players at a time. You'll see how to mediate players' access to the game through a space. Before diving into the game service, let's start by taking a quick look at an important concept that you'll use to build synchronization into your distributed programs: how the JavaSpaces API provides basic synchronization on entries for free.
Space operations and synchronization
Coordinating distributed processes can be hard work. In an application that runs on a single machine, the operating system, acting as a centralized manager, can synchronize multiple threads. But in a networked environment, a single point of control doesn't necessarily exist. Processes run on different machines and at their own pace. Unless you want to build a centralized controller to manage those processes, which would introduce an unwelcome bottleneck to the environment, you must build a distributed means of managing their interactions, which can be significantly trickier.
JavaSpaces can ease the synchronization of distributed processes because synchronization is built into the space operations themselves. Recall the basics of the JavaSpaces API: write deposits an object, called an entry, into a space; read makes a copy of an entry in a space (but leaves the object there); and take removes an entry from a space. Let's see how this simple API incorporates the basics of space-based synchronization. Suppose you define a simple Message entry like this:
public class Message implements Entry {
public String content;
public Message() {
}
}
Then you instantiate a Message entry and set its content:
Message msg = new Message();
msg.content = "Hello!";
Assuming you have access to a space object, you call its write method to place a copy of the entry into the space:
space.write(msg, null, Lease.FOREVER);
Now any process with access to the space can create a template and read the entry:
Message template = new Message();
Message result = (Message)space.read(template, null, Long.MAX_VALUE);
Any number of processes can read the entry in the space at a given time. But suppose a process wants to update the entry: the process must first remove the entry from the space, make the changes, and then write the modified entry back to the space:
Message result = (Message)space.take(template, null, Long.MAX_VALUE);
result.content = "Goodbye!";
space.write(result, null, Lease.FOREVER);
It's important to note that a process needs to obtain exclusive access to an entry that resides in the space before modifying it. If multiple processes are trying to update the same entry using this code, only one obtains the entry at a time. The others wait during the take operation until the entry has been written back to the space, and then one of the waiting processes takes the entry from the space while the others continue to wait.
The basics of space-based programming synchronization can be quickly summarized: Multiple processes can read an entry in a space at any time. But when a process wants to update an entry, it first has to remove it from the space and thereby gain sole access to it. In other words, the read , take , and write operations enforce coordinated access to entries. Entries and their operations give you everything you need to build more complex coordination schemes. With the basics under your belt, let's start building the game service.
A Jini game service
Consider a distributed multiplayer game, offered as a Jini service, that allows only a set number of players at a time. If the game is already at full capacity, a person wanting to play has to wait until an active player leaves. In its simplest form, given a pool of waiting players, the service admits an arbitrary player to the game; this is the approach I take in the example. But of course, in this scheme some players may wait forever while relative newcomers are allowed to play. If you want to be fair, you could make the waiting players queue up and have your service mediate admission to the game on a first-come, first-served basis. For now let's implement the simpler arbitrary-player approach, using a small amount of JavaSpaces code.
Here is the overview of my game service, depicted in Figure 1: The Jini game service supplies two basic methods, joinGame and leaveGame . When a player wishes to play, he or she looks up a game service provider in the standard Jini way, using a lookup server, and is delivered a proxy object to a game service. (I'm not going to cover the basics of Jini services, lookup, and discovery in this article, so if those concepts and terminology are unfamiliar to you, you may want to make a detour to Resources .) With the proxy in hand, the player calls joinGame to join a specific game. When joinGame succeeds in getting admission to the game (via JavaSpaces, as you'll see shortly), it returns an interface to a remote game object, which can be used to play the game. At this point, the player calls the play method of the game object (the game's only method in my simple example) to begin playing. When the play method returns, the player is finished playing and calls the proxy's leaveGame method. In my example, the player sleeps for a bit and then loops, calling joinGame to continue playing the game.
Figure 1. An overview of the game service example
From the command line, you can start a game service, specifying a name for the game and a maximum number of players. Then you can start as many players for that game as you want: if there are fewer players than the maximum, everyone gets to play at once, but if there are more players than the maximum, your game service will need to coordinate access to the game. You may want to download the full example code ( Resources ) to play with and examine. Let's take a closer look at how the pieces of the system are implemented and how to use JavaSpaces to coordinate them.
The player
Let's start by looking at the implementation of a player. Here is the basic skeleton of the player code, excluding some of the Jini lookup and discovery details (you can find the full code in Player.java from the code.zip file in Resources ):
public class Player implements Runnable {
protected String gameName;
protected String myName;
...
public Player(String gameName, String myName) throws IOException {
this.gameName = gameName;
this.myName = myName;
...
// create a template for locating a GameServiceInterface, set a
// security manager, & set up a listener for discovery events
// in the Jini public group
...
}
// This method is called whenever a new lookup service is found
protected void lookForService(ServiceRegistrar lookupService) {
...
// use a template to search for proxies that implement GameServiceInterface
...
GameServiceInterface gameInterface = (GameServiceInterface)proxy;
while (true) {
Game game = gameInterface.joinGame(gameName);
if (game != null) {
try {
System.out.println("Playing game " + gameName);
game.play(myName);
} catch (RemoteException e) {
e.printStackTrace();
}
gameInterface.leaveGame();
} else {
System.out.println("Couldn't obtain game " + gameName);
}
// sleep for 10 seconds before trying to join the game again
try {
Thread.sleep(10000);
} catch (Exception e) {
e.printStackTrace();
}
}
}
// Create a Player and start its thread
public static void main(String args[]) {
if (args.length < 2) {
System.out.println("Usage: Player gameName playerName");
S
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Make room for JavaSpaces, Part 3 - JavaWorld March
2000
View Tutorial: Make room for JavaSpaces, Part 3 - JavaWorld March
2000
Related
Tutorials:
 3D graphics programming in
Java, Part 3: OpenGL
3D graphics programming in
Java, Part 3: OpenGL
|
Java security evolution
and concepts, Part 5
Java security evolution
and concepts, Part 5
|
A birds-eye view of Web services
A birds-eye view of Web services
|
I want my AOP!, Part 3
I want my AOP!, Part 3
|
Create your own type 3 JDBC driver, Part 2
Create your own type 3 JDBC driver, Part 2
|
J2SE 1.4
breathes new life into the CORBA community, Part
3
J2SE 1.4
breathes new life into the CORBA community, Part
3
|
Effort on the
edge, Part 1
Effort on the
edge, Part 1
|
Get the inside
track on J2EE architect certification
Get the inside
track on J2EE architect certification
|
Servlet 2.4:
What's in store
Servlet 2.4:
What's in store
|
Develop state-of-the-art mobile
games
Develop state-of-the-art mobile
games
|
Finally, getting hands in !
Finally, getting hands in !
|
Fixing the Java Memory Model, Part 2
Writing concurrent code is hard to begin with; the language should not make it any harder. While the Java platform included support for threading from the outset, including a cross-platform memory model that was intended to provide \"Write Once, Run Anywh
|
JSP 2.0: The New Deal, Part 3
JSP 2.0: The New Deal, Part 3
More Flexible JSP Document Format Rules
The JSP specification supports two types of JSP pages: regular JSP pages containing any type of text or markup, and JSP Documents, which are well-formed XML documents; i.e., docum
|
Template-Based Code Generation with Apache Velocity, Part 2
Template-Based Code Generation with Apache Velocity, Part 2
As described in part one of this series, code generation typically uses a template engine to transform some kind of "model" into compilable code, given the formatting specified by a template.
|
Software Download Central
compatible.
GNU getopt - Java port
A while back I found myself in need of a Java command line option parser. Unsatisfied with free versions I was able to find on the net, I volunteered to port the GNU getopt family of functions from C to Java. The current release
|
Struts, JavaServer Faces, and Java Studio Creator:
The Evolution of Web Application Frameworks Sun Microsystems' Craig McClanahan, the creator of the Apache Struts Framework, co-specification lead for JavaServer Faces 1.0, and prime architect for Sun Java Studio Creator's new release, explains all three.
|
Buy Fedora Core 3 Test 1 Linux CD's in India.
Buy Fedora Core 3 Test 1 Linux CD's in India.
Fedora Core 3 Test 1 Linux
Fedora Core 3 Is Available
Now Available Fedora Core 3 Test 1CD's
We are providing the free downloadable version of Fedora Core 3 Test 1 Linux CDs, which is distributed
|
New Technical Articles: 64-bit Programming on Solaris 10 OS for x86 Platforms
Four technical articles describe the new Sun Studio 10 software's 64-bit programming features on the Solaris 10 OS for x86 and AMD64 platforms. Important issues regarding the AMD64 ABI (Application Binary Interface), debugging, migration to 64-bits, and p
|
Chat Transcript: Java Web Services Developer Pack (Java WSDP) 1.5
Learn about the exciting new web services features in the recently-released Java WSDP 1.5.
|
Solaris 10 OS Certification Beta Exams
If you are an expert in system and network administration, you can get involved in the creation of three new Solaris 10 certification exams. These Beta exams count toward official Solaris Certification and allow you to provide comments and technical feedb
|
|
|
|
