1. Working Group 3 – Grid C/W & VOs Glenn Gapper, Josep Vallés Sanchez, Boas Betzler, John Brooke & many others! Questions Posed: –What are VOs? –Services required by VOs? –Sectors to mobilised? –Business Models? –Follow-up actions? –IPs, NoEs, CAs, SSAs? –Route map (strategy)?

2. Services From the perspective of VOs and collaborative working. ­ Trust and security, ability to enter and leave VO dynamically. Ad-hoc or controlled joining. ­ Ad-hoc brokering or rigidly adhered brokering? ­ Membership of VO. Role of association. ­ Consolidated accounting and billing, non-repudiation and contract compliance ­ Customisable user interfaces that also need to support mobility. ­ Composition and orchestration of services from component services. Workflow management of use of services. ­ Ability to integrate legacy services. ­ Ability to manage policies and associate policies with members. Do we have community membership, e.g. group membership? VO consortium agreement and a usage policy. ­ Quality assurance of resources. ­ Interoperability (middleware, resources, etc). ­ Discovery of services. ­ Intra-group communications.

3. Requirements for Grid Enabling Technology for VOs Ontology of organisational structure, role, resources, rights, obligations, licensing and so on … –Analysis of use cases for VO to establish roles and services required. VO structure may be different for e.g. scientific problem solving, business process. Model of knowledge within VO, maybe linked to ontology. Ability to identify position of actors within the VO, e.g. when messages are received the recipients can identify the role of the sender in the VO.

4. Sectors for Grid Technology for VOs Disaster and crisis management, environment Manufacturing and engineering (e.g. aerospace, automobile) Publishing and media Medicine and health, bio and pharma. Learning Banking and finance Large scale data-intensive and scientific collaborations. IT Service Provision

5. Business Models Not sufficient time to address this question

6. Follow-up actions - 1 Creation of use-case scenarios for different types of VOs both static, dynamic and evolving, for all potential uses and levels of security, quality of service and internal economy (e.g. are resources charged or free?, is knowledge charged or free?) and risk management. (See list of sectors.) Matching use cases against user requirements and Grid enabling technology for VO. Listing different business models and drivers. Match potentialities of Grid technology against use-cases to drive both new forms of collaboration in VO and new Grid technology. Abstract generic grid functionality

7. Specific Support Actions Need for planning specific support action to coordinate future Grid projects (IPs, NoEs etc..) from FP6 Call 1 onwards with FP5 projects. What sort of actions, workshops? Identification of specification of common enabling application technologies, interface layer between applications and middleware, common grid services as needed by different application sectors building on the GRIDSTART survey of technologies developed within FP5 projects and soon to be delivered.

8. Strategic Options & identifiable requirements for IPs or NoEs The previous slides indicate that there is a pressing need to gather requirements and actions to further this as recommended. It is expected that the identification of such requirements will provide useful background for the formation of effective IPs and NoEs.

9. Follow-up actions 2 It is suggested to continue this ongoing discussion (on use-case scenarios, business models and the strategic requirements & identifiable options for IPs and NoEs) via workshops and other means (electronic forum, etc…) to encourage a broad exchange on generic Grid middleware. We suggest to use the GRIDSTART Web site and an email list.

10. Route Map Insufficient time to address this question – more work needed Personal suggestion from the Chair: ­Need & Want vision ­Need end-user/market pull ­But also need to maintain expectations, risks, and to achieve success! ­Structure programme over time such that priority is given earlier to applications where data is not sensitive (security issues less important) or to local/enterprise scale Grids (where security can be better managed and is required from outset)