Spring Integration深度实践

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

"Spring Integration In Action.pdf 是一本关于Spring Integration技术的书籍，由Manning Publications出版，通过Manning Early Access Program (MEAP) 提供。该书涵盖了Spring Integration的多个方面，旨在帮助读者理解并应用Spring Integration进行企业级系统集成。书中详细介绍了Spring Integration的核心概念、消息处理、系统集成策略以及高级主题，包括监控、管理、并发控制、Web服务等。" 详细内容: Spring Integration是Spring框架的一个扩展，专注于简化企业级应用间的通信和集成。这本书"Spring Integration In Action"分为四个部分，全面讲解了这一强大的工具。 1. **背景介绍**：这部分提供了Spring Integration的基本概念和它在企业集成中的作用。作者将引导读者了解为什么需要Spring Integration，以及它如何解决传统集成中的复杂性问题。 2. **企业集成基础**：第二部分深入探讨企业集成的基础知识，解释了集成模式和设计原则，为后续章节打下坚实基础。 3. **消息处理**： - **消息与通道**：第三章详细阐述了Spring Integration中的消息和通道模型，这是Spring Integration的核心，允许应用通过消息传递进行解耦通信。 - **消息端点**：第四章讲解了如何定义和配置消息端点，这些端点可以处理消息的接收和发送。 - **业务处理**：第五章介绍了如何实现实际的业务逻辑，包括消息的转换和处理。 - **路由与过滤**：第六章则探讨了如何根据特定条件对消息进行路由和过滤，实现非线性的流程控制。 4. **系统集成**： - **消息拆分与聚合**：第七章展示了如何拆分大型消息以及聚合响应，以处理复杂的集成场景。 - **XML消息处理**：第八章讨论了处理XML负载的消息，这对于企业集成中的数据交换至关重要。 - **JMS集成**：第九章介绍了Spring Integration与Java Message Service (JMS) 的整合，以支持异步和可靠的通信。 - **邮件集成**：第十章讲解了发送和接收邮件的功能，使得系统能够自动处理电子邮件。 - **文件系统集成**：第十一章介绍了如何与文件系统交互，如文件上传下载、监控文件夹变动等。 - **Web服务**：第十二章探讨了Spring Integration在Web服务集成中的应用，包括SOAP和REST服务。 5. **高级话题**： - **监控与管理**：第十三章讲解了如何监控和管理Spring Integration应用程序，确保系统的稳定性和性能。 - **调度与并发**：第十四章涵盖了调度任务和并发控制，以优化系统资源利用。 - **丰富的Web集成**：第十五章介绍了Spring Integration与现代Web应用的结合，包括Web插座和Ajax支持。 - **消息与批处理**：第十六章讨论了如何将Spring Integration应用于批量操作，提高处理效率。 - **OSGi和AMQP扩展**：第十七章介绍了如何利用OSGi和Advanced Message Queuing Protocol (AMQP) 来扩展和扩展Spring Integration的应用场景，以适应大规模和分布式系统。 18. **实践应用**：最后一章"Putting your Spring Integration to work"提供了一些实战案例，帮助读者将理论知识应用到实际项目中。通过这本全面的指南，读者不仅可以掌握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页未读，继续阅读

luxas

粉丝: 0
资源: 23

Spring Integration深度实践

spring_integration_in_action.pdf

Spring in Action 3rd Edition.pdf

Spring.Boot.in.Action.2015.12.pdf

Spring_in_Action.pdf

Manning - Eclipse In Action.pdf

MyEclipse开发Struts+Spring+Hibernate入门.pdf

Manning.Spring.Batch.in.Action.Oct.2011

Activiti-in-Action.pdf

struts-spring-hibernate-_-integration-2.zip_spring pdf_struts+hi

Spring Batch in Action英文pdf版

最新资源