Latest stable release: v2.1.7 (prepared for EDG release 2.1). See documentation.

Latest bug fix release: v2.1.11, for edg-spitfire-server and edg-spitfire-client-c++, December 2003.

Description of Spitfire

Spitfire is a project of Work Package 2 within the European Data Grid Project.

Spitfire is provides a means to access relational databases from the Grid. The Spitfire Task has the mandate to provide middleware to provide transparent, secure access to metadata for GRID middleware and applications. Currently it consists of the Spitfire Server module and the Spitfire Client libraries, a Browser and command line executables.

Spitfire is a very thin layer on top of an RDBMS (by default MySQL) that provides a JDBC driver. It's using Web Service technology (Jakarta Tomcat) to provide SOAP-based RPC (through Apache Axis) to a few user-definable database operations. The Spitfire layer gives a quick and easy access to data, but is not supposed to be used as a full-fledged Data Management System. Problems may arise for queries returning a very large result set, long-running queries and other complex operations like multi-way joins that need a large amount of system memory etc. The Spitfire module itself provides an example of a simple set of very common database operations.

Spitfire is designed to give quick and easy access to (meta)data where the access patterns are simple: single- or few-row lookups and inserts, updates and deletes. Information on the tables is also provided.

Spitfire also has a 'browser' module that helps the developers to create JSP pages to expose the data through a secure web interface. Spitfire makes use of the Security modules to enable full GSI authentication and additional authorization.

Why would I want to use it?

Grid middleware and Grid application software often need access to persistent data or need to write data into a persistent store. For massive amounts of application data the applications will continue to use their own optimized data stores. But for short lived, small amounts of data and metadata that needs to be highly accessible to many users and applications throughout the Grid there is a need for an abstract high-level Grid database interface. Without such a service applications and Grid middleware services will continue to use dozens of varying and incompatible approaches necessitating complex and expensive translation and conversion steps.

How does Spitfire address this problem?

Spitfire provides a uniform way to access many RDBMS systems through standard protocols and well-published interfaces. Grid users are mapped to DB roles in a configurable way to support many different policies. Three SOAP services are defined: a Base service for standard operations, an Admin service for administrative access and an Info service for information on the database and its tables. There is also the possibility to use a web browser to access the database through HTTP and canonical XML through a simple SQLDatabaseService. Client-side APIs are provided for java and c++ for the SOAP-enabled interfaces, there are also some client-side tools for the SQLDatabaseService. The Spitfire services are abstracting the access to a local RDBMS.

Spitfire Architecture. The Local Layer service connects through a RDBMS through JDBC (black solid line) using predefined roles. The client can connect directly to the local layer through any published interface, and perform database operations. In the future Global Layer services will be provided for more sophisticated distributed database methodologies. The Database Services are implemented as a Java servlet through AXIS. SOAP is used for remote messaging to ensure interoperability. We will apply the Open Grid Services Architecture guidelines for our interfaces as soon as its spec stabilizes. WSDL

Depending on the requirements on the quality of the service, it can be deployed in freely available servlet containers (like Tomcat) or commercial servlet containers. The client libraries provide the necessary Grid authentication mechanisms to connect to a secure session through HTTPS. For normal unsecured sessions any HTTP client can be used (wget, curl et al).

Is it efficient? Effort has been invested into enabling high performance and low latency. Java servlets are highly efficient and scalable solutions, and known to be superior to other approaches such as CGI scripts, modperl, PHP. To minimize the number of connection setup and tear-downs, persistent HTTP(S) 1.1 connections can be used (but not required). For similar reasons, the services use thread and JDBC connection pooling and advanced caching. The net effect is that requests and responses are passed through layers with little delay.

Is it secure? The HTTPS configuration is fully GSI compatible. Spitfire uses the edg-java-security module of WP2, see the Security Task's webpages.