Introduction

The purpose of this document is to generalize GLAST web applications in order to extract features common to all of them. Such features would be collected in a common jar file and be accessible via appropriate tags.

This generalization would offer the following advantages:

  • Changes can easily be propagated to all applications using this model
  • Separation of Model/Controller from View (jsp code can get hard to read pretty quickly)
  • It might be also possible to load the jars in an application like JAS3 reproducing some of the functionality of the web based application with the addition of several interactive features

Application

An application can be defined by the following features:

  • context or name
  • url Where the application has been deployed
  • configuration parameters an application has a set of configuration parameters the uniquely define its internal state
  • provided data applications provide data that is uniquely identified by the configuration parameters
  • internal variables they depend on the configuration parameters and are used internally by the application

Configuration parameters

Each application has a set of configuration parameters that uniquely define the internal state of the application. In a web or GUI environment such parameters are set or modified via drop down menus, checkboxes, text fields.

Parameters can be described by the following features:

  • name
  • value The current value of the parameter
  • defaultValue The default value of the parameter.
  • multipleSelection A parameter might accept multiple values (comma separated?)
  • allowedValues The allowed values, if present, are used to create drop down menus or checkboxes in GUI environments. They can also be used to validate the parameter's value.
  • type The type of the parameter. If the parameter has no allowed values an input text box is used in a GUI environment. The type is used to validate the input.

Allowed Values

Allowed values for configuration parameters can either be static or dynamic.

  • static allowed values are set once and for all. They don't depend on the internal state of the application. An example of parameter with static allowed values is the model in the SystemTests application ("GlastRelease", "EngModel", "BeamTest"). Static allowed values can also change due to major changes in the application. It seems reasonable to expect these changes to take effect when restarting the application itself.
  • dynamic For some parameters the list of allowed values depends on the value/s of other parameter/s. For example the version parameter in the SystemTests depends on the model. In order to get a parameter's dynamic allowed values, all the dependencies have to be specified and set.

Provided Data

The following data can be provided:

  • Configuration data : the allowed values for the configuration parameters.
  • Application data : the actual data -> Histograms, set of data points, variables (# events, CPU usage)

Configuration Data

Configuration data is the list of all the allowed values (if any) for a given parameter.

These values are stored in a database and are available to the web application via a query. It could be possible to access such values like:

Database Connection

To provide data appliations have to query database tables; this involves authentification, firewall issues etc etc.
For web applications these problems are handled by the tomcat container.
For GUI applications there are two possibilities:

  • going via the web The GUI application could use the Web application to fetch the data. The two applications would have to implement a common set of interfaces for getting data and parameters.
  • going via a proxy The proxy could be used by both the web and the GUI applicaiton making the common code uniform
  • web service A central place where both the GUI and web application can get the data
  • rmi

Standard Data Access

We need an interface for accessing the data.

  • No labels