7. Cos’è un ESB
• ESB = Enterprise Service Bus
• Termine coniato nei primi anni 2000
• E’ un modello architetturale che permette
l’integrazione fra applicazioni (EAI)
• Si basa sull’astrazione di un BUS, in
maniera similare all’analogo concetto per
le architetture hardware
9. Cos’è un ESB
• Routing delle richieste
• Trasformazione dei dati
• Versionamento dei servizi
• Buffering delle richieste
• Bilanciamento e Scalabilità dei servizi
• Monitoring e controllo
11. Cos’è OSGI?
• Uno standard per un Java “Modulare”
• permette di “impacchettare” il codice in un
bundle (jar)
• gestisce le dipendenze dei bundle
• i bundle OSGI possono essere installati,
lanciati, fermati, aggiornati (Lifecycle
Management) ed offrire servizi
• OSGI = SOA in una JVM
• la prima versione risale al 2000 e nasce
negli ambienti telco.
12. Maven / Nexus
• Maven è lo standard “de facto” del dependency
management nel mondo Java
• Nexus è un repository Maven centralizzato che
facilita l’approccio “Devops”
• permette di gestire le dipendenze in maniera
controllata
• un server che contiene tutti gli “artifatti” del
processo di sviluppo
• Coadiuva la gestione dipendenze a runtime di OSGi
16. Cos’è ActiveMQ
• Il Messaging Broker Open Source più
diffuso al mondo
• JMS, AMQP, MQTT, OpenWire, STOMP, REST
• Java, C, C++, C#, Ruby, Perl, Python, PHP
• Pluggable Transport
• in-VM, TCP, SSL, NIO, UDP, JGroups
17.
18. Enterprise Integration Patterns
• Lavoro di Hohpe / Woolf
• Divenuto uno standard de facto
• parlare un linguaggio comune
• riutilizzo di know how e soluzioni
• Eliminazione codice custom dalle
implementazioni
• performance, bugs, quantità di codice
21. Cos’è Camel
• Framework Open source che implementa i
pattern EIP (>100 componenti)
• mapping 1:1 fra pattern e componenti
• le rotte camel sono gestite tramite OSGI
• per Container si intende il “contenitore” di
componenti OSGI
• OSGI : Container = EJB : J2EE Server
24. Cos’è ZooKeeper
• E’ un componente dell’ecosistema di Hadoop
• Serve a costruire logiche di coordinamento
• Sharding, Failover, Discovery, Master
election, ecc.
• Usato da HBase, Kafka, Solr, Yahoo, Fuse
Fabric8
29. Cos’è JBoss Fuse
• Middleware composto da:
• JBoss AMQ (ActiveMQ) per la
messaggistica
• Camel per le mediazioni (rotte)
• CXF per i Web Services
• Fabric8 per la governance (registry,
provisioning) con Zookeeper, git, hawt.io
• decine di sottocomponenti “minori”
37. Processo di sviluppo
• Raccolta del requisito di integrazione
• Se il tag A contenuto nel messaggio M ha
nel record corrispondente della tabella B il
campo X
• Trasformazione del messaggio M
(rimozione tag t1, aggiunta tag X)
• Successiva trasformazione del messaggio
M aggiungendo un tag t3
38. Processo di sviluppo
“Traduzione” del requisito in Enterprise
Integration Patterns
40. Processo di sviluppo
• Riportare gli EIP sotto forma di codice
• usando un DSL Java
• usando un DSL XML
• con un editor grafico (plugin per Eclipse)
43. Processo di sviluppo
• Impacchettare la rotta in un bundle OSGI
• mvn install
• Fare il push sul repository
• mvn deploy
44. Processo di sviluppo
• Tramite CLI console o Web Console, e
secondo le strategie di Roll-out aziendale,
prelevare il bundle dal repository
• I container selezionati faranno partire
automaticamente la rotta se il deploy è
andato a buon fine (in caso di autostart, il
default)
45. Processo canonico
• Il processo “canonico” dunque è:
• creare una nuova rotta che implementi le
nuove regole di business
• creare una nuova versione su Fabric, per
esempio 1.1
• effettuare un check facendo un upgrade di un
container alla 1.1
• roll-out su tutti i container o roll-back del
subset
46. DEFCON 2
• Il processo “DEFCON 2”:
• aprire la console grafica sui server di
produzione
• editare la rotta
48. Hawt.io
• Web console
• Progetto open source: Hawt.io
• Accesso completo e remoto:
• container, log, dashboard con strumenti di
controllo
• rotte camel, nodi AMQ, API Management,
cluster.
50. Hawt.io
• versioni, profili, bundle OSGI, ...
• permette il DEBUG grafico delle rotte camel,
con breakpoint
• permette di editare rotte camel, anche su
server di PRODUZIONE
• permette di effettuare dei TRACE delle rotte
• può mostrare i SORGENTI di codice Java che
ha sollevato un’eccezione
55. Performance ActiveMQ
• Persistenza AMQ basata su File system
• Utilizza LevelDB, un nosql di Google
• il Btree di indicizzazione di LevelDB
garantisce tempi O(1) per il caricamento dei
messaggi
• in altre parole, 3 o 30.000.000 di messaggi
persistenti vengono “presi in carico”
“istantaneamente” da un broker.
56. Performance ActiveMQ
• LevelDB permette anche eccellenti tempi di
scrittura sul file system
• La velocità del disco è il singolo fattore più
importante nel tuning.
• Circa 10k msg/secondo da 5kb sostenuti per
ore su un laptop moderno con SSD
• Circa 4.5k msg/secondo sostenuti sul server
di Amazon (9k msg/secondo con due dischi)
62. Scalabilità ActiveMQ
• AMQ offre diverse topologie per scalare
orizzontalmente:
• Network of Brokers
• Client side partitioning
63. Network of Brokers
• I messaggi vengono “inoltrati” fra i brokers
• Store and Forward
• Mono o bi-direzionale
• Questa topologia implica un certo grado di
comunicazione fra i broker (chattiness)
• Uno o più hop per raggiungere il server su
cui il messaggio è presente
65. Client side Partitioning
• E’ la topologia che permette di scalare
orizzontalmente in maniera illimitata
• I diversi Broker NON sono a conoscenza
l’uno dell’altro
• I client “partizionano” i messaggi secondo un
criterio qualsiasi
• In questa topologia è possibile avere una
singola coda deployata su centinaia di broker
67. Client side Partitioning
• E’ la topologia consigliata per ambienti ad
altissime performance, insieme al Master/
Slave per l’HA
• La natura dei messaggi deve prevedere criteri
di partizionamento
• E’ anche possibile avere diversi broker divisi
per area geografica per architetture Follow
The Sun
78. Resilienza
!
• Resilienza
• Architettura distribuita
• Failover
• Master/Slave per l’alta affidabilità
• Scalabilità orizzontale: Network of Brokers,
Client side partitioning
79. Manutenibilità
!
• Manutenibilità
• OSGI based, ciclo di vita dei componenti
standardizzato (con versionamento)
• Console di amministrazione molto potente
• Debug/Trace rotte, gestione log, editing
rotte, ...
80. Alte performance
• Alte performance
• da 4.5k a 10k messaggi al secondo per coda
(messaggi persistenti “reali” da diversi Kb)
• Possibile dedicare un broker ed un disco
per ogni coda (o anche distribuire la stessa
coda su più macchine ottenendo facilmente
> 100k msg/secondo)
• Tempi O(1) per presa in carico da parte del
broker