Composite Gravitation

What do the users really want?

In application development, responsible developers realize that they are, in fact, developing for users, and we (yes, sometimes I too am responsible) ask regularly ourselves what users really want and need. In our hearts, we really do want to get it right; we want to deliver "added value"; it gives us great pleasure when we can show some users some new feature and with growing eyes and smiles an, "Oh, cool!" is uttered appreciatively. With that said, all too often we, as developers, are given (sometimes tacitly) the task to sift through the requirements docs, the discussions, the diagrams, the charts and all the other mediums through which our users are asking for something, and get down to the heart of what they want. However, sometimes even we cannot "see the pattern". Composite gravitation is a name I've given to one such pattern.

Composite gravitation can be manifest in many ways, but is most apparent when users start to grumble about having too many different applications to use in order to complete their tasks. I can sympathize with their angst; I certainly wouldn't want to be required to leave my IDE regularly in order to complete this task or that. On top of it all, who wants to learn and use a multitude of applications, each with its own look and feel? The desires of the users begin to gravitate toward some sort of consolidation and optimization, even though they may not understand what that means or voice it accurately. In any case, it's not long before you start hearing terms like "integrated desktop", "dashboard", "container application" and "portal".

In most cases, this situation results from introducing applications separately and disparately, generally with very narrow use-cases and without attention to the look and feel of previously introduced apps. It's a natural enough progression that could occur for various reasons; for example, they could have been developed at different times, or with different technologies, or perhaps they seem functionally unrelated, 3rd-party apps could be thrown into the mix, or a combination of these.

The grumbling of users is not the only symptom of composite gravitation. It can be seen when companies begin to require all internal applications to be web applications stating many justifications, and I use that term loosely, including that it consolidates the number of applications down to each user's browser. It can also be observed when IT and development shops begin to realize the maintenance nightmare that's been created by the existence of a myriad of disparate applications, each with separate yet remarkably similar code-bases, with run-time counterparts that soak up desktop and server resources utilizing no algorithm for sharing with sibling apps. In any case, the reasons are swelling, not dwindling, and something must be done.

Enter the Composite Application

A composite application is exactly what its name entails, an application composed of applications. You see composite applications in many forms, but generally each has a single extensible shell built using a modular and pluggable architecture. When new business use-cases arise, new modules can be built and plugged into the existing application in a seamless manner. Each module is built so as to maximize maintainability and efficiency, typically through code reuse, extensible menu structures and toolbars, connection management, authentication services or other resources.

If done correctly, composite applications greatly benefit both worlds, users and IT/Development. The users get their applications in a consolidated and cohesive package with intuitive look and feel, while the common shell and extensible, pluggable architecture eases the maintenance headaches generally involved with disparate applications.

For more information on composite applications, Atanu Banerjee of Microsoft Corporation has a great MSDN article entitled What Are Composite Applications?, and for you Windows hackers, let me also direct you to the Smart Client - Composite UI Application Block, a framework for building composite applications in .NET, graciously provided by the Microsoft Patterns and Practices group.

Web Applications are Overrated

For years we've been told that web apps are the way of the future. But are they really? The answer is "probably not". Think about where web applications are going. You don't know where they're going? We'll let's think about where they've been.

The Stateless Abyss
For almost 20 years now, web applications have lived in the stateless depths of the World Wide Web, thanks to that wonderful little protocol, HTTP. HTTP's request/response nature allowed for simple and straight-forward communication back in the day, when all we really wanted was to ask another machine on the web for a resource.

The Dynamic Shift
As the Web grew in popularity, we started placing more and more demands on the resources for which we asked. We started making the dog do tricks. We wanted more "interactivity"; static text and images were no longer enough; we now needed the ability to customize the resource and create "dynamic content" with each request. We wanted to conduct business and stream media all over a stateless channel, where each transaction had no knowledge of previous ones.

The Stateful Revolution
Soon, having the dog roll over or shake hands was not enough as well. The time came for stateful transactions. We now want to keep track of whom is logged in, what he/she has done and where he/she has been. We want state. Only now, we're making the dog walk a tight-rope and juggle chainsaws. We've begun to do things like stuff variable values in responses and re-collect them on the next request or write database records to keep track of transaction state on the web server; all to mimic stateful transactions. Dozens of web frameworks have surfaced, many having a mechanism built-in to get around the stateless nature of HTTP. We now have technologies that effectively mix web and desktop technologies, something I like to call "webtop clients", manifest in Adobe Flash Player, Java Applets, and Microsoft Silverlight.

The Pattern
Do you see the pattern? Since the inception of the Web, web applications have evolved significantly; from static content to dynamic content, from statelessness to statefulness, from browser-only technology to browser-desktop mixture technologies. However, their evolution is not toward something new and unseen, but to something all too familiar, the thick client.

With today's frameworks for desktop application development and deployment, the justification for many of today's web applications, especially web apps internal to a company, are no longer legit. Take a look at Apple's iTunes; everything Apple flows through that application. As for deployment, Microsoft's ClickOnce for .NET Windows applications and Sparkle for Cocoa applications make deployment and updates so easy, it's ridiculous. Don't get me wrong, web applications do have their place, but the number of scenarios for which they are the optimal choice is dwindling; sure they can be used for nearly everything, but what's the point? It all comes down to the following question: in a particular situation, what problem does a web application solve that a desktop application does not? When you realize how many times you can't find any, you'll realize that web applications are overrated.