Spitfire A Relational DB Service for the Grid

1. Spitfire A Relational DB Service for the Grid Peter Z. Kunszt European DataGrid Data Management CERN Database Group

2. Motivation • Small and large Grid applications • working together to provide access to and management of massive amounts of data • Examples • replica metadata catalog, service registry, application metadata, logging and performance monitors • Use • easy to use, interoperable and high-performing database technology • Otherwise • continue to use many proprietary approaches towards metadata storage and retrieval

3. Baseline • Aim: Unified Grid enabled front end to relational databases. • Convenient, scalable and efficient storage, retrieval and query of data held in any type of local or remote RDBMS. • Core SQL functionality is insert, delete, update and query. • Implement as Grid Service

4. WP2: What did we sign up for? Metadata Management • 'Simple' Grid Persistency • Grid Metadata • Application Metadata • Metadata Replication and Consistency • Publish information on the metadata service

5. Local Application Local Database Local Computing Grid Application Layer Grid Job Management Data Management Metadata Management Object to File Mapper Collective Services Information & Monitoring Replica Manager Grid Scheduler Replica Catalog Interface Replica Optimization Underlying Grid Services Spitfire MetaData Service Computing Element Services Storage Element Services Replica Catalog Authorisation, Authentication and Accounting Service Index Grid Fabric services Fabric Monitoring and Fault Tolerance Node Installation & Management Fabric Storage Management Resource Management Configuration Management

6. Connecting Layer SOAP Global Spitfire Layer SOAP SOAP SOAP SOAP SOAP OracleLayer OracleLayer PGLayer MyLayer Local Spitfire Layer Oracle DB2 PostGres MySQL Spitfire Architecture • Web/Grid Services Paradigm • SOAP interfaces • JDBC interface to RDBMS • But not a 'real' distributed DBMS • no distributed locking & transactions (yet?) • lazy consistency model • Atomic RDBMS is always consistent • No local replication of data • Role-based authorization

7. The Local Layer Required from the local Site: • Any JDBC-enabled RDBMS backend. (PostGreSQL, Oracle, ..) • Any Servlet Container. (Tomcat, Oracle Application Server, WebSphere…) • SSL Provides: • SOAP & WSDL interface • Role-based Authorization • Simple Persistency • Expiration based on a timestamp

8. The Global Layer These are all only 'on the table' ; not worked out in detail, see also Database BoF • Distributed Querying • Needs additional information on the given data, like definition of common schemata and indices. • Caching/Replication mechanisms • Consistency • Expiration • Cleanup • Transactions

9. Local Layer Architecture Client API SSL Auth Security Servlet Translator Servlet RDBMS JDBC Expiration Servlet

10. HTTP + SSLRequest + client certificate Is certificate signedby a trusted CA? Has certificatebeen revoked? No No Yes Find default Role ok? Request and connection ID Security Mechanism Servlet Container SSLServletSocketFactory RDBMS Trusted CAs TrustManager Revoked Certsrepository Security Servlet ConnectionPool Authorization Module Does user specify role? Role repository Translator Servlet Role Connectionmappings Map role to connection id

11. DB Administration Create Database Delete Database Create Table Drop Table Role Administration Create Role Delete Role Update Role DB Information Quotas Memory, Disk space User Info Schemata Core Functionality Insert Update Delete Select Timestamps Set Table Timestamp Set Row Timestamp Connections Open Dedicated Connection Close Connection Local Layer Functionality