immcss的专栏

<br />在给出采用service方式实现的“扶贫助手”之前，我们稍微回顾一下上一篇的成果。<br />在（五）中，我们看到程序被分成多个bundle后，程序的模块程度得到提高，而控制模块间的耦合度由Import-Package和Export-Package来控制，相对比较灵活。另一方面程序的更新和升级的粒度变小了。谁都知道只更新部分要比全部更新强，尤其当更新发生在一些需要建立昂贵的连接时，细粒度会节省不少花销。除了这些，我们看不到其他新鲜的东西。说白了，也就是挖空心思想一些design pattern来

<br /><br />过于的一年多，在和很多it届的同学及朋友见面时，他们总会问我最近在做什么。“OSGi！”，我不加思索的回答。到目前为止，对这个单词得到的反应都没有超出“这是什么？”，“我没有听说过”，“噢，能具体点吗？”等等。而我的回答更让他们糊涂，最后，大家干脆放弃这个话题，转到买房，运动等等更能体现聚会实质的问题上。不过最近，我一直在思考这个问题，下次再遇到这种情况时，该如何去表达才能让也是it届的哥们姐们能迅速的理解这个领域的范围呢？要知道，技术人员往往不善于表达，我们已经习惯了和业内人士用行

如何分析OSGi service platform的机制？给出几个硬生生的例子，然后分析一下代码？那还不如你自己看书看规范好了。因此，我觉得还是结合一个应用实例来分析会更容易理解，当然，是一个假想的应用实例。用怎样一个实例呢？嗯......几个月前，一个中学同学打电话给我说他们要在PDA上开发一个简单的应用程序来临时纪录工作的结果，并向我咨询，这种开发的难度和周期。这事启发我了，就以PDA的应用为背景，让我们来假想一个场景，从而来比较传统的应用模型与采用OSGi的应用模型有怎样的区别。我这样想象：小李是一个

先让我们来看看OSGi service platform的体系结构。另外要说明的是，我在后面的文章中，将采用framework来代替OSGi service platfrom，这样比较简便。下面这张图来自OSGi Alliance的主页（http://www.osgi.org/）层次很分明吧。放到我们假想的案例中，OS&Hardware可以对应为PDA的硬件和操作系统，您可以想象它是Intel xscacle + Microsoft window mobile，或者是Arm + embedded Linux

<br />先给出“扶贫助手”的第一种改造，我称之为“直接型”，请看：<br /><br />package aa.bb.cc;<br />//需要import osgi的核心package<br />import org.osgi.framework.BundleActivator;<br />import org.osgi.framework.BundleContext;<br />//实现了BundleActivator<br />public class FamilyInfo implements 

<br />（四）中提到的直接型改造法实际上和一个传统的java应用程序没有区别。因此客户的需求发生变化，通常是牵一发而动全身。<br />那么我们现在就看看如果在osgi framework中，用多个bundle来实现的效果吧。我的想法是用两个bundle来配合实现“扶贫助手”的功能。一个bundle专门负责录入和显示纪录，一个bundle专门负责纪录的数据结构和对数据的处理，用时下时髦的说法就是使用了mvc，只是我的m和c放到了一起。<br />先看看mc的bundle实现代码片断：<br />pack