2.3 Main Components
From the vertical perspective(从纵向角度来看), a layered architecture facilitates separation of concerns(一个分层的体系结构，有利于分离组件), and interface-based contracts between layers promote loose coupling(解耦). Spring-based applications are typically designed this way, and the Spring framework and portfolio provide a strong foundation for following this best practice for the full-stack of an enterprise application. Message-driven architectures add a horizontal perspective, yet these same goals are still relevant. Just as "layered architecture" is an extremely generic and abstract paradigm, messaging systems typically follow the similarly abstract "pipes-and-filters"（管道过滤体系） model. The "filters" represent（代表） any component that is capable of producing and/or consuming messages, and the "pipes"（管道） transport（传输） the messages between filters so that the components themselves remain loosely-coupled（解耦）. It is important to note that these two high-level paradigms are not mutually exclusive（互相排斥）. The underlying messaging infrastructure that supports the "pipes" should still be encapsulated （封装） in a layer whose contracts are defined as interfaces. Likewise, the "filters" themselves would typically be managed within a layer that is logically above the application's service layer, interacting with those services through interfaces much in the same way that a web-tier would.
(PS:从纵向角度来看：一个分层清晰的框架体系，更加有利层间的解耦。这是典型的Spring框架系列所遵从的原则。 Spring框架组合为实现full-stack模式的企业集成提供了坚实的基础与良好的实践。 通过消息驱动框架提供的横向透视图，也实现了同样的目标与原则，正如“分层结构”是一个非常通用的和抽象的范式， 通讯系统通常遵循同样抽象的“管道和过滤器”模型，其中“Filter”代表这样一种组件：该组件介于具有生产、消费消息以及 与管道传输消息的中间层，他实现了两者之间的解耦。他们之间并不存在互斥的行为，底层消息传输体系依然是通过既定的 接口封装来支持“pipes”，同样，"filters" 自身受制于应用层之上的逻辑层。通过接口实现业务数据传输的网络传输层。 )
2.3.1 Message
In Spring Integration, a Message is a generic wrapper for any Java object combined with metadata used by the framework while handling that object. It consists of a payload （有效负载） and headers（消息头）. The payload can be of any type and the headers hold commonly required information such as id, timestamp, correlation id, and return address. Headers are also used for passing values to and from connected transports. For example, when creating a Message from a received File, the file name may be stored in a header to be accessed by downstream components. Likewise, if a Message's content is ultimately（最终） going to be sent by an outbound Mail adapter, the various properties (to, from, cc, subject, etc.) may be configured as Message header values by an upstream component. Developers can also store any arbitrary key-value pairs in the headers.
(PS:在Spring Integration框架中，消息是一个很重要的组件，他是包含有元数据的普通的Java 对象。他由消息头与有效负载组成 。其中有效负载可以是任何类型的数据。而消息头定义了传输的一些公用信息，例如消息ID，时间戳、返回地址、相关ID 。同样，消息头也常被用来传输一些数据。例如，文件名称可以被存储在消息头中被下游的组件所访问。 同样，消息内容最终将被发送到外部的邮件适配器，很多属性（来自、抄送、主题等）同样可以定义在消息头中被上游的组件。 开发者存储这些信息是采用 key-value 的模式进行存储的。)
2.3.2 Message Channel
A Message Channel represents（代表、充当） the "pipe" of a pipes-and-filters architecture. Producers send Messages to a channel, and consumers receive Messages from a channel. The Message Channel therefore decouples（解耦） the messaging components, and also provides a convenient point for interception（拦截） and monitoring（监控） of Messages.
(PS:消息通道，充当“pipes-and-filters”体系中的"pipe"角色。生产者发送一个消息到通道，消费者从通道中 获取消息。消息通道仍然是解耦的消息传输组件。该组件一系列例如拦截、监控等特性。 )
A Message Channel may follow either Point-to-Point or Publish/Subscribe semantics. With a Point-to-Point channel, at most one consumer can receive each Message sent to the channel. Publish/Subscribe channels, on the other hand, will attempt to broadcast each Message to all of its subscribers. Spring Integration supports both of these.
（PS：消息通道支持 点对点 与 广播/订阅两种模式，对于点对点模式的通道，通道中的发送的消息只能被一个消费者持有。 而广播/订阅通道则不同，它尝试把消息传输给每一个订阅者，Spring Integration对这两种模式都提供了很好的支持）
Whereas "Point-to-Point" and "Publish/Subscribe" define the two options for how many consumers will ultimately receive each Message, there is another important consideration（考虑，思考）: should the channel buffer messages? In Spring Integration, Pollable（可 轮询） Channels are capable of buffering Messages within a queue. The advantage of buffering is that it allows for throttling（节流） the inbound Messages and thereby prevents（防止） overloading（过载） a consumer. However, as the name suggests, this also adds some complexity, since a consumer can only receive the Messages from such a channel if a poller is configured. On the other hand, a consumer connected to a Subscribable Channel is simply Message-driven. The variety（种类） of channel implementations available in Spring Integration will be discussed in detail in Section 3.1.2, “Message Channel Implementations”.
(PS:实际上 点对点 以及 广播/订阅 定义了到底有多少个消费者能从通道中获取一个消息的策略。从而引发另外一个 值得思考的问题，通道是否支持缓存消息呢？在Spring Integration，一种支持轮询机制的通道实现具有缓存消息 的特性。该特性的引入主要是为了节流内部消息向外输出以及防止外部的消息对内部系统造成过载。从“轮询”字面定义可以猜到： 该通道增加了配置复杂性，理由是通过轮询消费者每次仅能获取一条消息。另外一种订阅通道者相反， 消费者连接该通道是基于简单的 消息驱动 模式。Integration 提供了这对两种模式多种实现，从而应用到不同的场景中。 这些会在之后的章节中逐一进行展开描述。)
2.3.3 Message Endpoint消息终端
One of the primary goals（一个很重要的目标） of Spring Integration is to simplify the development of enterprise integration solutions（解决方案） through inversion of control（反转控制）. This means that you should not have to implement consumers and producers directly, and you should not even have to build Messages and invoke send or receive operations on a Message Channel. Instead（相反）, you should be able to focus on your specific domain model with an implementation based on plain Objects. Then, by providing declarative configuration, you can "connect" your domain-specific（特定领域的，这里可理解为业务逻辑） code to the messaging infrastructure provided by Spring Integration. The components responsible（有责任） for these connections are Message Endpoints. This does not mean that you will necessarily connect your existing application code directly. Any real-world enterprise integration solution will require some amount of code focused upon integration concerns such as routing and transformation. The important thing is to achieve（实现） separation of concerns between such integration logic and business logic. In other words, as with the Model-View-Controller paradigm for web applications, the goal should be to provide a thin but dedicated layer that translates inbound requests into service layer invocations, and then translates service layer return values into outbound replies. The next section will provide an overview of the Message Endpoint types that handle these responsibilities, and in upcoming chapters, you will see how Spring Integration's declarative configuration options provide a non-invasive way to use each of these.
(PS:一个很重要的目标对于Spring Integration而言，就是利用Spring框架的反转控制提供一个轻量级的企业集成解决方案。 这意味者作为开发人员无需关注生产者与消费者，甚至无需关注消息的创建以及首发等细节。相反，开发者应该重点 关注如何简单实现业务逻辑本身，然后，通过声明式配置，可以把你的业务逻辑与Spring Integration进行无缝集成。 实现这种连接的责任就是 Message Endpoints 所要完成的工作。但是者并不意味着着你可以直接去使用它们。在一个 现实的企业集成场景下，需要大量不同功能的模块实现不同的功能点，例如路由功能、协议转换功能等。 还有一个需要重点指出的就是：他实现业务逻辑与集成逻辑的分离解耦。这个类似与大家熟知的MVC模式。 ........ 下面就是对MVC的描述 自己阅读吧 呵呵~~~~~)