Extension for Financial Services
Extension for Financial Services ( XFS ) is a programming interface for controlling peripheral devices in self-service systems such as ATMs or transfer terminals .
The original specification of XFS comes from Microsoft ( WOSA / XFS ). Today XFS is specified by the CEN ( CEN / XFS ).
In newer devices, an interface called J / XFS , defined in the Java programming language, is also used.
The XFS architecture
XFS mainly consists of three main parts, namely the XFS-API (application programming interface), a corresponding XFS-SPI (service provider interface - the counterpart of the XFS-API), an XFS manager and the so-called service Providers. These components are explained in detail below.
The API offers an XFS-based application services that it can use. The SPI in turn is available to those applications that offer a service. The SPI therefore addresses the service provider developed by the manufacturer of the machine directly. These service providers represent the peripheral devices. The vendor-neutral application interface of the API abstracts from device-specific implementations, so that the same application can control various machines from different manufacturers such as Wincor Nixdorf, IBM, etc., provided they offer an XFS API.
The connection and communication between the API of the XFS application and the manufacturer-specific SPI takes place via the so-called XFS manager. This is not only responsible for mapping the API to the SPI, but also for calling a specific service provider, which must be implemented for each device to be controlled. It translates the API calls into SPI calls and is also responsible for controlling the network. It therefore enables the application and peripheral control to run on different computers and processes the synchronous or asynchronous communication flow.
Together with the API and the SPI, the definition of the XFS interfaces also includes a definition of configuration parameters for each individual unit of the peripheral devices. In the case of a note payout, the configuration parameter could, for example, indicate whether it is a 4-slot or 8-slot payout. The configuration parameters are required to forward the call of the API using the XFS Manager to the appropriate service provider, which in turn addresses the specific device or the specific service. They also tell the application which devices a machine has.
XFS is a protocol that establishes either an asynchronous, synchronous or a direct connection for communication with a server. The sequence of the connections mentioned differs significantly from one another. The roles of the individual modules (XFS manager, service provider) are just as different as the messages that z. B. can be used to control a device.
The advantage is that the application and the XFS manager do not know anything about the communication between the service providers and the services or devices. Therefore, an individual development of different manufacturers of the SPI interfaces for communication with their devices can take place. These interfaces are then available to the application as a service via the API and can be used by it. This means that a bank, for example, can implement the SPI and the service provider of the relevant manufacturer in its application and address the various devices. From the point of view of XFS, the manufacturer of the machines is responsible for delivering the appropriate modules to control these devices. The manufacturer must therefore design and develop the service classes or the service provider for controlling the peripheral devices. It is therefore of secondary importance whether the machine to be depicted is an ATM device, a kiosk system or a pay machine in the government sector. It is important that the device classes are implemented in such a way that they meet the criteria of XFS, so that any XFS-compliant application can control or monitor the devices.
Automatically controlled by an XFS application
XFS can be used to develop interfaces that guarantee control of the devices regardless of the proprietary application of the machine. Using these interfaces, any XFS application can now access the service providers via the XFS manager and thus use their services. The logic of the application on the machine computer could now look like the figure 'XFS control'.
Architecture of an XFS application
The following is to explain what interacts when developing an XFS application or when developing service providers for components (Figure XFS control: interaction of API, XFS manager, SPI).
XFS application and the API
An XFS application can consist of a graphical user interface for the customer side of the machine (mostly HTML), a GUI for information and control purposes of the application (administration tool) and a kernel which takes over the main functions of the interaction of the services during a transaction. How the application looks in detail, however, is independent of the XFS framework, provided that the functions of the individual XFS components can be executed reliably. The application does not know anything more precise about the devices and will therefore only send commands via the API which, for example, should initiate the payment of a certain amount via the payment devices or the printing of a receipt. The actual payment or printing process is a matter for the service provider.
The XFS manager
The XFS manager consists of three different DLLs, which take on the following tasks (Figure XFS manager perspective).
- MSXFS.DLL
- This DLL contains the function calls of the API and the SPI. It is therefore responsible for forwarding a command from the XFS application by calling the equivalent of the SPI and thus starting the actual service via the service provider. If successful, this is returned to the application as a pointer of the type HResult.
- XFS_SUPP.DLL
- The functions of this DLL are limited to the support tasks of the XFS manager, which can be requested by the XFS application and / or by the service provider. So this DLL u. a. responsible for allocating memory.
- XFS_CONF.DLL
- Calls the configuration parameters stored by the manufacturer in the Windows registry for a z. B. on the service requested by the XFS application. The above-mentioned MSXFS.DLL must know the exact parameters of this service in order to be able to call the correct service. The XFS_CONF.DLL therefore provides the required information about the service so that the correctly requested service can be called.
SPI and service provider
The SPI is the counterpart to the API. It defines standardized and portable interfaces to the service providers. Like the API, the SPI consists of a set of methods or functions. You will u. a. needed to z. B. to receive a service through the service provider. The SPI interface is used by the XFS manager to call a service requested by the application via the API.
The service providers are services that are either housed individually in a DLL - note payout in a Dispenser.dll, receipt printer in a Printer.dll, etc. - or they are all modules in a DLL.
The service providers are now not just simple modules that are only addressed when a certain service is to be performed. You also have to ensure that so-called multiple devices - such as a log printer and a receipt printer in a physical printer - can be controlled and addressed accordingly. From service providers z. For example, the management of the requirements of different applications can be taken over, which all want to access a certain device at the same time.
Web links
- Alexander Jammer: Analysis and comparison of bidirectional banking communication protocols . Thesis