Manage users with Java Message Service

1
Manage users with Java Message Service
Università degli Studi di Bologna FACOLTÀ DI
INGEGNERIA Corso di Laurea in Ingegneria
Informatica L-S Anno Accademico 2005-2006

• Autore NICOLA IOVINO
• Matricola 171684
• Corso Reti Di Calcolatori L-S
• Docente Prof. Antonio Corradi

2
Introduzione

• Molte aziende nellambito dellE-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.

Nellambito dellE-commerce i profili utente sono
utilizzati per la pianificazione delle risorse
dellimpresa (ERP),per amministrare i rapporti
con i clienti (CRM) e amministrare le catene di
rifornimento (SCM).
3
Obiettivi dellapplicazione

• Lobiettivo è 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.

4
Infrastruttura Middleware

• Un sistema di middleware Message-Oriented (MOM)
  è una infrastruttura che permette lo scambio di
  dati fra le applicazioni mediante linvio 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

5
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 unapplicazione JMS sono
  sintetizzabili in

• Robustezza ai cambiamenti
• Time independence
• Location independence
• Qualità del servizio configurabile

• Supporto per i due modelli base PTP, Pub/Sub

6
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.

7
Schema generale
User
JMS Topic
Account Manager
JMS Publisher
Account Manager è linterfaccia che consente di
aggiornare le informazioni dellutente. Una volta
aggiornato il master database, il topic verrà
notificato dal JMS Publisher.
Master DB
8
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 nelleventuale 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.

9
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() nellinterfaccia di callback.

10
Struttura di un messaggio

• Con JMS è possibile integrare un documento XML
  allinterno di un messaggio. La struttura di un
  messaggio sarà allora

ltUserProfilesgt ltUsergt ltActiongtCreatelt/Actiongt
ltUsernamegtRedlt/Usernamegt ltFirstNamegtPaololt/Firs
tNamegt ltLastNamegtRossilt/LastNamegt ltEmailgtpross
i_at_provider.itlt/Emailgt   lt/Usergt lt/UserProfilesgt
XML è una tecnologia non proprietaria che
consente di scambiare dati fra applicazioni
eterogenee.
11
Architettura Cluster (1)

• Per conseguire gli obiettivi di reliability e
  high availability occorre ovviare alleventuale
  caduta del JMS Provider

Su ogni broker del cluster vanno replicate le
ConnectionFactories, Destinations e
DurableSubscriptions
Failover il cliente si connette ad un nodo nel
cluster e auto-fail over in un nuovo nodo se
cè fallimento.
Clustering realizzato in maniera trasparente. Il
topic è disponibile allinterno del cluster.
12
Architettura Cluster (2)

• Per realizzare larchitettura 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
  auto-reconnects 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.

13
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 ) )
14
Replicated Message Store (2)

• 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 allaltro broker del cluster che non
possiede nel suo persistent storage il messaggio
inviato precedentemente.
15
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
16
Architettura e Interfaccia
17
Conclusioni

• Il framework descritto sopra offre un sistema
  robusto ed efficiente per la gestione dei profili
  utente. Consente, grazie al modello uno-a-molti,
  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, lutilizzo di queste due
  tecnologie insieme offre una importante soluzione
  per molti enterprise application problems.

• Possibili miglioramenti possono riguardare
  limplementazione di politiche di sicurezza e
  lutilizzo di JSP o Servlets per la gestione dei
  profili utente.