Client/Server Architecture for PAC2

cabbagewheatInternet και Εφαρμογές Web

13 Νοε 2013 (πριν από 3 χρόνια και 5 μήνες)

245 εμφανίσεις





1



Client/Server Architecture for PAC2






Computer Science Honours Report

Author Jun Zhang, 2003



(The report displayed here is not the final properly formatted
version.)





2



Abstract

PAC2 is a multi
-
user E
-
learning software for the analysis of audio and vide
o
documents. PAC2 is designed to address the functionalities of handling learning
objects and their segments, attaching descriptions to the segments, performing queries
on the descriptions for locating desired segments, as well as the full support of acces
s
control on accessing and sharing data. Java technology, including Java Database
Connectivity (JDBC) and Java Media Framework (JMF), and relation database
technology were used to develop PAC2.


In the current implementation of PAC2, there are two major de
ficiencies. One is a
security issue

The information about the databases that are used by the PAC2
system to store the information of the PAC2 users and other application data is saved
in a text file, and any person can access this text file from the local

computer. The
other is the fact that the PAC2 system lacks communication among the PAC2 systems
running on different computers.


Investigation has shown that the PAC2 system can be extended to a client/server
architecture to solve these two problems.


Thr
ee Java APIs (Java Socket, Java RMI, Java Servlet) that can be used to implement
client/server architecture have been investigated in this project. Java RMI was
selected as the best solution for an extension of PAC2 based on the comparisons
among these thr
ee Java APIs and the specific requirements of the PAC2 system.


A Mini PAC system has been designed and implemented using the Java RMI
technology to demonstrate how the client/server architecture can solve the two
problems of PAC2. this Mini PAC system sim
ulates all the user access control
functionalities of the PAC2 system and only provides an minimized audio and video
handling functionality.


Guidelines that show how to extend the entire PAC2 system using the Java RMI
technology following the principles o
f Mini PAC are also presented.





3



Chapter 1

Introduction

Nowadays, along with the rapid developing of computer programming technologies,
multi
-
user computer software becomes more and more popular. Such multi
-
user
software can provide different services to di
fferent users. During the running of a
multi
-
user system, some application data can be shared by all the users, but the other
data can only be accessed by a specific group of users. All the multi
-
user system must
integrate the functionalities of user manag
ement to achieve user validation and access
control. Most of multi
-
user systems take advantages of the modern database
technology to save/retrieve the information of users and the application data.


PAC2 system, developed by Chen during his master’s proje
ct in Massey University
(Chen 2002), is one of this kind of multi
-
user system that can be used to support
learning by handling audio and video files as learning materials and attaching
descriptions to these AV files. PAC2 has four different kinds of users,

i.e. application
owner, set owner, trusted user, and general user. Different kinds of users have
different access rights to the functionalities and application data of PAC2. Relational
database technology is used by PAC2 to store the information about the

users, AV
files and the attached descriptions. Chen’s work was mainly focus on applying the
concepts of learning supporting to PAC2 and there is a security deficiency existing in
the current implementation of Pac2 as identified by Chen in his master’s the
sis


“…the database information (for log in) is presented as a text file at the hard disk of
each client computer” (Chen 2002).



The more detailed information on PAC2 and its existing problems can be found in
Chapter 2.


1.1

The goal of this project

The obj
ective of this project is to find a way to solve the security problem of PAC2.
This solution must be implemented in Java language since PAC2 is developed as a
Java application.






4



1.2

Research steps

The optimal way to do this project is to break it into steps a
s showed in the following
list:

1.

Learn PAC2;

2.

Find the way in which to redesign or extend PAC2 to solve the problem
related with its user management;

3.

Explore Java language and find the suitable APIs that can be used to
implement the solutions identified in S
tep 2;

4.

Design a relatively small system that simulates all the user management
functionalities of PAC2 and only provides a minimized function of AV files
handling to demonstrate the solution to PAC2;

5.

Implement this demonstrating system.


1.3

Organization o
f this report

This report is organized as follows:



Chapter 2: introduction on PAC2, mainly focus on the analysis of its user
management. Identifying its deficiencies;



Chapter 3: presenting my solution to PAC2 system


extend PAC2 to a
client/server archite
cture;



Chapter 4: introducing several Java APIs that can be used to implement the
new architecture of PAC2;



Chapter 5: presenting the design and implementation of Mini PAC system that
can be used to demonstrate how the new architecture can solve the proble
ms
existing in PAC2;



Chapter 6: conclusion, including the contributions of this project and the
future work.














5





Chapter 2

Review on PAC2


In this chapter a brief review on PAC2 system, as well as a detailed description on the
problems existing in
PAC2 are presented.

2.1

An Introduction to PAC2

PAC2, a java application developed by Chen and Heinrich (Chen, 2002), is a
computer based learning software for the collaborative annotation and analysis of
multimedia documents. It was designed to handle audio
and video files as learning
objects (“any digital resource that can be used to support learning, it includes anything
that can be delivered across the network”). By using PAC2, users can play AV files,
separate these AV files into segments, attach descript
ions to these segments, save the
information about the AV files, their segments, and the attached descriptions into a
database, perform database queries to fetch the desired segments and the
corresponding descriptions, modify the segments and their descrip
tions, update the
data saved in the database. PAC2 also supports access controls on accessing and
sharing description/retrieval data. Section 2.1.1 to 2.1.5 lists the main features of
PAC2.


2.1.1

Integration with relational databases

In PAC2, all the related d
ata are saved to or retrieved from relational databases. Users
can add/remove a database to/from PAC2 as long as they can provide the required
information to log onto a relational Database Management System (DBMS), such as
the host of the DBMS, the usernam
e and password to log into the DBMS.
Figure 2
-
1

shows the steps to add a new database to PAC2.


Following the operations described in
Figure 2
-
1
, a new “mypac” database and the
tables of this database will be created within the mysql DBMS located o
n the
“localhost” machine. All the information about this new database will be stored into a
text file (
DatabaseFile.txt
), see
Figure 2
-
2
. This text file is saved on the hard disk of
the user’s computer.





6




To remove a database from PAC2 system, the user has

to input the related data
including the DBMS username and password referred to that database. If the database
is removed successfully from PAC2, its data will be deleted from the

DatabaseFile.txt
” file.











Figure 2
-
1

How to add a new da
tabase to PAC2










Figure 2
-
2


DatabaseFile.txt
” file


DBMS host

Database name

JDBC driver

JDBC subprotocol

DBMS username & password

Step 1
: Press the “
Add Database

button in the “
PAC Login

睩湤潷Ⱐw桩捨⁩猠h桥⁩湩瑩a氠
睩湤潷w⁐䅃㈠Ay獴敭Ⱐ瑯I
activate the “
Add Database
Window
”.

Step 2
: fill in all the required
information, then press the “
Add DB

button in “
Add Database Window
”.





7



2.1.2

Users of PAC2

Another important feature of PAC2 is its user management. In PAC2, there are four
types of users, and they have different access level on the data saved in the databases.
They are:



Application owner
: the user who sets up a new database. The
application
owner

can add new users or remove existing users to/ from the PAC2 system.
For every new user, the
application owner

has to assign a unique pair of PAC2
username and password. The PAC
2 username and password of the
application
owner
are the DBMS username and password used to create the new database.
The PAC2 usernames, passwords, and access levels of all the users including
the
application owner

are stored in a table name “
pacuser
” of t
he database.



Set owner
: the user who sets up a new description set or query set. A
description/query set means a group of descriptions/queries, and these
descriptions/queries may refer to different learning objects or segments. The
set owner

can assign oth
er users as
trusted users

of the set or remove existing
trusted users

from the set. The
set owners

have full access right to the sets
they set up.



Trusted user
: the
trusted users

have the same access rights as the
set owners

except that they cannot assign

others as
trusted users
. A table named

trusteduser
” stores the information of all the
trusted users
.



General user
: the user who is not an
application owner
,
set owner
, and
trusted
user
. The
general users

only have a limited access right to the sets.


2.1.3

Va
lidation of users

All users have to log into PAC2 system using their PAC2 usernames and passwords
before they can use the application. See
Figure 2
-
3
.


The detailed background working to validate a PAC2 user is:



After the “
Log in
” button is pressed, the PA
C2 system first tries to connect to
the selected database using the information retrieved from the

DatabaseFile.txt
” file.





8





If the connection to the database was created successfully, the PAC2 system
will check the input PAC2 username and password against
the entries of the

pacuser
” table of this database.



If the pair of input PAC2 username and password exists in this “
pacuser

table, the application window is activated. Otherwise, an error message will
pop up to the user.














Figure 2
-
3

Log i
nto PAC2



Select a database, input the PAC2
username and password, then
press “
Log in
” bu
瑴潮o

ff⁴桥⁐䅃㈠畳O牮rme⁡n搠灡獳睯s搠dre⁣o牲ec琬⁴桥⁐䅃㈠
a灰汩ca瑩潮⁷楮摯眠o楬氠扥⁡c瑩癡瑥搮





9



2.1.4

PAC2 applications and user’s access rights

The PAC2 system provides varieties of services to the users, such as, user
management, setting new description sets and query sets, modifying the existing
description sets. For specific users, some appl
ications could be unavailable due to
their limited access rights. For example, a user cannot add or remove another user
since he/she is not the
application owner

and some users can only read other’s
description because their access rights are
READ_ONLY
. Th
e mechanism of this user
access control is that PAC2 system will check against the data retrieved from the

pacuser
” and “
trusteduser
” tables whenever the user asks services.
Figure 2
-
4

presents an example of PAC2 application.




Figure 2
-
4
PAC2 applicati
on window


2.1.5

A stand
-
alone system

Every user has to put the entire PAC2 program including the “
DatabaseFile.txt
” file
in his/her computer if he/she wants to use it. It can be viewed as a stand
-
alone system
if the factor of DBMS is not considered, i.e. only o
ne java virtual machine is needed
to get the whole PAC2 system running and the running PAC2 doesn’t need any help
from other programs, computers, or network.
Figure 2
-
5

presents a simple description
on the architecture of PAC2 system.





10























Figure 2
-
5

The architecture of PAC2 system


2.2

Limitations of PAC2

The current implementation of PAC2 has some weakness under two categories, one is
security issue and another is no communications and coordinates among PAC2
installed on different computers.


2.2.1

Security problem

In his master’s thesis Chen identified a security problem of PAC2 login mechanism
(Chen 2002). Since the “
DatabaseFile.txt
” file can be accessed from a local computer,
any person can use the information saved in it to log into the databas
e and
modify/retrieve data even he/she doesn’t have the correct username and password to
log into PAC2.


Chen made a suggestion to solve this security problem. His suggestion was using the
Java Cryptography Extension API to encrypt the contents of this tex
t file.


While his suggestion solve the problem of reaching the contents of the text file,
another security problem arises in this solution. It is very easy to get the PAC2 source
codes by implementing reverse engineering on the byte code files, i.e. the
.class files.
PAC2 system can be attacked either by finding the encryption key and algorithm from
the source codes or modifying some methods of the source codes, for example, the
JDBC

DatabaseFile

Java application

DBMS

AV file

PAC2

User’s computer





11



method which validates the PAC2 username and password can be modified so that

any pair of username and password is valid.
Figure 2
-
6

shows reconstructing java
source code from a class file of PAC2 using
cavaj

which is java decompiler and can
be downloaded from
http://d
ownload.com.com/3000
-
2417
-
10101180.html
.




Figure 2
-
6

Reverse engineering on java byte code


2.2.2

No communications among PAC2 on different computers

Another problem of PAC2 is that it is lack of communications among PAC2s on
different computers. When a data
base is added to or removed from a PAC2, there is
no way to inform the PAC2s installed on other computers about this adding/removal
operation unless sending the new “
databaseFilel.txt
” file to them.















12




Chapter 3

A New Architecture for PAC2



The sh
ortcomings mentioned above are inevitable in the current PAC2 system with a
structure illustrated by
Figure 2
-
5
. For example, there are no ways to prevent others
from reading the contents of “
DatabaseFile.txt
” file or modifying the program dealing
with dat
abase issues of PAC2. Thus a new structure is needed in order to overcome
the problems of PAC2. This chapter gives the new PAC2 structure


distributed
client/server architecture as one solution.


3.1

The New Distributed Client/server Architecture

Figure 3
-
1

depicts this new structure of PAC2 which has the following features:



The PAC2 program is separated into two parts, the server program and the
client program;



The machine holding the server program should be different from the machine
holding the client
program. These machines are connected via network;



Only the client program is accessible to the PAC2 users;



At any fixed time point, only one server program can be run, but more than
one client programs can be run simultaneously;



A bi
-
directional communica
tion exists between the running server program
and client program;



When a user creates a new learning object using an AV file which is located
on the user’s local computer, this AV file will be uploaded to the server
program automatically;



When a existing
learning object is referred by a user, the corresponding AV
file will be downloaded from the server program to the user’s client program;



The client program is in charge of creating user interfaces, getting user inputs,
sending message to and receiving mes
sage from the server program, uploading
AV files to and downloading AV files from the server program, and
presenting the result to the user;



The server program is in charge of receiving the messages from clients,
handling these messages including database

issues, and sending the results




13



back to the clients. How many and which client(s) can receive the results is
decided by the server program.

The uploading and downloading of the AV files are initiated, monitored, and
terminated by the java applications of
the client and server program. In the server
program, the java application reads data from and writes data to the

DatabaseFile.txt
” file. The DBMS could be located on any computer as long as it is
connectable to the server program.


3.2

Benefits of This New A
rchitecture


To implement PAC2 with such a distributed client/server architecture can solve the
two problems of current PAC2 system effectively.


In this new structure, not only the “
DatabaseFile.txt
” file, but also all the database
related operations incl
uding the user validation are inside the server program which is
inaccessible to the users. That means there are no ways to find the database
information or interfere with the operations on database outside the server program.
Although we still need protec
t the server program from network attacking, but this
belongs to the network security discipline and is beyond the cope of this project.


The server program has another role in this new structure, it acts as a bridge between
two different client programs,
as depicted in
Figure 3
-
1
(a). Via this bridge, the
communications among different PAC2 users can be achieved easily. For example, if
the server program receives a message to add a new database from one client
program, it will add this database to PAC2 sys
tem, write the information of this new
database to the “
DatabaseFile.txt
” file and inform all the running clients that a new
database has been added.











14


















































Figure 3
-
1

the distributed server
-
client architect
ure of PAC2

user

Client

program

user

Client

program

Server

program



DBMS

( a ) the new structure of PAC2 system

user

AV

file

Client program

AV
file

Input

Result

Downloaded from server

Message to server

Result from server

Uploaded to server

User’s computer

( b ) inside the client side computer

JDBC

AV

files

Server program

Java application

Database
File


DBMS

Message from client

Result to client

Upload from client

Download to client

( c ) inside the server program





15



3.3

Benefits of This New Architecture


To implement PAC2 with such a distributed client/server architecture can solve the
two problems of current PAC2 system effectively.


In this new structure, not only the “
DatabaseFile.txt
” file, but also all th
e database
related operations including the user validation are inside the server program which is
inaccessible to the users. That means there are no ways to find the database
information or interfere with the operations on database outside the server prog
ram.
Although we still need protect the server program from network attacking, but this
belongs to the network security discipline and is beyond the cope of this project.


Server program has another role in this new structure, it acts as a bridge between t
wo
different client programs, as depicted in
Figure 3
-
1
( a ). Via this bridge, the
communications among different PAC2 users can be achieved easily. For example, if
the server program received a message to add a new database from one client
program, it ad
ded this database to PAC2 system, wrote the information of this new
database to the “
DatabaseFile.txt
” file and informed all the running clients that a new
database had been added.






















16



Chapter 4

Java Implementation of Client
-
server
Architectur
e


Java, which is a portable, robust and secure language, is often proclaimed as the
premier tool for developing distributed client
-
server applications (Morrison 1997),.
Java’s binary
-
level portability gives Java a unique position in the world of distribut
ed
computing

the programmers are freed from having to worry about the differences
among platforms. Besides the portability, Java also provides a variety of tools to
develop sound distributed client
-
server systems.


This section presents brief overviews of
some of the facilities supplied by Java for
developing distributed client
-
server programs.


4.1

Sockets in Java

Computers on the network are commonly connected by the TCP/IP protocol. The
concept of socket represents a connection point into a TCP/IP network (M
orrison
1997), much like an electrical socket provides a connection point into the power
network for electrical apparatus. When two computers want to converse, one
computer termed the server opens a socket and listens for connections, the other
computer te
rmed client calls the server socket to start the connection. A socket has
two components: the server’s address and the port number.


Java language provides a simple
-
to
-
use socket facility in its
java.net

package.


4.1.1

Implementing client and server by sockets

To implement a server program that can receive data from or send data to a network,
it is necessary to create an object of
java.net.ServerSocket

and call its
accept( )

method to monitor a specific port(for example, 8080) and wait for a client program
conn
ecting to that port. Once a client program connects to this port, an object of
java.net.Socket

is returned by
accept( )
:



ServerSocket serverSocket = new ServerSocket( 8080 );

Socket socket = serverSocket.accept( );






17





Objects of
java.io.InputStream

and
java.io.OutputStream

can be acquired
from this socket object, as shown in the following codes:





These two streams are the ordinary Java io streams that can be used to send data to the
network by their
write( )

methods or receive data by their
read( )

methods.


In the client program, only an object of
java.net.Socket

needs to be created to call
t
he socket opened by the server:




The first parameter of the constructor is the address of the server, the second is the
port number.


Also, an input stream and an output stream, which can be used to receive data to or
send data from the server program,

can be acquired from this socket object using its
getInputStream( )

and
getOutputStream( )

methods.


Everything that the server program sends to the server output stream becomes the
content of the input stream of the client program, and all the output fr
om the client
program ends up in the server input stream.


4.1.2

Serving multiple clients

In any practical application, a server program needs to provide services to more than
one client program simultaneously. To achieve this concurrency goal, the
multithreadin
g facility of Java language has to be employed. A loop needs to be added
to the server’s program:



InputStream input = socket.getInputStream( );

OutputStream output = socket.getOutputStream( );


Socket socket = new Socket( “
localhost”, 8080 );

while( true ) {

Socket socket = serverSocket.accept( );


Thread thread = new MultiServer( socket );


thread.start( ); }






18



Whenever a new socket connection is established, that is, the call to the
accept( )

method is successful, the server program will launch a new thread to ta
ke care of that
new connection. The loop will just go back and wait for the next connection.


The services provided by the server program is defined in the
run( )

method of the
MultiServer

class which extends
java.lang.Thread

class, and this
run( )

method
is invoked whenever the
start( )

method is called within the loop described above.


Figure 4
-
1

presents a simple illustration of the server program serving multiple
clients.



















4.1.3

Advantage and disadvantage using sockets

The main advantage to

use sockets to implement a Java client
-
server application is
that the concept and implementation of sockets are simple to understand and there is
no complicated RMI( see Section 4.2 )or Servlets (see Section 4.3 ) APIs to learn. By
Client
program

Server
program


Thread


Thread

Figuer 4
-
1

Server progr
am creates multiple threads to serve multiple clients

Client
program

Client
program

1

2

2

3

3

1.

Client program calls

the socket opened by the server program to send or
receive data;

2.

Server program generates a new thread whenever a new clients connects;

3.

The thread provides the services to the client.





19



integrating Java multit
hreading, the server program becomes capable of handling
multiple clients.


There is one major disadvantage to use sockets. Although the initially implementation
is relatively simple, a complicated system using sockets can rapidly become very
complex and
sometimes force application designers become protocol designers as
well. For example, under the circumstance that the data sent by clients could be
strings or serialized Java objects randomly, a communication protocol has to be
designed, and this protocol
needs to be implemented by both of the client program
and server program so that the server program can recognize whether the incoming
data is a
String

or a Java object.



4.2

Remote Method Invocation( RMI )

Remote Method Invocation (RMI) is a Java mechanism (
Daconta 1998), packaged in
java.rmi
, which enables Java objects running on different Java virtual machines
(JVM) to communicate with each other, regardless whether or not they reside on the
same computer. It is designed to facilitate the remote communicati
ons between two
Java objects, and such communications can be implemented easily with very several
lines of codes. In addition, RMI takes advantages of object serialization, so Java
objects can be easily passed as parameters or return values between remote
Java
applications.

4.2.1

How does RMI work

RMI, as its name suggests, makes it possible for a Java object to call the methods of a
Java object that is located in another JVM (perhaps running on a different computer)
in precisely the same way that it calls a met
hod of a local Java object.


The following are some terms in RMI (Horstmann 2000). The object that makes the
remote call is termed
client object
,

the JVM on which it is running is termed
client
.
The object whose method is called remotely is termed
server
objec
t, the JVM on
which it is running is termed
server
. A
server object

must implement one or more




20



remote interfaces that are subclasses of
java.rmi.Remote

and declare the methods
that can be called remotely. A
stub

is a Java class generated by applying J
ava
rmic

tool (
rmic.exe

file in the standard Java download) to the
server object
class, and
resides on the machine of the
client object
. The parameters of the remote methods,
which could be serializable Java objects, are packaged into blocks of bytes by th
e
stub

using an encoding mechanism. This encoding process is called
parameter
marshalling
. A
skeleton

is the counterpart class of
stub

class, it is generated by
applying
rmic

to the
server object

class, but located on the machine of the
server
object
. The
server object
must register itself to a registry named
rmiregistry

so that
the
client object

can find it from this registry and call its methods remotely.


When a
client object

wants to invoke a remote method of the
server object
, the JVM
of the
client obj
ect

calls a local method of the
stub
. The
stub

builds an information
block that consists of:



An identifier of the remote
server object

to be used;



A description of the remote method to be called;



The marshalled parameters.

The
stub

then sends this block of

information to the
server object

via the network. On
the
server

side, the
skeleton

receives this information and performs the following
actions:



It unmarshalls the parameters;



It locates the object to be called;



It calls the desired method;



It captures an
d marshals the return value or exception of the call;



It sends a package consisting of the marshalled return value or exception back
to the
stub
.

The
stub

unmarshals the return value or the exception, and returns this unmarshalled
value to the
client objec
t

that called the remote method, or throws the exception.
Figure 4
-
2

shows the information flow of a remote method invocation (Horstmann
2000).


The process is obviously complex, but is completely automatic. Not only the
stub

and
skeleton

classes are gener
ated automatically by
rmic

tool instead of written by




21



programmers, but also these two classes are never used directly in either the client or
the server program.

In Java 2 platform, the
skeleton

is no longer necessary. The lower layer parts of RMI
architec
ture carry out the communications with the
stub
.

















4.2.2

Dynamic downloading

The
stub

classes must be available to the running
client object
. To achieve the goal,
one obvious way is to put the
stub

classes in the same local file system with the
cl
ient
object
. However, if the
server object

is extended and new classes for return types are
added, it would be a hard job to keep updating the
stubs

residing on the
client
. For
that reason, RMI is designed to allow automatic downloading of
stub

classes fro
m
other place. For example, the programmers can put all the
stubs

and the remote
interfaces that supports these
stubs

in a web server, whenever a
client object

starts to
run, it will first download these
stubs

from this web server and load them into its lo
cal
JVM.


Client Object

Stub

Skeleton

Call
stub

method
locally

Return value or
throw exception

Send marshalled parameters

Send marshalled return value or
exception

Call
server
object

method
locally

Client

Server

Figure 4
-
2

Data flow during a remot
e method invocation

Server Object





22



4.2.3

A simple client
-
server application with RMI

This section gives a simple RMI program that displays a string of “Hello World” to
the
client
’s console window to demonstrate how to develop, deploy, and run a client
-
server application using RMI.
Tabl
e 4
-
1

lists all the classes in this example and their
functionalities.


Table 4
-
1

Classes in the sample program

CLASS

FUNCTION

Hello

Remote interface implemented by
server object
(
HelloImpl
);

Declares the remote methods that can be called by
client object

(
HelloClient
).

HelloImpl

Server object

implementing remote interface of
Hello
;

Defines the remote methods declared by
Hello
;

HelloServer

Registers the
server object

(
HelloImpl
) to
rmiregistry
;

Starts the server side program.

HelloClient

Client object
;

Calls the
server object

(
HelloImpl
) by calling the methods of
Hello
;

Starts the client side program.


Generally, it needs six basic steps to complete a client
-
server project using RMI
(Allamaraju 2000):

1.

Defining the remote interface;

2.

Implementing the serv
er side;

3.

Implementing the client side;

4.

Compiling and generating
stub
;

5.

Deploying the application;

6.

Running the application.


Defining the remote interface

The remote interface extends
java.rmi.Remote

interface and is implemented by the
server object
. It decl
ares the methods that can be invoked by
client object

remotely.
Furthermore, the remote interface is shared between the
client object

and
server
object

and so resides on both machines. Only by this sharing of the remote interface,
the
client object

can hav
e the knowledge of what remote methods are provided by the
server object

that is located on another JVM. That is, actually the
client object

calls





23



the method declared in the remote interface instead of the method defined in the
server object
.


The followin
g
Figure 4
-
3

is the remote interface of my example:






Every method declared in a remote interface must throw an exception of
java.rmi.RemoteException
. The reason is that the remote method call is
inherently less reliable than local call


it is alway
s possible that a remote call will
fail. For example, the server or the network connection may temporarily unavailable.


Implementing the server side program

The implementation of the server side program is separated into two steps. The first
step is the

implementation of the
server object

and the second step is registration of
this object.

One way to implement the
server object

is to create a Java class that extends
java.rmi.server.UnicastRemoteObject

and implements one or more remote
interfaces. The
ser
ver object

must invoke one of its superclass constructors so that it
can be exported to the network. The
server object

implementation of my example is
given by
Figure 4
-
4
:












public interface Hello
extends

java.rmi.Remote{



public String sayHello( ) throws java.rmi.RemoteException;


}


Figure 4
-
3

Hello.java



牥浯me⁩湴e牦ace

public class HelloImpl
extends

java.rmi.server.UnicastRemoteObject


implements

Hello{



//calls the constructor of superclass to export this object


public HelloImpl( ) throws java.rmi.RemoteException{


super( );


}




//remote method


public String sayHello( ) throws java.rmi.RemoteException{


return “H
ello World”;


}

}//end of class HelloImpl


Figure 4
-
4

HelloImpl.java



server object





24



The static
rebind( )
or
bind( )

method of
java.rmi.Naming

is called to r
egister
the
server object

to the RMI registry so that the
client object

can find it from the
registry. Both of these two methods have two parameters, the first is a
String

with
URL
-
like syntax of “[rmi://host][:port]/name”, the default host is
localhost

an
d the
default port number is 1099, and the second parameter is the
server object
that needs
to be registered. The registration is implemented as
Figure 4
-
5

(the name of the
computer hosting the
server object

is “zhangjun”):











Implementing the clie
nt side program

The implementation of the client side program is quite simple compared with the
implementation of the server side program. First, the desired
server object

must be
found from the registry using the
lookup( )

method
java.rmi.Naming

and cast
to
the corresponding remote interface. The
lookup( )

method only takes one parameter
that is identical to the first parameter of
rebind( )

or
bind( )

method that is used to
register the
server object
. As the Java security requirement, a security manager mu
st
be set to guarantee the secure dynamic downloading of the
stub

classes, otherwise the
stubs

can only be loaded from the local classpath. Then, the remote methods can be
called in the exactly same way the local methods are called.
Figure 4
-
6

is the clien
t
side of my example.


All the .
java

files need to be compiled using the
javac

tool. The
stub

and
skeleton

classes are generated from the
server object
, by applying the
rmic

tool to the
server
object
. For example, in Windows system, running the following c
ommands will
compile the source codes of this sample program and generate the
stub

and
skeleton
:


javac *.java

public class HelloServer{


public static void main( String[] args ){


try{



//instantiate the object


HelloImpl server = new HelloImpl( );



//register the object


java.rmi.
Naming.rebind( “rmi://zhangjun/myServer”, server );


} catch( Exception e ){ }


}

}//end of class HelloServer


F
igure 4
-
5

HelloServer.java





25




rmic HelloImpl

Or, only generate the
stub

class in Java 1.2 and above version:


rmic

v1.2 HelloImpl

















Compiling source codes an
d generating
stubs


Deploying the application

To deploy the RMI client
-
server application, three folders are needed for the server
program, the client program, and the dynamic downloading respectively. For my
example, these three folders are
ServerProgram
,

ClientProgram
, and
Download
, they
contain:


ServerProgram:



Hello.class



HelloImpl.class



HelloImpl_Stub.class



HelloServer.class

Download:



Hello.class



HelloImpl_Stub.class

ClientProgram:



Hello.class



HelloClient.class



Client.policy*

public class HelloClient{



//start

the client side program


public static void main( String[] args ){


HelloClient client = new HelloClient( );


}



public HelloClient{


try{


//set the security manager


System.setSecurityManager( new RMISecurityManager( ) );




//
finds the server from the registry


Hello server = (Hello)java.rmi.Naming.lookup( “rmi://zhangjun/myServer” );






//calls the remote method


System.out.println( server.sayHello( ) );


}catch( Exception e ){ }


}

}//end of class HelloClient


Figure 4
-
6

HelloClient.java



client object





26




( * see
Figure 4
-
7

)

These three folders can be put on any computers as long as the following conditions
are satisfied:



Download

folder needs to be put within a web server system, for example
Apache. This web server can be accessed by t
he computer on which the
ClientProgram

resides;



There is network connection between the computer on which the
ServerProgram

resides and the computer on which the
ClientProgram

resides.


Running the application

To run a client
-
server RMI application is a li
ttle more complicated than running an
ordinary Java application more than one JVM are needed to run
rmiregistry
, server
program, and client program(s) separately.


To run
rmiregistry

in a Windows environment:

1.

Open a new DOS console;

2.

Execute the command



start rmiregistry
.

By running
rmiregistry
, a registry pool, in which the
server object

can register, is
opened.


To run the server program, the dynamic downloading issue has to be considered:

1.

Open a new DOS console in Windows, change directory to the
S
erverProgram

folder;

2.

Start the server program, with the value of
java.rmi.server.codebase

system property set to a URL pointing to the
Download

folder:

start java


Djava.rmi.server.codebase=http://zhangjun/Download/
HelloServer


To run the client program,

a
policy file
, which grants suitable permissions to the client
program, is needed.
Figure 4
-
7

is the
policy file

of my sample program, it is named

client.policy
” and saved in the
ClientProgram

folder as well. This
policy file

allows




27



an application to con
nect to the port located on the machine named “zhangjun” and
the port number is either 80 or greater than 1024:








The command in Windows DOS environment to start the client program is:


start java

Djava.security.policy=client.policy HelloClient

4.2.4

Callback from server


Besides the remote method invocation from
client object

to
server object
, RMI also
allows a
server object

to call the methods of a
client object

remotely. This technique
is called
callback

and is typically used by the
server object

to

let its clients

know that
it has completed a specific operation or to inform its clients of the occurrence of some
other events. To take advantage of the
callback

mechanism, the
client objects

need to
register itself with the
server object
, i.e. the
serve
r object

need to use a data structure
(for example, a vector) to keep records of the
client objects

connected to it.
















Grant

{ permission java.net.SocketPermission “zhangjun:80”, “connect”;


permission java.net.SocketPermission “zhangjun:1024
-
65535”, “connect”; }


Figure 4
-
7

cli
ent.policy

File


Server


Client


Client


Client


Client


Client

1

3

1

3

2

Figure 4
-
8

Using callbacks

1.

Client objects

connect to the
server object

and register themselves with the
server object
,
i.e. the
server object

adds these
client objects

into an object of a specific data structure, for
example, a vector;

2.

A
client object

triggers an event to the
serv
er object
;

3.

The
server object

picks up all the
client objects

that are interested in the event from the
vector and calls back to these objects.






28



Figure 4
-
8

shows the sequence of events involved in using
callback.


Establishing
callbacks

in RMI is relatively easy. To
allow the
server object

to call a
method of a
client object
, the
client object

must be a simple
server object
as well, i.e.
it needs to implement one or more remote interfaces. But the
client object

doesn’t
need to bind itself in any registry, it is only r
equired for the
client object

to export
itself to the network by calling the static
exportObject( )

method of
java.rmi.Server.UnicastRemoteObject

class. Since the
client object

is now
acting as a simple server, it is necessary to execute the
rmic

tool on i
t to generate the
requisite
stub

and
skeleton

classes.


The simple example is extended so that all the clients will receive a message from the
server to which they are connected whenever a new client is connected to this server.
Figure 4
-
9

is the remote in
terface that is implemented by the
client object
:







The
HelloClient

class needs to implement this
Callback

interface by defining the
remote method of
clientEcho( )
as shown in
Figure 4
-
10
.









In addition, the following two lines of code need to
be added to
HelloClient
,
immediately

after it has found the
server object

by calling the
lookup( )

method, to
export itself to the network and register with the server object


public interface Callback
extends

java.rmi.Remote{


public void clientEcho( String message ) throws java.rmi.RemoteException;

}


Figure 4
-
9

CallBack.java

public class HelloClient implements Callback{






public void clientEcho( St
ring message ) throws java.rmi.RemoteException{


System.out.println( message );


}




}

Figure 4
-
10

clientEcho( )

method in
HelloClient.java





29












A new remote method of
registerClient( )

that is used to register the
client objects

needs to be added to the remote interface of
Hello
, and the
server object

HelloImpl
implements
registerClient( )
in a way that it informs all the client objects connected
to it whenever a new client object gets connected,
Figure 4
-
11

gives t
he details how
to implement this new remote method:


















4.2.5

Multiple clients

In the RMI implementation of client
-
server program, more than one
client object

can
connect to the same
server object

and call its remote methods simultaneously. If thes
e
client objects

need to access and modify the instance variables of this
server object
,
//export itself

java.rmi.Server.UnicastRemoteObject.exportObject( (Callback)this );

//register itself with the server by calling a remote method of the server

server.registerClient( (Callback)this );


publi
c class HelloImpl
extends

java.rmi.server.UnicastRemoteObject

implements

Hello{


private java.util.Vector clients = new Vector( )
;
//keep records of all clients





††
//remote method, register the new client and informs all the existing clients



public
synchronized

void registerClient( Callback client ){


clients.add( client );


callClients( );


}





//calls back all the clients


private void callClients( ){


for( int i = 0; i < clients.size( ); i++ ){



Callback client = (Callback)clients.get( i );


try{



client.clientEcho( “another new client” );


}catch( Excpetion e ){ }


}


}




}



Figure 4
-
11

extended
HelloImpl.java





30



for example, the
clients

vector in my sample program, these accessing and modifying
operations must be made mutually exclusive. To achieve this goal, the programmer
ca
n use either the multithreading facility or simply use the
synchronized

keyword on
the relevant methods, like the
registerClient( )

method presented in
Figure 4
-
11
(Actually, an object of
java.util.Vector

itself is synchronized, i.e. it can’t be
accessed
concurrently by more than one object.).


The main purpose to use an instance variable in a
server object

is to achieve the
communication and cooperation between different
client objects
. For example, the
following shows how to send a message from a
client
object

(
Sender
) to another
specific
client object

(
Receiver
) via the instance variable of the
server object
:

1.

The
Sender

sends the message and the ID of the
Receiver

to the
server object
;

2.

The
server object

picks up the
Receiver

from the data structure that
keeps
records of all the
client objects

according the ID of the
Receiver
;

3.

The
server object

sends the message to the
Receiver
.


4.2.6

Advantages and disadvantages

RMI has the advantage of being simple to write and use. The programmers can
concentrate on the app
lication models other than the underling network
communication issues, since the generation of the
stubs

and the communications
among the
client objects
,
stubs
, and the
server objects

are undertaken by the Java
systems. In addition, it is a part of the cor
e Java download and therefore is supported
by every platform that supports Java.


Although the implementation of RMI is fairly simple, RMI contains a surprisingly
sophisticated set of features, for example:



RMI can pass serialized Java objects in both dire
ctions;



It can dynamically load the class files using the CodeBase;



It supports
callback

from the
server object

to the
client object
;

These features make RMI a practical solution for programmers to develop a Java
distributed application.






31



Disadvantage to R
MI exists (Potts 2002), however. RMI is a pure Java solution, there
is no support for RMI in languages other than Java, such as C/C++, VisualBasic,
Delphi and so on. If the application is required to support multiple programming
languages, the programmers
have to convert to some higher technologies, for
example, Common Object Request Broker Architecture (CORBA).


4.3

Java Servlets

In the context of internet
-
style client
-
server applications (Sridharan 1997), the server
-
side HTTP server can only provide the clien
t with static documents, usually written in
HTML. One way to provide dynamic document content is to use the server
-
side
Common Gateway Interface (CGI) scripts. But this solution has been proved to be
resource consuming and platform dependent. Java Servlets

replace the need for CGI,
and provide a much cleaner, more robust alternative.


4.3.1

What is a Servlet?

Servlets are Java applications implementing the Servlet APIs packaged in the
javax.servlet
. These applications reside on the server
-
side within a HTTP serve
r and
can be used to generate dynamic HTML documents as responses to the clients’ HTTP
requests.


Figure 4
-
12

shows the details how a Servlet responses to a client’s HTTP request.


The HTML documents generated by Servlet can use data gleaned from other so
urces,
including RMI remote objects, databases, text files, etc. (see
Figure 4
-
13

)


CGI scripts have two major drawbacks. Firstly, using CGI scripts can dramatically
degrade the server performance. Multiple CGI requests on the same server end up
creating
a new object for each request. The result is that these objects consume system
resources extensively and don’t cooperate with each other. Secondly, portability is
difficult to achieve by CGI scripts. CGI program codes are completely platform
dependent, and

are tied to a specific programming language.






32



A Java Servlet, since it is written in Java, is platform independent. It also can take
advantage of Java multithreading mechanism to minimize the consumption of system
resources and achieve the communications
among different clients. There is only one
Servlet object but multiple threads generated by this Servlet object dealing with the
clients’ requests, one thread per request. The goal to implement the communication
among different clients is achieved via the
communications among different Java
threads, which is an easy job in Java.































Client’s

web browser

servlet

RMI server

D

B

M

S

Text
file

Figure 4
-
13

Servlet uses multiple data sources

client

HTTP server

1

5

servlet

2

4

HTML

3

Figure 4
-
12

Servlet creates dynamic HTML documents

1.

Client sends a HT
TP request to the HTTP server;

2.

The HTTP server passes this request to the Servlet;

3.

The Servlet generates a dynamic HTML document, i.e. the contents of this document
could be different regarding to the different clients, or different generating time, etc.;

4.

The Servlet passes the HTML document to the HTTP server;

5.

The HTTP server sends this HTML back to the client.






33




4.3.2

Advantages over CGI


A Java Servlet, since it is written in Java, is platform independent. It also can take
advantage of Java multithreadin
g mechanism to minimize the consumption of system
resources and achieve the communications among different clients. There is only one
Servlet object but multiple threads generated by this Servlet object dealing with the
clients’ requests, one thread per re
quest. The goal to implement the communication
among different clients is achieved via the communications among different Java
threads, which is an easy job in Java.


4.3.3

How to implement a Java Servlet

All servlets need to inherit from either
javax.servlet.Ge
nericServlet

class or its
subclass
javax.servlet.http.HttpServlet
. Both of these two base classes are
abstract classes and map all HTTP requests onto a physical Servlet process.


Every class that inherits from
javax.servlet.GenericServlet

class must overr
ides
the
service( ServletRequest, ServletResponse )

method. Its first parameter
gives the information about the request sent to the Servlet, the second parameter
enables the Servlet to set the proper stream to which the dynamic document is writen.
Before t
he Servlet can send this document back, the
setContentType( String )

method must be invoked to tell the Servlet what kind of document it is dealing with.
Figure 4
-
14

presents a simple Servlet that generates a HTML page displays “Hello
World”.



The
java.se
rvlet.http.HttpServlet

class extends
javax.servlet.GenericServlet

class and provides a simple framework for using the HTTP protocol. Besides the
service( )

method, it also provides six
doXXX

methods, each of them handles the
corresponding HTTP request, for

example,
doGet( )

method handles the GET
request. All these
doXXX

methods take the same parameters as the
service( )

method

does, i.e.
HttpServletRequest

and
HttpServletResponse
, and throw
IOException

and
ServletException
. The implementation of the class

that extends




34



HttpServlet
is similar to the Servlet provided in
Figure 4
-
14



setting the type of the
documents, getting the io streams, and generating the HTML pages. The difference is
that operations can be defined within different
doXXX

methods as respo
nses to
different HTTP requests.
















4.3.4

Multithreading

When a Servlet receives a HTTP request (Allamaraju 2002), it will create a new
thread to handle this request by the
service( )

or
doXXX

methods. If this Servlet has
any instance variables, the
se variables must be manipulated in a thread
-
safe manner.
This can be achieved by using the
synchronized

keyword as discussed in section
4.2.5, or making the Servlet class implementing the Java Interface of
javax.servlet.SingleThreadMode

to guarantee that
only one thread is executing
the Servlet’s method at any given time.


Like the instance variables in RMI
server object

discussed in section 4.2.5, an
instance variable of Servlet that is shared by multiple threads also can be used to
accomplish the communi
cation and cooperation among different clients.


Import jav
ax.servlet.*;


public class MyServlet
extends

GenericServlet{



//overrides the service method


public void service( ServletRequest request, ServletResponse response )


throws ServletException, IOException{




//defines the type of the document


response.setContentType( “text/html” );



//
get the output stream


PrintStream doc = new PrintStream( response.getOutputStream( ) );






//generates the HTML page


doc.
println( “<HTML><HEAD><TITLE>my servlet</TITLE></HEAD>” );


doc.println( “<BODY>Hello World</BODY></HTML>” );


}

}


Figure 4
-
14

A simple Servlet

MyServelet.java

extending
GenericServlet





35



4.3.5

Invoking Servlets

A Java Servlet can be invoked by assigning its URL address to the ACTION attribute
of a HTML form:





Another way to invoke a Java Servlet is to use the
<Servlet>

tags, a kind of
S
erver
Side Include
( SSI ) tags. Files using SSI tags must be deployed using a file extension
of
.shtml
:





4.3.6

Advantage and disadvantage

The simplicity of the Java Servlet approach combined with the rapid spread of web
browsers made the Servlet technology of

choice for Web site development (Potts
2002).


Servlet provides a way of using standard HTML pages to present and capture data.
With Servlets, the client is a Web browser. Data can be captured and sent to the
server, where it can be manipulated by the Se
rvlet. This provides a way to easily
deploy an application, because it really exists only on the server side, not on each
client machine. Servlets can make calls to other popular technologies such as JDBC
and RMI, thereby extending their reach even further
.


The fact that the client runs in a browser places some limits on this approach.
Browsers tend to support fairly old versions of Java and the security model that they
use limits the amount of work that can be done on the client side.



<FORM NAME = [ name of the form ] METHOD = post


ACTION = [ URL of the servlet class file ] >


<SERVLET CODE = [ file name of the servlet class ]



CODEBASE = [ URL of the directory in which the servlet class file is ] >

</SERVL
ET>






36



4.4

Java Applets

Java

Applets are essentially executable content: Java applications that are embedded
within a HTML file, and rely on the support of a context to provide services such as
printing and display management. The context is usually a browser, such as NetScape
Naviga
tor or Microsoft Internet Explorer. A Java Applet will be downloaded to the
client’s local computer along with its host HTML file, and runs within the Java
Virtual Machine provided by the browsers.


While Java Servlet extends the functionality of the netwo
rk servers, the Java Applet
technology extends the functionality of client
-
side browsers by providing Java
executable code (distributed from a central source) within the browser context.


4.4.1

How to implement Java Applets

A Java Applet class is a subclass of
java.applet.Applet
, this is required to allow
the browser to work with the Applet. There is no
main( )

method in Applet, instead
the functionality is spread across the following methods
init( ), start( ), stop( ),
destroy( ),

update( )

and
paint( )
.
The fi
rst four methods are

invoked at different
time by the

system automatically after the Applet has been loaded into the client’s
JVM. The last two methods are invoked by Abstract Window Toolkit (AWT) for on
screen rendering.
Table 4
-
2

shows the time when thes
e methods are invoked. Like the
ordinary Java AWT graphics interface, a Java Applet using the APIs provided by
java.awt.event

package to handle the events it receives. For example, the Applet
needs to implement
java.awt.event.ActionListener

interface to ha
ndle the event
that occurs when a button is pressed.

So what a programmer needs to do for the implementation of a Java Applet is:

1.

Define a class that extends
java.applet.Applet

class and implements the
suitable event
-
handle interfaces;

2.

Override the method
s mentioned above according to their different invocation
time and the programmer’s requirements;

3.

Override the methods of the event
-
handle interfaces.







37






Table 4
-
2

when the methods of a Java Applet are invoked

Method

When invoked

init

After the applet i
s loaded.

Can only be invoked once.

start


After
init

method.

Or each time the user returns the page containing the Applet after
having gone off to other pages.

Can be invoked many times

stop

Each time the page containing the Applet is exited.

Or before
the invocation of
destroy

method

destroy

Just before the garbage collection of the Applet, it happens when the
browser is shut down.

update

In response to
repaint
; should invoke
paint
in turn.

paint

When the Applet need to be redrawn:



When first brought

on screen;



When re
-
exposed after being covered or miniaturized;



When scrolled.

Or when needed by
update
.


4.4.2

The Applet HTML tags

The
<APPLET>

tag is used to embed a Java Applet into a HTML document, its most
basic form is like this:



The value of the
COD
E

attribute is the name of the Applet class file, and must
include the
class

extension; the values of the
WIDTH

and
HEIGHT

define the size of
the area within the browser’s window that will hold the applet. These three attributes
can’t be omitted, otherwise
, the applet will not be loaded.


Within the Applet tag, the optional
ALIGN, VSPACE
, and
HSPACE

attributes can be
used as well to define the position of the applet.

There are two other optional attributes,
CODEBASE

and
ARCHIVE
, used to tell the
browser wh
ere it can find the Applet class. The value of the
CODEBASE

is the
directory below which the Applet class file is stored, the value of the
ARCHIVE

is the
<APPLET CODE = ”MyApplet.class” WIDTH = 300 HEIGHT =400></APPLET>





38



Java archive file(
.jar

file ) or other compressed file containing the Applet class file or
other reso
urces for the Applet. The browser fetches these files from the web server to
the local computer before the Applet is loaded.


4.4.3

Communicate with server
-
side Java application

Since Applet is written in Java, it is obvious that the socket or RMI mechanisms
dis
cussed in section 4.1 and section 4.2 can be used to create a communication
between the Applet and the server side Java applications. But the operation of Applet
is restricted to a small limit since Applet must obey some security rules (Horstmann
1997):



Ap
plet can never run any local executable file;



Applet cannot communicate with any host other than the server from which it
is downloaded;



Applet cannot read and write to the local computer’s file system;



Applet cannot find any information about the local co
mputer, except for the
versions of Java and operating system, and the characters used to separate files
(for instance, / or
\
), paths (such as : or ;), and lines (such as
\
n or
\
r
\
n);



All windows that Applet pops up carry a warning message.


4.4.4

Advantage and
disadvantage


Not only can Java Applet be used to provide dynamic graphical content to a web
page, but also as a client application delivery system (Daconta 1998). An Applet is
ideal for a “thin” client application. Thin
-
client is a technique that attempts

to
minimize the resource requirements of the application at the client
-
side. For example,
the client application only provides the user interface, but the actual processing and
work is performed by a server application.


But some drawbacks exist in using
Java Applets. One is the Applet download time. If
an Applet references many class files or uses a lot of resources, it may take the
browser a significant amount of time to download all the necessary files. Another
drawback is the security limit discussed i
n section 4.4.3.





39








Chapter 5

Extend PAC2 to A Distributed System
Using Java RMI API


As discussed in Chapter 3, the PAC2 system must be extended to a distributed system
in order to overcome the existing security and communication problems. This chapter
uses Mini PAC, a simple Java client
-
server application which simulates the basic
functionalities of PAC2, to demonstrate how to extend PAC2 to a distributed system
using Java RMI APIs. The reason to design such a Mini PAC system in my project is:



PAC2 is a

complicated system, and the security and communication problems
that need to be solved by this project are only involved in a small proportion
of it, for example, the implementation of user login and user access right
verification;



The other parts of PAC2
, although with a huge amount of codes, can be
generalized under one category, i.e. the operations on external files. These are
not the emphasis of my project.


5.1

Mini PAC

Mini Pac is a Java multi
-
user, distributed system that simulates all the user
manageme
nt functionalities of PAC2, but it only provides a minimized functionality
for handling AV file, for example, playing AV files and attaching simple comments to
these AV files. My solutions to the problems existing in the current PAC2 system are
reflected i
n the implementation of Mini PAC.


5.1.1

Main features of Mini PAC

Mini PAC system has the following four features:

1. Distribution
:





40





The Mini PAC system is separated into two parts: server side and client
side. It runs within a computer network.



Server si
de

is controlled by the network administrator, it consists of:

o

Web server software


apache in Mini PAC;

o

Relational database server software (DBMS)


mySQL in Mini
PAC;

o

Mini PAC server side software;

o

The web server, DBMS, and the server side software are al
l
running on the server machine(s) of this network.

o

Mini PAC client side software. It is stored in a specific folder
under the web server software.



Client side



the users of Mini PAC can download the client side software
from the
server side

and run it on

their own computers. For the definition
of the users of Mini PAC, please see 2.



A bi
-
directional communication exists between the
server side

and the
client side.


2. Different user types
:

There are two different kinds of users in Mini PAC:



Owner of data
base
: the user who has created a new PAC database. About
who can create a new database and how this database is created, please see
3.



General user
: any user who can access to a PAC database. After an
owner
of Database

has created a new database, he/she c
an add new users to this
database. The new user’s username, password, and access level to this
database are assigned by this
owner of Database.


3. Database and user creation/removal issues



Create/remove a new PAC database: the user who has got the “CREATE

or “DROP” privilege for DBMS from the administrator can create/remove
a PAC database using JDBC APIs from
client side
. This user becomes the
owner
of this database
.
The created database has a special table, named
“PACUSER”.





41





Add/remove
general user
: an
o
wner of database

can add a new
general
user

by specifying a unique pair of username and password, as well as an
access level for this user. The values of the username, password, and the
access level are stored in the “PACUSER” table. To remove a
general
us
er
, the
owner of PAC

just deletes all the values related to this
general
user

from the “PACUSER” table.


4. Functionalities of Mini PAC:



Add/remove new database.



Add/remove new users to a specific database; specify the usernames,
passwords, and access leve
ls (read
-
only, read
-
write) of the new users.



Log onto a specific database using the correct username and password.



Users can
upload AV file
s that are saved on their local computers to the
server side
.



Users can download the AV files from the server side an
d play these files
on their local computers.



Allow user
s

to present their own and/or read other’s description
s

to the AV
file
s

according to their access level
s
:

o

Read
-
only access level

o

Read
-
write access level



Different users can access to the same
uploaded

AV file or description
s

concurrently.



Communications exist among different users, i.e. whenever a user has
completed an operation, the Mini PAC system will inform the other users
about this operation immediately.


5.1.2

Use case analysis of Mini PAC

Table 5
-
1

l
ists all the use cases identified for the functionalities of Mini PAC system.
Figure 5
-
1

is the use case diagram of Mini PAC system.


The detailed descriptions of the use cases of Mini PAC system are attached to this
report as Appendix A.





42







Use case name

Purpose of the use case

Add a new database

Add a new PAC database to the Mini PAC system.

Remove a database

Remove the selected PAC database from Mini PAC.

Add a new user

Add a new user to the current PAC database.

Remove a user

Remove the selected us
er from the current PAC database.

Login

Login to the Mini PAC system.

Change password

Change the user’s Mini PAC password.

啰汯r搠d渠䅖 晩汥

Upload an AV file from the user’s local computer to the
獥牶r爮

m污y⁡渠n嘠s楬e

䑯a湬潡搠瑨n⁳ 汥c瑥搠t嘠s楬e⁦
牯洠獥牶r爠a湤⁰污y⁩ .

m潳琠愠摥獣物灴楯n

m潳琠愠摥獣物灴楯渠潮⁴桥⁰污y楮g⁁ 晩汥.


Add a new database
Remove a database
Add a new user
Remove a user
Owner of database
Login
Change password
Upload an AV file
Play an AV file
General user
Post a description

Figure 5
-
1

Use case diagram of Mini PAC system



Table 5
-
1

Use cases of Mini PAC system





43



5.2

Why Is RMI?

Java provides a variety of APIs to develop a distributed client/server application as
discussed in
Chapter 4. The programmer should select the suitable APIs according to
the application

s specific requirements. In my project, RMI is selected and the reason
why I choose it is presented in this section.

5.2.1

Why Not Java Sockets?

In Mini PAC, the data shared b
etween the server and clients are not limited to one
data

type. It could be as simple as a Java String or as complicated as a serialized Java
object.
I

have to design many new communication protocols to implement the
communications between the server and t
he clients if Java Sockets is selected. That
means a huge amount of extra workload and it will be difficult to debug the system.
So Java Sockets is not a good choice to develop Mini PAC.


5.2.2

Why Not Java Servlets?

Java Servlets is mainly used to provide web s
ervices and the clients get these services
from HTML documents using web browsers. According to the descriptions of Mini
PAC in Section 4.1, the Mini PAC system doesn

t need any web services at all and
pure Java application is
enough

to fulfill all its fun
ctionalities.

5.2.3

Why Not Java Applets?

Why I don

t choose Java Applets to implement the client side of Mini PAC is mainly
because:



Every time when the users start to run the client side programs, the Applets
have to be downloaded again;



The client side progr
am of Mini PAC may have operations on local file system
of the user

s computer. For example, uploading an AV file from the local
machine. These operations are forbidden by the Applet security policy and the
solution that uses signed Applet to lift the secu
rity restrictions on Applet
requires too much extra work.





44



5.2.4

Conclusion

RMI

Based on the studies of the four Java technologies discussed in Chapter 4 and the
comparisons among them, I decided to use Java RMI technology to implement Mini
PAC system. It’s main
ly because:



By using RMI APIs, both of the server and the client programs of Mini PAC
system can be written in pure Java and the running of them don’t need the
supports of any software other than Java Virtual Machine;



Users can install and start the client

programs locally. It is obviously more
efficient compared with Applets;



Any Java data types including Java object can be passed between server and
client as method parameters or return values using RMI technology and no
communication protocol is needed. I
t means the codes of Mini PAC is much
easier to write than using Java Sockets;



In RMI, there are less security limitations on the client program so that the
users of Mini PAC can easily upload files from local computers to the server;



The communications be
tween server and client are bi
-
directional. This bi
-
directional communication makes the communication between different
clients much easy to be implemented following the routine of client


server


client.


5.3

The Java Implementation of Mini PAC

This section

gives a brief description on how I implement Mini PAC system using
Java RMI APIs.


5.3.1

Structure of the Java codes of Mini PAC

The Java source codes of Mini PAC system have 7 packages totally. They are:



servers
package

Classes in this package are all RMI int
erfaces declaring remote methods. These
classes are implemented either by the classes of
controls

package or the classes of
clientapplication

package;



controls

package





45



This package is the core part of the server program of Mini PAC system. Each of
the clas
ses in this package implements a RMI interface of the
servers

package and
defines the concrete implementation of the remote methods that can be invoked
remotely by the client program of Mini PAC system. The function of these remote
methods is to pass the c
lients’ requests to other methods which could be defined
by the classes of either