基本上需要在WCF服务和Java客户端之间传输大文件，有人可以指路吗？
基本上，我需要创建一个 wcf 服务，该服务需要读取 blob 内容（实际上是存储在 db 列中的文件内容）并将其传递给 java Web 应用程序（作为 wcf 的客户端）。
文件大小可能从 1kb 到 20MB 不等。到目前为止，我已经研究/检查了下面的选项，但仍然无法最终确定我应该使用哪个选项，哪些可行，哪些不可行，有人可以指导我吗？
-
将文件内容作为 byte[] 传递：我知道它会增加传递给客户端的数据大小，因为它会将数据编码为 base 64 格式并将 base 64 编码嵌入到 soap 消息本身中，从而使通信速度变慢并出现性能问题。但这肯定有效，但我不确定是否建议采用这种方法。
-
共享客户端和 wcf 服务应用程序均可访问的 NetworkDrive/FTPFolder：根据客户端需要的这个文件，首先由 wcf 存储在那里，然后客户端需要使用 java I/O 或 FTP 选项来读取它。从数据大小/带宽的角度来看，这看起来不错，但在服务和客户端都有额外的处理（因为需要通过网络共享/FTP 文件夹存储/读取）
- 流媒体：我不确定这个在 Java 客户端上是否可行，但我的理解是非 .net 客户端支持流式处理，但我不确定如何去做???我知道对于流媒体，我需要使用 basichttp 绑定，但我是否需要使用 DataContract 或 MessageContract 或任何将起作用，然后在 java 客户端要做什么，我不确定。
- 使用 MTOM 方法在 SOAP 请求中传递大数据：这看起来实际上具有专门设计用于解决 Web 服务调用中的大型数据传输的支持，但必须对此进行进一步调查，到目前为止，我对此没有太多想法。你们中有人对此有什么建议吗？
我知道问题有点长，但我必须把我尝试过的所有 4 个选项以及我的担忧/发现放在每个选项中，以便你们都可以在这些选项或新选项中提出建议，您也会知道我已经尝试过什么，因此可以指导我更有效的方式。
我和你处于相同的位置，我可以从经验中说，选项 1 对于超过几 MB 的任何东西来说都是一个糟糕的选择。
在我自己的系统中，上传时间呈指数级增长，25MB 文件需要超过 30 分钟才能上传。
我已经运行了一些计时，其中大部分是将文件从 .NET 客户端传输到 Java Web 服务。 我们的网络服务是一组第三方服务的门面;使用第三方提供的内置客户端（在业务环境中不可行）要快得多 - 25MB 文件不到 5 分钟。上传到我们的客户端应用程序也很快。
我们已经尝试了MTOM，除非我们正确实现它，否则没有看到巨大的改进（速度提高不到10%）。
下一个停靠港将是选项 2 - 文件传输相对较快，因此通过将文件直接上传到其中一个 Web 服务主机，我希望这将大大加快速度 - 如果我得到一些有意义的结果，我会将它们添加到我的帖子中。