从基础开始，先来说说OSGi的基本理念。
OSGi通过隔离底层classloader，强制应用在设计的时候就考虑模块化，并且基于白板模式来支持服务的注册与订阅。
在OSGi中，模块可以等价理解为bundle，在bundle的基础上，提供了相应的生命周期的管理。同时，为了在多个bundle之间可以进行友好的合作，提供了内部注册中心，基于白板模式支持了服务的注册与订阅。
还有一些基础的概念，比如：片段、插件依赖、包导入导出、以及远程服务等。
这里只细说远程服务，其余的随便google下就好了。
1.为什么需要远程服务呢？
理由其实很简单，一个系统不会仅仅只需要系统内部可以正常工作，往往还需要和外围系统进行对接。而且，随着负载规模的加大，我们还希望分布式部署，支持各种协议的的通讯等。
2.远程服务的理念？
OSGi的远程服务规范中有相应的描述，如下图：
Framework A与Framework B是2个系统，A发布远程服务，提供了一系列的属性；B引用该远程服务，通过一系列属性进行过滤。A、B之间通过某种传输协议进行通讯。那么B如何找到A呢？答案就是通过外部的注册中心。
如下草图：
目前，对于OSGi的远程服务有两种实现。一种是eclipse的ECF；一种是apache的CXF。这两种基本上都是基于某一种RPC的机制来实现远程服务的。
那么，其实可以看出来，OSGi的远程服务本质上就是一个外部的SOA体系（之前内部的注册中心的服务体系可以理解为一个JVM内部的SOA）。在逻辑层面，外部和内部没有过多的区别，都有注册中心，都是基于白板模式注册与订阅服务。那么，比较大的区别在于远程服务，需要加入新的特性。比如：负载均衡，路由，黑白名单，权重设置，调用统计等治理手段。
远程服务实现的选择？
OSGi没有约束具体的通讯方式，本质上，只需要支持将合适的数据传输到远端，远端可以进行正确的解析并返回响应就可以满足远程服务的基本要求了。那么，根据应用场景，可以选择合适的RPC通讯方式。
现有的实现，包括：webservice，xml-RPC等。性能一般，但是是工业标准，和第三方对接也比较方便。除此之外，还可以尝试dubbo-RPC。当然，dubbo不仅仅是一个RPC框架，还包括一系列的治理功能，而且包含一系列的扩展协议支持，通用的远程服务协议都已经支持。
选择的需要考虑的问题
基本上一个应用迁移到OSGi都会或多或少的遇到classloader的问题，这需要熟悉OSGi的相关机制以及应用的实现机制后才能解决。不过一旦解决，分布式系统的部署与开发就降低了相当多的门槛。
现有的这些，足够了吗？
考虑到和第三方对接的各种场景，以及RPC的使用限制。可以得出一个初步的结论，RPC的远程服务，适合内部系统之间的通讯。和外部系统的通讯需要更通用，更少侵入的方式。目前流行的REST服务很好的满足了这点。
采用http协议，基于已有的有限动词，将指定名词的状态进行合适的切换（其实可以简单的看做是一个有限状态机，不过换了一套更花哨的说法而已）。而这些，不用像RPC一样，服务端服务接口发生变化，需要更新客户端的lib。REST不需要或者只需要提供一个新的url通知到客户端即可。那么，这样一来，在支持OSGi远程服务基础上的vrigo容器的价值就得到体现。