Mechanism for routing asynchronous state changes in a 3-tier application

[0002] This application is related to the applicants' copending application Ser. No. 09/112,532 filed Jul. 9, 1998, entitled “AUTOMATIC NOTIFICATION OF SYSTEM FAILURE IN A NETWORK APPLICATION,”

[0003] 1. Field of the Invention

[0004] The invention relates to the field of multi-processing systems in an asynchronous processing environment, for example, computer networks, and in particular, to providing notification to affected end users about state changes in relevant service objects distributed in the network.

[0005] 2. Background Information

[0006] Multi-processing systems are known, such as computer networks, and application programs may utilize resources which are distributed among the systems, e.g., a database located on a remote computer on the network may be accessed by an application program started by an end user interface on a network/personal computer (PC). Such an application program is referred to herein generically as a network application and PC is used for both network and personal computers.

[0007] It is generally desirable in a program with an end user interface to display the most up to date state of the data or entities that the end user is concerned with. If an end user performs an operation that resulted in a state change in data or an entity (from here on data, data or other entities will just be referred to as data) it is fairly straight forward to update the end user interface because the program knows that it changed the data and it knows that the user who caused the data to change is interested in that data. Other end users who are viewing the same data also need to have their views updated. This is a more complex problem, but it has generally been solved by data objects keeping track of the views that are interested in them so that they can notify the views when the data changes. Views register themselves with the data that they are interested in and unregister when they are deleted or no longer interested. This technique is known by many names such as the Observer design pattern or Model-View-Controller (MVC).

[0008] Using the observer pattern on a single system or in a client server is reasonably straight forward, but solving the problem of keeping the end user interface up to date in a 3-tier application is much more difficult. A 3-tier application that uses asynchronous communications between the 2nd and 3rd tier presents a different and much more complex problem. An exemplary 3-tier network application environment consists of the following 3-tiers.

[0009] On tier one, there is an end user interface on a PC. On tier two, there is a central application server associated with the end user that drives the majority of the application logic. On tier three, there are other systems that the application server deals with to perform distributed operations, called endpoints systems in this 3 tier model.

[0010] Asynchronous communication between the 2nd and 3rd tiers allows for the central application server to issue requests to the tier 3-systems in parallel. If the end user operation is to perform a task on 100 tier 3 systems, for example, it is not desirable for the central application server to perform these tasks in a synchronous fashion. If they were performed synchronously, the task could not be started on the 2nd system until it was completed on the 1st system, and it could not be started on the 3rd system until it was completed on the 2nd system, and so on.

[0011] Therefore, there is a need to solve the problem of keeping the end user interface up to date in a 3-tier application where the 2nd and 3rd tier, for example, communicate asynchronously.

[0012] It is, therefore, a principal object of this invention to provide a method for routing asynchronous state changes in a multi-processing environment.

[0013] It is another object of the invention to provide a method that solves the above mentioned problems so that an end user interface of an application can display the most up to date information.

[0014] These and other objects of the present invention are accomplished by the method disclosed herein.

[0015] According to an aspect of the invention, when a user action requires an operation to be performed in the network, a type of distributed service object is created on the central application server, and a proxy object is created on the PC where the end user requested the action. The distributed service object on the central application server knows the routing information to communicate with its proxy on the PC, and likewise, the proxy knows the routing information to the object on the central application server.

[0016] The distributed service object on the central application server will create some type of endpoint service object on each endpoint system that it needs to communicate with to accomplish the user's operation, and a proxy object is created on the central application server for every endpoint service object that was created. The endpoint service object knows the routing information necessary to communicate with its proxy on the central application server, and likewise, the proxy knows the routing information to the object on the endpoint system.

[0017] In both of the above cases, the proxy objects are interested in the service object that they are associated with. When those service objects change, they notify their proxy of the change, routing their messages using the routing information that they store about the location of their proxy.

[0018] This arrangement provides a notification path between a service object on an endpoint system (tier 3) and its proxy on the central application server (tier 2), and a notification path between a distributed service object on the central application server (tier 2) and its proxy on the PC (tier 1).

[0019] According to another aspect of the invention, two more levels of notification that are provided. In particular, a notification path between the endpoint's proxy object on the central application server and the distributed service object on the central application server, and between the distributed service object's proxy on the PC and the window in which the user is viewing the data.

[0020] According to another aspect of the invention, these other levels of notification are enabled by generalizing the concept of an owner of a service object proxy. The owner of the endpoint service object proxy on the central application server is registered to be the distributed service object on the central application server. The owner of the distributed service object proxy on the PC is registered to be the window ID of the window where the data is displayed.

[0021] According to another aspect of the invention, through these four levels of notification, a state change of data on an endpoint system is relayed to the end user interface on the PC.

[0022] According to another aspect of the invention, the endpoint service object detects the change in data (because it caused the change) and it notifies its proxy object on the central application server.

[0023] According to another aspect of the invention, the endpoint service object's proxy on the central server notifies its owner (the distributed service object on the central server) of the data change.

[0024] According to another aspect of the invention, the distributed service object on the central server notifies its proxy object on the PC of the data change.

[0025] According to another aspect of the invention, the distributed service object's proxy on the PC posts an event to its owner, e.g., a window or windows using window identification (ID).

[0026] These and other aspects of the invention will become apparent from the detailed description set forth below.

[0027] FIG. 1 illustrates a three-tier network application environment according to an exemplary embodiment of the present invention.

[0028] FIG. 2 illustrates a method of notification through a three-tier network started by a state change on an endpoint system, according to an exemplary embodiment of the invention.

[0029] FIG. 3 is a flow chart of an exemplary embodiment of a method according to the invention.

[0030] The invention will now be described in more detail by way of example with reference to the embodiments shown in the accompanying figures. It should be kept in mind that the following described embodiments are only presented by way of example and should not be construed as limiting the inventive concept to any particular physical configuration.

[0031] The invention will be described in the context of a three-tiered network environment, however, the invention is not necessarily limited thereto. In a classical three-tiered network, there is a presentation logic (PL) tier, a business logic (BL) tier, and a data logic (DL) tier. The presentation logic tier, tier one, is the so-called front end of the application. This is the graphical user interface (GUI) that collects data from the user and displays information for the user. Its purpose is to interact with the end user and to request services from one or more servers and/or host systems.

[0032] The business logic tier, tier two, is usually running on a server. It processes data on behalf of the PL client and may require the services of other BL's residing on the same or other machines.

[0033] The data logic tier, tier three, is usually a host program which obtains data requested by either a BL or PL from a database.

[0034] The network application environment illustrated in FIG. 1 has 3 tiers 101, 102 and 103. The first tier labeled TIER ONE 101, is the presentation logic (PL) tier, and represents an end user interface on a network/personal computer (PC), for example. End user window 104 is connected to distributed service proxy 105 by owner line 106. Distributed service proxy 105 is connected to a distributed service object 108 in the second tier 102 by line 107.

[0035] The second tier labeled TIER TWO 102, is the business logic (BL) tier, and represents a central application server associated with the end user that drives the majority of the application logic. However, there could be more than one server, as explained above. The first tier distributed service proxy 105 is connected to a distributed service object 108 in the second tier 102 by line 107.

[0036] The third tier labeled TIER THREE 103, is the data logic (DL) tier, and represents other systems, called endpoint systems, that the central application server of the second tier 102 deals with to perform distributed operations. Three endpoint systems (Systems A, B and C) are illustrated for the purposes of explanation, it being understood that there could be any number.

[0037] Distributed service object 108 is connected to three endpoint service proxies 109A, 109B and 109C by respective owner lines 110A, 110B and 110C. While three endpoint service proxies are illustrated, this is only for purposes of explanation, it being understood that there could be any number of endpoint service proxies in actuality. Each endpoint service proxy 109A, 109B and 109C, is connected to an endpoint service object 112A, 112B and 112C, in the third tier 103 by a respective line 111A, 111B and 111C.

[0038] End user operations result in some number of request and reply messages being sent between system in the 3-tier environment. Messages are sent in packets, and each packet contains routing information. Some packets contain routing information that tells them where to go, and others also contain routing information that identifies where they came from, so that messages can be sent in response. The routing information in a packet may include the system ID and an object ID.

[0039] All operations in the network application utilize service objects, e.g., 112A, 112B and 112C, and their corresponding proxies, e.g., 109A, 109B and 109C, that exist on the systems involved in the operation. A “service object” is a bundle of data and function for performing a particular service.

[0040] When a user action requires an operation to be performed in the network, a type of distributed service object 108 is created on the central application server of tier two 102, and a proxy object 105 is created on the PC of tier one 101 where the end user requested the action. The distributed service object 108 on the central application server of tier two 102 knows the routing information to communicate with its proxy 105 on the PC of tier one 101, and likewise, the proxy 105 knows the routing information to the object 108 on the central application server of tier two 102.

[0041] The distributed service object 105 on the central application server of tier two 102 will create some type of endpoint service object 112A, 112B, 112C on each endpoint system (A, B and C) of tier three 103 that it needs to communicate with to accomplish the user's operation, and a proxy object 109A, 109B, 109C is created on the central application server of tier two 102 for every endpoint service object 112A, 112B, 112C that was created. The endpoint service object 112A, 112B, 112C knows the routing information necessary to communicate with its proxy 109A, 109B, 109C on the central application server of tier two 102, and likewise, the proxy 109A, 109B, 109C knows the routing information to the object 112A, 112B, 112C on the endpoint system of tier three 103.

[0042] In both of the above cases, the proxy objects are interested in the service object with which they are associated. When those service objects change, they notify their proxy of the change, routing their messages using the routing information that they store about the location of their proxy.

[0043] This arrangement provides a notification path between a service object on an endpoint system of tier three 103 and its proxy on the central application server of tier two 102, and a notification path between a distributed service object on the central application server of tier two 102 and its proxy on the PC of tier one 101.

[0044] However, there are two more levels of notification that are needed. In particular, it is needed to enable a notification path between the endpoint's proxy object, e.g., 109A, on the central application server of tier two 102 and the distributed service object 108 on the central application server of tier two 102, and also between the distributed service object's proxy 105 on the PC of tier one 101 and the window 104 in which the user is viewing the data.

[0045] These other levels of notification are enabled by generalizing the concept of an owner of a service object proxy. The owner of the endpoint service object proxy, e.g., 109A, on the central application server of tier two 102 is registered to be the distributed service object 108 on the central application server of tier two 102. The owner of the distributed service object proxy 105 on the PC of tier one 101 is registered to be the window ID of the window 104 where the data is displayed.

[0046] Through these four levels of notification/ownership, a state change of data on an endpoint system of tier three 103 is relayed to the end user interface on the PC of tier one 101 as will now be described.

[0047] The endpoint service object, e.g., 112C, detects the change in data (because it caused the change) and it notifies its proxy object, e.g., 109C, on the central application server of tier two 102. The endpoint service object's proxy 109C on the central server notifies its owner, i.e., the distributed service object 108 on the central server, of the data change. The distributed service object 108 on the central server of tier two 102 in turn notifies its proxy object 105 on the PC on tier one 101 of the data change. The distributed service object's proxy 105 on the PC posts an event to its owner, i.e., an end user window 104, using its window ID.

[0048] The window 104 that the end user is viewing the data in now knows of the data change. The window 104 can furthermore update its view using data passed back in the notification.

[0049] It should be noted that there may be more than one user who is viewing the same data, e.g., on another PC. However, the solution according to the invention allows for this. At any of the four above described levels of notification, more than one object may be notified, e.g., any service object may have more than one proxy, or any proxy may have more than one owner.

[0050] FIG. 2 is an object-interact diagram, also referred to as a bubble diagram herein, which illustrates the above described method of notification through a three-tier network started by a state change on an endpoint system. In particular, there are three endpoint systems, SYSTEM A, SYSTEM B, and SYSTEM C, illustrated in tier three 103, for purposes of explanation. In SYSTEM C, some state change occurs at 201 which is detected by endpoint service object 112C.

[0051] A notify operation 202 is initiated, and an update is issued 203 to the corresponding endpoint service proxy 109C in tier two 102. A notify operation 204 is initiated and an update is issued 205 to the distributed service object 108.

[0052] A notify operation 206 is initiated and an update is issued 207 to the distributed service proxy 105 in tier one 101. A notify operation 208 is initiated and an respective update 209, 210, 211 issued to each affected graphical user interface (GUI) window 104A, 104B, 104C.

[0053] FIG. 3 is a flow chart of an exemplary embodiment of a method for routing asynchronous state changes in a multi-processing system having an end user system, a central application server system and an endpoint system, according to the invention. In block 301, a state change IS detected with a service object on the endpoint system. In block 302, a notification is sent to an associated service proxy object on the central application server system notifying the associated service proxy object of the state change. In block 303, a notification is sent to an associated distributed service object which is an owner of the service proxy notifying the associated distributed service object of the state change. In block 304, a notification is sent to an associated distributed service proxy object on the end user system notifying the associated distributed service proxy object of the state change. In block 305, an event is posted to an associated owner window of the distributed service proxy object using a window identifier. This includes sending a notification to the associated owner window notifying the associated owner window of the state change.

[0054] The advantageous solution according to the invention, while described with respect to a three-tiered network environment, is applicable to any N-tiered network application. As one skilled in the art would recognize and appreciate, a solution according to the invention has applicability to virtually any network or multi-processing application. That is, one skilled in the art would understand that the invention is applicable to any number of multi-processing arrangements where state change, e.g., data change, notification is important.

[0055] It will be apparent to one skilled in the art that the manner of making and using the claimed invention has been adequately disclosed in the above-written description of the preferred embodiments taken together with the drawings.

[0056] It will be understood that the above described preferred embodiments of the present invention are susceptible to various modifications, changes, and adaptations, and the same are intended to be comprehended within the meaning and range of equivalents of the appended claims.