Benefici di Mule 4 - Parte 2
Come evidenziato nel primo post di questa serie, Mule 4 è un runtime con architettura diversa rispetto a quella della versione precedente Mule 3. I nuovi disegno ed architettura di questa versione portano dei miglioramenti sostanziali e nuove funzionalità. Nel post di oggi vedremo quali sono queste novità riguardo lo streaming e classloader isolation.
Streaming
Che cosa è lo streaming? In informatica, lo streaming è un meccanismo di trasmissione di dati che permette di fruire del contenuto desiderato senza la necessità di aspettare che questo ultimo sia completamente ricevuto. Nel contesto del runtime di Mule, lo streaming consiste nella capacità di un event processor di incominciare a girare senza aspettare ad aver ricevuto tutti i dati dell processor precedente. Questo, come potete immaginare è incredibilmente utile quando si lavora con grandi quantità di dati, arrays o collections, come nel caso di un insieme di records che provengono dal database, da un file, oppure da uno stream esterno come Salesforce.L’utilizzo di streams per l’elaborazione dei nostri records o grandi blocchi di dati, si traduce in un aumento della performance e della gestione della memoria. Ad esempio, se dovessimo lavorare con files molto grandi, di 5-10 GB, in assenza della capacità di streaming dovremmo provvisionare la nostra applicazione con almeno 5-10 GB per permettere alla stessa di mantenere tutto il file in memoria. Utilizzando streams, l’applicazione sarà in grado di funzionare con molto meno memoria.
Lo streaming in realtà non è una novità di Mule 4, in Mule 3 era già possibile gestire streams. Con Mule 4 però, la gestione è molto più avanzata:
Il meccanismo standard di caricamento di queste classi Java nella Java Virtual Machine può provocare dei problemi o conflitti di versioni tra queste librerie. Questo è un serio problema, sopratutto quando i connettori di una applicazione condividono certe classi, perchè nel momento che aggiorniamo la versione di un connettore o la versione del runtime è probabile che si facciano delle modifiche su queste classi condivise e ci sia un’impatto sul funzionamento di altri connettori della applicazione.
Per evitare questi problemi, Mule 4 incorpora un meccanismo aggiuntivo per l’isolamento tra l’applicazione, il runtime, i connettori e qualsiasi altra libreria. Grazie a questo meccanismo possiamo stare tranquilli e aggiornare la versione di un connettore senza dover aggiornare il runtime, oppure aggiornare il runtime senza avere problemi di compatibilità con i connettori.
Come funziona?
- Prima di tutto, la gestione è automatica, come developers non ci dobbiamo preoccupare di quali componenti fanno streaming e quali no.
- Secondo, i dati nello stream possono essere consumati più di una volta.
- Possiamo scegliere se i dati vengono salvati in memoria o in disco e quindi decidere se vogliamo elaborare volumi di dati più grandi rispetto alla memoria provvista dall’applicazione.
- E' possibile, infine, utilizzare streams in parallelo.
Classloader Isolation
Il runtime di Mule è sviluppato in Java e quindi utilizza tante librerie Java. Le applicazioni di mule utilizzano librerie aggiuntive, in particular modo i moduli o extensions che forniscono integrazione, ovvero i connettori. I famosi connettori di Mule sono normalmente wrappers di librerie Java.Il meccanismo standard di caricamento di queste classi Java nella Java Virtual Machine può provocare dei problemi o conflitti di versioni tra queste librerie. Questo è un serio problema, sopratutto quando i connettori di una applicazione condividono certe classi, perchè nel momento che aggiorniamo la versione di un connettore o la versione del runtime è probabile che si facciano delle modifiche su queste classi condivise e ci sia un’impatto sul funzionamento di altri connettori della applicazione.
Per evitare questi problemi, Mule 4 incorpora un meccanismo aggiuntivo per l’isolamento tra l’applicazione, il runtime, i connettori e qualsiasi altra libreria. Grazie a questo meccanismo possiamo stare tranquilli e aggiornare la versione di un connettore senza dover aggiornare il runtime, oppure aggiornare il runtime senza avere problemi di compatibilità con i connettori.
Come funziona?
- Classloader isolation fa la separazione tra l’applicazione, il runtime ed i connettori
- Ogni componente dentro della applicazione ha il suo classloader
- Il codice dell’applicazione gira separatamente dal codice del runtime
Che succedeva con Mule 3?
- Il processo di upgrade era delicato perchè il codice delle applicazioni dipendeva e si appoggiava su librerie condivise con il runtime.
- Per questo motivo, nel momento di aggiornare il runtime si doveva stare attento a queste librerie e aggiornare non solo il runtime ma anche il codice delle applicazioni.
