JXTA in a Nutshell

Summary

In this chapter, we saw how JXTA peers use pipes to communicate between themselves. Pipes are a logical abstraction that hide the complexity of network protocols and topology from peers. Peers need to publish only their pipe advertisements and obtain pipe advertisements from other peers; the core pipe service is used to resolve the underlying network connections represented by these advertisements. Therefore, peers can focus on reading and interpreting the messages they send over the pipes: the “what” of their communication rather than the “how.” We’ve also seen how event-based, asynchronous APIs can be used to process newly discovered advertisements and newly available pipe messages.

JXTA pipes enable two peers to communicate independently of their physical location on the network. JXTA pipes can traverse firewalls and NAT systems. Two peers, each behind its own firewall, can exchange messages through a JXTA pipe. JXTA’s pipe advertisements virtualize the notion of the peers’ location.

In this chapter, our two peers were applications, and a HungryPeer depended on an available RestoPeer in order to satisfy its requests. In the next chapter, we’ll see how a JXTA application can be a JXTA service. A JXTA service can be created by any application that needs to use it; applications do not need to rely on finding an instance of the service within the peergroup.