1 / 28

The Open Grid Services Architecture, Version 1.0

The Open Grid Services Architecture, Version 1.0. I. Foster, H. Kishimoto, A. Savva, D. Berry, A. Djaoui, A. Grimshaw, B. Horn, F. Maciel, F. Siebenlist, R. Subramaniam, J. Treadwell, J. Von Reich. Presented by Oscar Valdivia. OGSA Introduction.

sloan
Télécharger la présentation

The Open Grid Services Architecture, Version 1.0

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. The Open Grid Services Architecture, Version 1.0 I. Foster, H. Kishimoto, A. Savva, D. Berry, A. Djaoui, A. Grimshaw, B. Horn, F. Maciel, F. Siebenlist, R. Subramaniam, J. Treadwell, J. Von Reich Presented by Oscar Valdivia

  2. OGSA Introduction GridGrid systems and applications aim to integrate, virtualize, and manage resources and services within distributed, heterogeneous, dynamic “virtual organizations” Items needed • Computers, application services, data, and other resources need to be accessed within different organizations • Standardization Open Grid Services Architecture (OGSA) Is a service-oriented architecture (SOA), that addresses the need for standardization by defining a set of core capabilities and behaviors that address key concerns in Grid systems SOA: A perspective of software architecture that defines the use of services to support the requirements of software users. Enables the creation of applications that are built by combining loosely coupled and interoperable services wikipedia.com

  3. OGSA Document Outline • RequirementsBased on requirements, use cases, technical challenges, previous experience, state of the art in related work. • CapabilitiesTranslates the requirements into a coherent set of capabilities that collectively define OGSA. • Describe infrastructure services and assumptions that constrain development of the OGSA design. • Refinement of the required functionality into capabilities: Execution Management, Data, Resource Management, Security, Self-Management and Information services.

  4. Requirements • Base input on the following Use Cases: http://www.gridforum.org/documents/GFD.29.pdf

  5. Requirements - Characteristics • Analysis of the previous use cases led to identify the following characteristics

  6. Capabilities - OGSA Overview • OGSA is intended to facilitate the seamless use and management of distributed, heterogeneous resources. • Three major logical and abstract tiers. Conceptual view of Grid infrastructure

  7. Capabilities - OGSA Framework

  8. Capabilities - OGSA Infrastructure • Define a coherent and integrated set of components that collectively address the requirements identified previously. Within SOA context. • OGSA Builds and contribute Web Services Architecture [WS-Architecture]. • Service interfaces are defined by the Web Services Description Language (WSDL). • XML for description and representation • SOAP as the primary message exchange format for OGSA services • WS-I for service definition • WS-Security • WS Resource Framework (WSRF) for state representation and manipulation • WS-Notification

  9. OGSA Capabilities • Data Services • Common access facilities • Efficient & reliable transport • Replication services • Execution Management • Job description & submission • Scheduling • Resource provisioning • Resource Management • Discovery • Monitoring • Control • Self-Management • Self-configuration • Self-optimization • Self-healing OGSA • Information Services • Registry • Notification • Logging/auditing • Security • Cross-organizational users • Trust nobody • Authorized access only OGSA “profiles” Web services foundation Source: OGSA keynotes 20060510 H. Kishimoto

  10. 3. Select from or deployrequired resources 1. Describe the job CDL JSDL 4. Manage the job 2. Submit the job Execution Management • The basic problem • Execute and manage jobs/services in the grid • Select from or provision required resources Job Source: OGSA keynotes 20060510 H. Kishimoto

  11. EMS Services • Resources • Service Container • Persistent State Handle Service (PSHS) • Job management and monitoring services • Job • Job Manager • Resource selection services • Execution Planning Services (EPS) • Candidate Set Generator (CSG) • Reservation services

  12. EMS Services Interactions with the rest of OGSA • Deployment & Configuration Service • Naming • Information Service • Monitoring • Fault-Detection and Recovery Services • Auditing, billing and logging services • Accounting

  13. Use cases Issues Access Manage Data Data Find Describe Data Move/Copy/Replicate Data Data Metadata Commonaccess Data Data Protocols Formats Sensor Relational database Data stream Text file Catalog Derived data Data Services The basic problem • Manage, transfer and access distributed data services and resources Source: OGSA keynotes 20060510 H. Kishimoto

  14. Replication Federation Data Services Cache Composite Data Services Data Service 1 Data Service 2 Data Service n Source: OGSA keynotes 20060510 H. Kishimoto

  15. Data Services Functional Capabilities • Transparency and Virtualization • Client APIs • Extensible data type support and operation • Data Location Management • Simple Access • Queries (Structured Access) • Transformation • Data Update • Security Mapping Extensions • Data Resource Configuration • Metadata • Provenance Properties • Scalability • Quality of Service • Coherency • Performance • Availability • Legal and Ethical Restrictions

  16. Data Services Interactions with the rest of OGSA • Transactions • Logging • Execution Management Services • Workflow • Provisioning • Resource Reservation • Discovery • Security • Network management • Naming • Notification

  17. Resource Management Services • Management of the resources themselves • Management of the resources on Grid • Management of the OGSA infrastructure Model

  18. Resource Management Services Interactions with the rest of OGSA • Information Services • Execution Management Services • Data Services • Self-Management Services • Infrastructure • Security Properties • Scalability • Interoperability • Security • Reliability

  19. Security Services Objectives • Enforcement of security-related policy in a VO • Span multiple administrative domains • Integrate and make interoperable unify popular security models, mechanisms, protocols, platforms, and technologies • Implementation-agnostic • Extensible and Integratable

  20. Security Services Model • Security policies are statements about entities, interaction mechanisms and contexts • The model defines the security services as entities with interaction patterns that facilitate the administration, expression, publishing, discovery, communication, verification, enforcement and reconciliation of the security policy

  21. Security Services Functional Requirements • Authentication • Identity mapping • Authorization • Credential conversion • Audit and secure logging • Privacy Interactions with the rest of OGSA • All of OGSA services • Can be a consumer of other services (E.g. Data Services)

  22. Self-Management Monitoring Policy Policy Policy SLA Policy Policy Action Analysis Projection Self-Management • Self-configuration: Automatically adapt to changes in the environment: • e.g. Deploy/undeploy resources as load changes • Self-optimization: Automatically tune system to best meet user or business needs • Uses service-level agreements (SLAs) • Self-healing: Automatically detect & correct problems • Component failures • Security violations • etc. Basic Properties • Service Level Agreement • Policy • Service Level Manager Model Source: OGSA keynotes 20060510 H. Kishimoto

  23. Self Management Services Functional Requirements • Service level management • Monitoring • Analysis and projection • Action • Policy and Model based Management • Entitlement • Planning • Capacity Management • Provisioning Properties • Availability • Security • Performance

  24. Self Management Services Interactions with the rest of OGSA • Discovery • Logging and monitoring • Resource reservation • Workflow • Composition • Security • Resource management

  25. Servicediscovery Loadbalancing Problemdetermination Executionmanagement Accounting Resourcereservation Applicationmonitoring Information Services Provide management and access facilities for information about applications and resources in the grid environment InformationServices Registry Asynchronous notification Consumers Producers Retrieval • Reliable • Secure • Efficient Logger Source: OGSA keynotes 20060510 H. Kishimoto

  26. Information Services Functional Requirements • Naming scheme • Human-oriented name • Abstract name • Address • Discovery • Message delivery • Logging • Monitoring • General Information and Monitoring service

  27. Information Services Interactions with the rest of OGSA • Standard event data models • Notification mechanisms • Security services • Replication

  28. Agnostics Questions • How does OGSI relate to IGSA? http://www-scf.usc.edu/~igsa • QoS is stated as a requirement, but isn’t this an implicit requirement for all computer systems. So how is it addressed in OGSA that makes it important to single out? • Keeping tabs on resources using XML messages sounds good, but what happens when the resource state information is too complex and makes the messages too big and cumbersome? As you know parsing and working with large SOAP messages is not efficient at all. Specifically, any ideas on how to make this a more efficient process? • Service discovery is mentioned as an existing facility, but service discovery is limited to the facilities each organization provides at this moments. Any ideas on how his could be streamlined and standardized? • In capabilities (section 3) the specification mentions self-management. Does this imply that OGSA also specifies a standard for all Grid Services to be Autonomic Systems? • Why where those specific Use Cases chosen? • Is this really an Architecture or more like a grouping of many different services?

More Related