Patent Application
20090198781
1. Field of the Invention
The present invention relates to the field of information services processing and, more particularly, to improving the efficiency of core group message handling for a distributed computing system with a large topology.
2. Description of the Related Art
Communications between peer core groups is critical for providing efficient processing of service requests in a service-oriented architecture (SOA). Since core groups are often used to encapsulate high availability domains, timely message handling is necessary to ensure that service requests are routed to other core groups in the case of service failure or high volume. Typically, a specific service, such as the core group bridge in WEBSPHERE, handles the message traffic between peer core groups.
While this architecture is effective at providing communication pathways between core groups, it can break down as the quantity of core groups and/or servers within the core groups increases into what is known as a large topology. In the case of a large topology, communication pathways can become clogged with the multitude of messages being sent. For example, if ten servers in Core Group A all subscribe to Service A in Core Group B, then ten subscription messages are sent from Core Group A to Core Group B. Core Group B must then process each of those ten messages and provide the necessary post messages back to Core Group A, which is duplicated ten times—once for each requesting server. Thus, as the amount of message traffic increases, consumption of system resources increases and system performance decreases.
Another factor compounding this problem is that the messaging service handles all topologies in the same manner. The efficiency of message handling could be improved by using delivery algorithms that take advantage of topological differences and architectures. For example, a chain topology requires that a message be passed linearly through the chain of core groups, which is not required in a mesh topology.
What is needed is a solution that provides efficient message handling between core groups in large topology distributed computing systems, such as a SOA. That is, the message handler would streamline the messaging processes for system topology and eliminate redundant messaging. Ideally, this solution would automatically determine the system topology and adjust the messaging configuration of the core group bridge accordingly.
There are shown in the drawings, embodiments which are presently preferred, it being understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown.
In large topology systems that generate a high volume of message traffic between peer core groups, the existing message handling by the core group bridge was found to lack an efficiency needed to provide timely transmission and processing for high availability domains. The present invention addresses this issue by modifying the core group bridge to act more like a communications coordinator and less as an open communications gateway.
In system 100, a peer-to-peer relationship can exist between the core groups 105 and 140. That is, neither core group 105 or 140 can have a hierarchically higher or lower relationship to each other. A core group 105 can represent a grouping of servers and/or related software components that provide services in a service-oriented architecture (SOA). The peer relationship between core groups 105 and 140 can allow for a core group to be aware of available services and key events in the other core groups. As such, service requests can be rerouted to servers in other peer core groups should a failure occur or to handle a high request volume.
A core group 105 can transmit a multitude of messages 110 to other core groups, such as core group 140 over a network 130. The messages 110 can include a variety of data, such as subscription messages, post messages, and status messages. Transmission of the messages 110 can be overseen by the core group bridge 115 associated with the core group 105.
The core group bridge 115 can represent a service initiated by the core group 105 to handle messaging to the core group bridge 145 of other peer core groups 140. The core group bridge 115 can include a topology evaluator 123, a message encapsulator 126, and a request coordinator 129.
The topology evaluator 123 can correspond to a software component and/or algorithm designed to determine the topology connecting the core bridge's 115 local core group 105 with its peer core groups 140. Topologies that can be determined by the topology evaluator 123 can include a chain, shown in
Upon determination of the topology, the topology evaluator 123 can set one or more corresponding values in the core group bridge 115 to designate the determined topology. The setting of these values can affect the message delivery behavior of the core group bridge 115. For example, determination of a chain topology can set a data attribute for message forwarding to “yes” or “enable” in order to signify that a message 110 should be forwarded through the chain of core groups.
The message encapsulator 126 can correspond to a software component that envelops a message 110 with an appropriate bridge message wrapper 137, creating an encapsulated message 135. For example, a subscription request message 110 can be encased in a subscription-oriented bridge message wrapper 137. The bridge message wrapper 137 can be a specialized message that can encase a message 110 from a core group 105 that alters the processing of the encased message 110. It should be noted that the format and/or contents of the message 110 are not altered by the addition of the bridge message wrapper 137.
These changes in the processing of the message 110 can include the replacement of multiple subscription and/or post messages 110 from individual core group 105 members with a single subscription and/or post message at the core group bridge 115 level. That is, the core group bridge 115 can subscribe to an information service in another core group 140 on behalf of the members of its local core group 105. A single subscription, therefore, means the receipt of a single return post message 110. The contents of a post message 110 can be stored in a local post repository 142 in the core group 140, where it can be accessed at any time by any member of the core group 140.
It should be appreciated that these processing alterations can result in a significant reduction in the quantity of subscription, post, and stop/failure messages 110 that need to be transmitted and processed within the system 100. The following table quantifies the savings in required messages 110 that can be achieved utilizing the present invention.
The proceeding equations can be better understood by using an example with numeric values. For example, let us use a system consisting of nine core groups in a mesh topology with each core group comprising fifty servers. The following table displays the calculation results associated with such an example.
As shown in the above table, an 86% reduction in subscription messaging can be achieved with the present invention. The reduction for post messages 110 at server startup can also be quite considerable with an 88% reduction for bridge fail-over.
The request coordinator 129 can correspond to the software component and/or algorithm that can determine the handling of messages 110 from its local core group 105. The request coordinator 129 can examine each received request and determine if the core group bridge 115 is already subscribed to the service. In cases where a subscription already exists, the request coordinator 129 can provide the requesting member with the corresponding data stored in the local post repository 112. Thus, the service request can be fulfilled without the need for reprocessing the subscription.
Network 130 can include any hardware/software/and firmware necessary to convey data encoded within carrier waves. Data can be contained within analog or digital signals and conveyed though data or voice channels. Network 130 can include local components and data pathways necessary for communications to be exchanged among computing device components and between integrated device components and peripheral devices. Network 130 can also include network equipment, such as routers, data lines, hubs, and intermediary servers which together form a data network, such as the Internet. Network 130 can also include circuit-based communication components and mobile communication components, such as telephony switches, modems, cellular communication towers, and the like. Network 130 can include line based and/or wireless communication pathways.
Information used by the various components of system100 can be digitally encoded within one or more data stores, which can be physical or virtual storage spaces configured to store digital information. The data stores can be physically implemented within any type of hardware including, but not limited to, a magnetic disk, an optical disk, a semiconductor memory, a digitally encoded plastic memory, a holographic memory, or any other recording medium. The data stores can be a stand-alone storage unit as well as a storage unit formed from a plurality of physical devices. Additionally, information can be stored within the data stores in a variety of manners. For example, information can be stored within a database structure or can be stored within one or more files of a file storage system, where each file may or may not be indexed for information searching purposes. Further, the data stores can utilize one or more encryption mechanisms to protect stored information from unauthorized access.
Method 200 can begin with step 205 where the core group bridge can receive a message. In step 210, the type of message received can be determined. When the message is determined to be a post message, flow can proceed to step 230 where the post handling process can be invoked. When the message is determined to be a status message, flow can proceed to step 235 where the status message handling process can be invoked.
When the message is determined to be a subscription request, flow can proceed to step 215 where it can be determined if the core group bridge already has a subscription for the request. If a subscription already exists, step 220 can execute where the core group bridge can provide the requesting server with the corresponding post data from the local post repository. If a subscription does not exist, then the subscription handling process can be invoked in step 225.
Method 300 can begin with step 305 where a core group bridge can invoke its topology evaluator. In step 310, the topology evaluator can determine the location of peer core group bridges. When the core group bridge is determined to be contained in exactly one set of peer core group bridges, the step 320 can execute where the core group bridge can be set to handle a mesh topology. A mesh topology can be determined since all core groups are directly connected to each other in a mesh, meaning that all groups are in the same set.
When the core group bridge is not contained in exactly one set of peer core group bridges, the step 325 can execute where it can be determined if the core group bridge is contained in more than one set of peers. If the core group bridge is contained in more than one set of peer core group bridges, then the core group bridge can be set to a chain topology. A chain topology can be determined since a core group must pass through multiple core sets with differing peers.
If the core group bridge is found not be contained in more than one peer set, then it can be determined that the core group bridge is disconnected and no communication can occur. This situation can signify a core group bridge failure in the core group bridge itself or its immediate peer core group bridges.
Collection 400 can comprise two separate methods 405 and 430 for handling subscription messages based on whether the core group bridge is sending or receiving the subscription message. When the core group bridge is sending a subscription message, method 405 can be executed.
Method 405 can begin with step 410 where the core group bridge can receive notification of a new subscription from its core group. In step 415, the subscription message can be encapsulated with a bridge subscription wrapper. The encapsulated subscription message can be sent to available peer core group bridges in step 420. In step 425, the subscription handling process can be deemed complete.
When the core group bridge is receiving a subscription message, method 430 can be executed. Method 430 can begin with step 435 where an encapsulated subscription message can be received by the core group bridge. In step 440, a subscription can be created on behalf of the sending core group bridge.
In step 445, it can be determined if the receiving core group bridge has subscription forwarding enabled. Message forwarding can be a process that is enabled when a chain topology is determined in order for a message to be propagated down the chain. When subscription forwarding is enabled, step 455 can execute where the encapsulated subscription message can be forwarded to available peer core group bridges. Step 450 can execute when subscription forwarding is disabled or after the execution of step 455 where the subscription handling process can be deemed complete.
Collection 500 can comprise two separate methods 505 and 530 for handling post messages based on whether the core group bridge is sending or receiving the post message. When the core group bridge is sending a post message, method 505 can be executed.
Method 505 can begin with step 510 where the core group bridge can receive notification of a new update or updates from its core group. In step 515, the update can be encapsulated with a bridge post wrapper. The encapsulated post message can be sent to available peer core group bridges in step 520. In step 525, the post handling process can be deemed complete.
When the core group bridge is receiving a post message, method 530 can be executed. Method 530 can begin with step 535 where an encapsulated post message can be received by the core group bridge. In step 540 it can be determined if the received post contains new data.
When it is determined that the received post contains new data, step 545 can execute where the received update can be stored in the core group, such as the local post repository 112 of system 100. When it is determined that the received post does not contain new data or upon the completion of step 545, flow can proceed to step 550 where it can be determined if post forwarding is enabled for the core group bridge.
When post forwarding is enabled, step 555 can execute where the encapsulated post message can be forwarded to available peer core group bridges. Step 560 can execute when post forwarding is disabled or after the execution of step 555 where the post handling process can be deemed complete.
When the core group bridge is sending a stop/failure message, method 605 can be executed. Method 605 can begin with step 610 where the core group bridge can receive notification that a core group bridge in another peer core group has failed. In step 615, it can be determined if another core group bridge is available in the peer core group containing the failed bridge.
If another bridge is unavailable in that core group, the subscriptions of the failed core group bridge can be removed from the sending core group bridge in step 620. In step 625, the post data from the failed core group bridge can be removed.
If another bridge is available in that core group or upon the completion of step 625, step 630 can execute where it can be determined the core group is enabled to send status messages. When the core group bridge is able to send status messages, step 635 can execute where the core group bridge sends a status message to its available peer group bridges. When the core group bridge is unable to send status messages or upon the completion of step 635, step 640 can execute where the stop/failure handling process can be deemed complete.
When the core group bridge is receiving a stop/failure message, method 645 can be executed. Method 645 can begin with step 650 where the core group bridge can receive a status message from another peer core group bridge. In step 655, it can be determined if the status message indicates a stop/failure in a peer core group bridge.
If the status message does indicate a core group bridge stop/failure, then step 660 can execute where the receiving core group bridge can remove the posts of the core group bridge referenced in the status message. If the status message does not indicate a core group bridge stop/failure or upon the completion of step 660, the status message can be forwarded to available peer core group bridges in step 665. In step 670, the stop/failure handling process can be deemed complete.
The present invention may be realized in hardware, software, or a combination of hardware and software. The present invention may be realized in a centralized fashion in one computer system, or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited. A typical combination of hardware and software may be a general purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein.
The present invention also may be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods. Computer program in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form.
This invention may be embodied in other forms without departing from the spirit or essential attributes thereof. Accordingly, reference should be made to the following claims, rather than to the foregoing specification, as indicating the scope of the invention.
