The Jxta solution to P2P

Sun's new network computing platform establishes a base infrastructure for peer-to-peer application development

Today's Internet is witnessing a revolution. A revolution that strives to change one of its basic features. A revolution where network endpoints -- or clients, such as desktop PCs, mobile phones, PDAs, and the like -- are demanding better network status. A revolution fueled by applications like Napster and Gnutella, applications that bring an end to a server-dominated Internet. A revolution hailed as P2P.

P2P (or peer-to-peer) networking is a network model where, depending on an operation's context, any node can operate as either a server or a client. P2P provides certain interesting capabilities not possible in traditional client/server networks, which have predefined client or server roles for their nodes.

In this article, I introduce you to P2P networking and compare it with client/server networking. I also introduce you to Jxta (pronounced jux-ta), a P2P computing platform pioneered by Bill Joy, Sun Microsystems' chief scientist and corporate executive officer; currently, Jxta is being molded by hundreds of open source developers. Jxta holds tremendous promise for the P2P world. It defines a set of protocols that developers can use to build almost any P2P application. At the same time, these protocols are flexible enough to be easily adapted to application-specific requirements. While Jxta does not dictate any particular programming language or environment, Java could potentially become the language of choice for P2P application development for obvious reasons: portability, ease of development, and a rich set of class libraries.

P2P: An overview

Today, the most common distributed computing model is the client/server model. Figure 1 depicts the typical client/server architecture.

Figure 1. The client/server model

In the client/server architecture, clients request services and servers provide those services. A variety of servers exist in today's Internet -- Web servers, mail servers, FTP servers, and so on. The client/server architecture is an example of a centralized architecture, where the whole network depends on central points, namely servers, to provide services. With no servers, the network would make no sense; without them, how would Web browsers work? Regardless of the number of browsers or clients, the network can exist only if a server exists.

Like the client/server architecture, P2P is also a distributed computing model, but there is an important difference. The P2P architecture is a decentralized architecture (see Figure 2), where neither client nor server status exists in a network. Every entity in the network, referred to as a peer, has equal status, meaning that an entity can either request a service (a client trait) or provide a service (a server trait). Figure 2 illustrates a P2P network.

Figure 2. The peer-to-peer model

Though peers all have equal status in the network, they don't all necessarily have equal physical capabilities. A P2P network might consist of peers with varying capabilities, from mobile devices to mainframes. A mobile peer might not be able to act as a server due to its intrinsic limitations, even though the network does not restrict it in any way.

Both networking models feature advantages and disadvantages. You can visualize from Figure 1 that as a client/server network grows (that is, as more and more clients are added), the pressure on the central point, the server, increases. As each client is added, the central point weakens; its failure can destroy the whole network.

A P2P network delivers a quite different scenario. Since every entity (or peer) in the network is an active participant, each peer contributes certain resources to the network, such as storage space and CPU cycles. As more and more peers join the network, the network's capability increases. Hence, as the network grows, it strengthens. You won't find that kind of scalability in client/server architectures.

A P2P network also differs from the client/server model in that the P2P network can be considered alive even if only one peer is active. The P2P network is unavailable only when no peers are active.

You pay the price for the advantages a P2P network offers, however. First, managing such a network can be a nightmare compared to managing a client/server network, where administration is only needed at the central points. Therefore, the enforcement of security policies, backup policies, and so on proves complicated in a P2P network. Second, P2P protocols are much more "talkative" -- as peers join and exit the network at will -- than typical client/server protocols. This transient nature can trigger performance concerns. (See "Bandwidth Barriers to Gnutella Network Scalability" for more information.)

The Jxta solution

Different protocols, different architectures, different implementations. That accurately describes current P2P solutions. Currently, developers use diverse methodologies and approaches to create P2P applications. Standards, abundant in the client/server world, are noticeably absent in the P2P world. To tackle this deficit, Sun developed Jxta.

From the Jxta vision statement:

Project Jxta is building core network computing technology to provide a set of simple, small, and flexible mechanisms that can support P2P computing on any platform, anywhere, and at any time. The project is first generalizing P2P functionality and then building core technology that addresses today's limitations on P2P computing. The focus is on creating basic mechanisms and leaving policy choices to application developers.

Jxta strives to provide a base P2P infrastructure over which other P2P applications can be built. This base consists of a set of protocols that are language independent, platform independent, and network agnostic (that is, they do not assume anything about the underlying network). These protocols address the bare necessities for building generic P2P applications. Designed to be simple with low overhead, the protocols target, to quote the Jxta vision statement, "every device with a digital heartbeat."

Jxta currently defines six protocols, but not all Jxta peers are required to implement all six of them. The number of protocols that a peer implements depends on that peer's capabilities; conceivably, a peer could use just one protocol. Peers can also extend or replace any protocol, depending on its particular requirements.

It is important to note that Jxta protocols by themselves do not promise interoperability. Here, you can draw parallels between Jxta and TCP/IP. Though both FTP and HTTP are built over TCP/IP, you cannot use an FTP client to access Webpages. The same is the case with Jxta. Just because two applications are built on top of Jxta doesn't mean that they can magically interoperate. Developers must design applications to be interoperable. However, developers can use Jxta, which provides an interoperable base layer, to further reduce interoperability concerns.

XML in Jxta

Undoubtedly, the first step towards providing a universal base protocol layer is to adopt a suitable representation that a majority of the platforms currently available can understand. XML is the ideal candidate for such a representation. The Jxta developers recognize that XML is fast becoming the default standard for data exchange. XML provides a universal, language-independent, and platform-independent form of data representation. XML can also be easily transformed into other encoding. Hence, the XML format defines all Jxta protocols.

Although Jxta messages are defined in XML, Jxta does not depend on XML encoding. In fact, a Jxta entity does not require an XML parser; it's an optional component. Just think of XML as a convenient form of data representation used by Jxta. Smaller entities like a mobile phone might use precompiled XML messages.

Understand the Jxta jargon

Before proceeding any further, let's quickly look at the various concepts in Jxta.

Any entity on the network implementing one or more Jxta protocols. A peer could be anything from a mainframe to a mobile phone or even just a motion sensor. A peer exists independently and communicates with other peers asynchronously.
Peer groups
Peers with common interests can aggregate and form peer groups. Peer groups can span multiple physical network domains.
All communication in the Jxta network is achieved by sending and receiving messages. These messages, called Jxta messages, adhere to a standard format, which is key to interoperability.
Pipes establish virtual communication channels in the Jxta environment. Peers use them for sending and receiving Jxta messages. Pipes are deemed virtual because peers don't need to know their actual network addresses to use them. That is an important abstraction.

Both peers and peer groups can offer services. A service offered by a peer individually, at a personal level, is called a peer service, a concept equivalent to centralization. No other peer needs to offer that service; if the peer is not active, the service might become unavailable.

Peer groups offer services called peer group services. Unlike peer services, these services are not specific to a single peer but available from multiple peers in the group. Peer group services are more readily available, because even if one peer is unavailable, other peers offer the same services.

Codat (Code/Data), in Jxta, means content that could be either code or data. Codats can be published, discovered, and replicated if necessary.
An advertisement publishes and discovers any Jxta resource such as a peer, a peer group, a pipe, or a codat. Advertisements are represented as XML documents.
Identifiers play a key role in the Jxta environment. Identifiers specify resources, not physical network addresses. The Jxta identifier is defined as a URN (Uniform Resource Name). A URN is nothing but a URI (Uniform Resource Identifier) that has to remain globally unique and persistent even when the resource ceases to exist (see Resources for more information on URNs and URIs).
World peer group
Every Jxta peer is, by default, a member of the world peer group. Each Jxta peer intrinsically knows the world peer group and can join this peer group, even if it can't find any other peers on the network. Even disconnected peers are members.
Net peer group
On a local network, the network administrators can usually configure a peer group that every peer on the network can join: the net peer group. This group resembles a DHCP (dynamic host configuration protocol) service. The net peer group provides peers with a global connectivity according to restrictions imposed by the administrators.
Rendezvous peers
A rendezvous peer is a special peer that stores information about other peers it knows about by caching these known peers' advertisements. Thus, a rendezvous peer can help peers discover other peers in the network. Rendezvous peers can also forward discovery requests to other rendezvous peers.
Endpoints are destinations on the network and can be represented by a network address. Peers don't generally use endpoints directly; they use them indirectly through pipes, which are built on top of endpoints.
Anything that moves packets around the Jxta network is called a Jxta router. Not all peers need to be routers. Peers that are not routers must find a router to route their messages.

The Jxta protocols

The key to Jxta lies in a set of common protocols defined by the Jxta community. These protocols can be used as a foundation to build applications. Designed with a low overhead, the protocols assume nothing about the underlying network topology over which an application that uses them is built.

1 2 3 Page 1
Page 1 of 3
How to choose a low-code development platform