Scott Seely

Developer Smackdown show

2011-05-05T21:26:00Z

I was recently on the Developer Smackdown podcast with Clark Sell, Mark Nichols, and Glenn Block. We spent an hour talking REST and WCF over at MIX. The show came out really good! Thanks for having me on again, Clark! Check out show #47: http://developersmackdown.com/Archives/Show/47.

PDC 10 Local Coming to Chicago/Milwaukee

2010-10-22T16:01:00Z

Microsoft PDC 10 is just around the corner! Expect to hear announcements about Visual Studio 2010, Windows Phone 7, and Windows Azure as well as other major announcements. Starting October 28, you will be hearing about many new things coming from Microsoft. If you aren't there in person, the whole experience may be less than satisfying. To boost the experience when watching closer to home, wouldn't it be better to watch the keynotes with a bunch of fellow developers? Of course it would! We have a few events planned post PDC 10 to check out the keynotes in the AM, then dive into the big technologies in the afternoon. Please come join us!

Nov 5, all day, Waukesha, WI

Nov 11, all day, Downers Grove, IL

Clean paths with WCF Hosted Workflows

2010-09-08T22:20:00Z

I am a big fan of the things added to WCF 4.0. One of those things is the deep integration with ASP.NET routes. Today, I was writing a service in WF and hosting the workflow with WCF. I really didn’t like the service URL—yeah, I’m a picky developer who doesn’t like exposing implementation details in the URL.

I knew a few things:

1. WF/WCF integration provides a ServiceHostFactory named WorkflowServiceHostFactory for hosting XAMLX files in WCF.

2. WorfklowServiceHostFactory will see CreateServiceHost called with some constructorString plus a bunch of baseAddresses.

3. I wanted the host to work on HTTP only—I don’t care about goofy URLs for net.tcp.

4. XAMLX services do not have a runtime defined type- they exist only in XAML.

My goal was to create a new route type, like ServiceRoute, that allowed me to pass in the desired path and the path to the XAMLX to instantiate. After a few minutes of thinking and hacking, I had the following:

public class WorkflowServiceRoute : ServiceRoute
{
  public class HostedWorkflowServiceHostFactory :

    WorkflowServiceHostFactory
  {
    public HostedWorkflowServiceHostFactory(string xamlxPath)
    {
      XamlxPath = xamlxPath;
    }

    string XamlxPath { get; set; }

    public override System.ServiceModel.ServiceHostBase CreateServiceHost(
      string constructorString, Uri[] baseAddresses)
    {
      return base.CreateServiceHost(XamlxPath, baseAddresses);
    }
  }

  public WorkflowServiceRoute(string routePrefix, string xamlxPath)
    : base(routePrefix,

           new HostedWorkflowServiceHostFactory(xamlxPath),

           typeof(object))
  {
  }
}

I’m pretty happy with the succinctness of the class and the fact that it works on the few use cases I have at hand. Requests are directed to the correct locations and integration seems to be just fine. Use of the WorkflowServiceRoute is just:

routes.Add(new WorkflowServiceRoute("helloWorld", "SimpleWorkflow.xamlx"));

Frankly, this is the first implementation I thought to write, and it works. The code size is small. I don’t like a few things about it, but I’ll live. Things I don’t like:

1. Passing typeof(object) to the base constructor from the route seems wrong. The receiver code thinks it needs a reference to the service type at all times. I’m just lying to the ServiceRoute so that I can take advantage of everything good about it.

2. Custom ServiceHost just so the code can remember the path to the XAMLX. This bothers me until I think that this is the same thing that happens with each .SVC or other XAMLX file.

As a benefit, I get URLs that look like this:

http://scottseely-xps/WfHostApp/helloWorld
instead of:

http://scottseely-xps/WfHostApp/SimpleWorkflow.xamlx

This serves as yet another example of how good it is that WCF is super extensible and what a great design decision it was to build WCF on top of the extensibility points instead of along side them.

How JSONP works (and some bits about implementing it in WCF)

2010-09-07T13:00:00Z

In the world of the web, we have lots of security concerns. One of the concerns lies with cross site scripting, XSS. From a high level, XSS is any occasion where data is sent from code on a page from one site to another site. The code is usually via JavaScript, though flash and Silverlight are included in the terminology and mitigations. One way around this that is generally viewed as safe is JSON with Padding, aka JSONP. The way JSONP works is this: you pass an HTTP GET request to retrieve a resource from another site which you do not control. The request contains two pieces of information:

1. The resource you want to retrieve.

2. The callback function that should be executed when the resource is returned.

What makes this safe? The callback function is always something that you control. It is assumed that if your callback does bad things, so be it; that problem existed without involving JSONP.

There is a convention around JSONP. The URL that you call needs to understand a querystring parameter named callback, which identifies the function to call when the method returns. How does this work? Assume we have a resource that, when no callback is specified, returns the following when requesting the resource at

http://localhost/WcfJsonp/jsonp/names:

[{"FirstName":"Scott","LastName":"Seely"},

{"FirstName":"Aaron","LastName":"Skonnard"},

{"FirstName":"Matt","LastName":"Milner"}]

With JSONP, we would like a GET of the above data to execute a function on our page named updatePeople. JSONP indicates that we do this with a request for the resource at http://localhost/WcfJsonp/jsonp/names?callback=updatePeople. In so doing, the resource is now returned as:

updatePeople(

[{"FirstName":"Scott","LastName":"Seely"},

{"FirstName":"Aaron","LastName":"Skonnard"},

{"FirstName":"Matt","LastName":"Milner"}]);

This causes the function, updatePeople, to be called as soon as the resource is retrieved.

How does this work? Most of us will use jQuery to get the job done and not think about things. But, without jQuery, JSONP is still possible. I’ll first show you how this works by hand, then with jQuery. jQuery eliminates a number of potential bugs, so I recommend reading the by hand portion solely to understand things—don’t implement it in production code!

Assume you have the following HTML body:

<body>
    <div>
      <input type="button" onclick="getPeopleJsonp();"

             value="Get people" />  
    </div>
    <div id="people"></div>
    <script type="text/javascript"

      src="/wcfjsonp/Scripts/jquery-1.4.1.min.js"></script>
    <script type="text/javascript">
        function updatePeople(data) {
          var innerHtml = "";
          for (i = 0; i < data.length; ++i) {
            innerHtml += data[i].FirstName + ' ' +

                         data[i].LastName + '<br/>';
          }
          $("#people").html(innerHtml);
        }

        function getPeopleJsonp() {
          var innerHtml = "<script type='text/javascript' " +

                          "src='http://scottseely-xps/wcfjsonp/" +

                          "jsonp/names?callback=updatePeople'><\/script>";
          $("#inject").html(innerHtml);
        }
    </script>
    <div id="inject"></div>
</body>

What is happening here? When someone clicks on the button, the page calls getPeopleJsonp. That code updates the content of the div whose id is inject to contain a script tag. The script tag points to a JSONP endpoint and passes the callback parameter indicating to call the function updatePeople upon success. That script is then evaluated, executes a local JavaScript function, and returns. Every time that same script is reinjected, the same behavior occurs.

Now, jQuery provides a more succinct mechanism for doing the same thing. Instead of having the previous two functions and updating the DOM ourselves, we would write this:

function getPeopleJquery() {
  $.ajax({
    dataType: 'jsonp',
    url: "http://scottseely-xps/WcfJsonp/jsonp/names",
    success: function (data) {
      var innerHtml = "";
      for (i = 0; i < data.length; ++i) {
        innerHtml += data[i].FirstName + ' ' + data[i].LastName + '<br/>';
      }
      $("#people").html(innerHtml);
    }
  });
}

The code to inject information into the DOM still occurs, as does the creation of a callback function. What jQuery does is it adds script tag to the DOM only until the callback (success function) is done executing. The tag is added to the header. It also adds a function to the window object which is called on return. The URL jQuery constructs looks like http://localhost/WcfJsonp/jsonp/names?callback=jsonp1283609644773. What it actually does is add the following:

Within the window object, a new function is added:

jsonp1283609644773 is just an object living on the window object and is a dynamically added function. When the function is done executing, it will remove itself from the window object, leaving a slot by the same name with a value of undefined. What does the function look like when it is alive?

function(q){n=q;b();d();z[i]=v;try{delete z[i]}catch(p){}A&&A.removeChild(B)}

So, yeah, not too intelligible, but it does appear to handle things just fine. b(), d(), and the other functions are all part of the minified jQuery library, meaning that it all makes sense in the context of the containing object. The call to b() is contains code to call the success function. Everything else is cleanup code (at least from what it looked like to me…). To make this whole thing work in WCF, you need to do a couple simple things:

1. Only use WebGet to fetch resources.

2. Make sure the resource is hard-coded to respond in JSON. Otherwise, the response will appear as XML and the callback code won’t execute.

3. Make sure your binding supports JSONP.

4. Make sure your service requires ASP.NET compatibility.

For example, to get the names, I have the following WCF code:

[ServiceContract]
[AspNetCompatibilityRequirements(
  RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
public class JsonpDemo
{
  [OperationContract]
  [WebGet(UriTemplate = "names", ResponseFormat = WebMessageFormat.Json)]
  public PersonName[] GetNames()
  {
    return new PersonName[]
              {
                new PersonName {FirstName = "Scott", LastName = "Seely"},
                new PersonName {FirstName = "Aaron", LastName = "Skonnard"},
                new PersonName {FirstName = "Matt", LastName = "Milner"}
              };
  }
}

Configuration has:

<system.serviceModel>
  <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
  <standardEndpoints>
    <webHttpEndpoint>
      <standardEndpoint crossDomainScriptAccessEnabled="true" 
                        automaticFormatSelectionEnabled="true"/>
    </webHttpEndpoint>
  </standardEndpoints>
</system.serviceModel>

The crossDomainScriptAccessEnabled flag turns on the ability to correctly parse and respond to the presence of the callback parameter in the query string.

Finally, I added a route to handle the service within my Global.asax:

var factory = new WebServiceHostFactory();
routes.Add(new ServiceRoute("jsonp", factory, typeof(JsonpDemo)));

I was looking at the technology only to evaluate how to use it and to understand, a bit more deeply, how JSONP actually works. I found myself looking for a post that explains the magic, but most of the information I found just said “use jQuery.” Handy—sure. But that didn’t help me understand all the magic goodness that jQuery was doing for me.

Talking about REST

2010-09-02T14:55:00Z

Mark and Clark over at developersmackdown.com just published ‘my’ show: http://developersmackdown.com/archives/SingleShow/30. We spent time talking about REST and SOAP as well as a number of other topics related to REST. One of the things that I don’t think was made clear enough was that REST and SOAP are not competing service techniques. Each technology/interface type has an appropriate use case. When integrating applications within an enterprise, the development team needs to worry about:

- Security

- Transactions

- Reliable delivery of messages

- Integration with tooling for other developers

In the enterprise case, WCF + SOAP/WS-* can make integration between systems pretty simple. Yes, the teams may struggle with getting the security setup just right between domains, but overall, things will go well, especially if the setup requires communicating between different WS-* implementations. Finally, enterprise integrations typically happen for applications running on the same network/VPN. The infrastructure for an enterprise is different than that for the web. It’s important to build your applications for their environment.

When integrating applications over the Internet, sometimes WS-* adds too much complexity. For extensive integration across partners who are connected via the Internet, there is some benefit to understanding REST. REST will allow your application to scale using the HTTP architecture. Features such as caching, proxy servers, and the general uniform interface exposed by HTTP helps make things work better on the global network.

Because of my point of view here, when asked “do you prefer SOAP or REST?”, I am forced to answer “For what scenario?” I’m not popular in either circle, but understanding both helps me get stuff done.

Project Phoenix

2010-08-19T13:30:00Z

The current economic condition is hitting everyone pretty hard, even developers. For developers, part of the challenge in finding that next job is having the right, up to date skills. To help folks get those skills, Arnie Rowland and a number of other MVPs got together to pool MSDN subscriptions. This year, every MVP gets 3 MSDN Universal Subscriptions- 1 to use and 2 to give to worthy recipients. To pick a worthy recipient, an unemployed or underemployed developer needs to propose a software project for a non-profit agency, school, or church to be assisted by Project Phoenix. Arnie and his associates will then pick at least one project week to ‘fund’ with the MSDN Universal Subscription. A number of other companies joined in to offer more resources to help the selected developers make the most of this opportunity. Publishers have donated books and software companies have donated tools. I’m very proud that Pluralsight has donated a subscription to their .NET Training Library. I have created content for that library and am thrilled that an organization I am involved with is helping developers get back up to speed with current technology.

Project Phoenix is not a ‘free lunch.’ It supports the developers’ efforts so that they can gain from the work they do. I do recommend that you visit Arnie’s site to read all the details!

Here is the an example of one project that was funded:

Feed My Sheep: We are a community feeding program, that originally started as a 3 month summer project, one night a week we would provide a free meal for anyone who wanted to attend. We are in desperate need of a website in which we could post updates, have a calendar of volunteers and groups that will be serving each month and list special events.

Azure Storage is a RESTful service

2010-06-25T13:09:00Z

Today I had to build a demo for Azure and I noticed that I was following a tired old path where one demonstrates Azure storage services (Table/Queue/Blob) via a hosted application. My demo has two key points:

1. Look, there’s a picture that I uploaded!

2. Look, these processes can send messages via the queue!

The kicker was going to be that the messages are exchanged over the Internet, not the demo environment. I wanted a visible resource, an image of penguins, to be visible via a public URL. That was going to be the cool part.Then, I thought- “Well, the Azure SDK is just a bunch of libraries. The libraries should work fine in a console application, right?” Right!

And guess what: the demo actually works pretty slick because I can demo the storage service in isolation. I don’t need to demo it with a deployed application. That helps me out, and gives me some ideas on how I can use Azure differently.

I started out with a little utility class that reads a connection string from a config file and returns a ready to use CloudStorageAccount instance.

public static class Utility
{
  private static CloudStorageAccount _account;

  public static CloudStorageAccount StorageAccount
  {
    get
    {
      if (_account == null)
      {
        _account = CloudStorageAccount.Parse(
          ConfigurationManager.AppSettings["storageAccount"]);
      }
      return _account;
    }
  }
}

The config is just the following (minus the line breaks in the ‘value’ value):

  <appSettings>
    <add key="storageAccount" 
         value="DefaultEndpointsProtocol=https;

                AccountName=[your account name];

                AccountKey=[your account key]"/>
  </appSettings>

My scenario is this: I have a directory with images. I want to force those images to be uploaded to Azure blob storage. This needs to happen from the local machine. I was really surprised how easy this is to do. The Microsoft.WindowsAzure.StorageClient assembly has all the code you need to make this work. To upload the images and make them visible to the public, I just wrote the following:

static void Main()
{
  var client = Utility.StorageAccount.CreateCloudBlobClient();
  var dirInfo = new DirectoryInfo(Environment.CurrentDirectory);
  var cloudContainer = new CloudBlobContainer("friseton", client);
  var permissions = new BlobContainerPermissions
                      {
                        PublicAccess = BlobContainerPublicAccessType.Blob
                      };
  cloudContainer.CreateIfNotExist();
  cloudContainer.SetPermissions(permissions);
  foreach (var fileInfo in dirInfo.EnumerateFiles("*.jpg"))
  {
    var blobRef = cloudContainer.GetBlobReference(fileInfo.Name);
    blobRef.DeleteIfExists();
    blobRef.UploadFile(fileInfo.FullName);
  }
}

In this way, you can use Azure blob storage the same way you use Amazon’s S3. The queue can be used like the Simple Queue Service, and table can be accessed liked SimpleDB.

Yes, I understand that this has been possible for Azure all along. It finally clicked in my noggin that developing for Azure really can mean just picking and choosing the parts you want to use. You don’t need to go all in to use the service. Instead, just pick the parts that make sense and build apps!

For those that are curious, here is the queue demo too. It uses an object, Name, to send messages. This could be ANY object, I just picked something simple for demo purposes.

[DataContract]
public class Name
{
  [DataMember]
  public string FirstName { get; set; }

  [DataMember]
  public string LastName { get; set; }
}

It is sent to the queue with this code:

static void Main()
{
  var client = Utility.StorageAccount.CreateCloudQueueClient();
  var cloudQueue = new CloudQueue(
    Utility.StorageAccount.QueueEndpoint + "friseton", 
    client.Credentials);
  cloudQueue.CreateIfNotExist();
  var name = new Name {FirstName = "Scott", LastName = "Seely"};
  var stream = new MemoryStream();
  var writer = XmlDictionaryWriter.CreateBinaryWriter(stream);
  var ser = new DataContractSerializer(typeof (Name));
  ser.WriteObject(writer, name);
  writer.Flush();
  var buffer = new byte[stream.Length];
  Array.Copy(stream.GetBuffer(), buffer, stream.Length);
  var message = new CloudQueueMessage(buffer);
  cloudQueue.AddMessage(message, TimeSpan.FromHours(1));
}

And read from the queue thusly:

static void Main()
{
  var client = Utility.StorageAccount.CreateCloudQueueClient();
  var cloudQueue = new CloudQueue(
    Utility.StorageAccount.QueueEndpoint + "friseton",
    client.Credentials);
  cloudQueue.CreateIfNotExist();
  var ser = new DataContractSerializer(typeof(Name));
  var timeToStop = DateTime.Now + TimeSpan.FromMinutes(2);
  while (DateTime.Now < timeToStop)
  {
    if (cloudQueue.RetrieveApproximateMessageCount() > 0)
    {
      var message = cloudQueue.GetMessage();
      var buffer = message.AsBytes;
      var writer = XmlDictionaryReader.CreateBinaryReader(buffer, 0, 
        buffer.Length, XmlDictionaryReaderQuotas.Max);
      var name = ser.ReadObject(writer) as Name;
      if (name != null)
      {
        Console.WriteLine("{0} {1} {2}", name.FirstName, 
          name.LastName, message.InsertionTime);
      }
      cloudQueue.DeleteMessage(message);
    }
    Thread.Sleep(TimeSpan.FromSeconds(1));
  }
}

And yes, the queue code also works from your local machine. The example above does require you to have the Azure SDK installed.

Speaking at Chippewa Valley .NET Users’ Group Tomorrow

2010-06-23T21:18:00Z

I’ll be doing a beginner's talk on WCF tomorrow night at the Chippewa Valley .NET Users’ Group. Details are here: http://cvnug.wi-ineta.org/DesktopDefault.aspx?tabid=73. I’m looking forward to meeting some new people!

Reading a WebResponse into a byte[]

2010-06-15T20:04:00Z

This question came up on Twitter. I’m posting the solution here for posterity. How do you read a non-seekable Stream into a byte[]? Specifically, a HttpWebResponse? Like this:

class Program
{
  static void Main(string[] args)
  {
    var request = WebRequest.Create("http://www.scottseely.com/blog.aspx");
    var response = request.GetResponse() as HttpWebResponse;
    var stream = response.GetResponseStream();
    var buffer = new byte[int.Parse(response.Headers["Content-Length"])];
    var bytesRead = 0;
    var totalBytesRead = bytesRead;
    while(totalBytesRead < buffer.Length)
    {
      bytesRead = stream.Read(buffer, bytesRead, buffer.Length - bytesRead);
      totalBytesRead += bytesRead;
    }

    stream.Close();
    Console.WriteLine(Encoding.UTF8.GetString(buffer, 0, totalBytesRead));
  }
}

XmlDictionary and Binary Serialization

2010-06-14T13:00:00Z

One of the interesting things that came out of WCF is the improvements in Infoset serialization. In particular, WCF introduced a format for binary serialization which reduces space concerns for objects. One of the keys to saving space is the notion of an XmlDictionary. The WCF serialization folks asked the questions:

How much could we reduce the size of a message if we allowed the parties communicating to exchange metadata about the messages?

What if we could reduce the size of messages by exchanging aliases for the XML Infoset node names?

The result of this what if experiment is the XmlDictionary and XmlBinaryWriterSession. The mechanism is astonishingly simple. Assume that both ends have a mechanism for exchanging information about what to call the two parts of a QName: name namespace and the name of the node. Instead of sending namespace:element qualified items, send aliases. This works well in WCF messaging and happens whenever you send messages over the binary serializer. You can also use this in your own code that uses a binary serializer. The only requirement is that the serializer and deserializer have to agree on the makeup of the XmlDictionary. Let’s start by looking at some code that does plain old binary serialization.

We start with an object:

  [DataContract(Namespace = "http://www.friseton.com/Name/2010/06")]
  public class Person
  {
    [DataMember]
    public string FirstName { get; set; }
 
    [DataMember]
    public string LastName { get; set; }
 
    [DataMember]
    public DateTime Birthday { get; set; }
  }

I then have a ‘driver’ program:

    static void Main(string[] args)
    {
      var person = new Person
                   {
                     FirstName = "Scott",
                     LastName = "Seely",
                     Birthday = new DateTime(1900, 4, 5)
                   };
      var serializer = new DataContractSerializer(typeof (Person));
      Console.WriteLine("Serialize Binary: {0} bytes", 
        SerializeBinary(person, serializer).Length);
      Console.WriteLine("Serialize Binary with Dictionary: {0} bytes", 
        SerializeBinaryWithDictionary(person, serializer).Length);
    }

The application emits the size of the streams when each object is written out. The first, SerializeBinary, does not use a dictionary. As a result, it won’t have access to the aliases and must instead write out the full object.

    private static Stream SerializeBinary(Person person, 
      DataContractSerializer serializer)
    {
      var stream = new MemoryStream();
      var writer = XmlDictionaryWriter.CreateBinaryWriter(stream);
      serializer.WriteObject(writer, person);
      writer.Flush();
      return stream;
    }

In this case, we get a stream which contains 146 bytes. That’s pretty poor considering that we are interested in 10 characters (28 bytes: each string has a 4 byte length and then 2 bytes/character) and a simple DateTime representation (4 bytes). Can we make this smaller? How close can we get to 32 bytes? The answer: really close!

The version of SerializeBinaryWithDictionary that I wrote is verbose: it contains a number of lines that show what is going on internally. Your own code may be as long, but would include the lines as debug output.Please note that you need to include a reference to the XMLSchema-instance namespace in your dictionary so that both the reader and writer agree on the value of this attribute.

    private static Stream SerializeBinaryWithDictionary(Person person,
      DataContractSerializer serializer)
    {
      var stream = new MemoryStream();
      var dictionary = new XmlDictionary();
      var session = new XmlBinaryWriterSession();
      var key = 0;
      session.TryAdd(dictionary.Add("FirstName"), out key);
      Console.WriteLine("Added FirstName with key: {0}", key);
      session.TryAdd(dictionary.Add("LastName"), out key);
      Console.WriteLine("Added LastName with key: {0}", key);
      session.TryAdd(dictionary.Add("Birthday"), out key);
      Console.WriteLine("Added Birthday with key: {0}", key);
      session.TryAdd(dictionary.Add("Person"), out key);
      Console.WriteLine("Added Person with key: {0}", key);
      session.TryAdd(dictionary.Add("http://www.friseton.com/Name/2010/06"),
        out key);
      Console.WriteLine("Added xmlns with key: {0}", key);
      session.TryAdd(dictionary.Add("http://www.w3.org/2001/XMLSchema-instance"),
        out key);
      Console.WriteLine("Added xmlns for xsi with key: {0}", key);
 
      var writer = XmlDictionaryWriter.CreateBinaryWriter(
        stream, dictionary, session);
      serializer.WriteObject(writer, person);
      writer.Flush();
      return stream;
    }

The size difference is striking: we shave off 108 bytes by using the dictionary. We are getting close to the same size as the memory footprint of the object data! The cool bit: you can use this in your own code. The dictionary needs to be shared between the reader and writer sessions (there is a corresponding XmlBinaryReaderSession which can also be populated from the common dictionary via the deserialization process). For posterity, the output of the program is:

A slightly different version that shows both reading and writing with a shared understanding of what the dictionary looks like follows:

    private static Stream SerializeBinaryWithDictionary(Person person, 
      DataContractSerializer serializer)
    {
      var strings = new List<XmlDictionaryString>();
      var stream = new MemoryStream();
      var dictionary = new XmlDictionary();
      var session = new XmlBinaryWriterSession();
      var rdr = new XmlBinaryReaderSession();
      
      var key = 0;
      strings.Add(dictionary.Add("FirstName"));
      strings.Add(dictionary.Add("LastName"));
      strings.Add(dictionary.Add("Birthday"));
      strings.Add(dictionary.Add("Person"));
      strings.Add(dictionary.Add("http://www.friseton.com/Name/2010/06"));
      strings.Add(dictionary.Add("http://www.w3.org/2001/XMLSchema-instance"));
      Console.WriteLine("Added xmlns with key: {0}", key);
      
      var writer = XmlDictionaryWriter.CreateBinaryWriter(
        stream, dictionary, session);
 
      foreach (var val in strings)
      {
        if (session.TryAdd(val, out key))
        {
          rdr.Add(key, val.Value);
        }
      }
      serializer.WriteObject(writer, person);
      writer.Flush();
      stream.Position = 0;
      var reader = XmlDictionaryReader.CreateBinaryReader(stream, dictionary, 
        XmlDictionaryReaderQuotas.Max, rdr);
      var per = serializer.ReadObject(reader) as Person;
      writer.Flush();
      return stream;
    }

Looking at the above, we can also account for the missing 6 bytes in our serialization: the extra 6 bytes are names of the nodes.

Serialize Binary: 146 bytes
Added FirstName with key: 0
Added LastName with key: 1
Added Birthday with key: 2
Added Person with key: 3
Added xmlns with key: 4
Added xmlns for xsi with key: 5
Serialize Binary with Dictionary: 38 bytes

Speaking at Chicago Architects Group May 18

2010-05-17T23:53:00Z

I’ll be speaking at the Chicago Architects Group on May 18 over at the ITA (next to Union Station in Chicago- corner of Adams and Wacker). My topic is Azure for Architects. In this talk, I go over how to look at and use Azure from a software architecture point of view. Unlike most Azure talks, this one has no code in it—just concepts. This isn’t the type of talk I normally give, but given the crowd, architecture and slides will work better than whiz bang demos.

The slides are here if you want them. I tend to use slides as guideposts when I present. Please don’t look at these slides as notes. 80% of the presentation is in what I say, not in what you can read. I’ll try to record the presentation as well and will put up the recording if the quality is good enough. There are still some seats open. Register at http://chicagoarchitectsgroup.eventbrite.com.

Custom ChannelFactory Creation

2010-05-07T22:06:00Z

Just the other day, Derik Whitaker ran into some issues setting up his ChannelFactory to handle large object graphs being returned to his clients (post is here). After some back and forth through email, we came up with a solution. Instead of use the default ChannelFactory<T>, we created a new class that inherits from ChannelFactory<T> and sets the DataContractSerializerBehavior to handle int.MaxValue objects in the graph.

The trick is to override the ChannelFactory<T>.OnOpening method. This method is called as the ChannelFactory is opened and allows a derived class to alter the behavior at the last minute. All OperationDescriptions have a DataContractSerializerOperationBehavior attached to them. What we want to do is pull out that behavior and set the MaxItemsInObjectGraph property to int.MaxValue so that it allows all content to be serialized in. Derik’s use case was valid—he owned the client and server and wanted to incur any penalty associated with reading ALL data. If you are in a similar situation and need to remove that safety net/throttle in your code, here is what you need. Note that the constructors aren’t interesting other than they preserve the signatures made available through ChannelFactory<T> and make them visible in my DerikChannelFactory<T>.

public class DerikChannelFactory<T> : ChannelFactory<T>
{
    public DerikChannelFactory(Binding binding) : 
        base(binding) { }

    public DerikChannelFactory(ServiceEndpoint endpoint) : 
        base(endpoint) { }

    public DerikChannelFactory(string endpointConfigurationName) : 
        base(endpointConfigurationName) { }

    public DerikChannelFactory(Binding binding, EndpointAddress remoteAddress) : 
        base(binding, remoteAddress) { }

    public DerikChannelFactory(Binding binding, string remoteAddress) : 
        base(binding, remoteAddress) { }

    public DerikChannelFactory(string endpointConfigurationName, 
        EndpointAddress remoteAddress) : 
        base(endpointConfigurationName, remoteAddress) { }

    protected override void OnOpening()
    {
        foreach (var operation in Endpoint.Contract.Operations)
        {
            var behavior = 
                operation.Behaviors.
                    Find<DataContractSerializerOperationBehavior>();
            if (behavior != null)
            {
                behavior.MaxItemsInObjectGraph = int.MaxValue;
            }
        }
        base.OnOpening();
    }
}

The OnOpening override is also a good place to inject behaviors or other items if you want to make sure that all ChannelFactory instances have the same setup without resorting to configuration or code for each instance.

Move to WCF 4.0 for Less Configuration/Code

2010-05-04T05:00:00Z

People have lots of complaints around WCF. For the 3.x codebase, many don’t like the amount of configuration one has to write or code in order to get a service up and running. For example, let’s assume that we have a simple service contract, IEchoService.

[ServiceContract(Namespace="http://www.friseton.com/Echo")]
interface IEchoService
{
  [OperationContract]
  string Echo(string value);
}

The class is implemented by EchoService:

class EchoService : IEchoService
{
  public string Echo(string value)
  {
    return value;
  }
}

In .NET 3.x, we would then have to setup some endpoints, each endpoint specific to the protocol we wanted to understand. We had to remember things like “URLs that begin with net.tcp use the NetTcpBinding.” For intranet and local machine communication, this is a pain in the butt. In .NET 4.0, the common case of taking the defaults is much easier. If you plan on listening at the base URL(s) for the service, a console application can look like this:

(code only)

var netTcp = new Uri(string.Format("net.tcp://{0}/EchoService", 
  Environment.MachineName));
var netPipe = new Uri(string.Format("net.pipe://{0}/EchoService", 
  Environment.MachineName));
using (var host = new ServiceHost(typeof(EchoService), netTcp, netPipe))
{
  host.Open();
  Console.WriteLine("Press [Enter] to exit.");
  Console.ReadLine();
}

You could also configure the base URIs if you wanted this all to be dynamic. This mechanism only works if you don’t explicitly add any endpoints. Choosing to add any endpoint: discovery, metadata, or a specific contract WILL mean you have to specify everything. The implicit behavior will expose all contracts on the endpoint, so a service that implements 2 or more contracts will listen for all contracts when you use implicit listeners.

More with Discovery, Day 4

2010-05-03T05:00:00Z

Previously, we looked at configuring discovery on the server. What about the client? To discover from the client, we use a class named DiscoveryClient. DiscoveryClient implements the WS-Discovery protocol. Discovery is typically done over UDP because UDP allows for endpoints to broadcast a message.

The client uses a FindCriteria instance. In our case, we will ask for discovery to give us the metadata exchange endpoints that have definitions for ITest. Upon finding 1 of these, or timing out, we will resolve the metadata exchange endpoint and ask for information about the endpoint. If at least one of those is found (which it should be but it may disappear in between the first request and this one), extract the ITest information and create an ITest ChannelFactory using the discovered binding and endpoint. Sample code looks exactly like this:

// Create a client to find ITest instance. Return as soon as 
// 1 is found.
var discoveryClient = new DiscoveryClient(new UdpDiscoveryEndpoint());
var criteria = FindCriteria.
  CreateMetadataExchangeEndpointCriteria(typeof (ITest));
criteria.MaxResults = 1;
var findResponse = discoveryClient.Find(criteria);
discoveryClient.Close();
if (findResponse.Endpoints.Count > 0)
{
  // Resolve the metadata for the first address. 
  // Return the binding and address information.
  var endpoints = MetadataResolver.Resolve(typeof (ITest), 
    findResponse.Endpoints[0].Address);
  if (endpoints.Count > 0)
  {
    // Create a factory based on the binding and address information
    // we received from the metadata endpoint.
    var factory = new ChannelFactory<ITest>(endpoints[0].Binding, 
      endpoints[0].Address);
    var channel = factory.CreateChannel();

    // Call the add function
    Console.WriteLine(channel.Add(3, 4));
    factory.Close();
  }
}

The above code will fail if authentication credentials other than Windows or anonymous are required. But, if you use standard windows authentication on the service (or nothing) this works well. Discovery is well suited to intranet scenarios, because things like Windows identities and authentication are already in use.

More with Discovery, Day 3

2010-04-30T05:00:00Z

By now, you might be wondering where a person would actually use discovery. A common case would be allowing two processes on the same machine to find each other and allow for dynamic naming of all endpoints (such as using GUIDs in the URLs). This could be used by every Windows Service that has an application running in the system tray. In the enterprise, you would use discovery as one part of a publish and subscribe system. The subscribers would query for all endpoints that publish some kind of information (which would allow the subscribers to poll). Alternatively, a publisher could periodically ask for all entities on the network that were interested in a given topic and push to those endpoints. Likewise, a client could look for a service that implemented some other functionality and dynamically configure itself (instead of needing a priori knowledge about how infrastructure is deployed).

To make a service discoverable on the server, you add a ServiceDiscoveryBehavior to the service. This behavior, when combined with a UdpDiscoveryEndpoint, allows the service to be found over a broadcast message sent on the network. If you want clients to be able to automatically configure themselves, you need to add an IMetadataExchange endpoint as well. The IMetadataExchange endpoint allows the service to send information about the contracts in use, the bindings against those contracts, and address information on where the service is listening for messages.

The following code constructs a ServiceHost for some service, TestService, that implements a contract named ITest.

var baseUri = string.Format("net.tcp://{0}/Test", Environment.MachineName);
using (var host = new ServiceHost(typeof(TestService), new Uri(baseUri)))
{
  // Make the service discoverable and make sure it has an
  // endpoint to announce its presence.
  var discoveryBehavior = new ServiceDiscoveryBehavior();
  discoveryBehavior.AnnouncementEndpoints.Add(
    new UdpAnnouncementEndpoint());
  host.Description.Behaviors.Add(discoveryBehavior);

  // Make sure the service can respond to probes.
  host.AddServiceEndpoint(new UdpDiscoveryEndpoint());

  // Add the ability to handle Metadata requests (aka WSDL)
  host.Description.Behaviors.Add(new ServiceMetadataBehavior());
  host.AddServiceEndpoint(typeof(IMetadataExchange), 
    MetadataExchangeBindings.CreateMexTcpBinding(), "/mex");

  // Tell the service to listen for ITest messages on net.tcp
  host.AddServiceEndpoint(typeof (ITest), new NetTcpBinding(), 
    string.Empty);

  // Open the host and start listening.
  host.Open();

  // Display what we are listening for
  foreach (var endpoint in host.Description.Endpoints)
  {
    Console.WriteLine("{0}: {1}", 
      endpoint.Contract.Name,
      endpoint.ListenUri);
  }

  // Wait until we are done.
  Console.WriteLine("Press [Enter] to exit");
  Console.ReadLine();
}

With this code, we have a service that is discoverable and callable without requiring a client to have any code or configuration that is specific to our service (though it may if the developer chooses).