CN102214187A

CN102214187A - 复合事件处理方法及装置

Info

Publication number: CN102214187A
Application number: CN2010101473589A
Authority: CN
Inventors: 蔡学镛
Original assignee: Alibaba Group Holding Ltd
Current assignee: Advanced New Technologies Co Ltd
Priority date: 2010-04-12
Filing date: 2010-04-12
Publication date: 2011-10-12
Anticipated expiration: 2030-04-12
Also published as: CN102214187B

Abstract

本申请实施例公开了一种复合事件处理方法及装置，所述方法包括：接收到基础事件后，根据所述基础事件的事件信息确定所述基础事件所属的事件模式，所述基础事件中携带事件标识；将所述基础事件输入与所述事件标识对应的状态机实例，所述状态机实例为按照所述基础事件所属的事件模式定义的状态机所创建的实例，属于同一个状态机实例的基础事件具有相同的事件标识；根据所述状态机实例的状态迁移结果输出复合事件。本申请实施例通过状态机实例的状态迁移结果输出复合事件，由此节约了系统为存储大量基础事件所耗费的存储空间，并且由于可以根据实际应用需求变换对某个事件模式的状态机定义，因此增强了系统对复合事件处理的灵活性。

Description

复合事件处理方法及装置

技术领域

本申请涉及网络技术领域，尤其涉及一种复合事件处理方法及装置。

背景技术

基于互联网实现各种业务功能时，会产生海量的基础事件(Base Event)，包括各种销售数据、业务数据、系统之间的交互数据等，这些基础事件仅反映了业务功能的片面信息，且信息量庞大，难以从中获取有用信息。因此，需要对海量的基础事件进行处理以提取出有用的复合事件(Complex Event)。例如，某个商品销售时被POS机扫描，此时会触发一个基础事件至后台服务器，而后台服务器结合众多商品出售的基础事件，分析得到该商品的销售趋势信息即为复合事件处理后得到的复合事件信息。

现有技术中，复合事件处理(Complex Event Process，CEP)基于数据库系统实现，预先对基础事件进行分类，同一类型的基础事件具有相同的字段，用于保存基础事件的信息，同一类型的基础事件被存放在数据库的同一个数据库表中；多个有关联的基础事件形成一种事件模式，以支付宝(www.alipay.com)的担保交易为例，担保交易为一种事件模式，这个事件模式下包含了相互关联的五个基础事件，分别为创建交易、买家付款到中介机构、卖家发货、买家收货和中间机构付款到卖家；在进行复合事件处理时，采用结构化查询语言(Structured Query Language，SQL)对数据库表进行查询，从中找出复合事件，例如，如果从数据库表中依次找到担保交易模式的五个基础事件，则表示找到一个交易正常完成的复合事件，如果无法顺序查找到这五个基础事件，则返回交易系统异常的复合事件，进行报警。

发明人在对现有技术的研究过程中发现，现有复合事件处理都基于数据库实现，每个数据库表要预先定义字段及对字段的限制，因此难以根据实际应用灵活调整，并且数据库内需要存储海量的基础事件信息，因此将占用系统的大量存储空间；另外，数据库查询语言难以描述和查询复杂的复合事件，因此限制了复合事件处理的应用范围。

发明内容

本申请实施例的目的是提供一种复合事件处理方法及装置，以解决现有技术中基于数据库进行复合事件处理时占用大量存储空间，且难以对复杂事件进行处理的问题。

为解决上述技术问题，本申请实施例提供了一种复合事件处理方法，是这样实现的：

一种复合事件处理方法，所述方法包括：

接收到基础事件后，根据所述基础事件的事件信息确定所述基础事件所属的事件模式，所述基础事件中携带事件标识；

将所述基础事件输入与所述事件标识对应的状态机实例，所述状态机实例为按照所述基础事件所属的事件模式定义的状态机所创建的实例，属于同一个状态机实例的基础事件具有相同的事件标识；

根据所述状态机实例的状态迁移结果输出复合事件。

为解决上述技术问题，本申请实施例还提供了一种复合事件处理装置，是这样实现的：

一种复合事件处理装置，包括：

接收单元，用于接收基础事件；

确定单元，用于根据所述基础事件的事件信息确定所述基础事件所属的事件模式，所述基础事件中携带事件标识；

输入单元，用于将所述基础事件输入与所述事件标识对应的状态机实例，所述状态机实例为按照所述基础事件所属的事件模式定义的状态机所创建的实例，属于同一个状态机实例的基础事件具有相同的事件标识；

输出单元，用于根据所述状态机实例的状态迁移结果输出复合事件。

可见，本申请实施例中接收到基础事件后，根据基础事件的事件类型确定基础事件所属的事件模式，将基础事件输入与该基础事件的事件标识对应的状态机实例，并根据状态机实例的状态迁移结果输出复合事件。由于本申请复合事件处理的实施例无需数据库支持，通过状态机实例的状态迁移结果输出复合事件，由此节约了系统为存储大量基础事件所耗费的存储空间，并且由于可以根据实际应用需求变换对某个事件模式的状态机定义，因此增强了系统对复合事件处理的灵活性；由于复合事件的处理都基于状态机进行，无需运用大量的查询语言，因此只需定义状态机，就可处理各种复杂的复合事件，扩展了复合事件处理的应用范围。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请复合事件处理方法的第一实施例流程图；

图2A为本申请复合事件处理方法的第二实施例流程图；

图2B为本申请一种应用实例中担保交易的事件模式状态机定义示意图；

图3为本申请复合事件处理装置的第一实施例框图；

图4为本申请复合事件处理装置的第二实施例框图。

具体实施方式

本申请实施例提供一种复合事件处理方法及装置，对接收到的基础事件，根据预先定义的事件模式对应的状态机输出相应的复合事件，从而可以针对复合事件进行报警或者对复合事件进行所需要的处理。

为了使本技术领域的人员更好地理解本申请实施例中的技术方案，并使本申请实施例的上述目的、特征和优点能够更加明显易懂，下面结合附图对本申请实施例中技术方案作进一步详细的说明。

参见图1，为本申请复合事件处理方法的第一实施例流程图：

步骤101：接收到基础事件后，根据基础事件的事件信息确定该基础事件所属的事件模式。

事件模式是对一系列相互关联的基础事件的总称，每种事件模式都包含了顺序执行的多个基础事件。以支付宝的担保交易为例，担保交易是一种需要关心是否发货的事件模式，担保交易包括的基础事件有创建交易、买家付款到中间机构、卖家发货、买家收货和中间机构付款到卖家；另外，即时到账也是一种事件模式，这种事件模式不需要关心是否发货。

本申请实施例中，为每种事件模式定义一个状态机，这个状态机中包含了若干迁移状态，从初始状态开始，该事件模式包含的顺序执行的每个基础事件都对应一个迁移状态，以一个包含三个基础事件的事件模式A为例，假设基础事件的执行顺序应为基础事件1、基础事件2、基础事件3，则从初始状态开始，应顺序执行基础事件1，相应的从初始状态迁移到状态1，然后执行基础事件2，相应的从状态1迁移到状态2，最后执行基础事件3，相应的从状态2迁移到结束状态。

每个基础事件中都携带了事件信息，以担保交易中的创建交易这个基础事件为例，该基础事件的事件类型就为“创建交易”，其包含的事件信息包括：交易序号、买家账号、卖家账号、商品描述、交易金额、事件模式。当接收到一个创建交易的基础事件后，根据该基础事件的事件信息就可以确定该基础事件所属的事件模式为“担保交易”。当系统中定义了多个事件模式时，可以为每个事件模式分配一个模式标识，则通过在基础事件中携带该模式标识来实现对其所属事件模式的识别。

步骤102：将该基础事件输入与其事件标识对应的状态机实例。

仍然以担保交易这个事件模式为例，在该事件模式定义的状态机下，可能需要处理若干笔交易，则为每笔交易都创建一个状态机实例，属于同一个状态机实例的基础事件都具有相同的事件标识，这个事件标识应可以唯一识别一笔交易，例如使用交易序号。

在担保交易所定义的状态机中，各个基础事件携带的事件信息如下：

创建交易携带事件信息：交易序号、买家帐号、卖家帐号、商品描述、交易金额、事件模式；

买家付款到中间机构携带事件信息：交易序号、买家帐号、交易金额；

卖家发货携带事件信息：交易序号、卖家帐号、商品描述；

买家收货携带事件信息：交易序号、买家帐号、商品描述；

中间机构付款到卖家携带事件信息：交易序号、卖家帐号、交易金额。

由此可知，上述担保交易的每个基础事件中都包含了“交易序号”，因此可以将交易序号作为每个状态机实例的唯一标识，当接收到一个基础事件后，读取该基础事件中的交易序号，就可以将该基础事件输入到与该交易序号唯一对应的状态机实例中。

步骤103：根据状态机实例的状态迁移结果输出复合事件，结束当前流程。

查找状态机实例所迁移的当前状态，根据基础事件的事件类型判断状态机实例是否能够从当前状态顺序迁移到下一状态，若判断结果为是，则迁移到下一状态，并进一步判断下一状态是否为状态机实例的结束状态，若是结束状态，则输出系统事件完成的复合事件，若不是结束状态，则将下一状态保存为状态机实例的当前状态；若不能从当前状态迁移到下一状态，则输出系统异常的复合事件。

仍然以前述包含三个基础事件的事件模式为例，假设当前收到基础事件2，在找到该基础事件2对应的状态机实例后，可以查看该状态机实例当前所迁移的状态，假如该状态机实例已经迁移到状态1，则根据接收的基础事件2可以判断该状态机实例能够从状态1迁移到状态2，由于状态2仍然不是该状态机实例的结束状态，因此保存状态2为该状态机实例的当前状态，以便后续接到其它基础事件后依据该保存的当前状态进行复合事件处理；假如该状态机实例已经迁移到状态2，则根据接收的基础事件2判断该状态机实例无法进行状态迁移，因此输出系统异常的复合事件，并可据此结果进行报警。

参见图2A，为本申请复合事件处理方法的第二实施例流程图，该实施例示出了复合事件处理的详细过程：

步骤201：预先为每个事件模式定义状态机，该状态机中包含按照基础事件的事件类型顺序迁移的若干状态。

参见图2B为，为一种担保交易的事件模式状态机定义示意图：

其中，担保交易包括的基础事件有基础事件1(创建交易)、基础事件2(买家付款到中间机构)、基础事件3(卖家发货)、基础事件4(买家收货)和基础事件5(中间机构付款到卖家)；相应的，担保交易的状态机中包含了六个状态，分别为状态1(初始状态)、状态2(等待买家付款)、状态3(等待卖家送货)、状态4(等待买家收货)、状态5(等待向卖家付款)和状态6(结束状态)。

结合图2B，描述该状态机的完整状态迁移过程：

初始，状态机处于状态1；

接收到基础事件1(创建交易，ET-CREATE)后状态变迁，进入状态2(等待买家付款)，此时只需要记录当前的状态为状态2，不需要保留基础事件1的所有事件信息；

接收到基础事件2(买家付款到中间机构，ET-BUYER-TO-ALIPAY)后状态变迁，进入状态3(等待卖家送货)，此时只需要记录当前的状态为状态3，不需要保留基础事件1和基础事件2的所有事件信息；

接收到基础事件3(卖家发货ET-SELLER-SHIP)后状态变迁，进入状态4(等待买家收货)，此时只需要记录当前的状态为状态4，不需要保留基础事件1、基础事件2和基础事件3的所有事件信息；

接收到基础事件4(买家收货，ET-BUYER-RECEIVE)后状态变迁，进入状态5(等待向卖家付款)，此时只需要记录当前的状态为状态5，不需要保留基础事件1、基础事件2、基础事件3和基础事件4的所有事件信息；

接收到基础事件5(中间机构付款到卖家，ET-ALIPAY-TO-SELLER)后状态变迁，进入状态6(结束状态)，此时只需要记录当前的状态为状态6，不需要保留基础事件1、基础事件2、基础事件3、基础事件4和基础事件5的所有事件信息；当进入状态6(结束状态)时，表示找到一个复合事件。

由于本申请实施例中状态机可以随着基础事件进行状态迁移，这个过程中只需要记录当前所迁移到的状态即可，无需记录所有基础事件信息，因此与现有技术相比，节约了大量系统存储空间。

步骤202：接收到基础事件后，对该基础事件携带的信息进行格式转换。

通常复合事件处理中心可以接收通过网络传输的基础事件，例如，支付宝交易过程中触发的每个基础事件都通过网络发送到服务器端的复合事件处理中心。

通过对基础事件携带的事件信息进行格式转换得到事件类型、事件标识、事件描述等，以便于根据这些信息执行复合事件处理的后续步骤。转换后的事件信息可以采用如下格式：字段1＝值1；字段2＝值2；......；例如，对于一个基础事件“创建交易”，其转换格式后的事件信息包括：事件类型＝“ET-CREATE”；交易序号＝“12212319”；买家帐号＝“1522326223”；卖家帐号＝“242326893”；商品描述＝“HL-220三件”；交易金额＝“540.00”。

步骤203：根据基础事件的事件信息确定基础事件所属的事件模式。

步骤204：根据事件标识判断是否已经创建与该事件标识对应的状态机实例，若是，则执行步骤207；否则，执行步骤205。

以担保交易为例，其所对应的每个状态机实例都通过“交易序号”来唯一标识，当接收的基础事件为携带了交易序号“12212319”的“创建交易”时，读取该交易序号，由于“创建交易”为状态机中顺序执行的首个基础事件，因此查找不到该交易序号“12212319”对应的状态机实例(若创建，则记为实例A)；当接收到的基础事件为携带了交易序号“22212319”的“买家收货”时，读取该交易序号，由于“买家收货”为状态机中顺序执行的第四个基础事件，因此通常可以查找到该交易序号22212319”对应的状态机实例(记为实例B)。

步骤205：判断该基础事件的事件类型是否为所创建状态机的初始状态对应的事件类型，若是，则执行步骤206；否则，执行步骤214。

如果判断还未创建与接收到的基础事件的事件标识对应的状态机实例，则需要进一步判断该基础事件是否为初始状态对应的事件类型。以担保交易为例，当接收到的基础事件“买家收货”携带的交易序号为“12345”，且未查找到与该交易序号对应的状态机实例，此时判断“买家收货”对应的状态并非初始状态；如果接收到的基础事件“创建交易”携带的交易序号为“12345”，且未查找到与该交易序号对应的状态机实例，此时判断“创建交易”对应的状态为初始状态。

步骤206：创建与事件标识对应的状态机实例。

如果接收到的基础事件“创建交易”携带的交易序号为“12345”，且未查找到与该交易序号对应的状态机实例，在判断“创建交易”对应的状态为初始状态后，可以根据交易序号“12345”创建一个新的状态机实例。

步骤207：将该基础事件输入与其事件标识对应的状态机实例。

步骤208：查找状态机实例所迁移的当前状态。

假设接收到的基础事件为“买家收货”，根据该基础事件中携带的交易序号找到对应的状态机实例B后，查看该状态机实例B中的当前迁移状态。

步骤209：根据该基础事件的事件类型判断状态机实例是否能够从当前状态顺序迁移到下一状态，若是，则执行步骤210；否则，执行步骤213。

如果状态机实例B当前已经顺序迁移到了状态4，则说明该状态机实例B根据“买家收货”这个基础事件4能够顺序迁移到状态5；如果状态机实例B当前迁移到了除状态4外的其它状态，则说明该状态机实例B根据“买家收货”这个基础事件4难以从当前状态进行迁移。

步骤210：判断下一状态是否为状态机实例的结束状态，若是，则执行步骤211；否则，执行步骤212。

步骤211：输出系统事件完成的复合事件，结束当前流程。

状态机实例的状态从初始状态顺序迁移到结束状态后，则表示一个复合事件完成，输出该复合事件完成的结果。

步骤212：将下一状态保存为状态机实例的当前状态，结束当前流程。

假设状态机实例B根据“买家收货”这个基础事件4，从状态4顺序迁移到了状态5，由于状态5不是结束状态，因此将该状态5记录为状态机实例B的当前状态。

步骤213：输出系统异常的复合事件，结束当前流程。

如果状态机实例B根据“买家收货”这个基础事件4难以从当前状态进行迁移，则会产生系统异常的复合事件，并可进一步输出报警信息。

步骤214：丢弃该基础事件，结束当前流程。

当接收到的基础事件“买家收货”携带的交易序号为“12345”，且未查找到与该交易序号对应的状态机实例，则判断“买家收货”对应的状态并非初始状态后，说明该基础事件无用，丢弃该基础事件即可。

与本申请复合事件处理方法的实施例相对应，本申请还提供了复合事件处理装置的实施例。

参见图3，为本申请复合事件处理装置的第一实施例框图。

该复合事件处理装置包括：接收单元310、确定单元320、输入单元330和输出单元340。

其中，接收单元310，用于接收基础事件；

确定单元320，用于根据所述基础事件的事件信息确定所述基础事件所属的事件模式，所述基础事件中携带事件标识；

输入单元330，用于将所述基础事件输入与所述事件标识对应的状态机实例，所述状态机实例为按照所述基础事件所属的事件模式定义的状态机所创建的实例，属于同一个状态机实例的基础事件具有相同的事件标识；

输出单元340，用于根据所述状态机实例的状态迁移结果输出复合事件。

参见图4，为本申请复合事件处理装置的第二实施例框图。

该复合事件处理装置包括：预设单元410、接收单元420、转换单元430、确定单元440、判断单元450、执行单元460、输入单元470和输出单元480。

其中，预设单元410，用于预先为每个事件模式定义状态机，所述状态机中包含按照基础事件的事件类型顺序迁移的若干状态；

接收单元420，用于接收基础事件；

转换单元430，用于对所述接收单元接收的基础事件携带的信息进行格式转换，所述格式转换后的信息包括事件类型、事件标识和事件描述；

确定单元440，用于根据所述基础事件的事件信息确定所述基础事件所属的事件模式，所述基础事件中携带事件标识；

判断单元450，用于根据所述事件标识判断是否已经创建与所述事件标识对应的状态机实例；

执行单元460，用于当所述判断单元450的判断结果为是时，触发所述输入单元470的功能；

进一步，所述判断单元450，还用于当所述判断单元450的判断结果为否时，进一步判断所述基础事件的事件类型是否为所述状态机的初始状态对应的事件类型；

进一步，所述执行单元460，还用于当所述判断单元450判断是初始状态对应的事件类型时，创建与所述事件标识对应的状态机实例，当所述判断单元450判断不是初始状态对应的事件类型时，丢弃所述基础事件；

输入单元470，用于将所述基础事件输入与所述事件标识对应的状态机实例，所述状态机实例为按照所述基础事件所属的事件模式定义的状态机所创建的实例，属于同一个状态机实例的基础事件具有相同的事件标识；

输出单元480，用于根据所述状态机实例的状态迁移结果输出复合事件。

具体的，所述输出单元480可以包括(图4中未示出)：状态查找单元，用于查找所述状态机实例所迁移的当前状态；状态判断单元，用于根据所述基础事件的事件类型判断所述状态机实例是否能够从所述当前状态顺序迁移到下一状态；结果执行单元，用于当所述状态判断单元的判断结果为是时，迁移到所述下一状态，当所述状态判断单元的判断结果为否时，输出系统异常的复合事件；进一步，所述状态判断单元，还用于当迁移到所述下一状态后，判断所述下一状态是否为所述状态机实例的结束状态；所述结果执行单元，还用于当所述状态判断单元的判断结果为是时，输出系统事件完成的复合事件，当所述状态判断单元的判断结果为否时，将所述下一状态保存为所述状态机实例的当前状态。

通过以上的实施方式的描述可知，本申请实施例中接收到基础事件后，根据基础事件的事件类型确定基础事件所属的事件模式，将基础事件输入与该基础事件的事件标识对应的状态机实例，并根据状态机实例的状态迁移结果输出复合事件。由于本申请复合事件处理的实施例无需数据库支持，通过状态机实例的状态迁移结果输出复合事件，由此节约了系统为存储大量基础事件所耗费的存储空间，并且由于可以根据实际应用需求变换对某个事件模式的状态机定义，因此增强了系统对复合事件处理的灵活性；由于复合事件的处理都基于状态机进行，无需运用大量的查询语言，因此只需定义状态机，就可处理各种复杂的复合事件，扩展了复合事件处理的应用范围。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本申请可用于众多通用或专用的计算系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

虽然通过实施例描绘了本申请，本领域普通技术人员知道，本申请有许多变形和变化而不脱离本申请的精神，希望所附的权利要求包括这些变形和变化而不脱离本申请的精神。

Claims

1.一种复合事件处理方法，其特征在于，所述方法包括：

根据所述状态机实例的状态迁移结果输出复合事件。

2.根据权利要求1所述的方法，其特征在于，还包括：

预先为每个事件模式定义状态机，所述状态机中包含按照基础事件的事件类型顺序迁移的若干状态。

3.根据权利要求1所述的方法，其特征在于，所述接收到基础事件后，还包括：对所述基础事件携带的事件信息进行格式转换，所述格式转换后的事件信息包括事件类型、事件标识、事件描述、事件模式之一或其组合。

4.根据权利要求1所述的方法，其特征在于，所述将基础事件输入与所述事件标识对应的状态机实例之前还包括：

根据所述事件标识判断是否已经创建与所述事件标识对应的状态机实例；

若判断结果为是，则执行所述将基础事件输入与事件标识对应的状态机实例，若判断结果为否，则创建与所述事件标识对应的状态机实例。

5.根据权利要求4所述的方法，其特征在于，还包括：

当所述判断结果为否时，判断所述基础事件的事件类型是否为所述状态机的初始状态对应的事件类型；

若判断结果为是，则执行所述创建与事件标识对应的状态机实例，若判断结果为否，则丢弃所述基础事件。

6.根据权利要求1至5任意一项所述的方法，其特征在于，所述根据所述状态机实例的状态迁移结果输出复合事件包括：

查找所述状态机实例所迁移的当前状态；

根据所述基础事件的事件类型判断所述状态机实例是否能够从所述当前状态顺序迁移到下一状态；

若判断结果为是，则迁移到所述下一状态，否则判断结果为否，则输出系统异常的复合事件。

7.根据权利要求6所述的方法，其特征在于，还包括：

当迁移到所述下一状态后，判断所述下一状态是否为所述状态机实例的结束状态；

若判断结果为是，则输出系统事件完成的复合事件，若判断结果为否，则将所述下一状态保存为所述状态机实例的当前状态。

8.一种复合事件处理装置，其特征在于，包括：

接收单元，用于接收基础事件；

9.根据权利要求8所述的装置，其特征在于，还包括：

预设单元，用于预先为每个事件模式定义状态机，所述状态机中包含按照基础事件的事件类型顺序迁移的若干状态。

10.根据权利要求8所述的装置，其特征在于，还包括：

转换单元，用于对所述接收单元接收的基础事件携带的事件信息进行格式转换，所述格式转换后的事件信息包括事件类型、事件标识和事件描述、事件模式之一或其组合。

11.根据权利要求8所述的装置，其特征在于，还包括：

判断单元，用于根据所述事件标识判断是否已经创建与所述事件标识对应的状态机实例；

执行单元，用于当所述判断单元的判断结果为是时，触发所述输入单元的功能，当所述判断单元的判断结果为否时，创建与所述事件标识对应的状态机实例。

12.根据权利要求11所述的装置，其特征在于，所述判断单元，还用于当判断结果为否时，进一步判断所述基础事件的事件类型是否为所述状态机的初始状态对应的事件类型；

所述执行单元，还用于当所述判断单元判断是初始状态对应的事件类型时，执行所述创建与所述事件标识对应的状态机实例，当所述判断单元判断不是初始状态对应的事件类型时，丢弃所述基础事件。

13.根据权利要求8至12任意一项所述的装置，其特征在于，所述输出单元包括：

状态查找单元，用于查找所述状态机实例所迁移的当前状态；

状态判断单元，用于根据所述基础事件的事件类型判断所述状态机实例是否能够从所述当前状态顺序迁移到下一状态；

结果执行单元，用于当所述状态判断单元的判断结果为是时，迁移到所述下一状态，当所述状态判断单元的判断结果为否时，输出系统异常的复合事件。

14.根据权利要求13所述的装置，其特征在于，所述状态判断单元，还用于当迁移到所述下一状态后，判断所述下一状态是否为所述状态机实例的结束状态；

所述结果执行单元，还用于当所述状态判断单元的判断结果为是时，输出系统事件完成的复合事件，当所述状态判断单元的判断结果为否时，将所述下一状态保存为所述状态机实例的当前状态。