Making P2P interoperable: The JXTA story

Document options Document options requiring JavaScript are not displayed Rate this page Help us improve this content

Level: Introductory

Sing Li (westmakaha@yahoo.com), Author, Wrox Press

01 Aug 2001

Peer-to-peer networking is coming, and it promises to create a computing world fundamentally different -- and, in some ways, better -- than the one based on the old client/server model. Project JXTA is a community-run attempt to build a utility application substrate for peer-to-peer applications. Though its reference implementation is written in the Java language, JXTA can embrace virtually any language, OS, or platform in existence today -- and, more importantly, it's ready for technologies that haven't even been conceived of yet. In this first installment in a three-part series, Java developer and author Sing Li explains the basic concepts and protocols that underlie JXTA to prepare you for future articles, in which you'll experiment with the JXTA shell and build P2P applications.

A peer-to-peer (P2P) network differs from conventional client/server or multitiered servers networks in that participating peers in the network communicate directly with each other. This work is done typically without the reliance on centralized servers or resources. Within a P2P network, work is done and information is shared through interaction between peers. P2P architecture enables true distributed computing, creating networks of computing resources that can potentially exhibit very high availability and fault tolerance.

While traditional client/server and multitiered architectures are state-of-the-art workhorses for our industry, systems with P2P architectures are the new kids on the block. Project JXTA is Sun's foray into providing a utility application substrate for building P2P applications across platforms, OSs, and programming languages. It is now an open source project with participation from Sun; see the Resources section below for information on the JXTA community.

The JXTA design philosophy

The components of Project JXTA are the results of careful design factoring. They provide the minimal requirements for a generic P2P network, stripping it of all the policy-specific logic and components. This leaves only the building-block constituents that almost all P2P applications can use, regardless of their intended users and specific implementation. In the coming months and years, one of the key charters for the JXTA core community is to ensure that this generic applicability remains true. You can argue that the most compelling applications for P2P have yet to be invented, and if JXTA ended up with policy- or implementation-specific details embedded into its fundamental infrastructure layer, such undreamt-of applications might never work with the platform. In other words, the JXTA components enable and facilitate the simple fabrication of P2P applications without imposing unnecessary policies or enforcing specific application operational models.

Back to top

Project JXTA's independence from the Java platform

As we cover JXTA's core building blocks, you'll notice that we won't mention anything related to Java technology! Sun has provided an initial Java language implementation for JXTA; but, amazingly enough, Project JXTA is specific neither to the Java programming language nor to the Java platform. In other words, anyone can implement JXTA-based networks on any hardware platform, with any operating system, using any programming language. Add to this JXTA's transport-agnostic nature (as you'll see, it is not even dependent on TCP/IP) and you have a P2P infrastructure that is ready to interoperate.

JXTA: What's in a name? JXTA is more than a four-letter acronym beginning with the letter J in the spirit of the names Java and Jini. In fact, it stands for Project Juxtapose. Juxtapose beautifully and elegantly describes the future world of integrated P2P computing. Existing client/server computing within an intranet or the Internet as we know it will never disappear or be displaced. Instead, JXTA technology will complement and coexist alongside these technologies (hence juxtaposition), and add tremendous value to the end user's experience. Internet and intranet users will be able to benefit from both forms of networking.

Interoperability as a design choice

Some may question the viability of a specification as generic as JXTA's. JXTA systems can be designed to be interoperable -- but there are no hard-and-fast rules that they must be interoperable in any useful manner. In other words, a JXTA application that meets the minimum specified interoperable requirements superficially and does not interoperate in any meaningful way with others can still be in accord with the JXTA specification. However, it is anticipated that the viral growth of P2P applications and services will force vendors to embrace interoperability as a key product feature. The consequences of this design decision are left to be tested by the trials and tribulations of open market forces.

Deploying XML at its heart

As we'll explain in more detail shortly, JXTA currently uses XML as a message and advertisement format; this goes a long way toward making JXTA interoperable. Thanks to the simplicity and universal accessibility of XML technologies, software can be created on almost any platform to generate and parse JXTA messages.

Back to top

JXTA core building blocks

The components that make up a JXTA system are the very same that can be identified in many P2P network implementations:

• Peers and peer groups
• Services
• Pipes
• Messages
• Advertisements

An examination of each of these components will reveal how P2P communications work over a JXTA network.

Peers and peer groups

Of course, a peer-to-peer network consists of peer machines communicating with each other. Ultimately, the entire connected universe is one big P2P system. But with today's limit on connectivity and available bandwidth, harnessing the entire Internet as one huge P2P network is impractical. Instead, some partitioning is necessary.

The logical partitioning of the physical network creates working sets of peers called peer groups in P2P lingo. Peer group memberships can overlap with no restriction; in other words, any peer can belong to as many peer groups as necessary. The JXTA specification does not dictate or recommend an appropriate way of forming peer groups. In a JXTA network, a peer group is a collection of peers that share resources and services. You can easily see that if the specification were to restrict a peer group to, say, a local area network -- or even a subset of a wide area network -- many possibilities for new applications that require group membership beyond these physical limits may be precluded altogether. Consistent with JXTA's design philosophy, a peer group is specified to be as unconstrained and as generic as possible.

Note that the existence of peer groups mandates some means of maintaining membership. Again, the JXTA specification states only the minimal need for maintaining group membership, without dictating how this should be done. This membership service is a part of the core JXTA services, but it could take many forms -- it could be either a database or directory service, for instance, and could be based on either a centralized or a distributed implementation.

Services

JXTA services are available for shared use by peers within a peer group. In fact, a peer may join a group primarily to use the services available within that group. A set of services, called core services, is essential to the basic operation of a JXTA network. We've already seen one instance of a core service -- the membership service. Table 1 shows the core services included in version 1.0 of the JXTA specification.

The initial reference implementation of project JXTA does not provide any services beyond the five listed above. Even some of the core services, such as the access service dealing with security, are implemented in a very basic way. The active JXTA community is in charge of fleshing out the details of many of these services, as well as defining and implementing new services that may be beneficial to peer groups (generically or specifically). For example, some of the new services currently being worked on by the community include:

• A monitoring and metering service
• A payment service for anonymous and secured financial transactions
• A distributed search service for Web content and services

In the JXTA 1.0 specification, a running service instance is always associated with a peer (you can think of it as being hosted on a peer "server"). Within a peer group, there can be only one instance of a service associated with a specific peer. This type of service is considered a peer service; if the peer hosting the peer service goes down, the service becomes unavailable. On the other hand, multiple instances of the same service may be redundantly installed on multiple peers within a peer group -- this is called a peer group service. Peer group services are the key to the high availability and fault tolerance of JXTA networks. The implementer of a JXTA application is free to install any JXTA service as a peer service or peer group service. The pipe service, the core JXTA service providing a logical pipe abstraction for peer-to-peer communications, is frequently implemented as a peer group service to ensure that it is always available.

Pipes

One way to transfer data, files, information, code, or multimedia content between peers is through logical pipes, as defined by the JXTA specification. JXTA pipes are used to send messages (with arbitrary content) between peers.

A pipe instance is, logically speaking, a resource within a peer group. The actual implementation of a pipe instance is typically through the pipe service. Unlike conventional (UNIX-like) systems, JXTA pipes are unidirectional and asynchronous. Two peers requiring two-way communications will have to create two independent pipe instances. Also unlike conventional mechanisms such as UNIX pipes or TCP/IP sockets, JXTA pipes can have ends that are connected to different peers at different times, or not connected at all. This single concept alone is a revolutionary step in providing a redundant implementation of a service over a P2P network. A peer can logically "pick up" a pipe at any point in time. For example, imagine a peer that wants to use a spell checker service. It can connect to a peer group's spell checker pipe (which is implemented as a redundant peer group service). In this case, the peer will always be serviced as long as there is at least one single instance of a spell checker service still running somewhere within the peer group.

The JXTA 1.0 specification provides for two general type of pipes: point-to-point and propagate.

A peer can use a point-to-point pipe to connect to another peer and pass messages in one direction. A peer can use a propagate pipe to connect to one or more other peers and pass messages to all of them. Essentially, a point-to-point pipe is a one-to-one message-passing mechanism, and a propagate pipe is a one-to-many message-passing mechanism. The JXTA community is currently working on a many-to-many message-passing mechanism; this mechanism has been christened the JXTA wire.

Regardless of the type of pipe, the blocks of information carried though the pipe are referred to as JXTA messages. What exactly is the format of these messages?

Messages

JXTA messages are data bundles that are passed from one peer to another through pipes. The JXTA spec is again as generic as possible here, so as not to inadvertently introduce any implementation-dependent policies into the definition of a message. A message is defined to be an arbitrarily sized bundle, consisting of an envelope and a body. The envelope is in a standard format that contains:

• A header
• Source endpoint information (in URI form)
• Destination endpoint information (in URI form)
• A message digest (optional -- for security purposes)

The body of a message is of arbitrary length and can contain an optional credential (for security purposes) and content.

Note how loosely JXTA messages are defined. It may not be immediately apparent why this is necessary, given that we generally operate on reliable, high-bandwidth TCP/IP networks daily. But the JXTA message format has to be flexible and accommodating because it may be implemented on top of all sorts of networks, not just TCP/IP. Imagine a JXTA implementation on top of a network supporting 256-byte data packets with an unreliable delivery transport, like a legacy packet-based wireless network. You can appreciate how the simple definition of a JXTA message adapts itself to such adverse environments.

To provide for a standard, easy-to-parse, universal encoding mechanism, JXTA messages are currently XML documents. JXTA takes advantage of the universal accessibility and ease of use and programming of XML, which means that JXTA can be easily implemented on most platforms using most programming languages -- wherever XML parser and generation libraries are available. The design of JXTA itself, however, is not dependent on using XML to encode messages. While it's not too probable, it is entirely possible for the JXTA community to include (or require) non-XML based messages in a future revision of the specification.

About JXTA identifiers A peer group could potentially be as large as the entire connected universe. Naming anything uniquely is a challenge in such a large namespace. In order to cope with this, JXTA assigns an internal identifier to every addressable instance of a JXTA component. This identification is done via a UUID, a 64-byte number generated using an algorithm that ensures a high probability of uniqueness in both time and space. JXTA identifiers are in URN (Uniform Resource Name) format and embedded into advertisements for internal use. Currently, four identifier types are defined, for identifying peer groups, peers, pipes, and code/data (abbreviated codat).

Advertisements

Advertisements are the less obvious cousins of messages. JXTA advertisements are also XML documents. The content of an advertisement describes the properties of a JXTA component instance, such as a peer, a peer group, a pipe, or a service. For example, a peer having access to an advertisement of another peer can try to connect directly to that other peer. A peer having access to an advertisement of a peer group can use the advertisement to join that group. The current Internet analogue to an advertisement is the domain name and DNS record of a Web site. The JXTA specification does not dictate how advertisements are created, circulated, or destroyed.

Back to top

Interoperable base: The JXTA protocols

Another key to interoperability is the fact that the core JXTA peer-to-peer interaction model is completely expressed as a set of simple protocols to be transmitted over the underlying network. In other words, interoperability between JXTA-based system can be completely achieved on the wire since the protocol and message formats are well specified.

For example, a simple PDA (8-bit processor, C-based programming) can be a JXTA peer operating over a packet-based wireless network, interacting with a variety of systems, from PC servers to mainframes, within the same peer group. This is achievable provided the peers share a common network (transport) and are communicating using JXTA protocols and message formats.

Sun has provided the initial Java language implementation for JXTA. The JXTA community now owns this reference implementation. This reference implementation makes things simple for Java programmers who want to work with JXTA right away. If you are implementing JXTA on non-Java platforms, however, an understanding of these protocols is essential. Table 2 briefly describes the core set of JXTA protocols, covering discovery (how peers find each other), advertisement (how peers let other peers know about peer groups, pipes, and so on), communications via pipe, and peer group membership handling. All of the following protocols are based on exchange of XML messages over a transport. As such, they can be implemented on almost any platform, using almost any programming language.

The JXTA specification does not require that peers implement all of the above protocols. Any particular peer needs to implement only those protocols it actually uses.

Back to top

Some interesting properties of JXTA-based systems

Now that you have basic understanding of the theoretical building blocks of the JXTA platform, let's cover some interesting properties that are the consequences of the JXTA design.

Anything with an electronic heartbeat can become a JXTA peer

A minimal device with the ability to generate a text string can theoretically participate in a JXTA network (though not necessarily in every P2P application). How is this possible?

The simplistic device needs a surrogate peer on the P2P network. This surrogate can perform discovery, advertisement, and communications on behalf of the simplistic device (or many simplistic devices). The location of the surrogate can be hard-wired into the simplistic device. In this way, the simplistic device with the help of the surrogate can be a full-fledged peer on the JXTA network. For example, a GPS locator, strapped to a sea turtle and sending out JXTA messages wirelessly with location information, can become a peer on a JXTA network.

Order in a network with a nondeterministic topology

Another fascinating aspect of a typical JXTA network is its inherently nondeterministic topology/response structure. Computer users in general are accustomed to computer systems that are deterministic and synchronous in nature, and think of such a structure as the norm. For example, when our browsers issue a URL request for a Web page, we expect the output to appear shortly afterwards. We also expect that everyone around the world will be able to retrieve the same page from the same Web server using the same URL.

In the JXTA world, a specific resource request may not return for minutes, hours, or even days; in fact, it may never return at all. In addition, people from different parts of the world requesting the same resource are likely to get different copies of the resource from completely different servers. This leads to a question: what good is a system that is nondeterministic?

Inspiration from the grassroots software revolution

We need to look no further than popular P2P systems like Napster and Gnutella for the answer. Here are some big bonus features that make the loss of synchronicity and determinism worthwhile:

• High availability of content. Peers can obtain content from multiple servers, ideally reaching a nearby one that is up and running. The original source peer need not service every resource request; in fact, it does not even have to be up and running.
  
  
• Optimized use of network bandwidth. The concentrated localized traffic congestion typical of today's Web doesn't affect P2P networking.
  
  
• Lowered cost of content distribution. The P2P network can absorb contents and replicate it for easy access.
  
  
• Leveraged computing power from every node in the network. With asynchronous operations, you can issue many requests for many resources or services simultaneously and have the network do the work for you.
  
  
• Unlimited scalability. A properly designed P2P application can span the entire known connected universe without hitting scalability limits; this is simply not possible with any centralized scheme.

In a perfect JXTA world, we would perform asynchronous requests against a nondeterministic network. Does this concept seem bizarre to you?

Let's clarify with an example. Imagine a network-based music request service that operates over a JXTA-based P2P network. A peer submits multiple requests for music files and then checks back sometime later to see if the music request service in the peer group has found them. When we check the music request service sometime later, a few requested files have been found, but others cannot be located. The service's response in regards to those files is "Music selection and availability changes continuously; please retry your request later." This is an acceptable nondeterministic outcome: even though the service couldn't find a file, the same file may be available later if we submit the same request again, because peers that host the files we want may have come online.

When placed into such a concrete context, the concept of a nondeterministic network doesn't seem so strange any more. In fact, most of us can probably accept and work with such a music request service. Some of us my even be willing to pay a small fee for an automated agent that continuously monitors the availability of selected files and then fetches and stores copies for us. This is one of the great allures of P2P computing: the ability to leverage and share all connected resources that the world as to offer -- hopefully in an orderly and civil manner.

Having said all of this, the first few JXTA/P2P applications that break through commercially will probably boast determinism and synchronicity as their main features. This is a necessary transition because users' habits and market preferences do not change overnight -- and will not change without a compelling reason. The new P2P model will emerge slowly, and probably in hybrid form at first. One current example: edge-propagation-based network caching technologies such as Akamai are the norm these days on the deterministic, centralized Web. These technologies use P2P-style concepts to implement optimized delivery of content in a world of centralized servers.

Social impact and sticky intellectual property problems

The phrase we used earlier -- "orderly and civil" -- is where cutting-edge computing meets contemporary sociology. In fact, the phrase "orderly and civil" can be interpreted differently in different cultures, or even in different contexts within a single culture. This has caused tremendous controversy and debate in the copyright-sensitive world of intellectual property (IP) management. Because of the dominance of the parties involved and the long-entrenched market practices in content distribution, this controversy is not about to subside soon.

Much has been written already in popular and trade press. Sun's decision to not dictate policy in its JXTA implementation allows it to sail free and clear of this controversy -- leaving the onus on the shoulders of the pioneering early adopter of JXTA technology when working on content distribution. However, the community-based evolution of JXTA technology in this arena has the potential of ensuring a smooth balance of control between the IP owners and the public at large. The open JXTA community can serve as a forum where IP owners and technologists can work out their differences.

Back to top

JXTA in perspective: How it stacks up against .Net and Jini

Since its introduction, JXTA has been compared to every networking technology imaginable. Even respectable business journals have casually dismissed this innovation because it apparently doesn't stack up against major competitors' hype-laden flagship road maps. Project JXTA is a unique beast -- there is no existing point of reference to draw from when discussing it. As such, it must be evaluated independently.

To be sure, JXTA's XML-based messaging is similar to Microsoft's .Net and SOAP technologies. But that is a very thin foundation for comparison. As more and more third-party protocols make use of XML, it will become obvious that just using XML as a message format says nothing at all about an actual networking technology. Comparing the high-level, policy-rich, Web-services-based infrastructure that is .Net to the low-level, fundamental, policy-neutral nature of JXTA is a futile exercise.

Project JXTA and the Jini project are also fundamentally different. Both of them have some similarity in higher-level interaction, enabling true distributed computing over a network. However, the similarity abruptly ends there. Because true distributed computing is still a futuristic vision, it is often easy to minimize the differences between the JXTA and Jini projects -- despite the fact that we would not do the same when comparing implementations of more established client/server or multitiered server technologies.

Obvious strategic differences between the two exist: JXTA started life as a completely interoperable technology (any platform, any programming language, any vendor). Sun is a mere contributor in the community. Jini is a Java-centered technology that Sun will integrate and deploy strategically in future product offerings. Sun will maintain a degree of control over Jini's evolution.

Without the support of the Java platform (code mobility, RMI, and so on), the utility of Jini is limited; JXTA, on the other hand, is completely independent of Java trappings. To put it another way: Sun is only positioned to facilitate the growth of JXTA, while Sun has a major stake in the growth of Jini. Over time, Jini will become the more introverted cousin of JXTA; it will be employed and deployed as an enabling embedded technology in many products. JXTA's destiny, on the other hand, will be dictated by the enthusiasm and ingenuity of the public community evolving the technology.

Back to top

The versatility of JXTA

By providing a base mechanism and not dictating policies, the JXTA foundation can be applicable and valuable to many P2P applications. Here are three more common scenarios:

• Users on peer machines searching for and sharing files, information, and content within peer groups
• Peers joining peer groups to use special services available only within specific peer groups
• Instant messaging systems between peers in a peer group, and across peer groups via gateways

Of course, the possible applications are endless, and many have yet to be invented or even conceived of. In future articles, we will set up JXTA and experiment with its command-line shell, create custom extensions to the shell, and design P2P application for a JXTA network.

Resources

• Part 2 of this series, "The JXTA command shell," takes you through a hands-on tour of the JXTA shell. You'll explore its command set and extend its capability by writing your own custom commands using the Java programming language. Part 3, "Creating JXTA systems," showcases JXTA's extension of the TCP/IP network and demonstrates that JXTA isn't bound by the constraints typical of client-server networks.
  
  
  
  
• Visit the official JXTA community to find the latest specifications, documentation, source, and binaries.
  
  
  
  
• Check out Professional Jini by Sing Li if you are interested in more details on Jini-based technology.
  
  
  
  
• The practice of peer-to-peer computing , a monthly developerWorks column by Todd Sundsted, provides an abstract view of P2P concepts and a hands-on learning experience using his own P2P application framework.
  
  
  
  
• For an alternate open source P2P system, see the Freenet project.
  
  
  
  
• Find more Java resources on the developerWorks Java technology zone.
  

About the author

		Sing Li is the author of Professional Jini and numerous other books with Wrox Press. He is a regular contributor to technical magazines and is an active evangelist of the P2P revolution. Sing is a consultant and freelance writer, and can be reached at westmakaha@yahoo.com.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Back to top