Build Your AJAX Applications The Smart Client Way
I've been thinking about AJAX a lot lately. Those of you who have read my past blogs (and thanks to both of you) know that I'm a fan of Smart Client applications and have been fairly critical of the mass enthusiasm for all things AJAX. But like any good architect I have to keep my options open and so I've been thinking about AJAX a lot lately. And what I've noticed is that AJAX in fact has remarkable similarities to Smart Client development.
Before I start explaining the architectural reasons why I think AJAX and Smart Client development is so similar let me explain why I consider this to be a "good thing". The primary tenets of a Smart Client application are:
- It uses local resources and provides a rich user experience
- It exchanges data across a network, Intranet or Internet
- It can function without a connection
- It is easy to deploy
Obviously, number 3 is out for AJAX applications but the rest can be accomplished via AJAX if the application is architected correctly. They key advantage to smart client applications, in my opinion, is the use of local resources. One of the most underutilized local resources in a browser world is the CPU on the client machine. While browsing even complex sites like MSDN my CPU rarely goes beyond 15% capacity. Making that resource available to your applications for performing repetitive GUI tasks while lowering the need for more and bigger server hardware is where I think AJAX has the ability to make the most impact on application development.
Another key feature of Smart Clients not addressed in the tenets listed above is that the data sent between disparate servers and clients doesn't include UI markup which can significantly improve an applications performance. What's more AJAX can broaden the reach of your application beyond that of a Smart Client application to non-Windows environments. This is all serious goodness, if not quite the greatness of a completely disconnected application.
In this diagram I show just how similar the architectural model for an AJAX enabled browser application is to that of a standard Smart Client application. Notice only the labels on the boxes change.
If you consider each portion of the application not by technology but by its responsibilities the similarity becomes clear.
AJAX: In an AJAX enabled application much of the actual business functionality is accessed via web service calls (or static method calls which I consider a step in the wrong direction architecturally). Data is sent and received in XML or JSON format over HTTP. The HTML, CSS, images, etc. are all downloaded on demand by the browser and then stored on the client machine in the temporary internet files folder. Little of the UI processing is done at this point beyond the combination of ASPX with ASCX controls. This frees the server up to handle the more "chatty" but also more flexible interface with the client.
Smart Client: In a smart client application, the application server provides the same access to business functionality via services (ASMX or WCF). Data is sent and received as XML via SOAP. EXEs, DLLs, and other content are downloaded as needed and stored in the user's profile directories. All of the UI processing is performed on the client, once again freeing up the application server to handle service requests.
Smart Client: In a typical smart client application the execution environment is the .NET CLR with significant security sandboxing. The CLR provides the security infrastructure to protect the client machine from malicious code as well as providing the framework for logic written in .NET code to run. It also provides UI features via the System.Windows.Forms namespace to allow the logic to interact with the user. And lastly, it provides the mechanisms to communicate with the application server via XML and SOAP.
Smart Client: A smart client application has a bit more freedom about how to get objects across the wire. It can use HTTP or several other protocols, it can send and receive data in a number of formats including binary. But in most cases, for the sake of interoperability and accessibility through firewalls, it's a good idea to stick to web standard protocols of XML and HTTP just like AJAX. And also like AJAX, only the data and protocol plumbing need be sent back and forth increasing performance of the application overall. Data can be cached locally in an isolated area.
Smart Client: In a smart client application, the UI logic is programmed with any .NET language. The UI logic can render data to the client via calls into the WinForms namespaces. It can validate input from the user before making subsequent calls to the application server. It also is fundamentally responsible for the user experience of the application.
AJAX: The user interface for an AJAX application is rendered as a combination of HTML DOM objects and CSS styles. The individual browser specifies the limits of what can be accomplished graphically in the user interface but a common standard set of features has been hammered out amongst vendors.
Smart Client: The user interface for a smart client application is rendered via Win32 calls on the Windows operating system. It is limited by the features and functionality supported by the WinForms namespaces as well as those features allowed by the security context.
Up to this point I've been speaking of the capabilities of AJAX but not necessarily the implementation, or at least not what I believe is the common implementation provided by AJAX.NET. In most applications that tout themselves as being "AJAX Enabled", a significant portion of the UI logic is still taking place on the server. So why, you ask is that bad? Of course it's not "bad", it's just not the best use of a centralized (aka limited) resource that is your application server and is old fashioned Web 1.0 thinking. No server, regardless of how powerful, can come close to the rendering power of 100 client CPUs much less the thousands deployed throughout organizations all over the world. Since the CPUs are there and the capability to use them exists, doesn't it make sense to push the UI logic to those devices?
So how then do we architect an AJAX application that keeps the UI logic on the client machine? Here are a few simple rules that should help.
- HTML pages contain only static layout and file references. The caching features available for HTML pages make static pages very fast to access. Since all UI logic is being done on the client these pages could even be .HTML files instead of parsed .ASPX pages.
- Use CSS for all UI specific features. The advantages to using CSS for layout and UI features is nothing new, websites are being built every day using CSS styles instead of the more traditional tag properties.
- Resist the urge to use server side controls like the UpdatePanel that while making your development more productive, continue the Web 1.0 paradigm of building web applications by combining the UI markup with the data on the application server machines and rendering the client PCs as little more than dumb terminals.