SAGE Documentation

Application Management

The BardFrame is a general application piece for managing contexts, bean sessions, data, etc and will need to be extended for each specific use case if the use case requires an entirely new application (e.g. e-AIRS and e-Spine have different use cases and might require two separate BardFrame's). All application bean types should register with BardFrame and the BardServiceRegistry should provide the right instance of BardFrame. Alternatively, BardFrame could be made to allow applications to register their bean types.

Scenarios View

Displays user scenario(s). A scenario is similar to the concept of a project where it contains a collection of parts (input datasets, output datasets, etc) that are part of the scenario. Users will launch jobs on the HPC machines that run workflows using the inputs in their scenario and when a project completes, the outputs should be added to the users scenario. A user might have multiple scenarios open at once, close scenarios, or even delete scenarios from their scenario view (deleted from the view, but still in the repository) so we'll need to manage which scenarios are in a session and what is their current state (open/closed). For example, I might have scenario A, B and C stored in a local repository, but only A and B are loaded into my application.

Scenario

A scenario will contain user data specific to a scenario (or project). This will include datasets and a define service for launching HPC jobs. or

private String title;
private String description;
private Set<DatasetBean> dataSets;
private RMIServiceBean serviceBean;

RMI Service Registry

The service registry contains all machine defined as available to the user for installing the PTPFlow plugins required to run HPC jobs and return status information to the client.

RMIService Info

The information about each service installation will be stored in an RMIServiceBean.

// Service Info
private String name;
private String platform;
private String deployUsingURI;  // e.g. file:/
private String launchUsingURI;
private String installLocation;  // e.g. /home/user_home/ptpflow
private String rmiContactURI;
private int rmiPortLowerBound;
private int rmiPortUpperBound;
private int gridftpPortLowerBound;
private int gridftpPortUpperBound;
private Date installedDate;
private boolean running;

Repository View

Rather than a single repository view, this might actually be multiple views that are configured to show a particular type of data using a content provider that gets the data type from the tupelo contexts it knows about. For example, we might have something like "Data Repository View" that shows all datasets (e.g. input/output datasets) and a way to manipulate them (e.g. add tags, annotations, etc), "Scenario Repository View" that shows all defined scenarios, "Service Repository View" that shows defined RMI service endpoints for launching jobs, etc. This seems like too much disparate information to display in a single view.
A repository is anything that is used for storing data, scenarios, and beans that describe things.

Functional Requirements

1. Import datasets that will be used as input to HPC workflows such as Mesh files, input files (e.g. mach number, poisson ratio, etc)
2. Store output datasets
3. Store scenarios
4. Store defined RMI services
5. Store known-hosts
6. Other functionality?

Known Host View

This view lists information about the HPC hosts such as environment settings, user information for the host (username, user home, etc), host operating system, node properties, etc.

private String osName;  // host os name
private String osVersion; // host os version
private String architecture; // host architecture
private String id; // host id
private Set<PropertyBean> envProperties;  // environment properties on host
private Set<NodeBean> hpcNodes;  // properties of each node