Service Station, by Aaron Skonnard

Screencast: Configuring MEX endpoints

Aaron Skonnard — Tue, 30 Dec 2008 22:39:15 GMT

In this short WCF screencast, you'll learn how to configure your WCF services with Metadata Exchange (MEX) endpoints - both over HTTP and TCP - allowing consumers to automatically retrieve metadata from your services at runtime. Enjoy!

Be sure to check out our growing collection of short screencasts on the Pluralsight screencast page.

Previous WCF Screencasts (RSS for all posts in the series)

Screencast: Configuring services with behaviors

Aaron Skonnard — Sat, 20 Dec 2008 00:22:09 GMT

In this WCF screencast, I'll show you how to configure WCF services with behaviors, which will allow you to customize different aspects of the runtime execution "behavior".

Be sure to check out our growing collection of short screencasts on Pluralsight's screencast landing page.

Previous WCF Screencasts (RSS for all posts in the series)

Word 2007: mouse not responding, crashes on start/exit

Aaron Skonnard — Thu, 18 Dec 2008 17:38:57 GMT

Apparently, there's a nasty little bug in Word 2007 that occurs sometimes when an automatic update is applied. If Word is running while the update occurs, and your machine reboots while word is running, something bad happens to the system registry that basically cripples it. Symptoms include: your mouse no longer responds within the document or it crashes altogether when you start/exit the program.

It's happened to me twice within a few weeks so I figured it was something worth blogging about.

You can find the magic sauce to fix it here.

To summarize the KB article, you just need to delete the following registry key and you'll be fine:
HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Word\Data

Screencast: Configuring bindings

Aaron Skonnard — Thu, 11 Dec 2008 23:13:22 GMT

In this WCF screencast, I'll show you how to configure bindings on your WCF endpoints, which will allow you to customize the precise communication details you wish to support on your WCF services.

Be sure to check out our growing collection of short screencasts on Pluralsight's screencast landing page.

Previous WCF Screencasts (RSS for all posts in the series)

Screencast: Configuring WAS for TCP endpoints

Aaron Skonnard — Mon, 08 Dec 2008 22:04:22 GMT

In this WCF screencast, I'll show you how to configure Windows Process Activation Service (WAS) for TCP-based activation, making it possible for you to host your WCF service in IIS with TCP-based endpoints.

Be sure to check out our growing collection of short screencasts on our screencast landing page.

Previous WCF Screencasts (RSS for all posts in the series)

My geekSpeak webcast on cloud services (today!)

Aaron Skonnard — Wed, 03 Dec 2008 07:31:43 GMT

I'll be geeking out today on this MSDN Web cast, where I'll be talking about Windows Azure and Microsoft .NET Services, and the impact they'll have on .NET developers in the years ahead. We'll be following the typical geekSpeak formula -- all demo, no slides.

MSDN Webcast: geekSpeak: Cloud Services 101 with Aaron Skonnard
12/3/08; 12:00 PM (PST)
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032397078&Culture=en-US

RESTful .NET

Aaron Skonnard — Wed, 03 Dec 2008 07:19:47 GMT

My copy of RESTful .NET arrived today. In Jon's typical style, he dives right into the meat of the WCF 3.5 REST programming model and doesn't waste much time re-covering the basics. This is a great WCF-specific companion to O'Reilly's RESTful Web Services book. And I love the form factor.

Definitely a must have for .NET developers moving towards REST.

Congrats Jon!

Screencast: Hosting WCF services in Windows Services

Aaron Skonnard — Wed, 03 Dec 2008 06:51:26 GMT

In this screencast, I show you how to host WCF services within traditional Windows services. This is often necessary when you cannot use IIS/ASP.NET hosting for whatever reason or when you don't want to use message-based activation. In certain scenarios you want to ensure that your services are always running and that the host process won't be automatically recycled causing havoc on your underlying resources (think sockets). These are just a few of the reasons why some folks prefer this hosting technique in some cases.

Be sure to check out our growing collection of short screencasts on our screencast landing page.

Previous WCF Screencasts (RSS for all posts in the series)

Screencast: Calling services asynchronously with WCF

Aaron Skonnard — Mon, 01 Dec 2008 20:58:44 GMT

Time for another screencast in the WCF screencast series. In this one you'll learn how to call services asynchronously with WCF in order to avoid tying up your main application thread for extended durations. You'll see how to configure your service references to support asynchronous calls, and then I'll show you how to write the async invocation logic. Enjoy!

Be sure to check out our growing collection of screencasts via our screencast landing page at Pluralsight.

Previous WCF Screencasts (RSS for all posts in the series)

Teched EMEA 2008 Wrap-up

Aaron Skonnard — Tue, 18 Nov 2008 15:56:42 GMT

I had a great time at Teched EMEA last week in Barcelona. I gave several talks on emerging technologies in the Connected Systems space and had a great time interacting with everyone at the show. This is always one of my favorite conferences of the year.

If you're looking for my demos, you can download them here.

Also, if you weren't able to get a Pluralsight On-Demand invitation code from one of us during the show, contact me directly and let me know which session you attended and we'll get you one via email.

Also, they've announced the locations for next year's Teched events. Teched US will be held in Los Angeles, May 11-15, 2009. And Teched EMEA is moving to Berlin! (sometime in November 2009)

Teched EMEA 2008

Aaron Skonnard — Mon, 10 Nov 2008 13:49:01 GMT

I'm at Teched EMEA 2008 this week in Barcelona until Friday. I'm presenting several sessions on a variety of topics that I'm excited about including the Windows Azure Service Bus (part of the .NET Services layer), a first look at WF 4.0, moving towards Web 2.0 with WCF (primarily REST), and the WCF LOB Adapter SDK. If you're here this week, hope to see you in one of my sessions. I have some Pluralsight t-shirts I'll be giving away.

Also, if you're interested in our Pluralsight On-Demand offering, find one of the Pluralsight guys this week (Jon, Brian, Ian or me) and we'll give you a registration card for a special Teched discount.

Flander's introduction to M in "Oslo"

Aaron Skonnard — Wed, 05 Nov 2008 16:45:28 GMT

As I explained in my Introduction to "Oslo", the "Oslo" modeling platform comes with three main components: the repository, the modeling language (M), and the modeling tool ("Quadrant"). M is probably the hardest of the three to get your head around.

One of the reasons it's hard to get your head around M is because it's multifaceted -- it can serve different purposes -- and the different use cases aren't immediately obvious when you first jump in. In an attempt to make things clearer, my fellow instructor Jon Flanders has produced a nice introduction to M video that shows how M can be used as a simpler language for generating database tables. Check it out here.

By the way, we now have a central landing page for our screencasts produced by Pluralsight instructors. We intend to continue growing this collection of free screencasts over time.

"Oslo" and the future of BizTalk Server

Aaron Skonnard — Tue, 04 Nov 2008 21:34:57 GMT

“Oslo” is a new modeling platform being developed by Microsoft that promises to simplify the way we design, build, and manage systems on Windows. Check out my last post on Introducing "Oslo" for more details.

Because CSD also includes the teams responsible for Windows Communication Foundation (WCF), Windows Workflow Foundation (WF), and BizTalk Server, it stands to reason that “Oslo” is related to these technologies to some degree. It’s also reasonable to question what future impact, if any, “Oslo” might have on your applications that were built using these CSD technologies.

There are many similarities between the current version of BizTalk Server and some of concepts that “Oslo” tries to address. These similarities raise some understandable questions about Microsoft’s future roadmap for BizTalk Server. There have even been rumblings of a complete BizTalk Server rewrite on top of the “Oslo” modeling platform. Given what a complete rewrite typically means to a product, this would probably not sit well with most enterprise customers who have made serious investments in BizTalk Server and are counting on a stable future.

In order to help answer these concerns, Microsoft recently announced their plans for the next version of BizTalk Server, which will carry the moniker BizTalk Server 2009 (instead of the previously planned “R3” title), and clarified the future roadmap for the product. They announced that BizTalk Server 2009 will focus on the following improvements/additions: updated Windows platform support (e.g., Windows Server 2008, SQL Server 2008, and Visual Studio 2008), improved service enablement, a built-in UDDI registry, improved B2B integration, increased developer productivity, and even Hyper-V support. Notice there was no mention of "Oslo" in the list of new features.

Microsoft also made it clear that they plan to continue releasing a new version of BizTalk Server approximately every two years along with interim service packs as needed. They seem genuinely committed to maintaining the stability of backwards-compatibility of the product. Microsoft has assured customers that even with “Oslo” on the horizon, the charter for BizTalk Server remains consistent – it allows the Microsoft application platform to connect and interoperate with other kinds of systems (e.g., LOB applications, legacy systems, RFID devices, and B2B standards). BizTalk Server will remain focused on these core strengths and will not be rewritten for “Oslo” until it can value for their customers.

Microsoft has emphasized that BizTalk Server will follow a disciplined, evolutionary path to ease customer adoption of the newer platform technologies while continuing to build on the current mature BizTalk Server architecture. They have also promised that BizTalk customers won’t be forced to migrate to a newer version of the product before they are ready, and they have committed to providing backwards compatibility for applications built against previous BizTalk Server versions.

Furthermore, BizTalk customers will be able to take advantage of the “Oslo” modeling platform benefits – without any architectural changes to the product – by simply service-enabling their BizTalk solutions and composing those BizTalk services into composite “Oslo” applications using the modeling platform components.

So if you’re a BizTalk customer and “Oslo” is making you nervous, you can relax. Microsoft doesn’t have immediate plans to redesign BizTalk Server around “Oslo” from what I understand. The product team will remain focused on adding new features and capabilities requested by customers, and they’ll take a longer-term approach for incorporating new “Oslo”-driven features when that makes sense.

The BizTalk team will have to decide, like everyone else, if the “Oslo” modeling platform brings enough value to customers to warrant changes that might impact customers in the future. If the business value is evident, customers will want it. Otherwise, customers simply won’t put up with it.

What's probably more likely in the shorter term is some convergence between BizTalk Server and the new "Dublin" extensions that were also announced at PDC. "Dublin" provides a hosting and management experience for WCF and WF applications that will remind you a lot of BizTalk Server. I don't know of any details but it seems like an obvious path forward. I'll write more about "Dublin" in a separate post.

Introducing "Oslo"

Aaron Skonnard — Mon, 03 Nov 2008 21:01:52 GMT

At this year’s PDC, Microsoft announced a new technology called “Oslo”. This article aims to help you understand the vision of “Oslo”, how it fits into the bigger picture as a Microsoft developer, and some of the key features it will ultimately provide in the years ahead.

What is “Oslo”?

“Oslo” is a new modeling platform being developed by the Connected Systems Division (CSD) at Microsoft. CSD includes the teams responsible for Windows Communication Foundation (WCF), Windows Workflow Foundation (WF), BizTalk Server, and other related technologies. The “Oslo” modeling platform promises to simplify the way we design, build, and manage systems using these CSD technologies, as well as potentially many others down the road. It’s an incredibly ambitious endeavor by Microsoft to finally tackle the modeling space.

The initiative encompasses an entire group of forthcoming products and technologies that will be released by CSD over time. In order to lay the technical foundation for the “Oslo” modeling platform, CSD will first ship a new version of the .NET Framework and Visual Studio – currently referred to as .NET Framework 4.0 and Visual Studio 2010 – containing some key updates to WCF and WF that make it possible to author declarative workflows and services (think of these as XAML-based “models”).

In addition to these advances, the “Oslo” modeling platform provides a revolutionary model-driven approach for building distributed applications. The modeling platform consists of three main components: the “Oslo” modeling language (also known as “M”), the “Oslo” repository, and the “Oslo” modeling tool (also known as “Quadrant”), described here:

Repository
A store for distributed application “metadata”. The data in the repository describes the entities that make up your system, which other “Oslo” components can take advantage of to simplify the user experience for the different stakeholders involved.
Modeling Language (“M”)
A new text-based data modeling language, designed for developers, for describing the data stored in the repository and for generating SQL. The repository will come with numerous pre-defined schemas that represent common distributed application constructs. “M” also provides a grammar for creating custom Domain Specific Languages (DSL).
Modeling Tool (“Quadrant”)
A new visual editor for interacting with the data found in the repository. It provides a “visual” experience for the less technical stakeholders. You can both view & edit repository data using this tool. It even supports custom views for different stakeholders.

In a nutshell, developers use the modeling language to define new models – they could be data models, workflow models (e.g., XAML-based workflows), or even IT infrastructure models. Models are ultimately stored in the repository. The various stakeholders (analysts, architects, developers, and IT pros) can use the “Oslo” modeling tool to interact with the models found in the repository.

Runtime environments can then be built on top of the “Oslo” repository for executing models. One of the first runtimes to build on the “Oslo” modeling platform will be “Dublin”, the codename for some new capabilities being packaged into Windows within the “Application Server” role (it may end up being loosely referred to as the Windows Application Server). “Dublin” provides an enterprise-level hosting platform for WCF and WF applications and it will eventually use “Oslo” to simplify the deployment, scale-out, and various operations and management tasks (final details TBD).

Other Microsoft products and technologies are expected to build on “Oslo” to provide other runtimes. A few that have already been announced include Microsoft System Center (Operations Manager) and Team Foundation Server (TFS) in Visual Studio Team System. It’s important to note that the next version of BizTalk Server – BizTalk Server 2009 – will release well before “Oslo” so it will not include “Oslo” integration in the 2009 release.

Microsoft hasn’t yet provided official dates for when these various “Oslo”-related pieces will be released. All we know is that first they’ll release .NET Framework 4.0 and Visual Studio 2010, and then at some point after they’ll release the “Oslo” modeling platform and the first version of “Dublin”. PDC attendees received an initial “Oslo” CTP – they handed out at VPC at the show – for everyone else, keep your eyes on MSDN and the Microsoft Connect site. There will be a public Visual Studio 2010 CTP at some point but unfortunately, it may not contain the WCF and WF 4.0 bits according to my sources. It’s still unclear at what point WCF and WF 4.0, “Oslo”, and “Dublin” will be made publicly available.

The “Oslo” Modeling Platform

A typical distributed application is a complex beast. Part of this complexity stems from the fact that there are many moving parts – different types of data, different servers and environments, and different line-of-business applications running on different platforms – creating a complex heterogeneous environment to manage. In addition, there are numerous stakeholders involved in a typical distributed application – business analysts, enterprise architects, developers, and IT professionals – all of whom must work together to accomplish the goals of the system. Unfortunately different stakeholders have different concerns and priorities. This makes it difficult for the business to move forward towards common goals, especially when the technology is fighting against the business each step of the way.

For example, when someone notices that a key SLA isn’t being met, how does one go about tracking down the problem within a large distributed application? Which business process is it related to? Who is the business analyst responsible for that particular business process? What application actually supports the business process and what server is it running on? And more specifically, what component or service within that application is ultimately responsible for the problem preventing the business from meeting the SLA? Given today’s technologies, situations like this can be extremely difficult to resolve – yet they’re all too common – welcome to the wonderful world of distributed applications.

What many organizations need is a platform that addresses the complexities of distributed applications head-on. They need a platform that allows analysts to model business data and processes, architects to design the system, and developers to implement system components, while collaborating effectively with one another along the way. And perhaps more importantly, they need a platform that provides visibility into the applications and tools that make it easy to manage the system especially when problems arise. It should facilitate identifying problems, tracking down the cause, and resolving things quickly. They need a platform for managing the distributed application lifecycle more effectively.

This is precisely the type of support that the “Oslo” modeling platform promises to provide. “Oslo” provides the technical foundation for designing, building, and managing distributed applications while improving collaboration across the various stakeholders. Ultimately, the full “Oslo” vision will be realized by the various products that build on the “Oslo” platform like Windows Application Server (“Dublin”), Microsoft System Center (Operations Manager), Team Foundation Server (TFS), and potentially BizTalk Server. If successful, “Oslo” may radically change the face of distributed applications in the years ahead.

Understanding “Models”

The term “model” often comes with negative connotations. This is because the promise of “model-driven” architectures has long been touted but never fully-realized. The various attempts always seem to start with some great hype, but that hype quickly fizzles away once organizations try putting it to use. Hopefully that will not be the case with the “Oslo” platform. Ultimately, the success of “Oslo” will be judged by the companies that put it to use and are able to measure real business value.

There’s a lot of baggage that comes with the term “model”. It’s a term that can actually mean different things to different people. When Microsoft uses the term “model”, they’re using the term in the broadest sense – it’s an abstract representation of something – it could take many forms such as a picture, written text, or perhaps a concrete schema definition. Because of the real issues surrounding the term “model”, Microsoft often uses the term “schema” instead of “model”. So in the context of “Oslo”, when you hear the term “model” or “schema”, they’re probably referring to the same thing.

You can think of “Oslo” models as distributed application “metadata” or, in other words, data that describes the distributed application itself. One of the great lessons we’ve learned over the past few decades is that metadata is incredibly valuable to a platform. The more data we make available within our code, the more possibilities we open up to the runtime during execution. For example, a runtime can inspect the data found within our code to make execution and behavioral decisions dynamically.

We’ve experienced an incredible evolution of metadata technology over the last decade – from traditional DLLs, to COM type libraries, to .NET metadata attributes, and culminating in XAML in .NET 4.0 – each transition has moved us closer to the vision of “code as data”. A declarative workflow service, encoded in XAML, is nothing more than data that can be treated as code within a WF runtime. And since it’s just data, it can also be queried, tooled, stored, and deployed in a lot of different ways.

The repository is a place to store declarative programs along with other types of distributed application metadata – you can store models for things like IT infrastructure (e.g., physical machines and their environments), business processes (e.g. workflows), and even service level agreements (SLA). “Dublin”, on the other hand, is a runtime environment for deploying, executing, and managing these models (primarily XAML-based workflows, which are also considered “models” by “Oslo”).

The fact that you can actually “run” a model sets the “Oslo” modeling platform apart from those of the past. This completely removes the gap between the model and the resulting code that is often problematic in today’s modeling environments. “Oslo” makes it possible for a variety of different stakeholders to collaborate on the same model definition, which can be executed in a model runtime without losing any fidelity. In this sense, “Oslo” gives you a more direct path for getting thoughts out of your head and into a running system. As Microsoft likes to put it, “Oslo” attempts to move from a world where models describe the application to a world where models are the application.

Ultimately, models sit at the heart of the “Oslo” platform. You store models in the “Oslo” repository and stakeholders interact with models found in the system through the “Oslo” Visual Editor (“Quadrant”). And when you need to extend the “Oslo” repository with domain specific models, your developers can use “Oslo” modeling language (“M”) to define them. Let’s dig into each one of these below.

The “Oslo” Repository

The repository is really the central nervous system of the “Oslo” modeling platform. It’s what the various stakeholders and system components look at to figure out what to do. It enables everyone to work from a common information set, thereby improving communication and cross-stakeholder collaboration.

Ultimately, the repository is just a SQL Server database that contains a bunch of tables and rows. Developers can use the “Oslo” modeling language to define new models to be incorporated into the repository. However, the “Oslo” modeling platform will initially ship with numerous pre-defined models common to all distributed applications, thereby reducing the need for custom models to some degree. The repository makes some exciting things possible. It’s ultimately what allows different stakeholders in a distributed application to collaborate with one another throughout the application lifecycle.

For example, the analysts can define the data models, business processes, and SLAs that drive the business, without getting into any technical details (they’ll typically do this by using the “Oslo” modeling tool we’re about to discuss). They can also define the events they’ll want to monitor and track over time. All of this information is stored in the repository. At the same time, the IT pros can describe the infrastructure landscape (e.g., data centers, clusters, computers, etc) and store that information in the repository. Developers can then access the models in the repository and implement them with Visual Studio using declarative WCF and WF code. Once they’re done, they’ll store their XAML-based models back in the repository. An architect can then define an application model for how the various software models should be deployed onto the IT infrastructure and store the resulting model in the repository.

Once the repository contains these valuable models, IT pros can use Windows Application Server (“Dublin”) to deploy, execute, monitor, and manage the application across a set of managed servers. While the application is running, the business analysts will be able to gather valuable tracking information and business analytics. And when problems arise, IT pros can identify problems through the monitoring and tracking features, and figure out who to talk to by navigating the repository.

What I’ve just described is the long-term vision for the “Oslo” repository – the initial release will have a much more model scope in terms of functionality (so everything I’ve described here may not be possible in v1). Once TFS and System Center support “Oslo”, we’ll get closer to the full “Oslo” vision.

The “Oslo” Modeling Tool (“Quadrant”)

The other major component that makes up the “Oslo” modeling platform is the “Oslo” modeling tool – also referred by its codename of “Quadrant”. The goal of this tool was to provide an intuitive visual user experience for interacting with the models found in the repository. For example, “Quadrant” can be used to view data models, business processes, or even IT infrastructure models with appropriate views for each type. The tool also highlights the relationships between different models, making it easy to navigate and explore all of the valuable information found in the repository.

“Quadrant” was designed to be highly customizable for the different types of stakeholders involved in a distributed application. Every model in the repository comes with a default view but users can create custom views while they’re using the tool, in ways that are important to each stakeholder.

In addition to viewing information found in the repository, “Quadrant” also makes it possible for users to “edit” repository information. This will be the primary user experience for less technical users (like business analysts and IT pros) to add information to the repository or to make necessary changes in response to system feedback without having to work with the modeling language (“M”) directly. It also gives developers an easier way to track things down and find models of interest within the repository.

Without a tool like “Quadrant”, the “Oslo” modeling platform wouldn’t have be complete. The initial version seems to have great potential for bridging the gap between the stakeholders in a distributed application, and it’s great to see Microsoft investing in it up front. Hopefully this tool will continue to evolve into something that makes “Oslo” truly shine in the world of model-driven development.

The “Oslo” Modeling Language (“M”)

The “Oslo” modeling language – also referred to as “M” – is a developer-centric language for defining models without using a visual editor but without getting too bogged down in details either. “M” was specifically designed for developers to type and read, and it was meant to provide a nice middle ground between the worlds of visual modeling tools (which many developers don’t like) and the very low-level worlds of T-SQL and XAML. The primary reason Microsoft invented “M” was because their developers needed something like it for defining the myriad of models that will ship within “Oslo” and according to Microsoft, their developers didn’t want to work directly with T-SQL or a visual modeling tool.

It’s important to note that “M” does not mandate how data is stored or accessed, nor does it mandate a specific implementation technology. Rather, “M” was designed to allow users to write down what they want from their data without having to specify how those desires are met against a given technology or platform. However, the models are ultimately stored in the “Oslo” repository, which is a SQL Server database so we’ll need some tools for translating the “M” definitions into SQL constructs.

Once you’ve defined a model using “M”, you can use the tools found in the “Oslo” SDK to generate the resulting SQL and a repository installation package. The SDK comes with several tools for working with “M” models. There’s a tool for compiling “M” files into installable packages. And there’s another tool for installing models into the repository. The SDK also comes with a Notepad-style editor called Intellipad (IPad) targeted at developers working with “M” files (it’s actually more like Emacs than Notepad). It provides features like syntax highlighting, validation, and a command mode for using the "Oslo" SDK tools within an integrate buffer window.

If you’re savvy with SQL, you can actually bypass “M” and write data straight into the repository but I don’t expect that to be very common given the repository’s inherent complexity. Also, the repository will ship with a bunch of predefined models common to all distributed applications, further reducing the need for custom models. Hence, using “M” won’t be a requirement for building “Oslo” applications.

You’ll only need to use “M” when you wish to extend the “Oslo” platform with domain-specific models. You can use “M” to define a variety of different models – new data models, business process models (workflows), or even IT infrastructure models (describing physical hardware). You can even use “M” to define custom DSL's to further simplify the authoring of domain-specific models, which is one of the most compelling use cases in my opinion). You could use “M” to define a DSL for authoring domain-specific workflows that makes perfect sense to business workers.

Summary

“Oslo” provides a powerful new platform for designing, developing, and managing distributed applications on the Windows platform with key features that target unifying stakeholders, increasing visibility, and simplifying various development and management tasks. Whatever your role happens to be – whether business analyst, architect, developer, or IT pro – “Oslo” has something to offer you.

However, it’s important to note that you’re seeing a very early glimpse of “Oslo” in its longer-term roadmap. There’s a lot of work left to do on the “Oslo” front and the real business value won't become fully evident until other products have successfully used it to provide additional capabilities. Remember, “Oslo” is a platform for other things to build on. As a result, it probably won’t be very useful to you right now unless you’re an ISV looking for a new business opportunity. Before “Oslo” becomes immediately actionable at large, it needs to directly translate into decreased costs, additional capabilities, or improved business agility, and that's probably going to take some time for Microsoft to pull off.

There are numerous teams at Microsoft anxiously engaged in making this happen by using “Oslo” to improve their capabilities. Some of these include Windows Application Server (“Dublin”), Microsoft Systems Center, and TFS. Once they ship “Oslo” enabled versions, the business value of “Oslo” should become much clearer. It’s just hard to say at this point exactly when that might come to fruition. As always, “Oslo” could be the start of something big, and then again, it could just be another blip on the radar of “model-driven” hype. I guess only time will tell.

Additional Resources

Microsoft takes REST to the next level: the WCF REST Starter Kit

Aaron Skonnard — Wed, 29 Oct 2008 18:02:00 GMT

The first version of WCF didn't have any built-in REST support. WCF 3.5 introduced a "Web" programming model that enabled REST service development scenarios (through classes like WebServiceHost, WebServiceHostFactory, WebHttpBehavior, WebHttpBinding, WebGetAttribute, WebInvokeAttribute, UriTemplate, etc). However, building RESTful services today with WCF 3.5 still leaves a lot to be desired.

At PDC this week, Microsoft announced the WCF REST Starter Kit, which makes building RESTful services with WCF much easier. You can download the WCF REST Starter Kit from CodePlex. It comes with a new library of APIs, both new classes and extension methods, that address some of the common pain points around building RESTful services with WCF 3.5 today. For example, you'll find new classes like WebServiceHost2, WebServiceHost2Factory, WebHelpAttribute, WebCacheAttribute, WebProtocolException, and RequestInterceptor to name a few. One of my favorite features is how the new host enables an automatic documentation page for your RESTful services describing the URI design, message formats, and sample instances, making it much easier for clients to discover how to integrate with your RESTful service.

Today when you download the WCF REST Starter Kit from CodePlex, you get the source code, which opens up additional opportunities for community collaboration and internal customization. As we move towards .NET 4.0, the WCF team will be looking at the various features found in the WCF REST Starter Kit they'll be evaluating which ones make sense to roll back into the .NET framework moving forward.

The WCF REST Starter Kit also comes with a Visual Studio installer that provides a suite of new project templates that provide skeleton implementations for today's most common types of RESTful services including: REST singleton services, REST collection services, AtomFeed services, AtomPub services, and HTTP Plain XML (POX) services. These templates make it really easy to get simple REST services up-and-running quickly.

If you want to learn more about REST and the WCF REST Starter Kit, browse to the new REST landing page on MSDN WCF Dev Center. This will become the new gathering place for WCF REST resources.

I recently wrote a REST whitepaper called A Guide to Designing and Building RESTful Services with WCF 3.5, which covers REST design fundamentals, the new WCF 3.5 programming model, and the new WCF REST Starter Kit. It's a great way to get your head around REST and to start writing REST code. I've also recorded a bunch of screencasts illustrating how to get started with the starter kit. You'll find links on the REST landing page.

Kudos to Microsoft, specifically Vish, RC, Steve, Kent, and the rest of team for providing first-class REST support to .NET developers. I'm excited to watch this project continue to evolve over the next year.