如何仅使用 GWT 开发模块化企业应用程序

Question

嗨 我想设计和开发一个大型企业应用程序 客户端的 GWT。 我想把这个企业应用程序分成几部分，然后分别调用 其中一个模块（或捆绑包或 portlet 或其他任何东西！）。 这些模块可能相互关联，并且可能调用一些服务 存在于其他模块中（在客户端和服务器端）。

问题是，这些模块必须是Designed、Developed、Compiled 和独立部署和动态，它们将被放置和 在客户端和依赖项的一个上下文中一起显示 模块之间应该是可管理的（在客户端和服务器端）。

我能做什么？我可以使用什么样的技术来构建这样的企业应用程序？

当您开发的应用程序不分成多个部分时（以我提到的方式），您可以在构建项目后轻松部署您的应用程序，但是当您只更改应用程序中的一个表单时，您必须构建整个应用程序再次，并部署整个应用程序。

在这个应用程序中，我无法停止服务器再次部署应用程序，我想更改和部署需要更改的应用程序部分，而不是整个应用程序！！！

当然我已经搜索过我可以解决我的问题的方法了！！！ 我发现我可以在服务器端使用 OSGI，因为它在软件构建级别提供了模块化，并帮助我管理模块的生命周期以及您知道的许多其他好处！ 而且我发现我可以在客户端使用小工具。

你怎么看？他们是不错的选择吗？

如果它们是不错的选择，我该如何开始？我知道我们有不同类型的 OSGi 实现，例如 Apache Felix、Eclipse Equinox 和 Knopflerfish。哪个适合这个选择？

如何集成 GWT 和 OSGi？它们如何相互影响？

Answer 1

很遗憾，您想要做的事情在 GWT 中并不完全可行。

OSGi 是 Java 的模块化解决方案，或者更准确地说是 JVM。 GWT 客户端应用程序不在 JVM 上运行，它在 JavaScript 环境中的浏览器上运行。因此 OSGi 不能用于创建运行时组装的模块化 GWT 应用程序。

GWT 应用程序可以在源代码级别模块化，但必须在构建时将模块组装到应用程序中。生成的运行时是单片的。

但是，完全可以使用 OSGi 来托管 GWT servlet，并且您可以在服务器端使用 OSGi 运行时模块化的全部功能。

作为替代方案，您可能希望查看 Vaadin。这是一个使用 GWT 提供小部件的 Web 框架，但应用程序的逻辑运行在服务器上。因此，它确实通过 OSGi 包支持完整的运行时模块化。但是，这种方法是有代价的：您的 Web 应用程序非常健谈，与 GWT 或传统 Web 应用程序相比，浏览器和服务器之间的通信要多得多。这种方法可能不适用于大量用户。

至于是用Equinox、Felix还是Knopflerfish……真的无所谓。坚持规范，您可以轻松地在实现之间切换。

Answer 2

两年前我就这样做了：OSGi 和 GWT 用于项目模块的无停机部署。

结论：除非你真的必须这样做，否则不要这样做。

简而言之，OSGi 是一头野兽，为它改造现有应用程序绝非易事。您不再制作 .war 文件（现在为 .ear），并且无法使用您之前使用的标准 jar 和 Maven 存储库。现在一切都需要捆绑。麻烦的是，很多东西（GWT、Spring、大量的库）不是捆绑包！您需要在企业捆绑存储库中找到它们，或者更有趣的是，自己开始重新捆绑第三方资源。更好的是，告诉其他开发人员重写使用他们最喜欢的库的所有内容，因为捆绑它太复杂了。

GWT 部分并没有花费太多的工作。必须修改 gwt-servlet 中处理模块上下文的方式，以便每个模块都可以在服务器上找到它的上下文。我们还必须为大多数 GWT 服务在加载时注册/取消注册和发现服务提供一种方法，以便他们知道还有谁在外面。

现在另一个痛苦：项目爆炸。

假设您有 20 个要独立部署的模块。好吧，首先它们可能比你想要的更耦合，所以最好花几个星期将它们分解成独立的 Maven 项目并将公共部分推到一个 lib 项目中。但是现在，您需要跟踪大量依赖项。当有人调整你的 lib 项目时，你需要升级每个项目还是只升级其中的 7 个？在经典的stop the world 部署中，您只有一个版本的所有代码。现在，您需要确定升级忘记密码表单是否需要您也升级索引页面模块。您将拥有大量的版本号来弥补和跟踪。在我们的案例中，我们很快就在 CI 服务器中构建了 55 个 Maven 项目。这意味着一些签入可能会触发 55 次构建。哎呀。

最后，JSON 接口。

我们使用 GWT RPC。这很神奇。编写一个界面，一切正常。它也被序列化并通过网络压缩。惊人的。但是，序列化策略取决于在每个模块编译时构建的对象和字符串查找表。所以，项目 A 不能 RPC 到项目 B。嘘。我们选择使用 JSON 是因为优雅降级，当对象上出现新的无法识别的属性时不会失败。这意味着您将再次需要一种方法来保持所有后端服务调用在他们期望并可以处理的 JSON 版本中保持一致。最好也提前模拟实时升级。

所以，最后一句话：可能，但为什么呢？ 您是否真的需要 OSGi 来热部署模块，因为您正在运行一个 1000% 正常运行时间的关键业务应用程序？还是您的老板/建筑师只是拒绝接受 99.999% 就足够了？您可能不需要该正常运行时间，并且可以通过良好的代理实现近 100% 的正常运行时间，让您将实例放入/取出平衡器池。另外，不要忘记，即使您可以实时升级您的项目，我希望您有一种方法可以在不丢失任何事务的情况下实时升级您的数据库。

Answer 3

我认为你让自己感到头疼的事情超出了它的价值。
我会立即部署整个事情。如果不是这样，您最终会得到彼此不同步的不匹配的应用程序部分。 GWT 有客户端和服务器组件，它们需要一起部署。如果您有零停机时间政策，那么您可能已经实施了负载平衡。
我会使用负载平衡软件来部署新版本的应用程序。关闭一侧（通过将所有流量转移到另一侧）部署到它，进行快速冒烟测试，将所有流量切换到新的一侧并在旧的一侧重复。