大规模访问的性能问题

我也觉得可能ejb都要比web service好点,在这个问题上.

事务我们用买交易中间件,比如Tuxedo,我们现在的问题就是怎样提供给营业部的系统来访问服务,就是说不用webservice,不用socket,还能用什么呢,因为目前就有两个系统要通过我们这处交易层来访问数据库,一个是DEPHI做的,一个就是J2EE的

使用tuxedo之后,tuxedo提供供C++,VB,Delphi,java等多种语言开发客户端去调用tuxedo的服务.

现在就是说我们不但要做tuxedo的服务端还要要封装tuxedo的客户端做为一个中间服务层,让各个系统去调用,各个系统不用管你是怎么把他传来的数据存到数据库中去的

过滤汇总有没有想过？
每一百家的用一台小的web服务+一个数据库（但是放在总部）
当下班之后分时汇总传到大统一服务器。
这时可以用报文，
串过防火墙。
一台小的web也就传个两三百兆的文件
再用C或汇编作一套数据挖掘机。
把重要数据存入大统一数据库
其它数据或存档或刻盘。都行。

总结一下楼主的需求：
1.大并发，录入为主的应用；
2.异构应用，客户程序有J2EE,Delphi；
3.封装数据库访问，提供统一的接口。

我想，用Socket的效率应该更高，但是对于维护不利；
用Webservice或许性能有问题，但我想那不会是瓶颈－－相对于这么大并发的数据库插入操作来说，Application Server相对于数据库来说是很容易通过负载均衡、集群等方式来提高性能的－－你需要担心的是数据库性能是否足够，以及如何提升。

所以我觉得用web service，它的性能不会是一个问题。

个人觉得你对tuxedo的了解好像太少.
tuxedo你可以理解成就是个tomcat,
而你要做的事情就是写一点jsp(对应tuxedo中的开发业务模块),
然后告诉其他人url地址(tuxedo服务入口地址)和传入参数格式(url的参数) ,
至于客户端用IE,用Firefox还是httpunit还是c++或者VB等写的http客户端控件.
这些都不是你要操心的事情.

TUXEDO我了解的是不太多,但是最简单的一条就是领导要求就是不要让别人系统去直接访问TUXEDO的服务端,也就是说别的系统不需要去编写TUXEDO客户端,他只需要把一些数据发给一个WEBSERVICE或是别的服务就可以了,不用去编写TUXEDO客户端

算错了才50M的数据不用这么麻烦。。。。
以为是50G

如果你们的系统不是用来 release 出去的，建议你们考虑 ICE (http://www.zeroc.com) 作为传输层。这个东西比socket方便，比webservice的效率高多了。