webservice 大文件传输

压缩一下也是权宜之计，我们以前做过一个，在调用前用gzip压缩一下XML文件，然后收到后再解压缩，压缩比能达到8：1

还有一个是XML解析的时候得用SAX，不能用DOM

有时候业务数据量就是这么大的，而且有时候系统和系统之间的接口就是死的，要么是FTP，要么是中间件，要么是web services，要改起来涉及的系统太多，层层审批的时间可能都超过开发的时间了。

以前做过一个系统，用web services传头行结构的订单信息，测试的时候一点问题没有

但是一上系统发现websphere经常被弄死

后来一查，发现最大的订单有一两万行，光是订单信息的xml文件就有几兆甚至十几兆

但是系统接口是没法变的，就采用了gzip压缩，websphere调优，xml解析优化这些方法

最后优化的效果很好，还是可以用的

If you put large file in SOAP, you will get out of memory error for sure. You need use the attachment of large files. Try to use Axis2 SwA as well as Axis2 MTOM. But remember enable the file caching. When file caching is enabled, the size limit is the available space in your temp directory.

By the way, I think large files should not be put into the database, as the IO probably will write the file to database twice depends on the database. The file will be write to the database transaction log first, and then, it will be committed to the database(which means it will be read and write again depends on your database as well as database configuration). Thus, compare to file system, the performance is much lower.

outofmemory 你还是调一下你的websphere的虚拟机参数吧
，这个问题可以解决的

用FTP多好

http://commons.apache.org/net/

这种场合我一直都是用FTP

俺当年也被javaeye的人因为同样的问题鄙视过了。。。

http://www.javaeye.com/post/221278

参考下吧，用附件的方式，我上传过600多M的文件。

其实我觉得可以用文件下载的方式， 就是把文件打包，压缩，加密。然后把文件放在一个随机生成的临时文件夹里。把文件地址和密码用webService的方式发给客户端。 当客户端收到后SOAP后用文件下载的方式下载和解压文件。完成后发一个SOAP到服务器端，告诉他可以把文件删除。 如果超过一定时间没有回复，服务器端自动删除文件。
我没有实现过，但想着应该不是很难。

比较认同分布式文件系统，传个文件路径
这样有利于系统的维护

对，对于大文件使用DOM效率太低