WO2003044683A1 - Processing and distributing data according to specified rules - Google Patents

Abstract

An engine supports communications among source and destination computer systems. The source systems generate source events. A source event describes a change in a condition of data in a repository at a source system or serves as a notification of data from the source system. The engine includes connection managers receiving source events (510) from the source systems. The engine also includes a database storing rules describing pre-effects and effects processing (512) to performing response to the source event, the connection manager retrieves any associated rules (514) from the database and stores the source event, the connection retrieves any associated rules from the database and stores the source event and rules in a queue (516). A queue manager reads, applies pre-effect processing to the data from the source event to generate a destination event, and applies the effect processing to deliver the destination event data to the appropriate destination systems (522).

Description

PROCESSING AND DISTRIBUTING DATA ACCORDING TO SPECIFIED RULES

INVENTORS JAY BORENSTEIN DANIEL HARSELL

TlNO WUENSCHE THADDEUS JAMPOL

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of U.S. Provisional Application No. 60/331,933, filed November 20, 2001, and hereby incorporated by reference herein.

BACKGROUND OF THE INVENTION FIELD OF THE INVENTION

[0002] This invention pertains in general to data communications and processing and in particular to controlling the gathering, processing, and delivering of data from source systems to a broad range of destination systems.

BACKGROUND ART

[0003] Modern organizations, such as companies and government agencies, often work with separate computer systems that cannot effectively communicate to and from one another. Each computer system stores and provides access to different sets of data. For example, an organization may store customer relationship and management (CRM) information on a first computer system, word processing documents on a second computer system, and accounting data on a third computer system. In addition, two or more computer systems may store the same data, albeit in different formats.

[0004] Commonly, users within these organizations interact with the various sets of data in the computer systems in different ways. For example, users may access one set of data through custom software applications, access another set of data via email or web browsers, and access a third set of data through direct database queries.

[0005] Since each computer system maintains different sets of data and possibly supports different access methods, organizations find it difficult to effectively communicate and coordinate data among the systems. For example, a customer's address may be stored with the customer's billing records and in the CRM system. The organization will typically want an address change made in either system to automatically change the other system, but will find this task difficult to automate due to the differences between the systems.

[0006] Organizations have tried several solutions to ease data sharing among different computer systems. Perhaps the simplest approach is for human users to manually update the separate systems by redundantly entering information to reflect new or changed data. This solution is inefficient and error-prone, although it is often the most practical in terms of cost and capability. Another solution is for the organization to move all data to a single enterprise resource planning (ERP) system. This ERP solution ensures that all of the enterprise's computer systems can share data, but is costly, time consuming, and severely limits the flexibility of the organization to choose its own tools.

[0007] A third solution to sharing data is adding an additional application layer as a "broker" of information between the various computer systems. Programmers design application programs executing on the computer systems to interact with the broker rather than the different computer systems when sharing data. Thus, the broker creates an avenue for accessing and sharing information among different systems. However, to make changes or add functionality, the organizations are forced to modify or rewrite the application programs. Performing this task is often time consuming and prohibitively expensive.

[0008] Therefore, there is a need in the art for a way to efficiently share data among different computer systems.

BRIEF SUMMARY OF THE INVENTION [0009] The above need is met by a communication facilitating engine that provides communication and data processing capabilities in order to support data sharing, yet does not require any substantial modifications to the systems generating and/or receiving the data. The engine operates in a computing environment having one or more source systems and one or more destination systems.

[0010] The source systems generate source events. One type of source event describes a change in a condition of data in a repository at a source system. Another type of source event serves as an acquisition of data from the source system. In one embodiment, the source system includes database triggers, a database table, and an agent module that monitors the database for changes to data. The agent communicates a source event to the engine for subsequent processing by using the extensible markup language (XML) to describe the changed data. In another embodiment, the engine includes a polling client for polling the source system to identify changes to data and generate the source events in response thereto.

[0011] A user preferably uses a graphical user interface (GUI) provided by a user console to describe rules for processing the source events. Rules are comprised of instructions for gathering data, processing data, and disseminating data. The gathering aspect of the rules specifies where and in what circumstances source events are gathered in order to initiate a communication process. The processing aspect of the rules can perform a wide variety of operations on the data in the source event, and includes a facility for applying pre-effect and effect processing on the data to dynamically generate one or more types of destination events. Types of processing operations supported by one embodiment of the present invention include conditional logic, data incorporation, data transformation, and user-defined functions. The dissemination aspect of the rules specifies where, in what format, and in what circumstances information is to be communicated to one or more destination systems. Possible delivery actions include, but are not limited to, a database operation, an email, and an XML broadcast. [0012] A database in the engine stores the rules. The engine also includes a connection manager for receiving the source events from the source systems. Upon receiving an XML packet created and communicated in response to a source event, the connection manager retrieves the rules pertaining to the source event from the database and takes actions specified in the rules to generate an intermediate data representation from the source event data. [0013] The engine preferably has multiple queues corresponding to the types of effects being processed and/or the locations of the destination systems. The connection engine identifies the queue or queues corresponding to the effect processing specified by the rules associated with the source event and generates the intermediate data representation accordingly. Each queue preferably has an associated queue manager that reads the data from the queue and performs the specified processing, thereby generating any number of destination events and delivering data representative of the destination events to the destination system(s).

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] FIG. 1 is a high-level block diagram illustrating a typical computing environment according to an embodiment of the present invention;

[0015] FIG. 2 is a high-level block diagram illustrating a more detailed view of the interaction between the source systems and the engine in the computing environment;

[0016] FIG. 3 is a high-level block diagram illustrating a more detailed view of the engine in relation to the other entities illustrated in FIG. 1 ;

[0017] FIG. 4 is a block diagram graphically illustrating the rule-based processing performed by the modules of the engine illustrated in FIG. 3;

[0018] FIG. 5 is a flowchart illustrating the steps performed by the engine to facilitate communications according to a preferred embodiment of the present invention;

[0019] FIG. 6 is a flowchart illustrating the steps performed by a user to establish a rule for the engine;

[0020] FIG. 7 illustrates a graphical user interface (GUI) for enabling the user to select a source system and specify the source event for a rule;

[0021] FIG. 8 illustrates a GUI for enabling the user to specify the action type of an effect;

[0022] FIG. 9 illustrates a GUI for enabling the user to specify what information should be communicated from the source system to the destination system, and what processing should be performed on that information as part of the communication;

[0023] FIG. 10 illustrates a GUI for enabling the user to specify pre-effect processing for the specified rules;

[0024] FIG. 11 illustrates a GUI for specifying a form of pre-effect processing where a Boolean pre-effect assertion is evaluated before processing specified rules; and [0025] FIG. 12 illustrates a GUI for specifying another form of pre-effect processing where information is solicited from another source before processing specified rules.

[0026] The figures depict an embodiment of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein.

DETAILED DESCRIPTION OF THE INVENTION

[0027] In the figures, like elements are identified with like reference numerals. A letter after the reference numeral, such as "112A," indicates that the text refers specifically to the element having that particular reference numeral. A reference numeral in the text without a following letter, such as "112," refers to any or all of the elements in the figures bearing that reference number (e.g. "112" in the text refers to reference numerals "112A" and/or "112B" in the figures).

[0028] FIG. 1 is a high-level block diagram illustrating a typical computing environment 100 according to an embodiment of the present invention. FIG. 1 illustrates a communication facilitating engine (the "engine") 110 in communication with four data source computer systems 112 (hereinafter referred to as "source systems") via communications links 114. The engine 110 is also in communication with two data destination systems 116 ("destination systems") via communications links 118. In FIG. 1 , four source 112 and two destination 116 systems are shown. However, it should be understood that the engine 110 may be in communication with any practical number of such systems. For purposes of convenience and clarity, this description frequently refers to a single source 112 and/or destination 116 system. These single systems 112, 116 are merely representative of the one or more systems in communication with the engine 110. The engine 110 is also in communication with a user console 120 via another communications link 122. This user console 120 is representative of the one or more user consoles that maybe in communication with the engine 110.

[0029] The environment 100 of FIG. 1 is representative of a typical computing environment at an organization such as a company or a government agency. The environment has multiple disparate computer systems and multiple computer users. Many of the computer systems and data representations utilized by the computer systems are different because the computer systems were purchased at different times, from different vendors, etc. Nevertheless, the organization has a desire to enable the computer systems to communicate information to and from one another in order to improve data accuracy and business efficiency, and to reduce risks, costs, etc.

[0030] The source systems 112 are sources from which the engine 110 receives and/or can obtain data. In a preferred embodiment, the source systems 112 are conventional computer systems adapted to act as data sources and/or repositories. The computer systems maybe, for example, personal computer systems, server systems, and/or mainframe systems. However, one or more of the source systems 112 can be a device lacking typical computer functionality. For example, an electronic thermometer or other type of sensor can act as a source system.

[0031] There are many ways in which the source system 112 can act as data source and or repository. The source system 112 can execute a relational database such as Oracle9i from Oracle Corp, execute application programs that maintain data in one or more proprietary formats, execute a mainframe database, and or hold data in a flat-file. The source system 112 can also be a computer system having an interface through which data on the system can be accessed. Such interfaces include those allowing access via the hypertext transport protocol (HTTP), the file transfer protocol (FTP), the post office protocol (POP), and a command shell.

[0032] The destination systems 116 are adapted to receive data. The destination systems 116 may store the received data, act on the received data, and/or ignore the data. In one embodiment, a destination system 116 is a conventional computer system similar to a source system 112 and can execute a relational database, proprietary application, mainframe database, hold a flat data file, etc. In another embodiment, a destination system 116 is a device lacking all or some functionality typically associated with a computer system, such as a cellular telephone, a pager, a fax machine, or another device adapted to receive data.

[0033] In many cases, there are no physical distinctions between the source 112 and destination systems 116. A system can function as both a source and a destination in the same environment 100, with the only distinction being the direction of the data flow in a particular transaction. Indeed, it is expected that many of the systems will simultaneously function as both sources and destinations. Moreover, multiple source 112 and/or destination systems 116 can reside on a single computer system. For example, if multiple databases reside on a single computer system, each database can be treated as a distinct source system 112. Likewise, a single database that spans multiple computer systems can be treated as a single source system 112.

[0034] The communications links 114, 118 coupling the source 112 and destination 116 systems to the engine 110 are preferably conventional communications links. The links 114, 118 may include private links, such as dedicated Tl lines, local or wide area networks, and/or serial connections. The links 114, 118 also may include public links, such as public telephone lines, television distribution systems, or shared Internet connections. The links 114, 118 may utilize conventional communications technologies such as analog modems, digital subscriber line modems, cable modems, Ethernet, etc.

[0035] In one embodiment, data are transmitted over the communications links 114, 118 via conventional communications protocols such as the HTTP, the FTP, and the transmission control protocol Internet protocol (TCP/IP). The data maybe encoded in the extensible markup language (XML), hypertext markup language (HTML), or any other suitable representation. These transmissions can be encrypted using the secure sockets layer (SSL) or other convention encryption technologies.

[0036] The engine 110 is preferably a conventional computer system adapted to execute computer program modules providing communication facilitating functionality. As used herein, the term "module" refers to computer program logic and/or any hardware or circuitry utilized to provide the functionality attributed to the module. Thus, a module can be implemented in hardware, firmware, and/or software. In one embodiment, the engine computer system executes the Linux operating system. In another embodiment, the engine computer system executes one of the WINDOWS operating systems from MICROSOFT CORPORATION.

[0037] The engine 110 interacts with the source systems 112 to detect source events and receive data describing the source events. A source event is an event that affects data stored and/or provided by a source system 112. For example, a source event occurs when data in a field in a database at a source system 112 is added, deleted, or modified.

[0038] The engine 110 performs pre-effect and effect processing on the data describing the source events according to a defined set of rules. Preferably, the rules transform the data from the format of the source system 112 into the formats of one or more destination systems 116. For example, if a source event describes modified data in a field of a first type of database, the engine 110 processes the data describing the source event into a format suitable for modifying a corresponding field in a second type of database. The processed data describing the source events are referred to herein as "destination events" or as "data describing the destination events."

[0039] The engine 110 performs "actions" on the destination events according to the defined set of rules. In general, the actions describe how to deliver the destination events to the destination systems 116. For example, a destination event can be delivered to a destination system by making a Structured Query Language (SQL) call, sending an email, submitting information via an HTML form, sending an XML broadcast, etc. In this manner the engine 110 sends data describing destination events to the destination systems 116 in response to the source events generated by the source systems 112 and allows multiple disparate systems to share data effectively.

[0040] A user uses the console 120 to communicate with and control the engine 110. In one embodiment, the console 120 is a conventional computer system executing computer program modules for interfacing with the engine 110. In one embodiment, the console 120 executes specialized software providing a graphical user interface (GUI) for conveniently controlling the engine 110. In another embodiment, the console executes web browsing software for operating as a client that accesses the engine 110 via a network. In these embodiments, the communications link 122 coupling the console 120 to the engine is preferably a conventional network connection as described above with respect to links 114 and 118. These embodiments are advantageous because they allow the console 120 to be located anywhere on the network. In another embodiment, the console 120 is directly coupled to the computer system 110 executing the engine.

[0041] FIG. 2 is a high-level block diagram illustrating a more detailed view of the interaction between source systems 210 and the engine 110. FIG. 2 illustrates three source systems 210A, 210B, 210C for generating source events. There are two primary types of source events: 1) a change in a condition of data; and 2) a data notification.

[0042] The first type of source event, a change in a condition of data, occurs when data at a data repository maintained by a source system 210 are modified. Consider, for example, a modern relational database where modifications to the data repository take the form of insert, update, and delete operations. Each of these operations is a potential source event. The second type of source event, a data notification, occurs when data are proactively generated from a source system 210 either by that source system or by an outside system or process. For example, a source system 210 that occasionally sends messages and/or is contacted by a polling server generates data notification source events.

[0043] In FIG. 2, source system 210A illustrates an example of a system for generating the first type of source event. The source system 212A includes a data repository 212 A. Preferably, the data repository 212A is part of a database system supporting trigger functionality through the SQL or another technique. As is known in the art, a database "trigger" is a set of statements that are executed when a specific operation, such as changing data in a table, occurs.

[0044] Source system 210A includes a trigger module 214 containing one or more triggers that are executed when specific data in the repository 212A are modified (i.e., inserted, updated, or deleted). The triggers in the trigger module 214 preferably capture the modified, inserted, or deleted data of interest and, in one embodiment, store the data in a separate table 216 on the source system 210A. In one embodiment, the triggers also process the data, if necessary, from a format utilized by the repository 212A into a format utilized by the engine 110. The triggers also capture data representative of deletions.

[0045] An agent module 218 A at the source system 210A monitors the table 216 for source events. In a preferred embodiment, the agent module 218 A is a background process or, on MICROSOFT WINDOWS-based systems, a Windows service, executing on the source system 210A. When the agent module 218A detects a new source event in the table, it retrieves the modified data from the table and sends it to the engine 110. As part of the sending process, the agent module 218A preferably formats the data as an XML message using pre-defined tags that are understood by the engine 110. Then, the agent module 218A establishes a TCP/IP connection on a predefined port with the engine 110 and sends the XML message.

[0046] In FIG. 2, source system 21 OB illustrates an example of a system for generating the first type of source event, a change in a condition of data, where the data repository 212B is a hierarchical or flat file or another type of repository that does not necessarily support triggers. In this system 210B, a polling server 220 preferably polls the data repository 212B to detect changes to the data. When the polling server 220 detects data changes, it passes data describing the change to an agent module 218B in the source system 21 OB. The agent module 218B formats the data as an XML message and sends it to the engine 110. The polling server 220 and agent module 218B are both preferably background processes, or Windows services, executing on the source system 210B .

[0047] An advantage of utilizing the triggers 214, polling server 220, and agent modules 218 in the source data systems 210 described above is that the operations of these modules are transparent to the source systems. The tasks performed by these modules are relatively lightweight, meaning that the modules can execute on the systems 210 without adding significant processing overhead. In addition, the modules do not affect the integrity of the data repositories 212, even if the communications links 114 between the systems and the engine 110 are severed. Furthermore, the application and presentation layers of the systems are unchanged, so how users interact with the systems remains the same.

[0048] In FIG. 2, source system 210C illustrates an example of a system for generating the second type of source event, a data notification. In this system 210C, the data repository 212C is preferably representative of data that can be accessed through an interface such as telnet, FTP, HTTP, LDAP, POP, secure shell (SSH), and/or SQL or another interface.

[0049] Preferably, a polling client 222 in the engine 110 initiates the data notification source event by polling the data repository 212C via the appropriate interface. For example, if the interface is FTP, the polling client 222 preferably initiates an FTP connection with the source system 210C and executes the appropriate commands to access the data in the repository 212C. The source system 210C sees the activity of the polling client 222 merely as a client requesting information via an established interface. The polling client 222 formats the data as an XML packet and provides the packet to the other modules in the engine 110.

[0050] A preferred embodiment of the present invention provides data to the engine 110 in the XML format because this format is efficient and flexible. The following text illustrates the XML for a database update source event: <req id="l">

<db_action rule_id=" 18"> <update> <pre> <col id="13">3813</col> </pre> <post>

<col id="19">2.9330</col> <col id=" 17">Cast Iron</col>

<col id="13">3813</col> <col id="15">3</col>

<col id='"18">2001-08-l l 15:33:22.000</col> <col id="26">3.342572644267050e-006</col> </post> </uρdate> </db_action> </req>

In this example, the outermost "req" tag identifies the source event being communicated to the engine 110. The "db_action" tag identifies the rule ID of the engine rule (discussed in more detail below) for which the data are being communicated. The "update" tag identifies the operation type. The "pre" and "post" tags respectively identify blocks of data prior to and after the database operation. In addition, each "col" element identifies a specific table column having data contained between the opening and closing tags.

[0051] In FIG. 2, the source systems 210A, 210B of FIG. 2 that generate "change in the condition of data" source events utilize agents to push the data describing the source events to the engine 110. In contrast, the polling client 222 in the engine pulls source data from the source system 210C and thereby generates "data notification" source events.

[0052] A data notification event may also be pushed to the engine 110 by an agent on the source system that uses its own polling server or by the source system itself. For example, a source system 210 can push data notification events to the engine 110 via a HTTP request or another protocol.

[0053] FIG. 3 is a high-level block diagram illustrating a more detailed view ofthe engine 110 in relation to the other entities illustrated in FIG. 1. FIG. 3 illustrates functional modules within the engine. FIG. 3 illustrates only the modules ofthe engine 110 useful for describing the present invention, and it will be understood that an embodiment ofthe present invention may include other modules not described herein. In addition, embodiments ofthe present invention may lack modules described herein and/or distribute the described functionality among the modules in a manner different than described herein.

[0054] As briefly mentioned above, in one embodiment the engine 110 is executed on a conventional computer system running the Linux operating system. As such, the modules of the engine 110 are preferably Linux processes. In one embodiment, the modules are written in the Perl and Java programming languages, stored on a storage device associated with the computer system, and executed by other modules present in the operating system and/or computer system to provide the described functionality. In another embodiment, the modules ofthe engine 110 are processes executing on a version ofthe WINDOWS operating system from MICROSOFT CORP.

[0055] Turning now to the specific modules within the engine 100, a polling layer 310 illustrated within the engine 110 represents the engine's functionality for obtaining source events via polling. As described with respect to FIG. 2, a polling server 220 and agent 218B executed on a source system 210B can generate source events. Likewise, the engine 110 itself can execute a polling client 222 for polling source systems 210C. The polling layer 310 of FIG. 3 abstractly represents modules for receiving data via either polling method.

[0056] A connection manager 312 preferably receives the XML data packets describing the source events from the polling layer 310 and/or directly from the source systems 112. The connection manager 312 preferably parses and validates the packets, and sends receipt acknowledgements back to the polling layer 310 and/or source systems 112. The connection manager 312 also preferably retrieves rules for processing the source events from a rules database 314. The connection manager 312 constructs intermediate data representations describing the source events and the associated processing rules and stores the representations in queues 316. In another embodiment, the connection manager 312 does not construct the intermediate data representations but instead stores the XML data packets describing the source events.

[0057] In a preferred embodiment, the connection manager 312 analyzes the retrieved rules in order to detect rule-firing cycles (i.e., potentially infinite rule-firing loops). Such a cycle might occur, for example, if source event A results in action B which, in turn, results in other actions that eventually cause source event A to occur again. Upon detecting such cycles, the connection manager 312 preferably breaks the cycle by leaving the final rule (i.e., the rule that completes the cycle) out ofthe intermediate data representation. The cycle detection process is described below in more detail.

[0058] In a preferred embodiment, the engine 110 executes a separate instance ofthe connection manager 312 for each source system 112. Separate instances are desirable because they increase the performance ofthe engine 110 by enabling parallel execution. In an alternate embodiment a single instance ofthe connection manager 312 processes source events from some or all ofthe source systems 112.

[0059] The database 314 preferably stores rules and metadata describing the processing to be performed on the data describing the source events and the effects to be performed to deliver data describing destination events to the destination systems. Each rule preferably describes a distinct source event, and the processing and effect(s) to perform in response to the event. For example, a source event could be the database update of table X in database Y. Inserting a new record into the same table would be considered a separate source event and therefore be described by a separate rule. In one embodiment, the rules contain numeric identifiers that refer to columns and/or tables in the data repositories 212 in the source systems 112 to which the rules pertain. The rules also refer to data sources (the metadata) stored in the database 314 or elsewhere. Preferably, the rules in the database 314 are encoded in XML. However, other embodiments ofthe database 314 can use different representations ofthe rules.

[0060] Preferably, the engine 110 includes multiple queues for holding the intermediate data representations created by the connection manager 312 that describe the source events and rules. In one embodiment the engine 110 maintains separate first-in-first-out (FIFO) queues 316 for each destination system 116 and each action type (i.e., delivery method). For example, there are preferably separate queues for each destination system 116, as well as a queue for the email action, a queue for the HTTP action, etc. Alternative embodiments ofthe present invention store the intermediate data representations in data structures other than queues.

[0061 ] In one embodiment, each queue is implemented as a separate directory on the storage device associated with the computer system executing the engine 110. The entries in the queue are stored as sequentially numbered files (e.g., _000004901.tsi), with the number indicating a file's position in the queue. Each file contains a data structure describing the data from the source event and rules with which the data are associated. [0062] The engine 110 preferably includes an instance of a queue manager 318 for each queue 316. Each queue manager 318 sequentially reads the files in its queue's corresponding directory and processes the data and rules as specified by the files' data structures. The queue manager 318 applies the pre-effect and effect processing specified by the rules in the queue entry to the data to produce data describing the destination event. Then, the queue manager preferably executes the action specified by the rules and/or associated with the queue 316 to deliver the data describing the destination event to the destination system(s) 116. For example, in one embodiment the queue manager 318 executes a SQL command at a database maintained by a destination system 116 in order to "deliver" the destination event to the destination system. In another embodiment the queue manager 318 sends an email containing the data describing the destination event to a destination system 116. In yet another embodiment, the queue manager 318 submits an HTML form to a web server operated by the destination system. Should a destination system 116 be unavailable, the queue manager 318 will preferably try to connect to the system at specified intervals either indefinitely or until a timeout period passes.

[0063] A transform server 320 in the engine 110 preferably supports pre-defined, as well as user-defined, functions for transforming the data in the source events. In one embodiment, the server 320 provides "plug-in" style functionality, meaning that users can define custom transformations using functions and store them on the transform server 320. The custom transformations can utilize other functions stored on the transform server 320 and/or functions provided by the database 314. In one embodiment, the server 320 allows user-defined functions to be added dynamically, i.e., at runtime and without having to restart the engine 110 or any module within the engine.

[0064] Preferably, the transform server 320 is implemented as a daemon that monitors ports for remote procedure calls (RPCs) made according to the XML-RPC protocol. When a queue manager 316 encounters a user-defined function in a rule's logic, it makes a RPC to the transform server 320. The server 320 executes the user-defined function and returns the result to the queue manager.

[0065] A parent queue manager 322 in the engine 110 manages the queue managers 318. The parent queue manager 322 dynamically adds and removes queue managers 318 as destination systems 116 are added and removed. Likewise, the parent queue manager 322 adds and removes queue managers 318 as particular action types are used or no longer used. [0066] A control server 324 preferably provides the console 120 and other devices and/or applications outside the engine 110 with an interface for viewing and controlling the engine. For example, the control server 324 allows the console 120 to start and stop individual components within the engine 110, such as the connection manager 312 and parent queue manager 322, and retrieve status and accounting information from the engine.

[0067] Preferably, the engine 110 also includes a license server 326 for specifying the features available to users ofthe engine 110. The license server 326 maintains license data specifying the rights and privileges available to users ofthe engine 110. In one embodiment, the license server 326 specifies how many source 112 and/or destination 116 systems can be utilized with the engine, the data processing functions and effects available to users, whether users can develop custom rules, etc. The other modules within the engine 110 periodically contact the license server 326 to ascertain and verify the user's right to use certain features.

[0068] FIG. 4 is a block diagram graphically illustrating the rule-based processing performed by the modules ofthe engine 110 illustrated in FIG. 3. In general, the engine 110 provides two-stage processing. The first stage is pre-effect processing 410 and the second stage is effect processing 412. Preferably, the two stages are highly configurable and flexible, thereby enabling the engine 110 to provide an extensible framework for communicating information among the systems 112, 116. Either or both stages can be skipped depending upon the rules. As described above, a queue manager 318 preferably performs both processing stages in response to rules retrieved from the database 314 by the connection manager 312 and or the action type associated with the queue. Other embodiments ofthe engine 110 distribute this processing functionality differently.

[0069] The pre-effect processing stage 410 provides multiple types of processing ofthe data describing the source event in order to produce data describing a destination event. In one embodiment, there are four types of pre-effect processing: data incorporation 414, data transformation 418, user-defined processing 420, and conditional logic 422. Other embodiments ofthe engine 110 provide different processing types at this stage in addition to, or instead of, the types described herein.

[0070] Data incorporation 414 allows the pre-effect processing to combine and/or utilize multiple sets of data with the data describing the source event. For example, pre-effect processing 410 can perform a SQL query on an external database to retrieve data, such as an email address, before performing actions that use this data.

[0071] If necessary or desired, the engine 110 can wait for the other data to arrive before performing data incorporation 414. For example, the engine 110 can suspend processing of a first source event until a second source event (or another data input) containing certain data arrives. The engine 110 can preferably also actively obtain data from external sources. For example, the pre-effect processing for a source event from a first source system 112 can include requesting, polling, or otherwise accessing a second source system for data. Similarly, the pre-effect processing can include accessing a computer system on the Internet or another network to obtain certain data.

[0072] The engine 110 can also incorporate or reference other data in order to perform validation or comparison testing with data in a source event. The reference data is distinguished from obtained data in that it is only used as part of validation or comparison operations rather than being added to the information set. For example, data received from a source event may contain product codes that a company wants to validate as existing in a separate warehouse data repository before continuing on with processing. In this example, the engine 110 would perform the comparison as a condition to proceeding with processing.

[0073] Data transformation 418 pre-effect processing enables low-level manipulation of the data in a source event. In one embodiment, the data transformation processing 418 uses functions selected from a library in the database 314 and/or transform server 320 to operate on the data. The functions in the library are preferably grouped into categories, which in one embodiment include: arithmetic; branch; date/time; general; logical; lookup; relational; security; and string manipulation. Other embodiments ofthe engine 110 utilize different functions and/or function categories instead of, or in addition to, the ones described herein.

[0074] User-defined processing 420 processes the data in the source event according to user-defined functions stored in the transform server 320. Preferably, the console 120 provides the user with a scripting interface with which the user can define custom functions. In one embodiment, the scripting interface supports the Perl, JavaScript, and Tel scripting languages. Using this interface, a user can work with data in source events and other data by specifying specific data elements as inputs. The resulting outputs ofthe custom functions can be used in other processing functions and/or incorporated into the source and/or destination events. [0075] The conditional logic 422 enables the data processing performed on the data in a source event to be determined dynamically using control flow logic. In one embodiment, the conditional logic can evaluate a Boolean equation and use the result to determine whether to perform or omit certain actions.

[0076] The conditional logic 422 allows the data processing to be conditioned on factors including the type of data, the information contained in the data, the environmental context surrounding the data, etc. The engine 110 dynamically responds to these factors in real time, thereby providing a user with precise control over how source events are processed.

[0077] The types of data on which the data processing are conditioned include, for example, customer names, product names, codes, monetary values, etc. Thus, by means of applying conditional logic 422, the engine 110 can process a source event containing data representative of a customer name differently than a source event containing data representative of a monetary value, even if both source events come from the same source system 112. In another example, the conditional logic 422 can be applied to data in a source event to process names beginning with "B" differently than names beginning with "G," or to process monetary values differently depending upon whether the value exceeds $500.

[0078] The environmental context surrounding the data on which the data processing is conditioned are variables determined in response to external events. Examples of environmental variables include the time, date, number of events processed by the engine 110 within a given time period, the location ofthe source system 112 that produced a given source event, etc. The engine 110 can use conditional logic 422 to perform processing based on the environmental context to, for example, treat source events received from Chicago during business hours differently than source events received from Los Angeles on a Sunday.

[0079] The effect processing stage 412 distributes the destination events to the destination systems 116. In a preferred embodiment, the effect processing stage 412 can perform data transformation 418 and user-defined 420 processing on the destination messages before distribution in the same manner as the pre-effect processing stage 410. Other embodiments of the engine 110 provide different processing types at this stage 412 in addition to, or instead of, the types described herein. [0080] The effect processing stage 412 distributes the data describing the destination events via one or more action types 424. An "action" delivers the destination event data to one or more destination systems 116 according to the rules in the engine 110, the results of any processing performed in the pre-effect 410 and/or effect 412 stages, and/or the action type associated with a queue 316. Each action type defines a different delivery method or technique. A commonly used action type is the "database" action. One type of database action delivers the destination event data by making one or more SQL calls to the destination system(s) 116. The SQL calls effect changes in the destination system's data repository that reflect the data describing the destination event. For example, the database action can make a SQL call that causes data in a specific field ofthe destination event to be stored in a specific field in the data repository at the destination system 116.

[0081] Another action type is the "email" action. This action type preferably delivers the destination event data, encoded as text or HTML, to the destination system(s) 116 via an email message. A similar "FTP" action type delivers destination event data encoded as text, XML, SQL, HTML, and/or binary data to destination systems 11 via the FTP.

[0082] Other action types supported by a preferred embodiment of the present mvention include an "HTTP" action type that uses HTTP GET/POST commands, a "JMS" action type that uses the JAVA messaging service (JMS) "publish" command, and a "TCP/IP broadcast" command. Each of these action types can use its respective commands to deliver plain text, XML, SQL, HTML or binary destination event data to the destination systems 116.

[0083] Additional action types include the "LDAP" action type that uses the Lightweight Directory Access Protocol (LDAP), the "SOAP" action type that uses the Simple Object Access Protocol (SOAP), and the "XML-RPC" action type that uses the XML-remote procedure call (RPC) protocol. These action types use the respective protocols to deliver destination event data encoded as plain text, XML, and/or HTML to the destination systems 116. Preferably, the action 424 types also include a "telnet" action type that uses the telnet command to deliver destination events to the destination systems 116 as plain text. Alternative embodiments ofthe present invention support other action types in addition to, or instead of, the ones described herein.

[0084] FIG. 5 is a flowchart illustrating the steps performed by the engine 110 to facilitate communications according to a preferred embodiment ofthe present invention. Other embodiments ofthe present mvention may perform different or additional steps than those described herein. In addition, the steps maybe performed in different orders. As described above, the engine 110 can preferably simultaneously process multiple source events. This description refers to the processing of a single source event for purposes of clarity.

[0085] Initially, the engine 110 receives 510 the data describing the source event from a source system 112. The engine 110 preferably parses, validates, and acknowledges receiving 512 the event. The engine 110 identifies and retrieves 514 rules pertaining to the source event from the rules database 314 based on the event type and or the source system 112. The rules specify the pre-effect and effect processing to perform on the source event (if any).

[0086] Preferably, the engine 110 builds an intermediate representation ofthe data describing the source event and the rules. The engine 110 places 516 this representation into the appropriate FIFO queue 316 or queues. The engine determines the appropriate queue based on the effect processing, specifically the action type, specified by the rules.

[0087] In due course, the engine 110 reads the intermediate representation from the queue and performs 518 any pre-effect processing specified by the rules to transform the intermediate representation into a destination event (or discard the source event). Next, the engine 110 performs 520 the effect processing specified by the rules. At this point, the destination event is ready for delivery to a destination system 116 via the action type specified by the rules. Accordingly, the engine 110 performs 522 the action and thereby delivers the destination event data to the destination system 116.

[0088] Preferably, the user uses the GUI provided by the user console 120 to establish, view, modify, and delete rules stored in the database 314. However, other embodiments ofthe present invention use other techniques to perform these functions. FIG. 6 is a flowchart illustrating the steps performed by a user to establish a rule for the engine 110. Other embodiments ofthe present invention may perform different or additional steps than those described herein. In addition, the steps may be performed in different orders. Moreover, those of ordinary skill in the art will recognize that the user can perform similar steps to view, modify, and/or delete rules stored in the database 314.

[0089] The user specifies 610 a source system 112 to which the rule applies. In one embodiment, the user selects a named source system 112 from a list of potential source systems presented by the GUI. The user also specifies 612 a source event on the source system 112 that will trigger the rule. For example, if the source system 112 is a database, the user can preferably select among source events including "insert," "update," and "delete."

[0090] If the source system 112 has not previously been used with the engine 110, the user may need to register the source system. In one embodiment, the user provides credentials, such as a user name and password, that the engine 110 can use to access the source system 112. In addition, the user also specifies the data storage type and other parameters depending upon the type of data repository at the source system 112. Once the source system 112 is registered, the engine 110 preferably treats it in the same manner as any other source system/data provider.

[0091] The user preferably specifies 614 an action type for the rule. For example, the user can choose among types including "database" (i.e., the action is a database update), email, LDAP, etc. The user also specifies 614 the destination system 116 for the action type. Depending upon the action type, the user provides different information to specify the destination system 116. For example, if the action type is "email," the user preferably provides a destination email address. If the action type is "database," the user preferably identifies the database to update.

[0092] The user also specifies the pre-effect 616 and effect 618 processing (other than the action type) to perform on the source/destination event. As described above with respect to FIG. 4, the present invention enables complex pre-effect and effect processing. The techniques that the user uses to specify the processing vary depending upon the specified source system, source event, and action type. For example, if the source system is a database, the event is a database update, and the action type is another database update, the user specifies the effect processing by specifying a mapping between the source database field(s) and the destination database field(s), as well as specifying any additional processing to perform on the data used to update the field(s) (i.e., the data contained in the source event). In another example, if the source system is a database, the event is a database update, and the action type is email, the user specifies the source database field(s), any processing to perform on the data used to update the field(s), and any text to include in the email along with data that can be inserted into the email text dynamically (e.g., "Congratulations! Your credit card limit is now $ !"). [0093] At this point, the user preferably saves 620 the rule to the database 314 in the engine 110. Preferably, upon receipt of a "save rule" instruction from the user, program modules in the user console 120 check for any "connections" between the rules before saving the rule in the database 314. In general, two rules are connected if the firing ofthe first rule can lead to a firing ofthe second rule. In certain circumstances, two or more rules can be connected in a manner that creates an infinite loop, especially when both the source systems and destination systems are databases. For example, a first rule that updates a field in a destination database may be connected to a second rule in the destination database that updates a field in the original source database, leading to an infinite loop of database updates. If the program modules identify any rules that are connected to the rule being saved, the modules preferably mark the rule being saved as "bi-directional." The rule is then saved to the database 314, where a data field indicates whether it is bi-directional. In response to the saved rule, the engine 110 preferably propagates the triggers and/or other logic to the source systems 112, connection manager 312, and/or polling layer 310 as may be necessary to bring the rule into effect (this action is not shown in FIG. 6).

[0094] Preferably, the engine 110 includes functionality for detecting and breaking potential infinite rule-firing loops. In one embodiment, when the engine 110 fires a rule marked as bi-directional, the engine causes a token to be saved to the table 216 on the destination system 116. The token identifies the source system 112 that generated the source event that ultimately caused the destination event at the destination system 116. Then, when the (former) destination system 116 generates a new source event, the agent 218 sends the token to the engine 110 with the source event identifier. If any ofthe rules fired in response to the new source event are marked as "bi-directional," the engine 110 determines whether the actions associated with the rules are directed to the source system 112 identified by the token. If so, the engine 110 preferably suppresses the action to the source system 112, thereby breaking the rule-firing loop.

[0095] Once a rule is saved to the database 314, the user can optionally specify 622 the operational mode for the rule. In one embodiment, a rule's possible operational modes are "active," "simulation", and "inactive." A rule in active mode fires in response to source events as described above. A rule in simulated mode fires normally, except that the engine 110 does not send the destination event data to the destination systems 116; the engine preferably records and make visible in a log what would have been sent, thereby allowing the rule to be tested without affecting the destination systems. Thus, the simulation mode can be conceptualized as an action type that delivers the data describing the destination event to a log instead of to the destination systems. A rule in inactive mode disables the trigger and/or agent on the source system 112, so both the source system and the engine 110 function as if the rule did not exist.

[0096] FIGS. 7-12 illustrate some ofthe GUIs presented by the user console 120 to allow the user to perform the steps of FIG. 6 according to one embodiment ofthe present invention. Those of skill in the art understand that other embodiments ofthe present invention can have different GUIs, and the GUIs illustrated herein are merely examples of possible GUIs.

[0097] FIG. 7 illustrates a GUI 700 for enabling the user to select a source system 112 and specify the source event. A list box 710 displays a tree hierarchically listing the source systems 112 available to the engine 110. In this exemplary tree, the source systems include a "Pet Store" database having tables named "account," "bannerdata," and "category." Each of these tables can be selected by the user and represents a potential logical source system for purposes ofthe present mvention. The GUI also includes a selection box 714 enabling the user to specify whether the source event is an insert, update, or delete operation to the identified source system.

[0098] FIG. 8 illustrates a GUI 800 for enabling the user to specify the action type for an effect. A list box 810 lists and allows the user to select one ofthe possible actions (e.g., database, email, etc.) at a time. Multiple actions and effect types can be utilized in response to one or a combination of source events. An area 812 adjacent to the list box 810 displays an explanation ofthe currently selected action.

[0099] FIG. 9 illustrates a GUI 900 for enabling the user to specify the processing to perform on source event data to transform it into a desired format for the destination event. Specifically, this portion of the GUI 900 allows the user to specify mappings between the source database field(s) and the destination database field(s), as well as specifying any additional processing to perform on the data used to update the field(s). A list box 910 on the left side ofthe GUI lists the data fields 912 in the source system 112, which in this example are the fields of he "account" table in the "Pet Store" database. A list box 914 on the right side ofthe GUI 900 lists the fields 916 available in the destination system 116. [0100] In this example, the destination system 116 is a database table entitled ACCOUNT and having fields corresponding to the fields in the source system 112. The names ofthe fields in the source table are displayed in lowercase while the fields in the destination table are displayed in uppercase. The right list box 914 graphically indicates the relationship between the source fields, the effect processing, and the destination fields. For example, the list box illustrates 914 that the effect processing concatenates the "addrl" and "addr2" fields in the source database into a single entry stored in the "ADDRESS" field 918 ofthe ACCOUNT table.

[0101] The GUI 900 also displays additional elements allowing the user to specify the details of specific effect type processing. A selection box 920 allows the user to specify whether the destination event is an insert, update, or delete operation. A "link" button 922 allows the user to create a relationship between the fields ofthe source table and the fields of the destination table. Tabs 924 across the top ofthe left text box 910 control whether the box displays the source fields (as shown), the destination fields, or functions for processing the contents of the fields.

[0102] FIG. 10 illustrates a GUI 1000 for enabling the user to specify pre-effect processing for the specific rules. The illustrated GUI 1000 has two list boxes 1010, 1012 respectively aligned on the left and right sides ofthe display. The left list box 1010 preferably lists the source systems 112 and the rules defined for the systems, if any. For example, in FIG. 10 the "Bookstore" source system 1014 (which is a database executing on the "ocelot" server) has a single defined rule named "ACCOUNT." The list box 1010 also lists a "Global" entity that enables the user to specify pre-effects accessible to every rule in the engine 110.

[0103] The right list box 1012 preferably lists the pre-effects for the currently selected rule in the left list box. In the example of FIG. 10, the right list box 1012 lists two pre-effects 1018 respectively named "Get UniquelD" and "Is new customer." As indicated by graphical icons to the left ofthe effects' names, the "Get UmquelD" pre-effect is an SQL statement while the "Is new customer" pre-effect is a Boolean assertion. Preferably, the pre-effects are applied to the associated rule in listed order and the user can use arrow buttons 1020 in the GUI 1000 to change the order. Additional buttons 1022 in the GUI respectfully allow a user to specify a new SQL pre-effect, a new Boolean assertion pre-effect, to edit already-created pre-effects, and to delete existing pre-effects. [0104] FIG. 11 illustrates a pre-effect assertion 1100 where a Boolean equation 1110 is evaluated and a conditional action is taken in response to the results ofthe evaluation. In the illustrated example, called "Is new customer," the status data element 1112 in the accounts table ofthe primary source system is being compared to the three character, all capital, string, "NEW."

[0105] FIG. 12 illustrates a pre-effect in which data is being incorporated from another location. In this case, a SQL statement 1214 is being used to gather information from the "Petstore" database on the "Ocelot" system 1210. The SQL statement 1214 is constructed dynamically using data elements from the primary source system. In this case, the data elements for "userid" and "email" are being used in the SQL statement 1214 to generate a variable 1216 called "uniquelD" that is available for effect processing. Once the SQL statement is constructed, it is executed as part ofthe pre-effect. The values to be gathered as part ofthe pre-effect can be gathered before or after the pre-effect action.

[0106] In sum, the present invention includes an efficient and flexible architecture enabling multiple disparate source systems to communicate via a variety of communication techniques and technologies. Moreover, the present invention also provides sophisticated data processing capabilities allowing a broad range of data transformation and effect processing rules to be applied to the communications among the computer systems. An organization can use the present invention to maintain data coherence between different types of computer systems, data storage systems, and/or data delivery systems.

[0107] The above description is included to illustrate the operation ofthe preferred embodiments and is not meant to limit the scope ofthe invention. The scope ofthe invention is to be limited only by the following claims. From the above discussion, many variations will be apparent to one skilled in the relevant art that would yet be encompassed by the spirit and scope ofthe invention.

Claims

1. A method of communicating data between a source system and a destination system, comprising: receiving data describing a source event from the source system; identifying one or more rules applicable to the source event, the rules describing processing to perform on the source event; and processing the source event responsive to the identified rules to generate data describing a destination event and provide the data describing the destination event to the destination system responsive to the identified rules.

2. The method of claim 1 , wherein the receiving comprises: receiving the data describing the source event from an agent executing on the source system.

3. The method of claim 2, wherein the agent generates the data describing the source event responsive to a firing of a trigger associated with a data repository on the source system.

4. The method of claim 2, wherein the agent generates the data describing the source event responsive to a polling of a data repository on the source system.

5. The method of claim 1, wherein the receiving comprises: polling the source system to retrieve the data describing the source event.

6. The method of claim 1, wherein the data describing the source event are encoded in the extensible markup language (XML).

7. The method of claim 1 , wherein the processing comprises: performing pre-effect processing on the data describing the source event.

8. The method of claim 7, wherein performing pre-effect processing comprises: incorporating external data with the data describing the source event.

9. The method of claim 7, wherein performing pre-effect processing comprises: transforming the data describing the source event with one or more data transformation functions.

10. The method of claim 7, wherein performing pre-effect processing comprises: evaluating conditional logic responsive to the data describing the source event; wherein the processing is performed responsive to evaluations ofthe conditional logic.

11. The method of claim 1 , further comprising: storing the data describing the source event and the identified rules in at least one data structure selected from among a plurality of data structures, wherein the data structure is selected responsive to the identified rules.

12. The method of claim 1 , wherein the processing comprises: performing effect processing on the data describing the destination event to provide the data describing the destination event to the destination system.

13. The method of claim 12, wherein the effect processing provides the data describing the destination event responsive to one or more action types specified by the rules.

14. The method of claim 13, wherein an action type specifies a modification to perform on a data repository stored by the destination system.

15. The method of claim 13, wherein an action type specifies providing the data describing the destination event to the destination system via a conventional electromc communication protocol.

16. The method of claim 13, wherein an action type specifies providing the data describing the destination event to a log file.

17. The method of claim 16, wherein the data describing the destination event are provided to the log file instead of to the destination system.

18. The method of claim 1 , further comprising: detecting potential rule-firing cycles occurring responsive to the rules applicable to the source event.

19. A computer program product comprising: a computer-readable medium having computer program logic embodied therein for communicating data among source systems and destination systems, the computer program logic comprising: a database module adapted to hold rules describing processing to perform on data describing source events; a connection manager module adapted to receive data describing a source event from a source system, to identify rules in the database associated with the source event, and to store the data describing the source event and the associated rules; and a storage manager adapted to access the data describing the source event and the associated rules stored by the connection manager, and to process the data describing the source event responsive to the associated rules to generate data describing a destination event.

20. The computer program product of claim 19, further comprising: a polling layer interfacing with the source system and the connection manager and adapted to receive the data describing the source event responsive to a poll ofthe source system and provide the data to the connection manager.

21. The computer program product of claim 20, wherein the polling layer comprises: a polling client adapted to poll a data repository at the source system.

22. The computer program product of claim 20, wherein the polling layer is adapted to interface with an agent process at the source system, wherein the agent process is adapted to poll a data repository at the source system to detect a source event and to send the data representative ofthe source event to the connection manager.

23. The computer program product of claim 19, wherein the storage manager is further adapted to provide the data describing the destination event to the destination system.

24. The computer program product of claim 19, wherein the storage manager is adapted to manage a queue, wherein the queue holds data describing a plurality of source events, and wherein the storage manager is adapted to process the data describing the plurality of source events in a first-in first-out order.

25. The computer program product of claim 19, further comprising: a parent storage manager for managing instances of the storage manager, wherein the parent storage manager creates and destroys instances ofthe storage manager in real-time responsive to the rules in the database module.

26. The computer program product of claim 19, wherein the storage manager is adapted to perform pre-effect processing on the data describing the source event.

27. The computer program product of claim 26, wherein the pre-effect processing comprises: incorporating external data with the data describing the source event.

28. The computer program product of claim 26, wherein the pre-effect processing comprises: transforming the data describing the source event with one or more data transformation functions.

29. The computer program product of claim 26, wherein the pre-effect processing comprises: evaluating conditional logic responsive to the data describing the source event.

30. The computer program product of claim 19, wherein the storage manager is adapted to perform effect processing to deliver the data describing the destination event to a destination system.

31. The computer program product of claim 30, wherein the effect processing delivers the data describing the destination event to the destination system responsive to one or more action types specified by the rules associated with the source event.

32. The computer program product of claim 31 , wherein there are a plurality of storage managers and wherein each storage manager is adapted to send the data describing the destination event to a destination system via a different action type.

33. The computer program product of claim 31 , wherein an action type specifies a modification to perform on a data repository stored by the destination system.

34. The computer program product of claim 31 , wherein an action type specifies providing the data describing the destination event to the destination system via a conventional electronic communication protocol.

35. The computer program product of claim 19, wherein the storage manager is further adapted to store the data describing the destination event to a log.

36. The computer program product of claim 19, further comprising: a transform server for storing functions for transforming the data describing the source events responsive to the rules associated with the source events.

37. The computer program product of claim 19, further comprising: a license server for specifying the rights and privileges available to users ofthe computer program logic.

38. The computer program product of claim 19, further comprising: a control server for providing a graphical user interface (GUI) with which a user can control operation ofthe computer program logic.

39. A data communications system comprising: one or more source systems for generating data describing source events; one or more destination systems for receiving data describing destination events; an engine in communication with the source and destination systems, the engine adapted to receive the data describing the source events generated by the source systems, to process the data describing the source events responsive to rules applicable to the source events to generate data describing destination events, and to provide the data describing the destination events to particular destination systems.

40. The system of claim 39, wherein a source system comprises: a data repository, wherein a source event is a change to data in the repository; and an agent adapted to monitor the data repository for source events and to send the data describing the source events to the engine.

41. The system of claim 40, wherein the agent generates the data describing the source event responsive to a firing of a trigger associated with the data repository.

42. The system of claim 40, wherein the agent generates the data describing the source event responsive to a polling ofthe data repository.

43. The system of claim 39, wherein the engine is further adapted to poll a source system to retrieve the data describing the source event.

44. The system of claim 39, wherein a source event is a data notification from a source system.

45. The system of claim 39, wherein the data describing the source event are encoded in the extensible markup language (XML).

46. The system of claim 39, wherein the engine is adapted to perform pre-effect processing on the data describing the source event.

47. The system of claim 46, wherein the pre-effect processing comprises: incorporating external data with the data describing the source event.

48. The system of claim 46, wherein the pre-effect processing comprises: transforming the data describing the source event with one or more data transformation functions.

49. The system of claim 46, wherein the pre-effect processing comprises: evaluating conditional logic responsive to the data describing the source event.

50. The system of claim 39, wherein the engine is adapted to perform effect processing on data describing a destination event.

51. The system of claim 50, wherein the effect processing provides the data describing the destination event to a destination system responsive to one or more action types specified by the rules.

52. The system of claim 51, wherein an action type specifies a modification to perform on a data repository maintained by the destination system.

53. The system of claim 51 , wherein an action type specifies providing the data describing the destination event to the destination system via a conventional electronic communication protocol.

54. The system of claim 39, wherein the engine is further adapted to detect potential rule-firing cycles occurring responsive to the rules applicable to the source event.