WO2007084991A2 - Rules engine for enterprise system - Google Patents

Abstract

An example embodiment provides a process relating to an inference engine for enterprise systems and enterprise contracts In the example, the inference engine receives a fact and stores it in an input queue. Then the inference engine retrieves the fact from the input queue and routes the fact to a schedule queue on the basis of the fact's processing schedule and a condition that is part of a rule. The inference engine retrieves the fact from the schedule queue in accordance with the processing schedule and routes the fact to a rule executer on the basis of the fact's contents The rule executer applies an action to the fact, where the action is also part of the rule and the action transforms the fact or creates new facts. Then the inference engine routes the transformed fact or new facts to the input queue and possibly to a persistent storage device.

Description

PATENT APPLICATION

Rules Engine for Enterprise System

Inventors. Marcos Vescovi, a citizen of the United States, and Chris Hagmann, a citizen of Switzerland

Assignee: mHave, LLC.

800 Sea Spray Lane, Suite 213 Foster City, CA 94404 United States of America

Prepared By Law Office of Mark J. Spolyar

2200 Cesar Chavez Street, Suite 8 San Francisco, CA S>4 !24 (415) 826-7906

(41 5) 480-1780 (fax) Customer Number: 30505

RULES ENGINE FOR ENTOtPRlSE SYSTEM

CROSS-REFERENCE- TO RELATED APPLICATIONS

[0001] This application claims the benefit of and is related to the following commoniy-owned U.S. provisional patent application, whose disclosure is incorporated herein by reference in its entirety for ail purposes: U.S. Provisional Application No. 60/760,098, entitled '"Enterprise Rule Engine", filed on January 19, 2006.

TECHNSCAI, FIELD

[0002] The present disclosure relates to business or inference rules engines and distributed systems.

BACKGROUND

[0003] A production system (or production rale system) is a computer program which consists primarily of a set of rules about behavior and which is used to provide some form of artificial intelligence (Al). These rules, termed productions, are a basic representation found useful in Aϊ planning, expert systems, and action selection, A production system provides the mechanism to execute productions hi order to achieve some goal for the system.

[0004] Typically, productions consist of two parts: a sensory precondition (or "IF" statement) and an action (or "THEN"). If a production's precondition matches the current state of knowledge, then the production is said to be triggered, ϊf a production's action is executed, it is said to have Sired. A typical production system also contains a database, sometimes called working memory, which maintains data about current state or knowledge, and a rule interpreter. The rule interpreter usually provides a mechanism for prioritizing productions when more than one is triggered. Rule interpreters generally execute a forward chaining algorithm for selecting productions to execute to meet current goals, which can include updating the system's data or knowledge. The condition portion of each rule (left-hand side or LBS) is tested against the current state of the working memory

[0005] Idealized or data-oriented production systems often assume that any triggered conditions w ilϊ be executed, e g , that the consequent actions (right-hand side or RHS) will update the agent's knowledge, removing or adding data to the working memory, if nothing else The system stops processing either when the usei mteimpts the forwaid chaining loop, when a

en number of cvcles has been performed, when a "halt" RHS is executed, or when no rules

true LHSs Real-time systems, in contrast, often will choose between mutually exclusive productions, since actions take time, only one action can be taken In such systems, the rule interpreter, or rules engine (also called inference engine), c> cles through two steps (a) matching production rules against the database, followed by selecting which of the matched rales to apply, and (b) executing the selected actions In many instances, the αiles or inference engine is a separate component of a larger program or application

[0006] Production systems ma\ v ary on the

power of conditions in production rules Accordingly, the pattern matching algorithm which collects production rules with matched conditions raa\ range from the nane, in which rules are tried in sequence and until the first match, to the optimized, in which rules are "compiled" into a network of inter-related conditions The latter is illustrated by the RFTK algorithm, designed by Charles L horgj in 1983. which is used in a series of production systems, called OPS and originally developed at Carnegie Mellon

culminating in OPS5 in the early eighties [0007] A computer cluster is a group of looselv coupled computers that work together so closely that they can be

as though they ate a single computer The components of a cluster are commonly, but not always, connected to each other through local area networks Clusters are usually deployed to improve performance and/or availability over that provided by a single computer, while typically being much more cost-erTecth e than single computers of comparable speed oi availability

[000H] High-availability (rlΛΛ clusters are implemented primarily for the purpose of improving the availability of the services which the cluster provides They operate by

ing redundant nodes, which are then used to provide service when system components fail HA cluster implementations attempt to manage the redundancy inherent in a cluster to eliminate single points of failure Load-balancing clusters operate by

all workload come through one oi more load-balancing front ends, which then distribute it to a collection of back end servers. Although they are primarily implemented for improved performance, they commonly include high-availability features as well Such a cluster of computers is sometimes referred to as a server farm. High-performance clusters (HPC) are implemented primarily to provide increased performance by splitting a computational task across many different nodes in the cluster and are most commonly used in scientific computing Such clusters commonly run custom programs which have been designed to exploit the available parallelism HPC clusters are optimized for workloads which require active communication between jobs or processes Tunning on separate computer nodes during the computation. These include computations where intermediate results from one node's calculations will affect future calculations on other nodes

SUMMARY

[0009] In particular embodiments, the present invention provides methods, apparatuses, and systems directed to the creation of a business or inference rules engine that executes in an enterprise environment which might comprise a distributed system

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure I is a diagram showing an example distributed computing system or cluster, which might be used with a.π embodiment of the present invention

[00! 1] Figure 2 is a diagram showing a system architecture for a rules-engine server, which might be used with the present invention in particular embodiments.

[0012] Figure 3 is a diagram showing the main components of a rules engine, which might be used in some embodiments of the present invention

[0013] Figure 4 is a diagram showing a flowchart of a process which a rules engine might use to process an XMI. message, in some embodiments of the present invention.

[0014] Figure 5 is a diagram showing the components of a contract-execution engine, which might be used in some embodiments of the present invention.

[0015 j Figure 6 is a diagram showing a flowchart of a process which a contract-execution engine might use to process an event, in some embodiments of the present invention. [0016] Figore 7 is a diagram showing the flow of a message in a contract-execution engine, which How might be used in some embodiments of the present invention. [00 i 7] Figure 8 is a diagram showing the flow of an "under-processing" message in a contract- execution engine, which flow might be used in some embodiments of the present invention. [0018] Figure 9 is a diagram showing a flowchart of a process which might be used by a term set router in a contract-execution engine, in some embodiments of the present invention. [0019] Figure 10 is a diagram showing a flowchart of a process which might be used by a terms router in a contract-execution engine, in some embodiments of the present invention. [0020] Figure 1 1 is a diagram showing a flowchart of a process which might be used by a term executer in a contract-execution engine, in some embodiments of the present invention. [0021 ] Figure 1.2 is a diagram showing the flow of conditional caching in a contract -execution engine, which flow might be used in some embodiments of the present invention. [0022] Figure 13 is a diagram showing a flowchart of a process which might be used by an optimized terms router in a contract-execution engine, in some embodiments of the present invention.

[0023] Figure 14 is a diagram showing a flowchart of a process which might be used by an optimized terra executer in a contract-execution engine, in some embodiments of the present invention.

[0024] Figure 15 is a diagram showing a flowchart of a process which might be used for caching a new entity such as a contract, participant, or plan in a contract-execution engine, in some embodiments of the present invention.

[0025] Figures 16, 17, 18, 19, 20, 21, and 22 show a use case, which might be used with a contract-execution engine, in some embodiments of the present invention. [0026] Figure 23 is a diagram showing a flowchart of a process which might be used when adding an entity to a contract-execution engine, in some embodiments of the present invention.

DESCRIPTION OF EXAMPLE EMBODIMENTS)

[0027] The following example embodiments are described and illustrated in conjunction with apparatuses, methods, and s> stems which are meant to be examples and illustrative, not limiting in scope

A Distributed Computing System or Cluster

|0028| Hg 1 illustrates an example distributed computing system, consisting of one master server 101, four slave servers 102, and a client 103, which system might be used to run a rules engine HI some embodiments The distributed computing system comprises a cluster of servers in which the slave servers are typically called nodes Though onh four nodes are shown in Fig 1, the number of nodes might well exceed dozens in some embodiments Ordinarily, nodes in a cluster are redundant so that if one node crashes while performing a particular application, the cluster software can restart the application on one or more otheτ nodes |0029] Multiple nodes also facilitate the parallel processing of a large database, including the "working memory'^* of a rules engine In some embodiments of the present invention, a master serv er, such as 101 , might receive a rules-engine job le g . a set of production rules to be checked against working memory) from a client such as 103. and then assign tasks resulting fjtom that job to slave servers or nodes, such as servers 102, which do the actual work of executing the assigned tasks upon instruction from the master and which move data between tasks Likewise, in some embodiments of the present invention, a master server, such as server 101 , governs the distributed file s\ stem needed to support parallel processing of large databases In particular, the master server manages the file system's namespace and block mapping to nodes, as well as client access to files, which are actual!) stored on

servers or nodes, such as 102 In turn, in some embodiments, the slave servers do the actual work of executing iead and write requests from clients, such as 103, and perform block creation, deletion, and replication upon instruction from the master server

[0030] Figure 2 illustrates, for didactic purposes, a hardware system 200, which might be used as a server in a cluster or a standalone server that runs the aϊles engine described below, in particular embodiments Additionally. Figure 2 might illustrate a client that runs an application program that uses the rules engine In one embodiment, hardware s\ stem 200 comprises a processor 202, a cache memory 204, and one or more software applications and drivers directed to the functions described herein Additionally, hardware s\ stem 200 includes a high

b performance input/output (I/O) bus 206 and a standard I/O bus 208. A host bridge 210 couples processor 202 to high performance I/O bos 206, whereas I/O bus bridge 212 couples the two buses 206 and 208 to each other. A system memory 214 and a network/communication interface 216 couple to bus 206. Hardware system 200 may further include video memory (not shown) and a display device coupled to the video memory. Mass storage 21 S and I/O ports 220 couple to bus 208. In some, but not all, embodiments, hardware system 200 may also include a keyboard and pointing device 222 and a display 224 coupled to bus 20S. Collectively, these elements are intended to represent a broad category of computer hardware systems, including but not limited to general purpose computer systems based on the x86-comρatible processors manufactured by Intel Corporation of Santa Clara, California, and the x86-compatible processors manufactured by Advanced Micro Devices (AMD), Inc., of Sunnyvale, California, as well as any other suitable processor.

[0031] The elements of hardware system 200 are described in greater detail below. In particular, network interface 216 provides communication between hardware system 200 and any of a wide range of networks, such as an Ethernet (e.g., IEEE 802.3) network, etc. Mass storage 218 provides permanent storage for the data and programming instructions to perform the above described functions implemented in the RF coverage map generator, whereas system memory 214 (e.g., DRAM) provides temporary storage for the data and programming instructions when executed by processor 202, 3/0 ports 220 are one or more serial and/or parallel communication ports that provide communication between additional peripheral devices, which may be coupled to hardware system 200.

[0032] Hardware system 200 may include a variety of system architectures; and various components of hardware system 200 may be rearranged. For example, cache 204 may be oii- chip with processor 202. Alternatively, cache 204 and processor 202 may be packed together as a "processor module," with processor 202 being referred to as the "processor core." Furthermore, certain embodiments of the present invention may not require nor include all of the above components. For example, the peripheral devices shown coupled to standard I/O bus 208 may couple to high performance I/O bus 206 In addition, in some embodiments only a single bus may exist with the components of hardware system 200 being coupled to the single bus Furthermore, hardware system 200 may include additional components, such as additional processors, storage devices, or memories.

[0033] In particular embodiments, the processes described herein are implemented as a series of software routines run by hardware system 200. These software routines comprise a plurality or series of instructions to be executed by a processor in a hardware system, such as processor 202, Initially, the series of instructions are stored on a storage device, such as mass storage 218. However, the series of instructions can be stored on any suitable storage medium, such as a diskette, CD-ROM, ROM, EEPROM, etc. Furthermore, the series of instructions need not be stored locally, and could be received from a remote storage device, such as a server on a network, via network/communication interface 216. The instructions are copied from the storage device, such as mass storage 218, into memory 214 and then accessed and executed by processor 202.

[0034] An operating system manages and controls the operation of hardware system 200, including the input and output of data to and from software applications (not shown). The operating system provides an interface between the software applications being executed on the system and the hardware components of the system. According to one embodiment of the present invention, the operating system is the Linux operating system. However, the present invention may be used with other suitable operating systems, such as the Windows® 95/98/NT/XP operating system, available from Microsoft Corporation of Redmond, Washington, the Apple Macintosh Operating System, available from Apple Computer Inc. of Cupertino, California, UNIX operating systems, and the like.

B. Rules Engine^'s Components and Processes

[0035] As noted above, a rule is an 'Hf-Then" statement where the "If part corresponds to the condition and the "Then" part corresponds to the action of the rule. A Riles engine is an inference engine that executes rules against a set of "^"facts" or data set. When a rule condition matches a fact, the rules engine applies the rule action to the fact, generating new facts that become available to the rule engine for further processing. The process continues until no rules match the existing facts or other end conditions apply. In the case of real-time continuous operation, the rules engine continuously processes facts as they enter the rule engine in reai- time

[0036] Figure 3 is a diagram showing the main components of a rules engine, which might be used in some embodiments of the present im ention As shown in Figure 3, the rules engine comprises Ca) a schedule router, (b) a rule router, (c) a rule executes and (d) an event saver Also as shown in figure 3, a main component of the rules engine is the "'queue" (see e g , the Input Queue, the DB (database) Queue, the Monthh Queue, the Dai Iv Queue, the Real- lime Queue, and the Rule 1, Rule 2, and Rule N Queues) In particular embodiments, the rules engine uses JMS (Ja\a Messaging System) queues, which can be implemented in memorv or disk and which facilitate as> nchronous operation of the other components of the rules engine (The JMS API is a Ja\ a Message Oriented Middleware (MOM) APS for sending messages between two or more clients JMS is a specification developed under the Jav a Community Process as JSR ^ i 4 ) As indicated abo\ e. the rules engine^'s queues can he depkn ed in a single machine or on multiple machines in a cluster

[0037] In particular embodiments, the rules engine uses XML messages to represent "facts'^" and Java methods to represent "rules^'" Figure 4 is a diagram showing a flowchart of a process which a ailes engine might use to process an XML message, in some embodiments of the present invention In the process's first step 401 , a new fact represented by an XML message enters the rules engine and is stored in the Input Queue In the process^'s next stop 402, the Schedule Router routes the XML message to the appropriate Schedule Queue (e g , Real-Time, Daily, W eekly, Monthh . etc }. depending on the message's processing schedule, e g , whether the message will be pioeessed in real-time on a daily, « eekly or monthly basis and so on Rach Schedule Queue has an associated Condition (e g „ an "'If" part of a aile) that is exaluated against each XML message to check whether the XMI message belongs in the Schedule Queue [0038] in step 403 of the piocess, the Rule Router jtetrieves the XML message from the Schedule Queue at the apptopriate time Ce g , teal -time, daily, weekly, monthly, etc ) and checks which rule conditions match the XML message When performing this cSieeL the rules engine uses various strategics to test only the relevant rules and thereby optimize performance Once the check is performed ihe Rule Router completes step 403 by routing ihe XML message to the appropriate Rule Hxecuter Here again, there are various strategies for routing the XJML messages to Rule Rxecuters, such as load balancing (in which case, the same rule πύφi be executed on different machines) or partitioning (in which case, a specific machine might execute only a particular set of rules) It will be appreciated that domain knowledge might provide other routing strategies

[0039] hi step 404 of the process, the Rule Exccuter applies the Action part of the rule by processing the XMi.. message, e g , transforming it or creating new XML messages Then in step

405, the Rule Exccuter routes the transformed or new XML messages into the Input Queue for further processing by the rules engine Also, as shown in step 406, the Rule Executer might route the XMI. Message to the Event Saver component for persistence in a database, memory, or other persistence device. The Event Saver gets messages from the DB Queue and saves or updates their contents in the database

[0040] In particular embodiments, a fact might be routed directly from the input queue to a rule executer, for real-time processing. Similarly, in particular embodiments, a fact might be routed directly from the schedule queue to a rule executer. for real-time processing. The rules engine allows for considerable flexibility with respect to real-time processing.

[0041 ] ϊt will be appreciated that the above components and processes allow considerable flexibility with respect to configuration Thus, in some embodiments, the components can be deployed in multiple machines, allowing for horizontal and vertical scalability. Further, the use of queues provides an easy way to configure where the rules engine's components might be deployed. Also, in some embodiments, the rules engine might compose various schemas for routing messages and load balancing according to various criteria which might be easily configured.

[0042] Additionally, it will be appreciated that the rules engine's use of queues enables the fully asynchronous processing desired for performance and scalability in enterprise applications.

Thus, each process can perform its task and route XML messages into the appropriate queues. without waiting for any subsequent process hi this regard, it will also be appreciated that the

Riles engine executes scheduled

at appropriate times, through the use of queues. That is. some X\1L messages aie only executed at specific times (or in real-time) Each of these messages is stored in its associated schedule queue until execution time

[0043] Similarly, in particular embodiments, the rules engine might use completely transacliona! processing That is to say. an XML. message retrieved from a queue by a rules engine component is committed on!) when the message^'s processing is o\er and the resulting XML messages are put into other queues Consequently, in the case of a crash, the rules engine does not perform the commit and the XML message remains in its original queue [0044] It will further be appreciated that each ruies engine component might be given a piocessmg power <e g , by running the component on specific

assigning the component a certain number of threads, etc ) to improve quality of service, in particular embodiments For example, a particular set of rules might retrieve XML messages out of a queue and be ghen a larger number of threads for their execution

10045 ] Likewise, in particular embodiments, the rules engine can handle peak processing times without the loss of XML messaaes bv storina a hiiih volume of XML messases in queues for later retriev al, routing, and execution, when processing resources are available And in particular embodiments, the rules engine might contain connectors allowing rules to request web services or the rules engine itself might provide such services

C Contract-F.xeeution Engine^'s Model

[0046] A particular embodiment of the rules engine is called the contract execution engine, which implements a contractual model in the following way A contract represents the legal agreement between participants (which might be businesses or peopled Each contract has multiple terms (or clauses) fcach term is fulfilled by a selector and a plan The selector corresponds to the "If conditional part of a rule and the plan corresponds to the "Then" action part of the rule In other words, a term is fulfilled b\ a rule

[0047] The participants are the entities participating in the contracts A participant can be of type merchant, processor, account prcnider, consumer, merchant acquirer, etc A participant can have the following status active or inactive Participants ma> have multiple relationships with other participants Λ relationship is between

participants A relationship can be of type account prov ider, rcfen ei, acquirer, etc

[0048] Λ contract has multiple participants Λ contract type can be revenue-share, dynamic rating, etc The contract type reflects the t\ pe of vertical application (e g , an application program for a v crtical or ni chc market \\ liich meets the needs of a particular industry ) being represented h> the contract The status can be active or inactive A contract can have multiple terms A term has its validity begin and end dates The term can be of type revenue share or fee, payables consolidation, or im oiring, for example Hs status can be

e. inactή e, or deleted

A term can have values associated with it The term values are values for the parameters of the template 01 selectoi formulae but that are defined at the terra level The term "pa) er^" or

"rceeiv cr ^' arc examples of term values A plan template can be considered as a predefined mathematical formula for calculating payables, consolidated payables, invoices etc

100401 Hach v ertical application built on top of the contract-execution engine provides a variety of plan templates that can be used to construct plans related to the particular vertical or niche market A plan can have the status active and inactive A plan defines the values for the alphanumeric parameters of its template formula A plan may have multiple plan-sets (e g . sets of values) and each plan-set can have multiple plan-set-values

plan-set-value is an attribute-value pair The selector is a logical expression or condition used for selecting the e\eπts, payables, etc , that a term plan must apply to The selector can have values in the same

alues

[0050] A schedule specifics when a contract term must be executed The schedule frequency can be real-time, daiSv . or monthly depending on whether the terra should be triggered as the event, payable, etc , ocαus in real-time or on a daily or monthly basis The schedule stait-timo specifies at which day and at time the schedule terms should start to run

[0051] Various contract terms are grouped into a term set The terms of a term set are executed under the same schedule Fach term set is associated to a terms selector and a schedule selector f he terms selector specifies the set of events. pa\ables. etc „ that trigger the term set The terms selector condition coiiespontls to the disjunction of the selector conditions of the terms of the terra set (e g , the union of the sets specified by each teim selector condition)

Foi example, consider Term Set TS₁ with Terms T₁, and Terms Selector Condition TSCi and each Term T_KI with Selector Condition SC, , Then TSC, ~ (SC₁ 1 or SC, 2 or SC, ,,)

[0052] The schedule selector specifies the events, payables, etc , which must be selected to trigger the term set each time the schedule fires The set specified b> the schedule selector is a sub-set of the set specified b\ the terms selector

[0053] In particular embodiments, the contract-execution engine predefines four term sets RTF. (Real-Time Events), PDE (Prior Day Events), PME (Prior Month Events), and PCE (Prior Cycle Events).

[0054] The attributes of Term Set RTE ( Real-Time Events) are as follows: (a) schedule frequency of real-time (this schedule terms run non-stop for real-time processing); (b) schedule start-time beginning at installation time, (c) terms selector that selects all events, payabies, and consolidated payabies that must be processed in real-time; and (d) schedule selector that selects all events, payabies, and consolidated payabies that were selected by terms selector. 100551 ^'The attributes of Term Set PDF. < Prior Day Events) are as follows (a) schedule frequency of daily; (b) schedule start-time that usually is a delay time after midnight for coping with delayed events of the prior day; (c) terms selector that selects all events, payabies, etc., that must be processed by this terra set; and (d) schedule selector that selects all events, payabies, etc , that were selected by the terms selector and such that the causing event occurred on the prior day.

[0056] The attributes of Term Set PME (Prior Month Events) are as follows, (a) schedule frequency of monthly, (b) schedule start-time that usually is a delay time after midnight for coping with delayed events of the prior day (c) terms selector that selects all events, payabies, etc that must be processed by this term set; and (d) schedule selector that selects all events, payabies, etc , that were selected by the terms selector and such that the causing event occurred on the prior month.

[0057] The attributes of Terra Set PCE (Prior Cycle Events) are as follows: (a) schedule frequency of daily; Cb) schedule start-time usually is a delay time after midnight for coping with delayed events of the prior day: fc) terms selector that selects all events, payabies, etc., that must be processed by this term set; and (d) schedule selector that selects all events, payabies ,etc. that were selected by the terms selector and such that the causing event cycle date was the prior day. [0058] The event is a generic entity representing input or external events to the system The type of an event can be purchase, rating, etc. Its status can be loaded, processed., or missed. An event is defined by a set of attribute-value pairs The selection and selection-value entities represent such attribute- value pairs.

[0059] The trail is used for audit purposes. It links events and other concepts caused by the events such as payabies etc. The trail status can be shared, reversed, etc [0060] To summarize, each contract in a particular embodiment of the contract-execution engine can have multiple terms. Each term is represented by a selector and a plan. The selector specifies which events, payabies, etc, will trigger the plan The execution of a plan generates new concepts (payabies, consolidated payabies, etc.) that can eventually trigger new contract terms. Each terra set can be executed either in real-time as the events occur or based on a time schedule, e.g., they might be executed on a daily or monthly basis. The term set also defines which events or other concepts are selected for triggering the terms of the term set at the scheduled time.

D. Contract-Execution Engine^'s Components and Processes

[0061 ] Figure 5 is a diagram showing the components of a contract-execution engine, which might be used in some embodiments of the present invention. To some extent, the contract- execution engine's components shown in Figure S overlap the rules engine components shown in Figure 3, though the latter engine is more generalized. However, as shown in Figure 5, the contract-execution engine has more types of queues: (a) General Queues including the Input Queue, the DB Queue, and the Missed Events Queue; (b) Term Set Queues including the RTE (Real-Time Events) Queue, the PDE (Prior Day Events) Queue, the PME (Prior Month Events) Queue, and the FCE (Prior Cycle Events) Queue; (c) Term Queues including one queue per contract term and possibly an extra under-processing queue for each contract term that requires temporary intermediary calculations These terms are called ''Cumulative" Terms, in some embodiments.

[0062] As just described, the contract-execution engine has a queue-centered architecture in which the events, payabies, and other data are carried by (or represented within) "messages" that go from queue to queue and get processed by the "components". Figure 6 is a diagram showing a flowchart of a process which a contract-execution engine might use to process a message, in some embodiments of the present invention. In the first step of the process 601 , an external event enters the contract-execution engine, possibly from a vertical application, and is put in the Input Queue, in the next step 602, the event is routed by the engine into a Term Set Queue, where each term set is related to a schedule In turn, the schedule determines whether the event will he consumed in real-time, dail\ . or monthly Recall from Figure 5 that there are four pre-defined Term Set Queues (one per pre-defined Term Set) namely RTE (Real-Time Iλ ents), PDH (Prior Da> [--vents.). PMi: (Prior Month [--vents), and PCl; (Prior Cycle i-vents) Queues

[0063] In step (>(B of the piocess show n in iϊguie 6, the contt act-execution engine routes the events to a Term Queue which corresponds to a term in the contract (c g . each term has a corresponding Term Queue) in step WH the term plan executes the event in the respective Term Queue Then in step 605, the contract-execution engine routes the payah^'es and other results from the term plan execution back to the Input Queue and the process continues [0064] In a particular embodiment, messages earn- tiie data representing the e\ents. payables, and other concepts that are processed within the contract-execution engine The messages are picked up from a queue 1\\ a component The component processes the messages and/or mutes the messages to other queues The content of a message represents the latest concept processed within the contract-execution engine During a typical life c) cle (for example, in the context of a revenue sharing application), a message has the following sequence of contents e\ent, ρa\ able, consolidate pay able, and invoice

[0Ot)S] In a particular embodiment, a message status can be (a) for-processing (eligible for processing), (b) undet -processing {dining intermediary calculations), (c) processed, Cd) missed, or (e) tor-client "hor-processing" means that the message will get picked up and processed by a term If the minimal processing does not occur, the message gets the status "missed" "Processed"^" means that the contents of the message will be saved "For-ciient" means that the message wilt be returned to the client Figure 7 shows the life c>c!e of a message as it moves through the queues of the contract-execution engine, from "for-processing" to "missed" or ^■'processed^*'

[QOoόj ""Under-processing" means that the message is holding intermediary results The cumulative term executes" takes as input a message "for- processing^'*, as well as an "under- piocessing^" message As soon as the processing is ftnali/od (c g , there are no more ^vibr- piocessing" messages available in the Term Queue), the term executer takes the "υndei- processing^" message and transforms it into a "for-processing^". "processed", or "for-client message^" [0067] Consolidation is an example of a process that requires the accumulation of results and is implemented in the contract-execution engine using ''under-processing" messages The "under- processing message^'1 holds intermediate iesults and guarantees the transaction iϊguie 8 is a diagram showing the flow of an "under-processing" message in the contract-execution engine. w hich flow might be used in some embodiments of the present invention [0068] Figure 9 is a diagram showing a flowchart of a process which might be used b\ a term set router in a con tract-cv edition engine, in some embodiments of the present invention In the first step of the process 001, the term set router creates a loop for processing messages, with status 'Tor-Processing'^", in the Input Queue In the next step 902, the term set router removes a message from the Input Queue and then determines, in step 903. whether the message represents a past-period event Such an event is an event whose event date equals a prior date and whose current time is greater than any delaj for the event If the message does represent a past-period event the term set router goes to step 904 and sets the message status to "missed^", sends the message to the Missed F.\eπts Queue, and sends the message to the DB Queue (this message now has status "missed") From step ^c>04, the term set router goes to step 906 where all queue operations are rolled back, if an exception has occurred

[0069]

e\em\ the term set router goes to step 905. whore (1 ) it loops over each Term Set (RTE, PDE, PME, and PCC) and, if the terms selector evaluation of the message is true, sends the message to the corresponding Term Set Queue, (2) sends the message to the DB Queue (the messages still has status "for- processing"), and (3) if no terms selector has evaluated to tree, then set the message status to "missed" and send the message to the Missed Events Queue and send the message to the DB Queue (the message now has status "missed") From step 905, the term set router also goes to step 90(>. described above Then in step 007, the term set router commits to all queue operations This step is the last step in the loop created in step ^01

[0070] As suggested by Figure °, the term set router runs non-stop There can be multiple threads running term set routers in parallel As long as there arc messages in the Input Queue, the term set routers will process ihe messages

[0071] Figure 10 is a diagram showing a flowchart of a process which might be used by a terms router in a contract-execution engine, in some embodiments of the present im ention There is one terms router per terra set, e g., an RTF., PDE, PME and PCE Terms Router. In step 1001 of the process, the terms router starts on a control message from the corresponding Schedule {except for the RTE Terms Router, which runs non-stop). In step H)02, the terms router loops over each active term in the corresponding term set and sends a start message to the term queue. Here, an "active terra^" is a term that has active status and validity period verified In step 1003, the terms router creates a loop that runs until the term set queue selection is empty, according to the schedule selector. In this loop, the terms router begins by removing a message from the corresponding term set queue (the message still has a status of "for-processing^") according to the schedule selector Then in step 1004, the terms router loops over each active term in the corresponding term set and, if the term selector evaluation is true, sends the message to the corresponding term queue. If no terms selector has evaluated to true, then in step 1005, the terms router sets the message status to "missed^" and sends the message to the Missed Events Queue and to the DB Queue (the message now has status "missed") In step 1006, the terms router roils back at! queue operations, if there has been an exception. In step 1007, the terms router commits to all queue operations. Step 1008 is the last step in the loop created in step 1003 and once this loop is finished the terms router stops

[0072] The terms routers run according to their correspondent term set schedule The RTE Terms Router runs non-stop, as noted above. The Period Terms Routers (PDE, PME, and PCE) are started at the end of the "current period", which is daily, monthly, and daily respectively. The Period Terms Routers send a start control message to the Term Queue of all active terms of their correspondent term set as soon as they get started The Period Terms Routers route the messages that are specified by the schedule selector of their correspondent term set. There can be multiple threads running each terms router in parallel. As long as there are messages in the corresponding Term Set Queue (messages that have been specified by their term set schedule selector), the terms routers will process and route them to the term queues. The term set queues and terms routers improve the overall system performance since each message is tested against the selectors of terms that correspond to the particular term set as opposed to being matched against all terms

[0073] There is one term execυter per term queue. Figure 11 is a diagram showing a flowchart of a process which might be used by the Term Executer for Cumulative Terms in a contract- execution engine, in some embodiments of the present indention In the first step of the process

1101 , the terra executor starts on a control message from corresponding Terras Rooter In step

1 102, the term executof creates a loop for processing messages in the Term Queue (messages still have status "For-Processing^") The loop ends when the Term Queue is empty In step 1 103 the term execute? remoses a message from the corresponding queue and, in step 1 104, determines whether an "under-processing" message is

If not, the term executor goes to step 1 105 and sets' the message status to "under-processing" and sends the message to the Under-Processing Queue From step 1 105, the term executor goes to step 1 107, where all queue operations are rolled back if an exception occurs

[0074] However, if an "under-processing^" message is available at step i 104, the term executor goes to step i 106 and updates the "under- processing" message with data from the message and sends the "'undei -processing^"1 message to the I ^'nder-Processing Queue hom step 1 106, the term executor also goes to step 1107, described above F hen in step 1 108, the term executor commits to at! queue operations This loop cieated in step 1 102 ends in step 1 109 [0075] Once the loop has ended, the term executor goes to step 1 1 K* and gets an "under- processing^"' message and sets the message's status to either "processed'^". "ibr-ρrocessϊng"\ or "for-client" Then also in this step, the term executor sends the message to the appropriate T ecipiont, e g , the DB Queue for a "processed" message, the Input Queue for a 'ibr-pfocessing'^" message, and the client for a "for-client^" message Then the term executor stops [0076] In some embodiments, there can be multiple threads running the term cxccuter for a particular term The term executers belonging to the RTF, Term Set run non-stop The teπn executers belonging to Period Term Sets are triggered by a start message sent by the corresponding teπn set router They run until the corresponding term queue is empty [0077] In particular embodiments, the contract-execution engine caches all contract, participants, and plan data in memory and consists of a queue-based structure with one queue per contract term In some cases, the number of contracts, participants, and plans might pre\ent full caching in memory or the number of contract terms might be to numerous to allocate one queue per contract term

[007H] figure 12 is a diagram showing the flow of conditional caching in a contract-execution engine, which flow might be used in some embodiments of the present invention, to alleviate

I S caching problems As shown in the diagram, the contract-execution engine first determines whether there is a prohibitive number of contracts If the number of contracts is not prohibitive, contracts are cached and queues are allocated one queue per term But if the number of contiacts is prohibitive, the contract-execution engine next determines whether the number of plans is piohϊbitn e If the number of plans is not piobibitn e, contracts are fetched, plans are cached, and queues are allocated one queue per plan But if the number of plans is prohibitive, contracts and plans are fetched and queues are allocated one queue per plan template |0070| Also in particular embodiments, the current terms router matches each message against all of the term selectors of the particular term-set, which can adversely affect the performance of the contract-execution engine Fo improve performance, some rales engines (e g , OPS-5) create a graph mapping predicates (e g , types of the message data) to the rules that can be affected (e g , that could be fired) by such predicates For each new fact (e g , message) generated, the rule engine can retrieve the potential rules by mapping the predicates of the fact using the graph There are major advantages and drawbacks with such an approach Λrnoπg the advantages arc the fact that the algorithm is \erv fast and that it is generic insofar as there are no assumptions about the type or semantics of the data (i e , it works for whatever set of rules, regardless of their meaning) Among the drawbacks are the complexity of the algorithm as implemented and the potentially large size of the graph itself

[0080] 1 he contract-execution engine uses a different approach in this regard, it will be appreciated that in the contract-execution engine each message carries information about all of us related participants and that the only contract terms that appl) to such a message are the terms of the contracts among such message participants Therefore, the contract-execution engine might extract the participants from the message and then retrieve the terms of the contracts of such participants

[0OS I ] \1oτe specifically, in particular embodiments, the terms router extracts the participants from the message and for each participant retrie\es their contracts from the database and caches them in memory (if they are not already in mernoη, ) Since each participant knows about all the contracts that it participates in, it is straightforward to retrieve such contracts The terms router then checks each contract term that belongs to the corresponding term-set When a match occurs, it records the term plan in the message and sends it to the corresponding plan template

| 0 queue

[0082] Figore 13 is a diagram showing a flowchart of a process which might be used by an optimized terms router in a contract-execution engine, in some embodiments of the present invention. There is one optimized terms router per term set e.g., an RTE, PDE, PM£ and PCE Optimized Terms Router. In step 1301 of the process, the optimized terms router starts on a control message from the corresponding schedule (except for the R TE Terras Router, which runs non-stop) In step 1302, the optimized terms router loops over each plan template of an active terra in the corresponding term set and sends a start message to the Plan Template Queue. Here again, an "active term" is a term that has active status and verified validity period, In step 1303, the optimized terms router creates a loop that runs until the Term Set Queue selection is empty, according to the schedule selector. In this loop, the optimized terms router begins by removing a message from the corresponding Term Set Queue (the message still has a status of "for-processing'~} according to the schedule selector. Then in step 1304, the optimized terms router retrieves the participants from the message. Jn step S 305, the optimized terms router loops over each event participant that is not already cached in memory and retrieves the event participant from the database and caches the event participant in memory. In step 1306, the optimized terms router loops over each contract of each event participant which contract is not already cached in memory and retrieves the contract from the database and caches the contract in memory. Then in step 1307, the optimized terras router loops over each active term of each contract of each event participant of the corresponding terra set and, if the term selector evaluation is true, sends the message to the corresponding plan template queue, if no terms selector has evaluated to true, then in step 1308. the optimized terms router sets the message status to "missed" and sends the message to the Missed Events Queue and to the DB Queue (the message now has status "missed") In step 130^Q ₅ the optimized terms router rolls hack all queue operations, if there has been an exception Irs step 13 10, the optimized terms router commits to all queue operations. Step 131 1 is the last step in the loop created in step 1303 and once this ioop is finished the optimized terms router stops.

[0083] In particular embodiments, there is one optimized term executer per plan template queue. Figure 14 is a diagram showing a flowchart of a process which might be used by an optimized Term Executer for Cumulative Terms in a contract-execution engine, in some embodiments of the present invention Generally in this process, the optimized term executor checks if the plan recorded in the message is already cached in memory If not. the optimized term executor retrieve:_* the pSan-set-vaiues from the database and caches the plan in memory [0084] More specifically, in the first step of the process 1401. the optimized term executor starts on a control message from corresponding Terms Router In step 1402, the optimized teim executor creates a loop for processing messages in the Plan Template Queue (the messages will still "For-Processing" status) The loop ends when the Plan Template Queue is empty in step 1403, the optimized term executor

a message from the corresponding plan template queue Then in step 1404, the optimized term executor determines whether the plan of the message is already cached in memory and. if not, retrie\es the plan set- values of the plan from the database and caches the plan in memory In step 1405, the optimized term executor determines whether an "under-processing^" message is available ϊf not, the optimized teim executor goes to step 1406 and sets the message status to "under-processing^" and sends the message to the Under-Processing Queue From step 1406, the optimized term executor goes to step 1408. u here all queue operations are rolled back if an exception occurs [0085] However, if an "under-processing" message is available at step 1404, the optimized term executor goes to step 1407 and updates the "^"tinder-processing" message with data from the message Cc g , executes the plan of the message) and sends the "under-processing" message to the Under-Processing Queue From step 1407, the optimized term executor also goes to step 1408, described above Then in step 1409, the optimized term executor commits to all queue operations This loop created in step 1402 ends in step 1410

[0086] Once the loop has ended, the optimized term executor goes to step Mi l and gets an "under-processing" message and sets the message^'s status to either "processed^", "foi- pioeessing^", or "for-cUenf Then also in this step, the optimized term executor sends the message to the appropriate recipient, e g , the DB Queue for a "processed" message, the Input Queue for a "for-processing^" message, and the client for a "for-clienf message Then the optimized term executor stops

[0087] In particular embodiments, the mechanism for caching each entity (contract, participants, and plans) in memory is similar to a typical EJB (Enterprise JavaBeaii) Entitv Beans mechanism There is a configurable memoiv size or number of entities available for storing each type of en tit j The entities are stored until the limit is reached After that each entity is stored to the expense of another entity being removed from memory The choice for which entity to remove may be based on quality of service associated to the emit) . time, etc [0088] Figure 15 is a diagram showing a flowchart of a process which might be used for caching a new entity such as a contract, participant or plan in a contract-execution engine, in some embodiments of the present i mention In step i 501. the contract-execution engine determines whether the number of entities currently cached is less; than the maximum number If so, the contract-execution engine goes to step 1502 where it caches the new entity and increments the number of entities Otherwise, the contract-execution engine goes to step 1503, where it (a) assigns to a swap-entity- the current entity with the lowest quality of service, (b) removes the s\\ ap-entity , and (c) then caches the new entity

[0089] It will be appreciated that an additional optimization is to have the messages associated to specific participants routed to specific servers which are devoted to executing the contracts of such participants

[0090] Figures 16. 17, ! 8, 19, 20, 21, and 22 show a use case, which might be used with the contract-execution engine, in some embodiments of the present invention Figure 16 shows the term set terras, schedule selectors, and terra selectors for the use case, which involves a merchant called AOL Figure !7 shows flows 1, 2, 3, and 4 in the initial event message path in the use case Hgυre 18 shows flow 5 in the use case, namely, pa\ able message creation by the I erm 1 Executcr and the message's path back to the Input Queue Figure 19 shows flows 6, 7, and 8 in ihe use case name!) , the payable message path to both the PDF, and PCF queues f igure 20 shows flows 7 and 9 in the use case, namely, schedule selection of ρa>able messages 1 , 2. and 3 on July 5^lh by the PDR Terms Router Figure 2! shows How 10 of the use case, namely, a consolidated payables (under-processing) message being created by the Term 2 Exccuter, after processing message I Figure 22 shows flows 11, 12, and 13 of the use case, namely the consolidated payables (under-processing) message being updated or transformed by the Term 2 Executor after processing message 2

[0091 ] In particular embodiments, the following components are automatically installed at startup time for contract-execution engine the general queues (e g , Input Queue, DB Queue, Missed pΛ ents Queue), the term set queues (e g , RTC Queue. PDH Queue, P\!F, Queue, PCE Queue), the Term Set Router, the Bvent Updater, the terms routers (e g , RI F Femis Roister, PDF Terms Router. PME Terms Router, PCE Terms Router), the plan templates, and the selector templates [0092] Also in particular embodiments, the contract-execution engine usei provisions participants, plans, and contracts before the engine can start receiving and processing events related to such entities Further, the usei can continuous!) piovision these entities ovei time fcvcnrs that enter the s\ stem before the provision of their related participants, plans, or contracts do not get processed and are considered "missed events" During the provisioning process, the entities being entered (or modified) are first \ alidated, persisted into the database, and then a set of elements are installed (or modified) into the sv, stem

[0093] in particular embodiments, the following elements are installed at provisioning time as new entities are created (a) one term queue per contract term, (b) possibly an extra under- processing queue per contract term foτ the Cumulative Term Plan Template (a consolidation plan template might have an extra queue for persisting the message that holds intermedial} calculations), (c) one term executor per contract term. Cd) participants, (e) plans, (f) contracts and their terms

[0094] Figure 23 is a diagram showing a flowchart of a process which might be used when adding an entity to a con tract -execution engine, in some embodiments of the present imention In the process^'s first step 2301. an entity, such as a contract term, enters the contract-execution engine, e g , from a vertical application In the next step 2302, the contract-execution engine determines whether the entitv can be validated If not the contract-execution engine goes to step 2303 and ietums a validation erroi Otherwise, the contract-execution engine goes to step 2304 and saves the entitv- into the engine^'s database, using the transactional processing described above In step 2305, the contract-execution engine determines w nether an exception has occurred If so, the contract-execution engine goes to step 2306 and rolls hack the "Save Bntity" operation performed in step 2304 Oth ci wise, the contract-execution engine goes to step 2307 and installs the entity in memory

[0095] In particular embodiments of the invention, one can reboot the contract-execution engine (for example after a crash), by re-installing the following elements the Term Set Router, the fcvent Saver, the RTE Terms Router, the PDfc Terms Router, the PJMb Terms Router, the PCE Tαms Router, the term executers, the plan templates, the selectors, the participants, the plans, and the contracts and their terms.

[00%] Particular embodiments of the above-described processes might be comprised of instructions that are stored on storage media. The instructions might be retrieved and executed by a processing system. The instructions are operational when executed by the processing system to direct the processing system to operate in accord with the present invention Some examples of instructions are software, program code, firmware, and microcode. Some examples of storage media are memory devices, tape, disks, integrated circuits, and servers The term "processing system" refers to a single processing device or a group of inter-operational processing devices. Some examples of processing devices are integrated circuits and logic circuitry Those skilled in the art are familiar with instructions, storage media, and processing systems

[(XWj Those skilled in the art will appreciate variations of the above-described embodiments that fall within the scope of the invention. In this regard, it will be appreciated that there are many possible orderiπgs of the steps in the processes described above and many possible allocations of those steps between the nodes in a cluster. As a result, the invention is not limited to the specific examples and illustrations discussed above, but only by the following claims and their equivalents.

Claims

What is claimed is;

1. A method, comprising: receiving a fact in an inference engine and storing the fact in an input queue; retrieving the fact from the input queue and routing the fact to one of one or more schedule queues on the basis of a processing schedule for the fact and a condition, wherein the condition is associated with the schedule queue and is part of a rule; retrieving the fact from the schedule queue in accordance with the processing schedule for the fact and routing the fact to a queue associated with a rule executer, wherein the routing is based on the contents of the fact; applying, at the rule execυter, an action to the fact, wherein the action is also part of the rule and wherein the action transforms the fact or creates new facts from the fact, routing the transformed fact or new facts to the input queue; and routing the fact to a device for persistent storage,

2. The method of claim L wherein the fact is routed directly from the input queue to a rule executer, for real time processing.

3. The method of claim 1, wherein the fact is routed directly from the schedule queue to a aile executer, for real time processing.

4. The method of claim 1, wherein the schedule queues comprise one or more of a real-time queue, a daily queue, a weekly queue, and a monthly queue.

5 The method of claim 1. wherein the fact is an XML message

6. The method of claim 1 , wherein the queues employ the Java Message Service.

7. The method of claim 1, wherein the device for persistent storage is a database

8. A method, comprising; receiving an event in a.n inference engine and storing the event in an input queue; retrieving the event from the input queue and routing the event to one of one or more term set queues on the basis of a processing schedule for the event, wherein each term in a contact is associated with a term set queue; retrieving the event from the term set queue in accordance with a processing schedule for the event and routing the event to a term queue on the basts of the contents of the event; retrieving the event from the term queue and executing the event in accordance with a plan, wherein the terras of the contract are based on the plan and the plan transforms the event or creates new events from the event; routing the transformed event or new event to the input queue; and routing the fact to a device for persistent storage.

9. The method of claim 8, wherein the routing to a term queue further depends on the participants to the contract.

10. The method of claim 8, wherein data regarding the participants in a contract for an event and the terms of a contract for an event are obtained from a database and cached in memory after retrieving the event from the term set queue when memory is unavailable due to load

1 i The method of claim 8, wherein the term set queues comprise one or more of a real-time queue, a daily queue, a monthly queue, and a cycle queue,

12 The method of claim 8. wherein the event is an XML, message

13. The method of claim 8, wherein the queues employ the Java Message Service. 14 An apparatus, comprising logic encoded in one or more computer-readable media for execution and when executed operable to receή e a fact in an infeience engine and store the fact in an input queue, retrieve the fact from the input queue and route the fact to one of one or more schedule queues on the basis of the piocessmg schedule for a fact and a condition, wherein the condition is associated with the schedule queue and is part of a rule- retrieve the fact from the schedule queue in accordance with the processing schedule for the fact and route the fact to a queue associated with a mie executer on the basis of the contents of a fact, apply, at the rule executes an action to the fact, wherein the action is also part of the rale and wherein the action transforms the fact or creates new facts from the fact, route the transformed fact oτ new facts to the input queue, and route the fact to a device for persistent storage

15 The apparatus of claim 14, wherein the fact is routed directlv from the input queue to a rule ex center, for real time processing

16 The apparatus of claim 14, whetein the fact is routed directly from the schedule queue to a rule executes for real time processing

17 The apparatus of claim 14 wherein the schedule queues comprise one or more of a real-time queue, a dail\ queue, a weeki\ queue, and a rnonthh queue

18 The apparatus of claim 14, wherein the fact is an XMI message

1¹> The apparatus of claim 14, wherein the queues employ the Java Message Service

20 The apparatus of claim 14, wheiein the device for persistent storage is a database

2 ! Λπ apparatus, comprising logic encoded in one or moie computer-ieadable media for execution and when executed operable to. receive an event in an inference engine and store the event in an input queue; retrieve the event from the input queue and route the event to one of one or more term set queues ori the basis of the processing schedule for an event, wherein each terai in a contact is associated with a terra set queue, retrieve the event from the term set queue in accordance with the processing schedule for an event and route the event to a term queue on the basis of the contents of an event; retrieve the event from the term queue and execute the event in accordance with a plan, wherein the terms of the contract are based on the plan and the plan transforms the event or creates new events from the event; route the transformed event or new event to the input queue: and route the fact to a device for persistent storage

22 The apparatus of claim 21, wherein the routing to a term queue further depends on the participants to the contract.

23 The apparatus of claim 21. wherein data regarding the participants in an event's contract and the terms of the contract for an event are obtained from a database and cached in memory after retrieving the event from the term set queue when memory is unavailable due to load.

24 The apparatus of claim 21. wherein the term set queues comprise one or more of a real-time queue, a daily queue, a monthly queue, and a cycle queue.

25 The apparatus of claim 2 U wherein the event is an XML message.

26. The apparatus of claim 2 L wherein the queues employ the Java Message Service.