Subscribe to News

From TechnologicalWiki

Contents 1 Introduction 1.1 Why OSGi? 2 OSGi Benefits 3 Web Container VS OSGi Container 4 The Framework 4.1 Bundles 4.2 Services 4.3 Service Registry. WhiteBoard Pattern 5 Examples 6 Breaking News 7 Distributed OSGi 8 Problems 9 Conclusions

[edit] Introduction

OSGi technology is a dynamic module system for Java that implements a complete and dynamic component model. Initially, It was created for smart environments. In 1999 was born the OSGi Alliance which was focused on solutions for the Embedded Java and networked devices markets. Some of the main firms which support it: IBM, Oracle, Nokia, Ericsson, Sun Microsystems, RedHat, Siemens, etc.

[edit] Why OSGi?

Over the last year the software complexity is increasing. Integrate existing software and reusing existing components is so costly today, moreover, there is no specific tool that standarize the integration aspects of software.

OSGi technology has some advance and new features with regard to other Java technologies:

• Smart class loading. That is mean it is possible to have multiple version jars of the same application.
• Highly dynamic. The application can be deploy or undeploy without restart or stop containers
• Highly extensible and configurable
• Dinamic Module System. Applications are constructed from small, reusable and collaborative components. These components can be composed into an application and deployed (Bundles)

OSGi can be applied in some different areas: automobiles, industrial automation, building automation, PDAs, grid computing, entertainment, smart devices and application servers.

[edit] OSGi Benefits

Any application that is designed in a modular fashion where it is necessary to start, stop, update individual modules with minimal impact on other modules is going to be benefited from OSGi. Furthermore, OSGi will allow developers an application remote management mechanism.

Below some of the main benefits for developers:

• Reduced Complexity: Developing with OSGi technology means developing bundles(the OSGi components). Bundles are modules
• Reuse, Easy Deployment, Dynamic Updates (without restarting the container)
• Versioning: OSGi technology solves JAR hell. In the OSGi environment, all bundles are carefully versioned and only bundles that can collaborate are wired together in the same class space
• Simple and Small: The core API is only one package and less than 30 classes/interfaces
• Fast and Lazy: Lazy in software is good and the OSGi technology has many mechanisms in place to do things only when they are really needed
• Humble: Many frameworks take over the whole VM, they only allow one instance to run in a VM. The flexibility of the OSGi specifications is demonstrated by how it can even run inside a J2EE Application Server
• Multiple versions: Applications can have more than one version of a particular module running at the same time

[edit] Web Container VS OSGi Container

The OSGi behaviour is similar to a Web Container altought OSGi is able to start, stop and update its components in a dynamic way. It also can run any kind of Java application and allows a direct communication each other. The next graphic explain clearly this feature:

[edit] The Framework

OSGi is a Service Oriented Architecture (SOA), quite solid, open and not restricted because of it must be able to run across different systems and over several devices. The core component of the OSGi specifications is the OSGi Framework. This framework provides a standardized environment to applications (called bundles) and is divided in a number of layers:

• Execution Environment: Defines what methods and classes are available in a specific platform (Java VM)
• Modules: defines the class loading policies. The OSGi Framework is a powerful and rigidly specified class-loading model
• Life-Cycle: The API to install, start, stop, update, and uninstall bundles
• Services: The services layer connects bundles in a dynamic way by offering a publish-find-bind model for plain old Java objects
• Bundles: the OSGi components made by the developers
• Security: The layer that handles the security aspects

[edit] Bundles

The Bundles are normal "jar" components with an extra MANIFEST file. Usually the bundles carry descriptive information about themself in the manifest file and bundle's services are exposed to other bundles installed in the OSGi Service Platform. Some important Manifest Headers:

Bundle-Activator: class used to start, stop the bundle
Bundle-SymbolicName: identifies the bundle
Bundle-Version: specifies the version of the bundle
Export-Package: declaration of exported packages
Import-Package: declaration of imported packages
                  . . . . . .
                  . . . . . .

Bundles can hide packages and classes from other bundles, as well as share packages with other bundles.

[edit] Services

Services are specified by a Java interface. Bundles can implement an interface and register the service with the Service Registry. Clients of the service can find it in the registry, or react to it when it appears or disappears

The OSGi Alliance has specified many services splitted in four areas:

• Framework (URL hander, Package Admin,..)
• System (Log, Admin, IO Connector, …)
• Protocol (Http, UPnP, …)
• Miscellaneous (XML Parser, Wire Admin Service,..)

[edit] Service Registry. WhiteBoard Pattern

The OSGi framework maintains a central Service Registry. Here,services can be registered with a set of properties (i.e: service's uri, name, etc.)

The Service Registry makes use of the WhiteBoard pattern, also known as BlackBoard pattern. This pattern permits multiple data sources as well as multiple viewers. It also has the effect of completely decoupling producers and consumers of information.The services are dynamically added and removed from the registry.

An event listener must take action when a an event source is unregistered. Vice-versa, the event source must monitor the bundle of the event listener and take action when this bundle is stopped The whiteboard pattern has event listeners register themselves as a service with the OSGi framework. When the event source has an event object to deliver, the event source calls all event listeners in the service registry.

[edit] Examples

Some tools and real applications using OSGi Framework:

• Pax Runner: tool to provision OSGi bundles in all major open source OSGi framework implementations (Felix, Equinox, Knopflerfish, Concierge)
• From Eclipse 3.0 and up: is fully compliant with the OSGi framework specification R3.0. In fact, plug-ins are bundles
• GlassFish V3: It is possible to run this application server on an OSGI R4 platform
• OSGI Android: project to run Apache Felix on Google Android. Furthermore, it contains documentation and examples of how to create dynamic applications that use OSGi and run on Android
• Nuxeo: an open source, standards-compliant, Java EE-based platform for Enterprise Content Management (ECM), both server-side and client-side, based on OSGi
• SpringSource Application Platform: an open source, completely modular, OSGi-based Java server designed to run enterprise Java applications
• OpenEJB: open source OSGi-enabled EJB 3.0 container that can be run both in standalone or embedded mode.
• Philips iPronto: Philips revolutionizes control of home cinema and home automation products.
• JBoss: it is developed its last version over OSGi framework.
• Other: BMW serie 7, Volvo, Siemens, NokiaE70, LinkedIn, Spring Dynamic Modules, etc.

[edit] Breaking News

Nowadays, there are four (renowned) open source OSGi containers: Equinox, Knopflerfish, Apache Felix, Concierge. Obviously there are other comercial OSGi containers.

The last version is "OSGi Service Platform Release 4.2” (OSGi R4.2), which includes the next new features:

• Distributed OSGi (RFC 119)
  • Standard that enables the distribution of OSGi Services
  • Localization of OSGi bundle manifests enabling service deployment anywhere
• Compatibility with Release 3, requiring no changes for existing OSGi bundles, applications, or services
• Service Component Runtime (SCR): using Declarative Service (DS), developers can specify what services their bundle provides and what services are required.  This is all specified declaratively using XML, and the DS bundle is responsible for wiring everything together
• Service Tracker, Mobile Operational Management (JSR 232 ), BluePrint Container, etc.

[edit] Distributed OSGi

This new specification allos to invoke services running in other Machines or JVMs. The mechanism of how they communicate (RMI, WebServices etc.) is open to providers but most common is a “middleware” bundle that adapts OSGi services to become Web services.

Features:

• Allow OSGi services to publish themselves and be invoked from outside their own runtime
• Allow OSGi services to discover and consume services outside their own runtime
• OSGi service programming model is kept intact!

Next, the current implementations of distributed OSGi:

• Apache CXF Distributed OSGi: implements the Remote Services functionality using Web Services, leveraging SOAP over HTTP and exposing the Service over a WSDL contract
• Eclipse ECF Project: framework to build Eclipse RCP (Rich Client Platform) applications. Support multiple protocols like: XMPP, ECF, Generic, R-OSGi,… .
• R-OSGi: provides a transparent way to access services on remote OSGi platforms. Runs as an OSGi bundle and facilitates distribution for arbitrary OSGi framework implementations

[edit] Problems

There are some problems about this new technology, just expose some of them:

• OSGi is great, but tooling is not quite quite there yet
• Not every library is a bundle
• OSGi was designed for embedded devices. Using it for server side is recent
• OSGi is quite low level. Some work to 'hide' the complexity:
  • Spring Dynamic Module
  • Multiple Vendors Containers
• Version management can be nightmarish

 Import–Package:  com.vodafone.util;version=1.0.0

Version=1.0.0 means [1.0.0, infinity)!!!

Should use:

 Import–Package:  com.vodafone.util;version=[1.0.0,2.0.0)

• Upgrades (in bundles) can loose dependencies
• Mapping of key Java EE technologies is not completed yet

[edit] Conclusions

OSGi specifications are widely applicables because the platform is spplited in small layers that allows multiple Java™ based components to efficiently cooperate in a single Java Virtual Machine.

The framework provides an extensive security model so that components can run in a shielded environment. However, with the proper permissions, components can reuse and cooperate, unlike other Java application environments.

The presence of OSGi technology-based middleware in many different industries creates a large software market for OSGi software components.

The rigid definition of the OSGi Service Platform enables components that can run on a variety of devices, from very small to very big.

Adoption of the OSGi specifications can therefore reduce software development costs as well as provide new business opportunities.

• Future:
  • OSGi vs Jigsaw (JSR 294: Improved Modularity Support in the Java Programming Language)