Java Reference
In-Depth Information
Communicating with Other Xlets
A key difference between the MIDlet execution model provided by the MIDP and that of
the Xlet execution model provided by the PBP is that the Xlet execution model requires
that Xlets support rudimentary Inter-Xlet Communication (IXC). Data sharing for Xlets is
increasingly important, as the platforms that can run Xlets typically have access to a great
deal of data (through either broadcast or wide-area networks such as the Internet) but
limited storage for applications and data. As a result, data sharing between applications
becomes increasingly important, because it is impractical for each application to contain
the code necessary to access and decode a network source for data and cache its own
copy of the data it needs in order to function.
The usual means for applications to share data in the Java environment is through
the Java RMI stack, which permits both interapplication and interdevice communica-
tion. In fact, a robust subset of the RMI stack
can
be made available for Java ME; this is
discussed in JSR 66, and I discuss it in more detail in Chapter 11. This support for RMI
is key for some set-top boxes and other platforms with a strong reliance on middle-
ware, because RMI enables servers and clients to exchange data in a Java-native,
object-oriented way, simplifying the design and deployment of multitier systems.
Not all PBP devices need the entire RMI stack, however, so the PBP defines only a
subset of RMI suitable for letting Xlets share data. Not surprisingly, the PBP mechanisms
closely mirror the RMI architecture, leveraging some classes and the same basic process
for defining the communication process.
IXC requires that data be represented by shared Java objects that encapsulate the
data you want to share. These objects must be
remotable
—that is, they must implement
the
java.rmi.Remote
interface. Xlets share these remotable objects through the IXC reg-
istry, which is a singleton shared by all Xlets running on the local host available from the
XletContext
. Xlets can register the remotable object using the IXC registry, or they can
obtain access to remoted objects through the registry. Figure 9-5 shows a schematic of
the relationship between two different Xlets and an object they share.
As the diagram suggests, there's a subtle difference between the object shared
through the registry by the first Xlet, and what the second Xlet actually consumes. Due
to the way the Java class loader operates, Xlets cannot simply share objects; instead,
the IXC registry creates and returns a stub object that acts as a proxy to the shared
object. This is similar to the RMI model, although in the full RMI implementation,
either you must generate the stub using the RMI compiler (if you're using a version of
Java before Java 5) or the RMI runtime can do this automatically (if you're using a ver-
sion of Java after version 5).
