之前也写过关于Service-Oriented Component Model的blog了，Service-Oriented Component Model(以下简称SOCM)是OSGi R4中最为重要的改进，SOCM也是切实体现OSGi的动态性的模型，大家在使用SOCM的时候可能会因为受到原有思想的影响而一时无法理解，在这篇blog中将再次的对SOCM进行讲解，以便大家能够更好的理解和进行运用。
SOCM是一种模块化的详细设计思想，不属于架构级别的思想，相应的我们对比一下传统情况下基于Spring的模块化详细设计，在Spring中，对于一个模块的详细设计，通常可以这么来简述，模块由多个bean共同构成，bean通过注入其他bean实现的接口来获取相应的功能，同样通过实现接口来对外提供功能(加上xml中的描述)，在系统启动时默认情况下所有的bean都自动的初始化了，当然，也可以通过类似lazy的属性使得bean延迟的进行加载，在bean启动后其依赖关系就已经确定，是一种静态的依赖关系，bean的生命周期可通过spring提供的接口来进行管理。
通常来讲习惯了基于spring实现的同学们在转变到使用SOCM时会碰到一些问题：
1、怎么样注入其他Component？
这个思想呢，我个人觉得是在使用spring时本来就有些错误了，注入思想最重要的就是接口注入，所以在说注入其他Component这句话上是有一定的概念性的错误的，每个Component其实都是通过set接口来获得相应接口的功能，按照SOCM的说法，就是每个Component通过bind相应的服务的接口来获取需要使用的功能。
在SOCM中，要引用其他的Service非常的简单，和Spring的DI没有很大的区别，也可以通过setService这样的方法来实现，和spring的不同只是spring在设置bean的依赖时是通过ref bean="beanID"来获取，而SOCM中呢，则是充分的Service-Oriented的表达方式：
<reference name="LogService" interface="org.osgi.service.log.LogService" bind="setLog" unbind="unsetLog" policy="dynamic"/>
通过的是interface属性来获取到所需的服务，而不是通过ref bean的那种方式，这里也是充分表达SOCM是一种动态化设计的思想。
2、怎么样管理Component的生命周期？
这是大家最为迷惑的，当你查遍OSGi的相关文档后，会发现OSGi是没有提供接口来外部调用Component的呢，这和Spring提供了接口调用bean完全不同，在SOCM中Component的生命周期是由OSGi框架来负责管理的，外部没法通过接口去调用某个Component，这就会使大家产生疑问，那么Component中的方法是怎么被执行的呢，对于这个疑问，需要分成两种形式的Component来看待：
(1)、只引用其他Service的Component；
对于这种类型的Component，在启动Bundle后OSGi将会自动的对Component进行激活，Component激活的前提是Component所引用的Service满足条件，Component激活时将会通过调用bind属性对应的方法将相应的服务注入，在将所需的服务均注入后，将会调用Component中的activate方法，如没有此方法，则不进行调用，:)，在这种情况下，我们会发现以前Bundle中的BundleActivator通常都会变得没有意义，完全可以通过编写一个POJO的Component来实现同样的功能和效果，而且更为简单。
对于这种Component，我们现在可以清楚，只要Component所必须需要的服务都存在，那么它就会被自动的激活，这种Component的例子可以参见OSGi Opendoc所附带的ds部分代码中的LoginServlet。
(2)、对外提供Service的Component；
如果Component对外提供了Service，那么只有当这个service需要被使用时Component才会被激活，这是它区别于第一种形式Component的地方。
对于这种Component，可以参见OSGi Opendoc所附带的ds部分代码中的DBValidatorImpl(如果你想看它是什么时候被激活的话，可以增加一个activate(ComponentContext context)方法来确定)。
其实对于上面两种形式Component的激活原理，我们从设计角度去看的话很容易理解，第一种Component相当于消费型的，这种Component自然是直接就需要启动了，而对于第二种呢，是提供服务型的，当没人需要服务的时候，自然没必要激活了。
为什么Component的生命周期需要交给OSGi框架去管理，而不能通过外部管理呢，这就是OSGi动态性特征的表现，Component什么时候能激活取决于系统运行时的状况，这和静态的设计思想是完全不同，例如当Component所必须的服务在系统中突然不存在了时，这个时候Component将会变成不激活的状态，这和传统的静态化的bean有很大的不同，Component的状态是会根据运行时的情况来动态改变的，这自然是远强于静态化的bean的系统了。
其实从上面的问题可以看出，当你将基于Spring的模块移植到OSGi中时，我相信你的系统的设计会随着使用SOCM而得到明显的提升，真正的做到面向服务、面向接口，SOCM本身就是一种很好的SOA的实现模型，在理解SOCM时，最重要的主要是要把握SOCM的三个核心思想：
1、模块是由一堆Component组成的；
2、Component通过注入服务接口和提供服务接口来实现Component之间的依赖设定，服务接口是Component之间依赖的桥梁；
3、Component的生命周期是由OSGi框架管理的。
其实上面仍然只是简要的讲了讲SOCM，SOCM在动态化的表现上其实还有更多的东西，象cardinality、policy、filter等等。
OSGi中实现SOCM的是Declarative Services，不能说SOCM就没有缺点了，SOCM没有提供调用Component的接口(准确的说应该是外部调用SOCM中的Service，例如要在普通的java object中调用SOCM中的service，目前是没办法的，只能把那个java object也作为Component才行)，这也就使得系统必须完全遵循SOCM而构建，这使得基于SOCM而构建的模块很难与本地的程序做集成，这是它的一个缺点，但是这里面确实有个问题，就是OSGi的Component是动态化的，其实它是无法简单的通过提供一个接口来对外部的程序提供SOCM中的service的，必须同时还附带一个通知模型，以便在service状态发生改变时外部的程序能够得知，从而做出相应的动作，这个问题在SCA中是得到解决了的，EEG对这个问题也表示了关注，可以相信在不久的将来SOCM将会更加的完善和实用。
ps：之前看EclipseCon 2007中OSGi Long Talks的时候看到Bea的microServices也是基于OSGi的，:)，果然没有出乎意料，也就是说BEA的所有软件产品将全部基于OSGi了，这对于OSGi的推进无疑是个很好的消息，呵呵，看来IBM的动作还得加快。
另外说说最近Equinox的一个最好的消息，那就是它的基于aspect实现AOP的bundle已经推出，:)，可以想想这意味着什么，意味着面临的很多企业应用的问题就得以解决了，象跨Bundle的事务等等..