As a developer, I always used to implement the observer pattern in software. The principle of the observer pattern is that there is a weak link between the subject and the observers. As a result of this pattern there is bi-directional communication: concrete implementations of the observers call functions on the subject and the subject notifies the observers with events.
One limitation of web-technology over client/server-technology is the single direction of the communication. A javascript function is able to call functions on the webserver and process the return values, but it is not possible to call javascript functions with the webserver.
The question arises why do you ever want to access a javascript function from the webserver? To give an example: an auction-house publishes the actual bids to the customers. Using the traditional approach, a java-script function must poll the webserver continuously for actual prices. With SignalR it is possible to publish the prices tot he webclients using an event. This increases the performance and decreases the load on the webserver. In this case there is also a commercial motive, because bids are directly published to the clients, so clients are able to react faster on a new bid.
The technique SignalR uses is websockets. As a fallback, for browsers which doesn’t support websockets (aka internet explorer), long polling requests are used. Developing SignalR is easy and straightforward. An code-example can be found on https://github.com/SignalR/SignalR/wiki/QuickStart-Hubs. SignalR can also be used in webfarms and azure using the Windows Azure Service Bus.
For more information about SignalR
- Wiki of SignalR => https://github.com/SignalR/SignalR/wiki
- Impressive live chat example of SignalR => http://jabbr.net/
