Shulou(Shulou.com)06/02 Report--

This article shows you what the new features of OSGi 4.2 are, concise and easy to understand, which will definitely catch your eyes. I hope you can learn something from the details of this article.

Some OSGi implementations, such as Equinox 3.5 and Felix 2.0, had already made some compatible implementations for the OSGi 4.2 specification, but OSGi 4.2 had not been released at the time, and it certainly could not be said to have implemented the OSGi 4.2 specification. Now that the specification has been officially released, the implementation teams still need to make some adjustments to fully meet the requirements of the specification.

What are the features in the new specification?

Framework launch (Framework launching)

Although embedded OSGi engines can be started in Java applications (such as Equinox's servlet bridge), there are specific ways to start them for specific engines. Although some wrappers, such as Pax Runner, make it relatively easy to start an engine, you must be familiar with the knowledge of a particular engine. In the current specification, a transparent startup mechanism is defined so that it can be started without knowing the OSGi implementation engine. In this way, testing under Equinox or Felix can only be done by replacing the corresponding engine Jar package under the startup classpath.

Remote Services (Remote Service)

You may have heard of distributed OSGi (Distributed OSGi) and RFC 113 before, and remote service in OSGi 4.2 is a new name for similar technology, which connects various OSGi virtual machines (OSGi VMs) together. Remote service adopts the concept of service (the essence of hot-swappable OSGi application) and provides a mechanism for exporting services to remote consumers and consuming remote services locally. Unlike other distributed methods, such as RMI, remote services do not need to implement special interfaces or throw a checked exception. Of course, when an exception occurs, the remote service does not pretend to be working properly, and you can think of the exception as a service that should enter and act on the OSGi environment under any circumstances.

Preparatory Services (Blueprint Service)

The concept of preparatory services in OSGi 4.2 is very similar to inversion of control / dependency injection. It allows the client to specify the connected service from an external profile, which will be dynamically connected to the client. Like declarative services, you can impose some restrictions on the type of service, such as whether it is mandatory (mandatory); but unlike declarative services, the preparatory service can provide a default service proxy implementation when the required service is missing, and when the client code attempts to invoke this service, the client will be blocked by the service proxy until the actual service connection is successful. To sum up, using the features of preparatory services can avoid coupling with OSGi, which allows applications to run both in and out of the OSGi environment.

Bundle Tracker (Bundle Tracker)

OSGi already has a service tracker to monitor the context of the service, while the Bundle tracker is an extension of tracking bundles. In the past, BundleListener could be used in services to monitor the dynamic entry and exit of bundle, but today BundleTracker has the same availability as ServiceListener. It can be used to perform dynamic registration when a preparatory service or a declarative service is reading (and processing) metadata. For example, a Web-based engine can automatically scan for newly installed bundles and automatically register servlets with HttpService.

Service hook (Service Hooks)

When judging what services exist, events between services can be intercepted and filtered. For example, in implementing a role-based permission model or disabling / available corresponding feature sets for different product levels. Another approach is to provide proxy services (or load balancers) to intercept events of other bundle and hide them for proxy to other mechanisms (such as distributed services) at a later stage. In addition, the listening hook can also start the service on demand before the service is registered.

Conditional permissions (Conditional permissions)

OSGi 4.2's upgrades to permissions include access denied (DENY access) and access allowed. After authenticating the signature, you can specify operation permissions for the bundles subset explicitly. Unsigned bundles installations can be locked to help build a secure OSGi platform.

There are many changes to the OSGi 4.2 specification compared to version 4.1. For example, OSGi bundles has its own MIME type (application/vnd.osgi.bundle), you can specify icons and licenses for a bundle, and for declarative services, you can simplify its permission set settings (using in-package friendliness instead of protected). DS schema also allows other XML elements that are helpful to specific service information. In addition, a mechanism is provided to enable the application administrator to obtain the return value of the application at the end of the application.

Equinox 3.5 already provides some similar features, and Apache Felix passed tests on similar features earlier this month (prior to the 4.2 specification release).

The above is what are the new features of OSGi 4.2? have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.