Comprendere l'architettura service oriented

Comprendere l’architettura
Service-Oriented

UNA PRIMA INTRODUZIONE TEORICA

Comprendere l’architettura SOA

Introduzione

 Sembra probabile che la maggior parte del software possa essere realizzato e
consumato sotto forma di servizio
 I sistemi possono essere spesso disaccoppiati in maniera tale da renderne
fruibile le funzionalità da portali, da dispositivi o da qualunque mezzo sia in
grado di esporre una interfaccia
 Il timore concreto, manifestato da architetti e designer, è quello di mantenere
una certa prudenza in questo approccio
 Il pericolo è che tutto il software possa essere pensato e progettato sotto
forma di servizio
 E questo approccio può generare solo confusione

Comprendere l’architettura SOA 3

Approccio tecnologico

 In realtà, tutto quello che può essere realizzato in forma di web service, può
essere visto come un servizio
 E la maturità tecnologica di questo paradigma può spingere facilmente verso
questa direzione
 Ma questo non toglie la necessità di progettare tutto da una prospettiva di
servizio solo quando è conveniente
 Il servizio è la parte principale della progettazione e deve essere utilizzato
correttamente in tutti i punti significativi di ogni interfaccia


Influenza nel ciclo di vita del software

 L’architettura Service-Oriented ci consente di gestire completamente i servizi
da realizzare
 La gestione è intesa sia in termini di design che di rilascio, manutenzione e
utilizzo
 Questo comporta notevoli implicazioni nella modo di gestire il ciclo di vita del
software
 Si può passare direttamente dalla specifica dei requisiti (che possono
rappresentare direttamente i servizi da erogare), alla loro progettazione in
forma di servizi
 Inoltre è altamente facilitato l’utilizzo di altri servizi esterni


Evoluzione naturale

 Nel corso del tempo, il livello di astrazione delle specifiche funzionali, è
divenuta progressivamente sempre più alta
 Il modello si è evoluto, prima dalla forma di moduli, quindi agli oggetti, poi ai
componenti, e ora ai servizi
 Tuttavia, il concetto di SOA, anche se applicato naturalmente alle architetture,
può facilmente travalicare questo limite
 Non è possibile limitare la discussione alla sola architettura, perché il concetto
può essere applicato anche ad ambiti diversi
 Un esempio possono essere il Business Design (disegno della logica di
business) e il Delivery Process (fase di rilascio)


Paradigmi e parallelismi

 La nomenclatura più corretta dovrebbe essere SO (Service-
Orientation), applicabile a diversi contesti
 Ci sono anche diversi paralleli con il paradigma OO (Object-
Oriented) e con quello CBD (Component-Based Development)
 Alla stregua degli oggetti e dei componenti, i servizi sono i
mattoni naturali per lo sviluppo delle funzionalità
 E allo stesso modo ci consentono di realizzare queste
funzionalità in maniera tale da consentirne l’uso in un modo a
noi familiare


Paradigmi e parallelismi

 Inoltre, sempre come gli oggetti e i componenti, i servizi ci
consentono di:
 combinare le informazioni e i comportamenti
 proteggere le funzionalità interne dalle intrusioni
 presentarsi con interfacce semplici per l’integrazione
 Laddove gli oggetti usano astrazioni sui dati, i servizi sono in
grado di fornire una similitudine con l’utilizzo di un contesto
 Mentre oggetti e componenti si organizzano con delle classi
con comportamenti ereditabili, i servizi possono organizzarsi
autonomamente in forma gerarchica o collaborativa


Analogie con i Web Services

 Spesso le aziende tendono a progettare le architetture basate
sui servizi, basandole sull’uso dei web services
 Sebbene ci siano diversi similitudini, possiamo comunque
affermare da subito che i web services non sono strettamente
inerenti alle architetture basate su servizi
 I web services infatti, eseguono meramente delle funzionalità,
esponendole attraverso i protocolli web
 Bisogna stabilire delle linee guida per discernere la necessità
di utilizzo dei due paradigmi


Principi e definizioni

 Oramai il termine SOA è largamente utilizzato, addirittura
quasi inflazionato
 Tuttavia le varie definizioni che troviamo in giro generano un
po’ di confusione sul concetto esatto di questo termine
 L’autorevole W3C (World Wide Web Consortium) identifica il
termine SOA con la definizione:

Service-Oriented Architecture:

“A set of components which can be invoked, and
whose interface descriptions can be published and
discovered”



 Quella del W3C è la definizione più comunemente diffusa

 Il limite (se vogliamo) di questa definizione è che rappresenta

l’architettura in maniera esplicitamente tecnica

 Infatti il termine architettura non si presta soltanto al disegno

architetturale nel senso informatico del termine

 Abbiamo già detto infatti che gli ambiti applicativi possono

essere tanti e diversi



 Un’altra entità importante in questo ambito è la CBDI

 L’acronimo CBDI sta per Component-Based Development

and Integration

 Si tratta di un organismo autonomo che si occupa

principalmente dello studio e nella definizione delle best

practices relative all’ambito SOA

 L’indirizzo del sito è: http://www.cbdiforum.com/



 Il CBDI ritiene la definizione del W3C estremamente riduttiva,

e quindi utilizza per SOA una definizione “più ampia”

 E’ utile a questo scopo effettuare dei paragoni tra la

definizione del W3C e quella del CBDI

 Queste differenze ci aiuteranno a capire meglio i limiti e gli

ambiti in cui collocare il concetto di servizio


Definizioni – “Service”

 Service
 Un componente capace di eseguire un task. Un servizio WSDL:
una collezione di endpoints (W3C)

 Un insieme di funzionalità descritte con un WSDL (CBDI)

 Service Definition
 Un sistema utilizzato dal consumer del servizio per accordarsi
(implicitamente or esplicitamente) sulle modalità di erogazione
del servizio, sulle sue regolamentazioni, sulle funzioni offerte e
quant’altro (CBDI)

 A Service Fulfillment (adempimento del servizio)

 Una istanza di esecuzione del servizio e delle sue funzionalità


Definizioni – “Web Service”

 Web Service
 (W3C)
• Un sistema software capace di supportare l’interazione tra sistemi
• L’interazione avviene normalmente nell’ambito di una rete
• E’ fornito di una interfaccia descrittiva delle funzionalità esposte
• Tale interfaccia viene normalmente fornita in un formato tale da
essere elaborato dai sistemi (WSDL)
• Consente l’utilizzo delle funzionalità che espone, attraverso l’uso di
messaggi SOAP, l’impiego di serializzazioni XML ed altri meccanismi
standard dell’ambito web
 (CBDI)
• Una interfaccia programmatica verso una funzionalità conforme ai
protocolli WS-*


Definizioni – “Web Service”

 Web Service
 La definizione dei Web Services data da CBDI rispetto a
quella del W3C indica l’intenzione di non considerare i web
service come componenti
 Inoltre CBDI suggerisce l’utilizzo di tipo, definizione e
adempimento del servizio come parti separate
 Ma è nella definizione di SOA che CBDI realmente si
distingue dal W3C


Definizioni – “Service-Oriented Architecture”

 Service-Oriented Architecture
 Abbiamo già detto che la definizione del W3C ritiene che
l’architettura SOA possa essere intesa come:
“un insieme di componenti che possono essere invocati, e che espongono
una interfaccia descrittiva dei servizi offerti, che può essere pubblicata e
recuperata”

 CBDI ritiene non corretta questa definizione in due punti:
 i componenti (ovvero le loro implementazioni) spesso non
rappresentano un insieme
 la definizione data considera sempre e solo componenti
sviluppati e rilasciati, piuttosto che considerare la scienza,
l’arte o la pratica di disegnare e implementare una
architettura


 CBDI definisce SOA come:

“The policies, practices, frameworks that enable
application functionality to be provided and consumed as
sets of services published at a granularity relevant to
the service consumer. Services can be invoked, published
and discovered, and are abstracted away from the
implementation using a single, standards-based form of
interface”



 Service-Oriented Architecture (definizioni a confronto)

(W3C)

“A set of components which can be invoked, and whose
interface descriptions can be published and discovered”

(CBDI)

“The policies, practices, frameworks that enable
application functionality to be provided and consumed as
sets of services published at a granularity relevant to
the service consumer. Services can be invoked, published
and discovered, and are abstracted away from the
implementation using a single, standards-based form of
interface”



 I punti cardine della definizione del CBDI stabiliscono che
l’architettura SOA:
 è il risultato dell’impiego di particolari politiche, pratiche e
frameworks che consentono il rilascio di servizi in maniera
rispondente a specifiche regole
 si distingue sulla granularità del servizio, sulla sua
indipendenza dalla modalità di implementazione, e del suo
rispetto e coerenza per gli standard
 viene intravista la possibilità, in determinati casi, di esporre i
servizi anche in forma di web services


Le basi di SOA

 Molto spesso, e in maniera errata, si confonde il concetto di

“Service Orientation” con la realizzazione di un web service

 E’ chiaro tuttavia, che la realizzazione di un web service è il

primo passo verso il concetto di software distribuito in forma

di servizio

 Quello che è importante riconoscere è che i servizi Web sono

parte di un quadro più ampio, rappresentato da SOA


SOA attraverso i Web Services

 L’interfaccia esposta da un web service fornisce alcune

importanti caratteristiche architettoniche e di prestazioni, e in

particolare:

 l'indipendenza dalla piattaforma

 lasco accoppiamento

 capacità di autodescrizione

 capacità di essere “scoperti”

 Questo consente di realizzare una importante separazione

formale tra il provider dei servizi e i consumatori


SOA vs Web Services

 L’importante nel confronto tra Service e Web Service è

comprendere gli aspetti più rilevanti:

 il concetto fondamentale è (e resta) il Service

 i Web Services rappresentano un insieme di protocolli

tramite i quali i Service possono essere pubblicati, scoperti

e usati in una forma standard e tramite una tecnologia

neutrale


SOA vs Web Services

 In realtà i Web Services non sono una componente

obbligatoria per SOA, sebbene i Services vengano sempre più

spesso realizzati tramite essi

 SOA è potenzialmente molto più ampio nel suo campo di

applicazione

 Inoltre con SOA diventa più semplice la definizione di

attuazione del servizio, e della sua qualità dal punto di vista

del fornitore (provider) e del consumatore (consumer)


Tecnologia e Disciplina

 È possibile tracciare un parallelo con CDB (Component-Based

Development) e le tecnologie di sviluppo per componenti

 Tecnologie come COM con lo sviluppo di componenti, o la

modellazioni UML con la rappresentazione dei packages, si

preoccupano dei componenti dal punto di vista “tecnologico”

 CBD, o ancora meglio CBSE (Component-Based Software

Engineering), rappresentano invece la “disciplina” con cui si

assicura che si stiano costruendo i componenti in maniera

coerente e allineata con il business


Un confronto tra servizi

 Facciamo un confronto molto semplice ed allo stesso tempo

esplicativo delle differenze tra i vari servizi

 Prendiamo come termini di paragone due servizi disponibili, per

esempio, sotto forma di web services:

 il primo che offra funzionalità di business, e metodi per la

consultazione di dati relativi alle attività della compagnia

 il secondo che offra un accesso di tipo CRUD (Create, Read,

Update, Delete) alla propria base dati



 Nel primo caso le funzionalità sono correttamente implementate

(tramite il web service) in maniera tale da essere fruite da

diversi tipologie di consumer, quindi secondo il paradigma SOA

 Nel secondo caso, l’accesso alle entità presenti sul database

necessita di una conoscenza della struttura stessa della base

dati, oltre che la padronanza dello scenario

 Il secondo servizio poteva essere normalmente creato con un

“semplice” web service che non si basasse su SOA, poichè un

impiego di questo tipo non rispecchia il concetto di SOA



 Da un confronto di questo genere, fu dedotta dal CBDI una

considerazione che ancora oggi viene ritenuta come una delle

migliori definizioni di SOA:

“SOA is not just an architecture of services seen from a

technology perspective, but the policies, practices, and

frameworks by which we ensure the right services are

provided and consumed”

Principi della Service Orientation

 Sorge il problema di stabilire la capacità di aderenza al modello

“Service Orientation”

 Quello di cui abbiamo bisogno insomma, è un insieme di linee

guida che ci consenta di stabilire come e quando un servizio è

più o meno aderente al modello SOA

 Si manifesta la necessità di un insieme di Principi della Service

Orientation che ci permettano di impostare criteri, parametri e

quant’altro



 Possiamo subito distinguere due insiemi di principi:

 Interface related principles (Principi di relazione tra le

interfacce) che stabiliscono la funzione di neutralità della

tecnologia, orientata alla standardizzazione e alla sua

usabilità in termini di fruizione del servizio

 Design principles (Principi di disegno) che riguardano la

qualità dei services, la loro aderenza ai requisiti, e la loro

usabilità, intrinseca adattabilità e semplicità d’uso



 Il secondo insieme (Principi di disegno) dovrebbe essere idoneo

per l’utilizzo in aziende che hanno architetture SOA già mature

 Tuttavia, è proprio nelle aziende grandi che si riesce

difficilmente a giustificare questo livello di disciplina

 Infatti, sembra essere più giustificabile progettare e sviluppare

componenti per le parti fondamentali del sistema, che siano

riusabili e durevoli nel tempo, piuttosto che sostenere qualcosa

che viene percepito come un costo immediato anche se

prospetta un ritorno di investimento (ROI) a breve termine



 Tuttavia, quando questi principi vengono applicati nella

progettazione e sviluppo di servizi, risulta:

 una maggiore consapevolezza dei requisiti

 una maggiore aderenza a questi stessi requisiti

 una maggiore comprensione delle problematiche relative a

costi e vantaggi dei sistemi e sottosistemi

 una maggiore competenza, da parte delle divisioni IT

dell’azienda, sulle parti del sistema progettate per funzioni

collaterali ai requisiti


Principi di disegno applicati ai Web Services

 Neutralità della tecnologia

 indipendenza dalla piattaforma

 Standardizzazione

 protocolli standard o basati su standard

 Fruibilità

 capacità di scoperta e utilizzo


Principi di disegno applicati ai Servizi

 Aggiunge a quanto visto per i web services:
 Riusabilità
• riutilizzo del servizio
 Astrazione
• il servizio si astrae dalla implementazione
 Pubblicazione
• informazioni precise e dettagliate sull’uso ma non sulla
implementazione
 Formalizzazione
• Contratto formale tra il provider e il consumer
 Pertinenza
• Funzionalità presentate ad una granularità comunque
riconoscibile dagli utenti come un servizio significativo

Benefici derivanti dall’applicazione dei principi della SO

 Applicando i principi della Service Orientation, si possono
ottenere diversi vantaggi:
 Effettiva sincronia tra le prospettive di business e di
implementazione
 Un servizio ben formato costituisce una importante unità
di gestione che si relazioni al business specificato
 Un servizio che si astrae dalla sua implementazione è
un servizio in cui sia possibile considerare diverse opzioni
per il suo modello di distribuzione e di collaborazione



 Effettiva sincronia tra le prospettive di business e di
implementazione:
 Per diversi anni, le persone che si occupano del business
non hanno realmente capito le loro architetture IT
 Con un servizio ben disegnato si può migliorare
notevolmente la comunicazione con gli strati di business
 Si può andare finalmente considerare la convergenza di
business e IT



 Un servizio ben formato costituisce una importante unità di
gestione che si relazioni al business specificato:
 Separare in maniera netta la prestazione del servizio offre
una buona base per la comprensione del ciclo di vita
 Vengono ben compresi anche le dinamiche dei costi del
servizio e di come vengono questi costi vengano utilizzati
nel business



 Un servizio che si astrae dalla sua implementazione è un
servizio in cui sia possibile considerare diverse opzioni per il suo
modello di distribuzione e di collaborazione:
 una delle speranze del modello SO è che sia facilmente
componibile anche tramite altri servizi, siano essi interni o
esterni al contesto dell’azienda che li realizza
 quindi l’idea che in futuro, in un contesto in cui siano
presenti architetture Service Oriented, questo possa
accadere, non è tanto improbabile


L’importanza del processo

 Uno degli aspetti principali di SOA è l’implementazione del
processo su due fronti
 Questo implica una creazione di due processi separati, uno per il
provider del servizio e uno per il consumer del servizio
 Il processo per il consumer del servizio non è normalmente
sviluppato dallo stesso team che sviluppa il servizio ed il suo
provider
 Questo avviene specialmente nell’ottica in cui il servizio venga
usato esternamente all’azienda che lo realizza, ovvero che il
servizio non sia realizzato solo per un uso interno



 Dal punto di vista del consumer, la cosa importante è che il

servizio sia organizzato tramite interfacce

 Il servizio deve fornire delle specifiche formali relative a

modalità di utilizzo, tramite dei veri e propri “contratti”

 Soprattutto non ci deve essere nessun tipo di dipendenza del

consumer verso la modalità di implementazione del provider

 Questo è un vantaggio per entrambi, infatti anche il provider

non ha idea del modo con cui il consumer utilizzerà il servizio



 Le uniche cose che interessa sapere al consumer sono:

 dove si trova il servizio

 cosa fa il servizio

 come si può usare il servizio

 In questo scenario, le interfacce sono l’unica modalità con cui il

consumer può ottenere alcune di queste informazioni


Le parti (o viste) di un processo

 Come abbiamo visto la suddivisione è importante e deve essere

netta, tra la parte del provider e quella del consumer

 Tuttavia le parti (o anche viste) che compongono il processo

sono tre:

 Implementazione e rilascio del servizio

 Fornitura del servizio

 Utilizzo del servizio


Implementazione e rilascio del servizio

 Questa parte del processo si divide a sua volta in:

 Implementazione

 Pubblicazione del servizio (normalmente sottoforma di web

service e spesso tramite tools automatici)


Fornitura del servizio

 La suddivisione della fornitura (nel senso della disponibilità) del

servizio in questo caso viene fatta in:

 Orientamento ala problematica

 Vista interna and esterna

 Gestione del livello di servizio


Fornitura del servizio

 Suddividendo il processo in queste tre parti (o viste) si vede che

la maggior parte degli aspetti collaborativi del processo sono

concentrati in questa parte

 E su questa parte esercita una notevole influenza la natura del

contratto, la quale definisce i requisiti del processo


Utilizzo del servizio

 In quest’ultima parte possiamo trovare le seguenti :

 Business guidato dai processi

 Consumer del servizio interni o esterni

 Servizi disponibili come librerie, e non come codice

 Approccio di sviluppo dichiarativo

 Valutazione del servizio ad opera di analisti di business

(spesso sottovalutato)


Pattern di collaborazione tra Provider e Consumer

 Ci sono diversi pattern di disegno che possono essere utilizzati

nella collaborazione tra il Provider e il Consumer

 Di questi un paio sono sicuramente più rilevanti:

 Negotiated - Consumer and Provider jointly agree service

Negoziato (Provider e Consumer sono in accordo)

 Instantiated - This is it. Take it or leave it

Istanziato (Nessun accordo, il Consumer usa così com’è il servizio)


Pattern “Negotiated”

Negotiated - Consumer and Provider jointly agree service.
Negoziato (Provider e Consumer sono in accordo)

 Quando la parte provider e quella consumer di un servizio
vengono sviluppati insieme, c’è la possibilità di convenire come
e in che modalità il servizio debba essere realizzato
 L’occasione si verifica quando più aziende convergono verso la
necessità (o l’uso) di servizi da sviluppare ex-novo
 Altri casi sono i cosiddetti “early adopters” , oppure l’uso interno
ad una sola azienda o, ancora, in caso di definizione di nuovi
standard


Pattern “Instatiated”

Instantiated - This is it. Take it or leave it.
Istanziato (Nessun accordo, il Consumer usa così com’è il servizio)

 In questa situazione il servizio spesso già esiste, quindi si decide
semplicemente di usarlo o meno
 Analogo discorso quando bisogna integrare sistemi già esistenti
 Un altro caso è quello di una azienda dominante sul mercato che
semplicemente decide come sviluppare il servizio
 Possono esserci ulteriori casi di azienda dominante:
 Provider led (Use this service or we can't do business)

 Consumer led (Provide this service or we can't do business)


Prospettive architetturali

 Le parti (o viste) di processo appena analizzate rappresentano

la base necessaria per definire le tipologie di architettura più

adatte a definire gli interessi, le responsabilità e l’integrità

 Per SOA esistono tre importanti prospettive architetturali:

 Application Architecture

 Service Architecture

 Component Architecture


Application Architecture

 In questa architettura, il processo è visto in prospettiva dal solo

punto di vista business che si intende realizzare

 L’archiettura consuma uno o più servizi forniti da providers

interni e/o esterni e li integra insieme allo scopo di realizzare il

processo di business desiderato


Service Architecture

 Questa architettura rappresenta un “ponte” tra

l’implementazione del servizio e il suo utilizzo (consumo)

 Viene creata una vista logica dei servizi disponibili per l’uso,

invocabili attraverso delle interfacce comuni


Component Architecture

 Questa architettura descrive i vari ambienti e/o configurazioni

che supportano l’applicazione implementata

 Vengono rappresentati anche gli oggetti che rappresentano la

funzionalità di business da realizzare, oltre che la sua logica di

implementazione


Vista di insieme delle tre prospettive architetturali


Angolazioni

 A loro volta, queste tre prospettive architetturali possono

essere filtrate in maniera diversa se viste con gli “occhi” del

provider o del consumer

 Cerchiamo di comprendere meglio queste ulteriori

“angolazioni”


Angolazioni

 Possiamo pensare, per esempio che:

 il consumer non ha alcun interesse nei dettagli

implementativi con cui è stato realizzato il servizio, ma solo

nel modo con cui questi può essere utilizzato, e a parità di

servizio, potrebbero esistere anche implementazioni diverse

 in modo simile, il provider non ha nessun interesse nella

tipologia di applicazioni che includeranno (e consumeranno)

il servizio esposto, che sono e restano sconosciute


Angolazioni

 Un’altra “angolazione” è la seguente:
 il consumer è focalizzato sull’architettura applicativa, sui
servizi usati, e non sui dettagli dei componenti
 per esempio, il consumer non è interessato a come sono
organizzati o implementati i componenti dell’architettura, o
il database utilizzato
 in modo simile, il provider è focalizzato sull’architettura dei
componenti, del servizio e non sull’architettura applicativa
 per esempio, il provider può avere interesse a sapere alcuni
particolari utili, ma non tutti i dettagli relativi al consumer


Approfondiamo la Service Architecture

 Al centro della SOA vi è la principale necessità di gestire i servizi

da erogare

 La corretta gestione di questi servizi costituisce la chiave di

volta per la comunicazione tra il provider ed il consumer

 Abbiamo bisogno di una architettura che non riduca i servizi allo

status di interfacce

 I servizi infatti hanno una identità propria, e possono essere

gestiti singolarmente o in gruppi


Business Service Bus (BSB)

 A questo scopo CBDI ha ideato il concetto di Business

Service Bus (BSB)

 Questi rappresenta una vista logica dei servizi disponibili e/o

impiegati in un particolare contesto di business (business

domain)

 Un esempio di business domain può essere per esempio la

gestione delle Risorse Umane, oppure la Logistica



 Principalmente il BSB ci aiuta a rispondere a domande come:

 Di quale servizio ho bisogno?

 Quali servizi ho a disposizione?

 Quali servizi possono interagire e operare insieme?

 Quali servizi sono disponibili in alternativa?

 Quali sono le dipendenze tra i servizi nelle varie versioni?



 Piuttosto che lasciare gli sviluppatori alla ricerca dei servizi da
utilizzare e quindi usarli in un contesto, possiamo considerare
l’uso del BSB
 il Business Service Bus può essere il miglior punto di partenza
per guidare gli sviluppatori ad un set di servizi coerente con il
loro dominio
 Lo scopo del BSB insomma, è quello di stabilire le specifiche, le
politiche ed altre regole, che vengono stabilite a livello di bus e
non a livello di ogni singolo servizio



 I servizi su un bus devono seguire gli stessi standard sulla
semantica, aderire alle stesse policy di sicurezza, e devono
puntare tutti allo stesso modello globale del dominio
 Questo facilita anche l’implementazione di un certo numero di
servizi infrastrutturali di uso comune, che possono essere
aggregati sullo stesso bus (per esempio, un servizio di
validazione del codice prodotto utilizzabile da tutti)
 In generale, ogni business domain sviluppa un proprio
vocabolario e un proprio modello di business sia per quanto
riguarda i processi che gli oggetti



 Una domanda che a questo punto sorge spontanea è: “ma qual

è lo scopo di pubblicare un servizio sul BSB?”

 In maniera semplicistica si pensa che questo sia solo un livello

di astrazione della tematica

 La risposta a questa domanda, anche se suscettibile di

interpretazione, assicurerà comunque che il servizio soddisfi i

criteri di business, sia orientato al consumer, sia stato

correttamente concordato, e sia significativo per il business



 Il punto chiave di tutta la questione è la possibilità di aderire ad
un processo di aggregazioe e collaborazione
 Questo processo dovrebbe esistere ed evolvere in maniera
separata dagli altri componenti
 In questo modo, aumenta il livello di flessibilità che consenta ai
servizi esposti di essere modificati senza toccare le componenti
sottostanti
 In linea di principio, i livelli di astrazione devono essere
sviluppati in modo che i servizi siano sempre ad un livello
pertinente e opportuno per il consumer


Livelli di astrazione

 I livelli di astrazione potrebbero essere uno o tutti tra i
seguenti:
 Servizi di Business
 Servizi orientati ai Consumer
 Concordati tra Provider e Consumer
 Composizione di servizi a basso livello in qualcosa di
significativo per il Business
 Servizi generici (a granatura grossa)
 Adattabilità all’utilizzo dall’esterno
 Conforme alla progettazione pre-esistente


I livelli di astrazione


SOA Platform

 Il punto cardine della separazione è la definizione di una
piattaforma virtuale che sia egualmente rilevante per un certo
numero di piattaforme reali
 L’obiettivo di questa piattaforma virtuale è quello di consentire
una separazione dei servizi dalla loro implementazione, più
completa possibile
 Più netta sarà questa separazione, e maggiore sarà la possibilità
di consentire a componenti costruiti su diverse piattaforme di
offrire i loro servizi senza avere dipendenze legate alla loro
implementazione


SOA Platform

 La piattaforma virtuale SOA rappresenta uno schema che

riguarda lo sviluppo finalizzato alla realizzazione di queste

piattaforme

 Si tratta di linee guida, di orientamenti, allo scopo di assicurare

che i servizi pubblicati siano conformi allo stesso insieme di

principi strutturali

 Questi principi sono rilevanti sia per la gestione di questi servizi,

che per la capacità di comprensione da parte del consumer


SOA Platform

 Quando un certo numero di applicazioni differenti sono in grado

di condividere una stessa struttura, e le relazioni tra le parti di

questa struttura sono le stesse, allora abbiamo quello che viene

definito come uno “stile architetturale” condiviso

 Questo stile può essere implementato in vari modi: potrebbe

riguardare un insieme di policies, un framework di oggetti, o

una pratica comunemente adottata


Enterprise SOA (ESOA)

 La migliore implementazione per una architettura SOA resta

l’architettura basata su componenti (non intesi dal punto di vista

tecnologico)

 Questa tipologia di architettura, vista come insieme di

componenti relativi a processi ed entità, può risultare molto

stabile e allo stesso tempo flessibile

 Queste caratteristiche sono dovute alla corrispondenza univoca

tra le entità di business e le implementazioni dei componenti


Enterprise SOA (ESOA)

 Enterprise SOA (ESOA) considera queste due parti, Web services

e CBD (ovvero CBSE), e le unisce insieme

 Questo risultato è inteso come una architettura SOA che

aderisce contemporaneamente al modello del web service,

disponibile esternamente, e al modello del core business,

disponibile invece solo internamente

 Tuttavia l’approfondimento della ESOA è materia molto

complessa, e meriterebbe una ampia trattazione separata


Riepilogo

 L’obiettivo di SOA è realizzare una maglia di servizi collaborativi,

pubblicati e disponibili per l’invocazione su un Service Bus

 L’adozione del modello SOA è essenziale per realizzare appieno

l’agilità del business e la flessibilità dei sistemi IT, tanto

promessa dal modello dei web services

 Questi benefici non devono essere visti dal punto di vista

tecnologico, ma da una prospettiva di creazione di un ambiente

orientato ai servizi (Service Oriented Environment)


Riepilogo

 Riassumiamo gli aspetti principali:

 Il servizio è il concetto fondamentale, i web services sono

solo un insieme di protocolli con cui un servizio può essere

pubblicato, ritrovato e utilizzato

 SOA non è solo una architettura orientata ai servizi intesa

da un punto di vista tecnologico, bensì un insieme di

politiche, pratiche e librerie che consentono ai servizi di

essere correttamente fruiti


Riepilogo

 Ulteriori aspetti:

 Con SOA è importante implementare i processi in maniera

tale da assicurare che questi sia diviso in due parti distinte:

il processo per il provider e il processo per il consumer

 Piuttosto che lasciare gli sviluppatori alla ricerca dei servizi

da utilizzare in un contesto, possiamo considerare l’uso del

Business Service Bus come punto di partenza per guidare gli

sviluppatori ad un set di servizi coerente con il loro dominio


UN PUNTO DI VISTA PIÙ TECNICO

Comprendere l’architettura SOA

Applicazioni moderne

 Le applicazioni che oggi sviluppiamo sono sempre più pensate per collaborare
con altri sistemi operativi e altre applicazioni
 Usiamo sempre più spesso la connessione internet, o in alcuni casi delle
connessioni dedicate, assimilabili a quelle internet
 Le tipiche attività di lavoro possono riguardare diversi dipartimenti di una
azienda o diverse aziende al fine di realizzare un prodotto oppure di
erogare un servizio all’esterno
 Questo ovviamente deve considerare le varie tipologie di piattaforme e
sistemi operativi (oltre che delle loro versioni)

Introduzione all’architettura 76

Applicazioni moderne

Fornitore A
Applicazione 1
Azienda di Produzione
Applicazione 2
…
Applicazione N
Applicazione 1

App Server
INTERNET Applicazione 2
…
Applicazione K

Fornitore 2
Applicazione 1
Applicazione 2
…
Applicazione M


Infrastrutture di rete miste

UFFICIO
ACQUISTI
ERP

GESTIONE MARKETING
ORDINI

CRM

SISTEMA GESTIONE DEL
FINANZIARIO
SOFTWARE

Problema: integrare diverse piattaforme e diversi S.O.


Limiti dei componenti

 I componenti sono porzioni di codice riusabile, scritti tramite una tecnologia

particolare (CORBA, COM/COM+, .NET Remoting, ecc.)

 Dei componenti, normalmente, è necessario conoscere bene sia l’architettura

interna che il funzionamento

 Vengono installati normalmente una volta sola sul lato della distribuzione, e a

volte necessitano dell’installazione anche sul client che li utilizza


Limiti dei componenti

 Lavorano con dati non di loro competenza (BIZDAL)

 In caso di aggiornamento devono essere reinstallati ovunque

 Inoltre i componenti sono molto legati alla stessa tecnologia con la quale sono

stati sviluppati

 Nella quasi totalità dei casi non è possibile far dialogare direttamente

componenti sviluppati con tecnologie differenti

 Nella maggior parte dei casi non sono disponibili per tutte le piattaforme e

sistemi operativi


Vantaggi dei servizi

 Sono utilizzabili dai client senza necessità di deploy
 In caso di aggiornamento non richiedono operazioni sui client
 Non condividono oggetti o strutture dati
 Gestiscono i dati in maniera trasparente per il client
 Possiamo ignorare sia la loro architettura che il loro funzionamento interno
 Supportano il versioning e l’esecuzione parallela di versioni differenti
 Usano una infrastruttura tecnologica supportata da tutte le piattaforme


Le applicazioni moderne

 L’approccio di SOA deriva da una evoluzione delle applicazioni

 Le applicazioni “moderne” richiedono:

 Integrazione tra piattaforme diverse

 Aggregazione di dati differenti (trasparenza dei dati)

 Interazione tra strutture dati eterogenee

 Utilizzare internet per le comunicazioni

 Capacità di adattamento al cambiamento dei requisiti

 Apertura verso altre funzionalità disponibili all’esterno


Service Oriented Architecture

 I servizi sono porzioni indipendenti di software che espongono funzionalità

(non metodi!)

 Sono indipendenti dal protocollo, dalla piattaforma e dall’architettura del

contesto in cui vengono collocati

 Per concetto e per necessità devono essere fortemente disaccoppiati e

astratti dalla logica di funzionamento interna


Principi base di SOA

 In caso di evoluzione del servizio non deve essere richiesto agli utilizzatori
nessun aggiornamento (ancora disaccoppiamento)
 I tipi esposti devono astrarre dalla struttura dati sottostante
 Ancora, i tipi esposti devono essere estendibili (per esempio per supportare il
versioning)
 Non deve esistere alcun “legame forte” tra i tipi di dati usati dai servizi e quelli
usati dai loro utilizzatori
 Non devono esistere DLL o componenti comuni tra i servizi e i loro utilizzatori


Ragionare in termini di servizi

Da A
Funzioni Processi / Operazioni
Processi di sviluppo lunghi Ciclo di vita incrementale
Blocchi monolitici Orchestration
Pensato per durare nel tempo Pensato per cambiare
Forte accoppiamento Forte disaccoppiamento
Object Oriented Message Oriented
Implementazioni note Astratto


SOA Tenets

 Possiamo cercare di approfondire il concetto di Service

Orientation anche attraverso le 4 dottrine o postulati (tenets)

 Questi postulati sono stati elaborati da due architetti di

Microsoft, “Don Box” e “Pat Helland” verso il 2004

 Su questi postulati sono state aperte, sin da subito, accese

discussioni sulla validità o meno delle loro enunciazioni

 Alcuni sostengono che siano validi, altri ne sostengono la

validità parziale o solo di alcuni di questi quattro postulati


SOA Tenets

 I quattro postulati in questione sono:

1. Boundaries are explicit

2. Services are autonomous

3. Services share schema and contract, not class

4. Compatibility is based upon policy


SOA Tenets

 Boundaries are explicit

 “I confini sono espliciti”, ovvero la comunicazione da e verso

un servizio deve essere accessibili all’esterno, ma il confine

tra l’esterno e l’interno deve essere ben delineato

 Questo vuol dire impostare una separazione forte tra quello

che sta “dietro le quinte” (parte tecnica e di linguaggio) e la

parte disponibile a chi fruisce del servizio dall’esterno


SOA Tenets

 Services are autonomous

 “I servizi sono autonomi”, ovvero devono poter funzionare

presi singolarmente

 Ogni servizio deve racchiudere quindi una funzionalità finita

 Il servizio, fruito dall’esterno, deve poter vivere senza

necessità di coinvolgimenti di terzi (ad esempio altri servizi)


SOA Tenets

 Services share schema and contract, not class

 “I servizi condividono gli schema e i contratti ma non le

classi”, ovvero un servizio deve essere fruibile senza dovere

accedere al codice o a librerie lato server (ad esempio DLL)

del servizio stesso

 Il servizio deve condividere solo gli schema e i contratti,

ovvero le informazioni accessibili a chiunque per l’utilizzo

corretto del servizio

SOA Tenets

 Compatibility is based upon policy

 “La compatibilità è basata su delle regole”, ovvero la

definizione delle caratteristiche di compatibilità vanno

dettagliati tramite dei linguaggi o dei formati di

interoperabilità standardizzati

 Il formato di comunicazione e di presentazione deve essere

noto (per esempio le WS-* policy)


Message Oriented Design

 Costruiamo i servizi partendo dalla definizione dei messaggi

(ovvero cosa i servizi devono “dirsi”)

 Per farlo utilizziamo gli XSD

 Gli XSD possono definiti tutti i tipi a livello aziendale

 Si può creare addirittura un database aziendale (linguaggio)

 Descriviamo i servizi in base ai contratti (sequenze di messaggi)

 Per farlo utilizziamo i WSDL

 Implementiamo i messaggi e i contratti in maniera con una

qualsiasi piattaforma o linguaggio (che sappia farlo)


Definizione dei messaggi

 I messaggi rappresentano la comunicazione del servizio
 Si possono stabilire dei veri e propri standard aziendali:
 Sui nomi delle entità coinvolte
 Sui namespace (per esempio creando una directory dei
namespace a livello aziendale)
 Bisogna definire i tipi tramite XSD (noti e raggiungibili da tutti)
 Non mettere nei messaggi le informazioni infrastrutturali quali:
 Informazioni sul tipo di autenticazione
 Identificativi (sessione, transazione, ecc.)
 Altre informazioni sensibili
 Tenere sempre presente il versioning

Definizione dei contratti

 I contratti rappresentano le funzionalità del servizio
 Definiscono le operazioni sempre basandosi su sequenze di
messaggi
 Evitare di crearli in automatico, senza il nostro controllo:
 SI  Generare gli asmx dai WSDL
 NO  Generare i WSDL dagli asmx
 Cercare di scomporre le operazioni in diversi WSDL, per poterli
facilmente riutilizzare
 L’approccio di SOA è quello di cambiare le WSDL e non di
cambiare i prototipi delle funzioni


Concetto di idempotenza

 A volte può accadere che dei messaggi richiedano di essere

spediti più di una volta:

 perché non sono arrivati a destinazione

 perché non viene ricevuta la conferma di ricezione

 per altri motivi (es. replay attack da parte di un hacker)

 A parità di input, il sistema deve avere le stesse reazioni e

produrre gli stessi output:

 per evitare problemi in caso di replay dei messaggi

 per garantire univocità e stabilità di comportamento


Gestione dei dati

 All’interno del servizio:
 devono essere specifici per l’applicazione
 possono essere più complessi di come si presentano
all’esterno
 sono fortemente legati all’applicazione
 All’esterno del servizio:
 sono rappresentati dai messaggi (XML)
 vengono descritti da schema (XSD)
 devono essere estendibili e aggiornabili
 sono noti a tutti gli attori


I dati dentro e fuori dal servizio

MSG

DATA
MSG SQL

OUTSIDE INSIDE


Come esporre i dati

 In architettura SOA i nostri servizi non possono essere degli

intermediari verso il database

 A questo proposito, i web services che svolgono funzioni “CRUD”

(Create-Read-Update-Delete) non sono adatti allo scopo di SOA

 Non sono espressamente vietati da SOA, ma semplicemente non

sono SOA


Controllo sui dati e concorrenza

 In architettura SOA i nostri servizi non possono mai fidarsi dei

consumer

 Conviene sempre controllare tutti gli input

 E’ necessario utilizzare una logica di business solo per il

controllo

 Non bisogna fidarsi dei consumer perché i servizi devono essere

autonomi (come suggeriscono i SOA Tenets)


Ruolo della logica di business

 Ci deve sempre essere in ogni servizio una logica adeguata

 I servizi rappresentano solo la parte di comunicazione

 Questi sono dei wrapper sugli oggetti di business:

 L’implementazione va negli oggetti e non nei servizi

 Non va mai dimenticato l’aspetto della sicurezza

 Tale aspetto va introdotto direttamente nella logica di business


Quadro complessivo

XML

DATA
SQL

XML

XML INFOSET BIZ SQL
LOGIC DATA

Dialoghi e sequenze

 Alcuni dialoghi sono basati sulla sequenza di messaggi

 Per gestire i messaggi è consigliabile:

 HTTP: evitare di usare i cookie

 Applicativi: evitare parametri delle operazioni

 Infrastruttura: usare token di sessione nei SOAP header

(1) Inserisci Ordine
CONSUMER (2) OK – Ordine Inseribile PROVIDER
(3) Conferma Inserimento


Transazioni

 I servizi devono essere autonomi, ma:
 le transazioni vincolano le operazioni
 allo stesso tempo senza transazioni in molti casi non
potremmo utilizzare i servizi
 Laddove possibile isoliamo i servizi e rendiamoli implicitamente
transazionali
 Se non è possibile isolare la transazione all’interno del servizio,
abbiamo bisogno di transazioni distribuite “long-running” , e
WS-AtomicTransaction lavora in questo senso
 Affidare la transazionalità ad “accordi” tra i servizi non ha
senso, perché li renderebbe meno autonomi

Sicurezza

 Nella progettazione dello strato di sicurezza bisogna tenere

presente:

 Integrità: hashing, digital signature

 Riservatezza: XML encryption

 Autenticità del mittente/destinatario: token (username e

password, kerberos, ecc.)

 Va sempre realizzata a livello infrastrutturale (SOAP header),

tranne rari casi (per esempio, in caso di encryption)


WS-Interoperability

http://ws-i.org/
Web Service Interoperability Organization

 WS-I è un ente che si prefigge i seguenti obiettivi:

 ottenere l’interoperabilità tra i web service, tra

piattaforme, applicazioni e linguaggi differenti

 promuovere l’utilizzo dei web service

 facilitare e quindi rendere più rapida la produzione di

web service


WS-I Basic Profile 1.1

 Stabilisce le regole base per la interoperabilità tra servizi e
piattaforme differenti
 Dal 2004 sostituisce ed evolve la precedente versione 1.0
 E’ costituito da un insieme di assertion in merito a:
 Messaging (SOAP, HTTP, …)
 Service Description (WSDL, SOAP Binding XSD, XML,
Namespaces)
 Service publication and discovery (UDDI)
 Security (HTTPS, BP Security 1.0 aka WS-Security)
 WS-I mette a disposizione dei tools per la verifica delle
assertions (per C#.NET e Java principalmente)

Web Services Architecture (WSA)

Applications & Infrastructure

Connected
Applications Management Business Process ...

Foundation

Security Reliability Transactions
Metadata
Messaging

XML

Transport

HTTP TCP SMTP ...


Messaging

 Una serie di specifiche e regole nella gestione dei messaggi
(con SOAP 1.1/1.2)
 WS-Inspection
 per documentare e descrivere i servizi offerti da un
determinato sito
 WS-Addressing
 per gestire gli indirizzamenti/instradamenti dei messaggi
SOAP (es. dei “router” costituiti da messaggi SOAP)
 per definire le politiche di load-balancing


Security

 WS-Security
 autenticazione
 integrità
 riservatezza
 WS-SecurityPolicy
 per descrivere le politiche di sicurezza di WS-Security
 WS-Trust (tramite trust server)
 per gestire relazioni di fiducia tra servizi
 WS-SecureConversation (senza trust server)
 per stabilire sessioni sicure di comunicazione temporanee


Reliable Messaging e Transactions

 WS-ReliableMessaging

 Garanzia di consegna tra i nodi, bidirezionale

 WS-TransmissionControl

 per gestire e controllare lo scambio di messaggi

 WS-AtomicTransaction

 per fornire funzionalità di transazionalità ai servizi

 WS-Coordination

 per coordinare le attività distribuite su diversi servizi,

anche (e soprattutto) in caso di transazioni


Comunicazione

 WS-MetadataExchange

 per scambiarsi informazioni sui messaggi (XSD, WSDL,

WS-Policy, ecc.)

 WS-Eventing

 per la gestione delle notifiche (basate su sottoscrizione)

 Si può implementare un sistema di “Grid Computing”, per:

 scalare le applicazioni su più server e/o servizi

 distribuire i carichi di lavoro su più servizi

 gestire le notifiche tramite WS-Eventing


Comprendere l'architettura service oriented

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Semelhante a Comprendere l'architettura service oriented

Semelhante a Comprendere l'architettura service oriented (20)

Comprendere l'architettura service oriented