有人发现 OSGi 在企业应用程序中很有用吗？
有人在 OSGi 中部署了企业应用程序并发现它很有用吗？
我可以看到好处，强制模块化，良好的依赖关系定义等。但这些似乎主要是与构建相关的改进。
有人发现动态替换现有模块很有用吗？我们倾向于按进程拆分应用程序，说实话，使用更新的库启动应用程序的新实例并不困难。 OSGi 对此有用吗？
更换模块的可靠性如何？让我印象深刻的是，如果您的流程非常繁忙，有很多事情正在进行，那么更换正在运行的模块就充满了危险。
Has anyone deployed a corporate application in OSGi and found it useful?
I can see the benefits, forced modularity, good dependency definitions etc. But these seem to be mainly build related improvements.
Has anyone found it useful to dynamically replace an existing module? We tend to split our application by process and to be honest, it's not that difficult to startup a new instance of the app with updated libraries. Would OSGi be useful for this?
How reliable is the replacing of a module? It strikes me that if you have a very busy process with lots going on, replacing a running module is fraught with danger.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我刚刚在博客中阐述了为什么我们没有选择 OSGi
简而言之，我相信OSGi 的基础很坚实，但它并不是为大规模应用程序开发而构建的。它给本来就充满挑战的开发/部署过程带来了摩擦。我希望看到 OSGi 规范领导更多地关注 OSGi 的开发人员/用户角色，使其对开发过程不可见。另外，令我震惊的是 JVM 仍然没有透明的模块标准。
I have just blogged about why we didn't go with OSGi
In a nutshell, I believe the foundations of OSGi are solid but it wasn't built for mass application development. It introduces friction into the development/deploy process that is already fraught with challenges. I'd like to see the OSGi spec leads focus more on the developer/user persona of OSGi to make it invisibile to the development process. Also I'm appalled that the JVM still doesn't have a transparent module standard.
我们的大多数应用程序都是 Web 应用程序。
我们有一个收集生物识别信息的 OSGi 胖客户端。目前通过指纹卡扫描获取照片和指纹。
OSGi 对我们的优势在于我们可以从中央网站更新插件，而不是使用卸载/安装过程。我们的大客户遍布美国 100 多个地点，因此这对我们很重要。
Most of our applications are web applications.
We have one OSGi thick client that gathers biometric information. Photographs and fingerprints through fingerprint card scanning, currently.
The advantage of OSGi to us is that we can update the plug-ins from a central web site, rather than using an uninstall / install process. Our thick client will be in over 100 locations throughout the United States, so this was important to us.
我在电信环境中工作。像 OSGi 这样的东西对我们来说非常有用。我们向那些无法在不影响收入的情况下离线的客户部署应用程序。他们每秒处理数千个呼叫。现在，他们必须在维护时段进行更新才能接受新的修复或更新。
如果我们能够以热部署的方式提供修复和增强功能，那将带来巨大的好处。当然，在我们能够做到这一点之前，存在风险因素和模拟流量测试的额外测试工作。
OSGi 不仅仅适用于动态更新，它还适用于版本控制等事情，以确保在复杂的环境中选择正确的版本。
我们正在开始研究 OSGi，如果我发现任何更有趣的内容，我将发布更新。
I work in a telecom environment. Something like OSGi will be very useful for us. We deploy applications to clients who cannot go offline without taking a hit on revenue. They process thousands of calls per second. Right now, they have to do the updates in their maintenance window to take in new fixes or updates.
If we can deliver fixes and enhancements as a hot deploy, it will be of a great benefit. But of course there is a risk factor and extra testing efforts with simulated traffic test before we can do it.
OSGi is not just for dynamic updates, it is good for things like versioning to assure that the right version is being picked in a complex environment.
We are starting to look into OSGi, I will post updates if I find anything more interesting.
我们在一家大型电信公司中使用它。我们已经生产了 2 年，并且还在继续添加捆绑包，现在我们已经有大约 110 个捆绑包。
操作人员对这给他们带来的精细控制感到高兴：他们可以开始停止单个功能并监控它们。理论上我们也可以在生产中热部署新版本，但实际上我们仅在进行测试和预生产时才使用该功能。
我们的大刷架构基于此：http://servicemix.apache.org/home.html
我们的主要问题总是尝试在 osgi 中使用标准的 java 框架。第二个问题是捆绑导入/导出管理本身。我们正在使用 Maven 插件。
总而言之，我们对这个选择感到满意，但您需要考虑两件事：
1.你愿意与任何你想添加的java框架进行战斗吗？
2.你是否有足够的自律，不会扰乱你的依赖？
We're using it in a big telecom. We have it in production for 2 years and we're continuing adding bundles now we have about 110 bundles.
Operation guys are delighted for the fine control this give to them: they can start stop single functionalities and monitoring them. Theoretically we could also hotdeploy a new version in production, but in the reality we use that feature only when doing test and preprod.
Our broad brush architecture is based on this one: http://servicemix.apache.org/home.html
Our main problem is always try to use standard java framework within osgi. The second problem is the bundle import/export management itself. We're using maven plugin.
All in all we're happy with this choice but you need to consider 2 things:
1. are you willing to fight with any java framework you want to add?
2. are you disciplined enough to not mess up your dependency?