The OSC SciPortal
A WebFlow - Problem Solving Environment

Overview

The OSC SciPortal, is a WebFlow (WF) Problem Solving Environment (PSE) which provides, to the user, transparent access to distributed back end resources, remote file services, archiving and journaling. One goal of the OSC SciPortal is to generate computational resource requests from user developed problem descriptions. The PSE is the interface in which problems to be solved are stated, translated into requests for computational resources (such as software, hardware, information resources and other types of resources), and an analysis of the results can be performed. This multi-step view of doing science is encompassed in the different parts (toolkits) of OSC SciPortal.

The OSC SciPortal is a combination of a knowledge base of computational methods and codes combined with interaction from a user. Access to archives of user results is provided via a set of OSC SciPortal navigation bars and links.

The different steps in transforming the problem are encapsulated as toolkits, and the SciPortal interface with the WebFlow system handles the computational requests by passing the requests to the middle tier (WebFlow), via http or https by the browser. Specifically, the communication between the PSE and the middle tier object manager WebFlow occurs via a set of objects defined as part of the logical flow of the PSE.

The OSC SciPortal model starts with defining a problem (the science), then the system determines what can solve the science problem and generates a WebFlow session context and WebFlow application context to request for resources to solve the problem. The SciPortal provides navigation to access all the SciPortal actions:

The OSC SciPortal information services consists of various types of information, stored as sets of XML files:

SciPortal modules provide mechanisms to maintain and update this information.

Implementation of the underlying portal is a distributed model consisting of a set of hierarchical components which have a well defined behavior accessible via a specific interface. The hierarchy (called contexts) are accessed via the Context Manager. The Context Manager provides access to low level activities such as file access, submitting jobs, etc.

The OSC SciPortal utilizes the hierarchical contexts, which are accessed via a set navigator bars, to manage the different toolkits.

Security Model. Portals can provide secure protected access to a site. The OSC SciPortal uses the SSL browser mechanism plus passwords to secure access to the portal.

The WebFlow Problem Solving Environment (PSE) supports various of scientific disciplines. The PSE arranges the user activities into a set of toolbox kits. The PSE) provides a framework to construct the discipline specific toolboxes. This framework provides general capabilities such as file services, user authentication and a mechanism (API) to incorporate discipline specific tools.

The PSE toolkits. All toolkits (except the entry) support both the Advanced and User tracks.

PSE Toolkits

The WebFlow portal is arranged as a hierarchy of contexts, which are containers to hold information about users activities. This WebFlow PSE uses these contexts to implement the various toolkits as depicted in the following diagram:

The PSE toolkits. All toolkits (except the entry) support both the Advanced and User tracks.

PSE/WebFlow Contexts

WebFlow is a distributed system but the information about available applications needs to be accessible to the PSE. Thus, a Code Information server will provide information concerning all registered sites.

The Code Information Server will be a standard web server, such as Apache, and will provide different ports for various application areas to organize codes by discipline. Each site will register is AAD to a particular port on the server. To help consistency

Code Information Server

Toolkit API

Each toolkit:

The discipline specific information is separated from the toolkit information as shown below:

SciPortal Directories

The SciPortal layout to have classes for the portal and protected data and so on.

Section: Entry Toolkit

  • INPUT

    Access is from a login to the WebFlow system and selecting the appropriate science area (such as CCM, which is currently the default).

  • OUTPUT

    This toolkit generates the Welcome Page, the navigation bar providing access to the different toolkits, authentication for the PSE and a connection to a User Context. The User Context may contain data from previous activities.

Entry Toolkit Module

The Entry to the discipline specific set of toolkits is done using JSP (Java Server Page) to handle the login user ID and to dynamically generate the Welcome page and the toolkit navigation. The user ID provided at login to the WebFlow server allows WebFlow to create or attach to a User Context and the PSE to read the registeredUser XML file. This file provides additional authentication for the discipline specific activities.

The entry process can be described as follow:

SciPortal Entry Diagram

The user enters a URL and the server requests a login (user ID and password). The server then calls the Portal servlet which presents to the user the WebFlow login to begin a WebFlow session (Start Session button). This starts the access to a User Context and starts the WebFlow user server (slave server). Once the User WebFlow Server is running, the GatewayPortal servlet generates the CTA frameset.

In the CORBA client gw.java, cases 0 and 101 refer to the PDT, case 102 refers to the CT and the case 103 refers to the AT.

Section: Problem Description Toolkit (PDT)

  • INPUT

    This toolkit needs only the user information which can contain authorization information for applications and back end resources. The PSE can at this toolkit restore a previous Problem Description from either the current user context or the archive. Access to the previous problem descriptions for the current user context is done via a set of radio buttons.

    The current limitation for the SciPortal is that the PDT solves the science problem using a single application code, single input with multiple output files.

    The Problem Description context will also be the repository of the XML file, named after the Problem Description title which will contain information form the Code Toolkit and the Analysis Toolkit as well as the Problem Description Toolkit.

  • OUTPUT

    A list of codes and associated Application Descriptors (AD) which appear in the navigator of the CT. This toolkit will query the Code Information Server for information on the availability of codes from the AAD.

    The output will contain a code recommendation (or codes) plus some description to enable the CT to select a template input file.

Problem Description Toolkit Module

Either of the toolkit tracks (Advanced or User) generates an XML file which contains the Problem Description. The PDT also updates the problem context data by adding a pointer to the Problem Description XML file.

The Problem Description XML file contains:

  1. Title
  2. Problem information - such as properties, type of system, etc.

The User track assists the user with a decision process (which the user sees as a set of interactive forms) to select a set of codes (or only one code) to solve the specified problem. The decision process is discipline specific but the templates for the forms and the decision tree have been constructed for CCM.

The Advanced track provides a single form for the user to specify the problem to solve. This advanced problem description relies on the expertise of the user. The advanced problem description is used primarily for archiving such that the PSE can recover past activities.

The PDT can determine which code can handle the problem described via the User track. The advanced track user will select a code directly. The code selection process also requires information concerning the availability of the code. This information is supplied by the AAD. One way to view this process is to consider that the code selection is done based on WHAT the code can do and that the availability of the code answers the question about HOW the code is used.

The entry process can be described as follow:

Problem Description Entry Diagram

Selecting the Problem Description Toolkit button from the main navigator. This invokes the probDescPage servlet which will list the existing Problem Descriptions, if there are any. This is accomplished using the Context Manager.

Section: Code Toolkit (CT)

  • INPUT

    A list of codes which appear in the CT navigator. This list is constructed from a discipline specific analysis to determine the code can solve the problem and are available to the user.

    In general the input is a file at some location of one of three types:

    1. Template (selected with help from the PDT.
    2. A file uploaded from the client.
    3. An input file generated from an input form.
  • OUTPUT

    This toolkit will generate an ATD to allow WebFlow to request back end resources. The ATD contains information about the input file(s) (this is application specific) and requested resource (machine).

Code Toolkit Module

This toolkit is dependent on several components.

The advanced track will provide the user with the necessary options for running a code. Information about the switches is in the AAD. A tool to enter AAD information is forthcoming.

Section: Analysis Toolkit (AT)

Upon entry to the AT a list of problems, which is accessed via the Context manager. The user selects a problem and the list of sessions associated with the problem appears and after a session is selected, the application context data is displayed. This is the most general case, doing an analysis after the applications have been run. Links from a session and/or an application can be set up.

The AT needs to determine what analysis tools and data filters are available for each application. This may be done in the AAD or in the Code Descriptor (CD)

Analysis Toolkit Module

Developers Update

The SciPortal directory structure provides a flexible structure for developers. See the outline here.

Closing Thoughts

The PSE provides three important services:

  1. Archival of problem descriptions
  2. Assistance in selecting methods of solution
  3. Composing methods of solution