OSGi实战：探索Java模块化框架

需积分: 10 154 浏览量更新于2024-07-27 收藏 3.78MB PDF 举报

"Osgi_in_Action 是一本关于 OSGi 技术的英文完整版书籍，共计13章，509页。本书通过Manning Early Access Program (MEAP) 发布，由Manning Publications出版。作者鼓励读者在论坛上提供反馈和修正，论坛链接指向了特定的讨论板块。" 在 Java 平台的成功背后，虽然其设计精良且持续进化，但它并没有提供明确的模块化支持。OSGi（Open Service Gateway Initiative）的出现就是为了填补这一空白。OSGi 是一个用于创建模块化 Java 应用程序的框架，它引入了一种强大的机制来管理依赖关系、生命周期和服务发现，从而使得大型复杂系统的构建和维护变得更加容易。 1. OSGi Revealed：这部分内容可能是对 OSGi 的基础介绍，揭示了 OSGi 是如何工作的，包括它的核心概念、模块系统以及如何在 Java 应用中使用 OSGi。 2. Mastering Modularity：这一章节深入探讨了模块化的重要性，如何利用 OSGi 实现高效、可扩展的模块化设计，并可能涵盖模块间的隔离和互操作性。 3. Learning Lifecycle：这部分会介绍 OSGi 中服务和组件的生命周期管理，包括启动、暂停、停止和更新等操作，以及如何在不同状态之间平滑过渡。 4. Studying Services：服务是 OSGi 的核心特性，这部分可能会讲解如何声明、注册、查找和使用 OSGi 服务，以及服务的动态性。 5. Delving Deeper into Modularity：深入研究模块化，可能涵盖了高级主题，如依赖注入、版本管理和包的可见性控制。 6. Moving Toward Bundles：Bundle 是 OSGi 的基本单元，这部分将详细介绍如何创建和配置 Bundle，以及它们在 OSGi 框架中的作用。 7. Managing Bundles and Applications：讲解如何管理和部署 OSGi Bundle，以及如何组织和运行 OSGi 应用程序。 8. Testing Applications：这部分将介绍 OSGi 环境下的测试策略和工具，确保模块化应用程序的可靠性和稳定性。 9. Debugging Applications：针对 OSGi 应用的调试技巧和最佳实践，帮助开发者解决潜在问题。 10. Component Models：讨论 OSGi 如何与现有的组件模型（如 Spring、CDI 等）集成，以实现更丰富的应用架构。 11. Launching and Embedding an OSGi Framework：这部分可能涵盖如何启动和嵌入 OSGi 框架到自定义环境中，以及如何控制框架的行为。 12. Security：讲解 OSGi 的安全模型，如何保护服务和资源，以及如何实施细粒度的权限控制。 13. Web Applications and Services：最后，书中的内容可能涉及 OSGi 在构建和部署 Web 应用和服务中的应用，包括 RESTful API 和 WebSocket 等技术的集成。这本 Osgi_in_Action 书籍全面覆盖了 OSGi 技术的各个方面，对于想要理解和掌握 OSGi 的开发者来说是一份宝贵的资源。通过阅读这本书，读者可以学习到如何利用 OSGi 提升软件的可维护性和可扩展性，以及如何在实际项目中有效地运用 OSGi 技术。

Perhaps you want to create a module that performs some initialization task, such as

starting a background thread or initializing a driver; the lifecycle layer makes this possible.

Bundles may declare a given class as an “activator,” which is the bundle's hook into its own

lifecycle management. We will discuss the full lifecycle of a bundle later in chapter [ref ch3],

but first let's look at a simple example to give you an idea of what we are talking about. In

Listing 1.1.3, we extend our previous Greeting class to provide a singleton instance.

Listing 1.1.3 Extended greeting implementation

package org.foo.hello;

public class Greeting {

static Greeting instance; #A

final String m_name;

Greeting(String name) { #B

m_name = name;

}

public static Greeting get() { #C

return instance;

}

public void sayHello() {

System.out.println("Hello, " + m_name + "!");

}

#A singleton instance to be managed

#B constructor is now package private

#C clients can only use the singleton

Listing 1.1.4 implements a bundle activator that initializes the Greeting class singleton

when the bundle is started and clears it when it is stopped. The client can now use the pre-

configured singleton instead of creating its own instance.

Listing 1.1.4 OSGi bundle activator

package org.foo.hello;

import org.osgi.framework.BundleActivator;

import org.osgi.framework.BundleContext;

public class Activator implements BundleActivator { #A

public void start(BundleContext ctx) { #B

Greeting.instance = new Greeting("lifecycle");

}

public void stop(BundleContext ctx) { #C

Greeting.instance = null;

}

©Manning Publications Co. Please post comments or corrections to the Author Online forum:

http://www.manning-sandbox.com/forum.jspa?forumID=507

You can see at #A that a bundle activator must implement a simple OSGi interface, which

comprises the two methods depicted at #B and #C. At execution time, the framework will

construct an instance of this class and invoke the start() method when the bundle is

started and the stop() method when the bundle is stopped. What we precisely mean by

“starting” or “stopping” a bundle will become clearer in chapter [ref ch3]. Because the

framework uses the same activator instance while the bundle is active, you can share

member variables between the start() and stop() methods.

The inquisitive among you might be wondering what the single parameter of type

BundleContext in the start() and stop() methods is all about. This is how the bundle

gets access to the OSGi framework in which it is executing. From this context object, the

module has access to all of the OSGi functionality for modularity, lifecycle, and services. In

short, it is a fairly important object for most bundles, but we will defer a detailed introduction

of it until later when we discuss the lifecycle layer. The important point to take away from

this example is that bundles have a simple way to hook into their overall lifecycle and gain

access to the underlying OSGi framework.

Of course, it is not sufficient to just create this bundle activator implementation, you

actually have to tell the framework about it. Luckily, this is quite simple. If you have an

existing JAR file you are converting to be a module, then you must add the activator

implementation to the existing project so the class is included in the resulting JAR file. If you

are creating a bundle from scratch, then you just need to compile the class and put the

result in a JAR file. You also need to tell the OSGi framework about the bundle activator by

adding another piece of metadata to the JAR file manifest. For our example, we would add

the following metadata to the JAR manifest:

Bundle-Activator: org.foo.hello.Activator

Import-Package: org.osgi.framework

Notice we also need to import the org.osgi.framework package, since our bundle

activator has a dependency on it. Otherwise, it is pretty simple to make bundles lifecycle

aware. To see this example in action, go into the greeting-example/lifecycle/

directory for Chapter 1 in the accompanying code and type “ant” to build it and “java

-jar main.jar” to run it.

We've now introduced how to create OSGi bundles out of your existing JAR files using the

modularity layer and how to make your bundles lifecycle aware so that they can leverage

framework functionality. The last example in this section demonstrates the service-oriented

application programming approach promoted by OSGi.

1.3.3 Service layer

If you follow an interfaced-based approach in your development, the OSGi service approach

will feel quite natural to you. To illustrate, consider the Greeting interface depicted below:

package org.foo.hello;

public interface Greeting {

void sayHello();

©Manning Publications Co. Please post comments or corrections to the Author Online forum:

http://www.manning-sandbox.com/forum.jspa?forumID=507

}

For any given implementation of the Greeting interface, when the sayHello() method

is invoked a greeting will be displayed. In general, a service represents a contract between a

provider and prospective clients; the semantics of the contract are typically described in a

separate, human readable document, like a specification. The service interface above

represents the syntactic contract of all Greeting implementations. The notion of a contract

is necessary so that clients can be assured of getting the functionality they expect when

using a Greeting service. The precise details of how any given Greeting implementation

performs its task is not known to the client. For example, one implementation may print its

greeting textually, while another may display its greeting in a GUI dialog box. The code in

Listing 1.1.5 depicts a simple text-based implementation.

Listing 1.1.5 Greeting implementation

package org.foo.hello.impl;

import org.foo.hello.Greeting;

public class GreetingImpl implements Greeting {

final String m_name;

GreetingImpl(String name) {

m_name = name;

}

public void sayHello() {

System.out.println("Hello, " + m_name + "!");

}

Your might be thinking that nothing in the service interface or Listing 1.1.5 indicate we

are defining an OSGi service. Well, you'd be correct. That's what makes the OSGi's service

approach so natural if you are already following an interface-based approach, since your

code will largely stay the same. There are two places where your development will be a little

different. One is how you make a service instance available to the rest of your application

and the other is how the rest of your application discovers the available service.

All service implementations will ultimately be packaged into a bundle and that bundle will

need to be lifecycle aware in order to register the service; this means that we need to create

a bundle activator for our example service as depicted in Listing 1.1.6.

Listing 1.1.6 OSGi bundle activator with service registration

package org.foo.hello.impl;

import org.foo.hello.Greeting;

import org.osgi.framework.BundleActivator;

import org.osgi.framework.BundleContext;

public class Activator implements BundleActivator {

©Manning Publications Co. Please post comments or corrections to the Author Online forum:

http://www.manning-sandbox.com/forum.jspa?forumID=507

public void start(BundleContext ctx) { #A

ctx.registerService(Greeting.class.getName(),

new GreetingImpl("service"), null);

}

public void stop(BundleContext ctx) {} #B

}

This time in the start() method at #A, instead of storing the Greeting

implementation as a singleton, we use the provided bundle context to register it as a service

with the service registry. The first parameter we need to provide is the interface name(s)

that the service implements, followed by the actual service instance, and finally the service

properties. In the stop() method at #B we could unregister the service implementation

before stopping the bundle, but in practice you don't need to do this. The OSGi framework

will automatically unregister any registered services when a bundle stops.

We've seen how to register a service, but what about discovering a service? Listing 1.1.7

shows a very simplistic client, which does not handle missing services and suffers from

potential race conditions. A more robust way to access services will be discussed in chapter

[ref ch4].

Listing 1.1.7 OSGi bundle activator with service discovery

package org.foo.hello.client;

import org.foo.hello.Greeting;

import org.osgi.framework.*;

public class Client implements BundleActivator {

public void start(BundleContext ctx) {

ServiceReference ref =

ctx.getServiceReference(Greeting.class.getName()); #A

((Greeting) ctx.getService(ref)).sayHello(); #B

}

public void stop(BundleContext ctx) {}

}

The first thing you'll notice is that accessing a service in OSGi is a two-step process. First

at #A, a indirect reference is retrieved from the service registry, which points to the earliest

active service that was registered under the given interface name. Second at #B, this

indirect reference is used to access the actual service object instance. The service reference

can safely be stored in a member variable, but in general you should never store service

object instances since this will make your application less dynamic and stop bundles from

being cleanly uninstalled. We say “in general” since there are certain advanced use cases

discussed in later chapters [ref xx] where you may wish to store a reference to a service. But

http://www.manning-sandbox.com/forum.jspa?forumID=507

in these situations you must be very careful to de-reference the service when the OSGi

framework tells you it is no longer valid.

Also note that the client code only needs to declare an import for the Greeting

interface, it has no direct or explicit dependency on the actual service implementation(s).

This makes it very easy to swap services dynamically without restarting the client bundle.

Both the service implementation and client should be packaged into separate bundle JAR

files. Each bundle will name an activator in their respective bundle metadata, but only the

service implementation will export the org.foo.hello package, whereas the client will

import it. To see this example in action, go into the greeting-example/service/

directory for Chapter 1 in the accompanying code and type “ant” to build it and “java

-jar main.jar” to run it.

Now that we have seen some examples, it is possible for us to better understand how

each layer of the OSGi framework builds on the previous one. Each layer gives you additional

capabilities when building your application, but OSGi technology is flexible enough for you to

adopt it according to your specific needs. If you only want better modularity in your project,

then use the modularity layer. If you want a way to initialize your modules and interact with

the modularity layer, then use both the modularity and lifecycle layer. If you want a dynamic,

interface-based development approach, then use all three layers. The choice is yours.

1.3.4 Setting the stage

To help introduce the concepts of each layer in the OSGi framework in the next three

chapters, we will use a simple paint program, whose user interface is depicted in Figure

1.1.7. The paint program is not intended to be independently useful; rather, it is used to

demonstrate common issues and best practices. From a functionality perspective, the paint

program only allows the user to paint various shapes, such as a circles, squares, and

triangles. The shapes are painted in predefined colors. Available shapes are displayed as

buttons in the main window's toolbar. To draw a shape, the user selects it in the toolbar and

then clicks anywhere in the canvas to draw it. The same shape can be drawn repeatedly by

clicking in the canvas numerous times. The user can drag drawn shapes to reposition them.

This sounds simple enough. The value of using a visual program for demonstrating these

concepts will become evident when we start introducing run-time dynamism.

We have finished our overview of the OSGi framework and are ready to delve into the

details, but before we do let's try to put OSGi in context by discussing similar or related

technologies. While no Java technology fills the exact same niche as OSGi, there are several

treading similar ground, so it is worth understanding their relevance before moving forward.

http://www.manning-sandbox.com/forum.jspa?forumID=507

剩余508页未读，继续阅读

hwhoho2010

粉丝: 23
资源: 18

OSGi实战：探索Java模块化框架

OSGi原理与最佳实践(完整版)&OSGi_in_action

enterprise_osgi_in_action

OSGI.rar_OSGI eclipse_eclipse osgi_java OSGI_osgi

Manning.OSGi.in.Action.Jul.2010.MEAP.rar

探索Java模块化开发：OSGI in Action实战指南

OSGI-ROOT.rar

spring integration in action

构建模块化Java应用：OSGi实战英文全版

创建模块化Java应用：OSGi实战

Junit实战第二版 中文完整版.pdf

最新资源

Junit实战第二版中文完整版.pdf