• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Lezione 3a
 

Lezione 3a

on

  • 342 views

 

Statistics

Views

Total Views
342
Views on SlideShare
342
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • We define Grid architecture in terms of a layered collection of protocols. Fabric layer includes the protocols and interfaces that provide access to the resources that are being shared, including computers, storage systems, datasets, programs, and networks. This layer is a logical view rather then a physical view. For example, the view of a cluster with a local resource manager is defined by the local resource manger, and not the cluster hardware. Likewise, the fabric provided by a storage system is defined by the file system that is available on that system, not the raw disk or tapes. The connectivity layer defines core protocols required for Grid-specific network transactions. This layer includes the IP protocol stack (system level application protocols [e.g. DNS, RSVP (Resource Reservation Protocol) , Routing], transport and internet layers), as well as core Grid security protocols for authentication and authorization. Resource layer defines protocols to initiate and control sharing of (local) resources. Services defined at this level are gatekeeper, GRIS (Grid Resource Information Service) , along with some user oriented application protocols from the Internet protocol suite, such as file-transfer. Collective layer defines protocols that provide system oriented capabilities that are expected to be wide scale in deployment and generic in function. This includes GIIS ( Grid Index Information Service) , bandwidth brokers, resource brokers,…. Application layer defines protocols and services that are parochial in nature, targeted towards a specific application domain or class of applications. These are are are … arrgh
  • Open Grid Service Architecture Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. In general, entities (people and organizations) create capabilities to solve or support a solution for the problems they face in the course of their business. It is natural to think of one person needs being met by capabilities offered by someone else; or, in the world of distributed computing, one computer agent requirements being met by a computer agent belonging to a different owner.
  • A concept map is a diagram showing the relationships among concepts. They are graphical tools for organizing and representing knowledge. Concepts, usually represented as boxes or circles, are connected with labeled arrows in a downward-branching hierarchical structure. The relationship between concepts can be articulated in linking phrases such as "gives rise to", "results in", "is required by," or "contributes to". [1] The technique for visualizing these relationships among different concepts is called "Concept mapping". An industry standard that implements formal rules for designing at least a subset of such diagrams is the Unified Modeling Language (UML).
  • Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. In general, entities (people and organizations) create capabilities to solve or support a solution for the problems they face in the course of their business. It is natural to think of one person needs being met by capabilities offered by someone else; or, in the world of distributed computing, one computer agent requirements being met by a computer agent belonging to a different owner.
  • The work focused on defining an Abstract Model . This can quickly confuse non-architects, who have trouble distinguishing between concrete architecture and abstract models. The Reference Model (RM) of current interest is an abstract framework for understanding significant entities and relationships between them within a service oriented environment, and for the development of consistent standards or specifications supporting that environment. It is based on unifying concepts of SOA and may be used by architects developing specific service-oriented architectures or in training and explaining the SOA paradigm. A reference model is not directly tied to any standards, technologies or other concrete implementation details (such as "Web Services"). Hence, a good reference model provides common semantics that can be used unambiguously across and between different implementations.
  • Show in a similar fashion the base reference model decoupled from implementation. Reasons why it differs is… Service Description has relationship to contract.
  • The core view of the RM for SOA starts with the concepts of Service, Visibility, Service Description, Execution Context, Real World Effect and Contract & Policy. A service is a mechanism to enable access to a set of one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies ( Contract & Policy ) as specified by the service description . The consequence of invoking a service ( interaction ) is a realization of one or more real world effects , described in detail in the current draft of the RM specification (see 'Background' below for link). The execution context of a service interaction is the set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interaction.
  • OASIS SOA-RM Technical Committee
  • Core concepts The core view of the RM for SOA starts with the concepts of Service, Visibility, Service Description, Execution Context, Real World Effect and Contract & Policy.

Lezione 3a Lezione 3a Presentation Transcript

  • Lezione 3a - 20 ottobre 2009 Il materiale didattico usato in questo corso è stato mutuato da quello utilizzato da Paolo Veronesi per il corso di Griglie Computazionali per la Laurea Specialistica in Informatica tenuto nell’anno accademico 2008/09 presso l’ Università degli Studi di Ferrara . Paolo Veronesi paolo . [email_address] . infn .it , [email_address] http://www.cnaf.infn.it/~pveronesi/unife/ Università degli Studi di Bari – Corso di Laurea Specialistica in Informatica “ Tecnologia dei Servizi “Grid e cloud computing” A.A. 2009/2010 Giorgio Pietro Maggi giorgio . [email_address] . infn . it , http://www.ba.infn.it/~maggi
  • Outline
    • The Grid (riassunto delle puntate precedenti)
    • Service Oriented Architecture (SOA)
    • Richiami di HTTP
    • Richiami di XML
      • XML Namespaces, XML Schema
  • The Grid Metaphor G R I D M I D D L E W A R E Visualising Workstation Mobile Access Supercomputer, PC-Cluster Data-storage, Sensors, Experiments Internet, networks
  • 1. Grid computing: characteristics (2/4)
    • The three fundamental properties of Grid computing:
      • Large-scale coordinated management of resources belonging to different administrative domains (multi-domain vs single domain)
        •  Grid computing involves multiple management systems
      • Standard, open, multi-purpose protocols and interfaces that provide a range of services (standard vs proprietary)
        • Grid computing supports heterogeneous user applications
      • Delivery of complex Quality of Service (QoS): Grid computing allows its constituent resources to be used in a coordinated fashion to deliver various types of QoS, such as response time, throughput, availability, reliability, security, etc.
  • Elements of the Problem
    • Resource sharing: sharing issues today are not adequately addressed by existing technologies.
      • Complex requirements: “run program X at site Y subject to community policy P, providing access to data at Z according to policy Q”
      • High performance: unique demands of advanced & high-performance systems
      • Heterogeneous resources: computers, storage, sensors, networks, …
      • Sharing always conditional: issues of trust, policy, negotiation, payment, …
    • Coordinated problem solving
      • It extends the simple client-server: distributed data analysis and computation
  • The three main capabilities of a Grid middleware
    • Virtualization of users and resources
    Site A Site B Grid system
    • Mapping virtual resources to physical resources
    • Mapping virtual users to physical users
  • Layered Grid Architecture (by Analogy to the Internet Architecture) Grid Architecture Internet Architecture Application Fabric “ Controlling elements locally”: Access to, & control of, resources Connectivity “ Talking to Grid elements”: communication (Internet protocols) & security Resource “ Sharing single resources ”: negotiating access, controlling use Collective “ Coordinating multiple resources ”: ubiquitous infrastructure services, app-specific distributed services Internet Transport Application Link Internet Protocol Architecture
  • Who Defines Standard for Grid
    • OGF: Open Grid Forum
      • http://ogf.org
      • community of users, developers, and vendors leading the global standardization effort for Grid computing
    • OASIS: Organization for the Advancement of Structured Information Standards
      • http://www.oasis-open.org
      • not-for-profit consortium that drives the development, convergence and adoption of open standards for the global information society
    • DMTF: Distributed Management Task Force
      • http://www.dmtf.org
      • industry organization leading the development, adoption and promotion of interoperable management standards and initiatives
    • W3C: World Wide Web
      • http://www.w3.org
      • develops interoperable technologies (specifications, guidelines, software, and tools) to lead the Web to its full potential
  • OGSA Capabilities
    • Security
    • Cross-organizational users
    • Trust nobody
    • Authorized access only
    • Information Services
    • Registry
    • Notification
    • Logging/auditing
    • Execution Management
    • Job description & submission
    • Scheduling
    • Resource provisioning
    • Data Services
    • Common access facilities
    • Efficient & reliable transport
    • Replication services
    • Self-Management
    • Self-configuration
    • Self-optimization
    • Self-healing
    • Resource Management
    • Discovery
    • Monitoring
    • Control
    OGSA OGSA “profiles” Web services foundation
    • Service Oriented Architecture (SOA)
  • Before to enter the game…
    • We introduce the concept maps
      • A simple convention for brainstorming concepts during the development of software systems and/or architecture
      • Concepts maps are a two dimensional format composed of concepts (objects) and associations (relationships). Associations may be named to provide clarity
  • Concept Maps
    • A line between two concepts represents a relationship
    • The arrow on a line indicates an asymmetrical relationship, where the concept to which the arrow points can be interpreted as depending in some way on the concept from which the line originates (Concept 1)
    • Lines can have labels or descriptive text
    http://en.wikipedia.org/wiki/Concept_map
  • Why we talk about concept maps?
    • In general, they are used to identify concepts and relationships in a new investigation domain
    • We use them to sketch the concepts related to the “Service Oriented” world by defining a Reference Model
    • What is SOA; what is a reference model for SOA
    • Why is a reference model needed
    • The OASIS SOA RM
  • Defining SOA
    • Definition of Architecture:
      • “ Architecture: A software architecture for a system is the structure or structures of the system, which consist of elements and their externally visible properties, and the relationships among them.”
    • If Service Oriented Architecture is Architecture, as the name implies, it should be definable as architecture.
    • This should not be done by referencing specific implementations.
  • Closer look: “Service Oriented”
    • Is a paradigm (model) for software architecture.
      • Focus herein is “software & systems architecture”
    • “ Services” are the central concept; other concepts are present.
    • SOA not currently defined other than a “common law” or “defacto” perception of what it is.
    • Perceptions for definition of SOA are vastly disparate.
  • What is a SOA Reference Model?
    • Is a model for developing a range of Service Oriented Architectures and analysis/comparison thereof.
    • Is not architecture for a single implementation. This is very important to understand since things you may see in other architecture might not be present in the Reference Model.
    • Is a framework for understanding significant relationships among the elements of a SOA environment.
    • Is based on concepts present in all SOA’s.
    • A Reference Model defines SOA in an abstract sense. Example:
        • Abstract = Service Description
        • Concrete = WSDL
  • To develop a Reference Model for SOA
    • Some questions:
      • What elements are common in all implementations of SOA?
      • (Paraphrased) What are the core things that make SOA service oriented?
      • How do we describe those as abstract concepts?
      • What relationships exist amongst those concepts?
      • How do we represent those concepts without referencing concrete implementations.
  • Draft Conceptual SOA Reference Model
  • Base Components
    • Service: A behavior, or set of behaviors provided for use by another entity .
    • Service Description: A specification of the information necessary to:
      • allow a potential consumer to determine whether or not this service is applicable, and
      • facilitate invocation.
    • Advertisement: A methodology to convey awareness of (the existence of) a service(s) to all consumers on a fabric. Advertising makes discovery possible.
  • Base Components and Concepts of SOA
    • Data Model: The logical expression of a set of information items associated with the consumption of a service or services.
    • Contract: The syntactic,  semantic and logical constraints governing on the use of a service.
  • SOA Axioms
    • A Service is a set of functionality provided by one entity for the use of others.
    • Services are conceptually autonomous (self sufficient) and opaque (independent of underlying technology) in nature.
    • There is no need to make architectural distinctions between services that are consumed as part of a process vs. ones that are not.
    • There is not always a one to one correlation between “on the wire” requests to invoke a service and service responses being consumed.
    • Each logical Service has exactly one canonical Service Description.
  • SOA Axioms
    • A Service Description is comprised of three logical parts
      • - Data Model - The logical expression of a set of information items associated with the consumption of a service or services;
      • - Policy - Assertions and obligations that service consumers and/or providers must adhere to or provide; and
      • - Contract (and/or offer thereof) - the syntactic, semantic and logical constraints governing on the use of a service.
    • A security policy is a specialized type of the Service Description policy noted above.
    • Service Policy may mandate security requirements to be met, and if they are not, interaction (with the service) may be refused.
  • SOA Axioms
    • A null security policy is still logically considered a policy.
    • A Service Description is advertised to consumers on a fabric to make it discoverable.
    • Discovery does not constitute authorization to execute against the service.
    • What is SOA; what is a reference model for SOA
    • Why is a reference model needed
    • The OASIS SOA RM TC
  • Existing situation WSDL XML & Schema SOAP Base Standards WS-RM WS Addressing Reg/Rep UDDI WS-Security WS-Trust WS-* Requirements Question: How do I account for my requirements and organize components when building a concrete architecture?
  • Thoughts on developing specific SOA’s
    • Probably not logical to try and develop a “one size, fits all” architecture for SOA or WS.
    • Not rational to develop multiple architectures in standards bodies for every set of requirements.
    • Best solution: develop an SOA reference Model.
      • Used by architects to guide development of specific service oriented architectures.
      • Model for a “way of thinking” when architecting.
      • Re-useable by multiple architects writing SOA for multiple domains.
      • Helps architects slot existing standards into their architectures.
  • SOA RM used for range of architectures WSDL XML & Schema SOAP Base Standards WS-RM WS Addressing Reg/Rep UDDI WS-Security WS-Trust WS-* Requirements Guides developments of SOA-RM Specific Architectures Uses Input for
    • What is SOA; what is a reference model for SOA
    • Why is a reference model needed
    • The OASIS SOA RM TC
  • OASIS SOA Reference Model
    • Chartered February 2005
    • Problem to be solved :
      • "Service Oriented Architecture" (SOA) as a term is being used in an increasing number of contexts and specific technology implementations, sometimes with differing or conflicting understandings of implicit terminology and components.
      • The proposal to establish a Reference Model is intended to encourage the continued growth of specific and different SOA implementations whilst preserving a common layer that can be shared and understood between those or future implementations.
  • OASIS SOA Reference Model TC
    • Purpose :
      • The SOA-RM TC will deliver a Service Oriented Architecture Reference Model (SOA-RM).
      • The TC may also create sub-committees, promotional material, liaisons or other promulgation of the TC's work, in order to promote the use of the SOA Reference Model.
      • May help vertical industries develop SOA for their requirements.
  • Definition
    • Reference Model:
    • A reference model is an abstract framework for understanding significant relationships among the entities of some environment, and for the development of consistent standards or specifications supporting that environment. A reference model is based on a small number of unifying concepts. A reference model is not directly tied to any standards, technologies or other concrete implementation details, but it does seek to provide a common semantics that can be used unambiguously across and between different implementations.
  • The OASIS SOA Reference Model
    • Centered around the notions of
      • “ needs” and “capabilities”
    • SOA provides a powerful framework
      • for matching needs and capabilities
      • and for combining capabilities to address those needs
  • Needs and Capabilities
    • Entities (people and organizations) create capabilities to solve or support a solution for the problems they face in the course of their business
      • Just as one person’s needs may be met by capabilities offered by someone else
    • There is not necessarily a one-to-one correlation between needs and capabilities
      • The granularity of needs and capabilities are driven by the business, therefore they vary from fundamental to complex
      • Any given need may require the combining of numerous capabilities, while any single capability may address more than one need
  • Five key questions to interact with a Service
    • How can the Consumer dynamically discover the existence of a Provider , which can provide the services being requested?
    • Assuming the Consumer knows of the Provider’s existence, how can it locate the Provider ?
    • Assuming the Consumer has located the Provider, how can the two describe how to connect to each other , in a standard format which can be understood regardless of their IT platforms?
    • Assuming they have described themselves, how can they exchange messages in a common messaging format which is independent of their underlying platforms?
    • Assuming they have agreed upon a common messaging format, what data format can they use to exchange data independent of their underlying database technologies?
    Application 1 “ Service Consumer” Application 2 “ Service Provider”
  • What is Service Oriented Architecture (SOA)?
    • An SOA application is a composition of services
    • A “service” is the atomic unit of an SOA
    • Services encapsulate a business process
    • Service Providers Register themselves
    • Service use involves: Find, Bind, Execute
    • Most well-known instance is Web
    • Services
    Service Registry Service Provider Service Consumer Find Register Bind, Execute
  • SOA Actors
    • Service Provider
      • Provides a stateless, location transparent business service
    • Service Registry
      • Allows service consumers to locate service providers that meet required criteria
    • Service Consumer
      • Uses service providers to complete business processes
    Service Registry Service Provider Service Consumer Find Register Bind, Execute
  • SOA Benefits
    • Business Benefits
    • Focus on Business Domain solutions
    • Leverage Existing Infrastructure
    • Agility
    • Technical Benefits
    • Loose Coupling
    • Autonomous Service
    • Location Transparency
    • Late Binding
    Service Registry Service Provider Service Consumer Find Register Bind, Execute
  • What is not in the Reference Model?
    • Service composition
      • Choreography, orchestration
      • Process Oriented Architecture
    • Organizational framework
      • Who is doing what to whom
    • Specific technologies
      • not even specific architectures
  • The OASIS SOA reference model – Central concepts
    • Service
    • About services
      • Service description
      • Policies and Contracts
      • Execution context
    • Dynamics of Services
      • Visibility
      • Interacting with services
      • Real World Effect
  • The OASIS SOA reference model – Central concepts
    • Service
    • About services
      • Service description
      • Policies and Contracts
      • Execution context
    • Dynamics of Services
      • Visibility
      • Interacting with services
      • Real World Effect
  • Service
    • A mechanism to enable access to one or more capabilities
      • using a prescribed interface
      • consistent with constraints and policies as specified by the service description
    • A service is opaque in that its implementation is typically hidden from the service consumer
      • except for
        • the information and behavior models exposed through the service interface
        • the information required by service consumers to determine whether a given service is appropriate for their needs
  • Visibility
    • Visibility is the relationship between service participants that is satisfied when they are able to interact with each other
      • Awareness
        • Service description
        • Discovery
      • Willingness
        • Policy & contract
      • Reachability
        • Communication
  • Service Description
    • The service description represents the information needed in order to use, manage or provide a service
    • Service reachability
    • Service functionality
    • Service policies
    • Service interface
  • Anatomy of a Service Service Consumer Interface Proxy Service Interface New Service Wrapped Legacy Composite Service Transformation Layer Service Implementation
  • OO vs. SO Object Orientation Service Orientation When typically used Use Within enterprise Between enterprises Program language dependencies Tied to a set of programming languages Program language independent Coupling Tightly-coupled Loosely-coupled Communication paradigm Procedural Message-driven Communication protocol Usually bound to a particular transport Easily bound to different transports Efficiency Efficient processing (space/time) Relatively not efficient processing
  • Why is it different?
    • SOA reflects the reality of ownership boundaries
      • CORBA, RMI, COM, DCOM, etc. all try to implement transparent distributed systems
      • Ownership is of the essence in SOA
    • SOA is task oriented
      • Services are organized by function
        • Getting something done
    • SOA is inspired by human organizations
      • It worked for us, it should work for machines
  • A Service-Oriented Grid Brokering Service Registry Service Data Service CPU Resource Printer Service Job-Submit Service Compute Service Notify Advertise Application Service Virtualized resources Grid middleware services
  • OGSA: focus on Web Services foundation
    • Security
    • Cross-organizational users
    • Trust nobody
    • Authorized access only
    • Information Services
    • Registry
    • Notification
    • Logging/auditing
    • Execution Management
    • Job description & submission
    • Scheduling
    • Resource provisioning
    • Data Services
    • Common access facilities
    • Efficient & reliable transport
    • Replication services
    • Self-Management
    • Self-configuration
    • Self-optimization
    • Self-healing
    • Resource Management
    • Discovery
    • Monitoring
    • Control
    OGSA OGSA “profiles” Web services foundation