JXTA in a Nutshell

Why JXTA?

The rationale for JXTA has two facets. The first is the advantage of a P2P architecture for many applications. Take the auctioning example we used at the beginning of this chapter. We love the centralized auction services provided by eBay (and others) as much as anyone, but that model isn’t well-suited for the type of auction described above.

No single factor determines when a P2P architecture is appropriate. At the risk of overwhelming you with buzzwords, we can say that a P2P architecture should be considered whenever you require scalable, robust, dynamic, fault-tolerant, spontaneous, self-organizing network computing. P2P architectures achieve buzzword compliance through mechanisms other than client/server computing:

Scalability

A web auction for specialized French fries available only at your local restaurant presents enormous scalability problems for a centralized system, which must handle requests and responses from every conceivable restaurant and potential diner. The service can segregate requests, but this isn’t easy: the granularity the service uses to segregate the requests will directly affect the quality of the service it provides. And such a segregated service will inevitably be problematic for users on the segregation boundary. For example, if the service is segregated by zip code, users may be directed miles away within the same zip code when a closer choice is available a few blocks away in a different zip code.

A P2P system has a much easier time of it: the diner can discover nearby services automatically and at an appropriate scale. Since no centralized system monitors everything, there are no problems with system capacity: users of the service monitor nearby services in which they are interested and discard other information.

Robustness

As all computer users can attest, network computing is inherently unreliable: connections drop, servers crash, companies go out of business, and so on. Web search engines are useful entities and quite good at what they do, but they often lead to dead links and moved documents. We’d hate to direct our diner three miles out of his way to a restaurant that closed last week; it would be much better if we can direct him only to open restaurants. Similarly, we’d hate for our diner to go hungry because the restaurant auctioning server has gone down or is being subjected to a denial of service attack.

In a P2P architecture, it’s easier to deal with the vagaries of the network. If one particular restaurant goes offline, it can be dropped from the community. And since there’s no centralized resource controlling everything, the P2P community is less affected by network failures or denial of service attacks. These problems will still affect individual participants in the P2P community, but the failures they cause will not have a widespread effect on others within the community.

Dynamic behavior

P2P applications discover services and other resources dynamically and automatically when they are needed. There is no central registry of these services. This dynamic behavior allows scalability and robustness across the entire system, of course, and it also influences the way in which you must think about P2P applications. Resources may be available when you need them, but they may not; like the print shop posited above, they may be available just in time.

This adds a certain complexity to a good P2P application and would seem to place a big burden on the developer, who must explicitly cope with services that are not always available. In the end, however, this leads to better programs: a network is a changing entity, and applications that embrace and account for those changes are better suited to run in that environment.

Fault resistance

Well-written P2P applications that take advantage of the dynamic nature of the network have a degree of fault resistance that most applications do not: the P2P application is tolerant of faults in other services and in the network. Fault tolerance often implies a level of hardware redundancy; that definition does not necessarily apply to JXTA (though there is no reason, of course, why a JXTA service could not run on fault-tolerant hardware).

Spontaneity

All of our examples at the beginning of this chapter had a certain degree of spontaneity to them. This is a natural outgrowth of the dynamic behavior of a P2P community; it gives an important advantage to a P2P architecture, particularly when participants in the community are mobile.

Self-organization

Because they do not rely on a central registry, P2P communities are self-organizing. As our diner contacts others, they can self-organize into a group that can leverage their buying power when approaching a restaurant. In a general sense, a P2P community is organized around a group of peers who are interested in the same service(s).

As we develop sample JXTA applications later in this book, we’ll expand on these features of a P2P architecture.

The second facet of the JXTA rationale stems from what JXTA gives us: a common platform on which P2P applications can be built. There are several popular P2P applications in use today: various instant messaging platforms, file-sharing systems such as Gnutella, and so on. Traditionally, these applications have been developed from the ground up and are incompatible with each other; users in one P2P community are isolated from users in a different community. JXTA seeks to provide a common platform on which P2P applications may be built.

The use of a common platform allows P2P applications to share information easily. In addition, the JXTA platform allows developers to create P2P applications easily, since the JXTA protocols provide an easy means for dynamic discovery, message passing, and other core features of P2P architecture. In fact, JXTA provides a true P2P platform on which applications can be built: most of the applications that are considered P2P applications do not have all of the advantages we listed above. Napster and AOL Instant Messaging, two of the most popular P2P applications, rely on centralized registries; they suffer somewhat in the areas of robustness and fault tolerance, where true P2P applications can excel. JXTA allows you to develop true P2P applications.