PERSISTENT COLLABORATIVE FRAMEWORK FOR INTERACTIVE WEB APPLICATIONS

• US 20080168139A1
• Filed: 01/06/2007
• Published: 07/10/2008
• Est. Priority Date: 01/06/2007
• Status: Active Grant

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Corporation
• Inventors: He, Li-Wei, Drucker, Steven, Zhang, Zhengyou, Junuzovic, Sasa, Hegde, Rajesh
• Granted Patent: US 7,624,145 B2
• Time in Patent Office: Days
• US Class Current: 709/205
• CPC Class Codes: H04L 67/02 based on web technology, e.g. hypertext transfer protocol [HTTP]
• CPC Class Codes: H04L 67/1095 Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
• CPC Class Codes: Y10S 707/99931 Database or file accessing

Abstract

A framework for facilitating collaborative interaction between users of a web application is presented. The framework provides persistence and sharing mechanisms for arbitrary application-defined objects. The sharing mechanism is coupled with a consistency mechanism that keeps client states consistent even when users perform conflicting operations. This framework is application-independent in that the persistence, sharing between clients and maintaining a consistent state among the clients is accomplished without the need for specific knowledge of the design of the web application. Thus, web developers can focus on the logic of the application and the UI, instead of spending time designing and implementing collaborative capabilities.

Claims

1. A computer-implemented process for providing an application-independent framework for facilitating persistent, collaborative interaction between users of a web application respectively running on a client computer associated with each user, the process comprising using a server to perform the following process actions:

replicating a current state of the application on each client at the time the client joins a session of the application;

persisting changes to the application states received from the individual clients; and

maintaining the consistency of the state of the application across the clients;

wherein

said replicating, persisting and consistence maintenance are accomplished independent of the application.

2. The process of claim 1, wherein the current state is defined by a group of objects and each object comprises a set of property values, and wherein the process action of replicating a current state of the application, comprises the actions of:

receiving an initial update poll from each client when the client joins the session; and

transferring the property values of the objects comprising the current state to each client in response to the initial update poll, along with a timestamp identifying when the property values were transferred.

3. The process of claim 1, wherein the current state of the application is defined by a group of objects with each object comprising a set of property values, and wherein the process action of persisting changes to the application states, comprises the actions of:

receiving a tuple from one of the clients describing a change made to a property of an object in said group of objects, wherein a tuple is received each time such a change is made; and

persisting each tuple received.

4. The process of claim 3, wherein each client comprises a client-side library which interfaces with the client application and communicates with a server, and wherein the process action of maintaining the consistency of the state of the application, comprises the actions of:

receiving an update poll from the client-side library of a one of the clients requesting an update to the state of the application, and including a timestamp provided to the client-side library with the response to the last previous update poll, wherein the timestamp indicates when the response to the last previous update poll was sent to the client; and

providing persisted tuples not provided to the polling client-side library the last previous time the polling client-side library was sent an update, as determined from the timestamp, to the polling client-side library along with an updated timestamp.

5. The process of claim 4, wherein the process action of providing persisted tuples, comprises the actions of:

for each tuple persisted,

determining if there is a previously persisted tuple pertaining to the same object property received from any of the clients that has not been sent to the polling client-side library,

designating these tuples pertaining to the same object property as conflicting tuples,

determining if the last persisted conflicting tuple is to be implemented in lieu of a previously persisted conflicting tuple, and if so

designating the last persisted conflicting tuple as the implementable conflicting tuple; and

providing non-conflicting tuples and implementable conflicting tuples not provided to the polling client-side library the last time the polling client-side library received an update as determined from the timestamp to the polling client-side library, along with an updated timestamp.

6. The process of claim 4, wherein each tuple comprises a client sequence ID associated therewith comprising a sequentially increasing number for each tuple generated by a client application in the order in which it was produced, and wherein the process action of persisting each tuple received comprises the actions of:

determining if the sequence ID included with the received tuple is one unit more than the greatest of the sequence IDs associated with tuples persisted for the client sending the received tuple;

whenever the sequence ID included with the received tuple is not one unit more,

persisting a template entry for each missing tuple in the sequence between the tuple having the greatest of the sequence IDs associated with tuples persisted for the client and the received tuple, if the template entry for the missing tuple does not already exist, wherein said template entry holds a place a missing tuple,

determining if the received tuple has a sequence ID corresponding to a missing tuple,

whenever the received tuple has a sequence ID corresponding to a missing tuple, persisting the received tuple in place of the template entry associated with the missing tuple,

whenever the received tuple does not have a sequence ID corresponding to a missing tuple, persisting the received tuple,

whenever the sequence ID included with the received tuple is one unit more, persisting the received tuple; and

assigning a global sequence ID comprising a sequentially increasing number to each tuple and template entry persisted in the order in which it was persisted, and reassigning the global sequence ID assigned to a template entry to a missing tuple persisted in its place.

7. The process of claim 6, wherein some tuples generated by a client application comprise a tuple group, and wherein the process action of providing persisted tuples, further comprises the actions of:

designating each tuple persisted which comprises a part of a tuple group, as group tuple;

providing to the polling client-side library, the tuples persisted since the last previous time the polling client-side library requested an update or persisted but not previously provided, except those having a global sequence ID greater than the earliest global sequence ID assigned to any template entry or any group tuple that is part of tuple group for which not all the tuples making up the group have been persisted.

8. The process of claim 7, wherein the process action of designating each tuple persisted which comprises a part of a tuple group, as group tuple, comprises an action of identifying a tuple group as those tuples received from the same client comprising a start of group indicator, an end of group indicator and all tuples received in between.

9. The process of claim 7, wherein the process action of designating each tuple persisted which comprises a part of a tuple group, as group tuple, comprises an action of identifying a tuple group as those tuples received following a begin call from the client-side library of a client and before an end call from the client-side library of the client.

10. The process of claim 4, wherein the process action of providing persisted tuples, comprises the actions of:

determining if persisted tuples not yet provided to the polling client-side library will conflict with tuples implemented locally by the client application of the client associated with the polling library since the last previous update poll by that client;

whenever it is determined that no conflict will occur, providing to the polling client-side library, persisted tuples not provided as of the client'"'"'s last previous update poll, in the order the tuples were originally persisted, except for tuples in the beginning of the order that represent changes that were already implemented locally in the same sequence;

whenever it is determined that a conflict will occur, providing to the polling client-side library, persisted tuples not provided as of the client'"'"'s last previous update poll, in the order the tuples were originally persisted, along with additional tuples generated by the server which are added to the beginning of the order which represent changes that roll back the object properties of objects affected by the conflict to those existing at the last previous update poll.

11. A computer-implemented process for providing an application-independent framework for facilitating persistent, collaborative interaction between users of a web application respectively running on a client associated with each user, wherein each client comprises a client-side library which interfaces with the web application running on the client and communicates with a server, the process comprising using each client to perform the following process actions:

the client application invoking the client-side library to send a request to the server to log into a session of the web application;

the client application receiving in response to the request an indication of a successful login;

the client-side library sending an initial update poll to the server requesting an update to place the application running on the client in a current state;

the client-side library receiving, in response to the initial update poll, a current state of the application from the server as defined by a group of objects with each object comprising a set of property values, and a timestamp representing when the group of objects was sent;

the client-side library providing the group of objects defining the current state of the application to the application running on the client for implementation;

the client-side library caching the timestamp;

the client application generating and the client-side library sending a tuple describing a change to a property of an object to the server each time such a change is made, whereby said change is implemented locally by the client application;

the client-side library periodically sending an update poll to the server asking for an update to the state of the application, said update poll comprising the last cached timestamp;

the client-side library receiving from the server, tuples and an updated timestamp in response to each update poll, wherein each tuple describes a change to a property of an object;

the client-side library providing each tuple received to the application for possible implementation; and

the client-side library caching the updated timestamp in lieu of the last previously cached timestamp.

12. The process of claim 11, wherein the process actions of the client-side library receiving tuples in response to an update poll, comprises the actions of:

receiving all tuples posted to the server or released for distribution since the last previous update poll including those posted by the polling client-side library; and

providing each tuple received to the application for possible implementation.

13. The process of claim 11, wherein the process action of the client-side library sending a tuple describing a change made to a property of an object to the server each time such a change is made, comprises an action of including with each tuple, a client sequence ID comprising a sequentially increasing number for each tuple generated by a client application in the order in which it was produced.

14. The process of claim 11, wherein the process action of the client-side library sending a tuple describing a change made to a property of an object in said group of objects to the server each time such a change is made, comprises the actions of:

including a start of group indicator with a tuple that is the beginning of a group of tuples intended to be implemented together before any other changes are implemented; and

including an end of group indicator with a tuple that is the end of the group of tuples intended to be implemented together before any other changes are implemented, wherein the tuple including the end of group indicator is sent after all the other tuples in the group have been consecutively sent to the server.

15. The process of claim 11, wherein the process action of the client-side library sending a tuple describing a change made to a property of an object in said group of objects to the server each time such a change is made, comprises the actions of:

sending a begin call at the beginning of a group of tuples intended to be implemented together before any other changes are implemented; and

sending an end call at the end of the group of tuples intended to be implemented together before any other changes are implemented.

16. The process of claim 11, wherein the process action of the client application invoking the client-side library to send a request to the server to log into a session of the web application, comprises an action of the client-side library sending a users name identifying a user of the client and a session name identifying an application session the user wants to join.

17. The process of claim 16, wherein the session name identifies a new application session the user wishes to initiate.

18. The process of claim 11, wherein the process action of the client-side library sending an initial update poll to the server, comprises an action of including a zero-valued timestamp with the update poll, wherein the zero value of the timestamp indicates to the server that the update poll is the initial update poll from the client-side library.

19. The process of claim 11, wherein the process action of the client-side library receiving, in response to the initial update poll, a current state of the application from the server as defined by a group of objects, comprises an action of receiving tuples, each of which describes a property of an object of the application that is different from the property of that object as it exists in an initial state of the application.

20. A computer-implemented process for providing an application-independent framework for facilitating persistent, collaborative interaction between users of a web application respectively running on a client computer associated with each user, the process comprising using a server to perform the following process actions:

receiving a request from each client to log into a session of the web application, said request comprising a name identifying the session the client is requesting to join;

determining if the request is valid and from an authorized client;

whenever the request is valid and from an authorized client, determining if the session in the request is new,

whenever it is determined the session is new, creating a session,

sending a client identification token and session token to each client requesting to log into the session, wherein the client identification token uniquely identifies the client and the session token identifies the session, and wherein both tokens are to be included in all communications from the clients to the server;

receiving an initial update poll from each client logged into the session requesting update information to place the application running on the client in a current state;

sending in response to each initial update poll,

tuples defining the current state of the application whenever the session is not a newly created session, wherein the application is characterized as a group of objects with each object comprising a set of properties, and wherein each tuple defines a current value of a property of an object of the application, and

a timestamp representing when the tuples defining the current state of the application were sent to the client;

receiving tuples from at least one client, wherein each tuple defines a new value for a property of one of the objects;

persisting each tuple received;

receiving an update poll from at least one of the clients along with the last timestamp provided to that client, wherein the update poll requests updating tuples; and

providing in response to each update poll,

tuples persisted, after the time represented by the received timestamp, or which were not previously sent to the polling client but have become available for dissemination, and

a timestamp representing when the tuples provided in response to an update poll were sent to the client.