在本屆
EclipseCon 2007
大會上，
OSGi
占據(jù)了不少的
Topic
，下面就對本次
EclipseCon 2007
大會上
OSGi
相關的主要的一些
Topic
簡單的介紹下，最后總結下通過本次大會形成的反饋
(
信息來源于
OSGi
官方網(wǎng)站
blog
和
EclipseCon 2007
官方網(wǎng)站
)
，關于
EclipseCon
其他方面的精品
Topic
在后續(xù)的
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
搭建松散、動態(tài)的面向服務的系統(tǒng)。
基于
SOBA
這樣的架構體系搭建的系統(tǒng)能夠根據(jù)需求動態(tài)的導入和導出服務，同時繼承了
OSGi
的動態(tài)部署的優(yōu)勢，使得系統(tǒng)能夠動態(tài)的擴展和改變。
此篇
Topic
向參與者介紹
SOBA
的最佳實踐、建議的開發(fā)流程、工具箱、
Equinox
的運行以及客戶端的管理。
個人覺得這篇
Topic
基本還是屬于
OSGi
的基本知識篇，而且這篇
Topic
還沒有去充分發(fā)揮
Declarative Service
的優(yōu)勢，
DS
對于
OSGi
之所以是重大改進，就是它提出了更為符合系統(tǒng)建設的
Service-Oriented Component Model
，當然，這篇
Topic
是從
Architecture
角度去說，自然是
Bundle Architecture
。
Building Server-Side Eclipse based web applications
（★★★★★）
此篇
Topic
介紹開發(fā)基于
OSGi
的
Web
應用的技術、概念以及工具，分為兩個
Short Tutorial
進行講解：
l????????
基于
OSGi
的
Web
應用的開發(fā)和部署
此
Short Tutorial
非常詳細的介紹了基于
OSGi
的
Web
應用開發(fā)的概念、開發(fā)的步驟以及部署的方法，是
OSGi Web
應用開發(fā)的一篇非常好的指導
PPT
。
OSGi Web
應用開發(fā)主要可以采用這么兩種方式：
n????????
調用
HttpService
注冊
Servlet
；
n????????
使用擴展點注冊
Servlet
。
基于
OSGi
的
Web
應用可以采用內嵌的
Http Server
或者部署到現(xiàn)成的應用服務器中。
在部署上此
Short Tutorial
提及的方法就是和
RCP
部署同樣的方法，這方法遠強于我《
OSGi
實戰(zhàn)》
Opendoc
部署的方法，推薦大家采用這種。
最后
PPT
中提及到了現(xiàn)在新支持的
Equinox Application
的編寫方法，這個是非常有意義的東西，也就意味著可以讓
Equinox
的應用和
RCP
應用一樣的運行和管理，這就使得基于
Equinox
的應用也具備了應用級的管理的概念。
l????????
如何使用
Java EE
、
Rich Ajax Platform
或
GWT
構建基于
OSGi
的
Web
應用
這篇
Short Tutorial
介紹了如何使用
Java EE
、
Rich Ajax Platform
或
GWT
這三種方法來開發(fā)基于
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
程序的開發(fā)方法，使得開發(fā)人員可以按照桌面程序開發(fā)的方法來開發(fā)
B/S
應用，而通訊則通過
Ajax
來實現(xiàn)，在客戶端界面上
RAP
完全采用了和
RCP
同樣的構造方法，如
Workbench
等，使用
qooxdoo
來提供客戶端的控件，不過我不是很看好這種東西，我覺得這種一定程度上抹殺了
B/S
應用的優(yōu)勢，
B/S
應用在界面上可以很簡單的做到符合用戶的需求，而其實
C/S
的要做的話就要付出不小的代價。
在
Short Tutorial
中介紹了如何基于
RAP
來開發(fā)基于
OSGi
的
Web
應用，其實從
RAP
的設計思想上就可以看出其實基于
RAP
開發(fā)基于
OSGi
的
Web
應用并不需要做什么特殊的處理，因為
RAP
本身就是基于
OSGi
的。
n????????
GWT
GWT
現(xiàn)在名聲非常的大，基本沒什么可介紹的，不過我覺得它和
RAP
有些的類似，在
Short Tutorial
中也只是簡單的介紹了下如何使用
GWT
來開發(fā)。
Spring and OSGi combined
（★★★）
此篇
Topic
從標題就能夠看出其講解的內容了，就是現(xiàn)在非常火熱的
Spring and OSGi
，這篇
Topic
以一個例子來講解
Spring and OSGi
的使用，這個例子的客戶端基于
RCP
，服務端是基于
Jetty
的
Web
服務。
沒仔細看它的例子，不好評價，由于個人現(xiàn)在還不是那么的看好
Spring and OSGi
，覺得
Spring and OSGi
的發(fā)展還需要時間才能做到真正的融合。
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
，這也就說明了商業(yè)產品又一個采用
OSGi
作為其支撐容器的。
現(xiàn)在
Jboss
也是
OSGi
聯(lián)盟的成員之一。
周三
Ubiquitous Eclipse: Equinox everywhere
（★）
此篇
Topic
通過
Eclipse Runtime
切換為
OSGi
的原因簡單的介紹了下
Equinox
的強大，同時結合一些例子簡單的講解了下
Equinox
在
Server Side
的應用。
Services Everywhere
：
OSGi in Distributed Environments
（★★★★★）
這篇
Topic
說到了大家非常感興趣的話題，在分布式的環(huán)境中如何去使用
OSGi
，這個也是
EEG
目前的重點議題，來看看這篇
Topic
中是采用什么方法來實現(xiàn)基于
OSGi
的分布式應用的。
OSGi
本身是一個面向服務的組件模型，也就是說如果能夠實現(xiàn)分布式的
OSGi
通訊的話，自然也就是
Services Everywhere
了，在任何地方都可以獲取其他地方提供的服務，在實現(xiàn)分布式的技術上，
OSGi R3
中提出的為
Jini
，
OSGi R3
和
R4
中都有的為
UpnP
。
Jini
Jini
是一種網(wǎng)絡化設備類似的基礎架構，它通過一個服務尋找機器來幫助實現(xiàn)分布式的服務的通訊，可以認為它是
Service Discovery+RMI
的組合體。
但是采用
Jini
的話會有這么幾個問題：
l????????
需要服務尋找的中間機器
(
這就使得系統(tǒng)變?yōu)榧惺降模瑔吸c的失敗有可能導致所有系統(tǒng)的失敗
)
；
l????????
需要
RMI
；
(RMI
并不屬于標準的
Java EE
范疇
)
l????????
相對
OSGi
而言偏弱的服務狀態(tài)的通知（如服務被卸載等）；
l????????
配置麻煩。
UPnP
UPnP
適用于設備，設備的
Control Points
能夠發(fā)現(xiàn)和使用服務，設備和服務的信息通過
XML
進行傳遞，動作通過
SOAP
來交互。
采用
UPnP
有這么幾點不好：
l????????
服務必須是
UPnP Services
，
UPnP Services
不具備
OSGi Services
的所有優(yōu)點；
l????????
方法的參數(shù)限定了只有幾種類型；
l????????
不能訂閱特殊的事件；
l????????
SOAP
的性能。
根據(jù)對于
Jini
和
UPnP
的分析，兩者或多或少都有些問題和不足，在
PPT
中提出了需要一種新的方案，接著往下：
首先提到了分布式
OSGi
需要達到的目標：
l????????
透明化（本地和遠程的服務使用起來沒有什么區(qū)別）
l????????
無侵入（在服務的實現(xiàn)上沒有要求）
l????????
無縫集成
l????????
按需選擇
l????????
統(tǒng)一
講到這，
Topicer
終于講到了實現(xiàn)分布式
OSGi
的東西：
R-OSGi(http://r-osgi.sourceforge.net)
，來看看
R-OSGi
是如何實現(xiàn)上面所說的幾個目標的：
l????????
按需選擇
通過注冊一個
DiscoveryListener
來選擇所需的服務。
l????????
無縫集成
基于
RFC 2608
：服務地址協(xié)議
(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
的幾個系統(tǒng)，如
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
具備的優(yōu)勢：
n????????
自然的支持
SOA
應用；
n????????
組件模型；
n????????
服務的生命周期；
n????????
可用服務的注冊和尋找；
n????????
支持多線程應用；
n????????
開發(fā)工具的支持，例如
Eclipse
。
最關心的還是不足的幾點：
n????????
限制為單容器運行，不支持分布式；
n????????
服務模型限制為
OSGi
容器環(huán)境內的，不能調用其他外部的服務，外部也無法調用
OSGi
容器內的服務；
n????????
監(jiān)聽和追蹤都必須手工編寫代碼實現(xiàn)；
n????????
缺少對于多種通訊模式
(tcp
、
https
等
)
的支持；
n????????
缺少對于聲明式的依賴管理的描述；
n????????
缺少攔截器模式的支持；
n????????
缺少非
OSGi
應用的部署和配置的支持；
n????????
缺少對于基于用戶認證和授權的支持。
對于
OSGi R3
不熟，我無法評價，不過它列出的這幾點對于企業(yè)應用而言確實很有必要。
Simens
提出了他們對于
OSGi R3
這幾點不足的解決方案：
n????????
基于
MOM
集成了
Service Bus
，這也就實現(xiàn)了服務的分布式通訊，并且基于
MOM
自然就支持了多種通訊的方式和協(xié)議；
n????????
對于
Bundle
增加了以
XML
方式描述該
Bundle
中的組件、服務以及依賴關系（這些在
OSGi R4
的
DS
中得到了支持）；
n????????
注冊接口為
OSGi
服務，并支持在外部調用這些服務；
n????????
使用
IoC
模式注入依賴服務；
n????????
基于
Spring AOP
實現(xiàn)基于用戶的認證和授權。
l????????
OSGi R4
改進了不少，不過仍然有提升的空間
對于
OSGi R4
，
Simens
認為最大的改進主要為以下幾點：
n????????
DS
；
n????????
Deployment Admin Service
；
n????????
CM
；
n????????
Eclipse PDE
的支持。
不足的幾點：
n????????
DS
對于企業(yè)應用而言仍然顯得不夠靈活和不夠強大，不支持
POJO
依賴注入
(
這個
Simens
的理解顯然有誤，
DS
是支持
POJO
依賴注入的
)
、不支持攔截器模式以及缺少與
CM
的交互的定義（
Simens
提出這點應該是希望在組件的配置文件中可以直接使用
CM
中的屬性，這點確實支持的還不足）；
n????????
仍然不支持分布式；
在采用了
OSGi R4
后，
Simens
首先是吸取了
DS
，其次就仍然是在分布式部分做出了自己的支持。
l????????
加入
EEG
來解決不足的部分
OSGi
聯(lián)盟成立了
EEG
專門來制定
OSGi
在企業(yè)應用領域支持不足的部分的規(guī)范，
Simens
也希望作為其中的一員能夠更加好的制定相關的規(guī)范，以滿足
OSGi
對于企業(yè)應用領域的支持。
l????????
接下來準備做的
制定企業(yè)特殊解決方案的標準。
最有趣的仍然是在
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
組合的系統(tǒng)模型：
J
，希望
SCA
規(guī)范小組看到這個后有所反應，一直就非常的期待
OSGi
和
SCA
的強強組合。
Login and Go: Flipping plug-in distribution on its head
（★）
此篇
Topic
由
Cisco
的員工主講，講解的為
Cisco
的一個產品
Maya
，它是一個基于
Equinox
而構建的產品，同樣是分布式的，在通訊上它采用了
WebServices
來實現(xiàn)。
Integrating OSGi Bundle Repository (OBR) inside Eclipse for Bundle Deployment
（★★★）
這個
Short Talk
簡單的提及到了在
Eclipse
中直接使用
OBR
可以使得
Bundle
的部署和使用更加的方便，這個確實是如此，使用過
Equinox
進行開發(fā)的人就知道了，對于一個
Team
而言如果能搭建一個共同的
Bundle
倉庫的話那就能夠使得開發(fā)更加的方便。
不過目前
OBR
還不是
OSGi
中的標準，它目前只是
OSGi
聯(lián)盟的一個建議，不過已經有不少應用的場景了，
OBR
有點類似
Perl
中的
PPM
呀、
Maven
中的倉庫，這個相信對于將來
Eclipse
的
Update Site
的那種機制都會有影響，當然，這是一種好的改進。
Realizing the Plug and Play dream in the home network
（★★★）
這個
Short Talk
講到的就是今年
OSGi
重點發(fā)展的領域：智能家居領域，這個領域上而言
OSGi
無疑是具備了非常大的優(yōu)勢，
J
。
在分布式方面，由于智能家居上都是對于設備的控制，所以采用
UPnP
實現(xiàn)是很適合的。
J
，能夠基于
OSGi
來實現(xiàn)智能家居是一件很有趣的事，有機會需要玩玩這方面。
周四
Spring-OSGi
：
The Integration of Spring Framework and OSGi
（★★★★）
這個
Short Talk
簡單的介紹了下基于
Spring-OSGi
如何在
Spring
中訪問
OSGi
的
Service
，如何將
Spring
的
Bean
發(fā)布為
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
的成員主講，無疑現(xiàn)在
BEA
在
OSGi
的使用上也有了充足的經驗，這篇
Topic
之前基本都是對于
mSA
的一些講述，暫且忽略，不過從前面倒是發(fā)現(xiàn)
BEA
和我們公司有個共同的做法，就是實現(xiàn)了一個自己的
Equinox Launcher
，這也是我之前一直宣揚的
TPF
中的重要部分，基于這個
Equinox Launcher
就可以實現(xiàn)應用級別的插件的管理以及應用級別的生命周期的管理，通過這個
Launcher
可以定義出系統(tǒng)最小的核心是由哪些插件構成的，而其他的應用插件又有哪一些，在管理時則可以針對應用插件進行管理，在這樣的情況下，只要系統(tǒng)的最小核心仍然運行正常，那么其他的一切也就好辦了，
J
，這非常有助于實現(xiàn)遠程的應用程序的管理（模塊的分發(fā)、升級和配置等）。
J
，看
BEA
寫的他們實現(xiàn)的
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
也提到了，傳統(tǒng)的代碼也移植到
OSGi
還是非常麻煩，原因同樣是上面的那句話；
n????????
代碼的模塊化，這里同樣有句很經典的話：
”
Until modularity is not enforced, it is not there”
，確實是如此，當不用
OSGi
的時候，也許你認為你的系統(tǒng)是模塊化的設計、實現(xiàn)的，但如果真正使用
OSGi
的時候，你就會發(fā)現(xiàn)以前系統(tǒng)根本就沒有做到真正的模塊化，會發(fā)現(xiàn)有很大的差距。
l????????
Bad
n????????
在
DS
上，
BEA
提及的不足主要是
DS
對于兩階段生命周期支持的不足，這個其實是事務性的概念，這點是
OSGi
對于企業(yè)應用領域而言一個很大的不足；
n????????
安全性，這個之前的
Topic
中也有提及；
n????????
配置，這點我覺得是
BEA
對于
CM
研究的不夠造成的，其實
CM
已經能夠達到
BEA
所提及的要求了。
l????????
Ugly
n????????
Java
平臺和
OSGi
的集成
Java SE
中的
URL Handlers
無法轉入
OSGi
中；
JNDI Providers
這一塊現(xiàn)在也不好集成。
n????????
Bundle
安裝模型
在這一個部分
BEA
希望
OSGi
能夠支持將
Bundle
放入統(tǒng)一的服務器，然后每個應用選擇性的加載其中的部分
Bundle
，這其實就是
OBR
的工作了；
另外
BEA
希望
OSGi
能有啟動的標準的
API
，這個在
Equinox
中倒是開始做了，就是之前
Topic
中有講到的
Equinox Application
，有了那個后這點就實現(xiàn)了，不過還不是
OSGi
的標準
API
就是，不知道
OSGi R5
中是否會考慮這點。
這篇
Topic
畢竟是
BEA
的經驗之談，對于實戰(zhàn)還是具備了不小的指導作用的，盡管
Topic
有過多宣傳
mSA
的嫌疑，
J
，如果
BEA
能把它的那些
Bundle
貢獻出來的話那就更好了，之前
ProSyst
可是把他們的
DS
、
CM
這些實現(xiàn)貢獻出來了。
Using an OSGi Back-end System for the Purpose of Enterprise Management of Eclipse IDEs
（★★★）
此篇
Topic
由
ProSyst
公司員工主講，
ProSyst
無疑現(xiàn)在已經成為
OSGi
界的重要成員，他們在
OSGi
的豐富經驗也使得他們成為了這方面的頂尖公司，在這篇
Topic
中他們詳細的講述了其基于
OSGi
實現(xiàn)的企業(yè)管理的后臺系統(tǒng)，通過他們的這套管理系統(tǒng)可以通過多種協(xié)議
(SNMP
、
CIM
等
)
對于設備、應用的遠程管理。
總結
從四天的
Topic
中欣喜的發(fā)現(xiàn)，
OSGi
已經成為了
EclipseCon
大會的重要話題，這也就意味著目前
OSGi
在
Java
軟件界的地位，而從
Topic
的主講者（來自
IBM
、
Cisco
、
BEA
、
Simens
等等）中我們也同樣非常高興的看到各大軟件公司對于
OSGi
的使用和高度評價，而同時各大公司也針對
OSGi
在企業(yè)應用領域的不足提出了各自的解決方案，這必將大大的推動
OSGi
在企業(yè)應用領域的發(fā)展。
幾天的
Topic
中精品無數(shù)，都值得細細的品位，在閱讀過幾天的
Topic
后，對于每篇
Topic
我按照自己感興趣的程度以及講解的精彩程度給了個推薦的星級，跟隨在了
Topic
標題的后面。
這次大會上
OSGi
的
Topic
主要集中在了兩個方面：
l????????
推廣和介紹
OSGi
的使用方法
由于這是第一次
OSGi
成為
EclipseCon
大會的話題，推廣和介紹
OSGi
仍然是非常重要的事，所以在本次大會上也避免不了介紹
OSGi
的話題，以及一些
OSGi
使用的指導性質的講座。
l????????
OSGi
在企業(yè)應用領域的不足和解決方案
OSGi
在
IBM
、
Cisco
、
BEA
、
Simens
這些公司中都有實際的應用經驗，他們將他們在應用時發(fā)現(xiàn)的
OSGi
的不足以及他們的解決方案都貢獻了出來，這對于
OSGi
在企業(yè)應用領域的發(fā)展自然是起到了巨大的推動作用。
從這些
Topic
中可以看出
OSGi
在企業(yè)應用領域支持的不足主要集中在了分布式、事務等領域，而在分布式方面主要的解決方案有
R-OSGi
、
MOM+OSGi
、
SCA+OSGi
、
Webservices
等等方式。
應該說，本次大會對于
OSGi
而言是里程碑式的事件，通過這次大會極大的推廣了
OSGi
，同時也推進了
OSGi
進軍企業(yè)應用領域的步伐，讓我們共同期待在明年的
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”
而在規(guī)范的模塊化方面，
OSGi
是此方面為數(shù)不多的規(guī)范之一，而且是目前非常成功的規(guī)范。
l????????
OSGi
的服務模型
OSGi
的面向服務的組件模型得到了
OSGiers
強力推崇，
J
，原來連
OSGi
聯(lián)盟自己都沒想到這塊會獲得這么大的成功，
OSGi
的面向服務的組件模型是其成功的重要因素之一。
l????????
OSGi
書籍的迫切需求
通過本屆大會，
Peter
也發(fā)現(xiàn)
OSGi
實戰(zhàn)方面的書籍已經有巨大的需求了，
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