2 Ambiente che confina e sconfina con ambienti di business ed enterprise.

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