OSGi 可以帮助降低复杂性吗？
我看到了很多关于 OSGi 的演示，我认为这对于实施更好的模块化来说听起来很有希望。显然“热部署”和“并行运行不同版本的x”也是主要卖点。
我想知道 OSGi 承诺解决的问题是否是一个问题......？这让我想起了 OO 的早期，当时类似的主张还很常见：
当 OO 是新事物时，最大的争论是可重用性。人们普遍认为，使用面向对象时，只需“编写一次”，然后就可以“随处使用”。
在实践中，我只看到这适用于一些相当低级别的示例。我认为这样做的原因是编写可重用的代码很困难。不是从技术上讲，而是从界面设计的角度来看。您必须预测未来的客户将如何使用您的课程并预先做出正确的选择。从定义上来说，这是很困难的，因此潜在的可重用性好处常常无法实现。
使用 OSGi，我怀疑我们可能再次陷入承诺，我们实际上没有的问题的潜在解决方案。或者，即使我们有它们，我们也没有足够多的数量和严重程度来证明购买 OSGi 来寻求帮助。例如，模块子集的“热部署”绝对是一个好主意，但它真正起作用的频率有多少？有多少次不是因为事实证明您在特定问题上的模块化是错误的？在多个模块之间共享的模型实体怎么样？这些模块都必须同时更改吗？或者您是否将对象扁平化为基元并仅使用模块间通信中的对象，以便能够保持接口契约？
我认为应用 OSGi 时最困难的问题是获得“正确”的模块化。与在 OO 中正确获取类的接口类似，使用 OSGi，问题保持不变，但这次规模更大，是包甚至服务级别。
正如您可能已经猜到的，我目前正在尝试评估 OSGi 在项目中的使用。我们面临的主要问题是，随着代码库的增长，复杂性不断增加，我想将系统分解为更小的模块，这些模块的交互定义越来越少。
- 鉴于没有任何框架可以帮助决定模块化什么，OSGi 是否为您带来了回报？
- 团队合作是否让您的生活变得更轻松？
- 它有助于减少错误数量吗？
- 您是否曾经成功地“热部署”主要组件？
- 随着时间的推移，OSGi 是否有助于降低复杂性？
- OSGi 兑现了承诺吗？
- 它满足你的期望了吗？
谢谢！
I saw lots of presentations on OSGi and i think it sounds promising for enforcing better modularization. Apparently "hotdeployment" and "running different versions of x in parallel" are mayor selling points too.
I wonder whether what OSGi promises to solve is even an issue...? It reminded me of the early days of OO when similar claims were maid:
When OO was new, the big argument was reusability. It was widely claimed that when using OO, one would only have to "write once" and could then "use everywhere".
In practice I only saw this working for some pretty low level examples. I think the reason for this is that writing reusable code is hard. Not technically but from a interface design point of view. You have to anticipate how future clients will want to use your classes and take the right choices up front. This is difficult by definition and thus the potential reusability benefit often failed to deliver.
With OSGi, I have the suspicion that here again we could fall for promises, potential solutions for problems that we don't really have. Or if we have them, we don't have them in a big enough quantity and severity that would justify to buy into OSGi for help. "Hotdeployment" for example of a subset of modules is definitely a great idea, but how often does it really work? How often not because it turned out you got the modularization wrong for the particular issue? How about model entities that are shared between multiple modules? Do these modules all have to be changed at the same time? Or do you flatten your objects to primitives and use only those in inter-module communication, in order to be able to keep interface contracts?
The hardest problem when applying OSGi is, I would presume, to get the modularization "right". Similar to getting the interfaces of your classes right in OO, with OSGi, the problem stays the same, on a bigger scale this time, the package or even service level.
As you might have guessed, I'm currently trying to evaluate OSGi for use in a project. The major problem we have, is increasing complexity as the codebase grows and I would like to break the system up in smaller modules that have less and more defined interactions.
- Given no framework can ever help deciding what to modularize, has OSGi ever payed off for you?
- Has it made your life easier when working in teams?
- Has it helped to reduce bug count?
- Do you ever successfully "hotdeploy" major components?
- Does OSGi help to reduce complexity over time?
- Did OSGi keep its promises?
- Did it fulfill your expectations?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
OSGi 得到了回报，因为它在运行时强制执行模块化，这是您以前没有的，通常会导致纸上设计和实现脱节。这可能是开发过程中的一大胜利。
如果您让团队专注于单个模块（可能是一组捆绑包），并且您的模块化正确，那么它肯定有助于使团队工作变得更容易。有人可能会说，可以使用像 Ant+Ivy 或 Maven 这样的构建工具和依赖项来做同样的事情，在我看来，OSGi 使用的依赖项的粒度要优越得多，不会导致典型的“拖进所有东西加上厨房水槽” JAR 级别依赖性导致的。
具有较少依赖性的模块化代码往往会导致更干净、更少的代码，进而导致更少的错误，更容易测试和解决。它还促进设计组件尽可能简单和直接，同时可以选择插入更复杂的实现，或添加诸如缓存作为单独组件之类的方面。
热部署，即使您在运行时不使用它，也是一个非常好的测试，可以验证您是否正确模块化了应用程序。如果您根本无法以随机顺序启动捆绑包，则应该调查原因。此外，如果您可以更新任意捆绑包，它可以使您的开发周期更快。
只要您可以管理您的模块和依赖项，大型项目就可以保持可管理性并且可以轻松发展（使您免于可能糟糕的“完全重写”）。
OSGi 的缺点？这是一个非常低级的框架，虽然它很好地解决了它想要解决的问题，但有些事情仍然需要您自己解决。特别是如果您来自 Java EE 环境，您可以在其中获得免费的线程安全性和其他一些在您需要时非常有用的概念，您需要自己在 OSGi 中提出这些解决方案。
一个常见的陷阱是不使用 OSGi 之上的抽象来使普通开发人员更容易做到这一点。永远不要让他们手动干扰 ServiceListeners 或 ServiceTrackers。仔细考虑捆绑包可以做什么和不允许做什么：您是否愿意让开发人员访问 BundleContext，还是通过使用某种形式的声明性模型向他们隐藏所有这些内容。
OSGi pays off because it enforces modularization at runtime, something you previously did not have, often causing the design on paper and implementation to drift apart. This can be a big win during development.
It definitely helps make it easier to work in teams, if you let teams focus on a single module (possibly a set of bundles), and if you get your modularization right. One could argue that one can do the same thing with a build tool like Ant+Ivy or Maven and dependencies, the granularity of dependencies that OSGi uses is in my opinion far superior, not causing the typical "dragging in everything plus the kitchen sink" that JAR level dependencies cause.
Modular code with less dependencies tends to lead to cleaner and less code, in turn leading to less bugs that are easier to test for and solve. It also promotes designing components as simple and straightforward as possible, whilst at the same time having the option to plug in more complicated implementations, or adding aspects such as caching as separate components.
Hot deployment, even if you do not use it at runtime, is a very good test to validate if you modularized your application correctly. If you cannot start your bundles in a random order at all, you should investigate why. Also, it can make your development cycle a lot quicker if you can update an arbitrary bundle.
As long as you can manage your modules and dependencies, big projects stay manageable and can be easily evolved (saving you from the arguably bad "complete rewrite").
The downside of OSGi? It's a very low-level framework, and whilst it solves the problems it is intended for quite well, there are things that you still need to resolve yourself. Especially if you come from a Java EE environment, where you get free thread-safety and some other concepts that can be quite useful if you need them, you need to come up with solutions for these in OSGi yourself.
A common pitfall is to not use abstractions on top of OSGi to make this easier for the average developer. Never ever let them mess with ServiceListeners or ServiceTrackers manually. Carefully consider what bundles are and are not allowed to do: Are you willing to give developers access to the BundleContext or do you hide all of this from them by using some form of declarative model.
我已经使用 OSGi 多年了（尽管是在 Eclipse 项目中，而不是在 Web 项目中）。很明显，该框架并没有让你摆脱思考如何模块化的问题。但它使您能够定义规则。
如果您使用包并定义（在设计文档中？口头的？）某些包不能访问其他包中的类，如果不强制执行此约束，它将被破坏。如果您雇用新的开发人员，他们不了解规则。他们会违反规则。使用 OSGi，您可以在代码中定义规则。对于我们来说，这是一个巨大的胜利，因为它帮助我们维护了系统的架构。
OSGi 不会降低复杂性。但它绝对有助于处理它。
I've worked with OSGi for some years now (although in the context of an eclipse project, not in a web project). It is clear that the framework does not free you from thinking how to modularize. But it enables you to define the rules.
If you use packages and defines (In a design document? Verbal?) that certain packages may not access classes in other packages, without an enforcement of this constraint, it will be broken. If you hire new developers they don't know the rules. They WILL break the rules. With OSGi you can define the rules in code. For us this was a big win, as it has helped us to maintain the architecture of our system.
OSGi does not reduce complexity. But it definitely helps to handle it.
我使用 OSGI 已有 8 年多了，每次我参与非 OSGI 项目时，我都会有一种不系安全带就超速的感觉。
OSGI 使项目设置和部署变得更加困难，并迫使您预先考虑模块化，但让您轻松地在运行时执行规则。
以maven apache Camel为例。当您创建一个新的 Maven 项目并添加 apache Camel 作为依赖项时，应用程序似乎拥有其所有依赖项，并且您只会在运行时注意到 ClassNotFoundExceptions，这很糟糕。当您在 OSGI 容器中运行并加载 apache Camel 模块时，具有未满足依赖关系的模块不会启动，并且您可以预先知道问题所在。
我还一直使用热部署，并动态更新我的应用程序的部分内容，而无需重新启动。
I am using OSGI for over 8 years now, and every time I dive in a non-OSGI project I get the feeling over overspeeding without a seatbelt on.
OSGI makes project setup and deployment harder, and forces you to think about modularization upfront, but gives you the easy of mind of enforcing the rules at runtime.
Take maven apache camel as an example. When you create a new maven project and add apache camel as a dependency, the applications seems to have all its dependencies, and you will only notice the ClassNotFoundExceptions at runtime, which is bad. When you run in an OSGI container and load the apache camel modules, the modules with unmet dependencies are not started, and you know upfront what the problem is.
I also use the hot-deployment all the time, and update parts of my application on the fly without the need for a restart.
我在一个项目中使用了 OSGI（我承认 - 不是很多）。它提供了良好的承诺，但正如 @Arne 所说，您仍然需要自己思考如何模块化。
OSGI确实帮助了我们的项目，因为它使架构更加稳定。打破模块化更加“困难”，因此我们做出的关于如何模块化的决策在更长的时间内保持有效。
换句话说，如果没有 OSGI，并且在交付的时间压力下，有时您或您的团队成员会做出妥协、走捷径和其他黑客行为，并且架构的初衷就会丢失。
因此，OSGI 本身并没有降低复杂性，但它可以防止复杂性随着时间的推移而不必要地增长。我想这是一件好事:)
我没有使用过热部署功能，所以我无法对此发表评论。
回答你的最后一点，它确实满足了我的期望，但它需要一个学习曲线和一些适应，而且回报只是长期的。
（顺便说一句，你的问题让我想起了一句格言：“maven 是构建系统的 awt”）
I used OSGI in one project (I admit - not very much). It provides good promises, but as @Arne said, you still need to think on your own about how you modularize.
OSGI did help our project because it made the architecture more stable. Breaking the modularization is more "difficult", so decisions that we made regarding how to modularize stayed valid for a longer time.
To put it differently - without OSGI, and under time pressure to deliver, sometimes you or your team members make compromises, shortcuts and other hacks, and the the original intent of the architecture is lost.
So OSGI didn't reduce the complexity per se, but it protected it from growing unnecessarily over time. I guess that is a good thing :)
I haven't used the hot deploy feature, so I can't comment about that.
To answer your last point, it did meet my expectations, but it required a learning curve and some adaption, and the payoff is only for long-term.
(as a side note, your question reminds me a bit of the adage that "maven is the awt of build systems")
OSGi 没有得到回报。事实上，OSGi 并不容易使用，并且在一天或一年结束时，取决于您需要多长时间才能让事情正常运行，它不会增加价值：
我添加了以下幻灯片，并且我将使用示例代码来演示如何在被迫使用 OSGi 的情况下成功使用 OSGi。
http://www.slideshare.net/ielian/tdd-on-osgi
OSGi does NOT pay off. The fact is OSGi is not easy to use and at the end of the day or year depending on how long it takes you to get things working, it does not add value:
I added the following slides and I will follow up with example code to demonstrate how to work successfully with OSGi if it is forced on you.
http://www.slideshare.net/ielian/tdd-on-osgi
不，OSGI会让你早白白发。
No, OSGI will make you grey early.