基于接收表的ESB研究与设计

    ESB(Enterprise Service Bus，企业服务总线)，提供了消息交互的基础结构，使得消息可以传输到对应的服务中去。目前大多数的ESB系统都是采用基于内容的路由算法，即根据消息的内容把消息路由到正确的服务单元。当有较多服务单元接收消息时，此种算法的工作效率将大幅下降，ESB也会承担较大的负载，使得整个系统集成的效率降低。常规的解决方案是把判断服务单元是否应该接收消息的逻辑分布到各个服务单元上，但此方法增加了维护的负担。为了保持集中控制，可以在每条消息附带的列表中指定这个消息所面向的接收者。这样，当消息被广播给所有可能的接收者时，不在接收者列表中的各个接收者可以丢掉该消息。
    但采用这种方法的缺点是效率低，每个潜在的接收者必须处理每一条消息。并且，如果要求消息不希望被某些接收者看到，采用这种解决方案是不适合的。例如在发送某些机密消息时，是不希望无关接收者收到消息的。
    为了解决上述问题，文中提出了基于接收表的ESB路由算法，可以提高消息交互的效率和消息的保密性。

1 接收表路由算法的分析与设计
    在基于接收表的路由算法中，应为每个接收者定义一个通道，可以定义一个规则库来检验输入的消息，确定需要该消息的接受者列表，并把消息转发给与列表中接收者关联的所有通道。
1．1 路由设计
    在接收表的算法中，接收表路由器主要由接收者计算逻辑和消息分配器两个部分组成，消息的传递过程，如图1所示。

    接收者计算逻辑首先对消息进行处理，确定此消息应该发送到哪些服务中去，计算出接收者列表，进而分配器将消息转发到服务所对应的通道中去，最后服务接收到此消息。在接收者计算逻辑中，要对消息的内容进行分析，并且要结合服务接收消息的规则来计算接收者的列表。
    接收者计算逻辑应将服务者与其服务地址及服务规则进行关联，可以进行如下表示。
    Routing：=<ser_id，ser_name，uri，{ser_rule}>
    (1)ser_id表示服务单元的编号；
    (2)ser_name表示服务的名称；
    (3)uri表示服务的地址；
    (4){ser_rule}表示该服务单元的规则集。
    ser_rule应将规则的名称和该规则要求的值进行关联，可以进行如下表示：
    ser_rule：=<rule_name，value>
    (1)rule_name表示规则的名称；
    (2)value表示规则的对应值。
    接收者计算逻辑映射为xml文件的形式，并且将服务的地址和服务单元要求的规则进行了描述。

    在上述xml形式的接收者计算逻辑中，以服务单元B为例对规则库进行说明。“<rule name=”region”value=”Beijing”><／rule>”定义了服务地域的规则，即只服务北京的客户，“<rule name=”client”value=”enterprise”><／rule>”定义了服务客户类型的规则，即只服务于企业，“<rulename=”maxloanamout”value=”5 000”><／rule>”定义了服务项贷款的最大金额，其值为5 000万元。
    获取接收者列表的算法，可以进行如下描述：S为服务单元的集合，Si为的某个服务单元。ri为服务单元i的规则集，rij为服务单元i的某条规则，servicerList为接受者列表，在初始化时加载所有的服务单元(1≤i≤n，1≤j≤m，n为节点的个数，m为某个服务节点的规则的个数)。

    ／／如果不能满足此服务单元的路由规则，则接收者列表中删除此服务单元。

1．2 动态化
    为了使服务能够动态的调整自己的服务对象，提高整个系统集成的灵活性。将路由规则分布到各个服务来控制，是一种理想的解决方案。通过接收表的动态化，整个系统的实时性也有进一步的提高。例如，服务单元N以前只能处理贷款金额<1 000万元的服务请求，而服务单元N进行系统升级后，可以处理贷款金额<1亿元的服务请求，此时应该对接收表中规则库做相应的调整。为了实现这种功能，应在服务节点和接收表之间建立控制信息传输通道，使得服务节点能把自己处理消息的要求发送给接收表，并存储到其规则库中，其流程如图2所示。

    接口程序是由ESB路由器提供，服务单元只需调用ESB的(修改xml路由文件)服务接口，实现对接收表计算逻辑的修改。
    接口设计：
    class ServiceOperation
    {
    CreateServicer(Servicel s)；／／创建服务
    UpdateServicer(Serricer s)；／／更新服务包括服务名，路径的修改
    RemoveServicer(String ServicerID)；／／根据服务的ID删除对应服务在路由器中的信息
    CreateServicerRule(String ServicerID，StringruleName，String rule Value)；
    ／／根据服务的ID，创建该服务新的规则
    UpdateServicerRule(String ServicerID，StringruleName，String ruleValue)；
    ／／根据服务的ID和规则的名称，更新规则的值
    RemoveServicerRule(String ServicerID，StringruleName)；
    ／／根据服务的ID和规则的名称，删除该规则
    }
    此接口应以Web服务的方式暴露给与ESB集成的服务单元，使其可以调用接口中的方法来实时改变服务单元的服务。
1．3 事务处理
    接收表在进行消息传递时，应使用事务性通道，把消息放置到输出通道中属于同一个事务的一部分。
    为了保证事务，接收表路由器在发送消息m到服务单元后，服务单元应向接收表路由器发送ack消息。当接收表接收到所有应接收到消息m的服务单元返回的ack消息后，接收表路由器向服务单元发送commit消息，服务单元接收到commit消息后，才真正接收消息m。这样就保证所有消息要么全部发送，要么都不发送，从而避免了有的服务单元得到消息而有的服务单元没有得到消息的情况的发生，保证了整个系统的一致性。
1. 4 服务单元失效处理策略
    以在应用ESB集成的系统环境中，服务单元可能会发生故障。为提高系统的可用性，采用以下服务单元失效处理策略。
    每个服务单元定时向ESB的接受表路由器发送消息available告知服务处于活动状态。每个服务单元保存ESB所集成的所有服务单元的信息表。该列表同时记录最后一次收到各个节点available消息的时间。
    当ESB的接受表路由器长时间收不到服务单元Ⅳ的available消息，则认为服务单元Ⅳ失效，接受表路由器删除本地全局路由表中有关该服务单元的路由信息及其规则库。

2 接收表的工作效率
    与ESB集成的服务单元中，如果只有较少数量的服务单元接收消息，则基于内容的路由算法，有一定的速度优势，但当有大多数服务单元接收消息的情况下，由于接收表同时向多个服务单元发送消息，则接收表路由算法的效率会更高。
    在基于内容的路由算法中，消息传递到服务单元的期望时间与接收此消息的服务单元的数理呈现线性增长(t=kn，t为从发送消息到所有消息都被服务单元接收所用的时间，n为服务单元的个数，k为系数)的关系。而应用接收表的算法中，消息传递到服务单元的期望时间与接收此消息的服务单元的数理呈现近似二次曲线(t2=kn)的关系。两种路由算法的效率比较情况，如图3所示。

3 结束语
    文中研究并设计了基于接收表的ESB路由算法，并对路由算法的效率、动态化、事务处理和失效处理等关键问题进行了分析。基于接收表的路由算法提高了消息交互的效率，并且保证了消息的安全性和实时性，是利用ESB进行系统集成的解决方案之一。