高负荷业务流程可扩展性的制作方法

专利名称：高负荷业务流程可扩展性的制作方法
技术领域：
本发明涉及用于提供高负荷业务流程可扩展性(scalability)的软件、计算机系统和计算机实施的方法。
背景技术：
高带宽的网络和数据连接、以及高容量的数据存储服务器的越来越多的使用已经导致不同部署模式的实施，诸如云计算解决方案。在云计算解决方案中，资源、服务、增强的功能、或软件可以通过网络提供给客户端计算机。可以通过虚拟化技术在多个客户端当中共享资源，以实现改进的资源利用率和规模效应(scaling effect)。云计算模型也可以用来为用户提供数据的共享访问和远程存储。在云计算解决方案中，通过诸如互联网的网络提供作为托管服务(hosted service)的计算资源。这些服务可以包括通过云计算网络提供的、不需在客户端计算机上安装应用或软件的按需服务。公司利用业务流程管理套件(businessprocess management suites,BPMS)来建模(model)、提供文件(document)、自动操作、治理、优化、模拟和监控核心业务流程和复杂的重复性任务。在某些情况下，按需BPMS通过动态分配额外的云实例(计算机节点)处理额外的负荷来实现可扩展性或弹性(elasticity)。同时,基于云的BPMS连接到广泛的其他软件部件，包括移动设备上运行的客户端软件、预置(on-premise)业务软件安装(例如，企业资源规划系统)、基于网络的客户端、其他基于云的业务软件、以及业务合作伙伴运行的其他软件。BPMS系统中的业务流程可以与那些外部软件部件交换事件。

发明内容
本公开描述了用于在基于云的基础设施中提供高负荷业务流程可扩展性的技术。将计算机程序产品编码在有形的存储介质中，其中，产品包括用于使一个或多个处理器执行操作的计算机可读指令。这些操作可以包括在运行(execute)第一业务流程实例的第一计算机节点处接收消息。识别与该消息相关联的第二业务流程实例。如果第二业务流程实例不位于第一计算机节点处，则将该消息发送到由第二业务流程实例进行检索的消息队列。虽然一般描述为在有形的非临时性介质上具体实现的、处理并转换重复性数据的计算机实施的软件，但是一些方面或者所有方面可以是计算机实施的方法或者还包括在执行这个描述功能的各自系统或其他设备中。在附图和下面的描述中阐明本公开的这些和其他方面以及实施例的细节。根据说明书、附图和权利要求，本公开的其他特征、目的和优点将是明显的。


图I示出了云网络中分布式业务流程管理套件的示例环境；图2示出了计算机节点和消息系统(messaging system)中所包括的示例部件的、示图；图3是使用适当系统(诸如图2中描述的系统)向流程实例分派事件的过程的流程图；图4是使用适当系统(诸如图2中描述的系统)处理在计算机节点处从外部部件接收到的消息的过程的流程图；图5是使用适当系统(诸如图2中描述的系统)从消息队列检索相关消息的过程的流程图；图6是使用适当系统(诸如图2中描述的系统)接收消息并向业务流程实例分发消息的示例业务流程的示图；以及图7和图8是示出使用适当系统(诸如图2中描述的系统)向云实例分派消息的示例过程的示图。
具体实施例方式本公开一般描述用于在基于云的基础设施中提供高负荷业务流程可扩展性的计算机系统、软件、以及计算机实施的方法。在云计算或群集节点(cluster node)基础设施中，多个计算机节点或云实例可以用于为外部部件和用户提供应用或服务。在第一云或群集节点实例处(以下称为“云实例”)接收到的事件可能需要被转发到第二接收云实例以进行处理。事件是在应用和/或业务流程之间交换的消息或请求。不是立即与接收云实例通信以启动事件处理，而是将事件保存在数据库支持的(database-backed)事件队列中。然后，接收云实例可以从事件队列检索事件以将其分派给消耗(consume)该事件的本地运行的流程实例。在一些实施中，对接收云实例的通知调用将触发接收云实例以无延迟地检索事件。接收流程实例可以基于其内部状态在适当时间消耗事件。通过业务流程管理套件(BPMS)运转(run)业务流程,编排(orchestrate)诸如与其他部件同步流程的自动化活动、用户任务、以及事件的流程步骤。这些流程步骤往往与外部应用和设备相互作用。例如，用户任务可以被发送到用户的移动设备，在该移动设备中进行处理并将数据传回底层的业务流程。在另一个示例中，RFID阅读器可以将信号发送给业务流程，在该业务流程中的事件中消耗信号以触发一定后续动作。在另一个示例中，业务流程从自动化活动调用到企业资源规划(ERP)系统以改变其管理的业务对象(例如，发票或物料主数据(material master data))。在一些实施中，BPMS系统可以提供为在云计算网络中按需安装，以支持按需业务应用并从伴随云基础设施固有弹性和可扩展性的特点发生的较低的总拥有成本中受益。技术上，单一 BPMS安装分布在由底层云基础设施提供的动态范围的计算机“节点”上。这些节点共同运转许多业务流程。每当有较大工作负荷(workload)要处理时可以增加节点的数量，或者每当有较小工作负荷要处理时可能减少节点的数量。一些节点可以运行特定业务流程的不同实例，而其他节点可以在各种实施中运行完全不同的业务流程。转向示出的示例，图I示出了在基于云的基础设施中运行与业务流程管理套件(BPMS)相关联的业务流程的示例环境100。所示出的环境100包括网络(诸如云网络105)中的多个部件，或者所示出的环境100以通信方式耦合网络(诸如云网络105)中的多个部件。一般地，环境100描绘了系统的示例配置，该系统能够编排与诸如移动设备180或客户端171的外部应用和设备同步的流程步骤，该流程步骤诸如，云网络105内的自动化活动、用户任务、以及事件。BPMS可以分布在包括节点110、120等等的云网络105中的多个计算机节点上。如在本公开中所使用的，术语“计算机节点”和“云实例”可以适当互换使用而不偏离本公开的范围。在集群计算环境(未示出)中，“计算机节点”和“云实例”还可以类似于“群集节点”。网络105中的每个计算机节点可以包括需要运转许多业务流程或流程实例的多个不同部件。例如，如图I所示，计算机节点可以包括业务流程管理(BPM)运行时(runtime)环境、消息中间件、或通信适配器。计算机节点处的内部部件允许计算机节点执行与BPMS相关联的流程步骤、与其他计算机节点或外部部件通信、接收并响应来自外部部件的事件、并运行业务流程。云计算环境中的BPMS的实施通过在需要处理额外的工作负荷时分配额外的计算机节点来为BPMS提供灵活性和可扩展性。如图I所示，基于云的BPMS还可以连接到其他外部软件部件以向该外部软件部件提供按需服务。例如，BPMS可以连接到包括一个或多个客户端171、移动设备180、预置系 统190、和其他业务伙伴系统192的外部部件。外部部件可以运转通过云网络105与BPMS相互作用的客户端软件部件。在计算机节点110和120处运转的业务流程可以与外部软件部件交换事件。此外，云网络105还可以包括用于促进外部部件和计算机节点之间通信的部件，诸如用于管理和同步云网络105中的通信的接口 140和/或用于管理计算机节点当中的工作负荷分配的负荷平衡器150。典型的负荷平衡器150可以用于在将工作包分配给可用的工作流程之前，将总负荷划分成更小的固定大小的工作包。一般地，典型的负荷平衡器150接收消息并将消息分发给可用的节点，虽然不一定分发给与接收到的消息相关联的特定节点或运行接收流程实例的节点。业务流程和外部部件当中的事件交换可能需要业务流程持续使它们的内部状态与接收到的事件同步。当业务流程接收到事件时，业务流程需要对事件做出可靠反应，以便在业务流程的控制流和数据流上实现预期效果。因此，需要以事务(transaction)方式同步业务流程的状态，以便保持业务流程与外部部件的一致性(consistency)。换句话说，在任何离散时间点，业务流程的状态应该反映与业务流程相互作用的外部部件的状态。在某些情况下，业务流程和外部部件可以同步耦合，以确保状态的一致性。例如，诸如两阶段提交(Two-Phase Commit)的专用分布式事务协议同步稱合两个业务应用,诸如BPMS和外部软件部件。也就是说，两个应用在不同计算机节点上保持它们各自的状态并同步执行单一逻辑事务的动作(例如，在数据库中保持它们状态的快照)。然而，对于处理高工作负荷并需要遵守有关处理吞吐量和延迟的服务水平协议(SLA)的业务应用而言，同步耦合不同软件部件和不同计算机节点可能并不有效。通过请求另一个应用来与请求的应用同步地执行动作，既未考虑其他应用的当前可用性也未考虑其底层基础设施。实际上，其他应用当前可能不能够对请求做出响应，而使得整个事务被延迟。当计算机节点需要一次服务多个请求时，这个问题更加严重。本质上，依赖于同步耦合的分布式事务协议不能扩展到基于云的基础设施上。为了避免同步耦合，可以采用可靠的异步协议。异步协议可以以异步解耦的方式将事件从外部软件部件传递到业务流程，只保证该事件最终将被递送。同样，业务流程也可以以这种方式将事件传回外部软件部件。异步协议避免了分布式事务的阻塞特性。然而，这些协议需要业务流程和外部软件部件之间的松散耦合。例如，诸如等待进入事件(incomingevent)的异步功能需要被明确建模在业务流程中。此外，可以不将外部软件部件(例如，ERP系统)配置为了解事件的接收软件部件是什么或接收软件部件(如业务流程实例)当前运行在哪个特定计算机节点上。因此，某些事件相关机制(这可以是BPMS或其他消息中间件的一部分)需要将事件分派到接收软件部件。在某些实施中，群集启用协议可以用来解决基于云的BPMS实施中的可扩展性的问题。群集启用协议可以依靠驱逐算法(eviction algorithm)在两个计算机节点之间传输完整流程实例。特别地，将接收流程实例传输给接收事件的节点。在某些情况下，软件部件在第一计算机节点上发出请求，而应该接收请求的受影响的流程实例当前运转在不同的第二计算机节点上。与第一计算机节点相关联的流程实例可以从第一计算机节点逐出并迁移到不同的第二计算机节点，以便处理事件同时保持与事件的事务同步。例如，如图I所示，在客户端171处，在外部设备上运转的外部软件部件(例如，任务管理软件)可以将事件提交给在多个节点(包括节点110和120)上分布的BPMS。最初，事件可以由负荷平衡器150接收，该负荷平衡器150在其管理下的节点中选择一个节点以 向该节点发送事件。在本示例中，将事件发送给节点110处的特定流程实例，但是事件的消耗可能需要在不同的节点120处执行。基于群集启用协议，BPMS等待节点110处的流程实例达到空闲状态，诸如等待用户任务完成时。在空闲状态期间，在节点110处将包括其状态信息的流程实例逐出节点110并保持在数据库上。然后，节点120通过从数据库加载状态信息来恢复流程实例并在节点120处重新开始流程实例。然后将接收到的事件传递给节点120处的流程实例，这有效地同步了流程状态。群集启用协议可能在某些情况下导致延迟和吞吐量问题。首先，当流程实例与复杂状态相关联时，BPMS中的业务流程的性能可能受到不利影响。许多客户场景伴随采用深层嵌套的子流调用的大流程模型(big process model) 一起发生。实际上，在集群传输中需要保持到数据库中以及从数据库中获取的流程状态可能大的惊人，而且可能在数据库中生成大量负荷。此外，某些因素可能导致频繁的群集传输，这可能进一步占用系统资源。一些业务流程模型包含许多可触发群集传输的非自然信号(artifact)。可触发群集传输的非自然信号的示例是人的活动(例如，用户任务)、中间消息捕获事件、定时器事件、以及向同步流程接口发送响应。一般地，这些非自然信号的每次出现都可以触发在集群上传输流程实例，对于系统资源而言这可能是代价高昂的操作。第三，集群协议在节点之间使用同步通信，这由于内在可用性的限制而限定了可扩展性。此外，许多流程模型可能很少遇到空闲状态，而空闲状态是执行群集传输的先决条件。许多非自然信号会抑制空闲情况，诸如连续或并行循环、自动化活动调用长时间运行的服务(例如，ERP企业服务)、以及客户提供的数据映射功能，其可以是任意复杂的并因此以不可预知的方式消耗处理时间。当非自然信号驻留在调用堆栈的任意子流中的并行分支上时，它们可以暂时抑制作为群集传输的一部分的流程被逐出。实际上，将事件递送给流程的请求失败并且需要稍后重复该请求，这可能妨碍消息吞吐量。在基于云的基础设施中，由外部部件传送的事件可以到达特定的云实例，而将要处理该事件的接收流程实例可以驻留在另一个云实例上。可以提供将事件持续分派给分布式云基础设施中的接收流程业务的协议。在一些实施中，协议可以引入代价不高的协议开销并且不必依赖于“空闲”的业务流程来接收事件。当事件的数量或流程实例的数量增加时，通过分配额外的云实例来处理额外的负荷可以容易地补偿流程周转时间和整个流程端到端的吞吐量。此外，通过在集中式数据库中保持事件，由于不需要在云网络中的集群上传输接收流程实例，因此可以降低I/o和网络负荷。此外，大大降低了与将事件成功递送给BPMS运行时相关联的延迟。事件不再需要等待接收流程实例在集群上进行传输以完成递送事务。最后，递送失败的可能性也大大降低，因为不能在集群上进行传输的流程实例不能再抑制或阻挡事件递送。本公开通过以物理和异步方式解耦业务流程中的事件接收和消耗来解决与云计算基础设施中高负荷处理相关联的挑战。也就是说，当在第一云实例上接收事件时，将该事件保持在用于接收业务流程的数据库支持的事件队列中，该接收业务 流程可以在第二云实例上运转。运转接收业务流程的第二云实例将定期从队列中获取新到来的事件并将它们分派给消耗事件的、本地运转的流程实例。在某些情况下，第二云实例可以基于事件队列的轮询来获取新的事件。在一些实施中，一旦将事件放入队列中，则可选的通知调用将主动触发第二云实例，以消除轮询延迟。接收流程实例基于其内部状态和可用性来自由消耗事件，而不会阻塞在第一云实例上已经发出事件的事务。例如，任务管理软件可以自主地将通过在另一个云实例上运转的业务流程创建的用户任务的状态从“进行中”设置为“完成”。实际上，在单独的异步解耦事务中，对于将在其自己的云实例上拾取的受影响的流程将生成并保存事件(即，为该流程实例入队(enqueue))。在某些情况下，外部部件可以将事件发送给流程而陷入锁定冲突。在极少数情况下，当外部部件和业务流程两者都访问联合(joint)状态变量时，可能需要从中央锁定提供者获得锁定。可以通过将任何状态改变分组为只有在外部软件部件发出事件的时候才发生的单独事件实体来避免锁定。然而，一般地，业务流程管理专用资源并且不直接访问外部资源，而外部部件一般不处理内部流程资源。图2示出了环境200，其显示用于在基于云的基础设施中提供高负荷业务流程可扩展性的计算机节点202和消息系统222中的示例部件。环境200包括一个或多个远程系统250、计算机节点202、消息系统222，这些中的至少一些在网络212上通信。一般地，环境200描绘了 BPMS中所使用的、用于处理从外部部件接收到的事件的部件的示例配置。计算机节点202代表在诸如以上关于图I描述的BPMS实施中的示例节点。BPMS实施可以包括一个以上节点，而且每个节点可以取决于实施包括更少、更多、或者不同的部件。在某些情况下，节点202和消息系统222可以在云计算网络内进行逻辑分组并且是可访问的。因此，通过云计算网络以及传统的服务器客户端系统或远程系统250处的本地应用，BPMS系统可以提供为按需解决方案。一般地，节点202可以是诸如可操作以接收、传送、处理、存储或管理与环境200相关联的数据和信息的服务器的任意电子计算设备。节点202可以是存储一个或多个业务流程应用232的服务器，其中至少一部分业务流程应用经由发送到用户或客户端的请求和响应运行，所述用户或客户端在示出的图2的环境200内，或与环境200以通信方式耦合。在一些情况下，节点202可以存储多个不同的业务流程应用232，而在其他情况下，节点202可以是专用服务器，这意味着只存储和运行单一业务流程应用232。在一些情况下，节点202可以包括万维网(Web)服务器，或者以通信方式与Web服务器耦合，其中，业务流程应用232代表经由网络212由远程系统250访问并运行以执行业务流程应用232的程序化任务或操作的一个或多个基于Web的应用。图2所示的节点202可以负责从与环境200的远程系统250相关联的一个或多个客户端应用或业务应用接收应用请求(即，事件)，如果接收到的请求是同步请求，则通过在业务流程应用232中处理接收到的请求来对所述请求做出响应并且将来自业务流程应用232的适当响应传回发出请求的客户端应用。节点202还可以从网络212上的其他部件(诸如，消息系统222或者图2未示出的其他节点)接收请求并对请求做出响应。可替换地，节点202处的业务流程应用232能够对来自用户本地访问节点202的请求进行处理并做出响应。因此，除了来自图2中所示的远程系统250的请求，还可以从内部用户、外部或第三方客户、其他自动化应用、以及任何其他适当实体、个人、系统、或计算机发送与业务流程应用232相关联的请求。如本公开中所使用的，术语“计算机”旨在包括任何合适的处理设备。例如，虽然图2示出了包括计算机的单一节点202，但是可以使用一个或多个节点以及除服务器之外的计算机(包括服务器池)来实现环境200。事实上，节点202、远程系统250、消息系统 222可以是任何计算机或处理设备，例如，刀片服务器、通用个人计算机(PC)、麦金托什机(Macintosh)、工作站、基于UNIX的工作站、或任何其他合适的设备。换句话说，本公开预期(contemplate)除了通用计算机的其他计算机、以及不使用传统操作系统的计算机。此外，所示出的节点202、远程系统250和消息系统222可以适于运行任何操作系统,包括Linux、UNIX、Windows、Mac OS、或任何其他合适的操作系统。在本实施中，如图2所示，节点202包括处理器208、接口 205、存储器211、以及一个或多个业务流程应用232。节点202使用接口 205与连接到网络212的客户端-服务器或其他包括在内部环境200内的分布式环境中的其他系统(例如，远程系统250、以及以通信方式与网络212耦合的其他系统)通信。一般地，接口 205包括在软件和/或硬件中以合适的组合编码的逻辑，并且可操作以与网络212通信。更具体地，接口 205可以包括支持与通信相关联的一个或多个通信协议的软件，从而网络212或者接口的硬件可操作以在所示的环境200的内部和外部传递物理信号。在一些实施中，节点202还可以包括用户界面，诸如图形用户界面(⑶I)。⑶I包括可操作以例如允许服务器202的用户与用于任何合适用途(诸如创建、准备、请求、或分析数据、以及查看和访问与商业事务相关联的源文件)的平台的至少一部分连接(interface)的图形用户界面。一般地，⑶I为特定用户提供由系统提供的或者在系统内通信的业务数据的高效和用户友好的呈现。具体地，例如，GUI可以用于呈现源自业务流程的用户任务。Gn还可以提供允许用户访问和利用业务流程应用232的各种服务和功能的一般交互式元素。⑶I往往可配置为支持表格和图形(条、线、饼图、状态刻度盘等)的组合，并能够建立实时门户(real-time portal),其中通过关键特点(例如,站点或微站点)描绘标签(tab)。因此，⑶I预期任何合适的图形用户界面，诸如在平台中处理信息并将结果直观呈现给用户的通用Web浏览器和命令行界面(CLI)的组合。一般地，示例节点202可以以通信方式与网络212耦合，该网络212便于环境200的部件之间(即，节点202和远程系统250之间)的无线或有线通信，而且示例节点202可以以通信方式与任何其他本地或远程计算机，诸如信息系统222、以通信方式与网络212耦合但是在图2中未示出的附加客户端、服务器或其他设备耦合。在所示出的环境中，网络212在图2中被描述为单一网络，但是网络212可以是连续或不连续的网络而不偏离本公开的范围，只要网络212的至少一部分可以便于发送者和接收者之间的通信。网络212可以是企业或安全网络的全部或一部分，而在另一个实例中网络212的至少一部分可以代表到互联网的连接。在一些情况下，网络212的一部分可以是虚拟专用网(VPN)，诸如，例如，远程系统250和节点202之间的连接。此外，网络212的全部或一部分可以包括有线链接或无线链接。示例无线链接可以包括支持802. lla/b/g/n、802. 20、WiMAXjP /或任何其他适当的无线链接。换句话说，网络212包含可操作以便于在所示出的环境200的内部和外部的各种计算部件之间通信的任何内部或外部网络、网络、子网络、或其组合。例如，网络212可以在网络地址之间传递互联网协议(IP)数据包、帧中继帧、异步传输模式(ATM)单元、语音、视频、数据、以及其他合适的信息。网络212还可以包括在一个或多个地点的一个或多个本地区域网络(LAN)、无线接入网络(RAN)、城域网(MAN)、广域网(WAN)、互联网的全部或一部分、和/或任何其他通信系统。
远程系统250可以访问网络212内诸如节点202的资源。在某些实施中，网络212内的服务器(在一些情况下包括节点202)可以包括用于提供基于云的服务的云计算平台。术语“云”、“云计算”和“基于云的”可以适当互换使用而不偏离本公开的范围。基于云的服务可以是托管服务，其由服务器提供并通过网络递送给客户端平台以加强、补充或替换在客户端计算机上本地执行的应用。远程系统250可以在可以将资源递送给远程系统250之前使用基于云的服务来快速接收软件升级、应用、以及其他资源，否则将需要一段漫长时间。此外，其它设备也可以访问基于云的服务，诸如由通过网络212可访问的服务器所提供的按需服务。而且，云平台的部署实施不是本公开的必需元素，而是也可以使用其他分布式基础设施，诸如基于集群的系统。如本公开所述，按需服务可以包括多种类型的服务和业务流程，诸如产品、可行性(actionable)分析、企业门户、管理网页内容、复合应用(composite)、或者创建、整合、使用、呈现业务应用的能力。例如，基于云的实施可以允许远程系统250从旧的用户界面平台透明地更新到平台的新版本而不损失功能。如图2所示，节点202包括处理器208。虽然在图2中示出为单一处理器208，但是根据环境200的特定需要、期望、或特定实施例，可以使用两个或两个以上处理器。每个处理器208可以是中央处理单元(CPU)、刀片处理器(blade)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、或其他合适的部件。一般地，处理器208运行指令并操纵数据以执行节点202的操作，以及具体地，一个或多个业务流程应用232。具体地，服务器的处理器208运行要求接收来自远程系统250和它们各自客户端应用144的请求并对请求做出响应的功能，以及要求执行业务流程应用232的其他操作的功能。与特定实施无关，“软件”可以包括当运行软件时可操作以执行至少这里所描述的流程和操作的、在有形的非临时性介质上的计算机可读指令、固件、有线或程序化硬件、或其任意组合。事实上，每个软件部件可以完全或部分地由包括C、C++、JAVA、Visual Basic、汇编(assembler)、Perl、任何合适的版本的4GL、以及其他语言的任何合适的计算机语言编写或描述。将要理解的是，虽然图2中所描述的软件部分示出为通过不同对象、方法、或其他流程实施各种特征和功能的单独模块，但是软件可以替代地适当包括许多子模块、第三方服务、部件、库等。相反，各个部件的特征和功能可以适当合并成单一部件。在所示出的环境200中，处理器208运行节点202上的一个或多个业务流程应用232。在高层次上，根据本公开，一个或多个业务流程应用232中的每一个是任何应用、程序、模块、过程、或其他软件，其可以运行、改变、删除、生成、或以其他方式管理信息，特别是对通过网络212从所示出的远程系统250及其相关联的客户端应用254或从其他服务器或部件接收的一个或多个请求做出响应并与其联系。在某些情况下，只有一个业务流程应用232可以位于特定节点202。在其他情况下，多个相关和/或无关业务流程应用232可以存储在单一节点202处、或位于多个其他节点202上。在某些情况下，环境200可以实施复合业务流程应用232。例如，复合应用的某些部分可以实施为企业级Java Beans (EJB)，或者设计时(design-time)部件可以具有在不同平台中生成运行时实施的能力，所述平台诸如JEE (Java平台，企业版)、ABAP (高级商业应用编程)对象、或微软的.NET等等。此外，一个或多个业务流程应用232可以代表由远程系统250或客户端应用254
经由网络212(例如，通过互联网)访问和运行的基于Web的应用。此外，虽然与特定业务流程应用232相关联的一个或多个流程示出为在节点202内部，但是所述一个或多个流程可以远程储存、引用或执行。例如，特定业务流程应用232的一部分可以是与远程调用的应用相关联的Web服务，而业务流程应用232的另一部分可以是绑定(bundle)用于在远程系统250处的处理的界面对象或代理。此外，任意或全部业务流程应用232可以是其他软件模块或企业应用(未示出)的子代(child)或子模块而不偏离本公开的范围。更进一步地，一部分业务流程应用232可以由直接工作在节点202处的用户执行，也可以由远程工作在远程系统250处的用户执行。如图所示，节点202还可以包括业务流程管理(BPM)运行时234，其提供用于执行业务流程应用232的服务、库和工具。业务流程实例是特定业务流程的运行实例。在一些情况下，可以运转相同业务流程的多个实例(例如，通过不同的业务流程实例可以同时生成多个分立的(discrete)采购订单)。此外，可以在不同的节点运转相同业务流程的多个实例，从而每个业务流程实例与指定到托管业务流程实例的节点的信息相关联。BPM运行时234还可以处理业务流程的任何状态变化，包括与基于接收到的事件运行流程步骤相关联的状态变化。节点202还包括消息中间件240。消息中间件240可以包括软件或硬件基础设施，其被配置以便于在分布式系统之间发送和接收消息并提供事务(故障转移-安全，failover-safe)消息递送、消息排队、以及发布/订阅功能。一般地，消息中间件240允许应用模块分布在异构平台上，并且通过使应用开发人员与各种操作系统和网络接口的细节隔离开来降低开发跨越多个操作系统和网络协议的应用的复杂性。在一些情况下，消息中间件240可以提供用于向消息系统222及其消息队列223发送消息以及从消息系统222及其消息队列223接收消息的方法和技术。节点202的消息中间件240还可以提供诸如Java消息服务(JMS)API的消息中间件应用编程接口(API) 242，其允许跨过不同网络在节点202和不同平台之间进行交互。一个或多个进入消息适配器236还可以包括在节点202中。进入消息适配器236包括硬件或软件部件，其用于接收从外部部件(诸如，远程系统250、其他节点或消息系统222)接收到的消息或事件。进入消息适配器还可以与消息分析器模块238耦合。消息分析器模块238可以是配置为分析接收到的事件以便为该事件确定适当接收者的任何应用。在一些情况下，消息分析器模块238可以确定接收到的事件应该路由入(route)的队列。事件可能需要基于传送事件的外部部件或者与事件相关联的其他内容信息在特定节点处消耗或由具体流程实例消耗。在一些情况下，消息分析器模块238可以将接收到的事件识别为与在相同节点202上运行的业务流程实例相关联的事件。在这些情况下，可以消耗接收到的事件或消息，而不将消息转发或发送到消息队列223或其他系统。—般地，节点202还包括用于存储数据和程序指令的存储器211。存储器211可以包括任何存储器或数据库模块，并且可以采用易失性或非易失性存储器的形式，包括但不限于磁介质、光学介质、随机存取存储器(RAM)、只读存储器(ROM)、可删除介质(removable)、或任何其他合适的本地或远程存储器部件。存储器211可以存储各种对象或数据，包括类、框架(framework)、应用、备份数据、业务对象、作业、网页、网页模板、数据库表、存储业务和/或动态信息的存储库、以及任何其他适当的信息(包括与节点202及其一个或多个业务流程应用232的用途相关联的任何参数、变量、算法、指令、规则、约束、或引用)。存储器211还可以存储数据对象，诸如业务流程模型214和业务流程元数据216。业务流程模型214可以包括代表企业的各个方面或流程的数据对象，业务流程元数据216可以包括与业务流程相关联的任何元数据，其中节点202管理或与该业务流程相互作用。特别地，存储器211可以保持流程实例数据，诸如实例化的流程内容、流程令牌(token)、以及其他流程实例数据。在一些实施中，业务流程模型214可以是基于BPMN(业务流程建模标注)的模型或基于BPEL (业务流程执行语言)的模型。图2所示的环境还包括一个或多个远程系统250。每个远程系统250可以是任何计算设备，其可操作以经由使用有线或无线连接的网络212与至少节点202连接或通信。此夕卜，如图2所示，远程系统250包括处理器256、接口 255、客户端应用254、存储器258。在一些情况下，远程系统250还可以包括图形用户界面(⑶I) 252。一般地，远程系统250包括电子计算机设备，其可操作以接收、传送、处理、和存储与图2中的环境200相关联的任何适当数据。将理解的是，可以存在任何数量的、与外部环境100相关联或在外部环境100外部的远程系统250。例如，虽然所示出的环境200包括远程系统250，但是环境200的可替换实施可以包括以通信方式耦合到节点202的多个客户端，或者适合环境200的用途的任何其他数量的客户端。此外，在环境200的所示出部分以外还可以存在一个或多个附加的远程系统，其能够经由网络212与环境200相互作用。术语“远程系统”也可以指代通过网络212以通信方式与一个或多个服务器耦合的任何计算机、应用、或设备，诸如移动设备。此外，虽然按照每个远程系统250由单一用户使用来描述每个远程系统250，但是本公开预期，很多用户可以使用一台计算机或者一个用户可以使用多台计算机。在一些实施中，远程系统250可以是客户端系统，并且⑶I 252可以与远程系统250相关联。在这些情况下，⑶I 252包括可操作以例如允许远程服务器250的用户与用于任何合适用途(诸如创建、准备、请求、或分析数据、以及查看和访问与商业事务相关联的源文件)的平台的至少一部分连接的图形用户界面。一般地，⑶I 252为特定用户提供由系统提供的或者在系统内通信的业务数据的高效和用户友好的呈现。⑶I 252可以包括多个可定制的框架或具有交互字段、下拉列表、和用户操作按钮的视图。一般地，⑶1252也可以提供允许用户访问和利用应用254的各种服务和功能的一般交互式元素。GUI 252往、往可配置为支持表格和图形(条、线、饼图、状态刻度盘等)的组合，并能够建立实时门户，其中通过关键特点(例如，站点或微站点)描绘标签。因此，GUI 252预期任何合适的图形用户界面，诸如在平台中处理信息并将结果直观呈现给用户的通用Web浏览器、智能引擎(intelligent engine)和命令行界面(CLI)的组合。然而，⑶I 252不是本公开必需的部件。例如，在一些情况下，远程系统250可以是未必包括⑶I的服务器或ERP系统的其他部件。如本公开中所使用的，远程系统250可以包括个人计算机、触摸屏终端、工作站、网络计算机、信息亭、无线数据端口、智能电话、个人数据助理(PDA)、这些或其他设备中的一个或多个处理器、或任何其他合适的处理设备。例如，每个远程系统250可以包括计算机，该计算机包括输入设备和输出设备，输入设备诸如键盘、触摸屏、鼠标、或者可以接受用户信息的其他设备，输出设备传达与节点202(和业务流程应用232)或远程系统250本身的操作相关联的信息，该信息包括数字数据、可视化信息、客户端应用254、或GUI 252。输入设备和输出设备两者都可以包括固定的或可移动的存储介质，诸如磁性存储介质、·⑶-ROM、或者既通过显示器(即，⑶I 252)从远程系统250的用户接收输入、又通过显示器为远程系统250的用户提供输出的其他合适的介质。在一些实施中，节点202也以通信方式与消息系统222耦合，该消息系统222提供了存储在存储器221中的、用于保持进入事件的消息队列223。在一些情况下，存储器221可以是非易失性存储器或数据库系统。消息系统222可以是任何电子计算设备，其被配置为接收、储存从其他部件接收到的事件或消息、或者提供对其他部件的访问。在一些情况下，消息系统222与一个或多个节点202耦合以作为主干或后端系统，而在其他情况下，消息系统222代表通过网络212连接到多个其他节点202、设备和部件的独立(stand-alone)系统。消息系统222可以包括处理器228、接口 225、或用于接收和管理事件的其他部件。在一些实施中，消息系统222包括通过消息中间件的相容性和故障转移(failover)特征。消息系统222处的消息中间件226可以以事务方式来接收(入队)和转发(出队(dequeue))消息，而不丢失消息或递送重复消息。此外，消息中间件226还可以提供消息顺序，诸如先入先出(First-In-First-Out，FIFO)顺序。换句话说，消息系统222处的消息中间件226可以用于保持进入事件，以用于流程实例稍后检索。虽然消息中间件226可以实施为消息系统222处的中央数据库，但是它也可以使用任何适当方法实施，诸如本地持久性(localpersistency)或懒散复制(lazy replication)技术。例如，诸如远程系统250的外部部件可以向云网络中的特定节点202发送事件或请求。事件可能需要在不同位置被消耗，然而，节点202可以向消息系统222转发事件以将事件保持在消息队列223中，以使得适当的业务流程可以从消息队列223检索事件用于消耗。可以由消息服务224执行由消息系统222提供的、用于为接收到的事件提供队列的功能。在某些实施中，消息服务224也可以向特定节点发送通知消息，该特定节点包含将用于消耗存储在消息队列223中的特定事件的流程实例。当将消息或事件发送给消息队列223时，通知消息也可以由节点202本身(诸如通过消息中间件240)提供。虽然在图2中将消息系统222描绘为关于节点202远程定位，但是在一些实施中，消息系统222可以定位为BPMS中的多个节点之一的一部分、或者分布在BPMS中的不同节点上。虽然图2描述为包含多个部件或者与多个部件相关联，但是并非图2的环境200内所示出的所有元素都可以用在本公开的每个可替换的实施中。例如，这里所描述的元素中的一个或多个可以位于环境200的外部，而在其他情况下，某些元素可以包括在环境200的内部，或者作为所示出的实施中的其他描述元素以及未描述的其他元素中的一个或多个元素的一部分。此外，图2所示出的某些元素可以与其他部件相结合，以及用于除了这里所描述的那些用途以外的替代或附加用途。图3示出了用于可扩展的(scalab le)事件分派的示例过程300。如图3所示，在310处，在第一云实例320 (即，计算机节点320)上接收消息(即事件)305。事件305最初可以转发到计算机节点320中的特定流程实例。在某些情况下，第一计算机节点320可以不具有被分配以消耗事件305的流程实例或与事件305相关联的流程实例。相反，位于其他计算机节点的一个或多个其他业务流程实例可以是事件305的适当接收者。因此，在325处确定受影响的流程实例。受影响的流程实例的确定可以包括相关程序，其中，接收流程实例基于消息的有效载荷和流程的数据内容与进入消息进行匹配。在其他情况下，消息可能已经在逻辑上涉及(refer to) 一个具体流程实例，从而不要求明确相关。受影响的流程实例345可以位于第一计算机节点320处或者位于不同的计算机节点340处。如果受影响的流程实例345位于不同的计算机节点340处，则事件305在330处经由消息中间件排队进入具体实例的队列。在某些情况下，多个流程队列可以在特定计算机节点处托管，而且每个流程队列与具体业务流程实例相关联。因此，消息中间件可以用于基于与接收流程实例相关联的流程实例标识符来识别用于保持事件305的具体流程队列。如图3所示，流程队列可以是通过消息中间件335访问的数据库支持的流程队列。在任何情况下，消息中间件都可以提供接口，该接口允许保存进入消息，用于由接收流程实例随后进行检索。在某些实施中，消息中间件335可以关于为与仓库或主干系统中的、对于多个计算机节点上的不同流程实例可用的集中式数据库(centralizeddatabase)来实施消息中间件335，同时每个流程实例为了检索用于消耗的事件而访问消息队列223。可替换地，消息中间件335可以依靠其他方法，诸如利用本地持久性的复制协议，来为进入的事件提供分布式队列。如果受影响的流程实例位于与第一次接收到事件305的节点320相同的计算机节点，则可以将事件305递送到适当的流程实例或者由适当的流程实例消耗，而不将事件305保持在消息中间件335中。在一些实施中，在确定哪个流程实例受到影响之后并且在将事件305保持在流程队列中之后，通过消息中间件主动通知受影响的流程实例345。在一些情况下，对计算机节点340的通知调用可以避免计算机节点340处由流程实例345检索并消耗事件305的延迟。在一些实施中，在350处，包含受影响的流程实例345的计算机节点340可以在消息中间件335处执行流程队列的定期轮询，以确定在消息中间件335处是否已经接收到特定的事件305。然后，在确定已经接收到用于由计算机节点340处的流程实例345消耗的事件305之后，计算机节点340可以从消息中间件335检索事件。一旦在计算机节点340处已经检索到事件305，则可以由流程实例345消耗该事件305。可以在BPMS中的每个节点上实施如上关于图3所述的事件到消息中间件的转发。然而，在一些情况下，仅关于BPMS的某些节点、某些流程实例、某些接收到的事件、或者在某些条件下将事件保持在消息中间件中。通过将事件保持在信息系统222处的流程队列223中，可以提高交换事件时的BPMS的性能，尤其是在某些情况下。在用户任务与调用流程实例非常频繁地相互作用的情况下，将接收到的事件保持在流程队列223中可以减少与流程实例的频繁调用相关联的延迟。例如，呈现给多个用户(用户需要向表格中填写数据并在完成之后将那个表格传递回流程实例)的表格可能占用资源，因为任何用户触发的任务状态的变化可能导致事件发送给流程实例。假设用户任务的处理时间相对较长，则通过消息中间件轮询方式向流程实例传递任务状态变化事件可以有利于BPMS的性能。图4示出了用于处理在计算机节点处从外部部件接收到的消息的示例过程400。首先，在405处，识别在第一计算机节点接收到的消息。该消息可以是与从外部设备(如远程系统250)处的外部软件部件接收到的事件相关联的消息或其他信息。在410处，分析接收到的消息的内容。特别地，在分析过程中，在415处识别与该消息相关联的业务流程实例。例如，特定业务流程实例可以被分配以处理消息或基于消息执行某些动作。在一些情况下，该消息可以指定与该消息相关联的特定业务流程实例，而在其他情况下，可以基于规则集或关联(association)的其他方法来推导与该消息相关联的特定业务流程实例。虽然可以在执行一个或多个业务流程实例的第一计算机节点接收消息，但是为接收到的特定消息分配的业务流程实例可以不位于相同的计算机节点上。因此，在420处，确定所识别的业 务流程实例是否正在第一节点上运行。如果所识别的业务流程实例正在第一节点上执行，则在440处，向所识别的业务流程实例提供接收到的消息，其中，该消息及其内容可以在第一节点上本地访问和消耗。如果所识别的业务流程实例未在第一节点上执行，则在第二计算机节点上处理接收到的消息。然而，第二计算机节点的位置可能尚未识别。因此，在425处，将消息发送到用于由第二计算机节点检索的消息中间件。在一些实施中，在消息中间件内可以启用主动通知，以便向第二计算机节点通知等待由第二计算机节点检索的消息。因此，在430处，确定是否已经启用主动通知。如果已经启用主动通知，则在435处，将通知消息发送到第二计算机节点。主动通知可以包括与在435处向消息队列发送的特定消息有关的信息、或者是没有更多细节的、消息队列中与第二计算机节点相关联的消息可用的通知。如果尚未启用主动通知，则过程返回到正常操作并等待另外的消息的到来。图5示出了用于从消息队列检索相关消息的示例过程500。如上关于图4所述，可以在第一计算机节点处接收消息，但是然后在确定该消息将由不同于接收到该消息的第一计算机节点的第二计算机节点消耗或者与位于第二计算机节点的业务流程实例有关之后，使用消息中间件将该消息转发给集中式消息队列。在一些情况下，通过消息中间件可以将通知发送给第二计算机节点，以便向第二计算机节点通知从集中式消息队列检索的消息的可用性。因此，在505，在第二计算节点处确定是否已经接收到指示可能的消息可用于检索的通知。在一些实施中，通知方法与轮询算法耦合。接收流程实例可以轮询消息队列以在一定时间间隔挂起(Pend)消息，但是在从第一计算机节点接收到通知的情况下，也可以立即检查队列。因此，如果已经接收到指示消息队列中的消息可用于第二计算机节点的通知时，则在515处为相关消息轮询集中式消息队列。如果尚未接收到通知，则在510处确定是否到了为检索任意可用消息而轮询集中式消息队列的时间。对于每个业务流程实例而言，轮询时间可以是不同的，以便允许正在执行的业务流程之间的差异。例如，依赖于流程实例是否是时间关键(time-critical)或非时间关键(non-time-critical)流程实例，每个业务流程实例可以与适合于该特定业务流程实例的轮询时间相关联。在一些情况下，轮询时间可以由用户或管理员手动修改、设置为默认值，或者基于关于接收到新消息的平均或中值时间的计算而动态修改。在一些情况下，消息可以在不同时间发送给业务流程，以便可以使用默认轮询时间。如果未到轮询消息队列的时间，则过程500返回以确定是否从相关业务流程节点接收到通知(在505处)。如果到了轮询消息队列的时间，则在515处，第二计算机节点为相关消息轮询集中式消息队列。如果在520处没有相关消息存储在集中式消息队列中，则过程500返回以确定是否从消息中间件接收到通知(在505处)。如果消息队列中存在相关消息，则在525处从集中式消息队列检索相关消息。在从消息队列检索到消息之后，在530处，在第二计算机节点的适当业务流程实例中消耗该消息。图6示出了涉及进入消息的示例业务流程600。如图6所示，关于第一活动(activity)630发起实例事务流程。在业务流程期间，中间消息事件625在上部流 程分支650上等待进入消息，而且用户任务620被分派给人类处理员，等待在下部分支660上完成。同时触发两个分支。换句话说，在用户处理来自下部分支的用户任务620期间、之前或之后，可以接收用于中间消息事件625的消息。可以使用用于处理基于云的环境的内在复杂性的专用协议，在基于云的环境中，在任何云实例上都可以独立接收任何要消耗的事件(例如，由中间消息事件625接收的消息610或者用户任务620中的任务状态变化)。事实上，可以在第一云实例上运转业务流程，而在另一个云实例上接收用于中间消息事件的消息(例如，通过通用负荷平衡器进行路由和递送)，而且在第三云实例上接收来自用户的、处理他的收件箱的任务的Web请求。这两个事件(由中间消息事件625接收的消息610和来自用户620的任务状态变化)都需要以可靠方式到达业务流程而不引入显著的性能损失或损坏云网络的横向扩展(scale out)性能。将接收到的事件保持在消息队列中允许流程实例在流程实例的生命周期内驻留在特定云实例中，有时被称为业务流程“粘性(stickiness)”。除此之外可以包括云拓扑的变化(例如，分配额外的云实例以处理有效载荷的一部分)。为了使业务流程以事务方式可靠且相容地接收事件，按照与当将入站(inbound)事件递送到BPMS运行时234时相同的事务将任何入站事件(例如，图6中的任务状态变化620和消息610)本地保持在具有消息队列223的消息中间件上。当在与接收流程当前所驻留的云实例不同的云实例上接收到事件时，将事件保存在由流程实例(假定将事件分派给该流程实例)检索的、数据库支持的队列中。在一些情况下，可能需要将事件分派给到多个流程实例。如果将事件递送给接收流程当前所驻留的云实例，则绕过消息队列，立即将事件递送给该流程实例。这里可以不需要进一步步骤，因为已经成功将事件递送给用于消耗该事件的适当流程实例。然而，如果将事件递送给接收流程实例并未驻留的云实例，则可以将该事件保持在集中式消息队列中，以便将该事件递送给接收流程实例。图7和图8示出了向适当云实例分派一个或多个事件的示例流程700和800。在图7所示的示例中，在第一云实例处可以接收已完成的用户任务的指示。已完成的用户任务可以是与用户相关联的特定任务状态需要改变的用户指示。因此，在710处，在第一云实例处接收到指示。在720处，可以从与第一云实例相关联的BPMS运行时获取任务状态变量。然后，在730处，第一云实例向BPMS运行时提交请求以改变任务状态。在某些情况下，当涉及共享状态时，由云实例接收到的事件类型可以要求保护(safeguard)或“锁定(lock) ”流程状态变量，以防止在基于接收到的事件利用变化来更新业务流程状态变量时的业务流程状态的不必要的变化。例如，一些类型的事件触发新的状态变量的创建。由于新的状态变量在创建时仍不为现有云实例所知，因此其他流程实例不会引起新的状态变量不必要的变化并且不需要锁定机制。然而，一些类型的事件可能触发改变或删除现有的状态变量。在这些情况下，可以实施中央锁定机制以锁定现有的状态变量并防止对状态变量不必要的访问。然而，只有在状态变量同时可以由多个部件、进程等操作(即，状态变量在它们之间共享)的情况下，才需要锁定状态变量。在大多数情况下，不要求锁定协议。转向所示出的示例，由用户提交的任务状态的变化可以要求锁定与任务状态相关联的状态变量，因为所请求的变化导致在编排任务的流程实例和向用户呈现任务的任务管理部件之间所共享的现有状态变量的修改。如图7所示，在740处，BPMS运行时可以通过访问中央锁定服务来获得任务状态变量的锁定，以防止对任务状态变量的一致性冲突(consistency violation)。一旦已经由中央锁定服务锁定了任务状态变量,贝U BPMS运行时可以在750处生成改变事件以对从第一云实例接收到的任务变化请求做出响应。然后，在760处，将事件保持或入队到消息中间件(诸如如图2所示的消息队列223)中，以便将该事件分派给适当的接收流程实例以完成任务状态变化。在将事件传到中央数据库之后，在 770处，可以通过中央锁定服务释放对任务变量的锁定。在一些实施中，可以将通知调用发送给接收流程实例所位于的云实例处，以便向该云实例告知事件可用于检索。在这些情况下，在780处，可以将通知作为信号事件发送给与第二云实例(其与接收流程实例相关联)相关联的BPMS运行时。在图8中，在780处，在第二云实例的BPMS运行时处可以接收信号事件。在接收流程实例所驻留的节点上，可以实施某些机制以允许本地流程实例接收事件。在一些实施中，接收流程实例可以在相关数据流队列上对进入事件执行轮询方法或定期检查。检查可以合并成单一的、定期的数据库查询，其对可以在本地云实例上驻留的所有流程实体处所接收的所有事件检查流程队列。具体流程的数据库查询可以是单一事务的一部分，该单一事务为在本地云实例上驻留的所有流程实例检查事件队列。可替换地，每个流程实例可以具有其自己的轮询事务，以便在不同流程之间实现更好的解耦并配置单独的轮询间隔。因此，数据库事务的数量可以保持最小。虽然轮询方法可以通过云实例实施，但是如果接收到指示在中央数据库存在进入事件的信号事件，则云实例的BPMS运行时可以立即从中央数据库检索该事件，这可以降低仅依靠轮询所造成的一些延迟。使用定期轮询请求可以执行从消息队列取回新到达的事件，其中，数据库检查之间的时间间隔可对具体流程实例进行配置(如果未对流程实例配置间隔，则可以对流程类型或所有流程类型使用默认值)。在一些实施中，可以基于先前接收事件的频率、与接收业务流程实例相关联的业务流程类型、或与业务流程实例相关联的任何其他因素自动调整数据库检查之间的时间间隔。当另一个云实例主动向流程所驻留的云实例通知事件已经包括在与该云实例相关联的消息队列之一中时，可以忽略(override)轮询间隔。因此，可以避免由过长的轮询间隔所造成的增加的延迟。在省略通知机制或丢失通知的情况下，仍然保持相容性，因为下一个轮询间隔将最终从消息队列中获取消息。在所示出的示例中，第二云实例的BPMS运行时在810处启动中央数据库的轮询，在820处触发对中央数据库的查找调用以搜索新的排队事件。在这里，可以由第二云实例检索如上关于图7所述的通过第一云实例提交给中央数据流的事件，以进行消耗。在一些情况下，检索到的事件需要成为流程状态的一部分，这可以通过在流程状态变量变化的过程中物化(materialize)事件来实现。然而，在第二云实例处接收到的事件可能需要锁定与接收云实例相关联的状态变量。因此，在840处将事件应用于相应状态变量之前，在830处从中央锁定服务请求锁定机制。然后将事件从消息队列取出并从消息队列清除(出队)。在流程实例已经从队列取出事件并且将事件应用于状态变量的事务已经提交(commit)之后，在850处可以释放锁定。在这里，BPMS运行时然后可以选择性地触发对状态变量变化做出反应的连续流程步骤。这些步骤通常将影响流程实例的控制流和/或数据流方面。在某些情况下，触发这些流程步骤可能延迟或取决于其他条件。在这些情况下，具体化的事件(即，流程状态变量)仍然是流程状态的一部分，但实际上可能只是随后由流程消耗。在这些情况中的一些情况下，流程可能永远不会消耗事件。在这些情况下，BPMS运行时可以被配置为要么(I)当流程已经终止时移除具体化的流程，要么(2)当流程已经终止时为其他流程释放事件。例如，在由流程实例消耗消息流且其中每个实例仅处理固定数量的消息的场景下，超过固定数量的消息需要由后续流程实例拾取。在其他情况下，一旦流程已经终止，则事件实际上可能变 得不相关(irrelevant)。例如，流程实例可以被取消，而相关联的用户任务仍在进行中。当该用户任务完成时，不需要将相应事件分派给另一个流程实例而是可以将其丢弃。前面的附图和伴随的描述示出了示例流程和计算机可实施的技术。但是环境100 (或它的软件或其他部件)考虑使用、实施或运行用于执行这些和其他任务的任何合适的技术。将要理解的是，这些流程仅用于说明性目的，而且所描述的或类似技术可以在任何适当时间执行，包括并发地、单独地或以组合方式。此外，这些流程中的许多步骤可以同时发生和/或与所示的顺序不同的顺序发生。此外，环境100可以使用具有额外的步骤、更少的步骤、和/或不同的步骤的流程，只要该方法保持适当。换句话说，虽然已经根据某些实施例和一般关联的方法描述了本公开，但是这些实施例和方法的改变和置换对本领域普通技术人员将是明显的。因此，示例实施例的以上描述不限定或限制本公开。在不偏离本公开的精神和范围的情况下，其他变化、替换和改变也是可能的。
权利要求
1.一种由一个或多个处理器执行的用于向业务流程实例分派事件的计算机实施的方法，该方法包括以下操作 在运行第一业务流程实例的第一计算机节点处接收消息； 识别与所述消息相关联的第二业务流程实例；以及 如果所述第二业务流程实例没有位于所述第一计算机节点处，则向用于由所述第二业务流程实例检索的消息队列发送所述消息。
2.如权利要求I所述的方法，还包括向托管所述第二业务流程实例的第二计算机节点发送通知消息，所述通知消息指示能够从所述消息队列检索所述消息。
3.如权利要求2所述的方法，其中，所述第一计算机节点和所述第二计算机节点是在业务流程管理套件中使用的计算设备。
4.如权利要求I所述的方法，其中，所述消息队列是基于所述第二业务流程实例的流程实例标识符来识别的。
5.如权利要求I所述的方法，其中，在所述第一计算机节点处接收所述消息包括从对在云网络处接收到的消息进行分发的负荷平衡器接收所述消息。
6.如权利要求I所述的方法，其中，识别与所述消息相关联的第二业务流程实例还包括识别与所述消息相关联的多个业务流程实例。
7.如权利要求I所述的方法，还包括确定所述消息是否指示改变共享状态变量。
8.如权利要求7所述的方法，还包括如果所述消息指示改变共享状态变量，则获得对所述共享状态变量的锁定。
9.如权利要求8所述的方法，其中，获得对所述共享状态变量的锁定包括防止除了所述第二业务流程实例以外的其他部件和业务流程实例访问所述共享状态变量。
10.一种在非临时性、有形存储介质上编码的计算机程序产品，该产品包括用于使一个或多个处理器执行以下操作的计算机可读指令 启动从计算机节点到消息队列的轮询请求； 基于所述轮询请求识别用于检索的所述消息队列中的消息； 从所述消息队列检索并出队所述消息；以及 使用与所述消息相关联的业务流程实例来处理所述消息。
11.如权利要求10所述的计算机程序产品，其中，所述轮询请求包括对所述消息队列的周期性请求，以确定是否已经接收到被分配为由所述计算机节点处理的进入消息。
12.如权利要求11所述的计算机程序产品，其中，在所述周期性请求之间以特定时间间隔将所述周期性请求发送给所述消息队列。
13.如权利要求12所述的计算机程序产品，其中，所述特定时间间隔能够操作以基于与所述业务流程实例相关联的内容进行调整。
14.如权利要求12所述的计算机程序产品，其中，如果接收到指示所述消息队列中的消息的可用性的通知时，则将立即轮询请求发送给所述消息队列，其中，在以所述特定时间间隔发送下一周期性请求之前发送所述立即轮询请求。
15.如权利要求10所述的计算机程序产品，还包括在从所述消息队列检索到所述消息之前，获得对与所述业务流程实例相关联的共享状态变量的锁定。
16.如权利要求15所述的计算机程序产品，其中，获得对所述共享状态变量的锁定包括防止除了与所述消息相关联的业务流程实例以外的其他部件或业务流程实例访问所述共享状态变量。
17.—种系统,包括 存储器，其能够操作以存储在所述系统处接收到的消息；以及 一个或多个处理器，其能够操作以 识别与所述消息相关联的业务流程实例；以及 如果所述业务流程实例没有位于所述系统处，则向用于由所述业务 流程实例检索的消息队列发送所述消息。
18.如权利要求17所述的系统，其中，所述ー个或多个处理器还能够操作以向托管所述业务流程实例的计算机节点发送通知消息，所述通知消息指示能够从所述消息队列检索所述消息。
19.如权利要求17所述的系统，其中，识别与所述消息相关联的业务流程实例还包括识别与所述消息相关联的多个业务流程实例。
20.如权利要求17所述的系统，其中，所述ー个或多个处理器还能够操作以获得对与所述业务流程实例相关联的共享状态变量的锁定，其中，获得对所述共享状态变量的锁定包括防止除了所述业务流程实例以外的其他部件和业务流程实例访问所述共享状态变量。
全文摘要
本公开涉及用于在基于云的基础设施中提供高负荷业务流程可扩展性的系统、软件和计算机实施的方法。一个流程包括在运行第一业务流程实例的第一计算机节点处接收消息的操作。识别与该消息相关联的第二业务流程示例。如果第二业务流程实例没有位于第一计算机节点处，则向由第二业务流程实例检索的消息队列发送该消息。
文档编号G06F9/46GK102760074SQ20121012405
公开日2012年10月31日 申请日期2012年4月25日 优先权日2011年4月26日
发明者S.巴尔科 申请人:Sap股份公司