Getting Started with Osgi--apache Felix

Introduction

This article is part 1th of this series, and we will develop an order application that contains both client and server-side components. These components are then packaged as OSGi packages. The client invokes the service component to process the order. The service component has methods for processing orders and printing order IDs. After reading this article, you can apply the concepts and features of Apache Felix to build and package Java component classes into OSGi packages.

System Requirements

To run the examples in this article, make sure that the following software is installed and set up on your computer: Java 5 or later Ant build tool Apache binary distribution 1.0.4

Next, set the following environment variables (set according to the example ant_home=c:\apache-ant-1.7.0): Java_home (for JAVA) ant_home (for ANT)

Next, add the following content to the PATH environment variable: java_home\bin ant_home\bin

Back to the top of the page

Osgi

The OSGi specification defines and propagates the modularity of Java applications in a more dynamic manner. Typically, a Java application is modeled as a JAR package. However, there are limitations to using JAR files: Jar packages are resolved through CLASSPATH environment variables, which do not provide a reliable framework for managing JAR dependencies. Jars cannot be versioned, so you cannot track the history of the jar packages that you create or modify. There is no framework for dynamically updating JAR files when code changes occur at run time.

To address these issues, you can use the OSGi framework because of the redefinition of the Java modular system. In contrast to traditional JAR modules, OSGi based systems have the following advantages: OSGi provides a reliable integration environment in which packages can be published and exported for use by other packages. OSGi provides package versioning capabilities for each new component. You can therefore track the history of package creation and change. With OSGi, you can dynamically update a package at run time when changes occur.

There are currently three known OSGi implementations: Equinox knopflerfish Felix

This series of articles will describe how to use Felix as an OSGi container. This article series covers the following topics: part 1th describes how to use the OSGi API for component development. Part 2nd will focus on using Spring in the OSGi container and eliminating OSGi API dependencies from the component classes, making it a traditional Java object (plain old Java Objects,pojo). The advantage of this is that you simply focus on writing the business methods in the component class, while the Spring configuration file processes the component's lifecycle.

Back to the top of the page

Order Application

Next, let's look at how to create an order application package using the Felix based OSGi framework. This application includes two components: Orderclient.java (client) and Orderservice.java (server side). The client components are packaged as Client.jar, and the server components are packaged as Order.jar. Next let's look at the Orderclient class first.
Listing 1. Client Component Orderclient

public class Orderclient implements Bundleactivator {private Servicetracker ordertracker; Private OrderService OrderService; public void Setservice (OrderService orderservice) {this.orderservice = OrderService; public void RemoveService () {this.orderservice = null; } public void Start (Bundlecontext context) throws Exception {ordertracker = new Servicetracker (context, Orderse Rvice.class.getName (), NULL); Ordertracker.open (); OrderService order = (OrderService) ordertracker.getservice (); if (order = = null) {SYSTEM.OUT.PRINTLN ("Order service not available"); else {order.processorder (); } public void Stop (Bundlecontext context) {System.out.println ("Bundle stopped"); Ordertracker.close (); } }

As shown in Listing 1, Orderclient calls the ProcessOrder method on the OrderService component to print the OrderID when the Client.jar package is started. This class implements the Bundleactivator interface, which has two callback methods: Start () and stop (). When the client package is started and stopped, the Felix container invokes the implemented start () and Stop () methods.

Next, let's look at the start () method. In the start () method, you first get a reference to the Servicetracker class. You can treat this class as a factory class. It then obtains the service reference from this factory class by calling this GetService method. Servicetracker uses the following parameter constructs: The package context and the OrderService class name.
Listing 2. OrderService implementation

public class Orderserviceimpl implements OrderService, Bundleactivator { private serviceregistration registration; Public void Start (Bundlecontext context) { registration = Context.registerservice ( OrderService.class.getName (), this, null); System.out.println ("Order Service registered"); } public void Stop (Bundlecontext context) { System.out.println (' Order Service stopped '); } public void ProcessOrder () { System.out.println (' Order id:ord123 '); }

The server-side Order.jar file contains two components: the OrderService interface and the Orderserviceimpl class. This interface has an abstract class ProcessOrder implemented by the Orderserviceimpl class. This class also implements the Bundleactivator interface, which is invoked by the Felix container to start and stop the Order.jar package. The start () method registers the OrderService component in the registry for use by the client package. Registration is the same as exporting objects for use by other packages.

Back to the top of the page

Communication via Manifest

The real question is how the client package knows the registered service pack. This communication is handled by using the Manifest file. In the Manifest file, a reference to the package is provided in the import and export package. The client package Manifest typically imports the service component package, while the service pack Manifest exports its own package. Note that when package A Imports package B packages, package B must export its own package. Communication will fail without proper import and export definitions.
Listing 3. Client manifest file

manifest-version:1.0 bundle-manifestversion:2 bundle-name:order Service Client bundle-symbolicname: Orderclient bundle-version:1.0.0 bundle-activator:order.client.orderclient import-package: Org.osgi.framework, Org.osgi.util.tracker, order

Listing 4. Server manifest file

manifest-version:1.0 bundle-manifestversion:2 bundle-name:order Service bundle-symbolicname: OrderService bundle-version:1.0.0 export-package:order bundle-activator: Order.impl.OrderServiceImpl Import-package:org.osgi.framework

For the order application, the Client.jar package Manifest contains entries import-package:org.osgi.framework, Org.osgi.util.tracker, ordering. This actually means that the client package imports core OSGi packages and OrderService packages. Similarly, the Order.jar package manifest contains the entry Export-package:order. That is, the package exports its packages for use by clients. If import and export are not explicitly declared, OSGi throws a run-time error.

The Manifest file also contains additional information, such as the name of the package Activator class. The Activator class is responsible for calling the start () and Stop () methods in the package. In this case, the Activator class for the Client.jar package is the Orderclient,order.jar bundle's Activator class is orderservice.

Back to the top of the page

Deployment

Before you deploy and use a package, do the following: Create the catalog results shown in Figure 1 under the root directory C:\osgi folder, and put the components described earlier in this article into them: Java code into the appropriate package folder (client and service). The manifest file is placed in the appropriate Meta-inf folder (client and service).

Figure 1. Code directory structure

The next step is to deploy these packages. Use the Felix OSGi container to deploy the client and service packs by using the following steps: Use ANT to run Build.xml in the Services folder. Use ANT to run Build.xml in the client folder.

After the above build file is executed, the Client.jar and Order.jar packages are created in the Client/bin and Service/bin folders, respectively. Run Startfelix.bat at the microsoft®windows® command prompt to start the Felix runtime.

The profile name is prompted each time the Felix run is started. The profile name works like a project name. You can provide any name as the name of the project configuration file. For each subsequent boot of the Felix runtime, if you provide the same profile name that you entered earlier, Felix will load all the installed packages associated with the project name. If you provide a new configuration name, you will need to explicitly install each package again: The following commands are provided in the Felix Shell to install each package: Install File:service/bin/order.jar install file:client/bin/ Client.jar start service_bundle_id start client_bundle_id

To indicate the ID of the package, you can use the PS command. You must first start the service pack and then start the client package. When the appropriate package is started, the following output is displayed (see Figure 2).
Figure 2. Program Output

You can also update the package by supplying the update bundle_id command in the Felix Shell. The package will be dynamically updated at run time.

Back to the top of the page

Conclusion

This article briefly describes the functionality and concepts of the OSGi framework and explains how to use it to create dynamic JAR packages. You learned how to build and package a component as an OSGi package and then run it in the Felix run-time environment. We also learned how to create a package Manifest file to use as a communication interface between packages.

OSGi provides a new way to build and manage JAR packs. Keep an eye on part 2nd of this series, and we'll look at how the Spring framework is responsible for managing packages in place of OSGi in an OSGi environment.

Resource Usage Description:

In the resources below, the Felix version is 1.4.0, as described in the required context. It is to be noted that:

When you run the Ant compilation service and the client, modify the Felix_home variable in the client/build.xml, otherwise there will be a compilation error.

Download Address to use:

http://download.csdn.net/detail/icecream0/4187