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:
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:
Un ESB genericamente supporta quindi:
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:
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
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:
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:
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:
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.
Vantaggi dell’approccio EIP