SOA Service Oriented Architecture: definizione e qualità dei servizi

Slide from Università about SOA Service Oriented Architecture. La Pdf esplora la Service Oriented Architecture (SOA), definendo i servizi e fornendo esempi concreti, analizzando i livelli di adozione e gli elementi della qualità dei servizi (QoS) per la materia Informatica.

See more

22 Pages

Vincenzo Della Mea
SOA
Service Oriented Architecture
Riferimenti
T.Erl. Service-Oriented Architecture: Concepts, Tec hnology, and Design
T.Erl. Principles of Service Design
M.Papazoglou. Web Ser vices: Principles and Technology, cap.1
Papazoglou et al: Service-Oriented Computing: State of the Art and
Research Challenges, IEEE Computer 40:38-45, 2007
Service
Un servizio è un’entità autonoma, indipendente,
in grado di assolvere funzioni di varia
complessità
- Dalla semplice risposta ad una richiesta
- Alla esecuzione di processi complessi
(il concetto di service)
… è generale e lo
incrociamo nella vita
reale:
servizi semplici:
e composti:

Unlock the full PDF for free

Sign up to get full access to the document and start transforming it with AI.

Preview

Service Oriented Architecture

Vincenzo Della Mea

Riferimenti

  • .T.Erl. Service-Oriented Architecture: Concepts, Technology, and Design
  • T.Erl. Principles of Service Design
  • M.Papazoglou. Web Services: Principles and Technology, cap. I
  • Papazoglou et al: Service-Oriented Computing: State of the Art and Research Challenges, IEEE Computer 40:38-45, 2007

Service

  • Un servizio è un'entità autonoma, indipendente, in grado di assolvere funzioni di varia complessità
    • Dalla semplice risposta ad una richiesta
    • Alla esecuzione di processi complessi (il concetto di service)

e generale e lo incrociamo nella vita reale: servizi semplici:

dispatcher driver bookkeeper

"I take calls and arrange deliveries"

"I make deliveries"

"I take care of the accounting"

dispatcher

"SOA: Principles of Service Design" Copyright Prentice Hall/PearsonPTR

e composti:

driver ABC Delivery bookkeeper

"SOA: Principles of Service Design" Copyright Prentice Hall/PearsonPTR

THE PARADIGM SHIFT FROM PRODUCTS TO SERVICES

"Nobody wants a drill, people want a hole"

Service

  • Un servizio è un'entità (software) autonoma, indipendente dalla piattaforma, in grado di assolvere funzioni di varia complessità
    • Dalla semplice risposta ad una richiesta
    • Alla esecuzione di processi complessi
  • Tramite una qualche piattaforma middleware, un servizio può essere
    • Descritto, pubblicato, reperito, invocato tramite una qualche rete

Service Orientation

Service Orientation

  • Paradigma di progettazione e sviluppo di servizi
  • Basato sull'idea che si possano realizzare delle applicazioni "componendole" a partire da servizi indipendenti, disponibili e descritti su una qualche rete, e coordinati secondo una qualche modalità
    • Viceversa, chi intende fornire servizi li potrà esporre su una qualche rete, corredati dal necessario per la loro fruizione

Principi SO

  • Standardized Service Contract
  • Service Loose Coupling
  • Service Abstraction
  • Service Reusability
  • Service Autonomy
  • Service Statelessness
  • Service Discoverability
  • Service Composability

SO: Service Contract

  • Un servizio espone le sue funzioni e capacità sotto forma di contratto di servizio standardizzato
    • Temi trattati: funzioni fornite,
    • o su che canali/in che modi,
    • tipi di dati scambiati,
    • politiche di funzionamento (es. QoS)
  • Standardizzato affinché sia confrontabile con altri

SO: Loose Coupling

  • Accoppiamento <- > Dipendenza
  • Si creano servizi il più possibile indipendenti dagli altri,
    • In modo che siano adottabili indipendentemente
    • E cambiamenti in uno non influenzino gli altri
  • In realtà si può intendere più generalmente:
    • Accoppiamento tra contratto e servizio, servizio e implementazione, servizio e suoi consumatori ...

SO: Abstraction

  • È sempre un buon principio
    • Si nascondono i dettagli
  • permette l'accoppiamento debole

service encapsulating legacy system

service encapsulating custom components

service encapsulating other services

  • reduced technology abstraction
  • increased technology abstraction
  • dependent technology abstraction
  • limited functional abstraction
  • increased functional abstraction
  • increased functional abstraction
  • varied logic abstraction
  • increased logic abstraction
  • dependent logic abstraction
  • targeted quality of service abstraction
  • targeted quality of service abstraction
  • targeted quality of service abstraction

"SOA: Principles of Service Design", Copyright Prentice Hall/PearsonPTR

SO: Reusability

  • Il riuso del software è un obiettivo globale
    • Si può fare a vari livelli dal cut&paste in su,
  • Ma nel caso SO, in fase di progetto si devono identificare servizi le cui funzionalità possono essere di interesse generale,
  • Per implementarle quindi indipendentemente dalla specifica applicazione
    • ... che si otterrà per composizione di tali servizi

Commercial Product Vendor

commercial product delivery lifecycle

Step 1 Step 2 Step 3 1

commercial products for mass markets and with high reuse potential

Traditional Enterprise

custom development project delivery lifecycle

Step 1 Step 2 Step 3

custom applications for specific enterprise users and with little-to-no reuse potential

Service-Oriented Enterprise

service delivery lifecycle

Step 1 Step 2 Step 3 1

service inventory for a specific enterprise with high reuse potential

"SOA: Principles of Service Design", Copyright Prentice Hall/PearsonPTR

SO: Autonomy

  • Il servizio deve avere controllo sul suo proprio ambiente e risorse,
  • Affinché possa comportarsi consistentemente ed affidabilmente nel tempo
    • NB: anche rispetto alla QoS, es. tempo di risposta
  • L'autonomia ovviamente cala con la composizione

SO: Statelessness

  • Idealmente, per questioni di prestazioni e scalabilità, i servizi dovrebbero essere senza stato
    • Tutte le informazioni necessarie vengono scambiate nella chiamata
  • Praticamente, alcuni servizi invece devono avere stato, perché fa parte della funzione che svolgono
    • "stateful services"
    • Es. ogni funzione che implichi la manipolazione di un database

SO: Discoverability

  • Un servizio deve essere descritto in modo da presentare adeguatamente le sue capacità e le possibili opzioni di utilizzo
    • Sia per la ricercabilità in un eventuale catalogo di servizi, sia per se stesso
  • Ciò corrisponde ad utilizzare metadati adeguati nel contratto di servizio
    • Per identificare funzioni, dati scambiati, ecc

SO: Composability

  • La componibilità è l'obiettivo fondamentale di tutto l'ambito della SO
  • Ed è meno semplice di quanto sembra:
    • Il servizio deve essere progettato avendo in mente che possa essere composto con altri,
    • Anche in assenza di un obiettivo immediato di composizione
    • Altrimenti diventa necessario modificarlo quando è il momento di comporlo

"SOA: Principles of Service Design" C Copyright Prentice Hall/PearsonPTR

A F to solve the big problem, the units are assembled into a specific configuration that allows them to carry out their solution logic in a coordinated manner

B E D G H solves Big Problem A

Service Oriented Computing

Service Oriented Computing

  • E in generale la disciplina che si occupa dei vari aspetti relativi ai service: scienza, ricerca, tecnologie, applicazioni, progetto, patterns ...
    • e SOA
  • I temi trattati derivano dalla convergenza tra diversi settori preesistenti:
    • Sistemi distribuiti
    • Middleware
    • Ingegneria del software
    • Protocolli di comunicazione
    • Linguaggi di programmazione e database Rappresentazione della conoscenza

is designed to support the implementation of

Service-Oriented Architecture

is designed to support the creation and evolution of a

is primarily distinguished by

is designed to support the implementation of

Service-Orientation Design Paradigm

draw from the

provides specific principles in support of

Service Compositions

Service Inventory

provides a distinct set of principles that shape the design of

can be comprised of

automate business processes by assembling

Service-Oriented Solution Logic

Services

SOC: componenti

is comprised of

is comprised of standardized

"SOA: Principles of Service Design" Copyright Prentice Hall/PearsonPTR

service-oriented computing

SOC: obiettivi e benefici

  • Increased Intrinsic Interoperability
  • Increased ROI
  • Increased Federation
  • Increased Vendor Diversification Options
  • Increased Business and Technology Alignment
  • Increased Organizational Agility
  • Reduced IT Burden

SOC: interoperabilità

  • = capacità di scambiare dati
    • Se due programmi non sono interoperabili, bisogna realizzare un qualche meccanismo di integrazione che li renda tali
  • Un obiettivo di SOC è garantire nativamente l'interoperabilità,
    • In modo da ridurre le necessità di integrazione
  • L'interoperabilità è supportata da tutti i principi visti in precedenza (loose coupling, abstraction, etc)

SOC: federazione

  • Sistemi federati: risorse ed applicazioni cooperano, rimanendo però autonome ed indipendenti
  • SOC facilita la federazione poiché comporta la costruzione di servizi standard e componibili
    • A prescindere dai dettagli implementativi della singola applicazione, e
    • a fronte di un costo maggiore che si ha nella fase di progetto, in cui bisogna fare attenzione a questi aspetti

SOC: diversificazione

  • Possibilità, per un'impresa, di scegliere tra diversi fornitori dello stesso tipo di servizio, a seconda di costi e prestazioni, e senza lavoro di integrazione da compiere per passare dall'uno all'altro
    • Va contro il cosiddetto "vendor lock-in"
  • I Web services forniscono uno strumento neutrale che facilita la costituzione di una SOA in grado di sfruttare questo aspetto

SOC: allineamento business - tecnologia

  • Storicamente il software viene sviluppato per soddisfare esigenze specifiche dell'impresa, a breve/medio termine
    • E poi si fatica a mantenere aggiornato il software affinché continuino ad essere soddisfatte anche le nuove esigenze
  • La progettazione SO permette di astrarre i vari livelli che incapsulano accuratamente le attività dell'azienda, rappresentandone i modelli di funzionamento
    • È necessario che intervengano gli esperti del dominio
    • E qualche servizio può anche corrispondere a servizi fisici
  • La componibilità dei servizi permette una veloce riconfigurazione in caso di cambiamenti

SOC: benefici

  • I tre benefici nominati prima possono essere condensati nel fatto che l'informatica in azienda deve diventare sempre meno un peso, con esiti verificabili e reale riusabilità "veloce" dei prodotti.

Service Oriented Architecture

Service Oriented Architecture

  • È uno stile architetturale atto a supportare la service orientation
    • E quindi consiste di componenti atte a favorire la pubblicazione, descrizione, reperimento, utilizzo ecc. di servizi su una qualche rete
  • E' di per sé indipendente dalla tecnologia,
    • Anche se i Web Services sono la tecnologia più nota ed usata per la sua implementazione

SOA/2

  • L'implementazione di SOA comprende una combinazione di tecnologie, prodotti, API, infrastruttura, e altro
  • La SOA dispiegata in un particolare ambiente può essere anche creata ad hoc,
    • Con Java, C#, etc
  • Ma negli anni sono nate specifiche tecnologie che facilitano lo sviluppo di soluzioni SOA fin dall'inizio
    • Es. i Web Services

Ruoli principali

Service client

find bind

Service description

publish

Servic Service Service Registry Provider

Service description

Can’t find what you’re looking for?

Explore more topics in the Algor library or create your own materials with AI.