March 5, 2021
Hot Topics:

Overview of JXTA

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

JXTA Applications

Given the discussion so far, you may be confused as to what a JXTA application is. We have talked a great deal about how an application would do its work, but not where the code for the application resides.

To begin with, the general notion of an application has not changed. The key difference is that your JXTA application begins with starting the JXTA platform by accessing the world group. The world group is a group that is accessible to all peers. The world group is used to locate any peer or information that is available to all peers.

After the platform is started, your peer is a member of the default world group. From this point, you could begin your application with the world group and use all of the default services in the world group.

Group Membership

Group membership is probably one of the more important service protocols. Membership has two key features—authentication and credentialing. Authentication is the gatekeeper for the group, while credentialing is a token that ensures that authentication occurred. Both authentication and credentialing could be complex or simple, depending on how rigorous you need to be in your group.

Authentication is a multi-step process where the group requests that the peer supply information to join the group. The information supplied is then validated against the group's requirements for membership. The most obvious validation would be a user ID and password. Less restrictive systems may not ask for information or may be just a simple questionnaire. In the most restrictive systems, the authenticator may ask for an encrypted digital signature.

Credentials can also have various contents. Because credentials are passed around, they are usually fairly small to reduce overhead. In the least restrictive groups, the credential will just be a simple token. In groups that are paranoid about user identity, the credential would be a wrapper for encrypted digital signatures.

Peer Group Services

Peer groups are a context for services that interoperate in the group's domain of users. The peer group provides a set of services called peer group services that implement the JXTA protocols to supply the group with the necessary functionality. These services are not required, but most groups will probably have these services available for use by other services and applications. Groups can contain any set of services, and different groups can contain the same services of other groups.

Services are always associated with a group. You cannot have access to a service unless you are a member of the group. The services that a group supports are listed in the group advertisement.

The importance of the associating services to a group is to limit their scope. As a rule, services should not interact with peers not in their group. One reason is a matter of respect for peers that are not a part of the same group. There is also the practicality that there may be no reason to interact with peers outside of the group because they will not have the resources the service requires.

It is possible to write a service that will operate across groups. Such a service is unlikely because of the access service. The access will forbid any messages that are not properly marked as belonging to the group. Any service that goes across groups would need to have the cooperating access services.

If you need to interact with multiple groups, it is simpler to have an application that joins each group. There is no limit on how many groups a peer may join.

Core Services

Not all groups have the same advertisements, but it is expected that all groups support a set of standardized services that represent the core protocols. It is possible that none of these services are included or a completely different set of services would be provided. Without these core services, it would be difficult to interact with other peers. However, you could imagine a peer that uses a custom gateway that provides the functionality without requiring it on the peer itself. In addition to these core services, the creator of the group can add additional services. There are no specific requirements for these services. However, the services are expected to only work within the bounds of the group. If you use the core services for discovery and communication, limiting the scope to the group is automatic. The core services are described in the following sections.

Discovery Service

The discovery service provides access to Peer Discovery Protocol in the context of the group. It searches for peer group resources (peers, peer groups, pipes, and services). The search usually only searches within the group that contains this discovery service reference, so if a group is created and you use its discovery service, only advertisements published in that group will be found. Note, however, that this also depends on the implementation of the group that may expand the search scope to parent, sibling, or sister groups.

Some groups may inherit the search scope of the parent group. By default, the world group has access to all Peer advertisements and others created in its context. The default behavior of other groups is to search only in their scope.

Membership Service

The membership service provides access to a group-specific version of the Peer Membership Protocol. It is used as a gatekeeper to membership in the group. Peers wanting to join the group must fulfill the requirements of this service. The model is that of a membership application form where a document is submitted to the peer to be filled in and submitted for approval. If the peer is approved, the peer is considered a member of the group and is issued a credential that is used as proof of membership during communications. The membership service can extend the model from an application to external validation (such as a server that validates the user's initial credential) or by querying other peers or a manager peer for final approval (voting). We will cover group membership in more detail in Chapter 6, "Working with Groups."

Access Service

The access service is part of the membership service and is used to ensure that the peers are actually valid members of the group. This service uses the credential created when the peer joined the group. A peer receiving a request provides the requesting peer's credentials and information about the request being made to the access service, and the service determines if the context and credentials are correct; if so, access is permitted.

Peer Authentication Service

The authentication service uses credentials created by the membership protocol to verify that that messages are from a valid member of the group. The concept is that the application examines a credential for certain operations as needed to ensure that communications are with valid peers.

Authentication uses the credential as a standalone packet of information that is either self-authenticating or can be verified with other information the current peer obtained from another source.


The peer authentication service is not currently implemented in the Java JXTA platform.

Pipe Service

The pipe service implements Pipe Binding Protocol. The pipe service is used to manage and create pipe connections between the different peer group members.

Resolver Service

The resolver service implements the resolver protocol. The resolver service distributes queries to other resolver services running on peers within the group. The resolver also listens for the answers to these requests. We discuss this subject in more detail later in the chapter, in the "Resolver" section. We also use the resolver directly in Chapter 9, "Synchronizing Data Between Peers."

Monitoring Service

The monitoring service is used to allow a peer to monitor other group members of the peer group. The specification of what is monitored is left to the implementer. Monitoring can be used to collect data on peers to ensure they are following the group's rules for behavior or just to gather simple statistics.

Monitoring of peers is mentioned in the specification, but few people have implemented the concept. There also appears to be no API harness to use as a base. The implementation would need to be a service that you create and make a part of your group.

The reasons for having a monitoring service are many. The following are a few:

  • Keep a log of peer activities (downloads, contributions, and so on) that are sent to other peers. This relates to the next item.

  • You could manage a peer's ability to use the group. This is similar to Gnutella that prevents a peer from downloading unless they also share a minimum of their content. This can be expanded to include other information, such as up-time and other statistics that trigger certain rights. The opposite is that other peers receive these statistics before they interact with the peer, so that they can decide if they want to interact with the peer. This can be automated or just presented to the wizard behind the curtain.

  • Management of the user access is also important. In the specification, there is no mention of a revocation of a group membership. There is the idea of expiration and renewal. The problem is that you may not want to wait for expiration and want to remove a user early. This relates back to using a credential, which is a part of the specification and can be used to notice when a user is no longer valid.

  • Managing issues like those that cause problems in JXTA, including abuse of resources, falsification of identity, hacking/hijacking of the group for other purposes, and denial of service attacks against the group or some of its peers.

Note that some of these core services, such as discovery and membership, implement JXTA protocols. Others, such as the monitoring service, are not associated with a protocol, but are useful in a group context.

Customized Services

Core services are not necessarily specific implementations. Core services for the group can provide specific behavior for the group. For example, the membership service is likely a specific implementation.

Core Services Are Optional

Core services, besides being customizable, may not even be supplied. For example, the monitoring service may not be provided if there is no reason for monitoring. Also, the discovery service may not be required if the peer is already populated with all the advertisements it needs.

The only service that is most likely to be supplied is the membership service. The reason is that when a peer joins the group, the membership service is used. If a group does not need membership, you should use the Null membership implementation that allows the join functionality to operate but does not impose membership requirements.

Groups as Applications

One aspect of groups that may seem odd at first is thinking of groups as applications. A group application is not a real stretch of imagination and actually provides a lot of utility. The simple fact is that an object needs to exist to represent the group. Because there is an object, it would need methods to create, destroy, and manage resources. As mentioned, a group also has other services that need to be started and stopped. For all of these reasons, associating groups with applications is reasonable.

However, groups do not need to be associated with applications in a programmatic way. Groups can simply be used as a context to manage the groups of peers or groups of information. You do not need to add services to your groups and simply use the default services. For example, you could have an application such as SETI@Home implemented as a JXTA group with services for membership, communication, and reporting results. These would begin operation as soon as the group was joined and the default application in the group started. We will cover more of this in Chapter 3, when we discuss the Java implementation of groups.

Finding Information about the JXTA Network

When using the peer discovery protocol, there are three scoping parameters. These include the advertisement type (peer, peer group, or advertisement), a tag name to search with the contents to match, and a limit on how many advertisements for which to search. Only the first two are important to us here. The first scoping parameter specifying the type is useful to limit what you are looking for to just one of three different types of advertisements. The second, which allows you to specify a name and value, is then used to search each advertisement for matching XML tag and value.

The important qualifier is the name of the XML tag. This lets you choose a specific element of an advertisement, such as the name tag or an ID tag. This allows you to look up, for example, a named peer, a named group, or any other advertisement based on some tag name and its contents. Because the * wildcard is supported in the Java implementation, you can do more creative searches.

Passing Extra Data in Advertisements

It should be noted that many of the advertisements in JXTA can be expanded with additional XML tags. In some cases, these areas are clearly marked, such as the param section of the peer group advertisement. Be careful where you do put data and what type of tags you are using, because the messages may fail a syntax check. This version on JXTA does not support XML syntax checking but does have various places where unexpected XML could cause problems. You should only add data where allowed or use queries or pipes to pass information.

Adding data to advertisements that are outside of the protocol specification should only be done when you are implementing a variation on a protocol. For example, you could create a new transport type and add it to the group membership advertisement's TransportAdvertisement tag.

Caching and Aging of Advertisements

Advertisements are usually cached. Caching is not required by JXTA, but it is very useful and efficient to do so. Aging is a way to set an expiration time when an advertisement should be considered too old to be useful. Some advertisements can last a very long time, like peers, and others that are more volatile, like pipes.

There are two different ages—one local set by default to 365 days and one remote age set to 2 hours. The assumption would be that if the peer created the advertisement, it has value and should have a long lifetime. Advertisements coming from remote systems are suspect and should expire much sooner. Because advertisements are renewed, the shorter lifetime is moot unless the advertisement was really temporary or its peer unstable.


Advertisements are the language of JXTA. All of the information about peers, groups, services, and other JXTA constructs are defined by an advertisement. The following is a quick list of the main advertisement types:

  • Module Class Advertisement (MCA)—Defines the specific version of a module.

  • Module Specification Advertisement (MSA)—Defines the module with a cross platform definition that includes behavior.

  • Module Implementation Advertisement (MIA)—Specific instance of a module on a platform.

  • PipeAdvertisement—Defines. See PipeAdvertisement; a pipe available in a group or at a peer.

  • PeerGroupAdvertisement (PGA)—Defines the peer group. The group also defines the services, endpoints and other information.

  • PeerAdvertisement (PA)—The peer advertisement defines the peer.

  • EndpointAdvertisement—The endpoint advertisement defines a communications protocol and the termination.

We'll discuss these in more detail in the next section, Details of the Advertisement Types."

There are really only three classifications of advertisements. These are peers, peer groups, and everything else. It is difficult to say why these are the highest level, but the cache management system in the Java implementation uses these types to separate the advertisements into three separate directories.

Details of the Advertisement Types

Now we will look at each of the advertisements that JXTA uses in detail and talk about what they mean. We will also show some XML so that you will know how to recognize advertisements when debugging.

Peer Group Advertisement

The peer group advertisement is used to define both an identification of a group and the services of that group. Peer group advertisements have the following information:

  • Name—Name of the group.

  • Description (Desc)—Description of the group.

  • PeerGroup ID (GID)—An ID that is associated with this instance of this group.

  • PeerGroup Specification ID (MSID)—A Module Spec ID that this group uses. The ID is used to locate a module that references the services this group uses.

  • Service (Svc)—Optional list of elements that associate a group service, denoted by its Class ID (the value of an MCID element), and parameters via Parm elements.

The following is an example of an XML PeerGroupAdvertisement for a peer group created in Chapter 9:

<?xml version="1.0"?>
<jxta:PGA xmlns:jxta="http://jxta.org">
   Root application group

Peer Advertisement

A peer advertisement is almost identical to a peer group advertisement. The key difference, of course, is its type.

  • Name—Name of the peer.

  • Description (Desc)—Description of the peer.

  • PeerGroup ID (PID)—An ID that is associated with this peer instance.

  • Debug Flag (Dbg)—Optional tag used for debugging.

  • Service (Svc)—Optional list of elements that associate a group service, denoted by its Class ID (the value of an MCID element), and parameters via Parm elements. In most implementations, this will hold data that details information used to converse with the peer.

The following is an example of XML PeerAdvertisement. The service defined in this example defines the parameters for the MCID that references the default implementation for a peer. The data includes the endpoints for TCP, the group, and an HTTP ID used by an HTTP gateway. The second MCID refers to the implementation of secure pipes and defines a certificate:

<?xml version="1.0"?>
<!DOCTYPE jxta:PA>
<jxta:PA xmlns:jxta="http://jxta.org">
   Super Chicken


Modules are definitions of services and applications available on a peer or in a peer group. Modules are used to define the code to be executed. To ensure that different peers written with different languages, versions, and operating systems, modules are defined with three different XML advertisements:

  • Module Class—Defines the specific version of a module.

  • Module Specification—Defines the module with a cross platform definition that includes behavior.

  • Module Implementation—Specific instance of a module on a platform.

Each advertisement is used to narrow the final implementation used by the peer. However, only the respective IDs may be available and no true advertisement available on the general network. The reason is that some modules are not public or they do not have different versions or implementations. Instead, the advertisements are internal to the peer and only referenced by their identifiers as needed. The following three sections define the detail of the different module advertisement types.

Page 4 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