Progetto realizzato da:
Francesco Seccia Matr. 666784
Marco Spinelli Matr. 667109
Motivazioni alla base dell’asincronismo
Web Services asincroni
Metodi di correlazione asincrona
Pattern asincroni semplici
Pattern asincroni complessi
Implementazione dei pattern asincroni
Conclusioni
2
Necessità di latenza temporale
Funzioni complesse non sempre garantiscono risposte istantanee (Sincrone)
Privatezza della logica interna di business
Disaccoppiamento dell’interazione non solo temporale ma anche funzionale
Costi ed efficienza
Maggiore scalabilità (il sistema può essere progettato in funzione del carico
medio e non di quello di picco)
Maggiore affidabilità (Es. E-Mail)
Accessibilità
Si risolve il problema della caduta di connettività
Si consente un accesso affidabile anche a dispositivi che non presentano
una connessione “always on” (Es. dispositivi Wireless)
3
Sistemi software progettati per supportare interazioni di
interoperabilità asincrone macchina-macchina su una rete
Problemi da affrontare
Lunga persistenza delle informazioni inerenti allo stato della chiamata
Correlazione tra richieste e risposte
4
Correlazione a livello di trasporto
Esistono protocolli di trasporto che supportano nativamente
l’asincronismo (a differenza di HTTP)
Mette a disposizione meccanismi per recuperare lo stato e i messaggi di
risposta
Implementazione di client e server più semplici
Problemi:
Non esiste un protocollo standard
Relega l’utilizzo dei WS a un ambito chiuso (Scarsa interoperabilità)
Correlazione tramite semantica applicativa
Correlazione implicita all’interno dei dati applicativi
Problemi:
La struttura dei dati applicativi deve essere condivisa tra cliente e fornitore
I formati dei codici potrebbero non essere adatti per l’implementazione
Non esiste separazione tra dati applicativi e problemi di implementazione
5
Correlazione tramite meta-dati di conversazione
I meta-dati sono dati “ausiliari” di supporto al workframe, utilizzati per
effettuare la correlazione
Obiettivi:
Gestione della conversazione tramite info che descrivono i servizi da chiamare e
l’ordine di tali chiamate
Memorizzazione e data warehousing di messaggi, operazioni e conversazioni tra
WS
Problema:
Mancanza di standardizzazione
6
Correlazione tramite meta-dati di conversazione
Tramite il “Contesto di conversazione”
 Facile estrapolazione dei
dati applicativi
 Solo ConversationID per la
correlazione
 Basso Overhead dovuto ai
meta-dati
Possibile mismatch delle
risposte
7
Correlazione tramite meta-dati di conversazione
Tramite il “Contesto dell’operazione”
 Massimo potere espressivo
 Risolve il problema del
mismatch
Carico maggiore per il
sistema
Tramite “Tutti i meta-dati di conversazione”
Si implementa l’intera struttura di meta-dati
Ha lo stesso potere espressivo della tipologia precedente
Aggiunge Overhead senza un beneficio reale
8
“Polling” pattern
 Estrema semplicità (Thin client)
 Basato su tecnologie e Modus
Operandi collaudate
Bassa efficienza
Ritardo della notifica
Request-response di invio della richiesta
Request-response per sollecitare la risposta
9
“Callback” pattern
 Alta efficienza
 Possibilità di “P2P”
 Possibilità di specificare
l’indirizzo di ritorno
Il client deve pubblicare un
servizio che accetta chiamate
Standard non ancora consolidati
Richiesta con identificativo e indirizzo di ritorno
Risposta inviata all’indirizzo di ritorno
10
“Callback” pattern con Acknowledgement
 Vantaggi del “Callback”
tradizionale
 Consente la notifica di
ricezione, rendendo possibile la
verifica di non-ripudiazione
(Fondamentale nel B2B)
Svantaggi del “Callback”
tradizionale
Duplicazione del n° di messaggi
Ogni operazione coinvolta è bidirezionale
11
“Publish-Subscribe” pattern
 Vantaggi del “Callback”
tradizionale
Svantaggi del “Callback”
tradizionale
Il cliente riceve più di una risposta
Può essere esteso con un meccanismo di Acknowledgement
12
Pattern “Multi-Attore” (caso “Callback”)
Interazione contemporanea tra più attori
Anche gli altri pattern possono essere estesi in maniera simile
13
OASIS ASAP Standard Proposal
Il servizio cliente “Observer” invia una richiesta SOAP al servizio “Factory”
Il servizio “Factory” genera una istanza di servizio di cui si rende noto l’URI
L’istanza del servizio può essere utilizzata o modificata dal client attraverso
messaggi SOAP
14
Utilizzo dei buffer
 Risolve problemi di rete
 Risolve problemi di “Busy”
del WS
Capacità del buffer limitata
Costi aggiuntivi
I buffer dei clienti accumulano le richieste di servizio in uscita e le inoltrano
secondo una politica FIFO
Il buffer del WS accumulano i Job in ingresso e li mandano in esecuzione
secondo una politica FIFO
15
“Callback” pattern
Invio OK
INPUT:
• Parametri espliciti
• XML Document
 Invia la richiesta tramite un
Errore di trasporto
servizio One-way
 Pubblica un altro servizio
One-way per ricevere la
risposta
INPUT:
• Parametri espliciti
• XML Document
 Pubblica un servizio One-way
INPUT:
• Parametri espliciti
• XML Document
Link da applicazione
Coupling risposta
per ricevere le richieste
Invio OK
 Quando la risposta è pronta
viene spedita tramite un altro
servizio One-way
Errore di trasporto
16
“Publish-Subscribe” pattern
Invio OK
 Invia la richiesta tramite un
INPUT:
• Parametri espliciti
• XML Document
servizio One-way
Errore di trasporto
 Pubblica un altro servizio
One-way per ricevere le
risposte che via via saranno
inviate
INPUT:
• Parametri espliciti
• XML Document
INPUT:
• Parametri espliciti
• XML Document
Link da applicazione
Coupling risposta
 Pubblica un servizio Oneway per ricevere le
Invio OK
richieste
 Ogni volta che l’informazione
è disponibile viene spedita
tramite un altro servizio Oneway
Errore di trasporto
17
“Polling” pattern
 Invia la richiesta e riceve la
INPUT:
• Parametri espliciti
• XML Document
INPUT:
• CID
conferma tramite un
servizio Request-response
 Pubblica un altro servizio
Request-response per
ricevere la risposta e dare la
conferma
 Pubblica un servizio
INPUT:
• Parametri espliciti
• XML Document
INPUT:
• CID
Request-response per
ricevere le richieste e
inviare un msg di
avvenuta ricezione
 Quando la risposta è pronta
viene spedita tramite un
altro servizio Requestresponse che si occupa
anche della conferma
18
Mancanza di uno standard universalmente riconosciuto
Mosaico di proposte indipendenti
Tra le proposte individuate si evidenziano alcune idee chiave
Esistenza di due livelli di asincronismo
A livello di singola chiamata (Asincronismo “in the small”)
A livello del contesto di conversazione (Asincronismo “in the large”)
Le “unit” WebML introdotte coprono ogni possibile tipologia di
chiamata asincrona a WS
Sviluppi futuri:
Gestione delle eccezioni e impatto sulle comunicazioni asincrone
19
Francesco Seccia Matr. 666784
Marco Spinelli Matr. 667109
20