/bill's House O Insomnia : WIndows Communication Foundation

WF Persistence - Where [DataContract] != [Serializable]

William — Sat, 01 Nov 2008 07:27:07 GMT

Let's say you were using Workflow Foundation (WF) and Windows Communication Foundation (WCF). Assume you wanted to use WF's Persistence mechanism (which requires types to be Serializable). And assume that all the objects you were using in the workflow were decorated with the [DataContract] attribute. Would you expect any problems related to Serialization? (I can but to the chase really quickly here if you don't want my belabored background information and explanation. If you're creating a type to use w/ Workflow Foundation that will be saved via the Workflow Foundation Persistence Service which makes use of the SqlWorkflowPersistenceService class, marking the class as a [DataContract] alone will not work for WF's persistence mechanism. It does make the class serializable in a literal sense and will suffice [provided you meet the other requirements of a [DataContract] for WCF's serialization needs, but it is insufficient for WF (see the References section at the end of this post for more details on WF Serialization) - so make sure you use the Serializable attribute on any type that'll be consumed by the Persistence Service).

MSDN describes the DataContract class the following way:

Specifies that the type defines or implements a data contract and is serializable by a serializer, such as the DataContractSerializer. To make their type serializable, type authors must define a data contract for their type.

If you spend a lot of time in WCF, you'd likely assume that b/c types decorated with the DataContract attribute would satisfy any requirement for the type to be Serializable. But you'd likely be wrong. Yes, a type that is a [DataContract] is serializable in the literal sense, but it's serialized by the DataContractSerializer (see the References section at the end of this post for more details on WF Serialization)

So why is this an issue and what do you do about it? Often, non-trivial workflows span an amount of time that exceeds any given user's session. In fact, it's not uncommon for a non-trivial workflow to span as much as 30 days. Using a simple example, let's say that you are writing a Workflow to manage new employees. Further assume that there are several document requirements and that any deficiencies would result in severe penalties or liability risks. Just to make it clear, assume that each of the following must be procured before a new employee can start working. Further, assume that b/c of fees associated with each, if any previous one fails, that the whole process terminates (if someone's reference checks don't pass, there's no need to spend the money for a full background investigation as you know you're not going to hire them). [Also, this isn't a post on workplace hiring guidelines and is solely used for illustration - no need to point out why 'its bad business to drug test or whatever else].

Employment Application
Proof of Citizenship or ability to work in the U.S.
State withholding form
Federal withholding form
Reference check
License check
Completed Drug Screen
Full Background check

Implementation policies will vary from company to company but assume that all of these tasks wouldn't be completed within the user session that first created the entity. If you couldn't persist the workflow somehow and come back to it later, it would be of very little use. Workflow foundation provides an out-of-the-box solution named not surprisingly - Windows Workflow Persistence Service to help with long running workflows

Since Workflow Foundation is still in its infancy in terms of user adoption, many shops don't have well established design rules in place specifically for Workflow items. This can have some profound (although easily addressed in most cases) effects on Workflow development. It's common for a workflow to start out small in terms of steps and happen relatively quickly. When this is the case, there's little need for a persistence mechanism for the workflow. But as people get comfortable with WF and are willing to try more involved solutions, steps get added that often increase the time span the workflow could run to a point that's longer than the user session. For people new to WF, adding that first activity that'll possibly span a large amount of time is the first time they actually think seriously about the persistence service. And that's the point at which they often go back and try to retrofit things. In many cases, the number of "things" will be fairly substantial so it's quite easy to overlook something. Once you implement the persistence service, you'll typically go through the testing phase and make sure everything persist and can be retrieved correctly. And this is the time serialization problems with show themselves - often in a manner that's hard to isolate b/c the number of items involved.

In some cases, if there's a serialization problem, a fault will result. Unhandled faults in WF cause behavior that deviates from what you'd typically expect. So depending on your logging and tracing, you may or may not find the issue quickly. in many cases, you'll find the fault is related to serialization and you'll address it on the specific type, then go back and try to find every other type and make it serializable as well. This is likely to be overkill though - b/c you're likely to have some types that aren't involved in anything that's persisted and consequently don't require persistence. So you try to only make the items that will be persisted serializable. Until you get to the point where you're addressing everything in the planning and design stages, you're likely to run into situations like this and the only way out typically involves a lot of trial-and-error. That's why this post is relevant. If you go back and define each type that will be persisted as a [DataContract] , it'll take you some time to do, may necessitate you adding new references to some projects and ultimately, after all that's done, won't fix the problem. The following type may work all day long when just dealing with WCF's serialization requirements...

namespace Ger911.HCStandard.Core.Shared
{
    [DataContract]
    public class MatrixItem
    {
        [DataMember]
        public String EntityName { get; set; }
        [DataMember]
        public String ContactName { get; set; }
        [DataMember]
        public Int32 BedCount { get; set; }
        [DataMember]
        public String HospitalStatus { get; set; }
        [DataMember]
        public DateTime ModifiedDateTime { get; set; }
    }
}

But unless you modify it like this, you'll be in for some unpleasant surprises in WF:

namespace Ger911.HCStandard.Core.Shared
{

    [Serializable]
    [DataContract]
    public class MatrixItem
    {
        [DataMember]
        public String EntityName { get; set; }
        [DataMember]
        public String ContactName { get; set; }
        [DataMember]
        public Int32 BedCount { get; set; }
        [DataMember]
        public String HospitalStatus { get; set; }
        [DataMember]
        public DateTime ModifiedDateTime { get; set; }
    }
}

References:

Using Red Gate's Reflector, here's what you'll see under the hood of the WorkflowPesistenceService class's RestoreFromDefaultSerializedForm and GetDefaultSerializedForm. For further insight into this, use Reflector and examine the SqlWorkflowPersistenceService:

RestoreFromDefaultSerializedForm

protected static Activity RestoreFromDefaultSerializedForm(byte[] activityBytes, Activity outerActivity)
{
            Activity activity;
            DateTime now = DateTime.Now;
            MemoryStream stream = new MemoryStream(activityBytes);
            stream.Position = 0L;
            using (GZipStream stream2 = new GZipStream(stream, CompressionMode.Decompress, true))
            {
                activity = Activity.Load(stream2, outerActivity);
            }
            TimeSpan span = (TimeSpan)(DateTime.Now - now);
            WorkflowTrace.Host.TraceEvent(TraceEventType.Information, 0, "Deserialized a {0} to length {1}. Took {2}.",
                new object[] { activity, stream.Length, span }); return activity;
}

GetDefaultSerializedForm

protected static byte[] GetDefaultSerializedForm(Activity activity)
{
          DateTime now = DateTime.Now;
          using (MemoryStream stream = new MemoryStream(0x2800))
          {
              stream.Position = 0L;
              activity.Save(stream);
              using (MemoryStream stream2 = new MemoryStream((int)stream.Length))
              {
                  using (GZipStream stream3 = new GZipStream(stream2, CompressionMode.Compress, true))
                  {
                      stream3.Write(stream.GetBuffer(), 0, (int)stream.Length);
                  }
                  ActivityExecutionContextInfo info = (ActivityExecutionContextInfo)activity.GetValue(Activity.ActivityExecutionContextInfoProperty);
                  TimeSpan span = (TimeSpan)(DateTime.Now - now);
                  WorkflowTrace.Host.TraceEvent(TraceEventType.Information, 0, "Serialized a {0} with id {1} to length {2}. Took {3}.", new object[] { info, info.ContextGuid, stream2.Length, span });
                  byte[] array = stream2.GetBuffer();
                  Array.Resize<byte>(ref array, Convert.ToInt32(stream2.Length));
                  return array;
              }
          }
}

DataContractSerializer

public sealed class DataContractSerializer : XmlObjectSerializer
{
    // Fields
    private IDataContractSurrogate dataContractSurrogate;
    private bool ignoreExtensionDataObject;
    internal Dictionary<XmlQualifiedName, DataContract> knownDataContracts;
    private ReadOnlyCollection<Type> knownTypeCollection;
    internal IList<Type> knownTypeList;
    private int maxItemsInObjectGraph;
    private bool needsContractNsAtRoot;
    private bool preserveObjectReferences;
    private DataContract rootContract;
    private XmlDictionaryString rootName;
    private XmlDictionaryString rootNamespace;
    private Type rootType;

    // Methods
    public DataContractSerializer(Type type);
    public DataContractSerializer(Type type, IEnumerable<Type> knownTypes);
    public DataContractSerializer(Type type, string rootName, string rootNamespace);
    public DataContractSerializer(Type type, XmlDictionaryString rootName, XmlDictionaryString rootNamespace);
    public DataContractSerializer(Type type, string rootName, string rootNamespace, IEnumerable<Type> knownTypes);
    public DataContractSerializer(Type type, XmlDictionaryString rootName, XmlDictionaryString rootNamespace, IEnumerable<Type> knownTypes);
    public DataContractSerializer(Type type, IEnumerable<Type> knownTypes, int maxItemsInObjectGraph, bool ignoreExtensionDataObject, bool preserveObjectReferences, IDataContractSurrogate dataContractSurrogate);
    public DataContractSerializer(Type type, string rootName, string rootNamespace, IEnumerable<Type> knownTypes, int maxItemsInObjectGraph, bool ignoreExtensionDataObject, bool preserveObjectReferences, IDataContractSurrogate dataContractSurrogate);
    public DataContractSerializer(Type type, XmlDictionaryString rootName, XmlDictionaryString rootNamespace, IEnumerable<Type> knownTypes, int maxItemsInObjectGraph, bool ignoreExtensionDataObject, bool preserveObjectReferences, IDataContractSurrogate dataContractSurrogate);
    internal static DataContract GetDataContract(DataContract declaredTypeContract, Type declaredType, Type objectType);
    internal override Type GetDeserializeType();
    internal override Type GetSerializeType(object graph);
    internal static Type GetSurrogatedType(IDataContractSurrogate dataContractSurrogate, Type type);
    private void Initialize(Type type, IEnumerable<Type> knownTypes, int maxItemsInObjectGraph, bool ignoreExtensionDataObject, bool preserveObjectReferences, IDataContractSurrogate dataContractSurrogate);
    private void Initialize(Type type, XmlDictionaryString rootName, XmlDictionaryString rootNamespace, IEnumerable<Type> knownTypes, int maxItemsInObjectGraph, bool ignoreExtensionDataObject, bool preserveObjectReferences, IDataContractSurrogate dataContractSurrogate);
    internal override bool InternalIsStartObject(XmlReaderDelegator reader);
    internal override object InternalReadObject(XmlReaderDelegator xmlReader, bool verifyObjectName);
    internal override void InternalWriteEndObject(XmlWriterDelegator writer);
    internal override void InternalWriteObject(XmlWriterDelegator writer, object graph);
    internal override void InternalWriteObjectContent(XmlWriterDelegator writer, object graph);
    internal override void InternalWriteStartObject(XmlWriterDelegator writer, object graph);
    public override bool IsStartObject(XmlDictionaryReader reader);
    public override bool IsStartObject(XmlReader reader);
    public override object ReadObject(XmlReader reader);
    public override object ReadObject(XmlDictionaryReader reader, bool verifyObjectName);
    public override object ReadObject(XmlReader reader, bool verifyObjectName);
    internal static object SurrogateToDataContractType(IDataContractSurrogate dataContractSurrogate, object oldObj, Type surrogatedDeclaredType, ref Type objType);
    public override void WriteEndObject(XmlDictionaryWriter writer);
    public override void WriteEndObject(XmlWriter writer);
    public override void WriteObject(XmlWriter writer, object graph);
    public override void WriteObjectContent(XmlDictionaryWriter writer, object graph);
    public override void WriteObjectContent(XmlWriter writer, object graph);
    public override void WriteStartObject(XmlDictionaryWriter writer, object graph);
    public override void WriteStartObject(XmlWriter writer, object graph);

    // Properties
    public IDataContractSurrogate DataContractSurrogate { get; }
    public bool IgnoreExtensionDataObject { get; }
    internal Dictionary<XmlQualifiedName, DataContract> KnownDataContracts { get; }
    public ReadOnlyCollection<Type> KnownTypes { get; }
    public int MaxItemsInObjectGraph { get; }
    public bool PreserveObjectReferences { get; }
    private DataContract RootContract { get; }
}

WCF to the rescue

William — Mon, 07 Jul 2008 23:41:23 GMT

Although part of the idea below was mine, James Ashley was crucial to helping me figure this out.

Problem:

Without getting into the ghoury details, we have an application that allows users to send messages to large groups of people. Anyone using a client application that is logged on will get a special notification which they can respond to once a message is sent. So far, Polling has been the bane of our existence. We're trying to fancy up the UI and Telerik's Winforms controls have helped out a lot, but there's simply no way I've been able to find to have a snappy UI with a lot of really cool looking effects - all the while polling every few seconds. Until now, I just bit down, and took a walk through multi-threadedville.

I wanted to remove the polling. We had experimented with a few different architectures, but all had the same problem, polling. So let's say you had 200 users logged on. In the User's bar, we wanted to show each user and their picture - much the same way IM does. This app had to work across network boundaries and you couldn't count on being able to use TCP so we had to at least make it work with http. If you poll every three seconds, to get the latest info on who's logged on and off, rebuilding the list of user's was painful. We resorted to several tricks to determine if a user was already in the list, but all of it was putting lipstick on a pig.

Solution:

One of the big things you often hear about with WCF is self-hosting. I had ignored it for the most part. But today, I wanted to basically have a Winforms app host one service, and a Windows Service host the other part of the service, having the services talk to each other. The client winforms app would simply talk to the client service, it would never hit the Windows Service directly.

So we built a client service and server service, with a client winforms app hosting the client service and a mock Windows Service (which was simply another winforms app) that hosted the service.

The problem we kept running into is as each client signed on to the system, how could we tell the server svc that they were online? Dynamically adding endpoints is child's play, but with each winforms app, you could only interact with the ServiceHost - not the service.

We tried using traditional events to no avail - that wasn't a surprise but we figured it's worth a try. Then James recommended a static event. I was completely skeptical, but alas it worked.

After looking at Juval's framework though, it became really clear. If we want the services to be able to interact with the hosts, then simply self-host the things.

So we had a method called ReceiveMessage which was called from the service (via a client proxy for the client service). Here's basically what the client looked like:

public partial class Form1 : Form, IClientService
{
    public Form1()
    {
        InitializeComponent();
    }

    ServiceHost currentHost = null;
    private void btnStartService_Click(object sender, EventArgs e)
    {
        currentHost = new ServiceHost(typeof(Form1));
        try
        {
            currentHost.Open();
            lblServiceStatus.Text = "Started";
        }
        catch (Exception ex)
        {
            lblServiceStatus.Text = ex.Message;
        }
    }

    public string ReceiveMessage(string msg)
    {
        String myMessage = msg;
        MessageBox.Show(myMessage);
        return msg;
    }

....

Now, from the Administrative application (which interacted with the service, you could Send a message by doing the following:)

private void btnSend_Click(object sender, EventArgs e)
{
      proxy = new ClientServiceClient(new NetNamedPipeBinding(), endpoint );
      try
      {
          proxy.ReceiveMessage(rtbMessageText.Text);
      }
      catch (FaultException ex)
      {
          lblServiceStatus.Text = ex.Message;
      }
}

ClientServiceClient is a stupid name for a client proxy class, but we were just experimenting - the main thing to note is that it's simply a proxy class for the client service, the same service that's effectively being hosted by the Winforms client. There's a server method called SendMessage(String msg) which you'd call on the service, which in turn would dynamically add endpoints for each active client , and then send the messages to them.

You can easily store all the information for clients you want to send messages to in a List<> or similar structure - or if you need stronger persistence or have different needs, then you can use a database. Either way the end result is the same - loop through all the clients, add an endpoint for each one, loop through each and call the method you want.

I'm having trouble getting to my ftp server from where i'm at, but I'll post the code when I can. In the meantime, if you're interested, just drop me a line.

Cool Powershell script

William — Wed, 21 May 2008 03:59:14 GMT

I can't take credit for this, I came across it in Windows Communication Foundation Unleashed - but it's very helpful for administering Windows Communication Foundation...

In the <diagnostics> tag of your service's configuration, two available options are wmiProviderEnabled and performanceCounters. So ideally you'll want to set both, but if you just need to identify the endpoint then only the first one is necessary:

<system.serviceModel>

<diagnostics

wmiProviderEnabled="true"

performanceCounters="ServiceOnly"/>

</system.ServiceModel>

After you have that in place for your service(s), you can use the following Powershell script

PS C:\Windows\System32> get-wmiobject endpoint -n root\ServiceModel | ft name

I don't know if I love Powershell more than Windows Communication Foundation or WCF more than Powershell, but few things are cooler than using them together and this is one script you'll undoubtedly find helpful.

ChannelFactory.CreateChannel goes to the Gentlemen's Club

William — Mon, 12 May 2008 22:07:00 GMT

Currently, I'm tasked with getting some people up to speed on .NET 3.5 as well as WCF. WCF is really cool and it's easy to fall in love with, but it's also easy to cause you to sleep when you're first learning it. So instead of walking through Hello World, I changed course.

Basically, we're using an architecture where the Business Layer and Data Layer are services. In most cases, we'd run them on the same machine, in Proc. In other cases, when scalability is more of an issue, we'd need to separate them out.

Creating Services is nothing special and other than a few attributes (ServiceContract, OperationContract, often DataContract and/or DataMember or EnumMember) and an interface, there's no real way to tell a wcf service from any other class (and since most of those attributes should go on the interface, the class itself shows no sign of being a service other than the interface implementation). One thing though, when you add a WCF service to an application through VS, it will stick the service class and the corresponding interface into the same project. I typically move my interfaces out of the project and into a library so that I can share them. In a case where your business methods just call the dal's methods, the interfaces/contracts will be the same so you may be able to share them.

WCF gives you similar hosting options to Remoting and Web Services. You can add a Service Reference and have svcutil.exe generate a proxy class which is virtually identical to what you did with web services. Hosting them is the easy part and if you can run a Console application and remember to put Console.Readline at the end of it, you can start a service host. There's about a zillion examples out there and it's usually one of the first things covered in WCF so I'm leaving that alone for now.

On the client, you can add a service reference as I said. However that is not without its problems and you may want a little more flexibility. If you want to create your own proxies, there are two primary methods (outside of svcutil related approaches). Let's say you have the following interface:

namespace Cuckooz.Sample.WCFStripClub { [DataContract] public enum BounceLevel{

[EnumMember] Lame, [EnumMember] Woot, [EnumMember] YeahBaby };

[DataContract] public enum PoleManeuver{ [EnumMember] Standard, [EnumMember] LookMaNoHands, [EnumMember] UpsideDownLookMaNoHands }; [ServiceContract] public interface IStripper { [OperationContract] String Bounce(BounceLevel bouncin); [OperationContract] String SlideDownPoll(PoleManeuver maneuver); [OperationContract] long MilkSuckerForCash(String customerName); } }

One approach is to create your own Proxy class , inheriting from ClientBase and passing in the type of the interface, while implementing the interface. Pay attention to the implementations of this class:

namespace Cuckooz.Sample.WCFStripClub { public partial class PurePlatinumServiceClient : ClientBase<IStripper>, IStripper {

public PurePlatinumServiceClient() { }

public PurePlatinumServiceClient(String endpointConfigurationName) : base(endpointConfigurationName) { }

public PurePlatinumServiceClient(String endpointConfigurationName, String remoteAddress) : base(endpointConfigurationName, remoteAddress) { }


        public PurePlatinumServiceClient(Binding binding, EndpointAddress remoteAddress) : base(binding, remoteAddress) { }
        public String Bounce(BounceLevel bouncin)
        {
            return base.Channel.Bounce(bouncin);
        }
        public String SlideDownPoll(PoleManeuver maneuver)
        {
            return base.Channel.SlideDownPoll(maneuver);
        }

public long MilkSuckerForCash(String customerName) { return base.Channel.SlideDownPoll(customerName); } } }

Note that b/c we are passing in the interface as a generic type parameter to ClientBase, we can refer to it through base.Channel.MethodName.

You will need to have an endpoint configured in order to call the service and you should give the endpoint a name to make things easy. In this case, I have a namedPipe endpoint configured named "NamedPipe". With that in place, you simply need to create an instance of your proxy and have at it:

PurePlatinumServiceClient dancerProxy = new PurePlatinumServiceClient("NamedPipe"); Console.WriteLine(dancerProxy.Bounce(BounceLevel.YeahBaby)); Console.WriteLine(dancerProxy.SlideDownPoll(PoleManeuver.UpsideDownLookMaNoHands)); Console.WriteLine(dancerProxy.MilkSuckerForCash("Peter Griffin"));

If you are going to create your proxies like this, do yourself a favor and use CodeSmith, some other template, or if you're just really hard up, copy and paste where applicable - it'll save you a lot of time.

If you don't want to go this route though, you can skip the whole proxy altogether. Using the ChannelFactory class, you can specify the same interface we used above and create a new ChannelFactory. Remember to name your endpoints in the configuration file so that you can refer to them. Otherwise, you'll need to specify the endpoint hard code style - which is lame. Once you've done that, you instantiate an IYourInterface object using the CreateChannel method of the ChannelFactory you just created. Then, you should cast it to an IDisposable object and throw it in a using block, and have at it from there. Note, you don't have to use IDispose but the other approach is to cast it as a ICommuncationObject and then call Close. For the money, it's easier and safer to just go the IDispose route. So the code below is functionally equivalent to the preceding block:

ChannelFactory<IStripper> stripperFactory = new ChannelFactory<IStripper>("NamedPipe"); IStripper serviceInstance = stripperFactory.CreateChannel(); using (serviceInstance as IDisposable) { Console.WriteLine(serviceInstance.Bounce(BounceLevel.Woot)); Console.WriteLine(serviceInstance.SlideDownPoll(PoleManeuver.LookMaNoHands)); Console.WriteLine(serviceInstance.MilkSuckerForCash("Peter Griffin")); }

Either of these approaches provides a ton of flexibility. For instance, you can create several endpoints, look at the environment and then decide which endpoint you want to talk on, hence, which binding you are going to use. Similarly, if you had several services you could easily change the execution to use on over the other ones. All in all it really couldn't be simpler and in this case, the hardest part of the equation is going to be setting up your configuration file properly.

If I have time tomorrow I'll post the next lesson which uses Duplexing, there's a lot of potential with this interface and service when you enhance it with duplexing ;-)

Pro WCF: Practical Microsoft SOA Implementation

William — Sun, 18 Feb 2007 23:41:00 GMT

I went on a book binge this week and have had my nose buried in WCF all week. There's a lot of really good stuff out there, but without a doubt, Pro WCF: Practical Microsoft SOA Implementation by Chris Peiris is probably my favorite.

Overall, the book is just over 400 pages but the author says quite a bit in those 400 pages. The coolest part is that they go over just about every topic that the MSDN Documentation is short on. I found that a lot of things that I stumbled my way through were covered there as well.

I can't find the link, but a while ago, KC had a post where his server program uploaded itself his web server and ran itself. His comment was something to the effect about "What did the first Blacksmith use". I was always really impressed with that program. And not just b/c of the lower cased one's coding skill. The idea itself was really cool. So when WSE 3.0 came out and MTOM was implemented, I tried to bite his style and accomplish the same thing with MTOM. It's an easy port so it didn't take much skill on my part.

Anyway, I've been trying to figure out how to port most of the WSE 3.0 code from my 70-529 book over to WCF. I've been able to do most of it, however it's been frustrating at times. I'm make a lot of typos and copy/paste errors and neither play well with .config files. After wasting about 3 hours trying to get the MTOM port to work, I read through this book and Viola'. I was kinda mad at myself for overcomplicating things that much. So I guess I really like the book in large part b/c I've had quite a few similar experiences with it.

My favorite chapters are discussed below:

Chapter 4 - It discusses installation and configuration. This is the single most frustrating area when learning WCF. Writing code instead of using .config files is lame so I try to avoid it. But getting some help in avoiding common mistakes is priceless..

Chatper 6 discusses managing WCF Services. Not a glamorous subject but being able to monitor and troubleshoot your programs is critical. Moreover, when you're first learning how to do things, it's easy to ignore performance. It's easy to overlook things that can kill performance. After reading this chapter, I am in a lot better shape to find problems

Chaper 7 discusses security. Obviously a pretty big issue when you're building services. Just for good measure there's some CardSpace stuff at the end which was a nice touch.

Chapter 9 discusses transactions. For obvious reasons, this is a subject you need to learn well and although I thought I was pretty familiar with them, I learned more than a few things from this chapter.

-------------------

All in all, this book was pretty impressive. They do mostly real world stuff and while they certainly talk theory, they stick to stuff that you'll encounter in your day to day development. You can only take so much theory and I've found that the documentation on MSDN is really heavy on theory and not enough implementation. This book will bridge that gap. Scott Klein's WCF book will help quite a bit too but won't be out for another month or two.

I also picked up John Sharp's Microsoft Windows Communication Foundation Step by Step. So far, my impressions are quite favorable although I haven't went through it in quite the detail I did with this one. I worked through each of the examples and found them pretty cool. Should have a review of it up shortly.

Windows Activation Hosting (WAS) and WCF

William — Sun, 28 Jan 2007 15:32:00 GMT

A few years ago, I took a job at Tiba Solutions . One of the coolest things about that job was working with Tobin Titus. Tobin is pretty much a bad a55 at all sorts of things and one of the things he really rocked at was Remoting. I learned most of what I know from him. He has long since left Tiba as have I and moved on to greener pastures. Currently he's at Microsoft. Now that I've sucked up enough to Tobin hopefully I can get him to explain to me how to get my GD WCF service configured properly to run in IIS 7.0 under WAS.. So if I run appcmd.exe from the VS Command Line, this file is generated and all is good. If I create a new site and do this manually, it bombs on me telling me the target machine is actively refusing my connection. I can't see any difference for the life of me. Does appcmd.exe do something else critical that I'm missing?

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.applicationhost>
<sites>
<site name="CuckooClock" id="1">
<bindings>
<binding protocol="http" bindinginformation="*:80*"/>
<binding protocol="net.msmq" bindinginformation="*"/>
<binding protocol="net.tcp" bindinginformation="*"/>
<binding protocol="net.pipe" bindinginformation="*"/>
</bindings> 
</site>
</sites>
</system.applicationhost>
</configuration>

Is my Windows Communication Foundaton Service configured correctly?

William — Sat, 27 Jan 2007 23:55:00 GMT

One of the really sucky things about doing presentations is that you have to learn what you're talking about first. Actually, there's nothing sucky about learning things, it's just that at until you hit your learning curve, it can be frustrating. It's after that point though that things become sucky. Why? Because all too often you start going "Wow, is this cool, I wonder if I can_____________" and then you give it a try. Some stuff works on the first pass, some stuff doesn't. Then you start debugging and searching around, figure out how to make it work and you in my case, it usually takes something like the dog pooping on the floor to make me realize how long I've been zoned out on the computer.

If you're familiar with Windows Communication Foundation (WCF) then you realize that it's so configurable its almost hard to fathom (I really woulnd't be surprised if the next version negates the need for code altogether and you simply flip around config file settings to do what you want). Configuration is as cool as hard coding stuff is lame, but one problem with it is that it's fussy. If you screw something up in a XAML file (which is similar in form to config files) for instance, the compiler jumps in and lends you a hand telling you rather precisely what you did wrong. If you screw something up in a configuration file for WCF, you get the same behavior you did with .NET Remoting (for the uninitiated, that means it just sits there and laughs at you as you try to figure out which word you incorrectly spelled).

So I'm trudging through a bunch of samples I was thinking about and then realized most of what I've done entails hosting the service in a Console application. Time to take off the training wheels and host it in IIS right? I ask myself "Hell, how hard can that be?"

I created my virtual director and started copying stuff over. Carefully, I changed my configuration file settings. Just to be safe I left out all the fancy stuff I was doing with CustomBindings and just left in the simple stuff. "This should be a breeze" I'm thinking the whole time. So far so good. Normally, as I progress along each step of the way I test that part to make sure I got it right up until then, just so it's easier to isolate problems down the road should they arise. My ego got ahead of my brain and off I went.

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"> <system.serviceModel> <services> <service name="MarkBrownService" behaviorConfiguration="returnFaults"> <endpoint contract="IKnightEmailHelper " binding="wsHttpBinding"/> </service> <service name="BlueCuckooService" behaviorConfiguration="returnFaults"> <endpoint contract="IPeck " binding="wsHttpBinding"/> </service> <service name="SausageDogService" behaviorConfiguration="returnFaults"> <endpoint contract="ITakeADump " binding="wsHttpBinding"/> </service> <service name="DigitalStripperService" behaviorConfiguration="returnFaults"> <endpoint contract="IStrip " binding="wsHttpBinding"/> </service>

Now, the first of these is really lame but the other three do quite a bit of stuff. I do a second glance to make sure everything looks ok and it does. I hand coded the client classes and was pretty sure they were good. So I fire everyting up and I see this:

The contract name 'IPeck ' could not be found in the list of contracts implemented by the service 'BlueCuckooService'.

The contract name 'ITakeADump ' could not be found in the list of contracts implemented by the service 'SausageDogService'.

The contract name 'IStrip ' could not be found in the list of contracts implemented by the service 'DigitalStripperService'.

Wheewwwy, I screwed up every single one of them. So I tried to eliminate them one at a time, same problem. I check the name, check the interface name. Both look good. So what have I done differently? I put the interfaces into a shared assembly, that must be it. So I removed the project reference and copied the classes back into the project. Double checked the namespaces and figured, this has to be it. But it wasn't. I went through everything I could think of and nothing. Fortunately, Nikki the sausage dog got that look in his eye that he usually does right before chewing up one of my shoes or taking a dump on the floor and sharing it with me. Upon getting up I realized I had went wayy tooo far down WindowsCommuncationFoundation express today and needed to do other things like walk the dog.

When I arrived back, I saw what the problem was by the time I got comfortably seating. A lot of times things just work like that.

So, take one last look at the problem and see if you can figure it out - it's totally glaring if you're careful. (If you've been a reader of my blog for a while, it's a well known thing that I due and have done the same thing many times before.

I tend to type fairly quickly and while I use both thumps to space with, I frequently double this the space bar. In T-SQL and C#, it seldom matters. MS Word and Excel both just fix it for me. So I don't even realize I"m doing it. But configuration files - well, I think that they were made by a bunch of German guys who though it'd be a great goof to give guys like me a hard time "So uuwwe really sink dat Lexus have betta quality control den der BMW, You fool, we'll teach you a lesson!"

So I looked around and looked around and realized I put an extra space in after an interface name. Ok, that's fixed. All is good. But each new service I added suffered from the same problem. This time I knew exactly what it was, but it was easy to mess up b/c of muscle memory in my fingers.

A quick way to know if you're service is configured correctly is as simple as one like in a browers:

http://localhost:2361/CuckooService/EvilBlueCuckooService.svc?wsdl

Substitute the name and location of your service(s) and use the good old ?wsdl method to make sure it works. If everything is in place, a browser window with a bunch of nested funky looking xml should appear that looks like your service definition. If not, well you gotta problem. So simple to use, it's worth it's price in gold.

So far, I got the images of the Cuckoo coming out of his clock, the SausageDog making "pinchy loaf loaf" all wired into to a client UI. If any of my reliable friends like KC , Brian Madsen , Sahil or Ryan wanna help me with the UI for the last one, I got the back end stuff worked out ;-)

And hopefully none of the Usual and BrainWashedGrievance Brigade
will try to pee on our parade. I have a lot of fun WCF samles which are pretty cool.

My next WCF post will be on "Doing things with Behaviors most people can only dream about..."