ESB之旅（关山何止千万重——ErrorHandler、LoanBroker）
? 有人说白人的傲慢是浸透在骨子里的，虽然表面看不出来，也许再待的时间长点我对此能有些体会，到时候再告诉大家。可是即便那样，Q和我也是可以忍受的。穷人到哪里都是穷人，Q和我都出生在国内贫穷落后的小城市，依靠自己的努力考上像样的大学，硕士毕业来到某直辖市，并得到当地的户籍，但始终无法融入当地人的生活，待了几年也没有学会直辖市人引以为傲的方言，一口普通话也让我们受到过不少的区别对待。所以我喜欢那篇文章——《我花了18年的时间才能和你坐在一起喝咖啡》，其实我们花的时间何止18年？何必说人家有种族优越感，即便在国内，对待自己的同胞，某些人又何尝有过平等的心态？Q和我，不过是这艰难时世中的一对凤凰男和凤凰女，努力寻找着可以挡风遮雨的一棵梧桐树罢了！——《关山何止千万重》
? 天涯上一篇帖子里的文字，就扔这了。
? 突然就想到一个问题：现在骡子这个东西早就绝种了吧？现在的马是比赛用的，驴也很罕见了，可能就剩点可可西里的野驴了，更别提骡子了，况且骡子不能生育，岂不是死一个少一个...
? Scripting 演示mule对JSR-223的支持，先略过不表，error handler例子过一下，重点分析loanBroker例子。
?
一、Error Handler （演示了如何使用Spring beans作为service component以及向多个出站endpoint发布消息，使用了文件监控inbound+邮件outbound）
? 1、示例翻译：? 示例包含两个services: ExceptionManager异常管理器 和 BusinessErrorManager业务错误管理器。BusinessErrorManager是个简单的service，它通过JMS接收业务异常消息并将消息记录到控制台，以此模仿真实的异常处理应用。
? ExceptionManager接收异常消息并根据异常消息的类型进行某些处理动作。例如如果收到致命异常则会向系统管理员发送邮件；收到标准系统异常则写入本地文件log，例子演示的不是异常处理、演示的是：
所有的service components都是以spring bean的形式在一个mule配置文件当中配置的。
?
Running the Example运行实例步骤：? （我将email.properties配置为我的公司邮箱地址，那个smtp.port=25一般不用更改。启动errorhandler.bat，将test-data\out\FatalException.xml拖到test-data\in目录下后即可看到console上有了反应，最后会打印出发送邮件的地址，但是我的邮箱并未实时收到邮件，当停掉console时才收到邮件，似乎邮件不是即刻发送而是当mule停止时关闭钩子会flush一下队列，什么原因不清楚）
? 2、源码分析：? 在echo例子的源码分析中分析到了Registry注册库，Registry从下到上的继承体系：
??? SpringRegistry
????????????? |
? AbstractRegistry抽象类?
????????????? |
????? ?Registry接口?
????????????? |
??org.mule.api.lifecycle.Initialisable + Disposable接口
?
? 1) Initialisable. initialise()在实现服务的初始化阶段被调用，你可以在该方法实现中加入任何初始化工作；Disposable. dispose()方法在实现服务的销毁阶段被调用。实现者应该在这个生命周期方法中加入释放所有资源的处理（这两个接口方法类似httpservlet的init和destroy，都是由外部容器去掉用，你只要在子类中覆写即可）
? 2) Registry注册器接口包含大量类似spring BeanFactory的方法如：lookupObject(String key)、lookupObjects(Class type)、registerObject(String key, Object value)、unregisterObject(String key)...但是注册库不创建任何bean，只是查找获取bean的客户端门面。
? 3) AbstractRegistry仍然是模版方法的抽象中间层，它把initialise()方法延迟到doInitialise()、dispose()延迟到doDispose()
? 4) SpringRegistry具有一个registry_id="org.mule.Registry.Spring"，另外它完全是read-only的，不允许注册或解除注册也就是再修改状态。
? 当你需要去存储在service component间共享运行时数据的时候，你可以将数据作为Object对象存储到Registry中。你可以在任何地方通过访问MuleContext获取Registry对象。
? 1) 客户customer 向不同的银行bank 发起请求搜寻最优利率。
? 2) 每家银行都要向客户询问社保号码ss、贷款数量以及期限。
? 3) 每家银行都要对该客户做信用背景调查：通常是咨询征信所credit bureau （通过征信中介credit? agency ），最后银行才能根据这些信息发放贷款。
? 4) 客户接收到所有银行的反馈以后，从中选择一家最好的，比如说利率最低。
?
? 增加贷款中介以后，这个处理流程可以更加自动化、允许客户在线获取更多银行的实时反馈，耗时要比一家一家询问少得多：
? 1) 接收到客户请求以后，loan broker贷款中介从征信所获取该客户的信用信息。
? 2) 替该客户向贷方服务lender service 列出的所有银行发出贷款请求（例子中这个服务啥也没做只是个意思）
? 3) 将反馈的贷款额度信息打包发送回用户供选择（例子中就是选择返回利率最低的那家银行）
? 贷款请求流程如下图：
? 这其中的角色包括
? 1、贷款中介服务http/rest（接收客户的http贷款请求，包含社保号、贷款额、期限并负责相应放贷信息）。
? 2、征信所服务EJB（由贷款中介公司管理的EJB外部服务，做信用检查的，暴露一个名为creditAgency的EJB的getCreaditProfile方法）
? 3、征信所网关（例子中的网关做的事情都是：在JMS消息总线和 外部应用或服务/征信所服务应用 之间整理请求）
? 4、贷方服务VM（根据客户的资信评分等信息选择请贷的银行，本地pojo组件，决定请求哪几家银行）
? 5、贷方网关（在消息总线到贷方服务应用之间整理请求）
? 6、银行网关（向多家银行分发贷款请求）
? 7、还有几家银行bank（soap协议的消息服务、为了简化、所有银行暴露同样的ws接口。当然你也可以配置不同接口的多家银行）。
? 这都算是应用，以往的应用之间通讯是点对点，客户自己去一家一家调用银行服务、所有银行都一遍一遍地调用征信所。而loanBroker就相当于我们的ESB，加入loanBroker以后就不再是点对点而是点对面，ESB就是面、覆盖了征信所、所有银行及各个网关的一个门面（这么看ESB蛮像一个fasade的嘛），这个门面替应用摆平一切，你只要说我要贷款！、其他的如你的资信评级、你都要请求谁、你的请求还需要依赖什么都包办，有事您只管说句话就得。
? 例子涉及异步的请求/响应处理模型；对JMS、http/rest、vm、soap、EJB各种协议的调用；把bank暴露为ws。总线中的消息用LoanQuoteRequest 代表，本例中这是个javaBean格式，但是实际中往往是个xml格式（用了ESB，我发现对消息这个东东来说格式是五花八门的：javabean pojo、xml、http参数、stdio、soap甚至json...）
?
? loan broker的示例包含ESB和ESN两种布局的版本，含义参见Mule Topologies的5种拓扑布局：
? ESB、ESN企业服务网、对等网（这不又成了点对点了么，不推荐）、C/S以hub为中心的辐射方式（可能性能有问题，不推荐）、管道方式（服务编排？）
? loan broker示例还包含第三个版本BPM版本，使用了业务处理引擎去编排请求。背景知识基本学完鸟。先看ESB版本：
? 1、示例翻译：? Loan Broker ESB基于当前的Loan Broker示例 但是实现了一个完整的ESB架构，该例子演示了如何使用HTTP/REST、 Web Services、EJB、JMS，他是根据典型ESB实现来配置的。
? Loan Broker ESB使用了JMS消息总线以提供在不同组件和应用间的公共消息通道：
? 包含消息端点和组件类型的细节图：
? 组件：
? 1、Loan Broker Service贷款中介服务 ：接收贷款请求(信息包括SS社保号码、贷款额度、期限)并负责收集放贷反馈向客户反馈。
? 2、Credit Agency Service征信所服务 ：外部服务提供者、它对客户的授信进行检验以确保合理的放贷额度。
? 3、Credit Agency Gateway征信所网关 ：在消息总线和征信所应用之间整理请求。
? 4、Lender Service贷方服务 ：基于客户的资信评分，放贷额度和期限，由贷方服务选择请求贷款的银行。
? 5、Lender Gateway贷方网关 ：从消息总线到贷方应用之间整理请求。
? 6、Banking Gateway银行网关 ：基于贷方列表、向一家或多家银行分发贷款请求。
?
? 总体流程：
客户应用向LoanBroker 贷款中介服务 发出 CustomerQuoteRequest消息 。LoanBroker 贷款中介服务 创建一个 LoanQuoteRequest 消息，这是总线通用消息格式。Mule通过JMS向Credit Agency Gateway 征信所网关 发送该消息。网关整理请求、调用CreditAgency EJB组件，RelectionMessageBuilder自动将CreditProfile附加到 LoanQuoteRequest 消息上 。Mule通过JMS向Lender Gateway贷方网关 发送该消息.贷方网关 使用VM传输调用贷方服务 .Mule通过JMS向Banking Gateway银行网关 发送该消息.Banking Gateway银行网关 通过Axis实现的SOAP调用银行服务.每家银行都把自己的贷款报价附加到请求中并通过应答地址ReplyTo 发回LoanBroker 贷款中介服务 。应答地址是由Banking Gateway银行网关 提供的.
? 2、源码分析：LoanBroker 贷款中介服务 的ResponseRouter响应路由接收对应答地址 的响应，它选择最低利率并返回客户。
? 03年mule从sourceforge开始、05年迁至codehaus并发布1.0版本、07年吧出的2.0，mulesoft也成立了。现在（2010年）2.2.1源码在2M多，只看source只会事倍功半。改为以例子的源码分析作为切入点。这里的分析需要你已经下载mule2.2.1，里面的例子中有loanbroker，结合着它的esb版配置文件（loanbroker\esb\conf\loan-broker-esb-mule-config.xml）分析。网上资料可能大多是mule1.0版本的，这里都是以2.2.1为准。
? 本例中，消息总线上的通用消息格式是java bean格式。一般情况下如JMS规范要求总线内的通用消息是xml格式，但是mule允许你使用任何数据格式，两种格式各有优缺，xml的文本消息允许你方便的直接实施xslt转换器之类，bean方式在component中更便于编码处理，两种方式也都方便用路由器去根据消息内容做路由判断。我们先来定义这个消息bean：LoanQuoteRequest（org.mule.example.loanbroker.messages.LoanBrokerQuoteRequest）：
?这句话的配置含义：
?1、内嵌Jetty servlet引擎
?2、mule启动jetty在8888端口上监听rest请求
?3、把rest servlet绑定到/loanbroker上下文
?来自客户的初始rest请求格式为：
?
这个转换器要用在贷款中介端点 上，在贷款中介服务的入站inbound配置上、入站端点endpoint引用了贷款中介端点 (CustomerRequestsREST)、同时也引用了这个转换器。也就是说从贷款中介端点 上接收的rest请求都直接用这个转换器予以转换：
?自定义转换器的写法比较简单请自行参见：org.mule.example.loanbroker.transformers.RestRequestToCustomerRequest，它把rest请求参数封装为CustomerQuoteRequest - CQR，注意CQR是LoanBrokerQuoteRequest的成员，CQR仅仅包含三个最基本的rest请求参数：
? 具体代码自行参看，总之贷款中介服务 LoanBrokerService接口定义了一进一出两个方法，分别做消息的请求和反馈：
LoanBrokerQuoteRequest bqr = new LoanBrokerQuoteRequest();bqr.setCustomerRequest(request);?就是构造一下LoanQuoteReques 这个通用消息javabean而已。下篇继续loanBroker的分析。
?
