presentazione

Simple Message-Oriented
Middleware
Autore: Bernardi Giorgio
Matricola: 0000.156.516
Corso di Laurea Specialistica in Ingegneria Informatica
Corso di Reti di Calcolatori LS
Università di Bologna
Obiettivi
Realizzare un middleware con i seguenti fini
 Consentire scambio di messaggi fra
applicazioni diverse
 Consentire di lavorare in modo orientato
agli oggetti con oggetti remoti
 Consentire il dialogo fra una applicazione
Java e una Visual Basic/COM
 Realizzare librerie il cui setup sia semplice e
veloce da parte del programmatore
Architettura Logica
 Middleware:
1. Nucleo di
comunicazione
2. Strato di servizi



Applicazione:
 Sfrutta i servizi
 Sfrutta il nucleo di
comunicazione
direttamente
Comunicazione anche
fra più applicazioni
Middleware
ampiamente
estendibile
Nucleo di Comunicazione
 Componenti:
 messaggio: contenuto della comunicazione
 Sender: colui che inizia la comunicazione
inviando il messaggio;
 Receiver: entità alla quale il messaggio deve
pervenire;
 canale: ambiente attraversato dal messaggio
per raggiungere il Receiver
 Infrastruttura: entità aggiuntive che ricevono il
messaggio dal Sender e fanno in modo che
giunga al Receiver
Infrastruttura di comunicazione
 Dispatcher per implementare politiche diverse
(code, priorità di messaggi, ecc…)
 MsgManager per gestire il canale di comunicazione
in maniera sequenziale
 Comunicazione tramite nomi ad-hoc univoci
(ObjectID e MsgManagerAddress)
Infrastruttura di comunicazione
 Molte configurazioni differenti organizzando i
dispatcher, i Receivers e i MsgManager
 Un Manager per ogni canale differente:
 Socket
 Mail
 Passaggio di messaggi locale fra oggetti della stessa
applicazione
 Tuple, ecc…
Servizi per Object Oriented
Programming inter-application
 Mappaggio di chiamate a
metodi mediante oggetti
CProcedure e oggetti CValue
che contengono valori
primitivi
 Utilizzo di Stub e Skeleton per
incapsulare l’invio di messaggi
per eseguire Remote
Procedure Calls
 Stub e Skeleton statici (per
una singola classe) generati in
automatico da dichiarazioni di
classi in Java, Vb, ecc…
 …
Stub e Skeleton Dinamici
 … oppure Stub e Skeleton dinamici implementati
dall’SMom


Proxy che implementa l’interfaccia desiderata e usa lo Stub
dinamico
Skeleton usa chiamate con late binding verso la classe da
raggiungere
Politiche per lo Stub
 Recupero del risultato:
 Fire & Forget
 Attesa sincrona del chiamante
 Polling del chiamante per recuperare il
risultato
 Attesa/Polling di un delegato che
successivamente mi passa il risultato
 Call back da parte dello stub
 Ecc…
Conclusioni
 E’ stato possibile realizzare una libreria Java e una
Visual Basic/COM che cooperano e comunicano fra
loro
 Applicazioni facilmente realizzabili
 Setup molto semplice
 Sistema di esempio:
 Applicazione Java (NavalBattle.jar)
 Applicazione Java wrapper
 Applicazione Visual Basic che dialoga con il wrapper
 Applicazioni di test
 Test Visual Basic
 Test Java locale