《(整理)ESB产品架构之通道设计..docx》由会员分享，可在线阅读，更多相关《(整理)ESB产品架构之通道设计..docx（6页珍藏版）》请在三一文库上搜索。
1、精品文档ESB产品架构之通道设计郭时光精品文档1概述消息处理管道是 ESB架构的一个核心部分，ESB的核心有消息处理器分为两部分，一部分是路由处理器，一部分是端点处理器。当然，我们的基础组件也会适时的在两部分的处 理器中间，拦截加入多个基础组件处理器。例如，日志组件，会在各个部分加日志处理器， 以记录ESB运行的日志。在（图1-1）中只是一个简单的通道， 在这个通道中没有分支，路由处理器也只有一个，在实际的使用过程中当然没有简单，在路由处理器可以有多个，Endpoint也可以拥有多个。当整个通道的分支过于复杂的时候，建议还是把它看成一个业务流程，交他专业的BPM应用来做，这样不但可以减少ESB
2、复杂度，而且可修改性也能有一个大的提高。在实际的开发过程中，我们可以使用责任链的模式。一条责任链就是一个通道，消息处理器ESB初始化的时候就初始化就是责任链中的一个个han dler。我们可以在使用配置组件，在好了一个个的消息处理器。Router拦截抑入流控 组件处理器r仃:截加入II恵 组件处理黠服养消息沆L "tJiInboundEnd point:C逋迅衿Y/J 坟处理L:l馮鱼-*鶉换拦截加入监控组件处理器1-1Outbound Endpoint2 ESB的通道三部分组成，他是这样运行的。ESB由 Outbound Endpoint、Inbound Endpoint、Rout
3、er看起来是不是很简单，但在现实环境下，我们可能会需多记录日志 我们的通道就会变成这样，需要做流控，这时候MessageReciverTransformer简单路由器| TransrormsrMessageDI&pach&r当然这也不是一个最复杂的状态，因为我们在ESB的内部可能会做一些简单的流程编排，所以，他可能会有多个的路由，可能会有多个的transformer或者是 MessageDispacher。这些都经求，我们在做这个通道的架构时，可修改性是十分重要的。在这种可修改性要求高的情况下， 我们当然不可能对每一支交易做硬编码，这时我们就一定会想起经典的模式 责任链(Cha
4、in of Responsibility Pattern UML)，相信大家对这个责 任链的模式应该十会的熟习了吧，以下是他的UML图大家可以回忆一下。为此我们定义了一个接口 MessageProcessor,这个接口就是handler，它会有很多的子接口如，Router,Transfomer,MessageDispacher,Filter等。除了 MessageReceiver所有的 ESB内部 的处理，都会被转化成一个消息处理器，他的最终的接口都是MessageProcessor。这当然也包括我们的日志和流控处理。这样我们就会得到一个很强的可修改性，虽然，可能在某种意义上来说，他牺牲了一定
5、的性能，但这一点点小的牺牲还是十分值得的。<interface>Router«inier1ceFilter=：=：interface» Transformer=interface>>MessageDisparcher我们要用怎么样的方式串起这个责任链呢，在一般的情况下，我们应当使用 配置信息来做，因为ESB对配置还是有一定的要求的，它是一个非常大的主题, 所以我留到以后来进行阐述，这里，我们先看看代码是怎么组装的，在这时，我 们也会充分的考虑以后，怎么改成配置化的要求。在组装通道时，我们最重要的是需要一个好的创建对象来做，这个创建对象 的接口如下，&
6、lt;interface»ChanndBuilder+ chafn(processor /essageProcessor) : vofdChain这个方法我们传入一个processor，我们会按前后顺利放到List中，这 个，我们可以把我们的一个个的 MessageProcessor chai倒我们的Builder中，然 后，使用 build 来获得一个 MessageProcesso，这个 MessageProcessor有下一个 processor的引用。他的接口如下，这个接口当然是需要继续 MessageProcessor?interface»I nt erceptorMess ageProce ss or-nmxl: Messageprocessor在这里可能会出现一个问题，并不是每一个处理器都会实现这个接口， 这样, 如果要成为责任链中的一个处理器， 我们就需要使用粉饰的模式，这个处理器加 上这个功能，就这样，我们的一个处理链就完成了。