Simple Message-Oriented Middleware

1
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
2
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

3
Architettura Logica

• Middleware
• Nucleo di comunicazione
• Strato di servizi
• Applicazione
• Sfrutta i servizi
• Sfrutta il nucleo di comunicazione direttamente
• Comunicazione anche fra più applicazioni
• Middleware ampiamente estendibile

4
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

5
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)

6
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

7
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
  linvio 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

8
Stub e Skeleton Dinamici

• oppure Stub e Skeleton dinamici implementati
  dallSMom
• Proxy che implementa linterfaccia desiderata e
  usa lo Stub dinamico
• Skeleton usa chiamate con late binding verso la
  classe da raggiungere

9
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

10
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