Web Services 2 Ambiente che confina e sconfina con ambienti di

Web Services
2
Ambiente che confina e sconfina con ambienti di business ed enterprise.
Service Oriented Architecture (SOA)
Soffermandoci solo alla lettura della sigla ciò che si intende è una architettura basata sui servizi e
basta...il che non sarebbe niente di nuovo. In realtà dietro questa sigla ci sono un po' di cose, e si
sono addensate delle modalità diverse di rappresentare soprattutto le esigenza d'impresa; questa
sigla ha un senso perché collegata all'evoluzione dei web services.
Enterprise Application Integration (EAI)
Questa sigla è invece più legata all'esigenza d'impresa. Si fa riferimento a tutte quelle applicazioni
che costituiscono il cuore aziendale per le diverse aree di gestione dell'azienda, ad esempio,
prendendo in considerazione una qualsiasi azienda, vi è tutta la parte finanziaria, tutta la parte di
gestione delle risorse, tutte le risorse aziendali (anche quelle umane), tutta la parte di gestione ed
interazione con i clienti ecc ecc, tutte parti importanti per la vita dell'azienda che tendono ad essere
gestite in modo automatico da strumenti che si occupano di ciò. La sigla EAI dice pertanto:
ambienti che tendono a mettere insieme le applicazioni aziendali in un modo integrato.
In generale un EAI è qualcosa di molto ampio, e sempre più si vorrebbe che riuscisse a gestire in
modo informatizzato tutte le risorse aziendali: un esempio di tale integrazione sono ad esempio le
SAP.
<<Perché ci sono queste due sigle?>>
3
In realtà l'idea di un architettura a servizi (SOA) potrebbe essere un buon modo per strutturare anche
ambienti enterprise!
Di base, nell'architettura SOA ci sono dei servizi che sono assolutamente indipendenti dalla
piattaforma che li fornisce, quindi, in sostanza, sono servizi che non dipendono dal fatto che di sotto
si ha un'architettura COM, DCOM, .NET, CORBA, ecc; i servizi devono essere disponibili e
quest'architettura (SOA) dovrebbe rendere i servizi largamente indipendenti dall'architettura
sottostante.
C'è qualcuno che fornisce i servizi, ossia il Provider dei servizi, e c'è qualcuno che li richiede a
quest'ultimo, ossia il Requestor: in sostanza quindi, il modello è un modello cliente servitore anche
tradizionale in cui le cose vengono richieste in maniera sincrona bloccante...
Si noti però che è un modello a 3 parti, perché
implicito nell'architettura SOA c'è che i servizio
effettivamente siano richiedibili perché sia il provider
che il requestor abbiano un idea chiara dell'interfaccia
(il contratto è previsto in modo preciso!), però anche
che il contratto può essere reso noto dinamicamente,
pertanto la terza parte è rappresentata da delle agenzie
di discovery (Descovery Agencies), ossia dei sistemi di
nomi che sono capaci di catalogare i servizi, o meglio
238
Stefano Di Monte
le interfacce dei servizi, e quindi consentire a qualcuno di capire l'interfaccia di un servizio ed
anche chi è il provider di quel servizio.
Quindi è un modello c/s accresciuto con l'idea che si possa fare un descovery dinamico delle cose
che si possono chiedere: è quindi un modello NON statico, per via del fatto che il cliente potrebbe
non conoscere il servizio da chiedere e deve poter richiedere la modalità con cui si può richiedere
una certa interfaccia durante l'esecuzione: il modello è un evoluzione importante del c/s
incorporando la parte di nomi.
NOTA: Si noti che nei middleware è già presente una struttura del genere, ma qui stiamo parlando
però di un modello che si applica a tutto, ad esempio anche alle esigenze aziendali, cosa che spesso
non c'era, difatti prima i modelli erano statici dal punto di vista della conoscenza dinamica
dell'interazione.
IMPORTANTE: in generale i servizi sono singoli, il che vuol dire che il servitore non ha un
contratto per mantenere una sessione: i servizi devono essere completamente autocontenuti; difatti
non è possibile pensare di richiedere (o di avere il diritto di richiedere) ad un server dieci (10)
servizi e che lui si ricordi di me nelle diverse fasi: non c'è stato nell'interazione!
Ciò appena detto, suggerisce la grana dei servizi stessi: tali servizi sono a GRANA GROSSA molto
più grossa della grana di CORBA!
(un servizio non è l'incremento di un contatore, ma ad esempio, una gestione di un magazzino, in
generale, un servizio con molti parametri, con una forte strutturazione e con la capacità di chiedere
delle operazioni ed ottenere dei risultati a grana grossa in modo che l'architettura di supporto possa
essere anche lei consistente).
4
<<Cosa sono i servizi?>>
Sicuramente sono servizi correlati all'impresa, quindi servizi di business, ma in realtà possono
essere qualunque cosa: risorse, processi di servizio, applicazioni tutte correlate alla vita aziendale.
Sicuramente devono avere un interfaccia nota e che deve essere stata pubblicata da qualche parte, ed
in particolare, in quelle che prima sono state definite Descovery Agencies, perché dev'essere
disponibile a delle richieste dinamiche.
A livello di definizione architetturale, le architetture SOA prevedono che i servizi siano:
• riusabili
non possono essere servizi consumabili: in sostanza un servizio una volta definito come interfaccia
deve continuare ad essere fornito, ripetutamente, non può quindi essere consumato.
• formali
nel senso che il comportamento del servizio dev'essere non ambiguo: al di là dell'interfaccia ci
dev'essere un implementazione precisa di cosa il servizio faccia: il servizio dev'essere sviluppato
bene in modo tale che non ci siano ambiguità.
• a scarso accoppiamento
un servizio non può essere correlato ad un altro servizio, ossia non dev'essere possibile che un
interfaccia di un certo servizio richieda un altra interfaccia di un altro servizio: un servizio
dev'essere autocontenuto ed assolutamente interno a se stesso senza correlazione con altri servizi.
Reti di Calcolatori LM
239
• a black box
l'approccio di realizzazione è un approccio black box, nel senso che chi chiede il servizio non deve
assolutamente sapere quali sono le caratteristiche della soluzione scelta.
Queste appena dette sono le specifiche a livello di servizio.
5
In realtà si danno un po' di specifiche ulteriori che assomigliano a quelle precedenti ma che danno
un po' più di caratteristiche di realizzazione del progetto.
Pertanto i servizi sono:
• autonomi
Ogni singolo servizio dev'essere autonomo, il che riporta anche allo scarso accoppiamento; in
sostanza, quando determiniamo i servizi e le interfacce si devono determinare le interfacce che
garantiscono l'autonomia dei servizi. I servizi quindi non devono dipendere dal contesto e devono
essere capaci di autogestione.
• senza stato
i servizi non devono avere stato; perché non è possibile che il servitore mantenga lo stato fra tutte le
diverse invocazioni e quindi tutto lo stato dell'interazione è nell'invocazione del servizio. Il servitore
non è in nessun modo tenuto a mantenere una capacità di riconoscere un cliente perché ciò va
contro l'architettura SOA. Questo non vieta però, il poter realizzare architetture in cui vi è uno o più
servitori con stato ma che, quindi, non andrebbero nella direzione definita da SOA.
• soggetti a discovery
tutte le interfacce dei servizi che sono state determinate devono poter essere ottenute
dinamicamente: i servizi sono soggetti a discovery.
• componibili
i servizi si possono comporre: partendo da tre servizi, è possibile difatti organizzare l'invocazione
dei tre servizi facendo un nuovo servizio che quindi sarà a disposizione e da questo momento in poi
inserito in un agenzia di discovery (ad esempio si potrebbe riunire il servizio di autenticazione con
un servizio di magazzino per fornire un servizio di magazzino autenticato).
NOTA. Tutte queste definizioni sono da intendere dal punto di vista del cliente, tutto ciò che fa un
servizio al suo interno è assolutamente indipendente dal modello.
6
Quando si è parlato di SOA si è pensato tipicamente ad un ambiente aziendale in cui, normalmente
ci sono delle applicazioni verticali che sono la finanziaria, l'ERP, ossia il resource plannig aziendale
e tutta la parte di gestione dei clienti.
Tipicamente, queste aree erano gestite in modo assolutamente indipendente l'una dall'altra, quindi
con soluzioni singole e poco interoperabili.
7
Pertanto l'idea di web services è determinare una serie di servizi che non sono ascrivibili ad un area
240
Stefano Di Monte
ma possono essere parte delle diverse aree, consentendo anche una buona interazione.
In sostanza il modello non è più un modello verticale, bensì un modello a grafo in cui l'esigenze
aziendali sono mappate in servizi e semplicemente dall'interazione e dalla possibilità d'invocazione
di questi si ottiene effettivamente la corretta gestione delle risorse aziendali in modo ampio.
In sostanza, l'architettura SOA dovrebbe, dato una risposta, consententire di identificare al meglio
delle interfacce differenziate.
NOTA: Come sempre succede, quando si parla di un nuovo modello, si dà molta fiducia a
quest'ultimo, perché capace di risolvere tutto; in realtà se usato male, un qualsiasi modello, non
risolve proprio niente: se io creo interfacce inadeguate alla realtà aziendale ciò non risolve niente
anzi fa decomporre male le applicazioni e non fa in modo tale da ottenere ciò che in realtà si voleva
ottenere.
Bisogna essere molto critici!
8
Nella figura presente possiamo distinguere due zone:
-) la parte di sotto e tratteggiata rappresenta tutta la parte tecnologica in cui abbiamo tutta la parte di
infrastruttura, l'insieme delle applicazioni, il ciclo d vita di quest' ultime e tutta la parte di gestione
delle applicazioni stesse. Tale parte non esisterebbe se non ci fosse la parte di sopra.
-) la parte di sopra è la parte di politica di gestione tecnologica a livello aziendale e politiche di
gestione assolutamente aziendali: è evidente che molte delle decisioni che si prendono di sotto sono
fortemente vincolate dalle decisioni che si prendono in questa parte.
In sostanza le cose di cui stiamo parlando hanno sicuramente impatto sulla parte tecnologica ma
hanno soprattutto l'obbiettivo di chiarire delle cose a livello esterno, quindi verso la parte di gestione
e strategia aziendale, verso la parte di business e di impresa, per ottenere anche un esportazione
delle necessità tecnologiche, in modo da farle comprendere ai manager che tipicamente prendono
decisioni in base ad altre cose.
9
Si è parlato di SOA perché quest'ultima è alla base delle specifiche tecnologiche di Web Services, i
quali fanno quindi, sempre riferimento all'architettura appena vista (SOA).
Reti di Calcolatori LM
241
Quando si parla di Web Services, NON si sta parlando di servizi web, i quali sono quei servizi che il
web predispone tipicamente per i clienti, i quali rappresentano gli utilizzatori finali: si lavora C2B;
quando si parla di Web Services si parla invece, tipicamente, di servizi che vengono usati per
produrre altri servizi, che poi potranno essere proposti agli utenti finali, ma che non vengono
direttamente proposti a quest'ultimi: di base si lavora B2B.
Sicuramente, una cosa fondamentale che sta dietro ai Web Services è l'ispirazione alla SOA, ma poi,
scelta importantissima, lavorare con servizi che sono web-compatibili: si crea quindi, un framework
in cui i servizi sono web-compatibili; in sostanza i Web Services sono descritti da un framework
XML-compatibile; pertanto la descrizione dei servizi e la realizzazione della architettura SOA è
tutta in termini di XML.
Questa decisione fu una decisione molto moderna, in quanto, il modo di realizzare SOA da parte di
Web Services, è un modo che si aggancia in modo completo all'evoluzione dei protocolli web, e ciò
è una cosa molto importante.
10 – 11
In generale tutte le cose di cui abbiamo parlato in questo corso, fino ad ora, sono usate in ambiti
aziendali e non, ed hanno l'obbiettivo massimo di interoperabilità: tutto ciò che è messo a
disposizione in una qualche architettura dev'essere visibile in una qualche altra architettura.
Pertanto un obbiettivo è superare l'eterogeneità.
Un altro importante obbiettivo è la sicurezza: in ambito aziendale è particolarmente importante che
le cose avvengano garantendo la qualità opportuna, dove per qualità si intende la sicurezza.
Dunque, le architetture viste finora, quelle DCOM, .NET e CORBA, rispondono alle esigenze
appena dette: interoperabilità tra linguaggi diversi e così via.
12
Ad esempio lavorando in CORBA:
CORBA fornisce una soluzione assolutamente standard per avere interazione fra clienti e servitori
(si lavora in modo sincrono), c'è un orb e poi effettivamente quest'ultimo fa da ponte e consente di
andare dal cliente ed il servitore.
13
Allo stesso modo, la stessa cosa si può dire per .NET (e quindi anche per DCOM o COM che sia),
in cui abbiamo clienti e servitori, ed in cui siamo in grado di far comunicare questi anche in
architetture con linguaggi diversi e con la corretta sicurezza.
I due aspetti importanti sono quindi, l'interoperabilità (cliente e servitore scritti in linguaggi ed
operanti in ambienti differenti) ed anche, sicuramente tenuto in conto sempre, la possibilità di
integrare sistemi vecchi, quindi sistemi legacy presenti a livello aziendale.
14
Questo qui presente, è un lucido un po' trionfalistico ma che prende atto del fatto che:
lavorando in un architettura CORBA/COM/DCOM/.NET, quest'ultima sicuramente permette
l'interoperabilità e la possibilità di passare da un qualunque ambito cliente ad un qualunque ambito
242
Stefano Di Monte
servitore, naturalmente con un protocollo di passaggio (che sarà su TCP l'IIOP per quanto riguarda
CORBA, mentre in DCOM l'RPC di DCE), ma il problema che c'è, molto spesso, è un problema
organizzativo e molto banale: quando si va sull'architettura di servizio e si cerca di entrare sulla
porta “pippo”, il manager che gestisce la sicurezza di quel sistema avrà già pensato di chiudere
quella porta e quindi ci si trova ad aver a che fare con una struttura che funziona meravigliosamente,
ma che per ragioni organizzative è stata chiusa; e cercando di aprire quella porta ci si scontra con
dei problemi di organizzazione assolutamente difficili da trattare e da risolvere.
In sostanza quindi, le soluzioni architetturali ci sono tutte, ma spesso sono bloccate da delle
decisioni organizzative e spesso da dei livelli di servizio su cui è molto difficile intervenire.
Pertanto, <<qual'è la porta sempre aperta?>>
La porta sempre aperta è il WEB: tutte le aziende hanno quindi capito che hanno necessità di far
vedere i propri servizi attraverso il web e quindi attraverso, ad esempio, la porta 80, è ovvio quindi
che la soluzione è usare quest'ultima per comunicare ed entrare all'interno dell'azienda.
L'idea molto semplice e fondamentale che sta dietro i Web Services è proprio questa!
Inoltre in questa slide si aggiungono anche una serie di cose che non sono specifiche della
tecnologia Web Services:
se io riesco a passare e lavoro con un architettura orientata ai servizi, naturalmente non so dall'altra
parte che architettura c'è (Win, Unix, …) ovviamente quel servizio lo posso ottenere
indipendentemente dal tipo di architettura.
Pertanto c'è un idea molto forte di interoperabilità, ma l'idea più importante, quella che ha diffuso
questa prospettiva, è soprattutto l'idea del passaggio attraverso i vincoli di sicurezza senza
perturbare gli standard aziendali.
15
Il modello che sta alla base dei Web Services è un modello in cui vi è:
-) il provider del servizio che non è altro che il servitore del servizio stesso, e fornisce tale servizio
con un interfaccia che dipende dall'implementazione.
-) i richiedenti del servizio, quindi i requestor, che lo possono richiedere indipendente
dall'architettura del provider dato che, ovviamente, ciò che importa è l'interfaccia del servizio.
Quest'ultima potrebbe essere nota prima al richiedente, ma tale architettura è sempre un architettura
a 3 parti e la terza parte è:
Reti di Calcolatori LM
243
-) un broker (termine scomparso perché andava in conflitto con termini già usati e soppiantato dal
termine directory dei servizi). La directory dei servizi è una funzionalità dove vengono esposti i
servizi (le interfacce) in modo tale che sia possibile, da parte di chi ne ha bisogno, di capire
l'interfaccia del servizio stesso.
NOTA: le tre parti ci devono essere tutte!
La parte più importante del modello dal punto di vista dinamico è la directory: quest'ultima non è
altro che un elenco delle interfacce di servizio. Difatti, vedendola in tal modo, la directory ha quindi
tutte le registrazioni che vengono fatte dai provider, pertanto, quando qualcuno ne ha bisogno
fornisce l'interfaccia del servizio.
NOTA: In tal modo, la directory assomiglia molto al repository delle interfacce!
Ma anche se nella slide vi è scritto “broker”, in realtà qui il broker non c'è, pertanto l'interazione tra
il provider ed il richiedente è esplicita, nel senso che il provider deve essere contattato dal
richiedente e solo in questo caso rispondere alle sue richieste; pertanto siamo più vicini al modello
p2p di DCOM....e neanche a quello di .NET, perché difatti, quando richiediamo in .NET un
servizio, ci sono tutti proxy che mi gestiscono il tutto mentre qui i proxy non ci sono....
Ragionando sul modello:
quando io requestor vado a chiedere al directory un interfaccia, a questo punto ottengo quest'ultima
che non è altro che una descrizione del servizio, quindi astratta (metodi, parametri ecc ecc); ora però
ho il problema concreto di andare a chiedere le cose ad un provider....
<<come faccio a sapere doc'è e chi è il provider?>>
pertanto il directory è un directory del provider del servizio e non solo della descrizione del
servizio.
Quindi in sostanza, non vi è un broker che media nella ricerca del provider, bensì quest'ultimo va
cercato dal richiedente del servizio stesso, all'interno del Service Directory, che quindi presenta una
descrizione astratta del servizio ed una descrizione concreta del provider.
16
NOTA: la descrizione presente in questa slide è una descrizione vecchia dei Web Services e
cambiata poi successivamente.
Quando si parla di Web Services, in realtà si parla di una suite di protocolli, in particolare di tre
protocolli tutti web-compatibili (o meglio XML-compatibili), e tutti necessari perché solo con
244
Stefano Di Monte
questi tre protocolli si riesce a realizzare il modello a tre parti.
NOTA: tutti i protocolli di Web Services sono descritti in XML, che è un linguaggio di descrizione
in accordo ad una specifica di alto livello comprensibile dall'utente (quindi non binario).
SOAP
E' l'acronimo di Simple Object Access Protocol.
É il protocollo con cui si fanno le richieste dal richiedente al provider: si standardizza quindi, come
un richiedente può chiedere un servizio ad un provider e come la risposta (dal provider al
richiedente), che eventualmente arriverà, dovrà quindi arrivare: è un protocollo di comunicazione.
WSDL
E' l'acronimo di Web Services Description Language.
Un provider deve fornire delle interfacce e par far ciò si deve registrare ad un servizio di directory,
ed in particolare con una specifica descritta dal protocollo WSDL; questo protocollo è un protocollo
che specifica l'interfaccia del servizio ed anche le sue caratteristiche concrete.
Pertanto è la descrizione del Web Services data come standardizzazione: rappresenta pertanto il
linguaggio di descrizione (assolutamente XML).
Ovviamente quindi, il directory è un insieme di WSDL, un insieme quindi di descrizioni date in
termini di questo linguaggio (XML); linguaggio che sarà quindi, anche quel qualche cosa fornito ad
un richiedente che ha bisogno di un servizio, che poi lo ottiene, ed a questo punto può prendere il
WSDL dal quale ricaverà l'interfaccia del servizio, il fornitore, e quindi potrà fare finalmente la
richiesta di SOAP per ottenere l'operazione di cui ha bisogno.
UDDI
E' l'acronimo di Universal Discovery, Descrption, and Integration.
Rappresenta la specifica con cui si deve progettare l'insieme dei discovery: viene quindi
standardizzato il modo con cui i discovery devono essere organizzati e devono consentire di ottenere
funzionalità d'accesso e di registrazione di servizi.
Questo standard è anche lui uno standard XML compatibile.
Questi te protocolli sono i tre protocolli di base!
Ragionando sul modello...
Da questo modello discende, chiaramente che ci sono dei requestor, dei provider e delle agenzie di
discovery.
La realizzazione di questo modello nel mondo business prevede che vi siano parecchi UDDI ognuno
per un unico gestore, e non prevede i meccanismi di interoperabilità tra i diversi UDDI. Pertanto i
diversi directory, quindi i diversi UDDI, non sono federati e sta all'utente andarsi a cercare i servizi
che gli interessano nei rispettivi UDDI.
Reti di Calcolatori LM
245
17
Questo è quello che viene considerato lo scenario Web Services prima generazione.
NOTA: il modello della SOA è un modello in cui si ragiona per singolo servizio.
18
XML è un linguaggio derivato dalla teoria standard dei linguaggi di murkup e porta con se l'idea di
poter descrivere in modo esteso e indipendente dall'applicazione la struttura delle informazioni.
Stiam definendo una descrizione sintattica.
19
Sicuramente è un linguaggio testuale, quindi non binario, e pertanto non efficiente, pertanto ci
collochiamo molto in alto, a livello applicativo.
20
Comunque, quando si parla di XML, tendiamo a dare la possibilità all'utente di definire i propri tag,
e quindi di definire, marcare, i dati di cui ha bisogno a seconda delle specifiche.
I protocolli quindi tendono ad usare XML, perché effettivamente consente di avere uno standard
come linguaggio, inoltre consente un estensione molto facile alle esigenze che man mano si
manifestano per i diversi protocolli.
21
Ricordando:
SOAP è il protocollo di comunicazione: in sostanza descrive come una richiesta possa essere fatta
dal richiedente al provider.
Siccome in generale, in prima battuta, ciò che si può immaginare è che le operazioni siano sincrone
bloccanti (il cliente fa una richiesta ed aspetta sino a che non arriva una risposta), tipicamente
SOAP descrive, ad esempio, sia la richiesta che deve viaggiare dal richiedente al provider, e sia la
risposta che deve viaggiare dal provider al richiedente.
L'idea fondamentale è che SOAP sia in linguaggio XML, che consente di descrivere come devono
viaggiare le richieste che porteranno sicuramente dei parametri, e come devono viaggiare le
rispettive risposte che dovranno portare i risultati: tutto viene quindi descritto da una specifica
standardizzata di XML.
246
Stefano Di Monte
Guardando le cose più in particolare:
Se io volessi richiedere un operazione a qualcuno che è in grado di fornirla, dovrò “imbustarla” in
una SOAP Envelope, in cui non vi è un header, ma sicuramente c'è il body che contiene
effettivamente la richiesta specifica che avrà probabilmente dei parametri.
22
In prima battuta, l'architettura SOA, tipicamente, descrive delle interazioni c/s; in realtà SOAP
prevede due forme di interazione:
1. interazione c/s
2. interazione one-way, quindi asincrona: il cliente fa delle richieste che vengono portate
dall'altra parte e non c'è risultato.
L'obbiettivo del protocollo SOAP è comunque quello di specificare solo il trasporto, ossia solo le
informazioni che devono essere scambiate e nient'altro. Ovviamente, non dovremo descrivere in
alcun modo come l'operazione sarà implementata dalla parte del provider, né lo stato del richiedente
perché i due ambienti devono essere tenuti assolutamente separati: siamo in un sistema che funziona
B2B, e di conseguenza le varie controparti dell'interazione potrebbero essere scritte in linguaggi
differenti.
In generale, la prima implementazione dei protocolli di prima generazione è un implementazione
assolutamente SOA, quindi stateless: il servitore non ha stato, non deve ricordarsi in nessun modo
che c'è stata una richiesta; pertanto se un richiedente ha bisogno, ad esempio, di 5 operazioni, le
richiederà ex-novo e saranno totalmente auto-contenute ed il servitore non dovrà in nessun modo
ricordare le richieste del richiedente.
RICORDA: nel XML non vi è semantica, vi è solo descrizione strutturale.
Il protocollo SOAP, deve essere ovviamente integrato con le normali operatività web; in sostanza si
usano delle post e delle get per veicolare le richieste (giacché siamo sicuramente in un sistema in cui
il servitore è un web server! Ed il cliente potrebbe essere anche lui un web-server se siamo B2B o
un cliente finale se si lavora B2C).
23
In realtà, un header che può pertanto dare una serie d' informazioni c'è!
In particolare, può dare delle informazioni di passaggio, ossia delle informazioni riguardanti delle
entità intermedie che potrebbero essere in mezzo, tra il provider ed il richiedente.
Pertanto la parte di header, specifica il percorso ed una serie di intermediari, i quali possono fare
delle operazioni, molto ampie, che tendono a stabilire il cammino stesso (reservation).
24 – 25
Reti di Calcolatori LM
247
Esaminando SOAP in modo più estensivo, ci accorgiamo che in realtà vi sono tre tipi di messaggi:
• richiesta
• risposta
• fault
Resta comunque che tutti i messaggi SOAP sono un envelope con header e body:
-) l' hedear che spesso è vuoto;
-) la parte di body è quella che descrive l'operatività ed in generale porta le informazioni:
sicuramente, data una richiesta, il body conterrà i parametri da portare al servitore (se c--->s) o la
risposta se l'interazione sarà dal servitore al richiedente, ed in quest'ultimo caso è anche possibile
avere dei fault, che sono espressioni di livello di SOAP e dicono sulla presenza di errori, ad
esempio, sulla fornitura della cosa richiesta ecc ecc.
26
Si tenga ben presente che si sta parlando di sistemi in cui, sicuramente abbiamo ottenuto la
possibilità di passare attraverso le porte privilegiate, ossia le porte web (80, 8080 ecc), però,
trovandoci molto molto in alto, per fare una richiesta, dobbiamo avere qualcosa che simuli un
servizio web che è in grado di fare una richiesta get/post al cui interno mettiamo l' envelope SOAP
di cui ce n'è bisogno.
Tipicamente, dalla parte servitore avremo sempre a che fare con web-server il quale avrà quindi
almeno un minimo di operatività per riconoscere le operazioni ecc ecc, ma per avere un supporto
web compatibile completo, abbiam bisogno che anche dalla parte cliente ci sia un qualche cosa che
assomigli ad un engine, perché le operazioni potrebbero essere, ad esempio, di fault, o anche
integrate in operazioni più complesse, e quindi difficili da definire manualmente (dalla parte del
richiedente).
Esempio di uno schema di colloquio:
248
Stefano Di Monte
NOTA: quando si ragiona con i Web Services bisogna (quasi) sempre ragionare in termini di B2B,
in cui non è il singolo cliente che fa una richiesta ad un web-server bensì, in cui l'interazione
avviene tra due web-server, tra due nodi che possono essere sia provider che richiedenti, e, quindi, le
cui operazioni tra loro sono operazioni più ricche di una normale operazione tra un client ed un
server: ci muoviamo nel mondo B2B.
É importante ricordare questo perché l'interazione che avviene è molto costosa e quindi sprecata (in
termini di overhead) se fosse utilizzata, ad esempio, per incrementare un contatore.
27
Un esempio di richiesta:
Come già detto, la parte di envelope è quella parte che contiene realmente la richiesta, ma, come si
vede nella slide in cui vi è un esempio di post, la envelope è all'interno della post stessa.
Poi c'è sempre la parte di body, che dovrà contenere, se fosse una richiesta, il nome del metodo con i
rispettivi parametri.
In questo caso c'è anche la parte di header, in cui sono presenti un po' di specifiche che sono, per
esempio, dei modi con cui andare a ritrovare gli standard a cui è ispirato il messaggio che si sta
inviando, la codifica di tali standard, ecc ecc. In sostanza, la parte di header ha una serie di
specifiche che consentono al ricevente, quindi al fornitore del servizio, di capire bene cosa sta
succedendo, quindi in particolare, quali sono gli standard di codifica, quali sono gli spazi di nomi
messi in gioco dalla richiesta ecc ecc.
Rispetto ad una richiesta binaria estendiamo molto, ed abbiam bisogno di un supporto necessario da
Reti di Calcolatori LM
249
una parte e dall'altra.
28
I Web Services, in Italia, sono stati subito abbastanza usati, in particolare, dal settore bancario. Una
delle ragioni trainanti, che portò le banche a sperimentare questa tecnologia, fu la possibilità da
parte delle banche, di avere una forte acquisizione reciproca l'una con l'altra, quindi la presenza di
forti problemi di interoperabilità, e al contempo, anche problemi di non alterare gli schemi di
sicurezza: quindi usare il modello del web per entrare, era effettivamente molto semplice, proprio
perché le banche avevano delle porte aperte tramite le quali facevano vedere, ai vari utenti, le
proprie funzionalità.
L'architettura SOAP tipicamente, lavora RPC style, il che vuol dire che chi fa una richiesta, aspetta
la risposta.
In realtà, guardando l'installato, e le esperienze che ci sono state, si è invece lavorato molto one-way,
che in termini di Web Services è stata definita document style: l'effetto che si ha, è un effetto di
trasferimento d' informazioni molto forte.
29
Lavorare document style si è affermato abbastanza, sempre più, tanto da far affermare il lavoro
asincrono, in sostanza senza risposta, e magari, con messaggi di buona riuscita o malriuscita
dell'operazione inviati di tanto in tanto (esempio: nei trasferimento dati tra banca e banca).
30
Questo lucido dice come sono fatte le risposte.
Esempio:
250
Stefano Di Monte
Le risposte ovviamente, hanno una struttura molto simile alle richieste:
il messaggio deve qualificare il fatto di essere un messaggio di risposta, ma dal punto di vista del
veicolo siam quasi allo stesso livello.
31
E' possibile comunque avere un messaggio d'errore, di fault , quindi un eccezione che è abbastanza
standard, qui un esempio:
si noti che per l' HTML (vedi esempio in alto) è un messaggio corretto, ma che a livello di SOAP
definisce che c'è stato qualcosa che non va, dando i dettagli (visibili all'applicazione e quindi
all'utente) sul problema avvenutosi.
32
Se volessimo fare una considerazione identica, sicuramente dovremmo dire che il protocollo SOAP
è su di uno stack piuttosto in alto, perché, non solo è applicativo ma sta sopra all'HTTP e all'HTML:
è sicuramente un protocollo non binario, un protocollo in cui c'è un overhead molto ampio, non solo
per l'HTML, ma anche per tutta la parte di descrizione di SOA la quale è fortemente ridondante.
Siamo sicuramente in un una generazione diversa, e ad una altezza differente di stack rispetto ai
middleware binari, con conseguenti costi più alti!
Si noti che, nonostante che i documenti W3C, o gli stessi documenti che descrivono i progetti,
parlino di estrema efficienza, lo fanno nell'ambito della proposta, perché, in realtà, tali protocolli
non sono efficienti perché siamo molto in alto!
Una delle ragioni per cui i progetti di prima generazione hanno fallito, è perché sono stati usati
male, non è stata capita la grana di tali protocolli, la quale è assolutamente grossa!
33
Pertanto le operazioni non sono leggere...
<<Sono però robuste?>>
Facendo una richiesta ad un server-web, non ho la garanzia che le coso vadano bene; difatti, se
Reti di Calcolatori LM
251
dovesse cadere la connessione, la risposta non arriva!
Pertanto, la robustezza sta tutta nel supporto TCP che c'è sotto, che quindi il canale vada a buon fine
e regga per tutto il tempo per cui le cose ci stanno e devono arrivare come richiesta e quindi
risposta.
NOTA: distinguere sempre bene ciò che viene detto di una tecnologia da ciò che realmente può
fornire.
Sicuramente, è possibile passare da qualunque ambiente a qualsiasi altro ambiente: installo il mio
server da qualche parte, qualunque sia la mia architettura di supporto, e quindi posso mettere i miei
servizi a disposizione in e da qualunque architettura.
Sicuramente, anche, il protocollo SOAP è un protocollo semplice dal punto di vista della
comprensibilità e semplice dal punto di vista della descrizione!
34
WSDL è il linguaggio di descrizione del servizio; è il linguaggio con il quale descriviamo in modo
ampio il servizio da fornire, l'interfaccia per poi poter fare le richieste SOAP e le risposte SOAP che
sono necessarie.
UDDI invece è un registro che stabilisce come si registra la WSDL di un servitore.
NOTA: l'organizzazione di supporto è W3C, ossia l'organizzazione di standardizzazione del web
che pesantemente era supportata da una serie di aziende.
35
WSDL è in sostanza la descrizione di come un servizio può essere ottenuto in modo molto ampio:
pertanto WSDL potrebbe essere inteso come un IDL, in realtà non è vero, perché è un qualche cosa
di più!
Difatti, a differenza di un IDL, che è un linguaggio astratto di descrizione dei dati, in quanto non
dice niente di chi fornisce l'interfaccia (questo perché in CORBA, vi è tutta l'infrastruttura che è in
grado di andare a recuperare, sulla base dell' IR, il servitore per fornire il servizio), WSDL è in
realtà la parte astratta accoppiata ad una parte concreta, proprio perché il cliente dovrà andare sul
servitore per richiederne un metodo e se non sa dove è situato non può farlo: l'interazione, qui, è
pari-a-pari, non vi è supporto, e quindi è il provider che si deve esser reso noto e deve aver messo
nel WSDL la specifica di chi è e di come le cose possono essergli chieste (difatti vi è anche una
parte di descrizione concreta dell'operatività) senza le quali non si potrebbe far nulla.
Concludendo, in WSDL, non vi è solo la parte dichiarativa, ossia cosa un servizio può fare, quindi
quali sono le operazioni che si possono richiedere ecc ecc, ma ci posso trovare anche informazioni
su a chi posso chiedere tali operazioni, dove è situato, e come devo fare l'invocazione: senza quest'
ultime informazioni non si potrebbe avere la possibilità di lavorare in modo auto-contenuto,
252
Stefano Di Monte
autonomo e senza interferenze.
36
37 – 38 – 39 – 40
Nell' WSDL vi è tutta una parte che descrive la parte astratta, ossia la descrizione della pura
interfaccia (come per IDL), quindi con una serie di operazioni, le quali sono le entità che possono
essere di tipo RPC-style o anche di tipo document-style; le operazioni sono fatte normalmente, di un
messaggio di input (la richiesta) e di un messaggio di output (la risposta). A sua volta i messaggi
sono qualificati da dei tipi di parametri che sono i parametri da richiedere (ad esempio il tipo
dell'operazione sarà una stringa con il nome dell'operazione stessa).
Vi è tuttavia, tutta la parte concreta, quindi la parte che descrive concretamente i fornitori dei
servizi, i quali sono tipicamente dei binding (ossia c'è qualcuno che si è legato per fornire tali
servizi); in realtà i binding, che rappresentano le cose richiedibili, hanno un endpoint che consente
di raggiungere l'entità concreta, quella che risponde alle esigenze specifiche di realizzazione; in
sostanza, nell'ambito del web-server, dicono dove sta chi gestisce quella specifica operazione e
qual'è il suo nome in modo tale che possa essere integrato nella logica completa del servizio.
41
Vi sono due versioni di WSDL.
La versione seconda (WSDL 2.0) è quella che viene considerata negli ultimi anni, e che differenzia
dalla prima versione (WSDL 1.1) perché pone un accento più forte sui termini astratti anziché sui
termini concreti.
Difatti, nella prima versione si parlava di port, termine più concreto, mentre nella versione 2.0 si
parla di endpoint, termine un po' più astratto; così come l'interfaccia prima si chiamava portType.
Quindi semplicemente sono cambiate delle parole chiavi, il che può, comunque, diventare un
problema se fatto in corso, quindi quando il protocollo si sta affermando, anche se si tratta di
differenze insignificanti in termini di funzionamento del protocollo stesso.
Reti di Calcolatori LM
253
NOTA: importante mantenere gli standard al fine di far diffondere la tecnologia correttamente!
42
43
44
45
I tipi servono per qualificare una richiesta, sono quindi necessarie per ottenere operatività: nome
dell'operazione (tipo stringa), nome del parametro (ad esempio tipo float), ecc.
46
Un messaggio di richiesta è composto dalla descrizione del suo corpo, che in questo caso è legato
all' esempio in questione, ed è il valore col tipo corrispondente, così come il messaggio della
risposta avrà il valore, in questo caso in float, della risposta corrispondente che si ottiene dal server.
Qui di seguito un esempio di descrizione di un messaggio di input ed uno di output:
Queste cose sono qui messe insieme, perché l'operazione richiede un messaggio di input ed un
messaggio di output.
47
254
Stefano Di Monte
Molto importante è la modalità, quindi l'uso dei protocolli per ottenere le operatività di cui si
necessita.
Sicuramente, vi sono operazioni sincrono ed asincrone, come definisce lo stile di SOAP (RPC o
document style), e, come si nota da questa slide, vi sono 4 modalità a seconda se si parla del
richiedente o del fornitore:
•
Request_response: rappresenta la modalità normale di lavorare client-side, in cui il cliente fa
una richiesta ed aspetta una risposta.
•
Solicit_response: è una modalità in cui il è il provider del servizio a fare una richiesta al
cliente, ma resta esattamente una richiesta sincrona bloccante; cambia solo il punto di vista.
Pertanto se un provider fa una richiesta al cliente, non usa una request_response, bensì usa
una solicit_response, in quanto cambia, in termini di WSDL, la descrizione.
•
One_way: vuol dire lavorare document-style client-side: non si aspetta la risposta.
•
Notification: esattamente, in maniera simmetrica, se è il servitore che deve sollecitare il
cliente in maniera asincrona (nel senso di non avere risposta), allora si lavorerà con
notification.
In sostanza, i meccanismi sono inseriti in un gioco di ruoli molto preciso: chi riceve una richiesta,
può al tempo stesso sollecitare chi c'è dall'altra parte e ciò viene trattato e descritto in modo
coordinato, mettendo un po' le operazioni insieme, in accordo però ad una logica che non è SOA:
difatti se in quest'ultimo le operazioni sono completamente auto-contenute, qui invece abbiamo un
ruolo che viene mantenuto dal server, che può quindi sollecitare oppure chiedere delle cose al
cliente.
Si comincia a dire che l'interazione non è per una sola operazione, bensì per più operazioni!
Difatti, non avrebbe nessun senso avere una Solicit_response, se non: fosse che, ad esempio, un
server che deve dare una risposta, per dare tale risposta avesse bisogno di ulteriori informazioni del
cliente.
Pertanto non è in accordo all'architettura SOA, in cui sarebbero bastate le due operazioni di
request_response e one_way per realizzare le modalità sincrona e asincrona: qui si crea un contesto
di comunicazione!
48
La storia sulla parte concreta è molto simile.
Il binding viene dato con l' idea di legame con l'interfaccia che si deve fornire, e con le operazioni
che tale interfaccia deve fornire; dopodiché bisogna specificare una soapAction attraverso l' URI che
fornisce la reale presenza del server di cui ce n'è bisogno, il quale ha una descrizione che dice quali
sono i messaggi che effettivamente devono entrare e devono uscire per le operazioni di cui abbiamo
bisogno.
L'operazione fondamentale è l'operazione Soap che viene messa a disposizione dal binding per
ottenere un certo effetto.
In sostanza il binding è visto come collegamento tra un tipo di operazione (type), un nome di
Reti di Calcolatori LM
255
operazione (name) e l'azione da eseguire (soapAction):
NOTA: si stanno riferendo le implementazioni concrete.
49
Il servizio è un insieme di operazioni (in questo caso di un unica operazione):
Si noti, che vi è tutta una parte di documentazione, che potrebbe descrivere, ad esempio, in un
formato molto vicino all'utente, cosa fa il binding, quindi l'insieme dei servizi, ma potrebbero
esserci anche tutta una serie di dettagli architetturali che possono servire al cliente per capire come
fare le cose (ad esempio descrizioni di intermediari per avere operazioni più coordinate).
<<Cosa potrebbero fare due intermediari che sono situati in mezzo tra il server ed il richiedente?>>
Giocano un ruolo molto vicino al ruolo degl' interceptor, quindi potrebbero ad esempio, criptare (e
quindi decriptare) l'informazione che va dal cliente al servitore; ovviamente però, nell'esempio
appena citato, i due intermediari starebbero nella rete privata dell'uno e dell'altro! Comunque tutto
ciò aumenta i costi ma d'altra parte aumenta l'operatività.
50
WSDL ha giocato molto nella diffusione dei Web Services perché si integrava molto bene con gli
strumenti di sviluppo, in particolar modo con i servizi di generazione di stub o cose similari,
presenti nei vari linguaggi.
<<Le cose sono molto efficienti?>>
Sono adatte se l'interazione è a grana grossa!
Una cosa importante è che man mano, i Web Services, cominciano ad essere un veicolo che ha
come target lo stesso target dei middleware.
Pertanto tendono a dire alle aziende che, in presenza di loro parti legacy da voler rendere disponibili
256
Stefano Di Monte
ed esportare con le rispettive interfacce, di usare i Web Services!
E su questo giocano molto gli strumenti di integrazione, che sono in grado di far descrivere con un
WSDL delle cose già esistenti, e di conseguenza di integrarli.
51
Assieme alle specifiche di come si fa una comunicazione (SOAP) e alle specifiche di com'è che si
descrivono le operazioni in modo concreto ed in modo astratto (WSDL), vi è la specifica di come è
fatto il server che registra tutte i WSDL dei servizi che sono messi a disposizione dai provider, ossia
UDDI.
Quando parliamo di UDDI, si parla di entità a cui i provider dei servizi devono registrarsi per
registrare i propri WSDL.
Ragionando in astratto:
<<Se si hanno due provider che forniscono lo stesso servizio, quindi la stessa interfaccia, si avrà lo
stesso WSDL?>>
NO! perché presente nel WSDL vi è la parte concreta che dà la descrizione concreta del provider del
servizio, ed essendo questi diversi, di conseguenza saranno differenti anche i WSDL; tutto ciò anche
se la parte astratta, quella di descrizione dell'interfaccia sia la stessa e comune ad entrambi.
UDDI, è quindi, un servitore universale, capace di registrare delle descrizioni e fornisce un
linguaggio di discovery e di integrazione dei servizi.
Pertanto la funzionalità fondamentale è quella di discovery, con la quale, chiedendo all' UDDI per
un servizio specifico, si ottiene una risposta capace di far capire al richiedente com'è lo stato dei
provider del servizio richiesto.
É un sistema di nomi che registra tutti i provider che sono disponibili.
Pertanto, il server UDDI, ha la funzione di sistema di nomi e deve registrare tutte le possibili
definizioni di interfacce che producono poi delle operatività che possono essere richieste da
qualcuno.
La logica usata per la standardizzazione di UDDI, è una logica tipicamente di business: si intende
una logica in cui la funzionalità fondamentale è descrivere delle informazioni non tanto
tecnologiche che però siano in grado, a chi ne richiede, di ottenere in modo efficiente di arrivare ad
ottenere le funzionalità di cui ne ha bisogno senza un obbiettivo particolarmente informatico, ma
come descrizione molto di impresa: ci si muove molto vicino ai sistemi di gestione aziendale dove
domina la logica di impresa, pertanto si descrive anche l'azienda che fornisce i servizi.
NOTA: si ha altresì una descrizione tecnica (confinata maggiormente alla parte di WSDL), ma
Reti di Calcolatori LM
257
molto più importante qui è la descrizione dell'impresa.
52 – 53
Tipicamente, UDDI è un insieme di entità di business, aventi una serie di informazioni che sono
sicuramente informazioni aziendali (nome, contatti, descrizione, ecc.); è composto ovviamente
anche da tutta una serie di descrizioni per categoria che sono la base per fare poi discovery. Vi sono
altresì tutta una serie di informazioni di descrizione del singolo servizio con dei tamplate di servizio
ed infine si hanno descrizioni tecniche del servizio stesso.
54
Normalmente quando utilizziamo un sistema di nomi, si dice che si stanno utilizzando le pagine
bianche, le quali attraverso la descrizione del servizio, data da un nome, si ottiene in uscita un
riferimento al servizio, in questo caso in uscita si ottiene un WSDL del servizio, e con quest'ultimo
si può fare la richiesta al provider del servizio che si vuole richiedere.
Vi sono esplorazioni di discovery leggermente differenti alle pagine bianche:
-) si può lavorare a pagine gialle, ossia la ricerca può avvenire su attributi tipicamente che
descrivono il tipo di servizio, pertanto il discovery vien fatto sui vari tModels (ad esempio potrei
richiedere un servizio di stampa).
-) oppure è possibile lavorare sulle pagine verdi, ossia pagine di descrizione tecnica del servizio (per
cui, riprendendo l'esempio precedente, potrei richiedere un servizio di stampa in cui si è in grado di
stampare 20 pagine al secondo, magari rispetto a dove mi trovo che sia in un raggio di 400 mt ecc
ecc).
Chiaramente, resta il fatto che, le pagine bianche, gialle o verdi che siano, come funzioni d'accesso,
si possono fare solamente se i provider si sono registrati e solo per questi.
55
Si noti che c'è un problema molto forte di distinzione dei ruoli.
Un fornitore di WSDL, che quindi registra tutti i provider dei servizi, è tenuto a rispondere solo
sulle cose che sono registrate su di lui: siamo molto lontani dal DNS il quale è un sistema globale in
258
Stefano Di Monte
cui se non ottengo una risposta da un determinato servitore vado da un altro, qui no!
Tutto ciò teneva conto delle esigenze lavorative, del fatto che è molto difficile che un organizzazione
lavorativa, se non possiede un servizio, ti mandi su di un concorrente....
Pertanto tipicamente i server UDDI non sono coordinati: non c'è un protocollo ad-hoc per passare
informazioni tra server UDDI!
56 – 57
Si noti che all'inizio, le maggiori fornitrici di servizi, fornirono dei server UDDI pubblici che
potevano essere consultati per conoscere WSDL dei provider; in realtà questo ha portato, all'inizio a
sperimentare un mondo aperto in cui tutti sfidavano tutti (in sostanza internet primo modo); però,
quello che subito successe, è che ci fu qualcuno che cancellò i servizi degli altri, pertanto fu
necessario introdurre almeno un minimo di supporto alla sicurezza per garantire che la
cancellazione del servizio sia un qualche cosa che non possa esser fatta da chiunque ma solo da chi
era autorizzato.
Quindi i registri divennero, quasi subito, da pubblici a privati o semi-privati, ma, tristemente, non
c'è mai stato alcun movimento verso la federazione; i server UDDI sono assolutamente singoli!
Non c'è un protocollo ad-hoc di federazione tra i server UDDI!
NOTA: tipicamente un azienda ha un solo server UDDI.
Qui di seguito uno schema riassuntivo dell'architettura WebServices con SOAP-WSDL-UDDI:
61
La curva presente in questa slide non è una curva tecnologica ma definisce il ciclo di vita dell'
HYPE, ossia dell' “entusiasmo immotivato”: arriva una tecnologia, e nel momento in cui arriva, tale
tecnologia è il miracolo per risolvere tutto.
Reti di Calcolatori LM
259
NOTA: In realtà è giusto avere fiducia in una nuova tecnologia ma bisogna capire come usarla e
cosa fa.
La curva è composta da 5 parti, e dice che:
normalmente quando una tecnologia comincia ad affermarsi, in questa c'è un sacco di fiducia che si
manifesta nella prima salita: ora la nuova tecnologia è la soluzione a tutti i problemi (Web Services
versione 2.0 è in questa fase); poi ci si rende conto che non è proprio così, perché spesso la si usa
per situazioni per le quali non è adatta, pertanto si cade a picco: comincia la parte di sfiducia della
nuova tecnologia che non ha soddisfatto le nostre attese (Web Services versione 1.0 è in questa
fase); man mano poi si comincia a salire, perché si comincia ad utilizzare la tecnologia
effettivamente per cosa serve realmente: CORBA si trova in questa fase.
59
Non vale la pena di utilizzare una tecnologia in un ambito per essa sbagliato; pertanto i Web
Services sono a grana molto grossa, più grossa di quella di CORBA.
Pertanto, dati gli ultimi due esempi mostrati in figura, se richiediamo una sola applicazione per
metodo, allora sarà meglio utilizzare il protocollo SNMP, mentre se dovessimo richiedere N
applicazioni dello stesso metodo, allora utilizzare CORBA converrebbe, in quanto, mantenendo lo
stesso ObjRef, effettivamente manteniamo aperto un canale, tecnicamente l'orb, ed i costi sono
molto bassi.
260
Stefano Di Monte
60
Parlando di intermediari:
Se lavoriamo con CORBA (o RMI) le prestazioni sono migliori di quelle ottenibili lavorando con
Web Services, perché effettivamente i WS sono una tecnologia che non mira all' efficienza.
NOTA: non capendo questo, usiamo male la tecnologia ed alimentiamo la curva dell' hype ed
avviciniamo, in termini di tempo, la caduta delle illusioni (fase 3 della curva dell' hype).
63
In realtà, i Web Services rappresentano un po' un esempio, di come le cose possono andare
velocemente e magari, proporre alterazioni e variazioni rispetto allo standard.
Abbiam sinora discusso la versione iniziale dei WS la quale, come già detto, prevede tre protocolli
(SOAP, WSDL, UDDI), che fanno parte della suite dei WS.
In realtà tali protocolli, rappresentano una buona risposta all'idea delle architetture services oriented
(SOA) le quali hanno, sicuramente, delle ipotesi di base molto precise: ci sono delle operazioni,
quindi dei metodi, che sono richiesti e che devono essere auto-contenuti, non dipendenti l'uno
dall'altro, senza stato, ecc ecc; tuttavia i WS vanno un po' oltre, presentando intermediari e tutta una
serie di altre azioni che non sono rigidamente limitate alla singola operazione, ma sicuramente è un
modello in cui si hanno delle entità che si scambiano dei messaggi SOAP, che sono stati registrati
dall'entità di registrazione dell'agenzia di discovery e sono in formato concreto WSDL.
Sicuramente, però, se volessimo pensare a fare dei progetti un po' più significativi, allora si nota che
nei WS mancano un sacco di cose: ad esempio non vi è nessuna garanzia che, fatta partire un
interazione SOAP, la rete TCP si mantenga stabile e mandi a buon fine l'interazione avviata,
evitando, ad esempio, che niente si possa perdere tra gli intermediari, o addirittura nel server.
64
In sostanza ci si rende conto che è necessario introdurre degli altri protocolli.
Dato che ogni azienda tendeva ad introdurre le proprie aggiunte XML, quello che succedeva era che
alcune implementazioni introducevano degli attributi e dei modi che non erano interoperabili. Venne
introdotto pertanto, un protocollo chiamato Web Services Interoperability, il quale rappresenta il
fattor comune che tutti devono implementare.
In pratica si introducono una serie di nuovi protocolli che fanno chiamare la suite WS*!
Ad esempio venne introdotto un protocollo che garantisce qualità dal punto di vista del fallimento
Reti di Calcolatori LM
261
del supporto ai messaggi: WS-Reliable Messaging. Difatti questi garantisce che anche se qualcuno
perde una request o una response, questa viene correttamente rimandata finché non arriva al server
o al client corrispondente.
Tutto ciò viene espresso con delle politiche di qualità che sono espresse con un estensione del Web
Services che si occupa dell'estensione della qualità.
Così come tutta la parte di sicurezza viene definita in uno standard che si chiama WS-Security, nel
senso che tutte le possibilità di cifratura e di garanzia di integrità vengono definite da tale
protocollo, che poi verrà implementato dalle diverse parti d'implementazione.
Così come la parte di transaction, definita con uno standard che si chiama per l'appunto WSTransaction, che prevede una serie di azioni che compongono tutte insieme un unica entità che deve
essere fatta tutta oppure dev'essere disfatta per tornare alla situazione iniziale.
Si aggiungono così facendo, tutta una serie di protocolli!
Un protocollo importante, considerato chiave per poter fare delle cose con i Web Services, è il
protocollo BPEL4WS.
NOTA: il grafico presente in questa slide non è completo.
65
Tipicamente, si è detto che quando si lavora con architetture SOA, i singoli servizi sono per
l'appunto singoli, e possono esser chiesti in modo assolutamente auto-contenuto e senza una storia
(in realtà il WS-Transaction ed il WS-Coordination vanno già nel senso del mettere insieme...),
inoltre c'è tutto un filone che è tipicamente legato alle esigenze d'impresa, quindi considerato da
262
Stefano Di Monte
questo punto di vista abbastanza gestionale, e che è particolarmente importante per accrescere le
capacità espressive che si possono ottenere da questo scenario abbastanza concettuale in linea di
principio.
Pensando in termini informatici:
abbiamo un servizio, il quale ha degli input e degli output; normalmente, la prima cosa che viene in
mente è pensare di coordinare le richieste e le applicazioni del servizio, ad esempio semplicemente
con una banale pipeline, con la quale potrei mettere ciò che è in output ad un servizio in input ad un
altro, formando quindi una catena che potrebbe consentire un trattamento un po' più coordinato
dell'input che entra nel primo sino ad arrivare alloutput finale dell'ultimo.
In realtà tutti i linguaggi di workflow, vanno nel senso di diventare veri e propri linguaggi che
abbiano il massimo della capacità espressiva: non c'è solo possibilità di fare sequenza bensì c'è
anche possibilità di fare alternative, quindi cicli e ripetizioni, ed eventualmente, se è un linguaggio
di flusso, si potrebbe avere una biforcazione dell'attività (ad esempio si hanno due uscite finali come
in figura) oppure un join delle attività che aspettano le due uscite finali, i due risultati, e operano su
di loro, ad esempio, mettendoli insieme, confrontandoli ecc ecc, producendo comunque, un unica
uscita (quindi ci possono essere biforcazioni o join).
In particolare, per capire di cosa si sta parlando, si pensi ad un target che sia scarsamente capace dal
punto di vista informatico, e che ha a disposizione dei servizi che rappresentano bene la sua realtà
aziendale. Sicuramente, non manca la necessità di creare altri nuovi servizi, il che ci vien fatto da un
informatico che quindi ci risolve il problema.
É evidente però che, molto spesso, una banale composizione dei servizi, che possono essere messi
insieme in modo molto semplice, potrebbe essere progettata anche da un utente che non è esperto di
informatica: i linguaggi di flusso hanno esattamente questo target!
Quindi pensano ad un target manageriale, in cui c'è poca competenza, ed è in grado, se ci riesce, di
mettere insieme servizi con un flusso molto semplice.
Si noti che gran parte dei linguaggi di flusso, hanno descrizione in termini informatici, ma spesso
hanno un ambiente di supporto che è tipicamente grafico (i servizi potrebbero essere raffigurati da
dei blocchettini che verranno quindi collegati da delle frecce).
L'idea di workflow, è un idea molto importante, che richiede una capacità limitata, però è il
massimo delle cose che possono essere espresse da un utente di questo genere.
D'altra parte, molto spesso i processi aziendali si possono esprimere in tal modo: se arriva una
richiesta di certi prodotti, e tali prodotti non sono in magazzino, sarà bene scatenare i fornitori, e
andare ad accelerare il workflow, che a questo punto poi produrrà la presenza del prodotto di cui ho
bisogno e la possibilità di rispondere all'ordine che è stato richiesto: in sostanza, componendo dei
blocchettini è possibile rispondere a delle esigenze anche dinamiche dell'azienda!
Nell'ambito dell'architettura SOA, rimangono un po' offuscate queste possibilità di mettere insieme,
abbastanza dinamicamente, con una sorta di linguaggio di script, dei metodi, delle operazioni, che
sono disponibili.
Reti di Calcolatori LM
263
66
BPEL4WS= Business Process Execution Language for Web Services.
BPEL4WS è un linguaggio di cui viene data una specifica abbastanza precisa in termini di
possibilità di comporre attività.
Come è possibile immaginare, tutti i linguaggi di workflow, se completi, hanno più o meno le
operazioni descritte in questa slide:
•
è possibile fare una sequenza: un esempio è prendere due blocchettini, in particolare
prendere l'uscita dell'uno e cortocircuitarla con l'input dell'altro.
È possibile, ovviamente in alcuni casi, effettuare gli split di una attività; per cui una certa attività
che esprime un certo flusso di controllo può essere divisa su più flussi, i quali possono essere in:
•
•
•
AND: da una attività ne vengono generate due (in parallelo).
OR: da una attività, una sola di queste due viene attivata mentre l'altra non viene servita
(alternativa).
Ovviamente, se si hanno degli split, si hanno anche dei join: due attività in AND o in OR
potranno congiungersi in un join e quindi produrre un risultato unico che può essere usato
nei diagrammi di flusso corrispondenti.
Di base, le specifiche di questi linguaggi, si noti la stessa sigla, dicono pertanto, che si stanno
creando dei processi di business in base alla composizione di quello che esiste: non si fa nessuna
programmazione ma si lavora con uno script molto in alto,
Si è già detto, che questi linguaggi sono dei linguaggi grafici, quindi potrebbe essere possibile
rappresentare, in una qualche finestra, i diversi servizi disponibili, e magari collegarli graficamente
con delle frecce che specificano la correlazione tra i servizi stessi, e quindi quali parametri devono
andare nelle varie posizioni, consentendo pertanto di lavorare molto in alto.
BPEL4WS in realtà va un po' oltre, in quanto ci mette dentro anche la possibilità di input e di
output: è possibile aspettare dell'input, produrre dell'output intermedio, salvare su di un database ecc
ecc.
NOTA: I linguaggi di flusso non sono stati un area in cui c'è stata una qualche standardizzazione;
pertanto i WS definiscono il proprio linguaggio di workflow, e quindi danno un po' di chiarezza
effettivamente nell'ambito della suite intera.
NOTA: questi linguaggi di workflow, sono tipici degli ambienti d'impresa, difatti quando si compra
un sistema aziendale per le risorse aziendali, tipicamente al di dentro c'è qualcosa di questo genere,
magari chiamato con altre sigle ed ispirato ad altri standard, ma c'è sicuramente la possibilità di fare
del workflow.
67
A questo punto, dato come stanno le cose, la seconda proposta di standardizzazione parte da “sulla
base delle risorse interne ho creato dei WS i quali se ne stanno in un area e sono disponibili per
264
Stefano Di Monte
essere invocabili da qualunque ambiente di programmazione, secondo la logica SOA, in maniera
singola” ed arrivano alla creazione di un piano ex-novo, il piano di Orchestrazione in cui abbiamo i
linguaggi di flusso, i quali sono in grado di mettere insieme i diversi WS.
A questo punto, è possibile creare dei grafi, magari anche complessi, che saranno nient'altro che dei
nuovi WS che potranno essere invocati da chiunque: creiamo nuovi servizi sulla base di altri servizi!
Si amplia la fascia di utenza: chi può fare orchestrazione potrebbe essere qualcuno che non è in
grado di sviluppare un singolo servizio!
Pertanto, si dona una gestione dinamica, in particolare di management, ad utenti che, normalmente,
non sarebbero capaci di fare queste tipo di azioni veloci sul sistema, e ciò rappresenta sicuramente
una parte importante che ha ridato fiducia allo stack dei WS, e ha portato una nuova possibilità di
considerazione di applicazioni in modo più ampio aziendale.
Naturalmente, dietro a tutto ciò, vi è il piano del publishing, che rappresenta il piano delle discovery
agencies, che possono registrare, a questo punto, non solo i WS singoli ma anche i WS composti!
Stiam quindi dicendo che i servizi web si possono comporre: idea che va un po' oltre all'idea iniziale
dell'architettura SOA....
68
Il vantaggio sta nel fatto che si entra, in maniera più pesante, negli ambienti d'impresa: pertanto si
faccia riferimento a quella sigla vista nella seconda slide EAI.
Si comincia, pertanto, una forte integrazione, quindi uno spazio di utilizzo dei WS, nelle aree
gestionali d'impresa, quindi di tutta la parte amministrativa dell'impresa e di gestione.
69
Web 2.0 dice sicuramente che la rete è più sociale, e quindi che l'utente diventa protagonista della
rete fornendo contenuti e diventando parte attiva, ma dice anche una tecnologia: è evidente che il
web viene usato dai WS per fare delle richieste business, ma sono anche necessarie tutta una serie di
ottimizzazioni senza le quali non si fa nulla.
Mentre si parla di WS, in contemporanea si lavora con AJAX: è evidente che se dobbiamo chiedere
un informazione ad un server web e questo ci deve rinfrescare continuamente la pagina quando
cambiamo un dettaglio, se le cose sono come sono, saremo un tantino perduti....pertanto la
tecnologia AJAX consente di mantenere una pagina, su cui continuiamo a ricevere dati, cambiando,
quindi, solo i dati di cui effettivamente abbiamo bisogno, con una modalità di comunicazione molto
meno sincrona e molto meno bloccante dal punto di vista dell'utilizzatore finale che eventualmente
usa quella determinata pagina.
Reti di Calcolatori LM
265
Pertanto Web 2.0, per noi, dovrebbe dire soprattutto AJAX! (resta comunque che, per una utenza
molto ampia vuol dire anche altre cose).
Sicuramente, Web 2.0 potrebbe essere rappresentabile come una sorta di tecnologia panacea, ma
sappiamo benissimo che non è affatto così...
70
Facendo considerazioni piuttosto ampie sulle modalità di offerta tecnologica:
guardando il grafico in questa slide, il quale mostra dei periodi diversi di uso dei sistemi informatici,
si nota che:
-) si parte dai primi anni '80 in cui si offrivano solo dei terminali che facevano riferimento ad un
sistema centrale, quindi sistemi molto pesanti, peraltro concentrati tutti su di un unico data center.
Sicuramente, la presenza di terminali (remoti) rende necessaria la presenza di un sistema di gestione
(PNMS).
-) gli anni '90 segnano un po' di cambiamento: si comincia a lavorare con client/server, quindi
macchine clienti e macchine servitori con un po' di interazione tra loro.
-) periodo fine anni '90 – inizio anni 2000, vi sono una serie di Application Service Provider (ASP):
pertanto si comincia a lavorare col web e ci sono dei fornitori di applicazione che tipicamente
tendono a lavorare in casa del cliente, ad installare macchine le quali lavorano e producono e
lavorano con le applicazioni che sono state personalizzate per il cliente.
-) fine anni 2010 arriva il Web 2.0: si comincia a lavorare in modo più cooperativo, ed il web è uno
strumento un po' più usabile per ottenere dei servizi e soprattutto la banda che si è in grado di
fornire comincia a crescere e a dare qualità di fornitura, nasce la sigla di SaaS, ossia dei Software As
A Services.
In sostanza, comincia a proporsi la possibilità di avere il software come se fosse un servizio e non
come una fornitura tecnologica.
71
Così come per l'impianto elettrico casalingo, in cui non è assolutamente vero che per usufruire di
266
Stefano Di Monte
corrente elettrica devo avere la centrale elettrica in casa....così anche per il software: posso avere il
servizio software, di cui ho bisogno, quando ne ho realmente bisogno, e pago solamente per questo,
no di certo per le macchine, quindi per l'hardware, che non è un mio possedimento ma dell'azienda,
non pago tanto meno per lo sviluppo dell'applicazione, che non ho ma che è fatto da qualcun' altro.
Pertanto, sempre più, l' application service provider (ASP), è qualcuno che ha le sue macchine, le
sue applicazioni, e fornisce i servizi a chi ne ha bisogno, i quali servizi, sono veicolati tramite web!
72
In altri termini, il software è visto come un servizio, quindi con delle utilities, le quali non sono
tipicamente presenti presso chi ne ha bisogno, bensì verso un provider dei servizi. Quest'ultimo,
quindi, mostra i suoi servizi come delle “prese”, come delle appliences attraverso le quali è possibili
richiederli, che sono veicolate sul web: è possibile chiedere servizi tramite web quando ne ho
bisogno!
Questa idea è un idea molto importante per le aziende, le quali, a questo punto, cominciano a
distinguere in modo preciso dei ruoli diversi.
Ci sono, tutte le aziende che si occupano di fornitura dei servizi che si chiamano Provider;
quest'ultimi devono avere della apparecchiature hardware, delle competenze per fare software, per
gestire software, per mantenere software installandolo sulle macchine e fornire i servizi.
E poi ci sono i clienti, che banalmente devono avere, in sostanza, solo la “presa” per effettuerà la
richiesta e, di conseguenza, ottenere la risposta relativa alla richiesta fatta.
I due ruoli, sono pertanto, molto distinti!
Quest'idea non è solo un idea tecnologica, bensì è un idea anche molto usata in ambito
commerciale, anche di servizi materiali, e va sotto il modello di business che prende il nome di payper-use: non si pagano le risorse ma si paga per ciò che si usa!
Chiaramente, ci sono dei problemi, ad esempio:
<<i servizi forniti al cliente sono privati del cliente o sono condivisi?>>
Potrebbero essere divisi in due categorie...per l'appunto servizi condivisi e servizi privati.
<<Cosa succede se il servizio fosse condiviso da parte di clienti diversi?>>
Un servizio condiviso potrebbe ad esempio essere un servizio di produttività individuale, un work
processor, una suite di office, potrebbe essere ad esempio una gestione di magazzino, la quale però
ha i dati del magazzino dell'azienda, quindi <<è possibile garantire che tali dati siano
Reti di Calcolatori LM
267
necessariamente protetti se l'applicazione è condivisa?>>
Nascono quindi dei problemi di sicurezza....e quindi si ha la necessità di distinguere servizi
condivisi da quelli privati.
<<E se i servizi fossero privati, i dati dove risiedono?>>
Potrebbero essere sul provider....
<<E se fossero sul provider, potrei fidarmi di lasciare i miei dati a tal provider?>>
Basta fare l'esempio della mail d'ateneo....
73
Bisogna pertanto tener conto di qualche svantaggio intrinseco a tale tecnologia...
Ciò che è sicuro però, è che i due ruoli, provider e cliente, sono totalmente distinti!
Inoltre, il provider, che ha il software e lo sviluppa, potrebbe fare uno sviluppo più efficiente perché
può concentrare le risorse e metterle insieme per servire le richieste dei diversi clienti soprattutto se
ha un parco clienti abbastanza ampio.
Sicuramente il produttore del software è il responsabile delle cose, mentre il cliente non è
responsabile affatto dello sviluppo e pertanto, può interessarsi ad una serie di cose focalizzando
l'attenzione solo sulla parte di logica.
Inoltre, il cliente non ha il costo della cessione del prodotto; in realtà il cliente si allontana da tutta
le parti di produzione e soprattutto dai costi usuali che sussistono nel caso in cui si sviluppi qualcosa
in casa.
Ovviamente, tipicamente, ci sono dei costi inferiori per il servizio stesso: si paga il servizio
certamente, ma se lo si usa in maniera sporadica e rara lo si pagherà sicuramente di meno. Inoltre, al
cliente non è dato da pagare il costo delle risorse e dello sviluppo, ma solo della singola appliance
se viene usata e per quante volte viene usata.
Nella fornitura del servizio, il cliente inoltre, deve essere soddisfatto, pertanto devono esserci delle
interfacce ben fatte: tipicamente web 2.0: affinché l'utente abbia direttamente il risultato ed in modo
ottimizzato e non debba aspettare dei tempi infiniti ed inaccettabili.
Sicuramente, sviluppando, come produttori dei servizi, dal punto di vista di chi ha competenza, ci si
può permettere di fornire sempre il servizio aggiornato: se si hanno delle release nuove, quando
l'utente chiede il servizio ottiene pertanto il servizio con le ultime patch, senza i problemi riscontrati
precedentemente.
É evidente che non si può lavorare con SaaS, se non vi è una banda sufficiente!
Pertanto a volte è preferibile non usare SaaS....
74
Resta pertanto che, questo modello è comunque un modello molto importante.
Le aziende, dopo l'hype iniziale, han cominciato a capire che lo si può applicare solo in talune aree,
quali, quelle indicate in questa slide, ovvero le seguenti:
268
Stefano Di Monte
•
•
•
•
•
•
•
•
Office
Spreadsheets
Word
Graphics
Database
Document Management
Contacts
Project Management
Aree in realtà molto laterali per l'azienda perché, tipicamente, questi rappresentanodei servizi
abbastanza orizzontali, che quindi possono essere applicati in molti settori ma che non sono
essenziali per la vita dell'azienda.
Se si fa questo, la promessa dell' economist dice che SaaS potrebbe essere solo un vantaggio!
<<Ne siamo sicuri?>>
Applicandoli in modo giusto forse si...
75
Modello di sviluppo-on-site:
Lo sviluppo normale del sofware prevede che ci sia un data center presso il cliente, e che, se non ci
sono le competenze necessarie, allora ci sia qualcuno che è in grado di fare software sul data center
del cliente.
Pertanto il cliente deve pagare tutta l'installazione del data center ed anche chi è in grado di
sviluppare le cose, pertanto ha dei costi di implementazione molto elevati.
Naturalmente, in questo caso il software è all'interno dell'azienda, ed ogni qual volta che c'è da fare
una personalizzazione si necessita di qualcuno esterno all'azienda, un provider, che ci impiegherà i
suoi tempi; inoltre è difficile da modificare e da mantenere.
Sicuramente, in questo caso il software è personalizzato per l'utente, ma certamente con un costo
molto elevato.
76
Ovviamente, il modello del SaaS è un modello in house per il produttore del software che non si
Reti di Calcolatori LM
269
muove dall'azienda per la fornitura del software stesso, che quindi avviene attraverso semplicemente
il web.
Per SaaS vi sono due modelli, uno in cui i clienti condividono i servizi e l'altro in cui non vi è
condivisione.
Modello con servizi condivisi:
In tale modello vi sono molti clienti per una stessa applicazione.
D'altro canto però, in tal modo, il software non può pertanto essere troppo adattabile e
personalizzabile per l'utente.
NOTA: Naturalmente, maggiore è il parco clienti, maggiore è la possibilità del provider di usare
bene le sue risorse.
Un esempio è l'azienda Salesforce.com che fornisce servizi condivisi, ma non quelli
critici/essenziali per l'azienda, ed i suoi profitti sono molto alti.
77
Modello con servizi NON condivisi:
Ogni cliente ha un contratto molto preciso con ogni applicazione: il software che gli viene fornito
tramite web è di loro proprietà, pertanto è adattato e personalizzato per le esigenze di ciascun
cliente e non è condiviso con nessun' altro.
Questo richiede naturalmente costi superiori:
-) problema di garanzia della sicurezza
-) continuamento dei dati
-) una buona gestione delle risorse
Pertanto, in una situazione di software privato, in cui si fornisce il servizio al singolo cliente,
diventa molto importante la gestione automatica delle risorse.
In sostanza, quando si riceve una richiesta da qualcuno, bisognerebbe cercare di fornire la risposta
nei tempi detti, mettendo a disposizione di quella particolare richiesta di servizio dell'applicazione,
una serie di risorse, le quali vanno gestite molto rapidamente per fornire la relativa risposta con
certe qualità: pertanto bisogna essere in grado di fare una gestione automatica molto dinamica, in
grado di smistare le risorse su chi ne fa richiesta.
L'idea della gestione è molto importante senza la quale si fatica a lavorare!
270
Stefano Di Monte
Applicazione SaaS condivisa
Applicazione SaaS privata
78 – 79
Oltre a SaaS, esistono:
• Platform as a Service (PaaS)
Una piattaforma è un insieme integrato di applicazioni che forniscono servizi che sono integrati tra
di loro.
Muovendoci in questo contesto, in cui si hanno servizi in grado di coordinarsi, tipicamente anziché
avere la richiesta di un servizio, possiamo pensare di avere una ambiente disponibile, che è una
piattaforma, su cui i servizi che chiediamo possano essere mantenuti anche con uno stato, e con
delle possibilità di interazioni (un po' come se ci fosse dietro un work-flow) in grado di passare
dall'uno all'altro e di dare un coordinamento maggiore (anche se non si è dovuto specificare il workflow).
Un esempio semplice è l'esempio delle Google Maps, in cui è possibile inserire delle terze parti,
annotazioni, ecc ecc, in generale è possibile inserirvi servizi.
• Infrastructure as a Service (IaaS)
C'è anche la possibilità di lavorare in modo più ampio, soprattutto se non lavoriamo a livello
personale.
Supponendo che un azienda abbia esigenze, non solo di applicazioni coordinate, ma anche di avere
in alcuni casi la possibilità di avere delle macchine su cui lavorare, che siano installate con certi s.o.,
ecc ecc, in generale con caratteristiche precise, ma che non siano in house, che siano pertanto fuori.
A questo punto entrano in gioco le IaaS: è possibile fornire l'intera infrastruttura, macchine virtuali
e non, come provider in cambio sicuramente di un pagamento.
In sostanza si hanno dei provider di hardware che sono in grado di mettere a disposizione delle
macchine su cui è possibile installare le piattaforme di cui ce n'è bisogno, quindi S.O. e applicazioni
fino al livello più alto che venga in mente, e pertanto tali applicazioni, a questo punto, possono
girare.
Il gioco richiede, naturalmente, un supporto web che necessita una banda ancora più ampia!
Lavorando con IaaS, si tende ad avere una visione molto vicina al Cloud Computing.
In particolare, IaaS prevede la possibilità di avere delle macchine, che spesso sono interne
all'azienda, e che possono essere usate per le applicazioni di cui ce n'è bisogno, aggiungendo
applicazioni e togliendo applicazioni quando ce n'è bisogno; una gestione dinamica particolarmente
Reti di Calcolatori LM
271
importante.
Nel Clounding invece, ci sono dei provider di architettura che non sono l'azienda: le macchine sono
sul web e sono disponibili solo per chi sul web vuole sviluppare.
Pertanto, mentre la visione delle aziende proprietarie tende a garantire che si usino le risorse interne
aziendali; la visione del Cloud Computing è più ampia: ci sono nel web delle macchine disponibili
che possono essere utilizzate nel Cloud da qualcuno che ne ha bisogno, il quale può quindi, fare una
richiesta di macchine, sulle quali poi può pertanto richiedere certi S.O., certe sue applicazioni, le
quali vengono scaricate su tali macchine ed applicate nei momenti giusti.
L'esempio tecnicamente più significativo è Amazon: un sistema di WS che consente a chi ne ha
bisogno di ottenere dei servizi che però sono fatti su macchine che però sono disponibili
nell'infrastruttura Amazon.
Inoltre, Amazon ha una gestione del Cloud elastica: ha tutte le sue risorse, che sono al suo interno e
di provider, ed è in grado di dare le sue risorse a chi ne ha bisogno, perché la richiesta è tramite WS;
ha un integrazione di sistema tecnicamente molto interessante, in cui il software (già al suo interno
stoccato) e le macchine vengono gestite dinamicamente e date a chi ne ha bisogno in tempi molto
veloci, con la capacità di metter insieme risorse in modo molto rapido e con una console di gestione
che consentano all'utente esterno di capire quante macchine vi sono in un certo istante, quanto gli
costano, quanta memoria hanno ecc ecc e richiederne di più o di meno in base al fabbisogno.
In sostanza, sempre di più, i data center che sono spesso sui clienti, non lo sono più in quanto sono
delocalizzati: i clienti ottengono le risposte tramite Web, in particolare tramite Web Services!
272
Stefano Di Monte