ActiveXFS规范何去何从.doc

ActiveXFS规范何去何从?刘永胜 2005年于广州 ActiveXFS规范也是属于CEN(欧洲标准委员会)机构所管理的一个金融行业标准，很多做金融一行的人估计对它都不太了解。在2000-1-25号，由NCR、微软、Nexus软件公司（现已被Diebold收购）共同制定了ActiveXFS规范，定为1.0版，它由13个单独的文档组成，分别是Part1: ActiveXFS Common Object Interface Specification;Part2: ActiveXFS Card Reader Object Interface Specification;Part3: ActiveXFS Cash Dispenser Object Interface SpecificationPart4: ActiveXFS Depository Object Interface SpecificationPart5: ActiveXFS PINPad Object Interface SpecificationPart6: ActiveXFS Journal Printer Object Interface SpecificationPart7: ActiveXFS Receipt Printer Object Interface SpecificationPart8: ActiveXFS Document Printer Object Interface SpecificationPart9: ActiveXFS Passbook Printer Object Interface SpecificationPart10: ActiveXFS Sensors Doors and Indicators Object Interface SpecificationPart11: ActiveXFS Text Terminal Object Interface SpecificationPart12: ActiveXFS Night Saf Object Interface SpecificationPart13: ActiveXFS Printer Auxiliary Object Interface Specification，其中part1是一个总的概述，剩下的每份文档都对应一类ATM外设，比如part2对应着读卡器设备，大家可以从名字上看出到底对应着哪种设备。 ActiveXFS规范实际上是CEN/XFS(即WOSA/XFS)规范的附属品，它是CEN/XFS规范出来后应运而生的。如果你对CEN/XFS规范有所了解，就可以更好的理解为什么需要ActiveXFS规范了。 我们再重新简单回顾一下CEN/XFS(即WOSA/XFS)的软件架构。 ATMC上层-微软XFS Manager(3个dll文件)-厂商的硬件SP驱动程序 其中微软的XFS MANAGER做为ATMC上层与厂商SP硬件驱动程序之间的桥梁，是由微软公司开发出来的，可以免费使用。通过XFS MANAGER，销售ATM机器的厂商只需提供各个设备的SP驱动，ATMC上层完全可以运行的是另外一个厂家的程序，这就是现在ATM业常说的跨平台。 跨平台就是CEN/XFS当初提出来的目的了。但是，CEN/XFS规范有个问题，就是它从技术上来讲，是用C语言来实现的。我们知道，ATMC的上层应用程序有些公司是用C/C+来写的，它们可以直接调用微软的XFS MANAGER动态库；但有些公司的ATMC上层应用程序并不是用C/C+写的，可能用VB、DELPHI之类的快速开发工具，更流行的是基于IE浏览器HTML网页脚本的ATMC上层。这些ATMC上层要么直接调用微软的XFS MANAGER提供的C语言API(Application Program Interface)接口比较困难，要么基本上没法调用C语言的API接口，此时我们该怎么办呢？实际上，这种语言之间没法方便的互相调用的问题在整个软件行业也无处不在，此时，微软的ActiveX技术登场了。有关ActiveX技术，熟悉Windows平台的人都或多或少地知道，这里就不多说，我们只看看怎么利用ActiveX技术解决前面提到的问题。 我们将上面的软件架构图变一下，将“ATMC上层”再分成两层： ATMC业务逻辑层-ActiveX控件层-微软XFS Manager(3个dll文件)-厂商的硬件SP驱动程序 其中的ActiveX控件是由许多控件组成，一般一种硬件类型对应一个控件(例如CardReader.ocx对应着读卡器设备)，这些控件封装了与设备硬件相关的操作，对上层的“ATMC业务逻辑层”提供自动化接口。这样我们的ATMC程序就可以这样实现了，银行业务流程用HTML网页、VBScript/JScript脚本、VB等来编写，在VB、网页或脚本中直接调用ActiveX控件来操作硬件，让硬件进行相应的动作。这样就解决了CEN/XFS是基于C语言的弱点。 到这里，我们应该对“ActiveX控件层”的功能有所了解，现在存在另外一个问题。既然CEN/XFS规范定义了ATMC上层与硬件设备驱动之间的统一的软件接口，那么我们可不可以进一步，在上面的“ATMC业务逻辑层”和“ActiveX控件层”之间再定义一套统一的软件接口呢？例如，对于读卡器设备所对应的ActiveX控件CardReader.ocx来说，我们能否统一地定义好它的接口方法、属性、事件的名字，输入输出参数及返回值？ 这么多ATM设备，怎么定义每种设备的控件接口方法呢？不用我们来动脑筋了，这就是ActiveX规范做的事情了。 好，到此该我们重新定义一下什么是ActiveXFS规范了。ActiveXFS规范的目的是制定所有对应于ATM硬件外设的ActiveX控件的接口，通过这种方式，这些控件可以被快速开发工具(VB/DELPHI等)，包括脚本语言方便地使用。 其实，简单的说，就是一种设备一种ActiveX控件，每种控件对应一份ActiveXFS规范，指明该种控件的对外接口，该接口是基于微软的COM技术的IDL接口。 有了ActiveXFS规范，我们如果想将符合CEN/XFS规范的SP驱动程序封装成一个控件给ATMC上层用，就不需要再绞尽脑汁去想怎么定义接口方法，每个方法怎么定义参数，定义哪些事件，这些ActiveXFS规范都帮你想好了，你只需要按照ActiveXFS规范实现你的ActiveX控件即可。 我们回过头来看看，其实ActiveXFS规范最适合于那些用脚本、VB等技术编写ATMC上层的公司，因为它们需要这种技术，假如你的上层直接用C/C+编写，则不怎么需要，直接调用XFS MANAGER提供地API即可。再者，CEN/XFS规范可以达到ATMC上层程序和厂商硬件驱动分别由不同的公司编写，实现跨平台的目的。而反观ActiveXFS规范却没有什么太大的意义，它附属在CEN/XFS规范上，单单指望它也实现不了跨平台，所以自从ActiveXFS规范推出后，没有象CEN/XFS规范那样引起注意，只有少数的几家公司在使用它，大部分行业公司根本不知其为何物。 1.0版的ActiveXFS规范是按照CEN/XFS2.0规范编写的，现在CEN/XFS规范早已升级到3.0多了，而ActiveXFS规范因为响应的公司寥寥，也没有推出新的版本出来，其前途渺茫而又微妙。不过NCR公司做为ActiveX规范的拥护者，内部已经升级了ActiveXFS规范，并且已经在APTRA平台里面广泛使用，只是没有提交到CEN委员会做为标准而已。随着当初的Nexus公司被Diebold收购(个人觉得Nexus当初的人可能在公司收购后已经离开了Nexus，也就是离开了Diebold，也有可能被NCR请去了，导致技术含量大跌，Diebold估计就买了个源代码而已，没有了人，要源代码也没有什么用处)，微软已经不管金融外设这块，当初制定ActiveXFS规范时的三足鼎立，已经凋零到NCR一支独秀了，而ActiveXFS规范又