Osgi 4.2 specification released

 

Osgi 4.2 specification released

Original article: osgi 4.2 released
, Infoq

Author:Alex Blewitt

September 16, 2009

Translators: 88250
September 17, 2009

 

 

Osgi Alliance
Osgi 4.2 was released the day before yesterday
Specification. Although early drafts have been available, this is the final standard release version.

Some osgi implementations, such as equinox
3.5 and Felix
2.0 has already implemented some compatible implementations for the osgi 4.2 specification, but osgi 4.2 was not released yet. Of course, it cannot be said that it has implemented the osgi 4.2 specification. Now the specifications have been officially released, and the implementation teams still need to make some adjustments that have fully met the specifications.

What are the features of the new specification? Infoq once published an article on new osgi specification Prediction
Now the specifications have been officially released to see what features we must pay attention:

• Framework startup (
  Framework launching)
  
  In the past, although it can be used in Java applications (for example, equinox servlet bridging
  ) Start the embedded osgi engine, but there are specific startup methods for specific engines. Although there are some wrappers (such as Pax runner
  ) Makes it easier to start the engine, but you must be familiar with the knowledge of the specific 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, you can replace the corresponding engine jar package in the startup class path in both equinox and Felix tests.

• Remote Service)
  
  You may have heard of distributed osgi (Distributed osgi) and
  RFC 113, while the remote service in osgi 4.2 is a new name for similar technologies. It connects various osgi virtual machines (osgi VMS) together. The remote service usesService
  Concept (the essence of Hot Plug osgi applications), provides a mechanism for exporting services to the remote consumer end and consuming remote services locally. Different from other distributed methods (such as RMI), remote services do not need to implement special interfaces or throwChecked exception
  . Of course, when an exception occurs, the remote service does not pretend to work normally. You can regard the exception as a service that should be entered and acted on the osgi environment under any circumstances.

• Preparatory Service)
  
  The concept of the Preparation Service in osgi 4.2 is very similar to the control inversion/
  Dependent injection. It allows the client to specify the service to be connected from an external configuration file, which will be dynamically connected to the client. Like a declarative service, you can restrict the service type, for example, whether it is mandatory.
  (Mandatory); but it is somewhat different from declarative services. When the required service is missing, the preparation service can provide a default service proxy implementation. When the Customer Code tries to call this service, the client will be
  The Service proxy is blocked until the real service connection is successful. In summary, using the features of the Preparation Service can avoid coupling with osgi, which enables applications
  It can also run in an osgi environment.

• Bundle Tracker)
  
  Osgi already has a service Tracker used to monitor the ins and outs of services, while bundle tracker is an extension of tracing bundles. It can be used in previous services
  Bundletracker and servicelistener
  Has the same availability. It can be used to execute dynamic registration when the preparation service or declarative service is reading (and processing) metadata. For example
  The engine can automatically scan the newly installed bundles and automatically register servlets through httpservice.

• Service hooks)
  
  When determining what services exist, you can intercept and filter events between services. For example, when implementing a role-based permission model or disabling/
  Corresponding function set is available. Another method is to provide Proxy services (or Server Load balancer) to intercept other bundle
  Events are hidden for future proxies to other mechanisms (such as distributed services ). In addition, the listener Hook can also start the service as needed before the service is registered.

• Conditional permission)
  
  Osgi 4.2 upgrades related permissions include deny access and allowed access. After the signature is authenticated, you can specify the operation permissions for the bundles subset. It can lock the installation of unsigned bundles and help build a secure osgi platform.

 

The osgi 4.2 specification has many changes compared with 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. For declarative services, you can simplify their permission set settings (replace protected in the package ). DS
Schema also allows other XML elements that help specific service information. In addition, an application administrator can obtain the return value of an application at the end of the application.

Equinox 3.5 already provides some similar functions, Apache Felix
Similar features were tested at the beginning of this month (released earlier than the 4.2 standard ). Before the end of this month, osgi will officially release test suite information for the 4.2 specification.

Infoq interviewed Richard Nicholson, paremus
Founder and CEO of paremus service Fabric
OsgiCloud
. He has the following opinions on the new specifications:

"Over the past few years, our experience in building a distributed osgi-based system has made us very eager to see relevant specifications, the remote service and preparation service features in the osgi 4.2 specification have been officially standardized."

What do you think is the most noteworthy part of osgi 4.2?