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.
We have deposited a project02 folder in your directory with two sub-directories:
server, which contains your interface specification from project 1 and
client, which contains someone else’s interface specification.
Each sub-directory corresponds to an implementation request:
server: Assume that the capable engineers you’ve outsourced to will deliver a library that implements your interface specification. Your task is to design and implement a server that makes use of the library. The server is specified below.
client: Imagine yourself as one of the engineers that your company is outsourcing to. You have just received this interface specification with the request to implement a corresponding library over the next shift. By the end of the shift you will deliver the library to your chief engineer in Houston, Texas, who will integrate it and its interface into a large system.
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:
when it encounters a graph description, it requests the construction of a graph from the specified edges;
when it encounters a join description, it asks for the incorporation of one graph into another, as indicated by the attribute names; and
when it encounters a path query calls for an inspection of the named graph. If the requested path exists, the server prints a PathDescription, which includes a series of EdgeDescriptions. A path is more than a sequence of NodeNames because two nodes may be connected by distinct edges with possibly distinct costs. If the requested path does not exist, the server prints False.
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.
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.