JXTA in a Nutshell

Chapter 4. Service Advertisement and Discovery

In the next few chapters, we’ll expand on the JXTA application interface and develop a complete JXTA application that is both a decentralized service and an application that uses the service. The complete example is spread out over a few chapters; we begin in this chapter by showing how to handle service advertisement and discovery. In later chapters, we’ll add the pipe communication between the service and application as well as handling some security issues.

An Auctioning Example

The example we’ll build will perform auctioning. Auctioning applications are great for demonstrating decentralized, P2P interactions between auctioneers and biders. The JXTA programming model can be applied with great simplicity to build a cost-effective and efficient auctioning system.

The Client/Server Auctioning Model

Auctioning systems are typically implemented with a centralized (client/server) auctioning server model (see Figure 4-1). The central auctioning server receives auction offers and bids, and matches them. While centralized auction architecture has some advantages, it presents some significant scalability, security, and reliability issues. The auctioning server needs to be scaled when the number of auctions and bid requests increase, as performance tends to decrease as more and more users are active on the system.

Figure 4-1. The client/server auction architecture

The auctioning server is a single point of failure for the entire system: if the server goes down, all transactions are stopped. While clustering and failover technologies are typically used to address single server failures, there is a tremendous cost associated with maintaining and growing a centralized server infrastructure. One cannot expect to continue to grow centralized server computing facilities without reaching a point at which too much complexity is introduced. Furthermore, as these facilities become larger, their level of unreliability is increased because more components can fail. Auctioning servers are also the perfect target for denial of service attacks as intruders and attackers can focus their effort on a limited set of servers to bring the entire system down.

Since all transactions are processed on the auctioning server, user information can be easily logged by the auctioning provider, potentially invading the privacy of the auctioneers or bidders. Auctioneer profiles can be easily captured and sold to marketing research companies. Sensitive user information (email or personal contact information) is typically maintained on the auctioning server, creating the possibility of an intruder accessing this information.

The P2P Auctioning Model

In a JXTA P2P model, things are different. When sellers and bidders have found each other, they do not need an intermediary to broker their transactions. Sellers and bidders can interact directly to finalize the transaction.

Using a P2P architecture for building an auctioning system provides a number of advantages:

Scalability

As the number of users increase in the system, performance will tend to increase. More peers will be available to participate and help other peers find new bids and auctions.

Reliability

The system has no single point of failure. Sellers and bidders can find each other even if a set of peers is down. A bidder can always bid on another auction if a previous seller is not responding.

Security

No centralized user database needs to be maintained; each peer can maintain its own private information so that it is not accessible by any other peer. Since transactions occur directly between peers, it is difficult to trace and record user patterns.

Robustness

Since all information is decentralized, it is very difficult to perform a denial of service attack. Every peer is interchangeable; if one peer is attacked, users can go to another peer.

In the next few chapters, we’ll develop an auctioning system within the JXTA P2P model. We want to create an auction service in which restaurants can advertise their food to hungry people who want to bid for it. The architecture of this example is shown in Figure 4-2. In this architecture, there are the following entities:

The peergroup (RestoNet)

The RestoNet peergroup defines the scope of interaction and discovery between all peer entities involved in the restaurant auction. It is composed of all the peers that participate in the auction. Peers must join this peergroup to participate in the auction as either restaurant sellers or bidders.

Restaurants (RestoPeers)

Restaurants provide dining services. They discover and join the RestoNet peergroup, advertise their food services, and receive bids for their services. Restaurants respond to the dining auctions they can satisfy.

Hungry individuals (HungryPeers)

Hungry individuals are searching for a place to eat. They will join the RestoNet peergroup in order to discover restaurants. They will then publish dining requests and wait for a possible bid from one or more restaurants. Individuals will typically select restaurants depending on a number of criteria (price, food type, distance, and time); they are typically looking for the best offer and the best food.

Figure 4-2. The P2P auctioning architecture

While a P2P architecture such as JXTA provides many advantages in the implementation of an auctioning system, some problems must still be addressed. Since there are no centralized services, auctioneers and bidders need to find each other without relying on costly network-crawling techniques. Lost connectivity between certain peers may partition the network, precluding one side of the network from performing transactions with the other side. Usage of the system is difficult to track and monitor.

These problems can be addressed in many ways, resulting in an efficient P2P auctioning system. In our examples, we will show how JXTA features help.