1
Neil P Chue Hong

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

Service: GridDataService
4 Allows access to a specified, single data resource
4
Availability of code/implementation
– http://www.ogsadai.org.uk
– Open source licence based on IBM CPL
– Support: support@ogsadai.org.uk (through GSC)
4
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
4 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
4
DAISGR locates GDSF creates GDS repres en ts
Data
Resource ac cess es

GDSF and GDS
4 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
4
Grid Data Service (GDS)
– Created by a GDSF
– Generally transient service
– Required to access data resource
– Holds the client session
5

4 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
DAISGR
6

Architecture
4 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

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

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

GDS: Service Operations
4
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
4
Document model
– Different from current DAIS specs
10

GDS: Service Operations
4 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
4 More about this later…
11

4 Widely Implemented Standard Specification (1pt)
– <Demonstrable Multiple Implementations, e.g. SOAP, WSDL> SOAP, WSDL,
XML Schema
4 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
4 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
4 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
4 Non-implemented proposal (5pt)
– <An idea that exits as a white paper, but no code and no specification details>
4 Concept (6pt)
– <An idea that exists only as power point slides!!>
4 TOTAL: Current total for OGSA-DAI 4.0 is 12
12

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

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

Exploiting the Service Architecture
4
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
15

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

Service Failure
4 Required Reliability
– Failure semantics?
• Different models, depending on need
• Rich exceptions
• Clean termination of requests
4
Required Persistence
– Needed for transactional activities
– Service persistence – should be handled by container
4
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
4 Remote access to:
– Performance information
– Progress / Status information
– Data Resource Management
– Inspection / Management of running activities
– Information on memory / computational load across entire container
18

The WS-I Approach
4
(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
4 Technical Issues:
– What is the metadata interface?
– How do we deal with identity?
– What is our approach to security
19

Issues: Data Movement
4
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
4 This is the key to making Grids work
– Staging via files is not flexible enough
4 This HAS to be a standard
20

Issues: Security
4 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
4 Want the same approach across frameworks:
INTEROPERABILITY
21

Issues: Identity
4
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
4
Need an application level ID scheme in some circumstances
4
Want the same approach across frameworks:
INTEROPERABILITY
22

Issues: Metadata
4
How do we access metadata for the
DataService?
– OGSI: ServiceDataElements
– WS-RF: Resource Properties
– WS-I: Define our own methods/operations
4 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?
4
Want the same approach across frameworks:
INTEROPERABILITY
23

Issues: Sessions
4
Different requirements for session type semantics
– Security
– Transaction
– Context
– Etc.
4
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
4 This issue is more internal than the others
24

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