OSGi服务平台核心规范详解

需积分: 9 36 浏览量更新于2024-07-26 收藏 1.86MB PDF 举报

"OSGi Service Platform Core Specification 是由 OSGi Alliance 发布的一份详细的技术规范文档，主要针对 OSGi 服务平台的核心部分。该文档涵盖了 Release 4, Version 4.0.1 的内容，发布于2006年7月。此文档旨在作为参考书籍，详细阐述了 OSGi 技术的各项核心特性，适用于开发者和架构师深入理解 OSGi 平台的工作原理和应用实践。" OSGi（Open Services Gateway initiative）是一个用于创建模块化Java应用程序的开放标准，它允许开发人员将复杂的应用程序分解为一组可独立更新和管理的模块，这些模块被称为捆绑（Bundles）。OSGi Service Platform Core Specification 描述了 OSGi 框架的基础架构、服务模型以及如何在 Java 应用中使用这些服务。在 OSGi 中，每个捆绑都是一个自包含的单元，拥有自己的类路径，并且可以声明其依赖于其他捆绑中的服务和资源。通过 OSGi 框架，这些捆绑之间的依赖关系可以动态管理和解决，使得应用程序可以在运行时安装、卸载和更新捆绑，而不会引起系统中断。核心规范中的关键概念包括： 1. **捆绑（Bundles）**：OSGi 应用程序的基本构建块，每个捆绑都包含一组相关的类和其他资源，并且可以有自己的生命周期（启动、停止、更新、卸载）。 2. **类加载器（Class Loaders）**：每个捆绑都有自己的类加载器，用于隔离不同捆绑的类空间，避免命名冲突。 3. **元数据（Metadata）**：每个捆绑都包含描述自身和其依赖的元数据，如 Manifest 文件，其中包含了捆绑的名称、版本、依赖关系等信息。 4. **服务注册表（Service Registry）**：OSGi 平台的核心组件，允许捆绑发布和查找服务，实现服务的共享和交互。 5. **生命周期管理**：捆绑可以动态地启动、停止、更新或卸载，无需重启整个应用程序。 6. **服务事件（Service Events）**：框架广播服务的添加、更改和移除事件，使得捆绑可以监听并响应这些变化。 OSGi 的优势在于提高了软件的可维护性、可扩展性和灵活性，尤其适用于复杂的大型企业级应用和嵌入式系统。开发者可以利用 OSGi 实现组件化的软件设计，便于代码复用、减少耦合，并实现更高效的应用部署和维护。通过阅读 OSGi Service Platform Core Specification，读者将能够理解 OSGi 框架的核心机制，学习如何创建、配置和管理 OSGi 捆绑，以及如何在 OSGi 环境下实现服务的交互和协作。这份文档对于想要深入掌握 OSGi 技术的开发者来说是不可或缺的参考资料。

Version Information Introduction

8-266 OSGi Service Platform Release 4

Figure 6 Bundles

1.4.5 Key Words

This specification consistently uses the words may, should, and must. Their

meaning is well-defined in [1] Bradner, S., Key words for use in RFCs to Indicate

Requirement Levels. A summary follows.

• must – An absolute requirement. Both the Framework implementation

and bundles have obligations that are required to be fulfilled to conform

to this specification.

• should – Recommended. It is strongly recommended to follow the

description, but reasons may exist to deviate from this recommendation.

• may or can – Optional. Implementations must still be interoperable

when these items are not implemented.

1.5 Version Information

This document specifies OSGi Service Platform Core Specification, Release

4. This specification is backward compatible to releases 1, 2, and 3.

All Security, Module, Life Cycle and Service Layers are part of the Frame-

work Specification

Components in this specification have their own specification version,

independent of the document release number. The following table summa-

rizes the packages and specification versions for the different subjects.

When a component is represented in a bundle, a version is needed in the

declaration of the Import-Package or Export-Package manifest headers.

<<interface>>

Role

<<interface>>

UserAdmin

0.n

has

name

UserAdminImpl RoleImpl

Implementation

bundle

Permission

0..n

Table 1 Packages and versions

Item Package Version

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

9 Conditional Permission Admin Specifica-

tion

org.osgi.service.condpermission-

admin

Version 1.0

7 Package Admin Service Specification org.osgi.service.packageadmin Version 1.2

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

8 Start Level Service Specification org.osgi.service.startlevel Version 1.0

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

OSGi Service Platform Release 4 9-266

Introduction Changes for Version 4.0.1

1.6 Changes for Version 4.0.1

• What Is New on page 2 – Corrected the bullet on signed bundles to cor-

rectly refered to Permission Admin service instead of Package Admin

service.

• General Syntax Definitions on page 4 – Corrected token grammar pro-

duction to end with + because * allowed empty tokens.

• Bundle-Localization: OSGI-INF/l10n/bundle on page 26 – Corrected the

paragraph to refer to Bundle-Localization header rather than Bundle-

Location header which is not defined.

• Naming of Execution Environments on page 31 – Additional execution envi-

ronment names have been defined for Java 2 SE 5.0 and Java SE 6.0. They

are J2SE-1.5 and JavaSE-1.6, respectively.

• Export-Package on page 37 – Corrected description of the exclude

directive which incorrectly refered to resources. Only classes may be

excluded or included. Also clarified the bundle-symbolicname and

bundle-version attributes in case the bundle is a fragment.

• Overall Search Order on page 52 – Clarified step 4 of the class searching

algorithm.

• Bundle Cycles on page 56 – Emphasized the depth first search for required

bundles.

• Manifest Localization on page 63 – Corrected the attribute names in

example to be properly escaped.

• Require-Bundle on page 65 – Improved description of package searching

for required bundles and fragments as well as permissions needed for

fragments.

• Fragment Bundles on page 67 – Defined the protection domain of frag-

ments, clarified what happens when a fragment is updated, and specified

what default properties are used for fragment packages.

• Fragment-Host on page 68 – Clarified the default attributes of fragments

and fragment hosts.

• Extension Bundles on page 71 – Clarified that resolving an extension

bundle can require a relaunch of the framework (step 2) and clarified

what must happen when an extension bundle changes type in an update.

• Bundle Permission on page 73 – Clarified that framework implementa-

tions that supports Require-Bundle and/or Fragment headers must also

support Bundle Permission. Also defined on what protection domain

must be used for the checks.

• Package Permission on page 73 – Defined what protection domain must be

used for Package Permission checking for Fragments.

• Access to Resources on page 85 – Clarified that a framework implemen-

tation may resolve a bundle during the execution of Bundle.findEntries

method without creating a class loader.

• Environment Properties on page 88 – Defined a new processor, SH4, and

two new operating systems, Emboss and Epoc32.

• Privileged Callbacks on page 98 – Clarified that a framework implemen-

tation must not call the constructor of a BundleActivator object from

within a doPrivileged region.

• Permission Management on page 226 – Clarified the name parameter can

be null or an empty string. Corrected the example code: the fields

EMPTY_CS and EMPTY_PS are now arrays and the code now checks for

empty lines.

Digitally Signed JAR Files Security Layer Version 1.3

12-266 OSGi Service Platform Release 4

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

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

• checkPermission – Return without throwing a SecurityException.

• 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 duplication 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 association 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 net-

working on their devices. 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 permissions to a company, after which the company

can create JARs that can use those permissions, without requiring any inter-

vention of, or communication with, the Operator for each particular JAR.

This delegation model is shown graphically in Figure 7.

剩余273页未读，继续阅读

走在架构的小路上

粉丝: 26
资源: 74

OSGi服务平台核心规范详解

OSGi Service Platform 4.1

OSGi Service Platform Service Compendium

使用Tycho构建OSGi插件项目

Springboot框架如何集成OSGI

osgi + rcp

OSGI container

osgi android

android jbundle-util-osgi-wrapped-httpclient - httpclient osgi

Spring OSGI 如何使用HystrixCommand

mvn dependency:tree 命令 为什么没解析出<dependency> <groupId>org.osgi</groupId> <artifactId>org.osgi.core</artifactId> </dependency>

最新资源

mvn dependency:tree 命令为什么没解析出<dependency> <groupId>org.osgi</groupId> <artifactId>org.osgi.core</artifactId> </dependency>