信息来源:邪恶八进制信息安全团队
作者：sqlcode时间：01-11-15 14:54
两大卖点：资源级事务、可靠消息队列；
优点：
1. 系统采用C/C++开发，执行效率高于JAVA,适合于OLTP系统;
2. Tuxedo以API方式屏蔽系统细节，简化编程,以较少的API函数调用即可开发一个应用;
3. 可以多个Server并行处理,提高处理能力,扩充性非常好,可以根据当前负载动态启动停止多个Server;
4. 资源级(Queue,Oracle,Informix...)的全局事务保证交易的完整性;
5. 可靠消息队列(Queue)实现数据的可靠传输,而且可以纳入Tuxedo事务中,可以和数据库操作同时提交或者回退,保证系统级事务的一致性;
6. 数据依赖路由,事先确定数据的流向,人工调整系统的负载;
7. 支持分布式系统, Tuxedo/Domain结构中各个域相互独立,通过信任关系调用对方的Service,可以方便复杂系统的划分,支持跨域事务.
8. 提供易于管理的工具,方便地管理整个应用.
缺点：
1. 速度问题: 作为一个适用于OLTP系统的交易中间件,若不采用XA方式,需要用户自己控制事务;若采用XA方式,由于要记录全局事务日志(TLOG),处理非常慢,尤其是处理实时任务时,Server是被动的,发起者调用Server,如果结果要记录到数据库,执行的方式为单条提交,速度更是无法忍受(<100条记录/秒).如果没有数据库,或者文件操作,速度非常快.但是一般情况下结果都是要入库的.
作为Tuxedo一大卖点的可靠队列(Queue)速度更是无法忍受, <50条/秒
BEA建议在实时处理中打包（几十条）处理，速度确实提高很多，但失去了实时的意义，而且要控制打包和拆包，按记录字段路由等Tuxedo优势都丧失了。
2. 增加了开发、调试、测试的复杂度: 开发Server使用C语言(访问数据库嵌入SQL,如:Pro*C),实现业务逻辑;前台使用可视化开发环境,用来输入数据和显示数据. 开发任务比两层结构多了很多,如果再使用存储过程,调试需要前台界面、后台Server、存储过程协调进行，大大增加了调试的复杂度，而且一般的开发队伍中都是做前台界面的专门做界面，开发后台的专门做后台，这样组装调试就更加困难了。
3. 事倍功半的查询处理: 交易处理开发复杂还划算，因为毕竟Tuxedo带给了我们并行、可靠、全局事务等好处，但是使用三层结构做查询处理就太亏了，本来就是简单的给一个条件查出结果显示就OK了，现在要前台输入查询条件，传送给Tuxedo Server,Tuxedo Server根据输入的条件查询数据库，再把数据传送给前台。在Tuxedo中一般使用FML传送数据，若结果有很多，还要控制翻页等功能，复杂得一塌糊涂。若使用两层结构（如PB/VB+Oracle），举手之劳！
4. 其它问题:
a. 域Server(GWADM)经常DOWN,不报任何错误,BEA正在解决;
b. 多机的跨域事务经常无法提交,不报任何错误;
c. QUE在网络不是特别好的情况下,居然会不先进先出(设置了FIFO).
其它小的问题多多....
在开发人员眼里,任何工具总是好多缺点,但是Tuxedo毕竟是中间件业界的老大,它提供给了我们许多优越的特性.其它中间件问题比Tuxedo还要多.
而且BEA在中间件和应用服务器行业绝对是老大哥,“世界1000强”企业排名中的全部24家电信公司,世界最大的前40家电信公司中的38家都是BEA的客户.
Tuxedo作为TPC-C测试的首选中间件平台（80%以上）, IBM,HP都有自己的中间件,但是测试无一例外都选择了Tuxedo.足以见得TUXEDO的实力.
欢迎同行多多交流, 互相学习!
作者：sameway时间：01-11-16 02:00
这篇文章不错，继续,朋友!
作者：蚂蚁没问题时间：01-11-22 14:50
不知道你关于速度的结论是怎么来的？
我现在做的系统采用tuxedo7.1做的一个省的radius认证.
速度没有问题。不过那一块我倒不是很熟悉，不太清楚那部分程序的处理方式。
作者：sqlcode时间：01-11-22 17:33
速度结论是这样得到的,在真的环境中非常慢,最初怀疑是程序写的有问题,我做了一个最简单的例子,略掉了所有的处理细节,速度仍然不理想.
radius认证全部是文件处理,当然没有问题了.如果你有兴趣,可以加上数据库操作,再加上QUE操作试试就明白了.
作者：蚂蚁没问题时间：01-11-23 09:01
不，我们的radius是用数据库认证的。
我记得在一台sunE3500上同时跑数据库(ora8.1.6)和radius都能达到每秒至少100左右的认证速度。具体多少不记得了。
作者：sqlcode时间：01-11-23 12:28
哦, 我了解的大部分radius都是文件操作的.浅薄了.
因为Tuxedo的Server是被动的,如果有数据入数据库的操作, 每次client调用Server是一个事务;如果每条清单调用一次,那么对于数据库来说就是单条提交的,性能可想而知.
我在SUN 450上做的测试, 非常简单的处理, 100条左右.
作者：larryh时间：01-11-23 23:47
懂的人不多，但是中间件3层结构是未来应用架构的唯一出路，再难也得至少搞懂原理。
此外，第一篇的结论比较武断，IBM RS/6000参加TPC-C测试全部采用IBM的TXSeries，从来不用Tuxedo，结果很好。
TXSeries功能比TUXEDO强大得多，IBM软件传统如此，但是很多东东较少用到，价格也不便宜，所以用的人少。
作者：sqlcode时间：01-11-24 17:00
98(99)年的TCP-C测试IBM确实是采用的TUXEDO,我刚查了一下今年的TPC公布的结果,好多都改用MICROSOFT COM+了,包括IBM.而且测试平台好多用2000了.
不过TUXEDO在中间件市场的占有率要比IBM高好多,98年40%多,现在可能有所下降吧.
但是TUXEDO好多不便之处也限制了它的进一步发展,它本身是一个中间件的开发/运行/管理环境,如果采用WEB前台,需要JOLT,甚至和BEA WEBLOGIC的连接都非常的不便,而目前多层应用都是强调易于整合,就像HP BLUESTONE一样,本身就是一个整合的环境.
TUXEDO在国外曾红极一时,国内大规模地使用TUXEDO一般都是电信、银行等有钱单位.
目前应用服务器领域里,人们更关注J2EE,因此基于过程的中间件自然逐渐没有了市场.现在BEA WEBLOGIC是他的主打产品, TUXEDO已经是日暮西山了.
作者：sqlcode时间：01-11-24 17:38
To larryh
关于武断一说,请看如下资料:
BEA TUXEDO是BEA公司的主要产品，市场占有率达44%，最早由AT&T贝尔实验室开发，拥有16年多的应用历史。是所有硬件厂商和数据库厂商在进行TPC-C测试时首选的中间件平台，充分体现了BEA TUXEDO在技术上的领先性。在1999年6月公布的TPC-C最新结果中，性能前十名中有8名采用BEA TUXEDO，而性能价格比前十名则全部采用BEA TUXEDO。
作者：larryh时间：01-11-26 17:03
To sqlcode:
我不会随便说人武断的，你看你在前面说的什么：Tuxedo作为TPC-C测试的首选中间件平台（80%以上）, IBM,HP都有自己的中间件,但是测试无一例外都选择了Tuxedo. 足以见得TUXEDO的实力.
1. TPC-C版本5的测试结果中，58个平台，只有10个用TUXEDO，IBM 16个平台，只有2个用TUXEDO；TPC-C上一版本（版本3）中，233个平台，120个用TUXEDO，IBM有22个平台，有5个用TUXEDO。80%？IBM、HP无一例外？
2. 上面帖子的资料没有一条可以证明那句话，连IBM、HP的字样都没有。前面说80%的时候，并没有说时间、范围，上面帖子才把范围限定到1999年6月、性能前十名。
不好意思，我是学数学的，容不得断章取义，信口开河。该严谨时当严谨。
作者：larryh时间：01-11-26 17:09
补充：就算只算早的，97-99年，TPC-C测试结果中，IBM 8个平台，也只有2个用TUXEDO
作者：sqlcode时间：01-11-26 17:44
多谢指正
作者：larryh时间：01-11-26 21:19
我对中间件和应用服务器只知结构，对数据库的道理基本知道，具体产品也不是那么熟悉，这方面还要向你和诸位高手多多学习。
作者：cyber_hu时间：01-11-28 19:37
TUXEDO在中小商业银行还挺普及，便宜。但各位的资料恐怕是各个厂家的吧。
作者：蚂蚁没问题时间：01-11-28 21:24
To:sqlcode
Re:TUXEDO已经是日暮西山了
几点商榷:
TUXEDO8.0和web logic6.1已经可以通过WTC连接了，不需要jolt，我前两个月调通了几个简单的程序，不过没有在正式应用中测试可靠性等。不过个人感觉还是可以的。
还有我觉得tuxedo不能说是日薄西山了，它和web logic针对的东西是不太一样的，在交易中间件市场它还是绝对的第一。
8月的时候我参加过一次BEA的发布会，其中举了一个tuxedo应用的例子，美国visa信用卡，每秒交易超过10000次。我觉得这很能说明tuxedo的长处所在。
作者：sqlcode时间：01-11-29 21:25
WTC我们也正在测试使用，从jolt升级到wtc感觉很不适应，而且也有好多问题。
我之所以说TUXEDO日暮西山，是和其它产品比较来说的。其它的中间件，象IBM的、HP的都在向整合的方向发展，HP的BLUE STONE就是一个典型的例子。但是毕竟TUXEDO是用C开发的，相对JAVA效率会高很多，适用于要求效率的场合。
不知道BEA会如何处理TUXEDO，是向整合的方向发展，还是继续用一个劳神费力的WTC实现和自己的Weblogic连接。
毕竟做了很长时间基于TUXEDO的开发，我希望TUXEDO能向前走下去。
