Oktopus

<p>Integration einmal anders</p>

Über Oktopus

Oktopus ist nicht nur eine Software, sondern auch ein völlig neues Konzept der Integration. Im Gegensatz zu anderen Integrationsservern verwendet Oktopus nicht ein channelbasiertes Modell, in welchem Kanäle zwischen einzelnen Subsystemen aufgebaut werden. Oktopus nutzt ein Nachrichtenmodell, das alle eingehenden Daten in eine universelle Normalform umwandelt. Diese normalisierten Nachrichten können dann beliebig weiterverarbeitet werden und in jedwede Nachrichtenform umgewandelt werden. Oktopus ist in der Lage Nachrichten in unterschiedlichen Encodings zu verarbeiten. Dabei wird jede Nachricht zu Unicode dekodiert, der alle denkbaren Zeichen beinhalten kann. Die Nachrichten in der Normalform können dann in beliebigen Encodings dargestellt werden.

Ein weiteres Konzept von Oktopus besteht darin, alle Kommunikation nach außen mittels Nachrichten zu realisieren. Hierzu werden Nachrichten auf sogenannte virtuelle Schnittstellen geroutet. Auf diese Art und Weise kann Oktopus auch durch Nachrichten gesteuert werden, sowie alle relevanten Loggingformationen über jedes beliebiges Interface ausgeben. Dies macht Oktopus zu einem System, welches beliebige Workflows abbilden kann und auf jedes Event reagieren kann. So kann eine beliebige Nachricht eines Subsystems Oktopus steuern und beispielsweise ein Interface stoppen oder starten. Oktopus stellt sogenannte Systemschnittstellen zur Verfügung. Diese dienen nicht für der Kommunikation mit Subsystemen, sondern der Verarbeitung von Nachrichten. So können Nachrichten zwischengespeichert und bei Bedarf weitergeroutet, archiviert oder an eine andere Instanz von Oktopus weitergeleitet werden.



Plattformunabhängig

Durch den Einsatz der Scriptsprache Python ist Oktopus in der Lage auf verschiedenen Plattformen ausgeführt zu werden. Oktopus kann als Windows-
Dienst, als Linux-Daemon oder unter Apples iOS eingesetzt werden. Entwickelt wird Oktopus unter Debian-Linux und FreeBSD. Hierfür existiert auch ein Installationsscript, welches alle nötigen Pakete automatisch mittels des Paketmanagers DPKG installiert. Als Serversystem kann Oktopus somit ohne Lizenzkosten für das Serverbetriebssystem mit maximaler Stabilität betrieben werden.



Effizient

Beim Import von Python-Programmcode wird vom Interpreter Bytecode erzeugt, der es Oktopus erlaubt, äußerst performant zu arbeiten und die vorhandenen Ressourcen sehr effizient zu nutzen. Oktopus kann auf einfacher Hardware bereits ca. 25 HL7-Nachrichten pro Sekunde zerlegen, routen, neu zusammensetzen und weiterversenden. Dies ist durch die konsequente Entwicklung von auf Performance optimierten Code und das integriertes Loadbalancing möglich, durch welches jedes Interface soviel Rechenzeit wie nötig zur Verfügung gestellt bekommt.



Multithreadingfähig

Durch ein hervorragendes Multithreading ist Oktopus in der Lage, die Kommunikation zu den unterschiedlichen Subsystemen asynchron auszuführen. Exceptions eines Ausführungsfadens haben dadurch keine Auswirkung auf andere Schnittstellen. Ressourcen, welche von mehreren Schnittstellen benötigt werden, wie beispielsweise der Counter, der angibt, an wieviele Interfaces eine Nachricht versendet wurde, werden mittels Semaphoren immer nur einer Schnittstelle zugewiesen. Hierdurch kommt es nicht zu Wechselwirkungen zwischen den Schnittstellen.

Unsere Motivation

Unsere Gesellschaft und unsere Wirtschaft wird jeden Tag vernetzter. Unterschiedliche Lebensbereiche, in denen wir verschiedene Anwendungen und Softwaresysteme benutzen, tauschen Daten aus und verschmelzen zu einem allumfassenden System. Um die Kommunikation zwischen diesen unterschiedlichen Systemen und Bereichen zu ermöglichen, wurden unterschiedliche Standards und Normen geschaffen. SOAP, ODBC, FinTS, EDI oder im Krankenhausbereich HL7 versuchen die verschiedenen Anwendungen zu normieren und stellen den Versuch dar, aus unterschiedlichen Applikationen ein möglichst lückenlos integriertes Gesamtsystem zu erzeugen.

Allerdings liegt die Betonung auf dem Attribut „verschiedene“. Es existieren eine ganze Reihe solcher Standards und nur die Systeme, welche sich auf den gleichen festgelegt haben, lassen sich mit geringem Aufwand integrieren. Und genau an dieser Stelle setzt Oktopus an. Ziel ist es, Schnittstellen auf veschiedenen Layern des OSI-Schichtenmodelles anzubinden und alle Nachrichten in eine einheitliche universelle Form zu transformieren. Diese Nachrichten können dann als Trigger für einen komplexen Workflow verwendet werden. Oktopus macht somit aus einer heterogenen Umgebung unterschiedlicher Softwaresysteme ein hochintegriertes Gesamtsystem.

Externe Schnittstellen

Oktopus unterstützt eine Vielzahl von Schnittstellen. Diese setzen auf verschiedenen Schichten des OSI-Schichtenmodelles an und ermöglichen es zwischen ganz unterschiedlichen Protokollen Nachrichten auszutauschen. So ist es denkbar, aus einem SNMP-Trap welcher per UDP an Oktopus gesendet wird, ein Latex-Dokument zu generieren und auszudrucken. Jede Nachricht die über eine Schnittstelle übertragen wird, kann flexibel mittels eines XML-Templates konfiguriert werden. So können im medizinischen Bereich HL7-Nachrichten jeden Typs, GDT- , ADT- oder BDT-Nachrichten aus dem Ambulanzbereich, finTS-Nachrichten aus dem Finazbereich oder EDI-Nachrichten sowie beliebige Formate generiert oder eingelesen werden.

b

File-Interface

m

Path-Interface



OS-Interface



Viewer-Inteface



Printer-Interface

z

Sound-Interface



UDP-Interface



Postgres-Inteface



Email-Interface



TCP/IP-Interface



HTTP-Interface



Oracle-Inteface



SMS-Interface



RS232-Interface

d

XMLRPC-Interface

I

Shell-Inteface

Interne Schnittstellen

Oktopus bietet die Möglichkeit interne Schnittstellen zu definieren. Diese sind nicht für die Kommunikation mit Subsystemen, sondern zur Realisierung eines Workflows gedacht. So können Nachrichten in eine Archivschnittstelle geroutet werden, die beispielsweise als dynamisch erzeugte Mappingtabelle oder als Nutzerdatenbank für Nachrichten benutzt werden kann. Durch das Bridge-Interface können verschiedene Oktopus-Instanzen miteinander vernetzt werden und das Stack-Interface dient als temporärer Speicher und zum Verbinden unterschiedlicher Nachrichten. Das Timer-Interface ist in der Lage in einem bestimmten Zeitintervall ein Event in Form einer Nachricht auszulösen. Mit Hilfe der Prozess-Schnittstelle kann ein Subrozess erzeugt werden, der eine Anzahl von Schnittstellen bedient. Dabei werden die Daten zwischen dem Hauptprozess und dem Kindprozess mittels Shared-Memory ausgetauscht, was diese Kommunikation sehr performant macht.



Stack-Interface



Archive-Interface



Bridge-Interface

g

Process-Interface



Timer-Interface

Virtuelle Schnittstellen

Oktopus kann Nachrichten auch an sogenannte "virtuelle Schnittstellen" routen, bzw. von diesen empfangen. Diese müssen nicht explizit definiert werden, da sie standardmäßig vorhanden sind. Das Logging-Interface generiert abhängig vom Loglevel Logginginformationen in Form von Nachrichten. Diese können dann in Files geschrieben, per Email verschickt oder als SMS versendet werden. Das System-Interface nimmt Befehle für Oktopus entgegen und liefert Statusinformationen auf Anfrage. Dadurch ist es möglich dass jede beliebige Nachricht das Verhalten von Oktopus dynamisch beeinflussen kann. Diese Eigenschaft macht Oktopus wesentlich flexibler als gängige Konkurrenzprodukte.



System-Interface

k

Logging-Interface

Besondere Features

Oktopus beinhaltet einen Agent für Android der auf Basis von Qpython wichtige Informationen wie den Standort an einen Oktopus-Server sendet. Die aktuellen GPS-Daten können dann mittels eines Webinterfaces abgerufen werden. In die andere Richtung kann das Smartphone auch mittels Nachrichten aus Oktopus ferngesteuert werden. Diese Features sind allerdings nur mit ausdrücklicher Erlaubnis des Besitzers des Smartphones zulässig. Für Oktopus gibt es ein Nagios-Plugin, welches es ermöglicht, Oktopus zu überwachen. Mit diesem Plugin kann Nagios abfragen ob Schnittstellen nicht verbunden sind, die es sein sollten oder ob die Inodes auf dem Volume auf dem sich ein Archive befindet zur Neige gehen.