Anypoint Platform von MuleSoft - Open Source API Management im Vergleich

Von: Thomas Bayer
Datum: 15. April 2020

1. Komponenten

Über eine Web Oberfläche kann auf die Komponenten der Anypoint Platform zugegriffen werden. Ein Menu verlinkt die einzelnen Bestandteile.

Abbildung 1: Auswahl der Anypoint Komponenten

Zusätzlich zu den Komponenten mit Web Oberfläche gibt es das Anypoint Studio als eigenständige Desktop-Anwendung.

Dieser Text beschreibt die Funktionalität der Komponenten in den folgenden Abschnitten.

2. Erstellen von API Beschreibungen im Design Center

Integrations-Anwendungen und APIs können im Design Center beschrieben werden. Unterstützt werden die Beschreibungssprachen Swagger und die REST API Markup Language kurz RAML genannt. Swagger bzw. Open API wird nur in der Version 2 und nicht in der neuen Version 3 unterstützt (Stand Anypoint Version 4.2.2.).

2.1 Swagger oder RAML?

RAML ist ein „offener Standard“ und wird zusammen mit der Community auf github als Open Source Projekt entwickelt. Bestimmt wird die Weiterentwicklung von RAML von Salesforce, der Muttergesellschaft von MuleSoft, die die Namensrechte an RAML besitzt. RAML ist folglich als eine herstellerabhängige Spezifikation zu betrachten.

SmartBear hat mit seiner API Beschreibungssprache Swagger einen smarten Schachzug gemacht und Swagger an eine unabhängige Organisation, die OpenAPI Initiative übergeben, die nicht von SmartBear kontrolliert wird. Mit diesem Schritt wurde der Name von Swagger in Open API geändert. Das hat dazu geführt, dass sich der Markt zu Gunsten von Swagger entschieden hat. Der Großteil der relevanten Player sind Mitglieder der OpenAPI Initiative, zu der selbst MuleSoft beigetreten ist. Wer seine APIs anderen zur Verfügung stellen oder APIs von anderen verwenden möchte, ist mit Swagger besser beraten. Eine herstellereigene Beschreibungssprache wiederspricht der API Idee. RAML hatte bis vor Kurzem einige Vorteile wie z.B. die Modularisierung von API Beschreibungen gegenüber Swagger. Mit der Version 3 von Swagger sind die beiden Sprachen vergleichbar.

Die Anypoint Platform unterstützt neben RAML auch Open API, so dass der Entwickler die Möglichkeit hat, den Industrie Standard zu verwenden. Der Designer ermöglicht es, RAML Dokumente in Swagger Beschreibungen zu konvertieren und umgekehrt. Der Fokus der Plattform liegt auf RAML, die Swagger Unterstützung fällt stiefmütterlicher aus. Beispielsweise ist das visuelle Editieren nur mit dem RAML Format möglich.

2.2 Visual Editor

Mit dem Visual Editor können API Beschreibungen Formular-basiert erstellt werden. Üblicherweise wird mit der Definition von Datentypen begonnen. Der Screenshot unten zeigt das Anlegen eines Artikel Objektes mit den drei Eigenschaften id, name und datum.

Abbildung 2: Anlegen eines Datentyps im Visual Editor

Die Datentypen können später bei der Beschreibung eines Endpoints für die Parameter und den Body von Nachrichten verwendet werden. Unten ist die Beschreibung des Endpunnktes:

zu sehen.

Abbildung 3: Anlegen eines Datentyps im Visual Editor

Übersichtlich ist die Anzeige der Endpoints im Editor. Jeder Pfad wird nur einmal aufgeführt und die unterstützten Methoden über farbige Punkte angezeigt. In der Abbildung unten steht Grün für GET und Lila für POST.

Abbildung 4: Anzeige der Ressourcen

Nach der Beschreibung eines Endpunktes kann dieser sofort getestet werden. Über einen Mocking Service wird automatisch ein „Dummy“-Service des API erzeugt, der über die „Try-it“-Funktionalität aufgerufen werden kann.

Abbildung 5: REST Client zum Testen eines APIs

2.3 RAML und OAS Code Editor

Neben dem visuellen Editor gibt es die Möglichkeit, API Beschreibungen im Quellcode zu bearbeiten. Das Textformat bei Swagger und RAML ist YAML, das Einrückungen für die Abbildung von Baumstrukturen verwendet. Mit der Completion-Funktion können mit dem RAML Editor selbst im Code mit etwas Übung schnell und effizient API Beschreibungen erstellt werden.

Abbildung 6: RAML Editor im Design Center

Der grafische Editor für API Beschreibungen ist komfortabel und mächtig. Der einzige Kritikpunkt ist die fehlende Unterstützung eines Roundtrips zwischen Visual Editor und Code Editor. Wurde eine Datei einmal im Code editiert, so kann diese nicht mehr visuell editiert werden.

Der in die Anypoint Plattform integrierte API Designer trägt dazu bei, dass der Entwickler alle Aufgaben mit der Plattform ausführen kann. Andere API Management Produkte verfügen über keinen integrierten Editor und überlassen das API Design externen Werkzeugen wie z.B. dem Swagger Editor oder einem Plugin für IntelliJ, Visual Studio Code, etc. Die Anypoint Plattform kann ebenfalls mit einem externen API Editor kombiniert werden. API Beschreibungen lassen sich in die Plattform hoch- und herunterladen.

3. Veröffentlichen von APIs im Exchange Marktplatz

Exchange ist ein Marktplatz für verschiedene Assetts wie z.B. APIs, Vorlagen und Konnektoren. Der Marktplatz kann unternehmensweit zur Verfügung gestellt werden.

Exchange unterstützt die in der folgenden Tabelle aufgeführten Assetts:

Im Marktplatz sind unzählige Einträge, die von Mulesoft zur Verfügung gestellt werden enthalten. Die Abbildung unten zeigt einige Einträge zu einer Suche nach dem Stichwort „pay“.

Abbildung 7: Assetts im Marktplatz zur Suche „pay“

Für SAP, Salesforce und für viele andere Systeme bietet Mulesoft über den Exchange Konnektoren und Vorlagen an. Wer diese für seine Arbeit einsetzen kann, kann mit der Anypoint Platform Zeit sparen. Neben den Assetts finden sich im Marktplatz auch Dokumentation, Videos und andere Materialien.

Beispiele, Templates und Konnektoren für Salesforce sind im Marktplatz dominant vertreten. Die gute Unterstützung für Salesforce liegt sicher daran, dass Salesforce 2018 die Firma MuleSoft gekauft hat, um die on-Premise Anbindung für Salesforce Installationen zu erleichtern.

Eigene Assetts können über die Plattform oder über einen Datei-Upload im Marktplatz veröffentlicht werden. Danach kann über einen Eintrag auf das Assett zugegriffen werden. Der Screenshot unten zeigt einen Eintrag für ein REST API. Die Einträge können mit Web-Seiten beschrieben werden. Für das Editieren der Seiten kann ein WYSIWYG-Editor oder die Textauszeichnungssprache Markdown verwendet werden.

Abbildung 8: Eintrag eines REST API im Exchange Marktplatz

Bewertungen und Reviews können Service Nutzern die Auswahl erleichtern.

4. Anypoint API Manager

Der API Manager sitzt als Vermittler zwischen dem Designer, dem Exchange Marktplatz, dem Studio und der Runtime. Mit dem API Manager können APIs konfiguriert und Richtlinien, Service Level Agreements sowie Alarme eingerichtet werden. Weitere Aufgaben des API Managers sind die Versionierung und die Überwachung von APIs.

Nach dem Erstellen eines APIs kann dieses per Knopfdruck im Exchange Marktplatz veröffentlicht werden.

Benachrichtigungen können eingerichtet werden, so dass z.B. ein Alert als Mail verschickt wird, wenn die Anzahl der Anfragen einen Schwellwert überschreitet.

Der API Manager steht in einer Beziehung zu den API Gateways, die später Aufrufe an die Backends weiterleiten, die Einhaltung der Richtlinien überwachen und Daten für das Monitoring sammeln.

4.1 API Gateway

In hybriden Infrastrukturen werden Dienste in der Cloud und lokal im Unternehmen (on-Premise) betrieben. Das API Gateway unterstützt hybride Setups, durch die Möglichkeit eines Deployments in der Cloud und im eigenen Datacenter. Mit dem API Manager können mehrere Gateways in der Cloud und lokal zentral in einer Oberfläche verwaltet werden.

4.2 Proxies für bestehende Anwendungen

Ein Proxy ist ein virtuelles API, das Aufrufe entgegennimmt und an ein Backend weitergibt, welches nicht auf der Mule Plattform läuft.

Abbildung 9: Visualisierung eines API Proxies

4.3 Policies

Eine Policy ist eine Komponente, die in den Fluss der Nachrichten eingeklinkt wird und dort Nachrichten lesen und manipulieren kann. Im API Manager können die in der Tabelle unten aufgeführten Policies über ein Formular konfiguriert und eingeklinkt werden.

Viele Policies wie z.B. Rate Limiting, HTTP Caching, Message Logging und Client ID können über einen Ausdruck in der Mule Expression Languagekurz MEL konfiguriert werden. Beispielsweise könnte das Rate Limiting mit dem Ausdruck:

Aufrufe eines Client-Typs einschränken. Eine Expression Language ist ein wichtiges Hilfsmittel, um das Verhalten spezifischer anpassen zu können, als dies mit graphischen Formularen möglich wäre. Mit der Mule Expression Language konnten bereits beim Mule Enterprise Service Bus Komponenten konfiguriert werden.

Die Anzahl der Richtlinien ist für ein derart komplexes Produkt relativ klein. Sonst übliche Policies, wie die unten aufgeführten fehlen:

• JSON Validierung
• JSON Transformation
• Skript Ausführung z.B. Groovy oder JavaScript
• REST nach SOAP

Ganz besonders fehlt eine Policy zur Ausführung kleiner Skripte in Groovy oder JavaScript. Mit einer solchen Richtlinie kann oft schnell eine kleine Anpassung durchgeführt werden, um das Produkt anzupassen oder eine Aufgabe zu lösen. Eine Skriptsprache wie Java, Groovy usw. kann natürlich in einem Projekt mit einer Custom-Policy eingesetzt werden. Der Charme der Skript-Richtlinien liegt aber gerade darin, schnell ohne ein Projekt zu erstellen, eine Anpassung durchzuführen können.

Für die Transformation von Nachrichten stehen nur zwei Policies zum Hinzufügen und Entfernen von HTTP Header Feldern zur Verfügung. Wer den Body einer Nachricht von JSON nach XML oder von JSON nach JSON transformieren möchte, muss dafür einen Flow d.h. eine Integrationsanwendung erstellen und diese dem API nachgeschaltet installieren.

Das Fehlen einer Richtlinie sollte nicht überbewertet werden, da wie bei fast jedem Produkt auch eigene Richtlinien erstellt werden können.

4.3.1 Erstellen einer eigenen Policy

Die bestehenden Policies können durch eigene Policies im Anypoint Studio erweitert werden. Für das Erstellen einer Policy muss ein Maven Projekt angelegt werden. Im Projekt wird die Policy mit einer XML Datei wie der unten aufgelisteten realisiert, die im grafischen Editor mit den Bausteinen des ESBs entwickelt werden kann.

<mule xmlns="http://www.mulesoft.org/schema/mule/core">
    <http-policy:proxy name="meine-policy">
        <http-policy:source>

            <http-policy:execute-next/>

            <http-transform:set-response statusCode="200">
                <http-transform:body>#[ 'Hello World!' ]</http-transform:body>
            </http-transform:set-response>

        </http-policy:source>
    </http-policy:proxy>
</mule>

Das Erstellen einer Policy gleicht dem Erstellen eines Integration Flows. Dass die Entwicklung von Policies auf dem Mule ESB basiert, ist am XML Namespace:

ersichtlich.

Das Erstellen von eigenen Policies ist in der Open Source Variante der Anypoint Platform nicht möglich. Für die Erstellung werden im Projekt Maven-Bibliotheken benötigt, die es nur für Kunden mit Enterprise Zugang gibt. Leider ist diese Information nicht sofort ersichtlich. Der Autor dieses Artikels hat viele Stunden mit der Suche in Maven-Repositories, dem Lesen von Dokumentation und Foren verbracht, bis er von dieser Einschränkung erfahren hat.

5. Access Management

Im Access Management wird der Zugriff auf die Plattform und auf die APIs geregelt. Es können Organisationen, Abteilungen, Rollen und Benutzer verwaltet werden. Feingranulare Berechtigungen sind möglich. So kann ein Benutzer beispielsweise APIs einsehen, aber selbst keine APIs veröffentlichen.

An Single-Sign On Verfahren werden OpenID Connect und SAML unterstützt. Als Provider können u.a.:

• Salesforce
• Okta
• OpenAM
• PingFederate
• Shibboleth

eingesetzt werden. Für den Zugriff auf die Plattform und den Zugriff auf die APIs können verschiedene Provider und Authentifizierungsverfahren zum Einsatz kommen.

Wer wann was auf der Plattform gemacht hat, ist im Audit-Log ersichtlich.

Abbildung 10: Audit Log

6. Anypoint Visualizer

Der Visualizer kann die Beziehungen zwischen Services auf der Anypoint Platform in Echtzeit analysieren und in Diagrammen darstellen. Nützlich ist die Darstellung der Service Beziehungen für eine Root-Cause Analyse, bei der der verursachende Service gefunden werden soll. Die händische Pflege einer Dokumentation der Servicebeziehungen ist nicht mehr nötig.

Abbildung 11: Beziehungen eines API Proxies.

7. Anypoint Monitoring

Die Abbildung unten zeigt einen Ausschnitt aus einem Dashboard für einen API Proxy.

Abbildung 12: Diagramme zur Anzahl der Requests

Mit wenigen Klicks können eigene Dashboards erstellt werden. Die Anzahl der zur Verfügung stehenden Metriken und Ansichten ist jedoch begrenzt.

Die Analyse Werkzeuge der meisten API Management Lösungen sind meist begrenzt, da die Kunden die Analyse oft in bestehende Elastik, Splunk, Prometheus oder anderen zentralen Monitoring und Logging Lösungen durchführen möchten. Analysedaten und Logs der Anypoint Platform können z.B. zur Speicherung und Auswertung an den ELK Stack weitergeleitet werden.

8. Runtime Manager

Im Runtime Manager können Anwendungen in der Cloud und on-Premise zentral installiert und überwacht werden. Der Runtime Manager verfügt über ein REST API, mit dem die Installation automatisiert und in das Continuous Delivery und Deployment eingebunden werden kann.

Abbildung 13: Dashboard einer Anwendung im Runtime Manager

Mule Anwendungen das schließt APIs mit ein, werden in einer Java Runtime ausgeführt. Parameter wie Speicher, Garbage Collection und Thread Anzahl können über die Oberfläche analysiert werden. Der Betrieb von Integration Flows und APIs ist nur auf einer Anypoint Runtime möglich.

Abbildung 14: Diagramm zum Speicherverbrauch

9. Die Entwicklungsumgebung Anypoint Studio

Das Studio basiert auf der beliebten Entwicklungsumgebung Eclipse und kann unter Windows, Linux und Mac OS installiert werden.Das Anypoint Studio ist eng mit den Web Anwendungen der Anypoint Platform verknüpft. Über einen Assistenten können Vorlagen und API Beschreibungen aus dem Exchange Marktplatz für lokale Projekte verwendet werden. Eine mit dem Anypoint Studio erstellte Integration oder Service Implementierung kann über eine Service Discovery Id und einen Knopfdruck mit einer API der Platform verbunden werden. Selbstverständlich ist es auch möglich, fertige Integrationen vom Studio aus in der Cloud zu installieren. Eigene Policies für die APIs können mit dem Studio ebenfalls entwickelt werden.

Der Screenshot unten zeigt einen Assistenten, mit dem aus dem Studio heraus auf API Beschreibungen, die im Exchange Marktplatz angeboten werden, zugegriffen werden kann.

Abbildung 15: Assistent für die Einbindung von API Beschreibungen und anderen Abhängigkeiten aus dem Exchange Marktplatz.

Das Studio kann aus API Beschreibungen Projekte mit vordefinierten Integrations-Flows erzeugen. Die Abbildung hier zeigt den APIkit Router, der Aufrufe an speziellere Flows weiterleiten kann.

Abbildung 16: Mule Integration Flow mit APIkit Router

Der Router kann anhand des Endpoint, d.h. an der Kombination aus HTTP Methode und Pfad entscheiden, welcher Flow aufgerufen wird. Im Screenshot unten ist ein Flow für den Endpunkt:

zu sehen, welcher Nachrichten transformiert und an einen Message Broker weitergibt.

Abbildung 17: Integration für einen Endpunkt.

Neben Integrationen und Services können mit dem Studio auch Richtlinien, also Policies für APIs erstellt werden.

Das Entwickeln von APIs unterscheidet sich nicht wesentlich vom Entwickeln von Integrationen mit dem Anypoint Studio oder dem früheren Mule ESB. Dem Programmierer stehen dieselben Bausteine und Werkzeuge wie bei der Integration zur Verfügung. Aus dieser Verbindung gewinnt die Plattform auch seine Flexibilität.

9.1 API Orchestration

Wenn ein API, selbst eine Reihe weiterer APIs aufruft, spricht man von Orchestration. Das Anypoint Studio ist ideal, um damit Orchestrationen zu entwickeln. Da dem Entwickler der volle Funktionsumfang eines ESBs zur Verfügung steht, lassen sich leicht APIs für bestehende Anwendungen, Datenbanken und weitere Systeme entwickeln.

10. Deployment

Für das Deployment von APIs und Flows gibt es mehrere Optionen.

CloudHub
MuleSoft bietet das managed Hosting der Anypoint Platform in ihrer Cloud an.

Pivotal Cloud Foundry
Für Entwicklung und Betrieb in der Pivotal Cloud Foundry gibt es die spezielle PCF Komponente.

On Premise Installation
Die Private Cloud Edition kann auf eigenen Rechnern installiert werden. Eine lokale Installation basiert auf Docker und dem Container Orchestrator Kubernetes.

11. Dokumentation

Für die Anypoint Platform gibt es eine ausführliche Dokumentation, Tutorials und Videos. Da der Mule ESB seit vielen Jahren auf dem Markt ist, gibt es eine große Anwender Community mit zahlreichen Foren und Artikeln

12. Vor- und Nachteile

Der Einsatz der Anypoint Platform bringt die folgenden Vor- und Nachteile mit sich.

Vorteile:

• Großer Funktionsumfang
• Der frühere Mule ESB ist als Funktion in die Plattform integriert d.h. dem Entwickler steht die ganze Palette an Konnektoren und Integrationsmuster zur Verfügung.
• Es gibt zahlreiche Konnektoren für SAP, MongoDB, Salesforce, Kafka, MQ, …
• Im Marktplatz gibt es viele Beispiele und Vorlagen
• Es werden mehrere Umgebungen wie Sandbox, Test und Produktion unterstützt.
• Guter grafischer Editor für Integration, Orchestration und Mapping.
• Umfangreiche Dokumentation und Tutorials
• Gute Integration zwischen den Komponenten
• Unterstützung für die alten Web Services mit SOAP und WSDL
• Unterstützung für eine Authentifizierung mit SAML Tokens. Bestehende SSO Lösungen lassen sich so leichter anbinden.

Nachteile:

• Es sind nur wenige Policies verfügbar. JSON Transformation, Validierung und Skript Policies fehlen.
• Es ist nicht ersichtlich, was Open Source ist und was nicht.
• (Noch) keine Unterstützung für Open API in der Version 3.
• Starker Fokus auf das „eigene“ RAML Format
• Hoher Einarbeitungsaufwand
• Die Plattform trägt den Balast des Mule ESB mit sich. Ein Beispiel dafür ist die eigene proprietäre Runtime anstatt einem üblichen Deployment in Fett-Jars, Container oder Kubernetes.

13. Für Wen ist die Anypoint Platform

Den Einsatz der Anypoint Plattform sollte erwägen, wer:

• bereits Salesforce einsetzt und mit MuleSoft seine on-Premise IT anbinden möchte.
• eine große, leistungsfähige in sich abgeschlossene Lösung sucht, die Dank Java aber offen für Erweiterungen ist.
• alles von einem Anbieter beziehen möchte.
• neben dem API Management eine Lösung für die Integration sucht.
• bereits MuleSoft einsetzt.

Möglicherweise ist die Plattform nicht optimal für den der:

• Open API verwenden möchte, da die Plattform primär das eigene RAML Format unterstützt.
• eine leichtgewichtige Lösung sucht
• Open Source verwenden und die Lizenzkosten sparen möchte
• eine andere als die Anypoint Runtime einsetzen möchte.

14. Fazit

Der Mule ESB hat eine lange Entwicklung vom Enterprise Service Bus zur Anypoint Platform durchlaufen. Wie man auf der Homepage von MuleSoft entnehmen kann, sind APIs jetzt der Fokus und die Integration ist ein zusätzliches Feature, welches das Angebot komplettiert.

An zahlreichen Stellen wie z.B. im Studio ist ersichtlich, dass das API Management dem Mule ESB übergestülpt wurde. Diese Tatsache ist weder gut noch schlecht. Es ist aber ein wesentlicher Unterschied zu Produkten wie z.B. Tyk oder Gravitee, die von vorne herein als API Lösung konzipiert wurden. Es gibt weitere Produkte, wie z.B. die WSO2 Lösung, die ebenfalls auf dem früheren ESB Produkt basieren.

Das Produkt von Mule ist kein API Gateway oder ein API Management, das man zu einer bestehenden Landschaft hinzufügt. Das Produkt ist eine Plattform, ein komplexes Ökosystem, das in Konkurrenz zu anderen Plattformen steht. Es stellt ein in sich geschlossenes vollständiges System dar, welches seine eigene Runtime mitbringt.

Anypoint ermöglicht integrierte Workflows vom Entwurf bis in die Produktion. Ein API kann im Editor entworfen, auf dem Marktplatz veröffentlicht, im Studio implementiert, auf CloudHub installiert und mit dem API Manager verwaltet werden.

MuleSoft geht mit der API Beschreibungssprache RAML einen Sonderweg. Andere Hersteller setzen auf das weiter verbreitete Open API.

Der Einsatz der Anypoint Platform ist ausschließlich mit der Enterprise Lizenz sinnvoll. Mit den Open Source Projekten von MuleSoft stößt man bald an die Grenzen und benötigt eine Komponente oder Bibliothek, die es ausschließlich für die Enterprise Lizenz gibt. Der Entwickler ist der Angst ausgesetzt, etwas einzusetzen, was er nicht einsetzen darf, da die Transparenz fehlt, was ohne Enterprise Lizenz geht und was nicht. Die Veröffentlichung des Quellcodes ist auf jeden Fall löblich und MuleSoft hat bereits einiges zur Open Source Bewegung beigetragen.

Das Anypoint Studio verfügt über einen der besten graphischen Editoren für Integrationsanwendungen auf dem Markt. Ein Nicht-Java-Programmierer kommt dennoch mit der Anypoint Platform früher oder später an seine Grenzen. Zum Meistern der Plattform sind folgende Kenntnisse hilfreich oder sogar notwendig:

• Mule Expression Language
• XML
• Maven
• Java Plattform: Classloading, JVM, GC, …
• Eclipse (Anypoint Studio)

Wer sich mit diesen Themen auskennt, der ist meist auch Entwickler. Ohne Java und Programmierkenntnisse lassen sicher einige kleinere Aufgaben erledigen. Der ambitionierte Anwender wird aber ohne Programmierkenntnisse schnell an seine Grenzen stoßen.

15. Quellen

Zugriff auf Maven Enterprise Repository nur für Enterprise Lizenz.
https://stackoverflow.com/questions/50626500/mulesoft-custom-policy-transform-extension

MuleSoft Joins the OpenAPI Initiative: The End of the API Spec Wars
https://swagger.io/blog/news/mulesoft-joins-the-openapi-initiative/

Salesforce kauft Mulesoft für 6,5 Milliarden Dollar
https://www.computerwoche.de/a/salesforce-kauft-mulesoft-fuer-6-5-milliarden-dollar,3544594