Copyright © 2007 SLAC
This document specifies the functional and system requirements for "Aidaweb". Aidaweb is a servlet program to interface browser based HTTP clients (such as web browsers) to Aida. Aida is a system which provides access to accelerator system data, regardless of the source of that data or on which host it is located. Thereby, aidaweb is a web server servlet for providing users with a broad range of accelerator system data on the web.
This version of the this document is a draft, intended for comment from developers, and to scope development. These requirements concentrate on "phase 1" requirements, but refer to what is intended for phase 2.
The aidaweb servlet should present a web page modelled on Google's default page. A single text entry Form box, into which the user will type the aida name plus all parameter names and values, in the syntax:
instance(//|[ ]+)attribute {paramname(=|[ ]+)paramvalue}0+
That is, an aida name in the familiar Aida form of "name//value", or alternatively "name value", followed by zero, one, or more sets of parameter names and parameter values.
Other than the text entry box, there will be two primary buttons, "Name Search", and "Get Data". An "options" link should also be offered, to a page which describes options. In phase 2, there will also be an "Advanced Search" link to a page describing special purpose retrieval for History, BPM data, model data etc. These requirements are confined to the main page.
With focus in the data entry field, default behaviour for ENTER should be to attempt to get data.
Pattern match: If the user selects the button "Name Search", aidaweb must retrieve and display the aida names matching the given instance and attribute the user should have entered. The semantics of wild card pattern matching should be that as now in ref-aidalist. This may be achieved by coding in jdbc to mimic aidalist into the aidaweb server, or (preferably) adding a SearchNames method to Aida's DaNameServer [ref-danameserver].
As Google, the data delivery should echo the name, and parameters (if given), and followed by the retrieved data.
By default, output should not be reformatted in HTML. However, if a user selects "Format as HTML", as an Option, then reformat as HTML, and in particular HTML table for 2d data.
Tabular Output: 2d structured returned data should be displayed formatted as a table. This requirement may be satisfied by displaying returned data "as is" from AidaFetcher [ref-AidaFetcher] (subject to modification to AidaFetcher below); that is, without further html formatting as an html table, but tabular, unless the "Format as HTML" option has been selected (see Support Excel "Web Query" below).
No "null" column heading: If the returned DaValue does contain meta-data for column headings, then those should be printed. If these are valued null (as AidaFetcher populates them when there is no meta-data "name" for the value vector), then no column heading should be printed. Note that formatting is in AidaFetcher, so this may require modification of AidaFetcher.
Support Excel "Web Query": In order to support Excel data import through a URL (presently called "Web Query"), the option "Format as HTML" must be offered to present the data as an html table. This may be by direct conversion of AidaFetcher output to html table, or indirectly by modifying AidaFetcher to output XML, and using XSL to render html (see ref-brainbell). See Terms of Reference below.
If a user enters an invalid aida name, the response should be something like "No matching name was found", rather than an HTTP 404 or 505 error.
In the case that aida returns UnableToGetDataException exception, Aidaweb should print a meaningful error and refer the user to cmlog for more details. It should contain a link to a page describing how to start cmlog for both lcls and pepii.
Aidaweb should check that it has received 1d, or 2d data (a table). If more dimensions are in the returned DaValue, then it should print an error explaining the problem. Note, AidaFetcher, as used by aidaget, may already check for >2d.
Identify and acquire a server on which to run aidaweb. See Scope and Terms of Reference.
Install necessary infrastructure: Review candidate Application Server technologies (I believe this is confined to tomcat, JBoss, Oracle AS), decide on an appropriate server technology given other commitments in the group, and install the necessary technology on the nominated host(s).
Visibility: Aidaweb should only be visible from inside SLAC, for now, though from any public network machine.
Support AIDAPROD and AIDADEV: There should be an Aidaweb page for the AIDAPROD aida mode, and additionally one for the AIDADEV aida mode. These "modes" refer to whether the client connects to and uses the Aida development, or production, network.
Please work with Ernesto, Jingchen, and Terri to identify an appropriate host or hosts (one for AIDADEV, one for AIDAPROD).
aidaweb should, as much as possible, share code and functionality with ref-AiadFetcher.
Phase 1 is expected 12 Oct
This section describes functionality planned for phase 2. Phase 3 is expected 16 November 2007.
Throttling: Aidaweb will monitor the frequency of requests for some resource-expensive acquisitions, such as beam-synchronous BPM readings, and disallow acquisitions to be made too frequently.
Outside visibility: With the throttling requirement in place, aidaweb will be made visible outside SLAC.
Specialized Pages: Specialized aidaweb pages for accessing model, history, and bpm orbit data, will be developed. These will give help in entering valid parameters, and they will interpret and plot the results.