I servizi web , nozioni di base. Slide presentate al corso post laurea per Data Scientist tenutosi a Marzo 2019 presso Fidia Trento.

1. Web services
Ing. Franco Morelli

2. Argomenti
1. Cosa sono i web services?
2. Come funzionano?
3. Perchè si usano?
4. Architettura
5. Componenti
6. Sicurezza
7. Implementazioni
8. Esempi
9. REST

3. Cosa sono i web services
• Web Services sono in grado di convertire l'applicazione in un'applicazione web
che può pubblicare la sue funzioni o messaggi sulla rete globale
• La piattaforma di base Web Services è XML + HTTP
• Applicazioni eseguite su web (Internet o Intranet) che forniscono servizi generici
• I servizi forniti attraverso il web sono in un formato standard che li rende generici
e indipendenti sulla piattaforma o dal protocollo su cui è stato richiesto il servizio.

4. Cosa sono i web services
• I servizi Web sono applicazioni Web based basate su standard aperti (XML,
SOAP, HTTP, ecc) che interagiscono con altre applicazioni web allo scopo di
scambiare dati
• Ci sono due modalità principali per offrire web services
- SOAP
- REST

5. Cosa sono i web services
Per riassumere, un servizio web completo è, quindi, qualsiasi servizio che:
• È disponibile su reti private (Intranet) o Internet
• Utilizza un sistema di messaggistica XML standardizzato
• Non è legato ad alcun sistema operativo o un linguaggio di programmazione
• È auto-descrittivo tramite una grammatica XML comune
• È rilevabile tramite un semplice meccanismo di scoperta

6. Perchè si usano
• Esponendo la funzione esistente sulla rete:
Un servizio Web è un'unità di codice gestito che può essere richiamato da remoto
tramite HTTP, cioè, può essere attivato tramite richieste HTTP. Così un Web
Services consente di esporre la funzionalità del vostro codice esistente attraverso
la rete. Una volta che è esposto sulla rete, altra applicazione può utilizzare la
funzionalità del programma.

7. Perchè si usano
• Connessione di diverse applicazioni cioè Interoperabilità:
Web Services permettono a diverse applicazioni di comunicare tra loro e
condividere dati e servizi. Altre applicazioni possono poi utilizzare i servizi di
servizi web. Per esempio VB o un'applicazione .NET può dialogare con servizi
Web Java e viceversa. Così, i servizi Web sono usato per rendere le applicazioni
indipendenti dalle piattaforme.

8. Perchè si usano
• Protocollo standardizzato:
Web Services utilizzano protocolli standard del settore per la comunicazione. Tutti
i quattro strati (Servizio di trasporto, XML Messaging, Descrizione del servizio e
Service Discovery) utilizzano un protocollo ben definito nello stack di protocollo
Web Services. Questa standardizzazione di stack di protocollo offre più affidabilità
alle applicazioni.

9. Perchè si usano
• Basso costo della comunicazione:
Web Services utilizzano SOAP su protocollo HTTP per la comunicazione, in modo
da poter utilizzare la rete internet esistente per l'implementazione dei servizi.
Accanto a SOAP su HTTP, i Web Services possono essere realizzati anche su
altri meccanismi di trasporto affidabili, come FTP, ecc

10. Architettura

11. Ruoli
• Fornitore di servizi: Questo è il fornitore del servizio web. Il fornitore di servizi
implementa il servizio e lo rende disponibile su Internet.
• Cliente del servizio: Questo è un qualsiasi consumatore del servizio web. Il
richiedente utilizza un servizio Web esistente aprendo una connessione di rete e
l'invio di una richiesta XML.
• Registro di sistema di servizio: Questa è una directory logica centralizzata dei
servizi. Il Registro di sistema fornisce un posto centrale in cui gli sviluppatori
possono pubblicare nuovi servizi o trovare quelli esistenti.

12. Uno stack
Layer 4 - UDDI (Service Discovery)
Layer 3 - WSDL (Descrizione)
Layer 2 - XML messaging
(XML,SOAP)
Layer 1 - Trasporto (HTTP,FTP…)

13. Uno stack
• Servizio trasporto: Questo strato è responsabile del trasporto dei messaggi tra le
applicazioni. Solitamente, questo strato si basa su HTTP ma può prevedere
SMTP, FTP
• Messaggistica XML: Questo strato è responsabile per la codifica dei messaggi in
formato XML comune in modo che i messaggi possano essere compresi ad
entrambe le estremità. Attualmente, questo strato include XML-RPC e SOAP.
• Descrizione del servizio: Questo strato è responsabile per descrivere l'interfaccia
pubblica di un servizio web specifico. Attualmente, descrizione del servizio viene
gestito tramite Web Service Description Language (WSDL).
• Servizio ricerca: Questo strato è responsabile per la centralizzazione dei servizi
in un registro comune, Universal Description, Discovery and Integration (UDDI).

14. Componenti
• SOAP (Simple Object Access Protocol) Protocollo basato su XML, usato per il
trasferimento dei messaggi
• WSDL (Web Service Description Language) file XML usato per descrivere il
servizio Web e come accedervi
• UDDI (Universal Description Discovery e Integration) utilizzato per la
registrazione e la ricerca di web service
• JAX-RPC per intercomunicazione
• HTTP per il trasferimento di messaggi

15. SOAP
1. SOAP l'acronimo di Simple Object Access Protocol
2. SOAP è un protocollo di comunicazione
3. SOAP è un formato per l'invio di messaggi
4. SOAP è stato progettato per comunicare via Internet
5. SOAP è indipendente dalla piattaforma
6. SOAP è indipendente dalla lingua
7. SOAP è basato su XML
8. SOAP è semplice ed estensibile
9. SOAP permette di aggirare firewall
10.SOAP è uno standard W3C

16. WSDL
1. WSDL significa Web Services Description Language
2. WSDL è XML based
3. WSDL è usato per descrivere Web services
4. WSDL è usato per localizzare Web services
5. WSDL è uno standard W3C

17. UDDI
1. UDDI sta per Universal Description, Discovery and Integration
2. UDDI è una directory per la memorizzazione di informazioni su servizi web
3. UDDI è una directory di interfacce di servizio web descritto da WSDL
4. UDDI comunica tramite SOAP

18. XML-RPC
1. XML-RPC è un semplice protocollo che utilizza messaggi XML per eseguire
RPC.
2. Le richieste sono codificati in XML e inviati tramite HTTP POST.
3. Le risposte XML sono incorporate nel corpo della risposta HTTP.
4. XML-RPC è indipendente dalla piattaforma.
5. XML-RPC consente a diverse applicazioni di comunicare.
6. XML-RPC è il modo più semplice per iniziare con i servizi web, più leggero
rispetto a SOAP.

19. Sicurezza
• Riservatezza
Se un client invia una richiesta XML a un server, siamo in grado di garantire che la
comunicazione rimanga riservata?
In generale
1. XML-RPC e SOAP run principalmente sulla parte superiore del HTTP.
2. HTTP ha il supporto per Secure Sockets Layer (SSL).
3. La comunicazione può essere crittografata tramite il protocollo SSL.
4. SSL è una tecnologia collaudata e diffusa.

20. Sicurezza
• Autenticazione
Se un client si connette a un servizio Web, come possiamo identificare l'utente? E
è l'utente autorizzato ad utilizzare il servizio?
Le seguenti opzioni possono essere prese in considerazione, ma non c'è un
chiaro consenso su quale sia lo schema di autenticazione forte
- HTTP include il supporto integrato per l’autenticazione Basic e Digest servizi
può quindi essere protetto più o meno allo stesso modo in cui i documenti
HTML sono attualmente protetti.

21. Sicurezza
Autentiicazione - continua
- Estensioni SOAP sicurezza: Firma digitale (SOAP-DSig). DSIG sfrutta la
crittografia a chiave pubblica per firmare digitalmente i messaggi SOAP.
Questo consente al client o server per convalidare l'identità della controparte.
- Security Assertion Markup Language SAML, si tratta di un formato di dati
standard aperto basato su XML per lo scambio dei dati di autenticazione e
autorizzazione tra le parti, in particolare, tra un provider di identità e un
fornitore di servizi.

22. Implementazione

23. REST VS SOAP
Soap è uno standard con delle regole ben precise ed uno schema molto rigido, basato sull’XML. Lo scambio di dati avviene
tramite degli “endpoint” che funzionano in base ad un “contratto” sulla modalità di scambio dati e di comunicazione.Tutta la
gestione delle risposte avviene, così come lo scambio di dati, tramite XML - e quindi occupa più banda, oltre al fatto che,
dovendo seguire uno schema molto rigido, è più complicato da implementare.E’ considerato più sicuro perchè ha moduli di
sicurezza incorporati. Lo si utilizza molto in ambito finanziario.
Rest è un’architettura, e quindi può essere implementanta in diversi modi. Oggi si usa molto spesso JSON per lo scambio dati,
perchè è fruibile facilmente sia dai client che dai server, oltre ad essere molto più leggero e semplice da usare (ma si può
implementare REST anche con XML, o addirittura SOAP). Le comunicazioni avvengono tramite URL, utilizzando delle
azioni che corrispondono ai verbi base propri del protocollo HTTP : GET, POST, PUT, DELETE, ecc. - e queste azioni agiscono
su oggetti che vengono definiti risorse: in pratica ogni dato è una risorsa che dev’essere presa, caricata, aggiornata, cancellata,
ecc. La comunicazione di errori o esiti positivi, a differenza di SOAP, qui NON avviene, ma è il protocollo HTTP ad essere
delegato a farlo con i suoi codici di errore specifici. Ad esempio, se con SOAP cerchiamo una risorsa e non la troviamo ci viene
restituito un XML con la comunicazione pre-concordata dell’esito, mentre con REST riceviamo soltanto uno status http (404) che
dobbiamo gestire.

24. REST
1. REST è sulle risorse e su come rappresentare le risorse in modi diversi.
2. REST è circa la comunicazione client-server.
3. REST è su come manipolare le risorse.
4. REST offre un modo semplice, interoperabile e flessibile di scrittura di servizi
web che può essere molto diverso da altre tecniche.
5. Non è uno standard

25. REST
Representional State Transfer
• E’ uno stile architettonico (tecnicamente non è uno standard)
• Idea: una rete di pagine web in cui il cliente progredisce attraverso
un'applicazione selezionando link
• Quando cliente attraversa collegamento, accede una nuova risorsa (trasferisce
lo stato)
• Utilizza gli standard esistenti, ad esempio, HTTP
• REST è un'architettura eminentemente sulla comunicazione client-server.

26. REST
• Client richiede una specifica risorsa al server.
• Il server rispondere a tale richiesta fornendo la risorsa richiesta.
• Server non dispone di informazioni su chi sia il client.
• Quindi, non v'è alcuna differenza tra le due richieste dello stesso client
• Un modello dove le rappresentazioni delle risorse sono trasferite tra il client e il
server.
• Il Web come lo conosciamo è già in questa forma

27. REST
• Le risorse sono mappature coerenti da un identificatore [come ad esempio un
percorso URL] a un insieme di viste sullo stato del server.
• Ogni risorsa deve essere univocamente indirizzabile tramite un URI. • “Se una
vista non soddisfa le tue esigenze, quindi sentitevi liberi di creare una risorsa
diversa che offre una vista adatta.
• Queste viste non hanno bisogno di nulla a che fare con il modo in cui le
informazioni vengono memorizzate sul server ... hanno solo bisogno di essere
comprensibili da parte del destinatario.

28. REST - RICHIESTE
REQUEST
GET /news/ HTTP/1.1
Host: example.org
Accept-Encoding: compress, gzip
User-Agent: Python-httplib2
La richiesta GET a : «http://example.org/news/»
Method = GET

29. REST - RISPOSTE
RESPONSE
HTTP/1.1 200 Ok
Date: Thu, 07 Aug 2008 15:06:24 GMT
Server: Apache
Content-Type: text/html
Cache-Control: max-age=3600
<!DOCTYPE HTML>

30. REST - RICHIESTE E RISPOSTE
La richiesta è fatta ad una risorsa identificata da URI(URI = Unified Resource
Identifier).
In questo caso, la risorsa è «http://example.org/news/»
L’indirizzamento delle risorse è molto importante

31. REST - URI
http: // localhost: 9999 / RestAPI / libri
• GET - ottenere tutti i libri
• POST - aggiungere un nuovo libro
http: // localhost: 9999 / RestAPI / libri / {id}
• GET - ottenere il libro con ID
• POST - aggiornare il libro con ID
• DELETE - eliminare il libro con ID

32. REST - OPERAZIONI CRUD
Creazione POST
Lettura GET
Aggiornamento PUT or POST
Cancellazione DELETE
Interfaccia uniforme per tutte le risorse, si usano i metodi HTTP