network application
$100-500 USD
Pagado a la entrega
Programming Network Applications in Java: Module Coursework
Group Location Service
Aims:
· To practice and extend your Java programming skills.
· To develop a network application using the sockets API (Application
Programming Interface) and the JSP (Java Server Page) framework.
· To define, test and document a simple application level network protocol for a
client server architecture.
The Task
To design and implement a Simple Group Location Service (SGLS). This will allow
mobile/wireless use agents to report their geographical positions to a central
server and to request services about the position of other individuals, groups
and places.
The first stage of the work, which forms the scope of this coursework, is to
develop a server and a protocol to implement the group location service. In
addition a command line based client is also required to test the service.
You can imagine a second stage (that falls outside the scope of the coursework)
would be to port the client side code to a suitable mobile/wireless PDA platform
and to integrate an automated means of determining the device position (e.g.
GPS)
Development will be done using the standard edition JDK on desktop machines.
An iterative approach to development is to be adopted. The developing the system
is scheduled over 4 iterations. Each iteration extends the functionality of the
implementation. At the end of each iteration the design and code will be frozen
and documented.
Use cases for the initial iterations are described in detail but latter on just
the protocol or functionality is outlined and you have the scope to design the
interaction between the server and client as you see fit.
Summary of the Deliverables
There are 3 main deliverables.
No. Coursework Component Limts Assessment Criteria Marks
1 Code + Discussion of 1 aspect of the design per iterationIteration 1:
Locating Individuals Iteration 2 : GroupsIteration 3 : Places & Relative
positionsIteration 4 : Persistence and JSP status page For each iteration you
should show:- · A screen dump of how a transaction proceeds for each use case
you implement (or a print of the web page for the 4th JSP iteration).· Full java
source code is required for each iteration.· Select and discuss one key aspects
of the design that you tackled during that [url removed, login to view]: at the end of
each iteration you should freeze the code for the client and server respectively
and submit it separately as iterations 1, 2, 3 & 4. Do not continuously refine
the code and submit only the final version. consistent lay out, well commented,
simple, appropriate use of java language features and Java class libraries. 65%
2 Summary of the SGLS protocol in the style of an IETF [url removed, login to view] should write a
brief document in the style of an IETF RFC to describe the "Simple GLS" protocol
you have developed. Include any additional functionality you feel the protocol
needs to be complete (but do not extend it beyond the scope described here -
keep it 'simple') 2000 word max concise, clear, complete 25%
3 Finally comment on what additions or changes you would suggest the server &
protocol needs to be viable. for example timestamps, altitudes, security? 500
words max Relevant and innovative 10%
Appendix A
Iteration 1 - Locating Individuals
In the first short iteration you are to create a primitive service to support
individual users. The client issues commands and the server responds.
1-1 Use case: User Reports Location
1. A command line client opens a socket to a server.
2. The server responds by sending a message of the form:
Welcome to SGLS
3. The client sends a message of the form:
USER #USERID REPORT
Where #USERID is an integer and their position is two specified by two
integers x & y.
4. The server records the position internally and responds ok.
5. The client closes the connection.
1-2 Use case: Locate a user
1. The client connects to the server
2. The server responds with the welcome message
3. The client sends
USER #USERID WHEREIS
4. The server looks up the last known position of #USERID responds
USER #ID is at absolute position
Where x,y is the last know location of the user specified by integer #USERID
5. The connection is closed
In this first iteration:
· The server needs only hold the last reported position of an individual
· No error checking or reporting is required
· All requests relating to individuals begin 'USER'
· The GLS version reported for iteration 1 will be of the form [url removed, login to view]
· The interpretation of the position is not important at this phase of the
design so you may adopt an arbitrary scale (i.e. not official grid references or
GPS readings).
Iteration 2 - Groups
In this iteration we add functionality to deal with groups and some error
conditions.
2-1 Use Case - Create a Group
1. The client connects to the SGLS server.
2. The client receives the welcome message and it checks the version is [url removed, login to view] if
not it closes the connection, reports and error and stops.
3. The client sends the message
GROUP #GROUPID CREATE
Where #GROUPID is an integer.
4. The server creates an empty group identified by #GROUPID and responds ok or
with an error code if it was unable to create the group (e.g. it already exists
or has no space or is an invalid #GROUPID).
5. The connection is closed.
2-1 Use case - User joins a group
1. The client connects to the server and checks the version number of the
welcome message.
2. The client sends a message
USER #USERID JOIN GROUP #GROUPID
3. The server records that #USERID is a member of #GROUPID and responds ok or
with an error code if it was unable to add the user (e.g. unknown group, unknown
user).
4. The connection is closed.
2-2 Use case - Locate Group
1. The client connects to the server and checks the version number of the
welcome message.
2. The client sends a message
GROUP #GROUPID LOCATE ABSOLUTE USERS
3. The server responds with a list of the group members in the form
USER #USERID is at absolute position x,y
USER #USERID is at absolute position x,y
.
Where x,y is the location of the user specified by integer #USERID
4. At the end of the list the server prints a blank
a. If the group is empty the server responds 'EMPTY'
5. The connection is closed
Optionally for completeness you can add use cases for:
2-3 Use case - User leave a group
Checks as in 'join' use case above but with message
USER #USERID LEAVE GROUP #GROUPID
2-4 Use case - delete a group
Checks as in 'join' use case above but with the message
GROUP #GROUPID DELETE
2-5 Use case - delete a suer
Checks as in 'join' use case above but with the message
USER #USERID DELETE
In this second iteration:
· The GLS version reported for iteration 2 will be of the form [url removed, login to view]
· There is no permission scheme restricting who can form, join or delete groups.
· All requests relating to Groups begin 'GROUP'
· All transaction are non-persistent. A connection is established a single
transaction occurs and the connection is closed
Iteration3 - Places and relative positions
In this iteration we add the concept of places (landmarks) & relative positions.
3-1 Use Case - Client reports a place
1. The client connects to the SGLS server.
2. The client receives the welcome message and it checks the version is [url removed, login to view] if
not it closes the connection, reports and error, and stops.
3. The client sends a message of the form:
PLACE "title: description" REPORT
4. The server records the position of 'title' and responds ok
5. The connection is closed
3-2 Use Case - Find the absolute location of a place
1. Client connects and checks the SGLS version
2. The client sends a message of the form
PLACE WHEREIS
3. The server looks up the location and responds with
is at absolute position x,y
or an error message if the title is not recognised.
4. The connection is closed
3-3 Use Case - Find relative location of a place
1. Client connects and checks SGLS server version
2. The client sends a message of the form
PLACE WHEREIS RELATIVE TO USER #USERID
3. The server responds with
is at relative to #USERID
4. Where you calculate the distance and bearing using Pythagoras and simple
trigonometry (we assume the earth is flat for a small region) with respect to
the user.
5. The connection is closed
3-4 Use case - Locate Group Centre
1. Client connects and checks version of the SGLS server
2. The client sends a message of the form
GROUP #GROUPID WHEREIS CENTER
3. The server responds with a list of the group members in the form
GROUP #GROUPID CENTER is at absolute position
Where x,y is the location of centroid (centre of gravity) of the group
a. If the group is empty the server responds 'EMPTY'
4. The connections is closed
Optionally you can add use cases for:
3-5 Use case - Find group spread
Client sends
GROUP #GROUPID SPREAD
Server responds with a list of the users
USER #USERID is from group centre
In this 3rd iteration
· The GLS version reported for iteration 3 will be of the form [url removed, login to view]
· You can preload the server with some know landmarks either from a file or
statically.
Iteration 4 - Persistence and JSP status page
In the 4th and final iteration we add the idea of persistence and develop a
simple web interface to view the overall status of the GLS server.
Use Case - User snapshots the system status
1. The client connects to the SGLS server.
2. The client receives the welcome message and checks the version is [url removed, login to view] if not
it close the connection and stops.
3. The client sends a message of the form
SYSTEM snapshot
4. The server writes the current user, group and place information it holds to 3
separate files and responds 'done'
The user can then access a web page that is created on the fly using JSP to
access and layout the current snapshot of the GLS system.
4-1 Use Case - View users
A web page is build on the fly to show the users know to the system when the
most recent snapshot was taken.
4-2 Use Case - View groups
A web page is build on the fly to show the groups know to the system when the
most recent snapshot was taken and there membership
4-3 Use Case - View Places
A web page is build on the fly to show the places know to the system when the
most recent snapshot was taken
In this 4th iteration
· The GLS version reported for iteration 4 will be of the form [url removed, login to view]
· Although this is obviously meant to be a follow on from the initial 3
iterations. You may construct the files from scratch to show the JSP
functionality if your implementation of the first 3 iterations is incomplete.
Nº del proyecto: #10629
