Blog / Research · Messaging Gateway

I n diesem Artikel diskutieren wir die Funktionen des Messaging Gateway und beschreiben seinen Nutzen für den Anwender. Dieser Artikel richtet sich an jeden, der an den technischen Hintergründen der internen Kommunikation unserer Software interessiert ist und ist folgendermaßen aufgebaut: Nach einer kurzen Einführung beschreiben wir grob die Rolle des Gateways innerhalb der Infrastruktur und die Funktionen. Weiter geben wir einen Überblick über die verwendeten Technologien und diskutieren einige Interna. Nachdem wir dann die Integration und den Informationsfluss aus der Sicht des Anwenders beschreiben, schließen wir mit Möglichkeiten für die zukünftige Entwicklung.

EINFÜHRUNG

Im üblichen Client-Server-Kommunikationsmodell ist der Initiator der Kommunikation immer der Client (den man sich in diesem Kontext als mobiles Endgerät vorstellen kann), der eine Anfrage an den Server stellt. Der Server reagiert dann mit der Vorbereitung einer Antwort, die dann verschickt und vom Client empfangen wird. Es ist jedoch möglicherweise wünschenswert, dass der Server den Client aktiv kontaktiert, um ihn über ein serverseitig stattgefundenes Ereignis zu informieren. Dadurch soll die Verteilung von Daten beschleunigt werden.

Es gibt grundsätzlich zwei Mechanismen, um dieses Ziel zu erreichen. Der erste ist die Implementierung einer Server-Komponente im Client, der eine Client-Komponente im Server gegenübersteht. Dieser Ansatz ermöglicht den kommunizierenden Agenten, vorrübergehend die Rollen zu tauschen. Dazu muss der Client jedoch einen Callback am Server anmelden. Der zweite, der vom Ansatz her etwas einfacher ist, ist Polling. Bei diesem Ansatz kontaktiert der Client periodisch den Server, um nachzufragen, ob zwischenzeitlich ein relevantes Ereignis stattgefunden hat.

Der zweite der beiden Mechanismen könnte direkt in einer Client-Anwendung implementiert werden. Mit dem Aufkommen moderner Smartphones wurde es jedoch üblich, diesen Mechanismus bereits in das Betriebssystem der mobilen Plattform (etwa Blackberry OS, iOS, Android oder Windows Phone) zu integrieren. Dadurch wird ein einheitlicher Kommunikationskanal etabliert, der es so aussehen lässt, als ob der Server aktiv und beliebig Information an einen Client senden würde, der sogar zum Empfang der Nachricht gestartet werden kann, falls er nicht läuft. Dieser Mechanismus, den der Kunde typischerweise schon von anderen Anwendungen wie etwa Social-Media-Clients her kennt, wird üblicherweise als „Push“ bezeichnet. Eine vom Client empfangene Push-Nachricht sollte jedoch keine wesentliche Nutzinformation enthalten, sondern nur eine clientseitige Synchronisation auslösen. Diese Konvention ermöglicht eine robuste Implementierung, in der der Client alle nötigen Funktionen auslösen kann und nur der Informationsfluss verlangsamt ist, falls der Push-Dienst vorübergehend nicht funktioniert.

ROLLE UND FUNKTIONEN DES MESSAGING GATEWAY

Die Hauptaufgabe des Messaging Gateway ist die Vereinheitlichung der Push-Mechanismen verschiedener mobiler Plattformen und ihre Bereitstellung über eine einzige Web Service-Methode. Noch wichtiger als die Vereinheitlichung der spezifischen Plattform-Details ist aber das Hosting außerhalb des Kundensystems, was durch einen unserer IT-Partner erfolgt. Für die Authentifizierung gegenüber dem jeweiligen Plattform-Anbieter sind digitale Zertifikate oder API-Schlüssel nötig, die gelegentlich ausgetauscht werden müssen. Das Hosting als separate Komponente macht dies möglich, ohne dass Administrationstätigkeiten innerhalb des Kundensystems notwendig sind. Ferner wird so die Implementierung von Zugriffsrechten möglich.

Während die Push-Nachrichten in erster Linie maschinenlesbare Information enthalten, ist es ein weiterer Zweck des Messaging Gateway, über eine vereinheitlichte Web Service-Methode das Verschicken von SMS zu ermöglichen, wofür intern mehrere Provider (SmsNews, MessageBird und inMobile) verwendet werden. Anders als für Mail gibt es für SMS faktisch kein standardisiertes Protokoll für die programmatische Annahme von Daten über das Web. Ähnlich wie beim Verschicken von Push werden die Details und die Administrationsaufgaben unter einer Abstraktionsschicht vor dem Kunden verborgen.

IMPLEMENTIERUNGSDETAILS UND VERWENDETE TECHNOLOGIEN

Das Messaging Gateway besteht aus insgesamt ca 8.500 Codezeilen, die in ca. 150 Sourcecode-Dateien organisiert sind. Es ist als Server-Komponente in C# als SOAP Web Service mittels Windows Communication Foundation implementiert, einer Infrastruktur innerhalb des Microsoft .NET-Frameworks. Der Dienst wird üblicherweise als Windows-Systemdienst bereitgestellt, kann aber auch als Windows-Anwendung laufen. Neben Logging, das sowohl in eine Textdatei als auch zur besseren Auswertbarkeit und Kontingentierung in eine SQLite3-Datenbank erfolgt, ist der Server größtenteils zustandslos in dem Sinne, dass ein Methodenaufruf das Verhalten späterer Methodenaufrufe nicht ändert. Alle Konfigurationsdaten sind in XML-Dateien gespeichert; somit können die Benutzeraccounts, Zertifikate und API-Schlüssel im laufenden Betrieb mittels eines Text-Editors geändert werden. Dies kommt einem Systemadministrator, der mit möglichst geringer Ausfallzeit die Konfiguration ändern muss, sehr entgegen.

Um die Implementierung so einfach und robust wie möglich zu halten, wurde keine manuelle Performance-Optimierung vorgenommen. Performance ist hier zweitrangig, da problemlos mehrere Instanzen des Dienstes bereitgestellt werden können. Für die interne Kommunikation mit den Dienstanbietern wird sowohl XML als auch JSON zur Serialisierung der Daten verwendet. Aus Gründen der Qualitätssicherung sind automatisierte Komponententests mit Hilfe von MSTest implementiert worden. Derzeit werden 83 einzelne kategorisierte Tests ausgeführt, die in erster Linie dazu dienen sollen, Fehlkonfigurationen der Anwendung auszuschließen. Nach regelmäßiger Ausführung dieser Tests wird der Dienst programmatisch installiert, gestartet und eine Web Service-Methode aufgerufen. Schließlich wird die gesamte Anwendung in einem Zip-Archiv bereitgestellt. Der gesamte Bereitstellungsprozess erfolgt durch ein Jenkins-Projekt.