service oriented architectures e web services
Post on 29-May-2022
7 Views
Preview:
TRANSCRIPT
Corso di Applicazioni TelematicheA.A. 20010-11
Prof. Simon Pietro Romano
Università degli Studi di Napoli Federico II
Facoltà di Ingegneria
Service Oriented Architectures e
Web Services
Cos’è un Web Service?
• L’evoluzione delle tecnologie Internet ha due obiettivi principali:• soddisfare i bisogni degli utenti
• integrare sistemi informativi eterogenei e sempre più complessi
• Web Service:• componenti software distribuiti ed accoppiati in modo
lasco
• forniscono un servizio ben definito• servizio inteso non necessariamente come un servizio finale,
ma come un componente indipendente che può essere usato per fornire un servizio finale
• sono accessibili da programmi mediante protocolli Internet standard
Web Services secondo il W3C
“Software applications identified by a URI,
whose interface and bindings are capable of
being identified, described and discovered
by XML artifacts and supports direct
interactions with other software applications
using XML based messages via Internet-
based protocls” (W3C).
Web Service: definizioni
• Componenti per la programmazione
web:
• auto-contenuti, auto-descrittivi, modulari
• possono essere, sempre tramite
interazioni basate sul web:
• pubblicati
• localizzati
• invocati
Caratteristiche dei Web Service
• Riutilizzabili
• Indipendenti da:
• piattaforma (Unix, Windows, Mac, …)
• implementazione (VB, C#, Java, ...)
• architettura sottostante (.NET, J2EE, …)
• Accessibili mediante un’interfaccia standard auto-descrittiva
• Combinano opportunamente:
• lo sviluppo basato sui componenti
• gli standard web
Service Oriented Architecture (SOA)
• I WS si basano sulla cosiddetta Service Oriented Architecture (SOA)
• Tre componenti principali:1. Service Provider
• rende disponibile il servizio e pubblica il contratto che ne descrive l’interfaccia, tramite un’apposita entità detta Broker
2. Service Requestor o Consumer• invia richieste al service broker; quest’ultimo cerca il
servizio compatibile
3. Service Registry o Broker• fornisce informazioni al consumer riguardo quale
servizio utilizzare (ivi compresa la sua localizzazione)
Ricerca di un servizio
Client
Service
RegistroRichiesta al registro
Link verso il servizio
Descrizione
Richiesta della descrizione del servizio
Descrizione del servizio
Invocazione del servizio
Chiamate
Risposte
Scenario di richiesta di un servizio
WS: non così nuovi…
• Sun RPC (Remote Procedure Call) 1985
• CORBA (Common Object Resource Broker)
1992
• DCE/RPC 1993
• Microsoft COM 1993
• Microsoft DCOM 1996
• Java RMI (Remote Method Invocation) 1996
…ma comunque diversi!
• Neutrali rispetto alla piattaforma
• Basati su standard aperti
• Interoperabili
• Basati sull’impiego di componenti
software ampiamente diffusi
• parser XML
• server HTTP
ServiceRegistry
ServiceUser
ServiceProvider
Find
Service
Web Services: ruoli ed interazioni
ServiceBroker
ServiceUser
ServiceProvider
UDDI/WSDL
Find
Comunicazione: HTTP
Dati: XML
Interazione: SOAP
Web Services: architettura
Web Services: scenario tipico di interazione
• Il Provider crea e definisce il servizio utilizzando illinguaggio WSDL (Web Services Description Language)
• Il Provider registra il servizio tramite UDDI (Universal Description Discovery and Integration)
• L’utente ‘trova’ il servizio effettuando una ricercanel registro UDDI
• L’applicazione utente:
• si collega (‘binding’) al Web Service
• invoca le operazioni da esso definite, tramite ilprotocollo SOAP (Simple Object Access Protocol)
Stack di tecnologie per i web services
• UDDI (Universal Description, Discovery and Integration):
• le ‘pagine gialle’ dei servizi Web
• WSDL (Web Services Description Language):
• descrizione dei messaggi
• SOAP (Simple Object Access Protocol):
• protocollo per lo scambio di messaggi
• XML (eXtensible Markup Language):
• formato per lo scambio dei dati
Internet Protocols(HTTP, FTP, ...)
SOAP
WSDL
UDDI
Emerging layers
Discovery
Let me talk to you (SOAP)
Web Services: protocolli
How do we talk? (WSDL)
Web Service
WebService
Consumer
UDDI
Find a Service
return service response (XML)
http://yourservice.com/svc1
return service descriptions (XML)
http://yourservice.com/?WSDL
HTML with link to WSDL
http://yourservice.com
http://www.uddi.org
Link to discovery document
Servizi di comunicazione e trasporto
SOAP
HTTP
TCP/IP
Transport
• Strato di trasporto:
• XML è usato per descrivere la struttura dei
messaggi scambiati tra servizi Web
• Il messaggio è costituito da:
• l’identificativo
• il destinatario
• una lista di argomenti eventuali
• il nome dell’operazione invocata
• una lista di valori di ritorno attesi
• altri parametri
Trasporto
• HTTP, con il metodo POST, è il più comune…
• …ma è possibile:
• utilizzare HTTP, con il metodo GET
• adoperare altri protocolli ‘classici’
• FTP
• SMTP
• adoperare altri protocolli di nuova generazione:
• Jabber (XMPP)
• BEEP
SOAP
• Un protocollo basato su XML e tipicamenteincapsulato in HTTP
• Costituito da:
• un ‘involucro’ esterno per descrivere:
• ciò che c’è in un messaggio
• come processare il messaggio
• un insieme di regole di codifica
• per rappresentare istanze di tipi di dati definiti a livelloapplicativo
• una convenzione per rappresentare chiamate a procedure remote, insieme alle relative risposte
Messaggio SOAP
• La struttura dei messaggi SOAP
• la busta
• l’header
• Il corpo del messaggio
Busta SOAP <SOAP:Envelopexmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
</SOAP:Envelope>
Header SOAP <SOAP:Header>
<example:header xmlns:example="www.y.com"></example:header>
</SOAP:Header>
Corpo del messaggio SOAP
<SOAP:Body>
<example:body xmlns:example="www.y.com"></example:body>
</SOAP:Body>
Applicazione
Client
Client SOAP
XML API HTTP API
HTTP
Server SOAP
XML API HTTP API
Applicazione
Server
Schema della comunicazione SOAP
Chiamata al metodo remoto
CLIENT
Stack
a=5
b=6
SOAP
SERVER
Stack
a=5
b=6
SOAP
HTTP
XML
<a>5 </a>
<b>6 </b>
Invio del messaggio di risposta
CLIENT
Stack
Result=30
SOAP
SERVER
Stack
Result = 30
SOAP
HTTP
XML
<Result>
30
</Result>
Esempio di richiesta SOAP
POST /AT-WebServicesSample2/services/DayOfWeekPort HTTP/1.0
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: Axis/1.4
Host: localhost:8080
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: "getdayofweek"
Content-Length: 304
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<soapenv:Envelopexmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<date xsi:type="xsd:date">2010-04-12</date>
</soapenv:Body>
</soapenv:Envelope>
Esempio di risposta SOAP
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=utf-8
Date: Mon, 12 Apr 2010 08:56:35 GMT
Connection: close
<?xml version="1.0" encoding="utf-8" standalone="no"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/
" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<dayOfWeek>OK ciccio...the day is a : Monday</dayOfWeek>
</soapenv:Body>
</soapenv:Envelope>
WSDL
• Documento XML che contiene la descrizione dell’interazione client-server
• Un documento WSDL completo deve dare due tipi di informazioni:• Descrizione del servizio di livello applicativo (interfaccia
astratta)• Vocabolario
• Messaggi
• Interazioni
• Dettagli dipendenti dal protocollo specifico• quale protocollo di comunicazione usare:
• es. SOAP su HTTP
• tipi di interazione su questo protocollo
• endpoint (indirizzo di rete)
WSDL: struttura
<wsdl:definition>
</wsdl:definition>
<wsdl:Service>
…
</wsdl:Service>
<wsdl:Service>
…
</wsdl:Service>
<wsdl:Service>
…
</wsdl:Service>
<wsdl:Types>
…
</wsdl:Types>
<wsdl:Message>
…
</wsdl:Message>
<wsdl:PortType>
…
</wsdl:PortType>
<wsdl:Service>
…
</wsdl:Service>
<wsdl:Message>
…
</wsdl:Message>
<wsdl:Message>
…
</wsdl:Message>
<wsdl:PortType>
…
</wsdl:PortType>
<wsdl:PortType>
…
</wsdl:PortType>
<wsdl:Service>
…
</wsdl:Service>
<wsdl:Binding>
…
</wsdl:Binding>
• Tipi:
• definizione dei tipi di dati del Web Service (uso di XMLSchema)
• Messaggio:
• definizione dei messaggi che fanno riferimento ai tipi
• Tipo di porta:
• insieme di operazioni (action) implementate da un Web Service
• una porta è un punto di terminazione identificato in maniera univoca da:
• un identificativo (ad es: URL)
• un binding
• Binding WSDL/SOAP:
• un protocollo concreto d’accesso a una porta e un formato dei messaggi e dei dati per questa porta
• Servizio:
• una collezione di porte (le instanze delle porte WSDL)
WSDL in sintesi
Types Definizioni tipi di dati
Message Firme di richesta e risposta per
ogni metodo (≈ IDL)
Port Type <servizio, protocollo>
operazioni
Operation metodo messaggi
Binding Specifica del Protocollo e del
formato dei dati
Service { Port binding }
Port Indirizzo (≈ URL)
WSDL: un esempio
UDDI
• Universal Description, Discovery and Integration• insieme di specifiche che definiscono un modo per pubblicare e cercare
servizi attraverso una repository centralizzata
• Obiettivo:
• fornire un catalogo mondiale che permetta di ricercare i Servizi Web in base allo stesso principio delle pagine gialle
• Definizione delle informazioni da fornire per ciascun servizio e del tipo di codifica
• API di ricerca ed aggiornamento che descrivono come si può accedere alla repository ed aggiornare le informazioni
• La riuscita di UDDI richiede che i diversi fornitori di Servizi Web si accordino sulla definizione di criteri comuni e di determinate categorie di servizi• Operatori: Microsoft, IBM, SAP e HP
• Problematico…cfr. slide seguente!
UDDI: un registro pubblico?
UDDI: un sito di esempio ancora “vivo”
http://www.xmethods.com/ve2/index.po
Discovery – UDDI
UDDI RegistryInquiry
Publish
Discovery – UDDI
UDDI RegistryInquiry
Publish
UDDI
Pagine bianche
Pagine gialle
Pagine verdi
Identità del fornitore, indirizzo fisico ed elettronico, qualificazioni che fanno riferimento a tassonomie
industriali standard
La descrizione dei servizi offerti
Informazioni sui modelli di accesso al servizio e i differenti modelli di dati sottostanti
Le specifiche UDDI definiscono le tre parti costituenti il registry
Servizi Business
• Si tratta generalmente di funzioni legate al commercio elettronico
• Riproduzione in un mondo virtuale delle transazioni commerciali del mondo reale• transazioni, contratti, fatturazione, pagamenti, ecc.
• I servizi Web Business mettono a disposizione degli sviluppatori un insieme di specifiche che facilitano lo sviluppo di applicazioni Web per settori applicativi specifici
• Per quanto riguarda gli aspetti tecnici, la specifica di alcuni Servizi Business è iniziata prima delle attività di standardizzazione del W3C
Servizi Business
ebXML e RosettaNet:
per formalizzare un’infrastruttura completa per l’e-commerce
BitzTalk di Microsoft:
formalizzazione dello scambio elettronico dei documenti professionali (fatture, ordini, ecc.) tra applicazioni Web distribuite
WSFL (Web Services Flow Language) di IBM, XLANG di Microsoft e WSCL (Web Services Conversation Language) di HP
per la specifica della composizione di un’applicazione Web per l’esecuzione di processi business
BPML (Business Process Modeling Language) e BPQL del consorzio BPMI:
una parte delle specifiche copre la sincronizzazione dei processi business in diverse aziende (es: gestione delle relazioni con i clienti, logistica, ecc.)
WSUI (Web Service User Interface) di Epicentric, WSXL (Web Services Experience Language) di IBM e WSIA (Web ServicesInteractive Applications) di OASIS:
Gestione dell’accesso ai servizi Web
WSFL – XLANGBPMLBPQL
ebXMLRosettaNet
tpaML
Servizi Business
BizTalk
WSUIWSXLWSIA
Piattaforme di sviluppo e esercizio
• Web Service su piattaforma leggera• Server HTTP e Parser XML
• Esempi: Apache SOAP, Apache Axis, SOAP::Lite (Perl), PHPSOAP (PHP), WhiteMesa SOAP (C++), SOAP for ADA, Smalltalk Web Services
• Web Service su Application Server• Valori aggiunti: gestione dell’accesso concorrente, gestione delle
transazioni, sicurezza e autenticazione, infrastrutture, tool di sviluppo
• Classificazione dei fornitori:• Basi di dati: DBMS tradizionale + infrastruttura XML per integrare
l’architettura UDDI/WSDL/SOAP: Oracle, IBM, Sybase
• Middleware: BEA, Vitia, IBM, Progress
• Sistemi operativi: SUN, IBM, Microsoft
Supporto Java per Web Services
• JAX-RPC (Java API for XML-RPC):
• è di fatto Java RMI (Remote Method Invocation) su SOAP
• fornisce un’interfaccia remota per lo scambio di messaggi SOAP in stile RPC
• SAAJ (SOAP API with Attachments for Java):
• è un’API che modella la struttura di un messaggio SOAP ed implementa alcune funzionalità del protocollo per la comunicazione
• JAXM (Java API for XML Messaging):
• è simile a JMS (Java Message Service)
• fornisce un’infrastruttura di messaging per spedire e ricevere messaggi SOAP
SOAP Toolkit: API- vs Stub-based
• Un toolkit SOAP è un’API usata per spedire e ricevere messaggi SOAP
• Ci sono dozzine di SOAP toolkit in molti linguaggi:• Java, C e C++, C#, VB.NET, Perl, ecc.
• Un toolkit stub-based usa il tradizionale modello di programmazione basato su RPC:
• uno stub RPC per comunicare con un Web service
• client-side si modella un Web service come un oggetto (remoto) che espone dei metodi
• JAX-RPC è lo standard stub-based di EJB 2.1
• Un toolkit API-based è usato per costruire messaggi SOAP (Envelope, Header, Body, ecc.) esplicitamente
• SAAJ è lo standard SOAP API in EJB 2.1
Modelli di programmazione JAX-RPC
1. Generated Stub
2. Dynamic Proxy
3. DII (Dynamic Invocation Interface)
Generated Stub
• Il toolkit JAX-RPC genera, in accordo con la
descrizione WSDL:
• l’interfaccia java RMI
• il relativo stub
• Interfaccia RMI e stub possono poi essere
pubblicati in un JNDI ENC (Environment
Naming Context)
• In questo modello lo stub è generato a
deployment time
Dynamic Proxy
• Un dynamic proxy è usato nello stesso modo di generated stub, ma:
• l’implementazione dello stub e l’interfaccia remota sono generati dinamicamente, a run-time
• Come per il caso precedente, la generazione dell’interfaccia remota avviene in accordo con il documento WSDL che descrive le interfacce come porte
• ogni porta può avere una o più operazioni
• Porte e operazioni sono analoghe, rispettivamente, ad interfacce e metodi Java
DII (Dynamic Invocation Interface)
• JAX-RPC supporta un’ulteriore API, ancora più dinamica, chiamata DII (Dynamic InvocationInterface)• DII permette di assemblare chiamate a metodi SOAP
dinamicamente, a run time
• L’idea è la stessa di CORBA Dynamic InvocationInterface
• JAX-RPC DII permette di:• creare oggetti che rappresentano singole operazioni di
Web Service, altrimenti modellati come metodi di un’interfaccia remota
• invocare tali operazioni senza la necessità di accedere ad una service factory o di usare uno stub e un’interfaccia remota
AXIS: Apache eXtensible Interaction System
• Un SOAP Engine open source, caratterizzato da:
• configurazione/deployment molto flessibili (file “.wsdd”)
• supporto per drop-in deployment (Java Web Service,
JWS)
• supporto per tutti i tipi base
• serializzazione/deserializzazione automatica di Java
Bean e possibilità di definire serializer/deserializer
“custom”
• RPC e message-based provider
• Supporto per WSDL (WSDL2Java, Java2WSDL)
• Trasporto: HTTP, JMS (stabili)
4444
Domande?
top related