I servizi Web sono applicazioni Web basate su standard aperti (XML, SOAP, HTTP ecc.) Che interagiscono con altre applicazioni Web allo scopo di scambiare dati. I servizi Web possono convertire le applicazioni esistenti in applicazioni Web.

Di seguito sono riportate le caratteristiche del servizio Web:

  • È disponibile su Internet o su reti private (intranet).

  • Utilizza un sistema di messaggistica XML standardizzato.

  • Non è legato a nessun sistema operativo o linguaggio di programmazione.

  • Si autodefinisce tramite una comune grammatica XML.

  • È rilevabile tramite un semplice meccanismo di ricerca.

La piattaforma di servizi Web di base è XML + HTTP. Tutti i servizi web standard funzionano utilizzando i seguenti componenti:

  • SOAP (Simple Object Access Protocol)

  • UDDI (Universal Description, Discovery and Integration)

  • WSDL (Web Services Description Language)

Un servizio Web consente la comunicazione tra varie applicazioni utilizzando standard aperti come HTML, XML, WSDL e SOAP.

È possibile creare un servizio Web basato su Java su Solaris accessibile dal programma Visual Basic in esecuzione su Windows.

È inoltre possibile utilizzare C # per creare nuovi servizi Web su Windows che possono essere richiamati dall'applicazione Web basata su JSP (JavaServer Pages) e eseguita su Linux.

Un servizio web richiede l'aiuto di XML per etichettare i dati, formattare i dati.

Un servizio web utilizza l'aiuto di SOAP per trasferire un messaggio.

Un servizio Web utilizza l'aiuto di WSDL per descrivere la disponibilità del servizio.

Di seguito sono riportati i vantaggi dell'utilizzo dei servizi Web:

  • Exposing the Existing Function on the network- I servizi Web consentono di esporre la funzionalità del codice esistente sulla rete. Una volta esposto sulla rete, un'altra applicazione può utilizzare le funzionalità del programma.

  • Interoperability - I servizi Web consentono a varie applicazioni di dialogare tra loro e condividere dati e servizi tra di loro.

  • Standardized Protocol- I servizi Web utilizzano un protocollo standard del settore standard per la comunicazione. Tutti e quattro i livelli (trasporto del servizio, messaggistica XML, descrizione del servizio e livello di rilevamento del servizio) utilizzano protocolli ben definiti nello stack di protocolli dei servizi Web.

  • Low Cost of Communication - I servizi Web utilizzano il protocollo SOAP su HTTP, quindi è possibile utilizzare Internet a basso costo esistente per implementare i servizi Web.

I servizi Web consentono a varie applicazioni di dialogare tra loro e condividere dati e servizi tra di loro. Anche altre applicazioni possono utilizzare i servizi web. Ad esempio, un'applicazione VB o .NET può comunicare con i servizi Web Java e viceversa. I servizi Web vengono utilizzati per rendere la piattaforma dell'applicazione e la tecnologia indipendenti.

Un consumatore di un servizio web non è legato direttamente a quel servizio web. L'interfaccia del servizio web può cambiare nel tempo senza compromettere la capacità del cliente di interagire con il servizio. Un sistema strettamente accoppiato implica che la logica del client e del server sono strettamente legate l'una all'altra, il che implica che se un'interfaccia cambia, l'altra deve essere aggiornata. L'adozione di un'architettura debolmente accoppiata tende a rendere i sistemi software più gestibili e consente un'integrazione più semplice tra sistemi diversi.

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 i parametri di input e output che un servizio Web deve supportare.

Negli ultimi due anni lo sviluppo di componenti tramite Enterprise JavaBeans (EJB) e .NET Components è diventato sempre più parte delle architetture e delle distribuzioni aziendali. Entrambe le tecnologie sono distribuite e accessibili tramite una varietà di meccanismi RPC.

Un servizio Web supporta RPC fornendo servizi propri, equivalenti a quelli di un componente tradizionale, o traducendo le chiamate in entrata in una chiamata di un EJB o di un componente .NET.

I servizi Web hanno le seguenti caratteristiche comportamentali speciali:

  • XML-Based - I servizi Web utilizzano XML nella rappresentazione dei dati e nei livelli di trasporto dei dati.

  • Loosely Coupled - Un consumatore di un servizio web non è legato direttamente a quel servizio web.

  • Coarse-Grained- Le aziende e le interfacce che espongono dovrebbero essere a grana grossa. La tecnologia dei servizi Web fornisce un modo naturale per definire servizi a grana grossa che accedono alla giusta quantità di logica aziendale.

  • Ability to be Synchronous or Asynchronous- I client asincroni recuperano il risultato in un secondo momento, mentre i client sincroni ricevono il risultato quando il servizio è stato completato. La capacità asincrona è un fattore chiave nell'abilitazione di sistemi ad accoppiamento lasco.

  • Supports Remote Procedure Calls(RPCs) - Un servizio web supporta RPC fornendo servizi propri, equivalenti a quelli di un componente tradizionale, o traducendo le chiamate in arrivo in una chiamata di un EJB o di un componente .NET.

  • Supports Document Exchange - I servizi Web supportano lo scambio trasparente di documenti per facilitare l'integrazione aziendale.

L'utilizzo di XML elimina qualsiasi rete, sistema operativo o associazione di piattaforma. Quindi le applicazioni basate sui servizi Web sono applicazioni altamente interoperabili al loro livello principale.

L'interfaccia del servizio web può cambiare nel tempo senza compromettere la capacità del cliente di interagire con il servizio. Un sistema strettamente accoppiato implica che la logica del client e del server sono strettamente legate l'una all'altra, il che implica che se un'interfaccia cambia, l'altra deve essere aggiornata. L'adozione di un'architettura debolmente accoppiata tende a rendere i sistemi software più gestibili e consente un'integrazione più semplice tra sistemi diversi.

La sincronicità si riferisce al vincolo del cliente all'esecuzione del servizio. Nelle chiamate sincrone, il client si blocca e attende che il servizio completi la sua operazione prima di continuare. Le operazioni asincrone consentono a un client di richiamare un servizio e quindi eseguire altre funzioni.

Ci sono tre ruoli principali all'interno dell'architettura del servizio web:

  • Fornitore di servizi

  • Richiedente del servizio

  • Registro dei servizi

Questo è il fornitore del servizio web. Il fornitore di servizi implementa il servizio e lo rende disponibile su Internet.

Questo è qualsiasi consumatore del servizio web. Il richiedente utilizza un servizio Web esistente aprendo una connessione di rete e inviando una richiesta XML.

Questa è una directory di servizi centralizzata in modo logico. Il registro fornisce un luogo centrale in cui gli sviluppatori possono pubblicare nuovi servizi o trovare quelli esistenti. Serve quindi come un centro di compensazione centralizzato per le aziende e i loro servizi.

Lo stack del protocollo del servizio Web è ancora in evoluzione, ma attualmente ha quattro livelli principali:

  • Servizio di trasporto

  • Messaggistica XML

  • Descrizione del servizio

  • Scoperta del servizio

Questo livello è responsabile del trasporto dei messaggi tra le applicazioni. Attualmente, questo livello include Hyper Text Transport Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP) e protocolli più recenti come Blocks Extensible Exchange Protocol (BEEP).

Questo livello è responsabile della codifica dei messaggi in un formato XML comune in modo che i messaggi possano essere compresi a entrambe le estremità. Attualmente, questo livello include XML-RPC e SOAP.

R. Questo livello è responsabile della descrizione dell'interfaccia pubblica di un servizio Web specifico. Attualmente, la descrizione del servizio viene gestita tramite WSDL (Web Service Description Language).

Questo livello è responsabile della centralizzazione dei servizi in un registro comune e della semplice funzionalità di pubblicazione / ricerca. Attualmente, l'individuazione dei servizi viene gestita tramite UDDI (Universal Description, Discovery, and Integration).

HTTP sta per Hyper Text Transfer Protocol.

Attualmente, HTTP è l'opzione più popolare per il trasporto di servizi. HTTP è semplice, stabile e ampiamente distribuito. Inoltre, la maggior parte dei firewall consente il traffico HTTP. Ciò consente ai messaggi XML-RPC o SOAP di mascherarsi come messaggi HTTP.

BEEP sta per Blocks Extensible Exchange Protocol.

Questa è una promettente alternativa a HTTP. BEEP è un nuovo framework IETF (Internet Engineering Task Force) per la creazione di nuovi protocolli. BEEP è stratificato direttamente su TCP e include una serie di funzionalità integrate, tra cui un protocollo di handshake iniziale, autenticazione, sicurezza e gestione degli errori. Utilizzando BEEP, è possibile creare nuovi protocolli per una varietà di applicazioni, inclusi messaggistica istantanea, trasferimento di file, diffusione di contenuti e gestione della rete.

XML-RPC è un protocollo semplice che utilizza messaggi XML per eseguire RPC.

Le richieste vengono codificate in XML e inviate tramite HTTP POST.

Le risposte XML sono incorporate nel corpo della risposta HTTP.

Di seguito sono riportate le caratteristiche di XML-RPC:

  • XML-RPC è un protocollo semplice che utilizza messaggi XML per eseguire RPC.

  • Le richieste vengono codificate in XML e inviate tramite HTTP POST.

  • Le risposte XML sono incorporate nel corpo della risposta HTTP.

  • XML-RPC è indipendente dalla piattaforma.

  • XML-RPC consente a diverse applicazioni di comunicare.

  • Un client Java può parlare XML-RPC a un server Perl.

  • XML-RPC è il modo più semplice per iniziare con i servizi web.

SOAP è l'acronimo di Simple Access Object Protocol.

SOAP è un protocollo basato su XML per lo scambio di informazioni tra computer.

Di seguito sono riportate le caratteristiche di SOAP:

  • SOAP è un protocollo di comunicazione.

  • SOAP è per la comunicazione tra le applicazioni.

  • SOAP è un formato per l'invio di messaggi.

  • SOAP è progettato per comunicare tramite Internet.

  • SOAP è indipendente dalla piattaforma.

  • SOAP è indipendente dalla lingua.

  • SOAP è semplice ed estensibile.

  • SOAP ti consente di aggirare i firewall.

  • SOAP sarà sviluppato come standard W3C.

Sì!

WSDL è l'acronimo di Web Services Description Language.

WSDL è un linguaggio basato su XML per descrivere i servizi Web e come accedervi.

Di seguito sono riportate le caratteristiche di WSDL:

  • WSDL è stato sviluppato congiuntamente da Microsoft e IBM.

  • WSDL è un protocollo basato su XML per lo scambio di informazioni in ambienti decentralizzati e distribuiti.

  • WSDL è il formato standard per descrivere un servizio web.

  • La definizione WSDL descrive come accedere a un servizio Web e quali operazioni eseguirà.

  • WSDL è un linguaggio per descrivere come interfacciarsi con servizi basati su XML.

  • WSDL è parte integrante di UDDI, un registro aziendale mondiale basato su XML.

  • WSDL è la lingua utilizzata da UDDI.

  • WSDL è pronunciato come "wiz-dull" e definito come "WSD-L".

UDDI è l'acronimo di Universal Description, Discovery e Integration.

UDDI è uno standard basato su XML per la descrizione, la pubblicazione e la ricerca di servizi Web.

Di seguito sono riportate le caratteristiche di UDDI:

  • UDDI è una specifica per un registro distribuito di servizi web.

  • UDDI è un framework aperto e indipendente dalla piattaforma.

  • UDDI può comunicare tramite SOAP, CORBA e Java RMI Protocol.

  • UDDI utilizza WSDL per descrivere le interfacce ai servizi web.

  • UDDI è visto con SOAP e WSDL come uno dei tre standard di base dei servizi web.

  • UDDI è un'iniziativa di settore aperto che consente alle aziende di scoprirsi a vicenda e definire il modo in cui interagiscono su Internet.

Ci sono tre problemi di sicurezza specifici con i servizi web:

  • Confidentiality

  • Authentication

  • Sicurezza della rete

UDDI descrive le interfacce per i servizi web.

WSDL è la lingua utilizzata da UDDI.

No! XML-RPC è indipendente dalla piattaforma.

Sì! Poiché XML-RPC e SOAP vengono eseguiti principalmente su HTTP e HTTP ha il supporto per SSL (Secure Socketes Layer). La comunicazione può essere crittografata tramite SSL.

Le seguenti opzioni possono essere prese in considerazione ma non c'è un chiaro consenso su uno schema di autenticazione forte.

HTTP include il supporto integrato per l'autenticazione Basic e Digest, e quindi i servizi possono essere protetti più o meno allo stesso modo in cui i documenti HTML sono attualmente protetti.

SOAP Digital Signature (SOAP-DSIG) sfrutta la crittografia a chiave pubblica per firmare digitalmente i messaggi SOAP. Consente al client o al server di convalidare l'identità dell'altra parte. Controllalo su http://www.w3.org/TR/SOAP-dsig.

L'Organizzazione per l'avanzamento degli standard di informazione strutturata (OASIS) sta lavorando al Security Assertion Markup Language (SAML).

La gestibilità dei servizi Web è definita come un insieme di capacità per scoprire l'esistenza, la disponibilità, l'integrità, le prestazioni, l'utilizzo, nonché il controllo e la configurazione di un servizio Web all'interno dell'architettura dei servizi Web. Poiché i servizi Web diventano pervasivi e critici per le operazioni aziendali, il compito di gestirli e implementarli è fondamentale per il successo delle operazioni aziendali.

Ci sono due possibili soluzioni:

  • Filtra tutte le richieste HTTP POST che impostano il tipo di contenuto su text / xml.

  • Un'altra alternativa è filtrare l'attributo dell'intestazione HTTP SOAPAction.