OSGi实战：服务追踪与并发服务请求 - CSDN文库

需积分: 3 13 浏览量更新于2024-08-02 收藏 2.52MB PDF 举报

"osgi in practice" 本书《OSGi in Practice》由Neil Bartlett撰写，发布于2009年1月11日，主要探讨了OSGi（Open Service Gateway Initiative）技术及其在实际开发中的应用。书中内容涵盖了OSGi的基本概念、问题、解决方案以及与JARs、J2EE类加载器的对比，并介绍了如何开始使用OSGi。 1. OSGi基础 - 模块系统：OSGi的核心是模块化，作者在第1章介绍什么是模块，解释了模块系统对于软件工程的重要性。 - JARs的问题：JARs作为Java应用程序的打包方式，存在一系列问题，包括类加载器的全局类路径问题、类冲突、缺乏显式依赖、版本信息不足以及无法在JARs之间实现信息隐藏。 1.1 J2EE类加载书中讨论了J2EE环境下的类加载机制，指出它与OSGi的差异。 1.2 OSGi：简单理念 - 从树到图：OSGi将类的依赖关系从静态的树状结构转变为动态的图结构，允许更灵活的依赖管理。 - 信息隐藏：OSGi包（bundle）提供了一种信息隐藏机制，增强了代码的封装性。 - 版本控制：OSGi支持并行版本，使得不同版本的库可以同时存在并互不影响。 1.3 动态模块 OSGi的模块系统是动态的，这意味着模块可以在运行时安装、启动、停止和卸载，提供了高度的灵活性。 1.4 OSGi联盟与标准 OSGi Alliance制定了一系列标准，推动了OSGi的规范化发展。 1.5 OSGi实现书中提到了一些OSGi的实现，如Equinox和Felix，它们是OSGi规范的具体实现。 1.6 OSGi的替代方案 - 构建工具：Maven和Ivy等工具可以解决部分模块化问题，但它们并不是完整的模块系统。 - Eclipse插件系统：虽然Eclipse有自己的插件模型，但它并非完全符合OSGi标准。 - JSR277：这是一个试图标准化Java模块化的Java Specification Request，但与OSGi有区别。 2. 开始使用OSGi - 包建设：作者详细讲解了如何构建OSGi bundle，这是使用OSGi的第一步。 - OSGi开发工具：推荐了Eclipse PDE（Plugin Development Environment）和bnd等工具，用于简化OSGi开发过程。 - 安装框架：指导读者如何安装和配置OSGi框架，如Felix。 - 设置Eclipse：提供配置Eclipse以支持OSGi开发的步骤。 - 运行Felix：演示了如何启动Felix框架。 - bnd安装：解释了bnd工具的安装过程。 - "Hello, World!"示例：通过一个简单的示例，引导读者开始OSGi编程。《OSGi in Practice》深入浅出地介绍了OSGi的概念和实践，旨在帮助开发者理解OSGi的优势，克服传统Java开发中遇到的问题，以及如何利用OSGi实现更高效、更灵活的模块化系统。

1 Introduction

Consider the following question. In any large engineering project, for example

the design of a new bridge, skyscraper, or jet airliner, what is nearly always

the most diﬃcult challenge to overcome?

The answer is Complexity.

The Boeing 747-400 “Jumbo Jet” has six million parts[1], of which half are

fasteners. It contains 171 miles (274 km) of wiring and 5 miles (8 km) of

tubing. Seventy-ﬁve thousand engineering drawings were used to produce the

original 747 design. It is a very, very complex machine, and because of this

complexity, no single person can have a complete understand of how a Boeing

747 works. Yet, this is a machine ﬁrst designed in the 1960s — modern aircraft

have multiplied the level of complexity many times over. The only approach

that will allow human beings to design such incredible machines is to break

them down into smaller, more understandable modules.

Modularity enables several important beneﬁts:

Division of Labour. We can assign separate individuals or groups to work on

separate modules. The people working on a module will have a thorough

understanding of their own module but not all the others. For example,

the designer of the entertainment system does not need to know anything

about how the landing gear works (and vice versa!) but can concentrate

all her eﬀorts on building the best possible entertainment system.

Abstraction. We can now think about the aircraft as an abstract whole, with-

out needing a complete understanding of every part. For example, we

grasp that a 747 is able to ﬂy due to the lift provided by the wings and

the forward thrust of the engines, even if we do not understand exactly

how fuel is supplied to the engines or how many motors are required to

move the ﬂaps up and down.

Reuse. Given the amount of eﬀort that goes into designing even some of the

smaller components of an aircraft, it would be a shame to have to start

from scratch when we need an identical or very similar component in

another aircraft, or even in another part of the same aircraft. It would

be helpful if we could reuse components with minimal alterations.

Ease of Maintenance and Repair. It would be a shame to have to scrap an

entire aeroplane over a single burst tyre or torn seat cover. Modular

DRAFT PREVIEW

4 Chapter 1. Introduction

designs allow for failed modules to be removed and either repaired or

replaced without aﬀecting the rest of the machine.

It’s debatable whether the production of software can be characterised as an

engineering discipline, but nevertheless the complexity of sofware rivals what

is seen in other ﬁelds. Modern software is incredibly complex, and furthermore

is accelerating in its complexity. For example, the onboard computers of the

NASA Space Shuttle contained half a million lines of code, but today the DVD

player in your living room contains around one million lines of code. Microsoft

Windows XP is estimated to contain 40 million lines, and Windows Vista 50

million. A BMW 7-series car can contain up to 50 networked computers.

Just like aircraft engineers, software professionals are in the business of cre-

ating large and complex machines, which we can only hope to understand by

breaking them into modules.

The Java™ programming language is one of the most popular languages to-

day for building both large, enterprise applications and also small but widely

deployed mobile applications. However Java alone does not support modular-

ity in any useful way. . . we will see in the next section why Java’s existing

mechanisms fail to deliver all four of the above listed beneﬁts of modularity.

However, Java’s great strength is its ﬂexibility, which has allowed a powerful

module system to be built on top.

That module system is called OSGi. OSGi is nothing more nor less than the

way to build modular applications in Java.

1.1 What is a Module?

So, what should a software module look like? It should have the following

properties:

Self-Contained. A module is a logical whole: it can be moved around, installed

and uninstalled as a single unit. It is not an atom — it consists of smaller

parts — but those parts cannot stand alone, and the module may cease

to function if any single part is removed.

Highly Cohesive. Cohesion is a measure of how strongly related or focussed

the responsibilities of a module are. A module should not do many

unrelated things, but stick to one logical purpose and fulﬁl that purpose

well.

Loosely Coupled. A module should not be concerned with the internal im-

plementation of other modules that it interacts with. Loose coupling

allows us to change the implementation of one module without needing

to update all other modules that use it (along with any modules that

use those modules, and so on).

DRAFT PREVIEW

1.2 The Problem(s) with JARs 5

To support all three properties, it is vital for modules to have a well-deﬁned

interface for interaction with other modules. A stable interface enforces logical

boundaries between modules and prevents access to internal implementation

details. Ideally, the interface should be deﬁned in terms of what each module

oﬀers to other modules, and what each module requires from other modules.

1.2 The Problem(s) with JARs

The standard unit of deployment in Java is the JAR ﬁle, as documented by the

JAR File Speciﬁcation[2]. JARs are archive ﬁles based on the ZIP ﬁle format,

allowing many ﬁles to be aggregated into a single ﬁle. Typically the ﬁles

contained in the archive are a mixture of compiled Java class ﬁles and resource

ﬁles such as images and documents. Additionally the speciﬁcation deﬁnes a

standard location within a JAR archive for metadata — the META-INF folder

— and several standard ﬁle names and formats within that directly, most

important of which is the MANIFEST.MF ﬁle.

JAR ﬁles typically provide either a single library or a portion of the function-

ality of an application. Rarely is an entire application delivered as a single

JAR, unless it is very small. Therefore, constructing Java applications requires

composing together many JAR ﬁles: large applications can have a JAR count

in double or even triple ﬁgures. And yet the Java Development Kit (JDK)

provides only very rudimentary tools and technologies for managing and com-

posing JARs. In fact the tools available are so simplistic that the term “JAR

Hell”

1

has been coined for the problem of managing JARs, and the strange

error messages that one encounters when things go wrong.

The three biggest problems with JAR ﬁles as a unit of deployment are as

follows:

• There is no runtime concept that corresponds to a JAR; they are only

meaningful at build-time and deploy-time. Once the Java Virtual Ma-

chine is running, the contents of all the JARs are simply concatenated

and treated as a single, global list: the so-called “Classpath”. This model

scales very poorly.

• They contain no standard metadata to indicate their dependencies.

• They are not versioned, and multiple versions of JARs cannot be loaded

simultaneous.

• There is no mechanism for information hiding between JARs.

1

A reference to the term DLL Hell: a comparable problem with managing DLL ﬁles on the

Microsoft Windows operating system.

DRAFT PREVIEW

6 Chapter 1. Introduction

1.2.1 Class Loading and the Global Classpath

The term “classpath” originates from the command-line parameter that is

passed to the java command when running simple Java applications from

the command shell (or the DOS prompt in Windows terms), or more usually

from some kind of launcher script. It speciﬁes a list of JAR ﬁles and directo-

ries containing compiled Java class ﬁles. For example the following command

launches a Java application with both log4j.jar and the classes directory

on the classpath. First as it would be under UNIX (including Mac OS X):

java -classpath log4j.jar:classes org.example.HelloWorld

And then the DOS/Windows version:

java -classpath log4j.jar;classes org.example.HelloWorld

The ﬁnal parameter is the name of the “main” class to execute, which we will

assume has been compiled into the org/example/HelloWorld.class ﬁle in

the classes directory. Somehow the Java Virtual Machine (JVM) must load

the bytes in that class ﬁle and transform them into a Class object, on which

it can then execute the static main method. Let’s look at how this works in a

standard Java runtime environment (JRE).

The class in Java that loads classes is java.lang.ClassLoader, and it has

two responsibilities:

1. Finding classes, i.e. the physical bytes on disk, given their logical class

names.

2. Transforming those physical bytes into a Class object in memory.

We can extend the java.lang.ClassLoader class and provide our own imple-

mentation of the ﬁrst part, which allows us to extend the JRE to load code

from a network or other non-ﬁle-based storage system. However the second

part, i.e. transforming physical class bytes into Class objects, is implemented

in java.lang.ClassLoader by the defineClass method, which is both na-

tive and final. In other words, this functionality is built into the JRE and

cannot be overridden.

When we run the command above, the JRE determines that it needs to load

the class org.example.HelloWorld. Because it is the “main” class, it consults

a special ClassLoader named the application class loader. The ﬁrst thing the

application class loader does is ask its “parent” to load the class.

This illustrates a key feature of Java class loading called parent-ﬁrst delegation.

Class loaders are organised into a hierarchy, and by default all class loaders

DRAFT PREVIEW

剩余228页未读，继续阅读

mosquitoflying

粉丝: 0
资源: 7

最新资源