Thus far in your exploration of the Voyager environment, you’ve learned how to message remote objects and develop mobile objects. In this final technology section, you’ll learn about a Voyager technology called Space, which allows for redundant messaging between collections of objects. Space technology allows for objects that expose a common interface to be grouped into a logical Subspace, as well as for a collection of Subspaces to be linked together creating a larger Space. Once the objects are linked together, any method invocation delivered to an object contained in any Subspace causes the same method to be invoked in all objects contained in all Subspaces.
Because each object can uniquely respond to the message, it’s not possible to obtain a return value from any such interaction. The Space message replication technology is depicted in Figure 34.3.
In this next sample application, we develop a stock portfolio and symbol value
broadcaster. The portfolio is depicted by the PortfolioI interface contained in Listing 34.6, and it exposes a single method that’s invoked when a new symbol/value pair is available.
LISTING 34.6 THE PortfolioI INTERFACE
public interface PortfolioI {
public void quoteUpdate(String sSymbol, float fNewValue);
}
Figure 34.3: Message replication using Space technology.
The implementation of the PortfolioI interface, contained in Listing 34.7, prints out the symbol/value pair as it is received.
LISTING 34.7 THE Portfolio CLASS
public class Portfolio implements PortfolioI {
public Portfolio() { }
public void quoteUpdate(String sSymbol, float fNewValue) { System.out.println(sSymbol+" is at:: $"+fNewValue);
} }
Moving into the interesting part of the application, Listing 34.8 contains the StockBroadcast class. This class actually creates the Subspaces, links them
together, associates Portfolio instances with the Subspaces, and finally sends out an event.
As you examine the code, first note the manner in which the Subspaces are created. We use the Factory.create() method and pass in the fully qualified name of the
implementation class and also specify a location and alias for each. This example creates a new Subspace instance at port 7000, 8000, and 9000 on the same machine. After creating the Subspaces, we link them together with the Subspace.connect() method. Note that this link is bi-directional, meaning that if Subspace A is linked to Subspace B, Subspace B is automatically linked to Subspace A. The next action executed in the constructor is the creation of a PortfolioI instance at each
environment location and the setting of the object’s lifecycle to be indefinite. The Voyager environment implements a distributed garbage collector that’s charged with managing the lifecycle of all objects created in a Voyager environment. Because the PortfolioI instances are going to sit alone, with no local objects referencing them, we need to tell the distributed garbage collector to never garbage collect those objects. If this step is not performed, a low-memory condition could cause the removal of the objects.
Once created and told to live forever, the PortfolioI objects are added to each of the Subspaces. At this point, we now have three linked Subspace objects, each holding a single PortfolioI object. We now request a proxy used to communicate to all the objects and invoke its quoteUpdate() method. Of course, the value associated with the INKT symbol is only a guess; market pressure could drastically change the actual value by the time you read this.
LISTING 34.8 THE StockBroadcast CLASS
import com.objectspace.voyager.*;
import com.objectspace.voyager.space.*;
import com.objectspace.voyager.space.multicasting.*;
public class StockBroadcast {
public StockBroadcast() throws Exception { Voyager.startup();
// create three Subspaces at different locations ISubspace subspace1 = (ISubspace)Factory.create(
"com.objectspace.voyager.space.Subspace",
"//localhost:7000/Subspace1" ));
ISubspace subspace2 = (ISubspace)Factory.create(
"com.objectspace.voyager.space.Subspace",
"//localhost:8000/Subspace2" ));
ISubspace subspace3 = (ISubspace)Factory.create(
"com.objectspace.voyager.space.Subspace",
"//localhost:9000/Subspace3" ));
// connect the various Subspaces subspace1.connect(subspace2);
subspace1.connect(subspace3);
subspace2.connect(subspace3);
// create one PortfolioI object at each location PortfolioI portfolio1 =
(PortfolioI)Factory.create("Portfolio",
"//localhost:7000");
PortfolioI portfolio2 =
(PortfolioI)Factory.create("Portfolio",
"//localhost:8000");
PortfolioI portfolio3 =
(PortfolioI)Factory.create("Portfolio",
"//localhost:9000");
// add a PortfolioI to each Subspace subspace1.add(portfolio1);
subspace2.add(portfolio2);
subspace3.add(portfolio3);
// send a message
Multicast.invoke(subspace1, "quoteUpdate",
new Object[] {{"INKT", new Float(80f)},
"PortfolioI" ));
// exit
Voyager.shutdown();
}
public static void main(String[] args)) { try{ new StockBroadcast(); }
catch( Exception e ) { System.out.println; } }
}
To run the Space-based application, first compile the code in Listings 34.6 to 34.8. Next, start the Voyager environments by typing
voyager 7000 voyager 8000 voyager 9000
Finally, start the application by typing java StockBroadcast
As the application executes, you’ll see “INKT is at: $80.00” appear in all windows almost simultaneously.
As the applications you develop with Voyager grow in size and importance, the role played by Space technology will also grow. This is especially true when developing servers that must be available 24 hours a day, 7 days a week. In such 24×7 situations, Space
technology allows you to develop server applications that are completely redundant. At any one point in time, each server in the cluster will have the same state; therefore, if one crashes, the client will not notice.
FROM HERE
This chapter covered significant ground by introducing a lot of new technology. The most earth shattering being the introduction of the topic that objects can actually be fully
mobile. The Voyager agent platform allows for objects to change their physical location in much the same manner that we humans also have this ability. As you continue to study this book, you’ll find that the following chapters complement the knowledge imparted by this chapter:
• Chapter 15, “Remote Method Invocation (RMI)”
• Chapter 21, “CORBA Overview”
• Chapter 35, “Voyager-Based Implementation of the Airline Reservation System”
Chapter 35: Voyager-Based Implementation of the Airline Reservation System
Overview
Assuming you’ve been on a sequential tour of this book, you’ll recall that certain chap- ters focus on implementing a common set of use-cases, each using different technolo- gies. This chapter completes the exercise by implementing those use-cases using the Voyager Agent technology. If, for some reason, curling up with this tome and reading it cover to cover is not your cup of tea, and you did arrive at this chapter without exploring previous chapters, a bit of background is in order.
Back in Chapter 6, “The Airline Reservation System Model,” a collection of use-cases that model an airline reservation system are developed. These use-cases are then imple- mented throughout the book using sockets (Chapter 14, “Socket-Based Implementation of the Airline Reservation System”), RMI (Chapter 16, “RMI-Based Implementation of the Airline Reservation System”), servlets (Chapter 19, “Servlet-Based Implementation of the Airline Reservation System”) and finally CORBA (Chapter 26, “CORBA-Based
Implementation of the Airline Reservation System”). The goal of implementing the same use-cases using different technologies is to show you that different routes can be taken to reach a common solution. Each implementation chapter produces a piece of software that solves a common problem, yet implements the solution in its own unique manner. As you leave the safety of this book and begin to venture out into the world of producing real-world distributed solutions in Java, pay specific attention to the material taught by the implementation chapters.
Although the chapters do show how a common piece of software is implemented using different technologies, they do not decide on a blanket technology useful for all applica- tions. Unfortunately, no single distributed technology is a silver bullet; each application is best served by at least one technology. If your solutions are to be successful, you must not religiously adhere to one technology but rather choose the best technology for each application.
In building the airline reservation software with Voyager, it’s important that you first read the use-cases from Chapter 6 as well as the coverage of Voyager in Chapter 34,
“Voyager Agent Technology.” This chapter plows ahead with the assumption that you understand the previous material. Reading the other implementation chapters is not a requirement, but you’ll want to do so at some point in time. In covering the Voyager implementation in this chapter, the following points are addressed:
• Implementing client and server callbacks
• Developing mobile agents
• Exposing application functionality through interfaces