Distributed Marking System OMS)
114
Distributed Marking System OMS) CORBA lmplementation by Ali Elbashiri B. Sc. (Honors in Computer Science) Althide University, 199 1, Libya Thesis submitted in partial hilfillment of the requirements for the Degree of Master of Science (Computer Science) Acadia University Fall, 1999 Q by Ali Elbashiri, 1999
Transcript of Distributed Marking System OMS)
Distributed Marking System OMS)
CORBA lmplementation
by
Ali Elbashiri
B. Sc. (Honors in Computer Science)
Althide University, 199 1, Libya
Thesis
submitted in partial hilfillment of the requirements for
the Degree of Master of Science (Computer Science)
Acadia University
Fall, 1999
Q by Ali Elbashiri, 1999
National tibrary le1 dm", Bibliothèque nationale du Canada
Acquisitions and Acquisitions et Bibliographie Services services bibliographiques 395 WeUington Street 395, rue Wellington OltawaON K 1 A W ûttawaON K 1 A W can&a Canada
The author has granted a non- exclusive licence allowing the National Library of Canada to reproduce, loan, distribute or sel1 copies of this thesis in rnicrofom, paper or electronic formats.
The author retains ownership of the copyright in this thesis. Neither the thesis nor substantial extracts Erom it may be printed or otherwise reproduced without the author's permission.
L'auteur a accordé une licence non exclusive permettant à la Bibliothèque nationale du Canada de reproduire, prêter, distribuer ou vendre des copies de cette thèse sous la forme de microfiche/film, de reproduction sur papier ou sur format électronique.
L'auteur conserve la propriété du droit d'auteur qui protège cette thèse. Ni la thèse ni des extraits substantiels de celle-ci ne doivent être imprimes ou autrement reproduits sans son autorisation.
CHAPTER 1 ................................................................................................................................................. 1
1 INTRODUCTION o o o ~ ~ o o o o ~ ~ o m o ~ a o ~ ~ o o o m o o ~ m o o o o ~ m ~ ~ o o ~ o ~ o o o o o a m o o o m o o m o m o o o o o m m a o m o o m 1
............................................................................................................... 1.1 OVERVIEW OF THE THESIS 4
2 CLIENTBERVER ARCHITECTURE o o o o o o ~ o o o o o o o o o m ~ o ~ o ~ ~ o o ~ ~ ~ m ~ ~ ~ w o m o o o o o e o ~ ~ ~ ~ o o o o o o o m o o o o o o o m o o o o o o o o o o o o o o S
2.1 MODEL ............................................................................................................................................ 5 ................................................................................................................... 2.1. I Client Comportent 6 .................................................................................................................. 2.1.2 Server Component 7
2.2 ADVANTAGES ....~............................................................................................................................. 8 ................................................................................................................................ 2.2.1 Eficiency 8 ............................................................................................................................. 2.2.2 Throughput 8 .............................................................................................................................. 2.2.3 Modularity 8
................................................................................................................................ 2.2.4 Flexibiliry 9 ......................................................................................................................... 2.3 CHARACTE~US~CS 9
.............................................................................................................. 2.3.1 Networking Concepts 9 2.3.2 1dentr;fication and Authentication ....................................................................................... 10
................................................................................................................. 2.3.3 Access Conrrol..... I I 2.3.4 Adminisiration ...................................................................................................................... I I 2.3.5 Cooperation ......... ,., ..... ....,., .................................................................................................. I I 2.3.6 Procas-to-Process Isolation ............................... ... .............................................................. 12
2.4 TIERS .................~...~...~.......~...~....................................................................................................... 12 . . 2.4.1 1-TierMonol~thtc .............~.....................~...~.......................................................................... 13 2.4.2 2-Tier ................................................................................................................................ 13
........................................................................ 2.5 DRAWBACK~ OF CLIENT/SERVER ARC HI TE^ 15 2.5.1 Lack of centralked control .................................................................................................. 15 2.5.2 Lackofsecurity ..................................................................................................................... 15 2.5.3 Clientworkfoad .................................................................................................................... 15
2.6 CONCLUSION ...............................,... ............................................................................................ 16
3.3 CHOOSWG APPROPRIATE TECHNOLOGY ..................................................................................... 22 3.3.1 CGI/HITP ........................................................................................................................... 22 3.3.2 Java Technology ................................................................................................................. 24
3.32.1 JavaServlets ..................................................................................................................................... 25 3.32.2 Java RMI .......................................................................................................................................... 26
3.3.3 DCOM .................................................................................................................................. 26 3.3.4 CûRBA ................................................................................................................................. 27
3.4 CONCLUSION ................................................................................................................................. 29
4.1 INTRODUCTION ............................................................................................................................... 30 4.1.1 Related Work ................................................................................................................... 30 4.1.2 Objective ............................................................................................................................... 30 4.1.3 Strategy ................................................................................................................................. 31 4.1.4 Analys is. ................................................................................................................................ 31 4.1.5 Push and Pull Model ............................................................................................................ 32
4.2 FUNCTIONAL~TY .............................................................................................................................. 32 4.2.1 Actors ................................................................................................................................... 32
4.2.1.1 Students .......................................................................................... .... ............................................ 33 4.3.1 2 Markers .......................................................................................................................................... 34 4.2.1.3 Instnictors ...................................................................................................................................... 35
................................................................................................................................. 4.2.1.4 Administrators 36 4.2.2 Assignment Maintenance ...................................................................................................... 36
................................................................................................................. 4.3 SYSTEM REQUIREMENTS 37 4.3.1 Sofhoare Distribution and Deployment ................................................................................ 38 4.3.2 Object Persistence ................................................................................................................ 38
.................................................................................................... 4.3.3 Concurrent Object Access 39 .......................................................................................................... 4.3.4 Isolated Objecr Access 39
4.4 DESIGN ........................................................................................................................................... 39 4.4.1 Design Issues ........................................................................................................................ 40
.................................................................................................................................. 4.4.1.1 Data Filtering 40 ....................................................................................................................................... 4.4.1.2 Persistence 40
4.4.1.3 Security ........................................................................................................................................... 41 4.4.1.3.1 DMS Security ....................................................................................................................... 41
..................................................................................................................... 4.4.1.3.2 Applet Security 41 4.4.1.4 Object Factory ................................................................................................................................. 42
................................................................................................................ 4.4.1.5 System exception handler 42 ............................................................................................................................... 4.5 ARCHITECTURE 43
5.1 REMOTE INTERFACES .............~.~...................................................................................................... 47 5.1.1 Authenticator ........................................................................................................................ 49 5.1.2 FilterFactory ........................................................................................................................ 51 5.1.3 Datd'ilter ............................................................................................................................. 56 5.1.4 DataManager and DataResource .......~...~.....~.~~.~.................................................................. 58
5.2 DMS CLIENT SIDE .......................................................................................................................... 58 2 Creating the user inteface ................................................................................................... 60
.......................................................................................................... 5.2.2 Connecting to a semer 60 5.2.3 Invoking methods of remote objects ...................................................................................... 62
5.3 DMS SERVER SIDE ......................................................................................................................... 64
......................................................................................................................... 1) PUBLIC SERVICES 95
STUDENT SERVICES ..................................................................................................................... 96
III) MARKER SERVICES ...................................................................................................................... 97
IV) MSTRUCTOR SERVICES ......................................................................................................... 1ûû
V) ADMINTSTRATOR SERVICES ................................................................................................. 102
List of Figures
........................................................................ Client/Server Mode1 6
........................................................ 2 Tier ClientIServer Architecture 14
........................................................ 3 Tier Client/ Server Architecture 19
...................................... ...*..............*..*............ Actors Diagram .. 33
............................................................ DMS 3 Tier Architecture 4 4
................................................................... Architecture of DMS 4 5
............................................. Interfaces and Packages Diagram (UML) 48
............................................................ Client Class Diagram (UML) 59
............................................................ Server Class Diagram (LTML) 64
............................................................................ Logging Screen -71
................................................................ Administrator's Main GUI 71
........................................................................ S tudent's Main GUI 72
.............................................................. User Account Maintenance 74
.................................... ..................... Course Account Maintenance t, 75
........................................................................ Course Registration 76
................................................... Maintenance of Assignment Account 78
....................................................... Ass ivent Outline Downioading 79
....................................................... Assignment Solution Submission 80
............................................... Marker downioads assignment solutions 81
................................................... Marker uploads assigrment solutions 82
.................................................... S tudent downloads rnarked solution 83
Dedication
To tùe mernories of my father.
Acknowledgments
1 would like to express my shcere thanks to my supervisor Dr. T. Mddner for his
precious guidance, inspiration and valuable time throughout this work. Thanks also
extend to Dr. 1. Tomek for being my interna1 examiner and Dr. S. Srinivas for being my
extemal examiner.
A special th& to the Libyan Educational Secretary for their sponsonhip.
Findly, 1 would like to express my greatest gratitude to my mother for her love, support,
and encouragement.
Abstract
This thesis describes an integrated Dishibuted Marking System, DMS, which can
be used to post assignment descriptions, submit assignment solutions, mark solutions
using specialized marker tools, and maintain student marks using a file system or a
favorite database. DMS is a ClientIServer system and uses CORBA to provide language,
network and operating system independence. Persistent storage on the server is provided
through a file system or DBC.
ChWTER 1. INTRODUCTION
Chapter 1
1 Introduction
Maintenance of student assignments is an important part of the everyday routine
of al1 instructors. Traditionally, assignments are prepared by an instnictor in a paper
form, and then given to students. When student solutions are collected, they are given to
markers who upon marking update student mark files and return marked assignments to
sîudents.
The development of high petforniance cornputing and communications has
created new media, such as the World Wide Web. in tun, these new media enable new
types of messages and experiences which make it possible to develop synchronous,
presentation-centered foms of distance education-which replicate traditional 'Yeaching
by telling" across barriers of distance and tirne-into an alternative instmctiond
paradigm: distributed leaming. In particular, advances in computer-supported
collaborative learning, and multimediahypermedia offer the potential to create shared
"leaming-through-doing environments" available anywhere, any time, on demand.
In this thesis we describe the development of an extensible, integrated, and
Distributed Marking System, DMS which can be used to post assignment descriptions
and submit solutions, mark solutions using specialized marker tools, and maintain student
marks using a file system or a favorite database. Our main goal was to design a system
which is user-fnendly, distnbuted, and extensible. For a system to be user niendly, our
CHiWîER 1. INTRODUCTION
design uses speciaiized graphical user interfaces, GUIs. These GUIs are custom-made for
various kinds of users and wili appear different to students, markers and instnictors. DMS
consists of a server and a number of clients, and is fully distributeci so that users can
comect fiom networked computer. However, DMS supports not only pulling information
such as an assignment outiiie, and on-line access such as displayhg marks or assignment
outlines, but also pushing information onto a client's machine so that she or he can work
off-line. For example, to mark an assignment, the marker does not have to be connected
to the network. Off-line work is particularly usehl if the system is flexible and
extensible; for example, a marker should be able to use various specialized marking tools,
implemented in different programming languages. We do not wish to limit ourselves to a
specific hardware or an operating system; for example we want to be able to
accommodate a student who uses Unix on a PC, and a marker using a Macintosh. For this
reason, we are using a Common Object Request Broker Architecture, CORBA that
extends the reach of our applications across networks, languages, component boundaries,
and operating systems [OMG 981. While the cunent version has becn written in Java
[SUN 98a], any client or even the entire server could be written in any prograrnming
language, for example C++ or Smalltalk, and tun under any operating system on various
hardware platforms.
Why have we here chosen Java rather than another language? A standard web
browser is extended with a Java runtime, and it can automatically download an applet to
the user's host computer and execute it there. This feature provides a simple and flexible
mechanisrn for tramferring executable software to users when it is actually needed,
instead of installing it at their host or site ahead of the . Thetefore WWW inf'rastructwe
and Java applets can simplify the job of deploying the user client components of a
distributed application; something h d y possible with O ther languages [Orfali 97~1.
Since maintenance of student files is an important part of any marking system, we
designed a flexible interface that can be used to store marks, users, courses and
assignrnent idonnation in a file system, or through Java Data Base Connection, JDBC in
practically any available data base. Therefore, DMS is designed as a 3-tier application
where we have a thin-client, middleware and a database. Clearly, only authenticated users
should be allowed to use a marking system. Therefore, a "super-user", who creates
student, marker and instnictor password-protected accounts, administers DMS.
The combination of CORBA, Java and World Wide Web gives DMS full
advantage of simplicity, robustness and convenience. Llsers have their interfaces
independent of their cornputer operating system, web browser, and location. Aiso DMS
Client Applications can be downloaded and installed locally. DMS is easy to use, and
gives users clear error messages and positive feedback on successful performed tasks.
User interfaces are designed with minimum amount of typing required in order to reduce
the possibility of making mistakes. In addition DMS has high security level. It handles
authentication of its users and generates a small signature for each, to be used every time
the user calls DMS services.
1.1 Overview of the Thesis
In Chapter Two we provide background information on Client/Sewer Architecture.
We introduce the reader to several CliedServer Models and continue with a discussion
on Client/Server capabilities and limitations. In Chapter Three we give an ovewiew of
Dishibuted Object Computing; specifically CORBA and other Disûibuted Technologies
such as DCOM and Java RMI. Continuhg with a discussion on Distributed
Technologies, we answer the question why we chose a 3-tier architecture for our system
and CORBA for implementation. In Chapter Four we describe in detail the design and the
functionality of DMS. In Chapter Five we descnbe the implementation of DMS. Then, in
Chapter Six we show a case study on DMS and provide several screenshots of DMS in
action. In Chapter Seven we give the conclusions and recommendations for fhre work.
Finally, we include DMS installation guide in the Appendix A and DMS user's guide in
Appendix B.
CHAPTER 2. CLIENT'SER VER ARCHITECTURE
Chapter 2
2 ClientIServer Architecture
2.1 Model
Traditional software, which runs on a single PC uses the sarne cornputer resources
for somng and analyzing data slows down system performance, and allows access to only
one user at a time. ClienVServer Systems separate their activities using two or more
different computers. The computers are linked together and communicate with one
another, usuaily over a local area network (LAN).
Client/Server is a design mode1 that describes how the various components of an
information processing application will be deployed in a given processing environment.
It is a form of distributed processing that specifically envisions the components of an
application being separated into specialized modules, and be connected over network
services arnong computers, transaction service processors and database servers.
The client, which requests services, and the server, which provides the services,
(see Figure 2.1) are roles in which processes communicate. In addition to its role as a
client or a semer, a process may play many other roles, but will usually have one role ai a
the.
C ' T E R 2. CLIEMBERVER ARCHITECTURE
Figure 2.1 - ClientBewer Model.
2.1.1 Client Component
The client-based process is the front-end of the application (see Figure 2.1) that
the user sees and interacts with. It manages the local resources such as the monitor,
keyboard, and rnouse. The client process also contains solution-specific logic and
provides the interface between the user and the application system. It sends messages to a
server process (program), requesting that the semer perform a task (service). It operates
on the user's machine, and takes care of the interactive processing âriven by the user.
CHAPTER 2- CUEhWSERVER ARCHITECTURE
The client's responsibilities usually are:
1) Handle the user interface.
2) Translate the user's request into the desired protocol.
3) Send the request to the server.
4) Wait for the semer's response.
5) Translate the response into "human-readable" results.
6) Present the results to the user.
2.1.2 Server Component
The server-based process may nui on another machine on the network. This
server could be the host operating system or network file server; the server is then
provided with both file system seMces and application services. In some cases, another
desktop machine provides the application services. The server process acts as a software
engine that manages shared resources such as databases, printers, communication links,
or high-powered processors. The server process performs the back-end tasks (see Figure
2.1) ihat are common to similar applications.
The servets responsibilities usually are:
1) Listen for a client's request.
2) Process that request.
3) R e m the results to the client.
CHAPTER 2. CLIENT/SERVER ARCHITECTURE
2.2 Advantages
2.2.1 Ef'fxiency
Client/Server Architecture provides great efficiency in processing and
communications through localization and specialization. Each component needs only to
comect for the duration of its part in the process. Workstations, for example, are very
efficient at graphics display, document preparation, and print huictions and other foms
of presentation. Each workstation can tailor its own input and output without affecting
other processes. The developer can specialize and optimize prograrnming at each level to
take full advantage of the hardware.
2.2.2 Throughput
ClientBerver technology provides better throughput than centralized technology
by allowing more flexible process balancing and in some cases, dynamic reconfiguration.
Because we are not locked into a given configuration, we cm expand, contract or
redeploy our resources more easily. However, we must ensure that each of these
dynamic paths are controlled, and proiected and are not prone to attack or failure.
2.2.3 Modularity
Client/Server technology provides modularity, which allows independent design,
implementation, maintenance and control of application components. For example.
database design on the one end and presentation techniques on the other end have
improved and changed far more dramatically than basic transaction processing. By
separating these fiinctions behind compatible interfaces. the developer can take advantage
CHAPTER 2. C.ENT/SER E R ARCHITECTURE
of new technologies in one fiuictional area without impacting the others. But this only
works if the application interfaces are complete, consistent, appropriate and well
controlled.
2.2.4 Flexibiiity
What makes Client/Servet different ftom other structural or architectural models
is the flexibility with which the functionality cm be applied. Notice that at each
intermediate stage, dependhg on the direction of flow, the same functional unit cm be a
server to the requesting function and then become a client as it passes on requirements to
the next server. Figure 2.1 dernonstrates only one of the possible configurations.
Another possibility is that the flow fans out from one client to multiple data servers or
transaction serven and re-converges on the return trip. One data server, discovering that
it cannot respond fully to the client's request, may send lateral requests to related data
servers that do have the information.
2.3 C haracteristics
2.3.1 Networking Concepts
The types of connection between the clients and servea may differ at each point.
Some may be connected over LAN networks, some over wide area networks, and others
may be connected by speciai concentrators or control units. Geography and distance do
not enter into the dennition. ClienîBerver is ClientlServer whether the process travels
two feet or two continents.
CHAPTER 2- CLIENTBER RYER ARCHITECTURE
For this reason, the term Client/Server should be used to describe process
interaction and dependency, not specific technology or platforms. Although
workstations, local a d o r wide area networks, micro and mini processors and main fiame
data repositones are usual cornponents of the ClientBemer modcl, there is no single
prescribed technology for this architectural approach. There is no specific set of software
platfoms that is unique to ClientlServer. A LAN or a workstation may be part of a
ClientBerver application, but not al1 LANs or workstations are ClientlServer models.
2.3.2 Identification and Authentication
How does a client identiw itself to a server? How does the server authenticate the
client's identity and authorization? How does the server determine whether it should trust
the incoming request? 1s the client authorized for what is being requested? For example,
some ciients and servers examine each othefs content or code to ensure that they are
talking to the intended process. They also can actually distinguish between versions or
instances of each other. Some clients and servers employ authentication to achieve high
confidence that they are talking only to the intended process. Other servers will refresh
the incoming code fiom the client, such as a seMce request, with a tmsted equivalent
code to enhance security. They may also check the version control to ensure that the
client process is synchronized with the current version of the server.
End-users are usually enrolled with one client process and authenticated by that
process. If the server trusts the client process, then it may vouch for the identity of its
user and may inhent the privileges of its users in conducting transactions with the
servers.
CHAPTER 2, CWENTEERVER ARCHITECTURE
23.3 Access Control
Servers may limit access to their services according to niles that relate clients to
specific services. These d e s can be both detailed and specific. This level of access
control may be based on much more appropriate decision factors and elements than those
typically controlled and used by operating systems. For example, a server may control
access to tables, views, rows, columns, or combinations, while the operating system is
only aware of devices, volumes, directories, data sets, or files.
2.3.4 Administration
Most servers present an administrative interface, which can be used to manage
users and maintain the access rules. In some cases, the server responds to a separate
administrative process, which is a server in its own nght. Such a process may work
across multiple servers or senrices, helping to ensure consistency across those servers.
2.3.5 Cooperation
Clients and servers cooperate to meet the needs of the application or end-user.
Such cooperation is usually mandatory if al1 the objectives or requirements are to be met.
It is unlikely that either would be able to accomplish ail of the objectives by itself, which
include control objectives such as e m r detection and correction.
C W T E R 2- CUENT'LSERVER ARCHITECTURE
2.3.6 Process-to-Process Isolation
Clients and servers implemented on separate hardware platfonns provide a very
reliable form of process-to-process isolation. As a nile, the server does not provide the
client with the capability or fcunctionality to alter itself. While it usually provides the
client with the capability to alter its data, even this capability can be limited and
controlled. This fonn of process-to-process control is nomally more reliable than the one
that is provided on a single multi-user platform.
2.4 Tiers
The ClienVServer model is usually divided into three basic application components.
They are as follows [Orfali 97al:
1. Presentation Tier (or User System Interface such as session, text input, dialog, and
display management services).
2. Functionality (or Processing Management such as process development, process
enactment, process monitoring, and process resource services).
3. Database Management Tier (such as data and file senrices). This tier may include
existing systems, applications, and data that has been encapsulated to take advantage of
this architecture with a minimum of transitional programming effort.
In the traditional ClientlServer model, the fùnctionality is usually moved ont0 the
client side. This is a typical2-tier Ciient/Server architecture, fat client and thin server.
For a 3-tier ClientIServer architecture, which we will discuss in the next chapter, we
CHAPTER 2. CLIENTISERVER ARCHITECTURE
move the hctionality part from client to another platfonn, leaving it as a thin client and
thin semer.
2.4.1 1-Tier Monolithic
From the inception of the compter industry in the 1950s, through the end of the
1970s, vùtually al1 enterprise software applications were monolithic, with tightly
uitertwined pro- and data. Monolithic Tier is when entire business applications and
data run as one entity on a mainfiame. In this model, each application developer chose
how to structure and store data, often using clever techniques to rninimize the cost and
the time. This tight integration between program and data made it very difficult to model
and reuse corporate information.
With the commercial viability of Database Management Systems in the early
1980s, enterprises began to model their corporate information and create enterprise data
repositories that were accessible by multiple programs. This separation of program and
data caused a fundamental shifi in how companies ran their business; for the fïrst tirne,
so-called "Management Mormation Systems" departments were created to model
corporate data and provide multiple applications that manipulated comrnon information.
This model worked f&ly well when the user interfaces to corporate data were provided
by simple character-based intedaces, accessible by a smdl number of "data processing"
emplo yees.
CHAPTER 2. CLIENTEER VER ARCHITECTURE
The Client/Servet architecture is a generai description of a networked system
where client programs initiate contact with a separate sener program for a specific
hction. In most 2-tier applications, the ClientIServer architecture separates application
into code and management system. One tier contaias al1 the code, and the other contains
the database management system. The database resides on the server and the client-based
application accesses the database through the use of remote SQL calls that are sent across
the network from the client to the server. In Figure 2.2, al1 the application code resides on
the client side, that is a fat client.
Tier 1
Client
Functionality
Request
Tier 2
Server
Aceess I Data
Figure 2.2 - 2 Tier CliedServer Architecture.
However, the widespread adoption of graphical user interfaces in the 1990s, and the
extension of real-tirne information access to millions of desktops, led to a dramatic
CWPTER 2. C'ENT/SER VER ARCHITECTURE
increase in the size and complexity of client applications. Increasingly "fat" cclients
running on thousands of PC's are al1 ûybg to access a central data repository. While
there was some enterprise data reuse, fiom the development perspective, there was linle
reuse of encapsulated business logic.
2.5 Drawbacks of ClientiServer Architecture
2.5.1 Lack of centralized control
Many of the problerns associated with the ClientlServer architecture stem from
the fact that the network computer system does not make it possible to deploy application
components in a central location. OAen, the business logic required for an application is
deployed on each client computer, making maintenance and security difficult. In this
environment, making even trivial changes to a production application c m be problematic.
2.5.2 Lack of security
In a decentralized computing environment, controlling access to information is
more difficult. Security leaks can easily occur because client machines often have access
to algorithms for handling sensitive business data.
2.5.3 Client workload
When al1 of the business logic required for an application is deployed on each
client machine, the clients must have the processing power needed to hancile the
workload. This puts an undue burden on desktop resources. As applications become more
C W T E R 2. CLIENT/SERVER ARCHITECTURE
complex, desktop cornputers must be upgraded to cope with performance demands.
Sornetimes the demands even exceed the capabilities of the standard desktop machine.
For example, advanced operating system featutes such as multithreading and symmetrical
multiprocessing may not be supported by the standard desktop. Without access to the
computing power of a multitasking sewer machine, client applications cannot take
advantage of these operating system features.
2.6 Conclusion
The Client/Server architecture mode1 is a versatile, message-based and modular
infkastnicture that is intended to improve usability, flexibility, interoperability, and
scaiability as compared to centralized, mainfkame, time-shared computing. A client is
defined as a requester of services and a server is defined as the provider of services. A
single machine can be both a client and a server depending on the software configuration.
2-tier ClientISewer architecture has two important advantages. It is easy for
building small applications and many programmen support it. However, applications
built with a 2-tier architecture do not tend to scale well. For large-scale applications,
which usually require complex processing, high transaction volumes, and large numbers
of clients, the following are major issues [Orfali 97al:
Perfomance/scalability.
For large number of users using the system concurrently; data needs to be
transferred acroa the network to the ClienVServer system causing trafic overload
on the network.
Complexity.
CHAPTER 2. CWENTXSERVER ARCHITECTURE
The developer in a 2-tier system should know each component of designing
methodology such as user interface, data access and business specincation.
Supportability.
Most Ztier applications use the Visual Basic, Powerbuilder, Delphi or other
languages or packages to design the ClienVServer system. The user interface, data
access algorithm, and business specifications are tightly intertwhed, which will
cause supportability problems in the system modification and upgrade.
CHAPTER 3. DISTRIBUTED COMPONENT COMPUTING
Chapter 3
3 Distributed Component Computing
3.1 Architecture
Distributed component technologies are an emerging software development
approach that can reduce the cost to develop and deploy large systems. In addition, object
oriented approaches provide an effective Iegacy systern migration path and offer a full
range of technology seMces covering the entire life cycle for object oriented
development [Orfali 97bI.
Dunng the 1980's there was a great deal of experimentation in the computer
research community on "distributed computing" - writing applications that didn't just
access remote data on a DBMS server, but rather distributed various pieces of the
application itself across multiple systems. This research led to the development of
distributed cornputing standards such as the Distributed Computing Environment (DCE)
fiom the Open Software Foundation and Open Group ~ i c r o s o f t 971, and the Common
Object Request Broker Architecture (CORBA) f?om the Object Management Group
[OMG 981. During the 1990s, many companies began the process of building and
deploying so-called "multi-tier" distributed applications, with a thin GUI client taîking to
a middle-tier application server Minllig centtalized business logic, which is taiking to a
traditional DBMS smer (see Figure 3.1).
CHAPTER 3. DISTNBUTED COMPONENT COMPUTING
Client
Figure 3.1 - 3-Tier ClientEerver Architecture.
The 3-tier architecture emerged to overcome the limitations of the 2-tier
architecture. In this architecture, a middle tier was added between the user system
interface client environrnent and the database management server environrnent. This tier
cm perform queuing, application execution, and database staging. For example, if the
middle tier provides queuing, the client can deliver its requests to the middle layer and
disengage because the rniddle tier will access the data and retum the answer to the client.
Distributed computing addresses many of the problems associated with building
ClienVServer appiications [Hoque 981:
a Reuse and mod@ shared components in real t h e .
An essential aspect of component technology is that it is shared in a centralized
location. While this is similar to traditional CliedServer application
development, component technology is more effective because components can
be shared by more than one software application. By standardizing upon the
functionality of what each component does and where it is located, software
developers are able to add the functionality of proven code into their software
applications by simply calling the appropriate object. This approach has a number
of associated benefits, including accelerated software development times,
improved efficiency and less expensive development cycles.
a Reduce the total cost and time of software development.
Because components are reusable, this significantly lowers the cost of software
development. Programmers can simply cal1 an object to perform a specific task,
rather than writing a duplicate code. Also, since distributed component
technology is completely cross-platform. it is not necessary to create 'ttranslators"
or other platfonn migration routines to access data across languages and
platfoms. This reduces not only the tirne to develop software, but also to test and
deploy the application.
Remove dependence upon praprietary vendor solutions.
CHAPTER 3. DISTMBUTED COMPONENT COMPCITING
Uniike previous generations of software development architectures, distributed
component technologies c m fiee information technology managers Born
proprietary vendor solutions. By utilizing ORB (Object Request Broker)
technology and interfaces to multiple laquages and platforms, applications on
one platform are able to "talk" to other applications on different platfoms. As a
result, an application is not constrained to a particular vendor's solutioa, and
developers can leverage their investment in other software applications and
technologies.
O Fully scalable, and networked software development architecture.
Distributed component technologies allow corporations to deliver fully scalable,
completely networked applications that can be delivered on any type of network,
including LANs, WANs and the Intemet. This capability allows an application to
be utilized in a variety of ways. One of the most popular methods of using
distributed applications is via a browser-based interface, because it allows access
at any tirne fiom virtually anywhere in the world.
O Reduce the workload on the client and control access to sensitive infonnation.
By allowing developers to partition application funciions between the client and
the semer, distributed computing offers a natural way to separate user interface
components fiorn the business logic required by an application. Centralizing
business logic on application seners can reduce the workload on the client and
control access to sensitive information.
Enable heterogeneous units to be connecteci together.
CHAPTER 3. DISTRIB UTED COMPONENT C O M P m G
Disûibuted Computing enables heterogeneous units to be connected together so
that they behave as a single system for the user. This results in increased
e fficiency.
a Freedom to select fiom a wide range of hardware, software and networking
components.
hteroperability among ail the leading supplierd products.
a The ability to share information across the enterprise.
The flexibility to adapt computer systems to rapidly changing business conditions.
3.3 Choosing appropriate technology
Several disûibuted computing technologies exist today, including DCOM,
CORBA, CGVHTTP and Java RMI. The suitability of these technologies for a particular
system depends on its infiastructure and the processes followed by it.
in the rest of this chapter, we Qve a brief o v e ~ e w for each of these technologies,
and evaluation and cornparison of each of these technologies with regard to choosing a
particular technology for building DMS.
For the past few years the Web was deployed very rapidly, and people started to
use it for publishing and broadcasting electmnic documents. Since Web pages provide
static idonnation, what is needed is more interactive and applied Client/Smer
architecture. For this reason, the Common Gateway Interface (CGI) was htroduced over
CHAPTER 3. DISTRIBUTED COMPONENT COMPIITMG
HTTP to implcment a 3-tier architecture of Client/Semer system. Programming Intemet
ClienVServer applications with CG1 is a d e r poor choice because HTTP is a slow,
cumbersome, and stateless protocol [Orfali 97aI. The HTTP server machine has to start a
new process for each CG1 request, therefore the web clients must wait for the response to
each request they make. The clients can not send requests synchronously, which means
each request must be processed before starting another task. On the server side, the CG1
program must emulate al1 the processes performed by the client creating a heavy load on
the semer. To eliminate the need to create a new process for each request, an alternative
to standard CG1 named FastCGI was developed. FastCGI creates a single persistent
process for each FastCGI program. Although it is a step in the right direction, it still has
a problem with proliferation: there is at least one process for each FastCGI program. If a
FastCGI prograrn is to handle concurrent requests, it needs a pool of processes, one per
request. Another problem is that FastCGI does not help the FastCGI prograrn to interact
closely with the server.
in response to the performance problems for CG1 and FastCGI, severai vendors
have developed APIS for their semers. The two most notable are NSAPI nom Netscape
and ISAPI fkom Microsofi. As applications linked into the server, APIs may be
significantiy faster than CG1 programs. The CG1 startup/initialization problem is
improved, because the application nuis in the server process and is persistent across
requests. Web server APIs also offer more functionality than CGI: the developer can
write extensions that perform access control, get access to the server's log file, and link to
other stages in the server's request processhg. However, APIs sacrifice dl of CGI's
benefits and sufFer h m the following probiems:
CHAPTER 3. DISTRIBUTED COMPONENT COMPUTING
a Cornplexity. Vendor APIs introduce a steep leaming curve, with increased
implementation and maintenance costs.
0 Language dependence. Applications have to be written in a language
supported by the vendor API (usually C/C++). Perl, the most popular
language for CG1 programs, cantt be used with any existing vendor APL
a No process isolation. Since the applications nui in the server's address space,
buggy applications can compt the core server (or each other). A maiicious or
buggy application can compromise server security, and bugs in the core server
c m corrupt applications.
a Coding an application to a particular API locks it into a particular vendor's
server.
a Tie-in to server architecture. API applications have to share the sarne
architecture as the server: If the Web server is multi-threaded, the application
has to be thread-safe. Otherwise, multi-threaded applications don? gain any
performance advantage. Also, when the vendor changes the server's
architecture, the APIs will usually have to change, and applications will have
to be adapted or rewritten.
3.3.2 Java Technology
Java is a pure object-oriented pmgraxnming language developed by Sun
Microsystems [SUN 98aI. Since Java language compiles its source code to byte code, it is
possible to develop ûuly platfonn-independent client applications and reach a "write once
and nin anywhere" paradigm. The developer can also mite a small program in Java
CHAPTER 3. DISTRIBUTED COMPONENT C W U ï ï N G
named the applet, which c m run in a web browser. The web browsers already exist on
millions of desktop cornputers, so Java applets can use browsers to deploy anywhere.
Although Java gives the ability to provide more interactive content on World
Wide Web with dynamic pages that are no Longer hnited by the capabilities of HTML
and CG1 scripts; it is still not strong enough. Java is insufficient for building robust
enterprise systems, because it lacks a ClientBewer method invocation paradigm,
distribution service, persistence, and streamable storage.
3.3.2.1 Java Servlets
Servlets are Java objects that extend the fùnctionality of information servers, such
as HTTP or Web servers [Hunter 981. A plain HTML document that a Web server
retrieves is static. A servlet, on the other hand, is executed for every request so that it cm
output dynarnic information. For example, a browser generates a request to a server for a
document that contains dynamic information. The server examines the request and maps
it to a particular servlet. It then invokes the servlet, which creates the document with
dynarnic content and r e m s it to the client.
Servlets are cornmonly used with web servers, where they c m take the place of
CG1 scripts. The main advantage of servlets over CG1 is that a servlet is activated by the
nrst client that sends it a request. Then it conthes running in the background, waiting
for further requests and each request generates a new thread, not an entire process.
Multiple clients may be served simultaneously inside the sarne process and typically the
servlet process is destroyed only when the Web server is shut dom. A servlet nuis inside
a Java Virtual Machine (JVM) on the server. Servlets operate solely within the domain of
the sewer: unlike applets, they do not require support for Java in the browser.
The release of RMI (Remote Method Invocation) by Sun Corporation enables the
programmer to create distributed lava-toJava applications, in which the methods of
remote Java objects cm be invoked fiom other Java vimial machines, possibly on
different hosts [Orfali 97al. A Java program can make a call on a rernote object once it
obtains a reference to that object, either by looking up the remote object in the bootstrap
naming service provided by RMI or by receiving the reference as an argument or a r e m
value. A client can call a remote object in a server, and that sewer can also be a client of
other remote objects.
However, RMI is a concrete programming technology that works within the
boundaries of its own languages meaning RMI objects can tak only to other RMI
objects. RMI does not provide interface repositones and a wire protocol for security and
transactions. It is very slow in cornparison to CORBA and DCOM and lacks an
integration tec hnology for fiiture.
3.3.3 DCOM
DCOM is a Microsofi-specific distniuted solution [Microsoft 971. A DCOM
object is not an object in the object-oriented programrning sense; it does not have a
persistent object reference that lets you reconnect to the same object at a later tirne. In
CHAPTU 3- DISTRIBUTED COMPONENT COMPUTiNG
other words, DCOM objects do not maintain states between connections. This c m be a
big problem in environments where there are faulty connections on the Internet.
The current implementation of DCOM does not support distributed naming
services; it is based on the NT regisûy. Configuring DCOM and installing type libraries
is tedious and labor-intensive. Although DCOM is well suited to fiont-end application
development on a Microsoft platfonn, it is not for the other vendors' platforms.
3.3.4 CORBA
CORBA, or Common Object Request Broker Architecture, is a set of
specifications defining the ways so&are objects should work together in a distributed
environment. The organization, which drives the specifications, OMG, or Object
Management Group, has huncûeds of members representing a major portion of the
software industry. The members work together to propose, review, and fmally adopt the
set of specifications to dlow sof€ware objects to be developed independently and yet
work together [Orfali 97~1.
CORBA specifies a standard for the interoperability of object oriented software
and across operating systems, component boundaries and platforms in a heterogeneous
network environment. CORBA is the specification of an architecture and interface that
allows applications to comrnunicate with one another no matter where they are located or
in which language they implemented Pen-Naton 981.
One of the key aspects of the CORBA mode1 is that client and server are isolated
by a well-defined encapsulating interface thereby allowing the client application to
invoke server fiuictionality without knowledge of the server implementation details. This
afTords total fieedom in the way that the service is implemented (programming language
or an underlying hardware). Also, by effectively hiding both server implementation and
underlyhg transport/protocol details, CORBA greatly simplifies client application
development.
The encapsulating interface is dehed using IDL (Interface Description
Language). IDL provides a language-neutral way to descnbe a CORBA object and the
service it provides. The goal of D L is to enable the language-independent definition of
interfaces, so that components (client or server side) written in different languages can
communkate with each other. D L is not a programming but a specification language,
based on C++ language. This applicability to heterogeneous language environments is
one of the key factors differentiating between CORBA and language-specific approaches
to distributed computing such as RMI.
ORB (Obiect Request Broker) is the middleware that manages the interaction
between the client and server objects. The ORB establishes communication links and
routes information between given end points as needed. By using an ORB, a client can
transparently invoke a method on a server object, which can be on the same machine or
across a network. The ORB intercepts the cal1 and is responsible for finding an object that
can implement the request, pass it the parameters, invoke its method, and r e m the
result.
CHAPTER 3. DISTRIBUTED COMPONENT CQMPUTNG
3.4 Conclusion
The 34er architecture has been shown to improve performance and flexibility
when compared to the two-tier approach. Flexibility in partitionhg can be as simple as
"dragging and dropping" application code modules ont0 different cornputers in some 3-
tier architectures.
The main issues involved in designing our system @MS) are platform
heterogeneity, high system reliability and availability, flexibility of location, and the
support for transactions and security. CORBA provides a high level abstraction of the
design which fiees us from the low level communication details required in other
communication technologies like sockets. CORBA also supports an objectsriented
approach allowing better representation of di fferent entities.
The Java inhtnicture starts where CORBA ends. CORBA deals with network
transparency, avoids the CG1 bottleneck, and provides a scalable server-to-server
infkastnicture. CORBA extends Java with a distributed object infiastructure. Because
Java deals with implementation transparency, it allows CORBA to move intelligent
behavior around and simplifies code distribution in large CORBA systems. We conclude
that the combination of CORBA and Java cm be a good, practical fiamework for
developing a user-oriented distributed application.
CHAPTER 4. DMS FWCTIONAtlTY AND DESIGN
Chapter 4
4 DMS Functionality and Design
4.1 Introduction
4.1.1 Related Work
We have looked at some other available marking systems, for example the one
described in MCEXAMS [Dalhousie 951, which is a conventional ClienUSewer mode1
that do not exploit the WWW. Another examples are pillaipakkamnatt, Willcins 981 and
[Acme 981, which are web-based applications that use CGVHTTP. These systems do not
provide the same functionality, flexibility and extendibility as DMS. For instance, they
do not support off-line activities, or use of arbitrary implementation prograrnming
languages (refer to section 7.1).
4.1.2 Objective
The objective of this project is to build a portable and Distributed Marking
System @MS) that can be used for homework posting, submission, and marking using
CORBA, Java and World Wide Web. DMS consists of a central sexver and set of client
C W T E R 4. DMS FWCTIONALITY AND DESIGN
applications. Each application represents a group of clients, such as Students, Markers,
and Instructors.
4.1.3 Stmtegy
In this section we define our strategy for building DMS based on a domain of
distributed persistent objects. The System Architecture (SA) is not dependent on any
particular implementation technology, such as cornputer hardware, operating system,
database, programming language, or distribution technology. We develop persistent
domain objects that cooperate to implement a system of multiple applications. Restated,
the strategy is to develop a group of separate applications rather than one application. By
creating software mapping of the Domain Model, we create a core of functionality that
can be reused by multiple applications. As the business domain changes, so can the
domain mode1 can evolve to support the new applications that will be required. In other
words, developen should be able to develop the system without changing the main
design.
4.1.4 Analysis
In discussing distributed objects, it is important to distinguish between distributed
object programming, which allows the methods of an object to be invoked across a
network, and simple obj ect-oriented programming, where ail the objects are assumed to
share the same address space, or at least reside on the same machine. Object orientation
provides a useful fîamework for consttucting individuai cornputer programs; distributed
objects provide an object-oriented appmach to whole systern design.
CHAPTER 4. DMS FLJNCTIONALITï AND DESIGN
The goal of any software system is to provide implementations of processes
related to a particular Domain Model (DM). During our analysis, we decompose the
Domah Model into a set of related entities that interact to perform the processes.
Examples of entities include User, Course, Assignment, etc. Each entity has to be
associated with data attributes and behavior, collectively properties, that d e h e its role as
a component in the DM.
4.1.5 Push and Pull Model
DMS supports both push and pull models. The push model means that someone has
created or otherwise added value to an information stream and 'pushes' that stream to the
server. An example of this would be posting an assignment outline to group of students
by an instnictor. The pull model means that an information owner has placed an
information object in an area where other users go to 'pull' that infonnation. An example
of this would be downloadhg an assignment outline fiom the server by students.
4.2 Functionality
4.2.1 Actors
Actors are users who can connect and interact with the server. Users include
Students, Instnictors, and Markers as shown in Figure 4.1. Since every user has to be
registered and must be properly authenticated by the system, she or he has a password-
protected account, and therefore we provide one more type of an actor, an administrator
(super-mer), who is the only user allowed to mate, modify and remove accounts.
32
CHAPTER 4. DMS FWCTIONALJTY AND DESIGN
Administrator I nstructor
Figure 4.1 - Acton Diagram.
4.2.1.1 Students
Snidents cm perform several tasks £kom the student interface, including
submitting assignment solutions, downloading marked assignrnents or assignment
outlines and changing their passwords. Students can also check their marks on-line or
download them. For logghg in, the student must enter his/her usemame and password.
Students are presented with a List of the "names" of assignments given so far in their
classes. For submitting an assignment solution, the student can simply indicate the base
directory of the assignment to submit. The whole directory will be compressed and
CHAPTER 4. DMS FWCUONALITYAND DESIGN
shipped to the server. A student has to put the assignment files in one directory. Every
time the student performs a task, hdshe will be presented either with a successfil
perfomiing message or an error message indicating that there was a problem. Al1 enor
messages are clear and give recommendations on how to proceed.
4.2.1.2 Markers
The major task of markers is to download assignments, mark them and send them
back to the server. For downloading assignments the marker should select her/his
course/assignment. Once an assignment is selected, the marker cm acquire al1 solutions.
Marker is presented with a list of the "names" of students who submitted their solutions
so far. Marker c m either download al1 solutions or only some, but he/she cannot
download solutions that have already been downloaded. Courses may have more than one
marker so it is Ieft to the markers to divide the solutions among them. Solutions will be
saved in the marker machine as a tree-like structure, starting with a base directory (the
course name), student name and the assignment narne where the assignment files are
saved.
Once the assignment solutions are downloaded, the marker can disconnect fiom
the network and mark assignments off-line at her or his convenience. For this purpose,
specialized markkg software can be used (it is not available as a part of the cwent
version of DMS). For example, a single programming assignment in C may consist of
many files, but is submitted as a singie Jar file. This file will include the "packing
information", for exarnple, under Unix it may be required that the assignment source files
corne with the make program. This packing information and other specifications cm be
CHAPTER 4. DMS FWCTIONALITY AND DESIGN
specified for each assignment by the instmctor and be available for the marker to
download as a text file. Therefore, we need apreprocessor that retrieves and accordingly
unpacks the assignment (for the above Unix scenario, it will use rnake to create an
executable code). The preprocessor may also nin the executable code against test input
data, if provided, and inform the marker about the results of these runs. Then, an editor
would allow the marker to choose a course to mark, and then move fiom one solution to
another by simply selecting a menu item. Marks are automatically maintained and stored
in a form suitable for upload to the DMS server. A menu item provides standard mark
deducîions that can be customized for each assignment (for example, -10% for wrong
indentation). The marker can annotate the student's solution using appropnate comments.
When marking is completed, the marker moves to the next solution, and the editor saves
the annotated solution along with the mark. Then, when the marker uploads the
assignments to the DMS server, the annotated solution and the mark become available to
the students, and additionally the mark is saved in a central repository on the server.
Markers can upload marked solutions the same way as they download solutions;
when they specify the location of the base directory, the system will automatically upload
al1 marked solutions and show them in a separate window.
4.2.1.3 Instructon
There are several different tasks that the instructor can perfonn fkom the instructor
interface. These are: assigddmp markers tolfkom courses, create/modi@ assignment
accounts, modify assignments marks, delete old assignment accounts, allow or disallow
fuhue submissions or downloading for an assignment, and change thek passwords. Each
CHAPTER 4. DIUS FUNCTIONAtlTYAND DESIGN
of these takes appropriate parameters and the system indicates whether the task
succeeded. The instnictor c m prepare an assignrnent description off-line or on-line.
4.2.1.4 Administrators
The administrator handles creation and modification of the user and course
accounts. Before a user can use the system, the administrator must create account for
himher.
Administrators cm carry out the following activities:
- create, delete and modify user (instnictor, marker or student) accounts
- create, delete and modify course accounts
- register and &op courses to and from user accounts
- set client comection tirne to prevent server overload
- purge or whive old submissions and lirnit file sizes for subrnissions
Note that courses may be taught by more than one instnictor or marker. An
administrator assigns instnictors to courses. Administrator initially assigns markers, but
instnictors can rnodi@ them any time.
4.2.2 Assignment Maintenance
Here we identify the basic activities in the assignrnent maintenance process, as
well as actors involved in this process:
CHAPTER 4. DMS FUNClïONUTYAND DESIGN
Hund-out: Assignment outline is provided by the instnrctor
Hand-in: Assignment solution is provided by every student
Marking: Assignment solutions are marked by the marker
Retum: Marked solutions are retumed by the marker
For a hand-out activity, the assignment outline is uploaded to the DMS server,
and then it is downioaded fiom the server to the student's machine. For a hand-in
activity, an assignment solution is uploaded by the student to the server, and then
downloaded by the marker fiom the server. For a return activity, the marker uploads
marked assignments to the server, and then the students can download them. Note that the
network connections are minimized, and used only when necessary. As soon as the
process of uploading or downloading is completed, the user cm work off-line; in
particular, the rnarking activity requues no network connection.
4.3 System Requirements
'in order to achieve the DMS objective of supporting a Domain System based upon
distributed persistent Domain Objects, we must address a number of specific f'unctional
issues. The following is the description of the most significant issues and the resulting
DMS requirements.
CHAPTER 4. DMS FUNCTIONALITYAND DESIGN
4.3.1 Software Distribution and Deployment
In DMS, Applications and Domain Objects must be able to communicate and
interact across the physical boundaries of the system, which is done through CORBA.
Every actor cm communicate with DMS through what we cd1 a DMS-let, which
can appear in one of two ways; as a Java applet OMS-applet) or as a Java application
(DMS-application). Therefore, there are four types of DMS-lets, one for each type of an
actor; and every DMS-let can be an applet or an application. Using an applet the actor
merely requires a web browser and does not have to go through the installatioo process.
Unfortunately, with a DMS-applet client start-up is slow, since every time al1 of the client
applet classes need to be downloaded fiom the WWW server, so the user may choose
instead to use a DMS-application. DMS provides a convenient way of deploying DMS-
applications; which requires a single step using any browser to point to the DMS home
page, download this application and install it on her or his machine. In addition, the
functionality described above allows for easy updates of any DMS-application; update is
transparent for DMS-applets, and the DMS-application user co~ect ing to the DMS
server can be infonned that she or he should downtoad the newer version of this
application.
4.3.2 Object Persistence
Domain Object Instances have states that need to persist over time beyond the iife
span of a single application. DMS supports persistence of instances in a way that
encapsulates the persistence mechanian and allows the coexistence of multiple
persistence irnplementations.
CHMTER 4- DMS FUNCTIONcllilTYAND DESIGN
4.3.3 Concurrent Object Access
Multiple Client Applications need to have concurrent access to the same Domain
Object Instance. DMS parantees consistency and inte& of instance states across
multiple clients.
4.3.4 Isolated Object Access
An application may need to make tentative modifications to the state of an object
instance prior to committing updates to the persistent state of the instance. DMS provides
isolated access to an instance for modification without affecting the persistent state of the
instance or other concurrent links to the instance.
4.4 Design
During our design, we defined a set of software components that mode1 the
Domain Model as defined by the processes and entities. The Domain Model provides an
encapsulation of the properties of al1 entities in the system. It consists of a number of
Domain Objects, each of which is a representation of a particular entity. The Domain
Object includes both Class and Instance aspects of the entity, where a Class is a particular
type of entity, and an Instance is a unique entity of a given type. For example, "Student"
is a Class and "Ali Elbashir" is an Instance. We map the system processes into
applications, which utilize the Domain Objects as building blocks of functionality.
CHAPTER 4. DMS FWCïTONALiTYAND DESIGN
4.4.1 Design Issues
4.4.1.1 Data Filtering
One of our requirements is that transmissions are reasonably efficient. We don't
want to give users direct and full access to our data source, and so need to filter the data.
We should do the data filtering on the server side before sending them to the client to
avoid network overload. Therefore the server should provide a mechanism for controlling
the flow of data to the client, using filter objects. The filter object resides between the
data source channel and the client, and filters the data using user-specified criteria.
Filter objects are the source of data, as far as the client is concem. Each client
application acquires a reference to its filter object after first logging in. This object is
responsible for filtering the data that will be sent to the client. Each client gets a different
filter object, depending on user pnvileges, giving a user access to only these featwes or
services that he/she is allowed to use.
4.4.1 .Z Persistence
Persistence is one of the issues that must be addressed. How are we going to store
the data? We will use generic interfaces to provide the flexibility to upgrade to another
implementation in the fùture. These interfaces can be implemented to use JDBC to tallc to
a favorite database, Java serialization to persist the data into files, or any other
implementation.
CHAPTER 4. DMS FWCTIONAWTYAND DESIGN
4.4.1.3 Security
4.4.1.3.1 DMS SecUnty
Our implementation provides a password scheme to authenticate the user and
relies on the passing of an authentication token in subsequent operations to ven@ that
user's identity. This is achieved in two steps: Authentication and Authorkation.
Authentication takes place when a user initially attempts to gain access to the
server. At that point the DMS security service challenges the user to prove h i d e r
identity. User will have to enter a user ID and a password. If the user ID and the
password are valid the security s e ~ c e gives the user a token or a ticket that identifies
himher .
Authorkation takes place when an authenticated user requests the use of a
service. The security service examines the user packet to detemine if the user has been
granted permission (refer to section 5.1.1 for more details).
However, the transmission of the password and ID in the authentication process is
not encrypted and they can be cracked. Authentication can be improved by using a "key"
to encrypt and decrypt messages by tumîng text into digital gibberish before sending it
and then by restoring it to its original fom after been received.
4.4.1.3.2 Applet Security
The Java language and mtime have built-in hooks for security. For example,
whenever an applet attempts certain security-sensitive actions through a Java API class,
the method will first check with the Java runtime to detemiine whether the applet is
CHAPTER 4. DMS FC/NCTi!ONALITYAND DESIGN
allowed to perform that action. Examples of such sensitive actions Uiclude accessing the
file system of a Web browser's host, or opening a network comection to another host.
Currently some browsers do not allow applets to perfom any of these actions, even if the
browser's user may wish to allow them. However, in some cases DMS-applet has to be
able to access the user's file system. For example, the student's DMS-applet has to write
to the student's machine when an assignment outline is to be downloaded; and it has to
read from the file system when an assignment solution is to be uploaded. Therefore, we
use digitally signed applets [Sun 98b1, which provide a secure way of giving applets
access to the local machine file system. The user can dowdoad DMS-signature and
declare it as a tnisted entity allowing DMS-applet to access hisher machine.
4.4.1.4 Object Factory
If the server creates a single object instance, only one user will be supported. We
need a way to create objects on demand: an object factory. Object factory implements
interfaces for creating other objects. Remote objects are typically created through an
object factory, which is responsible for allocating instances of these network objects, and
obtaining their object references. In the DMS services, the server object factory creates
each of the remote objects.
4.4.1 J Systen exception bandler
DMS has a system exception handler that attempts to catch fatal system emrs and
exceptions. The system exception handler helps to prevent server application fkom
temiiaating due to problems with individual client co~ections. Whenever a fatal ermr
occurs in a client connection, DMS tries to terminate the client connection without
CHAPTER 4. DMS FUNCTTONALITYAND DESIGN
bringing d o m the server application or interferhg with other client connections. Once
the problem has been detected, the system exception handler throws an exception event in
the client application. The systern h d e r is also used to catch user data access error and
give a clear feedback messages about it. For example, if user tries to download
assignment outlines that are not available yet, the server application will throw an
exception on the client side with an explanation of the emr.
4.5 Architecture
DMS integrates Web-based and ClientIServer applications in a single, unified
architecture. Client Applications are generally standalone applications, but are integrated
into DMS through a single server. As we descnbed in section 4.3.1, client applications
are deployed either as DMS-applets or DMS-applications.
DMS is a 3-tier Client/Server Architecture as shown in Figure 4.2. Tier 1
repments a Client side: DMS-applet clients use HTTP protocol to link to the Web Server
and download the HTML page. Web browser loads DMS-applet fkom HTTP server. A
DMS-applet uses the ORB to hvoke the CORBA server objects. Tier 2 represents a Web
Server side: Client queries the implementation repository and b d s the seMce object at
nui-the. The ORB locates the appropriate irnplementation class, transmits parameters
and transfers control to the object hnplementation. Service object on server side will use
another middleware such as JDBC to communicate with the database server. Tier 3
represents a Database side: it is a legacy system such as relational DBMS. The sewer
side uses JDBC to retrieve the result h m the database. When the request is complete,
control and output values are retumed to the client.
CHAPTER 4. DMS FWCTIONALITY AND DESIGN
Client
* Tier 1
Network Web Sewer Database
Figure 4.2 - DMS 3-Tier Architecture.
Note that DMS-application clients use the CORBA IIOP to Ihk to the server and
the ORB to access the server and do not need to use the web browser.
CHAPTER 4. DMS FI/NCTIONALITY AND DESIGN
4.5.1 Components
Figure 4.3 presents the general architecture of the system. The system consists of
the following compoaents:
Client Server
Figure 4.3 - Architecture of the DMS.
Graphieal User Interface Component (GUI)
GUI component contains al1 of the windows and menus required for the user
interface.
Application Con troller Componen t (AC)
It listens to user interfaces and responds by calling the Connection Manager.
0 Application Conneetion Manager Component (CM)
CHMTER 4. DMS FüNCTIONALITY AND DESIGN
CM initializes the necessary parts of the ORB and establishes a comectioa with
the server. CM communicates with the semer by calling its hctions thmugh the
ORB. - Object Request Broker (ORB)
ORB main task is to maintain two-way communication between DMS-let and the
central server. It lets client objects transparently make requests to-and receive
response fiom server objects remotely. - DMS-Application Component (SA)
SA represents client appiications, which nui as Standalone Applications.
Standalone applications may be written in any programming language. Currently
they are implemented in Java for portability reason. Ail dowdoaded applications
cornmunicate with the server by the use of ORB.
0 DMS-Applet Component (JA)
Java Applet is aiso a client application but written in Java language, downloaded
through the network from an HTTP server, and executed in WWW environment.
The ORB also maintains communication between Java applet and central server.
Semer Listener Component (SL)
SL is a specialized application, which acts as an interface to the server. It is used
to launch the server locally or remotely, create service objects and Listen for
client's invocations.
Object Factory Component (OF)
C ' P T E R 4. DMS FUNCTIONALITY AND DESIGN
OF is the system object factory. It creates and manages access to services objects,
the sources of data for each client. Service objects to clients depend on user
privileges, giving a user access to only these features that he/she is allowed to use.
It allows also logging into the system.
Database Interfaces Component (DI)
DI represents general interface for database. It can be customized to access any
database systern.
DB represents Database Component
r WB is any web server used to download DMS-application or mn DMS-applet.
WS is the Web server where the DMS-let initially resides.
IIOP (Internet Inter-ORB Protocol) is CORBA protocol used in ORB to ORB
communications.
CHAPTER 5. SYSTEM CMPLEMENTA TION
Chapter 5
5 System Irnplementation
[n this chapter, we descnbe the system implementation using class diagrams and
code fragments.
We use 0rbixWeb3.1 [Iona 981, an implementation of CORBA in Java and
SDK1 J.8 [SUN 98a] for our implementation. The advantage of OrbixWeb is that it uses
iïOP for its transport, which allow clients and servers to interoperate with clients and
servers developed and hosted using ORBs from different vendon. OrbixWeb also
provides a daemon activator that allows clients to remotely activate the server.
5.1 Remote Interfaces
Figure 5.1, which is drawn using UML (Unified modeling Language) notations
Fational 981, shows a class diagram of the CORBA objects, as defined by their IDL
interfaces. These interfaces are stored in separate modules (packages). Each module
contains one or more interface. This separation is very important for the software
deployment. For example, to deploy a Student Client Application, we include Student
Module, which is separated fiom other client modules.
CHAPTER 5. SYSTEM IMPLEMENTAî7ON
1 Authenticata
Imt ctor -k-
Figure 5.1 - Interfaces and Packages Diagram m).
Below we describe the interface implementations and their d e s in the system.
C W T E R S. SYSTEM IMPLEMENTAZ7ON
5.1.1 Authenticator
The Authenticator interface is not meant to be used directly. It is intended to be
inhented by other objects that will provide this hctionality within the context of their
own intended use. It supports methods that allow clients to log in, change their password,
and ven@ identities.
The following is the code listing for the Auth module written in DL:
module Auth
//user types
enum UserType {
Studen t, Marker, Instructor, Administrator
1;
// Authentication token
typedef sequence<octet> Auth Token:
// Packet to be passed to al1 Secured" servers
string userID;
AuthToken token;
I ;
CHAPTER S. SYSTEM IMPLEMENTATION
// Failure reason
InvalidUser, InvalidPasswd, Tirnedûut. BadToken, BadFi [ter
//Exception for security errors
exception AuthFailure /
string descriprion;
AuthReason reason;
// Abstract Authenticator inter$ace to be specialized by
//abjects that need to authenticate users.
interface Authenticator {
Auth Packet login (in string user, in string pasmd,
void disconnectAndDestroy(in Authpacket tok)
CHAPTER 5. SYSTEM MPLEMENTATION
The Auth module defines Authenticator interface and remote objects for
exception handling. Once a client logs in, the Authorized object retums an Autltpacket
object that contains the client's "credentials." AI1 other methods require these credentials
that contain the user's identity and access permissions. The Auth Token sequence is simply
authentication data that the server uses to venQ the user's identity. Using a sequence of
octets means that data will be transmitted without modification. The Authpacket simply
encapsulates the authentication data with the user name. It is the structure that is passed
between client and server objects for authentication purposes.
5.1.2 FilterFactory
The FilterFactory, which is defined in the DMS module, generates and manages
access to DataFilter objects, the servant objects for clients. The FilterFactory therefore
does two things: It creates DataFilter objects, and manages access to those objects via an
authentication mechanism.
As shown in Figure 5.1, FilterFactory inherits from the Authenticator interface
dehed in the Auth module. The application-level hctionality of the FilterFactory is
provided by the FilterFactov interface, which allows clients to obtain a reference to a
FillerFactory object after logging in. The FilterFactory creates the DataFilter object and
r e m s its reference to the invoking client. The FilterFactory destroys the object when
the user logs out.
CHAPTER 5. SYSTEM IMPLEMENTAî7ON
Note that each method takes an AuthPacket authentication token as a parameter.
This allows the FilterFactory to authenticate the client on every operation. Without a
vaiid token, no client can hvoke any of the methods successfÙlly. This technique is what
the CORBA Security service does. Unfortunately, it is not available in the cunent
CORBA implementations.
The following is the code listing for the DMS module written in DL:
module Dms
{
// Failure reason
enum DmsReuson {
Invalid, NotFound, NotMarked, Exist, BadFilter
//Exception for data errors
exception DmsFadure {
string description;
DmsReason reason;
// data structures
CHAPTER 5, SYSTEMMPLEMENTATION
typedef sequence~uctet > Bytes;
//array of strings
typedef sequence<strhg> Strings;
//ossigrnent object
smrci File {
string name;
string courseSym;
string assignsym;
Bytes buffer:
1:
//coursefiller
smct CourseFilter {
string symbol:
string name;
Strings inshuctors;
Strings marks;
C ' T E R 5. SYSTEM lMPLEMENTATXON
string symbol;
string dueDate;
string symbol;
double mark;
string symbol;
sîring name;
Bytes outlines;
double mark;
//ist of courses filrem
CHAPTER 5. SYSTEM IMPLEMENTATION
Mist ofasignments filters
typedef sequence~AssignFiIter> AssignList;
//Est of marks filters
typedef sequence<MarkFiiter> MarkList;
// Abstract FilterFactory interfce extends Authenticaior
// interfocce fur provide its functionality when if is
//specialued by objects that need to authenticate users.
interface FilterFactory : Auth::Authenticator {
any getFiIter(in Auth::AuthPacket tok)
raises(Auth::AuihFaiIure);
boolean changePasswd(in Auth::AuthPacket tok, in string mrP W,
in string newPw
ruises(A u th::A uthFailure);
1;
// Abstract Nttegace to be inherited by other DataFiIter interfaces.
interfce DataFilter {
1; 1;
CHMTER 5. SYSTEMIMPLEMENTAl7ON
The DMS module defines FilterFacto~, DataFilter interfaces and generic remote
objects that can be used by ali clients.
5.1.3 DataFilter
DataFilter is an empty interface. Other interfaces are inherited nom it for the
sake of polymorphism. Therefore, DataFilter object could be any of these interfaces:
AdministratorDataFiZter, InstnrctorDataFiIter, StudentDataFifter, or MarkerDataFilter.
DatnFilter object is the source of data, as far as the user sees. Each client
application acquires a reference to its DataFilter object d'ter first logging in. This object
is responsible for filtering the data sent to the client. Each client gets a different
DataFilter object, depending on user pnvileges, giving a user access to only these
features that hdshe is allowed to use. For instance, here is the Student Module code,
w hich de fines StudentDataFilter intedace:
module Student
// Filtered data filter source
// Abstract StudentDataFilter interface to be imp Iemented by
// StudentDataFilter object
interfce StudentDataFilter :Dms::DutaFilter {
Dms:: CourseList get Courselist (in Auth::Auth Packet tok)
raises(Auth::AuthFaiIure);
CHAPTER 5. SYSTEM IMPLEMENTA TTION
Dms::AssignList getAssignlist(in Auth ::AuthPackt tok , in string CS')
in string a S p )
raises(.::DmsFailure, Auth::AuthFaiiure) ;
void submit4ssignSolution(in Auth::AuthPacket tok,in Dms::File file)
Dms::File getMarkedAssign(in Auth::AuthP acket tok,in string cSym,
in string aSym)
raises(hs::DmsFaiIure, Auth::AuthFaiiure);
double getAssignMork(in Auth ::AuthPacket tok, in string cSym,
in string uSym)
1;
1;
The StudentDataFiZter interface dehes al1 the remote services that a student can
use.
CHAPTER 5. SYSTEM IMPLEMENTATION
5.1.4 DataManager and DataResource
DataManager and DataResource are Java interfaces used to access databases.
These interfaces are designed to be general interfaces that can be implemented to access
any favorite database system and also, cm be switched to remote interfaces (IDL
interfaces) easily and used to access a remote database system. Currently, they are
implernented as local Java interfaces and are used to talk to the file system in the server
machine or database through JDBC.
An adrninistrator uses DataManager to maintain user, and course accounts, while
users use DatuResource to access data.
5.2 DMS Client Side
The Client application, which we cal1 here DMS-let, cm appear in one of hKo
forms; as a Java applet (DMS-applet) or as a Java application (DMS-application).
Therefore, there are four types of DMS-lets, one for each type of an actor; and every
DMS-let cm be an applet or an application. Client applications are somewhat similar in
the design therefore we wil1 only describe the largest one which is the Marker Client
Application (MCA).
CHAPTER 5. SYSTEM IMPLEMENTAï7ON
j <<Interface>> 1 I Controller I t / ConnectionManager
; ActionListmer r< /-. 1
Figure 5.2 - Client Application Class Diagram (UML).
Controller is the central class. It Listens and handles the interactions of the user
with the G U S and uses ConnectionManager to make remote calls. Because most of the
f'unctionality of the user interface is provideci through button actions, Controller
implements the ActionListener interface. This allows pmcessing of events fiom the
CHAPTER 5. SYSTEM IUPLEMENTA TlOM
various buttons fiom ail GUIS within a single class. LoginGu inherits fiom
java.applet.Applet and presents the login screen for the user to enter hidher user ID and
password upon start-up. Once the user has logged in, the controller shows the user its
main screen, which is presented by the MainGUI class. The main screen provides a
display of al1 the buttons and lists for the user to interact with the system. The
ConnectionManager handles ail interactions with the CORBA ORB.
5.2.1 Creating the user interface
in a distributed environment, most if not al1 of the user interaction take place in
the client application. The client application contains al1 of the windows and menus
required for the user interface. In addition, the client application contains scripts that
perform processing in response to each action that the user takes. For example, these
scripts can speciQ what happens, when a user clicks a button or enters data into a text
box in a window.
5.2.2 Connecting to a sewer
To allow a client application to function in a distributed environment, we need to
connect to a server application. Here, to connect to the server, we use the
ConnectionManager object, which needs to execute statements required to perform these
operations:
Initiake the ORB.
Look up the server.
Set properties for the client.
CHAPTER 5, SYSTW IMPLEMENTATION
Invoke bind fiinction in the ORB to establish a comection to the server
application.
Here is the Java code for the ConnectionManager constmctor:
public Connection.Manager(Contrul1er cuntrol) {
// Save con troller reference
controller = control;
// Initialize ORB.
orb = ORB. inito;
filterFactory = null;
//get the server host which is the 1oginGUTapplel host
serverhost = conr*oller.login G U.1. upplethost;
System.out.pRntln("Server Host: "+serverhost):
// bind to server object and gelfilter factory proxy object
) catch (SystemException excp) {
contro1ler.popMsg~E~or~ '? Initialùation Failed! Try again later. .. '7;
Systern.ew.p~ntlnrEwor during initiaIization of 0bjectFoctor-y'~;
System.err.println('%rception: " + excp);
CHAPTER 5. SYSTEM IMPLEMNTAîïON
retunt;
5.2.3 Invoking methods of remote objeets
Once a comection to a server application has been established, and the client
application has got ObjectFactory proxy object, the client can invoke the login method of
the ObjeciFactory, by referencing the proxy object, to login and to get the filter servant
object.
For instance, the marker client will invoke the gefFiiter fhction in the
ObjectFactory to get the MarkerDataF'iiter object. The ObjecfFactory will return a
UserDataFiiter type referencing to MarkerDataFilter. Then the client will extract it to a
MarkerData Filter.
Here is the code fiagrnent from the ConnecfionManager that is used to retrieve a
filter object nom the server:
//get ofilter object
trv l
//create Any CORBA object
//set filter object
any =filterFacto~.getFiIt~@acker);
CHAPTER 5. SYSTEM IMPLEMENTATION
// extract any object to MarkerDataFilterte object
fil ter = (MarkerDataFiZter) MarRerDataF'ilterHeipet.extract(any);
) catch (AuthAuthFailure authkcp) f
System. err.println('3ecurity Failure!! 'y;
coniroller.popMsgrEnor ", "! SecunrZty Failure!.. .'y;
return false;
I
catch (SystemException excp) {
System. err.prin tln("Err0r occured attempting to getFilter* 7;
excp.printStackTrace(System. err);
con~oller.popMsg("Emor", "!. Initialization Failed! Try ugain! '9;
retum false;
I
rehïrn true;
l'
The above code is similar in al1 clients, the connection.Manager creates and
initializes an Any CORBA object to receive the servant proxy object and then extracts the
Any object according to the client type; in this case to a marker servant object.
CHAPTER 5. SYSTEM IMPLEMENTAïTTlON
5.3 DMS Server Side
DMS defines six servant objects. These are the authorization manager, the object
factory, and the four original data filter objects (see Figure 5.3). Client pmgrams ded
with the authorization manager at M. The object factory creates multiple filter objects
for clients. M e r login, clients request a filter object fiom the object factory and receive a
reference to one of these relatively short-lived objects. The ObjectFactory object is the
one object outside that users should be able to find. M e r initialization, a name in the
namiag service ("DmsServern) has a reference to this object. That reference must then be
exported so outside users can find it. The DMS server maintains a temporary collection
of the currently logged in users.
Figure 5.3 - Server Class Diagram (UML).
64
CHAPTER 5. SYSTEM IMPLEMENTA UON
The FilterFactoryhpl class is the main impiementation servant for the
authorization and object factory remote interfaces.
makePacket() is a utility function for making authorization packets. It is a hook
where a variety of usehl per-packet processing cm take place. We place the array index
of the user in the packet so we c m easily h d it iater.
Here is the code for the AuthPacket method:
private AuthPacket makePacket(UserData ud, int inder) {
AuthPacket pck;
// use a sequence ofoctets tu grantee that the data will be
// tranismited without modifcation
byte oc[] = new byte[l];
oc[O] = (byte) inder;
// retum the packet
retum pck - new AuthPacket(ud. userlD, oc);
I
getFilter0 is a cal1 for the object factory. M e r the client logs in and gains an
authorization, the client calls getFiltet0 to get a reference to a DatuFitter object. Each
user gets hidher own unique data filter object that c m be used to access the data.
Here is the code for the getFiltW method:
CHAPTER 5. SYSTEMIMPLEMENTATION
public org.omg. CORBAdny getFilter(AuthPocket tok)
throws Auth. AuthFailure {
// Check auth packet
if!isAuth valid(tok)) {
throw(new Auth.AuthFailure("lnvalid Token 't
AuthReason. BadToken));
I
// Get index from auth packet
int ind=0;
if(toktoken.lengrh == 1) {
ind = tok token[O];
1
Server.trace("getFi1ter: d e n " + ind);
// create an any CûRBA object
org. ontg. CORBA.Any any = org.omg.CORBA ORû.init#.create-any0;
//gel the user current record
UserData usr = (UserDafa) curentUsers.elementAt(ind);
// initialize the DataFilter object
DataFiiter df = null;
CHAPTER 5. SYSTEM IMPLEMENTATION
//Assign this object to be the Authenticator object for this user.
Authen ticator auth = (Authenticator) this;
// checks the user type and create a probote m e r object for it
//and inserted to the any CORBA object
if(usr. type == Auth. UserType..Studenl)/
df = new StudentDataFilterlnipl(uuth, tok);
Systern.out.printfnn(3 "+usr.userlD+" got Student Filter.");
I
else
flusr.îype == Auth. UserType.Marker) {
df = new MarkerD~taFilterImpl(auth. tok);
System.out.println('3 "+usr. userlD + " got Marker Filter. ");
I
else
df = new InsmrciorDataFilterImpl(auth, tok);
Systern.out.println( "+usr.userlD+" got Instructor Filter. '9;
I
else
CHAPTER 5. SYSTEM CMPLEMENTA TION
i fwr . type == Auth. LlserTypeAdministrator) {
df = new AdministraiorDataFilterlntpl(aurh. tok);
System.out.println (3 "+us. userID+ " got Administrator Filter. '7;
I
Semer. trace('getFi1ter: Created filter.. . '7;
Semer. trace("getFi2ter: registered new DutuF'ilter 7;
// insert the filter object into any CORBA object
any. insert-Object(dfl;
// Register the newfilter with the current user record
synchronired (this) {
DutaFilter filter = usr./ilter;
//lfthe user has an oldftlfer here destroy it
// User can only have oneftlter ut a time.
@?!ter != nul[) {
//simply destroy the stored reference
filter = null:
I
//Store reference to new DataFilterjilter ut the user temporas, record
((UserData) currentUsers.elementAt(ind)).filter = dfi
CHAPTER 5. SYSTEM 1MPLEMENTAI7TION
I
Server.trace("getFi1ter: stored new DataFiltert');
//return amer reference object tu the client of type CORBA any
//whereas each client knows how to conshuct itssfilter object.
retum any;
I
Clients use their filter servant objects to access the semer.
CHAPTER 6. APPLICATION EHMPLES
Chapter 6
6 Application Examples
In tbis chapter, we illustrate the DMS system in action by studying an example of its
use. Tbroughout the description, we use screenshots to illustrate the interfaces that users
will typically encounter while using the system, but we do not provide complete coverage
of al1 operations available to users under ail possible circurnstances.
We begin with maintenance of course and users accounts, and then illustrate the
assignment maintenance process, but first we illustrate the logging in process that must
be taken by al1 users every time they want to access the system.
6.1 Logging in to the system
Upon client start up, each user is presented with hidher login screen, which appears
sirnilar to al1 users. The only difference is thai the username label has the user type. For
example, the login screen for administrators appean with a usemame label
"Administrator" as shown in Figure 6.1. The user has to provide valid user ID and
password.
CHAPTER 6. APPLICATION EXQMPLES
Figure 6.1 - Logging in Screen.
Once the user has logged in, the system presents the main user interface screen. For
example, Figure 6.2 shows an administrator main interface screen, which is different
fiom other user interfaces.
Figure 6.2 - Administratofs Main GUI.
Another example is student main interface screen as shown in Figure 6.3, which
appears somewhat similar to markers and Uisüuctors.
Figure 6.3 - Student's Main GUI.
The lefi-hand side column is generated based on courses currently taken by this
student. Once a specific course is selected (COMP2663), the description of this coune
appears in the center column, and assignments for this course appear in the right-hand
column. A specific assignment can be chosen (Assignment # 1 above); brief information
about this assignment is then appended to the central columa, which includes assignment
name, due date and assignment mode. Assignment mode indicates whether the
assignment is a new assignment, or has been submitted, marked or downloaded.
6.2 Maintenance of Course and User Accounts
In this section we illustrate the creation of two course accounts (MATH1423 and
COMP2337) and some user accounts, then illustrate how to register users to those
courses.
Maintenance of user and course accounts is the administrator's respoasibility (refer
to section 4.2.1.4). When an administrator tries to create a new course or user account,
the system will prompt the user for an account ID to check whether the account already
exists or not. Then the system wili present the course screen and will not dlow the
administrator to modify the account ID. Figure 6.4 shows how the administrator creates a
student account (Studentl). The acûninistrator has to provide a user name, an initial
password, and speci@ the user type. The administrator can also provide some comments
about the user, which are accessible only for other administrators.
CHAPTER 6. APPLICATION EXAMPLES
Figure 6.4 - User Account Maintenance.
The administrator adds other user accounts (student2, markerl, and instructorl)
the same way described above.
To create a course account the admlliistrator has to provide the course symbol and
the course name. The administrator can aiso provide some cornments about the course,
which are accessible only for other administrators.
Figure 6.5 - Course Account Maintenance.
When user and course accounts are created, administrators cm register users to
the courses. Figure 6.6 shows how an adrninistrator registers a student (studentl) to a
course (MATH1423).
Figure 6.6 - Course Registration.
The administrator is presented with a list of the user courses that he is already
registered in. In the above case the student has not registered to any course yet. The
adrninistrator has to click on "Add" to register the student to a course and then provide
the course symbol. The system will validate the course symbol and add the course to the
student course list. The adrninistrator registers the instnictor and the marker to the course
the sarne way described above.
6.3 Assignment Maintenance
In this section, we will illustrate the assignment maintenance process that we
described in. section 4.2.2.
Maintenance of Assignment Accounts is one of the instructor tasks (refer to
section 4.2.1.3). Instructor can maintain assignment accounts for his/her courses that
he/she has been registered in by an adminishator. The insûuctor can prepare an
assignment outline either off-he, or on-line; see Figure 6.7. Assignment outline must be
loaded in a text format so that it can be viewed on-line in the user GUI text area. To
prevent instnictoa fiom uploading files that are not in a text format, we limited their off-
line option. Inshuctors can only use cutfpaste technique for uploading assignent
outlines. The instructor should also provide other information such as assignment due
date and maximum mark.
Figure 6.7 - Maintenance of Assignrnent Account.
A student c m get access to assignment outline in two different ways. One way is
to download assignment outline as a text file that c m be saved in hisfher machine, and
access it off-line. The outline file name is a combination of the course symbol and the
assignment number. The other way is to view them on-lhe in the text area. Figure 6.8
shows a student who viewed the assignment outline, on-line and tries to download it to
his machine.
CHAPTER 6. A PPLICQ TION EXQMPL ES
Figure 6.8 - Assignment Outline Downloading.
To submit an assignment solution, the student should point to the assignment that
he/she wants to subrnit the solution for it in the assignment list and then click the submit
button. DMS will ask the student to specify where the assignment is located in the local
drive. Then DMS will automatically compress ail files in the selected directory to one
compressed file and send it to the sener. For example, in the case that is shown in Figure
6.9, DMS will compress the Listed files and send the compressed file to the server.
CHAPTER 6. APPLIC4TION EXlMPLES
l~raph Theroy end Hauix Aïgcbra
Figure 6.9 - Assignment Solution Submission.
The rnarker c m get assignment solutions that have been submited to the server by
students. Figure 6.10 shows how marker downloads assignment solutions for the selected
assignment (Assignment #1) by clicking "download solutions" h m the download menu.
CHAPTE. 6. APPLICATION EXQMPLES
iraph &iy and R l l a u i x Aigebra 1
sigmenc Na8e: Lrtor and tloacïng point eDatc : Ved Apr 21 02:05:00 1999
studentl Wed Apr 2 1 02:02:51 GMT 1999 -- j studentl Wed Apr 2 1 02 :OS: 10 GMT 1999 late
Figure 6.10 - Marker downioads solutions.
The marker is presented with a list of student solutions and their States; the state
indicates whether the assignment was submitted late or before the deadline. In Figure
6.10, two solutions are submitted and are available for downioading. Note that markea
are allowed to download late solutions too.
The marker can download al1 or some of the solutions, which will be saved on
his/her drive. Once the assignment solutions are downloaded, the marker can disconnect
CHAPTER 6. APPWCR TION EXQMPLES
from the network, and at hermis convenience, mark assignments off-line using DMS
Marking Editor (refer to section 4.2.1.3) or other software tools.
Markers can upload marked solutions the same way as they download solutions.
The marker has to speciQ the location of the course directory from which he/she
downloaded the solutions. DMS will automatically upload dl marked solutions and show
them in a separate window for mark update and then submission. Figure 6.1 1 shows how
a marker submits marked solutions to the server.
itudentl 3 tudent2
Figure 6.1 1 - Marker uploads assignrnent solutions.
CHRPTER 6. APPLICATION EXAMPLES
A student can get hidher markeâ assignments aftm being uploaded by the marker
to the semer. Figure 6.12 shows how the student downloads his marked assignment.
Figure 6.1 2 - Student downloads marked solution.
The marked assignment will be downloaded as one compressed file on the client
side. DMS will extract the file into the selected location. Note that cornpressing and
extracting file(s) process is doue implicitly and is hidden fiom the user.
CHAPTER 7. CONCLUSIONS
Chapter 7
7 Conclusions
7.1 Concluding Remarks
In this thesis, we leamed about a nurnber of basic areas of object technology such
as distributed objects, Java, and CORBA, and showed how they fit together to build an
extensible, portable, and disûibuted system.
We illustrated aspects of disûibuted object system construction that are both
important and recurring; including client/server partitioning, multi-user support,
authentication and security, integration of a legacy system and the distribution of
asynchronous events and data-streams across a heterogeneous network.
Our main aim was to establish whether we could develop reasonably sophisticated
client/server software that does not limit us to a specific hardware or an operating system.
For example we wanted to be able to accommodate a student who uses Unix on a PC, and
a marker using a Macintosh. We illustrated that our CORBA-based system correctly
performed its functions, and evaluated our approach with respect to design and
development, maintainability, configurcition, deployrnent, extensibility, and user
interface. We demonstrated that when the Java language environment, the World Wide
Web (WWW), and the Cornmon Object Request Broker Architecture (CORBA) are used
84
CHAPTER 7. CONCLUSIONS
together, they provide a powerfûl set of tools for developing and deploying user-oriented
distributed application.
We illustrated how DMS provides two different approaches on the client side.
DMS-application is based on a conventional client/server model, while DMS-applet is
based on a web-based clientlserver model,
We concluded that our approach to building distributed applications is not only
practical, but is in some ways supenor to the widely used CG1 approach, see for example
Homework Submission System [Pillaipakkamnatt 981, as well as conventional
clientherver approaches that do not exploit the WWW e.g. MCEXAMS [Dalhousie 951.
Below we descnbe the advantages and disadvantages of the DMS approach over
other approaches.
DMS software is independent of particular host architectures and operating
systems; it will execute on any platform supported by Java or a Java-enabled WWW
browser. DMS can also support langage-independent distributed objects. It is object-
oriented, with al1 its associated software engineering advantages. DMS client software
can exploit a richer GUI tooikit of Java for more sophisticated UI design. Operations
between client and server sides are explicitly defined in DL. The DMS-applet client
software is installed on demand via the WWW infiastructure. There is no need to write
the software that conveys operation requests and responses between clients and servers;
the ORB provides this. WWW servers are not involved in any operations between the
Java clients and server objects. DMS supports not only pulling information, and online
access, but also pushing information on to a client's machine for off-line work. DMS has
85
CHAPTER 7. CONCLUSIONS
generic interfaces for database access to provide the flexibility to upgrade to another
implementation in the future.
While implementing DMS applications using Java and CORBA, we encountered
some issues. An ORB must be licensed and installed to support both development and
execution; thus the new release of JDK (1.2) has included a Java ORB. DMS-applet
client start-up is slower than that for an HTML page with forms, since some or the client
Applet classes may need to be downloaded fkom the WWW server (though several
WWW browser-caching schemes are in use). The process of declaring DMS signed
applet to be tmsted entity is cumbersome. Some browsers still have considerable bugs in
their Java nuitirne or Java API implementations. For example, Netscape Navigator for
Solaris does not correctly show the standard Java GUI window component, specifically,
the GUI coloa. DMS-applet client state is at the mercy of the WWW browser. There is
no standard for what a browser does with the Applet when the user leaves the Applet's
page, then retums to it later (it might pause the Applet then restart it, or it might destroy
the Applet then recreate it).
Finally, we would like to indicate that, as a result of a separate project, DMS
Database side has been re-implemented to use JDBC to tak to Microsoft Access
Databases and did not require any change in the server or client sides. DMS Marking
Editor has not been implemented yet.
CHAPTER 7- CONCLUSIONS
7.2 Future Directions
We have demonstrated that DMS provides a good example O: P distributed systems.
However, there are many ways in which this work can be extended As an example, the
DMS server currently generates a transient object for each client connection and these
objects stay alive as long as the server is dive. These objects could be used to keep tmck
of client connections and to send notifications to users. For example, students could be
notified when their assignments are marked. Additionaily, these objects could also be
used to manipulate the server dynamically, and allow super users to monitor the server
and discomect or Iimit client connections.
Bibliography
[Acme 981
[Ben-Naton 981
[Daihousie 951
[Hoque 981
[Hunter 981
[Iona 981
[Lewis 981
[Microsoft 971
[OMG 981
[Orfali 97al
Acadia University (1 998), Wolfiille, NS. ACME. Availble via: <http://acme/ >
Ron Ben-Natan (1 998). CORBA on the Web. MxGraw-Hill, Donnelly & Sons: New York.
Dalhousie University, Halifax. NS. MCEXAMS: Multiple Choice Exarn Marking System (1 995). Avaiiable via: < http://is.dal.cd-itu/ 1995/falI/index.litmL>
Reaz, Hoque; Tarun Sharma (1 998). Programrning Web Components; MxGraw-Hill; Donnelly & Sons: New York.
Jason Hunter (1 998). Java Servlet Prograrnming ; O' Reilly ; Cambridge.
The OrbixWeb 3.1 Programmer's Guide and the OrbixWeb 3.1 Reference Guide. Available via
http://ww.iona.com/nroducts/internet/orbi.uweb/fordevelo~ers.html
Lewis; Barber; Siegel (1998) Programrning With Java IDL; Wiley & Sons: New York, NY.
Microsoft (1 997). COM/DCOM Specification. Available via: ~http://www.micros~fi.com/oiedev/olecom/title.htm~
Object Management Group (1 198). The Common Object Request Broker: Architecture and Specification. Available via < http://www.omn.ora/librar~/c2indx.h~l>
Robert, Orfali; Dan Harky (1 997). ClientBever Prograuunhg with
JAVA and CORBA. Wiley & Sons: New York, NY.
[Orfali 97b] Orfali; Harkey; Edward (1 997). The Essential Distributed Object survival guide. Jon Wiley & Sons: New York, NY.
[Orfali 97d] Orfali; Harkey; Edward. (1997). Instant CORBA. Jon Wiley & Sons: New York, NY.
[Pillaipakkamnatt 981 Pillaipakkamnatt, Krishnan, Wilkins, Dawn (1 WB). A Tool For Homework Submission Using the World Wide Web. Webnet 98, Orlando.
[Rational 981 Rational Software ( 1 998). The Unified Modeling Language (UML). Available via htt~://ww.ntiona~.com/
[SUN 98a] Sun Microsystems. The Java Language Environment (1998). Available via htt~://www.iavasoft.com/docs/white/laneenv/ ( 1 1 September 1998).
[SUN 98b] Sun Microsystems. JDK 1 . l .x Signed Applet [On-line]. Available via htt~://iava.sun.com/securit~/si~~nExam~le/
APPENDLXA. DMS I?VSTUTION GUIDE
Appendix A
DMS Installation Guide
In this Appendix, we describe the installation of DMS clients and server. Both
server and client installations need a Web browser, and JDK version 1.1.5 or higher, but
not version 1.2.
1) Server installation
A Web Server and OrbixWeb h m IONA, see [Iona 981 are needed prior to
installing DMS server. Cunently, DMS is installed on evilqueen.acadiau.ca, so this
hostnarne will be used as an exampte.
There are six steps to install and make the DMS server available to clients:
1. Get the DMS zip file (dm-PackageAp) nom a DMS host.
2. Unzip the file into a DMS directory (any directory that cm be accessed through the
WWW)*
3. Unzip the server zip file to a server directory (any directory).
4. Add the server directory path to the OrôixWeb classpath (use ûrbixweb
Configuration Tool).
5. Start the OrbixWeb Java daemon and then register the DMS server by typing the
following command:
% putit -j DmsSenrer Server.Sener
6. Change the activation and launching modes of the DMS server to public modes by
typing the following commands:
% chmodit DmsServer i+all
% chmodit DmsServer l+all
DMS server will add an administrator account to the database, and give it a login
narne "superuser" and a password "superuser". This account can be used to login to DMS
server for the first time.
II) Client Installation
DMS client c m be installed and nui as a standalone application @MS-
application) or as an applet (DMS-applet), which nuis in a web browser.
DMS client applications can be downloaded and installed in the user local drive.
Downloading client application involves downloading the client classes and CORBA
ORB (zIMbyte/application). These are the steps to download and install a client
application:
1. Get the client zip file fiom the DMS Download Page
APPENDLVA. DMS lNSTALL4 TION GUIDE
(see htttx//evil~ueen.acadiau.ca/dmsPage/downhdhm) and then unPp the P p file.
2. Set CLASSPATH
DMS application uses the defauit CLASSPATH that is set in the client driver. If
you encounter any problems with the CLASSPATH try to add the application directory to
your CLASSPATH. For exampie, if you have downloaded the studeat Application to
C:UlyApp\ , then your CLASSPATH should include this path.
3. Run the client application
To start DMS Client application, you must type the application package narne, the
LoginGUI class name and the serverhost name. The hostname is the DMS host name
from where you downloaded the application. For example, to run a DMS Application that
has been downloaded in c:\MyApp and connect to a server that was installed on the
remote host evilqueen.acadiau.ca, you must type
C :\M yApp\ java DMS App .LoginGu1 evilqueen.acadiau.ca
Note that DMSApp must be one of the following:
StudentApp for Student Client Application
MarkerApp for Marker Client Application
InstructorApp for Instmctor Client Application
AdminApp for Administrator Client Application
This will launch the Login GUI, which can be used to logon to the DMS server.
APPENDLX A. DMS /NSTAUAïTON GUIDE
Downloaded applets are prevented fiom writing or reading files to or fiom your
hard disk. Unfomuiately, the JDK 1.1 signing and venfication is not supported by the
web browsers (Netscape's and Microsoft's.). You can use the Java Plug-in in the Netscape
browser to get access to the more ment JDK technology. You can run JDKl. 1.x signed
applets with the Plug-in plugged into the Netscape browser.
To allow DMS applet to access your drive, you need to use a Netscape browser
and do the following:
1. Get the latest version of the Java Plug-in, install it, and make sure it is not set to use
JDK1.2. It must use JDKl . 1.5 or higher.
2. Set up your system Co accept code signed by Ali Elbashiri.
You should get a copy of Ali's certificate, import it into your system's identity
database and declare Ali to be a trusted entity, then you'll allow any applet signed by Ali
to have full authonty on your system. Here are the steps you need to take to accomplish
that:
a) Download a copy of Ali's certificate and store it in a file named aii.x509 (see
htto://evilaueen.acadiau.ca//dmsPage/DMSsie.htrn~. -
b) Create the identity "Ali" in your JDK I .1 identity database. By passing the parameter
"tnie", you're sayhg that you want Ali to be a trusted identity.
% javakey c ali true
APPENDLXA. DMS INSTAUA TION GUIDE
c) Import Ali's certificate hto your identity database. Associate the certificate with the
identity "di" by using that nickname as the first argument to the javakey command.
% javakey -ic ali ali.xS09
d) Make sure your identity database is in the directory where the Plug-in expects it to be.
Your identity database should be in the User home directory that was displayed as
part of the output in the Java Console. If your identity database does not already
reside in this directory, copy it there.
e) Remove your local CLASSPATH.
t) Exit and restart your browser.
g) Run DMS as a trusted entity.
APPENDHB. USER S GUIDE
Appendix B
User's Guide
In this Appendix, we describe how the user cm access DMS services.
1) Public Services
These services are available for every DMS user.
1. Dowaload Assignment Outline
Select course, assignment and click on [Download: Assignment Outlines] in the
main menu. DMS will download assignment outlines as a text file and give it a name.
The name of the file is the course symbol followed by the assignment syrnbol. If the
assignment outline is not available, DMS will notie you.
2. Update Client's Views Information
Click on ptility: Update Ido.] in the main menu. DMS will update your views
to have the latest version of data fiom the server.
3. Change User Password
Click on [Utility: Change Password] in the main menu. DMS will open a small
diaiog asking you to enter the current password, new password, and connmi new
APPENDLXB. USER 5' GUlDE
password. Click on [Ok] when you finish entering data. DMS will change your password
to the new one.
4. Open DMS ZipRTnzip Editor
Click on ptility: Zip/UtlZip] in the main menu. This will open the DMSPp tool,
which is an extra utility that c m be used by users to zip and unzip files.
5. Open DMS File Viewer
Click on [Utitity: File Viewer] in the main menu. This will open the DMS file
editor. It can be used to view assignment outlines or marks after being downloaded.
6. Display Assignment Ou tlines On-line
Select course, assignment and click on [Display: Assignrnent Outlines] in the
main menu. Assignment outlines will be displayed in the detail box.
II) Student Services
These services are available for students only.
1. Download Marked Assignment
Select course, and click on [Dodoad: Marked Assignment] in the main menu.
DMS will download the marked assignment as a zip file and ask you to specify and open
the target directory to save the file in.
APPEN1)lXB. USER'S GUIDE
2. Download Assignments Marks
Select course, and click on [Download: Assignment Marks] in the main menu.
DMS will download the assignment marks as a text file that has the assignment symbols
and marks and ask you to speciQ and open the target directory where to Save the file.
3. Submit Assignment Solution
Select course, select assignment and click on [Submit: Assignment Solution] in
the main menu. DMS will ask you to open the assignment base directory. Then DMS will
implicitly unzip the assignment directory and its subdirectory into a zip file and send it to
the semer.
4. Display an Assignment Mark
Select course, assignment and click on [Display: Mark: Selected Assignment] in the
main menu. The selected assignment mark will be displayed on the detail box.
5. Display Al1 Assignments Marks
Select course, and click on pisplay: Mark: Assignment Marks] in the main menu.
Assignment marks will be displayed on the detail box.
III) Marker Services
These services are available for markers only.
1. Download Assignment Speciucation
Select course, assignment and click on [Download: Assignment Specification] in the
main menu. DMS will downioad assigament outhes as a text file and give it the name of
the course symbol followed by assignment symbol. This file will be used by the "DMS
Marking Tool", currently is not available, for marking the assignment.
2. Download Assignment Solutions
Click on [Download: Assignment Solutions] in the Download Window. DMS will
download the assignment solutions that have been submitted and have not been marked
and show them in the Download Window, which has two buttons ~ o w n l o a d Ail] and
[Download] .
Download Al1
Click on [Download All] in the Download Window. DMS will download al1
the Iisted solutions to the specified directory (see below).
Download
Select some solutions from the Download Window and click on [Download].
DMS will download the selected solutions to the specified directory (see below).
In either way, DMS will ask you to specify and open a base directory to Save the
assignment solutions in. Then DMS will create a directory in the base directory for each
assignment and Save the file there. For example, if you have three; students; studentl,
student2, student3 submitted three solutions for assignment #t from the course
APPENDLX B. USER'S GUlDE
COMP 1233. DMS will create a tree-Wre structure, download each assignment zip file,
and Save it in the assignment directory as shown below.
3. Upload and Send Marked Assignments
Select corne, select assignment and click on ppload: Assignment Solutions] in
the main menu. DMS will open a srnall dialog asking you to speciQ the base directory,
where the course base directory resides, to upload the solutions. Then DMS will open
another window (Upload Window) showing a list of the marked solutions; solutions will
be initially given zero marks. Marker cm update marks by using the Edit button. UpIoad
Window has two buttons [Send All] and [Send].
Click on [Send All] in the Upload Window. DMS will send al1 the listed
marked solutions to the server.
Send
APPENDIX B. USER'S GUWE
Select some marked solutions fkom the Upload Window and click on [Send].
DMS will send the selected rnarked solutions to the server.
IV) Instructor Services
These services are available for instnictoa only.
1. Assign Marker to Course
Select course and click on [Course: Assign Marker] in the main menu. - DMS will ask you to enter the marker ID that you want to assign to the course. Then
DMS will look up the marker ID in the database and assign it the selected course to be
one of its markers.
2. Drop Marker from Course
Select course and click on [Course: Drop Marker] in the main menu. DMS will
ask you to enter the marker ID that you want to remove fiom the course marker list. Then
DMS will look up the marker in the course marker list and remove it.
3. Add Assignment Account
Select course, and click on [Assignment: New] in the main menu. DMS will ask
you to enter the new assignment symbol that you want to add to the selected course.
DMS will look up the symbol to make sure it doesntt exist. Then DMS will open a new
window to enter the assignment data. Enter al1 the data and click on [OK]. DMS will
create a new assignment and Save it in the database.
4. Edit Assignment Account
Select course, assignment and click on [Assignment: Open] in the main menu.
DMS will ask you to enter the assignment symbol that you want to modify fiom the
selected course. DMS will look up the symbol to make sure it doesdt exist. Then DMS
will open a new window showing the assignment data. You may modi@ the assignment
data and click on [OK]. DMS will replace the new assignment data and Save it in the
database.
5. Delete Assignment Account
Select coune, assignment and click on [Assignment: Delete] in the main menu.
DMS will ask you to enter the assignment symbol that you want to remove fiom the
selected course. Then DMS will look up the symbol in the database and delete it.
6. Mow Assignment Re-downloading & Re-subrnitting
Select a course, assignment and click on [Assignment: Allow Re-download] in the
main menu. DMS will ask you to enter the assignment symbol that you want to allow
markers or students to be able to redownload its solutions one more time.
7. Edit Assignment Marks
Select course, assignment and click on warks: Edit] in the main menu.
DMS will open a new window showing the assignment solutions marks. You c m modify
marks by using the Edit button.
APPEmLXB. USER'S GUlDE
V) Administrator Services
These services are available for administrators only.
1, Create New User Account
Click on [Account: New] in the main menu. DMS will ask you to enter the new
user ID that you want to add to database. DMS will look up the user ID to make sure it
does not exist. Then DMS will open a new window to enter the user data. Enter al1 the
data, speci@ the user type (i.e. Student) and click on [OK]. DMS will create a new user
account and Save it in the database.
2. Edit User Account
Click on [Account: Open] in the main menu. DMS will ask you to enter the user
ID that you want to modi@ fiom the database. DMS will look up the ID to make sure it
does not exist. Then DMS will open a new window showing the user account data. You
may modify the user data and click on [OK]. DMS will replace the new user data and
Save it in the database.
3, Delete User Account
Click on [Account: Delete] in the main menu. DMS will ask you to enter the user
ID that you want to remove fiom the database. Then DMS will look up the symbol in the
database and delete it.
4. Add Course Account
Click on [Course: New] in the main menu. DMS will ask you to enter the new
course symbol that you want to add to database. DMS will look up the symbol to make
sure it does not exist. Then DMS will open a new window to enter the course data. Enter
al1 the data and click on [OK]. DMS will create a new course account a d Save it in the
database.
S. Edit Course Account
Click on [Corne: Open] in the main menu. DMS will ask you to enter the course
symbol that you want to modify fiom the database. DMS will look up symbol to make
sure it does not exist. Then DMS will open a new window showing the course account
data. You may modify the course data and click on [OK]. DMS will replace the new
course data and Save it in the database.
6. Delete Course Account
Click on [Course: Delete] in the main menu. DMS will ask you to enter the course
symbol that you want to remove fkom the database. Then DMS will look up the symbol
in the database and delete it.
7. RegistedDrop Courses to Users
Click on [Course: AddDrop] in the main menu. DMS will ask you to enter the
user ID that you want to registeddrop to/fiom a course. DMS will look up the user ID in
the database to make sure it exists. Then DMS will open a new window showing al1
courses that are already registered for the user. To add a course, click on [Add]. DMS
APPEIWLX B. USER S GU121)E
will ask for the course symbol. Then DMS will look it up and add it to the user course
list. To drop course that is already registered, select the course n o m the user course list
and click on [Drop]. DMS will remove the course fiom the user corne list.
8. Modify Server Timeout
Click on wl i ty : Configure: Server Timeout] in the main menu. DMS will ask
you to enter the timeout for the server to shuts down in minutes. This time will be active
the next time the server is launched.
9. Modify System Time Zone
Click on ptility: Configure: System Time Difference] in the main menu. DMS
will list the available tirne zones. Select your time zone system and click on [OK]. The
new time zone will not be active till the server shuts down and is reactivated.
