ESB产品架构之通路设计
1.概述
消息处理管道是ESB架构的一个核心部分， ESB的核心有消息处理器分为两部分，一部分是路由处理器，一部分是端点处理器。当然，我们的基础组件也会适时的在两部分的处理器中间，拦截加入多个基础组件处理器。例如，日志组件，会在各个部分加日志处理器，以记录ESB运行的日志 。
在（图1-1）中只是一个简单的通道，在这个通道中没有分支，路由处理器也只有一个，在实际的使用过程中当然没有简单，在路由处理器可以有多个，Endpoint也可以拥有多个。当整个通道的分支过于复杂的时候，建议还是把它看成一个业务流程，交他专业的BPM应用来做，这样不但可以减少ESB复杂度，而且可修改性也能有一个大的提高。
在实际的开发过程中，我们可以使用责任链的模式。一条责任链就是一个通道，消息处理器就是责任链中的一个个handler。我们可以在使用配置组件，在ESB初始化的时候就初始化好了一个个的消息处理器。
2.ESB的通道
ESB由Outbound Endpoint、Inbound Endpoint、Router 三部分组成，他是这样运行的。
看起来是不是很简单，但在现实环境下，我们可能会需多记录日志 ，需要做流控，这时候我们的通道就会变成这样.
当然这也不是一个最复杂的状态，因为我们在ESB的内部可能会做一些简单的流程编排，所以，他可能会有多个的路由，可能会有多个的transformer或者是MessageDispacher。这些都经求，我们在做这个通道的架构时，可修改性是十分重要的。
在这种可修改性要求高的情况下，我们当然不可能对每一支交易做硬编码，这时我们就一定会想起经典的模式责任链（Chain of Responsibility Pattern UML），相信大家对这个责任链的模式应该十会的熟习了吧， 以下是他的UML图大家可以回忆一下。
为此我们定义了一个接口MessageProcessor，这个接口就是handler，它会有很多的子接口如,Router,Transfomer,MessageDispacher,Filter等。除了MessageReceiver所有的ESB内部的处理，都会被转化成一个消息处理器，他的最终的接口都是MessageProcessor。这当然也包括我们的日志和流控处理。这样我们就会得到一个很强的可修改性，虽然，可能在某种意义上来说，他牺牲了一定的性能，但这一点点小的牺牲还是十分值得的。
要用怎么样的方式串起这个责任链呢?
在一般的情况下，我们应当使用配置信息来做，因为ESB对配置还是有一定的要求的，它是一个非常大的主题，所以我留到以后来进行阐述，这里，我们先看看代码是怎么组装的，在这时，我们也会充分的考虑以后，怎么改成配置化的要求。
在组装通道时，我们最重要的是需要一个好的创建对象来做，这个创建对象的接口如下。
Chain这个方法我们传入一个processor，我们会按前后顺利放到List中，这个，我们可以把我们的一个个的MessageProcessor chain到我们的Builder中，然后，使用build来获得一个MessageProcessor，这个MessageProcessor有下一个processor的引用。他的接口如下， 这个接口当然是需要继续MessageProcessor。
在这里可能会出现一个问题，并不是每一个处理器都会实现这个接口，这样，如果要成为责任链中的一个处理器，我们就需要使用粉饰的模式，这个处理器加上这个功能，就这样，我们的一个处理链就完成了。