Is there some client server system java programs I can look at?

I'm currently doing a project where I'm going to build an application (created in Java) alongside a database. So this will be client server system i'm developing. Part of my project would be to research existing client server systems.

So I was wondering is there any good client server systems, that was built using Java, that I can take a look at? I'm interested in novice to professional programs, but not something too complicated that i won't be able to get my head around.

I want to discuss them in my research and see 开发者_运维问答how they work.

Thank you.

---

Some resources in a distributed system may require mutually exclusive access. A locking service is a service responsible for allowing or denying clients such exclusive access. In this project, you will implement a simple, high-availability, replicated locking service.

Client-server locking. The locking service is composed of two software components: a client-side library, and a server. The server is the one responsible for maintaining the information regarding who has been granted access to which resource. The client-side library { which you should implement { is responsible for making the service available to clients who need to use it. The library should provide clients with two functions: int a c q u i r e ( int c l i e n t i d , int r e s i d ) ; int r e l e a s e ( int c l i e n t i d , int r e s i d ) ; The first function allows a client identied by clientid to request exclusive access to a resource identied by resid, while the second allows a client to release that exclusive access. You can assume both clients and resources to be uniquely identiable by some numeric id. Further, the acquire call should return: 2 if the server is currently unavailable, 1 if the client calls acquire on a resource that has already been acquired by another client; or 0 if the server is up, and access to the resource has been granted (or already granted to this client).

The release call has similar return values: 2 if the server is currently unavailable; 1 if the client calls release on a resource for which it has never called acquire ; or 0 if there server is up, and the release operation is successful.

Replicated server. To allow high availability, you should make your server redundant. You should do that by transforming your \server" into a set of processes { one master, plus n replicas. The replicas are to be kept synchronized with the master by means of a reliable multicast protocol.

Clients connect only to the master, issuing acquire /release operations directly to it. Whenever a new request arrives at the master, the master should multicast this request to all replicas. Upon receiving such multicast requests from the master, the replicas should update their internal state so as to reflect them. The main point of keeping the replicas synchronized is that if the master should fail, the system can continue running by having one of the replicas take its place. To ensure correct operation, your reliable multicast protocol should guarantee that, even in the presence of crash failures: 1. either all correct replicas deliver the message, or none does, and; 2. the only case in which the \or none" case is allowed is when the master crashes before any correct replica can deliver the message.

Note that we do not care about crashed replicas: these might deliver or not the message. To get this task done, we suggest you adapt the two-phase commit (2PC) protocol, but having the following in mind: unlike \regular" 2PC, crashed replicas do not cause the message to not be delivered, and the only case you need to worry about is when the coordinator crashes. Failover. When the master fails, a new master must take over. You should provide a mechanism for a new master to be put in place (e.g. a replica could accept a special \become master" message that can be issued by a client when the current master fails). Further, clients must somehow be able to contact the new master once it is in place. To make things simpler, it is acceptable to query all replicas at each request so as to discover which one is the master. 1 Server Assumptions. While implementing the server, you should make the following assumptions. 1. The set of replicas is xed, and replicas may crash, but replicas never recover; 2. the number of resources that can be acquired and released is xed, and known beforehand; 3. the underlying network is unreliable and does not guarantee FIFO (if you use UDP, you have to account for that).

Client Library Assumptions. 1. If the master crashes midway through a request, the acquire /release functions can return error code 2, and the client code can then keep retrying the request until a new master is in place;

1. the client library is supposed to perform failover properly once a new master has been elected; i.e., it has to be able to somehow nd the current master.