Apache Servicemix

Apache ServiceMix è rilasciato sotto licenza Apache (Open Source) ed è una implementazione di Enterprise Service Bus che combina le funzionalità di Service Oriented Architecture e Event Driven Architecture utili nelle attività di system integration tra sistemi informativi eterogenei.

Lo sviluppo dell'Enterprise Service Bus ServiceMix è stato caratterizzato dai seguenti obiettivi:

  • Permettere a componenti e servizi di essere integrati in maniera indipendente.
  • Garantire il disaccoppiamento dei servizi, agendo da mediatore tra essi.
  • Fornire funzionalità di plug and play.
  • Fornire un ambiente di esecuzione per il deploy e l’attivazione dei servizi, associati a tools di progetto in grado di definirne le interazioni.
  • Fornire un’infrastruttura software che permette l’impiego di architetture SOA (Service-Oriented Architecture)

In termini Generali un Enterprise Service Bus è una tipologia di Middleware in grado di integrare varie tecnologie informatiche al fine di creare servizi ampiamente disponibili per il riuso.

Le funzioni fondamentali offerte da un ESB includono:

  • Protocolli di trasporto per i servizi
  • Definizione e scoperta dei servizi installati
  • Gestione ed instradamento dei messaggi

Un ESB genericamente supporta quindi:

  • L’eterogeneità dei messaggi, intesa sia in termini di molteplicità di modelli (sincroni, asincroni, publish e subscribe), sia in termini di molteplicità di formati(SOAP, XML).
  • Molteplici protocolli di trasporto per l’instradamento (FTP, HTTP, JMS).
  • Scoperta dei servizi, memorizzando informazioni su di essi (schemi,WSDLs e politiche).
  • Una gestione centralizzata e un accesso distribuito ai servizi.

L’aspetto chiave delle architetture JBI è il disaccoppiamento dei servizi, cosicché, la business logic non risulta essere caricata dai dettagli dell’infrastruttura, richiesti per l’invocazione ed il consumo dei servizi. Ciò garantisce un’architettura flessibile ed estensibile.

All’interno di JBI, sia i Binding Components che i Service Engine Components, possono assumere il ruolo di fornitori di servizi e/o consumatori di servizi.

In JBI esistono due tipi di componenti:

Binding Component (BC) :

sono essenzialmente adattatori di protocollo (consentono di agganciare il bus JBI a fonti di dati/servizi esterni come ad esempio database, web services, servizi CORBA ecc…)

Service Engine (SE) :

sono componenti interni al bus che implementano una logica applicativa (consentono di applicare delle logiche applicative ai messaggi che fluiscono nel bus, ad esempio logiche di routing, logiche di trasformazione o logiche di processo).

JBI utilizza un formato “normalizzato” per la rappresentazione dei messaggi all’interno dell’ambiente di sviluppo (NMR ).

Un messaggio normalizzato è costituito dalle seguenti parti:

  • Proprietà del messaggio: costituiscono i dati extra associati al messaggio. Possono contenere informazioni sulla sicurezza, informazioni su specifici componenti, etc.
  • Carico del messaggio: racchiuso in un documento XML.
  • Allegati del messaggio

ServiceMix nello specifico mette a disposizione 2 tipi di componenti:

Le Service Unit (SU)

Le Service Assembly (SA)

Le SU si dividono concettualmente tra BC (Binding Component) e SE (Service Engine).

Sono i componenti che si interfacciano col NMR (Messaggio normalizzato) e le vere unità funzionali. ServiceMix mette a disposizione dei componenti standard per semplificare lo sviluppo delle applicazioni

Le SA hanno il semplice ruolo di accorpare tutte le SU di un progetto per permettere il suo deploy (in pratica sono una sorta di applicazioni pacchettizzate per l’ESB).

Tecnologia dei messaggi NMR

esb xml message

Quella dei messaggi è una tecnologia che abilita comunicazioni tra procedure ad alta velocità in modalità sincrona o asincrona con certezza di consegna. In un paradigma di integrazione a messaggi le procedure comunicano inviando pacchetti di dati chiamati messaggi l'una verso l'altra.

I Canali , indicati anche come “code”, sono i percorsi logici che connettono le procedure e convogliano i messaggi. Un canale agisce come una collezione di array di messaggi, ma che è “magicamente” condivisa tra più sistemi di calcolo e può essere utilizzata in maniera concorrente da applicazioni multiple.
Un “producer” è una procedura che invia un messaggio scrivendolo in un canale. Un “Consumer” è una procedura che riceve messaggi leggendoli (e cancellandoli) da un canale.

Il Messaggio in se è semplicemente una sorta di struttura dati, come una stringa, un array di byte, un oggetto, UN DOCUMENTO in qualità di file binario.

Il messaggio può semplicemente essere interpretato come un dato, come la descrizione di un comando da invocare o come la descrizione di un evento occorso al “Producer”

Un messaggio è composto essenzialmente da due parti:

Un Header ed un Body.

L'Header contiene meta-informazioni relative al messaggio (chi lo invia, dove è destinato, etc) che sono utilizzate dal sistema di messaggistica e generalmente sono ignorate (ma non sempre) dalle applicazioni.

Il Body contiene i dati trasmessi ed è ignorato dal sistema di messaggistica.

Un approccio a messaggi fornisce alcuni vantaggi rispetto alle altre tecnologie di integrazione:

  • Sono più immediati rispetto ad un file transfer
  • Sono incapsulati in maniera migliore rispetto ad un database condiviso
  • Sono più robusti rispetto ad una chiamata RPC semplice

Inoltre la possibilità di utilizzare tecniche di accodamento e sincronizzazione differita può essere preziosa per procedure di produzione documentale originariamente non pensate per operare in rete.

La integrazione mediante un modello a messaggi è caratterizzata da il concetto di “loose coupling”.

Tale concetto di integrazione tra applicazioni informatiche è ormai ben noto sopratutto con il successo e la diffusione del paradigma dei “web services”.

Il principio che sta alla base del “loose coupling” è quello di ridurre il numero di assunti che due parti (componenti, applicazioni, servizi, programmi, utenti...) fanno circa l'altro quando si scambiano informazioni.

Maggiori infatti sono questi assunti riguardo l'altra parte ed il protocollo comune, maggiore può essere l'efficienza di comunicazione, ma minore è la tolleranza della soluzione riguardo ad interruzioni o cambiamenti a causa del fatto che le parti sono strettamente accoppiate tra di loro.

Una integrazione di tipo loose coupling è desiderabile sopratutto quando i sistemi informatici interessati dalla integrazione sono caratterizzati da cicli di vita differenti, scenari di uso differenti e tecnologie a obsolescenza differenziata, tutte caratteristiche che assolutamente riguardano lo scenario di riferimento nel quale si inquadra il progetto e la tematica generale.

Una integrazione di tipo loose coupling è esattamente quella assicurata dalla adozione di una soluzione di middleware come un ESB come Apache ServiceMix.

CAMEL Mediation Router

Servicemix è distribuito generalmente completo di un gruppo di tecnologie complementari preziose per strutturare in maniera rigorosa il lavoro di implementazione delle procedure di integrazione in ottica SOA.

La prima di queste è Apache Camel.

Apache Camel è un potente framework di integrazione basato sui noti Enterprise Integration Patterns (EIP) completo di una comoda possibilità di operare con semplici java bean.

Camel permette di creare EIP al fine di implementare regole di routing e mediazione dei messaggi sia mediante il linguaggio Java (Fluent API), sia via Spring o file di configurazione basati su xml, sia tramite il linguaggio Scala.
Il risultato è che è possibile ottenere funzioni di autocompletamento intelligente delle regole di routing all'interno di un qualsiasi IDE sia che si lavori in linguaggio Java, che xml, che Scala.

Camel è progettato per utilizzare un sistema di Uniform Resource Identifier (URI) in modo da poter operare facilmente con qualsiasi tipo di trasporto o modello di messaggistica come HTTP, JMS, Webservices, Rest, Ftp, etc unito ad un “Pluggable data format”.

La conseguenza è che con Camel è possibile lavorare con la stessa API indipendentemente dal tipo di trasporto utilizzato ed una volta appresa tale API si è in grado di interagire con tutti i numerosissimi componenti che sono forniti a corredo .

ACTIVEMQ Message broker

Un secondo componente utilizzato “in bundle” con ServiceMIx è il message broker open source Apache ActiveMQ, sicuramente il sistema JMS open source più utilizzato e diffuso. Sebbene ActiveMQ sia scritto in java, sono disponibili API standard per una grande varietà di linguaggi inclusi C/C++, .NET, Perl, PHP, Python, Ruby ed altri.

Il compito di un Message broker nell'ambito delle architetture SOA è essenzialmente quello di garantire la ricezione e la consegna dei messaggi che gli sono affidati per recapitarli ai servizi e per tale motivo è generalmente previsto di configurarlo in modalità di alta affidabilità e con l'opzione di poter scalare seguendo la necessità applicativa.

Esso fornisce delle “code” nelle quali i messaggi possono essere memorizzati prima di essere processati ed implementa una serie di meccanismi per garantire la consegna di tali messaggi a destinazione nelle modalità sincrona o asincrona.

ActiveMQ offre due importanti caratteristiche tecnologiche:

Il supporto ad una ampia gamma di possibilità di connettività con il supporto di HTTP/S, IP multicast, SSL, STOMP, TCP, UDP, XMPP etc

Il sistema di persistenza modulare che permette di configurare le modalità di persistenza dei messaggi nelle code secondo ogni specifica esigenza e strategia. Moduli di persistenza di uso comune sono il motore di persistenza su file system molto veloce KahaDB oppure il classico utilizzo di un database engine tramite connessione jdbc.

Come abbiamo accennato ActiveMQ supporta una API multilinguaggio. Per ambienti Microsoft oriented (spesso utilizzati per applicazioni di gestione e produzione di documenti).

Certamente la possibilità di utilizzare tali librerie rappresenta una risorsa preziosa per sviluppare alcuni moduli di connessione al middleware di integrazione da ambienti Microsoft.

APACHE CXF

Apache CXF è un framework per la costruzione di servizi applicativi in java open source.

I servizi implementati mediante Apache CXF sono in grado di utilizzare vari tipi di protocolli come SOAP, XML/HTTP, REST o Corba, operando su una varietà di protocolli di trasporto come Http, JMS (protocollo tipico di ActiveMQ) o JBI. La principale finalità della presenza di CXF in bundle con Apache ServiceMix è quella di garantire una robusta implementazione dello standard webservices/SOAP
 

KARAF

Karaf è il kernel di ServiceMix che implementa lo standard Osgi e che offre una serie di servizi di gestione per l'ambiente di runtime.

Tra questi servizi vi sono:

  • Hot deployment dei servizi nell' ESB
  • Configurazione dinamica
  • Servizi di logging
  • Provisioning
  • Servizi di sicurezza basati su Jaas
     

EIP : Enterprise Integration Patterns

La scelta di utilizzare un sistema di ESB come ServiceMix per la implementazione dei componenti e dei servizi di integrazione richiesti dal progetto nasce per appunto dalla considerazione che nel caso specifico l'utilizzo del bundle “Servicemix – Camel - ActiveMQ” ci offre un ambiente applicativo nel quale è possibile affrontare le problematiche di integrazione utilizzando la metodologia degli Enterprise Integration Patterns.

L'esigenza da risolvere attiene principalmente alla soluzione di problematiche di integrazione tra sistemi informatici ed solo in secondo grado riguarda il tema della trasmissione di documenti digitali.

In qualità di progetto di integrazione di sistemi il tema pone dei classici problemi tra cui:

  1. Il limitato grado di controllo che l'integratore possiede sulle applicazioni che partecipano alla integrazione. Molto spesso si tratta di sistemi “legacy” o applicazioni “pacchettizzate” che non possono essere modificate per essere connesse ad una soluzione integrata.
  2. Nell'ambito dell'integrazione di sistemi, il fatto che si adotti una rappresentazione comune (es. XML) non implica di per se di poter contare su una semantica comune. Per esempio la notazione di “account” può avere molte semantiche differenti, connotazioni, vincoli ed assunti in ciascun sistema partecipante. Risolvere le differenze semantiche può rappresentare una grossa parte dello sforzo complessivo di integrazione con importanti implicazioni sulle scelte tecniche.
  3. Mantenere una soluzione di integrazione nel tempo può essere più oneroso che svilupparla.
    L'insieme di tecnologie e la natura distribuita delle soluzioni di integrazione tra sistemi rendono lo sviluppo,il monitoraggio e la soluzione dei problemi dei compiti complessi che richiedono un insieme di competenze esteso. In molti casi esse possono non essere presenti tra il personale operativo IT o essere “polverizzate” tra molti individui.

Nei fatti non esiste una risposta semplice alle problematiche di integrazione tra sistemi, ma viceversa esistono best practice, ovvero schemi di soluzioni, per problemi ricorrenti che sono state identificate e formalizzate mediante l'esperienza.
Tali schemi non sono un mero copia ed incolla di esempi o componenti, ma viceversa formalizzazioni che descrivono soluzioni a problemi frequentemente ricorrenti. Usati in maniera propria gli “Enterprise Integration Patterns (metodologia presente all'interno di Camel) possono aiutare a coprire il gap tra una visione di alto livello della integrazione e la sua concreta implementazione.

eip-example

Vantaggi dell’approccio EIP

  1. Loose Coupling: Le applicazioni sono integrate in maniera disaccoppiata. La eventuale sostituzione di uno dei sistemi informativi implicherebbe la necessità di riscrivere solo il singolo Service Adapter specifico.
  2. Scalabilità e business continuity: L'ESB ServiceMIX ed i componenti citati possono essere configurati in clustering ed il carico di lavoro può essere bilanciato.
    L'uso congiunto di componenti di routing Camel e del message broker ActiveMQ permettono di implementare installazioni ESB distinte che sono in grado di richiamarsi a vicenda in una architettura geograficamente distribuita.
  3. Orchestrazione ed estensibilità: I componenti all'interno di un ESB operano con messaggi normalizzati e sono pertanto in grado di essere “concatenati” direttamente all'interno del bus mediante regole di “Business Process” in grado di realizzare processi più complessi a partire da componenti più semplici (orchestrazione). Per esempio nel caso in oggetto, stanti i componenti base per l'integrazione con il DM Alfresco, è possibile aggiungere componenti per l'esecuzione di firma elettronica batch mediante HSM o componenti di verifica della validità del certificato di documenti contenenti firme digitali e quindi aggiungerli alla catena di processo in maniera trasparente. L'applicazione invia un documento al repository mediante l'ESB e il documento viene memorizzato completo di firma elettronica nel repository in maniera trasparente alla applicazione chiamante. E possibile implementare un pattern “Filter” per dirottare su un componente specifico tutti i documenti non conformi in termini di validità del certificato.. e via così.
  4. Supporto di modalità sincrone ed asincrone: L'insieme delle tecnologie incluse con il sistema Esb ServiceMix permette di utilizzare i medesimi servizi di content store sia con chiamate sincrone, sia con chiamate asincrone.
  5. La disponibilità di librerie NMS per i linguaggi Microsoft VB, .NET e C# per ActiveMQ permette di utilizzare il protocollo OpenWire per la massime prestazioni. In alternativa le librerie STOMP forniscono la possibilità di interagire con le code con un livello di astrazione maggiore e quindi in modo più semplice ed immediato.
  6. Disponibilità di modalità “Publish/Subscribe: Nel caso due o più isole applicative debbano dover ricevere gli stessi messaggi questa modalità permette di non curarsi di prevedere una specifica gestione logica perché è sufficiente che tutte le applicazioni riceventi eseguano un "subscribe" al canale di interesse per ricevere automaticamente i messaggi che transitano nello stesso.
  7. Possibilità di usare il protocollo JMS per trasportare in maniera affidabile richieste SOAP in alternativa al protocollo http semplice
  8. Possibilità di aggiungere facilmente altri “end point” grazie alla disponibilità del framework Camel