mule示例分析
一、Hello World （主要演示了两个service component链式合作处理一条消息和消息格式转换
1、示例翻译：
展示了如何配置多个service components——它们与一个请求交互（就是说二者合作以链式方式先后处理一个请求消息，处理的方式是添加消息的内容），以及如何管理事件转换（所谓事件就是消息，这里的事件转换是指消息格式的转换，比如从stdio标准输入中输入的字符串转换为一个java bean对象以及不同java bean之间的转换）。这个例子还使用了属性文件来配置i18n国际化的消息文字。还有演示了出站过滤路由。

使用了两个类也就是两个service component组件来先后处理消息，第一个是Greeter 类，它的greet()方法 使用LocalMessage 来从上面提到的属性文件获取greeting问候语，然后把问候语"Hello"加到你在控制台输入的名字之前（这样它就第一次修改了消息的内容）。第二个是ChitChatter类，它的chat方法 把", how are you?"加到消息内容之后（这样它又一次修改了消息内容）：

ChitChatUMO服务组件又配置了两个转换器：NameStringToChatString、ChatStringToString。ChitChatter组件类的输入参数为 ChatString 类型，所以NameStringToChatString转换器将消息格式从NameString转为 ChatString、然后再调用 ChitChatter组件（流程：GreeterUMO -> vm://chitchatter -> NameStringToChatString -> ChitChatter -> ChatStringToString -> System.out）
注意Java bean是不含有任何路由逻辑的， Mule配置文件将它们组织到一起，任何已有的pojo、web services都可以照此办理并在它们之间传输消息。

二、Stock Quote （演示了如何调用ASPX web service、使用XSLT转换、反序列化StockQuote Java bean以及使用REST和SOAP调用服务。例子需要访问互联网上的公共.NET服务、主要是咱也不知道人家都有哪些股票代码有数据。源码就不看了） 
    1、示例翻译：通过System.in接收股票代码、调用StockQuote服务、通过XSLT转换器将返回结果转换格式、通过XmlToObject转换器再将结果转换为StockQuote类型、随后将股票报价打印到System.out
  （例子用到了类似spring的属性占位符特性来从配置文件取得一些信息、配置多个转换器并“串联”起来、其中还用到xslt转换器）

配置当中还用到所谓的REST service component , 它使用了REST服务包装器代理了一个REST服务、这样使得该service服务看上去似乎是本地的component组件一般（和CXF的web服务包装器差不多），REST服务包装器有一些配置属性：serviceUrl就是 访问REST服务的url、payloadParameterName是传参名 ，本例中只有一个参数"symbol"——股票代码、httpMethod是方法名 ——GET或POST。 

  我随便传了个代码过去返回了无数据的xml：

三、Error Handler （演示了如何使用Spring beans作为service component以及向多个出站endpoint发布消息，使用了文件监控inbound+邮件outbound）
示例包含两个services: ExceptionManager 异常管理器 和 BusinessErrorManager业务错误管理器。

BusinessErrorManager是个简单的service，它通过JMS接收业务异常消息并将消息记录到控制台，以此模仿真实的异常处理应用。 
  ExceptionManager接收异常消息并根据异常消息的类型进行某些处理动作。例如如果收到致命异常则会向系统管理员发送邮件；收到标准系统异常则写入本地文件log，例子演示的不是异常处理、演示的是：
(1)所有的service components都是以spring bean的形式在一个mule配置文件当中配置的。
(2)error manager拥有多个outbound endpoints出站端点，例子演示了消息如何发布到不同端点。 
(3)消息是Java对象形式，并且需要在XML形式之间互相转换。例子演示了链接多个转换器。

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为中心的辐射方式（可能性能有问题，不推荐）、管道方式（服务编排？）

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银行网关 ：基于贷方列表、向一家或多家银行分发贷款请求。

总体流程：

1，客户应用向LoanBroker 贷款中介服务 发出 CustomerQuoteRequest消息 。 
2,LoanBroker 贷款中介服务 创建一个 LoanQuoteRequest 消息，这是总线通用消息格式。 
3,Mule通过JMS向Credit Agency Gateway 征信所网关 发送该消息。 
4,网关整理请求、调用CreditAgency EJB组件，RelectionMessageBuilder自动将CreditProfile附加到LoanQuoteRequest 消息上 。 
5,Mule通过JMS向Lender Gateway贷方网关 发送该消息. 
6,贷方网关 使用VM传输调用贷方服务 . 
7,Mule通过JMS向Banking Gateway银行网关 发送该消息. 
8,Banking Gateway银行网关 通过Axis实现的SOAP调用银行服务. 
9,每家银行都把自己的贷款报价附加到请求中并通过应答地址ReplyTo 发回LoanBroker 贷款中介服务 。应答地址是由Banking Gateway银行网关 提供的. 
10,LoanBroker 贷款中介服务 的ResponseRouter响应路由接收对应答地址 的响应，它选择最低利率并返回客户。


本例中，消息总线上的通用消息格式是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请求都直接用这个转换器予以转换：