In questa lezione cercheremo di entrare nel dettaglio teorico del processo di pubblicazione/sottoscrizione di un Web Service. Le idee per cui bisognerebbe utilizzare un web service, le abbiamo già introdotte nella lezione precedente e sono, per lo più, di carattere commerciale (anche se i risvolti tecnologici non mancano).
Come anticipato, la forza di questa tecnologia è la standardizzazione e la comunicazione che avviene grazie allo scambio di informazioni in forma testuale. Questo, da una parte limita le performance per l'overhead di elaborazione della semantica dei messaggi, ma dall'altra consente un utilizzo obliquo da tutte le piattaforme software. Inoltre, un altro punto di forza è quello legato alla sicurezza: i messaggi testuali viaggiano su protocolli e porte "aperte" ai firewall. La comunicazione tra due sistemi non deve essere preceduta da noiose configurazioni ed accordi tra le parti.
Detto ciò, vediamo insieme il processo di pubblicazione (da parte di chi crea il servizio) e di utilizzo (da parte di chi lo vuole utilizzare), spiegando i passaggi e gli standard che sovrintendono queste procedure.
1.a. Il provider (chi crea il web service) crea il servizio la cui descrizione (nome dei metodi, parametri attesi, parametri di ritorno, ecc) è affidata ad un documento WSDL (Web Service Descriptor Language), cioè un formato standard XML. La pubblicazione del servizio viene affidata ad un registro (terzo rispetto le parti) UDDI (Universal Description Discovery and Integration).
1.b. Il client interroga il registro UDDI, per scoprire (fase di discovery) i servizi di cui ha bisogno.
1.c. Nel momento in cui la ricerca ha esito positivo, chiede al registro il documento WSDL, che definisce la struttura del servizio, e quindi indirizzi e modi sul come interrogarlo.
2. Il passaggio seguente è un accordo commerciale tra le parti: ad esempio tra un'azienda fornitrice di componenti ed una di sviluppo prodotti, oppure tra un magazzino ed un venditore.
3 - 4. L'ultimo passaggio è la messa in produzione del sistema. Il client crea uno strato software (request agent) a partire dal WSDL che interagisce con lo strato software (provider agent, cioè il servizio vero e proprio) fornitore del servizio. Lo scambio di messaggi avviene utilizzando un altro protocollo XML, SOAP (Simple Object Access Protocol), anch'esso standard. La richiesta (in forma testuale) viene scompattata dal suo involucro SOAP, portata in forma binaria ed elaborata secondo la logica del servizio. La risposta, a sua volta viene portata in forma testuale, convogliata in un messaggio SOAP ed inoltrata (generalmente su protocollo HTTP) verso il mittente.
La cosa interessante, dal punto di vista dello sviluppatore è che i meccanismi di comunicazione (messaggi SOAP) vengono creati in maniera semplice a partire dal documento WSDL. Infatti, chi si occupa di sviluppo (lato client o lato server) dovrà preoccuparsi di creare la logica del servizio e definire il WSDL del servizio stesso. La creazione dell'infrastruttura di comunicazione sarà automatizzata dalla presenza di opportuni strumenti di sviluppo.
