Extension for Financial Services

XFS besteht hauptsächlich aus drei Hauptteilen und zwar aus der XFS-API (Application-Programming-Interface), einer korrespondierenden XFS-SPI (Service-Provider-Interface – der Gegenpart der XFS-API), einem XFS-Manager und den sogenannten Service-Providern. Im Folgenden werden diese Komponenten im Einzelnen erklärt.

Die API bietet einer XFS-basierten Anwendung Services (Dienste) an, welche diese nutzen kann. Das SPI wiederum steht jenen Anwendungen zur Verfügung, die einen Service anbieten. Die SPI spricht also vom Hersteller des Automaten entwickelte Service Provider direkt an. Diese Service Provider repräsentieren die Peripherie-Geräte. Die herstellerneutrale Anwendungsschnittstelle der API abstrahiert von gerätespezifischen Implementierungen, sodass dieselbe Applikation verschiedene Automaten unterschiedlicher Hersteller wie Wincor Nixdorf, IBM usw. ansteuern kann, sofern diese eine XFS-API anbieten.

Die Verbindung und Kommunikation zwischen der API der XFS-Applikation und der herstellerspezifischen SPI erfolgt über den sog. XFS-Manager. Dieser ist nicht nur verantwortlich für die Abbildung der API auf die SPI, sondern auch für den Aufruf eines bestimmten Service-Providers, welcher für jedes anzusteuernde Gerät implementiert sein muss. Er übersetzt die API-Aufrufe in SPI-Aufrufe und ist darüber hinaus auch für die Steuerung im Netz zuständig. Er ermöglicht also, dass Anwendung und Peripherie-Steuerung auf verschiedenen Rechnern laufen können und verarbeitet den synchronen bzw. asynchronen Kommunikationsverlauf.

Zusammen mit der API und der SPI umfasst die Definition der XFS-Schnittstellen auch eine Definition von Konfigurationsparametern für jede einzelne Einheit der Peripherie-Geräte. Bei einem Notenauszahler könnte der Konfigurationsparameter beispielsweise mitteilen, ob es sich um einen 4-fach- oder 8-fach-Auszahler handelt. Die Konfigurationsparameter werden benötigt, um den Aufruf der API mittels XFS-Manager zu dem entsprechenden Service-Provider weiterzuleiten, welcher wiederum das spezifische Gerät oder den spezifischen Dienst anspricht. Sie teilen der Anwendung auch mit, um welche Geräte ein Automat verfügt.

XFS-Architektur

XFS ist ein Protokoll, welches entweder eine asynchrone, synchrone oder eine direkte Verbindung zur Kommunikation mit einem Server aufbaut. Der Ablauf der genannten Verbindungen unterscheidet sich wesentlich voneinander. Die Rollen der einzelnen Module (XFS-Manager, Service-Provider) sind genauso unterschiedlich wie die Nachrichten, welche z. B. zur Ansteuerung eines Gerätes verwendet werden.

Vorteil ist, dass die Applikation und der XFS-Manager nichts über die Kommunikation zwischen den Service-Providern und den Services bzw. Geräten wissen. Daher kann eine individuelle Entwicklung unterschiedlichster Hersteller der SPI-Schnittstellen zur Kommunikation mit deren Geräten erfolgen. Diese Schnittstellen stehen dann der Applikation als Service über die API zur Verfügung und können von ihr genutzt werden. Das heißt, eine Bank beispielsweise kann also die SPI und die Service-Provider der entsprechenden Hersteller in ihre Applikation implementieren und die unterschiedlichen Geräte ansprechen. Vom Standpunkt von XFS aus betrachtet, ist der Hersteller der Automaten dafür verantwortlich, die entsprechenden Module zur Steuerung dieser Geräte mitzuliefern. Der Hersteller muss also die Service-Klassen bzw. die Service-Provider zur Ansteuerung der Peripherie-Geräte entwerfen und entwickeln. Es ist demnach zweitrangig, ob es sich bei den abzubilden Automaten um ein ATM-Gerät, ein Kiosk-System oder einen Kassenautomaten im Behördenbereich handelt. Wichtig ist, dass die Geräteklassen so implementiert werden, dass sie den Kriterien von XFS entsprechen, so dass jede beliebige XFS konforme Applikation die Geräte steuern bzw. überwachen kann.

Automat gesteuert durch eine XFS-Anwendung

Über XFS können also Schnittstellen entwickelt werden, die eine Steuerung der Geräte unabhängig von der proprietären Anwendung des Automaten gewährleisten. Mittels dieser Schnittstellen kann nun eine beliebige XFS-Anwendung über den XFS-Manger auf die Service Provider zugreifen und so deren Dienste nutzen. Die Logik der auf dem Automaten-Rechner vorhandenen Anwendung könnte nun wie in Abbildung 'XFS-Steuerung' aussehen.

Steuerung durch XFS-Anwendung

Nachfolgend soll erklärt werden, was bei der Entwicklung einer XFS-Anwendung bzw. bei der Entwicklung von Service-Providern für Komponenten zusammenspielen (Abbildung XFS-Steuerung: Zusammenspiel von API, XFS-Manager, SPI).

XFS-Anwendung und die API

Eine XFS-Anwendung kann aus einer graphischen Benutzeroberfläche für die Kundenseite des Automaten (meist HTML), einer GUI zur Informations- und Steuerzwecke der Anwendung (Administrationstool) und einem Kernel bestehen, welcher die Hauptfunktionen des Zusammenspiels der Dienste während einer Transaktion übernimmt. Wie die Anwendung im Einzelnen aussieht, ist jedoch vom XFS-Framework unabhängig, sofern die Funktionen der einzelnen XFS-Komponenten zuverlässig ausgeführt werden können. Die Anwendung weiß nichts Genaueres über die Geräte und wird daher ihrerseits nur Kommandos über die API senden, welche beispielsweise das Auszahlen eines bestimmten Betrages über die Auszahlungsgeräte oder das Drucken einer Quittung veranlassen soll. Der eigentliche Auszahlungs- bzw. Druckvorgang ist Sache der Service-Provider.

API-Perspektive einer XFS-Anwendung

Der XFS-Manager

Der XFS-Manager besteht aus drei verschiedenen DLLs, welche folgende Aufgabe übernehmen (Abbildung XFS-Manager-Perspektive).

XFS-Manager-Perspektive einer XFS-Anwendung

MSXFS.DLL

Diese DLL beinhaltet die Funktionsaufrufe der API und der SPI. Sie ist also für die Weiterleitung eines Kommandos der XFS-Anwendung zuständig, indem sie das Äquivalent des SPI aufruft und so den eigentlichen Dienst über die Service-Provider startet. Dieser wird dann bei Erfolg als Pointer vom Typ HResult an die Applikation zurückgegeben.

XFS_SUPP.DLL

Die Funktionen dieser DLL beschränken sich auf die Support-Aufgaben des XFS-Managers, welche von der XFS-Anwendung und/oder von den Service-Providern angefordert werden können. So ist diese DLL u. a. zuständig Speicher zu allozieren.

XFS_CONF.DLL

Ruft die in der Windows-Registry vom Hersteller hinterlegten Konfigurations-Parameter für einen z. B. von der XFS-Anwendung angeforderten Dienst auf. Die o. g. MSXFS.DLL muss – um den richtigen Service aufrufen zu können – die genauen Parameter dieses Services kennen. Die XFS_CONF.DLL liefert also die benötigten Informationen über den Service, so dass der richtig angeforderte Service aufgerufen werden kann.

SPI und Service Provider

Die SPI ist das Gegenstück zur API. Sie definiert standardisierte und portable Schnittstellen zu den Service Providern. Die SPI besteht – genau wie die API auch – aus einem Set von Methoden bzw. Funktionen. Sie werden u. a. benötigt, um z. B. einen Service durch die Service Provider zu erhalten. Die SPI-Schnittstelle dient dem XFS-Manager zum Aufrufen eines von der Anwendung über die API geforderten Services.

Bei den Service Providern handelt es sich um Dienste, die entweder jeder für sich in einer DLL untergebracht sind – Notenauszahler in einer Dispenser.dll, Quittungsdrucker in einer Printer.dll usw. – oder es handelt sich um alle Module in einer DLL.

SPI-Perspektive einer XFS-Anwendung

Die Service Provider sind jetzt aber nicht nur einfache Module, welche nur angesprochen werden, wenn ein bestimmter Dienst ausgeführt werden soll. Sie haben auch dafür zu sorgen, dass sogenannte Multiple-Devices – wie ein Protokolldrucker und ein Quittungsdrucker in einem physischen Drucker – entsprechend gesteuert und angesprochen werden können. Von Service Providern muss z. B. auch das Verwalten von Anforderungen verschiedener Anwendungen übernommen werden, welche alle zur gleichen Zeit auf ein bestimmtes Gerät zugreifen möchten.

• Alexander Jammer: Analyse und Gegenüberstellung bidirektionaler Banken-Kommunikationsprotokolle. Diplomarbeit