Web services

Architettura SOA 

L’architettura web 2.0 introduce dinamismo e condivisione tra utenti, ma resta ancorata all’idea che i client siano dei browser che girano su computer con potenza limitata. Come sappiamo oggi non è così: i pc di oggi hanno potenze significative, hanno funzionalità molto variebage e poi non esistono più solo i pc. Oggi il dispositivo più diffuso al mondo è lo smartphone e ad esso si affiancano parecchi tipi di dispositivi “connessi”, come i wearable, le smartTV, i dispositivi di realtà aumentata, la domotica, l’IoT industriale. Che siano computer o no, questi dispositivi non usano il web solo per “navigare”, ma hanno app dedicate a svolgere una molteplicità di funzioni: streaming audio e video, giochi, produzione di contenuti, effettuare video comunicazioni, ecc. il browser diventa quindi una funzione addirittura minoritaria rispetto alle applicazioni possibili della connettività. E quindi il modello web 2.0 è poco funzionale a questo tipo di applicazioni.

A partire dai primi anni 2000 ha cominciato ad essere applicata l’idea dell’utilizzo del protocollo HTTP anche per scambiare dati tra client e server, dove il server diventa quindi un sistema che eroga servizi non più a persone dietro ad un browser, ma ad altre applicazioni connesse.

Questa architettura prende il nome di “SOA” (Service Oriented Architecture), dove i servizi sono operazioni richieste al server, ad esempio “esegui un bonifico”, oppure “invia una email”. Il server SOA non invia al client una pagina HTML già pronta, ma invia direttamente i dati, e quindi diventa compito del client gestirli, filtrarli, mostrarli all’utente in forma usabile, e gestire quindi anche il processo inverso, e rimandarle al server sotto forma di dati. Il client diventa un dispositivo “intelligente” ed assume un ruolo più centrale.

L’architettura SOA è in realtà più antica del Web, ed esistono tecnologie basate su SOA antecedenti (come CORBA e RPC), ma è solo grazie ad HTTP che l’architettura SOA viene usata in modo massiccio, grazie alle tecnologie come SOAP, REST e successive. L’architettura SOA applicata al Web prende il nome di Web Services. Esploriamo i Web Service analizzando tre concetti fondamentali:

• i formati dati
• API remote
• SOAP
• REST

XML e JSON

I Web Services non usano HTML (che è un formato pensato per gestire ipertesti e contenuti già formattati per l’utente). Sono quindi stati progettati formati dati. Il primo di questi è il linguaggio XML, un linguaggio di markup che anzichè usare tag fissi come in html, utilizza dei tag dinamici, con una sintassi che permette di essere letto da un essere umano, ma al contempo con un formalismo validabile anche da un sistema automatico. XML è un formato dati molto flessibile perchè permette di trasportare, nel file di testo, anche informazioni strutturate, descrizione di funzioni, dati formattati e strutturati anche in modo complesso. Qui un esempio di XML:

<!DOCTYPE lettera SYSTEM “lettera.dtd”> 
<lettera> 
        <destinatario>
               <nome>Sandro Bianchi </nome> 
               <sede>Ufficio di Roma</sede>
        </destinatario>
        <corpo>
               <titolo>Riunione</titolo>
               <testo>La riunione è fissata giovedi alle 9.30</testo> 
        </corpo>
</lettera>

XML è un formato di scambio dati di enorme diffusione, e non viene usato solo nel web. Ad esempio molti formati dati odierni sono in realtà formati XML, ad esempio i formati Word (docx), Excel (xlsx) sono tutti formati XML aperti.

Il formato JSON (Javascript Object Notation) è stato svluppato successivamente, con la diffusione del linguaggio Javascript, ed è un formato dati che consente di condividere strutture dati come liste, tabelle e record di database. E’ molto meno verboso di XML, ma è anche più limitato in quanto non consente di definire anche regole nella struttura dei dati, come campi obbligatori, liste di valori possibili, ordine di sequenza dei dati, ecc. E’ comunque estremamente efficace quando non servono regole troppo rigide sui dati. Anche JSON è usato fuori dal web, ad esempio è il formato nativo di alcune tecnologie di database, come Mongo e CouchDB. Qui un esempio di JSON:

[

  {

    "id": 4836,

    "uid": "e16e7e38-7278-48a0-8848-3f8fb5551796",

    "brand": "Corona Extra",

    "name": "Shakespeare Oatmeal",

    "style": "Merican Ale",

    "hop": "Sorachi Ace",

    "yeast": "3944 - Belgian Witbier",

    "malts": "Roasted barley",

    "ibu": "58 IBU",

    "alcohol": "6.3%",

    "blg": "18.4°Blg"

  },

  {

    "id": 4743,

    "uid": "c259e016-2a86-4c44-9a27-93ff46fd871a",

    "brand": "Corona Extra",

    "name": "Ten FIDY",

    "style": "Vegetable Beer",

    "hop": "Mt. Rainier",

    "yeast": "2308 - Munich Lager",

    "malts": "Chocolate",

    "ibu": "96 IBU",

    "alcohol": "7.4%",

    "blg": "12.3°Blg"

  },

  {

    "id": 122,

    "uid": "588a0b25-dc51-4736-af3e-f3f12a316608",

    "brand": "Pabst Blue Ribbon",

    "name": "Ruination IPA",

    "style": "Strong Ale",

    "hop": "Liberty",

    "yeast": "3763 - Roeselare Ale Blend",

    "malts": "Black malt",

    "ibu": "77 IBU",

    "alcohol": "7.3%",

    "blg": "14.7°Blg"

  }]

API remote e middleware

Una API remota è una interfaccia di programmazione tra due software tra di loro indipendenti ma connessi tramite Internet, dove un software (lato server) fornisce dei servizi ad un altro (lato client). L’API è definita da quello che possiamo definire un “contratto” tecnico, che definisce quali sono le risorse erogate, il tipo di dati scambiato, le modalità di comunicazione. Una API remota è in genere gestita da un modulo o un componente di una applicazione che si occupa di implementare il contratto e fornire internamente all’applicazione i servizi per utilizzarla. Questo componente prende il nome di middleware, ed ha quindi lo scopo di implementare sia lato server che lato cliente rendendo trasparente l’utilizzo della API remota nel resto dell’applicazione a cui è collegato.

Ad esempio, ipotizziamo di avere un servizio che restituisce i dati meteo di un determinato luogo. L’API remota che fornisce trasmette i dati in formato JSON, e richiede in input le coordinate in un determinato formato, e restituisce in uscita la temperatura in gradi Celsius. Una API può inoltre fornire regole e metodologie di autenticazione, di integrità e di consistenza del dato, tramite un sistema che garantisca gli accessi e l’identificazione del client. Il middleware traduce queste richieste in un formato compatible col linguaggio di programmazione usato, sia lato server e lato client. E’ importante capire che siccome la comunicazione passa sempre per HTTP, client e server possono essere sviluppati con tecnologie e linguaggi differenti, anche nei middleware, purché rispettino il contratto.

L’approccio utilizzato nella realizzazione di API remote si è – da sempre – diviso intorno a due possibili concezioni: l’API come “funzione” o l’API come “risorsa”.

• Nell’approccio basato su “funzione”, l’API mette a disposizione delle funzioni, quindi dei servizi che svolgono delle azioni vere e proprie. Ad esempio una API di questo tipo potrebbe fornire la funzione “login(nome, password)” che riceve come parametro due stringhe e restituisce come risposta un codice di sessione. Il middleware si occupa di trasformare l’astrazione legata all’azione in oggetti ed incapsularla in oggetti trasmissibili via HTTP. Il middleware client trasforma i parametri della richiesta di funzione in un oggetto inviabile e poi li invia al server, mentre il middleware lato server riceve questi dati e in base a questi richiama la libreria che svolge il servizio richiesto (che è del tutto ignara che il servizio sia richiesto da un client remoto). La risposta avviene con la stessa modalità, in senso opposto. Il modello basato su funzione ha origini storiche molto lontane (da RPC) ed ha l’obiettivo di semplificare il lavoro del programmatore, sia lato client che lato server, che deve avere la percezione di scrivere applicazioni connesse ma dove non deve occuparsi del dettaglio della connessione HTTP, ma ragionare come se fosse una unica grande applicazione. Vedremo qui sotto SOAP è la più nota tecnologia di questo tipo.

• Nell’approccio basato su “risorse” invece l’API mette a disposizione direttamente i dati. Ad esempio il client invia sempre tramite un middleware (molto più semplice) un oggetto contenente gli elementi della richuiesta ad una determinata URL che indica direttamente il tipo di azione richiesta. La URL identifica univocamente la risorsa ed il middleware lato server che gestisce quella URL analizza i dati ricevuti, chiama il servizio apposito che restituisce il risultato che viene di nuovo impacchettato e rispedito al client. Un middleware di questo tipo non è “trasparente” per il programmatore, che è quindi consapevole che sta sviluppando una applicazione dove client e server sono remoti tra loro: la separazione è netta, il client non usa funzioni del server, ma richiede ed invia solo dati, identificati da risorse identificate univocamente da URL. Questo modello è alla base della tecnologia REST.

SOAP Web Service

SOAP implementa API remote secondo un modello basato su oggetti e funzioni ed usa il formato XML. Tramite questo protocollo si incapsula in un pacchetto XML l’intero oggetto con le sue funzioni, lo stato e i metodi, e quindi permette, anche tra più chiamate distinte, di lavorare sugli stessi dati superando quindi anche il limite di sessione del protocollo HTTP.

L’obiettivo di SOAP è quello di rendere “trasparente” l’uso di funzioni remote sul server come se fossero eseguite sul pc client: in pratica il client richiama un metodo di una libreria SOAP, la libreria trasforma l’oggetto in un XML^[5] e questo XML viene inviato al server, che lo ritrasforma in oggetto, esegue la funzione, e poi esegue la procedura al contrario. In pratica il programmatore che sviluppa il client lavora come se utilizzasse un oggetto locale.

Qui uno schema di Web Service SOAP.

Le tecnologie basate su web application e su servizi SOAP sono state le grandi protagoniste a partire dai primi anni 2000, diventando lo standard della comunicazione su web, ed ancora oggi hanno una enorme diffusione in particolare in tutta l’industria “enterprise”, in particolare nel mondo finanziario, bancario, energia e telecomunicazioni. I linguaggi di programmazione principalmente utilizzati sono Java e C#, che dispongono di numerosi strumenti a supporto.

SOAP è molto efficace per gestire applicazioni connesse ma ha anche un insieme di limitazioni:

• le web applications, proprio per la relativa complessità dei passaggi sopra visti, hanno una latenza^[6] significativa quando si deve eseguire una applicazione “in tempo reale” (es. streaming, chat, videogioco, ecc.). Questa è dovuta alla complessità di aggiornare una intera pagina anche quando servono solo nuovi dati. Questo è inaccettabile in una chat o in un videogioco. 
• SOAP permette al programmatore una grande astrazione, tuttavia può diventare molto oneroso in termini di tempo e risorse da utilizzare a causa dell’overhead^[7] legato alla creazione dell’XML.
• Nel 2000 esisteva una forte disparità di prestazioni tra client e server. Questo significava che il client dovevano necessariamente demandare la maggior parte delle operazioni logiche ai server ed era quindi necessario fare richieste complesse. Oggi i PC (e i tablet e gli smartphone) sono in grado di eseguire applicazioni anche onerose e questa grande potenza di calcolo può essere usata per sostituirsi a molte elaborazioni lato server. Considerati i costi di mantenimento di una infrastruttura lato server, diventa economicamente conveniente spostare il più possibile le attività applicative direttamente nei client ed utilizzare la rete solo per scambiare dati grezzi.
• La nascita dello streaming ha mostrato poi i limiti di una tecnologia web pensata solo come “siti e pagine” in cui l’utente si connette, fa una richiesta, scarica la pagina e poi si disconnette. Lo streaming è tutto l’opposto: l’utente è perennemente connesso e continuamente riceve dati. Per realizzare questo meccanismo significa predisporre una tecnologia che richiede costantemente pacchetti (molti pacchetti in contemporanea) che vengono inviati al client che li ricostruisce e ricrea il flusso video. E’ quindi necessario non avere basse latenze, ma un ottimo throughput^[8]. 

Sono tutte problematiche importanti ed ancora oggi aperte^[9], per le quali l’evoluzione tecnologica è ancora in corso, e per cui sono state elaborate diverse soluzioni. Tra queste vi è REST che comunque risolve solo parzialmente i problemi sopra esposti.

REST Web service

REST è una tecnologia di API basata sul concetto di risorsa, che può utilizzare sia il formato XML che il formato JSON, e che si basa sul principio di trasportare solo dati. REST da molta importanza a fornire una interfaccia basata sui dati che si basi il più possibile su HTTP, e quindi le URL e il metodo HTTP assumono un ruolo fondamentale per indicare che tipo di operazione si vuole svolgere. L’argomento è approfondito nella lezione API REST.

Rich Internet Applications (RIA)

Con il miglioramento della potenza di calcolo delle macchine client, il linguaggio Javascript, inizialmente un semplice linguaggio di script che aggiungeva qualche animazione alla pagina web, viene migliorato fino a diventare un importante strumento a disposizione per trasformare una pagina web interattiva in una vera e propria applicazione. 

Viene introdotta prima di tutto la tecnologia AJAX, ovvero una libreria Javascript che permette di effettuare HTTP request/response senza ricaricare la pagina. In secondo luogo Javascript viene potenziato come linguaggio (versione 5 – 2009 e soprattutto versione 6 – 2015) diventando un vero e proprio linguaggio ad alto livello, con il controllo completo della pagina HTML, il salvataggio di dati su un db locale, la gestione delle websocket, ecc.

Questo ha reso possibile realizzare non più solo siti web più o meno statici, ma vere e proprie pagine dinamiche che sono in grado di ricostruire la propria struttura grafica html grazie al Javascript. Questo nuovo tipo di applicazioni si chiama RIA, e costituisce ormai uno standard consolidato del web a partire dal 2015. Da Javacript si è poi sviluppato Typescript, linguaggio fortemente orientato a gestire flussi di dati e che assomiglia molto a Java e C#.

C’è poi da considerare il mondo mobile. Lo sviluppo cellulari e tablet ha dato vita ad un nuovo tipo di applicazioni, le applicazioni mobile. Queste applicazioni – differenti per diversi aspetti alle applicazioni desktop – sono andate ad affiancare i browser come principali client HTTP nel consumare risorse senza passare dall’HTML. Sono emersi nuovi linguaggi ed architetture per gestire lo sviluppo di software lato client “connesso”, come Swift e Kotlin, linguaggi multithreading compilati pensati appositamente per gestire applicazioni e flussi di comunicazione basati su http.

Anche nel mobile SOAP è stata col tempo sostituita dalla tecnologia REST , che usa come formato dati JSON. Per le applicazioni a bassissima latenza, si sono infine sviluppate le Websocket, una forma speciale di connettività, basata sempre su HTTP, che crea delle socket (connessioni permanenti) per inviare e ricevere dati a livello applicativo.

Qui una tipica architettura REST, argomento che approfondiremo in una specifica lezione. Websocket ne è una estensione che si basa sui medesimi principi.

Conclusioni

Qui uno specchietto riassuntivo.

E’ importante capire che Web application lato server, SOA, SOAP e REST sono tutte tecnologie ed architetture che coesistono ancora oggi e si sono evolute in modo parallelo ed indipendente. Le Web Applications di oggi non sono le stesse dei primi anni 2000: esistono librerie e framework che permettono di semplificare enormemente il lavoro dello sviluppatore e realizzare siti web a partire da poche istruzioni. Quindi tecnologie più datate come PHP o Java sono riuscite a limitare il problema dell’obsolescenza rinnovandosi per stare al passo coi tempi ed ancora oggi sono le più diffuse.

Inoltre come si vede architettura Web Application e SOA hanno un confine molto sfumato lato server: con gli stessi linguaggi e strumenti si possono creare entrambe ed esistono anche molte applicazioni sviluppate per erogare contenuti sia in HTML (come siti web) o XML/JSON (come web services). Vedremo questo quando analizzeremo queste architetture dal punto di vista dello sviluppatore.

^[4] Non confondere SOA (che è una architettura) con SOAP (che è una tecnologia specifica che usa specificatamente XML e si usa principalmente con HTTP). 

^[5] Questa operazione di trasformazione viene chiamata “marshaling” o “serializzazione”.

^[6] La latenza è il tempo che intercorre tra una richiesta e la relativa risposta. E’ una delle due principali metriche per misurare le prestazioni di un sistema informatico.

^[7] L’overhead è il costo (in termini di risorse) usato per soddisfare i formalismi di un sistema informatico: intestazioni dei pacchetti, regole di validazione, tempo di codifica/decodifica, ecc. sono extradati presenti nel flusso di comunicazione che non contengono informazione. Talvolta sono utili o necessari (a fini della sicurezza o della correttezza) altre volte no.

^[8] Il throughput indica il numero di richieste eseguite per unità di tempo (es. 300 richieste al secondo). E’ l’altra principale metrica per misurare le prestazioni di un sistema informatico.

^[9] ad oggi ci sono molte applicazioni nuove, come la realtà aumentata, l’IoT, il metaverso, ecc. che mettono in evidenza diversi limiti anche dello stesso protocollo http.