1

背景

我们有一个由 Java 后端支持的 AIR 客户端应用程序。

在我们的应用程序中，我们有一个复杂的数据网格，可以一次捕获大量数据。每个单独的数据单元格都可能触发繁重的计算/处理。这将重复发生，直到用户满意并保存最终版本。

某些处理的性质要求其中很大一部分由 Java 完成。添加大量用户，我们有一个明确的服务器性能问题。

我们需要将大部分处理转移到客户端。

问题

现在，当用户提交最后一组输入时，服务器将在持久化它们之前执行最后一次计算。这意味着我们需要一组 Java 类来执行所有需要的计算/处理。

由于我们已经在编写 Java 类，理想的做法是在客户端将它们作为库重用，而不是在 Flex 中重新编写它们并同时维护它们。

我们认为 Adob​​e AIR 的本机扩展将是完美的 - 直到我们发现 Windows 上只支持 DLL。由于我们的交付机制，我们也不能使用 NativeProcess（Java 库没有 .exe）。

问题

到目前为止，我们已经尝试过 Merapi，但考虑到它已经有一段时间没有使用了，我们担心未来的兼容性。我们想知道默拉皮是否有其他替代品？

或者更好的是，尝试在 AIR 应用程序和 Java 库之间创建通信桥的问题的任何其他潜在方法。

4

1 回答 1

0

你有一些选择，取决于你愿意做多少工作。

如果您愿意考虑 FLEX 以外的其他东西...

您可以选择 Applet，因为：

它在浏览器中运行，可以与您的应用程序进行通信，并使用客户端上的浏览器资源来执行计算。

或者，这是我最喜欢的，您可以编写一个 Java Webstart 部署的桌面应用程序。这将完全在客户端上运行，它不会消耗服务器上的资源，可以通过 RMI 或简单的消息传递与服务器通信，尽可能接近本地桌面应用程序并自行更新，因此不会出现部署问题。

第三个选项比较棘手，但理论上，您可以使用 GWT 之类的东西用 Java 编写应用程序，然后通过 GWT 将其转换为 Javascript 应用程序。它在浏览器中运行，但它有严重的限制，在我看来，GWT Javascript 几乎不可读且难以定制。

替代方案：

将应用程序编写为标准 Web 应用程序并使用 Javascript 在客户端执行计算。问题是您将无法重用您的 Java 类。

结论（应阅读，最谦虚的意见）

总而言之，通过 Webstart 部署的 Java 桌面应用程序看起来是最好的解决方案。它将允许您重用您的计算代码，它还将充分利用客户端资源。

于 2012-05-21T05:41:47.677 回答