Suljettu

network application

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.

Taidot: Java, Javascript, JSP

Näytä lisää: find programming services, web programming developing java, web development skills list, web development positions, web development information security, web development scratch, web developing language, web design programming java, web design application form, web application system architecture, web application language, use proceeds example, use cases include extend, use case simple example, use case module, use case include example, use case include, use case extends example, use case extends, use case extend, select group, programming language second edition, test iteration, system level architecture, system architecture web application

About the Employer:
( 0 reviews ) lahore, Pakistan

Projektin tunnus: #10629