Cosa sono i servizi Web? ArchiTettura, Tipi, Esempio
Che cos'è il servizio Web?
servizio Web è un mezzo standardizzato per propagare la comunicazione tra le applicazioni client e server sul WWW (World Wide Web). Un servizio Web è un modulo software progettato per eseguire un determinato insieme di attività.
- I servizi web nel cloud computing possono essere ricercati in rete e richiamati di conseguenza.
- Quando richiamato, il servizio web sarà in grado di fornire la funzionalità al client, che invoca quel servizio web.
Come funzionano i servizi Web?

Il diagramma sopra mostra una visione molto semplicistica di come funzionerebbe effettivamente un servizio web. Il client invocherebbe una serie di chiamate al servizio web tramite richieste a un server che ospiterebbe il servizio web vero e proprio.
Queste richieste vengono effettuate tramite le cosiddette chiamate di procedura remota. Le chiamate di procedura remota (RPC) sono chiamate effettuate a metodi ospitati dal servizio Web pertinente.
Come esempio, Amazon fornisce un servizio web che fornisce prezzi per prodotti venduti online tramite amazon.com. Il front end o strato di presentazione può essere in .Net o Java ma entrambi i linguaggi di programmazione avrebbero la capacità di comunicare con il servizio web.
Il componente principale della progettazione di un servizio Web sono i dati che vengono trasferiti tra il client e il server, ovvero XML. XML (linguaggio di markup estensibile) è una controparte dell'HTML ed è il linguaggio intermedio di facile comprensione compreso da molti linguaggi di programmazione.
Pertanto, quando le applicazioni comunicano tra loro, in realtà parlano in XML. Ciò fornisce una piattaforma comune per le applicazioni sviluppate in vari linguaggi di programmazione per comunicare tra loro.
I servizi Web utilizzano qualcosa noto come SOAP (Simple Object Access Protocol) per inviare i dati XML tra le applicazioni. I dati vengono inviati tramite HTTP normale. I dati inviati dal servizio Web all'applicazione sono chiamati messaggi SOAP. Il messaggio SOAP non è altro che un documento XML. Poiché il documento è scritto in XML, l'applicazione client che chiama il servizio web può essere scritta in qualsiasi linguaggio di programmazione.
Perché hai bisogno di un servizio Web?
Le moderne applicazioni aziendali utilizzano una varietà di piattaforme di programmazione per sviluppare applicazioni basate sul Web. Alcune applicazioni potrebbero essere sviluppate in Java, altri in .Net, mentre altri in Angular JS, Node.js, ecc.
Molto spesso, queste applicazioni eterogenee hanno bisogno di una qualche forma di comunicazione tra loro. Dal momento che sono costruite utilizzando linguaggi di sviluppo diversi, diventa davvero difficile garantire una comunicazione accurata tra le applicazioni.
È qui che entrano in gioco i servizi Web. I servizi Web forniscono una piattaforma comune che consente più applicazioni basate su vari elementi linguaggi di programmazione avere la capacità di comunicare tra loro.
Tipo di servizio Web
Esistono principalmente due tipologie di servizi web.
- Servizi web SOAP.
- Servizi web RESTful.
Affinché un servizio web sia pienamente funzionale, è necessario che siano presenti alcuni componenti. Questi componenti devono essere presenti indipendentemente dal linguaggio di sviluppo utilizzato per programmare il servizio web.
Diamo un'occhiata a questi componenti in modo più dettagliato.
SOAP (protocollo di accesso semplice agli oggetti)
SOAP è noto come protocollo di messaggistica indipendente dal trasporto. SOAP si basa sul trasferimento di dati XML come messaggi SOAP. Ogni messaggio ha qualcosa che è noto come documento XML. Solo la struttura del documento XML segue uno schema specifico, ma non il contenuto. La parte migliore dei servizi Web e SOAP è che vengono tutti inviati tramite HTTP, che è il protocollo Web standard.
Ecco in cosa consiste un messaggio SOAP
- Ogni documento SOAP deve avere un elemento radice noto come elemento. L'elemento root è il primo elemento in un documento XML.
- La “busta” è a sua volta divisa in 2 parti. Il primo è l'intestazione e il successivo è il corpo.
- L'intestazione contiene i dati di instradamento che sono fondamentalmente le informazioni che indicano al documento XML a quale client deve essere inviato.
- Il corpo conterrà il messaggio vero e proprio.
Lo schema seguente mostra un semplice esempio di comunicazione tramite SOAP.
Discuteremo SOAP in dettaglio in questo lezione.
WSDL (linguaggio di descrizione dei servizi Web)
Un servizio web non può essere utilizzato se non può essere trovato. Il client che invoca il servizio web dovrebbe sapere dove risiede effettivamente il servizio web.
In secondo luogo, l'applicazione client deve sapere cosa fa effettivamente il servizio Web, in modo da poter invocare il servizio Web corretto. Ciò avviene con l'aiuto del WSDL, noto come linguaggio di descrizione dei servizi Web. Il file WSDL è ancora una volta un file basato su XML che sostanzialmente dice all'applicazione client cosa fa il servizio web. Utilizzando il documento WSDL, l'applicazione client sarebbe in grado di capire dove si trova il servizio web e come può essere utilizzato.
Esempio di servizio Web
Di seguito viene fornito un esempio di servizi Web di un file WSDL.
<definitions> <message name="TutorialRequest"> <part name="TutorialID" type="xsd:string"/> </message> <message name="TutorialResponse"> <part name="TutorialName" type="xsd:string"/> </message> <portType name="Tutorial_PortType"> <operation name="Tutorial"> <input message="tns:TutorialRequest"/> <output message="tns:TutorialResponse"/> </operation> </portType> <binding name="Tutorial_Binding" type="tns:Tutorial_PortType"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="Tutorial"> <soap:operation soapAction="Tutorial"/> <input> <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:examples:Tutorialservice" use="encoded"/> </input> <output> <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:examples:Tutorialservice" use="encoded"/> </output> </operation> </binding> </definitions>
Gli aspetti importanti da notare sugli esempi di dichiarazioni WSDL dei servizi web sopra riportati sono i seguenti:
- – Il parametro message nella definizione WSDL viene utilizzato per definire i diversi elementi di dati per ciascuna operazione eseguita dal servizio web. Pertanto, negli esempi di servizi Web precedenti, abbiamo 2 messaggi che possono essere scambiati tra il servizio Web e l'applicazione client, uno è "TutorialRequest" e l'altro è l'operazione "TutorialResponse". Il TutorialRequest contiene un elemento chiamato “TutorialID” che è del tipo stringa. Allo stesso modo, l'operazione TutorialResponse contiene un elemento chiamato "TutorialName" che è anche una stringa di tipo.
- – Qui viene infatti descritta l'operazione che può essere svolta dal servizio web, che nel nostro caso si chiama Tutorial. Questa operazione può richiedere 2 messaggi; uno è un messaggio di input e l'altro è il messaggio di output.
- – Questo elemento contiene il protocollo utilizzato. Quindi, nel nostro caso, lo stiamo definendo per utilizzare http (http://schemas.xmlsoap.org/soap/http). Specifichiamo anche altri dettagli per il corpo dell'operazione, come lo spazio dei nomi e se il messaggio deve essere codificato.
Discuteremo "WDSL" in dettaglio in questo lezione.
universale Descriptioni, scoperta e integrazione (UDDI)
UDDI è uno standard per descrivere, pubblicare e scoprire i servizi Web forniti da un particolare fornitore di servizi. Fornisce una specifica che aiuta a ospitare le informazioni sui servizi web.
Nell'argomento precedente abbiamo ora discusso del WSDL e di come contenga informazioni su ciò che effettivamente fa il servizio Web. Ma come può un'applicazione client individuare un file WSDL per comprendere le varie operazioni offerte da un servizio web? Quindi UDDI è la risposta a questa domanda e fornisce un repository su cui possono essere ospitati i file WSDL. Quindi l'applicazione client avrà accesso completo all'UDDI, che funge da database contenente tutti i file WSDL.
Proprio come un elenco telefonico contiene il nome, l'indirizzo e il numero di telefono di una determinata persona, allo stesso modo il registro UDDI avrà le informazioni rilevanti per il servizio web. In modo che un'applicazione client sappia dove può essere trovata.
Vantaggi dei servizi Web
Sappiamo già perché sono nati i servizi web, ovvero fornire una piattaforma che potesse consentire a diverse applicazioni di comunicare tra loro.
Ma diamo un'occhiata all'elenco dei vantaggi dei servizi web e scopriamo perché è importante utilizzare i servizi web.
- Esporre le funzionalità aziendali sulla rete – Un servizio Web è un'unità di codice gestito che fornisce una sorta di funzionalità alle applicazioni client o agli utenti finali. Questa funzionalità può essere richiamata tramite il protocollo HTTP, il che significa che può essere richiamata anche tramite Internet. Al giorno d'oggi tutte le applicazioni sono su Internet, il che rende più utile lo scopo dei servizi Web. Ciò significa che il servizio web può trovarsi ovunque su Internet e fornire le funzionalità necessarie secondo necessità.
- Interoperabilità tra le applicazioni – I servizi Web consentono a diverse applicazioni di dialogare tra loro e di condividere tra loro dati e servizi. Tutti i tipi di applicazioni possono comunicare tra loro. Quindi, invece di scrivere codice specifico che può essere compreso solo da applicazioni specifiche, ora puoi scrivere codice generico che può essere compreso da tutte le applicazioni
- Un protocollo standardizzato comprensibile a tutti – I servizi Web utilizzano un protocollo industriale standardizzato per la comunicazione. Tutti e quattro i livelli (Service Transport, XML Messaging, Service Description e livelli di Service Discovery) utilizza protocolli ben definiti nello stack di protocolli dei servizi Web.
- Riduzione dei costi di comunicazione – I servizi Web utilizzano il protocollo SOAP su HTTP, quindi puoi utilizzare la tua connessione Internet a basso costo esistente per implementare i servizi Web.
Servizi web Architectura
Ogni framework necessita di una sorta di architettura per garantire che l'intero framework funzioni come desiderato, allo stesso modo, nei servizi Web. Servizi web Architectura è composto da tre ruoli distinti come indicato di seguito:
- Provider – Il provider crea il servizio web e lo rende disponibile alle applicazioni client che desiderano utilizzarlo.
- Richiedente – Un richiedente non è altro che l'applicazione client che deve contattare un servizio web. L'applicazione client può essere un file .Net, Javao qualsiasi altra applicazione basata sul linguaggio che cerca qualche tipo di funzionalità tramite un servizio web.
- Broker – Il broker non è altro che l'applicazione che fornisce l'accesso all'UDDI. L'UDDI, come discusso nell'argomento precedente, consente all'applicazione client di individuare il servizio Web.
Il diagramma seguente mostra come il fornitore del servizio, il richiedente del servizio e il registro del servizio interagiscono tra loro.
- Pubblica – Un fornitore informa il broker (registro del servizio) sull'esistenza del servizio web utilizzando l'interfaccia di pubblicazione del broker per rendere il servizio accessibile ai clienti
- Trovate – Il richiedente consulta il broker per individuare un servizio web pubblicato
- legante – Con le informazioni ottenute dal broker (registro del servizio) sul servizio web, il richiedente è in grado di associare o invocare il servizio web.
Caratteristiche del servizio web
I servizi Web presentano le seguenti caratteristiche comportamentali particolari:
- Sono basati su XML – I servizi Web utilizzano XML per rappresentare i dati a livello di rappresentazione e trasporto dei dati. L'utilizzo di XML elimina qualsiasi tipo di dipendenza dalla rete, dal sistema operativo o dalla piattaforma poiché XML è il linguaggio comune compreso da tutti.
- Debolmente accoppiato – Loosely coupled significa che il client e il servizio web non sono vincolati l'uno all'altro, il che significa che anche se il servizio web cambia nel tempo, non dovrebbe cambiare il modo in cui il client chiama il servizio web. L'adozione di un'architettura loosely coupled tende a rendere i sistemi software più gestibili e consente un'integrazione più semplice tra sistemi diversi.
- Syncfunzionalità asincrona o sincronizzata - Synchronicity si riferisce al legame del client all'esecuzione del servizio. Nelle operazioni sincrone, il client attenderà effettivamente che il servizio Web completi un'operazione. Un esempio di ciò è probabilmente uno scenario in cui viene eseguita un'operazione di lettura e scrittura del database. Se i dati vengono letti da un database e successivamente scritti in un altro, le operazioni devono essere eseguite in modo sequenziale. Le operazioni asincrone consentono a un client di richiamare un servizio e quindi eseguire altre funzioni in parallelo. Questa è una delle tecniche comuni e probabilmente la più preferita per garantire che altri servizi non vengano interrotti quando viene eseguita una particolare operazione.
- Capacità di supportare chiamate di procedura remota (RPC) – I servizi Web consentono ai client di richiamare procedure, funzioni e metodi su oggetti remoti utilizzando un protocollo basato su XML. Le procedure remote espongono parametri di input e output che un servizio Web deve supportare.
- Supporta lo scambio di documenti – Uno dei principali vantaggi di XML è il suo modo generico di rappresentare non solo dati ma anche documenti complessi. Questi documenti possono essere semplici come rappresentare un indirizzo corrente, o possono essere complessi come rappresentare un intero libro.