Servizi Web - Guida rapida

Libri diversi e organizzazioni diverse forniscono definizioni diverse ai servizi Web. Alcuni di loro sono elencati qui.

  • Un servizio web è un qualsiasi software che si rende disponibile su Internet e utilizza un sistema di messaggistica XML standardizzato. XML viene utilizzato per codificare tutte le comunicazioni a un servizio Web. Ad esempio, un client richiama un servizio Web inviando un messaggio XML, quindi attende una risposta XML corrispondente. Poiché tutta la comunicazione è in XML, i servizi web non sono legati a nessun sistema operativo o linguaggio di programmazione: Java può parlare con Perl; Le applicazioni Windows possono dialogare con le applicazioni Unix.

  • I servizi Web sono applicazioni autonome, modulari, distribuite e dinamiche che possono essere descritte, pubblicate, localizzate o invocate sulla rete per creare prodotti, processi e catene di fornitura. Queste applicazioni possono essere locali, distribuite o basate sul Web. I servizi Web si basano su standard aperti come TCP / IP, HTTP, Java, HTML e XML.

  • I servizi Web sono sistemi di scambio di informazioni basati su XML che utilizzano Internet per l'interazione diretta da applicazione a applicazione. Questi sistemi possono includere programmi, oggetti, messaggi o documenti.

  • Un servizio Web è una raccolta di protocolli aperti e standard utilizzati per lo scambio di dati tra applicazioni o sistemi. Le applicazioni software scritte in vari linguaggi di programmazione e in esecuzione su varie piattaforme possono utilizzare i servizi Web per scambiare dati su reti di computer come Internet in un modo simile alla comunicazione tra processi su un singolo computer. Questa interoperabilità (ad esempio, tra Java e Python, o applicazioni Windows e Linux) è dovuta all'uso di standard aperti.

Per riassumere, un servizio web completo è, quindi, qualsiasi servizio che:

  • È disponibile su Internet o reti private (intranet)

  • Utilizza un sistema di messaggistica XML standardizzato

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

  • Si autodefinisce tramite una grammatica XML comune

  • È rilevabile tramite un semplice meccanismo di ricerca

Componenti dei servizi Web

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 (descrizione universale, rilevamento e integrazione)

  • WSDL (Web Services Description Language)

Tutti questi componenti sono stati discussi nel capitolo Architettura dei servizi Web .

Come funziona un servizio Web?

Un servizio Web consente la comunicazione tra varie applicazioni utilizzando standard aperti come HTML, XML, WSDL e SOAP. Un servizio web richiede l'aiuto di:

  • XML per contrassegnare i dati

  • SOAP per trasferire un messaggio

  • WSDL per descrivere la disponibilità del servizio.

È 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.

Esempio

Considera un semplice sistema di gestione degli account e di elaborazione degli ordini. Il personale addetto alla contabilità utilizza un'applicazione client creata con Visual Basic o JSP per creare nuovi account e immettere nuovi ordini cliente.

La logica di elaborazione di questo sistema è scritta in Java e risiede su una macchina Solaris, che interagisce anche con un database per memorizzare le informazioni.

I passaggi per eseguire questa operazione sono i seguenti:

  • Il programma client raggruppa le informazioni di registrazione dell'account in un messaggio SOAP.

  • Questo messaggio SOAP viene inviato al servizio Web come corpo di una richiesta HTTP POST.

  • Il servizio Web decomprime la richiesta SOAP e la converte in un comando comprensibile dall'applicazione.

  • L'applicazione elabora le informazioni come richiesto e risponde con un nuovo numero di conto univoco per quel cliente.

  • Successivamente, il servizio Web impacchetta la risposta in un altro messaggio SOAP, che invia al programma client in risposta alla sua richiesta HTTP.

  • Il programma client decomprime il messaggio SOAP per ottenere i risultati del processo di registrazione dell'account.

Ecco i vantaggi dell'utilizzo dei servizi Web:

Esposizione della funzione esistente sulla rete

Un servizio Web è un'unità di codice gestito che può essere richiamato in remoto utilizzando HTTP. Cioè, può essere attivato utilizzando richieste HTTP. I servizi Web consentono di esporre la funzionalità del codice esistente sulla rete. Una volta che è esposto sulla rete, altre applicazioni possono utilizzare le funzionalità del tuo programma.

Interoperabilità

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.

Protocollo standardizzato

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. Questa standardizzazione dello stack di protocolli offre all'azienda molti vantaggi come un'ampia gamma di scelte, riduzione dei costi dovuta alla concorrenza e aumento della qualità.

Comunicazione a basso costo

I servizi Web utilizzano SOAP su protocollo HTTP, quindi puoi utilizzare la tua Internet a basso costo esistente per implementare i servizi Web. Questa soluzione è molto meno costosa rispetto a soluzioni proprietarie come EDI / B2B. Oltre a SOAP su HTTP, i servizi Web possono essere implementati anche su altri meccanismi di trasporto affidabili come FTP.

I servizi Web hanno le seguenti caratteristiche comportamentali speciali:

Basato su XML

I servizi Web utilizzano XML nei livelli di rappresentazione e trasporto dei dati. L'utilizzo di XML elimina qualsiasi rete, sistema operativo o associazione di piattaforma. Le applicazioni basate sui servizi Web sono altamente interoperabili a livello di base.

Debolmente accoppiato

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.

Grana Grossa

Le tecnologie orientate agli oggetti come Java espongono i propri servizi tramite metodi individuali. Un metodo individuale è un'operazione troppo raffinata per fornire capacità utili a livello aziendale. La creazione di un programma Java da zero richiede la creazione di diversi metodi a grana fine che vengono poi composti in un servizio a grana grossa che viene utilizzato da un client o da un altro servizio.

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.

Capacità di essere sincrono o asincrono

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.

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.

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

Lo sviluppo di componenti tramite Enterprise JavaBeans (EJB) e .NET Components è diventato sempre più parte delle architetture e delle distribuzioni aziendali negli ultimi due anni. 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.

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, oppure possono essere complessi come rappresentare un intero libro o una richiesta di offerta (RFQ). I servizi Web supportano lo scambio trasparente di documenti per facilitare l'integrazione aziendale.

Esistono due modi per visualizzare l'architettura del servizio Web:

  • Il primo è esaminare i ruoli individuali di ogni attore del servizio web.
  • Il secondo è esaminare lo stack di protocolli del servizio web emergente.

Ruoli del servizio Web

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

Fornitore di servizi

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

Richiedente del servizio

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

Registro dei servizi

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.

Stack di protocollo del servizio Web

Una seconda opzione per visualizzare l'architettura del servizio Web è esaminare lo stack di protocollo del servizio Web emergente. Lo stack è ancora in evoluzione, ma attualmente ha quattro livelli principali.

Servizio di trasporto

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).

Messaggistica XML

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.

Descrizione del servizio

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).

Scoperta del servizio

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).

Con l'evolversi dei servizi Web, è possibile aggiungere ulteriori livelli e ulteriori tecnologie possono essere aggiunte a ogni livello.

Il capitolo successivo spiega i componenti dei servizi web.

Poche parole sul servizio di trasporto

Il fondo dello stack del protocollo del servizio Web è il trasporto del servizio. Questo livello è responsabile del trasporto effettivo dei messaggi XML tra due computer.

Hyper Text Transfer Protocol (HTTP)

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 XMLRPC o SOAP di mascherarsi come messaggi HTTP. Ciò è utile se si desidera integrare applicazioni remote, ma solleva una serie di problemi di sicurezza.

Blocks Extensible Exchange Protocol (BEEP)

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, tra cui messaggistica istantanea, trasferimento di file, diffusione di contenuti e gestione della rete.

SOAP non è legato ad alcun protocollo di trasporto specifico. In effetti, puoi utilizzare SOAP tramite HTTP, SMTP o FTP. Un'idea promettente è quindi quella di utilizzare SOAP su BEEP.

Negli ultimi anni, tre tecnologie primarie sono emerse come standard mondiali che costituiscono il nucleo della tecnologia dei servizi web di oggi. Queste tecnologie sono discusse di seguito.

XML-RPC

Questo è il più semplice protocollo basato su XML per lo scambio di informazioni tra computer.

  • 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.

Per ulteriori informazioni su XML-RPC, visita il nostro Tutorial XML-RPC .

SAPONE

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

  • 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.

Per saperne di più su SOAP, visita il nostro tutorial SOAP .

WSDL

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

  • WSDL è l'acronimo di Web Services Description Language.

  • 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".

Per saperne di più su WSDL, visita il nostro tutorial WSDL .

UDDI

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

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

  • 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 e definire il modo in cui interagiscono su Internet.

Per saperne di più su UDDI, visita il nostro tutorial UDDI .

Sulla base dell'architettura del servizio web, creiamo i seguenti due componenti come parte dell'implementazione dei servizi web:

Fornitore di servizi o editore

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

Scriveremo e pubblicheremo un semplice servizio web utilizzando .NET SDK.

Richiedente o consumatore del servizio

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

Scriveremo anche due richiedenti di servizi Web: un consumer basato sul Web (applicazione ASP.NET) e un altro consumer basato su applicazioni Windows.

Di seguito è riportato il nostro primo esempio di servizio web che funziona come un fornitore di servizi ed espone due metodi (aggiungi e SayHello) come servizi web da utilizzare dalle applicazioni. Questo è un modello standard per un servizio web. I servizi Web .NET utilizzano l'estensione .asmx. Si noti che un metodo esposto come servizio Web ha l'attributo WebMethod. Salvare questo file come FirstService.asmx nella directory virtuale di IIS (come spiegato nella configurazione di IIS; ad esempio, c: \ MyWebSerces).

FirstService.asmx
<%@ WebService language = "C#" class = "FirstService" %>

using System;
using System.Web.Services;
using System.Xml.Serialization;

[WebService(Namespace = "http://localhost/MyWebServices/")]
public class FirstService : WebService{
   [WebMethod]
   public int Add(int a, int b) {
      return a + b;
   }

   [WebMethod]
   public String SayHello() {
      return "Hello World";
   }
}

Per testare un servizio web, deve essere pubblicato. Un servizio Web può essere pubblicato su una intranet o su Internet. Pubblicheremo questo servizio web su IIS in esecuzione su una macchina locale. Cominciamo con la configurazione di IIS.

  • Apri Start → Impostazioni → Pannello di controllo → Strumenti di amministrazione → Gestione servizi Internet.

  • Espandere e fare clic con il pulsante destro del mouse sul sito Web predefinito; seleziona Nuovo & # rarr; Directory virtuale. Si apre la Creazione guidata directory virtuale. Fare clic su Avanti.

  • Viene visualizzata la schermata "Alias ​​directory virtuale". Digita il nome della directory virtuale. Ad esempio, MyWebServices. Fare clic su Avanti.

  • Viene visualizzata la schermata "Directory del contenuto del sito Web".

  • Immettere il nome del percorso della directory per la directory virtuale. Ad esempio, c: \ MyWebServices. Fare clic su Avanti.

  • Si apre la schermata "Autorizzazione di accesso". Modificare le impostazioni in base alle proprie esigenze. Manteniamo le impostazioni predefinite per questo esercizio.

  • Fare clic sul pulsante Avanti. Completa la configurazione IIS.

  • Fare clic su Fine per completare la configurazione.

Per verificare se IIS è stato configurato correttamente, copiare un file HTML (ad esempio, x.html) nella directory virtuale (C: \ MyWebServices) creata sopra. Ora apri Internet Explorer e digitahttp://localhost/MyWebServices/x.html. Dovrebbe aprire il file x.html.

Note- Se non funziona, prova a sostituire localhost con l'indirizzo IP della tua macchina. Se ancora non funziona, controlla se IIS è in esecuzione; potrebbe essere necessario riconfigurare IIS e la directory virtuale.

Per testare questo servizio web, copia FirstService.asmx nella directory virtuale IIS creata sopra (C: \ MyWebServices). Apri il servizio web in Internet Explorer (http: //localhost/MyWebServices/FirstService.asmx). Dovrebbe aprire la pagina del servizio web. La pagina dovrebbe contenere collegamenti a due metodi esposti come servizi Web dalla nostra applicazione. Congratulazioni! Hai scritto il tuo primo servizio web!

Testare il servizio Web

Come abbiamo appena visto, scrivere servizi web è facile in .NET Framework. Anche la scrittura di utenti di servizi Web è facile nel framework .NET; tuttavia, è un po 'più complicato. Come detto in precedenza, scriveremo due tipi di consumatori di servizi, uno basato sul Web e un altro basato su applicazioni Windows. Scriviamo il nostro primo consumatore di servizi web.

Consumatore di servizi basati sul Web

Scrivi un consumatore basato sul web come indicato di seguito. Chiamalo WebApp.aspx. Notare che è un'applicazione ASP.NET. Salvarlo nella directory virtuale del servizio web (c: \ MyWebServices \ WebApp.axpx).

Questa applicazione ha due campi di testo che vengono utilizzati per ottenere numeri dall'utente da aggiungere. Ha un pulsante, Esegui, che quando cliccato ottiene i servizi web Aggiungi e SayHello.

WebApp.aspx
<%@ Page Language = "C#" %>
<script runat = "server">
   void runSrvice_Click(Object sender, EventArgs e) {
      FirstService mySvc = new FirstService();
      Label1.Text = mySvc.SayHello();
      Label2.Text = mySvc.Add(Int32.Parse(txtNum1.Text),  Int32.Parse(txtNum2.Text)).ToString();
   }
</script>

<html>
   <head> </head>
   
   <body>
      <form runat = "server">
         <p>
            <em>First Number to Add </em>:
            <asp:TextBox id = "txtNum1" runat = "server" Width = "43px">4<  /asp:TextBox>
         </p>
			
         <p>
            <em>Second Number To Add </em>:
            <asp:TextBox id = "txtNum2" runat = "server" Width = "44px">5</asp:TextBox>
         </p>
			
         <p>
            <strong><u>Web Service Result -</u></strong>
         </p>
			
         <p>
            <em>Hello world Service</em> :
            <asp:Label id = "Label1" runat = "server" Font-Underline = "True">Label< /asp:Label>
         </p>

         <p>
            <em>Add Service</em> :
            & <asp:Label id = "Label2" runat = "server" Font-Underline = "True">Label</asp:Label>
         </p>
			
         <p align = "left">
            <asp:Button id = "runSrvice" onclick = "runSrvice_Click" runat = "server" Text = "Execute"></asp:Button>
         </p>
      </form>
   </body>
</html>

Dopo aver creato il consumatore, dobbiamo creare un proxy per l'utilizzo del servizio web. Questo lavoro viene eseguito automaticamente da Visual Studio .NET per noi quando si fa riferimento a un servizio Web che è stato aggiunto. Ecco i passaggi da seguire:

  • Creare un proxy per il servizio Web da utilizzare. Il proxy viene creato utilizzando l'utilità WSDL fornita con .NET SDK. Questa utilità estrae le informazioni dal servizio Web e crea un proxy. Il proxy è valido solo per un particolare servizio Web. Se è necessario utilizzare altri servizi Web, è necessario creare anche un proxy per questo servizio. Visual Studio .NET crea automaticamente un proxy quando viene aggiunto il riferimento al servizio Web. Creare un proxy per il servizio Web utilizzando l'utilità WSDL fornita con .NET SDK. Creerà il file FirstSevice.cs nella directory corrente. Dobbiamo compilarlo per creare FirstService.dll (proxy) per il servizio Web.

c:> WSDL http://localhost/MyWebServices/FirstService.asmx?WSDL
c:> csc /t:library FirstService.cs

  • Metti il ​​proxy compilato nella directory bin della directory virtuale del Web Service (c: \ MyWebServices \ bin). Internet Information Services (IIS) cerca il proxy in questa directory.

  • Creare il consumatore del servizio, nello stesso modo in cui abbiamo già fatto. Si noti che nel consumer viene creata un'istanza di un oggetto del proxy del servizio Web. Questo proxy si occupa di interagire con il servizio.

  • Digita l'URL del consumatore in IE per testarlo (ad esempio, http: //localhost/MyWebServices/WebApp.aspx).

Consumer del servizio Web basato su applicazioni Windows

Scrivere un consumatore di servizi Web basato su applicazioni Windows equivale a scrivere qualsiasi altra applicazione Windows. Hai solo bisogno di creare il proxy (cosa che abbiamo già fatto) e fare riferimento a questo proxy durante la compilazione dell'applicazione. Di seguito è la nostra applicazione Windows che utilizza il servizio web. Questa applicazione crea un oggetto servizio web (ovviamente, proxy) e chiama i metodi SayHello e Add su di esso.

WinApp.cs

using System;
using System.IO;

namespace SvcConsumer {
   class SvcEater {
      public static void Main(String[] args) {
         FirstService mySvc = new FirstService();
         Console.WriteLine("Calling Hello World Service: " + mySvc.SayHello());
         Console.WriteLine("Calling Add(2, 3) Service: " + mySvc.Add(2, 3).ToString());
      }
   }
}

Compilalo usando c:\>csc /r:FirstService.dll WinApp.cs. Creerà WinApp.exe. Eseguilo per testare l'applicazione e il servizio web.

Ora sorge la domanda: come si può essere sicuri che questa applicazione stia effettivamente chiamando il servizio web?

È semplice da testare. Arresta il tuo server web in modo che il servizio web non possa essere contattato. Ora, esegui l'applicazione WinApp. Attiverà un'eccezione di runtime. Ora riavvia il server web. Dovrebbe funzionare.

La sicurezza è fondamentale per i servizi web. Tuttavia, né le specifiche XML-RPC né SOAP impongono requisiti espliciti di sicurezza o autenticazione.

Esistono tre problemi di sicurezza specifici con i servizi Web:

  • Confidentiality
  • Authentication
  • Sicurezza della rete

Riservatezza

Se un client invia una richiesta XML a un server, possiamo garantire che la comunicazione rimanga riservata?

La risposta sta qui -

  • XML-RPC e SOAP vengono eseguiti principalmente su HTTP.
  • HTTP ha il supporto per Secure Sockets Layer (SSL).
  • La comunicazione può essere crittografata tramite SSL.
  • SSL è una tecnologia collaudata e ampiamente utilizzata.

Un singolo servizio Web può essere costituito da una catena di applicazioni. Ad esempio, un servizio di grandi dimensioni potrebbe legare insieme i servizi di altre tre applicazioni. In questo caso, SSL non è adeguato; i messaggi devono essere crittografati in ogni nodo lungo il percorso del servizio e ogni nodo rappresenta un potenziale anello debole della catena. Al momento, non esiste una soluzione concordata a questo problema, ma una soluzione promettente è lo standard di crittografia XML W3C. Questo standard fornisce una struttura per crittografare e decrittografare interi documenti XML o solo parti di un documento XML. Puoi verificarlo su www.w3.org/Encryption

Autenticazione

Se un client si connette a un servizio web, come identifichiamo l'utente? L'utente è autorizzato a utilizzare il servizio?

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 www.w3.org/TR/SOAP-dsig .

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

Sicurezza della rete

Al momento non esiste una risposta facile a questo problema ed è stato oggetto di molti dibattiti. Per ora, se sei veramente intenzionato a filtrare i messaggi SOAP o XML-RPC, una possibilità è filtrare tutte le richieste HTTP POST che impostano il tipo di contenuto su text / xml.

Un'altra alternativa è filtrare l'attributo dell'intestazione HTTP SOAPAction. I fornitori di firewall stanno attualmente sviluppando strumenti progettati esplicitamente per filtrare il traffico dei servizi web.

Questo capitolo ti dà un'idea di tutti gli ultimi standard relativi ai servizi web.

Trasporti

BEEP, il Blocks Extensible Exchange Protocol (precedentemente denominato BXXP), è un framework per la creazione di protocolli applicativi. È stato standardizzato da IETF e fa per i protocolli Internet ciò che XML ha fatto per i dati.

Messaggistica

Questi standard e specifiche di messaggistica intendono fornire una struttura per lo scambio di informazioni in un ambiente decentralizzato e distribuito.

Descrizione e scoperta

I servizi Web sono significativi solo se i potenziali utenti possono trovare informazioni sufficienti per consentirne l'esecuzione. Il fulcro di queste specifiche e standard è la definizione di una serie di servizi che supportano la descrizione e la scoperta di aziende, organizzazioni e altri fornitori di servizi web; i servizi web che mettono a disposizione; e le interfacce tecniche che possono essere utilizzate per accedere a tali servizi.

Sicurezza

Utilizzando queste specifiche di sicurezza, le applicazioni possono impegnarsi in comunicazioni protette progettate per funzionare con il framework generale dei servizi Web.

Gestione

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.

In questo tutorial hai imparato come utilizzare i servizi web. Tuttavia, un servizio Web include anche componenti come WSDL, UDDI e SOAP che contribuiscono a renderlo attivo. Il passaggio successivo consiste nell'apprendere WSDL, UDDI e SOAP.

WSDL

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

WSDL descrive un servizio Web, insieme al formato del messaggio e ai dettagli del protocollo per il servizio Web.

Per saperne di più su WSDL, visita il nostro tutorial WSDL .

UDDI

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

Per saperne di più su UDDI, visita il nostro tutorial UDDI .

SAPONE

SOAP è un semplice protocollo basato su XML che consente alle applicazioni di scambiare informazioni su HTTP.

Per saperne di più su SOAP, visita il nostro tutorial SOAP .