Einführung in den Oracle Messaging Cloud Service

Es gibt eine Vielzahl an Faktoren, weshalb Messaging bei den Integrationstechniken nicht so viel Beachtung erfahren hat, aber aus meiner Sicht sind die wesentlichen Faktoren dabei …

• teilweise, weil es keine Netzwerkports verwendet, die typischerweise bereits offen sind (d. h. die Ports für Web Traffic) – wodurch Mitarbeiter aus den Bereichen Security und Netzwerk zum Öffnen von Ports überredet werden müssen, und zwar immer, wenn Datenverkehr Sicherheitsgrenzen passieren muss,
• weil jeder Messaging-Server unterschiedlich ist, sodass die Java Library des entsprechenden Herstellers verwendet werden muss, um den JMS-API-Standard zu erfüllen,
• das Überbrücken unterschiedlicher JMS-Implementationen kann etwas chaotisch sein
• und JMS funktioniert üblicherweise nicht so gut mit Web Clients.

Diese Punkte tragen vermutlich alle dazu bei, dass OMCS im Vergleich zu ICS, PCS und anderen Oracle PaaS-Angeboten selten erwähnt wird. Aber durch die Erschaffung von Oracle Messaging Cloud Service (OMCS) hat Oracle seinem Arbeitspferd einige neue Features spendiert. In diesen Artikeln werden wir uns die OMCS Web API ansehen, die auf der Messaging Engine sitzt und die neuen Features von OMCS betrachten, mit denen Messaging einen Anstrich für das 21.Jahrhundert erhält.

Die REST-API

Es wäre einfach, zu sagen, dass OMCS nur JMS mit einer REST-Skin ist. Das ist zwar oberflächlich richtig, würde jedoch einige seiner Stärken nicht richtig zur Geltung bringen. Die REST-API spiegelt größtenteils den JMS-Life-Cycle wieder, d. h. die Abfolge der Schritte für das Versenden oder Empfangen von Nachrichten, wie auch das Diagramm zeigt.

Da die API auf REST basiert, können Kommandozeilentools wie cURL sehr einfach zur Interaktion mit der Messaging-Plattform verwendet werden. Eine Vielzahl an unterschiedlichen Aufgaben kann erledigt werden, vom Erstellen von Test-Skripten zum Ziehen oder Abholen von Testdaten über eine Integrationslösung oder gar für einen Ende-zu-Ende-Prozess, aber auch das Anhängen von OMCS an Ihr bevorzugtes Monitoring-Tool und die Verwendung von Skripten zum Sammeln von Betriebsstatusinformationen mit cURL oder sogar das Anhängen von REST-Aufrufen im Monitoring-Tool.

Die Dokumentation zum REST-Interface für OMCS gehört heute zu den besten für die neuen Oracle-iPaaS-Lösungen, obwohl es noch einige Lücken gibt. Daher führen wir Sie durch eine Reihe von Kommandos, um zu zeigen, wie einfach Messaging-Tasks ausgeführt werden können (dadurch wird auch dargestellt, wie einfach es wäre, OMCS in leichtgewichtigen Umgebungen wie Front-End-Clients zu verwenden oder die Bereitstellung eines leistungsstarken Backbones zur Kommunikation für Microservices).

Aus Sicherheitsgründen haben wir die Anmeldedaten und Informationen zur Server-Identifizierung verschwommen dargestellt.

Eine Verbindung herstellen

Das erste cURL-Kommando ist zum Herstellen der Verbindung. Wie Sie in diesem Screenshot sehen, beginnt das Kommando mit -u gefolgt von <Benutzername>:<Passwort>. Anschließend geben wir ein HTTP-Header-Attribut für X-OC-ID-TOKEN-STATUS an, mit dem Cross-Site Request Forgery (CSRF) Angriffe verhindert werden. CSRF kann ausgeschaltet werden, da wir die Kommunikation von nur einem Ort betreiben und den Overhead für zusätzliche Token-Details und Token-Gültigkeitsprüfung nicht benötigen. Die Parameter -c und -b zeigen beide auf eine Cookie-Datei. Diese Cookie-Datei wird benötigt, da die Sitzungsinformation des Messagings an die HTTP(S)-Sitzung gekoppelt ist. Ohne Cookie-Datei würde der nächste REST-Aufruf nicht mit der Verbindung verlinkt werden und daher fehlschlagen. Der letzte Parameter, den wir in allen Beispielen verwenden, ist –write-out %{http_code}. Dadurch wird sichergestellt, dass die HTTP-Antwortcodes und die dazugehörigen Nachrichten angezeigt werden. Das ist wichtig, da einige REST-Interfaces ausschließlich HTTP(S)-Antwortcodes zurückgeben. Diese Parameter werden konsistent für alle unsere Aufrufe verwendet.

Im nächsten Teil geht es um das Aufrufen des URI. Der URI-String bis v1 wird immer gleich bleiben für alle Aufrufe und enthält die Region und den Domänennamen. Im verbleibenden Teil der URI erstellen wir (daher PUT) eine Verbindung, die wir im Folgenden myConnection nennen und die Parameter sagen OMCS, die Verbindung unverzüglich herzustellen. Sie sehen, dass die bereitgestellte Antwort den Code 201 enthält – das ist der http_code, den wir angegeben haben. Die Codes im Bereich 2xx zeigen erfolgreiche Aktionen an und 201 im bedeutet "Erstellt".

Herstellen einer Sitzung

Damit haben wir jetzt eine Verbindung hergestellt, also ist der nächste Schritt das Erstellen des Sitzungsobjekts, das den folgenden REST-Aufruf verwendet, siehe Screenshot.

Wie Sie sehen, geht der URI-Pfad auf Sitzungen und identifiziert mySession mit einem Parameter, der die zu verwendende Verbindung nennt. Anschließend sehen wir eine weitere 201-Antwort, die uns anzeigt, dass die Sitzung erfolgreich hergestellt wurde.

Bei hergestellter Sitzung können wir nun mit folgendem Kommando eine Queue erstellen.

Erstellung einer Queue

Wir haben einen Antwortcode, der auf die erfolgreiche Queue-Erstellung zeigt. Aber wir können alle verfügbaren Queues betrachten. Gemäß den Design-Prinzipien von REST, sollten wir mit einer GET-Operation auf Queues Informationen aller Queues einsehen können. Genau das haben wir durch das Ergebnis des zweiten cURL-Statements im Screenshot.

Mit 3 Zeilen eines cURL-Skripts haben wir uns verbunden und eine Queue erstellt und mit einer vierten Zeile prüfen wir, welche Queues vorhanden sind. OMCS ist nicht beschränkt auf Queues, sondern kann auch temporäre und zeitlich andauernde Themen handhaben.

Hinzufügen von Nachrichten

Da die Queue erstellt ist, benötigen wir nur noch einen zusätzlichen REST-Aufruf, um einen Message Producer zu definieren (wir nennen ihn MyProducer) und hängen den Producer mit Sitzungs- und Zielparametern an eine bestimmte Queue (der erste Aufruf im Beispiel) und beginnen dann mit dem Hinzufügen von Nachrichten in die Queue über den Producer.  Zur besseren Lesbarkeit mit cURL haben wir cURL angewiesen, dass der REST-Body der Inhalt einer Datei -T <Dateiname> ist. Wie unten dargestellt, haben wir für diese kleine Demonstration drei einfache, unterschiedliche Nutzdaten verwendet. Da das Hinzufügen von Nachrichten als eine Änderung am Producer betrachtet wird, ist der entsprechende Aufruf ein HTTP POST. Damit kommen wir zu einer der Einschränkungen bei OMCS: Die Nachrichtengröße ist auf 512 kb begrenzt. Das sollte allerdings kein Problem sein, da selbst vollständig gefüllte, kanonische XML-Schemas von AIA, OAGIS, ARTs etc. diese Grenze nur schwer überschreiten dürften. Wenn Sie jedoch Medieninhalte übergeben möchten, wird dies sicher eine Einschränkung sein. In solch einem Fall würde ich aber dazu raten, die Medieninhalte direkt zu speichern und Nachrichten zu verschicken, die auf den Ablageort der Dateien zeigen.

Bei Bedarf können wir die Queue durchsuchen. Das ist dann in etwa wie das Bewegen eines Cursors in einer Datenbank. Die nächste Nachricht wird zurückgegeben, wenn Sie den Aufruf zum Durchsuchen durchführen und es wird ein HTTP-Code 200 zurückgegeben. Wenn das Ende der Queue erreicht wird, erhalten Sie einen leeren Nachrichtenkörper.

Queue Consumption

Im vorherigen Teil haben wir mit dem Befüllen der Queue aufgehört. Wir fahren jetzt fort mit dem Einrichten des Consumers. Das funktioniert im Großen und Ganzen genauso wie beim Producer. Mit den Parametern identifizieren wir das zu konsumierende Ziel und die zu verlinkende Sitzung, siehe Screenshot.

Den Consumer nennen wir q1Consumer (der Name ist wie zuvor der letzte Teil des URI). Wie bei JMS können bei Bedarf Filter auf den Consumer angewendet werden, aber in diesem Beispiel nehmen wir alle Nachrichten mit jeder Header-Attribut-Filterung. Den Consumer können wir anschließend zum Abrufen von Nachrichten verwenden. Beachten Sie, dass jeder Aufruf ein Timeout von 1 Sekunde (1000 Millisekunden) auslöst, da wir nicht durch das Warten auf eine Antwort gesperrt werden wollen, siehe Screenshot.

Jede Antwort gibt eine Nachricht mit dem Body der Antwort zurück. Beachten Sie, dass die HTTP-Antwortcodes direkt nach der Ausgabe des Nachrichteninhalts aufgeführt sind, da es keinen Zeilenumbruch zwischen der Antwortausgabe der cURL-Anweisung und der Ausgabe des HTTP-Antwortcodes gibt.

Game Changer – Push Listener

Die vorherigen Abschnitte haben gezeigt, wie einfach das Arbeiten mit Messaging Servers mit dem REST-Interface ist. Das clevere Feature von OMCS ist die Möglichkeit, Listener zu definieren, die als REST-Endpunkte Nachrichten empfangen. Diese Art von Listener ist bekannt als Push Listener, da OMCS aktiv den benannten REST-Endpunkt aufruft. Das bedeutet, dass wir eine JMS verwendende Alt-Anwendung mit einem zeitgemäßen REST-Webservice verbinden können.

Durch das Push Listener Framework entsteht eine zusätzliche Sicherheitsebene (darauf gehen wir gleich näher ein). Wie das Posten des Nachrichteninhalts, so ist auch das Bereitstellen des Nachrichtenkörpers und der Konfigurationsinformation für den Push Listener sehr einfach durch das Angeben einer Datei in cURL. Im Folgenden ein einfaches Beispiel, in dem wir einen Listener namens myListener definieren, der nach Nachrichten in der myFirstQueue sucht. Nach Empfang wird ein Web-Ziel aufgerufen, das über die URL und die zu verwendende HTTP-Methode identifiziert wird (PUT oder POST kann verwendet werden):

Das Beispiel ist sehr einfach gehalten, da wir keine Fehleraktionen definieren, falls der REST-Dienst fehlschlägt. Bei Verbindung zu einem bestimmten Thema müssen weitere Informationen bereitgestellt werden, z. B. ob die Verbindung dauerhaft ist.

Prüfung des Push Listeners

Bei Erstellung eines Push Listeners müssen zusätzliche Informationen bereitgestellt werden, da OMCS einen einfachen Prüfmechanismus implementiert zur Bestätigung, dass der REST-Dienst die Aufrufe erwartet und dass der Client vertrauenswürdig ist. Erreicht wird das durch den einen ersten Aufruf der REST URI, der nur die Header-Attribute enthält (X-OC-MPL-CHALLENGE) und optional einen zusätzlichen Parameter im Aufruf zur Herstellung des Listeners. Dieser Parameter wird dann als zusätzlicher Header-Wert X-OC-MPL-VERIFICATION weitergegeben. Beim ersten REST-Aufruf muss die Antwort im Body den bereitgestellten Wert aus X-OC-MPL-CHALLENGE enthalten. Dieser Prüfschritt dient dazu, dass ein Oracle-Dienst nicht als Quelle einer DoS-Attacke identifiziert wird, da der Empfänger die "Challenge" aktiv bestätigen muss. Werfen wir einen Blick auf den cURL-Aufruf zur Herstellung des Message Push Listeners, siehe Screenshot.

Für die Logik zur Handhabung der beschriebenen Sicherheitsprüfung nutzten wir die Testversion des Dienstes webscript.io. Mit diesem Dienst können wir einfach einen REST-Endpunkt definieren und nutzen die Skriptsprache des Dienstes (Die Sprache sieht aus wie JavaScript, basiert aber auf LUA). Das Skript sieht aus wie in Abbildung 9.

Beachten Sie, dass beim direkten Aufruf des Webskripts aus cURL das Header-Attribut wie bereitgestellt empfangen wird (in unserem Fall also komplett in Großbuchstaben). Beim Senden über OMCS wird das Webskript jedoch in Höckerschreibweise (Camel Case) empfangen.  Wir könnten natürlich die Bedingung durch String-Manipulation im Header-Attribut vereinfachen, aber wir haben uns dazu entschieden, einfach auf beide Formate zu prüfen. Wie dargestellt wird das Challenge-Header-Attribut zurückgegeben, wenn es identifiziert wurde (daraus wird der Body der Antwort gebildet). Ohne Rückgabeobjekt geben wir standardmäßig eine leere Antwort mit HTTP-Code 200 zurück.

Der erste Aufruf kann im Webskript betrachtet werden und ist einfach nur der Bestätigungsaufruf mit folgender Prüfung und Challenge, siehe Screenshot.

Anschließend wird die erzeugte Antwort mit der Challenge im Body gezeigt, wie in Bild 11.

Nach diesem Aufruf sieht der REST-Dienstaufruf für zu sendende Nachrichten aus wie in Bild 12.

Fazit

Die Einrichtung eines Push Listeners ist recht einfach. Lediglich etwas Arbeit muss in den Challenge-Mechanismus gesteckt werden, aber das ist nicht schwierig. In der Praxis nehmen Sie vermutlich lieber einen API-Gateway oder einen einfachen Proxy mit Container Cloud Service o. ä. zur Handhabung der Challenge.

Wie bereits erwähnt, können wir die Konfiguration flexibel anpassen und erweitern. OMCS ist eine tolle Plattform, um Messaging und webbasierte Integrationslösungen miteinander zu verknüpfen, insbesondere in Hybrid- oder Cloud-Umgebungen.