分类：
2008-09-10 10:06:20
1999年成立的OSGi联盟向市场的设备领域迈出了第一步。几年之后，它进一步扩展到了桌面项目，为Eclipse开源IDE项目的模块化和可扩展性发展提供了重要基础。现在，随着面向服务时代的来临，OSGi正在向最新的Java领域——端进军。
与技术行业中的其他许多联盟一样，OSGi的最佳实践和开发策略也是由它的许多成员公司统一制订的。在OSGi涉足端的举动下，许多重要的Java供应商都开始围绕OSGi的蓝图调整其SOA产品线，BEA自己的microService架构（mSA）就是一个典型的例子，它依赖于OSGi的底板组件。
本文解释了OSGi涉足Java/SOA服务器端领域的原因，包括Java供应商针对OSGi调整其SOA所获得的主要收益和受到的主要约束。本文深入分析了以下内容：从开发人员和架构师的角度来看，与OSGi的合作到底构成了什么，以及从更广的平台的意义来说，未来OSGi将在Java领域中扮演何种角色。
OSGi的关键概念
随着许多OSGi原则成功地应用于从智能电话到IDE（Integrated Development Environment）等各个领域，用几句话来总结OSGi的所有方面是很困难的；然而，下面这些关键概念应该足以阐明OSGi在Java生态系统中的总体位置：
环境和框架：OSGi通常被归类为Java框架。但是，这个词在Java世界中经常被滥用，因此不要认为它也是用于简化Java Web开发和Java测试的一种框架（存在数百个这样的框架）。OSGi超越了这一界线，有效地提供了一个专门的环境，用于促进应用程序的模块化，使其成为许多更小、更易于管理的部分。
JVM伙伴：因为OSGi扎根于市场，所以OSGi的重心在于提高Java的“最低公分母”Java Virtual Machine这一点也就不足为奇了。虽然JVM已经发展了十多年，但是在某些方面——如系统服务和动态装载——它已经与一些垂直行业的期望曲线有了很大差距，给像OSGi这些有创新精神的组织提供了切入点。
Java封装程序包：当然，环境或框架都必须拥有自己的封装模型，所以就像您可能在Java项目上使用Java EE应用程序或更通用的JAR（Java Archives)时已经习惯处理WAR（Web Archives）和EAR（Enterprise Archives）那样，OSGi也是如此，它也拥有自己的名为“程序包”的封装模型。请不用过多考虑程序包的组成——稍后我们会讲到——目前只需要知道“程序包”这个术语是与OSGi紧密联系的。
请记住这只是整个OSGi业务范围背后一个很小的概念。现在让我们来看看OSGi为服务器端带来了什么。
服务器端的OSGi：SOA和复杂性
如果看一下服务器端Java市场的当前形势，就会注意到企业向实现面向服务架构（SOA）的重大转变。虽然这种转变分为巨大变更的和自然渐进两种形式，但无可否认SOA已经带来了建和部署应用程序的新方法，其结果是重新考虑支持这一架构的相同基础架构。
看一下企业为实现SOA所使用的基础架构就会发现它是Java EE容器、轻量级框架和为此目的采用的中间件的混合体。这个基础架构本身没有问题，但是部署这种软件的方法倾向于单一和极端，它在一定程度上违反了SOA的灵活性和可重用性原则。
大部分Java应用程序在独立状态下都是相当易于管理的。当这些表面上简单的部分置于生产环境中，并且与其他Java部件或者（如果愿意的话）企业的面向服务的“云集”共同协作时，真正的问题就开始出现了。企业Java中间件和JVM在这些情况下的工作方式就是如前所述的极端方法，这就产生了几个显而易见的、令人头痛的问题：
膨胀的内存占用：由于一些Java应用程序部署根据企业设置需要大至1或2GB的内存（有时甚至更多）才能正常运行，所以会在服务器端产生资源黑洞，其大小与需要部署在单个服务器实例中的应用程序的数量成正比。
类/版本冲突：各种软件的发展演化是此情况下的另一个困境。在同一把伞下，一切都被装载了——JVM和类路径——在单个服务器实例中部署的应用程序越多，应用程序使用不同库（JAR文件）的可能性就越大。结果就是造成类装载冲突和版本冲突。
重复或多余的部件：所有应用程序的拥有者在提供正确执行所必需的依赖关系时都要谨慎入微。然而，一旦将应用程序部署在生产环境中，如果其他一些应用程序不满足某些依赖关系或者一个应用程序实际使用了百分之百的依赖关系（创建者预定的），那么要想中止它，将会很困难。
如果说有一般解决方案，那就应该是动态装载，该机制可确保应用程序构建块在不工作时被终止，从而将资源消耗限制在那些核心部分正常运行所需的水平。当OSGi推出时，因为它来自于资源缺乏的嵌入式市场，所以它正好提供了这么一种极其有效的按需安装、启动、停止、更新和卸载模块的方法。
借助此方法，OSGi在JVM（当前还没有这种动态装载和版本特性）和更重量级的Java企业应用程序（它们那更加复杂的依赖关系经常带来一种折磨）之间创建一种极好的协作。BEA's microService架构依靠OSGi作为其底板组件，这意味着BEA产品线将均匀地分布于众多的OSGi程序包中，从而有效地改进了大量部件之间的交互方式，并能限制部署BEA产品的完整的堆时可能出现的版本和类装载冲突。
再说一下，本文中使用的OSGi含义是经过一定简化的，但是这种更高层面的视角应该足以领会OSGi在试图解决什么。下面该来看看是OSGi内部移动组件的构成：它的环境和及对应的程序包。
[1]
