(4)如何对两层的结构进行扩展:
采用多路集中方式，客户端不直接与服务库服务器相连，而是先与一个sesstion connector 相连，再由sesstion connector 与数据库服务器。
（5）分布式系统的三层结构阶段：
对二层系统的扩展,就演变成了分布式系统的三层结构：
将业务逻辑从客户端应用中分离出来，组成业务逻辑服务器。客户端与业务逻辑服务器相联，业务逻辑服务器与数据库相连。这样就演变成 “客户端、业务逻辑服务器、数据库服务器”的三层结构。
2.2 中间件是三层结构的手段
（1） 中间件是将应用映射到相关的资源上的软件技术，它是由一系列的API 和通讯协议所组成的。中间件使得三层的客户服务器架构得以实现。
（2） 使用中间件的应用的优点：
l 灵活地在客户与服务器之间划分数据与逻辑.
l 便于按照业务需求修改客户端或服务器端的逻辑.
l 分隔系统的开发与系统的部署.
l 提供分布交易的全程保护
（3）
第3节 BEA TUXEDO 简介 3.1 TUXEDO消息处理机制
3.1.1 client/server架构的两种模式
? 在一个client/server结构的应用中，client(需要服务的实体)和server(提供服务的实体)是互相独立的两个逻辑对象，两者通过通讯来共同完成一个任务。
client发起一个服务请求，并接收server端返回的处理结果。
server端接收并处理client端的请求，并把结果返回到client端。
? 一个客户端应用（client application）的功能：组织服务请求数据，并接收请求处理结果。提供通过网络，发送服务请求数据、接收请求结果的机制
? 一个服务端应用 (server application) 的功能：接收client端的服务请求数据，根据业务逻辑处理客户请求，并将处理结果返回到client端。
? 有两种类型的client/server架构模式
ü 数据请求模式 （适合client/server之间传输大批量数据）
ü 服务请求模式 （适合快速的、级小数据传输的服务请求）
3.1.2 TUXEDO如何处理client/server架构模式
TUXEDO使用conversation(会话)方式来处理 “数据请求模式”
TUXEDO使用 request/reponse 方式来所处理 “服务请求模式”
使用TUXEDO的client/server应用的特点:
? 快速的，无连接的通讯：
在应用TUXEDO的系统中，客户端与TUXEDO bulletin board 建立连接(而不是与具体的Server建立直接的连接) ，然后由TUXEDO寻找最合适的SERVER来提供服务。这样节省了系统资源，提高了系统性能。
队列是实现无连接通讯结构的关键。每个SERVER被分配一个内部的消息队列，被称为“请求队列”，每一个客户端也被分配一个消息队列，被称为“响应队列”。这样客户端不用与具体的SERVER建立并维持连接，而只要检索“响应队列”来获得返回结果。
? 服务进程的透明性：
BB 包含一个后台所有service的目录，客户端只要按名调用后台service，而不用管service所在何处。
? 可扩展性：
因为service和server可以很容易的复制，并且它们可以是分布式的，因此，可以很方便的根据系统的负载来调整后台应用。
3.1.3 嵌套的服务请求（Nested Service Requests）
服务可以嵌套调用。一个service嵌套调用另外一个service,必须等到被调用的service返回，才能做下一步的处理。
嵌套调用优点：代码的可重用。缺点：影响系统的整体性能，尤其是在分布式应用服务器的架构中。
如果可能的话，嵌套应该限制在两层。在一个典型的三层模式的应用中，只有两层的嵌套调用会取得很好的效果。这三层是
? 表现层（Presetation Logic Layer）
? 业务逻辑层（Bussiness Logic Layer）
? 数据库层（Database Layer）
3.1.4 传递的服务请求(Forward Service Requests)
另外一种服务嵌套调用的方式是forward方式。在forward 方式中，service不是将处理结果返回给客户端，而是将服务请求传递给下一个service,下一个service或者将处理结果返回给客户端，或者继续传递。
forward 调用的层次没有限制，也不会导致server的堵塞。
3.1.5 TUXEDO 会话（conversation）处理机制
除了request-reply的消息机制，TUXEDO还支持大数据量的传输。TUXEDO采用叫做会话（CONVERSATION）的方式来处理。
在client端与server端建立一个虚连接(a virtual connection)，并且维持这个连接直到完成数据传输任务。
TUXEDO 提供一组API函数用于实现client与server端的这种通讯机制。主要包括
连接，发送、接受、终止连接。
Conversation这种通讯机制，是半双工的，只有取得控制权的一方，才可以发送数据。另外一方只能被动的接受数据。
在配置上conversation 模式的SERVER 要加 “CONV =Y”参数
3.1.6 主动通知/事件代理(Unsolicited Notification/ EventBroker)
TUXEDO还支持非listening -- reply的通讯方式，可以定义当某个“条件”满足时，系统自动与另外的系统进行通讯，即使其他系统没在listening。这个“条件”在TUXEDO中称为event
这种主动通讯方式叫做Unsolicited Notification
3.2 BEA TUXEDO 3层Client/Server架构 Jrepository中增加字段步骤
1． 确认jrepository中缺少的字段名称，如缺少字段[SCORE_NAME]；
2． 确认boss.flds.h是否存在，如果存在跳过该步骤，如果不存在，使用命令[mkfldhdr32 boss.flds]将Tuxedo的FML配置文件boss.flds生成对应的头文件boss.flds.h； 3． 在boss.flds.h中查找字段[SCORE_NAME]，如下所示：
#define SCORE_NAME ((FLDID32)167795964) /* number: 23804 type: string */
4． 在jrepository中找到对应的服务入口，如下所示： add SVC/ITF_BKHSVC:bt=FML32:ex=1:BT=FML32:vs=6:\\
5． 在该服务入口下按照已有字段格式增加字段[SCORE_NAME] bp:pn= SCORE_NAME:po=0:pf=167795964:pt=string:pa=rw:ep:\\
注意，其中的pf与boss.flds.h中的FLDID32保持一致，pt与boss.flds.h中的type保持一致
6． 修改完jrepository后，重启Tuxedo的JSL和JREPSVR进程，命令如下： [tmshutdown -s JSL]
[tmshutdown -s JREPSVR] [tmboot -s JREPSVR] [tmboot -s JSL]
Tuxedo常用的命令 中间件系统检查
1.日志检查清理。检查Tuxedo日志，用vi命令查看日志文件内容，检查有无Tuxedo系统出错记录；检查有无服务异常错误记录；检查有无服务被重起记录；对发现的异常记录进行分析；若无异常情况清除无用的历史日志。
2. 服务器运行情况。检查Tuxedo系统和应用的服务器的运行情况，用“ps －ｅｌｆ｜ｇｒｅｐｓｅｒｖｅｒ名”查看进程相关信息，如运行时间、占用内存大小等；用ｔｍａｄｍｉｎ命令检查看服务器运行情况，执行ｐｓｒ监控服务器运行情况，查看处理的请求数目、忙闲程度。
3. ｓｅｒｖｉｃｅ运行情况。检查ｓｅｒｖｉｃｅ运行情况，用ｔｍａｄｍｉｎ命令中的ｐｓｃ命令查看Ｔｕｘｅｄｏ各ｓｅｒｖｉｃｅ的运行情况和处理的交易数。
4. 队列使用情况。检查Ｔｕｘｅｄｏ队列的使用情况，用ｔｍａｄｍｉｎ命令中的ｐｑ命令查看Ｔｕｘｅｄｏ各ｓｅｒｖｅｒ队列的使用情况，主要查看交易高峰期队列中消息的增加情况，确定是否存在阻塞现象，是否需要对服务数进行调整。
5. 客户机连接情况。检查ＴｕｘｅｄｏＣｌｉｅｎｔ的连接情况，用ｔｍａｄｍｉｎ命令中的ｐｃｌｔ命令查看Ｔｕｘｅｄｏ各客户机的连接情况，检查ＭＡＸＣＬＩＥＮＴ参数是
否足够，Ｌｉｃｅｎｃｅ数是否满足并发要求。
6 .配置参数配置。检查Ｔｕｘｅｄｏ ｕｂｂｃｏｎｆｉｇ文件和ｄｍｃｏｎｆｉｇ文件，根据以上各项检查结果，查看Ｔｕｘｅｄｏ配置文件是否需要调整优化，以使中间件平台良好运行，保存配置文件并归档备案。
7. 系统核心参数配置。检查操作系统核心参数配置是否满足目前应用系统规模要求，是否需要调整，根据具体使用的操作系统提供的命令查看核心参数。 8. tmunloadcf 可以导出 ubb 文件, tmloadcf 加载ubb 文件
9. tmboot 启动, tmshutdown 关闭, 当然还有很多参数 比如 -y -i -s 等