前段时间公司产品在apache的孵化项目tuscany的基础上，做了一些扩展了自己的一些实现。在项目中发现模块的动态更新带来的模型之间的依赖关系处理比较复杂；没有一套好的机智处理这种模块动态的更新，部署，以及解决他们之间的关系。
Osgi的框架很好的解决了上面的问题，更够搭建动态化的系统可以说是OSGI在sca的部署策略上的一种很好的参考实现。
OSGI规范中包括很多层，安全层，Module 层，生命周期层，服务层等等
这里主要对服务层（service layer）做一下介绍
服务层定义了一个动态的协作模型，服务模型是定义在模块（bundle）的基础上的。
Bundle可以动态的发布，查找service，并且当该服务的状态（生命周期）改变时，更够发出通知，这样所有对该service关心的bundle，可以通过注册监听器的方式，接收消息，做后续的处理。
下面是它的模型
下面简单的加以说明：
在osgi平台中，各个模块（bundle）可以提供服务，并且可以引用其他的服务，而这些服务都有统一的管理注册中心（ServiceRegistry），该注册中心由框架提供，运行在框架之上的。
这样的一些服务都是归bundle所有并且运行在它的bundle上的；所以可以通过bundle的bundlecontext把这些服务注册在ServiceRegistry中，以便能够由框架统一管理，并且能够被其他的bundle所引用。这样当bundle的生命周期发生变化的时候，如stop，那么就能够通过框架，来自动的卸载提供的服务，并且解决好bundle之间的服务引用依赖关系。
服务对象serviceobject，类似与pojo，调用它的接口，可以提供服务。这样的一个serviceobject可以实现ServiceFactory接口，也可以实现其他的接口。如果实现了ServiceFactory，那么对于每一个bundle对服务的引用来说，都是一个通过ServiceFactory创建新的实例。否则所引用的服务对象就是通过bundlecontext注册的绑定在ServiceRegistration 的原始对象。
ServiceReference类似于服务对象的句柄，通过它可以查找到真实的服务对象。其实它只是包含了对对象的描述，如该服务是位于哪一个bundle上的，该服务的bundle是否已经停 止，以及服务的描述等等。
对于引用该服务的bundle来说，只是保存的service的句柄，真实的service对象可以不存在，这样的模式被广泛应用在动态的环境中。
ServiceListener可以通过BundleContext注册在框价ServiceRegistry中，这样在服务的生命周期改变时候，可以接收消息，每个bundle可以在自己的lisitener里，做出相应的处理，如释放响应的资源等等。
BundleContext提供了注册服务，注册服务，框架，bundle的监听器，查找服务的统一入口。
暂时写这么多，待叙