1.2 业务逻辑层的设计
1.2.1 服务的划分
    在TUXEDO应用系统服务端中把业务逻辑划分成一个个独立的服务(Serviece)，把多个服务按一定的规则绑定到一个Server中，客户端调用这些服务来实现相应的操作，所以服务端的主要任务就是编写一个个的服务。交互式自助服务平台业务逻辑层主要的业务逻辑处理有：管理终端对交易数据操作的请求；交互式自助服务终端办理常规业务的请求；交互式功能实现时所涉及到的坐席申请、分配、状态更新的请求。Web服务器请求的服务为第二种请求的子集。对于第一种请求，主要是对交易数据库进行查询、更新、删除、插入等操作，因此，可以划分两个Service：DataQuery(数据查询)和DataControl(数据操纵)，并绑定到进程(Server)Sys_Server中；第二种请求是平台业务处理中最为频繁的，主要包括用户身份验证、话费缴纳、账单查询、话费详单查询、业务受理等。出于系统安全性和灵活性以及上述服务划分、绑定原则的考虑，这里采用二个进程Term_Imprest和Term_Server来实现第二种请求。Term_Imprest有一个服务Multi_Imprest，实现用户缴费的业务处理；Term_Server划分为二个服务：Multi_Service和Multi_Request。Multi_Request实现业务逻辑层与电信运营商业务系统前置机之间的数据通信，Multi_Service实现自助服务终端用户业务请求逻辑，不同的业务通过交易编码(系统自定义参数)来区分。之所以将缴费缴纳单独采用一个进程处理，是因为在具体运行中经常需要关闭缴费功能但同时保证其他业务能正常办理。针对这种情况，管理维护人员只需将业务逻辑层中的Term_Imprest进程关闭即可，其他业务仍然可以照常办理；第三种请求主要是辅助交互式功能的实现。对于这种请求，业务逻辑层相当于一个坐席中转服务程序，它划分为三个服务：Query_Seat(坐席状态查询)，Update_Seat(坐席状态更新)，Apply_Seat(申请坐席)，并绑定到进程(Server)Seat_Server中。
1.2.2 坐席的分配
    在交互式自助服务平台中，交互式业务类型有多种，每种类型需要的服务时间各不相同。因此，本文采用基于服务时间和业务熟悉程度相结合的多队列机制来实现坐席分配。
    每一种交互式业务对应一个坐席队列，业务逻辑层从自助服务终端业务请求队列中按照FCFS的原则取出一个请求，然后从对应的坐席队列中取出服务时间和业务熟悉程度加权和最大的坐席分配给请求自助服务终端。加权计算方法为：服务时间×服务因子＋业务熟悉程度×业务因子。服务因子与服务时间成反比，服务时间越长，服务因子越小；业务因子与业务熟悉程度成正比，业务越熟悉，业务因子就越大。坐席在办完一次业务后，服务时间增加，业务熟悉程度增加，同时也将导致服务因子减小和业务因子的增大。通过这种方式，能有效地均衡坐席的服务强度。采用多队列的方式相比，单个队列方式能有效地提高效率和系统吞吐量。因为多队列方式中，每个坐席只需负责一种服务，其熟练程度要大于一个坐席负责多种服务，才能降低出错的可能，而且采用多队列机制也不会因为一种服务受阻而影响其他服务的办理。坐席分配示意如图2所示。

    图2中S表示服务时间，F表示业务熟悉程度，Factor_S表示服务因子，Factor_F表示业务因子。
1.2.3 数据通信的设计
    交互式自助服务平台的数据通信是平台运行的关键，它是将平台各个部分衔接起来的桥梁和纽带，而业务逻辑层是平台通信的枢纽。业务逻辑层的通信主要有二种模式：(1)表示层为获取数据而与业务逻辑层之间的通信。(2)业务逻辑层为获取用户所需的业务数据而与数据层的电信运营商业务系统前置机之间的通信。
    第一种通信模式是平台的主要通信方式，它借助于BEA TUXEDO中间件来实现。本文采用会话方式来实现表示层与业务逻辑层之间用户详单文件的传输。表示层调用tpconnect( )函数主动与业务逻辑层建立连接，之后业务逻辑层作为发送者调用tpsend( )函数向请求的表示层发送数据，表示层作为接收者调用tprec( )函数接收逻辑层发送的详单数据。当数据传送完毕，由表示层关闭连接。从连接建立到连接关闭，表示层与业务逻辑层之间连接一直保留，可以多次实现数据传输。采用Q/方式来实现交互式功能中的坐席分配。Q/方式有二种模式：基本模式和转发模式。基本模式适用于客户机对客户机，而转发模式适用于客户机对服务器。前者主要用于两者之间交换数据，在坐席分配实现中采用转发模式。表示层将坐席请求发送到消息队列中，业务逻辑层收到消息后转发给相应的处理进程进行处理，处理完毕之后，由表示层从消息队列中取出处理结果。采用同步请求/回答方式来处理第一种通信方式中剩余的表示层与业务逻辑层之间的通信，这种通信方式比较简单。表示层在调用相应的服务后处于阻塞状态，等待业务逻辑层的处理结果或者超时退出之后才继续往下执行。
    第二种通信模式中，业务逻辑层主要实现协议转换的功能。这种方式中，逻辑层充当了电信运营商业务系统前置机的客户端，它向电信运营商业务系统业务提出业务请求，并接收电信运营商业务系统业务的响应。这种通信方式的实现要视电信运营商业务系统提供的接口而定。
1.3 表示层的功能设计
    表示层主要是为系统使用者提供多样化的界面逻辑，将从业务逻辑层获取的数据展现给用户，因此表示层侧重于功能的设计。表示层由自助服务终端、客户服务中心、管理终端、Web服务器组成。交互式自助服务终端是平台中直接与用户交互的部分，它将用户的业务请求提交给业务逻辑层，并将业务逻辑层返回的数据直观地展现给用户，同时提供用户与客户服务中心坐席交互的功能。由于自助服务要求用户能在无人指导的情况下在自助设备上完成业务操作，因此，交互式自助服务终端要充分考虑各种阶层的使用者，要有人性化的操作界面。如用生动的图形动画、文字说明及丰富的声音来提示、引导客户进行自助操作；操作流程要简单、明了、无二义性，使客户能简单、直观地完成操作；容错性能好，能处理各种正常或异常情况，使客户放心操作。
    终端管理系统主要实现实时监控自助服务终端运行状况、交易状况、系统故障和对交易数据进行管理，使管理人员能随时准确地了解平台的运行状况，从而能根据终端运行情况采取相应的措施，保证平台能24小时稳定、正常地运行。终端管理系统由系统管理、终端管理、终端查询、坐席管理、报表管理、门禁系统管理6个子系统组成。
    Web服务器主要用来实现平台的Web功能，扩大平台的应用范围，实现平台的电子商务功能，从而实现原有的自助服务系统与电子商务平台的有机结合。Web服务器采用Bea公司的另一旗舰产品Weblogic Server实现，通过Bea公司的Jolt产品或者Wtc产品可以实现TUXEDO与Weblogic之间的互连。Web服务器实现的功能和自助服务终端相同，只是数据展现方式不同。
    客户服务中心通过与自助服务终端进行音、视频的交互，与用户一起完成综合电信业务的办理。
1.4 交互式功能的设计与实现
    平台的交互式功能通过网络视频会议系统实现。在实现过程中需要进行视频、音频、文件、数据传输。在交互式平台中采用实时流传输技术实现视频、音频信号的传输，文件和数据的传输则通过基于TCP/IP协议的套接字通信实现。由于视频流和音频流数据量大，因此在平台实现中协议的选择是实现实时多媒体流传输的关键。图3给出了交互式平台中实现视频会议功能时所采用的协议体系结构。