根据上一篇
服务框架的要素的blog，来分析下基于OSGi实现一个这样的服务框架时需要对目前的OSGi框架做出哪些方面的修改，以及预估一下实现的难度。
1、如何注册服务
OSGi服务采用的是xml+pojo的方式，应该说还是符合要求的，但如果要把这个服务注册到一个服务中心的话，目前是不支持的，但这个对于分布式部署服务的需求而言，是必须实现的了。
要实现注册服务至远程的服务中心，这个可以通过编写一个监听服务生命周期变化的对象来实现，当监听到服务的生命周期发生变化时，发送消息至远端的服务中心，这里也就需要做出一个服务中心和各OSGi应用与服务中心远程通讯的机制（消息机制、RPC机制、Webservice机制等等）。
2、如何调用服务
调用服务涉及的点比较的多，来看看基于OSGi如何来实现所有的需求：
injection方式和显示调用方式
OSGi支持injection方式的调用服务，在显示调用方式方面，OSGi不支持在OSGi框架范围外的显示调用，这个是有一定的不足的，因为这样会导致和第三方框架集成的复杂，不过由于目前有了Spring-OSGi，所以呢，可以选用Spring-OSGi，这样就两种方式都支持了，如果不想使用Spring-OSGi的话，那么可以选择查看OSGi框架的代码，找出显示调用的实现方法。
另外一个就是可以通过服务中心来实现显示的服务调用和injection方式。
本地调用和远程调用的区别
OSGi并不支持远程服务的调用，在《OSGi进阶》Opendoc中我曾经写过基于webservice调用的方式，但这个对于高性能的分布式调用时其实是不可用的，要屏蔽本地调用和远程调用的区别，就得在现有的DS模型的基础上做改进了，需要支持引用服务时从当前的OSGi环境中或从服务中心中注册了，这个需要对现有的OSGi框架的DS实现做出改进，才能做到屏蔽本地调用和远程调用的区别，就可以仅仅通过在xml中做动作就可以了。
同步调用和异步调用
这个不用说，目前OSGi自然也是不支持的，只能是对DS的实现进行改进了，增加服务的同步调用和异步调用的支持，同步调用的话就没什么改动的了，异步调用的话就得对ds做比较大的改动了，注入引用的服务时注入的不能像目前的ds实现一样直接注入服务实例对象了，而是只能注册一个proxy对象了。
lazy式的调用和固定的引用调用
lazy式的调用目前OSGi并不支持，只能是自己对DS进行改动了，在引用远程服务和异步调用时，lazy调用是非常重要的。
至于查找服务方面，这个OSGi目前的模型就可以了，只是要增加查找服务中心服务的功能，这个在修改DS实现调用远程OSGi服务时会去实现。
在服务的安全性等方面这个也只能基于DS扩展实现了。
3、如何测试服务
由于OSGi的服务是POJO的方式，在服务的测试方面是完全不会有问题的。
4、服务的生命周期
在服务的生命周期方面，我想OSGi服务目前的机制就是不错的，即如果当前这个服务组件是对外暴露服务的，那么只有当其被引用且其本身所引用的服务可用时才被激活，如组件没有对外暴露服务，那么只需其引用的服务可用就可激活了，至于服务的卸载就是在上面条件不符合的情况下就应该卸载了。
如果有必要的话，可以把服务的状态区分出installed、active、deactive。
另外一个值得注意的问题就是，OSGi的DS是当服务的生命周期发生变化时，会通过bind-method和unbind-method去通知引用服务的组件的，这个特性我想即使是对于lazy式的调用也应该保持，这里也就需要DS关于服务通知的部分实现的代码了。
来看看在这种服务框架的需求下的服务的生命周期的处理情况：
安装服务：
服务被激活：
服务被钝化：
服务被卸载：
5、服务的管理和维护
在服务的管理和维护上，应该说目前OSGi的DS模型提供的已经是很完整了，不过在服务中心点的服务的管理上则需自己实现了，基本可以参照OSGi的实现，需要考虑和增加的仍然是服务中心和各远程的OSGi应用的通讯。
6、服务的组装
服务的组装方面，这个OSGi也是完全没有支持的，这个可以考虑基于服务中心去实现，抑或完全可以单独实现，只需可组装远程的服务中心中的服务即可了。
7、服务的出错处理
服务的出错处理，这个对于OSGi来说还是有点的麻烦的，就像erlang强调的一点一样，不是进程隔离方式，自然很难保证当在同一VM中的一个OSGi服务出错时不影响到整个VM。
只能尽量的去考虑另外一种方式了，当服务处理出错时的广播了，这样可以做到fail-fast。
8、服务事件的广播和订阅
服务事件的广播和订阅，这方面OSGi目前支持的还是挺好的，不过在增加服务中心后，就需要增加事件广播至多个服务中心了。
在增加考量的两个因素方面，OSGi的DS是不支持aop方式的，不过要搭建一个服务库不是一件什么难事，其实服务中心本身就已经是服务库了。
上面的实现分析还是有点的虎头蛇尾吧，最后就按照上面的分析总结成一张图吧，来管窥下基于OSGi实现的分布式服务框架会是个什么样的结构：
从上图并结合服务的生命周期管理的部分可以看出要基于OSGi实现一个这种适合分布式场景的服务框架还是比较麻烦的，需要重写的部分是非常的多，以此来看的话，目前OSGi最适合的场景应该还是如下几种：
1、不需要分布式部署的应用场景；
2、需要分布式部署，但仅仅是分层的分布式部署，例如业务层在一台机器上，数据层在另外的机器上。
不过基于OSGi实现一个这样的服务框架也是一件很不错的事，估计这也是EEG目前正在做的事，希望以后能在自己有空的时候动手做做这个基于OSGi的服务框架。