LoanBroker教程

1. Overview

《Enterprist Integration Patterns》这本书中，ComposedMessagingTIBCO.html范例之后例举了借贷Broker(代理)的范例。书中说：“这是一个简单的银行服务调用请求系统。客户向借贷broker接口提交调用请求后，借贷broker先获得该客户的信用度，再将此调用请求转发给多个银行。得到各银行的返回结果后，借贷broker从中选择出最佳的，返回给客户。”

图1-1

图中：

1. 网络客户端向借贷Broker系统提出一个请求贷款利率的申请。

2. 借贷Broker的BPEL服务引擎向信用代理模块查询该请求者的信用度。

3. 借贷broker向多家银行请求最佳贷款利率的服务。WS-Notification(告知)服务引擎将贷款金额、期限和贷款者的信用度发送给多家银行。

4. 各银行将他们的最佳贷款利率返回给借贷broker。

5. 借贷broker判断各银行返回的结果中哪个是最佳的，并将该信息返回给请求者。

5.2 消息流

首先我们来看当借贷利率返回时，一个独立的借贷请求是如何被处理的。下图显示了借贷利率请求信息的流。

<shapetype id="_x0000_t75" stroked="f" filled="f" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t" o:spt="75" coordsize="21600,21600"><stroke joinstyle="miter"></stroke><formulas><f eqn="if lineDrawn pixelLineWidth 0"></f><f eqn="sum @0 1 0"></f><f eqn="sum 0 0 @1"></f><f eqn="prod @2 1 2"></f><f eqn="prod @3 21600 pixelWidth"></f><f eqn="prod @3 21600 pixelHeight"></f><f eqn="sum @0 0 1"></f><f eqn="prod @6 1 2"></f><f eqn="prod @7 21600 pixelWidth"></f><f eqn="sum @8 21600 0"></f><f eqn="prod @7 21600 pixelHeight"></f><f eqn="sum @10 21600 0"></f></formulas><path o:connecttype="rect" gradientshapeok="t" o:extrusionok="f"></path><lock aspectratio="t" v:ext="edit"></lock></shapetype><shape id="_x0000_i1025" style="WIDTH: 414.75pt; HEIGHT: 299.25pt" type="#_x0000_t75"><imagedata o:title="" src="file:///C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/msohtml1/01/clip_image001.emz"></imagedata></shape>

这个例子实现了两个银行。在一个现实的环境中，信用代理社和银行更有可能在借贷代理应用程序的外部——事实上，它们一般是外部的公司。为了使这个例子简单，银行0被实现为Loan Broker JBI容器的内部服务。银行1—银行X在图中作为外部实体。它们都通过一个绑定组件和Loan Broker JBI系统相连接。这些绑定组件使用它为之服务的银行所用的协议来彼此交流。

上图显示了一个借贷利率请求中的消息流：

1. Web客户是借贷请求者。它通过在一个Apache ActiveMQ队列上发布一个JMS消息来发送请求。

2. loanbroker-jms接收这个请求。Loanbroker-jms是一个绑定组件（BC），它可以接收和处理JMS消息。Loanbroker-jms把收到的消息规格化。规格化消息可以把消息转换成JBI系统使用的中立的格式。规格化以后，loanbroker-jms通过规格化消息路由器（NMR）把消息传输到预定的接收者。这时的接受者是loanbroker-lb。注意loanbroker-jms实现了In-Only Message Exchange Pattern（消息交换模式）（MEP）。请参照JSR-208和Apache ServiceMix介绍以便了解有关消息交换模式的更多细节。

3. loanbroker-lb是一个前台到BPEL的流程。Loanbroker-lb是一个服务引擎（SE），它的工作是接收接待请求并传输给loanbroker-bpel流程，然后等待一个从BPEL流程发来的回复。loanbroker-lb是一个聚集器；它接收一个In-Out MEP，把一个In-Only MEP给loanbroker-bpel，并在等待一个回复端的In-Only MEP。这个响应作为In-Out MEP的Out 消息被发给用户

4. loanbroker-bpel流程接收到借贷利率请求。由于BPEL流程是异步的，到来的loanbroker-bpel MEP是In-Only，相应作为一个In-Only MEP而发送给一个回复端（callback endpoint.）

5. 首先loanbroker-bpel必须获得请求者的信用度。BPEL流程通过NMR发送一个消息给loanbroker-ca流程。

6. loanbroker-ca是一个绑定组件。它把规格化的数据（包含一个信用度请求）翻译成一个HTTP+SOAP消息。完成这些之后，loanbroker-ca可以和creditagency-http绑定组件进行交流。loanbroker-ca的MEP是In-Out的。

7. creditagency-http绑定组件把信用度请求传输给creditagency-service。

<shapetype id="_x0000_t202" path="m,l,21600r21600,l21600,xe" o:spt="202" coordsize="21600,21600"><stroke joinstyle="miter"></stroke><path o:connecttype="rect" gradientshapeok="t"></path></shapetype><shape id="_x0000_s1027" style="MARGIN-TOP: 15.6pt; Z-INDEX: 2; LEFT: 0px; MARGIN-LEFT: 27pt; WIDTH: 5in; POSITION: absolute; HEIGHT: 148.2pt; TEXT-ALIGN: left" type="#_x0000_t202" strokecolor="blue" strokeweight="1.25pt"><textbox style="mso-next-textbox: #_x0000_s1027"></textbox></shape>

在我们的实现过程中， creditagency-service 作为一个服务引擎在 JBI 总线内部实现。然而，此图把它在外部作为一个单独的 JBI 容器。在一个现实世界环境中，信用代理社更有可能是一个外部实体，可能在另一个公司或至少在一个不同的服务器上。为了简化本例的代码，它被作为另一个服务引擎在 Loan Broker JBI 容器中实现，但是此图显示了比较可能的情景。

8. creditagency-service处理请求并答复。答复是通过在HTTP上返回一个SOAP消息给creditagency-http绑定组件的。

9. creditagency-http绑定组件从creditagency-service接收HTTP+SOAP响应并把它同样通过HTTP+SOAP响传送给loanbroker-ca绑定组件。

10. loanbroker-ca规格化HTTP+SOAP消息并把它通过NMR发送到loanbroker-bpel流程。

11. 至此BPEL流程获得了信用记录的信息，它可以把借贷利率请求发送给银行。银行的借贷请求发送给一个WS-N流程。这个组件会把请求通报给多家银行。loanbroker-bpel的消息交换格式是In-Only。

在我们的例子中只实现了两个银行，但是还可以加更多的银行。

而且，银行0作为一个服务引擎组件在JBI容器内部实现。

典型地，银行应该在JBI系统的外部

12. bank0-wsn把借贷请求发送给银行0。MEP是In-Only。

13. bank0-service处理借贷请求并发送一个响应给loanbroker-bpel。消息交换格式是In-Only。

BPEL流程和WS-N流程循环。BPEL流程通过WS-N发送借贷利率请求给银行。当BPEL流程接收到一个来自银行的回复，它把该银行的借贷利率和手头上的最佳利率作比较。如果新的利率更好，BPEL流程通过WS-N发送另一个消息给所有的银行，征求更好的利率。这说明WS-N流程也是循环的，因为当它得到另一个来自BPEL的带有最佳利率的消息时，它依次给所有的银行发送另一个请求。当一定的时间过去之后，如果没有银行能够给出一个更好的利率的话，手头上的最佳借贷利率将返回给请求者（Web客户）。

为简单起见，银行1-银行X的消息流这里就不给出了。上述情景和外部银行的情况相同。它们通过绑定组件和Loan Broker系统相连接时有一点不同，因为它们不像银行0那样在JBI的内部。

5.3企业集成模式。

另一种方式看在Loan Broker系统内部就是从企业集成的模式去看待它。

<shape id="_x0000_i1026" style="WIDTH: 415.5pt; HEIGHT: 178.5pt" type="#_x0000_t75"><imagedata o:title="" src="file:///C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/msohtml1/01/clip_image003.emz"></imagedata></shape>

总的来说所有的绿色方块代表了组件。带有桥形符号的绿色方块是绑定组件。这些组件规格化到来的消息。其他绿色方块代表了服务引擎组件。它们对消息做一些处理。所有的绿色方块都属于Loan Broker JBI系统并通过NMR进行交流。灰色方块代表外部服务，如银行和信用代理社。

从左向右解释该图：

1. 最左边的灰色方块（标签为“1”）代表了Web客户。它发送一个消息给loan broker系统请求一个借贷利率。注意绿色方块用符号来表示发送一个测试消息。

2. 借贷利率请求消息通过一个JMS队列被发送给一个消息桥。

3. 消息桥连接两个消息系统。也就是说，JMS队列通过消息桥与loan broker相连接。在JBI环境中，消息桥是一个绑定组件，它可以规格化消息。

4. 一个流程管理器通过一系列动态步骤路由消息。这个“流程管理器”是BPEL。在loan broker应用中，BPEL从信用代理社获得信用记录，并编制发送接待利率请求给银行（下一步可以看到）。在步骤4中，BPEL通过一个桥发送一个消息给信用代理社。

5. 信用代理社在loan broker系统外部。loan broker消息系统必须和信用代理社的消息系统桥接。桥将把消息翻译成一种信用代理社懂得的协议的格式。

6. 信用代理社把信用记录通过消息桥返回给loan broker。

7. loan broker（BPEL流程）获得了关于请求者的足够信息，现在可以把借贷请求发送给各个银行了。它把借贷请求发送给WS-Notification（WS-N）流程。

8. WS-N是一个基于Web服务的发现的工具，它使用一种基于主题的发布/订阅模式。在这种情况下，WS-N作为一个loan broker和银行之间的消息代理。WS-N将把借贷请求发布给一个内部JMS主题，对此感兴趣的银行将订阅该主题，接收借贷请求。

9. 银行1不能处理借贷请求，因为它使用一种不兼容的格式。因此，消息首先被一个消息翻译器处理。翻译器把消息转换成一种银行1可以接收的格式，通过HTTP，用SOAP的方式。

10. 银行1处理过请求之后，它返回一个响应给BPEL流程管理器。首先它把JMS消息翻译成其原先的格式。

11. 同时，银行2使用Polling方法接收借贷请求。当一个接收者在它接收到消息时想要获得控制时，采用选举用户的方式。在企业集成模式中被描述为“这也被看作是一个同步接收者，因为接收者线程在接到信息之前一直是被阻塞的。我们把它叫做选举用户，因为接收者选举一个消息并处理它，然后接着处理下一个消息”。

12. 处理过请求之后，银行2返回一个响应消息给BPEL流程管理器。

13. 银行2的响应消息通过桥而被翻译成一个规格化的格式，这个格式能被loan broker理解。

14. 同时，银行0收到借贷利率请求消息并处理它。银行0是一个特殊的案例，因为它在loan broker系统的内部。它和其他loan broker组件在同一个JBI容器中。因此，它可以接收规格化的消息。

15. 银行0发送一个响应给BPEL流程。

16. BPEL流程在这个借贷请求持续的时间内一直循环。当银行回复之后，BPEL跟踪迄今为止的最佳借贷利率。在收到每个响应并作出比较之后，BPEL发送另一个请求给所有的银行，征求更好的利率。此时启动一个计时器。如果计时器超时，BPEL知道已经拥有了最佳利率并把它发回给请求者。