OSGi已经深耕细耘了很长一段时间了。近年来，作为一个Eclipse标准，它已经受到了越来越多人的欢迎。它为Java组件部署提供了一个模块化的基础，从而也奠定了它在现代应用集成工程中的核心地位。

　　OSGi向来以“深奥，功能强大，且技术较难掌握”为大众所熟知。随着它的使用推广，OSGi的神秘面纱逐步褪去，现在已经发展到一些实用知识相继出现的地步了。

　　比如说，最近在美国维吉尼亚Reston举行的EclipseCon2012大会，就提供了一次“内幕揭秘”的好机会。在这次大会上，来自Zuhlke工程公司的OSGi专家Timothy Ward介绍了企业应用OSGi的最佳实践。咨询师Ward是Apache Aries项目管理委员会的成员之一。

　　在Ward讲到的一系列OSGi开发技巧中，包含有：将所有东西实行版本管理；避免紧密耦合；不要试图一次做太多。OSGi的bundle结构——它将JAR组件和元数据文件（Manifest header）关联起来——本来是有用处的，如果你想让它发挥好作用，那么就必须如对象设计那样，事先经过仔细考虑才行。

　　•将所有东西实行版本管理—如果你不采用版本管理的原则，即使最模块化的开发，也会产生很大的混乱。Ward说：“未进行版本管理的bundle就像一盒巧克力—你永远不知道你将会得到什么。”对语义进行适当的版本控制，将会使bundle减少出差错的机会。

　　•努力实现松散耦合—这同面向对象的情况有些类似。面向对象的代码应该是模块化，高内聚和低耦合。如今，松散耦合是服务设计最重要的驱动力。这同样也适合于OSGi bundle。Ward说：“避免紧密耦合。”

　　•不要试图一次做太多—反过来说，不要对OSGi 包敷衍了事。含有太多的方法和参数的应用编程接口（API）是很难使用的，这贯穿OSGi开发的整个过程。开发团队在处理OSGi bundle时，不应该创建太多的依赖关系和导出包（exported package）。有哪些迹象会显示你在“试图做太多”？当一个元数据文件（manifest）的长度需要以兆字节为单位来衡量时，Ward说，“你的做法已经不对头了”。

　　OSGi可有效地处理复杂性

　　既然OSGi这么难用，那么为什么还要用它呢？Ward这样回答：“使用它的主要目的是实现模块化。如果你的系统很大，那么全盘处理起来是非常困难的。并且，大的系统不易维护和理解。”还有，那些用来帮助开发人员了解Java系统的方法，也在有意无意之中增加了系统的复杂性。

　　作为OSGi可以用于解决复杂性的一个例子，Ward展示了一个完整的Java EE应用服务器API的模式。总的来说，这个API是很有用的，这毋庸置疑，但是，它太复杂了，看起来就像一团乱麻。Ward说道：“这里面有很多的依赖关系。如果你想把它分离开，那太棘手了。毫无疑问，大型的应用程序，跟大的应用服务器一样，都面临着复杂性的问题。”大型的应用程序通常有更多的外部依赖关系，他补充道。

　　作为集成复杂性的另一个例子，Ward提到了WAR文件。这些Web应用的JAR文件的存档版本，甚至会“比Tomcat还要大”（Tomcat指的是一个Ward似乎颇有微词的开源Web服务器/ servlet容器）。此外，他认为，类库依赖关系和类库的多版本，也是易于集成的障碍。

　　系统模块化，更易于集成

　　毫无疑问，现在还有一些开发团队仍然对OSGi持观望态度。有一些正在等待随同Java SE8的Java Jigsaw模块系统的推出。但是，Jigsaw与OSGi的“战斗”暂时可以告一段落了，因为Java SE在去年取得了很大进展，已经可以包容OSGi的开发方法。

　　OSGi宣称它提供的模块化基础，使得它能够角逐新兴的云应用建设，在云应用建设中，供应和配置的复杂性现在有时会产生负面影响。去年，OSGi的支持者创建了关于OSGi云计算方面的一些提案。

　　今年的EclipseCon大会的一大特色是举行的OSGi云研讨会，其中，有关方面讨论了云端的OSGI，在规范的未来版本中可能会涉及云端这个话题。在上个月发布的OSGi R5中包含了很多的新的服务支持和更新，其中包括支持子系统服务，储存库服务，解析器服务和JMX管理模式的更新，声明式服务和协调服务。