1 OGSA-DAI: Service Grids Neil P Chue Hong

2 Motivation  Access to data is a necessity on the Grid  The ability to integrate different data resources opens up wider possibilities for knowledge discovery  At present, even in the non-grid world it is difficult to access and integrate heterogeneous data resources  Aim to utilise the benefits of the Grid and Web Services frameworks

3 Service: GridDataService  Allows access to a specified, single data resource  Availability of code/implementation – –Open source licence based on IBM CPL –Support: (through GSC)  SOA Model:WS/WS-GAF/WS-RF/Jini –Currently OGSI –Moving towards WS and WS-RF interfaces as well –“do we care?” We probably do

4 OGSA-DAI Services  OGSA-DAI uses three main service types –DAISGR (registry) for discovery –GDSF (factory) to represent a data resource –GDS (data service) to access a data resource accesses represents DAISGR GDSF GDS Data Resource locates creates

5 GDSF and GDS  Grid Data Service Factory (GDSF) –Represents a data resource –Persistent service Currently static (no dynamic GDSFs) –Cannot instantiate new services to represent other/new databases –Exposes capabilities and metadata –May register with a DAISGR  Grid Data Service (GDS) –Created by a GDSF –Generally transient service –Required to access data resource –Holds the client session

6 DAISGR  DAI Service Group Registry (DAISGR) –Persistent service –Based on OGSI ServiceGroups –GDSFs may register with DAISGR –Clients access DAISGR to discover Resources Services (may need specific capabilities) –Support a given portType or activity

7 Architecture  Traditional three tier layer –Data layer is the data resources Other resources may include: information on resources, contexts for sessions and transactions, transformed data, data awaiting delivery… –Business Logic layer captures the functionality of OGSA-DAI Existing engine and activity framework Management of resources, sessions, transactions, contexts –Presentation layer deals with communication Extract information from messages for business logic layer Extract information from business layer and construct responses

8 GDS Architecture Other Resources Data Data Resources Other Resources Business Logic DAI-Core Presentation Web Service Proxy Client Client API DAIS DAI WS-I OGSIWS-RF

9 GDS Internals connection role data query perform document response document element credentials Query Activity Transform Activity Delivery Activity Data Resource Implementation Role Mapper The Engine connection

10 GDS: Service Operations  GridDataPerform::Perform –Description: Submit a perform document containing activity definitions and instructions for executing those activities –IN: XML Perform Document –OUT: XML Response Document –Service Data: ActivityTypes PerformDocumentSchema RequestStatus  Document model –Different from current DAIS specs

11 GDS: Service Operations  GridDataTransport::putFully/getFully/putBlock/getBlock –Description: Enables data transport between OGSA- DAI services (or other Grid Services implementing the GDT porttype) or to/from a client using a push/pull model, either in blocks or as one chunk –IN: null –OUT: block of data –No additional Service Data  More about this later…

12  Widely Implemented Standard Specification (1pt) – SOAP, WSDL, XML Schema  Implemented draft specification (2pt) – GSI/GSS/X509  Implemented draft specification (3pt) –<Specification in standards body but alternatives exist. Industry is divided. One/few implementations exist. (e.g., Transactions, coordination, notification, etc.). OGSI  Implemented proposal (4pt) –An implementation of an idea, a proposal but not submitted to standards body yet (e.g., WS-Addressing, WS-Trust, etc.) Grid Data Transport  Non-implemented proposal (5pt) –  Concept (6pt) –  TOTAL: Current total for OGSA-DAI 4.0 is 12 How standard is your service?

13 GDS: Service Dependencies  What else does your service depend on (i.e. external dependencies)? –Databases –Security –XML parsers –Logging (log4j) –Other services (optional Registry)  What does your implementation depend on? –Languages (Java 1.4+) –Container type (Tomcat / Axis)

14 AAA & Security  What authentication mechanism do you use? –GSI (X.509 certificates)  What authorisation mechanism do you use? –Rolemap file, From service  What accounting mechanism do you use? –No accounting at present  Does service interaction need to be encrypted? –Service interaction can be encrypted (message level using GSI) or unencrypted

15 Exploiting the Service Architecture  What features from your ‘plumbing’ do you use in your service? –Factory port (YES) –Factory pattern (YES) –Logging (YES, but log4j not service) –Event notification (YES, but through XML messages) –Meta-data (YES, through service data elements) –Registry discovery/advertisement (YES) –Other OGSI/WSRF/WS/WS-GAF characteristics? We have explored transactions via WS-AtomicTransaction but these are still at prototype stage We would like to explore Notification standards, e.g. with respect to triggers

16 Service Activity  Multiple interaction or single user? –Many users per Data Service Factory –Single user per transient Data Service  Throughput –Wide range  Typical data volume moved in –Wide range  Typical data volume moved out –Wide range

17 Service Failure  Required Reliability –Failure semantics? Different models, depending on need Rich exceptions Clean termination of requests  Required Persistence –Needed for transactional activities –Service persistence – should be handled by container  Required Availability –A factory must be available for each resource –Databases like to vae % uptime, can we do this in an SOA?

18 Required Service Management  Remote access to: –Performance information –Progress / Status information –Data Resource Management –Inspection / Management of running activities –Information on memory / computational load across entire container

19 The WS-I Approach  (Limited) Functionality of Data Service: –Combines aspects of GDS/GDSF functionality –Direct interaction only (no delivery) –Perform document methods stay the same –Defines methods for querying and accessing Metadata –No DAI specific registry –No WS-Security in initial version –A stepping stone towards WS-RF and DAIS Means paths do not diverge early  Technical Issues: –What is the metadata interface? –How do we deal with identity? –What is our approach to security

20 Issues: Data Movement  Interservice Data Movement –Fast, efficient, reliable, STANDARD way of specifying service- to-service movement of data –Identified as a gap in GGF Data Area –Many projects doing their own implementations We are guilty of this –Discussing with Geoffrey Fox and John Brooke  This is the key to making Grids work –Staging via files is not flexible enough  This HAS to be a standard

21 Issues: Security  Security –Efficient, scalable, security –People should be able to specify whichever (popular) authentication model they like: GSI, X509, Kerberos,… –A single approach which spans WS-I/WS-RF is essential –This is not our domain  Want the same approach across frameworks: INTEROPERABILITY

22  How do we uniquely identify a Data Resource given a web service interface –Pass Id through SOAP body Means changes to current DAI and DAIS interfaces Good for tooling –Pass Id through protocol header “REST”ful approach Good for tooling –Pass Id through SOAP header No specified way of doing this yet  Need an application level ID scheme in some circumstances  Want the same approach across frameworks: INTEROPERABILITY Issues: Identity

23  How do we access metadata for the DataService? –OGSI: ServiceDataElements –WS-RF: Resource Properties –WS-I: Define our own methods/operations  How do we discover what metadata is available? –Can’t easily use OGSI or WS-RF approach of including information in WSDL –Define our own method/operations?  Want the same approach across frameworks: INTEROPERABILITY Issues: Metadata

24  Different requirements for session type semantics –Security –Transaction –Context –Etc.  Mechanisms for supporting sessions not standardised in web services space –We have to pick and choose carefully when we need to support sessions –Don’t do it yet unless we have to  This issue is more internal than the others Issues: Sessions

25 And finally…  Savas has assured me that all my issues will be answered at this workshop… I’m looking forward to it