Abstract:
Methods, systems and computer program products are provided for managing shared data elements among a plurality of different client processes in a network environment. Shared data elements are associated with a Flow. A Flow is a logical stream of data that is only transmitted to a client process that explicitly subscribes for updates from the Flow. Update requests for the shared data elements are transmitted from client processes along the Flow so as to request the receipt of update notifications along the Flow. Update notifications are also transmitted about the shared data elements to the client processes along the Flow which have requested update notifications. Content of the shared data elements is, thereby, delivered to applications executing within said at least one client process which have requested updates of the shared data elements.

Description:
FIELD OF THE INVENTION 
     This invention relates in general to computer software, and in particular to a method and system for managing shared state information in a network environment. More particularly, the present invention relates to a method and system by which a plurality of clients can flexibly determine which information is cached locally and which information is retrieved from a server. 
     BACKGROUND OF THE INVENTION 
     In real-time network computing environments, a plurality of hosts typically must share one or more pieces of dynamic information. This shared state might include traditional publish-subscribe data such as stock quotes or news headlines. It might include dynamic information, such as content of an HTML page. In collaborative environments, the shared information might simply describe the presence or absence of other pieces of shared information. 
     In most cases, this shared state is managed by a server host, and client hosts can update the state and learn about its current value. Such traditional client-server systems have used either full-caching or no-caching to implement distributed state management. 
     Full-caching systems replicate all shared data locally at all of the clients. Whenever the data changes, the server transmits an update notification to all of the clients informing them to update their local data caches. All client application requests to read data are consequently handled by accessing the local cache, thereby gaining low request-response latency at the cost of significant network bandwidth consumption whenever an update occurs. Existing protocols such as the Lotus Notification Service Transport Protocol (NSTP) and IBM Interactive Universe (InVerse) server employ this approach. 
     No-caching systems maintain no state locally at the client and rely on a server interaction to perform all client application read and write requests. These systems only transmit the data that is specifically needed by each client at the expense of slower application response time and at the risk of potentially transmitting the same information multiple times over the network to a client. Most World-Wide Web applications employ this approach. 
     These two techniques require the system to choose an extreme between high network bandwidth consumption and fast client response time. However, in many environments, neither of these extremes is desirable. This is particularly true in synchronous groupware systems that must simultaneously support interactive response time and manage considerable amounts of shared state. Previous systems that have attempted to merge these two extremes have simply opted to statically mark some data as fully-cached and mark the remaining data as non-cached. However, this hybrid approach does not account for the fact that different clients manipulate different information, meaning that each client demands a different prioritization of interactive response time and bandwidth consumption on each piece of shared information 
     Therefore, a need exists for a method and system that supports partial caching of shared state information. Moreover, the decisions about what to cache should be made at run-time, so that a single system can support full-caching, no-caching, or any point in between these two extremes based on data update rates, client request rates, and available network and server resources. 
     SUMMARY OF THE INVENTION 
     An object of the present invention is to provide, within a network environment, a method for simultaneously supporting full-caching and no-caching semantics within a single system. 
     Another object of the present invention is to enable each element of shared data to employ different caching semantics at each host in the networked environment. 
     Yet another object of the present invention is to enable the caching semantics for each element of shared data at each host to be changed dynamically during the application&#39;s execution. 
     To achieve the foregoing objects and in accordance with the purpose of the invention as broadly described herein, a method and system are disclosed for flexibly managing the caching of shared data in a networked environment by using client-side data descriptors and data blocks. These and other features, aspects, and advantages of the present invention will become better understood with reference to the following description, appended claims, and accompanying drawings. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     For a more complete understanding of the present invention and for further advantages thereof, reference is now made to the following Detailed Description taken in conjunction with the accompanying drawings, in which: 
     FIG. 1 is a pictorial representation of a data processing system which may be utilized to implement a method and system of the present invention; 
     FIG. 2 illustrates a block diagram of system components that support the present invention; 
     FIG. 3 illustrates the relationship between a shared data element, a Flow, a Flow Block, and a Flow Descriptor in accordance with the present invention; 
     FIG. 4 illustrates how a client creates and destroys Flow Blocks and Flow Descriptors in accordance with the present invention; 
     FIG. 5 illustrates a flow chart depicting how a client reads dynamic information about a shared data element in accordance with the present invention; 
     FIG. 6 illustrates a flow chart depicting how a client determines current validity of a Flow in accordance with the present invention; 
     FIG. 7 illustrates a flow chart depicting how a client determines current validity of a Container in accordance with the present invention; and 
     FIG. 8 illustrates a flow chart depicting how a client subscribes for Flow creation and destruction in a Container and receives consistent notifications about Flows that already exist in the Container. 
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     Referring to FIG. 1, there is depicted a graphical representation of a data processing system  8 , which may be utilized to implement the present invention. As may be seen, data processing system  8  may include a plurality of networks, such as Local Area Networks (LAN)  10  and  32 , each of which preferably includes a plurality of individual computers  12  and  30 , respectively. Of course, those skilled in the art will appreciate that a plurality of Intelligent Work Stations (IWS) coupled to a host processor may be utilized for each such network. Each said network may also consist of a plurality of processors coupled via a communications medium, such as shared memory, shared storage, or an interconnection network. As is common in such data processing systems, each individual computer may be coupled to a storage device  14  and/or a printer/output device  16  and may be provided with a pointing device such as a mouse  17 . 
     The data processing system  8  may also include multiple mainframe computers, such as mainframe computer  18 , which may be preferably coupled to LAN  10  by means of communications link  22 . The mainframe computer  18  may also be coupled to a storage device  20  which may serve as remote storage for LAN  10 . Similarly, LAN  10  may be coupled via communications link  24  through a sub-system control unit/communications controller  26  and communications link  34  to a gateway server  28 . The gateway server  28  is preferably an IWS which serves to link LAN  32  to LAN  10 . 
     With respect to LAN  32  and LAN  10 , a plurality of documents or resource objects may be stored within storage device  20  and controlled by mainframe computer  18 , as resource manager or library service for the resource objects thus stored. Of course, those skilled in the art will appreciate that mainframe computer  18  may be located a great geographic distance from LAN  10  and similarly, LAN  10  may be located a substantial distance from LAN  32 . For example, LAN  32  may be located in California while LAN  10  may be located within North Carolina and mainframe computer  18  may be located in New York. 
     Software program code which employs the present invention is typically stored in the memory of a storage device  14  of a stand alone workstation or LAN server from which a developer may access the code for distribution purposes, the software program code may be embodied on any of a variety of known media for use with a data processing system such as a diskette or CD-ROM or may be distributed to users from a memory of one computer system over a network of some type to other computer systems for use by users of such other systems. Such techniques and methods for embodying software code on media and/or distributing software code are well-known and will not be further discussed herein. 
     Referring now to FIG. 2, components of a system that support the present invention are illustrated. A plurality of processes interact with a network  200 . A designated server process  201  is responsible for managing shared data in this environment. The server process  201  maintains information about a set of shared data elements that are currently available for client access and records the current value of each of these data elements. The server process  201  may optionally provide additional services such as persistence, transactional updates, and access control. However, these additional services are well understood in the prior art and are not discussed further herein. 
     A plurality of client processes, indicated by reference numerals  202 ,  203 , and  204 , create, read, write, and delete shared data. Within each of these client processes  202 ,  203  and  204 , an application  210  executes which employs a set of Data Access APIs (application programming interfaces)  211  for accessing and manipulating the set of shared data. Through these APIs, the application can create shared data elements, read the current values of shared data elements, update the values of shared data elements, subscribe for and receive notifications about changes to the values of shared data elements, and delete shared data. To support these Data Access APIs  211 , each client process  202 ,  203  or  204  can access a set of Data Descriptors  212  and a Data Block Cache  213 . 
     It is to be understood that no assumption is made about the physical location of the various client and server processes. For example, a single host machine may execute multiple processes concurrently. Indeed, all client processes  202 ,  203 , and  204  may execute on the same machine as the server process  201 , in which case communication over the network  200  would not be required. 
     Each element of shared data is associated with a logical construct called a Flow which represents a set of related network messages. In particular, the Flow carries all of the requests to update the associated data element, and it contains all of the confirmed updates to that data element. Each Flow is distinguished by a string name and a numeric ID. It is to be understood that although the present embodiment of the invention assigns both a string name and numeric ID to each Flow, in general, only one distinguishing identifier is required for each Flow. 
     Information about each shared data element is divided into two categories, namely the static data and the dynamic data. The static data comprises information that does not change during the data element&#39;s lifetime (from the time it is created to the time it is deleted). Such information, which is stored in a Flow Descriptor, includes the Flow&#39;s name, ID, and other user-defined properties. It is to be understood that alternative embodiments of this invention may designate other static information for each Flow. The dynamic data comprises information that may change during the data element&#39;s lifetime (from the time it is created to the time it is deleted). Such information, which is stored in a Flow Block, includes the data element&#39;s current value. It is to be understood that alternative embodiments of this invention may designate other dynamic information for each Flow. 
     FIG. 3 illustrates the relationship between a shared data element, a Flow, a Flow Descriptor and a Flow Block. A shared data element current value  300  is maintained by the server. Each data element current value  300  is associated with a flow  301  over which the server process  201  receives update requests from clients and transmits update notifications to clients. Each client process  202 ,  203  and  204  may optionally maintain a Flow Block  302  containing up-to-date information about the shared data element current value  300 . Update notifications transmitted along the Flow  301  are applied to the Flow Block  302 . In addition, each client process  202 ,  203  or  204  may also maintain a copy of a Flow Descriptor  303  for the Flow  301 . The Flow Descriptor  303  is created at each client process  202 ,  203  or  204  when it first receives notification from the server process  201  of the existence of the Flow  301  and is deleted when the client process  202 ,  203  or  204  receives notification from the server process  201  that the Flow  301  has been destroyed. 
     The Flow  301  is a logical stream of data that is only transmitted to client processes that explicitly subscribe for updates therealong. A client may subscribe to the Flow  301  at any time and may unsubscribe from the Flow  301  at any time. Through these dynamic subscriptions, the client process  202 ,  203  or  204  determines whether the shared data element current value  300  is fully cached locally or whether it is not cached locally. In particular, if the client process  202 ,  203  or  204  subscribes to the Flow  301 , then the client process  202 ,  203  or  204  can maintain an up-to-date local Flow Block  302 . All read requests can be handled by accessing this local Flow Block  302 . On the other hand, if the client process  202 ,  203  or  204  is not subscribed to the Flow  301 , then the client cannot maintain the up-to-date local Flow Block  302 . All read requests must be forwarded to the server process  201  for processing. 
     Each client process  202 ,  203  and  204  creates and maintains Flow Blocks, such as Flow Block  302 , and Flow Descriptors, such as Flow Descriptor  303 , in accordance with the dynamic caching semantics assigned locally for the associated shared data element. FIG. 4 illustrates how these Flow Blocks and Descriptors are created and destroyed at each client. Initially, the client has neither a Flow Block nor a Flow Descriptor, as indicated by reference numeral  400 . When the client receives notification from the server process of a new shared data element, it transitions to state  410  by retrieving the necessary information to create a Flow Descriptor. 
     At any time, the client application may request to receive notifications about updates to a particular shared data element. Alternatively, the Data Access APIs may detect that the application is frequently accessing a particular shared data element and that future accesses should, therefore, be handled from a local cache. In response, the client transitions to state  420  by subscribing to the Flow (by sending a message to the server) and creates a Flow Block for receiving shared data updates along the Flow. 
     At any time, the client application may request to no longer receive notifications about updates to a particular shared data element. Alternatively, the Data Access APIs may detect that the application is no longer frequently accessing a particular shared data element and that future accesses no longer need to be handled from a local cache. In response, the client may return to state  410  by unsubscribing to the Flow (by sending a message to the server) and destroying its Flow Block. 
     At any time, the client process may receive notification from the server process that a Flow no longer exists. In this case, the client transitions to state  400  by destroying both the Flow Block and Flow Descriptor. 
     As previously indicated above, the presence of the Flow Block on a particular client determines the caching semantics for the associated shared data element. Referring to FIG. 5, a flowchart shows how a client delivers the current value of the dynamic information about a Flow in response to an application request through the Data Access API (the static information is accessed from the Flow Descriptor). At decision block  500 , the client determines whether or not the Flow is valid, in accordance with a process to be subsequently discussed with reference to FIG.  6 . If the answer to block  500  is no, then an error is returned to the application at block  505 , and the procedure terminates at block  540 . If the answer to block  500  is yes, then at decision block  510 , it is determined whether or not a local Flow Block exists for the Flow (i.e. the client is currently in state  420  of FIG.  4 ). If the answer to decision block  510  is yes, then at block  520 , the information is retrieved from the Flow Block and returned to the requesting application. The procedure then terminates at block  540 . If the answer to decision block  510  is no, then at block  530 , the information is retrieved by querying the server and is then returned to the requesting application. The procedure then terminates at block  540 . 
     Flows are grouped by the server into Containers. Each Container is implemented as a Flow whose updates notify clients about the creation and deletion of other Flows (representing shared data elements) in that Container. Just as shared data element Flows are divided into Flow Descriptors and Flow Blocks, the Container Flow is also divided into a Container Descriptor and a Container Block. The Container Descriptor includes static information such as the Container&#39;s name, creator, etc. The Container Block includes dynamic information such as the list of currently active Flows in the Container. As with any other Flow, a client process may subscribe to and unsubscribe from the Container Flow (as shown in FIG. 4) based on an application request to be notified about the creation and deletion of shared data elements or based on an analysis of the application&#39;s access patterns. 
     Using information gathered from the Container Flow, the client can determine whether a selected shared data element Flow is presently active. FIG. 6 shows how the validity of a candidate Flow is determined. At decision block  600 , it is determined whether or not the Container for the candidate Flow is valid, in accordance with a procedure to be subsequently described with reference to FIG.  7 . If the answer to decision block  600  is no, then the candidate Flow is deemed to be invalid at block  605 , and the procedure terminates at block  640 . If the answer to decision block  600  is yes, then at decision block  610 , it is determined whether or not a local Container Flow Block exists for the Container Flow. If the answer to decision block  610  is yes, then at block  620 , the validity of the candidate Flow is determined by inspecting the Flow list contained in the Container Flow Block. The procedure then terminates at block  640 . If the answer to decision block  610  is no, then at block  630 , the server is queried for the candidate Flow&#39;s validity, and the procedure terminates at block  640 . 
     Containers may themselves be aggregated into higher-level Containers. Notifications along such a high-level Container Flow notifies the client about the creation and destruction of member Containers (by way of creating and destroying the member Container Flows). At the root level, all Containers are descendants of a well-known Session Container that exists during the life span of the application. Applications can, therefore, always subscribe to the Session Container Flow to learn about the creation and destruction of top-level Containers. The validity of a Container is determined by recursively determining the validity of its associated Container Flow, in accordance with FIG.  6 . However, the Session Container&#39;s validity is always assumed to be true. 
     FIG. 7 is a flowchart showing how the validity of a Container is determined. At decision block  700 , it is determined whether or not the Container is the Session Container. If the answer to decision block  700  is yes, then at block  710 , the Container is deemed to be valid and the procedure terminates at block  730 . If the answer to decision block  700  is no, then at block  720 , the Container&#39;s validity is determined by determining the validity of its Container Flow, in accordance with the procedure of FIG. 6, and the procedure terminates at block  730 . 
     It should be noted that, as described, the client may need to exchange multiple messages with the server to satisfy a particular application data access request. However, it is to be understood that alternative embodiments of the present invention may merge those multiple messages into a single server request (e.g. to verify multiple Container Flows at once). 
     As previously described above, an application may subscribe for notifications about the creation and destruction of Flows in a Container. In making this subscription, the application can designate that it wants to receive immediate notifications about all of the Flows that already exist in the Container. Such immediate notifications are known as “First Notifications.” From the application&#39;s point of view, therefore, all of the existing Flows in the Container appear to have been created immediately after the application subscribes for notifications about future Flow creations. 
     In FIG. 8, a flowchart illustrates how a client process satisfies such a “First Notification” request for information about existing Flows in a Container. At block  800 , the client process issues a Flow subscription request to the server. This request ensures that the client will receive all future notifications about Flow creation and destruction in the Container. After this request has succeeded, the client process requests a list of the current Flows in the Container at block  810  which is equivalent to a read request when the Container Flow Block does not yet exist locally. Upon receiving this list of Flows, the client creates and initializes a Container Flow Block at block  820 . At block  830 , the application receives notifications about all of the Flows listed in the newly created Container Flow Block. Finally, in block  840 , the application is actually added to the local list of callbacks that should learn about future notifications received on the Container Flow. This delayed registration of the application callback ensures that in a concurrent system with partial caching, the application receives a consistent set of notifications about the Container&#39;s Flows. 
     With this combination of Flow Descriptors, Flow Blocks, Containers, and Container Flows, applications can share data in a flexible manner while dynamically changing the local caching semantics for each data element. Although Flows have been described within the context of shared data elements at the server, it is to be understood that alternative embodiments of the present invention may implement Flows that are not associated with shared data elements at the server. In this case, the Flow is simply a vehicle for delivering event notifications among client applications. 
     Although the present invention has been described with respect to a specific preferred embodiment thereof, various changes and modifications may be suggested to one skilled in the art and it is intended that the present invention encompass such changes and modifications as fall within the scope of the appended claims.