Polling adapter providing high performance event delivery

An apparatus and method for improving event delivery efficiency in a polling adapter system is configured to poll an enterprise information system (EIS) to obtain a list of events occurring in the EIS. Each event may be associated with an object key. These events may then be allocated to multiple delivery lists wherein events associated with the same object key are allocated to the same delivery list. Multiple delivery threads may then be generated, with each delivery thread being associated with a delivery list. Each delivery thread is configured to retrieve, from the EIS, events listed in the delivery list associated with the thread and deliver the events to a client.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to enterprise application integration and more particularly to apparatus and methods for improving event delivery performance in polling adapters.

2. Description of the Related Art

Adapters allow business events to flow from an Enterprise Information System (EIS) to a listening client such as a business process or other application. The Java 2 Enterprise Edition (J2EE) standard defines a standard approach to building these adapters. This approach is outlined in the J2EE Connector Architecture (JCA) specification.

The flow of information from an EIS to a client system is commonly referred to as “inbound communication.” Often, the EIS is not configured to communicate directly with the adapter. As a result, the adapter may be configured to periodically poll the EIS for new information. In many cases, a “trigger” may be put in place in the EIS system, which may be configured to write “event records” into an “event table” when data has changed in the EIS. The adapter may then poll this event table to obtain a list of changed objects, including the types of objects and their keys. The adapter may then use this information to retrieve the entire event from the EIS system, send it to the client system, and delete the event from the event table, often within the context of a transaction.

A client system may often require that events be received and processed in a certain order. Specifically, for a given object key, events related to that object key may need to be received and processed in sequence. This may be important in data synchronization scenarios because if, for example, a CREATE operation for an object occurred prior to an UPDATE operation on the same object in an EIS, the CREATE operation would also need to occur prior to the UPDATE operation in the downstream client system. If the two operations were reversed, the synchronization process between the EIS and client system would fail.

An adapter will ideally deliver events to a client as fast as possible, while ensuring that events for the same object are processed in the correct order. Some intelligence in the adapter is necessary to make this happen. In the past, many polling adapters had two modes of operation: ORDERED and UNORDERED. The ORDERED mode would address the ordering requirement by placing all polling or event delivery logic on a single thread of execution. By contrast, the UNORDERED mode would utilize multiple threads of execution (up to one per event in the poll cycle) but could not guarantee a specific order. Additionally, because only one connection to the EIS was defined, the multiple threads of execution in UNORDERED mode would contend for the connection. To prevent some of this contention, the “delete” operation in the event table would be delayed until all delivery threads finished executing.

In view of the foregoing, what is needed is a polling adapter that can guarantee the related events are delivered in order, while allowing unrelated events to be delivered in any order. Ideally, such a polling adapter could accomplish these goals while delivering events to a client in a fast and efficient manner.

SUMMARY OF THE INVENTION

The present invention has been developed in response to the present state of the art, and in particular, in response to the problems and needs in the art that have not yet been fully solved by currently available polling adapters. Accordingly, the present invention has been developed to provide a polling adapter that can deliver related events in order, deliver unrelated events in any order, while still ensuring that events are delivered to a client system in a fast and efficient manner.

In a first aspect of the invention, a method for improving event delivery efficiency in a polling adapter may include polling an enterprise information system (EIS) to obtain a list of events occurring in the EIS. Each event may be associated with an object key. These events may be allocated to multiple delivery lists wherein events associated with the same object key are allocated to the same delivery list. The method may then include generating multiple delivery threads, wherein each delivery thread is associated with a delivery list. Each delivery thread is configured to retrieve, from the EIS, events listed in the delivery list and deliver the events to a client system.

In selected embodiments, the method may further include designating an order for each event in a delivery list that is associated with the same object key. The method may further include executing each delivery thread over a separate connection with the EIS.

In another aspect of the invention, an apparatus for improving event delivery efficiency in a polling adapter may include a polling module to poll an enterprise information system (EIS) in order to obtain a list of events occurring in the EIS. Each event may have an object key associated therewith. A delivery list generation module may be provided to allocate the events to multiple delivery lists, wherein events associated with the same object key are allocated to the same delivery list. A thread generation module may be provided to generate multiple delivery threads, wherein each delivery thread is associated with a delivery list. Each delivery thread is configured to retrieve, from the EIS, events listed in the delivery list and deliver the events to a client.

In selected embodiments, the apparatus may further include a sequencing module to designate an order for executing each event associated with the same object key. The apparatus may also include a connection pool module to provide multiple connections to the EIS. This may allow threads to be executed concurrently over separate connections with the EIS.

The present invention provides an improved polling adapter that provides high performance event delivery. The features and advantages of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter.

DETAILED DESCRIPTION OF THE INVENTION

Reference throughout this specification to “one embodiment,” “an embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, specific details may be provided, such as examples of programming, software modules, user selections, or the like, to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods or components. In other instances, well-known structures, or operations are not shown or described in detail to avoid obscuring aspects of the invention.

The illustrated embodiments of the invention will be best understood by reference to the drawings, wherein like parts are designated by like numerals throughout. The following description is intended only by way of example, and simply illustrates certain selected embodiments of apparatus and methods that are consistent with the invention as claimed herein.

Referring toFIG. 1, an adapter100in accordance with the invention may enable business events to flow from an Enterprise Information System (EIS)102to a listening client104such as a business process or application. The flow of information from the EIS102to the client system104may be referred to as “inbound communication”106whereas the flow of information from the client system104to the EIS102may be referred to as “outbound communication”108. As mentioned, a trigger may be put in place in the EIS102to write event records to an event table110when data has changed in the EIS102. The adapter100may periodically poll the EIS102for new information in the event table110.

Referring toFIG. 2, in selected embodiments, an improved adapter100, or apparatus100, in accordance with the invention may be configured to support a new mode of operation (e.g., ORDERED_BY_KEY) not supported by conventional adapters. This mode may be used to deliver related events in order, unrelated events in any order, while still providing efficient event delivery to a client system104. Such an adapter100may, in selected embodiments, include a polling module200, an event list generation module202, a delivery list generation module204, a thread generation module206, and a connection pool module208.

A polling module200in accordance with the invention may be configured to periodically poll the EIS event table110for new events which have occurred since the last poll cycle. The event table110may store a status associated with each event, and this status may indicate whether an event has been previously delivered to a client system104. Using this status information, an event list generation module202may create a list of new events that have occurred since the last poll cycle and that need to be delivered to a client system104. In selected embodiments, these events may reference objects changed in the EIS102, as well as the object types and keys.

Once the event list is generated, a delivery list generation module204may generate multiple delivery lists and assign the events to one of the delivery lists. An allocation module210may assign events associated with same object key to the same delivery list and ensure that roughly the same number of events is assigned to each delivery list. The logic needed to accomplish this task will be explained in more detail in association withFIG. 4. A sequencing module212may order the events within each delivery list so that events associated with the same object key are delivered to the client system104in the correct order. The allocation module210and sequencing module212together may ensure that related events are processed in order, while allowing unrelated events to be processed in any order.

A thread generation module206may generate a delivery thread, for execution by the adapter100, associated with each delivery list. For each thread, an event retrieval module214may retrieve the full event from the EIS102for each event in the delivery list associated with the thread. An event delivery module216may deliver each event in the delivery list to the client system104(possibly in a transaction) in the order specified in the delivery list. Once delivery is complete, an event deletion module218may delete the events from the event table110.

A connection pool module208may be used to provide multiple connections to the EIS102. Ideally, each thread generated by the thread generation module206will be executed over a different connection with the EIS102. This allows multiple threads to execute concurrently, reduces contention for connections, and allows events to be delivered to a client system104in a more efficient manner. In selected embodiments, the delivery list generation module204is configured to generate only as many delivery lists as there are available connections, ensuring that each deliver list, and thus each thread, utilizes a different connection. ensure

Referring toFIG. 3, one embodiment of a method300implementable by the adapter100is illustrated. As shown, after recovering from any previous failures (e.g., failed transactions, etc.), a method300may initially acquire302a connection from the connection pool and retrieve304, over the connection, a list of events from the EIS102. The connection may then be returned306to the connection pool. Once the list of events is obtained, multiple delivery lists may be created308. Ideally, one delivery list is created for each available connection in the connection pool, with each delivery list containing a roughly equal number of events. One example of a method for creating and allocating events to the delivery lists will be described in association withFIG. 4.

Once the delivery lists have been generated, a delivery thread may be generated310and initiated310for each delivery list. At this point in the method300, steps310-322may execute for each thread, as indicated by the diverging paths of the method300. As shown, each thread may acquire312a connection from the connection pool. For each event in a thread's delivery list, the thread may retrieve314the full event (i.e., object) from the EIS102, deliver316the event to the client system104, mark318the event as “delivered” in the event table110, and delete320the event from the event table110. Performance may be improved by allowing event table deletes to occur on a delivery thread. Furthermore, this may be useful in establishing a “threadsafe” connection by allowing the adapter100to delete events on the delivery thread even when there is no connection pool. This may be useful for adapters where the concept of a “connection” to the event table110is not applicable, or there is the possibility of only one connection, and it can handle calls on multiple threads.

Each of the steps314-320may be performed for each event in the thread's delivery list. The thread may then return322the connection to the connection pool and wait324, at a synchronization point324, for other delivery threads to finish executing. After all threads have finished executing, the method300may wait a specified period before beginning the next poll cycle.

Referring toFIG. 4, in one embodiment, a method400for creating and populating the delivery lists may include initially receiving402an event list and entering404each event in the event list into a hashtable, keyed by object key, to be used for later retrieval. If multiple events have the same object key, then the hashtable entry may be converted406to a list containing all events with the same object key.

If, at a decision step408, the number of hashtable entries (or lists) is less than or equal to the number of connections available, then the method400may create410a delivery list for each entry (or list) in the hashtable. Thus, a delivery list will be created for each object key in the hashtable. Events having the same object key will be assigned to the same delivery list.

Conversely, if the number of hashtable entries (or lists) is greater than the number of connections that are available, then the hashtable entries (or lists) may be consolidated to ensure that the number of delivery lists does not exceed the number of available connections. In this case, the method400may create412an array of delivery lists equal to the number (“N”) of available connections. The method400may then populate414the delivery lists with the first “N” entries (or lists) of events in the hashtable. Because the number of entries (lists) is greater than the number of delivery lists, the remaining entries (lists) may be distributed among the delivery lists in a way that distributes the work as evenly as possible. In general, the shortest delivery lists should receive the remaining entries (lists) to ensure that the delivery lists contain a roughly equal number of entries, or are equalized as much as possible.

In one embodiment, if the number of hashtable entries (or lists) is greater than the number of connections available, the method may include taking416the remaining entries and placing each entry in the delivery list where the new delivery list size will be less than the mean size of all the delivery lists. In this way, the length of the delivery lists will be equalized as much as possible. Because the threads (each containing a delivery list) may be executed concurrently over separate connections with the EIS102, this will distribute the load roughly evenly across each thread (and thus across each connection) to efficiently utilize resources.