CSC8530 DISTRIBUTED SYSTEMS

grapedraughtΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 3 χρόνια και 11 μήνες)

89 εμφανίσεις

Randolph
1






CSC8530 DISTRIBUTED SYSTEMS

PROJECT 1: COOKIE SERVER



















Steve Randolph

October 7, 2003



Randolph
2

1.0 ABSTRACT

This project consists of the implementation of a distributed CookieJar service, in
which clients request messages from a server and t
he server responds by sending the
stored message for the requestor. It is implemented using Java
TM

Remote Method
Invocation (RMI) API, which allows separate processes (potentially running on separate
machines) to communicate. The client obtains a remote
object via the RMI registry and
thus invokes methods that support Cookie sets, requests, resets, and Cookie Server kill.

2.0 PROJECT DESCRIPTION

The project involved the design, development, deployment and testing of a
distributed system (DS). The purpose

of the system, although secondary to the primary
goal of the successful deployment of a DS, is to provide rudimentary Cookie Server
functionality. In this case, clients access and make use of a Cookie Server, which is
ostensibly resident on a separate ma
chine. Client
-
server communications are
accomplished via sockets and the TCP/IP protocols.

For an overview of the classes used in the design of this system and an
understanding of their interrelationships, please see the class diagram in the section
lab
eled ‘Diagrams’. The Cookie Server is implemented using Java
TM

Remote Method
Invocation (RMI) API. A CookieServer interface was developed, which contains 4
abstract methods to request, set, reset a Cookie and to kill the Cookie Server. This
interface ex
tends the Remote interface, which facilitates objects creation and access.

The CookieServer interface is implemented by the CookieJar class, which also
extends UnicastRemoteObject and thus permits remote access, skeleton and stub
generation and object/data

marshalling and unmarshalling. The CookieJar class provides
Randolph
3

detailed implementations to the 4 methods defined in the interface. In addition, this class
contains a main method that enables CookieJar objects to run when called via RMI. This
CookieJar cla
ss serves the role of the Cookie Server; an instance of this class is bound in
the RMI registry and is available to any client that requests it. Remote method
invocations are possible on clients once the remote object has been obtained via the RMI
registr
y. One notable feature is the security verification. To ensure that external access
(from other than the specific client performing the CookieServer transaction) has not
occurred, the CookieServer compares the local and remote state fields, which are
mai
ntained and incremented with each operation. Cases where the two fields do not
equate cause a security warning to be raised.

The CookieClient class serves as the client’s interface to the Cookie Server. It
provides a Graphical User Interface (GUI) that m
akes data entry and Cookie transmission
and receipt user friendly. This GUI is implemented using the Java
TM

Swing API. With
each activation of the Cookie Send button, the CookieClient accesses the remote
CookieJar object via the RMI registry and invokes
the appropriate method based on the
user’s selections.

Messages passed between the client and server are stored in objects of the Cookie
class. In order to permit the objects to be passed safely, this class extends the parent class
Serializable


consiste
nt data ordering is thus ensured so that marshalling and
unmarshalling do not affect the integrity of the objects. This class contains data fields for
each of the required fields in a Cookie: Type, id, local state, remote state, and message. It
provides
public methods to get() and set() each of the aforementioned private data fields.
The class also contains static integer constants that represent the Cookie type codes and
Randolph
4

that are utilized by both the client and server classes for ease of Cookie identif
ication and
processing.

All of the requirements in the initial specification have been met. The Cookie
Server has been successfully implemented using Java
TM

RMI; message passing between
client and server is supported and messages contain all of the requir
ed fields. Two
notable areas of requirements interpretation should be noted. The first is data persistence.
The specification does not specify the requirement for data persistence (Cookies are
preserved in the event of Cookie Server shutdown). For this

reason, this implementation
does not support data persistence; Cookies are stored in a Hashtable, which is not
preserved upon Server shutdown. However, in future versions of this implementation,
this functionality could easily be added via the replacemen
t of the Hashtable with a
FileWriter (accesses a flat file) or another more sophisticated means of permanent data
storage (e.g., JDB/ODBC database access or JAXP XML file access). Functionality of
the CookieServer would not be affected, which is also why
the simpler Hashtable strategy
was employed. The second area is the Kill method. The specification does not require
this method to be fully functional. Rather, an error message is generated indicating that
the feature is not available. In the code for
this implementation, the calls to
Naming.unbind() are present, but have been commented out. Future implementations
would require the lines to be un
-
commented and tested.

3.0 TEST DESCRIPTION

Test cases were developed for all possible conditions of each of

the 6 Cookie
types that are handled by the Cookie Server. The 4 use
-
cases (see Use Case Scenarios
and Diagrams in the section labeled ‘Diagrams’) were used as the basis for this testing.
Randolph
5

These are: Set Cookie, Request Cookie, Reset Cookie and Kill Cooki
e Server. The
remaining 2 Cookie types (Reply and Error Cookies) are an integral sub
-
set of the 4 use
-
cases whereby the server response is determined and, as such, were tested during primary
function testing. In all cases there were two methods of confir
ming success or failure of
the specific operation being tested: 1) GUI display of Cookies received from the server,
and 2) status messaging written to STDOUT on each of the two processes (client and
server). At each step, the contents of the Hashtable use
d to store the contents of the
Cookie Server are displayed, which permits verification of the success of each operation.

In an additional series of tests, the scalability of the system was confirmed by
running test cases of each of the 3 operations that co
uld possibly be adversely affected as
the number of users of the system grows. In the test section labeled ‘System Capacity
Test Cases’, each of the Set, Request and Reset Cookie methods are confirmed when the
system holds more than 26 users. Also, mult
iple client applications were started and
Server functionality was confirmed by setting the Cookie for a user on one client and
then requesting the Cookie for that same user on the other client. It was determined that
the Kill Cookie Server method functio
nality would not be affected by the number of users
contained on the system, and so this method was not included in the System Capacity
Test Cases.

4.0 TEST RESULTS

Each of the following results are documented (via screen captures) and presented
in the sec
tion labeled Test Data. For each test, the screen shot includes: 1) A test number
and description, 2) The CookieJar GUI, 3) The client
-
side JVM, and 4) The server
-
side
Randolph
6

JVM. In each of the latter 2 processes, the window is scrolled to permit visibility of

the
test results for the given test being run.

In all of the following test cases, test results were acceptable and the test was
deemed to have been passed successfully. The following summarizes the test conditions
that were run and the results obtained:

SET METHOD TEST CASES:

1.

User ID field blank


test passes


Error Cookie returned by the Server with the
appropriate error message displayed.

2.

Set Cookie for user with no Cookies
-

test passes


User added to the system and
a Reply cookie is returned by th
e Server with the appropriate confirmation
message.

3.

Attempt to set Administrator’s Cookie


test passes


Administrator’s Cookie is
not set and an Error Cookie returned by the Server.

4.

Set Cookie for a user that already has a Cookie


test passes


Cookie i
s updated
for that user and a Reply Cookie is returned by the Server with the appropriate
confirmation message.

REQUEST METHOD TEST CASES:

5.

User ID field blank


test passes


Error Cookie returned by the Server with the
appropriate error message displayed.

6.

Request a Cookie for a user with no Cookies on the System


test passes
-

Error
Cookie returned by the Server with the appropriate error message displayed.

7.

Request Administrator’s Cookie


test passes


Administrator’s Cookie is
returned by the Server via

a Reply Cookie.

Randolph
7

8.

Request a Cookie for a user that has a Cookie on the System


test passes


the
user’s Cookie is returned by the Server via a Reply Cookie.

RESET METHOD TEST CASES:

9.

User ID field blank


test passes


Error Cookie returned by the Server wi
th the
appropriate error message displayed.

10.

Invalid user ID (not “admin”)


test passes


Cookies are not reset and an Error
Cookie is returned by the Server.

11.

User ID correct (“admin”) and Password field blank


test passes


Cookies are
not reset and an E
rror Cookie returned by the Server.

12.

User ID correct (“admin”) and Password invalid (not “cookie”)


test passes


Cookies are not reset and an Error Cookie returned by the Server.

13.

User ID correct (“admin” ) and Password correct (“cookie”)


test passes


C
ookies for all users with the exception of the Administrator’s are reset and a
Reply Cookie is returned by the Server with the appropriated confirmation
message.

14.

Request Cookie for user to confirm proper reset (in test case # 13)


test passes


User’s Coo
kie was reset.

KILL METHOD TEST CASES:

15.

User ID field blank


test passes


Error Cookie returned by the Server with the
appropriate error message displayed.

16.

Invalid user ID (not “admin”)


test passes


Cookie Server not killed and an
Error Cookie is retur
ned by the Server.

Randolph
8

17.

User ID correct (“admin”) and Password field blank


test passes Cookie Server
not killed and an Error Cookie returned by the Server.

18.

User ID correct (“admin”) and Password invalid (not “cookie”)


test passes


Cookie Server not killed
and an Error Cookie returned by the Server.

19.

User ID correct (“admin” ) and Password correct (“cookie”)


test passes


Reply
Cookie is returned by the Server with the appropriated confirmation message
(notification that the Kill method is not fully functio
nal).

SYSTEM CAPACITY TEST CASES:

20.

Set Cookie for a new user with > 26 users on the system


test passes


User
added to the system and a Reply Cookie is returned by the Server.

21.

Set Cookie for an existing user with > 26 users on the system


test passes


U
ser’s Cookie is updated and a Reply Cookie is returned by the Server.

22.

Reset all Cookies for > 26 users


test passes


All user’s Cookies (except the
Administrator’s) are reset and a Reply Cookie is returned by the Server.

23.

Set Cookie for a new user with mu
ltiple client applications running


test passes


User added to the system and a Reply Cookie is returned by the Server.

24.

Request Cookie for the same user as added in Test Case # 23 but via a different
client


test passes


User’s Cookie is obtained (with

the same message as was
added in Test Case # 23) and a Reply Cookie is returned by the Server.

Randolph
9

5.0 CONCLUSION

This project proved to be both challenging and rewarding. Although the RMI API
is designed to abstract the intricacies of remote object creatio
n and access, there remain
many small but vital steps that are necessary for successful deployment. The first such
step is the issue of Security. The API makes clear the need for a SecurityManager


if
not present, one must be instantiated on both the cl
ient and server processes. However,
what is not so clear is the need for and contents of a policy file. This file is used by the
SecurityManager object and contains specific access rights for the sockets necessary for
client
-
server TCP/IP communications.

Getting the contents of this policy file correct
proved to be the most challenging aspect of the deployment.

Another challenging step was the issue of the hostname. Although this issue was
somewhat related to the security access permissions mentioned pr
eviously, there proved
to be some difficulty in correctly specifying the hostname of the machine on which the
RMI registry was running. Initial (and much repeated) attempts at using the specific IP
address of the host machine proved fruitless. Only after

refinement of both the policy file
and the hostname definition sections of the client and server code was successful remote
object access obtained. Use of the default host (“localhost”) and RMI port (1099) proved
most consistently effective.

One interest
ing observation made during the development of the CookieServer
system was the issue of serialization. Because the decision was made during the initial
design of the system to pass objects of the Cookie class during client
-
server
communications, there was

a need for the Cookie class to implement the Serializable
interface. This permits consistent transfer of the objects’ state (data fields and methods)
Randolph
10

during marshalling and unmarshalling on the client and server. This was not obvious at
first, but was e
asily identified as the solution and proved to permit effective and
repeatable inter
-
process communication.

As discussed earlier, a suggested extension of the system would be the inclusion
of data persistence. This would easily be accomplished by replacin
g the existing Cookie
storage medium (Hashtable) with a more permanent one. The use of Java API would
make the addition of a file or database as the means of storage, which would retain
Cookie state between Server shutdowns, essentially plug
-
and
-
play. An
other area for
investigation would be the deployment across machines. Testing during the validation
phase of this project was limited to separate processes running on the same machine
(processor). The functionality exists in its present state for the Coo
kieServer system to
be deployed in a truly distributed fashion


across machines. This would be an
interesting area for further exporation.

This project was both intriguing and rewarding. Although the functionality of the
CookieServer in itself is not ea
rth shattering, the technology utilized to achieve the
deployment and the possibilities it presents definitely are. Java
TM

RMI is one of the
major frameworks that support distributed processing and the wide variety of existing
technologies (e.g., web ser
vices) that are thus made possible. I am excited to begin
extending the techniques and strategies learned on this project during work on the second
project.

Randolph
11

6.0 SOURCES

Booch, James Rumbaugh, and Ivar Jacobson.
The Unified Modeling Language User
Guide
. B
oston: Addison
-
Wesley, 1999.

Coulouris, Jean Dollimore, and Tim Kindberg.
Distributed Systems Concepts and
Design
. Harlow: Addison
-
Wesley, 2001.

Grosso, William.
Java
TM

RMI
. Sebastopol: O’Reilly, 2002.

Seshadri, Govind.
Fundamentals of RMI
. Feb. 2000. 20 S
ep. 2003.
<http://developer.java.sun.com/developer/onlineTraining/rmi/>.

Lewis, and William Loftus.
Java
TM

Software Solutions


Foundations of Program Design
.
Reading: Addison
-
Wesley, 1998.