Part IV -- Two Clients, One Server

Michael Chen
August 23, 1996
Rewritten: H. Hildreth, 9-20-96
Revised: H. Hildreth, 9-30-96

PART IV: TWO CLIENTS, ONE SERVER

The AdvLearn product enables multiple users to collaborate on a single project (discussion). Multiple users correspond to multiple clients at the AIL level. A single "server" (i.e., http server, session server, coach, database, and connection manager) controls the collaboration (e.g., maintains data integrity).

Objective: Using parameters.rpd from Part 3 as the baseline, increase the number of clients (users) from one to two. Later examples will enable multiple (i.e., > 2) clients.

Rapide concepts introduced: multiple instances (components) of a single interface type.

Notes:
(1) Based on a better understanding of the example domain, many minor changes were made to parameters.rpd from Part 3. These changes involve mostly action name changes and other minor changes (e.g., changing a string to an integer). The file name-changes.diff shows differences between parameters.rpd and oneclient.rpd.
(2) The file one-to-two.diff shows changes made strictly to satisfy the above objective; i.e., adding a second client to create the new file twoclient.rpd.

Procedure: Two clients, C1 and C2 were declared in the main, ail, architecture as follows:

   architecture ail() is
      C1, C2 : Client is ClientArch();

To handle two clients, a parameter of client identification needed to be attached to requests to enable the correct routing of server responses. In connections from a client to the server, the client's identification is lifted from the client-side event and passed as a parameter in the server-side event, like so:

(?C in Client) ?C.RequestHelp ||> S.RequestHelp(?C);

Within the server architecture, the client's identification is carried throughout the transaction.

(?C in Client) HTTP.HelpRequestToCoach(?C) ||> COACH.HelpRequestToCoach(?C)

"Return" connections utilize the client ID parameter to route the server's response to the correct client.

(?I in IPAddress, ?G in GraphAnnotation, ?C in Client)
   S.SendInfoToJava(?I, ?G, ?C) ||> ?C.SendInfoToJava(?I, ?G);

The connection manager represents somewhat of a special case in that it must notify clients other than the initiating client of the transaction. For now this is hard-coded; i.e., C1 is notified of C2's activities and vice versa.


   (?G in GraphAnnotation) S.UpdateToOtherClient(?G, C1) ||> 
	C2.GraphUpdate(?G);

Client arrays and more generic rules (connections and behaviors) are introduced in Part 9.

The ail.arch file had to be modified to include a second client. Modules within the second client (ClientArch:2) are identified as WebBrowser:2, JavaTools:2, etc. The changes between oneclient.arch and twoclient.arch are shown in arch.diff.

To view the use of the Client ID parameter for message routing, run raptor.


raptor -a twoclient.arch -p twoclient.log

For contrast, .log and .arch files are also provided for the revised one client example. To view the animation of the updated one-client example,


raptor -a oneclient.arch -p oneclient.log

The poset viewing tool, pov, can also be used to see differences between the one- and two-client posets.


pov oneclient.log


pov twoclient.log

[ Back to the Index | Next | Prev]