深入实践Spring Integration：企业级集成指南

5星 · 超过95%的资源需积分: 9 80 浏览量更新于2024-07-28 1 收藏 5.09MB PDF 举报

"Spring Integration in Action 是一本关于Spring Integration的专著，涵盖了企业集成的基础、消息处理、系统集成以及高级主题。这本书分为四个部分，详细介绍了Spring Integration在不同场景下的应用和技术细节。" 《Spring Integration in Action》是针对Spring Integration框架的一本实战型指南，旨在帮助读者理解和应用这个强大的集成工具。书中内容丰富，结构清晰，分为四个主要部分：第一部分 - 背景介绍 1. 引言到Spring Integration：这一章为读者提供了Spring Integration的基本概念和背景，解释了它为何在企业级应用集成中扮演重要角色。 2. 企业集成基础：深入讨论了企业系统集成的原理和模式，为后续章节奠定了理论基础。第二部分 - 消息处理 3. 消息与通道：详细阐述了Spring Integration中的消息模型和通道概念，如何通过它们进行数据传输。 4. 消息端点：介绍了消息的消费和生产者，包括不同的消息处理端点如Service Activator、Gateway等。 5. 进行业务操作：讲解如何利用Spring Integration实现实际业务逻辑。 6. 路由与过滤：扩展了消息处理能力，讨论了如何实现非顺序处理，包括消息路由和过滤策略。第三部分 - 系统集成 7. 消息拆分与聚合：展示了如何处理复杂的消息流，包括如何拆分和聚合消息。 8. 处理XML载荷消息：重点介绍了XML在Spring Integration中的处理，可能涉及到XML解析和转换。 9. Spring Integration与JMS：探讨了Spring Integration如何与Java消息服务（JMS）集成，实现异步通信。 10. 发送与接收邮件：展示了如何利用Spring Integration进行邮件的发送和接收。 11. 文件系统集成：讨论了与文件系统的交互，如文件的上传、下载、监控等。 12. Web服务：涵盖了如何利用Spring Integration处理Web服务的调用和响应。第四部分 - 高级主题 13. 监控与管理：讨论了如何监控和管理Spring Integration应用，确保系统的稳定性和性能。 14. 调度与并发控制：讲述了如何在Spring Integration中管理和调度任务，以及并发执行的策略。 15. Spring Integration与富Web应用：探讨了Spring Integration在构建富互联网应用中的应用。 16. 消息与批量操作：结合消息处理与批处理操作，提供更高效的数据处理方式。 17. 使用OSGi和AMQP扩展消息应用：讨论了如何利用OSGi模块化和AMQP协议来扩展和优化消息应用程序的可伸缩性。 18. 测试你的管道：介绍测试策略和方法，确保Spring Integration配置的正确性和可靠性。通过这些章节，读者可以逐步掌握Spring Integration的精髓，从而在实际项目中有效地集成和管理各个系统组件，提高企业的系统互操作性和灵活性。

Service service = new MySpecificServiceImplementation();

Now the code is tightly coupled directly to an implementation type. Sure that

implementation is being assigned to an interface, and hopefully the caller is never

required to downcast. However, no matter how you slice it, the code is tied to an

implementation, and that is a result of a very simple fact: interfaces are only

contracts and are separate from the implementations. An implementation type must

be chosen for instantiation, and the simplest means of instantiating objects in Java

is calling a constructor.

There is another option, and it often follows as a seemingly logical conclusion

to the problem above. After recognizing that the implementation type leaked into

the caller's code, even though that code really only needs the interface, a Factory

can be added to provide a level of indirection. Rather than constructing the object,

the caller can ask for it:

Service service = factory.createTheServiceForMe();

This is actually the first step down the road of Inversion of Control. The factory

is handling a responsibility that was previously handled directly in the caller's

code. The control has been inverted in favor of a Factory. The caller gladly

relinquishes that control in return for having to make fewer assumptions about the

implementation it is using. This seems to solve the problems at first, but to some

degree it's just pushing the problem one step further away. It is the programmatic

equivalent of sweeping dirt under the rug.

A better solution would remove all custom infrastructure code, like the factory

above. That final step to the full inversion of control is to simply define a

constructor or setter method. In effect, that declares the dependency without any

assumptions about who is responsible for instantiating or locating it.

public class Caller {

private Service service; // an interface

public void setService(Service service) {

this.service = service;

}

...

}

In a unit test that focuses on this single component, it is trivial to provide a stub

or mock implementation of the dependency directly. Then, in a fully integrated

system where there may be many components sharing dependencies as well as

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

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

Licensed to Roger Studner <rstudner@gmail.com>

complex transitive dependency chains, a framework such as Spring can handle the

responsibility. All you need to do is provide the implementation type as metadata.

Rather than being hard-coded as in our first example above, there is now a very

clear separation of code and configuration[5].

</bean>

The Spring Integration framework takes advantage of this same technique to

manage dependencies for its components. In fact, you can use the same syntax to

define the individual "bean" definitions, but for convenience custom XML

schemas have been defined so that you can declare a namespace[6] and then use

elements and attributes whose names match the domain. The domain in this case is

that of the enterprise integration patterns so the element and attribute names will

match those components described in the previous section. For example, any

Spring Integration Message Endpoint requires a reference to at least one Message

Channel (determined by its role as producer, consumer, or both). Here is an

example of a simple Message Splitter.

Another common case for dependency injection is when a particular

implementation of a strategy interface[7] needs to be wired into the component that

delegates to that strategy. For example, here is a Message Aggregator with a

custom strategy for determining when the processed items received qualify as a

complete order.

<aggregator input-channel="processedItems"

completion-strategy="orderCompletionChecker"

output-channel="processedOrders"/>

Don't worry about understanding the details of the above examples yet. There

will be much more coverage of these components throughout the book. The only

point we are trying to make so far is that dependency injection plays a role in

connecting the collaborating components while avoiding hard-coded references.

Method Invocation

Inversion of Control is often described as following the Hollywood Principle

which states "Don't call us, we'll call you"[8]. From the description of dependency

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

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

Licensed to Roger Studner <rstudner@gmail.com>

injection above, you can see how well this does apply. Rather than writing code

that calls a constructor or even a factory method, we can rely on the framework to

provide that dependency by calling our constructor or setter methods for us. This

same principle can also apply to method invocation at runtime.

Let's first consider the Spring Framework's support for asynchronous reception

of JMS Messages. Prior to Spring 2.0, the only support for receiving JMS

messages within Spring was the synchronous (blocking) receive() method on its

JmsTemplate. That works fine when you want to control polling of a JMS

Destination, but when working with JMS, the code that handles incoming

Messages can usually be reactive rather than proactive. In fact, the JMS API

defines a simple MessageListener interface, and the EJB 2.1 specification

introduced Message Driven Beans as a component model for hosting such listeners

within an Application Server. With version 2.0, Spring introduced its own

MessageListener containers as a lightweight alternative.

MessageListeners can be configured and deployed within a Spring application

running in any environment instead of requiring an EJB container. As with

Message Driven Beans, a listener is registered with a certain JMS Destination, but

with Spring, the listener's container is just a simple object that is itself managed by

Spring. There is even a dedicated XML namespace.

<jms:message-listener-container>

<jms:listener destination="someDestination" ref="someListener"/>

</jms:message-listener-container>

The container will manage the actual subscription and the background

processes that are ultimately responsible for receiving the Messages. There are a

number of configuration options for controlling the number of concurrent

consumers, managing transactions, and more. We're not going to cover those

details here since we just want to provide the background context for Spring

Integration's similar features.

In the above example, the listener could be any implementation of the JMS

MessageListener interface:

public interface MessageListener {

void onMessage(Message message);

}

Where it gets even more interesting and more relevant for our lead up to Spring

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

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

Licensed to Roger Studner <rstudner@gmail.com>

Integration is when we look at Spring's support for invoking methods on any

Spring-managed object. Sure, the MessageListener interface shown above seems

simple enough, but it has a few limitations. First, it requires a dependency on the

JMS API. This inhibits testing and also pollutes otherwise pure business logic that

we have achieved by relying on the inversion of control principle. Second, and

more severe, it has a void return type. That means that we cannot send a reply

Message from the listener method's implementation. Both of these limitations are

eliminated if we instead reference a POJO instance that does not implement

MessageListener and add the 'method' attribute to the configuration. For example,

let's assume we want to invoke the following service method:

public class QuoteService {

BigDecimal currentQuote(String tickerSymbol) {...}

}

The configuration would look like this:

<jms:message-listener-container>

<jms:listener destination="quoteRequests" ref="quoteService" method="currentQuote"/>

</jms:message-listener-container>

Whatever client is passing request Messages to the 'quoteRequest' destination

could also provide a JMSReplyTo property on that request Message. Spring's

listener container will use that property to send the reply Message to the

destination where the caller is waiting for the response to arrive. Alternatively, a

default reply destination can be provided with another attribute in the XML.

This message-driven support is a good example of Inversion of Control since

the listener-container is handling the background processes. It's also a good

example of the Hollywood Principle since the framework calls the referenced

object whenever a Message arrives.

Another common requirement in enterprise applications is to perform some task

at a certain time or repeatedly based on a configured interval. Java itself provides

some basic support for this with java.util.Timer and beginning with version 5, a

more powerful scheduling abstraction was added:

java.util.concurrent.ScheduledExecutorService. For functionality beyond what the

core language provides, there are projects such as Quartz[9] to support scheduling

based on cron expressions, persistence of job data, and more.

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

Licensed to Roger Studner <rstudner@gmail.com>

Interacting with any of these schedulers normally requires code that is

responsible for defining and registering a task. For example, imagine you have a

method called "poll" in a custom FilePoller class. You might wrap that call in a

Runnable and scheduled it in Java like this:

Listing 1.1 Scheduling a Task programmatically Runnable task = new Runnable() { public void run() { File file =

filePoller.poll(); if (file != null) { fileProcessor.process(file); } } }; long initialDelay = 0; long rate = 60;

ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(5);

scheduler.scheduleAtFixedRate(task, initialDelay, rate, TimeUnit.SECONDS);

The Spring Framework can handle much of that for you. It provides

method-invoking task adapters and support for automatic registration of the tasks.

That means you do not need to add any extra code. Instead you can declaratively

this:

Listing 1.2 Scheduling Tasks declaratively with Spring <task:scheduled-tasks scheduler="myScheduler">

<task:scheduled ref="filePoller" method="poll" fixed-rate="60000"/> </task:scheduled-tasks> <task:scheduler

id="myScheduler" pool-size="5"/>

As you can see, this provides a quite literal example of the Hollywood

Principle. The framework is now calling the code. This provides a few benefits

beyond the obvious one of simplification. First, even though the code being

invoked should be thoroughly unit-tested, you can rest assured that the Spring

scheduling mechanism is tested already. Second, the configuration of the initial

delay and fixed-rate period for the task and the thread pool size for the scheduler

are all externalized. By enforcing this separation of configuration from code, you

are much less likely to end up with hard-coded values in the application. The code

is not only easier to test but also more flexible for deploying into different

environments.

Now let's see how this same principle applies to Spring Integration. The

configuration of scheduled tasks follows the same technique as shown above. The

configuration of a Polling Consumer's trigger can be provided through declarative

configuration. Spring Integration takes the previous example a step further,

however, by actually providing a File polling Channel Adapter:

<file:inbound-channel-adapter directory="/tmp/example" channel="files">

<interval-trigger interval="60" time-unit="SECONDS"/>

</poller>

file:inbound-channel-adapter>

We should also mention that both the core Spring Framework scheduling

support and the Spring Integration polling triggers accept cron expressions in place

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

Licensed to Roger Studner <rstudner@gmail.com>

剩余355页未读，继续阅读

weimid

粉丝: 2
资源: 55

深入实践Spring Integration：企业级集成指南

Spring Integration深度实践

Spring Integration实战指南：Manning出版

Spring Integration实战指南：深度探索与实践

Spring Integration in Action

spring source spring integration in action 随书源码 example code

spring_integration_in_action.pdf

Spring Integration源码

Spring Batch in Action

Spring.Integration.in.Action.Mark.Fisher.文字版

Spring-Integration-in-Action：本书随附的源代码

最新资源