The understood benefits

The cost and resource benefits that real-time push bring start to be considered when the excitement of the technology dies down and you start talking in detail about using a Cloud Platform as a Service (PAAS) such as Kwwika. Kwwika provides the more obvious benefit of allowing anybody to publish and add real-time data to any web page, web application, Rich Internet Application (RIA), desktop or service application and share information between all these and from a number of different sources. The first thoughts of resource and cost saving are when you start to consider that by using a service you don’t need to buy servers to host your real-time push servers, you don’t need to spend time and effort installing, setting up and learning how to use the software, you don’t need to worry about maintaining the software and handling upgrades and you don’t need to worry about how you deal with scaling your servers to meet increased demand as well as keeping resource usage to a minimum during lean spells. Kwwika offers all the benefits of a hosted scalable service, but for real-time push streaming as a service. This means you can concentrate on building your application, developing your product or service and winning business.

The benefits of real-time push-once

The best way to understand one of the fundamental, but as yet hidden, benefits of Kwwika, and ultimately real-time push-once, is through an example:

Imagine a website known as the best destination for up to the second sports information for the newest and most popular sports of all time: Multiball. It’s a mixture of all the most popular sports including football (soccer), baseball, basketball, rugby, tennis, cricket and motor sports. This new game is fast paced and jam packed with statistics which change every second. Today there is a really big game on between Great Britain and USA. The world wants to watch this game but it’s during the day for many people who will be at work in front of their computers so they’ll be logging on to this well known website to keep up to date with the scores. The game is tied in the 4th quarter with only 1 minute remaining and millions of users from around the world starting hitting the F5 key and clicking the “Refresh” button in their web browser to refreshing the website and check for the latest score. The servers hosting the website can’t handle the load and crash.

Some websites try to get around this scenario by adding some script to their score web page which polls the server for an update at a set interval. The problem with this is that the web server still has to deal with, in effect, a refresh although the data returned to the request can be much smaller.

The most obvious use of a real-time push system is that as soon as a server (or score system) receives new information it can push it to any application instance that is interested in that information. In the above Multibal’ website example the application instance is each web browser session logged on to the website. If the sports website were using a real-time push system this would mean that they could instantly push any changes in the score to each web browser session which would mean that each website user wouldn’t need to refresh their page (reloading the whole page) to check if the score had changed.

This alone would take a massive load off of the sports website infrastructure, but it’s possible to take things even further.

Even in the real-time push scenario the sports website would need to build and maintain the real-time push infrastructure and push an update to each of the millions of website users. From the information above you’ll know that real-time push services can help them out with the infrastructure. The new, and game changing feature that Kwwika offers is that when Rooney Giggs McFadden makes that game winning manoeuvre-score for Great Britain the sports website would only need to publish the score update once into the Kwwika service (real-time push-once). Kwwika would then instantly distribute that update to the millions of website users. This means the website only ever needs to deal with single page loads from its users and push out each score change or game statistic once, Kwwika does the rest.

Thanks to Zen Elements Web Design & Development for the diagrams

Permalink

| Leave a comment  »

Related posts:

1. Add real-time news to your site with Google. Add any real-time data to your site with Kwwika
2. The death of “F5″ Ah, I get it!
3. Kwwika World Cup 2010 Real-Time Push Web App – Apple iPad competition

Related posts:

1. Kwwika Silverlight API – Chat Example
2. Defining the Kwwika API
3. Using Fiddler to trick Silverlight into allowing a crossdomain Web Request

Why do we need Kwwika?

There are loads of real-time technologies available at the moment. Almost all of them have a reasonable learning curve and require a developer to sort out server infrastructure, perform installation, do all sort of configuration and then finally get around to writing an application. In the same way that a lot of developers or organisations have moved into managed hosting for their websites, or more recently moved a lot of their IT infrastructure into the Cloud, Kwwika offers a managed and scalable real-time infrastructure so you can concentrate on building your Real-Time Rich Internet Application.

The way I’m describing Kwwika at the moment is:

Kwwika is a real-time web data sharing platform with APIs in JavaScript, Silveright, .NET, Java and C.

An example of where Kwwika could be used

Martin Tyler recently wrote a blog post that provides a great example of where a service like Kwwika would have been really useful. In the situation described in the blog post CricInfo could simply publish their cricket updates to their defined topic in Kwwika, maybe /CRICINFO/GAMES/INDIA-SOUTHAFRICA/, from a single server. They would then add a small piece of script to their game web page that subscribes to this topic and updates that web page whenever any new data is available. Users would see the real-time in-page updates and would no longer continue to hit “Refresh” to see if the score had updated. Kwwika would instead take the hit of the data transfer and push the live updates to the web page. This would take a massive load off of the CricInfo server and clearly save them a lot of time and infrastructure costs.

How will I use Kwwika?

When we launch Kwwika all you’ll need to do to use the service is:

1. Register for Kwwika via a sign up page
2. Define your topics that you would like to publish data to in the Kwwika dashboard e.g. /PhilLeggetter/Kwwika
3. Find some topics with information on that you are interested in using e.g. /BBC/NEWS/SPORT/FOOTBALL (doesn’t exist – just an example – but how cool would that be!)
4. Embed the Kwwika <script> tag in your web application or download the API for your chosen technology
5. Start developing your Real-Time Rich Internet Application

I think the great thing about this is that developers just use the Kwwika service and only ever need to care about developing their own application. Kwwika provides the server infrastructure so you don’t have to.

The Kwwika API

I’m in the middle of defining the Kwwika API and thought this would be a great opportunity to get some early feedback. We plan to have initial releases of the API for the following technologies:

• JavaScript
• Java
• .NET
• Silverlight
• C

The API is really simple. It has the following functionality:

• Connect
• Receive connection events
• Subscribe for data
• Receive subscription events such as errors and data updates
• Publish data
• Receive data publishing events (publish success or failure)
• Disconnect

At the moment we have two ways of thinking about the API. The following two examples are using the JavaScript API but we plan to make the APIs virtually identical between technologies with the only differences down to following the language specific standards.

Our main topic of discussion is around how you initiate your connection to the Kwwika service but for completeness I’ll provide full examples. The first option we have is to create a Connection object using a factory method on the kwwika namespace.

var oConnection = kwwika.connect({
									"connectionStatusUpdated":function(sStatus)
									{
										document.getElementById("connectionStatus").innerHTML = sStatus;
									}
								 });

var oSubscription =
	oConnection.subscribe("/KWWIKA/LIBRARIES/JavaScriptAPI",
						  {
						  	"topicUpdated":function(oSubscription, mUpdate)
						  	{
						  		for(var sFieldName in mUpdate)
						  		{
						  			document.getElementById("field_" + sFieldName).innerHTML = mUpdate[sFieldName];
						  		}
						  	},
						  	"topicError":function(oSubscription, sReason)
						  	{
						  		var sMsg = oSubscription.topicName + " error: " + sReason;
						  		document.getElementById("topicErrorMessage").innerHTML = sMsg;
						  	});

oConnection.publish("/KWWIKA/LIBRARIES/JavaScriptAPI",
					{
						"name": "Phil Leggetter",
						"status": "Getting feedback about the Kwwika API",
						"datetime": new Date().getTime()
					},
					{
						"commandSuccess":function(oSubscription)
						{
							var sMsg = oSubscription.topicName + " message published.";
						  	document.getElementById("publishStatus").innerHTML = sMsg;
						},
						"commandError":function(oSubscription, sError)
						{
							var sMsg = oSubscription.topicName + " publish error: " + sError;
						  	document.getElementById("publishStatus").innerHTML = sMsg;
						}
					});

In the second option is to create a new Kwwika object.

var oKwwika = new Kwwika({
							"connectionStatusUpdated":function(sStatus)
							{
								document.getElementById("connectionStatus").innerHTML = sStatus;
							}
						 });

var oSubscription =
	oKwwika.subscribe("/KWWIKA/LIBRARIES/JavaScriptAPI",
					  {
					  	"topicUpdated":function(oSubscription, mUpdate)
					  	{
					  		for(var sFieldName in mUpdate)
					  		{
					  			document.getElementById("field_" + sFieldName).innerHTML = mUpdate[sFieldName];
					  		}
					  	},
					  	"topicError":function(oSubscription, sReason)
					  	{
					  		var sMsg = oSubscription.topicName + " error: " + sReason;
					  		document.getElementById("topicErrorMessage").innerHTML = sMsg;
					  	});

oKwwika.publish("/KWWIKA/LIBRARIES/JavaScriptAPI",
				{
					"name": "Phil Leggetter",
					"status": "Getting feedback about the Kwwika API",
					"datetime": new Date().getTime()
				},
				{
					"commandSuccess":function(oSubscription)
					{
						var sMsg = oSubscription.topicName + " message published.";
					  	document.getElementById("publishStatus").innerHTML = sMsg;
					},
					"commandError":function(oSubscription, sError)
					{
						var sMsg = oSubscription.topicName + " publish error: " + sError;
					  	document.getElementById("publishStatus").innerHTML = sMsg;
					}
				});

Do the above examples make sense? Is the API easy enough to use? How would you establish a connection to the Kwwika service? Would you do anything differently?

I’d love to get you feedback so please leave your comments below or email me directly using phil@leggetter.co.uk.

Related posts:

1. Kwwika Silverlight API – Chat Example
2. Want to try out the Kwwika API but don’t want to register?
3. Making cross domain JavaScript requests using XMLHttpRequest or XDomainRequest

As of today, Facebook Fan Page status updates will begin appearing in Google search results, according to a tweet by Google. The announcement means that we will begin seeing results from the nearly 3 million fan pages, but not from the more than 400 million users.

Related posts:

1. How does Google Real-Time Search work?
2. Google realtime search isn’t real-time
3. Add real-time news to your site with Google. Add any real-time data to your site with Kwwika

The normal example given to show the benefits of using Comet to achieve full HTTP streaming and the importance of non-stale data is of a trader making a trade on an out of date price. Another example is given where a person places a bet using odds that are on screen but do not match up with the odds in the betting system.

I just read a post on Comet Daily about a company called Frozen Mountain who have just released a component that adds Comet Support for IIS. Along with this they’ve released a video which doesn’t cover the standard example.

It’s possible that in this example that a polling solution might actually be just as suitable but this is a good demonstration of the benefits of Comet. In the example Comet provides almost instant feedback on the number of available tickets to potential buyers. This has two benefits. The first is that the user (Bob in the video) has less of a chance of missing out on his tickets. The second is more of a commercial benefit in that the user gets instant feedback on the popularity of the event and availability of the tickets and is more likely to make an instant purchase.

Until a solution such as Comet is used the data that a user sees, in a event booking, trading, betting or even search system, cannot be classed as part of the truly real-time web.

Related posts:

1. When does NOW matter?
2. Using real-time web software and technology to distribute events
3. The benefits of Real-Time Push-Once

I think the UI revolution’s already here; now we see which ones bubble to the top!

This got me thinking about the criteria that may determine which RIA technology would be most successful.

I think there are a number of things that will determine which one will ultimately win, or at least become the dominant choice. At the moment I can think of three categories; Technology buy-in, Development environment and Data access capabilities and choice.

Technology buy-in

Some companies buy-in to a technology because they have always used that technology. For example, a company that have always used Java will be more likely to opt for the Adobe solution where they can write their server components using Java and their client in Flash/ActionScript/Flex (this terminology is still a bit unclear to me. I think this is why Adobe are renaming Flex Builder to Flash Builder) but a company that have traditionally used Microsoft products will undoubtedly go for Silverlight. More traditional web developers, who probably build upon the LAMP stack, that have been hand coding PHP on the server and JavaScript on the client tend to go for creating RIAs using Ajax.

Development environment

I believe that Microsoft have a massive advantage in having Visual Studio as a server and client IDE. It has it’s faults but in general it’s a fantastic development environment. Those choosing Flex (Java -> ActionScript/Flash) will more than likely choose the Eclipse IDE, which is powerful, but it’s ActionScript/Flex development tools are lacking maturity. I’ve recently used the Flash Builder 4 beta and it’s miles behind Visual Studio in terms of coding productivity features. I’ve heard that the Flex UI component development features may be better than Visual Studio’s support for Silverlight UI. The LAMP with Ajax stack suffers much the same problems as Flex with, as far as I know, Eclipse being the IDE of choice and client-side productivity tools still very much in their infancy. It’s clearly very difficult to write an IDE to enhance JavaScript/Ajax productivity.

Data access capabilities and choice

I think this has been one of the last things to be considered in the RIA stack. Previously browsers have locked down where you can get your data from. Developers were always trying to implement hacks to allow them to do things such as make a web request to a server on a different domain or cross-site scripting to implement HTTP streaming. As the web has opened up to the idea of Mashups, browser and RIA plugin vendors have had to change their stance on cross site security. It’s a difficult line to walk but I believe that the technology that makes retrieving data from multiple sources the easiest, without having to go via a proxy, will have a distinct advantage. Flash and Silverlight are winning the race at the moment with Silverlight’s use of security policy files and Flash’s support for master policy files. For the Ajax solution I still need to research information on HTTP cross domain access control headers and which browsers have implemented support for them. I still think there will be an argument for mashing up your data on the server and I have a blog post planned on RTRIA server technologies.

The important questions around RIA data are:

• Which RIA will be more efficient at consuming data?
• Which one will prove to be the most capable as a Real-Time Rich Internet Application (RTRIA)?
• Will RIA technology vendors try to lock developers into using a client-server technology stack, such as Adobe may be trying to do with LCDS and Flex, and will this put developers off?
• Is decoupling of server and client technology, and communication protocol, important? I think it is, do you?

Although RIAs have been around for a while now, as Patrick said, the race to dominate the Rich Internet Application Technology space is on.

Related posts:

1. Real-Time Rich Internet Applications (RTRIA)
2. Using real-time web software and technology to distribute events
3. Using Fiddler to trick Silverlight into allowing a crossdomain Web Request

The Code

First, and this is Important:

Now that you are aware of that, you will also need the Silverlight development environment. You can get everything you need via the Silverlight Getting Started page.

You’ve now got everything you need to run the RTRIA example. To run the sample application you should set the MSDNFlashRTRIAExample.Web project as the startup project and the MSDNFlashRTRIAExampleTestPage.html page as the startup page.

Setting up the solution to run the application

If you’d like to find out a bit more about the code then read on. If you’d rather jump straight into the code you can download it from the TweetStreamer Google Code project.

The streaming connection

The following extracts of code may be slightly modified but that has been done to be able to explain what the code does in general a bit better.

The following extract is used to establish a connection to the Twitter real-time data stream using a HttpWebRequest. The important thing to note is the use of request.AllowReadStreamBuffering = false; which is required since we are requesting a streaming feed. Without setting the AllowReadStreamBuffering property to false the ConnectionResponseCallback callback will not be invoked because the response will be continuously buffering.

Since the Twitter real-time data stream requires authentication, and we can’t set Credentials on the HttpWebRequest in Silverlight, the browser will prompt the user for a username and password.

private const string SPRITZER_URL = "http://stream.twitter.com/1/statuses/sample.json";

/// <summary>
/// Starts the connection to the Twitter real-time data stream.
/// </summary>
public void Connect()
{
    this.InternalConnectionStatus = ConnectionStatus.Connecting;

    try
    {
        HttpWebRequest request = (HttpWebRequest)WebRequest.Create(new Uri(SPRITZER_URL));
        request.AllowReadStreamBuffering = false;
        request.BeginGetResponse(ConnectionResponseCallback, request);
    }
    catch (Exception ex)
    {
        Debug.WriteLine(ex);
        this.InternalConnectionStatus = ConnectionStatus.Disconnected;
    }
}

Within the callback method we ensure that we are connected and then call the ReadResponseStream method which will not return until we call Disconnect().

/// <summary>
/// Called when the initial connection has been established.
/// </summary>
private void ConnectionResponseCallback(IAsyncResult asynchronousResult)
{
    try
    {
        HttpWebRequest request = (HttpWebRequest)asynchronousResult.AsyncState;
        using (HttpWebResponse response = (HttpWebResponse)request.EndGetResponse(asynchronousResult))
        {
            if (response.StatusCode == HttpStatusCode.OK)
            {
                this.InternalConnectionStatus = ConnectionStatus.Connected;

                this.ReadResponseStream(request, response);

                if (this.InternalConnectionStatus != ConnectionStatus.Disconnecting)
                {
                    // unexpected status
                    Debug.WriteLine("unexpected connection status: " + this.InternalConnectionStatus);
                }
            }
            else
            {
                Debug.WriteLine("unexpected status code: " + response.StatusCode);
            }
        }

        this.InternalConnectionStatus = ConnectionStatus.Disconnected;
    }
    catch (Exception ex)
    {
        Debug.WriteLine(ex);
    }
}

In the ReadResponseStream method we continually read the stream until we are interrupted by the user setting the connection status to a value other than ConnectionStatus.Connected, by calling the Disconnect() method, or an exception is thrown whilst reading from the stream. For each read from the stream we parse the data to get the tweets from the real-time data feed in JSON format.

/// <summary>
/// Reads the information received from the Twitter real-time data stream.
/// </summary>
private void ReadResponseStream(HttpWebRequest request, HttpWebResponse response)
{
    byte[] buffer = new byte[65536];
    using (Stream stream = response.GetResponseStream())
    {
        while (this.InternalConnectionStatus == ConnectionStatus.Connected)
        {
            int read = stream.Read(buffer, 0, buffer.Length);
            UTF8Encoding encoding = new UTF8Encoding();
            string data = encoding.GetString(buffer, 0, read);
            ParseResponseChunk(data);
        }

        // need to call request.Abort or the the thread will block at the end of
        // the using block.
        request.Abort();
    }
}

The ParseResponseChunk checks the data it’s passed and ensures that the data contains at least one full status message (tweet). I’ll not go into the details of that here since it’s just a matter of string parsing.

I chose to use the JSON format simply because the content passed over the wire is smaller than the XML feed. This should mean that the application has to do less work to read all the data. What we really should also do is benchmark the deserialisation of JSON against the deserialisation of XML to see which performs best within a Silverlight application.

Deserialising the JSON

The following JavaScript JSON snipped shows an example of a single Tweet that we get back from the Twitter real-time data feed.

{
    "in_reply_to_status_id":9999999,
    "in_reply_to_user_id":00000000,
    "favorited":false,
    "in_reply_to_screen_name":"leggetter",
    "text":"@leggetter Wow! A Real-Time Rich Internet Application (RTRIA)",
    "id":2820354600,
    "created_at":"Fri Nov 4 09:39:33 +0000 2009",
    "truncated":false,
    "source":"<a href=\"http:\/\/tweetdeck.com\/\">TweetDeck<\/a>"
}

The JSON can be deserialised as an instance of a C# class using the DataContract attribute on the class and the DataMember attributes on properties.

using System;
using System.Runtime.Serialization.Json;
using System.Runtime.Serialization;
using System.ComponentModel;

namespace TweetStreamer
{
    [DataContract]
    public class StatusMessage : IStatusMessage, INotifyPropertyChanged
    {
        [DataMember(Name = "text")]
        public string Text {get;set}
    }
}

A single Tweet, or in TweetStreamer a StatusMessage, can be deserialised using an instance of the DataContractJsonSerializer.

/// <summary>
/// Creates a single message from json string.
/// </summary>
/// <param name="messageData">The message data.</param>
/// <returns></returns>
private static IStatusMessage CreateMessageFromJsonString(string messageData)
{
    Debug.WriteLine(String.Format("Creating StatusMessage for: {0}", messageData));

    IStatusMessage message = null;

    using (MemoryStream stream = new MemoryStream(UTF8Encoding.UTF8.GetBytes(messageData)))
    {
        DataContractJsonSerializer ser = new DataContractJsonSerializer(typeof(StatusMessage));
        message = ser.ReadObject(stream) as StatusMessage;
    }

    if (string.IsNullOrEmpty(message.Id))
    {
        message = null;
        Debug.WriteLine("message had no ID. Assuming to be a delete message so nulling message object");
    }

    return message;
}

Binding the data to the grid

To bind the data to a DataGrid the grid needs to be defined in XAML. In addition we can specify the properties on the StatusMessage that we want to bind to columns. In the XAML below we are binding the CreatedAtString property to a Time column, a User.ScreenName to a User column, and a Text property to a Message column. Notice the cool binding of User.ScreenName. The StatusMessage.User property returns an instance of another class and we are actually binding to a property on the returned class.

<data:DataGrid Grid.Row="0" x:Name="Tweets" AutoGenerateColumns="False">
    <data:DataGrid.Columns>
        <data:DataGridTextColumn Header="Time"
            Binding="{Binding CreatedAtString}" />
        <data:DataGridTextColumn Header="User"
            Binding="{Binding User.ScreenName}" />
        <data:DataGridTextColumn Header="Message"
            Binding="{Binding Text}" />
    </data:DataGrid.Columns>
</data:DataGrid>

Next, the code to set up the binding and registering for StatusMessage updates using the StatusMessageReceived event. As you many have noticed, the StatusMessage object implements the INotifyPropertyChanged interface. This was used so that we could add each StatusMessage to an ObservableCollection<T> and then bind it to a DataGrid to display the Tweets in real-time.

Connection _twitterConnection;
ObservableCollection<IStatusMessage> _messages = new ObservableCollection<IStatusMessage>();
public MainPage()
{
    InitializeComponent();

    Tweets.ItemsSource = _messages;

    _twitterConnection = new Connection();
    _twitterConnection.StatusMessageReceived += new Connection.OnStatusMessageReceivedEventHandler
        (twitterConnection_StatusMessageReceived);
    _twitterConnection.Connect();
}

Finally, whenever we get a StatusMessageReceived callback we need to add the new StatusMessage to the ObservableCollection collection. This has to be done on the UI thread and via the Tweets.ItemsSource property or the UI will not update.

/// <summary>
/// Status message received event handler.
/// </summary>
/// <param name="sender"></param>
/// <param name="args"></param>
void twitterConnection_StatusMessageReceived(object sender, IStatusMessageReceivedEventArgs args)
{
    Dispatcher.BeginInvoke(() =>
        AddMessage(args.Message)
    );
}

/// <summary>
/// Adds a message to the observable message list which updates the UI.
/// </summary>
/// <param name="message"></param>
void AddMessage(IStatusMessage message)
{
    ObservableCollection<IStatusMessage> messageList = ((ObservableCollection<IStatusMessage>)Tweets.ItemsSource);
    messageList.Insert(0, message);
}

Hopefully this will have helped you understand how the Twitter real-time data stream is consumed and an example of how you can use it within a Real-Time Rich Internet Application. Now, why now download the TweetStreamer library and example application and have a play.

Download

You can download the source from the TweetStreamer Google Code project.

Screencast

This screencast was supposed to be short but ended up being just shy of 10 minutes. In it I provide some technical detail of how I built the application, show the basics of how Fiddler is used to give access to the Twitter real-time data stream, and give a demo of the application.

Related posts:

1. Real-Time Rich Internet Applications (RTRIA)
2. Which Rich Internet Application Technology will dominate?
3. Using Fiddler to trick Silverlight into allowing a crossdomain Web Request

How Silverlight makes a web request

If you were making a web request from Silverlight to download the following page:

http://www.leggetter.co.uk/2009/10/23/how-i-approach-problem-solving-in-code.html

The Silverlight runtime would first request

http://www.leggetter.co.uk/clientaccesspolicy.xml

If this request fails it will then request

http://www.leggetter.co.uk/crossdomain.xml

If both of these requests fail (return a 404 HTTP status) the Silverlight runtime will not allow you to make your web request. *

* Note: The web request failure due to a failure to download a security policy file can manifest itself in a number of ways. I’ll try to remember to put a post up about this later.

The clientaccesspolicy.xml file is Microsoft’s own security policy file. The crossdomain.xml file is used by Adobe Flash but is also supported by Silverlight. For more information see master-policy file.

Now that we’ve got the background information out of the way we can get on to the interesting stuff.

An example using the Twitter Streaming Feed

If you wanted to write your own Real-Time Rich Internet Application (RTRIA) that consumed data from the Twitter real-time data stream you’d be stuck. Well, you’ll be stuck until Twitter puts a security policy file up **. Until then you can trick the Silverlight runtime by using Fiddler to detect the security policy file request and fake a response.

** The following URLs are where Twitter would put their security policy files should they decide to allow cross domain access. Please not that you’ll be prompted for your Twitter username and password if you click on them by the browser because you need to sign in with valid twitter credentials to access the twitter stream domain: http://stream.twitter.com/clientaccesspolicy.xml and http://stream.twitter.com/crossdomain.xml)

To do this you will need to set up an AutoResponder in Fiddler that intercepts the request for the security policy file by the Silverlight runtime and returns a fake security policy file. In the example below I have an AutoResponder set up for http://stream.twitter.com/crossdomain.xml.

Using Fiddler to AutoRespond with a fake Security Policy File

Here’s an example of a crossdomain.xml security policy file which grants access to requests from all domains.

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy
  SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
  <allow-access-from domain="*" />
</cross-domain-policy>

Once you’ve set up the AutoResponder start Fiddler. Then start your Silverlight application that is trying to stream data from Twitter and bingo! You should have real-time data from Twitter in your RIA – a Real-Time Rich Internet Application (RTRIA).

Fiddler HTTP Proxy Screencast

Related posts:

1. How to make a cross domain web request with SilverLight 2
2. Silverlight uses XCP tmp files for Web Requests
3. Using Fiddler to help develop cross domain capable JavaScript web applications

I mentioned RTRIAs for the first time back in April 2009 in a post called “What is the real-time web” on the Caplin Systems Platformability blog, and since then there has been a real-time web explosion. The “real-time web” is now the buzz phrase around the Internet that everybody is jumping on. Back in April I set up a Google Alert for the term “real-time web”. Back then I got maybe one Google Alert a day for this term, probably less. Now, I get at least two dense emails a day from Google with people using the term for all sorts of things; real-time web stats, real-time analytics, real-time search, rssCloud, pubsubhubbub, the list goes on. This is not the real-time web! Whilst some of the things on this list will help  the web become truly real-time (rssCloud and pubsubhubbub may even form the back bone), none of these things give the user a truly real-time web experience.

My opinion about what the real-time web is has not changed from that first blog post. For me, it’s not just about data being available as soon as it’s been published. In this situation the user still has to actively make a request to see if any data is available. Instead it’s about making a single request for data (a subscription) and that data being pushed to your RIA to be consumed by the application user in real-time. Quite a few applications have implemented a polling solution (more on this later) but the experience presented to the user is not truly real-time.

"Real-Time?"

In my opinion the only way to guarantee being able to deliver truly real-time data (TRTD) to a web application is by maintaining a streaming connection to the source of the data using a continuous streaming HTTP connection. Most web applications use a technique called polling or long polling to retrieve their data which means that although the data is initially “fresh”, within seconds it could be out of date, or more information may be available. I’ll discuss server technologies further in a later post.

At the moment there are a number of technologies that allow you to develop RTRIAs. Ajax, Silverlight and Flash are the three mainstream solutions. The core barriers to RTRIAs are the scalability of server technology and access to truly real-time data.

Related posts:

1. Which Rich Internet Application Technology will dominate?
2. The ChristmasCrunch nearly real-time web event
3. Using Fiddler to trick Silverlight into allowing a crossdomain Web Request