WEB SERVICES

Definizione del W3C "Un servizio web è un'interfaccia che descrive una collezione di operazioni, accessibili attraverso una rete mediante messaggistica XML". sistema software progettato per supportare l'interoperabilità tra diversi elaboratori su di una medesima rete offre un'interfaccia software tramite la quale altri sistemi possono interagire con il Web Service stesso. L'interfaccia descrive le operazioni alle quali si accede tramite appositi messaggi trasportati tramite il protocollo HTTP e formattati secondo lo standard XML.

A cosa servono i WS? Garantire a dispositivi di natura differente pieno accesso a tipologie di dati eterogenei. Quando due entità si mettono d'accordo per scambiarsi una serie di informazioni e per astrarre il procedimento, si affidano ad un sistema in grado di garantire una manutenibilità ed una durata della soluzione il più lunga possibile.

Struttura Internet Client Server richiesta dati risposta

Schema generale dei WS Principalmente un web service espone all'esterno una serie di funzionalità, attraverso un server. Un listener è un particolare programma che si mette in ascolto delle richieste che provengono da eventuali client ed ovviamente, cerca di rispondere nel modo migliore.

Struttura WebService Server consumer Server Provider service request service response

Componenti dei WS A differenza di ciò che avviene con la normale navigazione attraverso un browser, nei Web Services gli attori non sono utente e server, ma due server.

Esempio1 : Weak Integration on the Application Web

Esempio1 : Improved Integration on the Service Web

Utilità I Web Services possono essere utilizzati: nelle applicazioni B2B per interfacciare diversi partner commerciali, nelle applicazioni B2C per fornire servizi all'utente finale. Es: un servizio che fornisce le quotazioni di borsa un servizio di traduzione da una lingua ad un'altra

Struttura dei Web Services Si possono distinguere varie componenti: (Universal Definition and Discovery Interface) registro che permette la pubblicazione e la successiva ricerca dei servizi. (Web Services Definition Language) strumento per la definizione dei servizi, definiscono le interfacce e le modalità di colloquio. (Simple Object Access Protocol) protocollo a basso livello per la comunicazione di messaggi XML Protocolli di trasporto nativi di Internet (http, ftp, altro)

Ciclo di vita di un servizio PRODUTTORE 3 1 CHIAMA PUBBLICA 2 CONSUMATORE REGISTRO CERCA

SOA System I WS si basano sulla Service Oriented Architecture (SOA). I tre componenti prncipali sono: Service Provider ,rende disponibile il servizio e pubblica il contratto che ne descrive l’interfaccia(tramite il broker). Service Requestor o Consumer,effettua le queries al service broker e questo cerca il servizio compatibile. Service Registry o Broker,da info al consumer su quale servizio utilizzare e dove trovarlo.

L’architettura concettuale SOA con SOAP, WSDL, and UDDI

Esempi SOA System Java RMI7: Java Remote Method Invocation CORBA8: The Object Management Group Common Object Request Broker Architecture DCE9: The Open Group Distributed Computing Environment DCOM10: Microsoft Distributed Component Object Model

Componenti Funzionali SOA TRASPORTO:rappresenta il formato e il protocollo per comunicare con il servizio DESCRIZIONE:rappresenta il linguaggio per descrivere un servizio, ne specifica il contratto(operazioni e parametri) e fornisce info relative al ‘bind’del servizio SCOPERTA:descrive il meccanismo per registrare e ricercare un servizio.

WS Technologies I Web Services comunicano perché adottano lo stesso linguaggio: XML. Questo descrive le interfacce dei WS e decodifica i loro messaggi. Ma XML da solo non assicura comunicazioni semplici,le applicazioni necessitano perciò di formati standard e protocolli che permettono loro di interpretare appropriatamente XML

Trasporto – SOAP 1 È un paradigma di scambio di messaggi stateless e unidirezionale il msg passa, tramite una trasmissione one-way, dal Soap sender al Soap receiver sono spesso del tipo richiesta/risposta(un’applicazione può essere o solo sender o solo receiver). Stateless=is a communications protocol that treats each request as an independent transaction that is unrelated to any previous request so that the communication consists of independent pairs of request and response. A stateless protocol does not require the server to retain session information or status about each communications partner

Trasporto - SOAP 2 Si utilizza il protocollo SOAP(Simple Object Access Protocol ) che definisce tutti gli standard per le comunicazioni nei WS: Formato dati Wire Format, è un documento XML chiamato ’busta’ che contiene un Soap Header (user, pass),un mandatario e un Soap Body(msg originale in Xml). Protocollo di trasporto (di solito Soap utilizza HTTP ma ci sono anche altri come Https, Smpt,Pop3, Imap, Java Messaging Services, Blocks Extensible Exchange Protocol ) Info aggiuntive di diverso tipo

A SOAP request <soap:Envelope xmlns:soap="..."> <soap:Header> <m:reservation .......> </m:reservation> <n:passenger.... ..> </n:passenger> <!-- extensible headers --> </soap:Header> <soap:Body> <p:departure....> </p:departure> <p:return....> </p:return> <!-- payload --> </soap:Body> </soap:Envelope>

Descrizione - WSDL WSDL (Web Services Description Language ) si preoccupa di definire un meccanismo standard per descrivere un WS: Interfaccia astratta. Si descrivono le funzionalità (what) e il tipo di servizio offerto. Binding concreto. Si descrive come (how) si realizza il collegamento dell’interfaccia con i protocolli concreti Implementazione. Si descrive il dove (where) cioè tramite quale porta si realizza il binding. Ciascuna porta specifica il punto di accesso del servizio.

Organizzazione di un documento WSDL In dettaglio: Types -- contenitore per i tipi di dati usati nei msg scambiati con il servizio Message – una definizione dei dati che devono essere comunicati Port type – un insieme di operazioni offerte dal servizio Operation – descrizione astratta di un’azione supportata da un servizio Binding – protocollo completo e specifica del formato dei dati per un particolare port type Port – porta di accesso, un servizio può avere anche più porte ciascuna con un nome e un protocollo di binding. Service – descrive dove il WS risiede attraverso uno specifico indirizzo URL .

Esempio: layout di un documento Wsdl

Scoperta – UDDI 1 La funzione di scoperta si realizza tramite UDDI (Universal Description, Discovery and Integration ) che offre un meccanismo standard per registrare e ricercare i WS: Tipo di servizio: si definisce il servizio e si assegna a questo un identificatore unico chiamato tModel. Un tModel punta a una specifica che definisce una risorsa. Oltre al servizio si definisce un’interfaccia astratta. Pagine bianche Service providers registra i businesses e tutti i servizi che offrono. Tramite il costrutto Template fornisce info sul binding e sul punto di accesso. Pagine verdi Categorizzazione: si usa una varietà di categorie per classificare le entità in base alla localizzazione geografica, al codice prodotto ecc. Pagine gialle Scoperta: descrive il meccanismo per registrare e ricercare un servizio.

Scoperta – UDDI 2 Ricerca. I service consumer possono ricercare il servizio effettuando queries al registro Uddi, questa ricerca può avvenire tramite tipo di servizio o service provides. Nel caso di una intranet,il broker può cercare prima i service provider interni e poi altri broker su Internet se tali servizi non esistono localmente. Binding : il collegamento tra client e servizio può avvenire sia in fase di compilazione che di runtime. Statico: La ricerca di un service viene effettuata una volta sola e se ne memorizza il risultato. Quindi la localizzazione dei servizi si conosce prima di iniziare l’esecuzione del programma e si tratta di indirizzi assoluti. Dinamico: la ricerca viene effettuata in fase di runtime e di solito perché è stata modificata la posizione del servizio. Scoperta dinamica. Siccome Uddi è esso stesso un WS, un’applicazione può fare richieste al servizio, trovare dinamicamente il servizio, localizzare il suo punto di accesso, recuperare il Wsdl e collegarsi ad esso tutto in runtime.

Sommario di una struttura funzionale WSA

Riassumendo XML Web service è un software service esposto sul Web tramite SOAP, descritto con un file WSDL è registrato in UDDI Quando un provider vuole rendere il servizio disponibile ai consumers, descrive il servizio utilizzando WSDL e lo registra in un UDDI registry. Quando un consumer vuole usare il servizio, chiede al registro UDDI di trovare quello che meglio risponde alle sue necessità. Ottiene il punto di accesso e la descrizione WSDL con la quale costruisce i msg SOAP e comunica con il servizio.

WSA (Web Services Architecture) Invocation mechanism Inizialmente non era stato definito uno specifico meccanismo di invocazione dei servizi ma soltanto i protocolli di comunicazione. Le specifiche di come le applicazioni interagiscono con Soap e Wsdl sono state lasciate, e quindi realizzate, dalle application community ( Microsoft, Java). Questi meccanismi permettono alle applicazioni di analizzare e trattare messaggi Xml ma soprattutto di costruire, semplicemente e direttamente, il msg Xml, di inserirlo in una busta Soap e scambiarlo.

WSA Invocation mechanism XML-RPC: una chiamata di procedura remota(RPC) è una richiesta all’applicazione server da un’altra locazione per realizzare operazioni e restituire informazioni. XML-RPC è un semplice protocollo che permette al software di girare in ambienti diversi per realizzare chiamate di procedure remote in internet e stabilire una vasta gamma di connessioni tra i computer. XML-RPC usa due standards: XML per codificare i messaggi, e HTTP per trasportarli.Un msg XML-RPC propriamente formattato è una richiesta HTTP POST il cui body è in XML. Il server remoto specificato esegue la chiamata e restituisce i dati richiesti in formato XML.

WSA Invocation mechanism JWSDL(Java Api for Wsdl) Toolkit usato per costruire , testare e implementare applicazioni Xml, WS e applicazioni Web con le più recenti tecnologie e implementazioni standard. Offre un Api per creare,controllare e manipolare documenti Wsdl. JAXM(Java Api for Xml Messagging) offre un’ interfaccia per costruire un messaggio. Determina la struttura di un msg Soap e costruisce dinamicamente l’envelope, l’header e il body Soap. L’applicazione client semplicemente aggiunge l’Xml payload al msg. SAAJ(Soap with attachments Api) offre un’interfaccia Soap. L’applicazione client può usare Saaj per costruire manualmente, processare e inviare un msg Soap in rete dalla piattaforma Java. JAXR(Java Api for Xml Registries) è un Api che può esser usata per accedere a una varietà di registri Xml, incluso quelli UDDI. Essendo un registro generico Api, il modello dei dati Jaxr è diverso dal modello dei dati Uddi.

Implementazione di una WSA Per la costruzione e l’implementazione dei WS è possibile utilizzare: Le tecnologie basate su XML viste prima oppure le cosiddette Web Service Platform. Il vantaggio nell’utilizzo di una piattaforma gli sviluppatori non devono preoccuparsi della costruzione e dell’implementazione dei messaggi Soap. Scrivono il codice che implementa il sevizio e a tutto il resto provvede la piattaforma.

WS Platform Generalmente è formata da: Strumenti di sviluppo , utilizzati per creare WS, descrizioni Wsdl, per generare client proxies (usati per mandare msg al servizio) e per registrare e cercare nel registro Uddi. Server runtime analizza tutti i msg Soap e offre un container runtime per WS. Strumenti di gestione permettono di effettuare tutte le operazioni necessarie all’amministrazione dei WS

Esempio1: HP Web Services Platform 2.0 include: HP-SOAP 2.0 - SOAP server and XML document pipeline-processing framework; features XML Digital Signature security capabilities HP Service Composer - graphical tool for creating and mapping WSDL interfaces; features automatic deployment to HP-AS 8.0 HP Registry Composer - graphical tool for registering and discovering Web services in UDDI registries via UDDI4J Java API Useful trail map tutorials, documentation, and use case examples to expedite the Web services learning process

WS e la rete I Web service hanno guadagnato consensi perchè, come protocollo di trasporto, possono utilizzare HTTP "over" TCP sulla porta 80; tale porta è, normalmente, una delle poche (se non l'unica) lasciata "aperta" dai sistemi firewall al traffico di entrata ed uscita dall'esterno verso i sistemi aziendali. Su tale porta transita il traffico HTTP dei web browser: ciò consente l'utilizzo dei Web Service senza modifiche sulle configurazioni di sicurezza dell'azienda (un aspetto che se da un lato è positivo solleva preoccupazioni concernenti la sicurezza). Un‘altra ragione che ha favorito l'adozione ed il proliferare dei Web Service è la mancanza, prima dello sviluppo di SOAP, di interfacce realmente funzionali per l'utilizzo di funzionalità distribuite in rete: EDI, RPC, ed altri tipi di API (Application Programming Interface), anche se più facili da utilizzare, erano e rimangono meno conosciute rispetto all'architettura dei Web Service