Get documents about "02222Distributed Systems Lab3The CheapFlight System
Document Sample
02222: Distributed Systems
Lab3: The CheapFlight System
Robin Sharp
February 2008
The aim of this lab is to give you some practice in the use of RMI as the technology
for implementing a small system which is to offer its users a service for finding the price
of the cheapest available plane ticket between two cities.
This exercise assumes that you have already carried out Lab2 (RMI Tutorial), which
introduces you to the RMI technology and how to set up clients and servers using RMI.
1 System description
The system is a so-called 3-tier system, whose architecture is shown in Figure 1. The
system processes user requests as follows: The user at a UI on the client (Client) passes
the client a request specifying two cities. The client then requests the main application
server (AS ) for the minimum price of a ticket for flying between these two cities. The
application server acts as a client for the data servers (D1, D2,. . . , Dk ), each of which can
respond with at most one price for the required flight. The application server finds the
lowest price given by any of the data servers, and returns this to the client, where it is
displayed to the user.
User D1
D2
Client AS
D3
.
.
Dk
Figure 1: Architecture of the CheapFlight system
1
1 SYSTEM DESCRIPTION 2
t D1
lef
User
1]
SAPA ht[ left D2
rig ht[2]
rig
right left right[3]
Client AS left
rig D3
ht[
k] .
.
lef .
t
Dk
Figure 2: CSP processes and channels in the CheapFlight system
def
Client = (C[1] T imer) \ {up}
def
C[n : N0 ] = (SAP A?(a, b : tok) → CT [n, a, b])
CT [n : N0 , a, b : tok]
def
= (right!(n, a, b) → (up!set → (right?(i : N0 , price : Z) →
(if (i = n)
then up!reset → SAP A!(a, b, price) → C[succ(n)]
else CT [n, a, b])
[]up?t : {timeout} → CT [n, a, b]) ) )
def
AS = (S[0] T imer) \ {up}
def
S[n : N0 ] = (left?(i : N0 , x, y : tok) → j∈ss right[j]!(i, x, y) → up!set → SC[i, ∅, ss, ∞])
SC[n : N0 , rs, ss : N0 -set, minp : Z]
def
= (right[j ∈ ss]?(i : N0 , p : Z) → if i = n
then if (rs ∪ {j}) = ss
then up!reset → lef t!(i, min(p, minp)) → S[succ(n)]
else SC[n, rs ∪ {j}, ss, min(p, minp)]
else SC[n, rs, ss, minp]
[]up?t : {timeout} → left!(i, minp) → S[succ(n)])
def
T imer = (up?s : {set} → (up?r : {reset} → T imer
[]up!timeout → T imer) )
def
D[j : {1..k}] = (left[j]?(i : N0 , from, to : tok) → left[j]!(i, cost(from, to)) → D[j])
Figure 3: CSP specification of the CheapFlight system
2 IMPLEMENTATION 3
The architecture of the system in terms of a set of communicating CSP processes is
shown in Figure 2 on the preceding page, in which the channels connecting the processes
have been indicated.
The behaviour of the client, the application server and the k data server processes
can then be described in terms of the CSP specification given in Figure 3. Note that the
application server collects up replies until either all data servers have replied or its internal
timer times out; this latter possibility is intended to cover the case where one or more of
the data servers fails. The function cost(a, b) in process D[j] is assumed to evaluate the
price of a trip from a to b, according to the information stored in data server D[j]; if no
information is stored about the trip, cost(a, b) returns the value ∞ (“infinity”). The set
ss = {1..k} is the set of indices of the data servers. The rest of the notation is described
in detail in Appendix A of PPD.
2 Implementation
You are required to implement the CheapFlight system using RMI as the implementation
technology. The application server (process AS ) is to act as server to the client (process
Client), but as a client to the data servers (processes D1,D2,. . . ,Dk ). In order to use RMI,
you need to define the interfaces which the servers offer to their respective clients, and to
produce implementations of these interfaces for use in the relevant servers. Think carefully
about the timeout functions in the CSP specification: Do you need them? How can they
be introduced in RMI? Could you replace them in the RMI implementation by exception
handlers of some sort?
In a real implementation of such a system, each of the data servers would in all proba-
bility have a database for storing the pricing data. For the sake of simplicity, you should
replace the database by a suitable data structure (for example a Vector), each of whose
elements contains three values: a string giving the 3-letter code for the airport from which
the journey starts (for example CPH for Copenhagen, LHR for London Heathrow, DUB
for Dublin, CDG for Paris Charles de Gaulle etc.), a string giving the code for the desti-
nation airport, and an integer giving the price for the journey. Note that you will need to
instantiate several data servers, preferably on different physical computers. Obviously it
is more interesting if the data servers contain different prices for given journeys!
Note that if you start several RMI servers (for example data servers) on the same
machine, then you will need to ensure that they are registered in the RMI registry under
different names. Furthermore, if you want to start an RMI registry on a machine on which
one or more other users already have registries running, you will need to make sure that
your registry listens on a port whose number is different from the numbers used by any
of the others. For details of how to specify ths port number, and for other general advice
about RMI, consult the Sun Java RMI Tutorial or the FAQ for RMI:
http://java.sun.com/j2se/1.5.0/docs/guide/rmi/
http://java.sun.com/j2se/1.5.0/docs/guide/rmi/faq.html
3 REPORT REQUIREMENTS 4
3 Report requirements
This lab is a mandatory part of the course, which means that you have to hand in a small
report which will be evaluated and count towards your final grade. You are expected to
work in groups of not more than 2 participants. Your report should document your solution
to the problem and explain briefly how you have chosen to implement and test the various
parts, using RMI as the implementation technology. The report should be limited to a
maximum of 5 pages, excluding the source code.
When writing your report for this task and the following mandatory tasks, it is impor-
tant that you explain how you have implemented features of the specification in terms of
facilities of the implementation technology in use (here RMI). For example, how you have
dealt with timeouts, how you have implemented multiple databases, how you have handled
the exchange of data between the Application Server and multiple data servers and so on.
In different technologies, there will often be different ways of dealing with these questions,
so it is important that you shed light on the decisions which you have made.
Remember two important rules about mandatory reports at DTU:
1. It must be possible to evaluate each individual’s contribution. This means that if
you are working in a group of 2, then you must indicate which of you was responsible
for the individual parts of the report.
2. You are welcome to seek information in the printed literature and via the Internet.
However, if you include in your report any material which you have not written
yourselves, then this material must be clearly marked, and a reference to its source
must be given.
The report should be handed in to one of the “postboxes” marked 02222 in the West
entrance to Building 322 not later than 16:00 on Thursday 13 March.
