我们现在改造一个C/S系统到B/S构架，采用J2EE（或者J2SE）方案，Oracle＋Weblogic。之前C/S结构的时候使用Tuxedo和数据库通信来保证事务。但是我觉得使用J2EE构架后就不再需要Tuxedo来作事务处理了，因为只有一个Weblogic访问数据库，而在J2EE里有很好的事务控制，而且我设计了好几层的池化，我认为不用Tuxedo足够应付大量并发的操作。
但是我对Tuxedo是一点也不懂，个人也不喜欢在构架里使用Tuxedo。我不想因为这一点影响判断，因此请真正对Tuxedo和J2EE熟悉的人指点一二，Tuxedo是否还有必要。
我的感觉：除非你要和非java系统通讯，否则是没必要用这东东乐
正好我所想的，C/S版本的数据库和业务逻辑都写的有够滥。所有的业务逻辑推翻重构是在所难免。我们目前很多逻辑都是在存储过程里实现的，大多情况下Tuxedo只是调用过程而已，而且这个Tuxedo还有瓶颈，老是拖慢系统。当然我不懂Tuxedo，也不知道C/S那帮人是不是没有用好Tuxedo。不过我是能不用就不想用，除非Tuxedo有什么J2EE实现不了的功能。
请板桥里人指点迷津
我对Tuxedo没有太多研究，在前年我就在论坛指出Tuxedo是过渡产品，必将被J2EE淘汰，当时很多公司热衷使用Tuxedo，因此有不少人反对我的观点。
其实现在的趋势是这样的，Bea已经将Tuxedo强大的事务机制转移到Weblogic平台中。
知音呀，谢谢。
我更确信自己的观点了，我要努力把Tuxedo拍出我们的项目，如果我可以说服大家
呵呵，偶的建议是小心而又小心，冷静而又冷静
要多考虑性能的问题。计算你们的系统对实时程度的要求以及高峰时
并发交易数。
比较
servlet直接调用存储过程
和
servlet调用Tuxedo和存储过程哪个快呢？
我想是直接调用存储过程。小心考虑性能还是不用Tuxedo更好！
看得出来楼主本身已经偏向于 J2EE BS 结构，在这种情况下，我认为从项目的需求出发：一、功能上J2EE BS是否能够满足；二、非功能需求，如性能、扩充性等J2EE BS是否能够满足。
如果回答可以的话，的确没有必要使用额外的产品/技术，毕竟没有必要把系统弄的更加复杂。不过Tuxedo在交易处理的性能/完整性有其独到之处，如果你的系统对这方面要求严格的话，一定要验证J2EE BS结构在你的环境下是否真的可以取代原系统。
BTW：Tuxedo决非什么过渡性产品，在大型CS应用中它可是所向无敌，目前还有很多系统都是CS结构的，例如电信/银行/物流等等。而且有很多BS/CS混合的系统。
看得出来楼主本身已经偏向于 J2EE BS 结构，在这种情况下，我认为从项目的需求出发：一、功能上J2EE BS是否能够满足；二、非功能需求，如性能、扩充性等J2EE BS是否能够满足。
如果回答可以的话，的确没有必要使用额外的产品/技术，毕竟没有必要把系统弄的更加复杂。不过Tuxedo在交易处理的性能/完整性有其独到之处，如果你的系统对这方面要求严格的话，一定要验证J2EE BS结构在你的环境下是否真的可以取代原系统。
BTW：Tuxedo决非什么过渡性产品，在大型CS应用中它可是所向无敌，目前还有很多系统都是CS结构的，例如电信/银行/物流等等。而且有很多BS/CS混合的系统。
估计tuxedo是淘汰不了，毕竟b/s不能解决所有问题
幼稚！
我和一个BEA公司的Technical Consulant聊天，他告诉我，他们实施WLS如果遇到性能问题无法解决的时候，有一个暗语，叫做“老办法”。这个老办法就是指的用Tuexdo来解决J2EE中的性能瓶颈。那种说Tuexdo过时或者淘汰的人，最好先问问BEA公司再下结论。Tuexdo是BEA公司的看家法宝，BEA再傻也不会傻到淘汰Tuexdo这么一个赚钱的产品。
我觉得“C/S那帮人”这样的用语应该删除，这种语言会大伤论坛人气，比你经验和能力强的多的人大部分是从C/S走过来的。我们不用Tuxedo但我们有自己成熟的一套通讯框架，在我眼里C/S和B/S差别只是在形式上而已，只不过C/S用Application显示界面，B/S通过浏览器显示界面，只要有良好的通讯框架我觉得C/S和B/S后台软件设计框架除了表示层外还有什么差别
banq 又胡说了！
井底之蛙 呱呱叫
什么井底之蛙，太过份了。
这里是讨论技术的地方，大家都是根据自己的应验和工作的领域得出的结论。不管对不对，提出来一起讨论不是很好吗？
说别人井底之蛙的人能提供一些资料或者链接来证明一下可能会更好。