Il documento fornisce un'introduzione all'architettura service-oriented (SOA), evidenziando come molti software possano essere progettati come servizi. Viene discusso il divario tra web services e SOA, sottolineando che i web services non sono essenziali per l'architettura SOA, che si estende a pratiche, politiche e framework per la fornitura di funzionalità applicative. Infine, si affrontano i principi della service orientation, che includono la neutralità della tecnologia e la qualità dei servizi, con l'obiettivo di migliorare la progettazione e l'implementazione.

1. Comprendere l’architettura
Service-Oriented

2. UNA PRIMA INTRODUZIONE TEORICA
Comprendere l’architettura SOA

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

4. 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
Comprendere l’architettura SOA 4

5. 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
Comprendere l’architettura SOA 5

6. 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)
Comprendere l’architettura SOA 6

7. 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
Comprendere l’architettura SOA 7

8. 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
Comprendere l’architettura SOA 8

9. 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
Comprendere l’architettura SOA 9

10. 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”
Comprendere l’architettura SOA 10

11. Principi e definizioni
 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
Comprendere l’architettura SOA 11

12. Principi e definizioni
 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/
Comprendere l’architettura SOA 12

13. Principi e definizioni
 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
Comprendere l’architettura SOA 13

14. 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à
Comprendere l’architettura SOA 14

15. 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-*
Comprendere l’architettura SOA 15

16. 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
Comprendere l’architettura SOA 16

17. 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
Comprendere l’architettura SOA 17

18. Definizioni – “Service-Oriented Architecture”
 Service-Oriented Architecture
 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”
Comprendere l’architettura SOA 18

19. Definizioni – “Service-Oriented Architecture”
 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”
Comprendere l’architettura SOA 19

20. Definizioni – “Service-Oriented Architecture”
 Service-Oriented Architecture
 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
Comprendere l’architettura SOA 20

21. 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
Comprendere l’architettura SOA 21

22. 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
Comprendere l’architettura SOA 22

23. 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
Comprendere l’architettura SOA 23

24. 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)
Comprendere l’architettura SOA 24

25. 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
Comprendere l’architettura SOA 25

26. 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
Comprendere l’architettura SOA 26

27. Un confronto tra servizi
 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
Comprendere l’architettura SOA 27

28. Un confronto tra servizi
 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”
Comprendere l’architettura SOA 28

29. 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
Comprendere l’architettura SOA 29

30. Principi della Service Orientation
 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
Comprendere l’architettura SOA 30

31. Principi della Service Orientation
 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
Comprendere l’architettura SOA 31

32. Principi della Service Orientation
 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
Comprendere l’architettura SOA 32

33. 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
Comprendere l’architettura SOA 33

34. 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
Comprendere l’architettura SOA 34

35. 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
Comprendere l’architettura SOA 35

36. Benefici derivanti dall’applicazione dei principi della SO
 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
Comprendere l’architettura SOA 36

37. Benefici derivanti dall’applicazione dei principi della SO
 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
Comprendere l’architettura SOA 37

38. Benefici derivanti dall’applicazione dei principi della SO
 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
Comprendere l’architettura SOA 38

39. 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
Comprendere l’architettura SOA 39

40. L’importanza del processo
 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
Comprendere l’architettura SOA 40

41. L’importanza del processo
 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
Comprendere l’architettura SOA 41

42. 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
Comprendere l’architettura SOA 42

43. 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)
Comprendere l’architettura SOA 43

44. 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
Comprendere l’architettura SOA 44

45. 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
Comprendere l’architettura SOA 45

46. 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)
Comprendere l’architettura SOA 46

47. 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)
Comprendere l’architettura SOA 47

48. 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
Comprendere l’architettura SOA 48

49. 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)
Comprendere l’architettura SOA 49

50. 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
Comprendere l’architettura SOA 50

51. 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
Comprendere l’architettura SOA 51

52. 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
Comprendere l’architettura SOA 52

53. 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
Comprendere l’architettura SOA 53

54. Vista di insieme delle tre prospettive architetturali
Comprendere l’architettura SOA 54

55. 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”
Comprendere l’architettura SOA 55

56. 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
Comprendere l’architettura SOA 56

57. 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
Comprendere l’architettura SOA 57

58. 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
Comprendere l’architettura SOA 58

59. 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
Comprendere l’architettura SOA 59

60. Business Service Bus (BSB)
 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?
Comprendere l’architettura SOA 60

61. Business Service Bus (BSB)
 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
Comprendere l’architettura SOA 61

62. Business Service Bus (BSB)
 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
Comprendere l’architettura SOA 62

63. Approfondiamo la Service Architecture
 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
Comprendere l’architettura SOA 63

64. Approfondiamo la Service Architecture
 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
Comprendere l’architettura SOA 64

65. 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
Comprendere l’architettura SOA 65

66. I livelli di astrazione
Comprendere l’architettura SOA 66

67. 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
Comprendere l’architettura SOA 67

68. 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
Comprendere l’architettura SOA 68

69. 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
Comprendere l’architettura SOA 69

70. 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
Comprendere l’architettura SOA 70

71. 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
Comprendere l’architettura SOA 71

72. 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)
Comprendere l’architettura SOA 72

73. 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
Comprendere l’architettura SOA 73

74. 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
Comprendere l’architettura SOA 74

75. UN PUNTO DI VISTA PIÙ TECNICO
Comprendere l’architettura SOA

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

77. 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
Introduzione all’architettura 77

78. Infrastrutture di rete miste
UFFICIO
ACQUISTI
ERP
GESTIONE MARKETING
ORDINI
CRM
SISTEMA GESTIONE DEL
FINANZIARIO
SOFTWARE
Problema: integrare diverse piattaforme e diversi S.O.
Introduzione all’architettura 78

79. 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
Introduzione all’architettura 79

80. 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
Introduzione all’architettura 80

81. 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
Introduzione all’architettura 81

82. 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
Introduzione all’architettura 82

83. 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
Introduzione all’architettura 83

84. 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
Introduzione all’architettura 84

85. 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
Introduzione all’architettura 85

86. 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
Introduzione all’architettura 86

87. 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
Introduzione all’architettura 87

88. 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
Introduzione all’architettura 88

89. 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)
Introduzione all’architettura 89

90. 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
Introduzione all’architettura 90

91. 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)
Introduzione all’architettura 91

92. 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)
Introduzione all’architettura 92

93. 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
Introduzione all’architettura 93

94. 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
Introduzione all’architettura 94

95. 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
Introduzione all’architettura 95

96. 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
Introduzione all’architettura 96

97. I dati dentro e fuori dal servizio
MSG
DATA
MSG SQL
OUTSIDE INSIDE
Introduzione all’architettura 97

98. 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
Introduzione all’architettura 98

99. 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)
Introduzione all’architettura 99

100. 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
Introduzione all’architettura 100

101. Quadro complessivo
XML
DATA
SQL
XML
XML INFOSET BIZ SQL
LOGIC DATA
Introduzione all’architettura 101

102. 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
Introduzione all’architettura 102

103. 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
Introduzione all’architettura 103

104. 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)
Introduzione all’architettura 104

105. 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
Introduzione all’architettura 105

106. 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)
Introduzione all’architettura 106

107. Web Services Architecture (WSA)
Applications & Infrastructure
Connected
Applications Management Business Process ...
Foundation
Security Reliability Transactions
Metadata
Messaging
XML
Transport
HTTP TCP SMTP ...
Introduzione all’architettura 107

108. 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
Introduzione all’architettura 108

109. 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
Introduzione all’architettura 109

110. 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
Introduzione all’architettura 110

111. 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
Introduzione all’architettura 111