Thursday, March 29, 2012

The Architecture of Open Source Applications

Found this cool book on the web, that explains the history behind many successful open source projects.

The chapters also contain a good amount of technical information - which was a pleasure to read :)

http://www.aosabook.org/en/index.html

Monday, March 26, 2012

Techniques for website design on all devices

Today, there is a growing demand to create websites that can render across multiple devices such as desktop browsers, tables and smart phones. New standards such as HTML5 help in this regard.

But it's important to apply proper design principles when we develop web pages that can reder across a wide array of devices. Found this cool article that describes a few techniques that can be used. The author of this blog 'Ethan Marcotte' has also written a book on this called "Responsive Web Design".

The core philosophy is how can we use CSS3/HTML5 to enable our application to detect the capabilities (size, resolution, JS support, etc.) of the browser and adapt the layout of the page accordingly. 

Friday, March 23, 2012

Lightweight UML sketching tool - UMLet

For years, I have been searching for a lightweight tool to quickly draw UML diagrams - in order to brainstorm an idea with my team. The traditional tools I have been using for UML were Rational Software Architect, IBM System Architect, Visual Studio 2010, Visio, ArgoUML, etc.

All the above tools are good, but are quite heavy to use and require installation. If you need a robust and quick UML sketching tool, then UMLet will blow your mind :)

I was particularly impressed with the simplicity of the tool. Drawing class diagrams, sequence/activity diagrams, package structures, deployment diagrams are a breeze....And it can run standalone as a JAR file or as an eclipse plugin. Loved the 'geeky' properties editor. U need to use it to appreciate it :)
It does not support code generation, as it was not the design intention of the tool.
Highly recommended for all agile architects!

Monday, March 05, 2012

How to ensure that IOCP is used for async operations in .NET?

In my last post, I had blogged about IO Completion Ports and how they work at the OS kernel level to provide for non-blocking IO.

But how can the 'average Joe' developer ensure that IOCP is being used when he uses async operations in .NET?

Well, the good news is that a developer need not worry about the complexities of IOCP as long as he is using the BeginXXX and EndXXX methods of all objects that support async operations. For e.g. SQLCommand has BeginExecuteReader/EndExecuteReader that you can use for asynchronously reading data from a database. FileStream, Socket class all have BeginXXX/EndXXX methods that use IOCP in the background. Under the bonnet,  these methods use IO completion ports which means that the thread handling the request can be returned to the threadpool while the IO operation completes. 

Some versions of Windows OS may not support IOCP on all devices, but the developer need not worry about this. Depending on the target platform, the .NET Framework will decide to use the IOCompletionPorts API or not, maximizing the performance and minimizing the resources.

An important caveat is to avoid using normal async operations for non-blocking IO - such as "ThreadPool.QueueUserWorkItem, Delegate.BeginInvoke", etc. because these do not use IOCP, but just pick up another thread from the managed thread pool. This defeats the very purpose of non-blocking IO, because then the async thread is drawn from the same process-wide CLR thread pool.

Non blocking IO in .NET (Completion Ports)

Non blocking IO is implemented in Windows by a concept called 'IO Completion Ports' (IOCP).
Using IOCP, we can build highly scalable server side applications that can perform asynchronous IO to deliver maximum throughput for large workloads.

Traditionally server side applications were written by assigning one thread to a socket connection. But this approach seriously limited the number of concurrent connections that a server can handle. By using IOCP, we can overcome the "one-thread-per-client" problem, because 'worker' threads are not blocked for IO. Rather there is a separate pool of IO threads called 'Completion Port Threads' that wait on a special kernel level object called 'Completion Port'.

A completion port is a kernel level object that you can bind with a file handle - either a file stream, database connection or a socket stream. Multiple file handles can be bound to a single completion port. The .NET CLR maintains its own completion port and can bind any file handle to it. Each completion port has a queue associate with it. Once a IO operation completes, a message (completion packet) is posted to the queue. IO threads block or 'wait' on this completion port queue, till a message is posted. The waiting IO threads (a.k.a completion port thread) pick up the messages in the queue in FIFO order. Hence any thread may handle any completion message packet. It is important to note that threads are 'woken' in a LIFO order, so chances are that caches are still warm.

The following links throw more light on this:
http://blog.stevensanderson.com/2008/04/05/improve-scalability-in-aspnet-mvc-using-asynchronous-requests/
http://www.codeproject.com/Articles/1052/Developing-a-Truly-Scalable-Winsock-Server-using-I

Why does the .NET Thread Pool have a separate worker thread pool and a Completion Port pool?
I believe that technically there is no fundamental difference in the nature of the threads associated with each pool. Worker threads are meant to do active work, where as Completion Port threads are meant to wait on completion ports. Since IO threads wait on CPs, they may block for longer periods of time. Hence the .NET framework has created separate categories for them. If there was a single pool, then there could be a situation where a high demand on worker threads exhausts all the threads available to dispatch native I/O callbacks,
potentially leading to deadlock.

Looks like in IIS 7, the threading model has undergone drastic changes. More info available here

Thursday, March 01, 2012

Why no delegates in Java? And will Closures come to Java?

Having worked across Java and .NET platforms, I often compare the features of one over the other. One of the interesting features of the .NET platform is the concept of 'delegates'.

At first, a Java guy may take some time to understand the concept of delegates, but once you are hooked on to it, you tend to use it everywhere...because it is so convienient. The .NET framework uses delegates extensively throughtout its event framework.Java folks have traditionally used the 'Listener' interface pattern for eventing. Even concurrent/parallel libraries in .NET heavily use delegates, whereas Java folks have to still stick with interfaces :(  The closest equivalent to delegates in Java is the anonymous inner class - which IMHO is messy to read and write.

StackOverFlow has a series of interesting discussion threads on this topic:
http://stackoverflow.com/questions/44912/java-delegates
http://stackoverflow.com/questions/2635013/why-not-net-style-delegates-rather-than-closures-in-java
http://stackoverflow.com/questions/1340231/is-there-an-equivilent-of-c-sharp-anonymous-delegates-in-java
http://stackoverflow.com/questions/1973579/why-doesnt-java-have-method-delegates


Another interesting feature that many dynamic languages have is 'closures'. A closure is similar to the concept of delegate, but they are not quite the same. Martin Fowler has a good bliki post explaining the concept of Closures and the difference compared to delegates.

.NET supports both closures and delegates. Found this good article explaning closures in .NET.