On this page:
1 Implement an Interface
2 Design a remote protocol
6.0.0.1

Project 2: 9/8

This project is due on 9/8 at midnight.

Submission Directory: project02 in your pair’s GitHub repository. Failure to follow the submission instructions means your project will not be graded.

1 Implement an Interface

We have deposited a project02 folder in your directory with two sub-directories:

Each sub-directory corresponds to an implementation request:

Next week, we will integrate your server with the outsourced library and your graph library with someone else’s server and subject them to a number of tests.

The graph server has the task of reading XML elements from standard input, to interpret each command, and to print XML elements in response to some of the inputs. Each input element is a GraphDescription, defined as follows:

GraphDescription = <graph name=GraphName> EdgeDescription ... </graph>

                 | <join add=GraphName to=GraphName />

                 | <path graph=GraphName from=NodeName to=NodeName />

where the auxiliary notions are defined as follows:

EdgeDescription  = <edge from=NodeName to=NodeName cost=Cost />

GraphName :: String

NodeName  :: String

Cost      :: String, a positive real number in

                     school book decimal notation,

                     e.g., "+2.593", ".5", "0.00"

Each output is one of three possible XML elements: a PathDescription, an Error, or a False. Here are their definitions:

PathDescription  = <path cost=Cost> EdgeDescription ... </path>

Error            = <error msg=String />

False            = <false />

Note that neither the input nor the output is a complete XML document. The server sequentially interprets the inputs as follows:

If either of the two graph construction commands fails due to a violation of some library pre-condition, the server prints an Error response with some appropriate message and moves on to the next input element.

Naturally your server may not implement the library itself. It must rely on the library that the outsourcing produced. If your interface specification differs from the one that you received, you may not be able to link the two together. You can still test your server up to the "foreign" calls using a "stub" implementation for the server’s library.

2 Design a remote protocol

Your company has decided to turn the graph management library into a "service"; think "web service" but we will use "graph service" instead. Naturally, the production of this service is again left to the capable engineers you’ve outsourced to. As before, the service’s clients are going to be constructed in-house.

It is your task to describe with an interaction diagram how this graph service is to interact with its clients. All business is conducted over a TCP/IP connection on port 8080. The chosen data exchange language is XML. The graph service supports the exact same functionality that your graph library implements: a client can create a new graph, add edges, join two graphs, respond to query responses, etc. Naturally, if a service request fails to live up to its preconditions, your interface description must allow for the transmission of an error response.

Create a sub-folder called 2 within your project02 folder. Place two files into this sub-folder: (1) a scan of your hand-drawn interaction diagram and an ASCII file (.txt) that describes the format of the incoming and outgoing XML messages. If you have a high-quality phone camera, you are welcome to use it instead of a scanner. While UML interaction diagrams are not formal specifications, it is nevertheless important that the diagram specifies exactly which messages the service may receive, with which messages it may respond, and whether the messages must be ordered in any way.

While the graph service is intended to serve multiple clients in parallel, you do not need to worry about security issues in your protocol. All clients have the same trust status.