Architects of the World Unite!

Howdy!

Long time no post.

But I've been busy.

And not just with XBox, drinking beer and napping. Although to be fair, there has been some of that...

What I've been working on is the creation of the Columbus Architects Group.

ColARC is a community user group for Architects and aspiring Architects to get together and share knowledge, experience and opinions. We are not bound by platforms and any Architect (or aspiring Architect) who is passionate about their craft is invited to attend.

The topic for the first meeting is "What is an Architect?" The format for most meetings will be a fish bowl meeting, but there may be panel discussions and speakers at some meetings.

Our first meeting is Wednesday September 10th at Quick Solutions in Westerville. We start at 6:00.

Normally, we will meet the second Tuesday of the month, but there was a conflict this first month so...

And yes, I know COJUG meets the same night. We're working on...

Check it out at www.colarc.org and hope to see you all there!

The Big Non-Story

For those of you who don't know, I do a lot of interviews. Not just for my current company. It seems that every company that I've worked for has decided at some point that I'm good at gauging a potential employee's technical chops as well as determining if their personality is a fit for the group. I've lost count of how many interviews I've done, but it has to easily be in the hundreds.

Recently Steve Harman, a co-worker of mine appeared on an episode of Deep Fried Bytes. Steve recounted (third person) a story about an "incident" that occurred during an interview I conducted YEARS ago.

Basically, halfway through the interview, the candidate started to cry.

It started off as any normal phone interview; introduced myself, talked about his resume a little, than started settling into some technical questions to find his skill level. As the discussion started turning to more advanced topics, I noticed a distinct pause between when I asked the question and when I got the answer. I also noticed the sound of pages in a book being turned (this was in the days before Google). I asked him if he was looking up the information in a book. That's when he basically started to cry.

He explained to me that he had been out of work for sometime, and was starting to get desperate. His mother was sick and he was worried about how he was going to take care of her. I felt very bad for the guy. At the end of the interview I thanked him for his time. I reported back to my employer that he was not a good candidate for the lead developer position we were looking to fill, but if something a little lower on the ladder came around we should talk to him again.

I've actually only told this story to a VERY few people, but because it is one of the "great interview war stories" it seems to have developed some legs, not to mention a life of it's own! To this day I have people asking me about it who I KNOW I never told the story too. Not that it's a big secret, I'm just surprised how many people seem to think it is a great story. And maybe it is.

But the reality was not great. Just to be clear, it is NOT (nor should it EVER BE) the goal of an interview to make someone uncomfortable enough to cry. Yes, I want to ask "hard" questions and have the person not only be able to prove their technical prowess, but I also want to find out a little bit about their character and personality. But the truth is that making a person cry during an interview is NOT something I'm proud of or something I ever want to experience again. Fact is, I was probably almost as uncomfortable as the potential candidate that I speak of, and I'm not at all eager to go through that again!

Anyway, I just wanted to clear this up a little since many people seem to be getting the wrong idea about the event. Challenging interview == good. Candidate having a "breakdown" == bad.

Happy Contribupendence Day!

Did you do your five recommendations? There is still time, so get to it!

Here are my "first" five (in no particular order):

Gayle Craig - Gayle is an extremely smart and talented developer who is not afraid of facing new challenges head on. Her recent move from Java to Ruby demonstrates that she is always looking for ways to expand and increase her knowledge. Instead of speaking, Gayle chooses to interact with the development community in a more personal, one-on-one mentoring role which I feel often does not get her the recognition that she so richly deserves.

Amanda Laucher - Amanda is one of the smartest people I have had the pleasure to know. Her ability to easily grasp and apply new, abstract and difficult concepts to mainstream development methodologies and techniques is nothing short of incredible. Her work in the .NET development community is highly appreciated and she can always be counted on to teach people something new and immediately useful.

Sarah Dutkiewicz - Sarah is an extremely smart, talented and energetic member of the .NET community. She and her colleges in Cleveland recently organized the first Day of .NET in the region with tremendous results. Her dedication to the development community is second to none. Her passion for technology is exemplified by her eagerness to learn and apply new technologies and techniques.

Jeff McWherter - Jeff has been instrumental in creating and nurturing a .NET development community in Eastern Michigan area that is an irreplaceable asset to its members. His commitment to the community was demonstrated by Jeff with the success of the Lansing Day of .NET which brought community members from as far away as Tennessee to participate and benefit from the knowledge and experience of his peers.  Jeff’s hard work and dedication to making this event so successful cannot be overstated. He is an asset to any team he is a part of.

Jeff Hunsaker - Jeff is an extremely smart, capable and talented member of the .NET community. Jeff is someone that enjoys tackling new challenges and helping others in the community overcome their own challenges. Jeff is very passionate about technology and is quick to learn new tools and techniques and find ways to leverage them in ways that make developments faster, less expensive and more successful.

So, what do I mean by my "first" five? Well, as I made my list I would think of a name that would make me think of two more names, which would make me think of two more names and so on and so on...

Currently my list is over 20 people. So, instead of trying to pare this down, I'm going to go ahead and write recommendations for ALL of them! It's going to take me probably most (all?) of the weekend, but now that I'm in the spirit of the "holiday" it seems the right thing to do.

Contribupendence Day?

What is Contribupendence Day? I mean, besides a word that apparently is not in my spell checker dictionary?

Well, according to Jeff Blankenburg, it's a day. Specifically July 3rd. More specifically, it's a day set aside for all of us in the development community to use those often overlooked features of social networking sites (like Plaxo and LinkedIn) and write something nice things about your peers.

So, on July 3rd., pick a few people who's work in the community you've appreciated in the past and write a glowing review (or just a few nice words) about them.

So, is this just another made-up holiday?

No! Well, yes. Sort of. I mean, we don't get the day off or anything, BUT we also don't have to mail out cards or buy gifts for people or anything. I mean, you can have a cook-out or something. If you want. That would be kind of cool....

Anyway, I've picked my five people. Have YOU?

Give Camp!

What is a "Give Camp?" It's an event designed to allow developers, designers, DBAs, Architects and enthusiasts to donate their time and talent by helping to developer or update applications for charities.

Many of these organizations rely on custom applications and web sites to be able to provide services, but unlike large companies they lack the funds and resources to keep these applications up to date or build them at all.

On July 11-13 you have the opportunity to help out by participating in the Ann Arbor Give Camp and using your powers for good instead of evil!

Lansing, Here I Come!

OK, short notice. Sorry about that...

For those of you in the area I will be speaking at the Lansing Day of .NET tomorrow, June 21. I will be presenting "Getting Started with WCF."

Hope to see you all there!

Lansing Day of .Net, 21 June 2008 - I'll be there!

SVCUTIL, you're my hero!

While I was putting my demos together for Cleveland Day of .NET I discovered a very frustrating, undocumented "feature" with the way the "Add Service Reference..." option works in Visual Studio 2008.

SPOILER ALERT!

My presentation is about custom behaviors, and one of my examples in an implementation of IInstanceProvider applied as an IServiceBehavior and added to my service runtime via code. I've done this a dozen times before with no issue, but this time something was amiss...

I wrote my code, fired up my application and saw the behavior "appear" to bind to my runtime. I ran my client and the call to the service worked. The only problem is that my behavior was not executed.

I had no idea what I could have done wrong. Like I said, I've done this dozens of times before with no issue. I went back and studied those old applications. Sure enough, they all still worked as expected. I started going line by line to see if there was ANYTHING I could have missed. Nothing.

Then I noticed one difference; usually I used SVCUTIL to create my proxies and add them to my client application. This time, in the interest of keeping the demo "easy" I used the "Add service reference" option from Visual Studio. In all other ways it seemed to work, but I couldn't escape the fact that it was the ONLY difference between the two solutions.

I tried a few more things around the service reference. I regenerated the reference. Nothing. I thought that maybe it was somehow calling the service before the behavior was bound (I know, kind of crazy but after 90 minutes I was started to get a little desperate). So I started the host manually, waited till I was SURE that the behavior was bound, then started the client. Nothing.

So, having exhausted all other ideas, I dropped the VS created service reference and used SVCUTIL to create a proxy object and an application configuration file. I added them to my client project, fired up the service, made my service call and... it worked!

Not being totally familiar with how VS creates the service references, I can't say for sure why it doesn't work. But, given that the behavior works when called from client that creates the channel stack (either manually via a generated proxy), I'm guessing that the service reference option is building this channel stack in a different way or somehow circumventing the aspects of the runtime on the service side.

I've never deployed an application with VS generated service references, so I'm not sure how it works in production. Or if it's even possible to deploy a WCF client in such a way. Nor have I heard of anyone else doing it.

To be honest, I prefer SVCUTIL proxies or developer written invocations of the channel stack. It gives you more control over how your client interacts with the service and if something does go horribly wrong I can debug into the stack and see what's going on.

So Mr. "Add Service Reference..." I've given you a chance, but I think I'll stick with SVCUTIL.

See you all at CDoDN!

Pimp Your WCF Runtime - Episode One

If you have ever made any effort in learning WCF, you have probably seen some variation of this:

 

static void Main(string[] args)
{
    ServiceHost host = null;
    try
    {
        host = new ServiceHost(typeof (HelloWCF), new Uri("http://localhost:8080/HelloWCF"));
        host.Description.Endpoints[0].Behaviors.Add(new MyCustomMessageFormatter("message"));
        host.Description.Behaviors.Add(new MyInstanceProvider());

        host.Opening += host_Opening;
        host.Opened += host_Opened;
        host.Faulted += host_Faulted;

        host.Open();

        Console.WriteLine("Service is available.");

        Console.ReadKey();
    }
    finally
    {
        if (host != null)
        {
            Console.WriteLine("Closing service...");
            host.Close();
        }
    }
}

This hosting code, or some variant of it, appears in almost every book on WCF, usually in a console application. It demonstrates creating an instance of ServiceHost for a service implementation (in this case HelloWCF) with a specified URI. A couple of behaviors are added at runtime and we wire up some custom event handlers. All in all, for WCF, nothing complicated.

But what if you want to host your service in IIS? Since it comes with Windows Activation Service (WAS), IIS7 is an ideal environment to host your WCF service. So how do we get the same ability to customize our runtime in IIS?

It's actually pretty easy.

System.ServiceModel.Activation to the rescue!

IIS uses an instance of a ServiceHostFactory to create a runtime for your hosted service. If you do not provide an implementation for this class, IIS will provide you with a default implementation.

If we want to use are own hosting logic, all we have to do is create our own host class which inherits from ServiceHostFactory like so:

 

public class MyCustomHost : ServiceHostFactory
{
    public override ServiceHostBase CreateServiceHost(string constructorString, Uri[] baseAddresses)
    {
        string serviceType = 
            string.Format("{0}, {1}", constructorString,
            constructorString.Substring(0, constructorString.IndexOf(".")));

        Type t =Type.GetType(serviceType);
        
        ServiceHost host = new ServiceHost(t, baseAddresses);

        return host;
    }

    protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
    {
        ServiceHost host = new ServiceHost(serviceType, baseAddresses);

        return host;
    }
}

When we do this we need to override both implementations of CreateServiceHost, which is the method IIS calls to create the runtime for you service. For both versions we get a service type and an array of base addresses. The only real difference between the two is that the version that takes the string as the first argument is taking the service type information as a string as opposed to a .NET Type. It's an easy matter to take this string and create an instance of a Type object, in which case we can refactor the code to this:

public class MyCustomHost : ServiceHostFactory
{
    public override ServiceHostBase CreateServiceHost(string constructorString, Uri[] baseAddresses)
    {
        string serviceType = 
            string.Format("{0}, {1}", constructorString,
            constructorString.Substring(0, constructorString.IndexOf(".")));

        Type t =Type.GetType(serviceType);
        
        return this.CreateServiceHost(t, baseAddresses);
    }

    protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
    {
        ServiceHost host = new ServiceHost(serviceType, baseAddresses);

        return host;
    }
}

I think this is a better way to handle this as you are able to keep all the specialized host creation logic to the second method. For example, lets add the events from the first example:

public class MyCustomHost : ServiceHostFactory
{
    public override ServiceHostBase CreateServiceHost(string constructorString, Uri[] baseAddresses)
    {
        string serviceType = 
            string.Format("{0}, {1}", constructorString,
            constructorString.Substring(0, constructorString.IndexOf(".")));

        Type t =Type.GetType(serviceType);
        
        return this.CreateServiceHost(t, baseAddresses);
    }

    protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
    {
        ServiceHost host = new ServiceHost(serviceType, baseAddresses);

        host.Opening += host_Opening;
        host.Opened += host_Opened;
        host.Faulted += host_Faulted;
        return host;
    }

    void host_Faulted(object sender, EventArgs e)
    {
        // Some logic...
    }

    void host_Opened(object sender, EventArgs e)
    {
        // Some logic...
    }

    void host_Opening(object sender, EventArgs e)
    {
        // Some logic...
    }
}

See, nothing to it!

All that's left is hook this up to our SVC file.

Unfortunately in Visual Studio 2008 it can be a little difficult to edit the SVC file. Double clicking it brings up the code behind file and not the SVC file. To get to that file, right click the file in the Solution Explorer and select "Open with..." Select "XML Editor" from the list and you should see something that looks like this:

<%@ ServiceHost Language="C#" Debug="true" Service="CustomHostExample.Service1" CodeBehind="Service1.svc.cs" %>

To add our service host, we just add a Factory attribute that identifies our service host:

<%@ ServiceHost Language="C#" Debug="true" Service="CustomHostExample.Service1" 
    CodeBehind="Service1.svc.cs" Factory="CustomHostExample.MyCustomHost" %>

Save the SVC file and that's it! You just customized your IIS runtime environment for you WCF service.

Reliable Messaging at CODODN

thank-you

Thanks to everyone who came to either my F# talk with Amanda Laucher or my Reliable Messaging talk. If you came to both than EXTRA THANKS! 

 

As promised, here is a link to my slides and sample code from the WCF talk.

 

For those of you who missed it, I will be presenting the same talk at the Western Michigan Day of .NET in Grand Rapids on May 10th.

WM Day of .Net May 10, 2008 - I'll be there!

 

See you all there!

It's Your Fault!

In talking to people about WCF, I've noticed that a lot of people, new to WCF and not, have not realized that WCF has the ability to send rich fault information back to the client by using a Fault Contract. It's very easy. In fact, you can do it in four steps...

Step 1: Admit your faults

The first thing we need to do is determine what kind of information we want to return back to the client and create a data contract that contains that information. You may have several kinds of fault classes, and you should so that you can return specific types of information for specific faults. Kinda like why there isn't just one Exception class in .NET. Although these are data contracts, you should not use them for anything other than sending faults back to the client. Here's a sample fault class:

[DataContract]
    public class MyFault
    {
        private string _message = string.Empty;

        public MyFault(string message)
        {
            _message = message;
        }

        [DataMember]
        public string Message
        {
            get
            {
                return _message;
            }
            set
            {
                _message = value;
            }
        }
    }

Like any .NET class, you can create a fault class the inherits from another .NET class, BUT that class also needs to be a data contract and be a known type.

Step 2: Find where you may go wrong

Next, we need to let WCF know where these faults might be coming from. This is done at the operation in the service contract. You simply use a FaultContract attribute which lets WCF know what kind of possible fault class to expect:

[ServiceContract]
public interface IFaultyService
{
    [OperationContract]
    [FaultContract(typeof(MyFault))]
    void ThrowMeAnError();
}

You can specify as many faults for the operation as you like, simply add more FaultContract attributes:

[ServiceContract]
public interface IFaultyService
{
    [OperationContract]
    [FaultContract(typeof(MyFault))]
    [FaultContract(typeof(MyOtherFault))]
    [FaultContract(typeof(YetAnotherFault))]
    void ThrowMeAnError();
}

Step 3: The throw...

Throwing faults from a service is a little different than throwing them from C# or VB code. We need to enclose our fault class in a FaultException<T>, which represents a SOAP exception. This is just as easy as the other steps:

throw new FaultException<MyFault>(new MyFault("This is a fault"), "Demonstration");

The second argument, in this case "Demonstration" is the reason for the fault. And yes, "reason" is the attribute name of the fault too. This can either be a string or a FaultReason object which allows you to send more detailed information about the exception.

Step 4: ... and the catch

If you've done everything correctly, when you generate a reference to your service, in addition to the normal proxy information, you should have a class representing the data contract you created for your fault class. Catching this exception on the client side is similar to throwing it on the server side. It will come wrapped in a FaultException<T> and you will need to specify that to catch it correctly:

.
.
.
catch(FaultException<MyFault> itsMyFault)
{
    Console.WriteLine("MyFault was caught");
    Console.WriteLine(string.Format(@"Message: {0}", itsMyFault.Detail.Message));
    Console.WriteLine(string.Format(@"Reason: {0}", itsMyFault.Reason));
}
.
.
.

As you can see, getting the reason is pretty straight forward. Our message, and any other field me might have added, will be accessible as a member of the Detail child object of our fault.

That's it. See, nothing to it.

Actually, this rabbit hole does go a little deeper, but this should be enough to get you all started with capturing rich error information from your services.