在速度上BEA Tuexdo要有很大优越性,现在移动公司的BOSS系统基本上使用TUEXDO
J2EE框架不错,但在运行速度上还是稍微欠缺一点

我现在做的是电信项目，目前是如果是查询直接用jsp调用javaBean实现，如果逻辑处理用ejb实现，当需要插入数据或更改数据的时候ejb调用Tuxedo与数据库进行操作。这样考虑是负载均衡的问题，以及与银行的接口程序的一致性！不过项目正在进行中，不知道最后的性能能否保证，以后是不是还需要改动。大家给出意见！

如果没有深入研究，就不应该草率下一些很大的结论。
事实是，Tuxedo目前是BEA的摇钱树，是最赚钱的一个产品，在北京成立了几十人的研发中心，专门进行Tuxedo的开发工作。

两年前我参加中国海关总署的电子口岸项目，系统采用weblogic+tuxedo+oracle，所有业务逻辑都在tuxedo中，weblogic上只有jsp和servelet。因为交易量非常大，这样的系统架构我感觉非常好。据说是BEA公司的人推荐这样做的。直接用jsp或ejb与数据库打交道我想一般的系统都能应付过来，当然与开发水平有关。
tuxedo上的服务是用pro*c也写的，即有C的高速度，又有嵌入SQL的方便，并且是ORACLE的产品，当然性能是最好的。weblogic中用jolt与tuxedo连接。这样的系统架构太复杂，所有是否能将系统各个环节配置到很优化，需要较强的技术支持。如果没有BEA的技术支持，万不得已不要采用这样的架构。

区别大，你理解错了，不是bs结构只有浏览器页面，也可以用java设计的页面去用地层函数访问网络服务器的，cs结构限制了范围，而bs结构不限制范围的，比如说，我的程序在国内，而我程序访问的数据库在国外。

凭空比较C/S与B/S，就像比较windows、linux或spring、EJB那个更好一样没有意义。

BEA的人当然会推荐你上Tuxedo了，呵呵，售前的话你们也当真？
关于性能，楼上没有一个能给出有力证据的，都是在凭空想象

项目需要多高的性能、多大的吞吐量？
一定要上Tuxedo才能达到么？J2EE集群达不到么？
J2EE直接访问数据库 会比J2EE连Tuxedo再访问数据库要慢么？
为了这个性能提升，值得付出增加复杂性的代价么？

搜索到一片文章，其中一段如下，值得借鉴：
Tuxedo的缺点：
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).
其它小的问题多多....

转自：https://forum.eviloctal.com/simple/index.php?t23164.html