Trustworthy: j/xfs Introduction, 1th part

As more and more financial institutions incorporate the Java platform into their banking solutions, it is really necessary to be able to control the hardware used for these solutions (such as card readers, printers, and ATM). The expansion of the Java Platform's financial services (J/XFS) makes it easier for Java developers engaged in bank application development and provides a reliable architecture for this work. In the 1th part of this series (a total of two parts), software engineer Christoph Czernohous introduces this robust architecture, provides an overview of the J/XFS standard and the implementation of the architecture--he has a prominent contribution to J/XFS for FDI (J/XFS Financial Equipment Interface) 。

Accessing hardware from within a virtual machine has always been a challenge. This is particularly noticeable when accessing specialized target devices (such as ATM ATMs) from within a virtual machine. We, the developers of bank application development, find that there is usually no predetermined way to develop the functionality of the underlying banking hardware. From a developer's perspective, it is ideal to encapsulate such a device so that it can be accessed through a well-defined interface (just as the virtual machine itself encapsulates the underlying computer hardware). If so, this device responds to the virtual machine as an optional but familiar attachment, regardless of the type of hardware installed.

The Java developer is fortunate that such encapsulation is no longer a fantasy. An extension of the J/xfs,java platform that provides a standard set of Java interfaces that support various input and output devices for banking applications. In this way, J/XFS provides the full capabilities of the Java technology to the application's new classes, i.e. object-oriented and independent of the hardware manufacturer and the operating system manufacturer. In fact, J/XFS is not even limited to specific communication topologies, which we'll discuss later in this article.

This paper (the 1th part of the two parts series) is introduced as J/XFS and its reference to realize ―J/XFS financial equipment Interface (FDI). I will discuss requirements, history, and design decisions for J/XFS, explain how the different components of the kernel work together and introduce FDI for J/XFS. For the purpose of preparing for the second part of the series (which we will discuss more about developing device services under the J/XFS framework), I will show you how to install and configure FDI for J/XFS (available free of charge from the J/XFS forum, see Resources).

At the end of part 1th, you will know how to install J/XFS and how FDI for J/XFS implement this architecture. You will also install and configure the software, which contains a fully operational demo that will help you prepare for the second part by learning this technology in practice.

J/XFS Architecture

J/XFS designers have done some design decisions that profoundly affect their nature. One of the basic decisions they make is that most operations performed on the device will be performed asynchronously. If you send a message to the J/XFS device, the method that you call returns an identification number immediately. As shown in the sequence diagram in Figure 1, the actual results of the operation you started will be returned to you in a separate event after a period of time.

Figure 1. Asynchronous operations

Another bank peripheral standard ―windows Open System architecture/Financial Services Extension (WOSA/XFS) has already been defined earlier than the J/XFS. This standard is well known, but it does have some drawbacks. For example, because the standard uses the C programming language to define its interfaces, it does not use a basic object-oriented concept. In addition, it is limited to an operating system. In order to facilitate the developers who are already familiar with WOSA/XFS to learn J/XFS, the basic J/XFS device specification is based on WOSA/XFS. This tradeoff makes the J/XFS specification look a bit less object-oriented in some places, but it obviously contributes to the architecture being accepted.

In the process of J/XFS, the network and communication received further attention. In addition, since J/XFS devices are independent of the manufacturer's hardware, they can be distributed and used on the network. The network itself, that is, its hardware and protocols, is completely transparent to the application. Communication layer can be completely exchanged, and any network technology that people expect will have the possibility of realization.

To better understand how these decisions affect the J/XFS architecture, let's look at the kernel and its basic components.

Inside the kernel

J/XFS is a traditional client/server environment with supporting middleware, that is, the kernel. The kernel is the core of J/XFS, providing the basic infrastructure and the Java class libraries that are used to install the J/XFS environment. It is responsible for tracking messages, event delivery between all connected devices, and between applications and devices. In addition, the kernel also provides support for, for example, persistent storage or logging and tracking.

Because it consists of two separate Java APIs (one for applications and one for hardware devices), the J/XFS kernel is also used as a programming framework. Figure 2 shows the components of the framework.

Figure 2. Components of the J/XFS environment