基于企业的有相互关系的事件的消息次序管理的制作方法

专利名称：：基于企业的有相互关系的事件的消息次序管理的制作方法
技术领域：
：本公开总体上涉及标识和管理服务请求。更具体地，本公开涉及在多应用的企业中管理与服务请求相关的消息。
背景技术：
：通信业持续面临着更多服务以及快速部署新服务的需求，同时，提供服务的基础技术的复杂性持续增加。服务提供商需要使居民消费者和商业消费者都能够容易地激活和管理服务请求的系统。电信服务提供商将消费者选择期望服务以及至少采取基本步骤来定购该服务的能力作为关键的市场区分器(marketdifferentiator)。消费者基于可用的服务的数量和消费者对服务的使用及激活的方便性来评估服务提供商。消费者还将发起服务请求到成功的服务激活之间的周期作为主要的市场区分器。提供电信服务涉及很多复杂的和技术上的细节，并且经常跨越位于各种技术平台和多个地理位置的多个应用和系统。对于任意给定的服务请求，可能需要访问、使用和更新多个这样的系统。这些系统彼此之间可能完全无关。例如，计费系统很可能不同于订单处理系统。而且，一个企业可以具有位于多个地理位置的多个计费系统。此外，访问、使用和更新这种系统的精确次序对于给定服务请求的成功执行而言至关重要。而且，同时处理多个相关的和不相关的请求都可能阻塞网络资源，并且在请求没有得到恰当处理的情况下导致错误，从而引起明显的人工千预。需要人工干预可能显著地增加为消费者提供可接受的客户服务水平的关联成本。此外，如果没有恰当地处理事件所需的精确执行次序，则可能导致电信服务提供商的利润损失以及受挫的消费者对电信服务提供商失去信任。例如，如果在消费者与电信服务提供商进行交互时发生了错误，则消费者可能会中断该过程并选择其他电信服务提供商。目前，电信服务提供商为了创建在多个不同应用和地理位置中处理服务请求的框架，电信服务提供商实现了面向其独特业务的一系列软件应用。这花费了大量的时间，并且对于电信服务提供商而言相当昂贵。此外，利用市场上所有可用的软件工具，电信服务提供商在多个不同的平台上使用各种软件工具。电信服务提供商的信息技术还可能更适合使用一组软件工具而不是另一组。例如，一个信息技术团队可能在UNIX和UNIX环境中运行的软件方面接受过较好的培训，而另一信息技术团队更适应Microsoft和基于Microsoft的产品。
发明内容作为引言，下文描述的实施例包括一种用于在需要精确执行次序的多消息流中对数据进行同步的系统和方法。在第一方面，公开了一种用于处理相互依赖的消息的方法。通常，电信服务提供商接收服务请求。电信服务提供商为服务请求指派相关性id，并创建针对该服务请求的新实例，该实例内具有该相关性id的有关信息。电信服务提供商确定是否已经存在具有相同相关性id的正在运行的实例。如果具有相同相关性id的实例已经在运行，则电信服务提供商将与新服务请求有关的附加元素添加到当前实例。附加元素指示当前实例阻止服务请求的执行，直到当前实例从正在运行的实例接收到了通知为止。在第二方面，公开了一种用于处理相互依赖的消息的备选方法。电信服务提供商接收服务请求，并为服务请求指派相关性id。接下来，如果电信服务提供商确定不存在具有相同相关性id的正在运行的实例，则电信服务提供商创建针对该服务请求的实例。如果电信服务提供商确定存在具有相同相关性id的正在运行的实例，则将新的服务请求添加到队列以用于处理。在第三方面，公开了一种用于管理有相互关系的服务请求的序列的方法。确定所有可能的服务请求及其各自的相互依赖关系。基于该确定，指派执行次序。在第四方面，公开了一种用于管理有相互关系的事件的系统。该系统包括多个不同组件，包括软件工具，用来对服务请求的内容进行建模；集成中间件技术，诸如MOM、ESB、BPM或EAI，用来标识和配置相关事件，以及支持基于消息的集成；以及外部应用组件，其包括对于电信服务提供商唯一的业务逻辑。软件工具监控服务请求的内容和属性，并被用来证明如下参数可以根据这些参数来确定相关性标准。集成中间件技术被配置为处理由外部服务消费者生成的服务请求。外部服务消费者或应用过程逻辑调用特定序列下的服务请求。外部服务消费者通常是这样的应用，其能够根据符合完成电信服参考下文的附图和描述将更好地理解本公开。附图中的组件不一定是按比例绘制的，强调的重点在于示出设计的原理。而且，在附图中，贯穿不同的视图，相同的附图标记表示相应的部分或元素。图1是操作环境的一个实施例的简化视图2是示出服务请求处理的流程图3是相关性和定序架构所涉及过程的一种可行实现的详细框图4是示出了当前设计示例的简化视图；图5是示出了当前设计备选示例的简化视图；图6示出了相关性代码的构造；以及图7概述了当前设计的简化示例。在研究下文的附图和详细描述之后，其他的系统、方法、特征和优点对于本领域技术人员而言将变得显而易见。意在将所有这样的附加系统、方法、特征和优点包括在本说明书之内，涵盖在本i殳计的范围内，并得到所附权利要求的保护。具体实施例方式目前，需要一种可以用最少的配置来并入任何电信服务提供商的独特业务需求的标准应用。此外，需要一种能够在多个平台上运行并且不依赖于厂商的系统。针对电信服务提供商而设计的、基于企业有相互关系的事件的消息次序管理把提供电信服务的复杂性与消费者体验分离开来。该设计标识并管理相关的服务请求，并且确保相关的服务请求遵循由业务逻辑定义的精确执行次序。此外，相关的服务请求在单个线程中操作，而不相关的服务请求在多个线程中操作。在基于企业有相互关系的事件的消息次序管理中，本设计可以处理被拆分为精细粒度级别的服务请求，这些请求促进了服务请求以及利用小粒度服务请求构成的更复杂服务的高效实现、复用和优化。下文将更详细地给出小粒度服务请求的例子。例如，服务请求可以包括客户创建服务请求、客户修改常规日期服务请求，以及服务订单提供服务请求。基于企业有相互关系的事件的消息次序管理系统可以接收服务请求，并标识定义相关性代码的服务请求属性(例如，客户代码、账户代码、分区代码、单位代码、产品代码，以及订单id)。可以使用相关性代码来按照协调方式对相关的服务请求和异常进行管理。本设计可以唯一地定义可操作事件(例如，动作)，其被映射到业务服务(例如，针对服务的服务请求)。本设计可以使用业务服务在服务的递送和管理所涉及的系统之间交换信息。在一种实现中，本设计实现一种数据模型模式，其定义了用以创建、读取、更新和删除服务请求的实体。实体可以代表架构内的离散对象，该架构用以为消费者提供服务并管理服务到消费者的递送。作为示例，该架构可以包括诸如计费账户实体、消费者实体和单位实体之类的实体。实体可以包括唯一地标识服务请求并定义相关性代码的属性。架构可以使用相关性代码来以协调的方式标识和管理相关的服务请求。例如，本设计可以使用相关性代码来实现异常处理功能性。尽管描述了系统的具体组件，但是符合该架构的方法、系统和产品可以包括附加的或不同的组件。图1示出了环境100的简化视图。环境IOO可以包括相关性和定序架构102、CCare(客户关注)系统104、客户入口系统106、计费系统108、综合订单管理系统(IOM)110、提供系统114、企业资源规划(ERP)系统116以及余额系统118(例如，账户管理系统)中的一些或全部。此外，还可以包括其他系统。例如，企业可以具有多个计费系统。环境IOO可以允许服务提供商120通过网络128(例如，互联网)与客户122、消费者124(例如，潜在的客户)、分销伙伴126以及其他实体进行通信。相关性和定序架构系统102可以在环境100中包括的、以及与环境IOO相通信的系统之间进行协调。相关性和定序架构系统102可以允许应用结合起来执行以实现多个逻辑上功能交叉的业务过程。相关性和定序架构系统102可以提供消息传送服务，使得不同的应用可以使用服务请求(例如，业务服务请求)一起通信。表1示出了环境IOO可以用来递送和管理所提供服务的业务服务示例列表。该列表的本质仅是示例性，并且不应该被用以限制可行的业务服务。环境IOO可以唯一地定义将由环境IOO映射为业务服务的可操作事件(例如，动作)。环境IOO可以使用业务服务在服务的管理和递送中所涉及的系统(例如，相关性和定序架构102、CCare系统104、客户入口系统106、计费系统108、IOM系统llO、提供系统114以及ERP系统116)之间交换信息(例如，服务请求中转发的、实体中所包括的数据)。表1:业务服务账户清单查询激活调整后付费账户银行账户检查创建警告创建计费账户创建客户创建服务账户创建后付费订单创建预付费订单创建服务请求创建用户信用余额查询修改计费账户修改客户数据修改服务请求修改用户号码可携性请求充值请求SIM卡替换取回计费账户数据取回客户数据取回已就位资产耳又回订单取回产品配置取回产品列表取回产品价格取回服务账户取回服务请求耳又回用户数据发送电子邮件消息发送SMS消息用于提供响应的服务项用于提供的服务订单用于提供响应的服务订单同步账户计费配置同步对地址的账户账单同步对个人的账户帐单同步账户一般性数据同步账户支付数据同步账户同步资产组成同步客户同步客户财政地址同步客户一般性数据任务执行任务执行响应业务使用查询验证信用卡数据验证客户地址验证客户数据验证DSL可用性简要参考图6，每个业务服务600可以包括报头602和对象604,对象604代表诸如计费账户实体606、客户实体608和单位实体610之类的实体。业务服务的报头602可以包括属性，诸如标识客户的客户代码612、单位代码614、业务事件名称616、指示状态的执行状态618、标识业务事件的多个实例和线程的业务事件实例id620,以及用于在系统收到业务服务时加盖时间戳的收到日期622。环境100可以参考相关性代码定义或者其他相关性代码规范来确定环境IOO使用哪些属性以及按照何种顺序来形成相关性代码。例如，架构可以将经过排序的计费账户实体606、客户实体608以及单位实体610的序歹'J串接到单个相关性代码624中来获取相关性代码624。在另一示例中，环境100可以按照不同的顺序或次序对来自业务服务600的实体进行组合来获得相关性代码626。表2示出了环境100可以用来递送和管理所提供服务的示例业务服务和实体组合。例如，创建客户业务服务可以包括报头以及实体"客户"、"地址"和"单位，，，而修改客户一般性数据业务服务可以包括报头以及实体"客户，，和"单位"。表2:业务服务(实体)组合_<table>tableseeoriginaldocumentpage13</column></row><table>环境IOO可以使用业务事件(例如，业务服务请求)在环境100之内的、以及与环境100通信的系统之间交换数据。例如，IOM系统110可以请求提供系统114执行导致任务执行事件的特定操作。在一种实现中，相关性和定序系统102从IOM系统110接收请求，并将该请求转发至适当的提供系统114。任务执行事件可以由任务执行业务服务表示，其中该任务执行业务服务包含由IOM系统110映射为系统操作任务的服务请求。CCare系统104可以管理客户关系，使得服务提供商120和客户122可以直接访问客户信息；将客户需求与产品服务规划和供应相匹配；关于服务要求提醒消费者；以及标识客户122购买和/或使用的所有产品。CCare系统104可以包括如下能力帮助服务提供商120的营销部门识别并定位服务提供商120的最佳客户；通过清晰的目标和目的来管理营销战略；以及产生服务提供商120的销售团队的质量引领。CCare系统104可以通过优化多个员工共享的信息以及流水线化已有的过程(例如，使用移动设备来接受订单)来辅助服务提供商120改进电话销售、账户和销售管理。CCare系统104可以为服务提供商120提供形成与客户122、消费者124(例如，潜在客户)和分销伙伴126的定制关系的功能。CCare系统104可以改进客户满意度、识别最有利润的客户、为客户提供最高级别的服务并由此使利润最大化。CCare系统104可以为服务提供商120的员工提供信息和过程，这些信息和过程是分析客户属性、理解客户122的需求以及有效地构建服务提供商120、客户124和分销伙伴126之间的关系所需的。客户入口106可以允许客户122和消费者124从网络(例如，互联网)直接访问和提供服务。在一种实现中，客户入口106通过简单对象访问协议(SOAP)来与相关性和定序系统102通信，其中SOAP提供交换基于XML的消息的方法。客户入口106可以为客户122和消费者124提供浏览器，以便查看、购买和提供可用的服务、修改统计信息、计费账户和支付数据、查看清单记录、余额以及充值预付费账户。计费系统108可以执行为客户122记录产品和服务清单的活动。计费系统108的主要功能可以包括维护计费数据、服务重复性费用和使用费用，折扣、服务费率、服务目录以及生成打印的和电子的账单。综合订单管理(IOM)IIO可以为环境IOO提供用于过程自动化的基础，以及用以提供服务的人工工作流组件。IOM系统IIO设计可以实现服务订单和用以成功提供服务的任务级管理。提供系统114可以提供用以建立服务的服务，该建立包括配置装备、布线和传输。提供系统114可以管理激活和去激活服务提供商120所提供的产品和服务的功能。提供系统114可以管理无线和有线提供，互联网协议电视(IPTV)、互联网协议语音(VOIP)和专用服务提供。ERP(企业资源规划)系统116可以管理产品规划、购买(例如，用来递送产品和服务的材料和组件)、维护库存、与供货商交互、提供客户服务以及跟踪订单。ERP系统116还可以包括管理服务提供商业务的财物和人力资源方面的应用才莫块。ERP系统116可以管理和跟踪计费系统108向其发送清单的客户122的支付兌现，记录支付，并且将订单和支付补给分销伙伴126(例如，供货商)。在一种实现中，CCare系统104管理与客户和账户管理相关的所有实体以及客户122购买的产品和服务的订单。CCare系统104发起用以激活、修改和删除客户数据的操作以及订单激活和去激活。相关性和定序系统102可以根据需要复制实体并将其转发至与环境100通信的系统，以便提供和管理服务。相关性和定序系统102可以将CCare系统104事件映射为相应的业务服务。环境IOO可以将转发至业务服务的数据变换成与环境IOO通信的系统所使用的公共对象模型，以便提供和管理服务。相关性和定序系统102可以提供使用预定的次序将事件(例如，对业务服务的服务请求)路由到应用的逻辑。相关性和定序系统102可以为消费者124和客户122提供入口(例如，客户入口系统106)，该入口提供一组可调用的服务。在一种实现中，客户入口系统106将服务请求转发至相关性和定序系统102,相关性和定序系统102将该服务请求转发至CCare系统104,以提供和管理服务。图2是示出了在新服务请求进入系统时所采取步骤的简化流程图。在框202处接收服务请求。在框204处，确定相关性id。在一种实现中，在此步骤中指派相关性id。在框206处，该实现创建针对该服务请求的实例。接下来，在框208处，确定是否存在具有相同相关性id的正在运行的实例。如果确定存在具有相同相关性id的正在运行的实例，则在框210处向该实例添加指令，以等待执行，直到接收到通知为止。现有技术的系统持续地轮询网络以确定状态，并最终阻塞网络资源，与此不同，当前实例转入休眠状态，并且等待接收通知。在框210处，可以在当前实例内加入故障恢复(fail-over)机制，以便时常"醒来"并在队列或存储库查询休眠状态中的实例正在何处运行。例如，可以在当前实例中编码20分钟的等待时间。在当前实例处于"休眠"模式中达20分钟之后，集成中间件中的过程可以醒来，并检查是否存在具有相同相关性ID的正在运行的实例。根据接收到的响应，可以确定应当如何继续。例如，实例可以再次返回休眠模式并又一次达到20分钟，或者可以执行。如果在框208处确定不存在与当前实例具有相同相关性id的其他实例正在运行，则系统锁定当前实例所需的资源，并开始处理请求。一旦实例完成了处理，便解锁使用的资源，并且在框214处向具有相同相关性id的下一实例发送通知。该通知指示下一实例开始处理。图3是使用BPEL技术的相关性和定序架构中所涉及过程的一个实现的瞬像。在此示例中，使用OracleBPEL软件包作为构建方案的软件平台。然而，也可以使用其他平台。图3示出了接收消息(也即，服务请求)并检查是否存在针对关联的相关性ID的正在运行的实例的过程。电信客户端301发出服务请求。在302处接收服务请求。在304处，系统检查与当前服务请求具有相同相关性id的正在运行的实例。这可以通过以Java编写的"CheckRunninglnstances(检查运行中实例)"过程来实现。"CheckRunninglnstances"使用BPELAPI"lookupinstances，，。"lookupinstances，，API才企查具有相同相关性id(例如，客户代码)的所有正在运行的实例，并确定在当前实例可以运行之前哪些实例需要结束处理。"CheckRunninglnstances，，还在当前实例中设置相关性id(例如，客户代码)，以确保在发起搜索的情况下其他实例能够查找到当前实例。在306处，生成将发送给客户端的响应。该响应可以是XML消息。接下来，在308处，将响应发送至客户端，该响应指明"该请求成功"消息或者类似消息。过程/服务请求尚未完成，但是这对客户端而言是透明的。由此，客户端不必必须等待电信服务提供者的所有内部处理完成。根据在步骤304中是否找到了具有相同相关性id的正在运行的实例，在步骤310中进行决策。如果在步骤304中没有找到具有相同相关性id的正在运行的实例，则实例前进到步骤312。不向实例添加附加的指令。在步骤316,实例处理消息。一旦处理完成，实例解锁资源，并且在步骤318中向下一等待实例发送通知，以便开始处理。如果在步骤304中找到了与当前实例具有相同相关性id的正在运行的实例，则在步骤314向实例添加属性，以便阻止执行，直到从正在运行的实例接收到通知为止。一旦接收到了通知，当前实例前进到步骤316并处理消息。一旦处理完成，实例解锁资源，并且在步骤318中向下一等待实例发送通知，以便开始处理。图4是示出了当前设计的示例的筒化视图。M(X)代表具有相关性ID"X"的消息。Q(X)代表在队列中等待的具有相关性ID"X"的消息。例如，假设消息402、404、406、408、410和412按照声明的顺序到达。消息術、406和412全都具有相关性id"A",因此这些消息是相关的。消息404、408和410全都具有相关性id"B",并且由此这些消息是相关的。在此示例中，相关性id"A"和相关性id"B"彼此无关。相关性ID"A"和"B，，可以涉及多个变量。例如，相关性id可以是客户端的唯一标识符，例如客户代码。系统为每个接收到的消息创建实例。对于消息402，创建实例422。对于消息404，创建实例424。对于消息406,创建实例426。对于消息408，创建实例428。对于消息410,创建实例430。对于消息412，创建实例432。具有相同相关性id的所有实例进入队列，以用于与该相关性id直接相关的进一步处理。由此，实例422、426和432进入Q(A)414，而实例424、428和430进入Q(B)416。Q(A)和Q(B)彼此无关，并且可以同时运行。针对Q(A)的实例422、426和432按照接收消息的相同顺序进行处理。由此，由于消息402在消息406之前接收，因此消息406在消息402完成之前不会开始处理，并且消息412在队列(Q(A))中等待，直到消息406完成处理。类似地，针对Q(B)的实例424、428和430按照接收消息的相同顺序进行处理。由此，由于消息404在消息408之前接收，因此消息408在消息404完成之前不会开始处理，并且消息410在队列Q(B)中等待，直到消息408完成处理。然而，虽然M(B)408在M(A)406之后进入系统，但是M(B)408有可能在M(A)406之前开始处理，这是因为M(A)和M(B)彼此无关，并且M(B)404可能在M(A)402之前完成处理。类似地，具有不同相关性id的消息可以同时运行。例如，M(A)408和M(B)406可以同时运行。图5是示出了当前设计的备选示例的简化视图。M(X)代表具有相关性ID"X"的消息。Q(X)代表在队列中等待的具有相关性ID"X"的消息。类似于图4,假设消息502、504、506、508、510和512按照声明的顺序到达。消息502、506和512全都具有相关性id"A",因此这些消息是相关的。消息504、508和510全都具有相关性id"B"，并且由此这些消息是相关的。再次，相关性id"A"和相关性id"B"彼此无关。在图5中，没有为接收到的每个消息创建实例。相反，接收到的具有给定相关性id的第一消息创建实例。这里，M(A)502创建了针对Q(A)514的实例，并且M(B)504创建了针对Q(B)516的实例。由此，Q(A)514中的所有消息在M(A)502创建的同一实例中运行。类似地，Q(B)516中的所有消息在M(B)504创建的同一实例中运行。具有同一相关性id的所有消息进入队列，以用于与该相关性id直接相关的进一步处理。由此，消息502、506和512进入Q(A)514,而消息504、508和512进入Q(B)516。Q(A)和Q(B)彼此无关，并且可以同时运行。Q(A)中的消息502、506和512按照接收消息的相同顺序进行处理。由此，由于消息502在消息506之前接收，因此消息506在消息502完成之前不会开始处理，并且消息512在队列(Q(A))中等待，直到消息506完成处理为止。类似地，Q(B)的消息504、508和510按照接收消息的相同顺序进行处理。由此，由于消息504在消息508之前接收，因此消息508在消息504完成之前不会被处理，并且消息510在队列Q(B)中等待，直到消息508完成处理为止。然而，虽然M(B)508在M(A)506之后进入系统，但是M(B)508有可能在M(A)506之前开始处理，这是因为M(A)和M(B)彼此无关，并且M(B)504可能在M(A)502之前完成处理。类似地，具有不同相关性id的消息可以同时运行。例如，M(A)508和M(B)506可以同时运^f亍。图7概述了当前设计的简化示例。在图7中，在非常短的时间段内向BPEL发送了4个消息。BPEL引擎仅是可以使用的技术的一个示例，在此参考BPEL是为了简化阐述。其他技术也可以用于图7。这4个消息将创建客户1，创建客户2，创建客户1的账户，以及客户1的服务订单。参考图7，创建客户1由CC1表示，创建客户2由CC2表示，创建客户1的账户由AC1表示，并且客户1的服务订单由S01表示。CC1、AC1和S01是针对同一客户的，因此其具有相同的相关性ID"1"。CC2是针对不同客户的，具有相关性ID"2"。对具有相关性ID"1"的3个消息进行排队，以便通过单个线程710顺序地处理。CC1启动BPEL过程的新实例714,在此例子中是针对实例#1的分发器过程。分发器过程管理针对实例#1的所有消息。由于CC2与CC1、AC1和S01无关，因此同时在第二线程712中处理CC2。CC2启动BPEL过程714的新实例，在此例子中是针对实例#2的分发器过程。应当将上述详细描述理解为本发明可选形式的说明，而不应当理解为对本发明的限定。已经描述了多种实现。然而，将会理解，在不脱离本发明的精神和范围的情况下，可以进行各种修改。因此，其他实现也属于所附权利要求的范围。权利要求1.一种用于有相互关系的事件的消息次序管理的计算机实现的方法，包括接收服务请求；确定相关性id并将其指派给所述服务请求；创建针对所述服务请求的当前实例；将所述相关性id信息包含在所述实例中；确定是否存在针对所述相关性id的正在运行的实例；如果存在针对所述相关性id的正在运行的实例，则向所述当前实例中添加元素；其中，给所述实例的所述元素包括给所述服务请求的指令，以便在接收到通知之前阻止所述服务请求的执行。2.根据权利要求1所述的方法，进一步包括定义多个小粒度的可复用服务请求，包括客户创建服务请求；客户修改常规日期服务请求；客户修改物理地址服务请求；以及修改客户数据服务请求。3.根据权利要求1或2所述的方法，进一步包括账户修改常规日期服务请求；账户修改计费配置服务请求；账户修改对个人的账单服务请求；账户修改对地址的账单服务请求；以及账户修改支付日期服务请求。4.根据权利要求1到3任一项所述的方法，进一步包括服务订单提供服务请求；资产组成服务请求；提供任务服务请求；以及任务执行响应服务请求。5.根据权利要求1到4任一项所述的方法，进一步包括在所述当前实例终止后，向具有相同的所述相关性id的下一接收到的实例发送通知。6.根据权利要求5所述的方法，其中，所述下一个接收到的实例只要接收到所述通知便开始处理。7.根据权利要求4到6任一项所述的方法，进一步包括锁定所述下一接收到的实例正在使用的资源。8.根据权利要求1到7任一项所述的方法，其中，如果存在针对所述相关性id的正在运行的实例则向所述当前实例添加元素进一步包括设置用于所述当前实例的时间周期，以确定所述正在运行的实例的状态。9.根据权利要求1所述的方法，进一步包括接收第二服务请求，确定第二相关性id并将其指派给接收到的所述第二服务请求。10.根据权利要求9所述的方法，其中，同时处理具有所述第一相关性id的所述第一实例和具有第二相关性id的所述第二实例。11.一种用于有相互关系的事件的消息次序管理的计算机实现的方法，包括接收服务请求；确定相关性id并将其指派给所述服务请求；确定是否存在针对所述相关性id的正在运行的实例；如果存在针对所述相关性id的正在运行的实例，则将所述服务请求添加到处理队列中；以及如果不存在针对所述相关性id的正在运行的实例，则创建当前实例；其中，所述处理队列以所述服务请求被接收的顺序来包括针对所述相关性id的接收到的所有服务请求。12.根据权利要求11所述的方法，其中，如果不存在针对所述相关性id的正在运行的实例则创建实例的步骤进一步包括创建队列，并且将所述服务请求添加到所述队列中。13.根据权利要求11或12所述的方法，进一步包括定义多个小粒度的可复用服务请求，包括客户创建服务请求；客户修改常规日期服务请求；客户修改物理地址服务请求；以及修改客户数据服务请求。14.根据权利要求11到13任一项所述的方法，进一步包括账户修改常规日期服务请求；账户修改计费配置服务请求；账户修改对个人的账单服务请求；账户修改对地址的账单服务请求；以及账户修改支付日期服务请求。15.根据权利要求11到14任一项所述的方法，进一步包括服务订单提供服务请求；资产组成服务请求；提供任务服务请求；以及任务执行响应服务请求。16.根据权利要求11到15任一项所述的方法，进一步包括接收第二服务请求，确定第二相关性id并将其指派给接收到的所述第二服务请求。17.根据权利要求16所述的方法，其中，同时处理具有第一相关性id的所述第一实例和具有第二相关性id的所述第二实例。18.—种用于管理有相互关系的服务请求序列的计算机实现的方法，所述方法包括确定多个可能的服务请求；配置所述可能的服务请求的相互依赖关系；以及至少部分地基于所述相互依赖关系来指派执行次序。19.根据权利要求18所述的方法，进一步包括定义多个小粒度的可复用服务请求，包括客户创建服务请求；客户修改常规日期服务请求；以及客户修改物理地址服务请求。20.根据权利要求18或19所述的方法，进一步包括修改客户数据服务请求；账户修改常规日期服务请求；账户修改计费配置服务请求；以及账户修改对个人的账单服务请求。21.根据权利要求18到20任一项所述的方法，进一步包括账户修改对地址的账单服务请求；账户修改支付日期服务请求；服务订单提供服务请求；资产组成服务请求；提供任务服务请求；以及任务执行响应服务请求。22.—种用于管理有相互关系的事件的系统，所述系统包括集成中间件技术组件，其支持基于消息的集成，并被配置为标识和配置有相互关系的事件；应用过程逻辑层，其能够调用对过程业务逻辑的服务请求，并被配置为通过所述集成中间件技术组件来发布所述有相互关系的事件；以及其中，所述应用过程逻辑层包括对于特定服务提供商唯一的业务逻辑。全文摘要一种基于企业的有相互关系的事件的消息次序管理，以最少的配置来并入电信服务提供商的变化的、唯一的业务。该设计标识并管理相关服务请求，并确保这些相关服务请求遵循业务逻辑所定义的精确执行次序。该设计的鲁棒特征允许对变化的业务过程和需求的简化集成和管理。文档编号H04M3/22GK101369919SQ20081014495公开日2009年2月18日申请日期2008年8月13日优先权日2007年8月13日发明者A·奥塔维,L·阿普里勒,S·R·甘迪尼申请人:埃森哲环球服务有限公司