Tecnologia dei Servizi Grid e cloud computing - Lezione 003a 0 Lezione 3a - 20 ottobre 2009 Il...

Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003a 1

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 [email protected], [email protected]://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 [email protected], 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


GRID

MIDDLEWARE

Visualising

Workstation

Mobile Access

Supercomputer, PC-Cluster

Data-storage, Sensors, Experiments

Internet, networks

The Grid Metaphor


1. Grid computing: characteristics (2/4) The three fundamental properties of Grid computing:

1. Large-scale coordinated management of resources belonging to different administrative domains (multi-domain vs single domain) Grid computing involves multiple management systems

2. Standard, open, multi-purpose protocols and interfaces that provide a range of services (standard vs proprietary) Grid computing supports heterogeneous user applications

3. 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


6

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)

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

InternetTransport

Application

Link

Internet Protocol

Architecture

Grid Architecture

Internet 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


OGSAOGSA

OGSA “profiles”OGSA “profiles”

Web services foundation 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

1. A Service is a set of functionality provided by one entity for the use of others.

2. Services are conceptually autonomous (self sufficient) and opaque (independent of underlying technology) in nature.

3. There is no need to make architectural distinctions between services that are consumed as part of a process vs. ones that are not.

4. There is not always a one to one correlation between “on the wire” requests to invoke a service and service responses being consumed.

5. Each logical Service has exactly one canonical Service Description.


SOA Axioms

6. 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.

7. A security policy is a specialized type of the Service Description policy noted above.

8. Service Policy may mandate security requirements to be met, and if they are not, interaction (with the service) may be refused.


SOA Axioms

9. A null security policy is still logically considered a policy.

10. A Service Description is advertised to consumers on a fabric to make it discoverable.

11. 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 &SchemaSOAP

Base Standards

WS-RMWS

Addressing Reg/RepUDDI

WS-SecurityWS-Trust

WS-*

RequirementsQuestion: How do I account formy 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 &SchemaSOAP

Base Standards

WS-RMWS

Addressing Reg/RepUDDI

WS-SecurityWS-Trust

WS-*

Requirements

Guides developments of

SOA-RM

SpecificArchitectures

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 2005Problem 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

1. How can the Consumer dynamically discover the existence of a Provider, which can provide the services being requested?

2. Assuming the Consumer knows of the Provider’s existence, how can it locate the Provider?

3. 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?

4. Assuming they have described themselves, how can they exchange messages in a common messaging format which is independent of their underlying platforms?

5. 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

ServiceRegistry

ServiceProvider

ServiceConsumer

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

ServiceRegistry

ServiceProvider

ServiceConsumer

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

ServiceRegistry

ServiceProvider

ServiceConsumer

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


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

ServiceInterface

New Service

WrappedLegacy

CompositeService

TransformationLayer

ServiceImplementation


OO vs. SO

Object Orientation Service OrientationWhen 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

Virtualized resources

Grid middleware

services

Brokering Service

Brokering Service

Registry Service

Registry Service

DataService

DataService

CPU ResourceCPU ResourcePrinter Service

Printer Service

Job-Submit Service

Job-Submit Service

ComputeService

ComputeService

No

tify

Ad

vertise

ApplicationService

ApplicationService


OGSA: focus on Web Services foundation













OGSAOGSA

OGSA “profiles”OGSA “profiles”

Web services foundation Web services foundation

Tecnologia dei Servizi Grid e cloud computing - Lezione 003a 0 Lezione 3a - 20 ottobre 2009 Il...

Documents

Transcript of Tecnologia dei Servizi Grid e cloud computing - Lezione 003a 0 Lezione 3a - 20 ottobre 2009 Il...