Finishing OSGi and ECLIPSE3

OSGi is the abbreviation for the Open Service Gateway initiative, which was established in 1999 and is a non-profit organization designed to establish an open service specification to open standards for service delivery over the network.

The OSGi specification includes various aspects of building an open, deliverable Network Service, and the OSGi specification includes the following child specifications.

Framework specification (OSGi Core, which provides a secure, manageable Java framework for deploying Extensible Java Services.) )

Package the Admin Service specification (to manage the reference relationships between different bundle.) Determine if there are other services using the current bundle when bundle update or reverse installation

The start level specification (defines the order in which different bundles are started or stopped when an OSGi Service platform is started and stopped)

Permission Admin Service Specification (Bundle permission to execute additional bundle code)

URL Handlers Service specification (how to register a URL Schema, how to convert a Java.io.InputStream object to a specific Java object)

LOG Service specification (below ...) ）

Configuration Admin Service Specification

Device Access Specification

User Admin Service Specification

IO Connector Service Specification

Http Service Specification

Preference Service Specification

Wire Admin Service Specification

XML Parser Service Specification

Metatype specification

Service Tracker Specification

Measurment and State specification

Position specification

Execution Environment Specfication
OSGI Framework
The framework is the core component of the OSGi Service platform specification. It provides a common, security-manageable Java framework. This framework enables the deployment and extension of a service application called bundles.

OSGI-compliant devices can download and install OSGi bundles, or delete them when they are no longer needed. Bundles is installed to register a certain number of services and is used by other bundles under the same framework.

In a dynamically expanding OSGI environment, the framework manages the installation and updating of bundles. It also manages the dependencies between bundles and services.

The framework provides the resources that bundle developers must have to develop on the Java platform, providing dynamic code loading for developing bundles, and making it easy for developers to develop and deploy a large services.

Second, the framework provides a concise and consistent programming model for Java bundle developers. Simplifies the complexity of development deployments. This programming model allows developers to bind their interface specifications to service in an OSGi environment. The selection of a specific implementation, optimized for a specific need or from a specific vendor, can thus is deferred To Run-time.

A consistent programming model helps developers cope with some of the critical errors that can be estimated. The framework will run on different hardware environments, but a consistent interface ensures that software builds can run on a consistent service interface.
The Bundle Object
For each bundle installed in the OSGi Service platform, there is a bundle object associated with it. A bundle object is used to manage the lifecycle of the bundle. This work is usually done by the management agent.
Bundle State
Bundle has the following States;

Installed–the Bundle has been successfully installed. Native code clauses must have been validated.



Resolved–all Java classes that the bundle needs are available. This state indicates which the bundle is either ready to be started or has stopped.



The starting–the bundle is being started, and the Bundleactivato R. Start method has been called and has not yet.



Stopping–the bundle is being stopped, and the Bundleactivato R. Stop method has been called and has not yet.



Active–the Bundle has successfully started and is running.



Uninstalled–the Bundle has been uninstalled. It cannot move to another state.



Eclipse 3.0 did not replace the original plugin mechanism with OSGi. It only works in a standard-compatible way: It provides users with a range of APIs to access, and in the process, changes (such as the plugin registry and loading mechanisms) are required to be fully compatible with the OSGi standard. The original plugin core supports only static extensions, which means that if you want to change an existing plug, you have to restart Core, which is to exit Eclipse and restart.

A lot of people ask why Eclipse is compatible with the OSGi specification and not the other specifications. Eclipse was developed by OTI before it was donated, with the goal of developing an embedded Java software development platform. There are still many connections on the Internet that point to Visual age Micro Edition (vame). This is one reason SWT is conceived, and they want to use SWT in the user interface of embedded devices. This source relationship explains why the OSGi specification was chosen at the time.

Another reason is that there are no other specifications except OSGi. The OSGI specification is widely supported in lightweight service architecture applications. And OSGi is supported by a number of well-known companies in the telecommunications industry and some other well-known companies in other industries. They need to use OSGi to compete with Sun's J2ME.