Locations

Blog Stats

Posts Tagged ‘Storyboard’

Introduction

This post attempts to highlight some of the intricacies involved in connecting a WPF Client to the existing Silverlight 2 Polling Duplex demo previously published on this blog. To recap, the demo consists of a WCF service designed to push Stock data to previously connected Silverlight 2 clients over Http. In a similar scenario to a chat application, the Silverlight 2 clients can also send ‘Note’ messages back to the server and have them propagated to other connected clients.

The aim of this post is to make the demo capable of also supporting connections from WPF clients. Success is defined by enabling WPF clients to connect to the same WCF service, receive the same Stock updates at the same time as the Silverlight 2 clients and having Notes synchronized across all connected clients regardless of their underlying technology. Below is a link to a screenshot of the final version of this demo running, shown is the Console Application hosting the WCF service with two Silverlight clients and one WPF client connected:

PollingDuplexHttpBinding and WPF clients

Up until this point the demo application has solely supported pushing data to Silverlight 2 clients, defining a PollingDuplexHttpBinding endpoint on the server side and creating a channel factory as part of the Silverlight 2 client as shown below:

However, attempting to use PollingDuplexHttpBinding for this purpose in a WPF application (as in the code above) currently results in a NotSupportedException exception being raised with a full explanation and even some architectural advice:

PollingDuplexHttpBinding cannot currently be used in non-Silverlight clients without running into this exception. In order to extend the demo to support pushing Stock data to a WPF client through Http the guidance from the above exception is to consider WSDualHttpBinding. This binding predates Silverlight and is the closest alternative for achieving equivalent results to PollingDuplexHttpBinding in a non-Silverlight client application. A look at the BindingElement objects each binding encapsulates reveals WSDualHttpBinding is actually a much more mature binding than PollingDuplexHttpBinding:

WSDualHttpBinding

PollingDuplexHttpBinding

TransactionFlowBindingElement

PollingDuplexBindingElement

ReliableSessionBindingElement

TextMessageEncodingBindingElement

SymmetricSecurityBindingElement

HttpTransportBindingElement

CompositeDuplexBindingElement

OneWayBindingElement

TextMessageEncodingBindingElement

HttpTransportBindingElement

The WSDualHttpBinding Endpoint

The outcome of acting on the aforementioned advice in the demo application is the addition of a new endpoint to the WCF service exposed from the StockServer Console Application. This could easily be specified entirely in a configuration file (see this post for how to configure the Silverlight policy and duplex endpoints) but in the download is achieved in code as shown below:

Although the WSDualHttpBinding endpoint is registered using a different URI, the endpoint is simply just another entry point into the same WCF service called by the existing Silverlight 2 clients using PollingDuplexHttpBinding. Before you can push data from a WCF duplex service to a client, the client must initiate the session by calling the service. The Register method serves this purpose in the demo application and the only change to the code in the WCF service itself (although there are no method signature changes) is in this method as shown below:

The change is minor but essential: extracting the MessageVersion from the initial message sent by the client and passing it to the constructor of the StockClient object along with a reference to the channel back to that client. The variety of MessageVersion used by each of the bindings in the demo application is as follows:

Binding

MessageVersion

WSDualHttpBinding

MessageVersion.Soap12WSAddressing10

PollingDuplexHttpBinding

MessageVersion.Soap11

Messages sent between WSDualHttpBinding endpoints use the SOAP 1.2 protocol; between PollingDuplexHttpBinding endpoints the SOAP 1.1 protocol is employed. There is a clue in the name of MessageVersion. Soap12WSAddressing10 that WSDualHttpBinding also requires addressing headers to support reliable messaging sessions via ReliableSessionBindingElement. In the case of these two bindings, attempting to use a mismatch of MessageVersion and binding, for example MessageVersion.Soap11 for messages sent to a WSDualHttpBinding endpoint, results in an InvalidOperationException as shown below:

Storing the message version along with the channel reference in an instance of the StockClient class (see code download) ensures the reply messages are pushed back to the client in the format the relevant binding expects. The rest of the WCF service remains the same: a new instance of StockService is created per session regardless of the endpoint used. Each session registers it’s interest in the DeltaReceived event of the singleton StockGenerator class. This event is raised approx every 250 milliseconds and each session’s handler (OnDeltaReceived) sends the same generated delta to its respective client via the stored channel reference using the appropriate message protocol.

The WPF Client Application

In a good advertisement for how nearly all of what you write in Silverlight 2 can be used without modification in WPF, the code in the WPF client application is extremely similar to that contained in the Silverlight 2 client project. The markup in StockWindow.xaml and code in StockWindow.xaml.cs is virtually identical to Page.xaml and Page.xaml.cs in the Silverlight 2 project.

One difference between the WPF and Silverlight client code is the WPF DataGrid which is from the October 2008 Release of the WPF Toolkit available from codeplex. Another difference already highlighted is that PollingDuplexHttpBinding cannot be used in a non-Silverlight client application. In its place we use WSDualHttpBinding on the WPF client side also and due to this binding’s maturity the code in StockTicker.cs is less verbose as shown below:

using System;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.ServiceModel.Channels;
using System.Windows.Threading;
using Common;
namespace WpfStockClient
{
public sealed class StockTicker : IStockClient
{
// Reference to layout instance that created the StockTicker
private readonly Dispatcher owner = null;
// Serializes instances of the Stock type before they are sent on the wire
private readonly DataContractSerializer stockSerializer = new DataContractSerializer(typeof(Stock));
// Proxy for communication to WCF service
private IStockService proxy;
// List of stocks designed to be bound to a UI control
private readonly StockList stockList = new StockList();
public StockList StockList
{
get { return stockList; }
}
public StockTicker(Dispatcher owner)
{
if (owner == null)
{
throw new ArgumentNullException("owner");
}
this.owner = owner;
}
public void SubscribeDeltas()
{
EndpointAddress endPoint = new EndpointAddress("http://localhost:10201/WpfStockService");
proxy = new DuplexChannelFactory<IStockService>(this,
new WSDualHttpBinding(WSDualHttpSecurityMode.None),
endPoint).CreateChannel();
proxy.Register(Message.CreateMessage(MessageVersion.Soap12WSAddressing10, "StockClient/IStockService/Register"));
}
public void Receive(Message message)
{
Stock stock = message.GetBody<Stock>();
// Queue a call to UpdateStockList on the Dispatcher of the thread that created this instance
Action<Stock> action = UpdateStockList;
owner.BeginInvoke(action, stock);
}
public void Sync(Stock stock)
{
// Create a message with the appropriate SOAPAction and asynchronously send it via the proxy with the serialized Stock as the body of the envelope
Message message = Message.CreateMessage(MessageVersion.Soap12WSAddressing10, "StockClient/IStockService/Sync", stock, stockSerializer);
proxy.Sync(message);
}
private void UpdateStockList(Stock delta)
{
// NOTE : CheckAccess is there but intellisense doesn't see it because of the [EditorBrowsable(EditorBrowsableState.Never)] attribute
if (!owner.CheckAccess())
{
throw new InvalidOperationException("The calling thread cannot access this method because a different thread owns it.");
}
// Check if this Stock is already in the collection
Stock existing = stockList.FirstOrDefault(s => s.Symbol == delta.Symbol);
if (existing == default(Stock))
{
// This delta is a new Stock
stockList.Add(new StockHighlight(delta));
}
else
{
// This delta is an existing Stock
existing.Ask = delta.Ask;
existing.Bid = delta.Bid;
if (!String.IsNullOrEmpty(delta.Notes))
{
existing.Notes = delta.Notes;
}
}
}
}
}

There are many similarities between the above code and the Silverlight 2 version; the changes are all centred on the body of the SubscribeDeltas method. This is where the client instance of the WSDualHttpBinding class is instantiated and used to establish a composite duplex channel (two one-way channels) with the new endpoint at the address exposed in the WCF service. The first parameter passed to the DuplexChannelFactory<IStockService> constructor specifies ‘this’ as the instance of the IStockService interface to receive the pushed messages from the WCF service in the Receive method. After the channel is created the initial message is sent using the correct MessageVersion as described earlier.

Linked Common Files

Those class files that are identical across both client projects are added to the Common Solution folder and are referenced using links from the respective projects where they are used:

The highlighted classes are written in one place and as such are assured of being the same structure throughout the solution (and where relevant on both sides of the wire as a consequence). As the files are linked, the code they contain will be compiled into IL that targets the respective version of the CLR implied by the type of project the classes are linked from. For the WPF project the linked classes will be compiled into an assembly that targets the desktop CLR, for the Silverlight project the linked classes will be compiled into an assembly that targets the more compact CoreCLR. Linking common files in this manner is one solution to the problem normally solved by using a class library when a common CLR is targeted by all projects.

Animating the Stock Price changes

Illustrating changes to Stock price instances displayed in the DataGrid by creating the illusion that the DataGrid cell background is changing color takes less code in WPF than in Silverlight. The code for this animation for both WPF and Silverlight 2 is contained in the StockHighlight class. The entire contents of the StockHighlight.cs file is shown below, the code between the #if and #endif directives is compiled only if the SILVERLIGHT symbol is defined as it is in the Build tab of project properties on all default Silverlight 2 projects:

The targets of the animation are the two public SolidColorBrush properties, AskHighlight and BidHighlight. The Color dependency property of these brushes is animated using color key frame animation from green for a positive change or red for a negative change. The animation for both WPF and Silverlight begins with a call to the BeginHighlight method when the corresponding Ask or Bid price property changes. The SILVERLIGHT debug symbol makes it clear to see the extra Storyboard objects and extra initialization required in the InitializeAnimation method to achieve the desired effect in Silverlight 2. You can see the references to these AskHighlight and BidHighlight properties in the WPF XAML below, also notice the xmlns:data for the DataGrid from the WPF Toolkit:

Introduction

This is the third and final post in my current series on the support for duplex communication with a WCF service added to Silverlight 2 Beta 2. I should point out that this technology in its current form has been deemed by Microsoft as not yet fit for production applications and is therefore currently for evaluation only. In this post I introduce the client part of a sample application available for download (the download includes the server discussed in the previous post also) that uses the bi-directional communication discussed in part one. The sample application as a whole represents a simple client and server application that illustrates polling duplex communication in both directions. The client displays stock prices in a grid and animates updates received from the server. The user of the client application can also enter notes against a stock and have those notes propagate to all other connected clients via the server using polling duplex communication in the other direction. Here is a screenshot of the sample application running with the server and two connected clients, the same stock price updates are being displayed by both clients and the notes entered in Internet Explorer have been pushed to another instance of the client running in Firefox:

The Client

The layout of the Visual Studio 2008 solution is as follows:

There are three projects in the PollingDuplexDemo solution, the first is the Silverlight Application project StockClient that references the client-side version of System.ServiceModel.PollingDuplex.dll. The .xap file produced by building this project is referenced by the Silverlight ASP.NET server control in the StockClientTestPage.aspx file as part of the hosting StockClientHost Web Application project. The StockServer project is a Console Application project that self-hosts the polling duplex WCF service. As you can see from the image there are multiple startup projects, the first to start is the StockServer project along with the StockClientHost project shortly after.

Page.xaml and Page.xaml.cs

The markup in Page.xaml (see code download) defines the StocksGrid Silverlight DataGrid along with the rest of the UI elements, the code in Page.xaml.cs adds some initialisation code to the default constructor and handlers for some UI events. When the Silverlight Application loads and assigns an instance of the Page class defined across these files to the RootVisual property of the Application class, the constructor shown below is executed:

The StockTicker Class

It’s apparent from the code above that the instance of the StockTicker class is central to everything happening in the client application and indeed it’s the code in this class that implements the client-side PollingDuplex support:

namespace StockClient
{
public sealed class StockTicker
{
// Reference to layout instance that created the StockTicker
private readonly Dispatcher owner = null;
// Object used to let ThreadPool know to stop waiting and proceed
private readonly AutoResetEvent waitObject = new AutoResetEvent(false);
// Asynchronously begins an open operation on an ICommunicationObject with code to call EndOpen when it completes
private static readonly Action<ICommunicationObject> Open =
ico => ico.BeginOpen(iar => ico.EndOpen(iar), ico);
// Asynchronously begins a send operation on an IDuplexSessionChannel with code to call EndSend when it completes
private static readonly Action<IDuplexSessionChannel, Message> Send =
(idc, msg) => idc.BeginSend(msg, iar => idc.EndSend(iar), idc);
// Asynchronously begins a receive operation on an IDuplexSessionChannel with code to call an Action<Message> when it completes
private static readonly Action<IDuplexSessionChannel, Action<Message>> Receive =
(idc, act) => idc.BeginReceive(iar => act(idc.EndReceive(iar)), idc);
// Serializes instances of the Stock type before they are sent on the wire
private readonly DataContractSerializer stockSerializer = new DataContractSerializer(typeof(Stock));
// Channel for communication to WCF service
private IDuplexSessionChannel channel;
// List of stocks designed to be bound to a UI control
private readonly StockList stockList = new StockList();
public StockList StockList
{
get { return stockList; }
}
public StockTicker(Dispatcher owner)
{
if (owner == null)
{
throw new ArgumentNullException("owner");
}
this.owner = owner;
}
public void SubscribeDeltas()
{
// Create a channel factory capable of producing a channel of type IDuplexSessionChannel
IChannelFactory<IDuplexSessionChannel> factory =
new PollingDuplexHttpBinding().BuildChannelFactory<IDuplexSessionChannel>();
Open(factory);
// Address of the polling duplex server and creation of the channel to that endpoint
EndpointAddress endPoint = new EndpointAddress("http://localhost:10201/StockService");
channel = factory.CreateChannel(endPoint);
Open(channel);
// Create a message with the appropriate SOAPAction and asynchronously send it on the channel
Message message =
Message.CreateMessage(MessageVersion.Soap11, "Silverlight/IStockService/Register");
Send(channel, message);
// Use the thread pool to start only one asynchronous request to Receive messages from the server
// Only start another asynchronous request when a signal is received that the first thread pool thread has received something
ThreadPool.RegisterWaitForSingleObject(waitObject,
delegate { Receive(channel, CompleteReceive); },
null,
Timeout.Infinite,
false);
waitObject.Set();
}
public void Sync(Stock stock)
{
// Create a message with the appropriate SOAPAction and asynchronously send it on the channel with the serialized Stock as the body of the envelope
Message message =
Message.CreateMessage(MessageVersion.Soap11, "Silverlight/IStockService/Sync", stock, stockSerializer);
Send(channel, message);
}
private void CompleteReceive(Message message)
{
// Deserialize the body of the SOAP message into a Stock object
Stock stock = message.GetBody<Stock>();
// Queue a call to UpdateStockList on the Dispatcher of the thread that created this instance
Action<Stock> action = UpdateStockList;
owner.BeginInvoke(action, stock);
// Signal the thread pool to start another single asynchronous request to Receive messages from the server
waitObject.Set();
}
private void UpdateStockList(Stock delta)
{
// NOTE : CheckAccess is there but intellisense doesn't see it because of the [EditorBrowsable(EditorBrowsableState.Never)] attribute
if (!owner.CheckAccess())
{
throw new InvalidOperationException("The calling thread cannot access this method because a different thread owns it.");
}
// Check if this Stock is already in the collection
Stock existing = stockList.FirstOrDefault(s => s.Symbol == delta.Symbol);
if (existing == default(Stock))
{
// This delta is a new Stock
stockList.Add(new StockHighlight(delta));
}
else
{
// This delta is an existing Stock
existing.Ask = delta.Ask;
existing.Bid = delta.Bid;
if (!String.IsNullOrEmpty(delta.Notes))
{
existing.Notes = delta.Notes;
}
}
}
}
}

In order to create an instance of the StockTicker class a reference to an instance of the System.Threading.Dispatcher class is required. In the initialisation of the StockTicker instance in the Page class constructor the Dispatcher property inherited all the way from System.Windows.DependencyObject is used. This provides StockTicker with a queue to add tasks to for execution on the UI thread. It is essential to update collections that may be bound to UI controls (such as the StockList property) from the UI thread to avoid an invalid cross-thread access (UnauthorizedAccessException) exception; this restriction also applies to the animation of individual stock prices using Storyboards managed by the StockHighlight class. The stored Dispatcher reference is later used to queue calls to UpdateStockList to be executed on the UI thread from the CompleteReceive method and to check the correct thread has called UpdateStockList before updating the collection or the Stock properties that cause animation Storyboards to begin.

After the instance of StockTicker has been created in the constructor of the Page class the SubscribeDeltas method is called. This method performs all of the client setup necessary to begin a polling duplex session with the WCF service. The method body begins by creating an instance of the client-side version of PollingDuplexHttpBinding (see part one) and extracting an instance of a channel factory of type IDuplexSessionChannel from that binding. The factory is then opened asynchronously and the channel is created, the client then initiates communication by asynchronously opening the channel to the WCF service specified in EndpointAddress. The method progresses to create a SOAP 1.1 Message instance specifying the One Way Register method discussed in the previous post in the SOAPAction; the instance of this message is then sent asynchronously along the channel to the server. Finally the method uses an AutoResetEvent to signal a ThreadPool thread to begin one asynchronous request to receive messages pushed from the server. When a message is eventually received the CompleteReceive callback method is executed to queue a call back to the UI thread with the received Stock object before signaling the wait handle; this signal in turn prompts the thread pool to release another single asynchronous request to receive another message.

The Sync method creates a new SOAP 1.1 Message with a different SOAPAction and with the Stock parameter (containing the Notes entered by the user) as the body of the envelope serialised via the DataContractSerializer. The method then uses the same channel opened in SubscribeDeltas to asynchronously send the message to the server for propagation to all connected clients. The code for the WCF service methods being called here is discussed in part two, the make up of these asynchronous calls and their responses on the wire is discussed under the ‘Anatomy Of A Message Exchange’ heading In part one.

The UpdateStockList method checks the current thread as previously described and then searches the StockList collection for the current Stock object comparing Symbol properties. A new instance of the StockHighlight class is created to add to StockList if the received stock does not exist in the collection. As StockList is an ObservableCollection this insert will notify the DataGrid that it’s ItemsSource has changed and to update itself to honour the addition in the UI. If the stock already exists then only the relevant price and notes properties on the existing StockHighlight instance are updated, triggering the relevant animations. These updates in turn cause the PropertyChanged event from INotifyPropertyChanged implemented by the Stock class (see code download) to fire again causing the DataGrid to update the UI.

The StockHighlight Class

This class extends the basic Stock class overriding the Ask and Bid properties and exposing two public properties of type Brush:

Each cell in the Bid and Ask columns of the DataGrid declared in Page.xaml contains a StackPanel whose Background property is bound to the respective Brush property. This way each cell is able to play it’s own unique animation specific to the Stock displayed. These Brush properties need to be part of each individual Stock object rather than global resources so the whole column does not change colour when one stock changes price. The InitializeAnimation method associates animations of type ColorAnimationUsingKeyFrames with each of these Brushes for both positive and negative changes. The appropriate Storyboard to play is chosen in the Bid and Ask property setters based on the new value.

The most salient parts of the client code are now covered, download the solution, press F5 to start the server and one client automatically, you can then browse to StockClientTestPage.aspx using the same address from multiple clients in separate browsers once the service is running.

In the future it looks likely that the client side Silverlight 2 Polling Duplex API will be simplified to enable a less verbose method of connecting to and receiving pushed messages from a WCF service. This post talks more about the possibility of a DuplexReceiver<T> class for simple client scenarios in the future; it’s always prudent to know what such a class will be doing for you behind the scenes.

Further Reading

A few links on polling duplex support in Silverlight 2 Beta 2 you might find useful: