I'd like to draw the attention to a whitepaper by David Chappell – not a long one, being comprehensive, can be easily cited (like cloud platform is "kind of platform lets developers write applications that run in the cloud, or use services provided from the cloud, or both" ) – so good for enterprise consumption as well 🙂 It provides context for Microsoft Software Plus Sevices (S+S) strategy by explaining the rationale for what an operating system provides: a foundation, infrastructure services, and application services. And how a cloud platform applications compare with on-premises applications. He explains how the two application types work together. In addition, he breaks down each of the pieces that are needed for a complete cloud platform, including storage, identity, search, mapping, and integration.

The Windows Server Division has named the next server Windows Server 2008 R2. The release would be 'just' a "minor" or Update release. In a blog posting, Windows Server '7' aka "Windows Server 2008 R2", the team announced that the plan is to keep up with a two-year minor release, four-year major release cycle for servers. The current version of the Windows Server 2008 Product Roadmap shows that R2 will release in 2010. It explains that an update release "integrate[s] the previous major release with the latest service pack, selected feature packs, and new functionality." About the client release Ward Ralston (Group Program Manager) stated, that "The client will be a major release, but, as we’ve said before, compatibility with previous versions of Windows Vista and Windows Server 2008 is a design goal."

The short overview of cache providers continues with two more of them – NCache and Velocity.

NCache

As a surprise – it doesn't come free! So our (my) expectations should be even higher. But hey – it has a free option as well! So – what we get from NCache?

• Enterprise Library pluggability – this can be useful, but doesn't seem to be unachievable using the other providers as well…
• HttpModule for 1.1, Session handling module for 2.0/3.0/3.5 for putting asp.net session into cache
• Can handle java and .net clients natively
• You have the option to build complex hiearchies, clusters, etc

So – this looks like heaven, or not? The trick lies in the limitations for the free version:

• Only a maximum of 2 servers supported
• Cache clients should be either local or from the second cache server
• Only the replicated cache topology can be used
• No support for session state/output cache (means no module)
• 32-bit only (which would mean a 2 Gig cap on cache size, but it's limited as of 500 Mb anyway…)
• No java clients, no remote .net clients
• No SQL dependency
• No event notifications (!)
• No GUI tool
• …

So most of the limitations are rock solid and stops me from using this, sorry…

Microsoft Velocity

Microsoft Velocity is anotherdistributed cache platform for in-memory caches spread across multiple computers. The Velocity API is in managed code, and as usual – any serializable managed object can be in the cache. So let's look at the bells and whistles and the downsides:

• It's running as a 32bit process – in order to use more than 2Gigs you have to run more of them
• It has session state provider module for asp.net
• It supports regions as another level of separation as well as asynch communication, locking and TTL
• Planned support for failover, replicated cache (currently only local/partitioned/routed available) and eventing

So if it's at least as good as the others why not using it today? I have to admit – I'd miss many of the planned features… And as it looks like currently, CTP2 is on the way to be delivered at PDC, and RTM is targeted to be in H1CY09…

Of course – this is not a full list. If you know any cache provider you think may worth showing here – don't hesitate. And I'll try to come to a conclusion in the part 3 – so be prepared!

In the following weeks, I'm going to learn about new technologies, strategies – or shorter to say: get a glimpse into the future. I'm going to get tons of information about things like new wave of products and old products' new waves – and what is the worse, I cannot share anything…

So see you in mid-August, when my journey across technology and architecture continues 🙂

Everybody knows about, that you have to be very keen about using unmanaged resources (like filestreams, sharepoint objects, sockets, etc), disposing them whenever it's important, etc. But do we know all situations, that you have to be careful not to leak memory or not to let an unmanaged resource to be collected by garbage collector (which should mean you were unaware about it being unreleased at the appropiate time)? I tried to collect most of the situations where you may leak an unmanaged object the way you even didn't think about.

Returning a ref value

Wow – returning a value may cause problems? But how? The sad thing – it's not that hard to create a situation when just returning a reference value can cause (curable) problems. Look at this situation:

We have two objects, both of them having unmanaged references to each other – let's name them Parent and Child. Let's state that both of them are backing up unmanaged resources as well. If I return the Child object from a call (let's say Child GetFirstChildForThisParent(guid), and it looks up the parent according to the guid given), the following is happening:

You get a child object, which you use for what reason you would like to use it – the problem arise at the end of your code snippet, when you want to dispose the object – you have to be very cautious when freeing it up. If it has a managed reference to the parent – you can grab it, and free it! Or not? No, you can't dispose it – what happens, if there are anything else in the memory from the parent – any other child, any other references that are hold, etc. So – where are we? Again at the reference counting world of COM arrived? Yes, this can be a solution as well, but what if you create a small class holding the parent and the child object together, and giving that as a result – and of course creating a new parent every time needed… That could work as well. So – this could be a solution, but this will create additional needs on the memory footprint and the number of unmanaged resources…

Iterating over a collection

Ok, what happens, if I iterate over a collecting? Collection iterating is done in two parts – first you get an iterator, than you get the values each by each by calling some property. So – in order not to leak the resources this time, try to reuse the collection from the original object in the iterator, and the main point – plan how you are going to manage the values you are giving from the list. A small problem would arise with this approach – you are not able to modify the collection easily while you are iterating over it, it's not easy anytime, but the unmanaged resources you are holding are going to drive you nuts 🙂

Yielding

Ok, yielding – it's a very good thing, but do we know exactly what is happening? State machine created, calls are stopped by early returns, etc. It's one of the most useful creations in .NET, but – if you followed the previous paragraphs carefully, you already should know what is the problem – you don't have the right control over the creation of unmanaged resources and linkage between them… So, as for the others, you can use this useful tool as well, but you have to be very careful at most of the cases… 🙁

According to a commenter there is always a question – are we allowed to use non-ms labeled technologies whenever it is appropiate?

Answer is tough – myself had the opportunity to use multiple technologies like NHibernate or NVelocity at multiple projects like a very complex system for a Canadian Insurance Company. And what is 'worse' – I was developer of those open source projects at the cost of my employer.The whole things depends not on technology, but it's inside various brains 🙂

It's all about things like Not Invented Here, Legacy Software, and Big Brand – these are things that cannot be proven by the right technology, just by the right approach. So, sorry, I cannot give the right answer…

I forgot an important part of the previous posts – I was talking about many projects using the original Velocity for many purposes – but is the .NET version used? I tried to put together a noncomprehensive list of usages – feel free to comment to add your own! One important thing – currently there are 2 branches on NVelocity – one can be found at http://nvelocity.sf.net, the other is part of Castle – use the latter one, it has more bells and support as well 🙂

• Project Castle
• Microsoft ASP.NET MVC has a flavor for using NVelocity (claim 1, claim 2, claim 3)
• Telligent System's Graffiti (same company makes Community Server that runs under many sites – like our one as well)
• Visual Studio Colorizer for NVelocity
• Castle Visual Studio Integration also has colorizer – and intellisense for NVelocity
• And manymanymany websites that are not mentioned here…

This post is part of the open source series

First of all – the Silverlight DRM client is FREE!

The main component for playing DRM protected content with silverlight streaming was released during the weekend – and it's called PlayReady Server SDK. There are two distinct license agreements depending on your needs – one for developing PlayReady Server Applications (the SDK itself) and another for deploying a PlayReady Service. About the bucks – no, it's not free: for developing applications, 30.000$ one time license fee is needed; for the deployment, an additional 30.000$ processor fee OR a 0.001$/license fee is needed. For qualified customers a 120 days eval period is given as well for testing and evaluating. Another possibility is to license the SDK as an ISV to build WPF applications that could process content protected with PlayReady.
The DRM technology itself is existing since 1999 – and PlayReady technology was later introduced to fullfit the ever increasing need for mobile instrumentation. Silverlight not being a mobile only technology (don't forget – sooner or later it comes to a phone near you, whether it is a Nokia or Smartphone), but thin enough to be a target platform for this technology. In the very soon future the technology will evolve to support literally anything from H.264 to AAC on any PlayReady compatible device and technology.

And now the fun part – how it works?

Silverlight DRM is a small, cross-platform version of the PlayReady client used exclusively by the Silverlight Web browser plug-in. Analogous to other online content services, a Silverlight service that offers protected content uses the PlayReady Server SDK to first encrypt the content. The first time a client tries to playback a protected media comes the individualization feature of the server – it binds the DRM client to the computer it was installed. Client is then authorized to connect to the license server and acquire a license – valid for the duration of the browser session. So every end-user is given an individualized Playready component and different certified license keys. This significantly reduces the danger of global breaks. If a specific version of a PlayReady client becomes compromised, it can be barred from acquiring licenses for new digital media files unless the latest version of the PlayReady client is downloaded that is robust against the circumvention.

If you got interested, you may play around with PlayReady – check the examples site, check the site for licensing, or read about the silverlight client.

Formerly as part of the Apache Jakarta project, now part of the Apache project itself can be found the Velocity project. Since the beginning, it is the de facto tool for generating template driven applications – websites, documents, etc., the list of projects, websites and tools powered by or capable of using Velocity is endless. As for other great and successfull projects (like Hibernate, which also uses velocity for generating POJO files), this was met with the new wind of .NET – there were NVelocity born. So to make it short – NVelocity is a .Net-based template engine – it permits anyone to use the simple yet powerful template language called VTL to reference objects, execute methods, etc defined in .Net code. Speaking of a web application, this leads to the MVC pattern – this simple to use and set up tool enables you to program against modells in your views, and put the controller in charge of binding the two – this (and NHibernate, and ActiveRecord, and Windsor…) is what lead to the born of the Castle and the Rhino projects – but these are in later post :).

So no whistles nor bells, but the main part of NVelocity is:

• You create the engine – new NVelocity.App.VelocityEngine(ep);
• You get a template – engine.GetTemplate("template.vm");
• You create a context – new NVelocity.VelocityContext();
• You fill the context – context.Put("key", "value");
• Than you merge the context with the template using the engine – template.Merge(context, outputStream);

The extras are coming mostly in the template file, and by the fact, that there are plenty of way to provide plugins into the system – ResourceLoaders for determining where to get the file (from the filesystem? database? embedded resource?), caches of various parts, etc. So, back to template file – what can I do?

• I can print the value for a key – ${key}
• I can use property getters and setters – #set ${object}.prop = "value"
• I can use loops, if-then-else, define macros, etc
• Call and return any method with parameterlists which may contain values, arrays, dictionaries, etc – ${object}.Method(${key}, "%{key = 'value', key2 = ${key}}");
• Meanwhile the whole thing is typesafe and – the template gets compiled into an AST tree the first time it met!

So – I think this is a very handy tool for generating source files, for generating documents and for driving data driven websites.

PS: No, it has nothing to do with Microsoft Velocity – that goes into the cache providers series 🙂

This post is part of the open source series

In the following few paragraphs I'll try to a give a less-or-more comprehensive view over the world of cache providers. What we call a cache provider? The first thing people generally do is cache things within their web processes. But this means your cache is duplicated multiple times, once for each thread. This is a waste of memory and you'll get low cache hit rates. If you're using a multi-threaded language or a shared memory API like the built-in System.Web.Cache with in-memory settings, you can have a global cache for all threads, but it's per-machine. It doesn't scale to multiple machines. Once you have 20 webservers, those 20 independent caches start to look just as silly as when you had 20 threads with their own caches on a single box. Cache providers' servers and clients work together to implement one global cache across as many machines as you have – like the state server or sql server options for System.Web.Cache. But is the default implementation of System.Web.Cache flawless and perfect? Some says no – there may be improvement both the server and client sides.

Memcached

Why bother with a linux damon cache implementation made by danga? Answer is easy: first of all – there is a win32 implementation for it. Secondly – there are thons of different APIs to access it from .NET. Three of those APIs am I going to further investigate – the .NET memcached client library, the enyim.com Memcached Client, and BeIT Memcached. (interesting thing to mark – 3 projects, 3 different forge – sourceforge, codeplex and google code 🙂 )

The .NET memcached client library is the one, that mostly follows the schema and technology of the java client – it's a 1:1 port of that one.

The BeIT client comes with many bells and whistles, like socket pooling, uses the ketama algorithm for sticking keys to servers (key – server assigment stays the same even if there are new servers added or removed between), most of the simple value types have their own optimized serialization, have compression schemas, automatic key prefixing, dead server detection, etc.

The enyim.com Memcached client comes with nearly the same set of features, except for an additional one – a provider project to wire it up into System.Web.Cache without any additional steps.

As a special experiment, there are .NET implementations of the memcached server as well, and compared to the native C implementation, they even doesn't work that bad. One of the implementations I tried was part of the experimental hive of the Rhino framework – I'll try to cover that framework in a later post 🙂