服务器端OSGI简介及安装

来源：CSDN 作者：佚名出处：巧巧读书 2008-07-22 进入讨论组

　　这个示例飞行应用程序可能似乎没什么价值，但是当您采用同样的原则用于更加复杂的企业环境时——这种环境可能同时装载成百上千的类，甚至不一定需要它们——OSGi区别对待需要装载什么和需要何时完成的概念可以拥有强大的性能。

模糊的未来：OSGi、Java Modules、JSRs和Java EE
　　致谢：感谢InfoQ、Peter Kriens、Alex Blewitt和Eric Newcomer对于这些OSGi、JSR和Java EE规范展开的在线讨论。

　　当OSGi涉及动态Java装载和Java平台缺少的其他服务时，它所提供的功能将极为有用，但是这并不意味Java标准组或JSR委员会背后的人们已经象他们常说的那样“开车时打瞌睡”。事实上，许多联盟的活动老眼与OSGi的特性有关，举例来说：JSR-291 与OSGi/Java集成有关，JSR-277 是与OSGi作用域相似且独立的Java模块规范，还有范围很宽的 JSR-316，它与Java EE 6即将发行的版本有关。

　　顾名思义，模糊的未来是指这些JSR计划的接受程度不同。根据开发的成熟度，OSGi相关的技术——JSR-291——明显比有关Java模块的技术——JSR-277——更加成熟，后面这个计划为Java SE 7的一部分。但是，当人们展望未来，关键的确认部分就会起作用，而以企业为中心的Java EE 6规范——JSR-316——没有提到OSGi相关的特性，因而推迟了对于尚未实现的Java模块规范JSR-277（据说将在Java SE 7中完成）的决策。

　　当然，这个模糊的未来确实与Java EE 6有关；JSR 277专家组，即Java模块系统，已经表明将力求实现与JSR 291/OSGi的互操作。总而言之，OSGi是三者中最成熟的联盟，当然这部分归功于它对其他Java联盟的影响和其他Java联盟对它的采纳。所以剩下的问题就是：“Java EE 6和Java模块系统会怎样做呢？它们仍然还停留在图纸上，是对OSGi进行补充还是与之集成？”

结束语
　　至今，OSGi联盟已经存在一段时间了，它对许多需要动态Java装载微小细节的部门以及标准Java平台没有覆盖的其他组织都产生了一定的影响。现在随着企业面向服务架构的出现，服务器端Java开发正在向这种同样敏捷和灵活的框架/环境迁移，以提供更健壮的应用程序功能。

　　我们回顾了OSGi程序包的组成和创建，并介绍了如何在应用程序中部署和运行OSGi程序包，您应该能更好地理解在服务器端架构中使用OSGi以及OSGi在Java平台已有的和将有的影响整体上带来的益处和限制。