Web Services have one great virtue: they're completely interoperable. They also have one great failing: in order to be interoperable, Web Services use a set of technologies that are guaranteed to give you, at best, adequate performance. Fortunately, WCF 4.5 has a solution: support for WebSockets.
Ever since Web Services appeared, developers have been trying to make them run faster. REST and JSON can be seen as a way of speeding things up by reducing the overhead in the messaging format used by Web Services. However, even with REST and JSON you're still moving and parsing text, which is the bulkiest and slowest data transfer mechanism; you'd get better performance if you could move binary data around. And REST and JSON don't tackle another reason for why Web Services give poor performance: HTTP, the network protocol used by Web Services. There are slower protocols than HTTP around, but no one is using them.
But performance isn't the only issue that using HTTP creates: HTTP in Web Services is tied to a request/response cycle. The reason Ajax applications make all their requests asynchronously is because if you call a service that takes a long time to complete, your request has to wait for that response before you can get your result.
On top of that, if your service has something else to tell your client after that initial response (an ongoing set of updates, for instance), then either your client has to make repeated polling calls to the service to get the result (another performance burden) or, in a non-Ajax application, you have to set up a complementary Web Service that the service can call with the updates.
A far better arrangement would be for the client to submit its request in a "fire and forget" kind of arrangement and then for the service to call back to the client when it has the data (and keep calling back if there are updates to send).
WebSockets addresses all of those issues, while still being an industry standard and therefore interoperable (confusions in vendor's implementations of the standard may interfere). In fact, your browser probably already supports WebSockets.
For most processing, WebSockets uses TCP to communicate, giving you the benefit of a faster protocol. WebSockets also supports sending both binary (for speed) and text (for interoperability). But in many ways, the best part of WebSockets is that it supports two-way communication: The client can call the service just to open communication; and after that, the service can call the client whenever it has information to share. And WCF 4.5 provides support for WebSockets.
So in the next few columns, I'm going to look at WebSockets in WCF 4.5. I'll look at the two ways you can implement WebSockets (one complicated and flexible, one simpler and less flexible) and create client a JavaScript client. Along the way I'll also discuss some of the issues you should consider in creating a WebSocket application.
Configuring the Server
One warning: You may not be able to use the code in this series, yet. As I write this (April 2012), WebSockets is only supported on Windows 8 (I worked on the 64-bit beta ISO for Windows 8 Server); even then, you'll need to configure Windows 8 to support WebSockets.
To configure Windows 8, in Server Manager, from the Manage menu, run the Add Server Roles and Features wizard. In the Wizard, you'll need to add the Web Server (IIS) role. After that, under Features, select ASP.NET 4.5 (if it isn't already selected) and, under Web Services, select HTTP Activation. Finally, under Web Services (IIS)/Role Services, select WebSockets. After finishinb the Wizard, select Local Server and set IIS Enhanced Security Configuration to off.
To work with WCF 4.5, you'll need Visual Studio 11 (again, in beta, as I write this). The first time you run it, Visual Studio 11 will probably offer to download an update; if so, take the update (I took the update and I won't guarantee that the following code will work without it).
Second warning: This may be a frustrating set of columns if you're reading them as soon as I post them. I've got a fair amount of ground to cover so, in this column, I'll only be setting up to write the code that a WebSocket service requires. But hang tough; the next column will have the code and subsequent columns will show you how to build the clients and provide an alternative way to build a WebSocket service.
Building the Service
I did my testing with a WCF Service Application Project. To take advantage of IIS's support for WebSockets that I'd just finished configuring, I went to the Web tab of my Project Properties and unchecked the Use IIS Express option so that I was testing with the "real" IIS.
Once you've set up your server and project, the first step in creating your WebSocket service is to define two interfaces: one with a single method that accepts requests from clients and another interface with a single method to send results.
For the first interface, I'll define a method that accepts an Order Id (I call the method OrderStatusById method and the interface IRequestOrderStatusUpdates). In the ServiceContract attribute on the interface that accepts requests, you need to use the attribute's CallbackContract to specify the second interface (the one with the method used to send data back to the client is ISendOrderStatus in this example). The method must accept a Message as its only input parameter and the method's OperationContract attribute must set its IsOneWay property to True and its Action property to an asterisk.
The result for my Order status example looks like this:
<ServiceContract(CallbackContract:=GetType(ISendOrderStatus))>
Public Interface IRequestOrderStatusUpdate
<OperationContract(IsOneWay:=True, Action:="*")>
Sub OrderStatusByID(OrderStatusMessage As Channels.Message)
End Interface
The definition for the return method is similar, except that you don't need any special specifications for the ServiceContract attribute. I've called my method SendOrderStatus:
<ServiceContract()>
Public Interface ISendOrderStatus
<OperationContract(IsOneWay:=True, Action:="*")>
Sub SendOrderStatus(OrderStatusMessage As Channels.Message)
End Interface
At this point you're ready to write the code for these methods, which I'll look at in my next column (the column after that will look at building a client).