The DISCOVER interaction/collaboration server builds on a traditional web server and extends its functionality to handle real-time information, and to serve client requests and application connections. Extension is achieved using Java servlets (server side Java programs). Each server consists of a number of handler servlets running to provide different interaction and collaboration services. Clients connect to the server using standard HTTP communication using a series of HTTP GET and POST requests. At the other end, application-to-server communication is achieved either using standard distributed object protocols like CORBA and Java RMI, or a more optimized, custom protocol using TCP sockets. The core service handlers provided by each server include, the Master Handler, Collaboration Handler, Command Handler, Security/Authentication Handler and a Daemon Servlet that listens for application connections. In addition to these core handlers, there can be a number of handlers providing auxiliary services such as session archival, database handling, visualization, request redirection, and remote application proxy invocations (using CORBA). These services are optional and need not be provided by every server.
The different services are described in the following paragraphs:
A. Core Discover Services
1. Master Handler
The master (accepter/controller) handler servlet is the client's gateway to the server. It manages client service requests, such as authentication, session archival, request redirection, and view handling, and delegates them to the corresponding handler servlet. For each of these commands it invokes the corresponding handler, either on the local server or on a remote server, using CORBA, if the handler is not available locally. Within a local server, the master servlet relies on reflection to dynamically invoke handlers, thus providing an extensible set of services. The master servlet creates a session object for each connecting client and uses it to maintain information about client-server-application sessions. It provides each client with a unique client-id. The client-id along with an application-id (corresponding to the application to which the client is connected) is used to identify each session. Finally, the master is responsible for generating the dynamic HTML to present application information requested by the clients.
2. Security/Authentication Handler
Security, client authentication and application access control is managed by a dedicated security and authentication handler. The current implementation supports two-level client authentication at startup; the first level is to authorize access to the server and the second level to permit access to a particular application. On successful validation of the primary authorization, the user is shown a list of the applications for which s/he has access capabilities. A second level authentication is performed for the application s/he chooses. Once authenticated, the authentication handler servlet builds a customized interaction interface for the client to match his/her access capabilities. This ensures that a client can only access, interact with and steer an application in an authorized way. On the client side, digital certificates are used to validate the server identity before the client downloads views. A Secure Socket Layer provides encryption for all communication between the client and the server. To control access, all applications are required to be registered with the server and to provide list of users and their access privileges (e.g. read, modify). The application can also provide access privileges (typically read-only) to the "world". This information is used to create access control lists (ACL) for each user-application pair. Each interaction request is then validated against the ACL before it is processed.
3. Command Handler
The command handler manages all client view/command requests. On receiving these requests from the master handler, this handler looks up the appropriate application proxy, and redirects them to the proxy. Application responses are handled by the collaboration handler. All requests and responses are objects and take advantage of Java's capability of serializing objects.
4. Collaboration Handler
DISCOVER enables multiple clients to collaboratively interact with and steer applications. Clients can form or join (or leave) collaboration groups for each application. Once s/he is part of the collaboration group, the client can selectively broadcast application information to the group. Clients can also select the type of information it should receive. This allows clients to enable only those views that it can handle, e.g. a client with limited graphics capability may disable all graphical views. All clients connected to an application form a collaboration group by default. Global updates (e.g. current application time step) are automatically broadcast to this group. Session management and concurrency control is based on capabilities granted by the server. A simple locking mechanism is used to ensure that the application remains in a consistent state during collaborative interactions. This ensures that only one client "drives" (issues commands) the application at any time. When the driver issues a command, all clients in the group are informed. In addition to view/command collaboration, each application on the client portal is provided with chat and whiteboard tools to further assist collaboration.
5. Daemon servlet and Application Proxies
The Daemon Servlet forms the bridge between the server and the applications. This servlet opens 3 communication channels with every application that connects to it: (1) A MainChannel for application registration and regular updates. (2) A CommandChannel for redirecting commands sent by the Command Handler servlet and (3) A ResponseChannel for receiving application responses to client interaction requests. Each application is authenticated at the server using a pre-assigned unique identifier. The Daemon servlet creates a new Application Proxy object for each new application that connects and a handle to these application proxies is maintained in a list. It also assigns each application a unique session identifier. The Application Proxy object encapsulates the entire context for an application. It spawns two threads - one for the initial application registration and subsequent updates and a second one for receiving all responses to view/command queries by the clients. All updates and responses from the application are logged on a per-client as well as a per-session basis. This log is used to prevent multiple requests for the same information from being sent to the application.
B. DISCOVER Auxiliary Services
1. Session Archival Handler
The session archival handler maintains two types of logs. The first one logs all interactions between client(s) and an application. This log enables clients to replay their interactions with the server. It also enables latecomers to a collaboration group to get up to speed. The second log maintains all requests, responses, and status messages for each application. This log thus allows clients to have direct access the entire history of the application. Logging uses standard JDBC interfaces, and local and/or remote databases.
2. View Handlers (Plug-Ins)
Application information is presented to the client in the form of application Views. Typical views include text strings, plots, contours and iso-surfaces. Associated with each of these views is a view plug-in that can be downloaded from the server at runtime and is used to present the requested view to the user. The server supports an extendible plug-in repository and allows users to extend, customize or create new views by registering custom mime types and the associated plug-ins. For example, in the current implementation plotting views are based on the Ptolemy software package. These plots are of two kinds: iterative or one time. The former shows the incremental change in the parameter with successive iterations whereas the latter is a response to a user request to show a log of the parameter history from startup or checkpoint.