La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Progetto realizzato da: Francesco Seccia Matr. 666784 Marco Spinelli Matr. 667109.

Presentazioni simili


Presentazione sul tema: "Progetto realizzato da: Francesco Seccia Matr. 666784 Marco Spinelli Matr. 667109."— Transcript della presentazione:

1 Progetto realizzato da: Francesco Seccia Matr. 666784 Marco Spinelli Matr. 667109

2 2 Motivazioni alla base dellasincronismo Motivazioni alla base dellasincronismo Web Services asincroni Web Services asincroni Metodi di correlazione asincrona Metodi di correlazione asincrona Pattern asincroni semplici Pattern asincroni semplici Pattern asincroni complessi Pattern asincroni complessi Implementazione dei pattern asincroni Implementazione dei pattern asincroni Conclusioni Conclusioni

3 3 Necessità di latenza temporale Necessità di latenza temporale Funzioni complesse non sempre garantiscono risposte istantanee (Sincrone) Privatezza della logica interna di business Privatezza della logica interna di business Disaccoppiamento dellinterazione non solo temporale ma anche funzionale Costi ed efficienza 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à 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)

4 4 Sistemi software progettati per supportare interazioni di interoperabilità asincrone macchina-macchina su una rete Sistemi software progettati per supportare interazioni di interoperabilità asincrone macchina-macchina su una rete Problemi da affrontare Problemi da affrontare Lunga persistenza delle informazioni inerenti allo stato della chiamata Correlazione tra richieste e risposte

5 5 Correlazione a livello di trasporto Esistono protocolli di trasporto che supportano nativamente lasincronismo (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 lutilizzo dei WS a un ambito chiuso (Scarsa interoperabilità) Correlazione tramite semantica applicativa Correlazione implicita allinterno 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 limplementazione Non esiste separazione tra dati applicativi e problemi di implementazione

6 6 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 lordine di tali chiamate Memorizzazione e data warehousing di messaggi, operazioni e conversazioni tra WS Problema: Mancanza di standardizzazione

7 7 Correlazione tramite meta-dati di conversazione Contesto di conversazione Tramite il Contesto di conversazione Facile estrapolazione dei dati applicativi Facile estrapolazione dei dati applicativi Solo ConversationID per la correlazione Solo ConversationID per la correlazione Basso Overhead dovuto ai meta-dati Basso Overhead dovuto ai meta-dati Possibile mismatch delle risposte Possibile mismatch delle risposte

8 8 Correlazione tramite meta-dati di conversazione Contesto delloperazione Tramite il Contesto delloperazione Tutti i meta-dati di conversazione Tramite Tutti i meta-dati di conversazione Si implementa lintera struttura di meta-dati Ha lo stesso potere espressivo della tipologia precedente Aggiunge Overhead senza un beneficio reale Massimo potere espressivo Massimo potere espressivo Risolve il problema del mismatch Risolve il problema del mismatch Carico maggiore per il sistema

9 9 Polling pattern Request-response di invio della richiesta Request-response per sollecitare la risposta Estrema semplicità (Thin client) Estrema semplicità (Thin client) Basato su tecnologie e Modus Operandi collaudate Basato su tecnologie e Modus Operandi collaudate Bassa efficienza Ritardo della notifica Ritardo della notifica

10 10 Callback pattern Richiesta con identificativo e indirizzo di ritorno Risposta inviata allindirizzo di ritorno Alta efficienza Alta efficienza Possibilità di P2P Possibilità di P2P Possibilità di specificare lindirizzo di ritorno Possibilità di specificare lindirizzo di ritorno Il client deve pubblicare un servizio che accetta chiamate Standard non ancora consolidati Standard non ancora consolidati

11 11 Callback pattern con Acknowledgement Ogni operazione coinvolta è bidirezionale Vantaggi del Callback tradizionale Vantaggi del Callback tradizionale Consente la notifica di ricezione, rendendo possibile la verifica di non-ripudiazione (Fondamentale nel B2B) Consente la notifica di ricezione, rendendo possibile la verifica di non-ripudiazione (Fondamentale nel B2B) Svantaggi del Callback tradizionale Svantaggi del Callback tradizionale Duplicazione del n° di messaggi Duplicazione del n° di messaggi

12 12 Publish-Subscribe pattern Il cliente riceve più di una risposta Può essere esteso con un meccanismo di Acknowledgement Vantaggi del Callback tradizionale Vantaggi del Callback tradizionale Svantaggi del Callback tradizionale Svantaggi del Callback tradizionale

13 13 Pattern Multi-Attore (caso Callback) Interazione contemporanea tra più attori Anche gli altri pattern possono essere estesi in maniera simile

14 14 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 lURI Listanza del servizio può essere utilizzata o modificata dal client attraverso messaggi SOAP

15 15 Utilizzo dei buffer 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 Risolve problemi di rete Risolve problemi di rete Risolve problemi di Busy del WS Risolve problemi di Busy del WS Capacità del buffer limitata Costi aggiuntivi Costi aggiuntivi

16 16 Callback pattern Pubblica un servizio One-way per ricevere le richieste Pubblica un servizio One-way per ricevere le richieste Quando la risposta è pronta viene spedita tramite un altro servizio One-way Quando la risposta è pronta viene spedita tramite un altro servizio One-way Invia la richiesta tramite un servizio One-way Invia la richiesta tramite un servizio One-way Pubblica un altro servizio One-way per ricevere la risposta Pubblica un altro servizio One-way per ricevere la risposta INPUT: Parametri espliciti XML Document Invio OK Errore di trasporto INPUT: Parametri espliciti XML Document INPUT: Parametri espliciti XML Document Link da applicazione Coupling risposta Invio OK Errore di trasporto

17 17 Publish-Subscribe pattern Pubblica un servizio One- way per ricevere le richieste Pubblica un servizio One- way per ricevere le richieste Ogni volta che linformazione è disponibile viene spedita tramite un altro servizio One- way Ogni volta che linformazione è disponibile viene spedita tramite un altro servizio One- way Invia la richiesta tramite un servizio One-way Invia la richiesta tramite un servizio One-way Pubblica un altro servizio One-way per ricevere le risposte che via via saranno inviate Pubblica un altro servizio One-way per ricevere le risposte che via via saranno inviate INPUT: Parametri espliciti XML Document Link da applicazione Coupling risposta Invio OK Errore di trasporto Invio OK Errore di trasporto INPUT: Parametri espliciti XML Document INPUT: Parametri espliciti XML Document

18 18 Polling pattern Pubblica un servizio Request-response per ricevere le richieste e inviare un msg di avvenuta ricezione Pubblica un servizio Request-response per ricevere le richieste e inviare un msg di avvenuta ricezione Quando la risposta è pronta viene spedita tramite un altro servizio Request- response che si occupa anche della conferma Quando la risposta è pronta viene spedita tramite un altro servizio Request- response che si occupa anche della conferma Invia la richiesta e riceve la conferma tramite un servizio Request-response Invia la richiesta e riceve la conferma tramite un servizio Request-response Pubblica un altro servizio Request-response per ricevere la risposta e dare la conferma Pubblica un altro servizio Request-response per ricevere la risposta e dare la conferma INPUT: Parametri espliciti XML Document INPUT: CID INPUT: Parametri espliciti XML Document INPUT: CID

19 19 Mancanza di uno standard universalmente riconosciuto Mancanza di uno standard universalmente riconosciuto Mosaico di proposte indipendenti Tra le proposte individuate si evidenziano alcune idee chiave 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 Le unit WebML introdotte coprono ogni possibile tipologia di chiamata asincrona a WS Sviluppi futuri: Sviluppi futuri: Gestione delle eccezioni e impatto sulle comunicazioni asincrone

20 20 Francesco Seccia Matr. 666784 Francesco Seccia Matr. 666784 Marco Spinelli Matr. 667109 Marco Spinelli Matr. 667109


Scaricare ppt "Progetto realizzato da: Francesco Seccia Matr. 666784 Marco Spinelli Matr. 667109."

Presentazioni simili


Annunci Google