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.
INTEGRATION UND VERHALTEN AUS SICHT DES ANWENDERS
Im Kundensystem muss die URL des Messaging Gateways zusammen mit geeigneten Zugangsdaten in der Konfigurationsdatei des VISITOUR Servers hinterlegt werden. Zusätzlich ist die Aktivierung einiger Module nötig. Aus der Sicht des Anwenders werden die beiden Funktionen des Messaging Gateway folgendermaßen benutzt:
1. Wenn entweder eine Ausführung des PowerOpt-Algorithmus oder ein manueller Eingriff eines Disponenten einen Auftrag am aktuellen Datum einer Ressource zuweist, wird eine Push-Nachricht an diejenige Installation von FLS MOBILE geschickt, die zu der betroffenen Ressource gehört, um sie über die Änderung der Planung zu informieren. Ganz ähnlich wird, falls der Auftrag von einer anderen Ressource entfernt wurde, die zugehörige Ressource ebenfalls informiert. Beide FLS MOBILE-Clients aktualisieren ihren Zustand, indem sie den VISITOUR-Server kontaktieren.
2. Wenn der Disponent eine Ressource informell kontaktieren möchte, kann eine SMS über eine Funktion innerhalb des VISITOUR-Dispositions-Clients geschickt werden. Für diese Funktion muss das Zielgerät der SMS kein Smartphone sein, da SMS als Dienst von FLS MOBILE unabhängig ist.
Im ersten Fall, der schematisch in Fig. 1 dargestellt ist, sind potenziell die meisten verschiedenen Clients betroffen. Wir nehmen an, dass zwei Ressourcen R1 und R2 im Außendienst mit den mobilen Geräten M1 und M2 arbeiten, wobei M1 ein iOS-Gerät und M2 ein Android-Gerät ist. Der Disponent verschiebt einen Auftrag von R1 nach R2. Der Dispositionsschritt wird (als 1 bezeichnet) an den VISITOUR Applikationsserver übertragen, der dann entscheidet, dass R1 und R2 ihren Status aktualisieren müssen. Aufgrund seiner internen Konfiguration kann der VISITOUR Applikationsserver die Ressourcen zu den zugehörigen Geräten M1 und M2 und ihren verschiedenen Plattformen auflösen. Anschließend sendet er eine Nachricht, die von M1 (einem iOS-Gerät) empfangen werden soll, und eine Nachricht, die von M2 (einem Android-Gerät) empfangen werden soll, was jeweils durch 2a und 2b bezeichnet ist. Beide Nachrichten werden über die gleiche Web Service-Methode verschickt. Intern löst das Messaging Gateway diese Anfragen so auf, dass sie schließlich über den Apple Push Notification Servie (APNS) an M1 und über Google Cloud Messaging (GCM) an M2 geschickt werden, bezeichnet jeweils durch 3a und 3b. Die Nachrichten werden dann, durch 4a und 4b bezeichnet, jeweils an M1 und M2 geschickt. Diese kontaktieren schließlich den VISITOUR Applikationsserver, um ihre Planung zu aktualisieren (5a und 5b).
AUSBLICK
Zusammenfassend liefert das Messaging Gateway geeignete Abstraktion, Vereinheitlichung und Zentralisierung durch die Integration von ausgereiften, etablierten Technologien. Obwohl nichts davon wirklich Hexenwerk ist, wird dadurch ein bemerkenswertes Maß an dynamischer Kommunikation über verschiedene Plattformen realisiert, das mit manuellen Implementierungen höchstens schwer möglich gewesen wäre. Zusätzlich wird der nötige Administrationsaufwand überraschend klein gehalten. Beim derzeitigen Stand der Implementierung werden die SMS-Anbieter durch jeweilige proprietäre Schnittstellen bedient. Innerhalb der Infrastruktur einiger unserer Kunden können jedoch SMS über einen Mailserver verschickt werden, den wir zukünftig gerne als weiteres SMS-Backend zusätzlich integrieren möchten. Ferner ist die Implementierung eines Web-Interfaces zur Erzeugung von Statistiken angedacht.