Abstract:
Disclosed is a method, apparatus and computer program for determining which resource manager of a plurality of resource managers an application may be connected to, given a connection request. A connection request is received which specifies a connection scope. The connection scope specifies the desired proximity of a suitable resource manager relative to the application&#39;s location. The application&#39;s location is determined and so are any resource managers that satisfy the connection request. The connection requester is then informed of at least one resource manager which satisfies the connection request.

Description:
FIELD OF THE INVENTION  
       [0001]     The present invention relates to the connection of an application to a resource manager selected from a plurality of resource managers.  
       BACKGROUND OF THE INVENTION  
       [0002]     A bus may contain many resource managers that are inter-connected such that every resource manager in the bus has at least one route to every other resource manager in the bus.  
         [0003]     For ease, the following explanation will be given in terms of messaging engines and a messaging bus. It should however be appreciated that the invention is not limited to such.  
         [0004]     A messaging engine typically permits an application to retrieve information from a destination (e.g. via get message request from queue x), to request processing of some work (e.g. a put message request to queue y, requesting the update of a database) and to connect to another messaging engine via the bus in order to access a destination (e.g. queue) owned by such a messaging engine. The bus provides location transparency, enabling an application connected to one engine in the bus to reach any part of the bus via that engine. See for example, http://www.sonicsoftware.com/news_events/docs/the451 — 022304.pdf  
         [0005]     An application may use a set of properties to control how they wish to be connected to a resource manager. These properties can contain such information as the name of the bus and the type of protocol to use. With no other constraints, in principle, an application may be connected to any messaging engine. However, while this will work functionally, connecting to an arbitrary engine may be undesirable in some situations. A performance critical application may need to connect to a particular engine—for example one that is “close” (proximate) to the application in terms of network delay.  
         [0006]     During the Atlanta Olympics, a load balancing technique was used for managing access to the official Olympics website. When a client browser visited the website for the first time, a server hosting the site would send details of the client&#39;s IP address to each server via which access to the site could be gained. Each server would then ping the client and use this to record which server was the closest (in terms of network delay) to the client. Future attempts to access the Olympics site by the same client would then be redirected to the closest server. This is described in the article “Atlanta Olympics WOMplex” by Andy Stanford-Clark in AIXexpert Magazine, March 1997. The contents of this article was also presented at “Get Connected Technical Interchange &#39;96 at IBM Hursley in October 1996. This process is however transparent to the client.  
         [0007]     Other systems are known, whereby an application is connected to a server chosen by for example an IP sprayer (see http://64.233.167.104/search?q=cache:SURFepov5M0J:content.websitegear.com/article/load_balance_types.htm+%22IP+Sprayer%22&amp;hl=en). The choice may be a random one or may be based on a factor such as load. Load Balancers are well-known—e.g. Network Dispatcher from IBM. Once again however, all of the above is transparent to the client.  
       SUMMARY OF THE INVENTION  
       [0008]     According to a first aspect, the invention provides a method for determining which resource manager of a plurality of resource managers an application may be connected to, given a connection request, the method comprising: receiving a connection request specifying a connection scope, the connection scope specifying the desired proximity of a suitable resource manager relative to the application&#39;s location; determining the application&#39;s location; determining which resource managers satisfy the received connection request; and informing the connection requester of at least one resource manager that satisfies the received connection request.  
         [0009]     In one embodiment connection scope is specified in terms of a maximum acceptable network delay. For example a user could specify an acceptable maximum network delay of 5 seconds. Statistics could be maintained and used to determine which resources are capable of meeting such a requirement. Such statistics could be gathered by resources sending out data packets such that network throughput can be measured.  
         [0010]     Alternatively an application might specify that the selected resource manager should be located, relative to the application itself, in one of: the same host, same node, same application server, same process, same cluster, same bus. Naturally the second option is an implicit specification of acceptable network delay. For example, a resource manager in the same process as the application will have no network delay as compared with a resource manager in the same cluster or host.  
         [0011]     Other criteria could also be used as indicative of proximity—e.g. response time, number of network hops etc.  
         [0012]     The invention preferably provides a way of controlling network traffic. The closer a resource manager is to a requesting application, the less traffic routed through the network to get to that resource manager.  
         [0013]     Note, an application&#39;s location may be information that is transmitted with the connection request but this does not have to be the case. Instead, an application&#39;s location may be configured information which is accessed remotely. Other variations are possible.  
         [0014]     The step of determining which resource managers satisfy the connection request, may involve receiving such information from another entity.  
         [0015]     In one embodiment, the selection of a resource manager comprises determining that at least two connections points satisfy the connection request and selecting a resource manager from the at least two.  
         [0016]     Determining which of the resource managers to select may be based on the resource manager having the greatest proximity to the application (e.g. in terms of network delay etc.).  
         [0017]     In one embodiment, information is maintained about the location of resource managers and this is used to determine which resource managers satisfy the connection request. This information may be maintained by a separate entity to the original receiver of the connection request from the application. This receiver may forward the request onto the separate entity and that entity may either select a resource manager or provide a list of possible resource managers to the receiver for selection of one thereat. In order for the receiver to make an informed choice when provided with a selection of possible resource managers, the separate entity preferably provides resource manager location information to the receiver. Alternatively, the choice may be a random one or one based on user configured preferences (these may specify a priority order of choice).  
         [0018]     According to a second aspect, the invention provides an apparatus for determining which resource manager of a plurality of resource managers an application may be connected to, given a connection request, the apparatus comprising: means for receiving a connection request specifying a connection scope, the connection scope specifying the desired proximity of a suitable resource manager relative to the application&#39;s location; means for determining the application&#39;s location; means for determining which resource managers satisfy the received connection request; and means for informing the connection requester of at least one resource manager that satisfies the received connection request.  
         [0019]     According to a third aspect, the invention provides a method for an application to indicate what constitutes a suitable resource manager for the application to connect to when a plurality of resource managers are available, the method comprising: specifying a connection request having a connection scope, the connection scope specifying a location of a suitable resource manager relative to the application&#39;s location; and receiving information about at least one resource manager, the at least one resource manager satisfying the connection scope specified in the connection request.  
         [0020]     According to a fourth aspect, the invention provides an apparatus for an application to indicate what constitutes a suitable resource manager for the application to connect to when a plurality of resource managers are available, the apparatus comprising: means for specifying a connection request having a connection scope, the connection scope specifying a location of a suitable resource manager relative to the application&#39;s location; and means for receiving information about at least one resource manager, the at least one resource manager satisfying the connection scope specified in the connection request.  
         [0021]     Preferably the resource manager returned to the receiving step/receiving means is connected to.  
         [0022]     In one embodiment, a plurality of resource managers satisfy the connection request. Information is received about one of the plurality of resource managers where the use of that resource manager is specified as mandatory.  
         [0023]     It will be appreciated that the present invention may be implemented in computer software. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0024]     A preferred embodiment of the present invention will now be described, by way of example only, and with reference to the following drawings:  
         [0025]      FIG. 1  is a component diagram of the environment in which the present invention can operate in accordance with a preferred embodiment;  
         [0026]      FIG. 2  illustrates the detail of the workload manager (WLM) of  FIG. 1  in accordance with a preferred embodiment of the present invention;  
         [0027]      FIG. 3  illustrates the detail of the Topology Routing Manager (TRM) of  FIG. 1 , in accordance with a preferred embodiment of the present invention;  
         [0028]      FIG. 4  illustrates the processing of the TRM in accordance with a preferred embodiment of the present invention; and  
         [0029]      FIG. 5  shows the processing of the WLM in accordance with a preferred embodiment of the present invention. 
     
    
     DETAILED DESCRIPTION  
       [0030]     Below is provided a glossary of the terms used throughout the specification. Such a glossary is not intended to be limiting on the present application but is provided to aid explanation:  
         [0000]     Glossary  
         [0000]    
       
         
           
              Host: Computer  
              Node: “Virtual Host”—A host may be partitioned into one or more nodes, each with their own identity  
              Process: A context within an operating system having its own address space. Each process runs within a node and one or more processes typically collaborate to provide an application. For example, one process may display a GUI, whilst another may print a file.  
              Application: One or more processes working together to provide some functionality—e.g. email capability.  
              Application Server: The means by which an application may be executed.  
              Cluster: A group of application servers with some commonality. For example, an organising function (e.g. finance); or for the purpose of availability.  
              Bus: The means by which a set of resource managers may be connected together for the purpose of communicating with one another.  
              Messaging Engine (ME) The means by which each application server connects to a bus and achieves the processing of work/retrieval of information.  
           
         
       
     
         [0039]     The present invention operates, in accordance with a preferred embodiment, in the environment shown in  FIG. 1 . A system  5  is shown having a plurality of hosts  10 ,  20 . A host may accommodate one or more individually addressable nodes. Host  10 , for example has two nodes  10 . 1 ,  10 . 2 , whilst host  20  has two nodes  20 . 1 ,  20 . 2 . Each node has at least one application server  10 . 1 . 1 ,  10 . 1 . 2 ,  10 . 2 . 1 ,  20 . 1 . 1 ,  20 . 1 . 2 ,  20 . 2 . 1 . Each application server typically executes one or more processes which collaborate together to provide application functionality  40 ,  60 . For example application server  10 . 1 . 1  executes processes p 1 , p 2 , p 3  (which together denote an application—not referenced), whilst application server  10 . 1 . 2  executes processes p 4 , p 5 , p 6 . The processes making up applications  40  and  60  do exist but are not shown in the figure.  
         [0040]     Certain application servers may be grouped together into clusters (one shown)  30 . Certain processes run a messaging engine (ME) thereby enabling an application to access the destinations owned by the ME and to connect to a bus  70 ,  80  in order to access destinations owned by other MEs. For example p 1  on application server  10 . 1 . 1  executes ME 1  which owns destinations (not shown) and which provides a connection to bus  70 .  
         [0041]     Via busses  70  and  80 , application servers are able to communicate with one another.  
         [0042]     Client  50  also runs an application  60  which communicates with ME 5  and is thus able to access bus  80 .  
         [0043]     The present invention, in accordance with a preferred embodiment, enables an application to specify a scoping constraint (connection scope), when connecting to a messaging engine. Such a scoping constraint can be used to enforce the use of a suitably “close” (proximate) messaging engine. In the preferred embodiment, “close” means any engine that may be connected to whilst avoiding or minimising networking delays.  
         [0044]     TRM (Topology Routing Manager) component  90  collaborates to achieve a connection request with a WLM component  100 . WLM keeps track of all the constituent parts of the environment described with reference to  FIG. 1 . When a messaging engine connects to a bus, it registers with WLM.  
         [0045]     Note, there may be more than one WLM, each WLM being responsible for a subset of the environment—E.g. A group of hosts, nodes or application servers.  
         [0046]     WLM is described in more detail with reference to  FIG. 2 . WLM includes a registration component  120 . When a messaging engine connects to a bus, that engine registers with WLM using component  120 . Such a registration involves providing, by way of example, WLM with the following information:  
         [0047]     ME id; bus name; cluster id; host id; node id; application server id; and process id.  
         [0048]     The ME of course knows its own id and the name of the bus that it connects to. The ME queries its owning process for its process id, the process queries its application server for an application server id, the ME queries whether it is part of a cluster and so on. In this way, suitable information is provided to the ME and the ME in turn provides this to WLM upon registration.  
         [0049]     Such information is then stored by WLM in directory  110 . Thus it can be seen that ME 1  connects to bus  70 , is not part of a cluster, is owned by process  1 , within application server  10 . 1 . 1 . That application server is on node  10 . 1  and the node sits on host  10 .  
         [0050]     WLM also includes an ME Sub-Setter component  130  but this will be described in more detail later.  
         [0051]      FIG. 3  illustrates the TRM component in more detail and  FIGS. 4 and 5  show the processing of the preferred embodiment.  FIG. 4  is from the point of view of TRM and  FIG. 5  is from the perspective of WLM.  
         [0052]     TRM receives connection requests from applications. An application may reside on a client  50  or on an application server. Such connections are received by Connection Request Receiver  170  (step  200 ) A connection request may include the location of the requesting application (alternatively this may be determined from administrator configured information or from the context in which the request is made etc.), a bus name (if there are multiple possibilities); and a connection scope. The connection scope may be tailored in accordance with the following options:  
         [0053]     Connect to a messaging engine in the same: 
    Cluster;     Application Server;     Process;     Node; or     Host.    
 
         [0059]     If “same bus” is specified, then any messaging engine on a particular bus may be chosen.  
         [0060]     The connection request is received from the application, information is then extracted from such a request and is provided at step  210  to WLM (WLM Querier  180 ). Extracted information may include the requesting application&#39;s location, the name of the bus to connect to, and a connection scope.  
         [0061]     WLM operates using such information to recommend an appropriate ME to the application (step  300 ). WLM queries its directory  110  using ME Sub-Setter Component  130  (step  310 ). A subset of MEs satisfying the specified connection scope is provided to TRM (step  320 ). The results are received by TRM&#39;s Receiver Component  190  (step  220 ). TRM then selects an appropriate ME (step  230 ) and informs the application of the ME to which it is to connect (Application Informer  195 , step  240 ).  
         [0062]     For example, the application comprising processes p 1 , p 2  and p 3  may specify that a connection scope of “same process” is required. From WLM&#39;s directory WLM would determine that ME 1  satisfies the required criterion.  
         [0063]     On the other hand, the same application may specify “same host”. From  FIG. 1  it can be seen that this would provide a choice of ME 1 , ME 2  or ME 3 .  
         [0064]     WLM provides the subset of ME&#39;s to TRM and TRM would then select one of the MEs. In accordance with a preferred embodiment, TRM is likely to select the ME with the closest proximity to the application. This can be determined by querier WLM&#39;s directory information. Thus once again a suitable choice is ME 1  since this sits within the same process as the application itself.  
         [0065]     Note, in order for TRM to be able to determine which ME of a subset is the most suitable, WLM needs to provide TRM with information from its directory  110  about each ME in the Subset. In an alternative embodiment, WLM does not provide TRM with subset information but rather selects an appropriate ME from the subset itself.  
         [0066]     Thus the present invention, in accordance with a preferred embodiment, permits an application to specify a connection scope. In this way an application&#39;s connection to a messaging engine may be controlled resulting in increased performance.  
         [0067]     For example, certain nodes may have access to particular resources (e.g. databases). By specifying a connection scope of “same node”, it is ensured that the application will have access to appropriate resources.  
         [0068]     Clusters can be used for certain functions, an example being that a cluster may be managing a particular messaging destination. By specifying a connection scope of “same cluster” an application can ensure that it will be granted a connection to an ME that is locally performing physical processing related to that destination.  
         [0069]     A connection scope property of “same host” eliminates any network communications.  
         [0070]     A connection scope of “same application server” permits interprocess communications but again eliminates network communication. Such an option may be chosen for reasons of communication efficiency.  
         [0071]     Thus the present invention permits applications to scope their connections to a set of resource appropriately.  
         [0072]     Note, whilst the present invention has been described in terms of messaging and messaging engines, the invention is not limited to such. Rather, the invention may apply to any set of connected resource managers and their resources.  
         [0073]     Note, the connection scope information may be obtained in a number of different ways. For example, it may be hard-coded into the application itself; it may be obtained by reading separate profile information; a user may be prompted for the information etc.