presentazione

Università degli Studi di Bologna
FACOLTÀ DI INGEGNERIA
Corso di Laurea in Ingegneria Informatica L-S
Anno Accademico 2005-2006
Manage users with Java Message
Service
Autore: NICOLA IOVINO
Matricola: 171684
Corso: Reti Di Calcolatori L-S
Docente: Prof. Antonio Corradi
1
Introduzione
 Molte aziende nell’ambito dell’E-commerce utilizzano un
insieme di applicazioni che memorizzano le proprie copie di
contatti utente al loro interno.
 Spesso molte informazioni relative agli utenti vengono
memorizzate in molte enterprise applications.
Nell’ambito dell’E-commerce i profili
utente sono utilizzati per la
pianificazione delle risorse dell’impresa
(ERP),per amministrare i rapporti con i
clienti (CRM) e amministrare le catene di
rifornimento (SCM).
2
Obiettivi dell’applicazione
 L’obiettivo è quello di mantenere le copie di profili utente
consistenti fra le varie applicazioni eterogenee per evitare
confusione.
 Occorre quindi una infrastruttura semplice di comunicazione fra
le varie enterprise applications; la comunicazione deve essere
affidabile, anche su reti non affidabili, così che le informazioni
non vengano perse.
 Dati questi rigidi obiettivi di affidabilità possiamo escludere
alcune soluzioni e protocolli come RMI, RPC, ecc.:tutte queste
tecnologie infatti, oltre ad essere sincrone, richiedono una
connessione fisica attiva fra il cliente e il server.
3
Infrastruttura Middleware
 Un sistema di middleware Message-Oriented (MOM) è una
infrastruttura che permette lo scambio di dati fra le applicazioni mediante
l’invio e la ricezione di messaggi con le seguenti caratteristiche:
 Elevato disaccoppiamento delle applicazioni
 Asincronicità
 Supporto alla comunicazione molti-a-molti
 Scalabilità
 I modelli di base per la gestione dei messaggi sono essenzialmente
due:
 Point-to-Point
 Publish and Subscribe
4
Java Message Service
 JMS è una specifica Sun facente parte della piattaforma J2EE che
fornisce un metodo standard tramite il quale le applicazioni
possono creare, inviare e ricevere messaggi usando un sistema
MOM.
 Le qualità di un’applicazione JMS sono sintetizzabili in:
 Robustezza ai cambiamenti
 Time independence
 Location independence
 Qualità del servizio configurabile
 Supporto per i due modelli base: PTP, Pub/Sub
5
Architettura logica
 Un sistema architettato con JMS è
costituito da:
-Client JMS
-Messaggi
-JMS Provider
-Administered Objects
 Mappiamo gli Administered Objects in uno spazio di nomi JNDI (Java Naming
Directory Service). JNDI è una serie di API per accedere a differenti servizi di
directory e naming. JMS utilizza JNDI per recuperare i references agli
Administered Objects: ConnectionFactory e Destination.
6
Schema generale
User
JMS Subscriber
(ERP)
Manager
Master
DB
JMS Publisher
Account Manager è l’interfaccia che
consente di aggiornare le informazioni
dell’utente. Una volta aggiornato il
master database, il topic verrà
notificato dal JMS Publisher.
JMS Topic
Account
JMS Subscriber
(SCM)
JMS Subscriber
(CRM)
7
Garanzie di consegna (1)
 Per conseguire la consegna affidabile e garantita dei messaggi dal
publisher ai subscribers occorre prendere degli accorgimenti:
• Il Publisher deve settare il DeliveryMode dei messaggi a
PERSISTENT: ciò evita che i messaggi non vengano persi
nell’eventuale caduta del provider (Persistent Storage).
• Le subscriptions verranno rese Durable: questa scelta
implica che se un subscriber è inattivo il messaggio non
viene perso ma piuttosto consegnato quando il subscriber
tornerà attivo nuovamente.
8
Garanzie di consegna (2)
• La sessione di un subscriber è caratterizzata dalla modalità
AUTO_ACKNOWLEDGE. Un messaggio non è “acknowledged”
finché non è consumato con successo: nel nostro caso il
messaggio verrà riconosciuto quando entrerà in funzione il
meccanismo di callback del sistema.
Consegna con modalità once-and-only-once
 Callback: handler “event driven” invocato in maniera
asincrona quando un nuovo messaggio arriva.
 Il subscriber registra un oggetto di callback. I messaggi
sono ricevuti invocando il metodo onMessage()
nell’interfaccia di callback.
9
Struttura di un messaggio
 Con JMS è possibile integrare un documento XML all’interno di
un messaggio. La struttura di un messaggio sarà allora:
<UserProfiles>
<User>
<Action>Create</Action>
<Username>Red</Username>
<FirstName>Paolo</FirstName>
XML è una tecnologia non
proprietaria che consente di
scambiare dati fra
applicazioni eterogenee.
<LastName>Rossi</LastName>
<Email>[email protected]</Email>
</User>
</UserProfiles>
10
Architettura Cluster (1)
 Per conseguire gli obiettivi di reliability e high availability
occorre ovviare all’eventuale caduta del JMS Provider:
Network of
Broker 2
Publisher
Broker 1
Clustering realizzato in
maniera trasparente. Il
topic è disponibile
all’interno del cluster.
Su ogni broker del cluster
brokers
vanno replicate
le
Failover:
il cliente si
ConnectionFactories,
connette ad un nodo nel
Destinations e
cluster e “auto-fail over” in
DurableSubscriptions
un nuovo nodo se c’è
fallimento.
Subscriber
11
Architettura Cluster (2)
 Per realizzare l’architettura cluster sfruttiamo le funzionalità
messe a disposizione dal JMS provider della LogicBlaze:
ActiveMQ.
 Utilizzeremo a questo scopo un protocollo messo a disposizione da
ActiveMQ:
Reliable: Provides a list of possible URIs to connect to and one is
randomly chosen. If the connection fails then the transport autoreconnects to a different one.
 Per le operazioni di recovery dopo un fallimento un broker sfrutta
il proprio PERSISTENT STORAGE dove potrà recuperare:
le destinazioni, la lista di “durable subscriptions”, la lista di “acks” per ogni
messaggio, lo stato di tutte le transizioni committed.
12
Replicated Message Store (1)
 Per conseguire gli obiettivi preposti del sistema occorre utilizzare un
sistema di gestione della persistenza.
 Per gestire il caso di subscribers non attivi occorre prevedere un
sistema che memorizzi il messaggio finché questo non verrà
consegnato. Questo ruolo è svolto da un database persistente in cui
verrà memorizzato il messaggio non “acknowledged”. Nel nostro
caso esso è rappresentato da una tabella realizzata in SQL:
CREATE TABLE ACTIVEMQ_MSGS(
ID INTEGER NOT NULL,
CONTAINER VARCHAR(250),
MSGID VARCHAR(250),
MSG BLOB,
PRIMARY KEY ( ID ) )
13
Replicated Message Store (2)
 Ma come gestiamo la persistenza con un cluster di brokers?
 Si presentano allora due scenari:
• Se entrambi i brokers fanno riferimento a un singolo
“persistent storage”
Singolo punto di fallimento
• Se il broker che gestisce un messaggio diretto a un
subscriber inattivo cade
Il cliente per aggiornare i propri profili utente si connette all’altro broker del
cluster che non possiede nel suo persistent storage il messaggio inviato
precedentemente.
14
Replicated Message Store (3)
 Per ovviare a questi inconvenienti ricorriamo al concetto di
RAIDb (Redundant Array Of Inexpensive Databases)
RAIDb fornisce affidabilità migliore di quella di un singolo database
combinando molteplici istanze di database in una matrice di database.
Nel nostro caso ricorriamo a RAIDb-1 (mirroring): il database è
completamente replicato su ogni macchina.
Riusciamo così a fare riferimento a una
astrazione di database che in realtà è
composto da due backends reali posti su due
macchine diverse.
Sfruttiamo i driver C-JDBC
15
Architettura e Interfaccia
Architettura del progetto:
Publisher:
Subscriber:
16
Conclusioni
 Il framework descritto sopra offre un sistema robusto ed efficiente
per la gestione dei profili utente. Consente, grazie al modello uno-amolti, la consegna garantita dei messaggi e dunque affidabilità.
 Il sistema garantisce sincronizzazione fra applicazioni eterogenee
senza che questa sia ottenuta esplicitamente ad intervalli regolari.
 Sebbene JMS non sia nato specificamente per scambiarsi dati XML,
l’utilizzo di queste due tecnologie insieme offre una importante
soluzione per molti “enterprise application problems”.
 Possibili miglioramenti possono riguardare l’implementazione
di politiche di sicurezza e l’utilizzo di JSP o Servlets per la
gestione dei profili utente.
17