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. |
![]() |
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. |
![]() |
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 |
![]() |
Each toolkit:
Provides a description of the information generated at each toolkit. The description is an XML file constructed from the the XML specification for each toolkit. The API core is an XML parser and tool to read/update and display the information.
Generates an update to the context data to provide a link to each toolkits information. This is accomplished via the WebFlow Context Manager.
Provide access to the archival system (to be discussed). Generate a list of links to previous PSE activities. This will include both complete and partial solutions. This archival system will need to restore the PSE toolkit XML files and the associated WebFlow context data.
The discipline specific information is separated from the toolkit information as shown below:
![]() |
The SciPortal layout to have classes for the portal and protected data and so on. |
|
![]() |
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:
![]() |
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. |
|
![]() |
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:
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:
![]() |
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. |
|
![]() |
This toolkit is dependent on several components.
The AAD is maintained by the WebFlow system administrator and keys off of the machine/code pair of values. The AAD is part of the WebFlow system and is described elsewhere. The PSE uses the AAD to construct the Application Descriptor (AD) and then the Abstract Application Descriptor (ATD) which is how back end services are requested.
The AAD provides information to the PSE about machines and sites.
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.
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) |
![]() |
The SciPortal directory structure provides a flexible structure for developers. See the outline here.
The PSE provides three important services: