The integration of OSGi with popular frameworks (Spring,struts,hibernate, etc.).

2. Integration with popular JAVA B/S Architecture

This paper introduces the basic idea of OSGi system design, and further studies the integration of OSGi with popular framework (spring,struts,hibernate, etc.), and explains the integration principle first.

• solution and Spring Integration

Because spring applications occupy most of the Java applications, solving the integration with spring is a must for OSGi, and the introduction of SPRING-DM greatly facilitates the combination of the two, helping OSGi move into the enterprise domain.

The main benefits of spring are two points:

1. Services that do not require external export can be controlled within the scope of the bundle for access.

2. Get the many features of the Pojo enhanced provided by spring.

Build the development environment

To build the SPRING-OSGI development environment, first we will provide some spring bundles deployed into the OSGI framework, resulting in the functionality provided by spring to deploy the bundles required by Spring-osgi:

Org.springframework.osgi.aopalliance.osgi;

..... osgi.aspectjrt.osgi..............

..... osgi.backport-util-concurrent..............

..... osgi.spring.aop..............

.................. osgi.spring.aspects

..... osgi.spring.beans..............

..... osgi.spring.context..............

..... osgi.spring.core..............

..... Osgi.spring.dao..............

..... osgi.spring-osgi-core..............

..... osgi.spring-osgi.extender..............

..... osgi.spring-osgi-io..............

Copy the corresponding jar package to Eclipse/plugin, which completes the SPRING-OSGI environment preparation.

Publish and Reference OSGi service in Spring Bean. xml

To publish a spring bean as an OSGi service, simply configure the XML for the spring bean as follows:

<osgi:service id= "OSGi service ID" ref= "interface for the spring Beans" interface= "service that needs to be published as an OSGi service >

When you publish an OSGi service , you also need to frequently use the configuration of the properties property, usually in spring beans. Add osgi:service-properties nodes in the XML file to achieve:

<osgi:service>

<osgi:service-properties>

<prop key= "Property name" > property value </prop>

</osgi:service-properties>

</osgi:service>

When referencing an OSGi service , the configuration file should be configured as follows:

<osgi:service id= "equivalent to Spring Bean name" interface= "Service Interface" cardinality= "0 ..."/>

Spring-osgi also supports Lazy-init (when configured to True, this service can only be activated when called), depends-on (Configuring the service on which this service depends), Context-classloader ( Used to configure the use of third-party ClassLoader to load the service) above the property configuration.

to implement bind and unbind settings:

Adding Osgi:listener nodes under the osgi:reference element

<osgi:reference>

<osgi:listener ref= "sping bean with reference to this service"

Bind-method= "method to invoke when service is available"

Unbind-method= "method to invoke when service is not available"

</osgi:reference>

spring-osgi default load resolves the xml file in the Meta-inf/spring directory as a spring bean configuration file, or you can specify the spring bean by adding spring-context in META-INF.MF Configuration file.

The simple message board is reconstructed as a spring bean based on the Spring-osgi refactoring.

L Define Spring Bean < directory as: meta-inf/spring/springbeans.xml (definition Bean) >

L Define the required references for OSGi services < configuration in osgiservice.xml>

L define the desired release of OSGi services < configuration on osgiservice.xml>

L Run (Application bundle starts with Spring-osgi bundle, reduce SPRING-OSGI bundle Start-level is 2. ）

The integration of the above OSGi and spring makes OSGi-based applications easy to meet some of the basic needs of the enterprise (transaction management, remote invocation, etc.)

Summarize the advantages that SPRING-OSGI brings:

• Injection support for intra-bundle services, so that internal services need to be published as OSGi service

• Support for the technology required by the enterprise (transaction management, remote invocation)

L support three-side classloader to load OSGi service.

Where Spring is worth improving:

L Form Spring microkernel (Spring's fineness integration with bundles). There is no need to reference too many bundles.

• Modular support for functionality supported by spring itself (spring-dao,spring MVC is not very practical for modular support)

L need to set the boot order in the SPRING-OSGI application. (may be implemented using the extensibility point method)

L SPRING-OSGI support for dynamic effects is not yet complete, (after the bundle Update,in same time don't update the Osgi:service).

As the integration of OSGi and spring embodies the great prospect of OSGi's foray into enterprise applications and the desire of people, here I have attached the spring OSGi specification to make it easy to understand:

Spring OSGi Specification

1.0 Introduction

The spring Framework is a leading Full-stack Java/jee application framework. It provides a lightweight container that relies on injected, AOP, pluggable service extraction, which makes the non-intrusive programming model possible. OSGi provides a dynamic application execution environment in which components (bundles) can be installed, updated, and deleted in the run. It also provides a good support for modularity and versioning.

The goal of Spring ' OSGi is to make it as easy as possible to write spring-based applications that can be deployed into OSGi's execution environment and effectively leverage the services provided by the OSGi framework. By building applications on an easy-to-use, powerful spring framework, spring's support for OSGi makes it easier and more efficient to develop such OSGi-based applications.

· Better separation of application logic and modules;

· The ability to deploy multiple versions of a module at the same time;

· Ability to dynamically find and use services provided by other modules of the system;

· Ability to dynamically deploy, upgrade, and unload modules in a runtime system;

· Use the spring framework to instantiate, configure, integrate, and decorate components between modules;

· Enable enterprise application developers to develop the capabilities of the OSGi platform using a simple, familiar programming model.

We believe that the combination of OSGi and spring provides the most comprehensive model available for building enterprise applications.

The goal of Spring's OSGi is not to provide a generic model to support arbitrary OSGI-based application development, but some OSGi developers will certainly find the spring model attractive and adopt it. The existing bundles of OSGi and any services that they export can be easily integrated into applications that use SPRINGOSGI support, just like a configuration item that already exists in spring.

Spring OSGi is located in OSGi R4 and above, JDK1.3 and above.

This specification assumes that the reader already has some knowledge of spring and OSGi. See Introduction to the white paper "OSGi for Spring Developers" and "Spring for OSGi developers". Note: These white papers do not yet exist and are still in the writing phase.

2.0 Bundles and application contexts

The development units (and module units) in OSGi are bundles. The bundles described in OSGi have three stable states: Installed,resolved,active. Bundles can export the service, and other bundles can find and use the service.

The main modular unit in spring is a application context, which contains a number of beans (objects managed by the spring application environment). Application contexts can be configured hierarchically so that a sub-application context can see the beans defined in its superior, but vice versa. The concepts of spring's exporters and factory beans are used to export beans that are referenced to clients outside application context, as well as inject references into services defined outside of a application context.

The bundle of OSGi is intrinsically linked to spring's application context: An active bundle can contain a spring application context, which is responsible for instantiating, configuring, Assemble and decorate objects (beans). Some of these beans can be exported as OSGi services for use by other bundles, and beans in bundles can be easily injected into OSGi service references.

2.1 Creating Application Context in Bundles

A application context can be configured with one or more XML configuration files that define the beans. (Strictly speaking, a application context is not known for the form of configuration, but XML is the most common form). The XML document containing the configuration information is placed in the Meta-inf/spring folder in the bundle. By default, Spring uses all documents in this folder that have an ". xml" extension as the configuration definition for application context.

The default settings can be overridden in the manifest header of Spring-context. The header value is a comma-delimited list of resource paths and directives.

Spring-context:: = Context (', ' context) *
> Context:: = Path ('; ' Path) * ('; ') Directive) *

Each path is treated as a resource path defined in the bundle, for example:

Spring-context:config/application-context.xml,config/security.xml

When bundles with Spring-context manifest entry files or resources located in the Meta-inf/spring folder are activated, Spring automatically creates application Context. To achieve this, you must first install and start (start) the Org.springframework.osgi.extender bundle in your OSGi runtime.

When a application context is first created, it determines which OSGi service reference is configured to see if any of the service references specify cardinality (for example, specify 1. 1 or 1. N). This context initialization is not completed until all the required services are available. The wait-for-dependencies instruction can be set to False in the Spring-conext header to change this behavior. When Wait-for-dependencies is set to false, creating application context will fail if application context is not available for the service it must have when it is activated.

List header entries (the Manifest header entry):

Spring-context: *;wait-for-dependencies:=false

Indicates that all XML files in meta-inf/spring should be configured, and the creation of the context will fail if the service required by the context is not immediately available.

A Header Entry:

Spring-context:config/application-context.xml;wait-for-dependencies:=false

Indicates that the Config/application-context.xml configuration file is used to configure the application context, and if the required services are not immediately available, the creation of the context will fail.

Application context is automatically published as an OSGi service as an instance of Org.springframework.context.ApplicationContext. In addition, Org.springframework.context.service.name is used to set the identity name of the bundle that resides in the application context. You can disable publishing the Context as a service by specifying "Publish-context:=false" in the Spring-context manifest entry.

Note: Application context is released as a service that makes testing and management easy. The preferred way to get a pointer to a bean defined in another application context is to use the <osgi:reference> and <osgi:service> elements (relative to the application Call the Getbean () method in the context service). The reason for this is that by using <osgi:reference> and <osgi:service> Component Services, the infrastructure of OSGi will ensure that a bean can only see services that are compatible with the version of the class. Conversely, if you look for a application context in the registry, then call Getbean (...). Returns an object, and the only guarantee of class compatibility is that the ApplicationContext class itself is compatible. It is obvious that this assurance is not robust enough in a system that has multiple versions of bundles deployed at the same time.

2.2 Spring Resource extraction

Spring uses spring Resourceloader to load resources in application context. The associated resource path is explained by application context in a way that matches the application context type (for example, a context-based class path, or a context-based web-app). For OSGi applications, the associated resource path is interpreted as a resource loaded from the bundle classpath. If the resource path begins with the "bundle:" prefix, then only the bundle itself and its attached fragments are searched with the given resource.

 

2.3 Bundlecontextaware

Spring encourages the development of applications based on simple objects that do not depend on any environment. However, if a spring bean does need to access its bundlecontext for some reason, the bean can implement Org.springfra