1

WEB SERVICESReti di calcolatori e sicurezza

prof.: S. Bistarelli

relatore: Giusy Bisceglia

2

INTRODUCTION TO A WEB SERVICES

3

Sommario

Definizione di Web Services Struttura di un WS Applicazione di un WS

4

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.

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

6

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.

7

Struttura Internet

Client Server

richiesta dati

risposta

8

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.

10

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.

12

Esempio1 : Weak Integration on the Application Web

13

Esempio1 : Improved Integration on the Service Web

14

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.

16

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.

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.

18

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

20

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.

21

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

22

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

23

Trasporto - SOAP 1Si 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

24

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>

26

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

28

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 .

29

Esempio: layout di un documento Wsdl

30

Scoperta – UDDI 1La 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

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.

32

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.

34

WSA Invocation mechanismInizialmente 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 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.

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.

36

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.

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

38

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

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

40

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.

42

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.

43

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

44

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