Motivation
OGSA-DAI Service Proforma
Middleware Workshop
Neil Chue Hong
• 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
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
Service Operations
• <perform>
– Description: Submit a perform document
containing activity definitions and instructions
for executing those activities
– IN: XML Perform Document
– OUT: XML Response Document
What do you use to build your service?
(i.e. How ‘standard’ is your service?)
Service Dependencies
NB:A low score means less risk & more mainstream
•
Widely Implemented Standard Specification (1pt)
•
Implemented draft specification (2pt)
•
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)
– <Demonstrable Multiple Implementations, e.g. SOAP, WSDL> SOAP, WSDL, XML Schema
– <Specification in standards body and supported by most/many companies. One/few
implementations exist (e.g., WS-Security, BPEL)> GSI/GSS/X509
•
•
– <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!!>
•
• What else does your service depend on (i.e.
external dependencies)?
–
–
–
–
–
Databases
Logging (log4j)
Security
XML parsers
Other services (optional Registry)
• What does your implementation depend on?
– Languages (Java 1.4+)
– Container type (Tomcat / Axis)
TOTAL: Current total for OGSA-DAI 4.0 is 12
1
AAA & Security
• What authentication mechanism do you use?
– GSI
• 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
• If these are not used now, will they be in the future?
Service Activity
• Multiple interaction or single user?
– Expected to be many users per Data Service Factory,
single user per transient Data Service
• Throughput (1/per day or 100/per second?)
– Wide range
• Typical data volume moved in
– Wide range
• Typical data volume moved out
– Wide range
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
Service Failure
• Required Reliability
– Failure semantics?
• Different models, depending on need
• Rich exceptions
• Clean termination of requests
• Required Persistence
– Only on transactional activities
• Required Availability
– A factory must be available for each resource
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
2