BlueDavy之技术Blog

在本届 EclipseCon 2007 大会上， OSGi 占据了不少的 Topic ，下面就对本次 EclipseCon 2007 大会上 OSGi 相关的主要的一些 Topic 简单的介绍下，最后总结下通过本次大会形成的反馈 ( 信息来源于 OSGi 官方网站 blog 和 EclipseCon 2007 官方网站 ) ，关于 EclipseCon 其他方面的精品 Topic 在后续的 blog 中也将相继介绍。

周一

周一关于 OSGi 的 Topic 主要有三个，分别为耗时 10 小时的 Long Tutorial ： Building Service Oriented Bundle Architectures ；耗时两小时的 Short Tutorial ： Spring and OSGi combined ；耗时 1 小时 15 分的 Server Side Eclipse and OSGi EOF 。

Building Service Oriented Bundle Architectures(SOBA) （★★★★★）

此篇 Topic 由 IBM 以及 Band XI 公司的几位主讲，通过 Topic 参与者可以学习到基于 OSGi 如何基于 SOBA 搭建松散、动态的面向服务的系统。

基于 SOBA 这样的架构体系搭建的系统能够根据需求动态的导入和导出服务，同时继承了 OSGi 的动态部署的优势，使得系统能够动态的扩展和改变。

此篇 Topic 向参与者介绍 SOBA 的最佳实践、建议的开发流程、工具箱、 Equinox 的运行以及客户端的管理。

个人觉得这篇 Topic 基本还是属于 OSGi 的基本知识篇，而且这篇 Topic 还没有去充分发挥 Declarative Service 的优势， DS 对于 OSGi 之所以是重大改进，就是它提出了更为符合系统建设的 Service-Oriented Component Model ，当然，这篇 Topic 是从 Architecture 角度去说，自然是 Bundle Architecture 。

Building Server-Side Eclipse based web applications （★★★★★）

此篇 Topic 介绍开发基于 OSGi 的 Web 应用的技术、概念以及工具，分为两个 Short Tutorial 进行讲解：

l         基于 OSGi 的 Web 应用的开发和部署

此 Short Tutorial 非常详细的介绍了基于 OSGi 的 Web 应用开发的概念、开发的步骤以及部署的方法，是 OSGi Web 应用开发的一篇非常好的指导 PPT 。

OSGi Web 应用开发主要可以采用这么两种方式：

n         调用 HttpService 注册 Servlet ；

n         使用扩展点注册 Servlet 。

基于 OSGi 的 Web 应用可以采用内嵌的 Http Server 或者部署到现成的应用服务器中。

在部署上此 Short Tutorial 提及的方法就是和 RCP 部署同样的方法，这方法远强于我《 OSGi 实战》 Opendoc 部署的方法，推荐大家采用这种。

最后 PPT 中提及到了现在新支持的 Equinox Application 的编写方法，这个是非常有意义的东西，也就意味着可以让 Equinox 的应用和 RCP 应用一样的运行和管理，这就使得基于 Equinox 的应用也具备了应用级的管理的概念。

l         如何使用 Java EE 、 Rich Ajax Platform 或 GWT 构建基于 OSGi 的 Web 应用

这篇 Short Tutorial 介绍了如何使用 Java EE 、 Rich Ajax Platform 或 GWT 这三种方法来开发基于 OSGi 的 Web 应用。

n         Java EE

提及到了如何注册 Servlet 、如何支持 Jsp 以及和 Struts 的结合 ( 不过这块是个 Demo ，无法判断它的方法是否可用 ) ，同时提及到了目前 OSGi 在这方面支持的不足，例如不支持 Filter 等 Web 应用非常需要的功能。

n         Rich Ajax Platform(RAP)

RAP 是 Eclipse 的工程，目前还处于里程碑版本阶段，不过已经可以拿来做原型用了，感兴趣的同学可以访问下 http://www.eclipse.org/rap 。

RAP 提供了类似 SWT 程序的开发方法，使得开发人员可以按照桌面程序开发的方法来开发 B/S 应用，而通讯则通过 Ajax 来实现，在客户端界面上 RAP 完全采用了和 RCP 同样的构造方法，如 Workbench 等，使用 qooxdoo 来提供客户端的控件，不过我不是很看好这种东西，我觉得这种一定程度上抹杀了 B/S 应用的优势， B/S 应用在界面上可以很简单的做到符合用户的需求，而其实 C/S 的要做的话就要付出不小的代价。

在 Short Tutorial 中介绍了如何基于 RAP 来开发基于 OSGi 的 Web 应用，其实从 RAP 的设计思想上就可以看出其实基于 RAP 开发基于 OSGi 的 Web 应用并不需要做什么特殊的处理，因为 RAP 本身就是基于 OSGi 的。

n         GWT

GWT 现在名声非常的大，基本没什么可介绍的，不过我觉得它和 RAP 有些的类似，在 Short Tutorial 中也只是简单的介绍了下如何使用 GWT 来开发。

Spring and OSGi combined （★★★）

此篇 Topic 从标题就能够看出其讲解的内容了，就是现在非常火热的 Spring and OSGi ，这篇 Topic 以一个例子来讲解 Spring and OSGi 的使用，这个例子的客户端基于 RCP ，服务端是基于 Jetty 的 Web 服务。

没仔细看它的例子，不好评价，由于个人现在还不是那么的看好 Spring and OSGi ，觉得 Spring and OSGi 的发展还需要时间才能做到真正的融合。

Server Side Eclipse and OSGi BOF （★★）

这个基本就是个讨论，由于 OSGi 目前在服务器端应用的使用已经越来越多， Jeff McAffer 希望能和从事相关工作的人讨论下 OSGi 在服务器端还需要做的工作。

… 看到 Jeff 的介绍，强的，他是 Equinox 、 RCP 和 orbit 三个项目的 leader ，同时是 IBM Rational 的高级技术主管。

周二

OSGi and JBoss Microcontainer （★★）

作为一个 Short Talk ，简单的介绍了下 Jboss Microcontainer ，这里唯一重要的信息就是 Jboss MC 采用的是 OSGi ，这也就说明了商业产品又一个采用 OSGi 作为其支撑容器的。

现在 Jboss 也是 OSGi 联盟的成员之一。

周三

Ubiquitous Eclipse: Equinox everywhere （★）

此篇 Topic 通过 Eclipse Runtime 切换为 OSGi 的原因简单的介绍了下 Equinox 的强大，同时结合一些例子简单的讲解了下 Equinox 在 Server Side 的应用。

Services Everywhere ： OSGi in Distributed Environments （★★★★★）

这篇 Topic 说到了大家非常感兴趣的话题，在分布式的环境中如何去使用 OSGi ，这个也是 EEG 目前的重点议题，来看看这篇 Topic 中是采用什么方法来实现基于 OSGi 的分布式应用的。

OSGi 本身是一个面向服务的组件模型，也就是说如果能够实现分布式的 OSGi 通讯的话，自然也就是 Services Everywhere 了，在任何地方都可以获取其他地方提供的服务，在实现分布式的技术上， OSGi R3 中提出的为 Jini ， OSGi R3 和 R4 中都有的为 UpnP 。

Jini

Jini 是一种网络化设备类似的基础架构，它通过一个服务寻找机器来帮助实现分布式的服务的通讯，可以认为它是 Service Discovery+RMI 的组合体。

但是采用 Jini 的话会有这么几个问题：

l         需要服务寻找的中间机器 ( 这就使得系统变为集中式的，单点的失败有可能导致所有系统的失败 ) ；

l         需要 RMI ； (RMI 并不属于标准的 Java EE 范畴 )

l         相对 OSGi 而言偏弱的服务状态的通知（如服务被卸载等）；

l         配置麻烦。

UPnP

UPnP 适用于设备，设备的 Control Points 能够发现和使用服务，设备和服务的信息通过 XML 进行传递，动作通过 SOAP 来交互。

采用 UPnP 有这么几点不好：

l         服务必须是 UPnP Services ， UPnP Services 不具备 OSGi Services 的所有优点；

l         方法的参数限定了只有几种类型；

l         不能订阅特殊的事件；

l         SOAP 的性能。

根据对于 Jini 和 UPnP 的分析，两者或多或少都有些问题和不足，在 PPT 中提出了需要一种新的方案，接着往下：

首先提到了分布式 OSGi 需要达到的目标：

l         透明化（本地和远程的服务使用起来没有什么区别）

l         无侵入（在服务的实现上没有要求）

l         无缝集成

l         按需选择

l         统一

讲到这， Topicer 终于讲到了实现分布式 OSGi 的东西： R-OSGi(http://r-osgi.sourceforge.net) ，来看看 R-OSGi 是如何实现上面所说的几个目标的：

l         按需选择

通过注册一个 DiscoveryListener 来选择所需的服务。

l         无缝集成

基于 RFC 2608 ：服务地址协议 (SLP) 。

使用到了 jSLP 这个开源的 SLP 产品 (http://jslp.sourceforge.net) 。

在方法的调用上 R-OSGi 的几个特点：

l         不是 RMI ；

l         纯粹的 MOM 机制；

l         支持所有的 Java 类型；

l         在 Java 5 下比 RMI 更快。

J ，作了基于 R-OSGi 用 PDA 控制茶壶烧茶的演示以及控制 Lego 机器人的演示，最后讲到了基于 R-OSGi 的几个系统，如 SwissQM 、 PDA 控制灯泡、流体计算等。

这篇 Topic 非常精彩，值得鼓掌。

Enterprise OSGi—how to tackle the problems of large scale applications in OSGi （★★★★★）

此篇 Topic 由 Simens 员工主讲，条理非常的清晰， Topic 按照这样的顺序进行讲解：

l         在 Simens 的应用中何处使用了 OSGi 、为什么要使用 OSGi

Simens 在做它的 OpenSOA 产品时考虑了 EJB Container & JMS 以及 OSGi 这两种方案，最终选择了 OSGi ，原因为：

n         基于 JMS 请求 / 响应模式的 MDB 过于重量级；

n         EJB 的限制；

n         MDB 并不是为轻量级事件而设计的；

最后决定了选择 OSGi ，然后弥补 OSGi 中对于 Simens 应用而言不足的部分。

l         OSGi R3 是个不错的选择，但对于 Simens 的应用而言还有不足

OSGi R3 具备的优势：

n         自然的支持 SOA 应用；

n         组件模型；

n         服务的生命周期；

n         可用服务的注册和寻找；

n         支持多线程应用；

n         开发工具的支持，例如 Eclipse 。

最关心的还是不足的几点：

n         限制为单容器运行，不支持分布式；

n         服务模型限制为 OSGi 容器环境内的，不能调用其他外部的服务，外部也无法调用 OSGi 容器内的服务；

n         监听和追踪都必须手工编写代码实现；

n         缺少对于多种通讯模式 (tcp 、 https 等 ) 的支持；

n         缺少对于声明式的依赖管理的描述；

n         缺少拦截器模式的支持；

n         缺少非 OSGi 应用的部署和配置的支持；

n         缺少对于基于用户认证和授权的支持。

对于 OSGi R3 不熟，我无法评价，不过它列出的这几点对于企业应用而言确实很有必要。

Simens 提出了他们对于 OSGi R3 这几点不足的解决方案：

n         基于 MOM 集成了 Service Bus ，这也就实现了服务的分布式通讯，并且基于 MOM 自然就支持了多种通讯的方式和协议；

n         对于 Bundle 增加了以 XML 方式描述该 Bundle 中的组件、服务以及依赖关系（这些在 OSGi R4 的 DS 中得到了支持）；

n         注册接口为 OSGi 服务，并支持在外部调用这些服务；

n         使用 IoC 模式注入依赖服务；

n         基于 Spring AOP 实现基于用户的认证和授权。

l         OSGi R4 改进了不少，不过仍然有提升的空间

对于 OSGi R4 ， Simens 认为最大的改进主要为以下几点：

n         DS ；

n         Deployment Admin Service ；

n         CM ；

n         Eclipse PDE 的支持。

不足的几点：

n         DS 对于企业应用而言仍然显得不够灵活和不够强大，不支持 POJO 依赖注入 ( 这个 Simens 的理解显然有误， DS 是支持 POJO 依赖注入的 ) 、不支持拦截器模式以及缺少与 CM 的交互的定义（ Simens 提出这点应该是希望在组件的配置文件中可以直接使用 CM 中的属性，这点确实支持的还不足）；

n         仍然不支持分布式；

在采用了 OSGi R4 后， Simens 首先是吸取了 DS ，其次就仍然是在分布式部分做出了自己的支持。

l         加入 EEG 来解决不足的部分

OSGi 联盟成立了 EEG 专门来制定 OSGi 在企业应用领域支持不足的部分的规范， Simens 也希望作为其中的一员能够更加好的制定相关的规范，以满足 OSGi 对于企业应用领域的支持。

l         接下来准备做的

制定企业特殊解决方案的标准。

最有趣的仍然是在 PPT 的最后， Simens 提及到了他们希望的 OSGi+SCA 的组合，他们非常的看好 OSGi+SCA 的组合，从这句原话中可以看出：

“ The power combination “OSGi and SCA”allows to use always the best suited technology and to integrate easily in heterogeneous environments. ”

在 PPT 中他们还画出了基于 OSGi+SCA 组合的系统模型：