OSGi Core技术详解与实战指南

需积分: 9 157 浏览量更新于2024-07-21 收藏 3.38MB PDF 举报

"OSGI Core 技术文档与说明，涵盖了OSGI技术的三个核心模块：服务层、模块层和生命周期层，旨在引导开发者理解和实践模块化开发，实现灵活的网络模块构建。" OSGI（Open Services Gateway Initiative）是Java平台上的一种模块化系统，它的主要目标是创建一个动态、可扩展的运行时环境。OSGI规范定义了一个模块化系统，允许Java应用程序以模块化的方式构建，从而提高软件的可维护性、可升级性和可重用性。在OSGI的核心模块中： 1. **服务层**：OSGI服务层是OSGI框架的心脏，它提供了服务注册和发现机制。开发者可以将服务注册到服务注册表中，其他模块可以通过查询服务注册表来获取并使用这些服务。服务层支持动态性，意味着服务可以在运行时被发布、查找、使用和取消发布，增强了系统的灵活性和适应性。 2. **模块层**：OSGI的模块层基于类加载器的概念，每个模块（Bundle）都有自己的类加载器，可以控制其对其他模块的依赖。这种模块化系统确保了模块间的隔离性，使得模块可以独立地安装、启动、更新和卸载，而不影响其他模块。模块通过导入导出包来声明依赖关系，这使得依赖管理变得简单且有效。 3. **生命周期层**：在OSGI中，每个模块都有一个生命周期，包括安装、启动、暂停、更新和卸载等状态。这些状态转换提供了对模块运行时行为的精细控制，允许在运行时动态调整系统配置，如热更新代码或替换模块。此外，OSGI还强调了命名空间的完整性，防止了类冲突，因为每个模块都有自己的类加载器，能够识别和管理自己范围内的类。同时，OSGI的API提供了管理服务，如启动、停止和查询模块，以及处理模块之间的依赖关系。通过OSGI，开发者可以创建更加灵活和动态的Java应用程序，特别是在大型复杂系统中，OSGI能够帮助解决传统Java应用程序中的类路径问题和依赖地狱。它的模块化特性使得系统更易于维护，也更容易实现组件的升级和替换。因此，理解并掌握OSGI技术对于任何希望在Java环境中构建可扩展、可维护应用的开发者来说都至关重要。

References Introduction

Page 16 OSGi Core Release 6

When a component is represented in a bundle, a version is needed in the declaration of the Im-

port-Package or Export-Package manifest headers.

Table 1.1 Packages and versions OSGi Core

Item Package Version

Framework Specification (all layers) org.osgi.framework Version 1.8

Framework Launching org.osgi.framework.launch Version 1.2

6 Resource API Specification org.osgi.resource Version 1.0

7 Bundle Wiring API Specification org.osgi.framework.wiring Version 1.2

8 Framework Namespaces Specification org.osgi.framework.namespace Version 1.1

9 Start Level API Specification org.osgi.framework.startlevel Version 1.0

50 ConditionalPermission Admin Service Specifi-

cation

org.osgi.service.condpermadmin Version 1.1

51 Permission Admin Service Specification org.osgi.service.permissionadmin Version 1.2

52 URL Handlers Service Specification org.osgi.service.url Version 1.0

53 Resolver Hook Service Specification org.osgi.framework.hooks.resolver Version 1.0

54 Bundle Hook Service Specification org.osgi.framework.hooks.bundle Version 1.1

55 Service Hook Service Specification org.osgi.framework.hooks.service Version 1.1

56 Weaving Hook Service Specification org.osgi.framework.hooks.weaving Version 1.1

57 Data Transfer Objects Specification org.osgi.dto Version 1.0

701 Tracker Specification org.osgi.util.tracker Version 1.5

Versioning Annotations org.osgi.annotation.versioning Version 1.0

A compliant framework implementation must implement all of the specifications in this document

except as outlined below.

• 50 ConditionalPermission Admin Service Specification and 51 Permission Admin Service Specification are

mandatory only if 2 Security Layer is supported and a Security Manager is installed.

• 52 URL Handlers Service Specification is mandatory if the framework implementation system bun-

dle exports the org.osgi.service.url package.

• 701 Tracker Specification is optional.

1.5 References

[1] Java Language Specification Third Edition

http://docs.oracle.com/javase/specs/

1.6 Changes

• Added Type Roles for Semantic Versioning on page 54 and Versioning Annotations to document

version and type role information for packages.

• Added 57 Data Transfer Objects Specification.

• Added Service Scope on page 134 and Prototype Service Factory on page 140.

Security Layer Version 1.8 Introduction

OSGi Core Release 6 Page 17

2 Security Layer

Version 1.8

2.1 Introduction

The OSGi Security Layer is an optional layer that underlies the OSGi framework. The layer is based

on the Java 2 security architecture. It provides the infrastructure to deploy and manage applications

that must run in fine-grained controlled environments.

2.1.1 Essentials

• Fine-grained - The control of applications running in an OSGi Framework must allow for detailed

control of those applications.

• Manageable - The security layer itself does not define an API to control the applications. The man-

agement of the security layer is left to the life cycle layer.

• Optional - The security layer is optional.

2.2 Security Overview

The Framework security model is based on the Java 2 specification. If security checks are performed,

they must be done according to [3] Java 2 Security Architecture. It is assumed that the reader is famil-

iar with this specification. The security layer is optional, see Optional Security on page 17.

2.2.1 Code Authentication

The OSGi framework can authenticate code in the following ways:

• By location

• By signer

At higher layers there are defined services that can manage the permissions that are associated with

the authenticated unit of code. These services are:

• Permission Admin service - Manages the permission based on full location strings.

• Conditional Permission Admin service - Manages the permissions based on a comprehensive condi-

tional model, where the conditions can test for location or signer.

For signing, this requires the JAR files to be signed; this is described in Digitally Signed JAR Files on

page 18.

2.2.2 Optional Security

The Java platform on which the Framework runs must provide the Java Security APIs necessary for

Java 2 permissions. On resource-constrained platforms, these Java Security APIs may be stubs that

allow the bundle classes to be loaded and executed, but the stubs never actually perform the securi-

ty checks. The behavior of these stubs must be as follows:

• checkPermission - Return without throwing a SecurityException.

Digitally Signed JAR Files Security Layer Version 1.8

Page 18 OSGi Core Release 6

• checkGuard - Return without throwing a SecurityException.

• implies - Return true.

This behavior allows code to run as if all bundles have AllPermission.

2.3 Digitally Signed JAR Files

This section defines in detail how JAR files must be signed. This section therefore overlaps with the

different JAR file specifications that are part of the different versions of Java. The reason for this du-

plication is that there are many aspects left as optional or not well-defined in these specifications. A

reference was therefore insufficient.

Digitally signing is a security feature that verifies the following:

• Authenticates the signer

• Ensures that the content has not been modified after it was signed by the principal.

In an OSGi Framework, the principals that signed a JAR become associated with that JAR. This asso-

ciation is then used to:

• Grant permissions to a JAR based on the authenticated principal

• Target a set of bundles by principal for a permission to operate on or with those bundles

For example, an Operator can grant the ACME company the right to use networking on their de-

vices. The ACME company can then use networking in every bundle they digitally sign and deploy

on the Operator's device. Also, a specific bundle can be granted permission to only manage the life

cycle of bundles that are signed by the ACME company.

Signing provides a powerful delegation model. It allows an Operator to grant a restricted set of per-

missions to a company, after which the company can create JARs that can use those permissions,

without requiring any intervention of, or communication with, the Operator for each particular

JAR. This delegation model is shown graphically in Figure 2.1.

Figure 2.1 Delegation model

Developer

Operator

Enterprise

OSGi

Framework

Employee

grants

permissions

uses

provides

installs

Digital signing is based on public key cryptography. Public key cryptography uses a system where

there are two mathematically related keys: a public and a private key. The public key is shared with

the world and can be dispersed freely, usually in the form of a certificate. The private key must be

kept a secret.

Messages signed with the private key can only be verified correctly with the public key. This can be

used to authenticate the signer of a message (assuming the public key is trusted, this is discussed in

Certificates on page 22).

Security Layer Version 1.8 Digitally Signed JAR Files

OSGi Core Release 6 Page 19

The digital signing process used is based on Java 2 JAR signing. The process of signing is repeated, re-

stricted and augmented here to improve the inter-operability of OSGi bundles.

2.3.1 JAR Structure and Manifest

A JAR can be signed by multiple signers. Each signer must store two resources in the JAR file. These

resources are:

• A signature instruction resource that has a similar format like the Manifest. It must have a .SF ex-

tension. This file provides digests for the complete manifest file.

• A PKCS#7 resource that contains the digital signature of the signature instruction resource. See

[11] Public Key Cryptography Standard #7 for information about its format.

These JAR file signing resources must be placed in the META-INF directory. For signing, the META-

INF directory is special because files in there are not signed in the normal way. These signing re-

sources must come directly after the MANIFEST.MF file, and before any other resources in a JAR

stream. If this is not the case, then a Framework should not accept the signatures and must treat

the bundle as unsigned. This ordering is important because it allows the receiver of the JAR file

to stream the contents without buffering. All the security information is available before any re-

sources are loaded. This model is shown in Figure 2.2.

Figure 2.2 Signer files in JAR

META-INF/

MANIFEST.MF

ACME.SF

ACME.RSA

DAFFY.SF

DAFFY.DSA

... other files

The signature instruction resource contains digests of the Manifest resource, not the actual resource

data itself. A digest is a one way function that computes a value from the bytes of a resource in such

a way that it is very difficult to create a set of bytes that matches that digest value.

The JAR Manifest must therefore contain one or more digests of the actual resources. These digests

must be placed in their name section of the manifest. The name of the digest header is constructed

with its algorithm followed by -Digest. An example is the SHA1-Digest. It is recommended that OS-

Gi Framework implementations support the following digest algorithms.

• MD5 - Message Digest 5, an improved version of MD4. It generates a 128-bit hash. It is described

at page 436 in [7] RFC 1321 The MD5 Message-Digest Algorithm.

• SHA1 - An improved version of SHA, delivers a 160 bit hash. It is defined in [6] Secure Hash Algo-

rithm 1.

The hash must be encoded with a Base 64 encoding. Base 64 encoding is defined in [8] RFC 1421 Pri-

vacy Enhancement for Internet Electronic Mail.

For example, a manifest could look like:

Manifest-Version: 1.0

Bundle-Name: DisplayManifest

↵

Name: x/A.class

SHA1-Digest: RJpDp+igoJ1kxs8CSFeDtMbMq78=

Digitally Signed JAR Files Security Layer Version 1.8

Page 20 OSGi Core Release 6

↵

Name: x/B.class

SHA1-Digest: 3EuIPcx414w2QfFSXSZEBfLgKYA=

↵

Graphically this looks like Figure 2.3.

Figure 2.3 Signer files in JAR

META-INF/

MANIFEST.MF

... other files

Manifest-Version: 1.0

Name: x/A.class

SHA1-Digest: RJpDp+igoJ1k...

Name: x/B.class

SHA1-Digest: 3EuIPcx414w2...

x/A.class

x/B.class

OSGi JARs must be signed by one or more signers that sign all resources except the ones in the

META-INF directory; the default behavior of the jarsigner tool. This is a restriction with respect to

standard Java JAR signing; there is no partial signing for an OSGi JAR. The OSGi specification only

supports fully signed bundles. The reason for this restriction is because partially signing can break

the protection of private packages. It also simplifies the security API because all code of a bundle is

using the same protection domain.

Signature files in nested JAR files (For example JARs on the Bundle-ClassPath) must be ignored.

These nested JAR files must share the same protection domain as their containing bundle. They

must be treated as if their resources were stored directly in the outer JAR.

Each signature is based on two resources. The first file is the signature instruction file; this file must

have a file name with an extension .SF. A signature file has the same syntax as the manifest, except

that it starts with Signature-Version: 1.0 instead of Manifest-Version: 1.0.

The only relevant part of the signature resource is the digest of the Manifest resource. The name of

the header must be the name algorithm (e.g. SHA1) followed by -Digest-Manifest. For example:

Signature-Version: 1.0

SHA1-Digest-Manifest: RJpDp+igoJ1kxs8CSFeDtMbMq78=

MD5-Digest-Manifest: IIsI6HranRNHMY27SK8M5qMunR4=

The signature resource can contain name sections as well. However, these name sections should be

ignored.

If there are multiple signers, then their signature instruction resources can be identical if they use

the same digest algorithms. However, each signer must still have its own signature instruction file.

That is, it is not allowed to share the signature resource between signers.

The indirection of the signature instruction files digests is depicted in Figure 2.4 for two signers:

ACME and DAFFY.

剩余449页未读，继续阅读

zhangshuyuan1234

粉丝: 0
资源: 4

OSGi Core技术详解与实战指南

org.osgi.core-6.0.0.jar

osgi解决不同版本jar包冲突的demo

org.osgi.core-4.2.0

spring-osgi-1.2.0.zip

OSGi core

OSGi Service Platform Core Specification

OSGi 4.3 Core Specification Release: April 2011

osgi相关文档、及学习资料

nelronik-core

servicemix-core-3.4.1.zip

最新资源