Vor kurzem standen wir vor der Frage, wie wir Daten von unserem internen Backoffice System in unseren unseren Online-Shop transportieren sollten. Die Fragestellung kam auf, da die beiden Anwendungen auf unterschiedlichen Datenbanken aufsetzen. Konkret ging es hierbei um Standardisierten Dienstleistungen, d.h. einheitliche Serviceleistungen, die in den PC-SPEZIALIST Stores in Anspruch genommen werden können. Die Basisdaten dieser Dienstleistungen werden bei uns intern im Backoffice gepflegt, die Vermarktung der Dienstleistungen erfolgt über den Online-Shop. Um die relevanten Daten, wie zum Beispiel Name und Beschreibung der Dienstleistung zwischen den Systemen transportieren zu können haben wir uns (Achtung, ab nun wird es technisch!) für die Kommunikation über einen Message Broker entschieden. Unsere Wahl fiel auf den ActiveMQ Server von Apache. ActiveMQ ist ein Open Source Produkt, das u.a. die vollständige Java Message Service API implementiert. Somit ist er für uns wunderbar geeignet, um die Basisdaten unserer Dienstleistungen in Form von JSON-Objekten an den ActiveMQ Server zu senden. Und da dieser neben weiteren anderen Sprachen, auch die Anbindung von PHP erlaubt, haben unsere Shopentwickler leichtes Spiel, wenn es darum geht die Nachrichten abzuholen und die Dienstleistung entsprechend im Shop darzustellen.

Was die Verwaltung der Nachrichten angeht, gilt es bei ActiveMQ grundsätzlichen zwischen zwei verschiedenen Arten zu unterscheiden. Sind die Nachrichten nur für einen einzigen Konsumenten interessant, werden sie vom Produzenten in einer Queue abgelegt. Sobald ein Konsument eine Nachricht abholt, steht sie möglichen anderen Konsumenten nicht mehr zu Verfügung. Sollte dies nötig sein, sollte man mit Topics arbeiten. Hier werden die Nachrichten vom sogenannten Publisher an ein Topic geschickt und stehen dort solange zur Verfügung bis sie von allen Subscribern abgeholt worden sind. In den obigen Ausführungen sind damit auch schon einige wichtige Grundbegriffe des Messagings gennannt. Es gibt zum einen Clients wie die Producer/Consumer (Messageverwaltung per Queue) und die Publisher/Subscriber (Messageverwaltung per Topic) und zum anderen den Broker, der die Nachrichten verwaltet. In unserem Fall arbeiten wir mit einer Queue. Unser Backoffice System repräsentiert den Producer und der Shop tritt als Consumer auf. Die Verwaltung der Nachrichten übernimmt für uns der ActiveMQ. Mithilfe dieser Struktur ist es möglich eine lose gekoppelte, verlässliche und asynchrone Kommunikation zwischen den beiden Anwendung zu realisieren.

Nützlicherweise bietet ActiveMQ obendrein auch einige Enterprise Features, wie z.B. Clustering. So haben wir uns ganz einfach zwei ActiveMQ Server nebeneinander aufgesetzt, die zusammen ein sogenanntes Network of Brokers im Master-Slave-Modus bilden. Die ActiveMQ API bietet nun die komfortable Möglichkeit, dass sich der Client in einem sogenannten Failover Transport Modus mit dem Broker verbindet. Die dahinterstehende Logik ist recht simpel zu verstehen. Der Client versucht zuerst, sich mit dem ersten Broker zu verbinden. Erst wenn das nicht gelingt, oder wenn der erste Broker ausfällt, verbindet er sich mit dem zweiten Broker. Dadurch wird sichergestellt, dass die Nachrichten mit sehr hoher Wahrscheinlichkeit auch zugestellt werden und nicht im Nirvana verschwinden.

Insgesamt bietet das ganze Thema noch viele weitergehende Möglichkeiten. Für uns in der IT Abteilung bedeutet der Einsatz von ActivqeMQ einen ersten Schritt in Richtung Message Oriented Middleware und/oder Enterprise Service Bus Architektur. Bereits jetzt haben wir einige weitere Anwendungsfälle im Hinterkopf, die wir mithilfe solche Architekturen umsetzen wollen. Die Zukunft als Entwickler bei der SYNAXON AG wird, neben der alltäglichen Routine, also auch weiterhin von technisch spannenden und reizvollen Themen geprägt sein.