Difference between revisions of "OSGi Concepts Modules"

From CDOT Wiki
Jump to: navigation, search
 
Line 10: Line 10:
 
packages from other bundles. The Module Layer can be used without the
 
packages from other bundles. The Module Layer can be used without the
 
life cycle and Service Layer. The Life Cycle Layer provides an API to manage
 
life cycle and Service Layer. The Life Cycle Layer provides an API to manage
the bundles in the Module Layer, while the Service Layer provides a communication model for the bundles ([http://www.osgi.org/Release4/HomePage see the OSGi Service Platform Release 4]_.
+
the bundles in the Module Layer, while the Service Layer provides a communication model for the bundles ([http://www.osgi.org/Release4/HomePage see the OSGi Service Platform Release 4]).

Latest revision as of 08:55, 25 January 2011

OSGi Modules

Modules layer defines the class loading policies.

The OSGi Framework is a powerful and rigidly specified class-loading model. It is based on top of Java but adds modularization. In Java, there is normally a single classpath that contains all the classes and resources. The OSGi Modules layer adds private classes for a module as well as controlled linking between modules. The module layer is fully integrated with the security architecture, enabling the option to deploy closed systems, walled gardens, or completely user managed systems at the discretion of the manufacturer.

The Module Layer defines a modularization model for Java. It addresses some of the shortcomings of Java’s deployment model. The modularization layer has strict rules for sharing Java packages between bundles or hiding packages from other bundles. The Module Layer can be used without the life cycle and Service Layer. The Life Cycle Layer provides an API to manage the bundles in the Module Layer, while the Service Layer provides a communication model for the bundles (see the OSGi Service Platform Release 4).