With the sudden proliferation of cloud-based services it no longer seems like much of a novelty to have an elastic infrastructure capable of on-demand scaling provisioning of virtual resources. Instead it has become something almost taken for granted, and it may even be expected that this can be easily provided given enough on-premise machines. New terms, however misleading, have even been coined to describe such an internal elastic architecture, and software custom tailored to the challenge has already been developed many times over, with even more offerings still in development.

However, working in technology education layers an additional set of requirements on this common expectation. Customers themselves must be able to trigger the provisioning of virtual resources, and access them directly from out in the wild wild web. What I am describing, albeit rather cryptically, are Virtual Labs.

The concept of a Virtual Lab is that a student can access a web page, and after a short period of boot-up time, be connected directly into a virtual machine that is set up and ready to provide a hands-on learning experience. These activities are typically limited in duration and do not provide persistence of a student’s work between sessions. This is less than ideal for typical classroom learning where a student will be using a single machine all week, but makes perfect sense for self-paced learning offerings wherein the student may spend many weeks working through the same material and computing resources cannot be tied up for the entire duration.

Right now QuickLearn is working to deliver some of its core .NET, SharePoint 2010 and BizTalk Server 2010 training offerings in a self-paced format. As part of this effort, it was decided that the lab activities for these new courses should be provided as Virtual Labs available from anywhere and on any device or platform containing a capable RDP client. An additional requirement was that we must be able to use existing VHD files for the classes, without having to rebuild anything or re-install software.

After existing solutions were evaluated (including Microsoft’s Virtual Machine Manager Self-Service Portal), it was decided that the solution should be built internally. Development was completed at the beginning of this week, and the resulting experience was even better than I had initially imagined.

(click for a larger view)

The solution ended up ultimately consisting of four separate components. The first was QuickLearn’s online player application. This provides the interface through which a student can initiate a Virtual Lab. Once the student decides to begin a virtual lab, a request is sent to a Virtual Lab Service. The Virtual Lab Service is a WCF service that is responsible for managing a pool of Hyper-V servers, and routing control messages to start / stop virtual machines. It is also responsible for providing the client with updates about the status of their request. Once the Virtual Lab Service receives the request, WMI is used to spin-up the requested instance (from a known save state). Within each instance, an application is running that will call back to the Virtual Lab Service when it realizes that the machine is back online. Once the Virtual Lab Service knows that the machine is online, it provides the client with connection details for accessing the Virtual Machine. Throughout all of this there is a processing loop that ensures VMs are properly destroyed whenever the time allocated for a given lab has expired.

Since RDP is being used for connectivity, the student can be offered an embedded connection within their browser (given that they are using Internet Explorer). If their browser will not support an embedded connection, they are provided connection details and instructions to connect directly to the image. One really interesting implication of this is that students running Windows 7 will be able to access newer Virtual Labs with true multi-monitor support.

The implications of using Hyper-V on the back-end is that we are able to share machines with up to three students and still provide a killer experience with multiple cores and up to 4GB of RAM per instance.

Overall, the development was more or less straight-forward, only requiring ~30 human-hours of time, and the reward for students will be incredible.

The .NET Endpoint blog announced this morning the availability of Windows Server AppFabric Beta 2, which can be downloaded at http://msdn.microsoft.com/appfabric. According to the announcement, Beta 2 was written to work against the RC of Visual Studio 2010, and is apparently now feature complete:

This build represents our “feature complete” milestone. That is, it contains all the features that we plan to ship in Windows Server AppFabric v1 by Q3 of 2010. For this release we focused on building a provider model for persistence, monitoring, and cache configuration stores. In our Beta 1 release we supported only the SQL Server based persistence and monitoring providers that we shipped and supported only an XML file based or SQL Server based cache configuration store. In Beta 2 we now also support providers for other database platforms or for other types of stores, in the case of persistence and cache configuration.

This is an exciting milestone for the team, and will certainly be a great time to begin evaluating Windows Server AppFabric for inclusion in upcoming projects.

Last week I undertook a completely unscientific study of the .NET Blogosphere (as much as I loathe that term), to determine which namespaces and classes people are most excited about, confused by, or frustrated with – at least to the point that they would dedicate the time to write in their blog about them. My methods for undertaking this study were rather simplistic. I wrote a quick and dirty console application to reflect through the .NET Framework namespaces and classes, and search the internet for mentions of them alongside the terms .NET and blog. For classes whose namespaces contained no periods, the full name of the class was used as the search term. For those classes whose namespaces did contain periods, the namespace and name of the class were used as separate search terms. For example, the class System.IO.File would result in a search for “System.IO File .NET blog”, whereas the class System.String would result in a search for “System.String .NET blog”.

More than to just do a popularity contest of the different classes, I wanted to try to determine the best sources of information for each component of the framework. I wanted to see which sites seemed to consistently beat out others as authoritative sources with complete coverage of a given area. In preparation for the transition to .NET 4, I also was interested to see if the features new to .NET 3, and .NET 3.5 received similar coverage to those classes/namespaces that are used in nearly every project created. This final concern will require further testing and analysis before any conclusions can be reached.

What I did find, however, was that (perhaps unsurprisingly considering the methods) those classes/namespaces which one might use more often round out the top 10 result getters:

I was surprised at how strong of a showing the Microsoft.VisualBasic namespace had among all other contenders. Another interesting study would be to look into those sites that are represented in the result count and find the ratio of C# to VB code contained within.

When looking only at classes, we find the following in the top 10:

From here it looks like features from .NET 2.0 (List<T>) and .NET 3.0 (System.Windows.Window) have gotten enough traction to make a big splash. Generics have had quite a long time to catch on so that’s not surprising. Features from WPF making the top 10 already is surprising (considering how much longer classes have had to be written about), and in this case may simply come as a result of the search term that the application used, which would split off Window from System.Windows.Window as its own term alongside the rest.

The top 10 sources for information about .NET would appear to be the following:

The number next to the name of the site indicates how many classes/namespaces for which the site is the top result. Further investigation shows that this might be inaccurate since dotnet247 seems to just index the entire framework and aggregate information from other sites in an automated fashion. Sounds like a great way to make some money from ads, but it might not be the best information source (though is still fairly genius). MSDN blogs definitely provide some serious coverage of the .NET Framework, and likely have excellent information about those classes/namespaces for which they were the top results.

Another interesting statistic that came out of this entirely informal study is that 29% of the .NET Framework (3.5) has less than 5 articles of coverage on the internet. In fact there are 389 classes or namespaces that would appear to have nothing written about them at all (according to the semi-flawed methodology described above).

You can use the download link below to download the complete results that contain all of the raw data that was analyzed, as well a pivot table, and some charts that can be used to explore it to some extent. What interesting information can you find? Has anyone else done a more formal survey of the same?

I was looking over some of the industry news this morning, and spotted this gem from Miguel de Icaza’s blog:

We are also porting our C# compiler to work with Microsoft's Reflection.Emit to enable us to run our C# Interactive Shell in Silverlight applications and to allow .NET developers to embed our compiler in their applications to support C# Eval.

For those that typically shy away from penguins: Miguel is heavily involved in the Mono project. Mono is a project under the wing of Novell to create an EMCA-334/335 compliant implementation of C# and the CLI. The project includes much of the base class library found in the .NET framework, and also includes more project specific classes. The big selling points for me are binary compatibility with existing .NET assemblies, and availability on multiple platforms.

This is certainly exciting technology (just look at the reaction Anders received demoing very similar functionality at PDC2008). Now imagine that same type of experience in the browser (minus the Windows Form popping up out of no where, since no one likes pop-ups anyway). Imagine games that can be scripted in-play, or instantly extensible rich client applications.

Naturally there will be security considerations, and testing considerations, but for now it is what it is: fairly awesome.

I was lurking around the ESB Toolkit forums yesterday, and got involved in an exchange with someone who was hitting the same roadblock to the Itinerary Designer that a lot of people hit: confusion with the model elements and extenders. Upon my first exposure to the Itinerary Designer it took me a week to get over the learning curve of this, and to understand why every send operation seemingly involved two off-ramp shapes instead of one.

Now in the case of that thread, the problem was actually not having a properly formatted SOAP request for the service that was going to be invoked (also a fairly common issue), but getting to the actual issue took cutting through some of the confusing bits of how the itinerary services themselves are implemented, and what they do.

That being said, I took some time last night to write up an article on the different model elements in the itinerary designer, their extenders, and how they can be used to compose an itinerary. You can access the article here: Making Sense of Model Elements and Extenders in the Itinerary Designer

Side note: The article is now part of the brand new (and still under-construction) QuickLearn Technical Library, which will soon contain many more similar articles and links to technical resources for all of the technologies about which QuickLearn teaches.

That’s all for now!