Hi folks, I thought I’d share something that captivated me on this rainy Easter day and that was

Visual Studio Asynchronous Programming - http://msdn.microsoft.com/en-au/vstudio/async
(you’ll need VS2010 + SP1 before you grab the CTP)
There’s a new improved compiler + an extended library for us.

Hands up who’s done async programming in either VB.NET or C#??? It’s a pain! Thread management, Main UI threads can only update certain objects, passing values between main + background threads, determining whether a thread has completed its tasks… and so on…

Basically all these ‘issues’ keep us from delving further into the world of asynchronous programming cause it very rapidly becomes complex just managing the two worlds – sync + async.

Today I was pleasantly surprised!!!

About a year ago I saw a great presentation on F# and I was amazed at how if they wanted to run a bit of code async it was simple an extra character as in:

set results = …..   <-sync

set results! = ….  <- run this async

(don’t quote me on the above, but it’s something like that – let’s call it pseudo code)

Why are we interested in this? – that’s always the first question to ask when investigating. Too many times we here ‘this is really cool’ and ‘check this cool software out’ etc… but the real reason of WHY do we want to go down this road is never answered.

On a ‘developers machine’ looking at 5 items, running a single test client – you’d have to say “works on my machine” and you’d have no need to async anything. True. Let’s move beyond our beloved developer box and think about UAT/PROD environments and what your code is doing.

What happens if 4 concurrent requests come along – how is your code going to perform? (As developers we’d be thinking …’it’s in the hands of IIS, not my issue’ :) )
(I recently was presented with a solution that ran across 20 odd servers, the answer to everything was get more hardware to make the app more performant, scalable etc – couldnt be the code.)

So as the requests start to build (don’t know an exact number but let’s say 100/sec), what is happening to your code? how often do we sit down with profiling tools on our code in this space? must be the disks..slow…and as always we have definitive proof works on my machine says the developer!

It’s not until we see our code running under load that we get an appreciation for where things could be improved and are causing grief for not only IIS but other systems as well.

Scalability, performance and scalability – single threaded app/service vs multi-threaded. Multi-threaded tend to win all the time.

Let me give you a couple of suggestions where this stuff is great:

1. As part of a WF/WCF/Class where you want to ‘push’ some processing into the background – critical things can be done upfront, and you can push some of the ‘other stuff’ into the background.
   
2. Take advantage of some of the great multi-core/multi-cpu Servers out there – single threaded tend to run on the same core on the same CPU (known as thread affinity)

Anyway enough jabbering from me and let’s see some of the hidden gems…

Async Programming Framework

Let me show you a couple of examples (from my set):

1. Fetching a webpage

Here I go off to twitter and search for all the BizTalk items.

Couple of things to notice
- …Async is added to the end of routines for convention, indicating that these are Async callable routines.
- not a single IAsyncResult to be seen, no StateObject and no Callback routines!
– line 104 the async keyword indicating that this routine itself can be called async if desired (more for the compiler)
- line 108 the await keyword is used in the Async framework to ‘wait for the async task to complete’  then move onto the next line.
- line 108 WebRequest.Create(…).GetResponseAsync – it’s the GetResponseAsync that is the async method, no …Begin or ..OnEnd calls! Just write it as you read it.
- line 109 We get a reference to the response stream (I should check for the existence of data etc – demo code, demo code :))
- line 112 …await stm.ReadAsync(…) – reads the response stream into a buffer on a background thread and we wait there until this completes (await keyword). By all means there’s many other ways to program this, as in we don’t need to wait, we could run this guy in the background quite happy and then check on him periodically.

That’s it! Not too tough at all, multi-threaded goodness right there. You can have blocking and non-blocking calls etc.

2. What about a Chunk of CPU based code

NO Async Example – as per normal, doing some cpu things.

Written in Async….

Points to notice:
- line 63 async Task<int[]> … to the Async framework the async methods are wrapped within a Task class. We must ‘wrap’ anything we return from our routines within a Task<..> – here I’m returning an int[]
-line 66 … = TaskEx.Run(…something to run in a background thread…). As we’re dealing with a block of code, there’s a Task Extension class that allows us to run that bit of code Async.
-line 79 await matrix – this line ensures that our async routine has indeed completed (or errored) before we move onto the next line.

Too easy if you’ve lived in the other world.

As always remember this is CTP so I wouldn’t go rolling out into Prod just yet. The perf numbers I get are pretty much identical to rolling all of this by hand with ThreadPool.QueueWorkItem(…) and IAsyncResult etc.

Well done MS!

Enjoy and here’s my VS.NET Sample Solutions – I had great fun! Oh – this is also applicable to Silverlight + WP7 apps :)

I just came across a great demonstration of a fantastic new piece of kit.

Siftables they're called (shot this month) that 'interact' and play with each other on a desk, table what ever.

CubeWorld guys was something I'd had my eye on for a while.....

 

Siftables takes it far beyond the next level, check it out for yourself.

http://www.ted.com/index.php/talks/david_merrill_demos_siftables_the_smart_blocks.html

Happy 2008 all!

Enter BizTalk HotRod

As we know getting things done in BizTalk requires specific knowledge around specific areas with various tweaks here and there (e.g. creating a flat file schema that removes the field names in the first line).

Some folks at Microsoft have felt the same way and decided to kick off their shoes and embrace an alternative to a mid-life crisis and the temptation of a Harley around the world. Two Microsoft TS's are embarking on the trail.

They have created a BizTalk quarterly magazine filled with some fantastic tips'n tricks (e.g. creating pipelines to handle zip compression using Office OpenXML format) - and the language and format of the magazine suits me down to a 'T'. Very funny reading.

I look down the table of contents and it's got some great tips all in the one spot -to find this stuff elsewhere is going to take alot of time assuming it exists.

Check it out and see if it's worthwhile - it's currently free (you may see yours truly post an article there one day :)

BizTalk HotRod Magazine - "Where BizTalk meets the road"

Well done guys - well done!!!

Move over Thierry Henry(shame he's gone to Barca :), Kylie and U2..... make room for .NET 3.5 up on your wall.

The folks at MS have been super busy, while talking about what will be in .NET 4+ they release the posters.

Stay tuned for more!

Grab the .NET 3.5 Common Types and Classes

The ever vibrant Andrew Coates pinged me an email yesterday asking for my involvement in becoming a TechTalk Blogger........

I'm currently on this Island called 'Hamilton' at a 'Partner' Conference (yeah right!!! :)) so naturally I said 'yes!' (not too many people are saying 'no' around here)

I've got some great stories around RFID, BizTalk R2 and obvious integration into WSS/MOSS and what that means.

Hope you're going to join me on a great journey together! Gotta dash the scuba diving boat is waiting for me... (erm...the next 'partner activity')

Mick.