Orchestrazione in Azione con WSO2: Guida Pratica, Benchmark e Analisi Comparativa.

8 min readApr 8, 2023

Nell’ultimo articolo, abbiamo esplorato l’orchestrazione di servizi utilizzando Apache Camel, un framework di integrazione leggero e flessibile che ha permesso di semplificare il processo di integrazione tra diversi sistemi.

Tuttavia, il mondo dell’integrazione è in continua evoluzione e sempre alla ricerca di soluzioni più avanzate e complete per affrontare le sfide in un ambiente aziendale in rapido cambiamento.

Oggi, ci addentreremo nel mondo di WSO2, un’alternativa potente ed estensibile ad Apache Camel, con l’obiettivo di implementare la logica di orchestrazione esaminata in precedenza, sfruttando i numerosi vantaggi offerti da questo ecosistema.

WSO2 è una piattaforma di integrazione open source leader nel settore che offre una vasta gamma di prodotti per l’integrazione di servizi, la gestione delle API, la sicurezza e l’analisi.

In questa occasione, adottiamo un approccio diverso e iniziamo definendo il nostro contratto: l’API esposta rappresenterà il servizio offerto dal nostro orchestratore. Pertanto, cominciamo creando un file YAML, prestando particolare attenzione all’ indentazione.

Utilizziamo l’editor online https://editor-next.swagger.io/ per ottenere una rappresentazione grafica dell’API che presenteremo, nonché per organizzare e monitorare le nostre modifiche in tempo reale.

Una volta definita l’API, i passi da seguire per implementare l’orchestrazione con WSO2 sono:

Installare Integration Studio : https://ei.docs.wso2.com/en/7.0.0/micro-integrator/develop/installing-WSO2-Integration-Studio/
Creare nuovo : Integration Project

Uno dei principali vantaggi di un progetto di integrazione è la flessibilità nell’attivare solo i componenti necessari, eliminando il resto.

In questo modo, si ottiene un’implementazione più snella e una gestione del progetto più semplice.

Per la nostra orchestrazione, ad esempio, possiamo concentrarci su soli tre componenti fondamentali:

API;
Endpoint;
Sequence.

Questo approccio semplificato permette di ottenere un’organizzazione più efficiente rispetto all’uso di numerose classi, come abbiamo visto nell’esempio con Apache Camel.

In definitiva, questa flessibilità consente una migliore gestione del progetto e un’implementazione più agile, consentendo di concentrarsi sulle funzionalità essenziali senza essere sopraffatti dalla complessità.

Project Root

Confrontiamo i due progetti (Nota l’orchestrazione è la medesima) :

Quindi, fondamentalmente, possiamo osservare che all’interno della cartella synapse-config, sono presenti tre componenti principali, ciascuno con uno scopo specifico all'interno dell'ambito di WSO2:

API — Write.xml: Questo file XML definisce l’API Write, che è il punto di ingresso per le richieste esterne. Esso gestisce le chiamate in arrivo e le indirizza verso le risorse appropriate, in base alle operazioni specificate.
Endpoint: Abbiamo due endpoint distinti, uno per le operazioni GET e uno per le operazioni POST. Gli endpoint sono responsabili della comunicazione con i servizi esterni o i microservizi, e permettono di effettuare chiamate verso altri sistemi.
Sequences: Le sequenze sono componenti di elaborazione che permettono di definire il flusso di messaggi all’interno dell’integrazione. Esse sono composte da una serie di mediatori che agiscono sui messaggi in ingresso e in uscita, trasformandoli o arricchendoli con informazioni aggiuntive. Nel nostro caso, abbiamo tre sequenze che gestiscono i diversi aspetti dell’orchestrazione, consentendo di separare le logiche di elaborazione e garantendo un flusso di lavoro chiaro e ordinato.

In effetti, alla luce di questa analisi, possiamo assegnare 1 punto a favore di WSO2 per quanto riguarda la chiarezza e l’ordine nella gestione di un progetto.
WSO2 offre un approccio più organizzato e modulare, grazie alla separazione dei componenti e alla possibilità di attivare solo le funzionalità necessarie.

Api

Adesso vediamo nel dettaglio il cuore del nostro flusso in Wso2, il file Write.xml dove abbiamo definito l’entrypoint della nostra orchestrazione:

È importante notare che il flusso gestito nella classe UserRouteBuilder in Apache Camel, essendo scritto in Java, può risultare più chiaro e di più semplice comprensione per gli sviluppatori abituati a questo linguaggio.

D’altro canto, WSO2 utilizza un linguaggio di markup come l’XML, il quale può rendere la lettura del codice più ostica per alcuni. Tuttavia, esiste la possibilità di utilizzare un tool grafico mediante la visualizzazione del design, che può semplificare la gestione del progetto. Nonostante ciò, in questo caso, non adotteremo tale approccio, preferendo lavorare direttamente sul codice.

Un’altra osservazione riguardante WSO2 è che, per gestire il transcoding e il mapping, è stato necessario aggiungere un’ulteriore chiamata a un API di transcoding, poiché la gestione di logiche all’interno delle sequenze con l’uso di <script> in JavaScript può risultare ostica.

Anche se in realtà Wso2 ci permette sia di utilizzare js Script inline

<script language="js"><![CDATA[...script source code...]]><script/>
ma anche in un file separato referenziato in locale o tramite il Remote registry entry.

per ulteriori approfondimenti rimando a : https://docs.wso2.com/display/EI611/Script+Mediator#d14effa7723746f38ee52e8cd6aed3e6

Nel contesto di Apache Camel e del linguaggio Java, le operazioni di mapping e transcoding possono essere gestite in modo più semplice e diretto grazie alla flessibilità e alle funzionalità offerte dal linguaggio di programmazione. Utilizzando l’oggetto Exchange, possiamo manipolare i dati secondo le nostre esigenze e preferenze, facilitando ulteriormente queste operazioni.

In sintesi, sebbene WSO2 offra una struttura organizzata e modulare, potrebbe presentare alcune difficoltà nella gestione di logiche , come il transcoding e il mapping, all’interno delle sequenze.

Apache Camel, grazie al linguaggio Java, semplifica questo aspetto e permette una maggiore facilità di implementazione di queste funzionalità.

Quindi assegnerei un punto a favore di Apache Camel.

BENCHMARK WsO2

Durante questo benchmark, utilizzeremo Plow per misurare il tempo di risposta delle richieste HTTP per identificare eventuali aree di miglioramento delle prestazioni.

GitHub - six-ddc/plow: A high-performance HTTP benchmarking tool that includes a real-time web UI…

Plow is an HTTP(S) benchmarking tool, written in Golang. It uses excellent fasthttp instead of Go's default net/http…

github.com

dove l’input.json:

{
    "firstName": "Andrea",
    "lastName": "Cavallo",
    "quantity": 1,
    "productName": "Example"
}

Dai risultati riportati si possono dedurre le seguenti informazioni:

Questi risultati sono relativi ad un benchmark eseguito per 1 min, durante il quale sono state inviate 27479 richieste e tutte hanno ottenuto una risposta di successo (2xx).
e dal Latency Histogram: 28.264ms / 61.40%

BENCHMARK APACHE-CAMEL

È importante notare che durante il primo benchmark con Apache Camel sono stati riscontrati 112 errori 5xx : “org.eclipse.jetty.io.EofException”.


org.eclipse.jetty.io.EofException: null
 at org.eclipse.jetty.io.ChannelEndPoint.flush(ChannelEndPoint.java:279) ~[jetty-io-9.4.45.v20220203.jar:9.4.45.v20220203]
 at org.eclipse.jetty.io.WriteFlusher.flush(WriteFlusher.java:422) ~[jetty-io-9.4.45.v20220203.jar:9.4.45.v20220203]
 at org.eclipse.jetty.io.WriteFlusher.write(WriteFlusher.java:277) ~[jetty-io-9.4.45.v20220203.jar:9.4.45.v20220203]

Dopo una ricerca più approfondita, ho capito che si trattava di un problema legato alla versione di Jetty utilizzata. In particolare, il messaggio di errore “The remote connection was closed before it was finished” indica che la connessione remota è stata chiusa prematuramente, prima che la risposta completa potesse essere inviata al client.

Questo è un errore comune a basso livello e può essere causato da molte cose al di fuori del controllo dell’applicazione Java.

Quindi, mi son deciso di passare da Jetty ad Undertow, riducendo a 0 i 5xx:

Migliore performance: Undertow è noto per essere molto più veloce di Jetty in alcune situazioni, grazie alla sua architettura ad alta velocità e bassa latenza.
Maggiore leggerezza: Undertow è più leggero di Jetty perché è costruito in modo da occupare meno spazio e risorse, rendendolo più efficiente e veloce.

In conclusione, confrontiamo i risultati ottenuti utilizzando Wso2 e Apache Camel:

Apache Camel ha registrato un tempo di latenza medio di 23.923ms, con il 57.78% delle richieste completate in meno di tale tempo;
D’altra parte, Wso2 ha registrato un tempo di latenza medio di 28.264ms, con il 61.40% delle richieste completate in meno di tale tempo;
Tuttavia, è importante notare che Apache Camel ha elaborato un totale di 8356 richieste con una velocità di 139.266 richieste al secondo durante il benchmark di 1 minuto, e tutte le richieste hanno restituito un codice di risposta 2xx di successo;
In confronto, WSO2 ha elaborato un totale di 27479 richieste con una velocità più elevata di 457.983 richieste al secondo, anche durante il benchmark di 1 minuto, e tutte le richieste hanno restituito un codice di risposta 2xx di successo.

In definitiva, il benchmark effettuato attraverso l’utilizzo di Plow ha permesso di valutare in modo oggettivo le prestazioni dei due framework, evidenziando le loro forze e le loro debolezze. La domanda che sorge spontanea è quindi la seguente: quale framework scegliereste per la vostra implementazione di orchestrazione e perché?

Postman Flows

Vorrei anche proporvi uno strumento visivo e moderno per la creazione di flussi di lavoro API, e in questo esempio ho chiamato simultaneamente le due orchestrazioni sviluppate in : Wso2 & Apache Camel.

Entrambe le orchestrazioni ricevono lo stesso input, ma il valore di “orderedAt” nell’output di risposta è leggermente diverso, con WSO2 che restituisce “2023–04–07T19:09:00.810000” e Apache Camel che restituisce “2023–04–07T19:09:00.791093”.

Osservando la differenza tra i tempi, si può notare che la chiamata effettuata tramite WSO2 impiega più tempo rispetto a quella effettuata tramite Apache Camel, in quanto la data e l’ora indicate nella risposta di WSO2 sono leggermente più tarde.

https://medium.com/@andreacavallo/confronto-tra-apache-camel-e-wso2-synapse-77a02c66c4fa

Link Utili:

Progetto in wso2: https://github.com/Andrea-Cavallo/WSO2-orchestration ;
Progetto in apache camel: https://github.com/Andrea-Cavallo/apachecamel;
Ms Core: https://github.com/Andrea-Cavallo/webFlux-CriteriaBuilderQuery-MapStruct
Swagger Editor : https://editor-next.swagger.io/;
Install Micro-Integrator: https://wso2.com/micro-integrator/;
Read wso2 Docs: https://wso2.com/documentation/;
install Plow: https://github.com/six-ddc/plow#installation ;
Postman Flows: https://learning.postman.com/docs/postman-flows/gs/flows-overview/
WSo2 collective StackOverFlow : https://stackoverflow.com/collectives/wso2;
Wso2 Discord: https://discord.com/invite/Xa5VubmThw?utm_source=wso2-dev&utm_medium=link&utm_campaign=wso2-dev_link_from-dev-homepage_221002
Jetty https://www.eclipse.org/jetty/download.php
UnderTow https://undertow.io/