MinaTutorialInChinese

MINA的应用，在MINA的Testimonials中有两个项目：
开源Flash server：red5
http://ludonet.leonardo.it/的game server
还有，就是MINA所在的项目，Apache的LDAP

开发一个基于消息的解决方案是不容易的事情，在生产中操作这样一个产品同样也是一个挑战：一个基于消息的集成解决方案一天可以产生、路由和转换成千上万的消息。我们不得不处理异常、效率瓶颈或改变合作系统。而为了使事情变得更加有挑战性，组件经常被分布在不同的平台和机器上，甚至位于不同的地理位置。

System Management包含以下几种模式

l         Control Bus

l         Detour

l         Wire Tap

l         Message History

l         Message Store      

l         Smart Proxy

l         Test Message

l         Channel Purger

除了与生据来的复杂性、分布式集成的规模以及个性化的应用之外，低耦合的架构使得测试和debug变得更加困难。Martin Fowler将这个症状称为“架构师的梦想，开发者的梦魇”。低耦合的架构原则以及间接的依赖于外部系统提供了灵活性。然而，测试一个消息生产者不了解消息消费者的系统可能会是一个挑战。另外异步的和时间相关的消息使得事情变的更加复杂。举例来说，消息方案可能被设计没有被成消息生产者者必须从接受者那里得到一个回应。同样的消息基础设施通常保证传输消息，但不能保证传输时间。这是的开发基于消息传送结果的测试用例变得困难。

当监控一个消息解决方案，我们可以在两个抽象层面上跟踪消息流。一个典型的系统管理方案监控多少消息被发送或者它多长时间得到一个被处理的消息。这些监控方案不检查消息数据，除了可能会检查消息头中的几个字段（比如消息标识或者消息历史）。与之相对的，BAM（business activity monitoring）方案聚焦于包含在消息中的有效数据，举例来说，发生在过去一小时的所有订单的金额。System Management中的很多模式都足够通用并可以用在以上两个目的中（监控消息头或者消息内容）。然而，由于BAM本身就是一个新领域，并且需要从数据仓库中获得很多数据（有些我们根本就没有涉及到），我们决定在系统管理的内容中讨论这些模式。

系统管理模式被设计用于为保持一个基于消息的复杂系统的运转所提出的需求并提供工具。System Management的模式涉及三个种类：监控和控制，观察和分析消息流量，测试和调试。

监控和控制

一个Control Bus提供一个单独的控制点来对一个分布式方案进行监控和管理。它将多个组件连接到一个中心管理控制台，这里可以显示每个组件的状态并且监控通过每个组件的消息流量。控制台同时也可以用于发送控制命令给组件，比如，转变消息流。

我们可能想要在路由消息时添加附加的步骤，比如验证或者日志。由于这些步骤可能使效率降低，所以我们可以通过Control Bus来控制他们开关。一个Detour为我们提供这种能力。

观察和分析消息流量

有时我们想要在不影响主要消息流的情况下观察消息的内容。一个Wire Tap允许我们接入到消息流中。

当我们调试一个基于消息的系统，知道一个特定的消息在哪使很有帮助的。Message History保留一个消息访问过的所有组件的日志，而不需要增加组件间的依赖。

然而Message History依赖于单独的消息，一个中心的Message Store可以提供一个穿越系统的每个消息的完整记录。结合Message History，Message Store可以分析所有消息穿过系统的可能路径。

Wire Tap, Message History, 和Message Store帮助我们分析异步的消息流。为了跟踪发送到请求-应答service的消息，我们需要在消息流中插入一个Smart Proxy。

测试和调试

在部署前测试一个消息系统是一个非常好的注意。但是测试不应该停止在部署前。你应该有能力验证正在运行的消息系统运行持续的运行正常。你可以周期性的发送一个Test Message到系统中并验证结果。

当一个组件失败或者运行不正常，它可以简单的终止，并放弃一个channel中的剩余消息。在测试期间这是很有用的。一个Channel Purger可以为我们做这些。

l         Messaging Gateway

l         Messaging Mapper

l         Transactional Client

l         Polling Consumer

l         Event-Driven Consumer

l         Competing Consumers

l         Message Dispatcher

l         Selective Consumer

l         Durable Subscriber

l         Idempotent Receiver

l         Service Activator

发送和接收模式

有些endpoint模式既可以使用在发送方也可以使用在接受方。它们描述一个应用连接一个消息系统的一般情况。

包装消息代码 － 一个应用不应该意识到正在使用消息同另外一个应用程序通讯，大多数应用代码应该在不知道message的情况下被编写。在应用集成的地方，应该有一个薄薄的一层代码来执行应用的集成部分。当集成是由消息实现的，这层将应用连接到消息系统的代码称为一个Message Gateway

数据转换 － 当发送者和接受者使用不同的数据格式，或者不同的消息格式（支持不同的发送和接收者），在这种情况下，使用一个Message Mapper来在应用格式和消息格式之间转换数据。

外部控制的事务 － 消息系统在内部和外部使用事务，默认的，每个发送和接收方法在他们自己的事务中运行。Message生产者和消费者应可选的使用一个Transactional Client来控制事务，当你需要将几个消息一起发送伙通过其他事务服务整理消息时是很有用的。

消息消费者模式

其他endpoint模式只适用于消息消费者，发送消息是简单的。棘手的问题是决定一个消息应该何时发送，它应包含什么，以及怎样将它送到接受者 － 这是为什么我们有很多消息结构模式 － 但是一旦消息被构建，发送它是很容易的。另一方面，接收消息 － 很麻烦。因此许多endpoint模式是关于接收消息的。

接收消息的一个最重要的主题就是流量控制：一个应用控制，或者调节它消费消息的速度。一个潜在的问题是任何server都面临着大量的客户端请求会使其超载。通过远程过程调用（RPI），server几乎受到客户端调用的支配。同样的，通过消息，server不能控制客户端发送请求的速度 － 但是server可是控制它处理这些请求的速度。应用不必像消息系统传送消息那么快的接收并处理消息；使用一个Message Channel可以使它在一个可接收的速率上处理消息。然而，当消息积累太多，而server还有资源可以处理的更快，它可以使用同步message消费者来加快速度。所以使用这些消息消费者模式可以让你的应用将速度控制在它可以承受的范围。

许多消息消费者模式都是成对出现的，你可以任选一个使用。

同步或异步接受者 － 可以使用轮询消费者或一个事件驱动消费者。轮询提供最好的流量控制，因为如果server忙，则它不再继续轮询消息，所以message将阻塞在队列。事件驱动的消费者倾向于消息到达便触发处理，所以有可能会使server超载，但是每个消费者每次只处理一个消息，所以限制消费者的数量可以有效的控制消费速度。

消息分派 vs 消息获取 － 另外一个二选一的模式是一堆消费者如何处理一堆消息。如果每个消费者获得一个消息，他们可以并行的处理消息。最简单的方法是Competing Consumers，也就是一个点对点的channel有多个消费者。每个都可能获得任何消息；消息系统的实现决定那个消费者获得消息。如果你想控制消息到消费者的匹配过程，使用Message Dispatcher。这时只有一个消费者接收消息，但是将委派消息到一个执行者去处理。一个应用程序可以通过限制消费者或执行者的数量来控制流量。当然，分派者Message Dispatcher也可以实现一个流量控制行为。

接收所有消息或者过滤 － 默认的，任何到达一个Message Channel的消息对于监听着这个channel的Message Endpoint都是可用的。然而有些消费者并不打算处理channel上的任何消息，而是希望只处理其中几种。这样一个识别的消费者可以使用一个Selective Consumer来描述它将接收什么类型的消息。然后消息系统将只将匹配的消息对该接受者描述为可用。

当断开连接的时候订阅消息 － Publish-Subscribe Channels带来的问题是，如果一个消费者感兴趣一个channel，但是现在网络是断开的怎么办？是不是一个未连接的应用将错过发布的消息，即使它已经订阅过该消息?默认的，是的，订阅只对连接的订阅者有效，为了使应用不会因为连接而错过订阅的消息，要使用Durable Subscriber。

等幂 － 有时一个消息可能被传输不只一次，可能因为消息系统不确定该消息是否已经被成功的传递过，或者可能因为Message Channel的QoS被设置较低来提高效率。另一面的，消息接受者认为每个消息只会被传输一次，并且当它们重复处理相同的消息，它们会出错。一个Idempotent Receiver可以优雅的处理重复的消息，并且阻止它们引起接收者应用的发生错误。

同步或异步服务 － 另外一个选择是一个应用应该暴露它的service为同步（RPI）还是异步的（Messaging）。不同的客户端可能喜欢不同的方式；不同的环境可能需要不同的方式。既然很难选择，就一起使用。一个Service Activator连接一个Message Channel到一个应用的同步服务以便当一个消息被接收，service就被调用。同步客户端可以简单的直接调用service；异步客户端可以通过发送消息调用service。

Message Endpoint的相关主题

Message Endpoint的另外一个重要主题是很难同其他模式共同应用Transactional Client。Event-Driven Consumer通常不能适当的在外部控制事务，Message Dispatcher也必须小心的设计这个问题，Competing Consumers的事务也是个重大问题。最安全的使用Transactional Client是使用一个单独的Polling Consumer，但是这不会是一个令人满意的解决方案。

这里特别要提到应该会保证成功的JMS风格的MDB，EJB的一种。一个MDB是一个消息消费者，它即使一个Event-Driven Consumer又是一个支持J2EE分布式事务的Transactional Client，并且它可以作为Competing Consumers动态的池化，甚至作为一个Publish-Subscribe Channel。这是在一个自由的应用中实现这些是一个困难且乏味的组合，但是这个功能作为一个EJB容器的内建的功能被提供。（MDB框架如何实现的？本质上，容器通过一个动态改变大小的可重用的执行者的线程池来实现了一个Message Dispatcher，在那里每个执行者自己使用自己的session和事务来消费消息。）

最后，紧记一个单独的Message Endpoint可以很好结合几个不同的模式。一组Competing Consumers可以被作为Polling Consumers实现，同时也可以是一个Selective Consumers并且可以作为一个Service Activator调用一个应用的service。

一个Message Dispatcher可以是一个Event-Driven Consumer和一个使用Messaging Mapper的一个Durable Subscriber。无论一个endpoint实现什么模式，它总是一个Messaging Gateway。所以，不要考虑使用哪种模式 － 而要考虑如何结合他们。这是使用模式解决问题的魅力所在。

要实现一个Message Endpoint有很多选择。Message Endpoint模式用于解释这些选择是什么以及如何最好的使用它们。

通常，通过消息系统集成的应用很少有同样的消息格式。比如说，一个帐务系统同一个CRM系统对客户对象是有着不同的概念的。基于这个，一个系统可能将消息存储在关系表中，另一个可能存储在文件中。集成已存在的系统通常意味着我们没有修改系统以便使他们更好的一起工作的自由。然而，集成方案不得不协调和解决各种系统之间的不同。Message Translator模式提供了一个通用的解决方案。这里解释几种特定的Message Translator。

Message Transformation包含以下几种模式：

l         Envelope Wrapper

l         Content Enricher

l         Content Filter

l         Claim Check

l         Normalizer

l         Canonical Data Model

大多数消息系统放置特定的需求在消息头的格式和内容中。我们包装有效数据到一个Envelope Wrapper中以适应消息基础设施的需求。如果消息需要穿过不同的消息基础设施，可以结合多个Envelope Wrapper。

如果原始系统不能提供目标系统需要的数据域，可以使用一个Content Enricher。它可以查找缺少的信息并从已有数据中计算出它。Content Filter正好相反，它从消息中删除不需要的数据。Claim Check也从消息中删除数据，但是它将存储他们以便以后取回。Normalizer将多个不同格式的消息翻译成统一格式。

消除依赖

消息转换在集成中是一个很深的话题。Message Channels和Message Routers可以通过消除应用必须知道另外一个应用的位置的需求从而解除应用间的基本依赖。

一个应用可以发送一个消息到Message Channel而不必担心谁来取出消息。然而消息格式增加了另外一种依赖。如果一个应用不得不将消息格式化成另外一个应用的数据格式，通过Message Channel解耦的说法就像一个幻想。接收系统的任何改变或切换到另外一个接收系统都需要对发送应用进行改变。Message Translators可以帮助除去这种依赖。

元数据管理

将消息从一个消息格式转换到另一个格式需要操作元数据 － 描述数据格式的数据。

元数据在两个并行系统之间的集成中扮演着非常重要的角色。一个处理实际的消息数据，另外一个处理元数据。许多用于处理消息数据的模式也同样可以管理元数据。比如说，Channel Adapter不仅可以从一个系统中移进和移出消息，还可以从一个外部应用中获取元数据，并将其加载到一个元数据仓库中。使用这个仓库，集成开发者可以定义应用元数据与Canonical Data Model.之间的转换。

元数据集成

举例来说，上面的图描述了两个需要交换客户信息的应用的集成。每个系统的客户数据的定义稍有不同。从A到B的消息需要转换一下才能被B接收。如果Channel Adapters可以抽取元数据的话，创建一个转换将非常简单。然后这个元数据可以被放入一个仓库，大大的简化了Message Translator的配置和验证。元数据可以被存储成不同的格式。通常XML消息使用XSD格式。其他EAI工具实现所有元数据格式，但是允许管理员导入或导出到其他格式。

消息系统外的数据转换

这些转换模式组成的很多原则可以被应用于非消息集成。比如说，File Transfer可以执行系统间的转换工作。类似的，Remote Procedure Invocation必须使请求使用要调用的service的格式，即使应用本身的格式可能不同。典型的，需要调用程序来执行转换。一些最成熟的转换引擎组成了ETL工具，比如Informatica或者DataMirror。这些工具一般都一次转换大量的数据，而不是转换单个消息。

Message System应专注于几种基本的Message Translator模式。而不应该关心实体间结构转换的细节（不同的数据模型之间的转换，比如ER模型不支持多对多关系而其他的支持这种）。关于这个主题最老也使最相关的书是Kent的《Data and Reality》。

在前面的关键组件中我们提到了Messages。当两个应用想要交换数据，他们将数据包装在一个message中。但是一个Message Channel不能传输原始数据，它只能传输包含在一个message中的数据（即传输特定格式的数据）。

Message在消息系统中处于信息载体的位置，而在ESB中，还消息识别、序列以及生存周期等职责。

Message的结构涉及以下几个模式：

l         Command Message      

l         Document Message      

l         Event Message

l         Request-Reply

l         Return Address

l         Correlation Identifier

l         Message Sequence

l         Message Expiration

l         Format Indicator

创建和发送一个Message产生以下几个问题：

消息意图 － Message最终是为了运送一些数据，但是发送者可能有其他目的，比如它希望接受者使用消息做些事情。它可以发送一个Command Message，指定它希望调用的接受者上的函数或方法。发送者告诉接受者运行那些代码。发送者可以发送一个Document Message来传送它的数据结构到接受者。发送者发送数据到接受者，但是不指定接受者应该做什么。

或者它可以发送一个Event Message，通知接受者发送者那里有一个改变。发送者不应告诉接受者应该怎样适应这个改变，而只应提供通知。

返回一个应答 － 当一个应用发送一个消息，它通常期望得到一个回应来确定消息被处理并提供一个结果。这是一个Request-Reply场景。Request通常是一个Command Message，而应答是一个包含返回值或异常的Document Message。请求者应该在请求中指定一个Return Address来告诉应答者使用哪个通道来传回应答。请求者可能在一个处理过程中发送多个请求，所以应答应该包含一个Correlation Identifier来指出这个应答对应哪个请求。

有两个Request-Reply场景需要注意；它们都包含了一个Command Message请求和一个对应的Document Message应答。在第一个场景中，Message RPC，请求不但要调用应答者的函数，而且期望一个返回值。这是RPC。另一个场景中，Message Query，请求者执行一个查询；应答者执行查询并在应答中返回结果。这是远程查询。

大量的数据 － 有时应用想要传送大量的数据结构，放入一个单独的message里面不是很合适。在这种情况下，将他们分解成可管理的消息块并将他们作为Message Sequence发送。这些消息必须按顺序发送，以便接受者能够充足原始数据结构。

慢速消息 － 消息系统的一个问题是发送者通常不知道接受者要多久才能接受到消息。然而，消息的内容可能是时间敏感的，所以如果消息在某一时间内没有被接受，它将被忽略并取消。在这种情况下，sender应该使用Message Expiration来指定一个到期时间。如果消息系统在规定时间内无法传输一个消息，应该将它取消并删除到Dead Letter Channel中。同样的一个receiver接受到一个超出该时间点的消息，也要取消该消息。

总之，只选择使用消息是不够的。使一个消息工作的其他决定性因素来自于消息所要完成的任务。

在前面一个专题中，我们列出了一个ESB系统所需要关心的所有方面的关键组件，这里介绍其中的Message Channels所关注的问题及相关的模式。

Message Channel主题之下包含以下模式，分别用于解决channel中不同方面的问题：

l         Point-to-Point Channel  

l         Publish-Subscribe Channel   

l         Datatype Channel  

l         Invalid Message Channel      

l         Dead Letter Channel     

l         Guaranteed Delivery     

l         Channel Adapter    

l         Messaging Bridge  

l         Message Bus  

当两个应用需要交换数据，它们通过连接两端的channel来发送数据。发送的应用可能不知道哪个应用将接受数据。然而，通过选择特定的channel来发送，发送者知道接受者将是守候在channel另一端等待数据的应用之一。通过这种方式，生产数据的应用有了一个同数据消费者通讯的途径。

Message Channels面对的各个主要问题：

如果一个应用要传输或接受数据，它一定会用到一个channel。问题是你的应用要知道要使用什么样的channel，以及用它来做什么。

固定的channel集合 － Channel中讨论的一个主题是，一个应用可用的Message Channel集合一般是固定的。设计一个应用时，一个开发者必须知道将某种类型的数据放到哪里可以同其他应用共享该数据，以及从什么地方可以找到其他应用的特定数据。这些通讯路径不会在运行期动态的创建和发现；它们需要在设计期间就确定下来，以便应用知道它的数据从哪里来以及数据将去哪里。（ 虽然大多数channel必须被静态定义使正确的，但是也有例外，有些情况下动态channel是很好用的。一个例外就是Request-Reply模式中的reply channel。请求者可以创建或者获得一个应答者不知道的新的channel，并在请求消息中指定该channel为Return Address，应答者就可以使用它。另外一个例外是支持集成channels的消息系统实现。一个接受者可以订阅一个集成体系的根channel，然后发送者可以发布消息到一个子channel，而接受者不需要知道子channel，仍然会收到消息。这些都是不常见的情况，channel通常仍然是在部署之前被定义，并且应用被设计连接到一个已知的channel集合 ）。

决定channel的集合 － 一个相关的主题是，谁决定那些Message Channel是可用的 － message系统还是应用程序？换句话说，是由消息系统确定一些channel，然后要求应用程序使用它们？还是应用决定它们需要什么channel，然后要求消息系统提供它们？这个问题没有一个简单的答案，设计必须的channel集合是迭代的。首先，应用要决定消息系统提供哪些channel。然后应用将围绕这些channel设计它们的通讯，但是如果这样是不可行的，它们将需要添加额外的channel。当一些应用已经使用了一个确定的channel集合，当加入新的应用，它们将使用已存在的channel。当为应用添加新的功能，它们需要新的channel。

单向channel － 另外一个经常引起混淆的是一个Message channel是单向的还是双向的。技术上来说，两者都不是，一个channel更像是一个桶，一个应用放入数据，另外一个应用从中取出数据。但是由于数据是放在消息中从一个应用传到另一个，这使得channel具有方向性，使它变成单向的。如果一个channel是双向的，应用将从中发送和接受数据，虽然技术上是可行的，但是会有小小的问题，应用将有可能持续的取出自己放进去的希望发送给其他应用的消息。所以，为了实践性的目的，channel是单向的。作为结论，两个应用如果有双向通讯，它们需要两个channel，每个方向一个。

如何使用Message channels：

现在我们来讨论以下如何使用channel。

一对一或者一对多 － 当你的应用共享一些数据，你希望只将它共享给一个应用还是对它感兴趣的所有应用？要传送数据到一个单独的应用，使用Point-to-Point Channel。这并不意味着发送到这个channel的每个数据都发送给同样的接受者，因为一个channel可能有多个接受者。它意味着，实际上，保证每个数据都被同一个应用接收。如果你想让所有接收应用都能接收数据，使用Publish-Subscribe Channel。当你通过这种方式发送数据，channel将高效的复制数据到每一个接收者。

什么类型的数据 － 任何内存中的数据都有一个类型。另一方面，所有数据都是一些bytes集合。消息系统工作同这类似，消息内容必须符合某些类型以便接受者了解数据的结构。Datatype Channel认为在一个channel中的数据必须拥有同样的类型。这也是为什么消息系统需要很多channel的主要原因（每个channel一种格式）。如果数据可以是任意的格式，那么消息系统在两个应用之间只需要两条channel。

无效的和过期的消息 － 消息系统可以确定消息被正确的传输，但是它不能保证接受者知道如何处理它。接收者对数据格式和意义存在期望。当它接收到一个不符合期望的消息，它什么也不能做。它们能作的，就是将这个陌生的消息放入到一个特别设计的Invalid Message Channel并希望某些监控这个channel的工具能够取出这个消息，并指出该如何处置它们。许多消息系统有一个类似的内建特征，一个Dead Letter Channel，用来存放成功送出但却无法成功投递的消息。另外，一个系统管理工具应该监视Dead Letter Channel并且决定如何处置这些无法投递的消息。

故障检测 － 如果一个消息系统发生故障或停机维护，它的消息会怎样？当它重启并重新运行，它的消息能否还在它的channel中？默认的：不会；channel将消息存储在内存中。然而，Guaranteed Delivery将channel持久化以便将它们的消息存储到硬盘上。这会影响效率，但会使消息更加可靠，即使消息系统是不可靠的。

非消息客户端 － 如果一个应用不能连接到一个消息系统但是仍然想要参与消息怎么办？通常它只能自认倒霉了，但是如果消息系统可以通过某种方式连接到应用系统