MuleESB Anypoint Platform, CloudHub und Anypoint Connectors

Cloud Computing gehört die Zukunft, und Cloud Computing macht auch vor Integrationstechnologien nicht halt. Denn auch im Integrationsumfeld muss Rechenleistung bereitgestellt und bezahlt werden. Und so kommt es, dass Mule ein ganz eigenes Konzept mit dem Namen „Anypoint Platform“ auf die Beine gestellt hat, mit dem ich mich in diesem Teil der Blog-Serie beschäftigen werde.

Im Mittelpunkt der Anypoint Platform steht weiterhin der Mule ESB. Anstatt den ESB selbst zu betreiben bietet Mule zusätzlich die Möglichkeit, Komponenten gehostet in „CloudHub“ zu betreiben, einer von Mule bereitgestellten Cloud Plattform. Beides kann parallel erfolgen, Komponenten können sowohl in einem lokalen ESB (Community- oder Enterprise-Edition) als auch in CloudHub betrieben werden. Im Parallelbetrieb kommunizieren beide über einen VPN-Tunnel. Um diesen Kern siedelt die Anypoint Platform die drei Bereiche „APIs“, „SOA“ und „SaaS“ an, die durch den ESB oder CloudHub integriert werden.

In diesem Teil werde ich „CloudHub“ in den Mittelpunkt stellen und wähle deswegen den Bereich „SaaS“ für ein Beispiel aus. Das Ziel ist, eine Mule Anwendung lokal in Mule Studio zu entwickeln und zu testen, die über einen Anypoint Connector mit einer externen Plattform kommuniziert. Mule bietet für einige Plattformen Connectoren an, die umfangreiche fachliche Funktionen anbieten. Außerdem besteht grundsätzlich die Möglichkeit, über das Dev-Kit eigene Connectoren zu implementieren.
Ich habe den Twitter-Connector ausgewählt, da sich hierunter jeder etwas vorstellen kann und Ergebnisse sofort sichtbar werden. Das Beispiel wird auch zeigen, dass Komponenten zwischen den Bereichen „SOA“ und „SaaS“ migriert werden können. In der Praxis ist dies sehr bedeutend: Jede CloudHub Komponente soll problemlos auch in einem selbst gehosteten ESB betrieben werden können.

Um loslegen zu können, müssen einige Bedingungen erfüllt sein. Damit die Arbeit später rund läuft, beschaffen wir uns die folgenden Dinge:

• Twitter: Account, Application und Access Tokens zur Application
• Cloudhub.io: Account und Application

Die Access Tokens sind erforderlich, damit sich unsere Anwendung gegenüber der Twitter App über das OAuth-Verfahren authentifizieren kann.
Einen Twitter-Account kann sich jeder kostenlos auf www.twitter.com anlegen. Es empfiehlt sich, ein temporäres Passwort zu verwenden, denn: Um eine App anlegen zu können, muss eine Handy-Nummer mit dem Twitter-Account verknüpft werden. Dies erfolgt über www.twitter.com -> Einstellungen -> Mobiltelefon. Sollte es hierbei Probleme geben (in Deutschland sollte dies der Fall sein), kann ein Handy wie unter finding-your-twitter-short-or-long-code , Kapitel „To add your phone to your Twitter profile via long code“ beschrieben, verknüpft werden. Hierbei muss das eigene Passwort per SMS versandt werden. Nach dem Senden jeder SMS sollte ca. eine Minute gewartet werden.

Um eine Twitter Application anzulegen, müssen die folgenden Schritte durchgeführt werden:

Zunächst loggen wir uns unter http://dev.twitter.com  ein und öffnen das Menü „My applications“:

Dort finden wir einen Button „Create New App“, über den wir eine neue App mit dem Namen „publishSimpleText“ anlegen. Wir ergänzen die erforderlichen Felder, die Callback URL lassen wir zunächst leer. Wir werden nun auf eine Übersicht unserer App weitergeleitet. Nun ändern wir den Access level der App von „Read-only“ auf „Read and write“:

Wir wählen im oberen Menü „API Keys“ aus:

Und generieren access tokens für unsere App:

War dies erfolgreich, stehen im Menü „API Keys“ unserer App nun die folgenden Elemente bereit, die wir uns in einer Text-Datei für später speichern:

• API key, API secret, Access level (read and write)
• Access token, Access token secret, Access level (read and write)

Nachdem wir alle Twitter-Artefakte erzeugt haben, richten wir einen CloudHub Account ein. CloudHub ist nicht vollständig kostenlos, kann jedoch problemlos ohne Kosten getestet werden. Hierzu erstellen wir unter www.cloudhub.io unter „try it free“ einen Account und loggen uns direkt ein. Auf der Startseite erwartet uns bereits ein Button „Add“. Wir legen eine Application wie folgt an:

Wir müssen einen freien Domain-Namen wählen und uns für später merken. Außerdem empfiehlt es sich, die Version an die eigene Mule Studio bzw. Mule Runtime Version anzupassen, in meinem Fall die 3.4.1. Solange wir gratis arbeiten, ist außerdem die Anzahl von Workern (Recheneinheiten) beschränkt. Damit sind wir in Cloudhub zunächst fertig und können unsere Entwicklung starten.

Um das Beispiel möglichst einfach zu halten, entwickeln wir eine Mule Application, die Anfragen per HTTP entgegennimmt und deren Payload als Tweet auf Twitter veröffentlicht. Hierzu nutzen wir den Twitter Connector.
Wir legen nun ein neues Mule Projekt mit dem Namen „twitterapp“ und einem gleichnamigen Flow an. Beginnen wir damit, ein Global Element vom Typ „Twitter“ hinzuzufügen (Dieses ist unter „Cloud Connectors“ zu finden). Hier fügen wir alle Tokens und Secrets ein, die wir uns beim Anlegen der Twitter App gemerkt haben. Die Zuordnung hierbei ist:

Access Key -> Twitter Access token
Access Secret -> Twitter Access token secret
Consumer Key -> Twitter API key
Consumer Secret -> Twitter API secret

Im XML-Code des Flows sollte noch kontrolliert werden, dass bei den Tokens keine Zeilenumbrüche an ungeeigneten Stellen (mitten im Token) enthalten sind. Nun fügen wir dem Flow einen HTTP Inbound Endpoint, eine Echo-Aktivität (um Aktivitäten beobachten zu können) sowie eine Twitter-Aktivität (Unter Cloud Connectors / Twitter) hinzu. In der Twitter-Aktivität wählen wir die neu angelegte Twitter Configuration sowie die Operation „Update status“ aus, als Status übergeben wir den derzeitigen Message Payload. „Update status“ ist die Operation zur Veröffentlichung von Tweets.

Damit ist unser Beispiel schon fertig. Wir können es direkt in Mule Studio ausführen und im Browser http://localhost:8081/hello  aufrufen, und wir werden auf Twitter folgendes zu sehen bekommen:

Im Grunde haben wir hier auch schon den Beweis, dass diese Mule Application in unserer eigenen Mule Umgebung funktionsfähig ist. Im nächsten Schritt werden wir das Beispiel in CloudHub ausrollen. Hierzu nehmen wir eine kleine Anpassung vor: In der Inbound HTTP Aktivität setzen wir den Port von 8081 auf „${http.port}“. Diese Variable wird von CloudHub bereitgestellt. Für das Deployment wählen wir den einfachen Weg über das Mule Studio. Ein Rechtsklick auf unser Projekt bringt die Option „CloudHub –> Deploy to CloudHub…“ hervor:

Im darauf folgenden Dialog füllen wir zunächst unsere Zugangsdaten aus. Daraufhin können wir das Feld „Environment“ befüllen. Unter „Domain“ fügen wir den zu Beginn gemerkten Wert ein und geben noch eine kurze Beschreibung an.

Mit Klick auf „Finish“ wird das CloudHub Deployment gestartet, ein kleines Dialogfenster bestätigt den Erfolg.

Als nächstes loggen wir uns wieder unter www.cloudhub.io ein und öffnen unsere Application. Im Menüpunkt „Deployment“ erfahren wir den Status unserer Anwendung: Sie sollte „deployed“ sein. Wir können außerdem das Logfile prüfen: Unter dem Menüpunkt „Logs“ sehen wir eine vollständige Konsoleausgabe unserer Anwendung. Hier erwarten wir auch unsere Textausgabe, sobald wir unsere Anwendung aufrufen.
Die Variable ${http.port} wird automatisch auf 80 gesetzt, deswegen können wir unsere Anwendung nun wie folgt aufrufen:

http://mytwitterapp.cloudhub.io/cloudtest

Unser Twitter-Account quittiert die Funktionsfähigkeit:

und auch im Log-File ist ein Echo-Eintrag mit dem Payload “/cloudtest“ zu finden. Unter dem Menüpunkt „Dashboard“ sehen wir außerdem, wie viele Nachrichten zu welcher Zeit verarbeitet wurden, was einen Indikator für die Auslastung darstellt.

Da die Variable ${http.port} als Port auch lokal funktioniert, ist es tatsächlich möglich, die Anwendung direkt zwischen einer eigenen Mule Umgebung und CloudHub umzuziehen. Dies erleichtert zum einen Entwicklung und Test, zum anderen reduziert es die Abhängigkeit von der Cloud Plattform, da jederzeit die Möglichkeit besteht, Komponenten aus der Cloud zurück in die eigene Umgebung zu holen.

Verfügbarkeitswerte, Preise und Leistungen lassen sich bei Mule direkt erfahren, weswegen ich diese Werte hier nicht aufzähle. Ich möchte jedoch abschließend erwähnen, dass CloudHub auf Amazon Web Services (AWS) betrieben wird. Ob dies nun Vor- oder Nachteil ist, bleibt für jeden selbst zu bewerten, ich halte es jedoch für eine Schlüsselinformation, die ich nicht vorenthalten möchte.