OSGi 4.2 发布
2009年10月7日
没有评论
OSGi 4.2 规范最终版已经发布.
OSGi 4.2 新版的一些内容：
- 框架加载（Framework Launching）。虽然我们可以从Java应用中运行嵌入式OSGi引擎（比如Equinox的Servlet桥）,但这种方式却将应用与具体的引擎绑定在了一起。借助于包装器（比如Pax Runner）可以通过相对简单的方式将特定于引擎的内容编码到引擎中来启动。现在可以通过一种透明的机制进行加载了，这意味着可以加载一个OSGi运行时而无需担心是哪个运行时。这样我们就可以通过替换启动类路径上的JAR文件在Equinox及Felix下测试应用了。
- 远程服务（Remote Service）。过去叫做分布式OSGi及RFC 119，现在称作远程服务的技术是用于连接多个OSGi VM的。远程服务采用了服务的概念（这对于动态OSGi应用来说非常关键）并提供了一种机制以将服务公开给远程使用者（使其可以在本地使用远程服务）。并不像其他方式（比如RMI）那样，远程服务无需实现不同的接口或是抛出受检查的异常。同时它也不会假设万物都会正常工作，而是认为OSGi服务是动态的，无论如何服务都能够在OSGi环境下抛出并处理异常。
- Blueprint服务（Blueprint Service）。对于熟悉Spring IoC与DI的开发者来说会发现Blueprint服务与其有异曲同工之妙。客户端可以根据外部的配置文件来决定连接到哪些服务上，同时还会动态连接这些服务。就像声明式服务那样，你可以约束所用的服务类型（比如强制与否等），但与声明式服务不同的是，在缺少服务的情况下Blueprint服务会提供一个相应的代理。在客户端代码与服务进行交互时，客户端会被阻塞住直到定位到服务之后。最后，凭借Blueprint服务之类的特性，我们可以避免应用中出现特定于容器的代码，这样无论系统运行在OSGi运行时内部还是外部都是大有裨益的。
- Bundle跟踪器（Bundle Tracker）。OSGi早就有了一个服务跟踪器（Service Tracker）用于监控进出的服务，Bundle跟踪器是对服务器跟踪器概念的一个延伸，用于监控bundle的信息。此前服务可以通过BundleListener来动态查看进出的bundle，而BundleTracker也达到了同样的高度，就像ServiceTracker之于ServiceListener一样。我们可以通过这个特性执行动态注册之类的功能，就好象是Blueprint服务或声明式服务读取或处理元数据一样。比如说，Web引擎可能会通过HttpService自动扫描新安装的bundle和自动注册的Servlet。
- 服务钩子（Service Hook）。除了判定当前的服务外，我们还可以拦截服务之间的事件并对其进行过滤。这可用来实现基于角色的许可模型或是根据产品的不同而开启不同的功能集。此外还可以通过拦截另一个bundle的事件而提供代理（或是负载平衡）同时又隐藏这些事件，然后用另一种机制进行代理（比如说分布式服务）。监听器钩子可以按需实现这些功能而无需提前注册。
- 条件许可（Conditional Permission）。OSGi 4.2中许可的一大变化是增加了DENY访问及允许访问的能力。通过与证书签名的结合，这种方式可以显式指定某个bundle的子集上都允许哪些许可权限。这有助于创建安全的OSGi平台，可以阻止安装那些未授权的bundle。
详细内容请见
