WCF, SSL and an F5

Last week, I was asked to help troubleshoot a problem with one of our WCF services. It was an external service that was to be consumed by a vendor. It was necessary to use SSL and on our network we use an F5 Big-IP device for load balancing. The external DNS points to the F5 device which forwards the call on to the appropriate service on the internal server hosting the WCF service. Things get a little tricky with the F5 and SSL. Requests come in to the F5 over HTTPS. The HTTPS request is terminated at the F5 and the decrypted request is forwarded to the internal machine over plain HTTP. How does one configure the WCF service and client when the client needs to send the request over HTTPS, but the service is going to receive it as HTTP?

Here’s the solution I came up with: First, both client and server need to use a basicHttpBinding. On the server side, I set the security mode to “TransportCredentialOnly” for the binding, then set the endpoint address as “http://domain.com/MyService.svc”. On the client side, the security mode for the binding is set to “Transport” and then endpoint address is set to “https://domain.com/MyService.svc”. The key difference being the registration of the client endpoint as https, while the service endpoint listens on http.

The test harness we built was then able to successfully consume the WCF service. The next problem was that the vendor still needed access to the schemas. In order to generate the schema automatically, the httpGetEnabled attribute on the service behavior needs to be set to true. Problem is, if it is set, the auto-generated path to the schema is over http, which would get blocked at the F5 device because it is only expecting secure traffic. If I took the generated path, but substituted https for http I could resolve the WSDL. So, what I ended up doing was as a temporary solution was to download the auto-generated schemas. I updated the references within the WSDL and XSD files so that they all used https to resolve addresses related to our service, then published these files to a “Schema” directory on the web server where the service was running. I then turned off the httpGetEnabled attribute on the service behavior, enabled the httpsGetEnabled attribute and set the httpsGetUrl to the URI for the WSDL I had just uploaded to the “Schema” folder. I fired up Visual Studio and added the Service Reference without issue.

I would’ve liked to have been able to have been allocated to coming up with the permanent solution for the WSDL, but I was reassigned as the immediate need was resolved. I suggested looking into deriving a class from the WsdlExporter that could enforce https for any schema URI related to the service. I don’t know if it’ll work, but it seemed as good a place as any to start.

LINQ Queryable SharePoint Collection

Today I ran into the need to bind the items in a SharePoint list to an asp:ListView control. While it was possible to use the SPListItemCollection as the DataSource for the control, it was made complicated by a "Hyperlink or Picture" column I was using in the list. When returned, that column would return as a single value in the format "{URL}, {DisplayText}". If I wanted to use the SPListItemCollection, it meant my ASCX page would be cluttered with string parsing, instead of a nice, clean <%# Eval("Link") %>.

I decided I would use LINQ to build the collection to bind to my ListView. Doing such, would allow me to move all the string parsing out of the front-end and into my classes. The only problem is that SharePoint collections are not queryable. A quick Google search, took me to a blog post by Asfar Sadewa, Direct Linq to SPListItemCollection. Then I thought, why not make this generic so that it can be applied to all SharePoint collections? Below is the result:

public class QueryableSharePointCollection<C, T> : List<T> where C : SPBaseCollection
{
    public QueryableSharePointCollection(C sharepointCollection)
    {
        this.Clear();

        foreach (T item in sharepointCollection)
        {
            this.Add(item);
        }
    }
}

Now I just have to instantiate a new QueryableSharePointCollection, specifying the collection type, and the type of the items in the collection, and I have a queryable collection derived from a SharePoint collection.

AppFabric of Our Lives

A couple weeks ago, I was assigned to a project creating the cross-cutting concerns in our new software architecture. Specifically, I was tasked with the caching aspect. As I searched for distributed caching solutions, I came across "Velocity", a Microsoft solution. As it turns out, Velocity is now a production release, part of the Windows Server AppFabric. I've spent the last few days setting up a virtual machine with AppFabric as my "cache cluster" and writing some tests against it. Here's some thoughts:

• The server-side installation is very streamlined. Much of the configuration is done after the fact through Powershell cmdlets, which I actually really like.
• When using Powershell to configure AppFabric, it must be run with elevated privileges, aka Run as Administrator. My account is a domain admin, but I kept receiving InvalidOperationException when I tried to use the Start-CacheCluster command.
• I looked through the MSDN documentation on how to set the size of the cache, and came across this: http://msdn.microsoft.com/en-us/library/ee790935.aspx. The Powershell commands listed for Cache size, Low watermark and High watermark under the Host Settings header are actually incorrect in the article. The correct commands are Get-CacheHostConfig and Set-CacheHostConfig.
• I played with adjusting the cache size and was actually able to adjust the size to more than the physical memory available on the machine. My guess is that it will just consume virtual memory after the physical memory is exhausted. The architects on my project were concerned with cost of physical hardware, so this may be an interesting compromise. I'll have to evaluate with some load testing.
  This is actually an incorrect assumption. Per Microsoft, you are allowed to configure the size past the physical memory in anticipation of growth, but AppFabric will throttle it back to the physical memory available.
• I noticed quite a bit of overhead on an object's size in the cache. I was pulling back a 350kb object (according to Fiddler) and seeing the cache size increase 560kb when it was added. I plan to follow up on this to see if I can determine what makes up the difference.
  Per Microsoft, there should be about 500 bytes of overhead per object stored in the cache. I believe my results were due to the object being returned from our WCF service being significantly larger when hydrated as opposed to the serialized data coming across the wire.
• Implementing caching in code is straightforward and intuitive with the AppFabric API.
• Performance is pretty great. I was able to pull 150 of those 350kb objects from the cache in the time it took to pull the 151st object from the service (although, maybe that says more about our ESB).

First impression: Windows Server AppFabric is pretty killer. If you're looking for a distributed caching solution, it's definitely worth a look. Check it out!

Ke Nako

It's time. The slogan of the 2010 World Cup is fitting for this my first ever blog post. I've always enjoyed reading blogs. Lord knows how many times someone's blog post has solved a particularly difficult issue I've spent hours googling. So, why have I never blogged? I guess I've never felt like I had anything worth sharing with the world.

I had lunch with a coworker today and we had a discussion that changed my mind. He made reference to a post Scott Hanselman put up this week, Do They Deserve the Gift of Your Keystrokes. I read through that post and the couple other posts he linked, and I have to say I'm pretty much sold. The gist is that we have a finite number of keystrokes with which to communicate in our lifetime. How much of those will be wasted communicating useful information to only a few people through email? I often find myself disseminating the same instructions to different people over and over. Better to post it in a central place that I can direct people to while cataloging the cool stuff I'm learning.

I'm actually pretty fired up to join the community. I've had lots of interesting concepts to look into already this week: OData, aspect-oriented programming, and Windows Server AppFabric to name a few Hopefully, I'll have some posts soon with some details about these and more!

So as far as blogging goes: ke nako.

~Josh