OGSA-DAI: Service Grids
Neil P Chue Hong
1
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
2
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@ogsadai.org.uk (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 
3
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
DAISGR
4
locates
GDSF
creates
Data
Resource
GDS
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
7
GDS Architecture
Client
Client API
Web Service Proxy
Presentation
DAI
DAIS
WS-RF
Other
Resources
OGSI
WS-I
Business
Logic
DAI-Core
Data
Data Resources
8
Other Resources
GDS Internals
element
Query
Activity
query
response
document
The
Engine
perform
document
data
element
element
Transform
Activity
data
Delivery
Activity
credentials
data
connection
connection
9
Data Resource
Implementation
role
Role Mapper
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
10
GDS: Service Operations
 GridDataTransport::putFully/getFully/putBlock/getBlock
– Description: Enables data transport between OGSADAI 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…
11
How standard is your service?
 Widely Implemented Standard Specification (1pt)
– <Demonstrable Multiple Implementations, e.g. SOAP, WSDL> SOAP, WSDL,
XML Schema
 Implemented draft specification (2pt)
– <Specification in standards body and supported by most/many companies.
One/few implementations exist (e.g., WS-Security, BPEL)> 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)
– <An idea that exits as a white paper, but no code and no specification details>
 Concept (6pt)
– <An idea that exists only as power point slides!!>
 TOTAL: Current total for OGSA-DAI 4.0 is 12
12
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)
13
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
14
Exploiting the Service Architecture
 What features from your ‘plumbing’ do you use in your
service?
–
–
–
–
–
–
–
15
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
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
16
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?
17
Required Service Management
Remote access to:
–
–
–
–
–
18
Performance information
Progress / Status information
Data Resource Management
Inspection / Management of running activities
Information on memory / computational load across entire
container
Issues: Data Movement
Interservice Data Movement
– Fast, efficient, reliable, STANDARD way of specifying serviceto-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
20
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
21
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
• “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
22
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?
– 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
23
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
– Don’t do it yet unless we have to
 This issue is more internal than the others
24
And finally…
Savas has assured me that all my issues will
be answered at this workshop…
I’m looking forward to it 
25