WSO2 ESB SugarCRM Proxy Service

L’articolo nasce e prende spunto da una domanda indirizzata a me qualche giorno addietro. Esattamente il quesito recitava: Come posso configurare un Proxy Service di SugarCRM sull’Enterprise Service Bus (ESB) di WSO2La risposta al quesito è stata abbastanza semplice e nel corso di quest’articolo vedremo come sia semplice configurare un Proxy Service.

1. Cos’è un Proxy Service

Un Proxy Service è un servizio virtuale che riceve i messaggi e opzionalmente li elabora prima di essere inoltrati a un servizio definito da un end point. Quest’approccio consente di eseguire le trasformazioni necessarie e introduce funzionalità aggiuntive senza modificare il servizio esistente. Per esempio, se si desidera utilizzare WS-Security con un servizio esistente non sicuro, è possibile creare un proxy service sicuro attraverso l’abilitazione del modulo WS-Security specificando una politica di sicurezza. Inoltre, è possibile creare un proxy service per trasformare le richieste e le risposte sulla base di configurazioni XSLT. Un proxy service può anche fare lo switch sul protocollo di trasporto e interfaccia, l’elaborazione dei messaggi tramite i mediation sequences e task, interrompere il flusso o inviare un messaggio al client anche senza inviarlo al servizio effettivo.

È possibile creare i seguenti tipi di servizi proxy:

  1. Pass Through Proxy: inoltra i messaggi verso l’end point senza eseguire alcuna elaborazione su di loro;
  2. Secure Proxy: Utilizza WS-Security per elaborare le richieste in ingresso e li trasmette al servizio di back-end non sicuro;
  3. WSDL Based Proxy : Un proxy service creato da un WSDL remoto di un servizio web esistente. Le informazioni sull’end point sono estratte dal WSDL;
  4. Logging Proxy : Registra tutte le richieste e le inoltra in entrata a un determinato end point. Può anche registrare le risposte dal servizio di backend prima di eseguire l’instradamento verso il client;
  5. Transformer Proxy : Trasforma tutte le richieste in arrivo utilizzando XSLT e poi li inoltra ad un dato end point. Può anche trasformare risposte provenienti dal servizio di backend;
  6. Custom Proxy : Un servizio proxy personalizzato in cui è possibile personalizzare le sequenze, end point, trasporti e altre impostazioni di QoS.

Il modo più semplice per creare e gestire un proxy service è attraverso la management console. E’ comunque possibile utilizzare l’ambiente di Studio di WSO2 oltre che configurare manualmente attraverso i file di configurazione XML.

Un proxy service è creato ed esposto sui determinati trasporti (http/s, JMS, VFS, etc…) attraverso il motore di Axis2 e può essere di tipo SOAP o REST/POX. L’EPR (End Point Reference) del proxy service è costruito secondo il nome del servizio, così come previsto dallo standard adottato da Axis2.

2. Configurazione Pass Through Proxy

Nel caso di studio proposto, il tipo di proxy service da creare è un Pass Through Proxy così come indicato in Figura 1.

Figura 1. Web Service Proxy

Figura 1. Web Service Proxy

La creazione di un proxy service di tipo Pass Through Proxy richiede la conoscenza dei seguenti elementi di base:

  1. Nome da assegnare al servizio;
  2. Target end point: End Point del servizio di backend. E’ possibile specificare sia l’URL o selezionare l’end point dal registro di WSO2;
  3. URI del documento WSDL del servizio di backend. Così come per il target end point, è possibile specificare sia l’URL o selezionare la risorsa (il WSDL) dal registro di WSO2;
  4. Il tipo di trasporto (http, https, local, etc…).
Figura 2. SugarCRMProxy Proxy Service

Figura 2. SugarCRMProxy Proxy Service

In Figura 3 è mostrata la configurazione del proxy service dalla management console, in Figura 4 la lista dei servizi installati, mentre al Listato 1 la configurazione XML del proxy service. Una volta che la configurazione del proxy service è terminata e il deploy andato a buon fine, il servizio sarà on line e pronto ad essere interrogato:

  • End Point del servizio: http://esb-shiruslabs.dontesta.it:8280/services/SugarCRMProxy
  • WSDL del servizio: http://esb-shiruslabs.dontesta.it:8280/services/SugarCRMProxy?wsdl
Figura 3. Configurazione Proxy Service di SugarCRM

Figura 3. Configurazione Proxy Service di SugarCRM

Figura 4. Lista servizi installati sull'ESB

Figura 4. Lista servizi installati sull’ESB

3. Test del Proxy Service

Tramite la management console di WSO2 è possibile eseguire dei test sul servizio appena creato e verificare che tutto funzioni in modo corretto. L’accesso alla GUI di test avviene direttamente dalla lista dei servizi (vedere Figura 4) cliccando sul pulsante “Try this service”. L’interfaccia è abbastanza semplice, per coloro che sono avvezzi all’uso di SoapUI o strumenti simile non sarà nulla di nuovo. Sulla barra sinistra sono elencate le operazioni disponibili sul servizio e sulla parte centrale sono presenti due box, a sinistra il box per il messaggio SOAP di richiesta, a destra il box che mostra il messaggio SOAP di risposta.

Figura 5. Test del servizio SugarCRMProxy

Figura 5. Test del servizio SugarCRMProxy

4. Servizi di monitoring

WSO2 ESB offre una varietà di opzioni per monitorare e gestire l’esecuzione del server, attraverso una serie di strumenti di monitoraggio accessibili direttamente dalla management console, così come Java Management Extensions (JMX). I dati raccolti da questi meccanismi di controllo dell’ESB possono essere usati per regolare i flussi dei messaggi sul bus, di rilevare fault di mediazione e tenere traccia dei messaggi. La piattaforma consente di eseguire statistiche sui seguenti elementi:

  • System
  • Transport
  • Mediation

inoltre, WSO2 ESB espone una serie di risorse di gestione come JMX MBean che possono essere utilizzate per la gestione e il monitoraggio del server, a questi è possibile accedere in remoto utilizzando un client JMX come JConsole o Visual VM. Svariati JMX MBean sono esposti via SNMP di conseguenza è possibile utilizzare strumenti come Nagios per eseguire il monitoraggio del server.

Nelle figure a seguire sono mostrati alcuni dati statistici sul proxy service SugarCRMProxy appena creato.

Figura 6. Overview del servizio SugarCRMProxy

Figura 6. Overview del servizio SugarCRMProxy

Figura 7. Tracker messaggi SOAP del servizio SugarCRMProxy

Figura 7. Tracker messaggi SOAP del servizio SugarCRMProxy

5. Conclusioni

E’ stato semplice configurare un proxy service, giusto? La creazione del proxy service non ha richiesto una sola riga di codice, sono state eseguite esclusivamente operazioni di configurazione. Anche i casi più complessi, che prevedono per esempio mediation sequences, balancing degli end point, etc… possono essere risolti attraverso operazioni di sola configurazione. Un valore aggiunto della piattaforma sono i servizi di monitoring e QoS che a gratis consentono di monitorare i servizi e aggiungere nuove funzionalità come WS-Security, Response Caching, etc….

Enhanced by Zemanta
0 Condivisioni

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...

Cos'è il progetto CIE/CNS Apache Docker - Developers Italia

In questo video https://youtu.be/TcAzn1POhsM introdurrò il progetto CIE/CNS Apache Docker di Developers Italia (https://developers.italia.it/it/cie/#resourcecontent-3) nato circa due anni fa.

L'obiettivo di questo progetto è quello di fornire un template pronto all'uso che realizza un sistema di autenticazione tramite la Smart Card TS-CNS (o CNS) e la CIE (Carta d'Identità Elettronica) basato su Apache HTTP. Ognuno può poi modificare o specializzare questo progetto sulla base delle proprie esigenze Si tratta di un progetto docker per la creazione di un container che implementa un sistema di mutua autenticazione o autenticazione bilaterale SSL/TLS.

Questo meccanismo di autenticazione richiede anche il certificato digitale da parte del client, certificato che in questo caso risiede all'interno della TS-CNS o della CIE. La particolarità del sistema implementato (attraverso questo container) è quella di consentire l'autenticazione tramite:

  • La TS-CNS (Tessera Sanitaria - Carta Nazionale Servizi), rilasciata dalla regione di appartenenza;
  • La CIE (Carta d'Identità Elettronica), rilasciata dal comune di residenza.

Nella versione 2.0.0 il progetto è stato aggiornato per essere uniforme alle linee guida di Bootstrap Italia. A seguire alcune risorse che possono essere utili.

  • Cos’è il progetto CIE/CNS Apache Docker (http://bit.ly/3aJ5Gbl)
  • CIE Carta d'Identità Elettronica (https://developers.italia.it/it/cie/)
  • Carta Nazionale dei Servizi (https://www.agid.gov.it/it/piattaforme/carta-nazionale-servizi)
  • Raspberry Pi – Un esempio di applicazione della TS-CNS (https://bit.ly/3hkJ8Aj)
  • Pubblicare il servizio CIE/CNS Apache Docker su Azure Cloud (http://bit.ly/3aPoq8V)
  • Come accedere al portale VETINFO tramite TS-CNS e Mac OS (http://bit.ly/2VFMKq7)