|Publication number||US7386857 B2|
|Application number||US 10/245,131|
|Publication date||Jun 10, 2008|
|Filing date||Sep 17, 2002|
|Priority date||Sep 17, 2002|
|Also published as||US7900210, US8010972, US20040055002, US20080052726, US20080104619|
|Publication number||10245131, 245131, US 7386857 B2, US 7386857B2, US-B2-7386857, US7386857 B2, US7386857B2|
|Original Assignee||International Business Machines Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (10), Non-Patent Citations (3), Referenced by (4), Classifications (14), Legal Events (6)|
|External Links: USPTO, USPTO Assignment, Espacenet|
1. Field of the Invention
The invention relates generally to information processing and more particularly to enterprise application integration systems having connectors providing an interface with a like number of application programs.
2. Description of the Background Art
Enterprise Application Integration (EAI) systems are those that allow a company's internal enterprise applications to operate together. EAI vendors offer a variety of products ranging from a low-level transport technology that must be heavily customized to meet a customer's needs, to integration-specific software tools that help build custom solutions, and to more complete, product-based integration solutions.
EAI systems can be broadly classified under point-to-point systems and hub & spoke systems. A traditional point-to-point integration scheme 100 comprises dedicated custom connectors 101 from each application system pair 102 as depicted in
The integration hub 201 typically contains: a generic business object model, a transformation engine that maps all application specific business objects to the generic form and vice versa during the integration process and, a collaboration engine that executes any business process logic that is part of the integration synchronization process.
Whenever a new application needs to be integrated, only a single new connector needs to be added in such a scheme. Since EAI systems are usually poised in the heart of an enterprise's information system, their performance and scalability become critically important.
Although there is no current industry standard benchmark metric (such as the industry standard OLTP benchmark TPC-C (an On Line Transaction Processing benchmark, see http://www.tpc.org/tpcc/ for more details) for measuring the performance of an integration system, the performance of integration systems typically can be measured using two broad metrics:
For point-to-point EAI systems, typical scaling solutions involve the manual addition of extra processing spokes (application connectors), each of which unnecessarily complicates management and administration of the overall integration solution. On the other hand, while most hub and spoke EAI systems are fairly well geared in scaling for the integration hub, not much has been done to address the scalability of the spokes (application connectors).
Although there is no current industry standard benchmark metric (such as the industry standard OLTP benchmark TPC-C for measuring the performance of an integration system, the performance of integration systems typically can be measured using two broad metrics:
Thus, a single synchronization point in the application connector that serializes all calls to the application, whether for a synchronous event delivery or for synchronous requests, becomes the crux of a performance bottleneck in most application connectors. In other words, in spite of multiple requests coming into the application connector at any point in time, they are all sequentially executed on their entry into the application. This dramatically affects the overall throughput of the system and the latency of individual requests. With the advent of the web-enabled user-interfaces, the need for quicker response times becomes even more critical to an end-user. Most connector architectures do not cater to this need.
For connectors of applications that have thread-safe APIs, there are no inherent scalability problems, since the underlying connector can be multi-threaded and concurrent connections to the underlying applications can be made. However, most APIs are not thread-safe and some applications do not even allow more than one connection from the same process.
With the advent of the support for call-triggered requests in the e-business arena, the need for quicker response times becomes even more critical. This current connector agent model 300 will obviously not scale, especially if: a high volume of incoming requests comes into the agent; a barrage of application events are generated within a short amount of time; or, both of the above happen concurrently.
Thus, there are two issues that are of critical concern to an end-user: the latency of individual synchronous requests to an EAI system and the need to maximize throughput of the overall event flow through the system. Most API libraries are unable to adequately address these problems because 1) they lack thread-safety, which precludes the use of multi-threading in the application connector and 2) they lack re-entrance within the same process, which sometimes restricts application connectors to a single connection, session or activity in the application. There is thus a need for solutions to the shortcomings discussed above.
The invention concerns a new approach in overcoming the scalability limitations of application connectivity in EAI systems. Briefly, according to the invention, a method for responding to requests for processing made by an integration broker to an application having a single threaded application programmer interface (API), comprises spawning multiple connector processes (one master and at least one multiple slave processes); receiving a request for processing; determining the type of request; and, sending the request to a connector slave process assigned to that type of request.
In order to solve the scalability limitations discussed above, an application integration system described herein adopts a variant of the concept of server classes used by most Transaction Processing monitors (TP monitors) referred to herein as resource classes. An idea behind the concept of resource classes is to dedicate a pool of application connector processes, each of which has a devoted connection to the underlying application, for a given class of requests. This approach of having dedicated resources to handle different types of requests has the following advantages: 1) it is a tried and tested approach (as used in TP monitors); 2) it is easy to implement and maintain; and 3) it comes close to guaranteeing the prevention of starvation of any given type of request.
In a typical EAI environment, there are two primary types of requests:
It is desirable to minimize the average latency for call-triggered requests, while at the same time ensuring acceptable average latency for event-triggered requests and achieving optimal throughput for the overall system. Therefore, a separate resource class is dedicated to handle each type of request. In order to be able to distinguish between each type of request, each request is tagged as either an event-triggered request or a call-triggered request in the integration hub before it flows into the application connector process. The invention is applicable to both hub & spoke and point-to-point integration architectures. However, for the sake of simplicity, the preferred embodiment detailed here is based on a hub & spoke EAI system.
The connector master process 404 comprises a listener 410 for accepting requests from the integration hub 402, a request dispatcher 412 for dispatching requests to a resource class request queue 414 based on the tag included in the request, and a resource cache 418 comprising a plurality of resource class pools and slave coordinators (slave pools) 416 for handling the received requests. The queues are dynamic data structures and their sizes will be limited only by available memory. The connector 404 may also comprise a plurality of connector slave processes 422 for processing the requests. These connector slave processes 422 can all belong to the shared resource cache 418, so that in order to optimize the utilization of resources, and hence avoid any waste, slave processes 422 can be scavenged from different pools 416 in case of a shortage in that pool. If no slaves are available in one resource pool, then a scavenge operation is attempted to obtain a slave from another pool and if that fails, the request waits until one becomes available. It is important to note that the master and slave processes will preferably operate within the same physical machine
In step 808 the slave connectors spawned in step 804 are booted up. The metadata from these slave connectors is synced with the master. Then in step 812 a decision must be made to determine if the slaves' boot-up is complete. If the boot-up is determined to be complete in step 814, the process is ended. Else, if the boot-up is not complete, a decision is made in step 806 to determine if the retries are exhausted. If not, then the boot-up process is re-initiated. If the retries are exhausted, then it is determined that the boot-up has failed in step 810 and the process is ended.
The integration system described herein can be implemented in various embodiments including as a method, a dedicated or programmable data processing apparatus, or a computer program product. While it is understood that parallelism can be achieved using either multiple threads or processes, various approaches for scheduling these parallel entities could potentially be adopted in order to realize our performance requirements for this invention. Therefore, while there has been described what is presently considered to be the preferred embodiment or embodiments, it will be understood by those skilled in the art that other modifications can be made within the spirit of the invention.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5603029 *||Jun 7, 1995||Feb 11, 1997||International Business Machines Corporation||System of assigning work requests based on classifying into an eligible class where the criteria is goal oriented and capacity information is available|
|US5754855 *||May 12, 1997||May 19, 1998||International Business Machines Corporation||System and method for managing control flow of computer programs executing in a computer system|
|US5940075||Sep 30, 1997||Aug 17, 1999||Unisys Corp.||Method for extending the hypertext markup language (HTML) to support enterprise application data binding|
|US6085198||Jun 5, 1998||Jul 4, 2000||Sun Microsystems, Inc.||Integrated three-tier application framework with automated class and table generation|
|US6085217 *||Mar 28, 1997||Jul 4, 2000||International Business Machines Corporation||Method and apparatus for controlling the assignment of units of work to a workload enclave in a client/server system|
|US6105067 *||Jun 5, 1998||Aug 15, 2000||International Business Machines Corp.||Connection pool management for backend servers using common interface|
|US6208345 *||Jun 8, 1998||Mar 27, 2001||Adc Telecommunications, Inc.||Visual data integration system and method|
|US6363421 *||May 31, 1998||Mar 26, 2002||Lucent Technologies, Inc.||Method for computer internet remote management of a telecommunication network element|
|US6718376 *||Dec 15, 1998||Apr 6, 2004||Cisco Technology, Inc.||Managing recovery of service components and notification of service errors and failures|
|US20050114201 *||Aug 20, 2004||May 26, 2005||Technology Center||Method and system for managing a plurality of enterprise business systems|
|1||"Application Connector Parallelism in Enterprise Application Integration (EAI) Systems," Pranta Das, Oct. 14-17, 2001.|
|2||"J2EE(TM) Connector Architecture" Sun Microsystems, Inc. (http://java.sun.com/j2eeconnector/).|
|3||Paper: Java Interoperability with Existing Code, V5R1 Update (IBM, http://www/as400.ibm.com).|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7984188 *||Jul 19, 2011||Sap Ag||System and a method for mediating within a network|
|US9335978 *||Sep 1, 2014||May 10, 2016||International Business Machines Corporation||Computer aided visualization of a business object model lifecycle|
|US20060259605 *||Apr 17, 2006||Nov 16, 2006||Michael Altenhofen||System and a method for mediating within a network|
|US20140372969 *||Sep 1, 2014||Dec 18, 2014||International Business Machines Corporation||Computer aided visualization of a business object model lifecycle|
|U.S. Classification||719/313, 719/320, 709/208|
|International Classification||G06F15/16, G06F9/46, G06F9/50, G06F9/44, G06F3/00, G06F9/00, G06F13/00|
|Cooperative Classification||G06F2209/5011, G06F9/5055, G06F2209/5018|
|Sep 17, 2002||AS||Assignment|
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:DAS, PRANTA;REEL/FRAME:013308/0459
Effective date: 20020917
|Jan 23, 2012||REMI||Maintenance fee reminder mailed|
|Apr 9, 2012||AS||Assignment|
Owner name: FACEBOOK, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INTERNATIONAL BUSINESS MACHINES CORPORATION;REEL/FRAME:028015/0181
Effective date: 20120327
|May 25, 2012||FPAY||Fee payment|
Year of fee payment: 4
|May 25, 2012||SULP||Surcharge for late payment|
|Nov 25, 2015||FPAY||Fee payment|
Year of fee payment: 8