三、中间件TUXEDO的特点

    要组成三层应用体系结构少不了要求采用中间件。中间件可以说是开发服务程序和管理这些服务程序运行的工具，是三层体系结构中一个非常重要的部分，它直接关系到整个应用系统的好坏，甚至成功与失败。

    现在市场上的中间件很多，有TUXEDO、CICS，有基于CORBA的VisiBroker、M3，还有面向对象的JavaBean，中间件的选用很大程度上要看其成熟度。电信计费营帐系统是直接面向用户的应用系统，只许成功，不许失败。浙江联通公司选用中间件TUXEDO，也是基于成熟度及性能/价格比等方面的考虑。

    TUXEDO是BEA公司的非常成熟的产品，占有很大市场份额，它有以下特点：

    （1）支持全局事务管理，支持X/Open规范，支持全局的两阶段提交。

    （2）分布式应用管理，支持异构环境下的分布应用（如同一应用中有不同的数据库，多个数据源）。

    （3）平衡负载。有多台机器做应用服务器时，系统可自动根据每个机器的负载情况决定服务程序在负载小的那一台机器上执行。

    （4）进程管理。系统根据需要（客户端请求量）自动增加或减少每个Service的进程数（1个Service可启动n个相同的进程）。某个Service忙，则相应地增加（启动）其进程数；某个Service闲，则相应地减少（关闭）其进程数，从而减少该Service占用的系统资源（如：内存、数据库连接数等），使整个系统的Service最优化运行。

    （5）优先级管理。可将Service根据优先级的不同赋权值，系统根据优先级权值将客户请求（Service）排队管理。

    （6）路由管理。有多台机器做应用服务器时，用户可设定同一种事务（根据申请包中FML的某一个域）在不同的机器上执行。

    （7）权限控制、安全管理。包括两个方面：①服务端控制，可限制用户对应用程序的启动、关闭，限制用户在应用中建立服务程序。②限制客户端对应用程序的访问。可由专门的Service做安全验证。

    （8） 丰富的通信方式。有同步调用、异步调用、管道通信、会话、广播、通知、队列、发布订阅等通信方式，能很好地满足应用开发的要求。

    （9）可MP方式工作，多台应用服务器互相备份，实现其高可用性。

四、中间件在浙江联通计费营业帐务系统营业子系统中的实现

    浙江联通计费营帐系统三层体系中客户端程序用C++BUILDER，服务端（应用服务层）程序用Pro*c开发，中间件采用Bea公司的TUXEDO，数据库采用ORACLE8。

三层体系中客户端与服务端的通信是由TUXEDO的API函数实现，客户端由函数Tpinit与服务器建立连接，由函数Tpcall申请Service服务，再由相关的TUXEDO函数对数据解包。

    数据传输采用TUXEDO提供的非常灵活的FML方式实现客户端与服务端的数据交换。

    目前，浙江联通计费营帐系统中所有营业受理模块、除详细话单以外的查询模块均采用三层结构来实现。

    营业模块包括开户、话费收缴、改号、换/补卡、套餐变更以及营业数据的查询等，营业模块是用得相当频繁得模块（有300台客户机要同时实现25种服务），在将来高峰时将达到500多台，所以在本系统中首先采用三层结构来实现前台各种业务受理工作。

4.1 营业受理系统服务端

    在营业受理子系统中，根据前台业务的分类，我们将服务端的服务（SERVICE）分成三类：

    1．公共服务函数：提供诸如操作员登录、操作员权限控制、两台清方式的第一次提交确认、欠费校验、黑名单校验等。

    2．公共查询服务函数：应用ORACLE的动态SQL功能，完成客户端发出的各种查询请求。

    3．各业务提交函数：完成客户端各个业务（开户、改号……）的提交确认。

    根据这三类SERVICE的不同特点，需要三种不同的配置要求。

    服务程序之所以采用一个公用模块（程序），是因为业务受理涉及面广，几乎涉及所有数据库表，若每一种业务都做一个服务程序，则要做很多个服务程序。程序开发和维护量很大，系统扩展、管理不方便。且运行性能也受到较大的影响，因为每个服务程序至少启动一个进程，而有些进程由于业务上的原因会很少利用（运用）却占用了系统资源（如：内存、数据库连接数等）。

4.2 营业受理系统客户端

    客户端的开发主要有两个问题需要解决：

    1．如何实现营业前台庞杂多样的各种业务受理？

    2．如何既简单又统一的实现界面中控件与FML缓冲、FML缓冲与服务端的数据的一致和数据交换？

    对于第一个问题，我们应用面向对象技术，定义了一个C++ Builder虚类SaleManBase，SaleManBase类抽象出了一般业务的流程，同时给继承实现类又留有不同业务的实现接口。

    应用SaleManBase类，一般简单的业务（例如：改号、换卡等）只须在派生类中重载1至2个方法，添加10几行代码即可完成一个前台业务界面的编程。极大减轻了前台编程人员的负担，同时也简化了前台程序的管理和标准化。

    对于第二个问题，我们主要通过两个组件来解决；一个是FMLClient组件，用来实现前台界面与TUXEDO的FML缓冲之间的数据交换。一个是MemTable组件，用来实现界面上的数据敏感组件和FMLClient组件之间的接口。

    这样，通过这两个组件，编程人员就可以很容易的实现前台界面控件与TUXEDO服务端的通讯了。

    MemTable组件在系统中与界面数据敏感控件之间的关系，在定义MemTable中的字段名字时，我们人为规定了其与FML缓存中字段名一致。同时，我们又在FMLClient中定义了一组从MemTable中根据字段名取数据，和向MemTable中设置数据的方法；通过FMLClient提供的这一组方法，编程人员可以非常方便的保持界面控件和服务端数据的一致。

4.3 营业受理系统得安全措施

4.3.1 应用级

    客户端程序控制：从客户端进行业务受理必须输入密码（由用户设定）才能办理相关业务，如：用户资料更改、特服变更、改号、换卡等。

    服务端程序控制：客户端传过来的SQL语句必须是合理有序的。服务程序（Service）

    菜单访问控制：

    每个操作员的菜单都是由管理员授予的，因此，操作员对于未授权的菜单是看不到和不能操作的。

4.3.2 系统级

    数据库控制：用户帐号被授权对脚色（ROLE）进行存取，操作元的帐号不是数据库系统实际帐号而是应用程序帐号。

    TUXEDO控制：利用TUXEDO特性对客户端访问服务程序（Service）的权限进行控制，由专门的Service控制。

    五、展望

    大型数据库应用系统开发采用中间件已成为趋势，出于系统之间的良好接口和开放性考虑，中间件应选用基于面向对象的中间件，现在中间件面向对象的标准有：CORBA、COM、JavaBean等，其中CORBA（Common Object Request Broker Architecture）已为大多数厂商所接受。基于公用的面向对象标准的中间件，可简化异构环境下分布处理的复杂程度。对于多种分布式软件（如交易管理、负载平衡、Web主页、传统计算等），中间件减少了应用软件开发商的负担，使他们可以在跨越客户挑选的硬件、操作系统、网络、数据库管理系统和对象模型上建造分布式应用软件。

    目前基于CORBA开发出来的中间件对大多数企业而言过于复杂，不易使用。但随着基于CORBA的中间件技术的进一步发展与成熟，三层体系结构的应用系统采用基于CORBA的中间件将成为一种趋势。