Request Interceptors are one of my favorite features of the "framework" preview bits in the kit because the eliminate a ton of boilerplate code that you would normally have write yourself. No more writing custom channels in most cases!
Entries categorized 'blog'
In case you were looking, the direct download link for the WCF REST Starter Kit is here:
The top link contains an .msi you can use, while the second link gets you the source code for the whole solution.
When I talk to customers about the API’s for building REST services we added to WCF in .NET 3.5, most people “get it” at some abstract level but come away really wishing for deeper guidance and samples on how to use the platform to address common problems. To answer some of those questions, we’ve taken about 20 of the top customer questions and put them into the REST Starter Kit download as SDK samples so you can look at code and see how the API’s are used in practice.
We’ve also gotten some requests around improving our experience in Visual Studio. To that end, we’ve taken 5 common use cases for WCF REST and turned them into Visual Studio templates to speed the developer experience. These scenarios including building an Atom feed, exposing singleton and collection resources over HTTP in a RESTful way, as well as simple XML and AJAX services. Aaron Skonnard from Pluralsight has recorded a great series of screencasts that show off the new developer experience. There are also some great hands-on labs to help you get started.
There’s also a new developer center on MSDN: http://msdn.microsoft.com/wcf/rest. This is the one stop shop for people interested in learning more about using WCF and .NET to build REST services.
Finally – this is the most interesting part – all of the REST starter kit bits are available today in source code form via the WCF Rest Starter Kit CodePlex site. There are a some fun new features and helper classes in the CodePlex library that I’m going to be talking about in my “Building RESTful Services” talk this Thursday at PDC. So if you’re in LA I hope to see you there (yes, it’s at 8:30 AM but I’m hoping to power through…)
A few days ago I created my own little political action committee on Facebook.
As you might infer from the title of this post, it's about ending nuke-you-luhr terrorism.
All are welcome and membership is free. The link is here.
We now return to our regularly scheduled programming.
As others have mentioned, Oslo has three basic components:
- A tool that provides a visual environment for creating, editing, and interacting with models
- A language for authoring models in a concise, textual way
- A relational repository for storing models, querying models, and making model data available to other parts of the platform
As Don mentioned, one of the goals of Oslo is to make application definition more of a data manipulation exercise as opposed to a code authoring exercise. We'll talk a lot about what this means in detail at PDC.
We're also going to be talking about how core parts of the development platform (.NET -- specifically, .NET 4.0) are evolving to support this vision while remaining independent of the Oslo-specific components. We've been doing a lot of work to bring WCF and WF forward in .NET 4.0 and I'm pretty excited to be able to tell you about them.
Should be a great PDC...
I've often used the "Hundred Dollar Exercise" with groups of folks at SDR's to get a rough sense of how to prioritize features.
This is where you give people a list of possible things you might build and 100 virtual dollars to spend across all of those. The more important you think a feature is, the more money you spend on it. The results aren't really scientific but it's a quick way to get a general sense of how important various things are to customers.
In smaller groups, it's interesting to run the exercise multiple times.
Between each iteration, you can have a discussion about why a person chose to invest more in Feature X vs Feature Y and the rationale behind their decisions. Everyone in the room listens to the arguments, and then you run the exercise again until the everybody's "budgets" agree within some reasonably small epsilon.
This is same consensus-building approach that Wideband Delphi uses for task breakouts and work item estimation, but applied to the domain of relative priority instead of individual task duration.
The hunch is that the same crowd-based wisdom that helps Wideband Delphi produce accurate estimates will also apply well to other nebulous problem domains like strategy and opportunity analysis.
We're looking at making some improvements to our configuration system in the next release of WCF.
I'm very interested in hearing peoples impressions of today's configuration experience with WCF. What works well? What irritates you? What's easy and what's hard? If you could change one thing (or five) about WCF configuration and the SvcConfigEditor.exe, what would it be? What's really important to you that we absolutely should not change?
I'm particularly interested in real-world feedback on how you'd grade the current solution on the following:
- Out-of-box developer experience
- Managing change across development lifecycle (dev/test/production)
- Separating out "stuff the IT Pro twiddles" from "stuff the service developer twiddles"
But any and all feedback you have in this area would be valuable, so don't be shy. Lots of folks from the product team will be watching the comments on this post as well as it's link cloud. If you prefer email, send me mail at smaine @ microsoft . com and I'll make sure it gets to the right people.
I hope the new Service Document OM we added in 3.5 SP1 will help cut out some of the more tedious parts of your implementation.
Side note -- are you doing open source work with the WCF web programming model? Send me an email (smaine @ microsoft . com), I'd love to hear about it
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:
- Zermatt announcement from Vittorio Bertocci
- Zermatt announcement from Keith Brown
- Download the Zermatt Beta SDK
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.