Deployment Architecture

This section illustrates and discusses the current (myGrid 0.6) deployment architecture, in terms of the principal software components.

The big picture

Understanding the diagram

The diagram uses (abuses?) conventions, where I"ve used the following stereotypes to classify the components (toothed boxes):

<>

A relational databases, managed by MySQL^?.

<>

A WSDL-based web service, deployed as a WAR file in Tomcat

<>

A Java application started from the command line or by double-clicking some file in a file system explorer

<>

A Java API, implemented as a JAR file and loaded in the context of a webapp or Executable

One component can make use of another: this is shown by a dashed arrow. Such a dependency can be direct via some proprietary API (as for Hibernate), or more usually via some interface. Interfaces are denoted by lollipos: small circles linked to a component that supports the interface. Interfaces to webapps are WSDL port type; the "interface" to a database is the Java JDBC API; and to libraries as genuine Java interfaces (package names omitted for brevity). Thus the MIR-Taverna-Plug-in is a Java JAR file containing a class that implements the Taverna-defined WorkflowEventListener interface, and is loaded inside the JVM running Taverna itself.

An overview of the sytem

The primary user interaction with the myGrid tolkit is via the Taverna based workbench. The MIRBrowser plugin allows the user to explore and update the MIR; The MIR-Taverna-Plug-in and KAVE-Taverna-Plug-in capture "audit trail" and "knowledge" provenance from running workflows and store them in the MIR and KAVE respectively. The MIR stores workflows, raw data and workflow results, structured according to the myGrid InformationModel. KAVE is essentially an annotation service, holding (domain-specific) knowledge about MIR entities in an RDF repository. The three services lsid-authority, lsid-dataservice and lsid-metadata between them support four of the port types.

• The lsid-authority allows users to locate the lsid-dataservice and lsid-metadata service, and also assigns LSIDs as the unique keys for entities stored in the MIR

• The lsid-dataservice service gives an alternative means of accessing the *MIR*"s content

• The lsid-metadata service supplies the known metatadata for some entity, given its LSID: it aggregates this metadata from KAVE and the MIR.

Behind the lsid-authority, KAVE and MIR services are three relational databases.

Noteworthy points

In principle, the relational databases should be "implementation details" behind pure service interfaces. However, the LSID data and metadata services both go behind the MIR service interface either directly to the relational database or via the Hibernate object-relational layer. This points to the need for some form of more flexible MIR query interface, either as an extension to the existing MIR service port type or as a separate port type. Main:NedimAlpdemir has investigated various alternatives, and proposed using the OGSA-DAI service in its WS-I realization. See http://www.mygrid.org.uk/wiki/pub/Mygrid/MyGridInformationRepository/MIR-GenericQuery-Opts.pdf. Note also that LSIDs for MIR-maintained entities are created outside the service itself (in the separate lsid-authority service). For example, it is possible to use the myGrid project"s deployed lsid-authority instance and have all LSIDs allocated by under the www.mygrid.org.uk authority. Thus the whole LSID is the primary key of each entity. Is it better always to require that each MIR instance uses a different authority, and auto-generates simple integer primary keys that appear, stringified, as the object identification components in its LSID? If so, it suggests that the MIR service should itself implement the LSID assigning service and data service port types, rather than have implement these in two distinct services. Should KAVE similarly implement the LSID metadata port type? If this approach is adopted, only the LSID authority service would be separate.

-- NickSharman - 14 Dec 2004