Introduction

PAL will be a code library and set of HowTo documents to help DataSet owners publish their data to AstroGrid. A beta version is downloadable from the Datacenter Maven page. Note this is really rough at the moment.

Versions

We'll produce two versions - a standalone that contains absolutely everything needed (i.e. tomcat), and a web archive version, that comes as a .WAR file to drop into an existing tomcat installation. Start with the web archive version.

Contents

If we distribute PAL as a Web Application, we can bundle lots of other resources (libraries, docs) in with it, which will then be published on the web server along with the web service. Which is a nice way to make things available.

What should we put in the PAL?

Documentation

PAL needs to contain an installation guide, configuration documentation, recipes and experience from other datacenters. Development docs (javadoc of apis, etc). Links back to the Astrogrid development site - updates, bug reporting form, mailing lists?

Code

Well, obviously the datacenter server. Plus interface libraries for various back ends (real databases, the HSQL java database, web service delegate), and the third party libs these depend on (i.e. jdbc drivers).

In addition, we should provide the delegate library, as a separate jar, that can be downloaded from the web application (with documentation).

Configuration

As the web application is all bundled up nicely, we don't want the installer to have to go delving into its innards to set it up.

The standard way to do configuration in J2EE is though JNDI. IIRC, a J2EE -standard web container has to provide access to a JNDI-compliant naming service. The deployment descriptor (web.xml) of a web application declares any external resources that the web application expects to find in the naming service. Its the responsibility of the application installer to define resources and bind them into the web application; in tomcat, this is done by editing the server.xml file. Many web containers provide nice GUI tools for resolving and setting up configuration resources using this process.

Other configuration settings are commonly placed in the web.xml file itself.

So, if we could assume a J2EE environment, there's enough configuration techniques open to us. I don't know if this has been decided by the astrogrid project though - hence our ad-hoc attempts to reinvent the configuration wheel.

If we can't mandate a J2EE environment,we'll probably provide a configuration file (properties/xml) that the deployer can edit to set up his own service. This could either be on the web application classpath (in which case the app deployer needs to go tinkering with the web application innards), or external to the web application, pointed to through JNDI.

We'll could provide both routes, and the deployer can choose whatever they're happiest with.

Testing

Axis has a 'happyaxis.jsp' script, that can be called by the user in a web browser. It performs a set of configuration tests, and returns a HTML page of the results. We should be able to do something similar - a JSP that calls a bunch of our existing unit / integration tests.

There's something called the 'Epicentric JUnit JSP test harness ' downloadable from the junit web site provides a web-harness for running standard Junit tests - just what we need.

Other stuff.

Would be nice to include a web form or two that can be used to 'drive' the local web service - good for testing the installation, and for letting people experiment.

I believe Paul is looking into providing something like this in the integration work group. There are also basic tools on the web which will generate a web form for a webservice given a WSDL. e.g.. These will do.

Schemas for the various xml formats - metadata, configuration, request and response formats.

Licenses

Production

Want to get maven to generate PAL in the automatic overnight build. Pal will probably become (yet another) maven project.

-- NoelWinstanley - 10/11/03