1
WEB SERVICES
Reti di calcolatori e sicurezza prof.: S. Bistarelli
relatore: Giusy Bisceglia
INTRODUCTION TO A WEB
SERVICES
3
Sommario
Definizione di Web Services
Struttura di un WS
Applicazione di un WS
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.
5
Definizione del W3C
‘A Web service is a software application
identified by a URI, whose interfaces and bindings are capable of being defined,
described, and discovered as XML
artifacts. A Web service supports direct
interactions with other software agents
using XML based messages exchanged
via internet-based protocols.’
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
7
Struttura Internet
Client Server richiesta dati
risposta
Componenti in Internet
Client effettua la richiesta (anche chiamato consumer )
Server fornisce una risposta (anche
chiamato provider ).
9
Schema generale dei WS
Principalmente un web service espone all'esterno una serie di funzionalità,
attraverso un listener, anche chiamato 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 WS
Server consumer Server Provider
service request service response
11
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
13
Esempio1 : Improved Integration on the
Service Web
Caratteristiche Generali
I WS sono applicabili in qualsiasi tipo di ambiente Web:Internet,intranet,extranet.
ogni tipo di applicazione può essere offerta come WS.
rappresentano la convergenza tra le architetture orientate ai servizi(SOA) e il web.
sono accessibili da ogni nodo della rete.
possono essere combinati, in modo da ottenere servizi complessi, semplicemente facendo interagire un
insieme di programmi che forniscono, ognuno, un servizio semplice.
15
Caratteristiche Tecniche
• Tutti i servizi comunicano tra loro usando protocolli Web indipendenti dalla piattaforma e dai linguaggi, facilitando l’integrazione di ambienti eterogenei.
• Un WS fornisce un’interfaccia programmata application- to-application che può essere invocata da un altro
programma, o meglio, da qualsiasi altro tipo di
applicazione client o server. Questa interfaccia agisce come un collegamento tra il web e l’applicazione logica attuale che implementa il Servizio.
• Si basano su HTTP, il più famoso ed utilizzato dei protocolli della famiglia TCP/IP, come base per il trasporto dei dati e su XML/SOAP per la loro
rappresentazione.
Benefici nell’utilizzo dei WS
Loose Coupling ( accoppiamento indipendente ) : ciascun servizio esiste indipendentemente dagli altri servizi che costituiscono l’applicazione. Questo permette alle singole parti di un’applicazione di essere modificate senza toccare le aree non interessate.
Utilizza architetture orientate ai servizi: i processi business che costituiscono un’applicazione sono separati in componenti indipendenti detti servizi. Questi servizi, interagendo con processi e macchine,riescono a creare una soluzione per i business problem. Le architetture SOA garantiscono una grande flessibilità perché è possibile modificare dinamicamente una parte di esse senza ridefinire l’intero sistema.
Facilita l’integrazione: l’integrazione tra business partners o ambienti diversi è garantita dall’utilizzo di formati standard per lo scambio dei msg. Tali standard sono, inoltre, comprensibili all’uomo e disponibili pubblicamente, e permetteno ad uno sviluppatore di vedere esattamente cosa sta accadendo nel sistema.
Facilmente accessibile: WS utilizzano il protocollo di trasporto già esistente e
17
SOA System
I WS si basano sulla Service Oriented Architecture (SOA). I tre componenti prncipali sono:
1.
Service Provider ,rende disponibile il servizio e pubblica il contratto che ne descrive
l’interfaccia(tramite il broker).
2.
Service Requestor o Consumer,effettua le queries al service broker e questo cerca il servizio compatibile.
3.
Service Registry o Broker,da info al consumer
su quale servizio utilizzare e dove trovarlo.
Web Services roles
19
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
21
L’architettura concettuale SOA con
SOAP, WSDL, and UDDI
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
23
Trasporto - SOAP 1
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
Trasporto – SOAP 2
È 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).
25
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.
27
Organizzazione di un documento
WSDL
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
29
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
31
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
33
Quindi…
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 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).
L’utilizzo di questi meccanismi permette alle applicazioni di analizzare e trattare Xml ma soprattutto di costruire, semplicemente e
direttamente, il msg Xml di inserirlo in una busta Soap e scambiarlo.
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
35
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
37
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 conteiner runtime per WS.
Strumenti di gestione permettono di effettuare tutte le operazioni necessarie
all’amministrazione dei WS
WS Platform
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
39
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 e ciò in quanto 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
Esempio 2:
ViaMichelin Web Services
Soluzione affidabile ed economicamente vantaggiosa per
integrare i servizi di cartografia digitale di ViaMichelin nelle applicazioni aziendali esistenti (internet, intranet, smart
phone e palmari,…).
SERVIZI OFFERTI:
generazione di mappe ViaMichelin
calcolo degli itinerari brevettato da Michelin
verifica degli indirizzi o la ricerca di prossimità
41
Esempio 2:
ViaMichelin Web Services
OBIETTIVI:
inserire i servizi di cartografia digitale a supporto della mobilità al centro degli scambi e dei processi di business di un’azienda, contribuendo a renderla più efficiente e competitiva.
Migliorare la mobilità e la produttività del personale aziendale (forza vendita, personale tecnico di intervento, addetti alla logistica)
uno strumento di supporto agli operatori dei call center, per una migliore elaborazione delle informazioni
i processi “geo-dipendenti” (localizzazione di flotte, servizi post- vendita, servizi di assistenza,....)
Rafforzare l’efficacia di azioni di marketing (verifica degli indirizzi, definizione delle aree di clientela....)
Controllare i costi interni ed esterni mediante un’integrazione automatica del tempo di percorrenza e del chilometraggio nelle applicazioni di gestione delle note spese.
Esempio 2:
ViaMichelin Web Services
compatibilità con gli standard http, SOAP, XML e WSDL, le aziende e coloro che sviluppano applicazioni possono implementare
velocemente e facilmente i ViaMichelin Web Services a livello
aziendale su qualsiasi piattaforma come: internet, telefoni cellulari, palmari, smart phone, sistemi di navigazione,…”
I Web Services sono forniti, a costi competitivi, alle aziende che pagano solo i servizi realmente utilizzati. Esiste un centro che
garantisce la sicurezza dei dati 24 ore su 24, 7 giorni su 7, con oltre 150 server, che supportano tutti i servizi on-line. I tassi di
accessibilità e i tempi di risposta di ViaMichelin sono misurati
costantemente da una società esterna (Keynote) che li classifica tra i migliori del mondo Internet. Gli strumenti di misurazione sono messi a disposizione dei clienti e permettono loro di accedere ai report di
43
