From Informatics

See: caBIG caGrid Wiki, Enterprise Architect, Dispatcher Implementation

This documents the architecture of the caGrid integration with geworkbench.

Overview

Server Side

The Dispatcher Implementation details how a server side service will be used to both invoke web-services and transform results to/from BISON data types.

The Dispatcher service will require a client stub to the service being invoked. This service must implement GridServiceClient. See dispatcher-accessible.

Client Side

Communication between the client (geworkbench, command line tool) and caGrid specific services will be done through the Dispatcher. With this separation we'll only need a DispatcherClient.jar, as opposed to jar files for each specific service.

On the first pass, communication will be client driven.

Geworkbench Client

Use Cases To Support - Exploration

Case A: Service Exploration With Services Available

1. The user points to the url of an Index Service and services with the name of the currently selected analytical services are returned.
2. The user selects one of the analytical services.
3. The user executes the service.

Case B: Service Exploration Without Services Available

1. The user points to the URL of an Index Service and services with no services returned.
2. The user cannot execute the service.

Use Cases To Support - Invocation

When an AbstractGridAnalysis is selected and invoked (ie. analyze is pressed), the bison datatypes should be sent to the DispatcherService for conversion into caGrid types. Currently, this conversion is being done on the client side but this will be pushed onto the DispatcherService. Similarly, caGrid service outputs will need to be converted into the corresponding BISON type. Again, this is currently being done on the client side but should be done at the level of the DispatcherService (so each client doesn't have to do the conversion). Since BISON types will be communicated between client and server, the client and server applications must use compatible versions. See CaGrid In Geworkench Implementation.

Case A: Basic Service Invocation

1. User discovers and selects service (as per the exploration details outlined above).
2. User invokes service.
3. User waits for results (by polling the service), and is notified of status.
4. The Project Panel shows a node as pending (ie. an hour glass).
5. When the results are available, they are obtained and the node in the Project Panel is marked as finished (ie. completed node).
6. The results are displayed in the visual area.

Case B: Service Invocation and Client Shutdown With Results Ready

1. User discovers and selects service (as per the exploration details outlined above).
2. User invokes service.
3. User waits for results (by polling the service), and is notified of status.
4. The Project Panel shows a node as pending (ie. hour glass).
5. User shuts down client.
6. User starts geworkbench at some later time.
7. Upon restarting of geworkbench, the server is polled to see if the results of any previously executing tasks are available.
8. When the results are available, they are obtained and the node in the Project Panel is marked as finished (ie. completed node).
9. The results are displayed in the view component.

Case C: Service Invocation and Client Shutdown With Results Not Ready

1. User discovers and selects service (as per the exploration details outlined above).
2. User invokes service.
3. User waits for results (by polling the service), and is notified of status.
4. The Project Panel shows a node as pending (ie. hour glass).
5. User shuts down client.
6. User starts geworkbench at some later time.
7. Upon restarting of geworkbench, the server is polled to see if the results of any previously executing tasks are available.
8. Results are not available, node in Project Panel remains as pending (ie. hour glass).

Case D: Save Workspace With Pending Nodes

1. User discovers and selects service (as per the exploration details outlined above).
2. User invokes service.
3. User waits for results (by polling the service), and is notified of status.
4. The Project Panel shows a node as pending (ie. hour glass).
5. User saves the workspace.
6. User starts geworkbench at some later time.
7. All currently executing grid threads are killed before new workspace is loaded. <-- TODO
8. Upon loading the workspace, the server is polled to see if the results of any previously executing tasks are available.
9. If results are not available, node in Project Panel remains as pending (ie. hour glass) else the results are returned and a completed node is displayed.

NOTE: User is blocked between the submission and return of the GridEndpointReferenceType.

Command Line Interface (CLI) Client

This is a work-in-progress as the CLI has not yet been used (Nov 19, 2007)

The exploration and invocation from the command line must be initiated by the user as two separate activities.

Use Cases To Support - Exploration

Case A: Service Exploration With Services Available

1. User invokes the "exploration" command line tool, passing in the appropriate IndexService URL and search term.
2. The list of services registered with this IndexService that fit the search term are returned, along with their URLs.

Case B: Service Exploration Without Services Available

1. User invokes the "exploration" command line tool, passing in the appropriate IndexService URL and search term.
2. No services returned.

Use Cases To Support - Invocation

Case A: Basic Service Invocation

1. User invokes the "invocation" command line tool, passing in the URL of the service to invoke. Parameters are also passed in. For example, if the input to the service contains microarray data, one parameter to the CLI would be a file with microarray data. These files would be transformed by the CLI into the appropriate BISON data types and packed into the GridInput object.
2. Status/progress (could be implemented by dots which is standard for CLI tools) are displayed on the screen.
3. <-- HOW TO HANDLE RESULTS (we could write the result to a file when/if appropriate)

Case B: Service Invocation and Client Shutdown With Results Ready

1. User invokes the "invocation" command line tool, passing in the URL of the service to invoke. Parameters are also passed in. For example, if the input to the service contains microarray data, one parameter to the CLI would be a file with microarray data. These files would be transformed by the CLI into the appropriate BISON data types and packed into the GridInput object.
2. Status/progress (could be implemented by dots which is standard for CLI tools) are displayed on the screen.
3. User shuts down command prompt.
4. User starts command prompt.
5. User invokes the "invocation" command line tool with the "getStatus" flag and the "jobId" flag (this will probably be a pointer to an EPR on disk).
6. Results are returned to the client.

Case C: Service Invocation and Client Shutdown Without Results Ready

1. User invokes the "invocation" command line tool, passing in the URL of the service to invoke. Parameters are also passed in. For example, if

the input to the service contains microarray data, one parameter to the CLI would be a file with microarray data. These files would be transformed by the CLI into the appropriate BISON data types and packed into the GridInput object.

1. Status/progress (could be implemented by dots which is standard for CLI tools) are displayed on the screen.
2. User shuts down command prompt.
3. User starts command prompt.
4. User invokes the "invocation" command line tool with the "getStatus" flag and the "jobId" flag (this will probably be a pointer to an EPR on disk).
5. Response is "Results not ready for job with Id xxx. Try again later." <-- CLI TOOL SO WE WILL NOT POLL. THIS MUST BE USER INITIATED.