Page History

...

The central management piece for each SAGE application is BardFrame. BardFrame provides an interface for working with the Tupelo semantic content repository and is responsible for managing contexts, bean sessions, data, etc. The use of beans will be a core concept for persisting information in the SAGE framework so all beans will need to descend from CETBean. Because every application will have its own bean requirements, each SAGE application should have its own instance of BardFrame to handle this. All application bean types should register with BardFrame and the BardServiceRegistry should provide the correct instance of BardFrame at runtime.

Scenarios View

Displays The first main view provided by SAGE will be the ScenariosView. This view displays user scenario(s) and all sub-parts displayed in a Tree view. A scenario is similar to the concept of a project where it contains a collection of parts (and is simply a way of organizing things that belong together. The scenario is responsible for managing all of the pieces that it contains including input datasets, output datasets , etc) that are part of the scenarioand workflows. A scenario may also contain the RMI Service that the workflows will use to launch their jobs, but this could end up being an application wide object or part of a Scenario Manager since users will most likely use the same launch point to execute jobs regardless of which scenario the workflow belongs to. Users will launch jobs on the HPC machines that run workflows using use the inputs in their scenario and when a project completes, the outputs should be added back to the users that scenario. A user might can 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 applicationIt is anticipated that new applications might extend this view to organize their view differently for their specific domain.

Scenario

A scenario will contain bean will be used to organize things such as user data , and workflows , etc specific to a scenario (or project). This will include datasets (input and output), workflows, and an possibly the RMI service for launching jobs. As previously mentioned, this might end up an application wide object that is viewable from the scenario view, but not specific to any one scenario. A snippet of what the scenario bean might look like is below:

private String title;  // scenario title
private String description;  // scenario description
private Set<DatasetBean> dataSets;  // datasets associated with scenario
private RMIServiceBean serviceBean;  // rmi service used to launch workflows
private List<WorkflowBean> workflows;  // workflows associated with this scenario
private boolean open;  // is the scenario opened or closed?
private PersonBean creator;  // scenario creator
private Date date;  // date scenario created

This code will evolve as the application framework is built and more final documentation will be put here as the design matures. DatasetBean's will be used to manage all of the input/output datasets, the RMIServiceBean (described later) will contain the service information and the WorkflowBean will contain the workflows associated with this scenario. A user might extend the ScenarioBean if their application has other things that logically belong to their scenarios.

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.

...