3

Am I generally right that the benefit of using the XFS interface is that I can write a program which interoperates with devices (pin-pads, card-readers) only once? The result (ideally) is that I can change devices and I don't need any changes in my software. And this is possible because of using a universal XFS interface. Am I right?

So I write a program which implements some business logic, it invokes operations of the XFS-interface, XFS-library finds (how by the way?) a service-provider library which understands the queries and commands from the XFS and that library works with the device directly. Am I right about that?

For example, I have a documentation and a DLL (from the device-vendor) for a device to work with. How can understand if it can be used with XFS infrastructure? I just see in the documentation that this dll exposes C-functions to work with the device.

brwirth
  • 5
  • 4
EngineerSpock
  • 2,575
  • 4
  • 35
  • 57

3 Answers3

4

About first part of your question. Yes, you are right. In ideal case XFS give you independence from device implementation in your application. You can use same commands and queries to work with different device models.

About how XFS find specific device library. To execute any XFS command or query you must open "Logical service", which is symbolic name for service. Any logical service is binded to specific service provider. All binding "logical service" <-> "service provider" is stored at windows registry. Any service provide is windows dll with specific interface. Dll must export set of functions named like WFPxxx, where xxx is XFS method name. More details you can find at XFS documentation. Thus of above, not all vendor dll is XFS service provider library. You can see exported function of dll to determine, that is XFS service provider dll.

Alex.D.Alexeev
  • 304
  • 1
  • 6
3

The main purpose of the CEN / XFS is to allow banking systems (that run in ATMs, Kioskys, etc.) could abstract the hardware complexity (example: each manufacturer has its solution about how a notes dispenser must behave). In fact, this goal is not always fully achieved, because the standard XFS is very open to differences of interpretation. Because of this, it is very common for banks (banks and the like) to create their own interpretation of XFS and require its suppliers to follow. This is possible when we are talking about large banks (such as Bradesco in Brazil). But for small banking entities, who do not buy a large volume of ATMs and other terminals, another alternative is possible, such as adding an layer of abstraction in top of the XFS layer inside their systems, so that this layer deal with small differences in interpretation that manufacturers give to the standard XFS.

I would also recommend you read the following articles:

  1. XFS Overview
  2. XFS Some detail
2

You intend to develop WOSA/XFS applications. Then you have to make a development environment, which includes: a) XFS installation from the hardware manufacture if you are developing a software for the machine which is already in use at the FI market (e.g. brand ATM or kiosk model) b) Or, if you are making your own hardware which includes some XFS devices (e.g. card reader, bar code reader etc) in the configuration, this is a more complicated and very hard for implementation because you have to implement your own port of CEN XFS standard, which includes to build all necessary code (dlls, libs and header files) for your own XFS Manager, and all device SPI's (Service Provider Interface) including API SPI responsible for a general XFS functionalities. This would be not a quite rational time and money investment if your new hardware FI unit cannot be sold in quantities, at least hundreds or even thousands. But, you can buy ready-made XFS installation from a variety of vendors (NCR, Wincor, Diebold, Glory Solutions etc).

This would be a first step, to supply both of your development and testing environment with an appropriate XFS installation (development version for devel machine, a runtime version for testing machine). Second, for the application development needs, you could install your favorite C++ environment on your development machine and debugging environment on the testing hardware.

When you finished with a setup, you have just to include header files in your code and to link libraries when building executable in order to make appropriate software for your cash/credit card machine.

You're right, XFS is more like Java "write once, run everywhere" so there are no needs for maintaining and adopting the software in the future if you change, for example, a discontinued card-reader or cash deposit unit for another one even from a different vendor.

dejvas
  • 21
  • 4