6515 S '13
Acquire, Revised
Acquire Plan
Project 1
Project 2
Project 3
Project 4
Project 5
Project 6
Project 7
Project 8
Project 9
Project 10
Project 11
Project 12

Project 2

Due date: 1/21, 23:59

Objective 1: to implement a server and a client module for the interface from project 1

Objective 2: to specify a remote server-client interface via an interaction diagram

Task 1: We have deposited a project2 folder in your directory with two sub-directories:

  1. server, which contains your interface specification from project 1 and
  2. client, which contains someone else's interface specification.
Each sub-directory corresponds to an implementation request:
  1. server: Assume that the capable engineers of Bulramistan 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.
  2. client: Imagine yourself in Bulramistan. 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: an 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:
  1. when it encounters a graph description, it requests the construction of a graph from the specified edges;
  2. when it encounters a join description, it asks for the incorporation of one graph into another, as indicated by the attribute names; and
  3. 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 produced in Bulramistan. 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.

Task 2: 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 in Bulramistan. 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/IPA 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 project2 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. The lab in WV H has a scanner. If you have a high-quality phone camera, you are welcome to use it instead. While I do consider UML interaction diagrams a "doodle" language, 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.

last updated on Wed Apr 10 20:51:12 EDT 2013generated with Racket