1. The e-Demand Project (A Demand-Led Service-Based Architecture for Dependable e-Science Applications) Jie Xu (Project PI) A joint 3-year EPSRC/DTI-funded research project involving: Universities of Durham, Leeds and Newcastle

2. 2 Project Summary Funding Sources: DTI/EPSRC (THBB/008/00112C) Industrial Partners (Sun, Sharp and Sparkle Computer Technology) Total Grant - £636,900 (managed by NEReSC) Duration: April 2002 - April 2005 Investigators: Jie Xu (Distributed Systems & Dependability, Leeds) Keith Bennett (Service-Based Architecture, SoE, Durham) Malcolm Munro & Nick Holliman (Visualisation, CS, Durham) Research Staff: Paul Townend, Nik Looker, Erica Yang, and Stuart Charters Hardware Testbed: A Sun 32 CPU UltraGrid computer connected to a network of Sun servers and workstations (e-Demand Laboratory) and to the White Rose Grid

3. 3 e-Demand: A Software-Based Solution The Demand-Led Service-Based Architecture - New service-based model for organising flexible Grid applications - An instance of the service-based test architecture Fault-Injection-Based Evaluation of Grid Middleware - The FITMVS tool, supported by clusters of workstations - Grid-FIT: Evaluation with respect to faults/attacks/performance (The White Rose Grid Booth, see Nik Looker, Binka Gwynne) Support for Dependable e-Science Applications - Instance-Level Authentication and Identity Management & Attack- Tolerant Information Service – ATIR (Dacheng Zhang & Dr. Erica Yang) - FT-Grid: Topologically-Aware Fault Tolerance (Paul Townend) - 3D visualisation service for e-Science Applications (Stuart Charters)

4. 4 Service-based Architecture  The architecture that we started with: Service consumer Contractor/assembly service provider Catalogue/ontology provider Demand Provision Finding Service/solution provider Ultra-late binding Publishing e-Action service Attack-tolerance service 3D visualization service …

5. 5 external WS architecture middleware internal service internal service internal WS architecture WS interface access to internal systems Web Services Architecture Web Services Architecture

6. 6 Service Description, Discovery and Interactions DescriptionDiscoveryInteractions properties & semantics business protocols interface common base language middleware properties protocol infrastructure basic & secure messaging transport XML WSDL WSCL BPEL QoS cost Directories UDDI HTTP SOAP- messaging WS- coordination WS- transaction

7. 7 Run-Time Checking & Monitoring Session Control & Management Security Enforcement Authorisation of actions Role/Task-based Access Control Policy Management Authentication Identity management Non-repudiation etc Execution Environment Workflow/Session Management Service Composition Information Integration Grid-based resources (Built on the UK NGS/ White Rose Grid) System Architecture for e-Demand Service 1Service 2Service 3 Service Instances Interactions Message Encrypt/Decrypt Traffic Monitoring & Filtering ATIR FT-Grid Grid-FIT

8. 8 Testing Architecture: Grid-FIT  Our testing service currently implements network level fault injection. Fault/Attack Injector (testing service) Client Server Service Request (may contain faults) Response (may contain faults) Middleware boundary Intercepted request Intercepted response Potentially altered request Potentially altered response

9. 9 Securing Instance-Level Interactions  A complex Web service business session may span diverse security domains and organisational boundaries  Independent authentication and authorisation mechanisms are often needed to protect Web service business sessions from malicious attacks  These authentication and authorization mechanisms must work at the service instance- level  Suppose that three instances, Consumer, Producer, Shipper, compose a session  Shipper is unknown to Consumer as it is selected by Producer at run time  Based on a certificate from the business authority, Consumer then accepts that Shipper is a legal corporation/entity  Consumer also wants to be sure that Shipper is the assigned instance processing the order  Potential solutions

10. 10 Service Instance Identification  Two key technical issues to address: 1) The Web service instances within a session have to be identified ID-based solution  Using instance identifiers to explicitly identify Web service instances  Suitable for fine-grained management mechanisms which can exercise more precise control over a business session Token-based solution  Using correlation information to identify the conversation/interactions amongst service instances and then implicitly identify the instances involved  Suitable for coarse-grained management mechanisms with less implementation overload 2) How to generate, distribute, and manage the security keys for enforcing the security boundaries of a business session – s o as to achieve effective attack/damage confinement

11. 11  Various key management solutions have been considered and examined  All participating instances within a given session share a security key  Group communication-based approaches  Public key-based solutions (can be combined with ID-based schemes for instance identification) Business Session Key Management Our Instance ID authenticator protocol is an ID-based scheme Using the Diffie-Hellman protocol to distribute authentication information amongst participating instances of a session Providing authentication to Web service instances of the same session by appending the MAC code to the sending messages

12. 12 System Evaluation: Examples Token-based scheme ID-based scheme Scalability Model Scalability Model

13. 13 Conclusions (1)  The e-Demand project is multi-faceted – it’s looking at service-based architectures, security, testing and fault tolerance.  The main focus of my talk has been to present some results from the e-Demand project in regard to architectures and instance-level interactions.  Important information about Grid-FIT, FT-Grid and ATIR etc can be found in the conf. proceedings.  Some Grid applications have been supported by the e-Demand architecture and services.  Experience with supporting interactions across organisational boundaries

14. 14 Conclusions (2)  We have designed and implemented a fairly efficient system that supports dependable instance-level interactions, independent of the underlying Grid systems used  To further enhance the dependability of Grid applications, we have developed mechanisms and services for fault/attack detection and tolerance  We have focussed on assessing the dependability of Grid mechanisms and systems based on fault/attack injection techniques

15. 15 The Way Forward  Continuous collaboration with NEReSC, the GOLD team, and the GT4 team etc  Wider range of Grid connections for larger scale experiments and assessments – the White Rose Grid, the CoLab Gird between UK and China etc  Grid applications in e-Social science domains (the MoSeS project)  Evaluation with a focus on performance and security