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.
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.
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; |
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.
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; |
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
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 |