O'Reilly Book Excerpts: JXTA in a Nutshell
Getting Started with JXTA, Part 5
In this fifth and final excerpt on getting started with JXTA, excerpted from JXTA in a Nutshell, learn about advertisements: structured XML documents for JXTA infrastructure.
We've mentioned advertisements in passing a number of times in this chapter; we even created advertisements for pipes and groups using the shell's
mkadv command. Advertisements are one of the basic building blocks of JXTA: they help peers discover any kind of service, including peergroups, other peers, and pipes. In fact, at a basic level, the JXTA infrastructure is simply about sending advertisements for various resources around to interested parties. A JXTA application simply searches for advertisements it is interested in and responds to requests for advertisements that it has published. The basic protocols we've mentioned all use advertisements as the mechanism by which they send data. Advertisements provide a platform-independent representation of platform objects that can be exchanged between different platform implementations (Java, C, etc.).
Advertisements are structured XML documents. The JXTA infrastructure defines six such documents:
- Peer advertisement
- Peergroup advertisement
- Pipe advertisement
- Service advertisement
- Content advertisement
- Endpoint advertisement
Developers may subclass these advertisements when they create their own services. For example, a content advertisement could announce that a peer has a particular item (such as a PDF file of this chapter). A JXTA application may create a subclass of the content advertisement to refer only to PDF files of this book. Peers who are interested in generic content can look for standard content advertisements; peers who are interested in only the PDF files of this book can look for the content subclass. Both peers will find the PDF of this chapter, but the second will find less extraneous content.
In This Series
Getting Started with JXTA, Part 2
There are three ways to obtain advertisements. First, peers create advertisements for services they are interested in supplying. For example, in the previous section we used the
mkadv -p command to create an advertisement for a peer endpoint. Second, peers discover some kinds of advertisements. Advertisements for other peers, for instance, are broadcast through a network, where peers will discover them. Finally, peers can search for advertisements: they can query other peers for advertisements that have specific attributes.
In our previous pipe example, we set up both ends of the pipe within the same peer. Now we'll see how advertisements allow us to set up the ends of the pipe in different peers. To follow along with this example, you'll need to start two shells (preferably on different machines).
First, one peer must create the pipe advertisement. In the first shell, execute this command:
JXTA>pipeadv = mkadv -p
Now this advertisement must be published--i.e., made available to other peers. In the first shell, this is done with the
Other peers must obtain this pipe advertisement. In the second shell, this is done with the
JXTA>search -r JXTA>search JXTA Advertisement adv0 JXTA Advertisement adv1 JXTA Advertisement adv2 JXTA Advertisement adv3
The first command tells the shell to search for advertisements using discovery (e.g., by broadcasting a message to other peers in the peergroup in order to see what shared advertisements they have). The second command prints out a list of all the advertisements that the peer has obtained (advertisements that the peer itself created will also appear in this list). Note that it may take a while between when the
search -r command is issued and when the remote advertisement is discovered; you may need to wait a minute or two before the desired advertisement shows up in the list.
You may also see multiple advertisements listed; in order to determine which is the desired pipe advertisement, you must
cat each advertisement. The pipe advertisement we're interested in looks something like this:
JXTA>cat adv3 <?xml version="1.0"?> <!DOCTYPE jxta:PipeAdvertisement> <jxta:PipeAdvertisement xmlns:jxta="http://jxta.org?"> <Id>urn:jxta:uuid-59616261646162614E5947295932593319469 D7BC74B47438A0FB4EBAEA6237804</Id> <Type>JxtaUnicast</Type> </jxta:PipeAdvertisement>
pipeadv variable in the first shell, you can determine the ID to look for in the list of advertisements in the second shell.
Now we can set up the actual pipes. In the first shell, set up the input pipe:
JXTA>inpipe = mkpipe -i pipeadv
In the second shell, set up the output pipe:
JXTA>outpipe = mkpipe -o adv3
Note that in the first shell, we used the
pipeadv variable to create the pipe; in the second shell, we must use the variable that the shell assigned when it discovered the pipe advertisement.
At this point, you can create a message in the second shell and use the
send command to deliver the message to the first shell (which reads it using the
recv command). This procedure is unchanged from our previous example.
In this chapter, we used the JXTA Shell to explore the underpinnings of the JXTA framework. Each instance of the shell is a peer, and we've seen how multiple peers can use a variety of techniques to discover other peers. As implemented in the shell, these techniques are tied to a particular network binding (e.g., TCP), though the PDP is designed to run over any network.
Similarly, we've seen how the shell peers organize themselves into peergroups, another key JXTA concept. Peergroups allow for the segregation of services so that peers can more easily manage their relationships with other peers.
The communication between peers in JXTA is based on the notion of an endpoint. One key example of an endpoint is a pipe, which can provide either input or output for a peer and allows complex behavior to be built from several simple peers. Pipes form the basis of communication in JXTA; peers depend on advertisements to locate pipes and other endpoints with which they want to communicate.
The shell provides a mechanism by which we can explore and test many of these features. In the next few chapters, we'll look into how we can develop our own JXTA applications that include these same features.
Scott Oaks is a Java Technologist at Sun Microsystems, where he has worked since 1987. While at Sun, he has specialized in many disparate technologies, from the SunOS kernel to network programming and RPCs.
Bernard Traversat is a well-known developer in the Java Community and an active member of the Project JXTA. Bernard is the Engineering Manager for the JXTA CORE.
Li Gong is a well-known developer in the Java Community and an active member of the Project JXTA. Li is the JXTA Engineering Director for the JXTA CORE.
Return to ONJava.com.