Dolly Web Messenger: High-level architecture of the program

Update 21/10/2010:
I just had to record a video of this working before it was decommissioned from the live site :)

----------------------------------------------------------------------------------------------------

A few months back I posted on the Dolly web messenger I worked on as part of my day to day work and promised to give out more details on how we managed to build a cross domain web messenger built on the Windows Live Messenger Library that runs across page loads (maintains state when the user navigates from page to page – a lot like Facebook chat)

Angus did a great post on his blog about this and highlighted how it maintains state across page loads:

Here is the high level architecture of the program, in comprises of a Brain and Client solution with a built in State Engine.

Brain and Client

• Once the user clicks on the ‘Sign In’ button on the Dolly page, a pop up window opens up (We call this the Brain) which we brand based on the site it loads from

• The Brain essentially is the web messenger program; it does all the API based work

• The inline messenger you see within the Dolly page which the user interacts with (We call this the Client) is just an interface that is in the same domain as the Brain and is embedded in an iframe inside the Dolly site. Everything the user does using the Client silently triggers functions on the Brain (using the standard Child – Parent relationship that exists) which do all the hard work.

• So if the user clicks on a contact and starts a conversation on the Client, the same actions are being done on the brain (but hidden from the user) and when the Brain receives communication from the API, it triggers interface events on the Client to mirror the updates.

This is how the flow works between the Brain and the Client

State Engine

• Now if the user moves from page to page, we worked out how to maintain a continuous flow of usages on our web messenger. We do this with the use of Secure cross domain communication as suggested by as article on The Architecture Journal http://msdn.microsoft.com/en-us/library/bb735305.aspx

• The Dolly site has the following iframe structure on the site that hosts the complete Brain-Client with the built in State Engine (click on the images to enlarge)

Figure 1: Before the user signs in. Dotted boxes indicate iframes (see last image)


Figure 2: After the user signs in. Dotted boxes indicate iframes (see last image)


Figure 3: iframe structure that enables cross-domain / state management

Conclusion

In this example, this structure of iframes and windows which host pages from 2 domains (Dolly which acts as the host domain and has the Channel page and the iframes, and an external domain that has the Brain, Client, Middleman etc) work together to authenticate cross domain requests and maintain a flow of communication that works across page loads and domains.

This is basically the high level design, we also have 4 site dependent cookies (2 on the host domain and 2 on the external domain) to authenticate users, provide custom skins for sites provide tracking etc.

Concerns

• Even though this solution should work across domains, it does rely of third-party cookies (cookies dropped on the External Domain) and if the user does restrict 3rd party cookies then it wont work

So that's it guys, I hope to soon post some of my other learning as well. Mainly the issues we came across with JavaScript when its put under heavy load, but until then.. stay tuned :)