Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/90—Details of database functions independent of the retrieved data types
  • G06F16/95—Retrieval from the web
  • G06F16/957—Browsing optimisation, e.g. caching or content distillation
  • G06F16/9577—Optimising the visualization of content, e.g. distillation of HTML documents

Definitions

• the present invention relates to a method for performing a distributed web application session, in particular a collaborative web browsing session, wherein a session has at least two participants initiating via their browsers events that cause changes of a web document, and wherein each participant reports changes to the browsers of the respective other participants of said session and to a master coordinator.
• the present invention relates to a system for performing a distributed web application session, in particular a collaborative web browsing session, comprising at least two participants being configured to participate in a session by initiating via their browsers events that cause changes of a web document, and a master coordinator, wherein each participant is configured to report changes to the browsers of the respective other participants of said session and to said master coordinator.
• DOM Document Object Model
• browser events are propagated to other participants' browsers, where they are replayed. More specifically, once an event occurs in a participant's browser, it is send to a coordinator, which sorts the events and propagates them in the same order to the browsers of all participants where the events are replayed.
• This method is rather light-weight, but has the trade-off that consistency of the respective web document, e.g. HTML, cannot be ensured.
• a web page e.g. a HTML document
• tags can be destroyed when handling a conflict (e.g. ⁇ ul> may become ⁇ ulb/). This means the web page cannot be correctly rendered in the browser.
• the aforementioned object is accomplished by a method comprising the features of claim 1 .
• said master coordinator performs the steps of analyzing changes it receives from participants of said session, detecting among said received changes concurrent changes, which are conflicting, and instructing the participants of said session to not apply detected conflicting changes.
• a system comprising the features of claim 14.
• said master coordinator comprises a module for analyzing changes it receives from participants of said session and for detecting among said received changes concurrent changes, which are conflicting, and communication means for instructing the participants of said session to not apply detected conflicting changes.
• participant By applying the invention participants of a co-browsing session have the same view on a collaboratively viewed web page. Moreover, the collaboration is improved due to less confusion since every participant has the same information and a consistent web page with an acceptable user experience.
• the present invention covers the entire spectrum of web pages, particularly the emerging trend towards more sophisticated web pages that allow dynamic changes, such as shopping sites or business intelligence reports. Apart from collaborative web browsing, the present invention can be suitably applied in co- shopping applications or in connection with interactive Web TV, to name just two further applications.
• the process of detecting concurrent changes may be performed by using vector clocks (sometimes also denoted clock-vectors), which constitute a framework for generating a partial ordering of events in distributed systems. Since those skilled in the art are sufficiently familiar with the mechanism of vector clocks, details can be omitted here. However, detailed aspects of vector clocks can be found in F.
• matrix clock instead of a vector clock, is attached to every change of a web document that is submitted to the other participants as well as to the master coordinator.
• matrix clocks are a generalization of the notion of vector clocks.
• a matrix clock maintains a vector of the vector clocks for each participant's browser. Every time a message is exchanged (e.g.
• the sending participant's browser increases its own clock and sends his clock together with the change as well as the state of clocks he knows from the other participants' browser, when receiving their changes and attached vector clocks, to the other participants' browser and the master coordinator.
• the master coordinator who receives all changes, may identify concurrent changes by comparing the vector clocks (or the matrix clocks, alternatively) it received from a participant each time something is sent to the master coordinator. Pairwise comparison of vector clocks attached to the changes sent by each participants, can show that if Vector V1 of a Change 1 and Vector V2 of a Change 2 are
• Vl(x i ) ⁇ V2(y i )Vi and Vl ⁇ V2 with x is the i-th element of V1 and y i is the i-th elment of V2
• browser participants that receive changes may apply them in the order defined by the vector/matrix clocks. In case of receiving concurrent changes, they may apply only one of them and then wait for the master coordinators decision. In this regard is important to note that browsers know if a non-concurrent change is missing by deriving this information from the vector/matrix clock attached to the change.
• an efficient detection of conflicts among concurrent changes it is important to note that basically a conflict occurs when one tries to insert a child node (within the DOM tree of a web document) into a parent node which has been concurrently deleted or when one tries to modify concurrently the same child node.
• the master coordinator in order to avoid problems with respect to failing identification, all elements in the DOM tree of a web document have assigned different IDs.
• the master coordinator in order to detect conflicting changes, may determine whether changes are dependent or independent by comparing the respective parent nodes.
• Handling means that some changes are made to the documents of the participants that they have a converging view.
• conflicting changes are highlighted to them.
• the master coordinator in case of detecting concurrent changes that are conflicting, will select a particular of the conflicting changes and instruct participants to apply only a particular change and to not apply other changes of the detected conflicting changes. Decisions on conflict are made eventually, i.e. there might be an inconsistent state at the participants for a short time before reaching a consistent state.
• the master coordinator maintains a list of changes, which assists master coordinator in detecting conflicting changes. The list may be garbage collected at one point in time, so that it does not grow exponentially.
• the browsers of the participants of a session synchronize each other on a regular basis.
• Such synchronization is favorable in order to rule out incomplete propagation of changes (e.g. some browsers receive changes and others not) and to detect missing changes. They may also regularly synchronize with the master coordinator to detect missing decisions. Although both measures cause more traffic, the reliability of the system is significantly increased.
• FIG. 1 is a schematic view illustrating a collaborative web browsing scenario according to a first embodiment of the present invention, and is a diagram illustrating the steps being performed by participants of a collaborative web browsing session according to a second embodiment of the present invention.
• Fig. 1 illustrates - schematically - a collaborative web browsing scenario with a total of n browser participants 1 that participate in a web browsing session, in which they access a particular web document 2. For the purpose of clarity, only three participants 1 are depicted in Fig. 1.
• each participant 1 transmits changes to all other participants 1 of the session. Thus, they have eventually the same view on the web page 2 as intended by collaborative web browsing. It is noted that only the changed parts of the web document 2 are submitted to others and not the whole document.
• a master coordinator 3 is provided to which participants 1 also propagate their changes. After a change to the web document 2 has been made and has been reported to the master coordinator 3, the following procedure applies:
• the master coordinator 3 detects concurrent changes, which are conflicting.
• the second step is about handling conflicting changes.
• the master coordinator 3 decides just on conflicting changes. Therefore, it is not a bottleneck, because it does not have to propagate all changes, but just decisions on conflicting changes.
• Detecting concurrent changes which are conflicting is performed by using a mechanism that preserves the causal order of changes, for instance a vector clock or a matrix clock approach. For instance, to every change of the web page 2 a vector clock is submitted to the other participants 1 and to the master coordinator 3.
• the master coordinator 3 receives all changes and can identify concurrent changes by comparing vector clocks.
• the master coordinator 3 has to identify among these changes those changes that are conflicting.
• a conflict occurs, for instance, in case a child node is inserted into a parent node which has been concurrently deleted, or when the same child node is concurrently modified. Therefore, the master coordinator 3 either checks all parent nodes up to the root node involved in a change, or it checks whether changes are dependent or independent. Once concurrent changes that are conflicting have been detected, these changes will be handled as follows:
• the challenge is that conflicting changes do not arrive necessarily at the same time.
• a na ' ive solution would imply that the master coordinator 3 waits a period of time for all changes to arrive, however, this waiting period is unpredictable and may lead to problems if a conflicting change arrives after waiting period.
• the master coordinator 3 upon arrival of a received change, the master coordinator 3 checks if it is concurrent conflicting with other changes, as already explained above. If this is not the case, the master coordinator 3 will not perform any further action. However, in case a change is concurrent conflicting with already propagated changes, the master coordinator 3 informs the other participants 1 , which one of the changes which are conflicting should not be applied. The participants 1 then apply the decision of the master coordinator. This means that participants 1 are informed about unexpected changes in the web document 2 (from their perspective) so that they are not confused and that no exceptions are raised in the browser systems or an inconsistent document is created.
• FIG. 2 is a diagram that schematically illustrates the steps being performed by participants of a collaborative web browsing session according to another embodiment of the present invention.
• the basic assumptions underlying the illustrated scenario are as follows: One participant 1 - browser participant 1A - initiates an event, denoted X, that changes the web document subject to the co-browsing session.
• Browser participant 1A determines the change, denoted C, to the web document affected by event X and propagates the change C to the other participants 1 of the session, which are depicted in Fig. 2 as a composite browser participant being denoted 1 B.
• browser participant 1A transmits the event X and a clock vector V together with change C. The same information is propagated to master coordinator 3.
• the master coordinator 3 when changes are propagated to the browsers of the other participants 1 B and the master coordinator 3, the browsers of the other participants 1 B apply these changes directly. Due to the implemented vector clock approach, the master coordinator 3 does not need to perform an ordering of changes, because this can be figured out by the participants 1 themselves, e.g. by deriving the respective information from the vector clock attached to the changes. The master coordinator 3 just decides which changes can be applied and which not. To this end, master coordinator 3 analyzes changes received from participants 1 to find out, in a first step, whether changes are concurrent. In a next step, changes that are concurrent are further analyzed to find out whether they are also conflicting. If so, master coordinator 3 performs a conflict resolution. The respective conflict resolution decision, denoted D, is propagated to the browsers of all participants 1 of a session, which then implement the decision.
• D The respective conflict resolution decision

Landscapes

• Engineering & Computer Science (AREA)
• Databases & Information Systems (AREA)
• Theoretical Computer Science (AREA)
• Data Mining & Analysis (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Information Transfer Between Computers (AREA)

Priority Applications (1)

Applications Claiming Priority (1)

Publications (1)

Family

ID=46682799

Family Applications (1)

Country Status (1)

Cited By (1)

Citations (2)

• 2012
  • 2012-07-05 WO PCT/EP2012/063164 patent/WO2014005640A1/fr not_active Ceased

Patent Citations (2)

Non-Patent Citations (5)

Similar Documents

Legal Events