• Feeds

    Subscribe in a reader

  • Ads

Congrats to all my friends working in the Identity space on the relase of first beta of the Zermatt SDK.

Other folks have written some great posts that provide the background and motivation for Zermatt better than I ever will, and there are some links you should check out at the bottom of this post.

Suffice it to say that Zermatt is about making the power of the claims-based identity protocols we shipped in WCF V1 programmable and usable by normal humans.

Zermatt has a few things that I think are really exciting:

  • Integration with IIdentity/IPrincipal, so code that you've written using [PrincipalPermissionAttribute] can be easily adapted to use claims-based authorization.
  • A new HttpModule for ASP.NET Web Application, making it much easier to turn web applications into claims-based identity consumers.
  • New ASP.NET UI controls for adding federated identity login capability to your web pages.
  • New framework API's that make creating security token issuers (STS's) much easier to implement.

I highly recommend reading Keith Brown's whitepaper for Zermatt developers, as it gives a great overview of what Zermatt is about and the value proposition it holds for connected application developers.

I'm really looking forward to playing with this.

Here are some more links:

Happy hacking!

Protocol Buffers

Posted on Wednesday, July 09 2008 by steve maine

Overheard in the restroom at a recent Web 2.0 gathering:

"Did you see that new RPC stack that Google is wearing? How gauche!"
"I know! It's so last season..."
"The whole thing is just so...I don't know...petty bourgeoisie"

And here I thought all the cool kids were doing REST. Silly me.

WCF .svc item templates for ASP.NET hosted apps

Posted on Wednesday, June 11 2008 by steve maine

I recently discovered a new (to me, at least) feature in Visual Studio called "Export Template". This guy lives in the VS File menu and makes it really easy to spit out VS project/item templates that you can use to create new apps. Very cool, and very easy.

One thing that's bugged me about the default WCF templates that ship in the box is that sometimes, the templates are too rich for what I want to do. Specifically, we don't ship an item template for an "empty .svc file" that doesn't have any configuration and doesn't spit out any code behind. I find myself wishing for this when I'm writing quick-and-dirty ASP.NET apps that host WCF services.

So last night I took my newfound knowledge of VS's "Export Template" feature to build me a few new templates that were more geared for what I personally wanted, and I thought I'd share.

The first one defines a custom System.ServiceModel.Activation.ServiceHostFactory inline in the .svc file, which lets me set up bindings imperatively:

<%@ ServiceHost Language="C#" Debug="true" Service="Service" 
                Factory="CustomFactory" %>

using System.ServiceModel;
using System.ServiceModel.Activation;

public class CustomFactory : ServiceHostFactory
{
    protected override ServiceHost CreateServiceHost(System.Type serviceType, System.Uri[] baseAddresses)
    {
        var host = base.CreateServiceHost(serviceType, baseAddresses);
        host.AddServiceEndpoint(typeof(Service),
                                 new BasicHttpBinding(), "");

        return host;
    }
}

[ServiceContract]
public class Service
{
    [OperationContract]
    public void HelloWorld()
    {
    }
}
 

If I'm being a bit more disciplined and externalizing bindings and such in config like a Good Developer, I can get an "empty" .svc file using the InlineService template. This one will throw an exception unless you explicitly add at least one endpoint in configuration yourself:

<%@ ServiceHost Language="C#" Debug="true" Service="Service" %>
using System.ServiceModel;

//Don't forget to add at least one endpoint in configuration!

[ServiceContract]
public class Service
{
    [OperationContract]
    public string Get()
    {
        return "Hello, world!";
    }
}

And finally, here's one that uses the System.ServiceModel.Web.WebServiceHostFactory to bootstrap my development of REST services. This one doesn't need any configuration at all, thanks to WebServiceHostFactory:

<%@ ServiceHost Language="C#" Debug="true" Service="RestService" 
                Factory="System.ServiceModel.Activation.WebServiceHostFactory" %>

using System.ServiceModel;
using System.ServiceModel.Web;

[ServiceContract]
public class RestService
{
    [OperationContract]
    [WebGet( UriTemplate="*" )]
    public string Get()
    {
        return "Hello, world!";
    }
}

If you like, you can download these templates for your own use here:

CustomServiceHost_CS.zip
CustomServiceHost_VB.zip
InlineService_CS.zip
InlineService_VB.zip
RESTService_CS.zip
RESTService_VB.zip

To install, just copy the .zip file to your <user>\Documents\Visual Studio 2008\Item Templates directory (no need to unzip, It Just Works):

image 

Once that's done, you should see them when you do "Add New Item" to an ASP.NET Web Site or ASP.NET Web Application Project in Visual Studio. You can see them hanging out in the bottom of this dialog:

image

If you find these useful, let me know. Especially if you have interesting ideas about Item Templates/Project Templates relating to WCF development that you'd like to see in the box...

IIS7 HostableWebCore

Posted on Sunday, June 08 2008 by steve maine

I spent a little bit of time this weekend playing around with IIS7's Hostable Web Core feature. This is a new thing in IIS7 that allows you to host IIS7 in a worker process of your own choosing. Kanwalijeet Singa has a nice description of the feature on his blog.

I love the idea of a having a lightweight, rehostable version of the IIS pipeline that can I stick anywhere. HostableWebCore is a great step in that direction, but (looking at things from a framework perspective, at least) it's not quite what I want.

Bring-your-own-process is nice, but I think I really want bring-your-own-app-domain as well. Having an appdomain barrier between the host and the pipeline is nice for reliability and enables things like AppDomain recycling, but I don't think I need that in all cases. I'd like to be able to new() up an IHttpHandler with some state in the host and stuff it in a Handlers collection and be done, without having to indirect though a local copy of applicationHost.config. I'd be willing to treat that pipeline configuration as immutable once opened in exchange for this capability.

I'd like to break the dependency on the physical file system as well, while we're at it. It would be nice if file system structure on disk were an option, not a requirement.

I wish the scope of HostableWebCore was at the virtual directory/application level instead of the site level. I'd love manage the HTTP.SYS URL reserverations externally instead of having HostableWebCore do it for me. This mainly so I can have multiple instances of this thing listening on the same port, demuxing by URL prefix at the HTTP.SYS layer. Right now I can't have multiple instance of HostableWebCore share the same port and that's heartbreaking.

Finally I wish there was a way to manage the receive loop externally so I have my own listener sitting under this thing pulling messages of of HTTP.SYS, I can just push these requests into the pipeline myself. Decoupling the pipeline from a direct dependency on HTTP.SYS would be a nice thing. I'd like to be able to swap out HTTP.SYS entirely in favor of my own sockets-based receive loop if I wanted to do such a thing. It's true that most scenarios would just use HTTP.SYS, but the ability to have different listeners is a good proof point for the architecture IMO. I also have a couple of crazy ideas floating around in my head that would use this capability, but I'm not quite ready to go public with those yet :)

To finish this off, here's an example of some hosting code that I'd like to be able to write:

public static void Main()
{
    var pipeline = new PipelineHost()
    {
        Port = 80,
        Hostname = "*",
        UrlPrefix = "mysite/myapp",
        
        Modules = 
        {
            new OutputCachingModule(),
            new SessionStateModule()
            {
                Provider = new SqlSessionStateProvider()
                {
                    ConnectionString = "Server=myDb;IntialCatalog=ASPNet;IntegratedSecurity=true"
                }
            }
        }
        
        Routes =
        {
            new Route()
            {
                UriTemplate = "customers/{id}",
                Handler = new CustomerHandler()
            }
        }
    }
    
    pipeline.Start();
    Console.ReadLine();
}

 

There are obvious issues around separation of concerns here when you define the behavior of the app completely inline like this. However, there are lots of ways to address those; the fact that the app can be be written this way if you want to is another one of those leading indicators that you got the arch right.

What do other folks think?

Graffiti!

Posted on Saturday, June 07 2008 by steve maine

This post probably sets me up for an awkward conversation with ClemensV on Monday, but oh well. To Clemens and the DasBlog crew -- thanks a ton for all your hard work to make DasBlog the engine that has powered Brain.Save() since I first started writing it back in 2003 (!).

However, I felt it was time to move on to a more 'turnkey' solution for my site.

I flipped the site over last night to Graffiti CMS 1.1 while I was eating an AllAmerican Slam at my local Denny's. The move was seriously that simple. I was able to use the DasBlog Import feature to move the content over pretty much automatically...all 800+ posts came through mostly unscathed. The hardest part was finding a theme that I liked. I'm not really a CSS wizard (which is probably obvious), but I was able to find a reasonable starting point on the Web and then twiddle a bit to get to a good place for now.

Overall, I'm really impressed with what Graffiti has to offer.

One of the reasons why I made the switch was the ecosystem that seems to be building around Graffiti themes, widgets and plugins. I spend my spare time hacking on code for other projects (i.e. not my blog), so I'm looking for a lot of off-the-shelf/off-the-web functionality from the product and the community.So far I've been pleased with what I've seen other people build for me :)

There are few things that I'm still looking for:

  • A reasonable solution for syntax-highlighted code that plays well with Graffiti themes. I've noticed that some of my old posts containing syntax-highlighted code don't render well with the new CSS, and I'd like to get that fixed. Ideally I'd be able to do this through a Chalk Extension or a tag that gets processed on the server (<div class="code"> would be ideal).
  • An "archives" page that every post I've every written, from newest to oldest (potentially several pages organized by month/year).
  • Chronological "next post"/"previous post" links that appear in the single-post view
  • Some way for administrators to tag posts directly from the index view, so I don't have to explicitly open each page in the editor

These are all pretty common idioms and I'm sure they are doable with a little bit of Chalk/widget magic...anyone want to educate me?

New look for the site

Posted on Saturday, June 07 2008 by steve maine

It's (late) spring; I figured it was time to do spring cleaning on the blog.

If you're visiting the site in a browser, you'll notice a new UI theme. I wish I could I say I did that myself, but alas no...I found it :) What do you think? I'm trying on the red, it seems to work although it's a bit on the angry side. We'll see if I still like it in the morning. Looking through some old posts there's some wacky-looking content in there now, but I'm inclined to live with that for the time being.

If you're visiting the site in an aggregator, you might notice that the feed has a new URI: http://feeds.feedburner.com/BrainSave. Actually, I hope that you don't notice because it means that Omar's little plug in is doing its job, and everyone is paying attention to the 301 redirects that are now appearing at the old feed addresses.

There are other things afoot here as well; I'll go into the hows and whys tomorrow, likely. Right now I'm just hoping all my links still work, and working through a could of irritating details with my hoster.

In the mean time, let me know if you run into any issues with the new site.

Cool open source WCF tool

Posted on Friday, June 06 2008 by steve maine

Eyal Vardi has been coding up a storm, it seems. He's got a lot of neat tools for WCF/.NET development up on his weblog.

My favorites are the WCF Debugger Visualizers. The internal structure of some of the WCF runtime objects (like ServiceHost and ServiceDescription) can get quite complicated, and spelunking those through the tiny window provided by the debugger's default property grid can be painful.

Once you install Eyal's visualizers, you get a rich visual view that makes exploring the OM much easier.

The code is up on CodePlex: WCFVisualizer

Thanks Eyal!

In case you haven't noticed yet, the bits for .NET 3.5 SP1 Beta 1 and Visual Studio 2008  SP1 Beta 1 are now available...take a minute and go grab them, and then you can finish reading this post while they install :)

What's new?
Looking at the platform holistically, the big-ticket features in SP1 are the ADO.NET Entity Framework (finally ;) ) and the ADO.NET Data Services (Astoria). I'm sure lots of folks will be talking in-depth about those things, so I'll focus on some of the smaller (but no less interesting!) features that my team is delivering as part of this release.

From the WCF/WF perspective, here's what you can look for in SP1. There's a lot here and each one of these probably merits an individual post but here are the bullet points:

Core Framework

  • Expanded UriTemplate syntax including support for compound template segments (like /{filename}.{ext} and /customers({id})), default values (like /customers/{id=0}), and optional trailing slashes.
  • Syndication OM for the Atom Publishing Protocol. We added strongly-typed OM for all of the constructs defined in the Atom Publishing Protocol specification (like ServiceDocument and Workspaces) and put them in the System.ServiceModel.Syndication namespace.
  • Attribute-free Data Contract serialization. The DataContract serializer now supports a model that doesn't require you to put [DataContract]/[DataMember] on every serializable member.
  • Interoperable Object References. The DataContract Serializer now supports an interoperable object reference scheme that allows it to serialize object graphs (not just trees). Thanks to this, Entity Framework types are also serializable via the DataContract serializer.
  • Improved logging/tracing in Partial Trust. We added more of our diagnostic/tracing path to the partial trust sandbox to improve the debuggability of hosted applications running in partial trust.
  • Scalability Improvements on IIS7: It's now possible to plug WCF into IIS7 asynchronously instead of synchronously, which can improve overall throughput and thread utilization on IIS7 for a class of high-latency scenarios.

Tools

  • Enhanced Service Test Client: The Test Client can now test services that use MessageContract/XmlSerializer types as well as Nullable<T>.
  • Hosting Wizard: There's now some tooling support for deploying Service Library projects to a host environment
  • Workflow Designer Performance Improvements: Auto-Save is faster now. A LOT faster.
  • Silverlight Templates: Visual Studio templates for WCF services in Silverlight, nuff said.

We've managed to put a lot into this little release...take a look at the new bits and tell us what you think.

Read Brian's blog on F#

Posted on Friday, May 09 2008 by steve maine

You should seriously check out Brian's F# blog. It's way good.

Brian is a WCF alum; he owned a hefty chunk of the code in System.ServiceModel.Dispatcher and the 3.5 Web Programming Model work.

It's funny...I used to mistype his name in emails a "Brain McNamara" at least once a week, which actually was a pretty accurate statement.

Anyway, he's over in 41 working on the F# compiler now and blogging up a storm. I'm spending more time getting to know the F# language, and I'm liking what I'm seeing.

Nicholas has a good post on the binding validation WCF does in partial trust.

As he points out, a ServiceHost running in anything less than a fully trusted AppDomin will so some baked-in validation on the bindings being used. Specifically, we have a list of binding elements that are explicitly prohibited in partial trust, and if we catch you trying to use one of these binding elements we'll prevent your service from activating.

This behavior has absolutely nothing (zip, zero, nada) to do with security. For that, we rely on the Code Access Security features implemented by the CLR, like any other framework component.

So why do we do this validation? One reason -- usability. Exceptions at deterministic times (say, Open()) are vastly better than exceptions at random times (say, when you receive a message that triggers a code path that does a demand for a permission you don't have). Having binding validation in place doesn't make the system more secure, but does avoid exposure to a large class of issues that can be pretty hard to reproduce and diagnose.