WO2001065382A1

WO2001065382A1 - Method and system for processing requests using dynamically loadable rules determined by class and context

Info

Publication number: WO2001065382A1
Application number: PCT/US2001/006497
Authority: WO
Inventors: Reimer Mellin; Rafael Szware
Original assignee: Abridge, Inc.
Priority date: 2000-02-29
Filing date: 2001-02-28
Publication date: 2001-09-07
Also published as: AU2001239959A1; AU2001239958A1; WO2001065336A2

Abstract

Efficient processing of requests is achieved through a system including a queue processor (140), one or more queues (120), one or more queue items (1201), a scheduler (130), and a plurality of rules (160). A request is anything that needs to be processed, including both commands to perform actions or static files that need to be filed. Every request, regardless of type, is placed in a queue (120). The queue holds items waiting to be processed. Once a request is placed in a queue, it is a queue item. In an asynchronous embodiment, a scheduler executes a queue processor, which processes all of the items in the queue according to a set of ordered rules provided by a rule finder.

Description

METHOD AND SYSTEM FOR PROCESSING REQUESTS USING DYNAMICALLY LOADABLE RULES DETERMINED BY CLASS AND CONTEXT

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority from Fisher, et al . , "Method and System for Utilizing Internet Email Communications for Group Collaboration", U.S. Provisional Application No. 60/185719, filed February 29, 2000, incorporated herein by reference .

TECHNICAL FIELD

This invention is directed to processing requests in an object oriented environment through the use of an extendable, scalable, system using various software processes, library components, and dynamically loadable rules .

BACKGROUND ART

A request is anything that can be processed by software logic. It includes internal requests from one piece of software to another piece of software, commands for system resources and static files that the invention can interpret.

An asynchronous request is a request that does not require an immediate response. For example, all email is asynchronous in nature. Unlike a phone call, an email message is not immediately received the moment it is sent . There can be a delay lasting seconds, minutes, or in extreme circumstances, hours. Fax, voice mail, or Short Messaging Service requests are also asynchronous. An email message is a simple text file containing addressing information and a body of text. Binary files, such as executable files, can be sent via email once they have been encoded as text characters. Email messages by themselves are entirely static. They are simply text sent over the internet from email server to email server. The text needs to be processed by the recipient in order to become a dynamic command .

A synchronous request requires an immediate response. For example, when a user clicks on a hyperlink to view a web page, the user expects the web server to return the requested page with little time lapse. The request must be handled as it is received. Other examples of synchronous requests are automated telephone answering service interfaces, Instant Message and WAP requests. Other synchronous requests are those used in transactional applications. For example, a customer purchasing a product needs to know if the product is in inventory and the seller needs to verify the customer's credit card. Although there can be some time lapse, a quick seemingly synchronous interaction is required. A slow interaction could mean a lost sale or lack of repeat business.

Handling requests is a part of every software system. Most approaches suffer from one or more of the following problems.

First, these systems are not extendable. They are designed to handle one specific task, such as handling email. Most systems have a different set of processes for handling each type of request. When additional functionality is needed, such as processing fax messages, the whole system must be rewritten, or a new system must be appended .

Second, these systems are not easily modified.

Changing a minor detail requires bringing the system down to recompile. For example, email or other request servers frequently have message handling logic hard coded into the server program. An abstract example of such code is: if x == y then k elseif x == z then j elseif x == a then h. To change any of these elements requires bringing down the entire system, making the change, recompiling and reinstalling.

Finally, these systems are not scalable, that is, they cannot grow as users and tasks grow. Most systems tend to suffer from bottleneck problems. They have one dedicated process to handle many requests. More requests require more time and system resources to be processed. These systems often address scalability by adding more memory and faster processors to existing machines.

DISCLOSURE OF THE INVENTION

The system ("system") of the present invention provides a novel method to manage all requests, both asynchronous and synchronous, using one approach. The invention is slightly different depending on whether it is used for synchronous requests or asynchronous requests .

The system of the present invention processes requests/objects that need processing. A component of the invention turns a non-object request into an object and places it in a queue. Once an object is in a queue, it is referred to as a queue item. Most request processing systems do not turn a request such as an email message into an object. These other systems would process it as an email message. These other systems would not turn a fax into an object. They would just process it as a fax. By turning them both into objects the system of the present invention can use the same processes on both.

The delivery agent is the component that takes a non- object request from the server, turns it into an object, and delivers it to a queue. While for many requests the delivery agent will be a separate component, for other requests the delivery agent could actually be part of some other component .

In other embodiments of the invention, the request may already be an object before reaching the system. In addition, items can be placed in queues by both external oriented components, like the delivery agent, and internal components, such as rules, as explained below.

A queue is a component of the present invention into which objects representing requests to be processed are placed. Queues are generally mapped to addressable entities. An addressable entity possesses a unique address or name, for example an email address, phone number, or any totally unique identifier.

Another component of the invention is a queue processor ("processor"), which evaluates an item in a queue to determine its class or other information. The processor processes items in a specific queue. When the queue is empty, the instance of the queue processor stops/closes.

The system of the present invention includes multiple queues and multiple instances of the queue processor. In the asynchronous mode of operation, a scheduler matches queue processor instances with queues in need of processing

The invention includes a rule finder that gathers a list of ordered rules to process an item in a queue. The queue processor passes the rule finder information about the item and its context. This information can include the name of a queue and the class of the item. The rule finder uses this information to gather a list of ordered rules which it returns to the processor. The list of rules included with the invention is dynamically loadable. Rules contain logic for processing a queue item.

One preferred embodiment of the method of the present invention, a request processing system for handling asynchronous requests such as email and fax requests, includes the following steps. First, requests, entities that need to be processed, are placed in a queue. These are referred to as queue items. If the request is an incoming message, such as email, a delivery agent places the request in the queue. Second, a scheduler program matches an available instance of a queue processor program with the queue containing queue items. Third, the queue processor removes a queue item from the queue. Fourth, the queue processor evaluates the item to determine information about the item. This information includes the class of the item, such as whether the item is an email, fax, voicemail, or some other request, and the name of the queue it is in. Fifth, the queue processor provides this information to a rule finder which generates a list of ordered rules. Next, the rule finder passes the list of rules to the queue processor. Finally, the queue processor feeds to each rule in order the queue item to be processed. The rule either returns the item to the queue processor for further processing, or it consumes the item, in which case processing on that item ceases. Note that before an item is consumed, it could cause a rule to generate one or more new queue items. Once an item is consumed, the processor checks to see if the queue contains any additional items. If the queue contains additional items, the processor processes each item until the queue is empty. When the queue is empty, the processor terminates.

It is an object of the invention to be generic enough to handle any type of request and to be extendable. No special rewriting is needed for a different type of request. To add support for a different type of incoming request, only a delivery agent for that type of server and a new set of rules for processing those requests need to be added to the system. The different types of requests can be placed in the same queue, and the same queue processor can process different types of items. Examples of different types of requests include email messages, fax messages and voice mail messages. Similarly, adding support for different types of outgoing requests only requires adding new command- recognizing and interface rules to the system.

It is a further object of the invention to be easily modified on the fly. Changes can be made by changing dynamically loaded rules, without bringing down the system or recompiling. In the system of the present invention, the logic is separate from the application and held in dynamically loaded rules, and each bit of logic can be separated into separate rules. The above if-then-else logic example can produce three separate rules : Rule 1: if x == y then k; Rule 2: if x == z then j; Rule 3: if x == a then h. Each rules acts on an item in order. If a rule does not apply, the next rule is applied. Rules are only loaded as needed. To change Rule 1 to "if x == y then 1" simply change Rule 1. This on the fly changeability is extremely useful in systems with complex constructs that would otherwise need to be recompiled when the internal logic is changed.

It is a further object of the invention to be scalable. The system of the present invention addresses scalability through the divide and conquer approach. Each process has multiple instances running on multiple physical machines. For example, rather than one big queue processor processing one big queue, the system of the invention has multiple queues and multiple processors. In addition, new processes are easily added on new machines with no performance loss or need to pull down the existing system. Multiple instances and machines solve bottleneck issues. Also, should one machine or process crash, others are available to continue processing.

In one embodiment, the system of the invention is part of an automated organizational or management application for groups of users accessible via any Internet application, such as the World Wide Web (web) or email. This automated group management application is described in Fisher, et al . , "Method and System for Utilizing Internet Email Communications for Group Collaboration", U.S. Provisional Application No. 60/185719, filed February 29, 2000, previously incorporated herein by reference. The group management of that invention is an expert messaging service that interprets messages and takes certain actions for users, and interacts with third-party applications to support real-time and cross-company collaboration. In particular, the request processing system of the present invention processes incoming and outgoing email, and achieves intelligent message handling. The system can store- messages and files, and turn static messages into dynamic commands . A user can ask the system to email a file by sending the system an email message requesting that file. In addition, the intelligent message handling of the invention can be provided through interfaces other than email, such as, for example, the web.

The system of the present invention is not limited to this particular application, however, but can also be used in, for example, a transactional purchase order processing application that enable consumers to purchase items over the telephone or the World Wide Web. Because consumers would expect quick turn around for their orders, the synchronous request processing embodiment of the invention would be used for this application. For synchronous request, the scheduler is not used. Instead, a queue processor is executed by whatever process added the request to the queue .

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 depicts a functional block diagram of the components of the system of the present invention.

FIG. 2 depicts a flow chart of how messages are added to the queue for processing.

FIG. 3 depicts a functional block diagram of a scheduler subsystem according to the present invention.

FIG. 4 depicts a functional block diagram of the queue processor subsystem according to the present invention. FIG. 5 depicts a flow chart of how queue items are processed by the queue processor of the present invention.

FIG. 6 depicts a functional block diagram of a volume manager according to the present invention. FIG. 7 depicts a flow chart of how rules process queue items .

BEST MODE FOR CARRYING OUT THE INVENTION The request processing system of the present invention includes several acting components, which can be independently compiled processes or threads, and various library components, referred to as frameworks. In one embodiment, the system receives all requests from an outside party through a request server, and all messages sent from the system to an outside third party are sent through the request server. For example, the request server can be an email server such as Sendmail, however, the invention is not limited to that embodiment and the request server could also be, for example, another email server, a fax server, a voicemail server, or a web server.

An acting component performs a specific function. In a preferred embodiment, an acting component is a single executable originally written in Java that runs in its own Java Virtual Machine. In other embodiments the functionality of an acting component can be handled by other system components provided the acting component code runs in its own thread. In the embodiment in which the asynchronous processing system of the invention is part of a group management application, the system includes the following acting components: (1) a delivery agent; (2) a scheduler; and (3) one or more queue processors. More or fewer acting components are, of course, possible, depending upon the embodiment.

A framework is a collection of code objects that can be dynamically loaded and shared by different processes. They provide information and instructions for the acting components. In one preferred embodiment of the invention, a framework is a collection of Java classes. Frameworks provide the system with, inter aliai classes for queues, queue items, and rules. A block diagram of the various acting components and frameworks of the embodiment of the invention that processes asynchronous requests such as email is presented in FIG. 1. When request server 100 receives a request, server 100 launches and executes a delivery agent 110. Delivery agent 110 obtains from a framework 150 the proper queue 120 in which to place the request and signals scheduler 130 that a request item is in queue 120. Scheduler 130 matches a queue processor 140 to queue 120 to process the item. Queue processor 140 obtains from a rule finder 160 in frameworks 150 a set of rules for processing the item in queue 120.

The Delivery Agent The function of delivery agent 110 is illustrated as a flow chart in FIG. 2. Agent 110 is started by server 100 and receives the request from server 100 at step 210 of FIG. 2. Agent 110, at step 220, queries the frameworks 150 to determine which queue 120 in which the request should be placed. Agent 110 then adds the request to the appropriate queue 120 at step 230. The process of adding a request to a queue turns the request into an object in the queue referred to as a queue item. Agent 110 informs the scheduler 130 at step 240 that an item has been added to a specific queue 120. The delivery agent 110 then terminates at step 250.

Queues

Queue 120 holds items that need to be processed. Items are added to queue 120 and remain there until queue processor 140 processes them. The items are processed in the order they entered the queue. Each queue item is processed independently of each other item in the queue. In addition to delivery agent 110, items are added to queues through rules 160 or other system parts.

This invention generally involves multiple queues. Each queue 120 is mapped to an addressable entity. An addressable entity is anything that has a unique name or address, for example, an email address or phone number. This entity could be more abstract and involve an address for a transaction. For example, in an embodiment of the invention that processes customer order requests, a queue can correspond to the item being purchased. Requests are generally destined for an addressable entity.

In one application, the invention is used to handle email processing for a group management application. In a preferred embodiment of this application, each group has it's own email address. Each queue 120 maps to one group. Email comes into the system addressed to the group and delivery agent 110 finds queue 120 for the address and hence the group. In an alternative embodiment of the group management application, each group has two queues, one for input and one for output . However both queues map to the same address . Which queue the item is added to is determined by the process adding the item, and certain logic in the process .

In a preferred embodiment, each queue is an instance of a class in the framework 150 that has methods, variables, and a persistent representation.

Queue Items

A queue item is an object and therefore has a class, methods, variables, and can interact with other objects. When an item is added to queue 120, it becomes a queue item. A queue item can be the actual data of the item, or it can merely represent the item. The latter representation can be used if the data associated with an item is be especially large, in which case the data can be stored in either a file system or a database. In this case, a file referencing the data is created and placed in queue 120. This file then constitutes the queue item, and contains no information regarding the content of the data. In one embodiment, the queue item reference is persistently stored as an XML representation created by the delivery agent 110. The Scheduler

FIG. 3 depicts the functional relationship of scheduler 130, a pool of queue processors 340 and a set of queues 320. Each pool of queue processors 340 contains a plurality of queue processors 140 and each set of queues 320 contains a plurality of queues. Scheduler 130 is an acting component that keeps track of which queues need processing, and matches a queue 120 from set 320 to a queue processor 140 from pool 340. There is only one scheduler for each set of queues, referred to as a volume, and that scheduler is always running. When scheduler 130 learns that queue 120 has items in it, it executes available queue processor 140 to process that queue 120. Scheduler 130 can learn that an item is in a queue either from delivery agent 110 or a rule or other framework object that added the item.

There are also situations when an item is added to a queue without scheduler 130 being informed. A part of the scheduler referred to as a sweeper 330 looks at every queue in volume 320 and tells scheduler 130 which queues contain queue items. Sweeper 330 executes when scheduler 130 is started and then periodically thereafter. In one embodiment, sweeper 330 runs every six hours.

Note that the scheduler is used when the invention is processing asynchronous requests, such as email. It is not used for processing synchronous requests, such as requests from a website.

Queue Processors

Queue processor 140 is an acting component that processes each item in a queue. The invention includes multiple instances (identical copies) of this program or thread. Scheduler 130 selects an available processor 140 from pool 340, specifies which queue to process, and executes processor 140 to process queue 120. At any one time, there can be many queue processors running, or there can be none running at all. There is a limit, however, to how many queue processors can run at the same time. Scheduler 130 keeps track of how many queue processors 140 are running to manage when the queues 120 get processed. The queue processor's primary purpose is to evaluate a queue item and feed it to an ordered set of rules provided by a rule finder. The actual processing is determined by the rules, as discussed below.

A block diagram depicting the functional relationship of the queue processor is depicted in FIG. 4, while a flow chart of the method of one embodiment of the queue processor is depicted in FIG. 5. Queue processor 140, at step 510, first determines if queue 120 contains any queue items 1200. If processor 140 determines queue 120 to be non-empty at step 520, queue processor 140 reads first item 1201 from queue 120 at step 530. Queue processor 140 then evaluates item 1201 to determine information such as class at step 540.

Processor 140 then passes the information about item 1201 to rule finder 160. This information can include the class of item 1201 and the name of queue 120 that item 1201 is in. Rule finder 160 uses this information to choose a list of ordered rules for processing item 1201. In a preferred embodiment, rule finder 160 is a class located in the framework 150. The rule finder 160 generates the rule list 163 using other classes and the database. Once rule finder 160 has generated list of rules 163, the list 163 is returned to queue processor 140 at step 555.

Queue processor 140 then feeds item 1201 to first rule 163.1 at step 560. Rule 163.1 either consumes the item or returns it to queue processor 140 at step 570 to be fed to another rule. Processor 140 repeats steps 560 and 570, feeding item 1201 to each subsequent rule, which either consumes or returns the item, until the item is consumed. When the item has been consumed, processor 140 moves on to the next item in queue 120, repeating steps 510 through 570 until queue 120 is empty. When queue 120 is empty, processor 140 informs scheduler 130 at step 590 and then closes .

The queue processor functions independently of how the rule list is generated. It simply asks for a rule list by passing information to the rule finder. When it receives the list, it passes the queue item to each rule until the item is consumed. Rules then process the queue item based on their content .

A variation on the above approach could involve having processor 140 move on to another queue 120, when the first queue 120 is empty. Although processor 140 is designed to process a specific queue 120, processor 140 could process multiple queues that are grouped together. For example, in an embodiment where the invention is used to process requests for a group management application, a group could have multiple queues. It could be useful for a group to have an incoming queue for input and an outgoing queue for output. Processor 140 would first process each item in the input queue. When the last item in the input queue is consumed, the same instance of the processor processes the output queue. When output queue is empty, queue processor 140 signals scheduler 130 at step 590 and terminates. After processing the output queue, queue processor 140 does not recheck the input queue to see if additional items have been added. Queue processor 140 completely processes the input queue, moves on the completely process the output queue, and terminates. If processor 140 finds an empty input queue, it processes the output queue and terminates. If, after processing the input queue, processor 140 finds the output queue to be empty, processor 140 terminates.

Rules

A rule is a piece of logic that processes items passed to it by queue processor 140. Rules are classified by order, class name, and context. Order specifies where in a list of rules a rule appears. The class name specifies the class of items to which a rule applies. The context specifies conditions that must be met for a rule to apply. For example, a context could be the name of a queue an item is taken from.

The rule finder generates a list of rules by collecting rules based on their class name and context. It then orders the rules based on their order. The rule finder then returns this list to the queue processor. The queue processor processes the queue item according to rules on the list. Each rule processes the item until the item is consumed. One embodiment of the invention includes rules for processing email, while other embodiments include rules for processing transactions and to communicate with other systems .

In a preferred embodiment, a rule is implemented as two classes. One class holds attributes that are used by the rule finder when it searches for rules, while the second holds the actual logic used for processing. In this embodiment, the first class includes five attributes: (1) ordering; (2) class name; (3) context; (4) status; and (5) a pointer to the logic class. The order attribute specifies where in the list of rules this rule goes. A rule with order number 12 comes after a rule with order number 11 and before a rule numbered 13. If there is no rule number 11, rule number 12 succeeds rule number 10. The class name specifies which item classes, e.g. email or fax, the rule applies to. The context specifies which queue an item must be taken from for a rule to apply. The status is for internal use, for example to deactivate a rule for testing. The pointer to the logic class points to the second rule class that contains the processing logic. Breaking the rule into two classes achieves faster searching of the first class and dynamic loading of the second class, and enables changing the second class without changing the first class .

In one preferred embodiment, the system is used to handle asynchronous requests for a group management application. In this situation queue 120 corresponds to a specific group. An item in a queue could be an email request. When the rule finder 160 is told the class of the 5 object and the name of queue 120, it can determine a list of rules 163 specific to email requests made for that group.

Referring now to FIG. 4, the list of rules 163 is given to queue processor 140 and every rule is given a chance to 0 process queue item 1201 until item 1201 is consumed.

Although every rule on list 163 gets queue item 1201 (until item 1201 is consumed) , in some cases not all of the rules operate on the item 1201. If an unnecessary rule on list 163 determines that it does not wish to operate on item 5 1201, the next rule on the list 163 is fed to item 1201. In some cases, the same list of rules 163 is used for different queue items, but only some of the rules will apply to a certain item.

o The process by which the queue processor and rules act on a queue item is depicted in FIG. 7. First, at step 700, the queue processor feeds the queue item to a rule. Second, at step 710, the rule determines if it wants to operate on the queue item. Although potentially every rule on the list 5 gets the queue item, in some cases only some of the rules operate on it. If the rule does not want to operate on the item, the rule returns the item to the processor at step 720. The processor then feeds the item to the next rule on the list. Third, if the rule wants to operate on the item, ₀ it performs one or more actions on that item at step 730. A rule knows nothing about other rules: it only knows its specific tasks. After the rule operates, the item is either consumed at step 740 or returned to the queue processor at step 720 to be fed to the next rule. Eventually a rule on 5 the list consumes the item.

Since the item is always consumed by a rule on the list, no queue item can be placed back in the queue once it has been removed from the queue. There are situations, however, when a rule modifies an item and wants the item to be accessed by either rules earlier on the list or rules on a different list. If the item was consumed, the rule determines at step 750 if the item needs additional processing. Thus, one or more new queue items are created at step 760 and placed in the queue at step 770. Sometimes the new queue item is identical to the consumed item, while in other cases the consumed queue item is broken into several new queue items. These items are each independently placed on the queue at step 770 to be processed as separate entities. Eventually the queue processor will process these new items in the same manner as the previous items . Note that a rule can also add the one or more newly queue items to different queues.

Rules can potentially perform any action. In one embodiment of the invention, in which the system of the present invention processes asynchronous requests for a group management application, server 100 is an email server. This embodiment includes five types of rules for incoming messages. (1) Gatekeeper rules: these rules accept or reject messages. There are several reasons for doing so. For example, only group members can send messages to a group's email address. A gatekeeper rule checks the From line of an incoming message and rejects the message if it is not from a valid sender. In addition, a gatekeeper rule could also reject a message because of file size or the type of attachment. (2) Error/Warning/System rules: these rules determine whether the message is a request to add a message/file to a group, or a request for a command action. For example, most messages sent to a group are merely requests to add that message to the group. However, some messages are commands for other actions, such as a request for a file. These two types of messages need to be handles differently. (3) Command Message rules: these rules handle messages that are requests for command actions. They interface with the other frameworks of the invention to issue commands. For example, the system allows users to request a group's file by sending a message. These rules determine how that request will work. (4) Chopper rules: these rules deal with messages with attachments . A chopper rule breaks a message and its attachments apart into separate entities. Consider, for example, a message received with three file attachments, a .DOC file, a .PPT file, and an .XLS file. The chopper rule creates four separate objects: the message itself, the .DOC file, the .PPT file and the .XLS file. (5) Filer rules: these rules determine what to do with a message or file. In the group management application, files and messages sent to a group are organized into user defined folders. The filer rules look at the subject line of an incoming message and automatically determine a folder fort he message of file.

These rule types are specific to this email processor embodiment . The invention is not limited to this set of rule type, however. More or fewer types of rules can be defined as needed for particular types of items or queues. If the queue being processed is an output queue, for example, one type of rule can send the queue item to the email server 100.

Email request processing is not the only embodiment of the invention. Anything can add an item to input queue 120. In order to interface with another server, delivery agent 110 is replaced with an acting component appropriate for that interface, and the rules for email are replace with rules appropriate for the new server. For example, server 100 could be a fax server, in which case agent 110 is adapted to receiving fax messages and adding them to queue 120. Queue processor 140 processes queue item 1201 using rules created for fax messages.

Scalability A feature of the invention is scalability, that is, the ability to grow with increased demand for services. Scheduler 130 provides a key to scalability. As the system receives more requests to process, if there was only one queue processor to do the processing, a bottleneck would result. This situation is avoided by the ability to run many queue processors simultaneously, managed by scheduler 130, since any queue processor can process any queue.

To further improve scalability, the system is broken into volumes. Rather than one huge system with a single scheduler to manage the queues and queue processors, the system is segmented into different volumes. This segmentation is depicted in FIG. 6. Each volume 610 has its own scheduler 130 that manages a set number of queue processors 240 and queues 220. This removes the bottleneck caused by having only one scheduler 130 and allows the system to grow with the number of queues and requests. The size of the volume can be either a fixed number of queues or a number determined by usage patterns . A volume manager entity 600 provided by the framework manages the volumes 610. In a preferred embodiment, the volume manager is a Java class .

Synchronous Requests

The system of the invention can also process synchronous requests. The difference between the synchronous embodiment of the invention and the asynchronous embodiment is that the synchronous embodiment does not use the scheduler. Instead, the process responsible for placing an object in a queue is responsible for matching a queue processor to that queue.

An example of an embodiment that processes synchronous request is an Internet based transactional purchase ordering processing system. In this embodiment, the server could be a web server. The delivery agent takes order information from an HTML form and creates an order object and places the order object in a queue. The delivery agent invokes a queue processor to process the items in the queue. Each customer of the purchase processing system could be associated with a different queue. The queue processor evaluates an item and asks the rule finder for rules to process the item. The queue processor receives the list of rules and feeds the item to each rule as before.

The synchronous embodiment uses the queue items and dynamically loadable rules of the asynchronous embodiment of the invention, however, the classes of the queue item and the contents of the rules differ. For example, the purchase processing system includes the following rules for processing order items. (1) Ask the credit card validation software to process the item. If the transaction is denied, return an error code to the queue processor. An internal reporting object is created and placed in a queue for asynchronous processing, and the item is consumed. If the transaction is approved, continue to the next item. (2) Create a shipping object and place it in a queue for asynchronous processing. (3) Create an invoice object and place it in a queue for asynchronous processing. (4) Create an internal reporting object and place it in a queue for asynchronous processing. (5) Return a success code to the queue processor and consume the item.

As seen from the above example, the transactional purchase order processing application processes some requests asynchronously. For those requests, it uses the asynchronous embodiment of the invention.

In a preferred embodiment of the invention, the system of the invention is written in Java. Queues are instances of a class in the framework, while rules are instances of two classes in the frameworks. The invention is not limited to this embodiment, however, and may be implemented in any other suitable computer language .

The system of the invention is not limited to the embodiments disclosed herein. It will be immediately apparent to those skilled in the art that variations and modifications to the disclosed embodiment are possible without departing from the spirit and scope of the present invention. The invention is defined by the appended claims.

Claims

WE CLAIM:

1. A software system for processing requests, comprising: a queue item object representing a request in need of processing; one or more queues adapted to contain one or more queue items; one or more queue processors; and one or more rules adapted to process the queue item; wherein a queue processor takes the queue item object from a queue and applies the one or more rules to the queue item until the queue item is fully processed.

2. The system of claim 1, further comprising an agent for transferring a request from an incoming request server to the queue, thereby converting the request into the queue item.

3. The system of claim 2, wherein said agent matches a queue processor to the queue.

4. The system of claim 1, further comprising a scheduler that matches a queue processor to a queue.

5. The system of claim 1, wherein the queue item object represents a purchase order transaction.

6. A software system for processing asynchronous requests, comprising: a queue item object representing a request in need of processing; one or more queues adapted to contain one or more queue items ; one or more queue processors; and a scheduler adapted to matching a queue processor to a queue; one or more rules adapted to process the queue item; wherein the queue processor, after being matched to the queue by the scheduler, takes the queue item from the queue and applies the one or more rules to the queue item until the queue item is fully processed.

7. The system of claim 1 or claim 6, further comprising a plurality of lists of the one or more rules .

8. The system of claim 1 or claim 6, further comprising a rule finder that finds one or more rules

5 suitable to process the queue item object based on criteria comprising the class of the queue item object and the queue in which said object is placed, and supplies the one or more rules to the queue processor.

9. The system of claim 1 or claim 6, wherein each of ₀ the one or more rules either consumes the queue item object to which the rule is applied, or returns the queue item object to the queue processor for further processing.

10. The system of claim 1 or claim 6, wherein the one 5 or more rules are dynamically loadable.

11. The system of claim 1 or claim 6, wherein, after consuming a queue item object, a rule creates one or more new queue item objects and places said one or more queue item objects in a queue. o

12. The system of claim 6, further comprising an agent for transferring a request from an incoming request server to the queue, thereby converting the request into the queue item, and for signaling the scheduler that the queue contains the queue item in need of processing. 5

13. The system of claim 6, wherein the requests are email messages.

14. The system of claim 6, wherein the requests are facsimile messages.

15. The system of claim 6, wherein the requests are ₀ voicemail messages.

16 The system of claim 6, wherein the scheduler comprises a sweeper that periodically examines the one or more queues to determine which of said one or more queues contain queue item objects in need of processing by a queue 5 processor.

17. A method of processing requests, comprising the steps of : placing a request in a queue, whereby the request becomes a queue item object; dynamically loading one or more rules to process the queue item object; and obtaining the queue item from the queue and applying to the queue item the one or more rules until the queue item is processed.

18. The method of claim 17, further comprising the step of matching a queue processor adapted to obtaining the queue item from the queue to a queue, and adapted to applying the one or more rules to the queue item.

19 The method of claim 17, further comprising the step of determining which of the one or more rules to apply to the queue item object.

20. The method of claim 19, whereby the step of determining which of said one or more rules to apply to said queue item object is based on criteria comprising the class of the queue item object and the queue in which said item is placed.

21. The method of claim 17, further comprising the step of periodically examining the queue to determine whether said queue contains a queue item object in need of processing.