- Protocol and API
- JXTA Goals
- JXTA Peer and Java
- Overview of the JXTA Protocols JAVA API
- Summary of Java API for JXTA Protocols
- Where JXTA Applications Begin
- The Peer
- Starting JXTA
- Peer Discovery Protocol API
- Peer Resolver Protocol API
- Peer Information Protocol
- Peer Membership Protocol
- Pipe Binding Protocol API
- Peer Endpoint Protocol
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Peer
A peer is an identification of a specific instance of JXTA. The peer is associated with just about everything because it represents the identity of the platform. The concept of peer is similar to the way a computer is named on a LAN, except that the name is not guaranteed to be unique. As a way to make sure that peers are unique, there is a peer ID. The peer ID is generated like other IDs.
The concept of peer ID is used because there are multiple methods to reach a peer, so a fixed address or name is not that useful. Also, in the case of computers behind security barriers such as firewalls or NATs, the actual computer name or address is quite useless.
Peer ID
The peer ID is created during the initial configuration of the JXTA platform. The Configurator class creates a new PeerAdvertisement and calls the advertisement's setPeerID method with the ID built by the IDFactory. The following line shows how the factory is used. As you can see, the World group ID is used in the call. What this does is register the ID as a member of the World group:
IDFactory.newPeerID(PeerGroupID.worldPeerGroupID)
Remember that when a peer is a member of a group, the peer can be located via discovery by another peer in that group. All peers are members of the World group, so all peers can see each other from the World group discovery service. The reason that the world peer group is used is to associate the ID with the group to which it belongs.
Peer Classes
Peers are represented by a peer advertisement, which in the Java JXTA API is represented by the PeerAdvertisement class. In the Java implementation, the total implementation of a protocol is usually separated into two different packages. In this case, there is the PeerAdvertisement class that has methods that pretty much match the peer advertisement's XML specification. The PeerAdv class adds additional features used to complete the Java implementation. Figure 3.3 shows the PeerAdvertisement, its implementation, and associated ID classes.
){kind=link}
Note
There are two different types of packages found in JXTA applications. These are an API and an implementation. The API is mostly abstract classes or interfaces. Some general functionality is provided in the API if the functionality is generic. Packages that are in the implementation have the platform specific code. Because the API is young, not all of the implementation is reflected by the API; so some parts of the implementation need to be accessed for some applications to work properly. In general, you should not need to use the implementation class explicitly unless it is a true extension of the API. This is true for the GenericPeerGroup class that adds the ability to look at child groups (discussed later in this chapter).
Figure 3.3 Peer classes used by JXTA