|
Notes from IE Teleconference Call
Oct 18, 1999 (Pierce Marlon, Marlon.Pierce@wpafb.af.mil)
This summary is taken from my hurriedly written notes, so if anyone has any corrections,
additions, or requests for clarification, please email me. For instance, I did not get all the
names for the NAVO contingent.
Participants: Doug Fein, John Melchi (NCSA), Roman Markowski, David Bernholdt
(NPAC), Cherri Pancake, Ken Ferschweiller, others (NAVO/NACSE), Derek Moses
(ARL), Tim Fahey (MHPCC), Charlotte Coleman, Marlon Pierce (ASC).
I started off the meeting with a brief statement of purpose. The goal is to attempt to
identify a common list of features that all centers would like to have from pieces being
assembled right now for various centers. This will lead to a presentation to the program
office and a request for funding. We are not attempting to override any current, funded
projects, or ask for centers to fund any project right now.
Next, we had brief presentations on currently funded projects. First, David Bernholdt
gave an overview of the IOE project at ARL being developed by NPAC and NCSA.
David’s slides were posted to the RADB mailing list. Questions followed. I asked David
to clarify how Tango would be integrated with IOE. IOE will provide access to Tango. I
also asked Doug Fein for a description of the user interface. This will make use of XML
and XSL to allow the individual user some customization and some history features.
NCSA will demo this at SC99. Charlotte asked for a clarification on slide 8 of David’s
presentation.
I then gave a presentation on two ASC projects. The Training Management Database
System was funded by ASC and written by NPAC. Allows students, instructors, course
administrators access to course information stored in databases. I also mentioned ASC’s
secure intranet and extranet activities, kerberized Apache module, and Information
Environment initiatives. My slides were posted to the RADB mailing list.
Cherri next described efforts at NAVO for building web interfaces to databases for
S/AAA’s. She emphasized that it was essential to take the end user into account and
build something they would want to use. One interface for all S/AAA’s at all sites will
not work. The way to proceed for web access to DB’s was to start from each particular
database and the individual users and design from there. This will determine the way to
proceed with middle tier design. It would take multiple interfaces, one for each site.
Doug Fein pointed out that XML could be useful here since it can be used to customize to
each individual user. Cherri pointed out that we still had to design for the users. It was
essential to design a good interface, which XML alone won’t guarantee.
We then attempted to identify goals, common features. NAVO will be building more
interfaces for other users. Derek suggested we focus on interoperable parts. Tim
identified 3 types of information he would like to have browser accessible: user data,
kerberos principal, and user information. Also said he was interested in the other
functions presented in by each site. Charlotte pointed out that an important goal was to
increase accessibility of information within each site. David @ NAVO said that he had
been part of two working groups for building web interfaces, problem was each site had
data in its own form. Charlotte said we did not want to change the backend data
structures, but instead have a different interface for each site.
Charlotte asked Tim to describe what he reported to the program office. They have raw
info such as expansion factors, CPU usage, info on Challenge Users. Currently have info
in MSAccess DB. Want to make reporting easier. Also have training information on
their web site that they would like to incorporate. Help desk information is stored in
Oracle DB. Would be nice to have a common way of reporting to the mod office. Was
interested in account information, allocations. Would like to know which users have
accounts at other centers.
NAVO’s interests were a) user services, b) system administration, c) program
management (such as financial data). They basically were in agreement with Charlotte’s
proposed features. They are moving forward on these things already, one piece at a time.
Derek @ ARL referred to David’s presentation on ARL’s interests. Also pointed out that
much of ARL’s data was not in a database. ASC’s wish list has been given already by
Charlotte in her presentation to the directors.
Cherri identified four categories of data that we had discussed: 1) basic data like
allocation and utilization data, contact information, 2) document repositories, 3)
management information (project status, milestones, timelines), and 4) compressed, high
volume data. The last is mostly scientific data and did not need to be considered here.
We then went through the categories and suggested who would be interested, would want
access. Allocation and utilization data would be desired by S/AAA’s, Principal
Investigators, CTA’s, program office, HPC user community. All sites were interested in
this. It was pointed out by NAVO that there is a potential problem. If 500 people
simultaneously hit the database/webserver at a site, it could swamp their system. Might
not want to give everyone access. I pointed out that since we were asking for funding,
we would include necessary hardware for each site in the funding request. There was a
question on how all of these users would access the DB since there were only a limited
number of user licenses. The idea is to run everything as an application account. The
users interact with the middle tier, the application account interacts with the DB directly.
Each user does not need his/her own DB account.
Category II was next discussed. This includes training materials and PET documents,
which would be accessible by all sites. Question then arose on how the databases would
be populated. We will give the user (with sufficient access permission) the ability to add
his/her own data. Some may be automatically updated as well.
David @ NPAC mentioned that he was worried about adding data that was in MSAccess
DB’s to the system. Weren’t sure how to have an end-to-end kerberized system with
Access on the back end. I suggested that we not include this for now, concentrate on data
in Oracle DBs.
Phone phatigue (fone fatigue?) had set in by this time, so we identified topics for the next
meeting. They are 1) the user interface, 2) making a final list of common features, 3)
making a final list of requirements, 4) identifying hardware and software requirements
(things we’ll need to purchase and thus things we’ll need to put in the funding request,
and 5) an estimate of the amount of money needed to fund the project.
|