企业服务总线及企业服务总线的消息处理方法

摘要

一种企业服务总线及企业服务总线的消息处理方法，企业服务总线包括：消息接收单元，包括多个消息接收通道，每一消息接收通道用于接收包括至少一个服务请求的消息；消息队列单元，用于从所述多个消息接收通道接收消息，并按预定规则进行排序；处理线程组，用于从所述消息队列单元接收预定数量的已排序的消息；请求处理单元，用于从所述处理线程组中获取所述消息中的服务请求，并处理该服务请求。将各种应用程序整合于电子交易平台，并通过本发明的企业服务总线实现各个应用程序之间的调用，服务使用者不必进行复杂的异步调用，由企业服务总线来进行同步到异步模式的转换。

说明书

技术领域

本发明涉及电子商务交易技术领域，尤其涉及一种应用于电子商务交易平台的一种企业服务总线及企业服务总线的消息处理方法。

背景技术

目前，大型企业网之间的应用集成服务日益复杂，传统的点对点式的系统集成显得捉襟见肘。为了解决这一问题，人们提出了企业服务总线(enterprise service bus，简称ESB)的概念，即组成企业网的各个子系统以类似于接插件的方式接入一个公共的信息平台，彼此之间相对独立，由调度引擎进行统一的数据调度，以高效整合数据和业务流程。按照著名的IT研究与顾问咨询机构Gartner公司所给的定义，企业服务总线是一种体系结构，利用企业的Web服务、消息中间件、智能路由和转换技术实现，是传统中间技术与XML、Web服务等技术结合的产物，ESB提供了网络中最基本的连接中枢。企业服务总线技术的目标是以标准化的方式实现企业应用集成，完成企业间应用系统的互联、互通和互操作，其中的标准化工作包括连接器标准化、管理标准化、业务消息标准化和消息标准化等。

ESB的出现改变了传统的软件架构，可以提供比传统中间软件产品更为廉价的解决方案，同时它还可以消除不同应用服务之间的技术差异，让不同的应用服务协调运作，实现了不同服务之间的通信与整合。从功能上看，ESB提供了事件驱动和文档导向的处理模式，以及分布式的管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并提供一系列的标准接口。例如，申请号为“200810227316.9”的中国专利申请公开了一种企业服务总线的实现方法。

现有的电子商务交易平台，服务使用者直接调用服务提供者是多对多的，杂乱无序的，很难对行内的服务进行维护管理；服务调用者与后台服务的实现间耦合度过高，往往牵一发而动全身，后台服务究竟有多少调用者，应用调用了哪些服务不清导致维护困难，服务使用者和服务提供者之间的可靠性、事务处理、同步/异步通信、安全认证管理都需要两者之间单独实现，缺少一个公共的基础架构；并且，缺少对后台服务进行监控、统计并提供分析数据的统一途径，不便于对面向服务的体系结构(Service-Oriented Architecture，J简称SOA)的应用进行维护管理。

发明内容

本发明解决的问题是提供一种企业服务总线，将其应用于企业电子交易平台时，可以实现不同的应用程序之间整合，服务使用者不必进行复杂的异步调用，由服务总线来完成同步到异步模式的转换。

为解决上述问题，本发明提供一种企业服务总线，包括：

消息接收单元，包括多个消息接收通道，每一消息接收通道用于接收包括至少一个服务请求的消息；

消息队列单元，用于从所述多个消息接收通道接收消息，并按预定规则进行排序；

处理线程组，用于从所述消息队列单元接收预定数量的已排序的消息；

请求处理单元，用于从所述处理线程组中获取所述消息中的服务请求，并处理该服务请求。

可选的，所述按预定规则进行排序是指按消息发送或接收的时间顺序进行排序。

可选的，所述消息包括至少两个服务请求；

所述企业服务总线还包括：请求拆分单元，用于将所述消息拆分成服务请求后发送给所述消息接收单元。

可选的，所述消息包括至少两个服务请求；

所述企业服务总线还包括：请求拆分单元，用于将所述消息接收单元接收的消息拆分成服务请求后发送给所述消息队列单元。

可选的，所述消息包括至少两个服务请求；

所述企业服务总线还包括：请求拆分单元，用于将所述消息队列单元接收的消息拆分成服务请求后发送给所述处理线程组。

可选的，所述请求处理单元包括多种请求处理管道，每一种请求处理管道对应处理一种服务请求。

可选的，所述请求处理单元处理服务请求包括按预定的流程生成至少一个访问请求，并基于所述访问请求调用对应的应用服务。

可选的，还包括：请求传送通道，用于将从所述请求处理单元生成的访问请求发送给对应的应用服务。

可选的，所述包括至少一个服务请求的消息被加密，所述企业服务总线还包括解密单元，用于在所述请求处理单元按预定的流程处理服务请求前对所述消息进行解密。

为解决上述技术问题，本发明还提供一种企业服务总线的消息处理方法，包括：

接收消息，每一消息包括至少一个服务请求；

按预定规则对所述接收的消息进行排序；

处理预定数量的已排序的消息中的服务请求。

可选的，所述消息包括至少两个服务请求；

所述消息处理方法还包括：将所述消息拆分成服务请求。

可选的，所述处理服务请求包括：按预定的流程生成至少一个访问请求，并基于所述访问请求调用对应的应用服务。

可选的，所述包括至少一个服务请求的消息被加密；

在所述处理服务请求前还包括对所述消息进行解密。

与现有技术相比，本发明具有以下优点：

本发明提供的企业服务总线应用于电子交易平台时，服务使用者不必直接调用服务提供者提供的服务，服务使用者和服务提供者通过标准接口与电子交易平台连接，将各种应用程序整合于电子交易平台，并通过本发明的企业服务总线实现各个应用程序之间的调用，服务使用者不必进行复杂的异步调用，由企业服务总线来进行同步到异步模式的转换。

并且本发明的企业服务总线通过处理线程组限定电子交易平台可以处理的消息的数量，对超过该数量的消息不响应，避免对某个服务的调用的压力过大，造成电子交易平台当机。

附图说明

图1是本发明具体实施例的企业服务总线的内部架构示意图；

图2是请求处理单元的架构示意图；

图3是具体实施例的访问请求的处理流程框图；

图4是本发明具体实施例的企业服务总线应用于电子交易平台的示意图。

具体实施方式

本发明具体实施方式的企业服务总线应用于电子交易平台时，服务使用者不必直接调用服务提供者，服务使用者和服务提供者通过标准接口与电子交易平台连接，将各种应用服务整合于电子交易平台，并通过本发明的企业服务总线实现对各个应用服务的调用，服务使用者不必进行复杂的异步调用，由企业服务总线来进行同步到异步模式的转换；并且本发明的企业服务总线通过处理线程组限定电子交易平台可以处理的消息的数量，对超过该数量的消息不响应，避免对某个服务(应用服务)的调用的压力过大，造成电子交易平台当机。

参考图1，本发明具体实施方式的企业服务总线100，包括：消息接收单元110，用于接收多个服务使用者发送的消息，包括多个消息接收通道，分别为消息接收通道1、消息接收通道2……消息接收通道n，每一消息接收通道接收包括至少一个服务请求的消息；为了减少服务使用者对不同的服务请求分别进行操作，在一个消息接收通道里包括至少一个服务请求，服务使用者可以一次提出多个服务请求；在服务使用者一次提出多个服务请求时，通过请求打包单元将用户进行的多个服务请求打包后以消息的形式发送，在本发明的该具体实施例中，所述消息包括至少两个服务请求，所述企业服务总线还包括请求拆分单元(图中未示)，用于将所述消息拆分成服务请求后发送给所述消息接收单元110；在本发明的具体实施例中，消息接收通道还通过调用加密单元，将消息接收通道接收的消息加密。

消息队列单元120，用于从消息接收单元110中接收消息，并且将来自于多个消息接收通道的多个消息，根据时间顺序进行排队，时间在前的消息比时间在后的消息优先处理，在此的时间顺序对应于服务使用者提出请求操作的先后顺序，也可以是消息队列单元120接收消息的先后顺序，参考图1，排队后的消息队列分别为消息队列10、消息队列20……消息队列n0；且在消息进入消息队列单元120前，消息队列单元120调用请求拆分单元(图中未示)，由请求拆分单元将打包的消息拆分成服务请求，此服务请求的数量对应于服务使用者提出的服务请求数量，参考附图1，消息队列10中的消息被拆分成服务请求11，服务请求12，服务请求13，消息队列20中的消息被拆分成服务请求21，服务请求22，服务请求23，……消息队列n0中的消息被拆分成服务请求n1，服务请求n2，服务请求n3，需要说明的是，此例中每一消息被拆分成三个服务请求，只是起示例性，在具体的实施例中，每一消息中包括的服务请求数量根据具体情况(即服务端用户的操作)而定；需要说明的是，在本发明的该具体实施例中根据时间顺序对消息队列单元中的消息进行排队，在本发明的其他实施例中也可以根据其他预定规则对消息队列单元中的消息进行排队，例如根据消息的优先级(重要性)对消息队列单元中的消息进行排队。

在本发明的另一实施例中，将打包的消息进行拆分也可以在消息接收通道接收消息前，所述消息包括至少两个服务请求；所述企业服务总线还包括：请求拆分单元，用于将所述包括至少一个服务请求的消息拆分成服务请求后发送给所述消息队列接收单元。在本发明的其他实施例中，将打包的消息进行拆分也可以在处理线程组接收消息前，所述消息包括至少两个服务请求；所述企业服务总线还包括：请求拆分单元，用于从所述消息队列单元接收消息，并将所述消息队列单元接收的包括至少一个服务请求的消息拆分成服务请求后发送给所述处理线程组。

处理线程组130，包括预定数量的处理线程，分别为处理线程1、处理线程2……处理线程n，用于从所述消息队列单元120接收预定数量的已排序的消息；处理线程组130中的处理线程的数量为预定的数量，此数量根据电子交易平台的处理能力设定，例如，处理线程组130中的处理线程的数量为200个，则同一时间电子交易平台只能响应200个消息，对于第200个以后的消息，电子交易平台不响应，避免服务使用者过多造成电子交易平台当机的现象，从而可以确保电子交易平台的正常运行。其中，处理线程1储存消息队列10中的服务请求11、服务请求12、服务请求13，处理线程2储存消息队列20中的服务请求21、服务请求22、服务请求23，……处理线程n储存消息队列n0中的服务请求n1、服务请求n2、服务请求n3。

请求处理单元140，用于从所述处理线程组130中获取所述消息中的服务请求，并处理该服务请求；在该具体实施例中，请求处理单元140包括多种请求处理管道，每一种请求处理管道包括多个请求处理管道，每一种请求处理管道对应处理一种服务请求；参考图2，请求处理单元140包括多种请求处理管道，分别为第一种请求处理管道10、第二种请求处理管道20……第N种请求处理管道n0，每一种请求处理管道包括多个请求处理管道，每种请求处理管道可以处理多个相同类型的服务请求，以第一种请求处理管道10为例，该第一种请求处理管道10包括多个请求处理管道分别为请求处理管道11、请求处理管道12……请求处理管道1n；所述处理线程130从所述消息队列单元110获取消息，并将获取的已拆分成服务请求的消息处理后发送给对应的请求处理管道；需要说明的是，所述请求处理管道的种类与服务的种类请求存在对应的关系，每一种服务请求对应相同种类的请求处理管道，每一消息中包括的服务请求将会进入对应种类的请求处理管道中，由请求处理管道处理服务请求。其中，在该具体实施例中，每一种请求处理管道包括解密阶段(stage)，处理阶段(stage)，此解密阶段对应消息接收通道接收消息时，调用加密单元对消息加密，将加密的消息通过调用解密单元解密，在其他实施例中，每一种请求处理管道可以包括不同的阶段，例如也可以包括解压阶段。在本发明的该具体实施例中，所述处理阶段处理服务请求包括：按预定的流程生成至少一个访问请求，并基于所述访问请求调用对应的应用服务。其中，应用服务由服务提供者提供，通过访问请求调用应用服务，在请求处理管道的处理阶段为根据预定的预定的流程生成访问请求，由访问请求调用应用服务，应用服务根据访问请求进行处理，生成访问请求的处理结果。

在本发明的具体实施例中，企业服务总线还包括：请求传送通道，用于寻址，将从所述请求处理单元生成的访问请求发送给对应的应用服务。

以上所述为服务使用者发送消息至应用服务的处理过程，应用服务根据访问请求生成访问请求的处理结果要返回给服务使用者。在本发明的该具体实施例中，应用服务根据访问请求生成访问请求的处理结果返回给服务使用者的过程和服务使用者发送消息至应用服务的处理过程相反，首先通过请求传送通道将调用应用服务后的信息发送给对应的请求处理管道，由请求处理管道将信息加密后发送给对应的处理线程，请求处理线程将接收到的服务请求的结果发送给对应的消息队列，之后发送给对应的消息接收通道，当一个消息中包括的所有的服务请求结果都返回其对应的消息接收通道时，消息接收通道调用请求打包单元，将一个消息中包括的所有消息打包后发送给相应的服务使用者，此时用户可以得到所发送的消息的处理结果。需要说明的是，在此使用“对应”一词的意思为，返回的消息、请求经由来时的路径返回。

本发明中的所述消息可以为各种商品的交易消息，以钢材的电子商务交易为例，商品为钢材，交易消息包括发布钢材现货的交易消息(对应于钢材的出库、入库)，合约的交易信息(对应于采购、销售的意向)，还包括注册消息(对应于注册成为电子交易平台的会员)，更新商品消息，注销消息(对应于注销电子交易平台的会员)，更新注册消息(对应于更新会员信息)，积分查询、信用查询等。

以服务使用者需要查询积分和信用等与用户信息有关的信息为例说明，服务使用者发送查询用户信息，消息接收单元中消息接收通道接收查询用户信息的消息，由于用户信息包括积分、信用等信息，查询用户信息的消息包括积分服务请求，信用服务请求等，将查询用户信息对应的积分服务请求、信用服务请求等打包，之后发送给消息接收单元的消息接收通道；消息接收通道接收到查询用户信息的消息后，调用加密模块，对该查询用户消息加密，之后将该查询用户信息的消息发送给消息队列单元，也可以由消息队列单元从消息接收通道中获取查询用户信息的消息，在消息队列单元接收消息时调用请求拆分单元，将查询用户信息拆分成对应的积分服务请求、信用服务请求等，因此进入消息队列单元中的查询用户消息为拆分后的服务请求，参考图1，如果查询用户消息对应于消息10，则积分服务请求对应于服务请求11，信用服务请求对应于服务请求12；之后积分服务请求、信用服务请求等经由处理线程后进入服务请求对应的请求处理管道，积分服务请求进入积分服务请求对应的请求处理管道，信用服务请求进入信用服务请求对应的请求处理管道，例如，积分服务请求进入第一种请求处理管道10中的请求处理管道11、信用服务请求进入第二种请求处理管道20中的请求处理管道，由各自对应的请求处理管道对积分服务请求、信用服务请求进行处理后生成访问请求，以积分服务请求为例，积分服务请求对应的请求处理管道首先经解密阶段将加密的积分服务请求解密，解密后进入积分服务请求的处理阶段生成调用积分数据库的访问请求，从数据库中查询积分。

以上所述的具体实施例的积分服务请求的处理阶段，没有涉及具体的业务，只是简单的积分的查询，因此并没有涉及业务流程。电子交易平台涉及具体的交易业务，必然会有业务流程，根据预定的业务流程才可以使业务顺利的进行，而且预定的流程将决定完成一个交易需要的消息的种类。

利用本发明的企业服务总线的电子交易平台的具体实施必须依靠具体的业务流程，以确保电子交易的顺利进行，根据具体的交易可以设定不同的业务流程，该业务流程对应于预定流程，并且该业务流程存储于流程单元中，在具体执行服务请求时，根据服务请求的处理阶段的需求调用业务流程。

以电子商务交易中的合约交易为例说明业务流程在处理阶段的作用。图3为完成一次合约交易的具体实施例的业务流程，根据图3所示的具体实施例的业务流程，将合约交易分成四种消息：分别为标准合约发布200，对应于第一种消息；申请结算单位关联300，对应于第二种消息；合约执行400，对应于第三种消息；合约履约申请500，对应于第四种消息；首先会员发布标准合约，然后申请绑定结算单位，公司审核通过后，合约才开始生效，进入生效合约，然后可以执行合约，进入执行中合约阶段，合约执行完毕或者执行到一定程度后，会员可以申请履约，进入履约中合约，合约履行完毕后，进入已履约合约，此时合约执行完毕。在此，以发布合约为例进行说明，对于其他种类的交易，根据交易的种类，可以根据预定的流程分为不同的种类的消息。

参考图3详细说明根据该预定的流程执行合约交易的实施过程。

当服务使用者执行标准合约发布200，此消息即为一个服务请求，无需再对其进行拆分，在请求处理管道中执行标准合约发布消息的处理阶段时，请求处理管道从流程单元中调用图3所示的业务流程，请求处理管道根据与标准合约发布有关的业务流程中的预定的规则将该服务请求分成多个步骤，具体为：步骤201，检查合约价格是否通过，此时请求处理管道调用数据库中的合约价格，如果合约价格通过，进行步骤202，检查发布人会员信用是否够用，此时请求处理管道调用信用模块，如果会员信用不够用不能发布合约，如果会员信用够用，可以发布合约，并产生标准合约会员信用占用，通过信用模块修改标准合约会员的信用，之后进行步骤203，生成标准合约，并将生成标准合约的结果反馈给服务使用者，完成标准合约发布的服务请求。

继续参考图3，电子交易平台的管理者看到发布的标准合约，想要购买该发布的标准合约，使之成为生效合约时，执行申请结算单位(对应于真实的客户)关联300，此为第二种消息，此消息即为一个服务请求，无需再对其进行拆分，请求处理管道根据业务流程中的预定的规则将该服务请求分成多个步骤，具体为：步骤301，业务管理人员审核，其中审核的内容根据实际的需要进行规定，如果审核未通过，合约不能关联结算单位，并将该不能关联结算单位的结果发送给服务使用者；如果审核通过，进行步骤302，业务管理人员手工输入合约预计亏损占用，并产生关联合约风险信用占用(对应会员信用)，此时同时调用信用模块，通过信用模块更改会员信用，之后进入步骤303，业务管理人员上传合约文本扫描件，建立真实的客户合约，并同时把真实客户合约扫描件作为关联合约附件，接下来进入步骤304，产生关联合约信用占用(对应交易信用)，同时释放标准合约信用占用(对应于会员信用)，此时通过调用信用模块完成对交易信用的占用和会员信用的释放，进入步骤305，关联合约生成成功，产生生效合约的结果，并将该结果返回。

继续参考图3，在进行合约执行400时，对应第三种消息，此消息即为一个服务请求，无需再对其进行拆分，请求处理管道根据预定流程的预定的规则将执行生效合约具体分为：步骤401，发现货，发现货后，合约由生效合约进入执行中合约，此时可以调用信用模块，按照执行量和合约量的比例释放部分或全部的关联合约信用，并将结果通过消息接收通道发送给服务使用者。

当服务使用者将现货发货，收货人收到货物后，将进行合约履约申请500，对应于第四种消息，此消息即为一个服务请求，无需再对其进行拆分，请求处理管道根据预定流程的预定规则将该服务请求分成多个步骤具体为：步骤501，公司审核，如果审核未通过，输出结果不能履约，如果审核通过，释放合约未履约占用信用，调用信用模块，完成释放合约未履约占用信用，完成合约的履行后，进入步骤502，履约中合约转化为已履约合约；此时可以调用积分模块，进行合约积分考核分配。

以上所述的本发明提供的企业服务总线应用于电子交易平台时，服务使用者不必直接调用服务提供者提供的服务，服务使用者和服务提供者通过标准接口与电子交易平台连接，将各种应用程序整合于电子交易平台，并通过本发明的企业服务总线实现各个应用程序(在该具体实施例中以信用模块为例进行说明)之间的调用，服务使用者不必进行复杂的异步调用，由企业服务总线来进行同步到异步模式的转换。

以上所述的具体实施例，仅以一个单独的合约信息为例进行说明，在具体实例中，会同时有多个不同的客户端发送信息，通过设置处理线程组中线程的数量，使线程组一次只能处理一定数量线程的消息，避免对某个服务的调用的压力过大，造成电子交易平台当机。

本发明的企业服务总线存在于JVM(Java Virtual Machine，Java虚拟机)中。企业服务总线外部的节点是外部服务使用者和服务提供者，代表了企业服务总线要集成的外部实体，这些外部实体可以通过各种各样的技术与企业服务总线绑定的服务模块交互。

图4为企业服务总线应用于电子交易平台的框架示意图，

企业服务总线100与流程单元600连接，所述流程单元600，用于向服务总线提供与所述服务请求对应的处理流程。并且，在该电子交易平台上，设有用户端接口801，可以供用户1、用户2……用户n接入电子交易平台，需要注册成为电子交易平台的用户由用户管理单元803管理注册，要注册成为电子交易平台的用户必须通过用户管理单元803的身份验证后才可以成为电子交易平台的用户；且企业服务总线设有服务端接口，供应用服务1、应用服务2……应用服务n接入电子交易平台，服务提供者向电子交易平台提供应用服务时，首先必须经过服务管理单元804的验证，经服务管理单元804验证的应用服务才可以通过企业服务总线发布到电子交易平台。

与以上所述的企业服务总线对应，本发明还提供一种企业服务总线的消息处理方法，包括：接收消息，每一消息包括至少一个服务请求；

按预定规则对所述接收的消息进行排序；

处理预定数量的已排序的消息中的服务请求。

其中，所述消息包括至少两个服务请求；所述消息处理方法还包括：将所述消息拆分成服务请求。

所述处理服务请求包括：按预定的流程生成至少一个访问请求，并基于所述访问请求调用对应的应用服务。

所述包括至少一个服务请求的消息被加密；在所述处理服务请求前还包括对所述消息进行解密。

本发明虽然已以较佳实施例公开如上，但其并不是用来限定本发明，任何本领域技术人员在不脱离本发明的精神和范围内，都可以利用上述揭示的方法和技术内容对本发明技术方案做出可能的变动和修改，因此，凡是未脱离本发明技术方案的内容，依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化及修饰，均属于本发明技术方案的保护范围。