osgi的bundle构建计谋.docVIP

软件编程发展到今天可以看作是一个量变引发质变的过程。最初，程序开发面向过程，开发人员需要编写大量的过程代码，随着过程代码的不断积累（量变产生），从代码维护和重用的角度，过程开发变得越来越不适应，质变产生，面向对象的开发逐渐被采用。由于面向对象的开发很好的封装了过程，而且从面向对象的角度可以很好的描述实际应用中的需求模型，因此面向对象的开发逐渐成为主流。同样，随着面向对象开发的不断应用（量变产生），出现了大量的可复用的类及包，维护这些类/包变得越来越困难，而且，尽管面向对象的编程机制可以很好的适应小规模应用的开发，但随着应用系统的规模越来越大，如同用细小的沙粒构建堤坝，面向对象的机制难于适应，质变产生，面向组件的开发被引入开发过程。面向组件的开发目前仍可以认为是处于一种探索状态，目前还不存在一种统一的标准可以遵循。 从另一个角度，历史是今天存在的基础，没有历史就没有今天。同样的道理，应用系统采用面向组件的开发实现，组件仍需要对象来构造，而对象在一定程度上是封装的功能过程，三者相辅相成。不管是从上而下还是从下而上，应用系统需求模型在其实现过程中，系统设计者应该充分关注组件、对象和功能过程三个层面。 OSGi可以看作是面向组件开发的一种思路和基础环境。在OSGi环境中实现应用系统的需求模型要求开发人员对组件、对象开发具有充分的理解。衡量一个应用系统实现好坏的标准之一是该系统是否是松耦合高内聚。面向对象的开发实现此目标的关键是接口/抽象的应用，OSGi面向组件的开发在此基础之上充分利用了对象类包封装的机制。 1. Bundle的构建策略 通常，当我们构建应用系统时，我们需要充分重视所构建应用的业务需求模型即领域模型，同样的，在用软件代码实现业务需求模型时，我们也应当对软件系统的架构模型给予充分的重视。采用OSGi技术实现应用系统时，展现在我们面前的将是一个个的Bundle组件，此时，我们必须首先弄清楚我们要构建什么样的Bundle。 1.1 明确Bundle的构建需求及实现粒度 从需求模型的角度看，Bundle可以看作是需求模型中的一个功能模块实现，因此，在开发Bundle之前系统开发人员必须明确Bundle的功能需求。需求模型中的功能模块的边界可大可小，同样，Bundle的实现粒度也是可大可小，极端情况下，小的Bundle可以仅实现一个微小的功能，大的Bundle可以实现整个业务系统。 以记录日志为例，如果记录日志仅输出到控制台，则一个类就可以实现整个的功能，如果记录日志输出到数据库系统，则开发人员需要在整个功能用一个Bundle实现，还是将日志记录功能和记录信息的数据库存储分为两个不同的Bundle实现，两个选择甚至更多的选择中做出决策。通常这个问题在现有的软件开发方式中不需要过多的重视，但在OSGi开发中，开发人员必须根据需求确定Bundle的实现粒度。 1.2 确定Bundle的类型 我们在面向对象的系统开发过程中，经常会将一些通用的功能设计成为工具类，多个工具类封装为一个工具类包。由于OSGi开发建立在面向对象的开发之上，Bundle的开发也存在这种特点。OSGi开发的另一个特点是服务机制的引入，一个Bundle可以将其提供的功能发布成为一个或多个服务，供其他Bundle查找使用。此外，建立在OSGi环境之上的组件开发也区别于通常的组件开发方式，因为我们可以利用OSGi环境提供的某些特性（参见下一节 充分利用OSGi环境的特性）。综上所述，我们可以将Bundle划分为如下几种类型（实际开发中，并不存在清晰的边界）： Utility Bundle 这种Bundle与通常开发方式中的工具类或工具类包没有本质的区别，仅仅是将这些工具类发布到OSGi环境中，这些工具类也不依赖任何的OSGi环境或特性。通常，这种Bundle特别适合目前存在的众多的第三方组件引入到OSGi环境中直接供OSGi开发人员使用。例如，我们可以将Apache开源项目Log4j发布的工具包通过修改其META-INF目录下的MANIFEST.MF文件，添加Bundle的元数据信息就可以直接将其封装为可供OSGi环境中其他Bundle使用的工具类Bundle。 依赖OSGi特性的Bundle 这类Bundle可以被其他Bundle引用，为其提供功能，但是这类Bundle不能离开OSGi运行环境，否则不能使用。举例来说，一个提供数据缓存功能的Bundle可能使用Bundle的数据存储区来缓存数据。Bundle的数据存储区的位置对Bundle开发者来说是透明的（参见下一节 充分利用OSGi环境的特性）。如果将该Bundle的数据缓存功能迁移到OSGi运行环境之外，则必须修改实现添加对缓存区位置的处理功能。 引用和（或）发布OSGi服务的Bundle 这类Bundle也