SOCATS STL-based Object Caching And Transport System

SOCATS SOCATS is Grid-based middleware for the efficient transfer of large relational datasets within the GAE framework Uses Clarens for remote procedure call layer

SOCATS Does not replace Sql2Root for generation of ROOT files Usage examples: A user wants to use an alternate analysis tool (e.g. Matlab,) on the client. The (s)he may want to transfer large resultsets in a non-ROOT relational DB format. A programmer/user wants to access large lists of file locations (from an rls), etc. A user wants to replicate large portions of centralized dbs to a client or server machine

SOCATS Relational DB access in Grid environments pose challenges in several areas: Security Latency Modularity / Data Provenance Accessibility / Ease of Use

SOCATS

Accessibility designed for C++/Python clients, with results delivered in Standard Template Library vector and map objects RPC interfaces defined with WSDL and results delivered in binary form Client-side caching of result sets in conjunction with VDC queries

SOCATS In Summary – SOCATS will provide DB vendor abstraction. Language natural access: STL for C++, RMI for Java,... Location transparency - client code does not have to know whether an object has been transferred in order to call a method on that object. Front-end caching - client code will cache frequently accessed result sets to minimize latencies integrated security and firewall transversal - currently GAE uses CLARENS for rpc and security functionality. Random access of rows in result set - reordering of transfers to meet user's requests. If a user jumps to row 10,000 of the result set, then intervening rows need not be transferred before row 10,000 can be transferred. Eliminate latencies associated with packaging result sets to files by streaming directly to the client. Self describing object collections Demo this afternoon