OGSA-DAI User Group
Infrastructure Breakout
1
Objective – To Propose…
• The collection of WS-* specifications to
base OGSA-DAI on
• The level of support that OGSA-DAI
should provide for the evolving GGF DAIS
specification
• The deployment platforms that OGSA-DAI
should support
2
Process
• We can’t do everything in OGSA-DAI due
to finite time and budget so we must
prioritise
– Requirements for projects
– Requirement across projects
– Requirements of high priority
• Today we should try and avoid the politics
and keep and eye on the clock
3
WS-*
• Generally
– OGSI
– WS-RF
– WS-I
• Which need to support
–
–
–
–
–
–
–
Identity of resources
Stateful interactions
Meta data
Sessions
Lifetime management
Endpoint fragility
Security
• Visibility of the differences
– What is the cost (to the administrator/consumer) of different approaches
4
• Cost of maintaining incompatible infrastructure higher
than writing access code
• WS-I OGSA-DAI followed by WS-RF OGSA-DAI
• WS-I/WS-RF can be used to represent the same data
resources in different ways
• Dangerous to track evolving specs
• People want GT4 compatible implementation
– But to require GT4 could also be problematic
• Can OGSA-DAI produce a straw man for the way forward
for WS-I/WS-RF
5
• Identifying data resources
– Applications have different ways of naming data and providing meta data
for data resources
– Not a clear separation between data and meta-data. eDiamond access
mechanisms are the same
– Be useful to be able to associate arbitrary meta data with data resource
– Mapping from name to service location
• Life sciences have LSIds
• Need a hierarchy of names/mappings will help map down to a data resource.
(GSH vs GSRs ?)
• What are we mapping to. Resource, Services, datasets.
• Major performance hit if you have to map name before doing anything
• Gnerally rely on registry to map from name to resource/service
6
• Security
– OGSI/WSRF say nothing about security
– GT3 imposed GSI security model
7
Support For DAIS
• OGSA-DAI current
– Perform document model
– GDSF = data resource
– GDS = session over data resource
• DAIS
–
–
–
–
8
Data service = data resource
Direct access via RPC style messages
Indirect access via derived data services
Other specs include
• DAIS
– Be useful to hide the model switch to DAIS
behind client toolkit
– Staged approach
• Simple WS-I
• More capable WS-RF
9
Deployment Platform
•
Build data services within
–
–
–
Globus Toolkit GT2/3/4
Unicore
J2EE
•
–
•
Windows
Linux
Other UNIX flavour
Point data services at
–
–
–
–
–
–
10
Java
C++
C#
Perl
Deploy data services on
–
–
–
•
.Net
Build data services with
–
–
–
–
•
Axis/Tomcat
DB2
Oracle
SQLServer
Postgres
MySQL
Xindice
• Does using WS-I imply not using Globus?
– Not necessarily but maybe we assume Tomcat/Axis
• Three axes of globus
– What you build on
– What clients require
– What is promised to those you call
• Client library may need porting to different languages
• Some users won’t use client library, e.g. resources included in BPEL.
– MyGrid/Gold want to ensure that DAI rendered resources can appear in
workflows
•
•
•
•
May want to call Perl on the server side
Files
Object DBs – no one here doing it
OGSA-DAI in front of continuous data sources
– Originally envisaged but no one doing it with ogsa-dai yet
11
Summary
Only 9 people in the room
4 of whom were users
from 5 projects
12
Infrastructure
• The community is uncertain about what to do
• Provide straw men to show implications
• Some people want WS-I others GT4 (!) others
don’t want to have to care
• WS-I first, WS-RF later as it matures
13
DAIS
• Keep functions that have provided value
– E.g. extensibility of Perform Documents, i.e.
activities
• Validate the DAIS standard
– Not a high priority user req
• Composability with other WS specs
14
Deployment
• Files Files Files
– Some subclass, e.g. CSV, DFDL
– When the file is the table
• Perl
• What do we mean by WS-R/WS-I?
– Standards or Platforms
• Different client library languages
– Java, C++, C#, Perl, C?, Fortran?
– As a contribution
• Publish an API for the client library
15