Types of Collaboration: Event-based

For this example, we’ll consider a simple application in you can draw boxes, and you have only 4 options:

• makeNewBox(centerX,centerY)
• deleteOldBox(boxID)
• translateBox(boxID, X, Y)
• rotateBox(boxID, alpha)

It means that instances of the application transmit across the network only  the actions taken in order to get from the old state to the new state. This is extremely useful if you have data models that take up a lot of space (like 3D polygon models), but changes made to them can be described using very little space.

So let’s say you have application A and application B, working on the same instance containing square1 and square2. Let’s say square1 is already rotated by 30 degrees, and instance A rotates it with another 15 degrees (to a total of 45 degrees). Instead of sending out rotateBox(square1, 45), it sends out rotateBox(square1,15). The great advantage of this approach if two rotations occur in (near) real time, they can get composed over the network. So if, at the same time, application B, applies and additional rotation of 10 degrees, the end result (in both instance A and B).

The order on the generated events will be the order they reach the XTWIP server. It this case, it may seem that the order of the events is irrelevant, but most actions (operations) are not commutative – that is changing the order of two actions changes the end result they yield.

The advantages of this approach:

• Events end up having one single order in all application instances (everyone sees the same thing)
• Concurrent changes (same time, same object) are composed
• Small traffic across the network

The disadvantages are however more subtle and only through implementing experience did we learn about them:

• Composing concurrent changes isn’t always the best thing to do. Coming back to the previous example, if user A rotates the square by 15 degree and user B rotates it by 10 degrees, the end result will be a total rotation of 25 degrees. This is a mix of what both users wanted. But in fact it isn’t what either of them wanted.

• Requires server-side logic – in this model, the XTWIP server has to be aware of what rotateBox means. So the logic for actually performing the rotation has to be on the server. The downside is that with every application you deploy, the logic for all its operations has to be deployed on the XTWIP server as well. So this means more work for developers who use our server for deploying their apps and more work for us (because we would have to enforce advanced security restrictions on application logic). More work = bad news

These significant disadvantages of the event-driven model lead us to the decision that we needed an alternative way of offering real time collaboration, with less debugging, less risks and less work. This is how we came up with the object-driven collaboration model …

* Keep following the Types of Collaboration series to get a true insight on how XTWIP provides real time collaboration for your Web & Rich Internet Applications.