February 2007 - Posts

WCF Proxy Performance vs WSE V3
Saturday, February 24, 2007 8:51 PM

Recently, I had been asked to examine a situation where WSE V3 service calls were substantially quicker than the equivalent WCF version.

The reason in this instance was the fact that the WCF proxy was being created for each and every service call made (which was also the case with WSE V3).

WCF proxies are far more heavyweight and incur significant penalty if they are being created all the time. WSE V3 proxies by comparison are pretty lightweight.

So the code was changed such that one proxy was created and all requests used that already created proxy. We used a static class to wrap the creation of the proxy and access to the instance so that only 1 proxy is created. We also changed to default behaviour of the service to have an InstanceContextMode of "PerCall". This improved the resource usage and was more inline with the expected model. The services themselves require no session/state and were ideal candidates for PerCall instancing in WCF.

However, in the world of ASP.NET, we have traditionally used the practice of creating, using, then destroying (or leaving for the GC if no IDispose). In addition, its hard to get away from this model in ASP.NET unless you do something extra. For high performance ASP.NET applications with thousands of concurrent users, creating proxy classes to make service calls is very costly.

Again, in our case, we used a static class to host a single instance of the proxy. It was always open, and never closed. Coupled with the PerCall instancing model, this seened to work well.

What I am not 100% sure of is the thread safety of the proxy. If using a single static instance, what happens when multiple threads make concurrent service calls using the same proxy? The MSDN doco states the usual: "Static members are guaranteed thrad safe, instance members are not". In the initial tests, everything worked very well, but we had yet to excercise this approach under extreme load.

Should this approach fail under extreme load, I had created a "ProxyPool" implementation which simply acted as a generic object pool but with semantics specific to WCF proxies. A pool of some amount was created and on initialisation, the pool was filled with a series of proxy objects, created, opened and ready to use. A GET and RELEASE method was provided to use a proxy from the pool and return it to the pool once done. So it will be interesting to see what occurs under high load and what the best practice approach is for ASP.NET apps. Note that this approach is well suited to the PerCall instancing model, where service instances are destroyed after each call. The PerSession instancing model would require a little more smarts by the proxy pool if this was used.

Any comments or suggestions would be extremely welcome.

ASP.NET Podcast/VideoCast - Show #86. Creating Extender controls with the AJAX Control Toolkit (Videocast)
Friday, February 16, 2007 5:22 PM

This videocast is a follow on from a previous Videocast I did when I showed how to create extender controls using just the ASP.NET AJAX Extensions. This video contrasts the different development approaches and shows how much easier it is to create the same AJAX Extender controls using the AJAX Control toolkit.


Original URL: http://aspnetpodcast.com/CS11/blogs/asp.net_podcast/archive/2007/02/15/asp-net-podcast-show-86-creating-extender-controls-with-the-ajax-control-toolkit-by-paul-glavich-video.aspx

Download WMV.

Download MP4.

Download support files.

Show Notes:

WCF Masterclass with Juval Lowy
Wednesday, February 7, 2007 11:39 PM

I have been lucky enough to be attending a WCF Masterclass this week taught by Juval Lowy and organised by readify. Its an awesome course and I am learning an incredible amount about WCF (Windows Communication Foundation). You know you’re on a good course when not only do you learn a lot about the specific topic of the course, but I am also picking up an incredible amount of useful tips and code along the way, not strictly tied to WCF.

For example, I never knew that Juval created and delivered a set of transactional objects for use as a Volatile Resource Manager. By this I mean, that an integer is transactional, a DictionaryList is transactional, a string is transactional, a List, queue and Array are transactional, and these objects can participate in full fledged transactions, whether using the Lightweight transaction manager, Kernel Transaction Manager, Distributed Transaction Co-ordinator or other derivative.

For example:

TransactionalArray<int> numbers = new TransactionalArray<int>(3);

numbers[0] = 1;

numbers[1] = 2;

numbers[2] = 3;


using (TransactionScope scope = new TransactionScope() )


  numbers[0] = 99;

  numbers[1] =88;

  numbers[2] =77;



// numbers[2] == 3 at this point as we did not Complete/Commit the transaction before it exited the scope.


TransactionalArray<int> numbers = new TransactionalArray<int>(3);

numbers[0] = 0;

numbers[1] = 0;

numbers[2] = 0;


using (TransactionScope scope = new TransactionScope() )


  numbers[0] = 99;

  numbers[1] =88;

  numbers[2] =77;




// numbers[2] == 77 at this point as we DID Complete/Commit the transaction before it exited the scope.

Apparently Juval released this stuff way back in late 2005 (and is on MSDN somewhere). I just had no idea, and its a super cool implementation of transacted objected. Again, these guys fully participate in all manner of promotable transactions. Juval has included transactable generic versions of all the collections. You can grab it from this page, Just look for Volatile Resource Managers.

A user experience only a mother could love
Tuesday, February 6, 2007 11:59 PM

So I downloaded Windows Mobile Device Centre, installed it, run it. Plugged in my Windows Mobile 5 device and received the "uber" useful screen you see below. Now which option shall I choose from here.....? I wonder how long it took to design this screen? Well at least its a green screen so it can't be all bad right?

ASP.NET Podcast Show #85 - Chris Riccio of the ASP.NET AJAX Team
Tuesday, February 6, 2007 5:24 PM

Wally does another podcast interview with Chris Riccio of the ASP.NET AJAX team. This one mostly deals with testing.

Full Post

Direct Download


Show Notes:

[tags: .Net, ASP.NET, Podcast, AJAX, Atlas, ASP.NET AJAX, Web 2.0]

MVC/MVP - Overused Patterns?
Sunday, February 4, 2007 10:57 PM

I did an engagement recently where a client wanted to create a windows forms application from an existing legacy application. The existing legacy app was important but relatively simple in terms of architecture.

A previous consultant went in and recommended the use of the Model View Controller (MVC) pattern, with the possible use of the CAB (Composite UI Application block).

While the MVC can be a good choice as far as a general pattern goes, and the CAB a reasonable application block, in this scenario I thought it was quite a bad decision. The team responsible for development had no real idea how to implement MVC properly, had never done anything remotely like the CAB before. Patterns such as Inversion of Control / Dependency Injection were very new and complex to them. The recommendation was simply a formulaic response to a problem that did not suit the context.

In reality, the team could not have delivered the application in their required timeframe, with their current skillset.

What’s the moral of this post? Well, more as a warning. Standard patterns and accepted trains of thought are good in general, but don’t recommend or use architectures just because everyone else is, or they are the current implementation flavour of the month. As an architect, assess not just the technical details, and possible ways of designing the solution, but also how that fits in with current social issues such as team skillsets, experience, likelihood of success and current needs. In this example, the legacy applications architecture was very simple. The architecture I ended up proposing was in itself quite simple (in fact overly simple), but achieved the goals of modularity, loose coupling, expandability and ability of the existing team to deliver it. It also allowed further complexity and patterns to be introduced where necessary and as required, but it certainly wasn’t required from the outset. Small Steps.

Its easy to make a simple thing complex, but its a much much harder task to make a very complex thing simple.



More Posts

This Blog