WSO2 ESB - Open Source Integration Vergleich Teil 7
Der Enterprise Service Bus von WSO2 ist in erster Linie ein Vermittler zwischen Web Services. Der Fokus liegt weniger auf der Integration zwischen Formaten und Protokollen, als der Mediation zwischen Services in einer Service orientieren Architektur.
Der WSO2 basiert auf dem Apache Synapse Projekt, welches wiederum auf dem Web Services Framework Apache Axis2 basiert.
Der WSO2 ESB stellt mit Mediation und Registry die Infrastruktur zur Verfügung, die für den erfolgreichen Betrieb einer SOA benötigt wird. Eine mächtige Web Oberfläche macht alle Funktionen des ESB zugänglich.
1. Installation
Bereits nach wenigen Minuten ist die Installation des WSO2 erfolgt und der Bus gestartet. Nach dem Start geht es in der Web Oberfläche mit der Einrichtung von Services weiter.
Abbildung 1:
2. Entwicklung
Services werden beim WSO2 nicht entwickelt sondern konfiguriert. Der Bus fungiert als Mittler zwischen Client und dem eigentlichen Service, welcher auf einem anderen Backend, z.B. auf einem Application Server, betrieben wird. Um einen Service über den WSO2 anzubieten wird in der Web Oberfläche ein Proxy angelegt.
Abbildung 2 zeigt die installierten Services. Der Service Proxy für den BLZ Service konnte in weniger als 5 Minuten einrichtet werden.
Abbildung 2:
Für die Einrichtung von Service Proxys stehen die folgenden Proxy Typen als Vorlage zur Auswahl:
- Transformer mit XSLT
- Web Services Security
- SOAP Proxy
- Logging
- Pass Through
- Custom
Die meisten Möglichkeiten bietet der Custom Proxy. Über einen Custom Proxy lassen sich u.a. die folgenden Funktionen einrichten:
- OAuth
- Throttle zur Begrenzung des Durchsatzes
- Transformation mit XSLT oder Smooks
- Proxy für Enterprise Javabeans
- Sicherheit mit Web Services Security, WS-Trust oder OAuth
Komplexere Abläufe können mit Sequenzen beschrieben werden, die in den Request- und Response Fluss der Service Proxys eingeklinkt werden können. Eine Sequenz ist eine Abfolge von Funktionen.
Editiert werden Sequenzen in der Web Oberfläche über eine Baumansicht. Abbildung 3 zeigt eine Sequenz mit Filter.
Abbildung 3:
Das folgende Listing zeigt die selbe Sequenz im Quellcode, der auch editiert werden kann.
<sequence name="main" xmlns="http://ws.apache.org/ns/synapse">
<in>
<log level="full"/>
<!-- ensure that the default configuration only sends if it is one of samples -->
<!-- Otherwise Synapse would be an open proxy by default (BAD!) -->
<filter regex="http://localhost:9000.*"
source="get-property('To')" xmlns:ns="http://org.apache.synapse/xsd">
<then>
<send/>
</then>
</filter>
</in>
<out>
<send/>
</out>
<description>The main sequence for the message mediation</description>
</sequence>
Der XML Code für die gesamte Bus Konfiguration mit Tasks, Message Stores, Templates und Endpunkten kann ebenfalls eingesehen werden. Am XML Namespace ist erkennbar, dass das Format der Bus Konfiguration das von Apache Synapse ist. Der WSO2 ESB ist im Grunde eine Oberfläche für Synapse sowie eine Reihe von Erweiterungen.
3. Konnektoren
Die Konnektoren des WSO2 begrenzen sich auf: HTTP, Datei, JMS, Apache Kafka, RabbitMQ und MQTT. Bei den letzten vier handelt es sich um Messaging. Bemerkenswert ist die Unterstützung für das innovative Apache Kafka, einem verteilten Commit Log, welches auch als Alternative für einen Message Broker dienen kann.
Bei der SOA sollte die gesamte Funktionalität eines Unternehmens über Web Services zur Verfügung stehen, weitere Konnektoren währen in einer reinen SOA überflüssig. Die Einschränkung auf wenige Konnektoren beim WSO2 ESB ist produkttypisch und nicht ungewöhnlich. Über die Installation von ZIP Dateien können aber zusätzliche Konnektoren hinzugefügt werden. In der Dokumentation werden Konnektoren für JIRA, Salesforce, Twitter und Twillo erwähnt.
4. Registry
Bei der Service orientierten Architektur sollte die Registry eine zentrale Rolle spielen und z.B. Informationen über die Adressen der Service Endpunkte bereitstellen.
In der integrieren Registry des WSO2 sind u.a. die Konfiguration des ESB und Informationen zu den Endpunkten abgelegt.
Abbildung 4:
5. Monitoring
Die Statistiken zu den einzelnen Service-Proxys enthalten Information über:
- Anzahl der Aufrufe
- Antwortzeitverhalten
- Häufigkeit von Fehlern
Die Tracing Funktion erlaubt das Inspizieren von Nachrichten.
Abbildung 5:
Das in die Web Oberfläche integrierte Log Management ermöglicht eine schnelle Recherche bei Fehler im Betrieb. Es kann nach Service-Proxy und Log-Level gefiltert werden.
Abbildung 6:
6. Test
Für einfache Tests enthält der WSO2 Server einen integrierten dynamischen Client für Web Service Aufrufe. Die Funktionalität ist praktisch um schnell mal einen Aufruf zu machen, sie ersetzt aber nicht ein spezialisiertes Werkzeug für den Test von Web Services wie z.B. SoapUI.
Abbildung 7:
7. Fazit
Alle Funktionen des WSO2 ESB können komfortabel über die Web Oberfläche aktiviert , konfiguriert und überwacht werden.
Mit dem WSO2 lassen sich auch Proxies und Abläufe für REST Schnittstellen erstellen. Der Schwerpunkt sind aber eindeutig SOAP basierte Web Services. Unterstützung für die API Beschreibungssprachen Swagger oder RAML sucht man vergeblich. Das Herz vom WSO2 ist das Apache Synapse Projekt, welches auf dem Web Services Toolkit Axis2 basiert.
Der WSO2 ESB, zumindest in der hier betrachteten Version 4.9.0 kann nur empfohlen werden, falls eine Infrastruktur für SOAP basierte Web Services im Rahmen einer SOA gesucht wird. Ein Highlight ist die Unterstützung der Standards Web Services Security und WS-Trust.
Zukunft gebe ich dem WSO2 Produkt keine, da das Herzstück Apache Synapse seit 2012 nicht mehr gepflegt wird. Um den WSO2 ESB zu retten, müsste dessen Architektur einem kompletten Redesign unterworfen und neben Web Services REST APIs besser unterstützt werden.