2004年被称为是Linux应用推广的开端之年。剖开历史巨大的横断面，诸多的Linux应用项目如繁星，开始隐隐出现在巨大的苍穹下。它们中的许多注定只是流星，划过天际，转眼消逝不见。但回溯历史，又有多少看似细微末节的小事件，却具有开启历史巨变的因果机缘。

       2004年年初，交通银行中国香港分行和高阳科技有限公司决定联合开发Linux前端系统，历时共8个月。这是国内银行业{dy}次在关键业务应用中大规模使用Linux平台。长期以来，大家对Linux是否适用于处理关键企业应用一直存有疑虑，国外也少有先例。Linux正处于一个发展的瓶颈，只有打开“应用”这个僵局，Linux才会像奔流之水，浩浩荡荡，蔓延开来。因此，这个项目具有很好的实验和示范效应。结合开发Linux前端系统的经验，我们将从架构设计和技术手段两个不同的角度来探讨Linux应用开发所面临的一些共性问题和解决办法。希望记录的这一点感悟与体会，不会被湮没在漫漫历史尘埃之中，而是为后来者贡献一点微光，照亮他们继续前行。

　　“可定制”前端VS“编程型”前端

　　银行是信息化开展最早的行业，传统的手工簿式记账早已被电脑所取代。走进任何一家银行网点，首先映入眼帘的，就是一排排电脑以及在电脑前忙碌的工作人员。这些部署在各营业网点或部门的电脑系统就称作银行网点前端系统，行内的人习惯称其为柜面系统。

　　前端系统完成的功能极其复杂，既包括对输入和输出的展示和控制，也包括外设驱动、数据校验、通讯和代码翻译等功能、还需要实现诸如现金箱管理、交易冲正、对账、报表打印、消息通知以及交易的复核、授权等业务功能。

　　Linux前端系统除了要满足上述功能之外，还把目标定位为一套“可定制”的前端系统，这有别于国内银行普遍采用的所谓“编程型前端”。

　　所谓编程型前端是指每一个交易都需要写一个前端程序。随着银行业务种类和业务复杂度的增加，这种前端系统的弊病就显露无疑了——程序人员不得不花费大量的时间来编写数目庞大的前端程序，而且一旦业务变化或者要新增功能，又需要重新修改调试程序，从而影响了整个银行电脑系统的稳定性和灵活性。

　　“可定制”的前端系统是指使用者不需要编写程序，利用前端系统的定制工具直接在电脑屏幕上设置输入画面和输出格式，同时定义好流程，一个交易的前端部分就完成了。这种前端系统的优点显而易见—灵活、易于扩展、维护方便。

　　上个世纪90年代后期，逐渐有公司开始研发这种产品化的前端系统，比较xx的有高阳的IFS，蓝天的OFP，以及韩国的Efinax和美国的S1 TELLER等系统。当然这些系统都运行在Windows或Unix平台上，在Linux上开发还没有先例。

　　旧系统：耶稣的十字架

　　企业应用开发，遇到的{dy}个问题就是如何实现与旧系统的兼容性。xx记载，耶稣罹难之时，背上的十字架承载了过去一切的罪孽与苦难。同样，旧系统也是任何新应用项目不得不背负的沉重十字架。开发企业应用软件不像平地起高楼，也不是在白纸上画{zx1}最美的图画，而是像旧城改造：要在一大片老城区中推倒一小块，重起新楼，但同时又要适应原有的规划布局，还要考虑道路的排列，地下管线的衔接。犹似建筑学上的{zg}境界，不仅要新颖独特，还要讲求和周围环境和谐统一。

　　银行前端系统只是庞大的银行IT网络中的神经末梢，必须与数据中心的各后台业务处理系统相配合，才能完成银行业务流程的处理。因此，替换前端系统就如同替换多米诺骨牌中的一张，同时又要保证其他骨牌不能倒掉。

　　比较传统和保险的做法是移植加改造。即尽量保留原来的程序架构不变，在这个基础上增加新的功能或修改原来的处理逻辑。但对需要迁移到Linux平台上的应用系统而言，这种方法不太可行，主要原因在于平台间的差异。相对于原来运行在Unix上的系统，Linux需要处理图形化的界面；相对于在Windows或OS/2上运行的系统，Linux又是类Unix的内核，在事件驱动和消息处理等机制上xx不同。因此，开发Linux前端系统只能另起炉灶，重新开始。但如何能将变化仅仅局限在系统内部，而不影响与其他业务系统的正确连接和整个IT架构的稳定呢？

　　方法一是采用快速原型法。先开发出一个满足接口要求的原型系统，重点在接口模块，系统内部则只需要实现框架功能。在这个原型系统的基础上不断测试和调整，使其能实现原系统的所有接口功能，可以与其他旧系统无缝衔接。预先解决接口问题后，就xx屏蔽掉了外部的影响，以后的设计就可以专注于系统的内部结构。

　　方法二是需要使用辅助工具进行大量的自动测试和验证。例如：港交行的业务系统共有34个子应用，2000多个交易，如果手工调试和测试每一个交易和功能点，工作量将会十分庞大。而且单靠人工，也无法进行xx的比对来确定系统运行的正确性。而通过我们开发的一套调试工具和自动测试工具，就可以自动完成输入数据的准备，模拟交易流程，校验输出结果等工作。

　　技术模式：向左转还是向右转？

　　Linux应用开发所面临的第二个问题通常是技术模式的选择。站在技术的十字路口，道路向两个方向延伸。一条路是采用浏览器模式（Browser/Server），另一条路是采用传统的C/S (Client/Server) 客户机模式，浏览器模式是如今比较流行和标准的架构，但C/S模式也有它的优势，二者各有千秋，向左转还是向右转？其实，正所谓水无常势，事无定规，一切皆取决于具体的业务需求和特点，不同的应用需要采用不同的路线。银行前端系统的特性决定了C/S之路更合适一些。

　　首先是前端系统对处理效率的要求高。浏览器模式走HTTP协议和使用Java，效率肯定比不上C++实现的C/S架构，而且C/S结构可以充分利用Client的处理能力，在Client层就对数据进行处理，不用全部提交到Server端，这样可以减少Server的负载和功能，使Server端具有很好的伸缩性，可以不囿于地域和行政架构的限制，部署在总分行到网点的任何一层，通讯模块则可以根据实际需求灵活配置。

　　其次，C/S模式对外设的处理比浏览器方便和强大许多，浏览器对外设的控制能力很弱，且不方便操作，而前端系统则会频繁使用打印机、密码键盘等外设。同时，采用C/S模式可以实现更灵活的处理，只需增加出口，就可以使前端系统更易于功能扩展。

　　当然，浏览器模式的一大好处是Client端不用维护。但只要有完善的自动化的版本维护工具，C/S模式下也可以解决这个问题。

　　积木和邮局

　　应用开发还必须解决的另一个大问题是采用何种系统结构，也就是如何划分系统的层次以及如何将程序模块组织在一起。对于一个由成百上千个程序组成的庞大应用系统，如果设计不好，其内部就会像蛛网一样，错综复杂，纠缠在一起，给系统的稳定性带来较大的隐患。

　　随着面向对象设计方法的流行，利用类的封装和继承特性，可以方便地建立积木式的模块结构，使各模块间具有清晰和简单的边界，并采用一致标准的外部接口。但要实现这种松耦合的组合方式，就必须有一个在模块间负责传递消息的枢纽，也就是实现一个类似“邮局”的功能。在Windows平台上，可以直接使用Windows的消息机制。但Linux本身则没有提供一个统一的异步消息调度机制，必须由应用实现该功能。因此，需要在应用层建立一个调度器（Dispatcher）和消息队列，其功能是实现一个抽象的“邮局”功能，根据各模块传来的消息类型和消息代码，把消息转发给相应的模块进行处理。

　　利用这种组件化的设计不仅使系统具备灵活、可组装的产品特性，而且有利于分组设计和编程。

　　同样，那些与具体业务相关的功能和特殊需求也应该与普通处理区分开来，放入独立的程序模块，通过动态库的形式挂接到系统中，从而保证核心的稳定性和整个系统的可扩展性。

　　双刃Linux

　　解决好设计阶段的几个基本问题之后，接下来就需要利用Linux的接口和环境开发应用程序。

　　Linux是一把双刃剑。

　　“开源”是Linux最锋利的刀刃。 “开源”使Linux能为大家所熟知和了解，在Linux上开发应用软件可以充分利用操作系统的特点和优势，避免各类软件陷阱，使应用软件不仅在效率上，而且在稳定性和安全性等许多方面都能够得到进一步提升。

　　同样，由于Linux具有非常灵活的配置特性，可以把Linux操作系统和应用软件打包做在一起，进行统一的版本升级、管理和维护。从而避免了由于操作系统和应用软件分离和不匹配而带来的维护上的困难。

　　还有，Linux拥有最广泛的硬件支持。利用这种特性，Linux前端系统实现了可以同时支持字符终端、普通PC和NC三种客户机模式。

　　但是，Linux的刀刃也有伤及自身的时候。Linux根植于深厚的黑客文化土壤之中，开源社区的黑客们习惯于单兵作战，而且喜欢从{zd2}层开始编码，但企业级的应用软件却需要大规模的协同开发，而且是尽量利用现有的函数库和类库来迅速构建应用。Windows之所以能占据99%以上的桌面系统市场，VB、DELPHI这样的快速开发工具功不可没。而Linux这十年来尽管赞誉很多，却始终未能得到迅速的推广和普及，其原因就是缺少像VB、DELPHI这样的集开发、调试、测试和管理于一体的IDE（集成开发环境）工具。

　　因此，进行Linux应用开发必须摈弃习惯的开发方法，尽量选择简单易用，并能实现协同工作的开发工具。2003年Borland公司推出了基于Linux的IDE工具软件Kylix。使用界面和类库与DELPHI和C++ BUILDER基本兼容。Kylix秉承了BORLAND公司其他产品一致的特点，简单、方便、快速，而且提供了强大的类库支持。根据我们使用的经验，使用Kylix开发应用软件比其他编程方法在效率上高两倍以上，而且工程质量也能得到大大提升。