Institution Name: Syracuse University Work Package Title: ASC CY4 IC Project Title: Interoperable Problem Solving Environment (IPSE) for ASC -- Demonstration of Concept POC: Bernholdt David E Email: bernhold@npac.syr.edu Phone: 315 443 3857 Fax: 315 443 1973 CTA or PEI: Information and Communications Project Description: This joint project developed by OSC and NPAC will demonstrate concepts embodied in a briefings on Gateway Interface to High Performance Commodity Computing (HPcc) Systems presented by Dr. Fox at the ASC MSRC Annual PET Review on July 2, 1998 and presented at MAPINT '98 on August 26, 1998 along with outreach briefings to industry and PET partners by Dana Hoffman, ASC Academic Coordinator. This consolidated information was then brought forward to the ASC Interoperability Working Group resulting in the IPSE (Interoperable Problem Solving Environment). Central issues are: How do we build seamless interfaces to HPC resources for DoD scientists and engineers? How do we extend access to those resources to DoD personnel with little or no HPC expertise? How do we demonstrate metacomputing concepts on a small scale before we move to very large-scale problems? And how do we adapt to the HPC hardware/software marketplace of the future so that we best serve the DoD user within the MSRC and DC environments? NPAC is already building initial front-end software for a Pragmatic Object Web (POW) in the HLA/RTI and web launching focused efforts they are conducting for CEWES MSRC. NPAC has also developed Oracle databases that serve network inquiries via web pages (e.g., the grid search engine for CEWES MSRC). OSC or OSU lead activities in CTA areas which are appropriate for early "proof of principle" demonstrations of HPcc concepts. Thus, the fundamental participants and pieces are in place to demonstrate the proof of concept for a 3-Tier (Client -- Smart Middle Server -- Back End Platform) HPcc architecture. The fundamental pieces of a "gateway" or Object Web Architecture for HPcc are: a client workstation that makes requests through a Common User Interface (CUI); one or more servers that receive such requests and determine how they should be met via Object Request Broker (ORB) middleware; and multiple back-end platforms (MPPs, NT clusters, networks, servers, etc.) that perform specific types of commodity tasks. Because many of these tasks do not have to be performed by MPPs, these costly resources can be reserved for tasks that can only be performed on such platforms. Complex operations that involve retrieval of data from mass storage, MPP resource requests, visualization of results, storage of resulting data, access to various non-local databases, etc. may be greatly simplified for the end user. Project Objectives: The project will demonstrate, in phases, the fundamental application of IPSE concepts: client request software (simple Applets or "ORBlets" written in Java); middleware, beginning with a trial implementation of a POW, running on a "gateway server"; and HPC applications, databases, etc. running on the (multiple) back-end platforms. The overall objectives of this project are to design and implement a proof of concept of the HPcc architecture. During Year 4, we expect to complete the initial version of an operational system combining the CCM PSE front-end, NPAC's WebFlow-based middle tier, and back-end computational resources at the ASC MSRC. The two leading issues for the middle tier at present are 1) Defining the WebFlow API (what services and how to access them) 2) Incorporating appropriate security throughout which we expect to be addressed to the extent of having a working prototype system by SC99. After that we plan to investigate enhancements and generalizations, such as support for additional front-ends, security across MSRCs, robustness, fault tolerance, etc. We do not anticipate that the demonstration environment will provide immediate performance improvements. The current implementations of Java compilers and JVM are not tuned for performance or scientific computing. These issues may not even be a driver if Java and its derivatives are only used for middleware and it does not become computationally intensive. They should also be addressed as the Java language and its spin-offs become more mainstream in the information technology marketplace. This project is primarily based on developing a proof-of-concept that provides a more productive environment for the end user. Deliverables: Syracuse is responsible for Middle Tier related deliverables according to the decisions of the Design Team, which includes representatives of Syracuse, OSC, and Nichols. Customers/End Users: All users within the HPC community, both DoD and otherwise. Benefit to Warfighter: The IPSE/HPcc concept offers a promise of dramatically extending access to HPC-like resources by warfighters requiring HPC resources for their desktop environments as well as researchers while minimizing the need to purchase high-dollar mainframes. This could have major implications for the Processing Level 3 (PL3) hardware purchases being planned at ASC and elsewhere. Potential FMS applications are directly relevant to the warfighter. Other benefits include reduction of RDT&E cycle time, etc. Project Dependencies and Scope: The scope of this joint OSC/NPAC project is to provide ASC with the IPSE proof of concept focused on CTAs of interest to ASC. Major areas to address are the PBS scheduler interface and the Kerberos secure environments. Nichols will lead this effort for responsibility to ASC and for overseeing the requirements and deliverables to satisfy the requirements (as the prime contractor for ASC). Nichols will assign a project manager to lead this project for ASC. Nichols will define the environment requirements and have the overall responsible to integrate the deliverables into the MSRC operations, for sustainment and to develop a test bed that will benefit all MSRC's for the HPCMO program. A separate management/oversight structure has been setup to handle the complexities of this multifaceted project. This team sets specific goals and deliverables for all parties as the project evolves. Risk Element: The primary "risk" here is performance of Java on certain platforms and whether the proposed design and middleware will operate at efficiencies that allow the IPSE to perform. The complexity of developing "real" ORBlets may be more difficult than imagined. The secondary "risk" is the requirements of the current ASC environments. The oversight teams are intended to minimize this risk and properly manage the deliverables from PET and ultimately to ASC as a MSRC team effort. An additional important risk lies with the security requirements on the system, including firewalls, authentication (i.e. Kerberos and SecureID), and other issues. In the first place, we can expect security requirements to change with time, which may have a significant impact on this project. Secondly, as the gateway architecture is a new concept, the detailed nature of the relationship between the architecture and security requirements is not yet clear. This risk is somewhat reduced by relying on "commodity" security mechanisms wherever possible, but ultimately, this is a risk which must be accepted as part of the project. Our design will make every effort to satisfy existing security needs, and to provide the flexibility to accommodate likely future changes such as we can envision. Required Funding Level Year X: 150,000 Year X+1: 156,000 Year X+2: 162,240