Distributed Java Application Development – Part 5

In this article we will explore Server Group membership/Group communication/Service Registry and Discovery capabilities which are required to build Application-Level Server-cluster-aware applications.

Group membership and Group communication

In distributed systems, application must be able to establish a dynamic process/server
group and track the status of all of the servers/processes in that group. Server group members should be able to communicate each other in the group. They should be able to exchange of data and commands across the server group.   Fig. A shows a example sample server group called “Server Cluster” with three members.

Server Group

Fig A. Server Group

Leader process/server And Task coordination

In distributed computing, leader election is the process of designating a single process as the organizer of some task distributed among several processes. This single process/server can be called as leader process.  After a leader election algorithm has been run, each server throughout the server group recognizes a particular, unique server as the task leader. This election process should be dynamic so that; if a leader server crashes, a new leader can be elected to continue processing application tasks.

This leader process can be used for controlling a task (or) distributed tasks.

Fig B. shows a sample cluster setup, in which component 2 selected as leader process and controls task distribution to other servers.

Leader Server

Fig. B Server Group with elected leader

Distributed Service Registry and Discovery

In SOA/distributed systems, services need to find each other. i.e. a web service might need to find a caching service, etc.. Clients may have to locate service which may be running at multiple servers.  Service Registry and Discovery is the mechanism by which severs register their services and clients find the required services.

Service Registry  provides a mechanism for Services to register their availability
Service Discovery system provides a mechanism for locating a single instance of a particular service. It also notifies when the instances of a service change (service deletion/addition/update).

Fig. C,D shows Service Discovery and Registry implementation using Apache ZooKeeper. In this all services register their availability with ZooKeeper and Clients (Web Server, API Server) can locate services using ZooKeeper.

Fig C. Service Registry and Discovery using ZooKeeper (photo courtesy:  http://engineering.pinterest.com/)

Fig C. Service Registry and Discovery using ZooKeeper (photo courtesy: http://engineering.pinterest.com/)

Fig. D Server Group with  ZooKeeper

Fig. D Server Group with ZooKeeper

Some of the open-source java based tools which can be used to implement above capabilities are

Apache ZooKeeper
Apache Curator
Apache Helix
Norbert.

References:

http://www.ibm.com/developerworks/library/bd-zookeeper/
http://www.ibm.com/developerworks/library/j-zookeeper/
http://engineering.pinterest.com/post/77933733851/zookeeper-resilience-at-pinterest

Advertisements
This entry was posted in Application Clustering, Distributed Systems, java and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s