转载的一篇介绍OSGI概况的文章

众所周知，Java平台有庞大的开源框架、类库支持，但我们却一直停留在类与API层次的复用，一个较大的Java项目往往有大量的Jar包混乱的堆积在classpath下。所以Java领域迫切需要一个实现组件级复用的解决方案，将所有这些混乱不堪的类库与API以组件的形式发布，在统一的容器内组装协作，OSGi规范无疑是目前最为出色的候选者。

OSGi的规范已经提出5、6年的时间，到现在被业界广泛认可，其发展过程很有趣。OSGi规范最初定位于嵌入式系统，如家电、汽车、手机、家庭网关，满足单一Java虚拟机上启动多个Java应用程序和动态从网络安装卸载应用程序的需求。但那时嵌入式Java虚拟机还不成熟，更不用提OSGi的应用，尽管有宝马等知名公司的应用，但一直没有在Java嵌入式领域获得广泛的应用。


随后的发展一定超出了OSGi委员会(www.osgi.org)的想象，OSGi居然被Eclipse应用到了客户端。 Eclipse原本插件体系结构是一个基于XML的静态扩展结构，即扩展(Extension)与(Extension Point)，不知道当初基于什么样的考虑，Eclipse组织在3.0版本选择OSGi作为插件体系的内核，这样由OSGi负责插件体系架构中ClassLoading机制，由扩展与扩展点负责业务层面的扩展架构，这是一个很完美的结合。但我认为这实际上并不是OSGi的最佳实践，Eclipse原本的静态扩展架构限制了OSGi的动态性，也没有应用OSGi的服务层模型，而是大量基于单例(Singleton) Plugin调用协作，开发RCP客户端时，你会发现很少需要注册OSGi的服务，往往一个Plugin的入口类提供很多静态方法。当然，这也可能与Eclipse的延迟加载(Lazy load)机制有关。


尽管Eclipse不是OSGi的一个最佳实践，但随着Eclipse的成功，OSGi迅速普及与成熟，最终将OSGi推向它最擅长但一直被忽略的领域：企业级应用软件的服务端，纯插件体系架构的服务端！目前，大量的服务端开源架构与商业产品向OSGi迁移，2007年将是OSGi服务端应用的开始。


随着OSGi在胖客户端(RCP)、服务端(Server Side)与嵌入式Java虚拟机上的广泛应用，相信未来几年内，60%的Java虚拟机上部署OSGi的目标并不是遥不可及。