OSGi 的盈亏平衡点
It seems that OSGi is a hot term these days. Many benefits are invoked:
- Reduced Complexity
- Reuse
- Easy deployment
- Versioning
(etc)
I'm asking for a very specific use case - small to medium-sized web applications. What benefits would OSGi bring for those? It is actually worth it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我会一如既往地说“这取决于”。
您的环境
考虑一个没有 OSGI 经验的现有团队（他们自豪地认为自己是“把事情做好”的经验丰富的开发人员。他们有可能会经历重大痛苦或起步缓慢。
很多（比您想象的要多）开发人员不熟悉 Ant 或 Maven，当它们使用时，它们只使用这些构建工具的有限功能。
创建 OSGI 包最好使用 Maven 来完成。 /eclipse.org" rel="nofollow noreferrer">Eclipse, Ant 任务或 Maven BND 插件 VS 脚本或手动编写的 jar 存档清单
对于小型应用程序
，OSGI 引入了不必要的复杂性，而您可以使用动态语言，例如 Jython 等或插件框架，例如 JPF 或SPI。 您还可以直接使用反射和简单的自定义类加载器。
大型应用程序
大型应用程序可能会受益于 OSGI，特别是当它们是从头开始编写时。 恕我直言，将 OSGI 集成到现有应用程序中更像是引入补丁来提供模块化架构。
根据我的经验，在重写许多应用程序之后，最好在项目的早期就考虑模块化。
其他问题
部署：
在任何应用中都是一样的。 如果您习惯于部署 Java Web Start 应用程序，那么部署就不是问题。 如果您习惯了 OSGI，那么部署就不是问题。
任何应用程序在将其部署到生产中时总会偶尔出现问题，这是很自然的。
版本控制：
有多种方法可以在应用程序中提供版本控制。 但是，如果您仅将版本控制用作“信息”而不是作为工具（管理依赖项要求），则版本控制不是问题。
重用：
使用 OSGI 时，您倾向于编写代码以供重用，但任何编写良好的 API 都是在设计时考虑到代码重用的。
Eclipse 是使用 OSGI 编写的成功大型应用程序的第一个示例。 还有其他一些不使用 OSGI 并且是模块化的大/好工具。
结论
在许多模块化框架中，在不重新启动应用程序的情况下，很难在运行时处理依赖关系、停止/启动/卸载/安装功能。 您可以使用自定义类加载器、关闭和启动挂钩等。
恕我直言，OSGI 以较小的成本为您提供了这种灵活性。
I would say as always "it depends".
Your environment
Consider an existing team with no OSGI experience(who proudly consider themselves as experienced developers who "get things done". There's a chance that they'll experience a major pain or a slow start.
MANY(more than you might think) developers are not familiar with build tools such as Ant or Maven, and when they are they only use limited features of those build tools.
Creating OSGI bundles is best accomplished with Eclipse, Ant tasks or Maven BND plugin VS a script or a manually written manifest for the jar archive.
Small applications
For small applications, OSGI introduces unnecessary complexity while you could use dynamic languages such as Jython, etc. or a plugin framework such as JPF or the SPI. You could also go directly with reflection and a simple custom classloader.
Big applications
Big applications might benefit from OSGI, especially when they are written from scratch. IMHO integrating OSGI in an existing application is more like introducing a patch for provide a modular architecture.
From my experience, after rewriting many applications, it's better to think about the modularity at the early days of a project.
Other concerns
Deployment :
It is the same in any applications. If you're used to deploy Java Web Start applications, deployment is not a concern. If you're used to OSGI, deployment shouldn't be a concern.
There are always problems once in a while in any application when it comes to deploying it in production, which is natural.
Versioning :
There are many ways to provide versioning in an application. But if you only use versioning as "information" vs as a tool(manage dependencies requirement), versioning is not a concern.
Reuse :
When using OSGI you tend to write your code for reuse, but any well written API is designed with code reuse in mind.
Eclipse is a number one example of a successful big application written with OSGI. There are other big/nice tools which don't use OSGI and are modular.
Conclusion
In many modular frameworks, it's difficult to handle dependencies, stop/start/uninstall/install features at runtime, without restarting the application. You play with a custom classloader, shutdown and startup hooks, etc.
OSGI gives you such flexibility at a minor cost IMHO.
尽管我是 OSGi 的忠实粉丝，但我还是冒险说“不”。 除非您正在使用其他 OSGi 包，或者您有一个没有这个大锤就无法轻松解决的特定问题。
好处是优雅的类路径分离（恕我直言）。 如果您需要同一 JAR/类的不同版本，例如因为您要在应用程序运行时升级应用程序的某些部分，或者因为您要组合许多第 3 方模块，那么 OSGi 就很棒。
这不是一件容易实现的事情，使用 OSGi 也不容易做到这一点。 它变得干净了，但代价是环境堆栈中的另一层。 还有很多工作需要学习和维护。
更不用说该文档对初学者来说并不是特别友好。
我建议学习它——构建 Eclipse 插件是一种非常好的方法——但在您充分了解之前不要将其构建到您的开发计划中。
I'll hazard a NO, even though I'm a big fan of OSGi. Unless you're working with other OSGi bundles or you have a specific problem that you can't easily solve without this sledgehammer.
The benefit is elegant classpath separation (IMHO). If you need different versions of the same JAR/class, say because you're upgrading certain portions of an app while it's running, or because you are combining a lot of 3rd party modules, then OSGi is great.
That's not an easy thing to achieve, and it's not made easy with OSGi. It's made clean, but at a cost of another layer in the environment stack. And a lot of work to learn and maintain.
Not to mention the documentation isn't particularly beginner-friendly.
I suggest learning about it -- building Eclipse plugins is one very good way -- but not building it in to your dev plan until you know it well.