OSGi 4.2有什么新功能？ [英] What's new in OSGi 4.2?

问题描述

OSGi 4.2已刚刚发布，它通过一些新的RFC更新了4.1规范。那么，OSGi 4.2有什么特别新的东西，哪个框架支持4.2已经（或接近）？为什么你要针对4.2框架而不是4.1来针对新开发？

OSGi 4.2 has just been released which updates the 4.1 specification with a few new RFCs. So, what's particularly new with OSGi 4.2, which frameworks support 4.2 already (or are close to) and why should you target new developments against a 4.2 framework instead of a 4.1?

推荐答案

在大多数情况下，OSGi的一个点发布（例如4.1-> 4.2）并没有真正改变现有的行为，因此可以肯定地说，如果你有一个依赖的应用程序在4.1上，它将在4.2上运行而没有问题。新的是一些标准化的项目应该能够实现不同OSGi引擎之间更好的互操作性（如 Equinox ， Felix 和 Knopflerfish ）。

In most cases, a point release of OSGi (such as 4.1->4.2) doesn't really change much existing behaviour, so it's safe to say that if you have an app that depends on 4.1, it'll run on 4.2 without problem. What is new is that a few items have been standardised which should enable for better interoperability between different OSGi engines (like Equinox, Felix and Knopflerfish).

事实上，尽管OSGi 4.2仅在2009年9月16日正式发布，但早期草案已经可供其他人参考，因此之前发布的产品（如Equinox） 3.5，Felix 1.8）已经对该标准有了合理的支持。与802.11n产品一样，它们符合早期的草案，但预计它们将在不久的将来被认证为完全符合4.2版本。

In fact, although OSGi 4.2 was only released officially on 16th September 2009, early drafts have been available for others to refer to, so previous releases of the products (like Equinox 3.5, Felix 1.8) already have a reasonable support for the standard. Like 802.11n products, they conformed to earlier drafts but the expectation is that they'll be certified as fully compliant against the 4.2 release in the not too distant future.

所以，4.2有什么新内容？

So, what's new in 4.2?

• 服务挂钩


• 框架启动

并且，在汇编中

• 远程服务


• 捆绑追踪器


• 蓝图服务

服务挂钩

Service Hook API允许您接收服务层发生的事件。例如，您可以在请求服务时，服务何时传递事件时挂钩，等等。您还可以导致事件未被传递（例如，隐藏您无权查看的事件）但不能更改任何事件（因为这会使正在传递的类复杂化）。服务挂钩是核心规范的一部分，因此所有OSGi版本都需要符合这一要求。

The Service Hook API allows you to pick up on events that occur at the service layer. For example, you can hook into when a service is requested, when a service has an event delivered, and so on. You can also cause events to be not delivered (for example, hiding events that you're not authorised to see) but can't change any events (as this would complicate the classes being delivered). Service hooks are part of the core specification, so all OSGi releases will need this to be compliant.

框架启动

虽然可以以编程方式从现有Java应用程序启动OSGi实例，但执行此操作的方式取决于您正在使用的OSGi运行时。特别是，配置项（例如存储瞬态数据的位置，捆绑引导委派策略应该是什么等）都是以特定于引擎的方式定义的。这整合了任何启动实用程序在框架上设置的属性。

Although it's possible to programmatically start an OSGi instance from an existing Java application, the way in which you do this has been dependent on which OSGi runtime you're using. In particular, configuration items (such as where to store transient data, what the bundle boot delegation policy should be and so on) were all defined in an engine-specific manner. This consolidates the properties that get set on the framework by any launching utility.

远程服务

Remote Services API允许OGSi服务在VM之间进行通信（可能在不同的机器上）。它们如何通信的确切机制（RMI，WebServices等）对提供商是开放的，因此它与其他分布式技术（如Corba）不同，后者专门规定了有线格式。显然，分布式服务具有与本地服务不同的语义（通信错误，序列化问题），如果需要，可以将各个服务分配给它们。

The Remote Services API allows OGSi services to communicate between VMs (possibly on different machines). The exact mechanism of how they communicate (RMI, WebServices etc.) is open to providers, so it's unlike other distributed technologies (like Corba) which specifically dictate an on the wire format. Clearly, distributed services have different semantics than local ones (communication errors, serialisation issues) and it is left to the individual services to be distributable if needed.

Bundle跟踪器

与4.1之前的ServiceTracker一样，BundleTracker可用于监视系统中哪些捆绑包的进出。动态GUI可以使用它来显示OSGi引擎的演变状态，而无需任何平台特定知识。

Like the ServiceTracker before it in 4.1, the BundleTracker can be used to keep an eye on which bundles come and go in the system. This can be used by dynamic GUIs to show the evolving state of the OSGi engine without any platform specific knowledge.

蓝图服务

蓝图服务类似于Spring，因为它提供了一个用于配置bundle的依赖注入机制。在某些方面，它类似于声明性服务;但是蓝图服务以不同的方式做事。此外，与声明性服务（只能处理存在的服务）不同，蓝图服务可以提前为服务创建代理占位符，该服务将在稍后上线。然后，对服务代理的调用将被阻塞，直到可以填充服务（而不是像声明性服务那样返回'null'）。如果您对Spring IOC和类似的依赖注入感到满意或熟悉，那么Blueprint服务将立即可以理解。

The blueprint service is similar to Spring as it provides a dependency injection mechanism for configuring bundles. In some regards, it is similar to declarative services; but the blueprint service does things in a different manner. In addition, unlike declarative services (which can only deal with services which are present), the blueprint service can create a proxy placeholder in advance for a service which will come on-line later. Calls to the service proxy will then block until the service can be filled (rather than returning 'null' as declarative services will do). If you are comfortable or familiar with Spring IOC and similar dependency injection, then the Blueprint service will be immediately understandable.

这篇关于OSGi 4.2有什么新功能？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！