Institution Name: Florida State University Work Package Title: ASC CY5 IC Project Title: Gateway: Interoperable Problem Solving Environment (IPSE) for ASC -- Evaluation and Extension 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: Florida State is responsible for Middle Tier related deliverables according to the decisions of the Design Team, which includes representatives of Florida State, 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 5: 156,000 --------------------------------------------------------------------- Institution Name: Florida State University Work Package Title: ASC CY5 IC Project Title: I/C Core Support CTA or PEI: Information and Communications Project Description: This project supports the core activities involved in NPAC's work in the Info/Comm area, including those related to Training and to the Gateway project. Project Objectives: Support the basic level of NPAC involvement in Info/Comm activities at ASC. This includes reporting, participating in meetings, technology tracking and advising in areas relevant to Info/Comm, Training technologies, and metacomputing. In accord with our emphasis on I/C technologies in support of training and education, we plan to develop an architecture for web-based training which integrates modern technologies (such as Java, Jini, Dynamic HTML, and the latest multimedia systems), existing and emerging authoring systems (i.e. WebCT, PowerPoint, "plain old web pages"), and databases into a flexible system that will properly serve the MSRC's needs today and in the future. Univeral Access considerations, very important to the federal government, will also be carefully considered in this design. We will also provide support for the use of NPAC-developed tools deployed at ASC, most especially TANGO Interactive, which we expect to be used extensively for distance training during Year 4. For our metacomputing activities ("Gateway") to be successful it is critically important that we stay abreast of the latest developments in this area, participate in standardization efforts and related activities which Gateway can subsequently leverage to provide better interoperability and functionality. Of particular relevance are the activities of the DATORR (Desktop Access To Remote Resources) effort and the "computational grid" of the DOE, NASA, and Alliance. Deliverables: 1) Periodic reporting, as required by PET management 2) Participation in Reviews, Planning Workshops, and other meetings sanctioned by PET management 3) Attendance at international meetings in areas of I/C and education technologies and exchange of ideas with leaders in the field 4) Attendance at international meetings in areas related to I/C and metacomputing and exchange of ideas with leaders in the field 5) Technology tracking and advising, including training architecture and metacomputing architecture 6) Support for TANGO Interactive and related tools for using in distance training, collaboration, and other applications. 7) Leadership of the MAPINT'99 conference and input into future such conferences Customers/End Users: The immediate "customer" for most of these activities is the rest of the PET program, however MSRC users also benefit directly from productivity improvements resulting from our I/C activities. Benefit to Warfighter: Project Dependencies and Scope: This project underlies all other NPAC activities at ASC. Risk Element: There is minimal risk associated with this activity. Required Funding Level Year 5: 75,000 --------------------------------------------------------------------- Institution Name: Florida State University Work Package Title: ASC CY4 IC Project Title: On-Site Support for I/C Activities 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 project will support Dr. Marlon Pierce as a Florida State University employee working on-site at ASC in support of NPAC's Info/Comm activities. Project Objectives: Florida State is undertaking a number of fairly large-scale projects which fall into the Info/Comm area. These are complex projects which in general require a significant amount of interaction with MSRC and PET staff as well as users to bring to fruition. Having an on-site staff member knowledgable in, and contributing to these projects will greatly facilitate their timely and successful completion. Deliverables: Pierce's primary duties will include (but not be limited to): o Work on Florida State and other PET activities under the direction of Geoffrey Fox and David Bernholdt in consultation with PET management. o Facilitating technology transfer from Florida State into the ASC MSRC environment. o Facilitating communications between ASC MSRC and PET staff and Florida State-based researchers. o Seek out new opportunities for Florida State technologies and expertise to contribute to the ASC MSRC PET program. Customers/End Users: ASC MSRC and PET programs Benefit to Warfighter: The warfighter will benefit indirectly from the enhancement of Florida State's ability to contribute to the PET program. Project Dependencies and Scope: Pierce will be involved to a greater or lesser degree in all NPAC projects which are active at ASC, however we do not forsee any project being singularly dependent on him -- in his absence, all work can be completed by Florida State-based staff (allowing for the lost effort). Risk Element: We are still in the process of trying to hire Pierce, though signs are good that he will accept if we can extend the offer fairly soon. Required Funding Level Year X: 159,000 Year X+1: 165,360 Year X+2: 171,974 --------------------------------------------------------------------- Institution Name: Florida State University Work Package Title: ASC CY4 IC Project Title: TangoInteractive Integration and Enhanced Authoring 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: Integration of existing training tools (TANGO, LecCorder, WebWisdomNT) into a unified framework for both synchronous and asynchronous web-based training and enhancements to incorporate the latest web technologies (i.e. dynamic HTML). Project Objectives: Over the last year, experience in using TangoInteractive and study of other major activities has led to an increasingly clear picture of a good model for web based training that can be expected to be effective and well supported as the web evolves. One should link synchronous and asynchronous models so that synchronous delivery uses a subset of material (web-site) used for asynchronous training. One needs to support both structured (e.g. database backend) and unstructured material (few pages put together by harried faculty just before class). One needs to be be able to archive training sessions. We have developed in TangoInteractive collaboration system, the WebWisdomDB database system and LecCorder archiving system solutions to the key needs of training supporting the above model. Separately we are enhancing this suite of tools with a training management database. In this project, we will join ASC ARL and CEWES support to integrate these systems for greater power and ease of use. We also add a key new ingredient -- good support for dynamic HTML and XML. Note that XML is a key part of Gateway approach. Authoring tools were studied in the last meeting organized by Central State at ASC. This identified a spectrum of approaches to authoring Web based training which offer different tradeoffs between ease of development and richness of the learning environment. At the easy to use end we have pure HTML and Powerpoint with Internet export. As an intermediate solution, there are systems like WebCT which various enhancements such as glossaries. Another successful model is to take HTML and use Java, Dynamic HTML and JavaScript (with possibly a database backbend) to provide a very interactive learning environment. Examples here include the Cornell Virtual Workshop and the many successful Physics and Engineering applets developed at Florida State. The latter are notable as several have already been ported as examples to TANGO Interactive. Finally, there are the authoring solutions used in the familiar sophisticated CD-ROM's and here Macromedia Director/Authorware is a typical authoring tool. There will never be a single authoring tool as there are properly different trade-offs and further different people certainly prefer different systems which are optimized for their needs and capabilities. Much of DoD training for the MSRC and University education uses "low-end" approaches such as HTML and Powerpoint as they are very suitable for rapidly changing topics. It is interesting to note that "Microsoft 2000" will allow more elegant export of PowerPoint to the web using XML and Dynamic HTML. We suggest that a good strategy is not to use sophisticated systems like Macromedia but rather focus on using core web technologies which are sure to track change well. Fortunately TangoInteractive with its powerful JavaScript API allows good support for XML and dynamic HTML. As part of this project we intend to extend our current prototype JavaScript shared browser to support the changing standards for dynamic HTML and XML. This will allow good authoring (support for telecursors and interactive pages) as well as elegant support for quizzes and glossaries. The other clear area of immediate improvement concerns the integration of our current tools so that one can simultaneously deliver a lecture using TangoInteractive with material in the WebWisdomDB database and with archiving using LecCorder. As well as this example, it is useful to link more simply LecCorder with TangoInteractive. We also can benefit by integrating the training database into this system. Here we focus on the most cases without this additional complication. Deliverables: o TANGO Interactive support for Dynamic HTML in version 4 browsers (Aug 99) o TANGO Interactive support for DHTML glossaries and interactive quizzes (Jan'00) o TANGO Interactive support for Dynamic HTML and XML in version 5 browsers (March 00) o Training in Authoring with dynamic HTML and use of training technologies as needed o Integration of LecCorder and Tango Interactive (July 99) o Integration of LecCorder, Tango Interactive and WebWisdomDB. This includes a two month testing and evaluation phase.(March-May '00). Customers/End Users: PET Training staff and instructors Benefit to Warfighter: Provides indirect benefit to the warfighter through support of PET's training mission Project Dependencies and Scope: This project leverages on-going work at CEWES and (if funded) at NAVO. Risk Element: The primary risk in this work involves the quality of web browser support for dynamic HTML. However we assume that even if there are problems initially, dHTML support will improve with time, so that in the long-term the risk is minimal. Required Funding Level Year 5: 0 --------------------------------------------------------------------- Institution Name: Florida State University Work Package Title: ASC CY5 IC Project Title: TangoInteractive in Gateway and Scientific Research 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: Integrates Gateway distributed computing infrastructure with Tango distributed collaboration infrastructure to provide a means for applications built upon the Gateway architecture to easily be made collaborative. Project Objectives: We have often observed that TangoInteractive can be used to support collaborative computing as well as its initial focus on education and training. In this regard we have developed various initial tools including shared visualization (NCSA and NPAC), shared telnet and shared editing with emacs. However we have not been able to clearly identify a good model for this. Gateway provides an important organizing principle that will allow us to properly develop TangoInteractive as a tool in scientific and engineering research. This is the essence of this proposal. To understand technical approach, remember that Gateway is defined in terms of services that are specified through XML used to specify both resources and access to resources. These correspond to XML used either as a serialized database or as as a web template language. Collaboration will also be represented as a set of XML tags in Gateway. Simplest -- given current state of Tango Interactive, are capabilities that do not interact directly with Gateway services. Here XML tags will invoke audio-video conferencing, chatrooms etc. This is still non trivial as it involves a different TangoInteractive interface. However more interesting and harder are those capabilities where Tango Interactive interacts with Gateway. Examples include security, visualization, shared job submittal, shared results and files (both basic web pages and those dynamically created by job). In this regard, we propose to interact with core Gateway group to establish requirements for these coupled interfaces (which will of course also be specified by XML). We will interact with project visualization teams including the NCSA and DICE groups. This will build on existing collaborative visualization work by NCSA and NPAC. Finally we will address CTA specific collaboration by working with CTA teams starting with CCM to establish special capabilities of value. This requirement activity with come up with an initial design, which we will implement, test and evaluate in an ongoing fashion. We will ensure that there will be an interesting demonstration capability for SC99 Deliverables: o Initial design with Gateway Core group of Tango Integration into Gateway with examination of basic capabilities, visualization and one or more CTA's (July 99) o Prototype and demonstration of Tango Interactive with Gateway but only a subset of capabilities(SC '99) o Full integration of TangoInteractive into Gateway with operational support for visualization, two CTA's and core collaboration (May '00) Customers/End Users: Users of the Gateway architecture (PET initially, MSRC users eventually) Benefit to Warfighter: This project will expand the kind of productivity enhancements that will be possible through the use of the Gateway system. Project Dependencies and Scope: This project requires interaction with the Gateway PSE teams and SciVis support. A related project just begun at CEWES involves direct collaboratization of HPC applications. Because of their similarity, these two projects should be strongly synergistic. Risk Element: While the risks of actually completing the proposed work are minimal, it is a novel idea, and w.r.t. the details of the Tango/Gateway integration should be considered a learning oportunity rather than a final implementation. Required Funding Level Year X: 50,000 Year X+1: 0 Year X+2: 0 --------------------------------------------------------------------- Institution Name: Florida State University Work Package Title: ASC CY4 IC Project Title: Training Management Database -- Phase 2 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: Design, implement and deploy a web-based, database-backed system to support training course administration. This project is based on a Statement of Work agreed to in February 1999 which sets out a three phase plan for the development of a Training Management Database system, each offering increasing levels of functionality and sophistication. Phase 1 of this effort was undertaken during Year 3 at no cost to ASC. This particular project corresponds to Phase 2 of the SOW, and a separate Year 4 proposal corresponds to Phase 3. Project Objectives: Statement of Work Training Database Project 1.Design, implementation, and deployment of a web-based data support system for course administration. ASC/MSRC has defined the architecture for an Oracle database to support course administration that is compatible with the ASC/MSRC user database. The database architecture is attached. For security reasons, the web support structure will interface with a mirror of the ASC/MSRC internal database. The work will be completed in three phases as noted in each section. We estimate the time and cost of each phase as follows: Phase Delivery Date Cost 1 1 May 1999 $0 (per agreement w/ GCF) 2 2.5 months after go ahead $25k 3 3-6 months after Phase 1 & 2 ESTIMATED at roughly $50k Please note that further discussions are required on Phase 3 before a firm estimate can be given. 2. The administrative module will consist of web interfaces to the database and will provide the following functionality: 2.1. There should be four levels of access: 2.1.1. Public should be able to view the training schedules, which would include the date(s) the course will be offered, the name of course, description, instructor, and similar information. 2.1.2. Instructors: write access via registration and input forms only. No edit privileges except via registration form. Instructors should have access to web form to input course description and syllabus and any other class information the instructor wishes to provide in advance. Instructors should have access to class enrollment information to include information on enrolled students. 2.1.3. Student: write access via registration and evaluation forms only. No edit privileges except via registration form. Read access to all of class information 2.1.4. Administrator should have read/write access to all tables i.e. access to web form to confirm all additions to schedule and edit, if necessary. 2.1.5. CTA's: Read access to all tables *Note: Individuals control what personal information is displayed (address, phone, email, etc) on the class roster at the public/instructor/student access level. Access levels will be included in phase 1. 2.2 Web Database Interfaces 2.2.1 Administrator read/write access forms, including creation of new courses and class sessions. 2.2.2 Instructor registration and input forms. 2.2.3 Student registration and editing forms. These forms will be included in phase 1, but will only interact with the database tables (web pages and account creation are in later phases). 3.Examples of Functionality 3.1. New course is announced: 3.1.1. Automatic updates to the website: 3.1.1.1. Creates updated training index/schedule web page 3.1.1.2. Creates syllabus web page 3.1.1.3. Creates web page(s) for other class info (conversion may be necessary to ps or pdf) 3.1.1.4. Creates class attendance list or roster web page 3.1.1.5. Updates extended schedule web page 3.1.1.6. Updates news link 3.1.1.7. Creates links to items 3.1.1.1 - 3.1.1.7 from training index/schedule page 3.1.1.8. Update html/cgi-bin registration form to include the new class (es). 3.1.1.9. Creates a text course announcement file and posts to listserver or emails to fixed list 3.1.1.10.Tracks Instructor and student registrations and automatically responds with confirmation automatically based on criteria set forth for each. 3.1.1.11.Upon completion of course, web schedule pages must be migrated from current to previous (items a - d above) and other web pages (items 3.1.1.1 - 3.1.1.12) must be "cleaned up". 3.1.1.12.Updates to existing information (e.g. cancellations, date changes) should be automated incorporate changes to items 3.1.1.1 - 3.1.1.12 above. Web site creation and maintenance of pages is included in phase 2. 3.2 Registration 3.2.1 Registration form should exist for Student and Instructor and include provisions for assignment of a student and/or instructor HPC account. 3.2.2 Registration for student account: dB should maintain current class list and respond with confirmation automatically based on class count, citizenship and DoD affiliation. There are 20 student accounts available per class session. 3.2.3 Registration for instructor account: dB should respond with confirmation automatically based on citizenship and DoD affiliation 3.2.4 Automated mailings should be sent out at predetermined times (e.g. final details). The capability of sending other necessary mailings necessary (e.g. cancellations) is also available. 3.3 Course Preparation 3.3.1 Student and Instructor accounts prepared semi automatically 3.3.2 Instructor unix and kerberos passwords need to be made current 3.3.3 A flag that a SecurID card must be mailed is raised 3.3.4 Kerberos passwords are made current and SecurID passcodes created for them (existing ASC/MSRC oracle database and scripts already exists, a web interface is necessary) 3.4 Upon Completion of a Course: 3.4.1 Information in instructor accounts must be archived 3.4.2 Instructor and student accounts must be cleaned out. (Scripts already exist for these functions but will need a web interface). All of the above items in section 3 pertaining to account creation will be in one part of phase 3. 3.4.3 On-line evaluations form results must be tracked and results automatically totaled, collated and formatted into a standard report. On-line evaluation forms, tabulation and reports will be a part of Phase 3. 3.5 Reports 3.5.1 All fields should be searchable (based on predefined user access) and output directed into custom reports 3.5.2 Standardized reports must be available. Searches, custon reports and availability of other reports will be a part of Phase 3. Deliverables: Phase 2 of the previously agreed SOW will be delivered by September 1999 Customers/End Users: The system will be used primarily by on-site MSRC and PET staff, but also by training instructors and training recipients (MSRC users). Benefit to Warfighter: The system will reduce the human effort required to oversee routine training activities, and thereby allow staff additional time to devote to other MSRC and PET activities which benefit the warfighter. Project Dependencies and Scope: Interacts with on-site Training, I/C PET staff, MSRC User Support and Database Support personnel. Is based on completion of Phase 1 of the SOW, which is underway during Year 3 at no cost to ASC. Risk Element: The principal risk of this project is the fact that the principal developer is a foreign national who (according to present policies) cannot obtain accounts on any ASC MSRC system. Therefore certain installation, testing, and debugging activities will have to rely on the participation of other staff (Florida State, PET, and MSRC). We have been aware of this situation from the start of the project and can manage the risk. Required Funding Level Year X: 25,000 Year X+1: 10,000 (suport and modest enhancements) Year X+2: 0 (support folded into core activities) --------------------------------------------------------------------- Institution Name: Florida State University Work Package Title: ASC CY4 IC Project Title: Training Management Database -- Phase 3 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: Design, implement and deploy a web-based, database-backed system to support training course administration. This project is based on a Statement of Work agreed to in February 1999 which sets out a three phase plan for the development of a Training Management Database system, each offering increasing levels of functionality and sophistication. Phase 1 of this effort was undertaken during Year 3 at no cost to ASC. A separate Year 4 proposal has been submitted corresponding to Phase 2, and this project corresponds to Phase 3. Project Objectives: Statement of Work Training Database Project 1.Design, implementation, and deployment of a web-based data support system for course administration. ASC/MSRC has defined the architecture for an Oracle database to support course administration that is compatible with the ASC/MSRC user database. The database architecture is attached. For security reasons, the web support structure will interface with a mirror of the ASC/MSRC internal database. The work will be completed in three phases as noted in each section. We estimate the time and cost of each phase as follows: Phase Delivery Date Cost 1 1 May 1999 $0 (per agreement w/ GCF) 2 2.5 months after go ahead $25k 3 3-6 months after Phase 1 & 2 ESTIMATED at roughly $50k Please note that further discussions are required on Phase 3 before a firm estimate can be given. 2. The administrative module will consist of web interfaces to the database and will provide the following functionality: 2.1. There should be four levels of access: 2.1.1. Public should be able to view the training schedules, which would include the date(s) the course will be offered, the name of course, description, instructor, and similar information. 2.1.2. Instructors: write access via registration and input forms only. No edit privileges except via registration form. Instructors should have access to web form to input course description and syllabus and any other class information the instructor wishes to provide in advance. Instructors should have access to class enrollment information to include information on enrolled students. 2.1.3. Student: write access via registration and evaluation forms only. No edit privileges except via registration form. Read access to all of class information 2.1.4. Administrator should have read/write access to all tables i.e. access to web form to confirm all additions to schedule and edit, if necessary. 2.1.5. CTA's: Read access to all tables *Note: Individuals control what personal information is displayed (address, phone, email, etc) on the class roster at the public/instructor/student access level. Access levels will be included in phase 1. 2.2 Web Database Interfaces 2.2.1 Administrator read/write access forms, including creation of new courses and class sessions. 2.2.2 Instructor registration and input forms. 2.2.3 Student registration and editing forms. These forms will be included in phase 1, but will only interact with the database tables (web pages and account creation are in later phases). 3.Examples of Functionality 3.1. New course is announced: 3.1.1. Automatic updates to the website: 3.1.1.1. Creates updated training index/schedule web page 3.1.1.2. Creates syllabus web page 3.1.1.3. Creates web page(s) for other class info (conversion may be necessary to ps or pdf) 3.1.1.4. Creates class attendance list or roster web page 3.1.1.5. Updates extended schedule web page 3.1.1.6. Updates news link 3.1.1.7. Creates links to items 3.1.1.1 - 3.1.1.7 from training index/schedule page 3.1.1.8. Update html/cgi-bin registration form to include the new class (es). 3.1.1.9. Creates a text course announcement file and posts to listserver or emails to fixed list 3.1.1.10.Tracks Instructor and student registrations and automatically responds with confirmation automatically based on criteria set forth for each. 3.1.1.11.Upon completion of course, web schedule pages must be migrated from current to previous (items a - d above) and other web pages (items 3.1.1.1 - 3.1.1.12) must be "cleaned up". 3.1.1.12.Updates to existing information (e.g. cancellations, date changes) should be automated incorporate changes to items 3.1.1.1 - 3.1.1.12 above. Web site creation and maintenance of pages is included in phase 2. 3.2 Registration 3.2.1 Registration form should exist for Student and Instructor and include provisions for assignment of a student and/or instructor HPC account. 3.2.2 Registration for student account: dB should maintain current class list and respond with confirmation automatically based on class count, citizenship and DoD affiliation. There are 20 student accounts available per class session. 3.2.3 Registration for instructor account: dB should respond with confirmation automatically based on citizenship and DoD affiliation 3.2.4 Automated mailings should be sent out at predetermined times (e.g. final details). The capability of sending other necessary mailings necessary (e.g. cancellations) is also available. 3.3 Course Preparation 3.3.1 Student and Instructor accounts prepared semi automatically 3.3.2 Instructor unix and kerberos passwords need to be made current 3.3.3 A flag that a SecurID card must be mailed is raised 3.3.4 Kerberos passwords are made current and SecurID passcodes created for them (existing ASC/MSRC oracle database and scripts already exists, a web interface is necessary) 3.4 Upon Completion of a Course: 3.4.1 Information in instructor accounts must be archived 3.4.2 Instructor and student accounts must be cleaned out. (Scripts already exist for these functions but will need a web interface). All of the above items in section 3 pertaining to account creation will be in one part of phase 3. 3.4.3 On-line evaluations form results must be tracked and results automatically totaled, collated and formatted into a standard report. On-line evaluation forms, tabulation and reports will be a part of Phase 3. 3.5 Reports 3.5.1 All fields should be searchable (based on predefined user access) and output directed into custom reports 3.5.2 Standardized reports must be available. Searches, custon reports and availability of other reports will be a part of Phase 3. Deliverables: Discussions finalizing Phase 3 details will follow delivery of Phase 2. Phase 3 will be delivered by May 2000 Customers/End Users: The system will be used primarily by on-site MSRC and PET staff, but also by training instructors and training recipients (MSRC users). Benefit to Warfighter: The system will reduce the human effort required to oversee routine training activities, and thereby allow staff additional time to devote to other MSRC and PET activities which benefit the warfighter. Project Dependencies and Scope: Interacts with on-site Training, I/C PET staff, MSRC User Support and Database Support personnel. Is based on completion of Phases 1 and 2 of the SOW. Phase 1 underway during Year 3 at no cost to ASC, Phase 2 offered as a separate Year 4 proposal. Risk Element: The principal risk of this project is the fact that the principal developer is a foreign national who (according to present policies) cannot obtain accounts on any ASC MSRC system. Therefore certain installation, testing, and debugging activities will have to rely on the participation of other staff (Florida State, PET, and MSRC). We have been aware of this situation from the start of the project and can manage the risk. Required Funding Level Year X: 50,000 (estimated) Year X+1: 15,000 (suport and modest enhancements) Year X+2: 0 (support folded into core activities) --------------------------------------------------------------------- -- David E. Bernholdt | Email: bernhold@npac.syr.edu Northeast Parallel Architectures Center | Phone: +1 315 443 3857 111 College Place, Florida State University | Fax: +1 315 443 1973 Florida State, NY 13244-4100 | URL: http://www.npac.syr.edu