级别： 初级 Christoph Czernohous (cc@de.ibm.com), 软件工程师
2001 年 8 月 02 日 由于越来越多的金融机构将 Java 平台纳入其银行业的解决方案，能够控制用于这些解决方案的硬件（诸如：读卡机、打印机以及 ATM）真的很有必要。Java 平台金融服务的扩展（J/XFS）能使从事银行应用程序开发的 Java 开发者轻松一些，并且为此项工作提供一种可靠的体系结构。在本系列（共两部分）的第 1 部分，软件工程师 Christoph Czernohous 介绍了这种健壮的体系结构，提供了 J/XFS 标准的概述和该体系结构的实现 ― 他对之有突出贡献的 J/XFS for FDI（J/XFS 金融设备接口）。请在
讨论论坛和作者以及其他读者交流对本文的心得。
从虚拟机内访问硬件一向是一种挑战。当从虚拟机内访问专门的目标设备（比如：自动柜员机 ATM）时，尤其显而易见。我们这些从事银行应用程序开发的开发者发现：通常没有预先确定的方法来开发底层银行硬件的功能。从开发者的角度看，将这样的设备封装起来，使其能够通过一个定义好的接口访问（就象虚拟机本身封装了底层的计算机硬件一样）是很理想的。如果这样，不管安装了什么类型的硬件，这样的设备都作为可选的却熟知的附件回应虚拟机。
Java 开发者值得庆幸的是这样的封装不再是空想。J/XFS，Java 平台的一种扩展，提供了一套标准的 Java 接口，支持用于银行应用程序的各种输入、输出设备。这样，J/XFS 给应用程序新的类提供了 Java 技术的全部能力，即面向对象和独立于硬件制造商以及操作系统厂商。实际上，J/XFS 甚至不局限于特定的通信拓扑结构，我们将在本文的后面部分讨论。
本文（两部分系列的第 1 部分）作为 J/XFS 及其参考实现 ― J/XFS 的金融设备接口（ FDI ）的介绍。 我将讨论需求、历史以及为 J/XFS 定形的设计决策，解释组成内核的不同部件怎样共同工作和介绍 FDI for J/XFS。出于为该系列的第二部分（我们将更多地讨论在 J/XFS 框架下开发设备服务）作准备的目的，我将向您展示怎样安装和配置 FDI for J/XFS（从 J/XFS 论坛可免费得到，请参阅
参考资料）。
在第 1 部分结束时，您将懂得怎样安装 J/XFS 以及 FDI for J/XFS 怎样实现这种体系结构。您还将安装和配置软件，它包含完全可操作的演示，有助于您通过实践学习此项技术，为第二部分内容作准备。
J/XFS 体系结构
J/XFS 设计师做了一些深刻影响其本质的设计决策。他们所做的基本的决策之一是：在设备上执行的大多数操作将以异步方式执行。如果您发送消息给 J/XFS 设备，您所调用的方法立刻返回一个标识号。如图 1 中的序列图表所示，您启动的操作的实际结果将在一段时间后，在一个单独事件里返回报告给您。
图 1. 异步操作
先于 J/XFS 的另一种银行外围设备标准 ― Windows 开放系统体系结构／金融服务的扩展（WOSA/XFS）早已经定义好了。这种标准广为人知，但是确实有一些缺点。例如，因为此标准使用 C 编程语言定义其接口，它没有使用基本的面向对象的概念。此外，它被局限在一个操作系统。为了便于已经很熟悉 WOSA/XFS 的开发者学习 J/XFS，基本的 J/XFS 设备规范都是基于 WOSA/XFS 的。这种折衷使得 J/XFS 规范在某些地方看起来有点不象是面向对象，但是它显然促成了这种体系结构被接受。
J/XFS 的过程中，网络和通信受到了进一步关注。此外，由于 J/XFS 设备是独立于制造商的硬件，可以被分布和使用于网络。网络本身，即它的硬件和协议，对应用程序完全透明。通信层能被完全交换，人们期望的任何网络技术都有实现的可能性。
为了更好地理解这些决策是怎样对 J/XFS 体系结构产生影响的，我们来看一看内核及其基本的组件。
内核内部
J/XFS 为带有起支持作用的中间件的传统的客户／服务器环境，即内核。内核是 J/XFS 的核心，提供基本的基础结构和安装 J/XFS 环境要用到的 Java 类库。它负责跟踪所有连接的设备以及应用程序和设备之间的消息、事件传递。此外，内核也提供诸如：持久存储或日志、跟踪的支持功能。
因为它由两个独立的 Java API 组成（一个用于应用程序，一个用于硬件设备），所以， J/XFS 内核也作为编程框架。图 2 展示了该框架的组件。
图 2. J/XFS 环境的组件
 |
J/XFS 的历史
1998 年 9 月，来自 DeLaRue，IBM，NCR，Sun Microsystems 和 Wincor Nixdorf 的代表，在一起讨论了怎样能将银行设备集成到电子商务环境中。Java 平台稳步发展足可以应用于金融应用程序，显然所有与之相关的群体，包括消费者，都能从集成应用程序这一普遍方法中受益。这样，他们成立了 J/XFS 论坛 ― 一个由来自于所有五个公司的成员组成的社区（请参阅
参考资料）。J/XFS 论坛的目的是为银行应用程序设计 Java 中间件，定义能被所有参与的公司接受的 API。
半年之后，1999 年 3 月，系统设计和规范准备就绪。为了强调 J/XFS 的重要性，J/XFS 论坛决定发行这种 API，作为官方的开放标准。因此，1999 年 5 月，他们着眼于欧洲标准化体系，建立了 CEN 工作室（请参阅
参考资料）。选择欧洲标准化体系是因为最初的研究始于欧洲。尽管如此，J/XFS 仍是应用于全世界的标准。
1999 年 9 月此规范被认可，自 2000 年 3 月起即可从 J/XFS 论坛 Web 站点免费下载其实现。
自该标准的第一个版本发布以来，CEN 工作室不断改进和扩展这个规范。今年晚些时候，可能出现实现的更新版。更新版将反映近期的改动，包含在规范的第一版中遗漏的设备类型的支持。
|
|
标识符
每个使用 J/XFS 的 Java 应用程序都在 J/XFS 客户上运行。因为内核管理连接的 J/XFS 客户的列表，因此必须有识别它们的方法。J/XFS 使用被称为
配置键的标识符来区分多个 J/XFS 客户。 此外，多个 J/XFS 客户能够在一起组成逻辑单元。例如，可以将在一个特定的计算机上的所有 J/XFS 客户放进一个组。您必须将一个 J/XFS 客户正好分配到一个组。这些组的标识符被称为
工作站名。“工作站名+配置键”必须是用来识别 J/XFS 客户的唯一组合。
正如应用程序需要被唯一地识别，必须有方法来区分所配置的设备。J/XFS 对设备采用了与对应用程序一样的方法。 J/XFS 中的每一个设备必须刚好连接一个 J/XFS 客户，J/XFS 客户反过来作为 J/XFS 客户组的一部分，通过其工作站名进行识别。必须给每个设备分配一个 ID，此 ID 在有同一个工作站名的组内一定是唯一的。ID 被称为
设备名。这样在 J/XFS 环境中，再一次用“工作站名+设备名”识别一个设备。
请注意被分在一组（因为同一工作站名）的 J/XFS 客户没有必要在同一物理工作站。组的标识符以工作站名命名是因为这是最适合的目标之一。但是一个组能跨越一个以上的物理计算机。反之亦成立：在一个工作站上可能有多个组。如果听起来让您感到糊涂，只考虑一个 J/XFS 客户组一个工作站名的情况。
应用程序接口
从应用程序角度来看，您并不知道（因为也没有必要知道）任何与之进行通信的硬件的机器特定细节。您所要知道的只是将要使用的设备的
类型。J/XFS 标准为每一种支持的设备定义了一个 Java 接口。目前，J/XFS 标准包括下面几种设备类型的规范：
- 收据打印机、日志打印机、存折打印机、文档打印机、扫描仪
- 现金分配器、现金回收器、ATM
- PIN 小键盘
- 芯片卡阅读器、磁条卡阅读器
- 文本输入／输出设备
- 报警设备
- 库存单元
- 支票阅读器和扫描仪
- 传感器和指示器系统
- 摄像机
这些接口定义了它们所描述的设备类型的功能。设备实现由内核提供。这些类被称为
设备控件。一个设备控件代表应用程序内的一个设备，作为设备本身的句柄和代理。
将与设备相关的所有消息发送给设备控件，内核关心的是消息有没有到达实际的设备。对这些消息的响应 ― 在设备上执行的操作的结果，将作为事件向您报告。为了接收这种信息，必须注册适当的侦听器对象。
设备接口
在内核的另一端定义了单独的 API 来插入硬件，并且使得内核可以访问它。这个 API 完全独立于内核的应用程序接口，因此应用程序开发者没有必要知道关于它存在任何信息。 正如我前面提到的，为每一设备类型定义一个 Java 接口。内核使用这个接口来访问设备。这些接口的实现被称之为
设备服务。它们负责对硬件的兼容 J/XFS 的行为进行控制。设备服务与它们控制的硬件紧密结合在一起。因此，如果想在 J/XFS 中使用特定类型的硬件，必须为之提供兼容 J/XFS 的设备服务。
内核为设备服务提供了“纤细”的接口，允许将事件回送给应用程序。
通信层
内核内部可以使用任意一种需要的通信类型。J/XFS 定义了明确的接口，允许通信层完全地交换。新的通信类型通常由 J/XFS 内核开发小组开发并集成到内核中。
作为 J/XFS 应用程序或设备服务开发者，您没有必要知道使用中的实际通信类型。事实上，您可以在部署应用程序之后改变通信层，完成这些不用修改一行应用程序代码或设备服务代码。
当 J/XFS 进行通信时要考虑一种特殊情况：如果不需要或不可能在网络上分布 J/XFS 环境，可以选择在一台 Java 虚拟机上运行任何东西。在这种情况下，不必通过网络发送消息，但应用程序和设备服务必须仍能够彼此通信。
对于这种情况，J/XFS 标准定义了一种特殊的通信类型
local。这种通信类型实际上以它表现出的细微不同的行为来区别于所有其它类型。但是这些仅仅是比较小的差别；可以将这种 local 类型当作是没有网络和在虚拟机内部进行信息交换的通信。
图 3描绘了异步设备在 J/XFS 中的访问。此图表建立在图 1 所示的图表的基础上，添加了些到目前为止所描述不同的组件。
服务器端
J/XFS 是一个客户／服务器系统。由于这个原因，J/XFS 环境中一定要正好有一个 J/XFS 服务器。没有中央服务器 J/XFS 不能工作。这个 J/XFS 的核心组件也是内核的一个部件。J/XFS 服务器要完成三项主要任务：
- 所有 J/XFS 组件的持久存储
- J/XFS 环境的动态行为监视
- 管理任务和系统管理的访问点
配置服务器是持久数据在 J/XFS 环境中的首选的位置。它在对象库内为每一个应用程序和设备服务提供虚拟空间。运行时如果需要记住超出应用程序生存周期的信息，应该将其发送到 J/XFS 服务器以便持久存储。为了检索存储在该服务器的数据，必须提供唯一的键值（您能够记得的）。 所有的内核配置信息存储在配置服务器中。
当 J/XFS 客户启动时，将在 J/XFS 服务器宣布其可用性。J/XFS 服务器的
动态服务器部件收集此信息。而更重要的是关于可用的设备服务信息。设备服务一旦被成功地初始化和启动，它将使动态服务器知道这一信息，这样应用程序就可以为它请求设备控件且开始使用设备。J/XFS 服务器收集所有的这些信息。
J/XFS 服务器的第三个部件为叫做
监控器的东西。为了配置 J/XFS 环境或在运行时影响其行为，它为管理工具提供了接口。通过开发强大的监控器 API，这些工具具备了一些能力，例如：远程启动和停止设备服务、关闭 J/XFS 客户以及修改配置服务器库中的值。
客户端
在运行时，Java 应用程序代表一个 J/XFS 客户。为了能够访问 J/XFS 的基础结构，J/XFS 应用程序中必须做的第一件事是初始化
设备管理器。设备管理器是 J/XFS 客户应用程序的核心部件。它负责建立 J/XFS 环境以及在运行时管理所有与客户有关的管理任务。
从设备管理器获得
设备控件。将唯一的设备标识符（工作站名+设备名）告诉它，作为回应 ― 假设标识有效以及设备是可用的 ― 将得到设备控件。
如果不知道工作站名和设备名，可以请求设备管理器提供设备列表。获得不同种类设备的列表有多种方法，取决于所需的信息。例如，可以向设备管理器请求所有活动的设备列表、具有应用程序的工作站名的所有设备列表或者所有配置好的设备列表，不管它们是不是活动的。一旦有可用的工作站名和设备名，可以向设备管理器请求设备控件，并且用它开始工作。
每一个 J/XFS 客户还包含一个
日志记录器对象。可以发送所有的日志和跟踪这个对象的信息。侦听器对象可以向日志记录器进行注册，日志记录器发送日志并跟踪日志信息。为了减少实际的信息处理量，可以给日志记录器添加一个过滤器，这样侦听器只接收部分日志并只跟踪所关心的信息。这是一种很灵活的方法，因为可以编写自己的日志侦听器类，该类以您希望的方式处理信息。
实现：FDI for J/XFS
为了能够提供一些现成可用的组件（能够集成到目前的解决方案中），J/XFS 论坛选择实现 J/XFS 内核。这种产品被称为 J/XFS 的金融设备接口（FDI），可以从 J/XFS 论坛 Web 站点免费下载（请参阅
参考资料）。FDI for J/XFS 带有所有定义好的接口和类，它们是您现在开始使用 J/XFS 所需要的。此外，它的类库包含几种工具和支持类，帮助您使用 FDI for J/XFS 进行工作。
这些将在配置和管理过程中提供支持并帮助您了解此产品的工具如下：
-
基本配置工具（BCT）是一个简单的命令行工具，使您能够完成基本的配置和管理任务。例如，可以将配置信息发送给 J/XFS 服务器或者看一看当前可用的 J/XFS 客户列表。BCT 可以被交互地使用或者可以把BCT 命令列在文件中以便进行批处理。
-
日志服务器和相应的
日志侦听器可以用来在中央位置收集日志和跟踪来自多个 J/XFS 客户的信息。这些工具用 RMI 在网络上发送数据。
-
设备服务启动器是没有任何业务逻辑的单独的 J/XFS 应用程序。其唯一的目的是启动 J/XFSI 客户，因此可以远程访问与之相连的设备。
-
Melange demo是一个 J/XFS 应用程序样本，允许在 GUI 中执行所选设备的一些操作。其目的是帮助您熟悉 FDI for J/XFS 环境。使用这个工具需要有 Java 基础类库。FDI for J/XFS 提供了几个具有有限功能的设备服务样本，因此您可以操作一遍 Melange demo。实际上这些是模拟器，因为它们并不管理真正的硬件。Melange demo 和设备服务样本都提供了源代码，但它们决不希望被用作真正的设备服务的模板。
安装 FDI for J/XFS
迄今为止，对于 FDI for J/XFS 还没有自动安装过程或指导安装的工具。您需要手工地进行 FDI for J/XFS 的 1.01 版本的安装。为了安装 FDI for J/XFS，需要 Java 虚拟机 1.1.8 或更高的版本。如果您在 Java 2 平台上工作，对于该版本的 FDI for J/XFS，必须禁用安全性。100 MHz 工业标准的 PC 对于客户来说已经足够了；服务器需要至少 200 MHz。您要在 FDI for J/XFS 的文档中查找准确的最小要求（以及一个测试 FDI for J/XFS 所用到过的操作系统和相应的 Java 虚拟机的列表）。请注意这些只是对 FDI for J/XFS 的要求；您必须给它们添加您的应用程序的要求。
在下载了包含 FDI for J/XFS 的 zip 压缩文档之后，执行下面的步骤：
- 将 zip 压缩文档解压缩到您选择的目录，并阅读 readme.html 文件。该 zip 压缩文档包含 PDF 格式的附加文档和 HTML 格式的 API 文档。为了方便，API 文档打包到一个单独的压缩文档 ― jxfsapidoc1.01.zip 中。
- 使 Java 虚拟机能够访问 Java 压缩文档。您最可能要做的是通过将压缩文档的文件名添加到系统的 CLASSPATH 环境来完成。在客户机上，压缩文档是 jxfsclient1.01.jar；服务器的压缩文档名是 jxfsserver1.01.jar。
- 在服务器系统上创建新的空目录，该目录可以存放所有的持久数据。本例使用 /home/jxfs/repository 目录。
配置 FDI for J/XFS
配置 FDI for J/XFS 有点棘手，因此在进行配置之前请仔细阅读这一段的每一步。
安装客户和服务器
- 为每个 J/XFS 客户逻辑组选定一个唯一的工作站名。至少需要一个工作站名。本例使用
developerWorks作为工作站名。
- 在所分配的 J/XFS 客户的逻辑组内，为每一个客户选定一个唯一的配置键。本例客户使用配置键
jxfsClient，服务器使用
jxfsServer。
- 有两个地方要涉及到 TCP/IP 通信:客户和服务器之间以及客户与客户之间。它们中的每一处需要一个没有用到的 TCP/IP 端口号。如果一个 TCP/IP 主机上有多个 J/XFS 客户，用于客户到客户通信的 TCP/IP 端口号对于每一个客户来说必须是不同的。本例中客户／服务器通信使用端口 2323，J/XFS 客户间的通信使用端口 2424。区分 J/XFS 工作站名和 TCP/IP 主机名是很重要的。这两者是完全独立的，当然可以是相同的。
- J/XFS 服务器从简短的配置文件读取其配置信息。在 server.cfg 文件里提供了配置信息的骨架。可以在 zip 压缩文档解压缩到的目录中找到该文件。配置信息由键值对组成。编辑该文件，填入前几步建立的信息。
-
workstation_name ：指定给 J/XFS 服务器的工作站名。如前面所述，本例使用的是 developerWorks。
-
config_key ：J/XFS 服务器的配置键，本例为 jxfsServer。
-
sdm_addparm_1 ：用于 J/XFS 服务器和所有 J/XFS 客户之间通信的 TCP/IP 端口，这里是 2323。
-
sdm_addparm_2 ：是安装期间为 J/XFS 服务器创建的目录的位置：/home/jxfs/repository。
-
log_file_name ：启动 J/XFS 服务器期间，只要发生问题，就会写日志文件。提供服务器可以存放该文件的路径和文件名，比如：/var/log/jxfs/server.log。
- 剩下的值保持不变。请注意：在使用反斜杠作为路径分隔符的系统中，反斜杠必须用
\ 表示。
- 用
com.jxfs.forum.tools.serverstart.JxfsServer 启动 J/XFS 服务器，并提供文件 server.cfgand 的路径作为其参数。完成了这一步，J/XFS 环境就配置好了并且运行。
- 配置一些设备服务样本以供 Melange demo 使用。您可以用包含的 BCT 批处理文件（developerWorks.bct - 请参阅
参考资料）设置客户。在此之后，您必须在文件中替换
所有下面出现的字符串：
- <
device_port > 客户之间通信所选定的 TCP/IP 端口号，此次配置我们使用端口 2424。
- <
hostname > 客户所在的计算机的 TCP/IP 主机名。
配置 BCT
由于 developerWorks.bct 文件由 BCT 命令组成，只有配置过 BCT 才能使用。这又是一个带有键值对的属性文件。
-
workstation_name ：指定给 J/XFS 客户的工作站名。如前面所述，本例使用 developerWorks。
-
config_key ：BCT 的配置键；您可以将其设置为
BCT 。
-
sdm_addparm_1 和
mgmt_addparm_1 ：用于 J/XFS 服务器和所有 J/XFS 客户之间通信的 TCP/IP 端口。您将使用端口 2323 和 J/XFS 服务器所在计算机的 TCP/IP 主机名。请注意端口和主机名必须由分号隔开。
-
log_file_name ：BCT 中 J/XFS 客户启动期间，只要出现问题，就会写日志文件。提供服务器可以存放该文件的路径和文件名，比如：/var/log/jxfs/bct.log。
剩下的值再一次保持不变，请记住在使用反斜杠作为路径分隔符的系统中，反斜杠必须用
\ 表示。
因为 BCT 是系统管理工具，它没有存放在客户的 Java 压缩文档 jxfsclient1.01.jar，而是在服务器压缩文档 jxfsserver1.01.jar 中。使 jxfsserver1.01.jar 在 Java 环境中可用，并通过启动 Java 程序
com.jxfs.forum.tools.bct.BCT （以 BCT 批处理文件名作为参数）来启动 BCT，将配置信息发送给 J/XFS 服务器。请注意参数前必须冠以
@ 符号。如果批处理文件叫 developerWorks.bct BCT，您将以
@developerWorks.bct 作为参数提供给 BCT Java 程序。
Melange demo
最后，准备启动演示程序，Melange demo。我们将再一次使用属性文件来安装该程序。这一次骨架文件叫 demo.cfg。对其进行编辑，下面的键要使用恰当的值：
-
workstation_name ：指定给 J/XFS 客户的工作站名。本例使用 developerWorks。
-
config_key ：J/XFS 客户的配置键；这个示例选用 jxfsClient 作为它的值。
-
sdm_addparm_1 ：用于 J/XFS 服务器和所有 J/XFS 客户之间通信的 TCP/IP 端口。这里我们使用端口 2323 和 J/XFS 服务器所在计算机的 TCP/IP 主机名。请注意这两者必须由分号隔开。
-
log_file_name ：如前面提到的所有情况，在 J/XFS 客户启动期间，只要发生问题就会将写日志文件。提供服务器可以存放该文件的路径和文件名，比如：/var/log/jxfs/jxfsClient.log。
如果直到这一步您都是按照文章中的步骤进行安装，那么现在您可以自信地启动您的第一个 J/XFS 客户。Melange demo 不是 J/XFS 内核的部件，因此存储在一个单独的 Java 压缩文档（jxfsdemo1.01.jar）中。当您使得该压缩文档在 Java 环境中可用之后，您可以通过调用 Java 程序
com.jxfs.samples.application.MelangeDemo （将演示配置属性文件作为参数提供给它）来启动 Melange demo。请不要忘记使 Java 虚拟机能够访问 Java 基础类库（在 swingall.jar 文件中包含 Swing ）。
图 4 是 Melange demo 的图解。操作这个演示，来感觉一下 J/XFS。
图 4. 带有设备列表的 Melange demo
总结
这篇文章仅仅作为介绍，不可能涵盖 J/XFS 和 FDI for J/XFS 的各个方面。更多信息包含在放在 FDI for J/XFS 的 zip 压缩文档的文档中。建议您操作演示以及阅读有帮助的文档（
参考资料中介绍的）。该系列的第二部分是 J/XFS 框架下的设备服务开发的实作介绍，那么开始准备吧！
参考资料
关于作者 | | | Christoph Czernohous 德国的 Boeblingen 的 IBM 实验室的一名软件工程师。他为 J/XFS 论坛 FDI for J/XFS 实现核心部件，他还对几个涉及 J/XFS 的客户工程做出了突出贡献。您可以通过
cc@de.ibm.com与 Christoph 联系。
|
对本文的评价
| 
