The Artima Developer Community
Sponsored Link

Make Room for JavaSpaces, Part III
Coordinate your Jini Apps with JavaSpaces
by Susan Hupfer
First Published in JavaWorld, March 2000

<<  Page 9 of 10  >>


The Advantages of Using JavaSpaces for Coordination

In this example, I've demonstrated a simple Jini service that coordinates access to a limited resource (a game with limited capacity). With a small amount of JavaSpaces code, I've managed to coordinate the activities of any number of players. I've already mentioned that the algorithm doesn't guarantee fair access to the game, but with some work, you could implement a turn-taking scheme to coordinate the players. My example also does nothing to guarantee that tickets won't be lost if, for instance, a ticket-holding player crashes while playing the game. You can remedy this situation by using transactions, which I'll explain in a future article.

I also want to point out that this example is flexible enough to mediate access to any number of games. The single limitation is that you can specify only one game name on the command line to the game service, so it creates tickets for just one game. This, however, is easy to fix. In fact, you could move the createTickets to a separate "Ticket Generator" program and run it whenever you want to generate a set of tickets for a new game.

JavaSpaces is a natural way to synchronize processes in a distributed environment that has no central controller. But what about the example in this article? Here, the Jini game service could certainly serve as a central point of control -- via some kind of internal data structure -- for admitting players to a game. The JavaSpaces approach has an advantage because it scales naturally: it works just as well if thousands of players try to access a game. If the Jini service were to mediate access, a bottleneck could occur at the internal data structure that handles the access, since players need to access that data structure sequentially. In the case of a space -- which is designed for concurrent access -- the players simply wait around for tickets, without a centralized data structure handling access to the game.

Another advantage of using JavaSpaces to coordinate your Jini applications is that it allows easy interaction with other Jini services. In the example game, for instance, the tickets are kept in a space and are available to other services that may need to interact with them. Suppose you revamp your remote game with a much improved play method. You can simply write a program that removes tickets from the JavaSpace in which they're stored, modifies the game field to refer to your new remote game object, and returns the tickets to the space. Without modifying or recompiling the game service, players automatically connect to your improved game the next time they gain access.

Suppose you want to broaden the access to your game. You could simply write a program that writes additional tickets into the JavaSpace. Again, you wouldn't have to touch any other code in the system or bring the game service down, since the concept of "maximum players" is embodied only in the number of tickets that reside in the space. Another advantage of using JavaSpaces is that it permits tickets to be "leased" in the space (leasing is another concept that I'll cover in future articles). Instead of writing tickets into the space and asking that they be stored indefinitely, you can give them a time limit, after which the space will remove them. This can be convenient if you want a game to be played within a certain time frame. You simply specify that tickets should disappear when the time is up, and players won't be able to obtain access to the game after that time.

<<  Page 9 of 10  >>

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use