1. BEA Tuxedo 产品介绍
BEA Tuxedo是一个非常开放的平台，支持七十多种服务器平台，BEA Tuxedo的商业版包括了支持绝大多数平台的版本，并且在所有平台上的API都是一致的，平台间的数据表示的差异由Tuxedo自动屏蔽，这也是Tuxedo的独到之处，极大地拓宽了用户对平台的选择范围。
构筑在Tuxedo系统之上的应用独立于计算机硬件、操作系统和数据库，将应用从一种开放平台移植到另一种开放平台，只需作应用程序的重新编译和极少的SQL语句的调整(不同数据库产品其SQL语法可能稍有不同)，应用系统就能顺畅地完成平台转移。为支持异构系统互联，Tuxedo允许用户在配置文件中设置机器类型，Tuxedo支持自动码集、位数及字节顺序的转换，Tuxedo屏蔽不同平台间的数据表示，不需要编程人员精通各种平台的数据表示差异，从而“自动地”完成异构系统的互联。开放系统的支持几乎所有的UNIX、NT 专有系统的支持，Tuxedo支持OS390，MVS 6.22及OS /400和Tandem 的NonStop系统。PC的支持：Tuxedo在客户端支持PC平台上的DOS、Windows,、Win 95、WinNT、OS/2、 Michintosh和所有的UNIX版本。
1.1. 支持的数据库管理系统
BEA Tuxedo所支持的数据库包括ORACLE、SYBASE、INGRES、INFORMIX、DB2等UNIX上的大型数据库和NT上的SQL Server，并且还支持C-ISAM文件系统。既可以通过 XA协议, 也可不用XA协议来和这些产品联接。(注：XA协议由Tuxedo首先提交给X/Open组织，作为资源管理器(数据库)与事务管理器的接口标准。Informix是最早宣布支持XA协议的数据库厂家，Informix5.0以上的版本都提供XA接口，以实现与Tuxedo的连接。目前，Oracle、Informix、DB2、Sybase等各大数据库厂家都提供对XA的支持。)
BEA Tuxedo不仅能通过XA协议保证交易中涉及的单个或多个同构的数据源的交易完整性, 而且还能通过XA协议的两阶段提交来保证异构平台上的异构数据源的交易完整性。当应用系统只有局部事务、没有全局事务时，Tuxedo直接利用数据库的事务处理功能，这样可提高系统性能。 分布式事务处理（DTP）能力能保证跨几个场地访问的数据和由不同数据库产品管理的数据的完整性。事务管理器协调分布式事务使之完成网络环境下针对异构数据库的多场地的修改。事务管理器用全局事务跟踪事务参与者，管理两阶段提交协议。这样就可以确保每个场地都能正确处理事务的提交和回退。事务管理器还在出现场地故障、网络故障或全局资源死锁时协调全局事务的恢复。事务管理器使用开放小组的X/Open XA接口，进行不同资源管 理器之间的通讯。该接口已被X/Open接纳为分布式事务控制的标准接口。
在Tuxedo应用系统的开发中，将存取不同数据源的操作封装在不同的服务请求(tpcall)中，并将所有需要保证交易完整性的不同服务请求放在ATMI事务处理函数tpbegin和tpcommit之间。BEA Tuxedo负责将数据存取操作提交给 正确的数据源并保证交易完整性。
通过BEA eLink for Mainframe SNA可以实现Tuxedo和主机上CICS之间的两阶段提交，BEA eLink for Mainframe SNA在SNA网上通过PU2.1和LU6.2直接与IBM主机上的IBM CICS实现互操作，在IBM系统上不需要安装任何BEA的软件。eLink for Mainframe SNA支持在BEA Tuxedo系统和IBM CICS系统之间的Sync Level 0, Sync Level 1或Sync Level 2连接。其中Sync Level 2支持在Tuxedo和CICS之间的两阶段提交。
1.2. 支持的编程语言和开发工具
BEA Tuxedo采用Client/Server方式的三层结构模式开发用户的应用系统。
BEA Tuxedo得到大量的第三方开发工具的支持，支持开发人员快速、简单地 开发Tuxedo的服务程序及客户程序。
在服务器端Tuxedo支持C、C++、COBOL语言。
在客户端Tuxedo支持几乎所有的编程语言和开发工具，只要这种语言或工具支持动态联接库DLL或支持C、COBOL的语言调用。其客户端通过DLL可以和Visual C++、Visual Basic、 Power Builder、SQL Windows、Delphi、 Develop/2000以及其他4GL和CASE工具互连。另外，通过BEA Jolt, 用户还 可用JAVA语言编写客户程序。
此外，BEA Tuxedo还得到其他第三方开发管理工具厂商的支持。
1.3. 支持的网络协议
Tuxedo提供对多种网络协议的支持，其中包括TCP/IP及IPX/SPX。
另外，通过BEA eLink可以实现对SNA、OSI/TP的支持。 BEA eLink for Mainframe SNA在SNA网上通过PU2.1 LU6.2直接与IBM主机上的IBM CICS实现互操作。BEA eLink OSI-TP扩展Tuxedo应用与OSI -TP协议间的接口，提供与 远程和OSI-TP兼容的系统到Tuxedo应用的透明通讯，使用X/Open的XATMI接 口函数访问另一个TP系统的服务，简化基于Tuxedo系统的应用开发。
在通讯链路方面，BEA Tuxedo可适应局域网、X.25、ISDN、专线、电话 拨号等多种通信链路。
1.4. BEA Tuxedo支持双机热备份、Cluster方式。
双机热备、Cluster方式可以从几个不同层次来看，首先是硬件层次，在这一层次上，服务器的硬件和操作系统软件和普通服务器的硬件及操作系统软件都有所不同，对数据库、中间件及其他应用软件的切换、备份或并行处理由硬件和操作系统完成，但相关软件和系统环境需要进行相应的配置，例如编写一些SCRIPT，BEA Tuxedo完全支持这种方式。例如，BEA Tuxedo运行在HP的Cluster服务器上时，HP提供了HA系统软件Service Guard，当Service Guard发现某个结点宕机后，即可在Master 结点上执行相应的SCRIPT，在备份结点启动相关的系统软件和Tuxedo的应用服务；若Service Guard发现Master 结点宕机，则在Backup Master执行Tuxedo的有关命令将Backup Master切换为管理主结点，并且将Master结点的应用服务迁移到备份结点。同时，BEA提供BEA Tuxedo HA Extension，它可以使工作进一步简化。
其次，数据库本身具有一些相应的功能，以在数据存储和检索处理等方面通过某种方式做到备份和并行处理，比如ORACLE的并行服务器OPS，BEA Tuxedo也支持这种方式，并和数据库通过XA实现无逢连接。
最后，是应用层次的双机热备、Cluster，这种方式也是成本最低、性价比最好、易用性和可维护性也最好的一种方式，对硬件和数据库要求都较低，BEA Tuxedo通过其独特的“虚拟主机”概念很好地实现了这种特性，虚拟主机可能涵盖了物理上的若干台服务器（在英国劳工局的应用实例中，多达1100台服务器构成了四台虚拟主机），应用根据用户的要求部署在各台服务器上，不同的服务器可以部署相同的服务也可以部署不同的服务，同时，这种部署的修改非常灵活方便，而且可以动态配置。在运行时，所有相关的调度和管理由Tuxedo来完成，对应用完全透明，做到应用层次的备份、Cluster。例如，利用BEA Tuxedo的Master结点和Backup Master结点构成双机系统，它们既可以运行相同的服务，也可以运行不同的服务并且互为备份，可以通过Tuxedo的管理命令把一台机器上的服务迁移到另外一台。同样利用BEA Tuxedo的Master和Backup Master以及虚拟主机概念，将相同或不同的服务部署到若干台机器，当某台机器出现问题时，可以把它上面的服务迁移到备份服务器。
Tuxedo管理的每个服务器上既可以部署同样的服务，也可以部署不同的服务，但不管怎样部署，所有服务的物理位置、请求的路由对客户程序都是透明的，服务器群对客户程序来看逻辑上就是一台机器（虚拟主机）。
BEA Tuxedo 在几个不同层次上都支持以上要求，用户可根据实际需要来选择不同方案。
1.5. BEA TUXEDO支持负载均衡
为了确保应用吞吐量最大，Tuxedo的事务管理器自动地在系统中完成动态负载平衡调度。用户根据每个服务请求的特点设置其负载因子的大小，Tuxedo通过使用每个服务请求的负载因子，累计在每个服务器的请求服务队列中的总计负载因子，事务管理器把请求发送给负载最小的服务器，从而使系统达到最快的处理速度。
Tuxedo有以下几种负载平衡的算法：
在同一机器中，将请求发向总负载最小的服务进程的请求队列。
在网络环境中，根据可动态改变的服务的负载因子及网络通讯的负载因子(由用户根据服务器的性能和网络情况设置)的变化情况，将请求发向总负载最小的机器中的服务进程的请求队列。
利用多服务进程单队列(MSSQ)机制，使多个服务进程能均匀地分担单一队列的请求。
利用数据依赖路由机制，根据请求数据的内容将请求分散到相应目标队列。
不做负荷平衡，由Tuxedo系统将请求发向第一个可用服务进程队列。
1.6. 支持动态伸缩
利用命令行或基于Web的图形管理界面， BEA Tuxedo可以动态的进行服务管理、负载均衡、数据依赖路由、网络用户的管理、队列的管理、存取资源管理器、增加可用资源，以及系统的启动、重启和恢复。
Tuxedo可根据系统负载的变化动态地增加或减少机器、服务进程组、服务进程和服务。
为提高系统处理能力，可以在现有系统上增加可用的服务数量，Tuxedo将可用的服务按组打包，在一台机器上可同时启动多个服务组，共同响应客户端的请求，从而使应用系统所提供的服务达到最大限度的可用性,充分利用系统资源。
用户可动态启动或停止某个服务；用户可使某些服务成为可用或不可用，当需要更新某个服务时，仅需停止旧的服务，然后重新启动更新后的服务，就完成了服务的更新，而不需要将关键业务全部停止。当增加新的服务时同样如此，这种动态调整的功能对于关键业务应用尤为重要。
Tuxedo支持“二维”的可伸缩性，它不仅可动态增加同类资源的个数来提高系统的性能和可用性,还可在系统中的任意位置动态增加不同机器、不同数据库、不同服务进程等异质资源，而不改变已存在的应用的结构。允许对一个复杂的混合结构的支持，为应用系统提供了广泛的选择范围。这一过程的完成不需要停止应用系统的运行，使应用系统的扩充在客户不知不觉中完成,即动态伸缩。同时任何与数据表示有关的问题（如不同的处理器表示）可以由Tuxedo透明地解决。
例如：在一个银行的应用系统中，原来以一台UNIX小型机处理300个营业网点的业务，当营业网点数增加至400个时，UNIX小型机可能不堪重负，这时甚至可以增加一台运行SCO UNIX的PC服务器，将UNIX小型机上的服务程序在PC服务器上 重新编译并运行，将网点号为301-400的营业网点的服务请求转移到PC服务器上 进行，PC服务器对数据库的操作通过XA协议完成，从而降低UNIX小型机上的负载， 小型机上的UNIX与SCO UNIX之间的平台差异由Tuxedo自动屏蔽。并且在这 一系统扩容的整个过程中，不需要停止原应用系统的正常运行。从而为应用系统的扩展提供了极大的灵活性和可能。
1.7. 支持数据依赖路由
BEA Tuxedo支持数据依赖路由。数据依赖型路由是根据数据缓冲区中一个指定域的值，把一个服务请求映射到一个指定的服务器组的机制。因为BEA Tuxedo服务器组映射成指定的资源管理 器/数据 库实 例，所以请求被导向到一个指定服务/资源管理器的组合。例如，一个银行的数据库可把存储在不同数据库实例中的不同范围的帐号进行水平分区。用户可用事务管理器进行路由选择，而不用把特定分区信息编码成访问帐号的应用代码。事实上，事务管理器查看指定的数据值，参考存储在BB中的路由信息，然后把请求发送到能在正确数据分区上操作的服务。如果用户需要改变数据库分区（把一个分区移到一个新服务器上，或在已有分区实例上改变帐号分布），那么，他只需改变事务管理器的路由信息，应用程序的代码不受影响。
1.8. 通讯
Tuxedo提供灵活多样的通讯机制，多达7种，既支持同步通讯又支持异步通讯，另外还支持对话、管道、队列、广播和事件发布/订阅方式。
（1）同步请求/回答方式
tpcall()
在同步请求/回答方式中，客户端使用tpcall()给本地或远程的服务器发送服务请求。此时客户将传送请求服务的名字、用于请求服务的输入参数和输出参数。tpcall()发出后，客户的数据被传送至服务器，得到相应的服务处理。在此方式下，服务器处理请求时，客户端将等待，不继续运行，直到服务器返回相应结果。
（2）异步请求/回答方式
tpacall()，tpgetrply()
在异步请求/回答方式中，客户端使用tpacall()给本地或远程的服务器发送服务请求，与同步方式不同的是：在此方式下，服务器处理请求时，客户继续运行。当客户端想得到请求的处理结果时，用tpgetrply()将结果取回。
（3）会话方式
tpconnect()，tpsend()， tprecv()， tpdiscon()
客户在建立了与服务的连接后，可以多次发送或接收数据，同时存储信息的上下文。Tuxedo采用的是半双工(half-duplex)的对话方式，这种方式特别适于 完成大数据量的数据传输。
（4）广播通知方式
tpbroadcast()， tpnotify()， tpchkunsol()，tpsetunsol()
由服务进程向客户进程以单个(tpnotify)或批量(tpbroadcast)方式发出的未经客户请求的广播或通知消息，客户可在适当的时候检查(tpchkunsol)是否收到通知消息并定义(tpsetunsol)收到消息后所采取的动作。
（5）管道方式
tpforward()
在BEA Tuxedo中，服务可被客户调用，也可被另一个服务调用，同时 Tuxedo提供另一种调用方式--管道方式：
服务进程在处理客户的请求时，不把结果返回给客户进程，而是把处理过的结果进一步转发给后续的其他服务进程，由其他服务进程接着处理，自己继续完成另外的服务请求，被转发的服务请求的结果由后续服务进程直接返回给客户进程，从而为编程和应用提供一种更加灵活的机制。
（6）队列方式
tpenqueue() ，tpdequeue()
Tuxedo提供一种可靠性的队列机制/Q ，将客户发出的请求用tpenqueue() 存储在可靠的队列中，由Tuxedo/Q从队列中将请求取出进行处理，完成各个队列中的服务请求。请求的入队和出队是异步的，并且具有事务特性。请求的出队次序可由用户设置为FIFO(先入先出)，LIFO(后入先出)，优先级，或定时执行。客户端可通过tpdequeue()取回处理结果。
（7）事件订阅方式
tpsubscribe() ，tppost()
用户进程可事先向系统订阅一些它所感兴趣的系统事件或用户自定义的应用程序事件，当系统或应用程序发生这些事件时，Tuxedo通知用户进程这些事件的发生，用户方可采取相应的动作。事件订阅机制使BEA Tuxedo的用户拥有 了独特的事件触发的功能，极大地方便了用户随时留意所订阅的系统或应用事件。
BEA Tuxedo支持应用间数据传递时的自动压缩，以减少网络上传输数据 的长度，提高系统性能。BEA Tuxedo采用的压缩技术可以使应用间传输的数 据量减少80%以上。
对此项功能的实现，只需要在Tuxedo服务器端的配置文件中进行相应的指定即可。
1.9. BEA Tuxedo支持多种数据类型和字段控制语言
网上数据的传输支持4种主要数据类型：
STRING：适用于可变长度的字符串。
CARRAY：适用于图象和声音数据的传输
VIEW：类似C的结构型变量，可同时包含多种数据类型
FML：字段控制语言,允许在同一个数据缓冲区内保存short、long、char、string、float、double和carray类型的变量。
除CARRAY类型的数据外，Tuxedo通过XDR 自动完成不同平台和不同编程语言的数据转换，其中FML类型的数据格式允许用户动态增加或减少其中某个或某些变量的个数。FML类型只保存有效数据，从而可节省内存并减少网络传输量。
1.10. 安全控制方式
BEA Tuxedo通过一个结构化的安全性接口提供应用服务的验证、授权和 访问控制。
BEA Tuxedo提供了下列五个递增的安全级别：
（1）无认证控制
当客户连接到应用时，不必进行身份认证。这个级别的典型用法是在应用开发阶段或物理环境具有安全保障的应用。
（2）应用口令
整个应用使用统一的口令。客户连接到应用时必须提供这个口令。这个安全级别可适用于按月或周获得新的口令。
（3）最终用户认证
除提供应用口令之外，客户必须提供用户名以及特定的应用数据(如口令)。这个安全级别允许应用设计者为应用设计特定的安全机制。
（4）可选访问控制(ACL)
客户程序必须提供应用口令、用户名和用户口令。采用访问控制表(ACL)可以控制用户对服务、应用队列、事件的访问。这个安全级别允许只对需要安全访问控制的资源进行访问授权配置。例如，可以对一组服务进行配置，使得对这组服务的访问进行控制，而访问其它服务则不受限制。当一个资源具有访问控制表时，不在访问控制表中的最终用户的访问将被拒绝。而成功地与应用建立连接的客户则可不受限制地访问无访问控制表的资源。
（5）强制访问控制(MANDATORY_ACL)
这个安全级别与可选访问控制表类似。客户必须提供应用口令、用户名和用户口令，主要差别是：对不具有访问控制表的资源的访问受约束，也就是说，不具有ACL的资源不能被访问。
1.11. 服务优先级的支持
BEA Tuxedo支持服务的优先级处理。
请求优先级是Tuxedo 的事务管理器提供的另一个核心能力。当某一服务有比 其他服务更高的优先级时，服务器在处理请求时，就不再单纯的按照请求在队列中的先后顺序处理，而是按优先级来决定。请求优先级越高的越早被处理。为了防止低优先级请求总是得不到服务，服务器每隔十个请求，就按FIFO次序进行一次请求选择。
典型的优先级应用例子是:银行的挂失操作应比其他操作具有更高的优先级。
1.12. 管理工具
（1）BEA Tuxedo提供以下几种管理工具：
Tuxedo提供一个基于普通WEB浏览器的管理工具，集中地监视和管理应用系统的运行，并且可动态地修改系统配置。利用普通的Web浏览器,比如 Netscape或Microsoft的Explorer，系统管理员通过Internet/Intranet，可在任何地方进行系统管理。
提供综合性的字符型管理命令。
可根据用户需要提供基于XWindow/Motif的GUI管理工具。
提供一个管理信息库(MIB)和编程接口，使用户可根据特定需求编写自己的管理工具。
Tuxedo的关联产品BEA Manager通过网络管理协议SNMP和Tuxedo的管理 信息库MIB可以把Tuxedo对应用程序的管理集成到一般的网络、数据库系统管理工具中，如OpenView,、NetView等。
Tuxedo 也提供了远程系统管理工具的支持，Tuxedo提供一个基于普通WEB浏览器的管理工具，集中地监视和管理应用系统的运行，并且可动态地修改系统配置。利用普通的Web浏览器，如Netscape或Microsoft的Explorer，系统管理员通过Internet/Intranet，可在任何地方进行系统管理。
（2） 管理API
BEA Tuxedo提供一个管理信息库(MIB)和编程接口（API），使得用户可根据特定需求编写自己的管理工具。
（3） 管理方式
Tuxedo的分布式应用由系统管理员集中式定义、集中式管理，管理员根据一个整体系统视图(而不仅是单个节点或单元)提供的信息，可以作出决定和采取动作。
（4） 动态配置
利用命令行或基于Web的图形管理界面，Tuxedo可以动态的进行服务管理、负载均衡、数据依赖路由、网络用户的管理、队列的管理、存取资源管理器、增加可用资源，以及系统的启动、重启和恢复。
Tuxedo可根据系统负载的变化动态地增加或减少机器、服务进程组和服务进程。用户可动态启动或停止某个服务；用户可使某些服务成为可用或不可用，当需要更新某个服务时，仅需停止旧的服务，然后重新启动更新后的服务，就完成了服务的更新，而不需要将关键业务全部停止。当增加新的服务时同样如此，这种动态调整的功能对于关键业务应用尤为重要。
（5） 日志文件
BEA Tuxedo提供各种日志，分别帮助用户根跟踪、分析、调试应用系统， 并在系统出现故障时作恢复处理。
Tuxedo提供动态跟踪日志，跟踪系统对ATMI的调用；提供应用服务级别的跟踪分析功能，帮助系统开发及管理人员分析应用的执行情况、找出性能的瓶颈；提供用户日志功能，使用户能按自己的需要记录必要的日志，或打印一些调试信息，系统管理员还可以从多种管理工具中检查用户日志，监督系统的安全运行；Tuxedo内部维护事务的日志，在系统出现故障时作必要的善后处理。
（6） 性能分析工具
Tuxedo提供系统性能分析工具，当设定监控系统运行时，Tuxedo以图表的方式显示指定时间段内指定的服务(或全部服务)的完成次数和平均响应时间，为系统管理员为每个服务指定负载和调整系统配置提供科学依据，并为业务人员分析业务情况提供帮助。
2. TUXEDO在邮政综合网中的应用研究案例之一:综合网交换平台与客户端程序的设计
2.1. 概述
客户端应用系统是相对邮政综合数据网信息交换系统的信息中心而言的，它包括一切要求接入信息交换系统，实现数据共享的应用系统。信息中心与客户端应用系统的接入主要有中心局生产作业系统的接入和电子化支局生产作业系统的接入两种。由于全国中心局所的数量很多,全国电子化支局所的数量更多，并且各地情况差别较大，所以这些平台在建设上各地存在很大的差异，将来会有各地开发的许多种应用系统平台在综合网上运行。为了确保这些应用系统平台能够有机地融入邮政综合计算机网，国家邮政局制定了一系列的标准和规范。关于电子化支局的包括电子化支局生产作业系统业务要求》、《电子化支局生产作业系统技术要求》、《邮区信息中心与电子化支局交换数据规范》、《邮区信息中心与电子化支局联网技术要求》等。这些规范为中心局生产作业系统和电子化支局生产作业系统的建设提供了统一的标准，为邮政信息中心信息交换系统全网数据有效、一致传输奠定了基础。
2.2. 客户端应用系统与信息交换系统的关系
信息中心信息交换处理系统是邮政综合网的一个重要组成部份，在整个综合网中处于信息传输枢纽地位。它为数据的表示、统一使用、统一传输提供一个完整的应用框架，为邮政综合网应用系统的建设建立一个统一的信息处理平台，实现各个应用系统在不同应用层次上的互联互操作，达到全网数据和应用共享的目的。
客户端应用系统是直接面向生产作业系统的。在生产作业过程中产生大量的数据，如果这些数据要和异地实现共享，就要将数据上传到本地信息中心，利用信息中心信息交换系统进行数据传输实现数据的交换，达到数据共享的目的。客户端应用系统在生产作业中需要异地应用系统平台数据时，先由异地应用系统平台将数据发送到其所属的信息中心，在由信息交换系统把数据上传本地信息中心，再由本地应用系统平台从本地信息中心下载所需要的数据。
客户端应用系统只与本地信息中心进行通讯。远程数据交换通过信息中心信息交换系统的信息中心间通讯完成。
2.3. 客户端应用系统与信息中心接入原理
客户端应用系统可以利用信息交换系统的客户端通讯平台，实现系统与信息中心的接入，也以开发内嵌API函数式的接入。这里以信息交换系统的客户端通讯平台为例说明客户端应用系统与信息中心信息交换系统接入原理。
客户端应用系统只需通过信息交换系统的客户端通讯平台，将要交换传输的数据（包括数据本身和相应的目的地及传输要求）交给信息交换处理系统的本地信息中心，信息交换处理系统负责将数据按传输要求传到目的信息中心，相应的目的客户端应用系统通过客户端通讯平台从目的信息中心取回数据。
信息中心有专门的服务来负责处理客户端应用系统发送数据和要求下载数据的请求。这些服务随时监听来自客户端接入系统的请求，收到请求后马上响应。客户端应用系统可以根据数据的流向，将信息中心可供调用的服务分为接收服务与发送服务二类：
数据接收服务：信息中心接收、处理客户端应用系统发送来的数据；
数据下载服务：为应用系统下载属于自己的数据提供服务。
信息交换系统的客户端通讯平台同样也具有两功能模块
数据发送模块：把客户端接入系统的数据按信息交换系统上传数据包的格式，打包后调用信息中心的数据接收服务将数据发送到本地信息中心；
数据接收模块：调用信息中心的数据下载服务，数据下载服务将属于该客户端应用系统的数据以数据包的形式下载到本地。数据接收模块再对数据包，进行解包，数据恢复等处理，最后把数据传给应用系统，供应用系统使用。
2.4. 应用系统接入原理
通信方式和通讯接口
客户端应用系统与信息中心交换系统网络通信协议采用TCP/IP，通信平台采用中间件。信息中心信息交换系统采用TUXEDO中间件，对底层通信协议有效屏蔽。客户端通讯平台只要调用TUXEDO的API函数即可实现与信息交换处理系统的通信。
客户端通讯平台仅配置中间件客户端通讯平台，所以它只能作客户端使用，没有服务的功能。因此，客户端通讯平台可以主动向交换系统发送数据，但交换系统不能主动向客户端通讯平台获取数据。同样客户端通讯平台为了接收数据，必须主动向交换系统发送接收数据请求，然后接收交换系统返回的数据。
应用系统需要定时向交换系统发送接收数据请求，以便及时接收数据。
2.5. 信息中心提供的功能
1) 普通数据传输
数据在源客户端应用系统打包上传到源信息中心；数据包通过信息交换系统传到目的信息中心；目的信息系统将数据回传目的应用系统。源客户端应用系统可以对数据的传输设置传输优先级、传输类型等控制项，以控制数据的传输。数据实现的是单向流动。
2) 批次传输/回执传输
信息中心信息交换系统内传输着许多重要数据，这些数据的发送方需要了解目的接收方接收数据的情况。这就要求数据接收方在接收数据后向数据发送方发送一种专用数据包，告诉发送方数据接收情况，这种数据包就是回执。回执数据包要有数据接收是否成功，数据接收的时间等信息。数据发送方从本地信息中心下载回执。分析回执，判断对方数据接收是否正确，据此作出相应处理。如:收到的回执正确，删除保存的原数据；收到的回执错误,重新发送原数据。数据实现的是两向流动。
2.6. 客户端通讯平台结构
客户端通讯平台具有四大功能：数据发送、数据接收、回执接收。
2.6.1. 数据发送
客户端通讯平台的发送功能主要完成：正常数据发送、断点续传、回执错误重发、重发断点续传，四大功能。
发送步骤如下：
1）开始；
2）读出配置；
3）连接数据库；
4）初始化TUXEDO中间件；
5）检查是否存在断点，如存在，则调用断点续传模块；
6）是否存在重发断点，如存在，则调用重发断点模块；
7）是否有回执错误需重发数据，有则调用回执错误重发模块；
8）调用正常数据发送；
9）断开数据库连接；
10）终止（Terminal）中间件TUXEDO；
11）结束。
2.6.1.1. 正常数据发送
正常发送是发送模块中最常用的功能。它按照从配置文件中读出的任务链表的要求从出口表中取出数据，打包上传到信息中心。上传数据以组为单位，每发送完一组向回执记录表（表名KH_T_RECEIPT）中记录一下本组信息。每发完一个数包在断点记录文件中记录一次发送情况。
2.6.1.2. 断点续传
断点是指一组数据在正常上传过程中，出现断电、系统问题等异常而形成的中断。在数据上传过程中我们随时记录数据的发送情况（记录断点）将发送情况写入断点文件。
在客户端通讯平台的发送模块重新启动时，读取断点文件。如发现未上传完毕的数据组，继续上传一组数据的剩余部分，这就是断点续传。
断点续传流程略
2.6.1.3. 回执错误重发
一组数据如果需要回执，客户端平台在正常数据发送结束后把该组数据信息要写入回执记录表中。当回执接收处理模块接收到该组数据的回执后，会对回执进行处理。如果需要重发，回执接收处理模块会在回执记录表中查找与之相对应的记录中的重发字段置成重发状态。
回执错误重发模块启动后，首先扫描回执记录表，当发现重发字段置成重发状态的记录后，恢复该记录对应那组数据信息并重发，然后删除该记录。
重发时组号，传输时间，流水号等都要重新生成。
任何一组最多重发3次，在回执记录表中有一个记录重发次数的字段，当重发次数大于3时删除记录并且删除该组对应的出口表中的数据。
回执错误重发流程图略。
2.6.2. 接收功能
客户端通讯平台的接收功能也是由正常数据接收和断点续传，两大功能组成。
接收步骤如下：
1）开始；
2）连接数据库；
3）初始化TUXEDO中间件；
4）检查是否存在断点，如存在，则调用断点续传模块；
5）调用正常数据接收模块；
6）断开数据库连接；
7）终止（Terminal）中间件TUXEDO；
8）结束。
2.6.2.1. 正常数据接收
数据接收原理：
客户端通讯平台主动向信息中心发送包含自己接入系统ID的请求；
信息中心在接到请求后将目的接入系统与之相同的数据回传给客户端通讯平台；
客户端通讯平台处理信息中心回传来的数据，将数据还原到入口表中。
客户端通讯平台发请求：
客户端通讯平台给信息中心的下载请求有二种：
数据组查询请求：向信息中心查询是否有属于自己的数据组。信息返回信息包括有或没有数据组等待下载，如果有数据还包括一组数据的有关信息。
数据包下载请求：向信息中心要求下载某一数据包的请求。
步骤及流程：
客户端通讯平台接收一组数据时，首先下载这一组数据的所有数据包，对包头进行处理，包体存入以二进制形式打开临时数据文件data.tmp中；然后再对包体进行解析，将数据还原到入口表中。
接收一组数据流程：
从数据组查询返回信息中得到一组数据的相关信息。然后根据这些信息向信息中心发送下载数据包的请求，从一组的第一个数据包开始，到最后一个数据包结束，按顺序下载数据包。每下载完一个数据包写一次断点文件，记录下载情况。下载的数据只对数据包的包头进行解析，包体存入data.tmp文件中。全部包下载完毕后，从新从data.tmp中取出数据，解析包体，从包头解析信息找到入口表表名，把从包体中解析出的数据插入相应的入口表。
接收多组数据流程：
如信息中心有多组数据等待下载，可以重复发送数据组查询请求，调用下载一组数据模块。直到信息中心返回无数据下载为止。
2.6.2.2. 断点续传
接收时的断点是客户端通讯平台在向信息中心发送下载数据包请求，接收数据包时忽然中断，而形成的断点。这种断点记录记录了正在下载的组的属性，以及中断时正在下载第几个数据包。
断点续传时首先读取断点记录文件，然后根据读取的信息恢复断点，继续接收剩余数据包。接收断点续传流程略。
2.6.3. 接收处理回执
回执下载方法：
客户端通讯平台向信息中心发送接收回执请求，信息中心返回一个回执数据包或通知客户端通讯平台没有要下载的回执数据。一个客户端通讯平台接收的回执，应该是由自己发送的数据返回的回执。在KH_T_RECEIPT中应有与其对应的记录，如果没有与之相对的记录这个回执就是错误回执。回执数据包中有一项叫作回执码，它表示数据接收方是否正确接收数据，以及出错误原因。接收处理回执模块对不同回执码的回执有不同的处理方法。
回执码：000 数据表正确 删除出口表中组号与回执包内源组号相同的记录；
回执码：001 数据表格式错 写错误日志
回执码：R01 第一个数据项错 重发(将回执记录表表中记录的重发字段，置成重发状态，由数据发送模块负责重发)
3. TXUEDO在邮政综合网中的应用研究案例之二:集中处理的电子化支局营业系统
3.1. 概述
目前电子化支局系统大多采用C/S局域网模式，这种模式适用于广域网连接条件较差的地区，网络化程度较低，数据存储比较分散，不易于统一管理和统计分析，不能实时向领导和业务部门提供决策依据。
随着邮政综合计算机网建设的完成和电子化支局工程的实施，各市县的网络环境得到了相应的改善，广域网下的集中处理模式也越来越引起邮政系统的重视。BEA TUXEDO 为中国邮政购买的中间件产品，电子化支局工程即基于此平台，在其上构建邮政电子化支局的应用系统，将能够满足网络环境比较好的市县数据集中的需要。
3.2. 系统方案论证
目前数据库的体系结构有客户/服务器模式、三层的客户服务器模式、基于浏览器的B/S体系结构。以下结合集中处理的电子化支局系统对几种模式进行比较分析，以选择适合的体系结构。
(一)客户/服务器模式
在客户/服务器模式下，客户端即数据库应用的用户接口层与业务规则层，负责提供用户与数据库交互的界面，向数据库服务器提交用户请求并接收来自数据库服务器的信息，并执行应用逻辑要求。服务器即数据库层，它由支持应用的底层数据库引擎组成，它的责任是保持数据库的完整性，也可以使用数据库提供的存储过程等完成部分或全部交易逻辑。
客户/服务器模式的特点是胖客户，客户端承担了过于繁重的任务，这种模式导致PC的配置较高，而且客户端应用的维护相当麻烦，所有的客户端都直接连接访问数据库，使得系统的安全性差，以单一服务器和局域网为中心，系统难以扩展，难以管理大量客户机。所以客户/服务器模式适用于局域网下的小规模的数据库应用系统。
（二）三层体系结构
三层体系结构在逻辑上可以分为三层：用户接口层、业务规则层、数据库层。其中用户接口层负责图形用户接口（GUI）逻辑的设计，业务规则层实现业务规则和应用逻辑，数据库层利用数据库自身的特点保证数据的完整性和一致性。 其中业务规则层可以基于现有的中间件产品平台来实现，如邮政电子汇兑系统采用了BEA 的TUXEDO 产品。三层体结构的特点是：可跨平台操作；减少整个系统的成本；维护升级十分方便； 具有良好的开放性和易扩充性； 进行严密的安全管理； 支持负载均衡；系统管理简单，可支持异种数据库，有很高的可用性。
（三）B/S结构
B/S结构即：浏览器——Web服务器——数据库服务器的三层结构。浏览器与WEB服务器之间通过HTTP协议来实现信息的存储和传递，利用URL来实现客户端的浏览器与Web服务器的资源建立连接，达到用户对服务器资源的透明访问。
特点：该模式中应用程序、数据库以及一些资源组件都集中在服务器端，客户端只需安装浏览器，无须其他辅助软件和相关的维护管理工作，使得维护起来非常容易，适用于局域网和广域网。
比较：
集中处理的电子化支局系统基于广域网结构，网点台席多达300多个，网络带宽没有很好的保障，不适合采用客户/服务器结构；B/S结构尽管维护简单，适合于广域网的应用，但由于中国邮政电子汇兑系统采用了基于TUXEDO 中间件的三层结构，B/S方式的电子化支局系统很难与三层模式的电子汇兑系统融合在一起。为此我们决定采用三层结构，使用BEA的TUXEDO 作为中间层的应用平台。 系统结构图如下：
3.3. 设计与实现
集中处理的电子化支局处理系统三层体系中客户端程序使用DELPHI开发，应用服务层程序用Pro*c开发，数据库采用ORACLE8。
由于采用三层体系结构后，将应用逻辑独立于界面显示，只要制定应用服务与界面之间的接口规范即可开始各个独立的开发，使得界面的开发与应用服务器的开发可以非常独立地进行。
三层体系中客户端与服务端的通信是由TUXEDO的API函数实现，客户端由函数Tpinit与服务器建立连接，由函数Tpcall申请Service服务，再由相关的TUXEDO函数对数据解包，进行相应的业务逻辑处理。
根据业务的分类，我们将服务端的服务分成以下几类：
1、 管理类服务：提供系统机构的增加、营业员的管理、营业员登录等等服务。
2、 资费维护类服务：提供营业中各种资费信息的维护。
3、 结帐类服务：提供台席结帐、全局结帐、个人业务量统计的功能。
4、 收寄类服务：提供函包速递国际等收寄业务的处理。
5、 内部处理类服务：提供封发时的清单路单制作等功能。
3.4. 编写TUXEDO SERVER 时考虑的几点问题
3.4.1. TUXEDO SERVER 与SERVICE 的组织
TUXEDO SERVER的结构是每个SERVER中包含若干个SERVICE，客户端与调用特定的SERVICE 。一般情况下，应该将业务处理复杂的SERVICE 与简单的SERVICE 组织到一个SERVER中，以便平衡系统的性能。在我们的案例中，我们按业务的应用组织的SERVER，如包裹 、函件、速递、内部处理等等。每个SERVER包含5个或6个SERVICE，而其中只有一、两个SERVICE 是经常被调用的，从而保证了系统的运行性能。
3.4.2. 与数据库的连接方式
与数据库的连接方式有两种：基于XA 的连接方式及采用数据库提供的连接方式。XA是一个标准化的接口，可以用于不同数据库之间的互联，可以用于异地保证数据库的事务处理的完整性。 大型的数据库如ORACLE SYBASE INFORMIX 等均支持XA的接口。TUXEO 也提供了通过XA访问数据库的API，可以很方便的进行事务控制，但是访问速度稍慢。
在我们的案例中，只访问一种数据库即ORACLE 数据库，所以我们采用了ORACLE 提供的连接方式，在每个访问数据库的SERVER启动时与ORACLE 建立连接。在每个访问数据库的SERVER 关闭时断开连接。
3.4.3. 报文的数据类型
在第一部分中讲述了TUXEDO提供了多种数据类型，如STRING CARRAY FML VIEW 等。其中FML类型的数据格式允许用户动态增加或减少其中某个或某些变量的个数。FML类型只保存有效数据，从而可节省内存并减少网络传输量。但是使用FML 类型要求在客户端和服务端相对应地定义，这影响了客户端与服务端的独立性，例如在电子汇兑中，服务端由华腾公司编写，客户端可以自行开发，使用FML 缓冲区会比较麻烦。我们也考虑到这一点，由于CAARAY能够传输机器0，而STRING不可以传输机器0，所以我们采用了CARRAY 作为报文传输的类型。
3.4.4. 客户与服务之间的通讯方式
客户与服务之间的通讯方式有很多种，如同步方式、异步方式、事件通知、队列方式。队列方式用于可靠的数据传递，在省际之间的报刊传输数据系统中使用了队列方式，在我们的系统中，应用的性质是实时的在线业务处理，使用同步方式（tpcall）即可。
3.4.5. 公共服务请求代理的使用
公共服务请求代理是做一个SERVER，其中包含一个SERVICE，该SERVICE完成统一的报文验证功能，由该SERVICE再调用其他的SERVICE 。这种方式使得客户端只需调用统一的SERVICE，简化了客户端的编程。
3.4.6. 配置文件中参数的调整
TUXEDO配置文件对于系统的性能至关重要的。某些参数的调整只能靠不断的进行测试来优化。如每个应用SERVER启动的个数，监听进程的启动个数等等
BEA Tuxedo是一个非常开放的平台，支持七十多种服务器平台，BEA Tuxedo的商业版包括了支持绝大多数平台的版本，并且在所有平台上的API都是一致的，平台间的数据表示的差异由Tuxedo自动屏蔽，这也是Tuxedo的独到之处，极大地拓宽了用户对平台的选择范围。
构筑在Tuxedo系统之上的应用独立于计算机硬件、操作系统和数据库，将应用从一种开放平台移植到另一种开放平台，只需作应用程序的重新编译和极少的SQL语句的调整(不同数据库产品其SQL语法可能稍有不同)，应用系统就能顺畅地完成平台转移。为支持异构系统互联，Tuxedo允许用户在配置文件中设置机器类型，Tuxedo支持自动码集、位数及字节顺序的转换，Tuxedo屏蔽不同平台间的数据表示，不需要编程人员精通各种平台的数据表示差异，从而“自动地”完成异构系统的互联。开放系统的支持几乎所有的UNIX、NT 专有系统的支持，Tuxedo支持OS390，MVS 6.22及OS /400和Tandem 的NonStop系统。PC的支持：Tuxedo在客户端支持PC平台上的DOS、Windows,、Win 95、WinNT、OS/2、 Michintosh和所有的UNIX版本。
1.1. 支持的数据库管理系统
BEA Tuxedo所支持的数据库包括ORACLE、SYBASE、INGRES、INFORMIX、DB2等UNIX上的大型数据库和NT上的SQL Server，并且还支持C-ISAM文件系统。既可以通过 XA协议, 也可不用XA协议来和这些产品联接。(注：XA协议由Tuxedo首先提交给X/Open组织，作为资源管理器(数据库)与事务管理器的接口标准。Informix是最早宣布支持XA协议的数据库厂家，Informix5.0以上的版本都提供XA接口，以实现与Tuxedo的连接。目前，Oracle、Informix、DB2、Sybase等各大数据库厂家都提供对XA的支持。)
BEA Tuxedo不仅能通过XA协议保证交易中涉及的单个或多个同构的数据源的交易完整性, 而且还能通过XA协议的两阶段提交来保证异构平台上的异构数据源的交易完整性。当应用系统只有局部事务、没有全局事务时，Tuxedo直接利用数据库的事务处理功能，这样可提高系统性能。 分布式事务处理（DTP）能力能保证跨几个场地访问的数据和由不同数据库产品管理的数据的完整性。事务管理器协调分布式事务使之完成网络环境下针对异构数据库的多场地的修改。事务管理器用全局事务跟踪事务参与者，管理两阶段提交协议。这样就可以确保每个场地都能正确处理事务的提交和回退。事务管理器还在出现场地故障、网络故障或全局资源死锁时协调全局事务的恢复。事务管理器使用开放小组的X/Open XA接口，进行不同资源管 理器之间的通讯。该接口已被X/Open接纳为分布式事务控制的标准接口。
在Tuxedo应用系统的开发中，将存取不同数据源的操作封装在不同的服务请求(tpcall)中，并将所有需要保证交易完整性的不同服务请求放在ATMI事务处理函数tpbegin和tpcommit之间。BEA Tuxedo负责将数据存取操作提交给 正确的数据源并保证交易完整性。
通过BEA eLink for Mainframe SNA可以实现Tuxedo和主机上CICS之间的两阶段提交，BEA eLink for Mainframe SNA在SNA网上通过PU2.1和LU6.2直接与IBM主机上的IBM CICS实现互操作，在IBM系统上不需要安装任何BEA的软件。eLink for Mainframe SNA支持在BEA Tuxedo系统和IBM CICS系统之间的Sync Level 0, Sync Level 1或Sync Level 2连接。其中Sync Level 2支持在Tuxedo和CICS之间的两阶段提交。
1.2. 支持的编程语言和开发工具
BEA Tuxedo采用Client/Server方式的三层结构模式开发用户的应用系统。
BEA Tuxedo得到大量的第三方开发工具的支持，支持开发人员快速、简单地 开发Tuxedo的服务程序及客户程序。
在服务器端Tuxedo支持C、C++、COBOL语言。
在客户端Tuxedo支持几乎所有的编程语言和开发工具，只要这种语言或工具支持动态联接库DLL或支持C、COBOL的语言调用。其客户端通过DLL可以和Visual C++、Visual Basic、 Power Builder、SQL Windows、Delphi、 Develop/2000以及其他4GL和CASE工具互连。另外，通过BEA Jolt, 用户还 可用JAVA语言编写客户程序。
此外，BEA Tuxedo还得到其他第三方开发管理工具厂商的支持。
1.3. 支持的网络协议
Tuxedo提供对多种网络协议的支持，其中包括TCP/IP及IPX/SPX。
另外，通过BEA eLink可以实现对SNA、OSI/TP的支持。 BEA eLink for Mainframe SNA在SNA网上通过PU2.1 LU6.2直接与IBM主机上的IBM CICS实现互操作。BEA eLink OSI-TP扩展Tuxedo应用与OSI -TP协议间的接口，提供与 远程和OSI-TP兼容的系统到Tuxedo应用的透明通讯，使用X/Open的XATMI接 口函数访问另一个TP系统的服务，简化基于Tuxedo系统的应用开发。
在通讯链路方面，BEA Tuxedo可适应局域网、X.25、ISDN、专线、电话 拨号等多种通信链路。
1.4. BEA Tuxedo支持双机热备份、Cluster方式。
双机热备、Cluster方式可以从几个不同层次来看，首先是硬件层次，在这一层次上，服务器的硬件和操作系统软件和普通服务器的硬件及操作系统软件都有所不同，对数据库、中间件及其他应用软件的切换、备份或并行处理由硬件和操作系统完成，但相关软件和系统环境需要进行相应的配置，例如编写一些SCRIPT，BEA Tuxedo完全支持这种方式。例如，BEA Tuxedo运行在HP的Cluster服务器上时，HP提供了HA系统软件Service Guard，当Service Guard发现某个结点宕机后，即可在Master 结点上执行相应的SCRIPT，在备份结点启动相关的系统软件和Tuxedo的应用服务；若Service Guard发现Master 结点宕机，则在Backup Master执行Tuxedo的有关命令将Backup Master切换为管理主结点，并且将Master结点的应用服务迁移到备份结点。同时，BEA提供BEA Tuxedo HA Extension，它可以使工作进一步简化。
其次，数据库本身具有一些相应的功能，以在数据存储和检索处理等方面通过某种方式做到备份和并行处理，比如ORACLE的并行服务器OPS，BEA Tuxedo也支持这种方式，并和数据库通过XA实现无逢连接。
最后，是应用层次的双机热备、Cluster，这种方式也是成本最低、性价比最好、易用性和可维护性也最好的一种方式，对硬件和数据库要求都较低，BEA Tuxedo通过其独特的“虚拟主机”概念很好地实现了这种特性，虚拟主机可能涵盖了物理上的若干台服务器（在英国劳工局的应用实例中，多达1100台服务器构成了四台虚拟主机），应用根据用户的要求部署在各台服务器上，不同的服务器可以部署相同的服务也可以部署不同的服务，同时，这种部署的修改非常灵活方便，而且可以动态配置。在运行时，所有相关的调度和管理由Tuxedo来完成，对应用完全透明，做到应用层次的备份、Cluster。例如，利用BEA Tuxedo的Master结点和Backup Master结点构成双机系统，它们既可以运行相同的服务，也可以运行不同的服务并且互为备份，可以通过Tuxedo的管理命令把一台机器上的服务迁移到另外一台。同样利用BEA Tuxedo的Master和Backup Master以及虚拟主机概念，将相同或不同的服务部署到若干台机器，当某台机器出现问题时，可以把它上面的服务迁移到备份服务器。
Tuxedo管理的每个服务器上既可以部署同样的服务，也可以部署不同的服务，但不管怎样部署，所有服务的物理位置、请求的路由对客户程序都是透明的，服务器群对客户程序来看逻辑上就是一台机器（虚拟主机）。
BEA Tuxedo 在几个不同层次上都支持以上要求，用户可根据实际需要来选择不同方案。
1.5. BEA TUXEDO支持负载均衡
为了确保应用吞吐量最大，Tuxedo的事务管理器自动地在系统中完成动态负载平衡调度。用户根据每个服务请求的特点设置其负载因子的大小，Tuxedo通过使用每个服务请求的负载因子，累计在每个服务器的请求服务队列中的总计负载因子，事务管理器把请求发送给负载最小的服务器，从而使系统达到最快的处理速度。
Tuxedo有以下几种负载平衡的算法：
在同一机器中，将请求发向总负载最小的服务进程的请求队列。
在网络环境中，根据可动态改变的服务的负载因子及网络通讯的负载因子(由用户根据服务器的性能和网络情况设置)的变化情况，将请求发向总负载最小的机器中的服务进程的请求队列。
利用多服务进程单队列(MSSQ)机制，使多个服务进程能均匀地分担单一队列的请求。
利用数据依赖路由机制，根据请求数据的内容将请求分散到相应目标队列。
不做负荷平衡，由Tuxedo系统将请求发向第一个可用服务进程队列。
1.6. 支持动态伸缩
利用命令行或基于Web的图形管理界面， BEA Tuxedo可以动态的进行服务管理、负载均衡、数据依赖路由、网络用户的管理、队列的管理、存取资源管理器、增加可用资源，以及系统的启动、重启和恢复。
Tuxedo可根据系统负载的变化动态地增加或减少机器、服务进程组、服务进程和服务。
为提高系统处理能力，可以在现有系统上增加可用的服务数量，Tuxedo将可用的服务按组打包，在一台机器上可同时启动多个服务组，共同响应客户端的请求，从而使应用系统所提供的服务达到最大限度的可用性,充分利用系统资源。
用户可动态启动或停止某个服务；用户可使某些服务成为可用或不可用，当需要更新某个服务时，仅需停止旧的服务，然后重新启动更新后的服务，就完成了服务的更新，而不需要将关键业务全部停止。当增加新的服务时同样如此，这种动态调整的功能对于关键业务应用尤为重要。
Tuxedo支持“二维”的可伸缩性，它不仅可动态增加同类资源的个数来提高系统的性能和可用性,还可在系统中的任意位置动态增加不同机器、不同数据库、不同服务进程等异质资源，而不改变已存在的应用的结构。允许对一个复杂的混合结构的支持，为应用系统提供了广泛的选择范围。这一过程的完成不需要停止应用系统的运行，使应用系统的扩充在客户不知不觉中完成,即动态伸缩。同时任何与数据表示有关的问题（如不同的处理器表示）可以由Tuxedo透明地解决。
例如：在一个银行的应用系统中，原来以一台UNIX小型机处理300个营业网点的业务，当营业网点数增加至400个时，UNIX小型机可能不堪重负，这时甚至可以增加一台运行SCO UNIX的PC服务器，将UNIX小型机上的服务程序在PC服务器上 重新编译并运行，将网点号为301-400的营业网点的服务请求转移到PC服务器上 进行，PC服务器对数据库的操作通过XA协议完成，从而降低UNIX小型机上的负载， 小型机上的UNIX与SCO UNIX之间的平台差异由Tuxedo自动屏蔽。并且在这 一系统扩容的整个过程中，不需要停止原应用系统的正常运行。从而为应用系统的扩展提供了极大的灵活性和可能。
1.7. 支持数据依赖路由
BEA Tuxedo支持数据依赖路由。数据依赖型路由是根据数据缓冲区中一个指定域的值，把一个服务请求映射到一个指定的服务器组的机制。因为BEA Tuxedo服务器组映射成指定的资源管理 器/数据 库实 例，所以请求被导向到一个指定服务/资源管理器的组合。例如，一个银行的数据库可把存储在不同数据库实例中的不同范围的帐号进行水平分区。用户可用事务管理器进行路由选择，而不用把特定分区信息编码成访问帐号的应用代码。事实上，事务管理器查看指定的数据值，参考存储在BB中的路由信息，然后把请求发送到能在正确数据分区上操作的服务。如果用户需要改变数据库分区（把一个分区移到一个新服务器上，或在已有分区实例上改变帐号分布），那么，他只需改变事务管理器的路由信息，应用程序的代码不受影响。
1.8. 通讯
Tuxedo提供灵活多样的通讯机制，多达7种，既支持同步通讯又支持异步通讯，另外还支持对话、管道、队列、广播和事件发布/订阅方式。
（1）同步请求/回答方式
tpcall()
在同步请求/回答方式中，客户端使用tpcall()给本地或远程的服务器发送服务请求。此时客户将传送请求服务的名字、用于请求服务的输入参数和输出参数。tpcall()发出后，客户的数据被传送至服务器，得到相应的服务处理。在此方式下，服务器处理请求时，客户端将等待，不继续运行，直到服务器返回相应结果。
（2）异步请求/回答方式
tpacall()，tpgetrply()
在异步请求/回答方式中，客户端使用tpacall()给本地或远程的服务器发送服务请求，与同步方式不同的是：在此方式下，服务器处理请求时，客户继续运行。当客户端想得到请求的处理结果时，用tpgetrply()将结果取回。
（3）会话方式
tpconnect()，tpsend()， tprecv()， tpdiscon()
客户在建立了与服务的连接后，可以多次发送或接收数据，同时存储信息的上下文。Tuxedo采用的是半双工(half-duplex)的对话方式，这种方式特别适于 完成大数据量的数据传输。
（4）广播通知方式
tpbroadcast()， tpnotify()， tpchkunsol()，tpsetunsol()
由服务进程向客户进程以单个(tpnotify)或批量(tpbroadcast)方式发出的未经客户请求的广播或通知消息，客户可在适当的时候检查(tpchkunsol)是否收到通知消息并定义(tpsetunsol)收到消息后所采取的动作。
（5）管道方式
tpforward()
在BEA Tuxedo中，服务可被客户调用，也可被另一个服务调用，同时 Tuxedo提供另一种调用方式--管道方式：
服务进程在处理客户的请求时，不把结果返回给客户进程，而是把处理过的结果进一步转发给后续的其他服务进程，由其他服务进程接着处理，自己继续完成另外的服务请求，被转发的服务请求的结果由后续服务进程直接返回给客户进程，从而为编程和应用提供一种更加灵活的机制。
（6）队列方式
tpenqueue() ，tpdequeue()
Tuxedo提供一种可靠性的队列机制/Q ，将客户发出的请求用tpenqueue() 存储在可靠的队列中，由Tuxedo/Q从队列中将请求取出进行处理，完成各个队列中的服务请求。请求的入队和出队是异步的，并且具有事务特性。请求的出队次序可由用户设置为FIFO(先入先出)，LIFO(后入先出)，优先级，或定时执行。客户端可通过tpdequeue()取回处理结果。
（7）事件订阅方式
tpsubscribe() ，tppost()
用户进程可事先向系统订阅一些它所感兴趣的系统事件或用户自定义的应用程序事件，当系统或应用程序发生这些事件时，Tuxedo通知用户进程这些事件的发生，用户方可采取相应的动作。事件订阅机制使BEA Tuxedo的用户拥有 了独特的事件触发的功能，极大地方便了用户随时留意所订阅的系统或应用事件。
BEA Tuxedo支持应用间数据传递时的自动压缩，以减少网络上传输数据 的长度，提高系统性能。BEA Tuxedo采用的压缩技术可以使应用间传输的数 据量减少80%以上。
对此项功能的实现，只需要在Tuxedo服务器端的配置文件中进行相应的指定即可。
1.9. BEA Tuxedo支持多种数据类型和字段控制语言
网上数据的传输支持4种主要数据类型：
STRING：适用于可变长度的字符串。
CARRAY：适用于图象和声音数据的传输
VIEW：类似C的结构型变量，可同时包含多种数据类型
FML：字段控制语言,允许在同一个数据缓冲区内保存short、long、char、string、float、double和carray类型的变量。
除CARRAY类型的数据外，Tuxedo通过XDR 自动完成不同平台和不同编程语言的数据转换，其中FML类型的数据格式允许用户动态增加或减少其中某个或某些变量的个数。FML类型只保存有效数据，从而可节省内存并减少网络传输量。
1.10. 安全控制方式
BEA Tuxedo通过一个结构化的安全性接口提供应用服务的验证、授权和 访问控制。
BEA Tuxedo提供了下列五个递增的安全级别：
（1）无认证控制
当客户连接到应用时，不必进行身份认证。这个级别的典型用法是在应用开发阶段或物理环境具有安全保障的应用。
（2）应用口令
整个应用使用统一的口令。客户连接到应用时必须提供这个口令。这个安全级别可适用于按月或周获得新的口令。
（3）最终用户认证
除提供应用口令之外，客户必须提供用户名以及特定的应用数据(如口令)。这个安全级别允许应用设计者为应用设计特定的安全机制。
（4）可选访问控制(ACL)
客户程序必须提供应用口令、用户名和用户口令。采用访问控制表(ACL)可以控制用户对服务、应用队列、事件的访问。这个安全级别允许只对需要安全访问控制的资源进行访问授权配置。例如，可以对一组服务进行配置，使得对这组服务的访问进行控制，而访问其它服务则不受限制。当一个资源具有访问控制表时，不在访问控制表中的最终用户的访问将被拒绝。而成功地与应用建立连接的客户则可不受限制地访问无访问控制表的资源。
（5）强制访问控制(MANDATORY_ACL)
这个安全级别与可选访问控制表类似。客户必须提供应用口令、用户名和用户口令，主要差别是：对不具有访问控制表的资源的访问受约束，也就是说，不具有ACL的资源不能被访问。
1.11. 服务优先级的支持
BEA Tuxedo支持服务的优先级处理。
请求优先级是Tuxedo 的事务管理器提供的另一个核心能力。当某一服务有比 其他服务更高的优先级时，服务器在处理请求时，就不再单纯的按照请求在队列中的先后顺序处理，而是按优先级来决定。请求优先级越高的越早被处理。为了防止低优先级请求总是得不到服务，服务器每隔十个请求，就按FIFO次序进行一次请求选择。
典型的优先级应用例子是:银行的挂失操作应比其他操作具有更高的优先级。
1.12. 管理工具
（1）BEA Tuxedo提供以下几种管理工具：
Tuxedo提供一个基于普通WEB浏览器的管理工具，集中地监视和管理应用系统的运行，并且可动态地修改系统配置。利用普通的Web浏览器,比如 Netscape或Microsoft的Explorer，系统管理员通过Internet/Intranet，可在任何地方进行系统管理。
提供综合性的字符型管理命令。
可根据用户需要提供基于XWindow/Motif的GUI管理工具。
提供一个管理信息库(MIB)和编程接口，使用户可根据特定需求编写自己的管理工具。
Tuxedo的关联产品BEA Manager通过网络管理协议SNMP和Tuxedo的管理 信息库MIB可以把Tuxedo对应用程序的管理集成到一般的网络、数据库系统管理工具中，如OpenView,、NetView等。
Tuxedo 也提供了远程系统管理工具的支持，Tuxedo提供一个基于普通WEB浏览器的管理工具，集中地监视和管理应用系统的运行，并且可动态地修改系统配置。利用普通的Web浏览器，如Netscape或Microsoft的Explorer，系统管理员通过Internet/Intranet，可在任何地方进行系统管理。
（2） 管理API
BEA Tuxedo提供一个管理信息库(MIB)和编程接口（API），使得用户可根据特定需求编写自己的管理工具。
（3） 管理方式
Tuxedo的分布式应用由系统管理员集中式定义、集中式管理，管理员根据一个整体系统视图(而不仅是单个节点或单元)提供的信息，可以作出决定和采取动作。
（4） 动态配置
利用命令行或基于Web的图形管理界面，Tuxedo可以动态的进行服务管理、负载均衡、数据依赖路由、网络用户的管理、队列的管理、存取资源管理器、增加可用资源，以及系统的启动、重启和恢复。
Tuxedo可根据系统负载的变化动态地增加或减少机器、服务进程组和服务进程。用户可动态启动或停止某个服务；用户可使某些服务成为可用或不可用，当需要更新某个服务时，仅需停止旧的服务，然后重新启动更新后的服务，就完成了服务的更新，而不需要将关键业务全部停止。当增加新的服务时同样如此，这种动态调整的功能对于关键业务应用尤为重要。
（5） 日志文件
BEA Tuxedo提供各种日志，分别帮助用户根跟踪、分析、调试应用系统， 并在系统出现故障时作恢复处理。
Tuxedo提供动态跟踪日志，跟踪系统对ATMI的调用；提供应用服务级别的跟踪分析功能，帮助系统开发及管理人员分析应用的执行情况、找出性能的瓶颈；提供用户日志功能，使用户能按自己的需要记录必要的日志，或打印一些调试信息，系统管理员还可以从多种管理工具中检查用户日志，监督系统的安全运行；Tuxedo内部维护事务的日志，在系统出现故障时作必要的善后处理。
（6） 性能分析工具
Tuxedo提供系统性能分析工具，当设定监控系统运行时，Tuxedo以图表的方式显示指定时间段内指定的服务(或全部服务)的完成次数和平均响应时间，为系统管理员为每个服务指定负载和调整系统配置提供科学依据，并为业务人员分析业务情况提供帮助。
2. TUXEDO在邮政综合网中的应用研究案例之一:综合网交换平台与客户端程序的设计
2.1. 概述
客户端应用系统是相对邮政综合数据网信息交换系统的信息中心而言的，它包括一切要求接入信息交换系统，实现数据共享的应用系统。信息中心与客户端应用系统的接入主要有中心局生产作业系统的接入和电子化支局生产作业系统的接入两种。由于全国中心局所的数量很多,全国电子化支局所的数量更多，并且各地情况差别较大，所以这些平台在建设上各地存在很大的差异，将来会有各地开发的许多种应用系统平台在综合网上运行。为了确保这些应用系统平台能够有机地融入邮政综合计算机网，国家邮政局制定了一系列的标准和规范。关于电子化支局的包括电子化支局生产作业系统业务要求》、《电子化支局生产作业系统技术要求》、《邮区信息中心与电子化支局交换数据规范》、《邮区信息中心与电子化支局联网技术要求》等。这些规范为中心局生产作业系统和电子化支局生产作业系统的建设提供了统一的标准，为邮政信息中心信息交换系统全网数据有效、一致传输奠定了基础。
2.2. 客户端应用系统与信息交换系统的关系
信息中心信息交换处理系统是邮政综合网的一个重要组成部份，在整个综合网中处于信息传输枢纽地位。它为数据的表示、统一使用、统一传输提供一个完整的应用框架，为邮政综合网应用系统的建设建立一个统一的信息处理平台，实现各个应用系统在不同应用层次上的互联互操作，达到全网数据和应用共享的目的。
客户端应用系统是直接面向生产作业系统的。在生产作业过程中产生大量的数据，如果这些数据要和异地实现共享，就要将数据上传到本地信息中心，利用信息中心信息交换系统进行数据传输实现数据的交换，达到数据共享的目的。客户端应用系统在生产作业中需要异地应用系统平台数据时，先由异地应用系统平台将数据发送到其所属的信息中心，在由信息交换系统把数据上传本地信息中心，再由本地应用系统平台从本地信息中心下载所需要的数据。
客户端应用系统只与本地信息中心进行通讯。远程数据交换通过信息中心信息交换系统的信息中心间通讯完成。
2.3. 客户端应用系统与信息中心接入原理
客户端应用系统可以利用信息交换系统的客户端通讯平台，实现系统与信息中心的接入，也以开发内嵌API函数式的接入。这里以信息交换系统的客户端通讯平台为例说明客户端应用系统与信息中心信息交换系统接入原理。
客户端应用系统只需通过信息交换系统的客户端通讯平台，将要交换传输的数据（包括数据本身和相应的目的地及传输要求）交给信息交换处理系统的本地信息中心，信息交换处理系统负责将数据按传输要求传到目的信息中心，相应的目的客户端应用系统通过客户端通讯平台从目的信息中心取回数据。
信息中心有专门的服务来负责处理客户端应用系统发送数据和要求下载数据的请求。这些服务随时监听来自客户端接入系统的请求，收到请求后马上响应。客户端应用系统可以根据数据的流向，将信息中心可供调用的服务分为接收服务与发送服务二类：
数据接收服务：信息中心接收、处理客户端应用系统发送来的数据；
数据下载服务：为应用系统下载属于自己的数据提供服务。
信息交换系统的客户端通讯平台同样也具有两功能模块
数据发送模块：把客户端接入系统的数据按信息交换系统上传数据包的格式，打包后调用信息中心的数据接收服务将数据发送到本地信息中心；
数据接收模块：调用信息中心的数据下载服务，数据下载服务将属于该客户端应用系统的数据以数据包的形式下载到本地。数据接收模块再对数据包，进行解包，数据恢复等处理，最后把数据传给应用系统，供应用系统使用。
2.4. 应用系统接入原理
通信方式和通讯接口
客户端应用系统与信息中心交换系统网络通信协议采用TCP/IP，通信平台采用中间件。信息中心信息交换系统采用TUXEDO中间件，对底层通信协议有效屏蔽。客户端通讯平台只要调用TUXEDO的API函数即可实现与信息交换处理系统的通信。
客户端通讯平台仅配置中间件客户端通讯平台，所以它只能作客户端使用，没有服务的功能。因此，客户端通讯平台可以主动向交换系统发送数据，但交换系统不能主动向客户端通讯平台获取数据。同样客户端通讯平台为了接收数据，必须主动向交换系统发送接收数据请求，然后接收交换系统返回的数据。
应用系统需要定时向交换系统发送接收数据请求，以便及时接收数据。
2.5. 信息中心提供的功能
1) 普通数据传输
数据在源客户端应用系统打包上传到源信息中心；数据包通过信息交换系统传到目的信息中心；目的信息系统将数据回传目的应用系统。源客户端应用系统可以对数据的传输设置传输优先级、传输类型等控制项，以控制数据的传输。数据实现的是单向流动。
2) 批次传输/回执传输
信息中心信息交换系统内传输着许多重要数据，这些数据的发送方需要了解目的接收方接收数据的情况。这就要求数据接收方在接收数据后向数据发送方发送一种专用数据包，告诉发送方数据接收情况，这种数据包就是回执。回执数据包要有数据接收是否成功，数据接收的时间等信息。数据发送方从本地信息中心下载回执。分析回执，判断对方数据接收是否正确，据此作出相应处理。如:收到的回执正确，删除保存的原数据；收到的回执错误,重新发送原数据。数据实现的是两向流动。
2.6. 客户端通讯平台结构
客户端通讯平台具有四大功能：数据发送、数据接收、回执接收。
2.6.1. 数据发送
客户端通讯平台的发送功能主要完成：正常数据发送、断点续传、回执错误重发、重发断点续传，四大功能。
发送步骤如下：
1）开始；
2）读出配置；
3）连接数据库；
4）初始化TUXEDO中间件；
5）检查是否存在断点，如存在，则调用断点续传模块；
6）是否存在重发断点，如存在，则调用重发断点模块；
7）是否有回执错误需重发数据，有则调用回执错误重发模块；
8）调用正常数据发送；
9）断开数据库连接；
10）终止（Terminal）中间件TUXEDO；
11）结束。
2.6.1.1. 正常数据发送
正常发送是发送模块中最常用的功能。它按照从配置文件中读出的任务链表的要求从出口表中取出数据，打包上传到信息中心。上传数据以组为单位，每发送完一组向回执记录表（表名KH_T_RECEIPT）中记录一下本组信息。每发完一个数包在断点记录文件中记录一次发送情况。
2.6.1.2. 断点续传
断点是指一组数据在正常上传过程中，出现断电、系统问题等异常而形成的中断。在数据上传过程中我们随时记录数据的发送情况（记录断点）将发送情况写入断点文件。
在客户端通讯平台的发送模块重新启动时，读取断点文件。如发现未上传完毕的数据组，继续上传一组数据的剩余部分，这就是断点续传。
断点续传流程略
2.6.1.3. 回执错误重发
一组数据如果需要回执，客户端平台在正常数据发送结束后把该组数据信息要写入回执记录表中。当回执接收处理模块接收到该组数据的回执后，会对回执进行处理。如果需要重发，回执接收处理模块会在回执记录表中查找与之相对应的记录中的重发字段置成重发状态。
回执错误重发模块启动后，首先扫描回执记录表，当发现重发字段置成重发状态的记录后，恢复该记录对应那组数据信息并重发，然后删除该记录。
重发时组号，传输时间，流水号等都要重新生成。
任何一组最多重发3次，在回执记录表中有一个记录重发次数的字段，当重发次数大于3时删除记录并且删除该组对应的出口表中的数据。
回执错误重发流程图略。
2.6.2. 接收功能
客户端通讯平台的接收功能也是由正常数据接收和断点续传，两大功能组成。
接收步骤如下：
1）开始；
2）连接数据库；
3）初始化TUXEDO中间件；
4）检查是否存在断点，如存在，则调用断点续传模块；
5）调用正常数据接收模块；
6）断开数据库连接；
7）终止（Terminal）中间件TUXEDO；
8）结束。
2.6.2.1. 正常数据接收
数据接收原理：
客户端通讯平台主动向信息中心发送包含自己接入系统ID的请求；
信息中心在接到请求后将目的接入系统与之相同的数据回传给客户端通讯平台；
客户端通讯平台处理信息中心回传来的数据，将数据还原到入口表中。
客户端通讯平台发请求：
客户端通讯平台给信息中心的下载请求有二种：
数据组查询请求：向信息中心查询是否有属于自己的数据组。信息返回信息包括有或没有数据组等待下载，如果有数据还包括一组数据的有关信息。
数据包下载请求：向信息中心要求下载某一数据包的请求。
步骤及流程：
客户端通讯平台接收一组数据时，首先下载这一组数据的所有数据包，对包头进行处理，包体存入以二进制形式打开临时数据文件data.tmp中；然后再对包体进行解析，将数据还原到入口表中。
接收一组数据流程：
从数据组查询返回信息中得到一组数据的相关信息。然后根据这些信息向信息中心发送下载数据包的请求，从一组的第一个数据包开始，到最后一个数据包结束，按顺序下载数据包。每下载完一个数据包写一次断点文件，记录下载情况。下载的数据只对数据包的包头进行解析，包体存入data.tmp文件中。全部包下载完毕后，从新从data.tmp中取出数据，解析包体，从包头解析信息找到入口表表名，把从包体中解析出的数据插入相应的入口表。
接收多组数据流程：
如信息中心有多组数据等待下载，可以重复发送数据组查询请求，调用下载一组数据模块。直到信息中心返回无数据下载为止。
2.6.2.2. 断点续传
接收时的断点是客户端通讯平台在向信息中心发送下载数据包请求，接收数据包时忽然中断，而形成的断点。这种断点记录记录了正在下载的组的属性，以及中断时正在下载第几个数据包。
断点续传时首先读取断点记录文件，然后根据读取的信息恢复断点，继续接收剩余数据包。接收断点续传流程略。
2.6.3. 接收处理回执
回执下载方法：
客户端通讯平台向信息中心发送接收回执请求，信息中心返回一个回执数据包或通知客户端通讯平台没有要下载的回执数据。一个客户端通讯平台接收的回执，应该是由自己发送的数据返回的回执。在KH_T_RECEIPT中应有与其对应的记录，如果没有与之相对的记录这个回执就是错误回执。回执数据包中有一项叫作回执码，它表示数据接收方是否正确接收数据，以及出错误原因。接收处理回执模块对不同回执码的回执有不同的处理方法。
回执码：000 数据表正确 删除出口表中组号与回执包内源组号相同的记录；
回执码：001 数据表格式错 写错误日志
回执码：R01 第一个数据项错 重发(将回执记录表表中记录的重发字段，置成重发状态，由数据发送模块负责重发)
3. TXUEDO在邮政综合网中的应用研究案例之二:集中处理的电子化支局营业系统
3.1. 概述
目前电子化支局系统大多采用C/S局域网模式，这种模式适用于广域网连接条件较差的地区，网络化程度较低，数据存储比较分散，不易于统一管理和统计分析，不能实时向领导和业务部门提供决策依据。
随着邮政综合计算机网建设的完成和电子化支局工程的实施，各市县的网络环境得到了相应的改善，广域网下的集中处理模式也越来越引起邮政系统的重视。BEA TUXEDO 为中国邮政购买的中间件产品，电子化支局工程即基于此平台，在其上构建邮政电子化支局的应用系统，将能够满足网络环境比较好的市县数据集中的需要。
3.2. 系统方案论证
目前数据库的体系结构有客户/服务器模式、三层的客户服务器模式、基于浏览器的B/S体系结构。以下结合集中处理的电子化支局系统对几种模式进行比较分析，以选择适合的体系结构。
(一)客户/服务器模式
在客户/服务器模式下，客户端即数据库应用的用户接口层与业务规则层，负责提供用户与数据库交互的界面，向数据库服务器提交用户请求并接收来自数据库服务器的信息，并执行应用逻辑要求。服务器即数据库层，它由支持应用的底层数据库引擎组成，它的责任是保持数据库的完整性，也可以使用数据库提供的存储过程等完成部分或全部交易逻辑。
客户/服务器模式的特点是胖客户，客户端承担了过于繁重的任务，这种模式导致PC的配置较高，而且客户端应用的维护相当麻烦，所有的客户端都直接连接访问数据库，使得系统的安全性差，以单一服务器和局域网为中心，系统难以扩展，难以管理大量客户机。所以客户/服务器模式适用于局域网下的小规模的数据库应用系统。
（二）三层体系结构
三层体系结构在逻辑上可以分为三层：用户接口层、业务规则层、数据库层。其中用户接口层负责图形用户接口（GUI）逻辑的设计，业务规则层实现业务规则和应用逻辑，数据库层利用数据库自身的特点保证数据的完整性和一致性。 其中业务规则层可以基于现有的中间件产品平台来实现，如邮政电子汇兑系统采用了BEA 的TUXEDO 产品。三层体结构的特点是：可跨平台操作；减少整个系统的成本；维护升级十分方便； 具有良好的开放性和易扩充性； 进行严密的安全管理； 支持负载均衡；系统管理简单，可支持异种数据库，有很高的可用性。
（三）B/S结构
B/S结构即：浏览器——Web服务器——数据库服务器的三层结构。浏览器与WEB服务器之间通过HTTP协议来实现信息的存储和传递，利用URL来实现客户端的浏览器与Web服务器的资源建立连接，达到用户对服务器资源的透明访问。
特点：该模式中应用程序、数据库以及一些资源组件都集中在服务器端，客户端只需安装浏览器，无须其他辅助软件和相关的维护管理工作，使得维护起来非常容易，适用于局域网和广域网。
比较：
集中处理的电子化支局系统基于广域网结构，网点台席多达300多个，网络带宽没有很好的保障，不适合采用客户/服务器结构；B/S结构尽管维护简单，适合于广域网的应用，但由于中国邮政电子汇兑系统采用了基于TUXEDO 中间件的三层结构，B/S方式的电子化支局系统很难与三层模式的电子汇兑系统融合在一起。为此我们决定采用三层结构，使用BEA的TUXEDO 作为中间层的应用平台。 系统结构图如下：
3.3. 设计与实现
集中处理的电子化支局处理系统三层体系中客户端程序使用DELPHI开发，应用服务层程序用Pro*c开发，数据库采用ORACLE8。
由于采用三层体系结构后，将应用逻辑独立于界面显示，只要制定应用服务与界面之间的接口规范即可开始各个独立的开发，使得界面的开发与应用服务器的开发可以非常独立地进行。
三层体系中客户端与服务端的通信是由TUXEDO的API函数实现，客户端由函数Tpinit与服务器建立连接，由函数Tpcall申请Service服务，再由相关的TUXEDO函数对数据解包，进行相应的业务逻辑处理。
根据业务的分类，我们将服务端的服务分成以下几类：
1、 管理类服务：提供系统机构的增加、营业员的管理、营业员登录等等服务。
2、 资费维护类服务：提供营业中各种资费信息的维护。
3、 结帐类服务：提供台席结帐、全局结帐、个人业务量统计的功能。
4、 收寄类服务：提供函包速递国际等收寄业务的处理。
5、 内部处理类服务：提供封发时的清单路单制作等功能。
3.4. 编写TUXEDO SERVER 时考虑的几点问题
3.4.1. TUXEDO SERVER 与SERVICE 的组织
TUXEDO SERVER的结构是每个SERVER中包含若干个SERVICE，客户端与调用特定的SERVICE 。一般情况下，应该将业务处理复杂的SERVICE 与简单的SERVICE 组织到一个SERVER中，以便平衡系统的性能。在我们的案例中，我们按业务的应用组织的SERVER，如包裹 、函件、速递、内部处理等等。每个SERVER包含5个或6个SERVICE，而其中只有一、两个SERVICE 是经常被调用的，从而保证了系统的运行性能。
3.4.2. 与数据库的连接方式
与数据库的连接方式有两种：基于XA 的连接方式及采用数据库提供的连接方式。XA是一个标准化的接口，可以用于不同数据库之间的互联，可以用于异地保证数据库的事务处理的完整性。 大型的数据库如ORACLE SYBASE INFORMIX 等均支持XA的接口。TUXEO 也提供了通过XA访问数据库的API，可以很方便的进行事务控制，但是访问速度稍慢。
在我们的案例中，只访问一种数据库即ORACLE 数据库，所以我们采用了ORACLE 提供的连接方式，在每个访问数据库的SERVER启动时与ORACLE 建立连接。在每个访问数据库的SERVER 关闭时断开连接。
3.4.3. 报文的数据类型
在第一部分中讲述了TUXEDO提供了多种数据类型，如STRING CARRAY FML VIEW 等。其中FML类型的数据格式允许用户动态增加或减少其中某个或某些变量的个数。FML类型只保存有效数据，从而可节省内存并减少网络传输量。但是使用FML 类型要求在客户端和服务端相对应地定义，这影响了客户端与服务端的独立性，例如在电子汇兑中，服务端由华腾公司编写，客户端可以自行开发，使用FML 缓冲区会比较麻烦。我们也考虑到这一点，由于CAARAY能够传输机器0，而STRING不可以传输机器0，所以我们采用了CARRAY 作为报文传输的类型。
3.4.4. 客户与服务之间的通讯方式
客户与服务之间的通讯方式有很多种，如同步方式、异步方式、事件通知、队列方式。队列方式用于可靠的数据传递，在省际之间的报刊传输数据系统中使用了队列方式，在我们的系统中，应用的性质是实时的在线业务处理，使用同步方式（tpcall）即可。
3.4.5. 公共服务请求代理的使用
公共服务请求代理是做一个SERVER，其中包含一个SERVICE，该SERVICE完成统一的报文验证功能，由该SERVICE再调用其他的SERVICE 。这种方式使得客户端只需调用统一的SERVICE，简化了客户端的编程。
3.4.6. 配置文件中参数的调整
TUXEDO配置文件对于系统的性能至关重要的。某些参数的调整只能靠不断的进行测试来优化。如每个应用SERVER启动的个数，监听进程的启动个数等等
扫一扫
998
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
