Introduction to OSGI Specification

The original purpose of OSGi (Open Service Gateway Initiative) is to provide a common software running platform for a variety of embedded devices, that is, a middleware platform that can shield the difference between device operating systems and hardware. PCs are basically monopolized by the Wintel architecture, and applications running on PCs can be run on another PC, but different for other devices, their hardware platforms may be completely different and their operating systems are from different vendors, so applications on any device need customization, The need for a middleware platform is thus generated.

OSGi is not specifically designed for home networking, except for residential gateways, other mobile embedded devices such as on-board computers can access the Internet through OSGi to obtain different application services. It provides an open, common architecture for service providers, software vendors, gateway developers, and device vendors to interact with the development, deployment, and management of services. Its software environment is based on Sun's Java Virtual machine and does not involve specific connection agreements. For any new device, it is flexible enough to incorporate it into the existing network. Objects that can use OSGi include a variety of digital and analog set-top boxes, service gateways, cable TV cable modems, consumer electronics, PCs, industrial computers, automobiles, and so on.

Because OSGi is based on Java technology, the biggest benefit of Java is platform independence. OSGi software can be implemented on different types of residential gateway devices. And the OSGI specification can access standard bridges with a variety of devices (as shown in Figure 1), such as systems that follow OSGi to deploy and manage the Jini service well, providing an interaction between Jini devices and service providers. For standards and specifications based on non-Java technologies such as Havi and UPnP, OSGi can also provide a bridge to communicate with them.

Chapter II Introduction to the OSGI specification

Architecture of the 2.1 OSGi specification

A reference Architecture [1] is provided in the OSGi specification, and it basically embodies the design intent of OSGi.

The architecture of OSGi is based on such a model: the operator manages a potentially huge service network platform. The OSGi specification assumes that the service platform is fully controlled by this operator and that the operator uses the service platform to run services from different service providers. However, this is only a scenario, there are other models, such as the deployment of PC, industrial applications (such as mobile phone base station is a management center full control of all aspects), middleware model. The most widely used application of OSGi is in networked services. In addition to the reference model, some other models are mentioned in the specification. Please refer to the OSGI 3.0 specification [1].

Features of the 2.1.1 OSGi Reference Architecture

1. Business driver: The operator's perspective drives OSGi's architecture.

2. Perfect: The architecture must be perfect and detailed enough to allow developers to produce robust products.

3. Unrestricted: Because the operator operates a service platform in the performance and network environment changes are very large.

4. Openness: The standard is not designed for a specific system, and the OSGi Reference Architecture must consider and support many different scenarios.

Entities involved in the 2.1.2 OSGi Reference Architecture

1. Service platform: an instance of a Java virtual machine, an OSGI framework structure, and a collection of running service packs.

2. Service Platform Server (SPS): hardware that resides on one or more service platforms.

3. Operator: An organization that controls many service platforms.

4. Service Application: A suite of software packages, documents and supporting applications that provide services to end users.

5. Service User: The user who obtains the Service Application service.

6. Service Providers: Developing service applications and deploying them to the service platform through the Service Deployment Manager.

7. Service Deployment Manager: Deploy and partially manage service applications provided by one or more service providers.