1. Introduction The OSGi (TM) specification defines a standard, component-oriented, computing environment for network services. After adding an OSGi service platform function for network devices (including embedded also include servers), the ability to control the life cycle of software components on this network device can be obtained anywhere. Software components on the network device can be arbitrarily installed, updated, or deleted without affecting the operation of the device. These components are some class libraries or applications that are capable of dynamically discovering and using other components, which can be obtained by purchasing by business components, or they can be developed. The OSGi Alliance has developed standard component interfaces for many common functions such as HTTP servers, configuration, logs, user management, XML, and so on.
The software component architecture has triggered an increasingly prominent problem during software development: software products have a lot of configuration information that requires development and maintenance. The standard OSGi component architecture greatly simplifies these configuration steps.
Second, the core component of the framework OSGI specification is the OSGI framework. The framework provides a standard environment for the application (called "bundles"). The OSGi framework is divided into four layers:
as the picture shows:
L0: EXECUTION Environment L1: Modules (MODULES) L2: Lifecycle Management (LIFE CYCLE Management) L3: Service Registry
In addition, there is a safety system to closely bind to each level.
L0: The operating environment is a Java operating environment. Java2's frames such as J2SE, CDC, CLDC, MIDP, etc. are all legitimate operating environments. Osgi defines a standard operating environment based on the underlying framework and the minimum demand required to run OSGi bundles.
L1: The module layer defines the class load policy. The OSGi framework is a powerful and strictly defined class load model that is built on Java and adds class loading modularization. In Java, only a single type of path definition contains all classes and resources, the OSGi module layer defines the private type path and the inter-module-controlled path connection inside the module.
L2: The life cycle layer control can dynamically install, start, stop, update, and uninstall bundles. Bundles depends on the class loading strategy of the module layer and provides an API of the management module in the runtime environment. The life cycle layer is dynamically established, usually not part of the application. The extensive dependency mechanism ensures the correct operation in the operating environment.
L3: The service registry provides a collaborative model for the dynamic feature of bundles. BBLES can be used to implement collaboration between the traditional class sharing mechanism, but the class sharing mechanism is unable to provide consistency for the module that is dynamically installed and uninstalled, so the service registry provides a consistent model for the shared object between bundles. Many services are similar to server-side objects, such as HTTP servers, other service representatives This is really an object in the world, such as Bluetooth phones around you.
The security of the OSGi framework is built on the Java language security and the Java2 security model. The Java language is designed to eliminate many possible security vulnerabilities, such as virus codes using buffer overflow attacks will no longer be possible. The access descriptor in the Java language defines the visibility of the code to other developers. The OSGI framework expands this model by allowing the unavailable private classes in the Java standard mechanism. The Java2 security model provides a comprehensive model for code access resources, and the OSGi framework supports full license dynamic management.
Third, the standard service is above the framework, the OSGi alliance defines many services, which are specified by the Java interface. Bundles can implement these interfaces and register as a service in the registry, using these services, client components that use these services can find these services in the registry and track them when these services can be tracked.
The following section gives a simple summary for the services in OSGi Release 3.
Fourth, the framework service OSGi framework provides a license management service, a package management service, and a boot level service. These services are in the optional implementation part of the specification, and the function of the command framework is played. License Management: Operational license for existing or future bundles is manipulated, once these operations permits are set, which will be activated immediately.
Package Management: Betles can share classes and resources in the package, and the system needs to recalculate the dependence between bundles after the Bundles update. The package management service provides a status of the system current package, and can also refresh the shared package, which means that the dependency will be broken and need to be recalculated.
Start level: The start level indicates that a set of bundles needs to initialize or start before other bundles. Start Level Service Provides setting the current start level of the system, set the Bundle's boot level and query the current set function.
(to be continued)
appendix:
Original link.
Contact the author, improper, please criticize the correct.
