IRhetoric - Karsten Januszewski : WCF

Windows Communication Foundation (WCF) Coding Practices By IDesign

karstenj — Thu, 07 Dec 2006 02:12:00 GMT

When doing some WCF coding not too long ago, I came across the IDesign code samples by Juval Lowry, whose work I was familiar with from MSDN magazine. IDesign just recently published a paper on WCF coding guidelines which I would highly recommend. The paper is short and sweet and cuts to the chase of many best practices for WCF that can be difficult to understand from the SDK. When working with a platform as vast as WCF, this comes in very handy.

We need the corresponding document for WPF.

WCF Calls Hanging Without Any Debug or Fault Information

karstenj — Wed, 15 Nov 2006 21:47:00 GMT

I recently encountered a confusing issue with WCF. An application that worked fine on RC1 suddenly started intermittently failing on the release build of .NET 3.0. What was most perplexing was that no errors were returned, no debug information was provided, nothing. Calls from the client to the server never returned but just hung and the server provided no fault information. It was as if messages just went into the aether.

After some consultation with the WCF team, it was determined that changes to the default serviceThrottling behavior between builds was the culprit. The defaults are 16 MaxConcurrentCalls and 10 MaxConcurrentSessions, which was changed between RC1 and the final release. So, the calls from the client truly were heading into the aether and the server wasn't able to provide any information because it wasn't able to even process them. Why was the server getting so hammered from just a single client? In this case, the client was spawning multiple threads (~10 proxies) and issuing multiple asynchronous requests (~15) from each proxy. You do the math and you can see what was happening.

The fix was to do two things. First, the <behaviors> section of the app.config file was updated as follows:

Note that I'm not an WCF expert and I'm not sure the sweet spot as far as performance vs. throughput when tweaking these numbers.

The other thing that was done to the application was to reel back the client a bit so that it wasn't hammering the server with so many simultaneous requests. Fewer proxies were spawned and fewer requests were sent. There was no degradation in performance when doing this, as the client couldn't handle all the responses it got anyway.

The moral of the story? If your WCF service starts misbehaving without any diagnostics, this may be the culprit.

Oh, and if you are still editing your WCF app.config file by hand, then you must immediately open SvcConfigEditor.exe from the SDK bin.

Inter Process Communication Between Applications and Vista Gadgets Using WCF (Part 2)

karstenj — Sat, 21 Oct 2006 01:17:00 GMT

Once I got WCF working in a gadget, another scenario came up: wouldn't it be nice if the gadget and the application shared a data model? The gadget could remotely databind to the same data that the application was databound to. As such, there would be one data source, owned by the application, that the gadget could both manipulate as well as receive updates when things changed. To be clear, there are not two data sources that I am trying to keep in sync, but rather one data source owned by the application which the gadget reads and writes to. (It does have a "local copy" but from the code never touches the "local copy" and only manipulates the data source through its proxy class to the master copy.) I wanted to use as much of the WPF databinding as I could to try and get some of the databinding goodness for free. I based the code on a sample in the SDK under the WCF samples called Data Binding in a Windows Presentation Client. Also, I found this blog post helpful.

Download the code and gadgets.

The architecture is different than my earlier example because there is a more pure client/server relationship between the application and the gadget. The application acts purely as the server and really could care less if it has any clients. The gadget acts as a client only, unlike my earlier sample.

Similar to my earlier sample, I removed the metadata exchange and share type between projects. Again, because no one else will be using the service, it turns out to be simpler to just share the code and not rely on the proxy code generation tool. In this case, I have have data contracts shared as well as contract. The contract itself is a bit trickier because I am using a Duplex channel, which is what allows the application to notify the gadget that data has changed. As such, I decorate the contract with the SessionMode=SessionMode.Required attribute. I then decorate the server implementation of the contract with [ServiceBehavior(InstanceContextMode = InstanceContextMode.Single,ConcurrencyMode = ConcurrencyMode.Multiple)]. Notice that I still have an InstanceContextMode of single, so that I only have one instance of the service object, but I allow a ConcurrencyMode of multiple, so that if there were multiple clients to the service, all would still be hunky dory. (Thanks to Craig McMurtry for helping understand the right choices to make here.)

In the implementation of the service, I used a trick I picked up from the fantastic samples up at the IDesign site. Basically, I use their technique of registering a list of clients through the use of a Connect method. Once a client is registered, it can be called back from the server. The convention of Disconnect allows the server to clean up any subscribers. Nice!

As I mentioned earlier, I wanted to try to preserve as much databinding goodness as I could. As such, I subclasses ObservableCollection and overrode the OnCollectionChanged event. It is within this event that I callback to any listeners to let them know that the data has changed. Unfortunately, I couldn't simply serialize the NotifyCollectionChangedEventArgs. As such, it would take quite a bit of custom code to truly serialize this event -- looking at Reflector is a good start if you are interested in doing this. For my purposes, I just notify the client that the data has changed so that they can rebind. It is worth calling out that this same technique could be used to serialize the INotifyPropertyChanged event as well, for more granular control over changes instead of the brute force approach I took here.

One thing I do in the client (which I also learned from the IDesign site) was to create my own asynchronous proxy class, rather than having the svcutil tool generate it for me. I then use a slightly different technique in instantiating the client than I did in part 1. This time, I create a DuplexChannelFactory which I use to new up clients to the service. Another thing I did was not use config files but rather I have things like the endpoint hardcoded into the app -- more secure.

I do something simliar as I did in part 1 as far as making the gadget reliable in the event that the application isn't running by wrapping the initial Connect operation in a do/while statement, nulling out a client object if it fails to connect.

The asynchronous databinding is entirely lifted from the SDK sample other than the moment where I get a callback. At first I tried to call the service as soon as I received the CollectionChanged notification. However, this created a race condition. So, I call the service on a background thread when I receive the callback, which worked out fine.

The WPF code itself is wrapped up in an ActiveX control, as discussed in this post. Nothing new here. Of course, installing the ActiveX control requires elevation.

So, to get the sample working, first run the install.cmd from a cmd prompt run as administrator to register the ActiveX control. Then, compile the databinding_serv.sln file in the sources directory. Again, if you don't have VS on your Vista box, you can use this trick from Tim Sneath to compile from a command line. You'll notice that the gadget binds to the application's data whenever the application comes online. If you update the data in the application, the gadget will get updated. And if you update the data in the gadget, the application's data is updated. Note that I never manipulate the data directly within the gadget, but always through the proxy. Also, note that I rebind to the gadget data every time, which isn't super efficient and could be a problem with larger data sets. Of course, it is communication on the same box, which is pretty darned fast. Go WCF!

Download the code and gadgets.

Inter Process Communication Between Applications and Vista Gadgets Using WCF (Part 1)

karstenj — Sat, 21 Oct 2006 00:46:00 GMT

I recently faced the design challenge of getting an application and gadget to communicate. How to solve the problem? Well, what better way to talk between applications than Windows Communication Foundation (WCF). After all, it is the inheritor of the .NET Remoting legacy, which is what would be used in the past. It was quite enjoyable to return to writing WCF code, which I hadn't done for awhile. It really is the analog to WPF in terms of beautifully factored code architecture. In part 1, I'll show my first prototype, which used an XBAP gadget acting as both a server and a client that sends mouse movements over WCF to trackball either the application or the gadget. In part 2, I'll show my second prototype, which shows an ActiveX-based gadget acting as a client to the application and databinding to the application's data model. I subclass ObservableCollection and show the beginnings of what I dubbed SerializedObservableCollection. Download the code and gadgets.

Before explaining how I went about coding this, please be aware of all the issues with WPF gadgets raised in this post.

Part 1

The first project remotes mouse move behaviors such that you can trackball the gadget and change the application. Or, you can trackball the application and update the gadget. In this case, the gadget is an XBAP. Now, because XBAPs run in partial trust, I had to change the XBAP security settings to allow for WCF, which requires full trust. This was just a matter of tweaking the settings in the security tab of the project properties. Because the XBAP is being launched from the file system, this does not present any deployment problems. Were the XBAP to be deployed from a serer, the certificate used to sign the XBAP needs to be installed in the trusted publishers list on the user's machine. In an installation routine, one could call certmgr /i under the covers. The other option here would be to place the WCF code in a seperate assembly marked as Allow Partially Trusted Callers (APTCA) and register it in the GAC. To protect the APTCA assembly, it should be locked down using FriendsAssembly concept (InternalsVisibleTo). That way only the Xbap that put the APTCA assembly can call into it. In this case, XBAP itself can stay in sandbox but APTCA assembly acts as a proxy between XBAP and full trust calls. I haven't done this myself but I've been told it works.

The way the WCF architecture works in this sample is that the gadget and application each act as both a server and a client. So, when you are trackballing the gadget, it is acting as a client to the application and sends messages about mouse position to the application, which is listening. As soon as the application is trackballed, the roles flip and the application then acts as the client and sends its mouse events to the gadget, which listens as a server.

All the communication uses the netNamedPipe binding of WCF. This is established in the app.config file. One interesting fact is that the messages between the app and gadget are signed and encrypted, which is cool. No other rogue application could sniff the traffic between the gadget and application. I have turned off the metadata exchange features of WCF. This means that to create my client proxy for talking to the service, I had to either use svcutil.exe on the application itself or, rather than generate a client, I could just craft up my own proxy, which I did. After all, no one else is going to consume the service but my own code. In fact, all the code is in a dll called RemoteMouse, which is shared by the XBAP gadget project and the application.

One area that was a little tricky was protecting both the gadget and the application for the possbility that one would not be alive. I achieved this by instantiating the client proxy on a seperate thread. If I get an exception from the server -- which would most likely occur if the gadget wasn't launched or the application wasn't launched -- I brute force null out the client and create a new one in a do/while loop every second. This might sound expensive, but turns out not to be. I found this approach easier than handling lots of events within WCF around the CommunicationState enumeration. One thing I don't do is nicely disconnect from the server, which I should do.

The way I host WCF within WPF is based on a sample in the SDK in the Cross Technology Samples/Integration Samples for the .NET Framework 3.0 Features called Hosting A WCF Service in WPF. It turns out to be pretty simple and elegant. I have an interface called IDisplay, which is implemented by the Trackball control. Then, when I create the WCF service, I pass a reference to the trackball class to the service in the constructor to the service. I can then call methods on the trackball from the WCF service. Pretty nifty!

To install, double click the RemoteMouse.gadget file. Then, compile the cubeapp_exe solution. If you don't have VS installed on Vista, no problem. Just use the trick Tim Sneath outlines here, as every build of Vista has all the tools needed to compile .NET 3.0 apps.

Download the code and gadgets.