TUXEDO培训.docx
《TUXEDO培训.docx》由会员分享，可在线阅读，更多相关《TUXEDO培训.docx（94页珍藏版）》请在冰豆网上搜索。
TUXEDO培训
TUXEDO补充培训资料
一、CS架构，三层架构，XA事务管理，TUXEDO简介
传统的CS体系结构简介
1.1C/S结构的数据库应用
与C/S体系形成对比，传统的数据库应用体系结构，例如基于主机-多终端的系统，或基于LAN上文件服务器运做的多用户系统，数据库是属于应用程序“私有的”，即使它也可以将数据文件放置在某台机器上供不同的用户共同访问（这种情形，称为“文件服务器”），但所有的操作、规则，都是在一个包罗万象的应用程序内部实现的。
应用程序因此具有最大的复杂性，即使是原班开发人马，要想对已有功能加以扩充也是很困难的，当数据库稍具复杂性（比如有稍多相互关联的表与规则），其他的人员开发另外的程序共同操作这个数据库的数据，几乎不具可行性。
C/S又称Client/Server或客户/服务器模式。
服务器通常采用高性能的PC、工作站或小型机，并采用大型数据库系统，如Oracle、Sybase、Informix或SQLServer。
客户端需要安装专用的客户端软件。
最简单的C/S体系结构的数据库应用，由两部分组成，即客户应用程序和数据库服务器程序。
二者可分别称为前台程序与后台程序。
运行数据库服务器程序的机器，称为应用服务器，一旦服务器程序被启动，就随时等待响应客户程序发来的请求；客户程序运行在用户自己的机器上，对应于服务器机器，可称为客户机。
当需要对数据库中的数据进行任何操作时，客户程序就自动地寻找服务器程序，并向其发出请求，服务器程序根据预定的规则作出应答，送回结果。
在典型的C/S数据库应用中，数据的储存管理功能，是由服务器程序独立进行的，并且通常把那些不同的（不管是已知还是未知的）前台应用所不能违反的规则，在服务器程序中集中实现，例如访问者的权限，帐号不准重复、必须有客户才能建立定单这样的规则。
所有这些，对于工作在前台程序上的最终用户，是“透明”的，他们无须过问（通常也无法干涉）这背后的过程，就可以完成自己的一切工作。
在客户服务器架构的应用中，前台程序可以变的非常“瘦小”，麻烦的事情，都交给了服务器和网络。
在C/S体系的下，数据库真正变成了公共、专业化的仓库，受到独立的专门管理。
C/S的优点是能充分发挥客户端ＰＣ的处理能力，很多工作可以在客户端处理后再提交给服务器。
对应的优点就是客户端响应速度快。
C/S系统各功能层
用户接口：
表示管理、表示逻辑
业务逻辑：
应用程序的逻辑/规则
数据管理：
数据访问逻辑（SQL）、数据库管理
缺点主要有以下几个：
1、难以维护。
客户端/服务器（Client/Server）结构用户界面、业务逻辑和数据逻辑相互交错，通常在难以升级或改进，而且经常基于某种专有的协议（通常是某种数据库协议）。
它使得重用业务逻辑和界面逻辑变得非常困难。
2、难以扩展。
随着系统的升级，系统复杂程度大大增加，难以扩展，另外，它是一个封闭的系统，很难与其他的应用系统实现互操作。
3、安全性差。
客户端程序可以直接访问数据库，可通过编程语言或数据库提供的工具字接对数据库进行操作，不安全。
4、性能不好。
客户端字接与数据库建立连接，当有大量的并发用户存在时，会使数据库不堪重负，性能迅速下降，甚至死机。
二、XA事务管理
XA基础
在谈到XA规范之前，必须首先了解分布式事务处理（DistributedTransactionProcessing，DTP）的概念。
Transaction，即事务，又称之为交易，指一个程序或程序段，在一个或多个资源如数据库或文件上为完成某些功能的执行过程的集合。
分布式事务处理是指一个事务可能涉及多个数据库操作，分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作，提交或回滚事务的决定必须产生统一的结果（全部提交或全部回滚）。
X/Open组织（即现在的OpenGroup）定义了分布式事务处理模型。
X/OpenDTP模型（1994）包括应用程序（AP）、事务管理器（TM）、资源管理器（RM）、通信资源管理器（CRM）四部分。
一般，常见的事务管理器（TM）是交易中间件，常见的资源管理器（RM）是数据库，常见的通信资源管理器（CRM）是消息中间件。
为表述方便起见，在本文中直接以其常见表现形式进行描述。
通常把一个数据库内部的事务处理，如对多个表的操作，作为本地事务看待。
数据库的事务处理对象是本地事务，而分布式事务处理的对象是全局事务。
所谓全局事务，是指分布式事务处理环境中，多个数据库可能需要共同完成一个工作，这个工作即是一个全局事务，例如，一个事务中可能更新几个不同的数据库。
对数据库的操作发生在系统的各处但必须全部被提交或回滚。
此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功，还要依赖与全局事务相关的其它数据库的操作是否成功，如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。
一般情况下，某一数据库无法知道其它数据库在做什么，因此，在一个DTP环境中，交易中间件是必需的，由它通知和协调相关数据库的提交或回滚。
而一个数据库只将其自己所做的操作（可恢复）影射到全局事务中。
XA就是X/OpenDTP定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。
XA接口函数由数据库厂商提供。
XA与两阶段提交协议
通常情况下，交易中间件与数据库通过XA接口规范，使用两阶段提交来完成一个全局事务，XA规范的基础是两阶段提交协议。
在第一阶段，交易中间件请求所有相关数据库准备提交（预提交）各自的事务分支，以确认是否所有相关数据库都可以提交各自的事务分支。
当某一数据库收到预提交后，如果可以提交属于自己的事务分支，则将自己在该事务分支中所做的操作固定记录下来，并给交易中间件一个同意提交的应答，此时数据库将不能再在该事务分支中加入任何操作，但此时数据库并没有真正提交该事务，数据库对共享资源的操作还未释放（处于上锁状态）。
如果由于某种原因数据库无法提交属于自己的事务分支，它将回滚自己的所有操作，释放对共享资源上的锁，并返回给交易中间件失败应答。
在第二阶段，交易中间件审查所有数据库返回的预提交结果，如所有数据库都可以提交，交易中间件将要求所有数据库做正式提交，这样该全局事务被提交。
而如果有任一数据库预提交返回失败，交易中间件将要求所有其它数据库回滚其操作，这样该全局事务被回滚。
以一个全局事务为例，AP首先通知交易中间件开始一个全局事务，交易中间件通过XA接口函数通知数据库开始事务，然后AP可以对数据库管理的资源进行操作，数据库系统记录事务对本地资源的所有操作。
操作完成后交易中间件通过XA接口函数通知数据库操作完成。
交易中间件负责记录AP操作过哪些数据库（事务分支）。
AP根据情况通知交易中间件提交该全局事务，交易中间件会通过XA接口函数要求各个数据库做预提交，所有数据库返回成功后要求各个数据库做正式提交，此时一笔全局事务结束。
XA规范对应用来说，最大好处在于事务的完整性由交易中间件和数据库通过XA接口控制，AP只需要关注与数据库的应用逻辑的处理，而无需过多关心事务的完整性，应用设计开发会简化很多。
具体来说，如果没有交易中间件，应用系统需要在程序内部直接通知数据库开始、结束和提交事务，当出现异常情况时必须由专门的程序对数据库进行反向操作才能完成回滚。
如果是有很多事务分支的全局事务，回滚时情况将变得异常复杂。
而使用XA接口，则全局事务的提交是由交易中间件控制，应用程序只需通知交易中间件提交或回滚事务，就可以控制整个事务（可能涉及多个异地的数据库）的全部提交或回滚，应用程序完全不用考虑冲正逻辑。
两阶段提交协议的一种变例
在一个涉及多个数据库的全局事务中，为保证全局事务的完整性，由交易中间件控制数据库做两阶段提交是必要的。
但典型的两阶段提交，对数据库来说事务从开始到结束（提交或回滚）时间相对较长，在事务处理期间数据库使用的资源（如逻辑日志、各种锁），直到事务结束时才会释放。
因此，使用典型的两阶段提交相对来说会占用更多的资源，在网络条件不是很好，如低速网、网络颠簸频繁，情况会更为严重。
当一个全局事务只涉及一个数据库时，有一种优化方式，即一阶段提交。
当AP通知交易中间件提交事务时，交易中间件直接要求数据库提交事务，省去两阶段提交中的第一阶段，可以缩短处理一个事务的时间，以提高事务处理的效率。
作为两阶段提交的一种特例，与两阶段一样，一阶段提交也是标准的。
三、中间件的引入
三层架构
三层客户机/服务器模式的核心概念是利用交易中间件将应用的业务逻辑、表示逻辑和数据分为三个不同的处理层。
表示逻辑（客户层）为第一层。
它的主要功能是实现用户交互和数据表示，为以后的处理收集数据，向第二层的业务逻辑请求调用核心服务处理，并显示处理结果。
业务逻辑（服务器组件）为中间层。
这些组件由中间件管理，实现核心业务逻辑服务并将这些服务按名字广播、管理并接受客户的服务请求，向资源管理器提交数据操作，并将处理结果返回给请求者---客户或其他服务器。
数据（资源管理器）构成模型的第三层。
比如关系数据库，负责管理应用系统的数据资源，完成数据操作。
服务器组件在完成服务的过程中通过资源管理器存取它管理的数据，或者说请求资源管理器的数据服务。
什么是中间件
中间件（middleware）是基础软件的一大类，属于可复用软件的范畴。
顾名思义，中间件处于操作系统软件与用户的应用软件的中间。
中间件在操作系统、网络和数据库之上，应用软件的下层，总的作用是为处于自己上层的应用软件提供运行与开发的环境，帮助用户灵活、高效地开发和集成复杂的应用软件。
在众多关于中间件的定义中，比较普遍被接受的是IDC表述的：
中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件位于客户机服务器的操作系统之上，管理计算资源和网络通信。
IDC对中间件的定义表明，中间件是一类软件，而非一种软件；中间件不仅仅实现互连，还要实现应用之间的互操作；中间件是基于分布式处理的软件，最突出的特点是其网络通信功能。
最早具有中间件技术思想及功能的软件是IBM的CICS，但由于CICS不是分布式环境的产物，因此人们一般把Tuxedo作为第一个严格意义上的中间件产品。
Tuxedo是1984年在当时属于AT&T的贝尔实验室开发完成的，但由于分布式处理当时并没有在商业应用上获得像今天一样的成功，Tuxedo在很长一段时期里只是实验室产品，后来被Novell收购，在经过Novell并不成功的商业推广之后，1995年被现在的BEA公司收购。
尽管中间件的概念很早就已经产生，但中间件技术的广泛运用却是在最近10年之中。
BEA公司1995年成立后收购Tuxedo才成为一个真正的中间件厂商，IBM的中间件MQSeries也是90年代的产品，其它许多中间件产品也都是最近几年才成熟起来。
中间件的十大优越性：
·缩短应用的开发周期
·节约应用的开发成本
·减少系统初期的建设成本
·降低应用开发的失败率
·保护已有的投资
·简化应用集成
·减少维护费用
·提高应用的开发质量
·保证技术进步的连续性
·增强应用的生命力
具体地说，中间件屏蔽了底层操作系统的复杂性，使程序开发人员面对一个简单而统一的开发环境，减少程序设计的复杂性，将注意力集中在自己的业务上，不必再为程序在不同系统软件上的移植而重复工作，从而大大减少了技术上的负担。
中间件带给应用系统的，不只是开发的简便、开发周期的缩短，也减少了系统的维护、运行和管理的工作量，还减少了计算机总体费用的投入。
Standish的调查报告显示，由于采用了中间件技术，应用系统的总建设费用可以减少50％左右。
在网络经济大发展、电子商务大发展的今天，从中间件获得利益的不只是IT厂商，IT用户同样是赢家，并且是更有把握的赢家。
其次，中间件作为新层次的基础软件，其重要作用是将不同时期、在不同操作系统上开发应用软件集成起来，彼此像一个天衣无缝的整体协调工作，这是操作系统、数据库管理系统本身做不了的。
中间件的这一作用，使得在技术不断发展之后，我们以往在应用软件上的劳动成果仍然物有所用，节约了大量的人力、财力投入。
四、TUXEDO简介
Tuxedo是什么
BEATUXEDO是在企业、Internet这样的分布式运算环境中开发和管理三层结构的客户/服务器型关键任务应用系统的强有力工具。
它具备分布式事务处理和应用通信功能，并提供完善的各种服务来建立、运行和管理关键任务应用系统。
开发人员能够用它建立跨多个硬件平台、数据库和操作系统的可互操作的应用系统。
BEATUXEDO是企业、Internet分布式应用中的基础主干平台。
它提供了一个开放的环境，支持各种各样的客户、数据库、网络、遗留系统和通讯方式。
使用Tuxedo构建的企业级C/S系统的特点
•使用者–大量在线用户
•处理对象–海量数据（workload,database）
•目的–对信息访问（purpose）
•持续时间–短事务（duration）
•应用领域–网络化的企业（topology）
Tuxedo的三个部分
1、客户端：
发出服务请求
2、服务器端：
完成服务请求
3、配置文件：
通过列出机器和服务器信息来描述具体应用
BEATUXEDO的组件软件模型
关键业务应用通常是面向事务的，要求具有准确的数据完整性、较好的性能和管理需求。
这些需求要求对应用的开发、调度和操作给出一个结构化的方案。
由像BEATUXEDO这样的中间件支持的组件软件模型为分布式环境处理关键性业务应用提供了一个结构化的解决方案。
BEATUXEDO和基于组件的应用设计从异构的计算资源中创建了一个虚拟主机：
在分布式应用系统级提供可管理的相互关联的资源。
许多组织在进行了一段时间的分布式应用工作后，现在已经认识到组件软件模型是他们的必然选择。
分布式应用的直接动力是主机应用和集中式中规模的应用系统基础上又逐渐配备有大量的台式系统和服务器系统，这些分布式系统在标准网络传送协议的支持下，呈松散耦合的态势，事实上它们构成了网络计算资源的基础。
在开始的时候，分布式系统主要服务于把集中式系统的前台应用迁移到网络环境----主要用台式处理器和文件服务器实现文档处理和电子邮件通讯应用系统。
接着，两层的客户/服务器数据库应用在部门级被采用，这类应用把交互式文件共享进化到并发数据元素访问，在数据级支持更细粒度的管理。
虽然这些客户/服务器应用具体化了真正分布式应用处理的概念，它们仍留有为某一目标定制的特性，规模和管理能力都有限。
更重要的，这些应用只停留在较细粒度的数据访问上，使得整个应用系统宛如磐石，不能有效地利用网络资源。
面对更大规模的关键业务应用，如要进行有效的分布式处理，就要求从客户/数据库方案转变到三层客户/应用系统/数据服务器结构。
以后者为核心的组件软件模型是客户/服务器计算的拓展，它支持应用分区，能有效地开发和调度应用业务逻辑，管理分布式应用的可靠执行。
BEATUXEDO采用三层结构的组件软件模型。
图2表示BEATUXEDO的组件软件模型的概要。
该结构分为三层：
BEATUXEDO的组件软件模型概要
●
客户为第一逻辑层，实现用户交互和数据表示，向第二层的服务器请求调用核心的业务逻辑处理服务，比如数据库的读取和更新。
●中间层为服务器组件，这些组件由BEATUXEDO管理，实现核心的业务逻辑服务并将这些服务按名字广播,接受并处理从客户或其他服务器发出的请求这些服务的消息，并将处理结果返回给请求者，即客户或其他服务器。
●资源管理器，比如像关系数据库，构成模型的第三层，负责管理应用系统的数据资源。
服务器组件在完成服务的过程中通过资源管理器存取它管理的数据，或者说请求资源管理器的数据服务。
相对于以数据库为中心的的两层客户/数据库服务器模型，BEATUXEDO的三层结构模型将客户/应用服务器/数据库将应用的业务逻辑和用户界面的表示分开。
这样就允许开发人员专注于应用的核心业务逻辑的划分、封装、与相互作用，快速建立系统的核心业务功能的原型。
另外，明确地划分界面表示和业务逻辑，对用户有效地管理应用系统也是意义重大。
对具有成百上千个客户的两层结构的系统来说，经常性的更新、升级系统是一项十分棘手的维护工作，尤其是当系统已经投入实地运行以后。
三层模型将用户交互的表示部分与内部的业务逻辑分开，这样对业务逻辑的一些修改甚至数据库模式的改动经常都不要求客户的改动。
而且，将核心业务逻辑组件和表示逻辑及数据层划分开，BEATUXEDO可以在服务级别上非常有效地管理应用的运行。
它可以动态地管理消息流程和服务请求，快速启动和停止服务器,根据变化的负荷复制服务器，动态地广播、撤消服务器中的服务，将服务从一个服务器转移到另一个服务器等等。
这些对中间层应用的服务级别上的管理大大增加了分布式应用的伸缩性和灵活性。
三、TUXEDO系统结构及实现原理
BEATUXEDO的组成与功能
BEATUXEDO应用程序既可服务于带有少量客户和服务的单个服务器系统，又可服务于由成千客户、成百服务器和众多服务器组件和服务构成的大规模的分布式环境。
一个这样的应用程序是以业务逻辑服务、由这些逻辑服务组织成的高层服务器组件和在服务器结点环境中的组件分布为特征的。
支持这种虚拟主机环境的BEATUXEDO元素包括配置信息库和实现运行时应用管理的核心子系统。
工作原理
Tuxedo是BEA公司的交易中间件产品，1984年由贝尔实验室开发成功，1992年易主Novell公司，1996年由BEA公司收购，经过十多年的不断更新和完善，Tuxedo已经发展成为交易中间件领域事实上的标准。
Tuxedo可以有效地整合企业异构C/S系统，实现大规模的关键业务处理和分布式事务管理，从而为企业提供一个可靠的、高性能的、易维护的三层分布式计算机环境。
图1展示了一个基本Tuxedo系统的组成和工作原理。
① Client向System/T发出查询请求，以找到Server消息队列的地址；
② Client根据找到的入口地址将请求发送到Server的消息队列中；
③ Server处理请求，并将结果返回给Client的消息队列。
System/T是Tuxedo系统的核心，它实现了Tuxedo的所有功能和特征，如C/S数据流管理、服务请求的负载均衡、全局事务管理以保证交易的完整性、同步/异步服务请求、两阶段提交以确保消息的发送等。
System/T提供了一个类似公告栏的服务，用以发布C/S计算机环境中所有服务器、服务和客户机的信息，供其它分布式计算的参与者使用。
下面将通过一个大写字母转换的简单例子，讲述Tuxedo应用程序工作的基本原理和开发方法。
1．配置信息库
BEATUXEDO应用程序由配置文件指定，这些配置文件被转换成若干紧耦合的运行时共享信息库。
这些共享库（在BEATUXEDO中称公告牌，BulletinBoard）驻留在每个参与应用的服务器结点上。
BEATUXEDO子系统访问和操作这些库。
应用程序配置
一个BEATUXEDO应用程序包括在一个高度分布的环境中运行该应用所需的资源。
开发人员编写服务的代码，应用管理员通过构造定义操作参数和资源分配的配置文件创建应用程序。
配置信息驻留在一个可编程访问的管理信息库（MIB）中。
MIB最少包括下列配置信息：
●系统范围的资源，包括有关全局应用属性（如安全性级别）、是否进行负载平衡、启动一个应用系统所需的资源定义和故障恢复时所需的资源定义。
●参与应用的每个服务器机器的定义和驻留在这些机器上的BEATUXEDO文件的规格说明。
●单个服务器可与其他组成员共享的资源组，如事务管理；组也定义了服务器和所操作的资源管理器之间的映射。
●服务应用程序所需的映射成进程的服务器，在这些服务器进程中实现了应用业务逻辑。
一个BEATUXEDO配置允许一个管理服务器或者从分布在一台/多台机器的一个/多个组中配置多个服务器。
●应用服务器进程定义的服务；服务级的属性包括负载因子、服务处理时间的相对量、该服务相对于服务器中提供的其他服务的优先级。
前三个配置属性定义了应用的处理元素（如处理结点）、全局属性和某一主资源的特殊指定。
组、服务器和服务集中在BEATUXEDO软件组件模型的分布式应用资源上：
BEATUXEDO应用程序定义了提供所需服务的服务器组件分组；可配置的服务器实例数量能在多个机器上调整；而且，BEATUXEDO能管理广播的单个服务和它们的相对优先级。
公告牌
BEATUXEDO应用配置文件被映射到一个运行时数据结构:
公告牌（BB）。
BB作为一个从配置文件中派生出来的共享信息库。
BB驻留在每个参与到由配置文件指定的应用程序的BEATUXEDO的服务器结点上。
BB作为分布式应用的名字服务数据库。
它作为应用统计数据的运行时仓库，提供分布式环境下的应用对象的位置信息。
BB由BEATUXEDO核心例程（对应用开发者透明）访问，由核心例程读/修改BB库。
这个信息库提供BEATUXEDO完成动态客户/服务器映射所需的信息，同时也提供完成诸如负载平衡、安全性和事务协调等功能的信息。
2．核心子系统
下面叙述的核心子系统包括：
●事务管理器
●工作站
●域
●与DCE的集成
●队列服务
BEATUXEDO组件之间的关系
事务管理器
事务管理器是BEATUXEDO体系结构的中心，它是每个BEATUXEDO服务器的核心，提供重要的分布式应用服务、命名、消息路由、负载平衡、配置管理、事务管理和安全性。
它也包含BB结构，使用维护和访问BB信息的服务。
换句话说，BB内包含有可靠执行和管理大规模的基于组件的应用程序所需的所有信息，它将对事务管理器进程起作用。
事务管理器的基本操作见下图的图示。
事实上，事务管理器是负责客户/服务器绑定和支持BEATUXEDO虚拟主机属性等特色的子系统。
来自网上的客户请求到达驻留在服务器上的客户代理进程，服务器通过注册参加到该应用中。
作为客户方通讯的一部分，事务管理器访问BB，然后选择服务器，接着，服务器消息队列的地址被返回，客户方的请求被马上传送到合适的队列等待服务为它进行处理
本节讨论一些关键属性：
1）名字服务/位置透明性
BB作为BEATUXEDO应用程序的名字服务器，复制到每个参与的结点上。
为了便于快速访问，名字服务器作为在共享内存中的一个结构存在。
事务管理器使用BB名字信息、配置信息和环境统计信息自动把服务请求平衡到可用的服务器上，并且根据数据内容为客户请求选择路由，为服务请求选择优先级。
编程员把应用程序编成对逻辑入口项（称有名服务）的函数调用。
事务管理器把这些逻辑请求映射到服务器结点/服务器进程环境内指定的服务实例。
2）数据依赖型路由
数据依赖型路由是根据数据缓冲区中一个指定域的值，把一个服务请求映射到一个指定的服务器组的机制。
因为BEATUXEDO服务器组映射成指定的资源管理器/数据库实例，所以请求被导向到一个指定服务/资源管理器的组合。
例如，一个银行的数据库可把存储在不同数据库实例中的不同范围的帐号进行水平分区。
用户可用事务管理器进行路由选择，而不用把特定分区信息编码成访问帐号的应用代码。
事实上，事务管理器查看指定的数据值，参考存储在BB中的路由信息，然
升级会员 