在本届
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
组合的系统模型：
J
，希望
SCA
规范小组看到这个后有所反应，一直就非常的期待
OSGi
和
SCA
的强强组合。
Login and Go: Flipping plug-in distribution on its head
（★）
此篇
Topic
由
Cisco
的员工主讲，讲解的为
Cisco
的一个产品
Maya
，它是一个基于
Equinox
而构建的产品，同样是分布式的，在通讯上它采用了
WebServices
来实现。
Integrating OSGi Bundle Repository (OBR) inside Eclipse for Bundle Deployment
（★★★）
这个
Short Talk
简单的提及到了在
Eclipse
中直接使用
OBR
可以使得
Bundle
的部署和使用更加的方便，这个确实是如此，使用过
Equinox
进行开发的人就知道了，对于一个
Team
而言如果能搭建一个共同的
Bundle
仓库的话那就能够使得开发更加的方便。
不过目前
OBR
还不是
OSGi
中的标准，它目前只是
OSGi
联盟的一个建议，不过已经有不少应用的场景了，
OBR
有点类似
Perl
中的
PPM
呀、
Maven
中的仓库，这个相信对于将来
Eclipse
的
Update Site
的那种机制都会有影响，当然，这是一种好的改进。
Realizing the Plug and Play dream in the home network
（★★★）
这个
Short Talk
讲到的就是今年
OSGi
重点发展的领域：智能家居领域，这个领域上而言
OSGi
无疑是具备了非常大的优势，
J
。
在分布式方面，由于智能家居上都是对于设备的控制，所以采用
UPnP
实现是很适合的。
J
，能够基于
OSGi
来实现智能家居是一件很有趣的事，有机会需要玩玩这方面。
周四
Spring-OSGi
：
The Integration of Spring Framework and OSGi
（★★★★）
这个
Short Talk
简单的介绍了下基于
Spring-OSGi
如何在
Spring
中访问
OSGi
的
Service
，如何将
Spring
的
Bean
发布为
OSGi Service
。
由于它的
ppt
下载过来打不开，对这个
Topic
不是很好评价，不过应该说还是不错的，毕竟这也算是
Spring-OSGi
使用的
Tutorial
。
The Good,Bad,and Ugly of OSGi
：
What we learned building the mSA Backplane
（★★★★★）
这个
Topic
由
BEA mSA Team
的成员主讲，无疑现在
BEA
在
OSGi
的使用上也有了充足的经验，这篇
Topic
之前基本都是对于
mSA
的一些讲述，暂且忽略，不过从前面倒是发现
BEA
和我们公司有个共同的做法，就是实现了一个自己的
Equinox Launcher
，这也是我之前一直宣扬的
TPF
中的重要部分，基于这个
Equinox Launcher
就可以实现应用级别的插件的管理以及应用级别的生命周期的管理，通过这个
Launcher
可以定义出系统最小的核心是由哪些插件构成的，而其他的应用插件又有哪一些，在管理时则可以针对应用插件进行管理，在这样的情况下，只要系统的最小核心仍然运行正常，那么其他的一切也就好办了，
J
，这非常有助于实现远程的应用程序的管理（模块的分发、升级和配置等）。
J
，看
BEA
写的他们实现的
Bundle
，实在是比较诱惑，如果将来这些都贡献出来的话就好了，呵呵，例如
JNDI
、
RMI
、
JTA
等等。
重点我们来看看
BEA
对于
OSGi
的
Good
、
Bad
以及
Ugly
这几点的评价。
l
Good
n
OSGi
包装载机制，这块列出的原因主要是这句话：
”If the build and test environments do not enforce modularity, then the code is not modular”
，这句话非常的经典，
J
，不过
BEA
也提到了，传统的代码也移植到
OSGi
还是非常麻烦，原因同样是上面的那句话；
n
代码的模块化，这里同样有句很经典的话：
”
Until modularity is not enforced, it is not there”
，确实是如此，当不用
OSGi
的时候，也许你认为你的系统是模块化的设计、实现的，但如果真正使用
OSGi
的时候，你就会发现以前系统根本就没有做到真正的模块化，会发现有很大的差距。
l
Bad
n
在
DS
上，
BEA
提及的不足主要是
DS
对于两阶段生命周期支持的不足，这个其实是事务性的概念，这点是
OSGi
对于企业应用领域而言一个很大的不足；
n
安全性，这个之前的
Topic
中也有提及；
n
配置，这点我觉得是
BEA
对于
CM
研究的不够造成的，其实
CM
已经能够达到
BEA
所提及的要求了。
l
Ugly
n
Java
平台和
OSGi
的集成
Java SE
中的
URL Handlers
无法转入
OSGi
中；
JNDI Providers
这一块现在也不好集成。
n
Bundle
安装模型
在这一个部分
BEA
希望
OSGi
能够支持将
Bundle
放入统一的服务器，然后每个应用选择性的加载其中的部分
Bundle
，这其实就是
OBR
的工作了；
另外
BEA
希望
OSGi
能有启动的标准的
API
，这个在
Equinox
中倒是开始做了，就是之前
Topic
中有讲到的
Equinox Application
，有了那个后这点就实现了，不过还不是
OSGi
的标准
API
就是，不知道
OSGi R5
中是否会考虑这点。
这篇
Topic
毕竟是
BEA
的经验之谈，对于实战还是具备了不小的指导作用的，尽管
Topic
有过多宣传
mSA
的嫌疑，
J
，如果
BEA
能把它的那些
Bundle
贡献出来的话那就更好了，之前
ProSyst
可是把他们的
DS
、
CM
这些实现贡献出来了。
Using an OSGi Back-end System for the Purpose of Enterprise Management of Eclipse IDEs
（★★★）
此篇
Topic
由
ProSyst
公司员工主讲，
ProSyst
无疑现在已经成为
OSGi
界的重要成员，他们在
OSGi
的丰富经验也使得他们成为了这方面的顶尖公司，在这篇
Topic
中他们详细的讲述了其基于
OSGi
实现的企业管理的后台系统，通过他们的这套管理系统可以通过多种协议
(SNMP
、
CIM
等
)
对于设备、应用的远程管理。
总结
从四天的
Topic
中欣喜的发现，
OSGi
已经成为了
EclipseCon
大会的重要话题，这也就意味着目前
OSGi
在
Java
软件界的地位，而从
Topic
的主讲者（来自
IBM
、
Cisco
、
BEA
、
Simens
等等）中我们也同样非常高兴的看到各大软件公司对于
OSGi
的使用和高度评价，而同时各大公司也针对
OSGi
在企业应用领域的不足提出了各自的解决方案，这必将大大的推动
OSGi
在企业应用领域的发展。
几天的
Topic
中精品无数，都值得细细的品位，在阅读过几天的
Topic
后，对于每篇
Topic
我按照自己感兴趣的程度以及讲解的精彩程度给了个推荐的星级，跟随在了
Topic
标题的后面。
这次大会上
OSGi
的
Topic
主要集中在了两个方面：
l
推广和介绍
OSGi
的使用方法
由于这是第一次
OSGi
成为
EclipseCon
大会的话题，推广和介绍
OSGi
仍然是非常重要的事，所以在本次大会上也避免不了介绍
OSGi
的话题，以及一些
OSGi
使用的指导性质的讲座。
l
OSGi
在企业应用领域的不足和解决方案
OSGi
在
IBM
、
Cisco
、
BEA
、
Simens
这些公司中都有实际的应用经验，他们将他们在应用时发现的
OSGi
的不足以及他们的解决方案都贡献了出来，这对于
OSGi
在企业应用领域的发展自然是起到了巨大的推动作用。
从这些
Topic
中可以看出
OSGi
在企业应用领域支持的不足主要集中在了分布式、事务等领域，而在分布式方面主要的解决方案有
R-OSGi
、
MOM+OSGi
、
SCA+OSGi
、
Webservices
等等方式。
应该说，本次大会对于
OSGi
而言是里程碑式的事件，通过这次大会极大的推广了
OSGi
，同时也推进了
OSGi
进军企业应用领域的步伐，让我们共同期待在明年的
EclipseCon
大会上
OSGi
更加辉煌、更加闪光的
Topic
。
来看看
OSGi
主席
Peter
对于本次大会的总结：
Peter
总结了本次大会上
OSGi
的
Top 3 Observations
：
l
OSGi
成功的应用案例
本届大会上来自
Jboss
、
BEA
、
IBM
、
Siemens
、
Oracle
以及其他公司的人都展示了各自公司使用
OSGi
的成功案例，基本的共同点就是都提及到了享受
OSGi
所提供的模块化所带来的巨大好处，
Peter
表示他也很同意
BEA
所说的那句话“如果没有强制的使用模块化，那么也就不存在模块化了“，
Peter
则用另外一句话来表达了这句意思：
” if you do not verify the modularity of the systems you build, it is highly unlikely that you will have it”
而在规范的模块化方面，
OSGi
是此方面为数不多的规范之一，而且是目前非常成功的规范。
l
OSGi
的服务模型
OSGi
的面向服务的组件模型得到了
OSGiers
强力推崇，
J
，原来连
OSGi
联盟自己都没想到这块会获得这么大的成功，
OSGi
的面向服务的组件模型是其成功的重要因素之一。
l
OSGi
书籍的迫切需求
通过本届大会，
Peter
也发现
OSGi
实战方面的书籍已经有巨大的需求了，
Peter
表示他希望能在今年抽出时间来写这方面的书，极度的期待，
J
，不知道到时国内会不会引进。
资源
Topic
索引
http://www.eclipsecon.org/2007/index.php?page=sub/&id=4202
Blog
http://www.osgi.org/blog/2007/03/eclipsecon-monday-wrap-up.html
http://www.osgi.org/blog/2007/03/if-you-followed-this-blog-you-have.html