|
Size: 9720
Comment:
|
← Revision 22 as of 2013-05-17 16:26:45 ⇥
Size: 694
Comment: converted to 1.6 markup
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| More information about use cases will be posted here shortly, but some notes in the meantime... | = Use case documents that we have produced = MAIN OUTPUT FOR THIS = The UseCasesPaper - identifying use cases for a generic grid. |
| Line 3: | Line 4: |
| = Useful Use Cases references = [wiki:Self:RequirementsBibliography#NagaratnamSOGS Nagaratnam et al.] May 2003: The use cases are good for the customer-service provider models and the scenarios where an intermediary is used. |
See also the draft [[attachment:FocusGroup/GridUseCases0_65.pdf|Grid use cases]] document (PDF) produced as a stimulus for the Focus Group Meeting. |
| Line 6: | Line 6: |
| [wiki:Self:RequirementsBibliography#FosterOGSAUC Foster et al.] October 2004: Large document with lots of use cases. Use this to bolster our set of use cases. [wiki:Self:RequirementsBibliography#WelchOGSAR Welch et al.] June 2003:Von Welch et. al. Fairly technical use cases – may be useful at a slightly deeper level. [wiki:Self:RequirementsBibliography#ACES Advanced Collaborative Environments references] July 02 and Dec 04. Could be useful. The earlier document contains use cases and risk analyses. [wiki:Self:RequirementsBibliography#eIRG551 eInfrastructure Reflection Group White Paper Version 5.51] (13 April 2004). May be useful for architecture and use models. Alun investigating further. Von Welch [wiki:Self:RequirementsBibliography#GridShibIntegration GridShib: Grid-Shibboleth Integration (Identity Federation and Grids)] presentation ''' April 11, 2005 includes '''Use cases''' and examples: * Campus Grid Use Case (Campus running Grid, Shibboleth service. Users with campus-issued certificates. Maybe a few outside users. Desires to use campus attributes to authorize use of campus grid. E.g. USC) * Grid Deployment Use Case (Multi-site Grid based around a virtual organization. Users have certificates from one or more Grid CAs, probably not run by VO. Grid wishes to establish attributes for their users to do role-based authorization. Grid is either large enough to establish and run their own Shibboleth AA or someone is willing to do it for them E.g. TeraGrid, OSG) * Hybrid Use Case (Grid based on virtual organization but wants to make resources available to larger community E.g. Allow all chemists to access some dataset. Users have certificates from one or more Grid CAs, probably not run by VO. Want to use campus-asserted attributes, from campus-run Shibboleth services to authorize access to VO resources. Currently done by issuing light-weight Grid credentials to users via a portal. E.g. ESG) Stephen Pickles' [wiki:Self:RequirementsBibliography#advancedreservation Use Cases for Advance Reservation and Co-allocation] presentation at PSNC Workshop on Resource Management, Poznan, 22 October, 2003, includes 'Steering Grid Service' (SGS) '''Use case'''. In summary: * Computational steering + remote, on-line visualization demand: * co-allocation of HPC (processors) and visualization (graphics pipes and processors) resources * at times to suit the humans in the loop * advanced reservation * For medium to large datasets, Network QoS is important * between simulation and visualization, * visualisation and display * Integration with Access Grid * want to book rooms and operators too * Cannot assume that all resources are owned by same VO * Want programmable interfaces that we can rely on * must be ubiquitous, standard, and robust * Reservations (agreements) should be re-negotiable * Hard to change attitudes of sysadmins and (some) vendors Notes: * Use case = 'Steering Grid Service' (SGS) (SGS provides public interface to application’s steering controls. Use standard grid service technology to do steering. Easy to publish our protocol. Interoperability with other steering clients, portals, or Modular Visualisation. Environments with steering capabilities. Application source is unchanged. SGSs used to bootstrap direct inter-component connections for large data transfers) * Scheduling requirements (A typical RealityGrid scenario involves. A simulation running on a massively parallel system, coupled to a visualization running on a high-end graphics system.) * The two sets of resources will often be located on remote systems owned and administered by different organisations. (The administration teams within the two organisations, if aware of each other’s existence at all, are unlikely to have established comprehensive Service Level Agreements or Memorandums of Understanding.) * Reservations: (The ability for a user to reserve processors and graphics pipes manually without involving system administrators would remove a significant barrier to the routine use of computational steering. The ability for an agent or service to do the same will be important for resource brokers later. ...Therefore want ability to reserve network bandwidth with certain quality of service characteristics, using the same protocols as for reservation of processors.) * More complex configurations (RealityGrid's "deep track" is enabling more complex configurations involving finer-grained componentisation. The application is composed out of more than two communicating components, each of which must be deployed onto (possibly remote) computational resources at run-time. Co-allocation mechanisms must therefore be robust and scalable. If we're paying for usage, and cancelling a reservation incurs a charge, then two-phase commit is highly desirable.) * References reservation models [wiki:Self:RequirementsBibliography#ebusinessgrid The Grid: An Infrastructure for e-Business and e-Science] David Walker of Cardiff University provides use cases for e-science, and take-up of grid technology, '''use cases''', incl mention of e-Health, e-Business, e-Commerce, e-Learning. Grid uses include: * Service Providers and Brokers (Trend is towards network-based computing paradigm. Nodes offer different sets of computing services with known advertised interfaces. Software is increasingly seen as a “pay-as-you-go” service rather than a product that you buy once computational economies. Web services important in architecture of the Grid.) * Use Case 1: Utility Computing (Access the power of a remote computer from user’s desktop. Used to run “canned” applications provided on remote computer. End users may be provided with an API or job submission/management tools. Usually a fee is charged. Quite a simple use of the Grid.) * Utility Computing: Advantages (End user doesn’t have to install, maintain, or update application. Service provider has low user support costs, and there is less likelihood of the code being pirated. Simple business model. Also works for data and storage.) * Utility Computing: Issues (Can the end user trust the results returned by the service? (trust, reputation) Should the end user be allowed to execute their own applications on the remote machine? (trust, reputation) If there are several remote resources all providing the same service, which one should an end-user use (discovery, negotiation, and markets).) * Use Case 2: Enterprise Integration (A distributed organisation wants to make all its compute resources (cycles, data, storage) accessible to all its members. Large companies are often interested in this. Assumes everyone in the organisation is trusted. Corresponds to a simple mini-grid.) * Enterprise Integration: Advantages (Reduce total cost of ownership. Improve productivity. Extend capability. Reduce design costs Reduce time to market.) * Enterprise Integration: Issues (Need some form of access control – not all members of the organisation should have access to all resources. Need some form of scheduling so that most important tasks have priority, and resources are accessed fairly.) * Use Case 3: Virtual Organisations (Many tasks requiring collaboration and resource sharing that spans organisational boundaries. Need mechanisms for controlling access and ensuring security. Same organisations my co-operate on one project and compete on another. VO is also called an “extended enterprise”) * Example of an Extended Enterprise: GECEM (GECEM: Grid-Enabled Computational Electromagnetics. Partners are BAE Systems, HP, Singapore Institute of HPC, Swansea and Cardiff universities. Partners form a globally-distributed extended enterprise.) * Slides about CEM * Why use the grid (Industrial and academic partners form an “extended enterprise” in which resources are intrinsically distributed, and only partially shared. Partners may be prepared to share data, but not the hardware and proprietary software that produces the data.) * Issues in Remote Execution (Performance and resilience. Mainly network issues. Security. Would like to migrate code to remote resource, execute it, and return results with minimum risk of unauthorised interference.) * The Output (Status results are returned to the client throughout execution. Results of CEM simulation are returned to client and visualised.) * e-Health: electronic patient records, distributed and/or remote diagnosis, collaborative surgical planning. * e-Business: streamline, distribute, and enhance business processes. * e-Commerce: use the Grid as a marketplace for both traditional and innovative goods and services. * e-Learning: remove barriers to education and training. = Short/Medium/Long term expectations of the Grid = 1. The [wiki:Self:RequirementsBibliography#IAPGRID IAP document] page 6 gives a medium term view of what the Grid could be used for and has some implicit requirements (see notes in [wiki:Self:RequirementsBibliography#IAPGRID Bibliography] ). 1. [wiki:Self:RequirementsBibliography#ebusinessgrid The Grid: An Infrastructure for e-Business and e-Science] David Walker of Cardiff University provides use cases for e-science, and take-up of grid technology, '''use cases''', incl mention of e-Health, e-Business, e-Commerce, e-Learning. |
See also [[http://users.ox.ac.uk/~markn/OxUseCases/|Oxford Use Cases]] for (largely role-based) access control issues, taken from a study of existing and planned projects associated with Oxford University. These use cases are 'information environment' applications (but some involve data processing for users), but the groups of users highlighted could easily be interpreted as strong potential grid users. |
Use case documents that we have produced
MAIN OUTPUT FOR THIS = The UseCasesPaper - identifying use cases for a generic grid.
See also the draft Grid use cases document (PDF) produced as a stimulus for the Focus Group Meeting.
See also Oxford Use Cases for (largely role-based) access control issues, taken from a study of existing and planned projects associated with Oxford University. These use cases are 'information environment' applications (but some involve data processing for users), but the groups of users highlighted could easily be interpreted as strong potential grid users.