什么是OSGi教程,用于学习如何构建模块化Java应用程序?[关闭]

什么级别的粒度是正确的

我希望这听起来不太老套,但我想不出任何方法来回答,除非-这要看情况而定。从我的头脑中,有一些因素会影响答案:项目有多大?有多少开发人员?它要用多长时间?它是一款一次性的应用程序(比如说,演示版),还是需要多年来继续开发的应用程序?是否要支持同一基本应用程序的多个配置?发布之后,您是否有机会进行重大的重构,或者这是不可能的?它是开放源码还是封闭源码?预算是否允许额外的前期成本(以适当的模块化方式设计和开发)用于预期的未来收益(不必模块化整体初始实现)?

如果你开发了很多小软件包,你就增加了你的灵活性,但是代价是增加了复杂性。您可能需要将公共接口抽象到自己的模块中,其他模块使用这些模块进行交互。如果你看看Eclipse IDE,它有很多捆绑包(100+?)其中一些本身就相当大,试图在没有一些真正好的文档或路线图的情况下破译它们是如何结合在一起的,就像拔牙一样。

你能提供一些具体的具体应用细节吗?这可能有助于缩小建议的范围。

正如阿什所说:“这要看情况。”在决定模块化的结构之前,我将考虑以下几点。

• 嵌入式还是企业应用程序?第一个领域是资源非常稀缺的环境。在这里,有许多捆绑包是有意义的,如果需要,可以加载和卸载(但对于许多捆绑包不是这样,因为管理等也会占用资源)。在企业界,您需要应用程序的快速启动时间和响应。
• 您能轻松地将您的应用程序从模型、视图和控制器中分离出来吗?这是模块化的良好起点。
• 您是否希望应用程序的某些部分需要经常更新,某些部分不需要更新?这条切割线可能也不错。
• 最后,您能预见到应用程序的某些部分可以在其他应用程序中重用吗?把它们放在一个单独的包里。

还有一个建议:看看OSGi的版本控制功能。您可以指定另一个包所需的最低(和最高)版本。

它可能不适合你,但我喜欢这本书(德语,我认为没有可用的翻译): http://www.dpunkt.de/buecher/2635.html

我认为你的问题没有直接的答案。这是一个软件工程问题,如果有一个短语适用于它的“它取决于……”。

分解的一般思想是通过组成一个大问题的解决方案来解决复杂性,从简单的解决方案到较小的问题(即分而治之)。不应该增加复杂性,而是应该更容易以这种方式构建系统。从实践来看,只要“模块”是松散耦合的,即不引入太多的相互依赖关系,这通常都可以很好地工作。

权衡有时可能会在每个模块上投入更多的工作,这取决于模块的独立性(例如:Felix在某些模块中嵌入了XML解析器以避免依赖性;或者它为配置提供了各种机制,这样捆绑包就不依赖于其他服务;总会有某种类型的tra脱掉…

还有一些机制可以让你直观地了解一篇文章,即使你有一篇复杂的文章,请看 "Visualizing OSGi Systems" (我还记得看到过一些BEA的图表演示…)。

我一直在研究 Coalevo Project 一段时间以来(很抱歉,链接目前已断开,因为我正处于过渡阶段),我认为它在很大程度上起了作用,也许未来会显示出这一点)。

从我的观点来看,我认为这个决定应该是相当战略性的,并且应该超越单一的项目观点。

另外,考虑到,在当今的情况下,大多数商业J2EE容器都位于OSGi之上(BEA是,WebSphere是,JBoss在某种程度上是,Glassfish在工作中),可能由于您可以从不同的供应商那里获得现成的、随时可以使用的捆绑包(这始终是OSGi的基本元素)OSGi愿景)。

预计随着时间的推移会出现更多的模式,这将有助于为模块化“适当地”设计OSGi软件;OSGi本身确实为动态模块化系统提供了基本定义,但我认为基于它的软件不仅仅是模块化的。

我自己也在这方面工作过一段时间,看看吧。 "OSGi Mediator" .

对于我来说,OSGi可能是节点级的,如果做得正确,那么SOA可以是大分布式的。