OGSA-DAI: Service Grids

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
• http//www.ogsadai.org.uk
• Open source licence based on IBM CPL
• Support support_at_ogsadai.org.uk (through GSC)
• SOA ModelWS/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

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
9
GDS Internals
response document
perform document
The Engine

element
element
element
Query Activity
Delivery Activity
Transform Activity
data
data
credentials
data
query
connection

Role Mapper
role
Data Resource Implementation
connection
10
GDS Service Operations

• GridDataPerformPerform
• 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

• GridDataTransportputFully/getFully/putBlock/getB
  lock
• 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
How standard is your service?
How standard is your service?

• Widely Implemented Standard Specification (1pt)
• ltDemonstrable Multiple Implementations, e.g.
  SOAP, WSDLgt SOAP, WSDL, XML Schema
• Implemented draft specification (2pt)
• ltSpecification in standards body and supported by
  most/many companies. One/few implementations
  exist (e.g., WS-Security, BPEL)gt GSI/GSS/X509
• Implemented draft specification (3pt)
• ltSpecification 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)
• ltAn idea that exits as a white paper, but no code
  and no specification detailsgt
• Concept (6pt)
• ltAn idea that exists only as power point
  slides!!gt
• TOTAL Current total for OGSA-DAI 4.0 is 12

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 99.999 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
Issues Identity

• 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
• RESTful 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

23
Issues Metadata

• 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?
• Cant easily use OGSI or WS-RF approach of
  including information in WSDL
• Define our own method/operations?
• Want the same approach across frameworks
  INTEROPERABILITY

24
Issues Sessions

• 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
• Dont do it yet unless we have to
• This issue is more internal than the others

25
And finally

• Savas has assured me that all my issues will be
  answered at this workshop
• Im looking forward to it ?