WSO2 ESB Balance SugarCRM Proxy Service

Ho ricevuto svariati input per approfondire l’argomento Proxy Service e allora così sia. Il caso di studio (poi molto vicino al reale) che ho intenzione di proporvi, tratterà sempre il tema del Proxy Service (su WSO2 ESB) verso i servizi SOAP esposti da SugarCRM, introducendo però dei meccanismi di elaborazione del messaggio poco più complessi.

1. Presentazione del caso di studio

All’interno della nostra ipotetica azienda tutti i sistemi comunicano tra loro attraverso un Enterprise Service Bus (ESB) che nel nostro caso è implementato tramite la soluzione WSO2 ESB. I sistemi “registrati” comunicano per mezzo dell’ESB tramite apposite interfacce/connettori e sempre l’ESB regola il flusso dei messaggi. In Figura 1 è mostrato lo schema d’integrazione dei sistemi aziendali sull’ESB.

Figura 1 Integrazione sistemi aziendali via ESB

Figura 1 Integrazione sistemi aziendali via ESB

L’accesso ai dati del sistema CRM (implementato dalla soluzione di SugarCRM) dovrà avvenire per mezzo di un Proxy Service esposto sull’ESB, regolato sulla base della rete di provenienza della richiesta e come ultimo requisito, bilanciato sulle diverse istanze dei servizi di backend esposti dal CRM. In sintesi, il Proxy Service da configurare sull’ESB dovrà eseguire le seguenti operazioni:

  1. Risalire all’indirizzo IP di chi sta richiedendo l’accesso al servizio;
  2. Filtrare l’accesso ai servizi di backend per consentire l’accesso alle sole reti fidate:
    • 10.1.1.0/28 (internal network dipartimento Sales)
    • 10.1.2.0/28 (internal network dipartimento Marketing)
    • 10.1.3.0/28 (internal network dipartimento Customer Support)
    • 196.168.1.0/255 (partner network)
  3. Gestire il rifiuto di accesso al servizio tramite un messaggio di fault;
  4. Bilanciare la richiesta di accesso al servizio sui nodi che sono parte del sistema di CRM:
    • CRMNODE0 (crm-node0-shiruslabs.dontesta.it)
    • CRMNODE1 (crm-node1-shiruslabs.dontesta.it)
    • CRMNODE2 (crm-node2-shiruslabs.dontesta.it)

Il flowchart di Figura 2 sintetizza il flusso proposto in precedenza.  L’operazione di filtro sull’IP sorgente del messaggio di richiesta è eseguita sulla base di una regular expression, costruita in modo tale che solo le reti indicate in precedenza passino con successo il filtro. La regular expression è la seguente:

  • (10\.1\.1\.(1[0-4]|[1-9]))|(10\.1\.2\.(1[0-4]|[1-9]))|(10\.1\.3\.(1[0-4]|[1-9]))|(192\.168\.1\.(25[0-4]|2[0-4][0-9]|1[0-9]{2}|0[1-9][0-9]|00[1-9]))
Figura 2. Flowchart messaggio di richiesta

Figura 2. Flowchart messaggio di richiesta

Lo schema di Figura 3 mostra invece il flusso di richiesta di accesso al servizio del CRM da parte di una generica applicazione. Il Proxy Service esposto dall’ESB è configurato sul trasporto HTTP/S. Per questo particolare caso (vedi Figura 3) la richiesta è stata inoltrata (dal componente LBE) verso il servizio del nodo CRMNODE2 che fa parte dell’intero sistema CRM.

Figura 3. Flusso della chiamata al servizio CRM

Figura 3. Flusso della chiamata al servizio CRM

2. Overview architettura di Messaging

Prima di proseguire con la configurazione del Proxy Service facciamo un breve ripasso sull’architettura di messaging e gli elementi che compongono l’architettura, elementi che poi useremo per la configurazione del Proxy Service. WSO2 ESB è una piattaforma completa e di livello enterprise costruita sul progetto Apache Synapse, quest’ultimo utilizza il progetto Apache Axis2 per l’engine dei Web Services. In Figura 4 è illustrata l’architettura di alto livello di Apache Synapse (la base di WSO2 ESB) mentre la Figura 5 mostra la più specifica architettura di WSO2 ESB dalla prospettiva dei messaggi.

Figura 4. Apache Synapse Architecture

Figura 4. Apache Synapse Architecture (fonte Apache)

Il diagramma di Figura 5 mostra come una richiesta è propagata verso l’endpoint attraverso l’ESB. Tutti gli elementi di base mostrati in Figura 4 possono essere gestiti e monitorati attraverso la console di management dell’ESB.

Figura 5. WSO2 ESB Messaging Architecture

Figura 5. WSO2 ESB Messaging Architecture (fonte WSO2)

L’architettura di WSO2 ha diversi componenti ma vediamo di descrivere brevemente quelli base che poi utilizzeremo nella realizzazione del Proxy Service, ricordando che anche quest’ultimo è un componente della piattaforma e descritto nel precedente articolo WSO2 ESB SugarCRM Proxy Service.

Il trasporto è in grado di ricevere e inviare messaggi su una moltitudine di protocolli sia di livello di trasporto sia di livello di applicazione (come per esempio: JMS, MSMQ, TCP, HL7, etc…).

Un endpoint definisce una destinazione esterna (come ad esempio un servizio web) per un messaggio. Un endpoint può essere specificato come un address endpointWSDL endpoint, load balancing endpoint e altro ancora. Un endpoint è definito in modo indipendente dal trasporto e ciò consente di poter utilizzare lo stesso endpoint con più trasporti.

mediators sono delle singole unità di elaborazione che svolgono una funzione specifica, come ad esempio l’invio di messaggi, filtraggio, etc… WSO2 ESB include una libreria molto vasta di mediators che fornisce funzionalità per l’implementazione dei più diffusi pattern di integrazione (EIP). È anche possibile scrivere facilmente un mediators personalizzato per le proprie esigenze utilizzando varie tecnologie come Java, linguaggi di scripting e Spring.

Le sequences sono la componente di configurazione per i mediator. Le Sequences consentono di organizzare i mediator per implementare pipe ed i modelli di filtro. Una mediation sequence, comunemente chiamata “sequences”, è una lista di mediator che sono eseguiti in ordine. Quando un messaggio è consegnato a una sequences, la sequences invia il messaggio attraverso tutti i suoi mediator (vedi Figura 6).

Figura 6. Messaggio che attraversa un Mediation Sequence

Figura 6. Messaggio che attraversa un Mediation Sequence

3. Dentro il Proxy Service

Il ruolo dell’ESB sarebbe di “mediare” i messaggi in ingresso al Proxy Service prima di essere inoltrati al servizio effettivo presente sul sistema di CRM. In definitiva le operazioni di mediazione saranno svolte all’interno di un mediation sequence, dove ogni mediator farà la sua parte, in particolare:

  1. Property Mediator: non ha alcun impatto diretto sul messaggio, ma piuttosto sul contesto del messaggio che scorre attraverso Synapse e ogni proprietà impostata ha uno scope. È possibile recuperare le proprietà impostate su un messaggio e recuperarle in seguito attraverso la funzione synapse:get-property(scope, prop-name), estensione di XPath. Nel nostro specifico caso questo mediator è utilizzato per impostare la proprietà client-add che conterrà l’indirizzo IP sorgente della richiesta ricevuta;
  2. Log Mediator: utilizzato per il logging. L’informazione che andremo a scrivere sul file di log sono l’indirizzo e l’hostname della richiesta ricevuta;
  3. Filter Mediator: esegue le operazioni di filtro utilizzando l’XPath con la possibilità d’utilizzo di regular expression. Nel nostro specifico caso il filtro lascia passare i messaggi al successivo mediator (quindi sempre più vicino alla destinazione finale) se l’indirizzo IP sorgente del messaggio soddisfa la regular expression mostrata in precedenza, in caso negativo il controllo passa a un mediation sequence che invierà un messaggio di errore (message fault) verso il client. Questo tipo di mediator ricorda una struttura di controllo if-else;
  4. Send Mediator: è utilizzato per inviare i messaggi di Synapse verso uno o più endpoint. Questo tipo di mediator è fa in modo che sia possibile la correlazione tra i messaggi inviati e quelli ricevuti. L’endpoint verso cui il messaggio è inviato è un load-balanced-endpoint.

In Figura 7 è mostrato il diagramma del mediation sequence specifico per il nostro Proxy Service, mentre in Figura 8 lo spaccato del load-balanced-endpoint composto da tre endpoint per i rispettivi nodi delle istanze di SugarCRM.

Il load balance endpoint distribuisce i messaggi in arrivo tra un gruppo di endpoint mediante la valutazione della politica di bilanciamento del carico. Allo stato attuale solo la politica di Round Robin è supportata da questo componente.

Figura 7. Mediation Sequence del Proxy Service dei servizi CRM

Figura 7. Mediation Sequence del Proxy Service dei servizi CRM

In Figura 7 è stato indicato un Fault Message Out, questo sarà restituito al client per indicare il “divieto di accesso” al servizio. Il messaggio sarà restituito al client sotto forma di SOAP Fault e il responsabile della costruzione del messaggio di fault è il mediation sequence definito sull’ESB con il nome di SugarCRMProxyLBAccessForbidden (vedi configurazione XML al Listato 1).

Listato 1. Configurazione del Mediation Sequence SugarCRMProxyFilteredByNetLB.

Figura 8. Composizione del Load Balance Endpoint

Figura 8. Composizione del Load Balance Endpoint

Dopo aver visto quali sono gli elementi essenziali del nostro Proxy Service non resta altro che vedere la configurazione XML completa.

Listato 2. Configurazione completa del Proxy Service SugarCRMProxyFilteredByNetLB.

 

4. Test del Proxy Service

Tramite la management console è possibile condurre dei test sul Proxy Service appena configurato. I test che possono essere eseguiti per verificare la corretta configurazione del servizio sono:

  1. Accesso al servizio da una rete consentita e verifica del corretto funzionamento del servizio;
  2. Accesso al servizio da una rete proibita e verifica della gestione dell’errore tramite SOAP Fault;
  3. Verifica di accesso al servizio anche nel caso di failure di uno dei nodi del sistema CRM.

Diamo per scontato il primo caso e passiamo alla verifica di ciò che dovrebbe succedere nei due restanti casi. Nel secondo caso il client dovrebbe ricevere un SOAP Fault e sul log (tramite il Log Mediator) essere indicato l’errore di accesso negato al servizio (vedi Listato 3 e Listato 4). I log mostrano come l’accesso al servizio sia stato correttamente negato poichè la richiesta ha origini dall’IP 192.168.43.226 che non rientra tra le reti consentite, quindi scartata dal Filter Mediator.

Listato 3. Entry su log file in caso di accesso negato al servizio

Listato 4. Messaggio SOAP Fault in caso di accesso negato al servizio

Passando al terzo caso della lista di test, supponiamo che il nodo CRMNODE2 sia offline per manutenzione, in queste condizioni il servizio dovrebbe continuare a rispondere mentre l’ESB marcherà l’endpoint in uno stato di sospensione per un determinato periodo di tempo (parametro che può essere configurato). Il Listato 5 mostra le entry sul file di log che mostrano la condizione di failure sollevata dal load balancer endpoint.

Listato 5. Condizione d’errore su di un nodo del load balancer endpoint.

5. Risorse

Per ogni approfondimento sull’argomento vi segnalo una serie di risorse pubbliche disponibili sul sito di WSO2:

6. Conclusioni

Aggiungendo qualche complessità in più rispetto al caso presentato con il precedente articolo WSO2 ESB SugarCRM Proxy Service, non è cambiato nulla, nessuna riga di codice, solo configurazione. Configurare un nuovo servizio o modificarne un’esistente, è un pò come fare un puzzle, anzi direi un lego. Dalla composizione dei singoli mattoncini (esempio i mediator, endpoint, etc…) è possibile con poco sforzo ottenere un manufatto che risponde ai propri requisiti, non male. Di serie la piattaforma di WSO2 mette a disposizione circa quaranta mediator per i più disparati utilizzi e qualora non fosse disponibile uno che faccia al caso nostro e possibile scriverlo da se.

Enhanced by Zemanta

Antonio Musarra

I began my journey into the world of computing from an Olivetti M24 PC (http://it.wikipedia.org/wiki/Olivetti_M24) bought by my father for his work. Day after day, quickly taking control until … Now doing business consulting for projects in the enterprise application development using web-oriented technologies such as J2EE, Web Services, ESB, TIBCO, PHP.

Potrebbero interessarti anche...