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牮rmen搠灡獳睯s搠dreo牲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
Enter the password to open this PDF file:
File name:
-
File size:
-
Title:
-
Author:
-
Subject:
-
Keywords:
-
Creation Date:
-
Modification Date:
-
Creator:
-
PDF Producer:
-
PDF Version:
-
Page Count:
-
Preparing document for printing…
0%
Commentaires 0
Connectez-vous pour poster un commentaire