tuxedo培训教程
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
BEA TUXEDO
简易培训教程
编写、整理 :文栈良
2003-1-21
第一章认识tuxedo
1.1 TUXEDO是什么?
BEA TUXEDO是在企业、Internet 这样的分布式运算环境中开发和管理三层结构的客户/服务器型关键任务应用系统的强有力工具。
它具备分布式事务处理和应用通信功能,并提供完善的各种服务来建立、运行和管理关键任务应用系统。
开发人员能够用它建立跨多个硬件平台、数据库和操作系统的可互操作的应用系统。
BEA TUXEDO是企业、Internet 分布式应用中的基础主干平台。
它提供了一个开放的环境,支持各种各样的客户、数据库、网络、遗留系统和通讯方式。
BEA TUXEDO使分布式关键任务应用系统具有大型主机的性能,从而使这些应用系统能够应付数以千计的用户,大交易吞吐量,多并行数据库存取和大量数据,同时保持较短的反应时间,较高数据完整性和安全性,并且确保全年365天,每周7天,每天24小时的系统可用性。
同时,BEA TUXEDO还能让开发人员和系统管理人员享用分布式运算环境提供的好处,如技术成本的低增长率,灵活性提高,快速应用开发和安装以及业务信息存取得以改善。
1.2 BEA TUXEDO的组件软件模型
关键业务应用通常是面向事务的,要求具有准确的数据完整性、
较好的性能和管理需求。
这些需求要求对应用的开发、调度和操作给出一个结构化的方案。
由像BEATUXEDO这样的中间件支持的组件软件模型为分布式环境处理关键性业务应用提供了一个结构化的解决方案。
BEA TUXEDO和基于组件的应用设计从异构的计算资源中创建了一个虚拟主机:在分布式应用系统级提供可管理的相互关联的资源。
许多组织在进行了一段时间的分布式应用工作后,现在已经认识到组件软件模型是他们的必然选择。
分布式应用的直接动力是主机应用和集中式中规模的应用系统基础上又逐渐配备有大量的台式系统和服务器系统,这些分布式系统在标准网络传送协议的支持下,呈松散耦合的态势,事实上它们构成了网络计算资源的基础。
在开始的时候,分布式系统主要服务于把集中式系统的前台应用迁移到网络环境----主要用台式处理器和文件服务器实现文档处理和电子邮件通讯应用系统。
接着,两层的客户/服务器数据库应用在部门级被采用,这类应用把交互式文件共享进化到并发数据元素访问,在数据级支持更细粒度的管理。
虽然这些客户/服务器应用具体化了真正分布式应用处理的概念,它们仍留有为某一目标定制的特性,规模和管理能力都有限。
更重要的,这些应用只停留在较细粒度的数据访问上,使得整个应用系统宛如磐石,不能有效地利用网络资源。
面对更大规模的关键业务应用,如要进行有效的分布式处理,就要求从客户/数据库方案转变到三层客户/应用系统/数据服务器结构。
以后者为核心的组件软件模型是客户/服务器计算的拓展,它
支持应用分区,能有效地开发和调度应用业务逻辑,管理分布式应用的可靠执行。
BEA TUXEDO 采用三层结构的组件软件模型。
图1 表示BEA TUXEDO 的组件软件模型的概要。
该结构分为三层:
图1 BEA TUXEDO 的组件软件模型概要
1.3 TUXEDO 的特点
1.3.1.减轻开发人员负担
BEA TUXEDO的三层结构组件软件模型将用户界面的表示部分和业务逻辑部分按客户组件服务器组件分开,使开发人员能够按组件的思想专注入于业务逻辑的开发,用户界面部分可用流行的前端开发工具来快速完成。
而客户和服务器之间、服务器和服务器之间的通讯,异构平台之间的数据变换,以及服务器和数据库之间的集成和事务控制都由BEA TUXEDO 来完成。
当数据库或服务器端的业务逻辑改变
时,客户端则不一定要改变;反之当客户改变或增加新的客户界面时,服务器端则不一定要改变,大大增加了应用系统的各部分的可复用性。
BEA TUXEDO提供的简洁API 使用户程序能够物理地点透明地在客户和服务器之间、服务器和服务器之间进行各种方式的通讯,极大地减轻开发人员的负担。
BEA TUXEDO提供的通讯方式有同步RPC调用,异步RPC调用,对话通信方式,广播通讯方式,异步存储转发队列通讯,事件通讯方式等。
1.3.2.使系统的安装与升级更容易
在BEA TUXEDO 的三层结构组件软件模型下开发的应用程序以服务器组件和客户组件为安装、升级的单位,当一个组件需要更新时,管理人员甚至能够在运行系统不停机的情况下完成系统的升级,这在客户端为数以千计的关键任务应用中尤为重要。
1.3.3.减轻系统管理人员负担
BEA TUXEDO系统提供从一个中心点对整个分布式系统进行全局监控及管理的能力,管理员根据一个整体系统视图(而不仅是单个节点或单元)提供的信息,可以作出决定和采取动作。
BEA TUXEDO不但提供了一些管理命令,而且提供了一个集成的图形界面管理工具,集中地监视和管理应用系统的运行,并且可动态地修改系统配置。
通过Java的 applets,还可利用 Internet的浏览器比如Netscape
或Microsoft的Explorer来运行该图形界面管理工具。
此外,BEA TUXEDO还提供了描述系统中各对象的管理信息数据库(MIBS)和存取管理这些管理信息数据库的管理API,用户可利用这些管理API,编写自己特有的管理工具。
1.3.4.非常高的性能
一方面,BEA TUXEDO能够使多个客户连接到一个服务器进程,由这个服务器进程存取数据库,为客户的请求服务。
这样,数据库为处理连接所需的资源大大减少。
另一方面,客户和服务器之间,服务器和服务器之间的通讯中,网络上流动的只有相对较少的客户或服务器的请求和服务器处理的结果,而不再是两层结构中客户和DBMS 之间的大量SQL请求和应答。
此外,利用BEA TUXEDO特有的一些机制也能极大提高应用系统的性能。
比如利用异步RPC机制实现扇出并行,利用转发机制实现流水线并行,利用多服务器单队列实现多处理并行等。
所有这些因素使BEA TUXEDO的应用系统具有极高的性能。
世界上大部分硬件服务器的TPC 性能指标都是在BEA TUXEDO上完成的。
1.3.5.更高的可用性
BEA TUXEDO随时知道它控制下的资源的情况,并利用这些信息为应用提供最大可用性。
分布式系统使资源故障的影响复杂化。
在一个分布式系统中,多个节点代表更多的潜在故障点的可能,但也可以
代表在资源恢复开始时在其他节点上重新分配工作的更大潜力。
BEA TUXEDO在这种分布式系统故障恢复上具有优势。
TUXEDO将重启应用进程, 并且能在硬件故障情况下在其它结点上重新运行进程。
1.3.6.分布式环境中更高水平的数据完整性
BEA TUXEDO设计了数据资源的绝对完整性。
目前出现的客户/服务器应用中,重要数据资源很可能是广泛的,而且受异构系统的控制。
应用可以设计成用严格的保证数据一致性的两阶段提交,或者用更多的缓冲存储和转发技术来管理异构的(或者同构的)数据库的更新。
在各种情况下,BEA TUXEDO能够确保异构的(或者同构的)数据库以及它资源管理器之间的完整性。
1.3.7、系统的安全性
BEA TUXEDO通过结构化用户界面支持应用服务的验证、授权和存取控制,允许用户加入自己的验证服务模块。
BEA TUXEDO还提供信息加密服务,允许对网络上传输的信息按RSA 的RC4算法加密。
目前美国本土内可按128位,本土外可按40位加密。
1.3.8、开放系统中最开放的中间件平台
BEA TUXEDO是一个非常开放的平台,支持三十多种服务器平台,包括大多数的 UNIX服务器,WindowsNT 服务器,IBM的S/370,S/390,
加上AS/400和 Tandem公司的 NonStop系统。
它的客户支持几乎所有
的工作站,包括 UNIX,MS-DOS,Windows3.1/95, Windows NT, OS/2,Macintosh等。
BEA TUXEDO支持X/Open组织的分布式事务
处理模型DTP,事务定界标准TX, 应用程序事务处理接口标准XA TMI以及和资源管理器(像数据库系统)的接口标准XA,并且还
支持事务处理器之间的互操作标准OSI-TP。
BEA TUXEDO的客户端通
过DLL 可以和Visual C++、Visual Basic、 Power Builder、 SQL Windows、Delphi、Develop/2000 以及其他4GL和CASE 工具互连。
此外,BEA TUXEDO还得到其他第三方开发管理工具厂商的支持。
1.3.9、系统的伸缩性
简单地说,软件可伸缩性就是可以很容易地增加被支持的用户数
和应用的全局吞吐量。
一个可伸缩的软件系统是利用网络分布系统优势的关键。
BEA TUXEDO提供的就是这样一个系统,它可以利用在一个网络上所能找
到的所有的异构的资源以获得最大的效益。
BEA TUXEDO提供这一点,而且提供许多可伸缩性选项。
垂直方向的可伸缩性代表的含义与通
常相同,即将系统转变(升级)为一个更大,更有力的相同或不同结
构的平台。
水平方向的可伸缩性多是在分布式系统结构中,它以增加
适当规模的附加系统来增强网络应用。
所增加的附加系统与原有系统
可能是同构的,也可是异构的(那就是不同的处理机或操作系统)。
BEA TUXEDO支持二维的可伸缩性。
二维可伸缩性可在结构上的任
意位置添加异质资源,而不改变已存在的应用的结构。
允许对一个复杂的混合结构的支持,为联机网络系统提供了广泛的规模选择范围。
任何与数据表示有关的(如不同的处理器表示)可以由 BEA TUXEDO透明地解决。
BEA TUXEDO 还可根据系统负荷的变化动态地增加或减少应用服务器的个数。
1.3.10、广泛的开发工具支持
除了像C,C++和COBOL这样的第三代语言编程环境,BEA TUXEDO 系统享受最广泛的第三方工具的支持,下面是开发BEA TUXEDO应用目前可用工具的一个列表。
表1 TUXEDO允许的开发工具选择
此外 BEA TUXEDO 的关联产品BEA CONNECT 允许BEA TUXEDO 和IBM的CICS、 IMS、 Unisys的System2000进行互操作,BEA Jolt 支持从Internet 浏览器上请求BEA TUXEDO 的服务。
BEA Builder 和BEA Manager将BEA TUXEDO应用的开发与管理更为简化。
1.4BEA TUXEDO 的组成与功能
BEA TUXEDO 应用程序既可服务于带有少量客户和服务的单个服务器系统,又可服务于由成千客户、成百服务器和众多服务器组
件和服务构成的大规模的分布式环境。
一个这样的应用程序是以业务逻辑服务、由这些逻辑服务组织成的高层服务器组件和在服务器结点环境中的组件分布为特征的。
支持这种虚拟主机环境的BEA TUXEDO 元素包括配置信息库和实现运行时应用管理的核心子系统。
1.配置信息库
BEA TUXEDO 应用程序由配置文件指定,这些配置文件被转换成若干紧耦合的运行时共享信息库。
这些共享库(在BEA TUXEDO 中称公告牌,Bulletin Board)驻留在每个参与应用的服务器结点上。
BEA TUXEDO子系统访问和操作这些库。
(1)应用程序配置
一个BEA TUXEDO应用程序包括在一个高度分布的环境中运行该应用所需的资源。
开发人员编写服务的代码,应用管理员通过构造定义操作参数和资源分配的配置文件创建应用程序。
配置信息驻留在一个可编程访问的管理信息库(MIB)中。
MIB最少包括下列配置信息:
●系统范围的资源,包括有关全局应用属性(如安全性级别)、是否
进行负载平衡、启动一个应用系统所需的资源定义和故障恢复时所需的资源定义。
●参与应用的每个服务器机器的定义和驻留在这些机器上的BEA
TUXEDO文件的规格说明。
●单个服务器可与其他组成员共享的资源组,如事务管理;组也定
义了服务器和所操作的资源管理器之间的映射。
●服务应用程序所需的映射成进程的服务器,在这些服务器进程中
实现了应用业务逻辑。
一个BEA TUXEDO配置允许一个管理服务器或者从分布在一台/多台机器的一个/多个组中配置多个服务器。
●应用服务器进程定义的服务;服务级的属性包括负载因子、服务
处理时间的相对量、该服务相对于服务器中提供的其他服务的优先级。
头三个配置属性定义了应用的处理元素(如处理结点)、全局属性和某一主资源的特殊指定。
组、服务器和服务集中在BEA TUXEDO软件组件模型的分布式应用资源上:BEA TUXEDO应用程序定义了提供所需服务的服务器组件分组;可配置的服务器实例数量能在多个机器上调整;而且,BEA TUXEDO能管理广播的单个服务和它们的相对优先级。
(2)公告牌
BEA TUXEDO 应用配置文件被映射到一个运行时数据结构:公告牌(BB)。
BB 作为一个从配置文件中派生出来的共享信息库。
BB 驻留在每个参与到由配置文件指定的应用程序的BEA TUXEDO 的服务器结点上。
BB作为分布式应用的名字服务数据库。
它作为应用
统计数据的运行时仓库,提供分布式环境下的应用对象的位置信息。
BB由BEA TUXEDO核心例程(对应用开发者透明)访问,由核心例程读/修改BB库。
这个信息库提供BEA TUXEDO完成动态客户/服务器映射所需的信息,同时也提供完成诸如负载平衡、安全性和事务协调等功能的信息。
2.事务管理器
事务管理器是BEA TUXEDO 体系结构的中心,它是每个BEA TUXEDO 服务器的核心,提供重要的分布式应用服务、命名、消息路由、负载平衡、配置管理、事务管理和安全性。
它也包含BB结构,使用维
护和访问BB信息的服务。
换句话说,BB内包含有可靠执行和管理大规模的基于组件的应用程序所需的所有信息,它将对事务管理器进程
起作用。
事务管理器的基本操作见下图的图示。
事实上,事务管理器是负责客户/服务器绑定和支持BEA TUXEDO虚拟主机属性等特色的子系统。
图4 来自网上的客户请的客户代理进程,服务器通过注册参加到该应用中。
作为客户方通讯的一部分,事务管理器访问BB,然后选择服务器,接着,服务器消息队列的地址被返回,客户方的请求被马上传送到合适的队列等待服务为它进行处理。
1)名字服务/位置透明性
BB作为BEA TUXEDO应用程序的名字服务器,复制到每个参与的结点上。
为了便于快速访问,名字服务器作为在共享内存中的一个结构存在。
事务管理器使用BB名字信息、配置信息和环境统计信息自动把服务请求平衡到可用的服务器上,并且根据数据内容为客户请求选择路由,为服务请求选择优先级。
编程员把应用程序编成对逻辑入口项(称有名服务)的函数调用。
事务管理器把这些逻辑请求映射到服务器结点/服务器进程环境内指定的服务实例。
2)数据依赖型路由
数据依赖型路由是根据数据缓冲区中一个指定域的值,把一个服务请求映射到一个指定的服务器组的机制。
因为BEA TUXEDO服务器组映射成指定的资源管理器/数据库实例,所以请求被导向到一个指定服务/资源管理器的组合。
例如,一个银行的数据库可把存储在不同数据库实例中的不同范围的帐号进行水平分区。
用户可用事务管理器进行路由选择,而不用把特定分区信息编码成访问帐号的应用代
码。
事实上,事务管理器查看指定的数据值,参考存储在BB中的路
由信息,然后把请求发送到能在正确数据分区上操作的服务。
如果用
户需要改变数据库分区(把一个分区移到一个新服务器上,或在已有
分区实例上改变帐号分布),那么,他只需改变事务管理器的路由信
息,应用程序的代码不受影响。
型路由:帐号操
作的请求与数据
分区是独立的,事
务管理器访问BB
路由表信息,把请
求映射到访问相
应分区的服务器
组,然后返回该组
指定服务的绑定。
3)负载平衡
为了确保应用流量最大,事务管理器自动地在系统中完成负载平
衡和调度。
通过使用每个服务的负载因子,事务管理器把请求发送给
能最快处理该请求的服务器。
事务管理器通过为当前排队的请求总计
负载因子来决定给定服务器上的负载。
下图给出了事物管理器负载平
衡能力如何帮助优化应用流量的一个例子。
图6 负载平衡: 服务 A ,B ,C 由不
同的服务器提供,每
个服务器有一个基
于当前排队请求的
负载值。
事务管理器
决定哪一个服务器提供服务,哪一个服务是负载最小。
事务管理器将在一个给定结点内或在提供服务的若干结点上,进行负载平衡。
4)优先权
请求优先权是事务管理器提供的另一个核心能力。
某一服务请求经常需要比其他服务更高的优先权。
例如,航空公司取消订座的优先级要比订座的优先级高:对大多数航空公司来说,要尽可能地再次买出被取消的座位。
优先权在服务队列级有用,参见下图的图示。
图7 优先权:右例 中,服务 器1提供服务A ,B ,
C 。
A ,B 服务的优先级是
50,C 的优先级是70。
在
上一个请求完成时,服务
器在队列中选择下一个请
求。
下一个请求是由优先级决定的,而不是根据请求在队列中的位置。
为了防止低优先级请求总是得不到服务,每隔十个请求,就按FIFO
次序进行一次请求选择。
5)稳固的运行环境
事务管理器包括许多支持应用可用性的特征,如进程可用性检查、超时检查、自动服务器重启和恢复过程、用户可定义的恢复过程。
事务管理器不仅仅控制应用程序的活动流而且能确保其流畅有效的操作。
6)安全性
事务管理器通过一个结构化的安全性接口提供应用服务的验证、授权和访问控制。
该接口概括了Kerberos安全模型,允许Kerberos 或类似的最终用户验证机制与应用集成。
用户能用访问控制列表保护服务、队列或事件免遭未授权的访问。
7)分布式事务处理
分布式事务处理(DTP)能力能保证跨几个场地访问的数据和由不同数据库产品管理的数据的完整性。
事务管理器协调分布式事务使之完成网络环境下针对异构数据库的多场地修改。
事务管理器用全局事务跟踪事务参与者,管理两阶段提交协议。
这样就可确保每个场地都能正确处理事务的提交和回退。
事务管理器还在出现场地故障、网络故障或全局资源死锁时协调全局事务的恢复。
事务管理器使用开放小组的X/Open XA接口,进行不同资源管理器之间的通讯。
该接口已被X/Open接纳为分布式事务控制的标准接口。
因为高性能和事务流量对OLTP系统产品是关键因素,所以事务
管理器DTP软件使用了最小化磁盘写的算法。
在其他属性中,事务管理器DTP开发了一些众所周知的技术如协调者迁移、只读和一阶段提交优化。
事务管理器由几个关键子系统支持,这些子系统扩展了BEA TUXEDO客户/服务器功能和与异构应用系统的互操作性。
下面的几个段落将描述这些关键子系统:
◎管理
BEA TUXEDO对分布式应用管理的关键性问题给出了一个结构化的解决方案。
BEA TUXEDO的管理接口包括一个综合性的命令行/脚本接口,一个编程接口和一个管理信息库(MIB),它们把BEA TUXEDO 实现成一个更大管理环境中的受控应用程序。
一个易用的基于GUI 的管理应用程序可利用这些管理接口,在BEA TUXEDO环境上提供了高层控制。
BEA TUXEDO资源,从高层的域属性向下贯穿一个单服务器进程的特性,支持图形化表示和拖放功能。
◎集中式的应用定义
事务管理器使得应用管理员可在一个文件中定义组成BEA TUXEDO 应用程序的硬件、软件和网络资源。
应用设计者能叙述在何处运行服务器和服务以及在处理器出故障时服务应该迁移到何处。
他们可把各种不同的特性,包括调度信息、进程恢复标准和超时时间段等,赋给应用服务器。
事务管理器为动态启动、停止或管理一个分布式应用程序提供中央配置管理和工具。
◎动态重配置
用户可动态启动或停止服务;用户可选择可用的服务。
用户可在一个配置中增加新的机器、组、服务器和服务。
另外,事务管理器可用不同的参数如超时故障等,使得一个无法使用的处理器上的服务器和服务在不中断运行程序的条件下移向另一个处理器上。
第二章开发与应用
2.1开发BEA Tuxedo应用程序
在开发BEA Tuxedo应用程序之前,你需要先搞清楚一系列和设计开发相关的概念,如识别什么是客户机,有哪些方法可以从外界收集数据并提交服务器进行业务处理;识别什么是服务器,哪些程序包容了可以处理客户机输入的商业逻辑;识别什么是类型缓冲区,客户程序在向其这程序发送数据前如何分配内存区域;什么是BEA Tuxedo的消息范例等。
最后你还要弄明白客户程序是通过调用ATMI 库来访问BEA Tuxedo系统的。
创建BEA Tuxedo的客户程序与在C和C++编程语言中创建其它应用程序一样,BEA Tuxedo提供了一个其于C语言的编程接口,即应用程序事务监控接口ATMI,这套接口很容易使用,以便用于开发客户程序和服务程序。
除了C语言接口外,BEA Tuxedo还提供了COBOL 接口。
2.1.1创建服务程序
2.1.1.1 概述
尽管开发者使用ATMI编程接口来创建BEA Tuxedo客户程序和服务程序,但服务程序不全部由开发者来编写,开发者只需写一些称为服务的商业函数,封装业务逻辑,然后和BEA Tuxedo的一些二进制程序联编成一个可执行的服务程序。
BEA Tuxedo服务程序启动后,它总是保持运行状态,只到接收到一个shutdown消息为止。
一个典型的BEA Tuxedo服务程序在shutdown或reboot之前都在执行着数千个服务。
2.1.1.2 服务的运行流程
为了更好的了解服务端的所有任务以编写服务端应用,有必要重新认识服务端在C/S模式中扮演的角色。
首先,服务是系统资源的联系点。
例如,一个数据库服务联系实际数据库并对其进行查询和修改。
为有效进行,应建立一个数据库连接。
其次,服务必须发布系统内可以访问的交易,保证客户端可以知道把请求发往何处。
以上两步结束后,服务进入一个循环——接收请求、处理请求并返回结果。
接收请求包括进入消息队列,得到交易请求。
处理请求包括检查请求数据缓冲,运行商业规则和逻辑,可能还包括访问数据库和返回结果数据缓冲。
当系统管理员需要关闭系统,可以通过系统管理工具将关闭系统的消息发给服务。
服务完成所有交易,取消交易发布,关闭资源连接然后结束。
2.1.1.3 服务程序的任务
(1)在BEA Tuxedo服务程序启动时,执行tpsvrinit()函数,可以
在里面打开一些如数据库之类的资源供以后使用;
(2)在BEA Tuxedo服务程序关闭时,执行tpsvrdown()函数,可
以在里面关闭tpsvrinit()中打开的资料;
(3)BEA Tuxedo服务程序以服务的形式来响应客户程序的请求,
客户程序不是通过名字来调用服务程序的,而是调用服务,客户程序不知道处理它请求的服务程序的位置;
(4)服务程序调用tpreturn()函数来结束服务请求,并返回一个缓
冲区,必要时,将它传给客户程序;
注:如果是在tpsvrinit()中连接数据库,为了保证数据库的正常连接,在执行服务的时候,最好能够判断数据库是否断开连接,如果断开连接,则重新连接数据库。
这样可以从根本上保证系统能够持续稳定的长期运行,基本上不需要人工干预。
也就不再会出现“数据库重启了,中间件必须重启”的情况。