.NET时代的ATM软件 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

熟悉微软的人都知道，微软的东西只有到了3.0版才可以使用。自从1999年这个软件巨人开始.NET的开发后，.NET到目前已经越过了3.0版，我们已经过了考虑是否学习.NET的时候，取而代之的是考虑什么时候开始全面转向.NET，显然这个时间是越快越好，并且是迫在眉睫的事情了。
     作为ATM行业来说，其向来是不会紧跟着整个软件行业层出不穷的新技术的，所以说ATM软件相对是比较保守的，一代代新技术的产生，总没有在ATM上马上投入使用。这次一样，到目前为止，暂时很少ATM软件转向.NET，仍然使用的是WIN32时代的东西，虽然这些东西还不会很快过时。如今已经是2005年，它离比尔盖茨在几年前指挥自己旗下的软件巨人全面转向.NET的时间已经有6年了。在摩尔定律的驱动下，6年无疑于沧海桑田，有多少事情已经在改变了。
     好了，是到了ATM软件全面转向.NET的时候了。如果你仍然在迟疑，那想必会很抱歉，因为你起步已经晚了。
     我们来回顾下在.NET之前的ATM软件是什么样子的。其实各个ATM软硬件厂商的软件架构大同小异，其结构从底层到上层一般如下：
     硬件－ 硬件驱动－ SP驱动－ XFS Manager管理器－ ActiveX控件－ 上层流程层
     稍微解释一下：硬件指ATM的机芯、读卡器等硬件；硬件驱动有些厂家没有，指直接封装硬件指令，提供API接口给上层用的驱动程序，一般为DLL形式；SP驱动指符合WOSA/XFS规范的SP；XFS Manager管理器指CEN提供的管理器；ActiveX控件主要是封装访问硬件、封装常用操作（比如操作注册表等功能）的控件，其目的是为了在VB、VBScript脚本语言等使用；上层流程可以用各种语言来编写，很多写成状态机形式，有个流程解析引擎来解析流程文件控制交易流程。
     总之，大部分的ATM软件与上面描述的差不多，通过上面的解释就基本知道目前的ATM软件是什么样子了。
     这些都是在WIN32时代的产物，形成目前的软件架构也是紧紧依赖着WIN32。可想而知，如果WIN32被抛弃了，这些ATM软件架构也就烟消云散了。
     
   ATM软件也到了该.NET出场的时候了，不管你愿不愿意，在今后的几年内将你的ATM软件改造到.NET平台下是避免不了的。不过还好，所以的技术最终都是一样的，你对ATM软件的投资也不会白白丢掉。只要你深入的掌握了软件技术，就会发现无论是.NET还是WIN32，都是一样的，就看你理解的怎样了。在我看来，软件技术根本就没有什么变化过，只是新瓶装旧酒而已，但是如果你没有深入的去领悟这些，你只会在层出不穷的新名词下望而生叹。
     既然ATM就要跨入.NET时代了，我们来看看.NET时代的ATM软件到底是什么样子。
     首先，整个ATM软件的架构变化不大，仍然从硬件到上层分为几个层次。在近几年内，XFS Manager仍然继续作为非托管代码运行在.NET平台上。SP仍然用基于C语言的接口，只是很多厂家会用VC.NET来开发，如果C++/CLI语言正式推出来后，也可能有很多人用它来开发SP。如果你喜欢，也可以仍然用VC6.0来开发，因为XFS Manager没有变化，即现有的SP可以保持基本不变。几年后，可能CEN会考虑将XFS Manager重新用.NET平台的技术实现，因为要用到.NET平台的许多功能，必须抛弃非托管代码的形式。那是，WOSA规范的SPI和API接口形式会发生变化，很可能直接以向.NET的FCL类库一样，直接以类接口形式提供。
     接着看看XFS Manager层下面的软件，SP和硬件驱动。因为.NET只是基于操作系统之上的，所以硬件是不会变化的。以前各个厂商的硬件都是提供串口形式的对外接口，随着USB技术的成熟和统一，各个厂商必然要将串口形式的接口转到USB接口形式。如果XFS Manager在近两年内保持为现在的非托管代码形式，则原有的硬件驱动程序和SP可以不用修改，只是将访问串口的操作改为访问USB而已。如果XFS Manager改到.NET平台下来，则很可能整个硬件驱动和SP都要重新写了。这个要看XFS Manager的接口改为什么形式，如果改为FCL那样的类库形式，则可能厂家会选择.NET的语言来开发SP和硬件驱动，比如C#等语言。因为毕竟SP驱动不是真正的Windows DDK开发的那种驱动，可以用C#来写的，不存在必须用C/C++这样直接操作硬件底层的语言来实现。
     然后来看看XFS Manager上面的软件。以前紧挨着XFS Manager的是ActiveX控件，针对这种技术，CEN还除了ActiveXFS规范出来过。不过这些已经要成为历史的名词。
     比尔盖茨早就看ActiveX不顺眼了，.NET就是ActiveX技术的集大成者，有了它，该彻底抛弃ActiveX技术了，因为ActiveX能够做的.NET正好拿手着。不过技术都是一样的，如果你深入的掌握了ActiveX和.NET，就会知道自己以前的技术投入并不会浪费，只是换汤不换药而已。如果ActiveX不用了用什么？不用担心，所有XFS Manager导出的API接口都会被厂家封装成继承于System.Object对象的类，上层业务流程直接使用这些类即可。原来的一个个ActiveX控件都用变成一个个类，软件是通过类来组装在一起的，这些类在各种语言之间无缝的连接在一起。你以前花很大力气写的各种控件基本该淘汰了，因为微软的FCL基本上达到你想要什么都有什么，如果没有，上网一搜索，想必也有人帮你完成了。
     上层流程开发起来就简单了，在Visual Studio 2005集成环境下面，想作出一个ATMC来，比以前简单多了。可能大多数的厂家将会选择微软钦定的C#语言来开发上层ATMC，如果以前用脚本的也会考虑是否该换一种思路了。下一版微软发表IE7，想必也有许多新的功能添加上去，那么ATM的画面就显得更加灵活好看了，因为ATM软件有关界面显示的模块基本都是封装了IE浏览器而已。
     至于ATMP，因为它们一般用的是UNIX平台，暂时是没有必要转向.NET，即使MONO在UNIX平台跳的再欢，想必也很少有人考虑将主机转向.NET平台。所以ATMP暂时会保持不变。
   到目前为止，全球几家大的ATM厂商已经先后完成了ATM软件向.NET的迁移，在保持其整个软件架构基本不变的情况下，重新将ActiveX控件层用C#等重新写过，上层的开发语言也都换成.NET平台的语言，各个封装模块（象封装屏幕显示的模块）也都用.NET平台的语言重新写过，以达到整个ATM软件的一致性。想必随着微软.NET操作系统的推出，各个ATM厂商马上就会将其雪藏的新ATM软件推出，以求在新一轮的IT技术下面跟上形式，将对手远远的抛在后面。
     .NET来了，你还在苦苦等待谁？
银行大部分系统是基于UNIX的，所以一般不会变化。对于客户端来说，很多是基于Windows的，微软已经基本停止WIN32的开发，全面转向.NET。
如果对.NET进行关注的话，就会知道.NET这个转变与当初从DOS转向WIN95是一样的，不是一个简单的跳跃。当然，现在还是有人在用DOS的，但更多的人在用Windows。
我也反对IT技术的频繁更新，但是如果象操作系统都变化了，那我们基于操作系统上的应用软件还能够逃离跟随的命运否？
毕竟操作系统底层掌握在别人手里，这也是无奈之举。银行大部分主机系统不需要更新，因为其不是跑在Windows上面的。