February 28, 2021
Hot Topics:

Overview of JXTA

  • By Sams Publishing
  • Send Email »
  • More Articles »

This material is from Chapter 2, Overview of JXTA, from the book JXTA: Java P2P Programming (ISBN: 0-672-32366-4) written by Daniel Brookshier, Darren Govoni, Navaneeth Krishnan, and Juan Carlos Soto, published by Sams Publishing.

In This Chapter

  • JXTA Defines
  • JXTAConcepts
  • Peer and Groups
  • Advertisements
  • Pipe Bending Protocols
  • Rendezvous Protocol
  • JXTA Identifiers
  • Summary

By Daniel Brookshier

Now we look at key JXTA concepts and the protocols used. In this chapter, we will reiterate aspects of that protocol from the author's point of view and in less formal language to ease you slowly into JXTA concepts. The JXTA protocol specification is a formal document that describes a standard for JXTA peers and their behavior. The goal of this chapter is to acquaint you with the concepts in preparation for Chapter 3, "JXTA Protocols," where we will begin covering Java API.

JXTA Defined

The following a quote is from the introduction of the JXTA protocol specification:

The JXTA protocols are a set of six protocols that have been specifically designed for ad hoc, pervasive, and multi-hop peer-to-peer (P2P) network computing. Using the JXTA protocols, peers can cooperate to form self-organized and self-configured peer groups independently of their positions in the network (edges, firewalls), and without the need of a centralized management infrastructure.

What this all means is that JXTA is a framework with a set of standards that support peer-to-peer applications. JXTA is not an application, and it does not define the type of applications you write. The protocols defined in the standard are also not rigidly defined, so their functionality can be extended to meet specific needs.

JXTA is made up of three distinct layers. The first is the platform. The platform contains core functionality used by services, which are the second layer. Services provide access to the JXTA protocols. Finally, there are applications that use services to access the JXTA network and utilities. This arrangement should be familiar because it is identical to a standard operating system, where there are three layers consisting of the core operating system, services, and applications.

JXTA adds several new concepts, such as the peer, peer group, pipe, and endpoints. JXTA uses a new concept in peer-to-peer communication and discovery with advertisements, which are XML documents that describe services and information available on the JXTA network. Finally, we have various types of identifiers used to distinguish one item or service from another.

Goals of JXTA

To begin, let's start with the goals of JXTA. The goals of JXTA are very simple:

  • Operating system independence

  • Language independence

  • Providing services and infrastructure for P2P applications

In essence, the goals of JXTA are to support peer-to-peer programming on any device from a desktop computer to a PDA to a car or washing machine.


JXTA is not a competitor to JINI. Although JXTA can run on devices, such as refrigerators, but that is not the ultimate goal—just something possible given the goals. Many new to JXTA confuse JXTA with JINI because of the many references to devices. JXTA and JINI have similar, but different, goals. JINI is aimed more at discovering and using devices. JINI is also more Java-centric where JXTA specifically uses XML instead of RMI, as does JINI. JINI was also designed to work within the bounds of a local area network, not to interoperate on the Web and across firewalls, as does JXTA. JINI is also more concerned with services located on a particular network, such as a printer, for example. JXTA would more likely be used to communicate with a software service that is not location specific.

There are also conceptual goals. These goals include the following:

  • Use groups to organize peers and to give context to services and applications.

  • Groups use authentication and credentials to control access and/or enable security at the group level.

  • Distribute information about peers and network resources throughout the network.

  • Queries are distributed throughout the system.

  • Provide an infrastructure for routing and communications between peers. Communication with peers behind firewalls and other barriers is a key part of this goal.

  • Provide mechanisms to allow peers to monitor each other and resources.

In addition to these goals, there are several other goals, such as encryption, support for various communications protocols, ease of use, stability, and performance. All of these goals were considered when creating the JXTA protocols and the initial Java API.

Additionally, there were other goals considered by the developers and the Sun Microsystem's managers:

  • Create a system that would enable any device to be added to the JXTA network (similar to JINI).

  • Create a system that would enable centralized management of peers within ISPs and corporate Internets.

  • Create a system that can support digital rights management. This would foster JXTA's use in purchasing digital products, such as software, music, movies, and other digital media. File sharing P2P applications that do not account for digital rights will be seen as a legal liability and will be blocked by businesses and ISPs. By respecting intellectual property and copyrights, JXTA managers hope that JXTA will be allowed access.

  • Encapsulate and abstract specific core functionality so that commercial applications can be created. In other words, enable manufactures to create appliances or hardware to perform functions similar to traditional networking products, such as routers, firewalls, and hubs. This enables hardware and appliance manufacturers to profit, as well as adds industry and corporate respectability.

The prior list has two key concepts. First, companies need to be able to feel like they have control. Most P2P systems do not have centralized management and are not welcome in most corporate situations. Secondly, the JXTA system needs to produce income for more than just application developers. This means that there needs to be hardware or hardware/software combinations that are sold by vendors. Because Sun Microsystems is in the hardware business as well as software, this is a very important goal.

Given all of the goals, JXTA is designed for industry acceptance, maintainability, robustness, and can be used to fulfill almost any P2P application concept. Because of the many goals, there is resulting complexity. Because the system is complex and there are many methods to implement a P2P platform, the specification is bound to change in the beginning. This chapter was rewritten several times as the specification changed in the early months of development of the JXTA platform.

In general, most of the following will be reasonably stable, but be aware that some name changes or structures may occur. Based on current experience, the differences will be minor and the following should remain mostly current for quite some time.


XML is the basis for most of the protocol in JXTA. The key reasons are its ability to be read by many languages and its ability to be validated. XML is also an easy choice just because of its popularity.

Overall, XML is a good choice because it is easy to sell as a protocol. To create a protocol that used a binary format would be more difficult to understand, and parsers would need to be built from scratch. With XML, there are many parsers that can be used, both commercial and free. XML is also becoming a standard for many different industries for representing data, so mixing data with the protocol is as simple as merging two XML documents.

There is a downside to using XML. XML is simply not a compact way to express data. Messages written in XML will be much larger than a binary equivalent. There are techniques that can be used, such as replacing tags with binary tokens or compacting data, but none of these are currently employed in JXTA because there are no widely accepted standards at this time. Consequently, the core JXTA developers have created a simple binary message transport and have used terse language and acronyms for tag names. Unfortunately, this means that the XML used in JXTA is devilishly hard to learn and read.

Because some developers are not familiar with XML, Appendix B, "XML Primer," has a short primer on XML concepts.

JXTA Concepts

Peer-to-peer networking, such as server-based networking, requires a lexicon of concepts that need to be understood. The concepts are similar to others you are familiar with, except that there are a few twists caused by the needs of a P2P network. Let's look at the important definitions and concepts that will be critical to understanding JXTA. We'll return to each of these concepts and discuss them in more detail later in the chapter.


A peer is a virtual communications point. You can have multiple peers on a computer or device. A peer is not the same as a user because a user may have peers on their phone, office/home computer, or other devices. It is also possible to have multiple peers on a single device, not necessarily an ideal situation but good for debugging.

Because a peer is not the same as a user, applications need to abstract the idea of user separately from peers. Any abstraction of users should be viable when a user has access to multiple peers.

Peers are also associated with special network services that they provide. In the reference implementation, peers can share basic services with the rest of the network, such as rendezvous, router, gateway, or a combination. These basic services provide search and communication services. In general, not all peers need to enable these services, but a percentage of them are required to ensure that other peers have access to these services. We will cover the concepts of these services a little later in this chapter.

One Peer On One Computer

Usually only one peer resides on a single platform. We assume a communications model where there is only one peer per device. When P2P is accomplished by a distributed network of computers acting as peers, we get the most value from collaboration, distributed searching, content sharing, bandwidth sharing, distributed processing, and other P2P applications. Nevertheless, there is nothing to preclude multiple peers from residing on a single platform or multi-CPU device. As long as the peers can be viewed as separate entities, there should be no problem, except for consuming extra resources. As a minimum, multiple peers can be launched on a single computer to simulate a network for debugging.

One reason for multiple peers on a single computer is to provide a proxy service for peers that are too small to be a JXTA client. This is true for cell phones or other portable devices. However, with advancements in portable devices, there is less of a need for this type of arrangement. There are cases where you need to do this, but they should be special cases. You should also realize that the same functionality could be created by a group of individual peers, each peer acting as a proxy for the telephone peer.

  • Context switching—The number of peers you need to run are greater than the capacity of the server. As each peer is communicated to, you need to switch its state into active memory.

  • Size—How much of a peer do you allow in the server? How big of an application? How do you constrain and manage it?

  • Application—What is the application? Will all customers use it? Is there a value worth charging for?

Another possible solution that could have multiple peers is to interface to an existing server. The peers would act as a proxy view of the server so that the resources would be available over the P2P network. Nevertheless, this again can be solved with a distributed system of external peers that proxy the server. Resources can be added at will by adding more peers. A peer could also optionally use the server directly or use a proxy peer.

The whole idea of P2P computing is to distribute resources. By creating servers with multiple peers, you are going against JXTA and P2P philosophy. You are also burdening yourself with all the server problems that true P2P avoids.

Imagine true P2P solutions when faced with legacy servers or attitudes. Refactor your old server applications using JXTA when faced with costly or inadequate server technology.

Peer Group

A peer group is a way to group peers and to advertise specific services that are available to group members. You can create groups, join them, and of course resign from a group. There is also the ability to renew a membership in a group.

A group may need to limit membership for various reasons, such as secure communications between members, privacy, or there may need to be certain information that a user must supply before joining a group. There is an authentication protocol specifically designed to collect information and allow the group to determine if the information meets the requirements for membership.

The peer group provides context to use applications and to use the applications with other peers in the same group. For example, a peer group of jugglers would use a chat service in the juggling group. The effect would be to limit the chat to just those that joined the juggling group.

To further the juggling example, the group could authenticate users by validating a membership ID from a national juggling organization. Those without an ID would not be allowed to chat with the rest of the group, because they could not join the group.

Another way to look at groups is as a virtual private network (VPN). A VPN allows several computers to talk to each other without allowing the rest of the Internet to participate. VPNs include encryption so that the group conversation is not understandable to anyone who might eavesdrop. Peer groups also limit access to peers, and they can also use encrypted messages.

Membership to a peer group can take several forms. The two key models are local and remote membership services. A local membership service runs entirely on the peer that is applying for membership. All resources and ability to validate a user reside also on the same peer. So local membership services allow you to join without connecting to any other peer.

Remote membership requires accessing one or more peers in the group that you are joining. The idea is that peers that already belong to the group either have access to resources for validating a new member. Similarly, the set of peers in the group could query their users with the new member's application to see if the members are willing to accept the new member.


The endpoint is the basic addressing method used by JXTA applications to communicate with each other. An endpoint is an address of a peer that implements a specific protocol of communication. A peer can have multiple endpoints and thus can be communicated with via different protocols.


Address as defined here is not necessarily a physical address. Endpoints allow the physical address to change. For example, in a DHCP-enabled ISP, the IP address of a computer that dials in, is going to be a random address each time.

A simple example of an endpoint is an IP address and port. By using these values, a stream could be opened to communicate to the target peer. However, JXTA places a layer on top of streams called pipes (discussed in the next section). Instead of connecting a stream to an address (represented by the endpoint), you connect a pipe to the endpoint. The beauty of endpoints and pipes is that you don't care what the real address is or what the best protocol to use for a particular peer. In addition, there are other services used to route and even forward messages. Using the pipe and endpoint abstraction provides a lot of power and reduces the complexity of building a P2P application.

Because pipes connect via a communications protocol, the endpoint describes the protocol and the specific information used to connect to it. Therefore, the endpoint can describe an HTTP, TCP, BEEP, or other supported base communications protocol.

A peer can support one or more endpoints. By supporting more than one protocol, the peer can use the most effective method. In other words, if two peers are behind a firewall, they can communicate through their TCP endpoints. When these peers communicate to peers across the firewall, which traditionally filters everything but HTTP, they would use the HTTP protocol.


A pipe is a virtual connection between peers. Normally, we think of peer-to-peer communications as a single connection, but this is not always possible. The problem is that many peers cannot connect directly because of firewalls or other barriers. Pipes are intended as a layer over multiple communication protocols and to support relayed communications via gateway peers.

Pipes are a basic and important feature of JXTA. They create a very useful paradigm that allows peers to communicate in most network situation, despite firewalls or other barriers. Even if you do not know anything about a peer or where it is, you will to have a mechanism to communicate with the peer via a pipe.

Pipes are used as an abstraction to hide the fact that there may be other peers involved along with multiple connections. Pipes can also be implemented to be self-healing and reroute around an original peer. Self healing in important because a peer, unlike a server, is not meant to be available 24 hours a day and can be removed from the network at any time. The Java JXTA implementation has several flavors of pipe. As discussed, the JXTA protocols support and encourage different types of pipe. The following is a list of a few possible (currently not implemented) pipes that are either part of the Java implementation or possible additions:

  • Uni-directional asynchronous—This is a pipe that is only used for communications that are in one direction. The pipe is asynchronous and messages may arrive out of order. This is the most basic type of pipe and should be implemented on most JXTA platforms.

  • Synchronous request/response—All messages sent will receive a return message of acknowledgment. Messages arrive in the order that they were sent.

  • Bulk transfer—Used to move large amounts of data.

  • Streaming—Used to efficiently move data in a stream similar to that of audio, video, and other data streams, such as a stock market data feed.

  • Bidirectional—A combination of two asynchronous pipes.

  • Uni-directional synchronous—All messages sent will receive a return message of acknowledgment. Messages arrive in the order that they were sent.

  • Unicast reliable secure pipe—All messages sent will receive a return message of acknowledgment and the data will be encrypted.

There are two different types of addressing for pipes:

  • Point-to-point—Point-to-point pipes connect two different peers. Multiple other gateway peers can be used to create the connection.

  • Propagate—Connects one peer to multiple destination peers. Propagate pipes are also called wire pipes because of the project that originally developed them. Propagate pipes can also have multiple peers involved in the connection, including those that are endpoints in the communication.

In the current platform, the uni-directional asynchronous, unicast reliable secure pipe, and bidirectional pipes are implemented. In addition, there is a secure version of a unicast and reliable secure pipe.

Endpoints and Pipes

JXTA is very different from a traditional network. Most network protocols have either no address (HTTP clients) or they have a fixed address where a URL or IP address is used to pinpoint the clients. JXTA abstracts the idea of a client address and calls it an endpoint.

A peer can have more than one endpoint. Peers can communicate over one or more protocols, such as TCP and HTTP, so there are usually multiple endpoints. This sounds strange at first because we usually deal with only one protocol in most applications. The reason JXTA uses multiple transport protocols is to allow a service to communicate with peers over the best method possible.

If you were behind a corporate firewall, you would use HTTP to communicate outside the firewall and TCP to talk to peers on the local LAN behind the firewall.

With multiple transport flexibility, you can use a specific protocol for a specific peer and thus the best speed and response. Behind the firewall, the speed and response is very good. Crossing the firewall, the response is poor. Overall, you are better off than if you only used HTTP that would have sacrificed efficiency behind the firewall.


An advertisement is an XML document that describes a JXTA message, peer, peer group, or service. Advertisements follow standards for encoding, tags, and content. The advertisement is used to exchange information about what is available in the JXTA network.

For an example of how this would work, imagine a peer that creates a peer group with the name Trekker Chat. The peer would publish the advertisement to the local JXTA network. This is done with an IP multicast. In other words, any peer in the sub-net will receive a copy of the advertisement. In addition the advertisement is sent to the rendezvous.

Peers use a special class of peers called rendezvous peers to discover advertisements from the rest of the network. Rendezvous peers (discussed in the next section), store advertisements and support searches. A peer can now request the peer group advertisement by searching for its name or other property. With the peer group advertisement, these client peers can then instantiate and join the Trekker Chat peer group by using the information contained in the XML. When they're members, they can use the group context of services or locate peers that belong to the group.


Most of JXTA's advertisements are encoded with UTF-8, which is an ASCII-preserving encoding method for Unicode (ISO 10646). Unicode could be used, but the advertisements do not use special language characters and foreign punctuation. Because UTF-8 is 8 bits and Unicode is 16 bits, the halving of the size of advertisements makes a lot of sense.

The only place you should find it necessary to use full Unicode is in the body of messages. Within messages, the encoding of the contents can be specified as Unicode or any other character set, including UTF-8.

Page 1 of 6

This article was originally published on August 21, 2002

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date