三十乱弹

OSGI错过了Geronimo

yanfei — Wed, 05 Nov 2008 09:41:45

在OSGI联盟主席Peter.Kriens的博客上看到说他错过了Geronimo，不觉有几分惋惜。在网上看到说Geronimo准备迁移到OSGI上，估计是假的。

Geronimo将50多个开源项目打包成了一个J2EE服务器，IBM网站上称它是一个洋葱式的容器嵌套结构，靠的就是它的GBean，GBean之间的引用和交互，则靠cglib生成的动态代理。

不过，有好事者已经将Geronimo迁移到了OSGI之上，这个网址介绍了他的做法：http://www.mail-archive.com/dev@geronimo.apache.org/msg10923.html。

不过看到ObjectWeb的JOnAS 5 的规划中, OSGi作为一个重要的基础设施被引入. 出于以下原因, JOnAS 5 将采用 OSGi 作为其架构和服务的基础。

„ OSGi enforce modularity with the Bundle concept

„ OSGi provide standard mechanism for Classes isolation and versionning

„ OSGi help us for remote artifacts deployment

„ OSGi is lightweight

„ OSGi handle dependencies issues (services inter-linking)

„ OSGi have large industry support

Equinox OSGI平台中集成Tuscany SCA容器

yanfei — Tue, 27 Nov 2007 20:11:33

本文介绍如何在Equinox中集成Tuscany，Tuscany容器作为OSGI环境中的一个Bundle存在。同时一个Contribution也对应为一个Bundle，此种方式使Tuscany的Contribution具有了热部署和动态修改替换的能力。这也是Tuscany邮件组中目前正在讨论的问题。

修改Tuscany：

1. 创建OsgiSCADomain,继承自SCADomain. OsgiSCADoamin参照DefaultSCADomain,做了少许改动。

a) DefaultSCADomain是在构造方法中加载Contribution的资源。修改OsgiSCADomain，添加initContribution(Bundle bundle)方法。代码片断如下：

ContributionService contributionService = runtime.getContributionService();

URL contributionURL;

try {

contributionURL = getContributionLocation(bundle);

if (contributionURL != null) {

// Make sure the URL is correctly encoded (for example, escape the space characters)

contributionURL = contributionURL.toURI().toURL();

}

} catch (Exception e) {

thrownew ServiceRuntimeException(e);

}

以上代码，获取Bundle的META-INF目录下sca-contribution.xml的URL,并通过ContributionService的contribute加载sca-contribution.xml及其他资源文件。在实验代码中仅考虑.composite文件。

b) 替换org.apache.tuscany.sca.host.embedded.SCADomain扩展点实现为org.apache.tuscany.sca.host.embedded.impl.OsgiSCADomain。

2. 另一个主要问题是要考虑ClassLoader的问题。在OSGI中，不同的Contribution使用不同的ClassLoader。因此在org.eclipse.equinox.tuscany插件中对构件进行装配时，无法加载构件描述文件的的类。

a) 新建BundleProxyClassLoader，Bundle默认不对外提供ClassLoader，因此创建一个代理ProxyClassLoader。BundleProxyClassLoader的代码参见：http://wiki.eclipse.org/index.php/BundleProxyClassLoader_recip

3. BundleContext在Tuscany中传递的问题。如果要将BundleContext直接在Tuscany中传递，需要修改大量已有代码，代价较大。采用折中方法。修改Contribution接口，添加setBundle和getBundle方法。

Bundle getBundle();

void setBundle(Bundle bundle);

4. 修改ContributionServiceImpl,

a) 添加addContribution方法，在此方法中将Bundle设置给Contribution。

b) 添加readContributionMetadata方法。在此方法中将BundleProxyClassLoader传给ContributionMetadataDocumentProcessor，用户加载sca-contribution.xml文件。

private Contribution readContributionMetadata(Bundle bundle) throws ContributionException{

Contribution contributionMetadata = null;

ClassLoader cl = new BundleProxyClassLoader(bundle);

ContributionMetadataDocumentProcessor metadataDocumentProcessor =

new ContributionMetadataDocumentProcessor(cl, staxProcessor, assemblyFactory, contributionFactory,

xmlFactory);

contributionMetadata = contributionFactory.createContribution();

try {

metadataDocumentProcessor.read(contributionMetadata);

} catch (XMLStreamException e) {

thrownew InvalidContributionMetadataException("Invalid contribution metadata for contribution.");

}

return contributionMetadata;

}

5. 修改ClassReferenceModelResolver，使用Contribution中Bundle的ClassLoader来加载Java Class。

public ClassReferenceModelResolver(Contribution contribution, ModelFactoryExtensionPoint modelFactories) {

this.contribution = contribution;

//FIXME The classloader should be passed in

// this.classLoader = new WeakReference(Thread.currentThread().getContextClassLoader());

this.classLoader = new WeakReference(new BundleProxyClassLoader(contribution.getBundle()));

try {

Class osgiResolverClass =

Class.forName("org.apache.tuscany.sca.contribution.osgi.impl.OSGiClassReferenceModelResolver");

if (osgiResolverClass != null) {

Constructor constructor =

osgiResolverClass.getConstructor(Contribution.class, ModelFactoryExtensionPoint.class);

this.osgiResolver = (ModelResolver)constructor.newInstance(contribution, modelFactories);

}

} catch (Exception e) {

}

创建org.apache.tuscany和org.eclipse.equinox.tuscany两个插件

org.apache.tuscany插件包含了Tuscany运行时刻类库文件。

org.eclipse.equinox.tuscany则负责在OSGI容器中启动SCA容器，并遍历ACTIVE的Bundle，加载Bundle中的SCA资源。

SCAActivator代码如下：

publicclass SCAActivator implements BundleActivator, BundleTrackerCustomizer, SynchronousBundleListener {

private SCADomain scaDomain;

private BundleTracker bundleTracker;

privatestatic SCAActivator activator;

public SCAActivator() {

activator = this;

}

publicstatic SCAActivator getDefault() {

returnactivator;

}

* (non-Javadoc)

* @see org.osgi.framework.BundleActivator#start(org.osgi.framework.BundleContext)

publicvoid start(BundleContext bundleContext) throws Exception {

scaDomain = SCADomain.newInstance();

bundleContext.registerService(SCADomain.class.getName(), scaDomain, null);

bundleTracker = new BundleTracker(bundleContext, Bundle.ACTIVE, this);

bundleContext.addBundleListener(this); //track UNRESOLVED events

bundleTracker.open();

}

* (non-Javadoc)

* @see org.osgi.framework.BundleActivator#stop(org.osgi.framework.BundleContext)

publicvoid stop(BundleContext context) throws Exception {

scaDomain.close();

}

publicvoid bundleChanged(BundleEvent event) {

if (event.getType() == BundleEvent.UNRESOLVED) {

//TODO

}

elseif (event.getType() == BundleEvent.RESOLVED) {

//TODO

}

public Object addingBundle(Bundle bundle) {

if (scaDomaininstanceof OsgiSCADomain) {

OsgiSCADomain domain = (OsgiSCADomain)scaDomain;

domain.initContribution(bundle);

}

returnnull;

}

publicvoid modifiedBundle(Bundle bundle, Object object) {

//TODO

}

publicvoid removedBundle(Bundle bundle, Object object) {

//TODO

}

public SCADomain getScaDomain() {

returnscaDomain;

}

运行时刻调用

在Servlet中可以使用如下方式调用：

publicvoid doGet(HttpServletRequest request, HttpServletResponse response)

throws IOException{

response.setContentType("text/html");

ServletOutputStream output=response.getOutputStream();

SCADomain scaDomain = SCAActivator.getDefault().getScaDomain();

CalculatorService calculatorService =

scaDomain.getService(CalculatorService.class, "CalculatorServiceComponent");

// Calculate

output.println("3 + 2=" + calculatorService.add(3, 2) + "
");

output.println("3 - 2=" + calculatorService.subtract(3, 2) + "
");

output.println("3 * 2=" + calculatorService.multiply(3, 2) + "
");

output.println("3 / 2=" + calculatorService.divide(3, 2) + "
");

}

Eclipse Equinox OSGI Declarative Service 实现分析

yanfei — Sun, 25 Nov 2007 18:11:12

Equinox项目是Eclipse开源组织提供的OSGi框架的实现。Equinox 的org.eclipse.equinox.ds项目提供了OSGi R4规范中的Declarative Service标准服务的实现。Declarative Service提供了基于OSGI平台之上的面向服务构件模型(Service-Oriented Component Model)，也为在OSGI基础之上搭建SOA应用提供了可能。

背景信息

Equinox项目是Eclipse开源组织提供的OSGi框架的实现。Eclipse自3.0版本开始，其内核移植到OSGi框架上。通过OSGi框架强大的组件控制，交互和管理能力，再加上Eclipse插件的自有特点，Eclipse开源框架得到了跳跃式的发展。同时，OSGi规范得益于Eclipse IDE环境庞大的使用者，OSGi联盟也进入了快速发展时期。

Equinox项目概述

Equinox项目包括OSGi R4版本规范核心框架的实现，一系列OSGi标准服务Bundle及运行基于OSGi的系统的一些基础构件。目前，Equinox项目包括OSGi核心框架的实现，OSGi标准服务Bundle实现，OSGi的服务器端（J2EE实现）应用，Equinox部署更新框架及一些研究方向（未成熟发布的构想如JMX管理，安全管理，面向方面的设计与应用等）。

Equinox Declarative Services(DS)

Equinox 的org.eclipse.equinox.ds项目提供了OSGi R4规范中的Declarative Service标准服务的实现，该组件由Prosyst公司提供实现。Declarative Service提供了基于OSGI平台之上的面向服务构件模型(Service-Oriented Component Model)，也为在OSGI基础之上搭建SOA应用提供了可能。Declarative Service实现并没有包含在Eclipse的默认软件包中，需要从Eclipse的CVS中获取。代码位于:pserver:anonymous:dev.eclipse.org/cvsroot/eclipse路径下。

Equinox在没有DS实现之前，对于服务的注册需要手工来做，如下面的代码：

service = new HelloServiceImpl();

// register the service

context.registerService(HelloService.class.getName(), service, new Hashtable());

// create a tracker and track the service

helloServiceTracker = new ServiceTracker(context, HelloService.class.getName(), null);

helloServiceTracker.open();

// grab the service

service = (HelloService) helloServiceTracker.getService();

service.speak();

在提供了DS之后可以采用XML文件的方式来声明：

上面的XML文件声明了HelloService的构件，实现类是com.primeton.osgi.HelloServiceImpl，同时，声明了构件的服务接口为com.primeton.osgi.HelloService。如果不声明服务，当你使用类似下面的代码是查找不到服务的：

ServiceReference reference = context.getServiceReference(TestService.class.getName());

TestService service = (TestService)context.getService(reference);

service.test();

调用BundleContext的getServiceReference方法将返回空。

类似于SCA规范的构件装配模型，Component可以引用别的Component的服务。如我们声明一个TestService，TestService引用了HelloService。

是不是和SCA的装配模型描述文件有点相似呢？^_^

下面对Equinox的Declarative Service的实现进行一下分析。

加载ComponentDescriptor

首先，构件的描述文件是如何被加载的呢？加载由org.eclipse.equinox.ds.tracker.BundleTracker来实现。BundleTracker会遍历所有的Bundle处于ACTIVE状态的Bundle,BundleTracker回调BundleTrackerCustomizer的addingBundle方法，读取所有的ComponentDescriptor，并加入到异步工作队列WorkQueue中。

Resovle ComponentDescriptor

加入到异步队列中的ComponentDescriptor需要由org.eclipse.equinox.ds.resolver. Resolver进行解析，判断Component所依赖的服务构件是否都存在，并满足条件。然后创建ComponentConfiguration。

解析Manifest Header

org.eclipse.equinox.ds.parser.Parser会解析Manifest文件，读取Manifest文件中的Service-Component属性。代码如下：

private ManifestElement[] parseManifestHeader(Bundle bundle) {

Dictionary headers = bundle.getHeaders();

String files = (String) headers.get(ComponentConstants.SERVICE_COMPONENT);

try {

return ManifestElement.parseHeader(ComponentConstants.SERVICE_COMPONENT, files);

} catch (BundleException e) {

Log.log(1, "[SCR] Error attempting parse Manifest Element Header. ", e);

returnnew ManifestElement[0];

}

因此，为了使Component的描述文件被加载，必须在Manifest文件中申明要加载的xml文件。如下所示：

Manifest-Version: 1.0

Bundle-ManifestVersion: 2

Bundle-Name: Test Plug-in

Bundle-SymbolicName: test

Bundle-Version: 1.0.0

Service-Componen: test.xml

Import-Package: org.osgi.framework;version="1.3.0",

org.osgi.util.tracker;version="1.3.1"

Eclipse-LazyStart: true

解析ComponentDescriptor

org.eclipse.equinox.ds.parser.Parser同时会负责解析构件描述文件。

创建Component实例

org.eclipse.equinox.ds.instance.BuildDispose负责根据ComponentDescriptor创建Component的实例。具体参见buildComponentConfigInstance方法。

ComponentDescription componentDescription = componentConfiguration.getComponentDescription();

Object instance = createInstance(componentDescription);

componentInstance = instantiate(componentConfiguration, instance);

createComponentContext(usingBundle, componentInstance);

bind(componentInstance);

activate(componentInstance);

componentConfiguration.addInstance(componentInstance);

1. 首先从ComponentConfiguration中获取ComponentDescriptor.

2. 根据ComponentDescritptor创建一个Component的实例。

3. 创建Component的上下文ComponentContext。

4. 将Component需要的Service进行绑定。

5. 调用Component的activate方法，激活Component。

Component可以是任何一个Java类，而不需要继承或实现OSGI的类或接口，但可以定义一个activate方法，在Component被激活时作相关处理。

org.eclipse.equinox.ds.instance.InvokeMethod负责在调用Component的相关方法，采用类反射的机制将Server绑定到Component上。InvokeMethod的findBindOrUnbindMethod会在Component的实现类和超类中去查找绑定方法。

从以上分析，可以看出Equinox的Declarative Service实现了一个服务构件定义、加载、装配、服务查找的一个服务构件运行环境。和SCA的构件装配模型异曲同工。Declarative Service规范应该早于SCA规范的制定，因此，在某种程度上，SCA装配模型参考了Declarative Service的服务构件模型，并在此基础上发展完善，多出了Contribution、Composite等概念，对于服务绑定的范畴也进行了拓宽，并不局限于Java语言的Service，从而做到了语言无关、平台无关。

OSGI作为WEB应用底层基础设施的问题

yanfei — Sun, 18 Nov 2007 11:11:49

OSGI在这一两年在开发者中被广泛的熟知，除了作为Eclipse的底层模块化框架之外，OSGI作为服务端应用的模块化框架支持也在不断的实践和尝试中。Equinox作为一个比较成熟的OSGI r4实现被广泛使用。 OSGI基于Equinox实现应用的在服务端应用目前主要有以下两种方式： 1.Equinox嵌入应用服务器容器中 2.应用服务器潜入Equinox中上面的两种不同的方式，我更看好第二种部署方式，可以更加灵活的支持更大型的应用。目前Eclipse的Equinox内置了Jetty来支持Http和Servlet访问。但也仅提供了一个WEB容器，而缺少其他的J2EE服务。一个显而易见的问题就是，如果要现有WEB应用移植到OSGI方式的容器中来，最大的问题就是应用服务器对OSGI的支持如何？值得我们期待的是，IBM下一个版本的Web Sphere的底层会使用OSGI，Bea最新版本的WebLogic10.3已经基于microService，而microService也正是基于OSGI框架，但如果对于一个能够适应多应用服务器平台的产品，还是要考虑对老版本的应用服务器和其他种类的应用服务器对OSGI的支持。因此，从这点来看，OSGI在Web服务端的大规模应用也许还需要时间。
--

Eclipse 4.0的目标是更小、更快、更简单

yanfei — Wed, 14 Nov 2007 12:11:56

A major overhaul of the Eclipse code base may be a long time off, but it"s on the minds of some of the leaders of the open-source tools platform.

在近期的Eclipse World 2007的座谈会上，Eclipse基金会的执行总监Mike Milinkovich说如果我们做Eclipse 4.0的话，它必须比现在的Eclipse更小、更快、更简单。这就意味这，Eclipse 4.0将会对现有的Eclipse 代码进行一次比较大的翻新，并在开发中时刻保持代码的清洁。Milinkovich还说在2008年6月份发布的 Ganymede不会包含以上大修的内容。

看来，现在的Eclipse变得越来越大，越来越慢是大家达成的共识，3年前，使用512兆内存的机器在Eclipse中开发很流畅，而现在1G内存的机器却也很勉强。软件变得越来越大，越来越慢，耗费的资源越来越多已经是所有软件开发商的共同诟病，回到10年前或者5年前，一个软件使用一张软盘就可以装下的时代已经一去不复返了。单元Eclipse 4.0能够真的做到更小、更快、更简单，而不仅仅是一个美好的愿望。

Newton组件模型介绍

yanfei — Sat, 03 Nov 2007 11:11:05

Newton项目的目的是建立一个分布式组件模型。要成为一个真正意义上可用的分布式组件框架，要从根本上解决本地计算和分布式计算的不同。如The Eight Fallacies of Distributed Computing 和 A note on distributed computing所讲。

目的

另一个要考虑的是必须易于开发。近来很多的轻量级POJO框架，如Spring ，他们迅速通过开源社区而得到发展。将域模型与基础设施分离，可以提高开发效率和可维护性，并避免依赖于特定的开发厂商。

Newton基于以上考虑开发，并将提供分布式计算功能。

关键技术

这个世界是一个高度动态的分布式组件模型，并会随时面对无法预料的失败和不确定的网络状态。分布式系统的管理，如部署或整理系统环境是一项繁重的工作。它阻碍了我们开发和建立一个可以自治的分布式系统。Newton使用OSGi和Jini来解决这些问题。OSGi是Newton整个构件模型的中心，而Jini则是其远程基础设施的基石。同时，Newton使用SCA来描述构件装配模型。

OSGI

Osgi为单个JVM提供了一个高度动态和设计良好的服务模型。OSGI的部署单元Bundle, 使用了平级的类加载模型，而不是出传统的层次的类加载模型，这种类加载模型确保了OSGI的运行环境具有高度一致性的类视图，而不会因为层次的类加载模型而导致类加载错误在不同层级的类加载器之间传递。 Bundle具有一个从安装到卸载的定义良好的生命周期。此外，OSGI对传统的jar形式封装进行了一些改进，可以将API暴露给用户，而将其余的类作为私有的，确保不被用户访问。Bundle在物理上是具有一些附加元数据的jar文件，Bundle在运行时靠这些元数据被运行环境解析。OSGI提供了一个内部的服务注册表，不同Bundle中的服务在创建时可以通过服务注册表查找到其他服务。

此外， OSGI在Bundle和服务级别都有严密的安全模型。

OSGI具有的以上的丰富的和高度的动态模型，使得Newton项目选择OSGI看起来顺理成章。Newton的容器本身在OSGI Bundles之外建立，最终用户的组建代码则以Bundle的形式部署。

目前，Newton运行在OSGI R4的容器中。Knopflerfish 和Equinox都可以直接被支持。我们期望不久可以加入到Felix。

Jini

jini的提供了一个面向服务的模型来解决了现实的分布式计算。尤其jini的提供分布式注册表，远程服务可以通过分布式注册表找到对方，and makes extensive use of leasing to ensure reclamation of resources that are not explicitly release by failed clients.。 Jini提供了一个高质量易扩展的RMI栈，对网络级和远程代码的安全提供良好支持。

Newton利用Jini的远程注册表来跟踪和连接远程依赖的Newton组件。未来推出的Newton项目将利用Jini的分布式事务管理的能力和Javaspaces来在分布式过程中进行协调。

SCA

SCA是一个与具体语言和协议无关的组件规范和编程模型。它允许具有层级关系的构件装配模型运行在同构或互相分离的异构系统中。

Newton可以实例化一个跨硬件系统的高度动态的SCA实现，SCA实现由SCA描述符所描述，Newton可以自动提供必要的资源并在不同的异构系统之间连接装配为SCA实现。

Newton的SCA实现是高度动态的，它由一个SCA描述符来描述，Newton能够无需人工干预地实例化一个跨硬件的分布式系统，提供必要的资源和连接SCA复合构件(Composite)。在运行期间Newton监控系统运行情况并对错误作出响应。Newton监控SCA描述符，并将描述符的改变广播并通知系统。当不在需要SCA系统时，Newton可以完全的释放所有使用的资源。

Component model

Overview

Newton的最小部署单元是一个SCA Composite运行在单独的进程中，SCA Composite打包为一个单独的OSGI Bundle,该Bundle是一个facory bundle。Factory bundle包含并导入了所有的必须的类和资源去实例化指定的Composite，Factory bundle根据composite 模板创建多个示例并进行管理。Composite模板是包含了创建一个composite的所必须描述符和Composite的结构，包括Composite的声明周期管理、服务、引用。

Composite描述符为Newton Install提供了安装所必须的信息，描述符是基于SCA的Composite模板，并根据制定信息重载并实例化Composite模板。描述符被从系统中移除时也会移除对应的Composite。

Newton Composite可以引用多个服务，贯穿于一个Composite的运行期间，Newton监控并根据Composite的绑定类型和元数据连接不同的Composite。当一个引用的服务实现时，会通知绑定，并且在和断开连接，然后再自动去重新连接引用的服务或者选择一个其他的服务。

当第一个Composite安装后，相关的factory bundle和所有的依赖也会被安装。当最后一个composite卸载时，bundle垃圾手机机制会从系统中溢出所有的不需要使用的bundle。

[程序员健康之路]----最健康的自制备安眠药

yanfei — Sat, 29 Sep 2007 09:09:19

配方:

绿茶,二锅头

说明:

先把茶泡好,平时怎么泡就怎么泡,等茶基本上可以喝的时候,就加入二锅头（最好是十年陈的）,整瓶倒进去,呵呵,当然不可以啦.

只要倒一滴就行了.....之后等茶凉点,再把茶喝了,这样你一上床,只要过一会儿,你就可以去教周公编程了.

注意(绿茶最好选用立顿牌的绿茶,二锅头最好是北京产的)

SCA同OSGI的比较

yanfei — Fri, 28 Sep 2007 10:09:48

最近一段时间先后看了SCA规范和OSGI的规范。看完之后再对二者作一个全面的比较。

首先，两个规范制定的出发点和初衷是不一样的。SCA规范是为了企业应用集成而制定，OSGI规范的初衷则是为移动设备计算而制定的。由于二者的出发点不一样，导致了两个规范的侧重点不一样。SCA规范现在的版本是0.95，相对OSGI规范的4.0版本还显得多少有些稚嫩。

SCA规范中着重解决了现有企业应用之间的相互调用和企业应用如何以面向服务的思想来建立和部署。但是对于构件容器的实现方面的规定则有些不足，仅仅是站在使用者的角度描述了客户端API的规格。

而OSGI规范因为最初的出发点是为了移动设备的计算环境，因此更多的考虑了运行时框架和服务在运行时刻的动态匹配等问题。此外，提供了运行时刻应用程序的热部署、解析、运行、卸载等能力。应该说，OSGI规范发展到4.0已经是一个比较完善的规范了。

SCA规范中目前对SCA容器的实现尚没有一个指导性的意见，但是OSGI规范在这方面已经做的很完善了。OSGI规范中定义了Framework、Start Level、Package Admin、Security，详细描述了不同组件之间的依赖规则(静态依赖，动态导入)，不同组件之间使用独立的类名称空间。

由于SCA规范面向企业应用集成，因此SCA构件的实现可以是Java，BPEL，EJB，WebService。而OSGI的实现只面向Java语言。这也是由于二者的出发点不同导致的。

对于SCA和OSGI的装配模型，二者是大同小异。二者都可以对外提供服务（Service），但SCA更偏重设计时刻的构件组装，而且定义了灵活的构件装配模型，可以由最小的原子构件组装成一个大系统。

从现有的已经实现的产品来看，OSGI更多的被用来作为单一产品的整体架构，SCA规范更多的是被用在面向业务的构件的组装规范，至于SCA产品的架构如何则不是SCA规范所关心的。

从上边的比较可以显而易见的看出二者分别的缺点，SCA规范过于强调集成，但是对SCA构件的运行时刻行为描述太弱，所有的构件实现都是在设计时刻绑定的。也许在SCA产品中可以实现运行时刻的动态绑定，但是作为一个规范，这是它所欠缺的。OSGI规范对组件的运行时刻描述很完备，但是所有的组件必须运行在同一个虚拟机中，不同虚拟机中的组件服务互操作则稍显不足。

以上完全是个人的看法，欢迎大家讨论。

OSGI、JMX、Spring、SOA

yanfei — Fri, 28 Sep 2007 10:09:32

OSGI、JMX、Spring、SOA

这两天得了重感冒，不过感觉感冒时更能静下心来看书。这两天看了些OSGI方面的资料，感觉需要整理一下思路。

OSGI Framework的结构有点意思，Framework本身就是一个Bundle(System Bundle),在Framework之上可以有用户的Bundle。

一直在思考OSGI和JMX有什么相似之处。看了OSGI规范的服务层相关内容，感觉和JMX很相似。

开始一直认为OSGI只是提供了对组件的生命周期管理。然而缺乏对组件内部的访问机制。现在发觉自己错了。一个Bundle可以注册N多的服务，通过BundleContext可以得到服务对象。代码如下：

注册一个服务：

//Register StartLevel Service

properties = new Hashtable();

properties

.put(Constants.SERVICE_PID, OSGiGaintFramework.STARTLEVEL_PID);

this.startLevelAdminImpl = new WukongStartLevelAdmin(this);

this.startLevelReg = context.registerService(

StartLevel.class.getName(), this.startLevelAdminImpl,

properties);

获取服务对象：

ServiceReference reference = context

.getServiceReference("org.osgi.service.startlevel.StartLevel");

StartLevel startLevel = (StartLevel) context.getService(reference);

startLevel.setStartLevel(0);

OSGI Framework对于服务的使用有跟踪机制，

这样看来是不是和JMX有几分相似？以JBoss为例，需要事先在jboss-service.xml文件中进行配置，然后

HelloWorldServiceMBean mbean = (HelloWorldServiceMBean) MBeanProxyExt.create(HelloWorldServiceMBean.class, ObjectNameFactory.create("www.chengang.com.cn:service=HelloWorld"));

String msg = mbean.getMessage();

System.out.println("Client.go()=" + msg);

JMX规范中也有动态MBean的概念，可以动态的部署MBean。

另外一个问题，OSGI的架构在J2EE应用服务器中如何使用，看到消息好像已经有J2EE服务器准备在OSGI的基础上实现了，可以理解，J2EE服务器的服务组件可以通过Bundle上注册Service来实现，但是对于WEB应用可以采用OSGI吗？感觉好像不行。第一，同WEB容器相关的规范不一致；第二，OSGI的类加载机制不适合WEB应用。

最近在看Spring，也对OSGI，Spring做一个比较。OSGI同JMX都是重量级的，都对容器有依赖，这一点Spring做的比较好。但是OSGI，JMX都提供了组件动态配置部署的能力，Spring是没有的。另外，感觉OSGI规范的内容更广，更全面。不光包括了组件动态加载、部署，还有安全性、完善的类加载机制等等。其次，OSGI，JMX更多的是面向服务的，而Spring的目标是提供可重用的商业组件和业务的域模型。

另外，今天看了一个PPT，是对OSGI和SOA的比较，下面是原话：

– Web services bind and discover over the net

– The OSGi Service Platform binds and discovers inside a Java VM

星期五和同事的讨论也聊到了OSGI是否有服务发现机制，这应该是答案吧。

期待SCA、OSGI的天作之合

yanfei — Fri, 28 Sep 2007 10:09:27

我博客中以前的文章中对SCA、OSGI、Spring曾做过一些粗略的比较，也一直在思考SCA、OSGI能否走到一起，最终以什么样的形式结合。在OSGI主席Peter的博客上看到了BlueDavy的提问， Peter回答说SCA和OSGI很多概念很相似，二者是天作之合（原话是match made in heaven），。但是毕竟SCA和OSGI所关注的方面不太相同。一个是关注于语言无关的企业应用集成，一个更关注于运行环境中组件和服务的动态更新特性。

在SCA规范正式版发布之前，总感觉缺少SCA容器打包部署方面的描述。终于在1.0版中看到了将打包部署作为了单独的一个章节列了出来。OSGI的Bundle可以将可以在SCA容器中部署。但对于OSGI的更进一步描述，在规范中也是闪烁其词。

时过半年，SCA、OSGI走向联合的趋势越来越明朗。可以看到在OSOA的SCA Assembly Model 1.0规范已经提到了将OSGI作为SCA的一种部署模式的参考实现。并且发布了Powerful Combination of SCA, Spring, and OSGi 的白皮书。白皮书中给出了SCA、Spring、OSGI如何在一起工作的概览。

OSGI联盟在2005年8月发布的R4规范，已经对组件和服务的部署、运行作了比较详细的描述，具体可参见Declarative Services规范。从部署描述符的格式上看，同SCA的元信息格式非常的相似，估计多半SCA规范在制定时参照了OSGI中的一些内容。

Eclipse Con 2007中有不少关于OSGI方面的专题，How to tackle the problems of large scale applications in OSGi专题的最后也提到了OSGI与SCA的结合。 SCA容器在OSGI容器中运行，SCA容器实现为OSGI的一个Bundle。SCA Bundle需要实现服务与引用的绑定，同时可以考虑使用Declarative Services。

从技术的角度看，SCA和OSGI有很多的相似，同时又有很多方面可以互补。SCA容器中的组件要求在运行时刻是隔离的，具体体现在Java实现中，要求不同的Composite具有不同的ClassLoader，这正是OSGI的强项，同时，对于服务的管理、动态更新等特性，SCA容器应该也是需要的。但是，OSGI也有其局限性，它只是一个Java平台之上的框架，而SCA需要面对的是多语言、多实现的集成应用环境。因此二者如何更好的结合，还需要在实践中不断的摸索。也期望SCA、OSGI能够修成正果。

Ps:如果要给SCA、OSGI分个公母的话，感觉应该OSGI更象个女的，而且是体贴贤惠的女人，SCA相对粗旷、大气一些，同时SCA是比OSGI小六七岁的小弟弟。这年头流行姐弟恋啊！！！两人腻腻歪歪一两年，也该确定关系了。