如何仅使用 GWT 开发模块化企业应用程序
你好 我想设计和开发一个大型企业应用程序 GWT 在客户端。 我想将这个企业应用程序分成几个部分，并将每个部分称为 其中一个模块（或捆绑包或 portlet 或其他什么！）。 这些模块可能彼此有关系，并且可能调用一些服务 存在于其他模块中（客户端和服务器端）。
问题是，这些模块必须设计、开发、编译 和独立部署和动态，它们将被放置和 在客户端和依赖项的一个上下文中一起显示 模块之间应该是可管理的（在客户端和服务器端）。
我能做些什么？我可以使用什么样的技术来构建这样的企业应用程序？
当您开发一个不分为多个部分的应用程序时（以我提到的方式），您可以在构建项目后轻松部署应用程序，但是当您仅更改应用程序中的一种形式时，您必须再次构建整个应用程序，并且部署整个应用程序。
在此应用程序中，我无法停止服务器来再次部署应用程序，我想更改和部署应用程序中需要更改的部分而不是整个应用程序！
当然，我已经搜索过可以解决我的问题的方法！ 我发现我可以在服务器端使用 OSGI，因为它在软件构建级别提供模块化，并帮助我管理模块的生命周期以及您知道的许多其他好处！ 我发现我可以在客户端使用小工具。
你怎么认为？它们是好的选择吗？
如果它们是不错的选择，我该如何开始？我知道我们有不同类型的 OSGi 实现，例如 Apache Felix、Eclipse Equinox 和 Knopflerfish。这一选择哪一个好呢？
GWT 和 OSGi 如何集成？他们如何相互作用？
Hi
I want to design and develop a big enterprise application using just
GWT in client side.
I want to break this enterprise application into parts and I call each
of them a module (or bundle or portlet or whatever!).
These modules might have relation with each other and might call some services that
exists in other modules (in both client and server side).
The problem is, These modules must be Designed , Developed, Compiled
and Deployed Independently and Dynamically and they will be placed and
shown together in one context on the client and the dependencies
between modules should be manageable (in both client and server side).
What can I do? What kind of technologies I can use to build an enterprise application like this?
When you develop an application that is not divided into parts (In the way that i mentioned) you can easily deploy your application after building your project, but when you change just one form in your application you have to build the entire application again, and deploy the entire application.
In this application I cannot stop the server to deploy the application again, I want to change and deploy that part of application that is needed to be changed not the entire application!!!
Of course I have searched about the way that I can solve my problem!!!
I have found that I can use OSGI on server side because it provides modularity at software construction level and helps me to manage life cycle of modules and many other benefits that you know!
And I have found that I can use Gadgets on client side.
What do you think? Are they good choices?
If they are good choices, how can I start? I know that we have different kinds of implementations of OSGi, like Apache Felix, Eclipse Equinox and Knopflerfish. Which one is good for this choice?
How GWT and OSGi can be integrated? How can they interact with each other?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不幸的是，GWT 无法完全实现您想要做的事情。
OSGi 是 Java（或更准确地说是 JVM）的模块化解决方案。 GWT 客户端应用程序不在 JVM 上运行，而是在 JavaScript 环境中的浏览器上运行。因此，OSGi 不能用于创建运行时组装的模块化 GWT 应用程序。
GWT 应用程序可以在源代码级别进行模块化，但模块必须在构建时组装到应用程序中。生成的运行时是整体的。
然而，完全可以使用 OSGi 来托管 GWT servlet，并且您可以在服务器端使用 OSGi 运行时模块化的全部功能。
作为替代方案，您可能想看看 Vaadin。这是一个使用 GWT 提供小部件的 Web 框架，但应用程序的逻辑运行在服务器上。因此，它确实通过 OSGi 包支持完整的运行时模块化。不过，这种方法是有代价的：您的 Web 应用程序非常繁琐，与 GWT 或传统 Web 应用程序相比，浏览器和服务器之间的通信要多得多。这种方法可能无法扩展到大量用户。
至于是用Equinox、Felix还是Knopflerfish……其实并不重要。遵循规范，您可以轻松地在实现之间切换。
Unfortunately what you want to do is not fully possible with GWT.
OSGi is a modularity solution for Java, or more accurately the JVM. A GWT client application does not run on the JVM, it runs on the browser in a JavaScript environment. Therefore OSGi cannot be used to create runtime-assembled modular GWT applications.
A GWT application can be modular at the source level, but the modules must be assembled into an application at build time. The resulting runtime is monolithic.
However, it's perfectly possible to use OSGi to host the GWT servlets, and you can use the full power of OSGi runtime modularity on the server side.
As an alternative you may want to look at Vaadin. This is a web framework that uses GWT to provide widgets, but the logic of the application runs on the server. As a result, it does support full runtime modularity through OSGi bundles. There is a cost with this approach though: your web application is quite chatty, with lots more communication going between the browser and the server than in GWT or in a traditional web application. It's possible that this approach will not scale to very large numbers of users.
As for whether to use Equinox, Felix or Knopflerfish... it really doesn't matter. Stick to the specification, and you can easily switch between implementations.
两年前我就这样做了：OSGi 和 GWT 用于项目模块的无停机部署。
结论：除非确实必要，否则不要这样做。
简而言之，OSGi 是一头野兽，为它改造现有的应用程序绝非易事。您不再制作 .war 文件（现在为 .ear），并且无法使用以前使用的标准 jar 和 Maven 存储库。现在一切都需要打包。问题是，很多东西（GWT、Spring、大量的库）都不是捆绑包！您需要在企业捆绑存储库中找到它们，或者更有趣的是，您自己开始重新捆绑第 3 方源。更好的是，告诉其他开发人员重写使用他们最喜欢的库的所有内容，因为捆绑它会太复杂。
GWT 部分不需要做那么多工作。必须修改 gwt-servlet 中处理模块上下文的方式，以便每个模块都可以在服务器上找到它的上下文。我们还必须为大多数 GWT 服务提供一种在加载时注册/取消注册的方法以及一个发现服务，以便他们知道还有谁在那里。
现在还有另一个痛苦：项目爆炸。
假设您有 20 个想要独立部署的模块。好吧，首先它们的耦合程度可能比您想象的要高，因此最好花几周时间将它们分解为独立的 Maven 项目，并将公共部分推送到 lib 项目。但现在，您有大量的依赖项需要跟踪。当有人调整你的 lib 项目时，你需要升级每个项目还是只升级其中 7 个项目？在经典的“stop the world”部署中，您的所有代码只有一个版本。现在，您需要决定升级的忘记密码表单是否还要求您升级索引页面模块。您将有大量的版本号需要组成和跟踪。在我们的例子中，我们很快就在 CI 服务器中一直构建了 55 个 Maven 项目。这意味着某些签入可能会触发 55 个构建。哎呀。
最后，JSON 接口。
我们使用了 GWT RPC。这很神奇。编写一个界面，一切就正常了。它还通过网络进行序列化和 gzip 压缩。惊人的。但是，序列化策略取决于每个模块在编译时构建的对象和字符串查找表。因此，项目 A 无法 RPC 到项目 B。Boo。我们选择使用 JSON 是因为它可以优雅地降级，当对象上出现新的无法识别的属性时，这种降级不会失败。这意味着您将再次需要一种方法来使所有后端服务调用在它们期望并可以处理的 JSON 版本中保持一致。最好提前模拟实时升级。
所以，最后一句话：可能，但为什么呢？ 您是否真的需要 OSGi 来热部署模块，因为您正在运行 1000% 正常运行时间的业务关键应用程序？或者您的老板/建筑师只是拒绝接受 99.999% 就足够了？您可能不需要这样的正常运行时间，并且可以通过良好的代理实现近 100% 的正常运行时间，让您将实例移入/移出平衡器池。另外，不要忘记，即使您可以动态升级项目，我希望您有一种方法可以动态升级数据库，而不会丢失任何事务。
I did just this two years ago: OSGi and GWT for no downtime deployments of project modules.
Verdict: Don't do it unless you really must.
In short, OSGi is a beast and retrofitting an existing application for it is far from trivial. You're no longer making .war files (.ear now) and can't use the standard jars and Maven repositories you used before. Now everything needs to be a bundle. Trouble is, a lot of stuff (GWT, Spring, tons of libs) are not bundles! And you'll need to find them in an enterprise bundle repository or, even more fun, start rebundling 3rd party sources them yourself. Better yet, telling the other devs to rewrite everything that uses their favorite lib because bundling it would be too complex.
The GWT part didn't take that much work. The way contexts for modules were handled in gwt-servlet had to be modified so each module could find it's context on the server. We also had to make a way for most of the GWT services to register/unregister on load and a discovery service so they could know who else was out there.
Now the other pain: project explosion.
Let's say you had 20 modules you wanted to deploy independently. Well, to start with they're probably more coupled than you'd like, so better spent a few weeks breaking them into independent Maven projects and pushing common parts to a lib project. But now, you've got tons of dependencies to keep track of. When someone tweaks your lib project, do you need up upgrade every project or just 7 of them? In the classic stop the world deployment, you only had one version of all your code. Now, you need to decide if that forgot password form being upgrades will require you to also upgrade your index page module. You'll have a ton of version numbers to make up and keep track of. In our case, we quickly had 55 Maven projects building all the time in our CI server. This meant some checkins could trigger 55 builds. Eek.
Finally, JSON interfaces.
We used GWT RPC. It's magical. Write an interface and everything just works. It's also serialized and gzipped over the wire too. Awesome. But, the serialization policies depend on object and string lookup tables that are built at compile time per module. So, project A cannot RPC to project B. Boo. We chose to use JSON due to the graceful degradation, that is not failing when new unrecognized properties were present on objects. This means you'll again need a way to keep all the backend service calls coherent in the versions of the JSON they are expecting and can handle. Better simulate that live upgrade beforehand too.
So, final word: possible, but why? Do you really need OSGi to hot deploy modules because you're running a 1000% uptime business critical application? Or does your boss/architect just refuse to accept that 99.999% is good enough? You probably don't need that uptime and can achieve nearly 100% uptime with a good proxy to let you take instances in/out of the balancer pool. Also, don't forget that even if you can upgrade your projects live on the fly, I hope you've got a way to upgrade your database on the fly without dropping a single transaction.
我认为你让自己陷入了不必要的麻烦。
我会立即部署整个事情。否则，您最终会得到应用程序中不匹配的部分，并且彼此不同步。 GWT 有客户端和服务器组件，它们需要一起部署。如果您有零停机政策，那么您可能已经实现了负载平衡。
我将使用负载平衡软件来部署应用程序的新版本。关闭一侧（通过将所有流量转移到另一侧）部署到它，进行快速冒烟测试，将所有流量切换到新侧并在旧侧重复。
I think you are setting yourself for more headaches than it is worth.
I would go with deploying the whole thing at a pop. If not you will end up with mismatched pieces of the application that are out of sync with each other. GWT has both Client and Server components and they need to be deployed together. If you have a zero downtime policy then you probably have load balancing in place.
I would use the load balancing software to deploy the new version of the app. Turn off one side (by diverting all traffic to the other side) deploy to it, do a quick smoke test, switch all traffic to the new side and repeat with the old side.