Reti di calcolatori e sicurezza
WEB
prof.: SERVICES
S. Bistarelli
relatore: Giusy Bisceglia
1
INTRODUCTION TO A WEB
SERVICES
2
Sommario
Definizione di Web Services
 Struttura di un WS
 Applicazione di un WS

3
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.
4
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.’
5
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.

6
Struttura Internet
Client
Server
richiesta dati
risposta
7
Componenti in Internet

Client effettua la richiesta (anche chiamato
consumer )

Server fornisce una risposta (anche
chiamato provider ).
8
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.

9
Struttura WS
Server consumer
Server Provider
service request
service response
10
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.
11
Esempio1 : Weak Integration on the
Application Web
12
Esempio1 : Improved Integration on the
Service Web
13
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.
14
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 applicationto-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.
15
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
notevolmente utilizzato come http, facendo leva su infrastrutture esistenti e
permettendo alle info di essere richieste e ricevute in tempo reale.
16
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.
17
Web Services roles
18
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
19
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.

20
L’architettura concettuale SOA con
SOAP, WSDL, and UDDI
21
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
22
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
23
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).
24
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>
25
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.
26
Organizzazione di un documento
WSDL
27
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 .
28
Esempio: layout di un documento
Wsdl
29
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
30
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.
31
Sommario di una struttura
funzionale WSA
32
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.
33
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 codificare i messaggi, e HTTP per trasportarli.Un msg XMLRPC 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.
34
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.
35
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.
36
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
37
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
Java API
 Useful trail map tutorials, documentation, and use case
examples to expedite the Web services learning process
38
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
39
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à
40
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 postvendita, 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.
41
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
utilizzo giornaliero di ogni servizio mentre una intranet sicura
consente una facile gestione on-line degli indirizzi, per integrarli nelle
applicazioni.
42
Esempio 2:
ViaMichelin Web Services
VANTAGGI:
aumento dell’efficienza operativa e la
diminuzione dei costi, proprio per la natura
dei Servizi, “sviluppati una volta e forniti
molte volte”.
43
…e per il futuro?
La Microsoft, già da tempo, ha realizzato un nuovo
progetto, un sistema operativo chiamato
Windows Longhorn che si poggia su tre pilastri,
uno dei quali è appunto Indigo il nome in codice
di una tecnologia basata proprio sui WS
organizzati in Soa.
Indigo sarà probabilmente la più grande ed
efficiente rampa di lancio per questa tecnologia
proprio perché inserita all’interno del sistema
operativo più diffuso al mondo.
Secondo quanto annunciato, il sistema operativo
verrà lanciato entro il 2006 anche se è già stato
ribattezzato Microsoft Windows Vista.
44