| Institution Name: |
Syracuse University |
| Project Identifier: |
ASC-CY4-IC--4 |
| 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: |
IC |
| 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: |
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 |
Year X Funding:
Year X+1 Funding:
Year X+2 Funding: |
|