Sei sulla pagina 1di 117

Web Services

Definizione

Un web service un servizio che che


comunica in xml non legato a nessun
linguaggio o sistema operativo
Propriet

Un web service pu comunicare utilizzando:

1. XML-RPC
2. SOAP
3. HTTP/POST trasmettendo
un messaggio XML
Riepilogo Propriet

Un web service :

1. un servizio web che comunica via xml

2. Non specifico di nessun sistema operativo o


linguaggio

3. auto-descrittivo (self-describing)
Web Service: schema
funzionamento

url public UDDI - http://www.xmethods.com/ve2/index.po


Caratteristiche Aggiuntive

Un web service rende pubblica e accessibile una o pi funzionalit attraverso la sua


interfaccia, un componente che pu essere utilizzato da altri componenti (application
centric)

Rende trasparente linteroperabilit tra ambienti non eterogenei, promuove


lintegrazione attraverso il disaccoppiamento

Un web service pu anche disaccoppiare VIEW e CONTENT, si pensi ad una web


application nel modello MVC:
Caratteristiche Aggiuntive

ECCO ALCUNE Java APIs for Web Services

SOAP messages as Java objects


SAAJ ( SOAP with Attachments API for Java)

Programming Model
JAX-RPC ( JSR101), JSR109, EJB2.1

Accessing WSDL descriptions


JWSDL (JSR110)

Accessing Web Services Registries


JAXR (Java API for XML Registries)
Architettura web service: ruoli
In una architettura web service si distinguono i seguenti ruoli

1. Service Provider: chi fornisce il web service

2. Service Consumer: chi utilizza il web service

3. Service registry: una directory centralizzata che contiene i web


service
Architettura web service: protocol stack
In una architettura web service si distinguono i seguenti protocolli:

1. Service Transport: il layer che trasporta i messaggi


2. Xml-Messaging: il layer che riguarda i messaggi scambiati
3. Service-Description: il layer che descrive il web service
4. Service Discovery: il layer che si occupa di centralizzare il web
service con servizi di find/discovery
PROTOCOLLI: XML-RPC

un protocollo per lo scambio messaggi via XML

Le richieste xml sono inviate via HTTP POST

La response inviata dal server nel body HTML


Un esempio di chiamata:

<?xml version="1.0" encoding="ISO-8859-1"?>


<methodCall>
<methodName>weather.getWeather</methodName>
<params>
<param><value>10016</value></param>
</params>
</methodCall>
PROTOCOLLI: XML-RPC

Un esempio di risposta:
!
Un limite di XML-
RPC che non ha
<?xml version="1.0" encoding="ISO-8859-1"?> una sintassi per
<methodResponse> descrivere il servizio
<params> (come WSDL)
<param>
<value><int>65</int></value>
</param>
</params>
</methodResponse>

Specifica il tipo del


dato in output
PROTOCOLLI: SOAP
Permette la comunicazione su HTTP via XML-RPC,utilizza XML SCHEMA
per descrivere il tipo dei dati trasmessi e i NAMESPACE per descrivere le
regole generali,

un esempio di chiamata SOAP:

<?xml version='1.0' encoding='UTF-8'?>


<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2001/09/soap-envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<ns1:getWeather xmlns:ns1="urn:examples:weatherservice"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/09/soap-
encoding/">
<zipcode xsi:type="xsd:string">10016</zipcode>
</ns1:getWeather>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
PROTOCOLLI: SOAP
un esempio di risposta utilizzando SOAP:

<?xml version='1.0' encoding='UTF-8'?>


<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2001/09/soap-envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<ns1:getWeatherResponse
xmlns:ns1="urn:examples:weatherservice"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/09/soap-
encoding/">
<return xsi:type="xsd:int">65</return>
</ns1:getWeatherResponse>
</SOAP-ENV:Body> Il tipo di dato e
</SOAP-ENV:Envelope> Il tipo di dato e
loutput
loutput
WSDL (WEB DESCRIPTION LAYER)

Descrive un WEB SERVICE utilizzando XML:

1. Funzionalit disponibili
2. Tipologia messaggi
3. Tipo di protocollo per lo scambio
4. Indirizzo per localizzare il web service
UDDI Service Discovery

Lacronimo significa Universal Description and


Discovery Integration

Permette di pubblicare e ricercare un web


service

composto da tre parti:


UDDI

In ambienti intranet si utilizzano servizi di


localizzazione come LDAP o JNDI per
localizzare le risorse
UDDI rimane comunque
una specifica dei web services

!
I registri UDDI sono poco
utilizzati soprattutto in
ambiente non web-related
La ricerca del web services di terze
parti in genere viene fatta in
maniera diretta e concordata tra
provider e client
Fine slide
HTTP come protocollo di trasporto

HTTP si presta facilmente lo scambio messaggi in


formato XML

Ha comunque delle limitazioni, oltre ad essere


stateless ha meccanismi di sicurezza
insufficienti (possibilit di sniffing, invocazione diretta ecc)

Con HTTP si pu usare SSL (secure socket


layer) con HTTPS per criptare i messaggi e
basic/digest per lautenticazione
Sicurezza e Autenticazione

Sia SOAP che XML-RPC NON prevedono


meccanismi di sicurezza ed autenticazione

Spesso questi meccanismi dipendono anche


da quale protocollo per il trasporto si utilizza
Request/Provider Perspective
REQUEST PERSPECTIVE

PROVIDER PERSPECTIVE
WEB SERVICE XML-RPC STYLE
Concetti e definizioni

Si accede ad un web service attraverso un url come:


http://www.ttdev./SimpleService questo rappresenta LENDPOINT

Il web service in esame pu contenere ad esempio, un metodo di nome


concat() per altri web service sullo stesso sito potrebbero avere la stessa
operazione quindi per differenziarle si utilizza un NAMESPACE
(supponiamo http://ttdev.com/ns ) che in genere un url perch univoco

Il metodo concat() riceve due parametri stringa s1 e s2 e s3 string in return


, il tipo string non pu riferirsi al tipo in java visto che un web service non
dipende da uno specifico linguaggio quindi si usa XML SCHEMA come
rappresentazione generica di un tipo di dato e il QNAME (QualifiedName):
Data Type Local Name Namespace
string string http://www.w3.org/2001/XMLSchema
integer int http://www.w3.org/2001/XMLSchema
.. .. ..
Concetti e definizioni
Attualmente per un web service:

1. Una chiamata a metodo viene chiamata input message

2. Un parametro viene chiamato part

3. Un return value viene chiamato output message e pu contenere multiple part

La nostra operazione:

Local name: concat


Namespace: http://ttdev.com/ns
Input message:
Part 1:
Name:s1
Type: string in http://www.w3.org/2001/XMLSchema
Part 2:
Name:s2
Type: string in http://www.w3.org/2001/XMLSchema
Output Message:
Part 1:
Name:s3
Type: string in http://www.w3.org/2001/XMLSchema
Concetti e definizioni
La nostra operazione:

Local name: concat


Namespace: http://ttdev.com/ns
Input message:
Part 1:
Name:s1
Type: string in http://www.w3.org/2001/XMLSchema
Output Message:
Part 1:
Name:s2
Type: string in http://www.w3.org/2001/XMLSchema

Quando viene richiamata la nostra operazione viene inviato:


Il namespace
di riferimento

<foo:concat xmlns:foo= http://ttdev.com/ns >


<s1>val1</s1>
<s2>val1</s2>
Questo loutput:
</foo>
<foo:output xmlns:foo= http://ttdev.com/ns >
abc123
</foo>
Xml-Rpc Data type
Xml-Rpc Data Type
Con lXML-RPC si pu costruire anche una struttura come un
array:

<value> Valore e tipo

<array>
<data>
<value><string>This </string></value>
<value><string>is </string></value>
<value><string>an </string></value>
<value><string>array.</string></value>
</data>
</array>
</value>
XML-RPC Request Structure

Sia la request che la response sono una


combinazione di contenuto xml e header HTTP

Lheader HTTP serve per indirizzare il


contenuto al server mentre lxml per
individuare la funzione da richiamare con i
relativi parametri da inviare
XML-RPC Request Structure
Un esempio di request con header HTTP:

POST /xmlrpc HTTP 1.0


User-Agent: myXMLRPCClient/1.0
Host: 192.168.124.2
Content-Type: text/xml
Content-Length: 169

<?xml version="1.0"?>
XML-RPC Response Structure
HTTP/1.1 200 OK
Date: Sat, 06 Oct 2001 23:20:04 GMT
MethodResponse deve
Server: Apache.1.3.12 (Unix) sempre ritornare un
valore anche se il
Connection: close metodo progettato per
Content-Type: text/xml restituire void

Content-Length: 124

<?xml version="1.0"?>
<methodResponse>
<params>
<param>
XML-RPC Response Structure
HTTP/1.1 200 OK Per la response viene
sempre restituito il
Date: Sat, 06 Oct 2001 23:20:04 GMT
codice 200 OK anche in
Server: Apache.1.3.12 (Unix) caso di fault

Connection: close
Content-Type: text/xml
Content-Length: 124
In caso di errore viene
restituito il tag <fault>

<?xml version="1.0"?>
<methodResponse>
<fault>
<value><string>No such method!</string></value>
</fault>
Considerazioni finali

XML-RPC non prevede la gestione dello stato


necessario utilizzare qualche meccanismo
esterno (come i cookie) per tenere traccia
dello stato

XML-RPC non prevede una sintassi per


descrivere il servizio (vedi WSDL)

Viene utilizzati in ambienti mediamente


SOAP

stato progettato per lo scambio di messaggi


su diversi protocolli e sistemi ma nato come
estensione di XML-RPC

Prevede le stesse funzionalit di CORBA,


DCOM ecc ma basato interamente su xml
(indipendenza)

Quasi tutti i linguaggi hanno una loro


SOAP: BENEFICI

E strutturato usando xml

Un messaggio SOAP viaggia su HTTP, porta


8080 quindi non protetta da Firewall

Un messaggio SOAP pu attraversare un


firewall
SOAP: SVANTAGGI

Mancanza di compatibilit tra diverse


implementazioni

I meccanismi di sicurezza non sono adeguati:


SOAP non definisce un meccanismo per
autenticare un messaggio prima
dellelaborazione ne prevede lencript dello
stesso anche se ci sono estensioni che lo
permettono inoltre il fatto che utilizza HTTP
sulla porta 8080 non controllata da firewall ne
SOAP: Architettura
SOAP MESSAGE

UN SOAP MESSAGE un messaggio one-way tra client e server o viceversa

I tag <envelope> e <body> sono mandatory mentre il tag <head>


facoltativo
SOAP MESSAGE
SOAP envelope non specifica una versione di riferimento con i numeri (come 3.2 )
ma attraverso il namespace utilizzato:

<SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/

Il SOAP 1.1 namespace URI http://schemas.xmlsoap.org/soap/envelope/, il


SOAP 1.2 namespace URI http://www.w3.org/2001/09/soap-envelope.
SOAP request
I TAG
Un esempio di richiesta SOAP: <ENVELOPE> E
<BODY> SONO
MANDATORY
<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope
Il tag <body>
xmlns:SOAP- incapsula il payload o
carico utile del
ENV="http://schemas.xmlsoap.org/soap/envelomessaggio
pe/"
xmlns:xsi="http://www.w3.org/2001/XMLSchem
a-instance" I namespace servono come
spazio di dominio per gli
elementi per evitare ambiguit
xmlns:xsd="http://www.w3.org/2001/XMLSche
ed a caricare lxml schema
SOAP HTTP REQUEST
Se utilizza HTTP come protocollo:

POST /rpcrouter HTTP/1.1


HOST: 196.128.3.1
Content-Type: text/xml; charset=utf-8
Content-Length:555
SOAPAction:

<SOAP-ENVELOP>
SOAP Response

?xml version='1.0' encoding='UTF-8'?>


<SOAP-ENV:Envelope
xmlns:SOAP-
ENV="http://schemas.xmlsoap.org/soap/envelo
pe/"
xmlns:xsi="http://www.w3.org/2001/XMLSchem
a-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSche
ma">
SOAP HTTP RESPONSE

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: 320

<SOAP-Enveloper>
....
....
</SOAP-Enveloper>
Soap Header Attribute
Le specifiche SOAP prevedono due attributi:

1. Actor attribute: i soap services nodes cio il message path (percorso


messaggio)

2. MustUnderstand: specifica se lheader mandatory oppure no pu essere


true o false (valore 0 oppure 1)

Un esempio di header con un parametro PaymentAccount che il server


deve interpretare:

<SOAP-ENV:Header>
Soap Header Attribute
Oltre ad aggiungere parametri lintestazione HEADER pu essere usata per gestire :

1. Autenticazione
2. Transazione
3. Altre funzionalit come servizi pagamento
Un esempio di autenticazione:

<SOAP-ENV:Header>
<a:autenthication xmlns:a=http://www.wrox.com/soap/autenthication>
<a:username>giuseppe</a:username>
<a:password>astarita</a:password> Bisogna in questo caso prevedere
</a:authentication> lencript del messaggio per evitare
</SOAP-ENV:Header> lo sniffing dello stesso sul canale di
comunicazione o linvio di una
stringa codificata
Soap Header Attribute
Oltre ad aggiungere parametri lintestazione HEADER pu essere usata per gestire :

1. Autenticazione
2. Transazione
3. Altre funzionalit come servizi pagamento
Un esempio di utilizzo di id transazionale:

<SOAP-ENV:Header>
<a:securityTransactionx mlns:a=http://www.wrox.com/soap/asecuritytransaction>
<a:client>giuseppe astarita</a:client>
<a:transactionID>RF43eed1</a:transactionID>
</a:authentication>
</SOAP-ENV:Header> Stessa regola per lid della
transazione anche se meno
necessario
Soap Fault
caso di errore il tag <body> conterr un tag <fault> , i child-nodes di <fault> sono:

faultCode: specifica il codice di errore che pu essere


1. SOAP-ENV:VERSION-MISMATCH -> invalid namespace

2. SOAP-ENV:MUST-UNDERSTAND -> il server non comprende lheader section

3. SOAP-ENV:client -> errore legato al client (es nome metodo inesistente)

4. SOAP-ENV:server -> errore server (es. Connection database failure

Faultstring: messaggio errore


Faultactor: specifica chi ha causato lerrore (utile in caso di message path con pi
nodi)
Detail: per aggiungere errori specifici dellapplicazione
Soap HTTP Fault
HTTP/1.1 500 internal Server Error
Content-Type: text/xml; charset=utf-8
Content-Length: 320
<SOAP-ENV:envelope xmlns... >
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>Client.authentication</faultcode>
<faultstring>username or password invalid>/fault>
...
Soap Encoding Types
Specifica come SOAP rappresenta un tipo di dato, le ultime specifiche
di
SOAP utilizzano XML-SCHEMA suddividendo i dati in due tipi:

1. Tipi scalari

2. Tipi composti
Soap Encoding Types: tipi scalari
Per i tipi scalari SOAP adotta la seguente tabella:
Soap Encoding Types
Un esempio di utilizzo di un tipo scalare:

<?xml version='1.0' encoding='UTF-8'?>


<SOAP-ENV:Envelope
xmlns:SOAP-
ENV="http://www.w3.org/2001/09/soap-
envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchem
a-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSche
ma">
Soap Encoding Types: tipi composti

Le specifiche SOAP prevedono due tipoi di dati


composti: array e struct

Non tutte le implementazioni SOAP


prevedeono array multidimensionali, questo
perch SOAP non ancora uno standard W3C
Soap Encoding Types: array

<?xml version='1.0' encoding='UTF-8'?>


<SOAP-ENV:Envelope
xmlns:SOAP-
ENV="http://www.w3.org/2001/09/soap-
envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchem
a-instance" Per larray si specifica lattributo
type mentre lxml-schema
xmlns:xsd="http://www.w3.org/2001/XMLSche
specifica il tipo di datai omogenei
contenuti
ma">
Soap Encoding Types: struct
<?xml version='1.0' encoding='UTF-8'?>
Ciascun
Gli elementi elemento
in retun
<SOAP-ENV:Envelope individuato
appartengono al da un key,
namespacenel nostro
ns2 caso
xmlns:SOAP-ENV="http://www.w3.org/2001/09/soap-envelope"
name,price,SKU
specificato
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body>

<ns1:getProductResponse xmlns:ns1="urn:examples:productservice"

SOAP-ENV:encodingStyle="http://www.w3.org/2001/09/soap-encoding">

<return xmlns:ns2="urn:examples" xsi:type="ns2:product">

<name xsi:type="xsd:string">Red Hat Linux</name>


Gli elementi di una struct
<price xsi:type="xsd:double">54.99</price> possono avere tipo diverso,
nel nostro caso xsi:type
<description xsi:type="xsd:string">Red Hat Linux Operating System</description>
specifica due stringhe e un
<SKU xsi:type="xsd:string">A358185</SKU> double
</return>
SOAP encoding style
Specifica il formato del messaggio, si pu specificare anche il contenuto come xml :

<?xml version='1.0' encoding='UTF-8'?>

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://www.w3.org/2001/09/soap-envelope"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body>

<ns1:getProductResponse xmlns:ns1="urn:examples:XMLproductservice"
Lattributo encodingstyle
SOAP-ENV:encodingStyle="http://xml.apache.org/xml-soap/literalxml"> in questo caso
impostato a literalxml
<return>
quindi la risposta sar
<product sku="A358185"> xml puro
<name>Red Hat Linux</name>
SOAP SECURITY
Se lattributo SOAPAction non
POST /xmlrpc HTTP 1.0 specificato o vale una stringa
vuota allora il server pu
User-Agent: myXMLRPCClient/1.0
utilizzare luri specificato dopo
Host: 192.168.124.2 POST
Content-Type: text/xml

Content-Length: 169

SOAPAction: http://www.wrox.com/TimeService/getDateTime

Lattributo SOAPAction pu essere


recuperato dal server Firewall o Proxy
per accettare o rifiutare il messaggio

Fine slide
APACHE SOAP

una implementazione java open source di


SOAP 1.1

Contiene API per creare servizi SOAP e API per


accedervi utilizzando un client

Per utilizzarlo necessario usare un


web/application server, nel nostro caso
utilizzeremo Apache Tomcat 7
Installazione Apache SOAP

1. Scaricare Apache Tomcat e installarlo in una


directory a scelta

2. Settare la variabile di ambiente


TOMCAT_HOME al path di installazione

3. Copiare le seguenti librerie sotto la directory


lib di Tomcat:
Installazione Apache SOAP

4. Avviare Tomcat e nella schermata di


amministrazione effettuare il deploy del file
soap.war presente nellarchivio soap-bin-
2.2.zip

5. allurl http://localhost:8080/soap/
La schermata che si presenta ci conferma che
linstallazione andata a buon fine
Installazione Apache SOAP

Cliccando su uno dei due


link verr avviato o
ladmin client o il SOAP
RPC ROUTER
Installazione Apache SOAP
Apache SOAP : DEPLOYING
1

Creiamo un progetto java in Eclipse con una


classe semplice con un metodo che visualizza un
messaggio di benvenuto:

package com.wrox.helloworld.service;

public class HelloWorld {


2

public void print() {


System.out.println("web service called!");
Apache SOAP: DEPLOYING

Nella schermata admin clicchiamo su deploy ed


inseriamo i seguenti valori:

Property value
ID Urn:HelloWorldservice
Scope Application
Methods print
Provider type Java
Provider Class com.wrox.helloworld.service.HelloWorld
Static No
Default Mapping Registry class Org.apache.soap.server.DOMFaultListener
Apache SOAP: DEPLOYING

Il messaggio ci informa che il


servizio deployato!

Cliccando su list verr


elencato come servizio
deployato e quindi
disponibile
Apache SOAP: testiamo il servizio
package com.wrox.helloworld.client;

import java.net.MalformedURLException;
import java.net.URL; Lend point
punter al nostro
import org.apache.soap.Constants; SOAP ROUTER!
import org.apache.soap.Fault;
import org.apache.soap.SOAPException;
import org.apache.soap.rpc.Call;
import org.apache.soap.rpc.Parameter;
import org.apache.soap.rpc.Response;

public class HelloWorldClient {


static String DEFAULT_ENDPOINT = "http://localhost:8080/soap/servlet/rpcrouter";
Apache SOAP: testiamo il servizio

public static void main(String[] args) {

// crea un oggetto proxy per la chiamata 1


Call c = new Call();

// specifica i parametri per la comunicazione 2


c.setTargetObjectURI("urn:HelloWorldService");
c.setMethodName("print");
c.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC);
Apache SOAP: testiamo il servizio
try {
// crea un oggetto URL 3
URL url = new URL(DEFAULT_ENDPOINT);

// richiama il servizio, non necessario un oggetto Response lo solo in caso di 4


// valore di ritorno da parte del web service

Response response = c.invoke(url, "");

// se viene sollevata una eccezione .. 5


if (response.generatedFault()) {
Fault fault = response.getFault();
System.out.println("errore:");
System.out.println("fault code:" + fault.getFaultCode());
System.out.println("fault string:" + fault.getFaultString());
} else
// esito chiamata positivo, verr stampato un messaggio sulla console di Tomcat 6
System.out.println("ok andato!");
} catch (MalformedURLException e) {
e.printStackTrace();
} catch (SOAPException e) {
e.printStackTrace();
}}
Apache SOAP: TCP/IP Monitor
Un monitor TCP/IP visualizza il traffico di dati su una determinata
porta di ascolto in pratica fa da intermediario tra il client del web
service e il web service stesso secondo la seguente modalit:

Si pone in ascolto sulla porta 8070 (diversa dalla 8080)

Il nostro client indirizza lurl alla porta 8070 invece che 8080

Il monitor settato per dirottare i dati di entrata della porta


8070 verso la porta 8080 e viceversa

Il nostro monitor quindi agisce da proxy


Apache SOAP: TCP/IP Monitor
Un monitor TCP/IP visualizza il
traffico di dati su una determinata
porta di ascolto in pratica fa da
intermediario tra il client del web
service e il web service stesso
secondo la seguente modalit:

Si pone in ascolto sulla porta 8070 (diversa dalla 8080)

Il nostro client indirizza lurl alla porta 8070 invece che 8080 PROXY

Il monitor settato per dirottare i dati di entrata della porta


8070 verso la porta 8080 e viceversa

Il nostro monitor quindi agisce da PROXY

FINE SLIDE
Apache SOAP: TCP/IP Monitor
In myeclipse selezioniamo
windows/show view/TCP/IP
Monitor:
Apache SOAP: TCP/IP Monitor
Cliccando col tasto destro del
mouse
Apache SOAP: TCP/IP Monitor
CLICCANDO SU ADD
Apache SOAP: TCP/IP Monitor
VIENE VISUALIZZATA LA FINESTRA PER SETTARE IL MONITOR
Apache SOAP: TCP/IP Monitor

PORTA DI ASCOLTO DEL MONITOR IN ENTRATA

HOST E PORTA PER LO SNIFFING

IL MONITOR VA AVVIATO

FINE SLIDE
Apache SOAP: TCP/IP Monitor
La modifica alla porta di riferimtno nel client del web service:
Apache SOAP: TCP/IP Monitor

PORTA 8070 IL monitor rimane in ascolto in entrata

il messaggio che arriva al monitor in entrata dal client

Il messaggio restituito sula porta 8080 dal web service

FINE SLIDE
SOAP: considerazioni finali

Promuove linteroperabilit

Prevede lo scambio di messaggi in xml


utilizzando xml-schema e i namespace

Pu appoggiarsi su HTTP e su altri protocolli


per lo scambio dei messaggi

Fine slide
WSDL

lacronimo di Web Service Description


Language

Le specifiche wsdl prevedono una grammatica


xml per descrivere i web services

Un web service pu avere associato un wsdl


che lo descrive
WSDL

1. Le specifiche prevedono sei elementi


principali:

2. Definitions: lelemento radice , dichiara il


nome del web service e i namespace

3. Types: descrive il tipo dei dati scambiati


WSDL
WSDL
Esempio definition:

<definitions name="HelloService"
targetNamespace="http://www.ecerami.com/wsdl/HelloService.wsdl"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.ecerami.com/wsdl/HelloService.wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
I namespace sono molto importanti perch permettono di differenziare gli elementi a
seconda del namespace di appartenenza, ci si pu quindi riferire a diverse specifiche
senza conflitti dei nomi..
WSDL
Esempio message:

<message name="SayHelloRequest">
<part name="firstName" type="xsd:string"/>
</message>
<message name="SayHelloResponse">
<part name="greeting" type="xsd:string"/>
</message>
WSDL
Esempio portType:

<portType name="Hello_PortType">
<operation name="sayHello">
<input message="tns:SayHelloRequest"/>
<output message="tns:SayHelloResponse"/>
</operation>
</portType>
WSDL: portType INFO!

Wsdl prevede quattro tipologie di operazioni:

One-way: il client invia il messaggio che il


servizio riceve

Request-response: il servizio riceve il


messaggio e invia una risposta
WSDL: portType INFO!
WSDL
Esempio binding:

<binding name="Hello_Binding" type="tns:Hello_PortType">


WSDL
Esempio binding:

<binding name="Hello_Binding" type="tns:Hello_PortType">


Concetti e definizioni

WSDL include estensioni interne per SOAP e


questo permette di specificare caratteristiche
di questo protocollo ad esempio potremo
trovare in un documento wsdl:

Soap:binding -> indica che il protocollo utilizzato


SOAP, pu essere valorizzato anche con rpc
oppure con style in caso di documento xml
Concetti e definizioni
Un WEB SERVICE pu essere rappresentato come:

1. Web service RPC-STYLE: il messaggio viene rappresentato seguendo le specifiche


SOAP

2. Web service DOCUMENT-STYLE: il messaggio viene rappresentato in XML puro

Nel primo caso il messaggio non pu essere validato nel secondo casi si, la WS-I
(webservice interoperability) promuove principalmente il secondo

Dove si specifica lo style nel file wsdl:

<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />

Infine il TargetNamespace il namespace di riferimento di un web service


WSDL: dinamic invocation

Esistono sul mercato framework come GLUE della Mind


Electric che permettono linvocazione di un web service senza
generare uno proxy/stub:

usage: invoke http://localhost:8080/wsdl/HelloService.wsdl


sayhello Helloworld

Dove viene invocato il metodo sayhello passandogli helloworld


come parametro stringa
JAVA WEB SERVICE SECURITY
Una applicazione per ritenersi sicura dovrebbe implementare:

Identificazione e autenticazione: chi sei e come riconosco la tua


identit

Autorizzazione: sei abilitato ad effettuare


questa operazione?

Integrit: i dati che mi hai inviato sono gli


stessi che ho ricevuto?
FINE SLIDE
WEB SERVICES
identificazione e autenticazione

si ottengono in genere con un form html dove


lutente inserisce user e password previo
registrazione

Con i web service il modello precedente non


direttamente fattibile

Questa fase propedeutica a quella di


autorizzazione
FINE SLIDE
WEB SERVICES
autorizzazione

determina quale operazione lutente pu fare


e su quali entit

in genere si utilizzano i Ruoli e Gruppi per la


classificazione delle azioni che sono possibili
effettuare

FINE SLIDE
WEB SERVICES
integrit

assicurarsi che il messaggio ricevuto sia


integro strettamente collegato alla qualit
del canale di comunicazione
WEB SERVICES
privacy

quando si effettua un acquisto sul web o si


fanno operazioni similari bisogna accertarsi
che i nostri dati privati (es. Numero carta di
credito) non vengano intercettati
Crittografia

La crittografia la scienza per mantenere i dati sicuri

i dati vengono chiamati testo in chiaro


mentre trasformarli in modo da renderli
illeggibili si chiama criptaggio

Il testo criptato si chiama testo cifrato

Convertire il testo cifrato in forma originale si


FINE SLIDE
CRITTOGRAFIA
ALGORITMO A CHIAVE SIMMETRICA: LE CHIAVI DI SENDER E RECEIVER SONO IDENTICHE

Lalgoritmo a chiave simmetrica pi diffuso il DES (Data Encription Standard)


CRITTOGRAFIA
ALGORITMO A CHIAVE ASIMMETRICA: LE CHIAVI DI SENDER E RECEIVER SONO IDENTICHE

Lalgoritmo a chiave ASIMMETRICA (Il pi diffuso lRSA ) in genere pi


complesso dato che richiede una chiave pi lunga rispetto a quello SIMMETRICO.
CRITTOGRAFIA
Esistono altre soluzioni come:

Firma digitale (Digital Signature)

Certificato Digitale (Digital Certificate)

per i web service SOAP based, esiste una estensione per la security chiamata SECURITY
SOAP EXTENSION

XML Signature

XML Encription

Con HTTP si pu usare SSL (secure socket layer) con HTTPS per criptare i messaggi e
basic/digest per lautenticazione
CRITTOGRAFIA
In java esistono diverse soluzioni, la pi semplice utilizzare Java
Api for Xml Messaging (JAXM), la seguente istruzione nel package
javax.crypto effettua loperazione di criptaggio sul messaggio xml:

EncryptXMLFields(file://somedir/soap.xml);
Considerazioni

Data la natura open dei web services legata


allutilizzo del protocollo HTTP bisogna prestare
attenzione alle applicazioni riguardo laspetto
della sicurezza adottando i meccanismi pi
adatti a sopperire alla mancanza di sicurezza del
protocollo HTTP
APACHE AXIS 2

TUTORIAL
JAX-WS

TUTORIAL
X-FIRE

TUTORIAL
Restful web service

REST lacronimo di REST Representational


State Transfer (Trasferimento rappresentativo
dello stato)

Un web service standard espone nella sua


interfaccia dei metodi mentre nellarchitettura
REST espone degli oggetti!
Restful web service
Consideriamo un web service standard che
Fornisce le condizioni meteorologiche di una
citt, questo avr un metodo GetWeatherInfo()
che riceve il nome della citt e restituisce una
stringa descrizione tempo

Nellarchitettura REST il web service restituisce


un oggetto citt che non ha metodi piuttosto si
Restful web service
Ci sono azioni standard che valgono per tutti gli
oggetti
ad esempio GET (recupero delloggetto)
Allopposto dei
GET c PUT che significa aggiorna loggetto.

Queste due azioni sono presenti nel protocollo


HTTP si
pu ad esempio supporre che :
Restful web service
Il protocollo HTTP supporta 8 tipi di comandi:

1. GET

2. POST

3. PUT

4. DELETE

5. HEAD

6. OPTION

7. TRACE

Se facciamo in modo di usare questi verbi UNIVERSALI per un web service allora
CHIUNQUE pu utilizzare HTTP per invocare azioni su di esso
Restful web service
pi in dettaglio il seguente url:

GET http://weatherinfo.com/45327 HTTP/1.1

Potrebbe richiamare il nostro restful web service


con 45327 che lID della
citt Londra , una possibile risposta allaRigahead
vuota separa
e body:
chiamata potrebbe essere: obbligatoria!
Restful web service: considerazioni

importante capire che un restuful web


service viene pilotato con comandi che
normalmente si usano per una applicazione
web

Non facile mappare tutte le operazioni con


quello disponibili (8) in HTTP ad esempio in
una applicazione e-commerce come mappare
lacquisto di un prodotto?
Fine slide
Restful web service: resources e
Supponiamo di voler rappresentare un URI
restful web service secondo lxml:

<Employee id=12098>

<Name>Peter Scheufele</Name>

<Address>123 Main St. Dallas TX 75226</Address>

<Designation>System Analyst</Designation>

</Employee>

Con il seguente url: http://employeeinfo/v1.4/employee/id=12098 (sicurezza?)

Employee e employees sono Resources cio oggetti esposti dal restful web service e
accessibili via URL pi in dettaglio gli url sopra sono URI (Uniform Resource Identifier)
Si recupera Peter che associato allID 12098 mentre con il seguente, in forma pi leggibile:
Perch fanno pi che localizzare una risorsa.. La identificano!
http://employeeinfo/v1.4/employees?name=peter

Fine slide
Restful web service: resources e
URI

La rappresentazione di una risorsa il suo


stato

Lo stato cambia se viene invocato UPDATE

Lo stato viene restituito invocando GET

La rappresentazione pu essere restituita in


comando GET: recupera rappresentazione

Richiesta browser:

Risposta server:
comando PUT: aggiorna rappresentazione
Richiesta browser:

Viene inviato dal


browser solo il nodo/i
xml da aggiornare!

Fine slide
Risposta server dopo aver aggiornato la risorsa:
comando POST: crea rappresentazione
Richiesta browser:

In questo caso lURI fa riferimento alla risorsa employees dove la sua rappresentazione
lalbero xml di employee , la risposta potrebbe essere sia il singolo record che lintera
alberatura employees con lo status code 201 created
comando DELETE: cancella
rappresentazione

Due tipologie equivalenti di DELETE:


Info
Due tipi di rappresentazione di employees:
Riepilogo
Abbiamo quindi implementato le operazioni:

1. GetEmployeeInfo,
2. SetEmployeeInfo,
3. AddEmployee
4. DeleteEmployee

Se volessimo implementare loperazione di trasferimento di un impiegato?

In questo caso basta chiedersi: CAMBIA LA RAPPRESENTAZIONE DELLA RISORSA?

La risposta ,essendo affermativa, implicitamente individua in PUT loperazione che pu


essere utilizzata!

Quindi utilizzare un RestFul web service significa pianificare attentamente larchitettura.


Considerazioni

Un Restful web service:

+ relativamente semplice da realizzare


+ utilizza i comandi HTTP per funzionare
+ non necessita di un client pesante
+ non necessita di protocolli come SOAP

-
Si accoppia fortemente con HTTP
RESTFUL WEB SERVICE

TUTORIAL