2010-07-31 155 views
11

我必须创建一个将大文档转换为不同格式的Java EE应用程序。每次转换需要10秒到2分钟。 SOAP请求将由我也必须创建的客户端应用程序创建。如何处理长时间运行的Web服务操作?

处理这些长时间运行的请求的最佳方式是什么?很明显,该过程需要很长时间才能运行,而无需向用户提供任何反馈。

我可以想出以下几种方式来提供某种反馈,但我不确定是否没有更好的方法,或许是标准化的东西。

  1. 客户端执行来自线程的请求,服务器在响应中发送文档,这可能需要几分钟的时间。在此之前,客户端显示“请稍候”消息,进度微调等。(这似乎很容易实现。
  2. 客户端发送“启动转换”命令。服务器返回某种作业ID,客户端可以使用该作业ID来频繁轮询状态更新或最终文档。 (这似乎是用户友好的,因为我可以显示进度,但也需要服务器有状态。
  3. 客户端发送一个“开始转换”命令。服务器以某种方式通知客户端何时完成。 (在这里,我甚至不知道如何做到这一点

还有没有其他的方法?在性能,稳定性,容错性,用户友好性等方面哪一个最好?

谢谢你的回答。

+0

你是如何最终实现这个?我面对同样的问题,正在考虑#2,然后我看到你的问题,并认为我会问。 – SqlRyan 2010-08-24 15:56:33

+0

我还在。因为这是一个业余爱好项目,所以需要一点时间。但我仍然坚信#2是最好的解决方案。 – 2010-08-25 08:57:15

回答

5

由于这几乎都是服务器端完成的,除了轮询服务器以更新状态之外,客户端可以做的事情并不多。

#1可以,但用户真的很急躁。 “几分钟”对大多数人来说太长了。你需要HTTP Streaming来实现#3,但我认为这是过度杀伤。

我只想去#2。

+3

我们不得不面对类似的情况,只有#2似乎是一个可行的解决方案。 – Hemant 2010-08-02 07:32:18

1

对于3,服务器应当返回一个唯一的ID返回给客户端,并使用该ID的客户端向服务器请求的结果在以后的时间

+0

这就是#2的作用 – NullUserException 2010-08-02 07:31:31

+1

服务器并不一定是完美的。客户端会将该ID保存到持久存储中,服务器也会将该ID保存到持久数据存储中,然后在稍后客户端将使用该ID保持从商店请求服务器的信息 – Lisa 2010-08-02 07:56:07

+0

我们已经使用了上面概述的内容,并且它工作得非常好。 唯一的问题是我们有两个版本的客户端,而有些客户端没有迁移到他们以后使用ID来稍后请求从服务器返回信息的更高版本 – Lisa 2010-08-02 07:57:42

相关问题