Introduction
There are three major forces that have been in development over the last ten years--thin client (HTML) applications hosted by a browser, distributed client-server applications, and declarative application architectures (HTML, XML, SOAP, etc). There is also a continual tug towards rich client architectures that leverage the specific and richer capabilities of the client machine and operating system. Also, declarative programming has never been well embraced except by the XUL/Mozilla community. Distributed applications, for the most part, still maintain their business logic on the client, relegating servers primarily to data management duties--databases, web services, email and messaging, and data integration and mining.
Several recent technological advances, such as the cross-platform open source Mono project, are creating an environment which allow independent software vendors (ISVs) to develop rich-thin client applications which leverage the features and capabilities of the client machine and operating system while maintaining business logic on the server. This is aided by the renewed interest in declarative programming, as witnessed by the recent introduction of XAML in Microsoft's Longhorn operating system, and continuing development in the XUL community of XAML-like parsers such as MyXaml.
Rich-Thin Clients
A rich-thin client architecture has to take advantage of the client's hardware and operating system features while at the same time relegating both business logic and data management to the server. What remains on the client application is mostly just managing the user interface--presentation, passing user actions along to the server, and responding to commands issued by the server. For performance reasons, certain business logic may be placed on the client side. There are two common approaches--browser based applications (using HTML as the declarative language) and client applets, using almost entirely imperative programming. The advantage of the browser-based thin client (runs on all platforms) and the advantage of rich-client (performance and presentation) can finally be brought together using a common framework and a declarative language that goes beyond mere presentation.
The Death Of The Browser-Based Thin Client
It is the position of this white paper that browser-based thin clients will eventually be replaced by a richer, declarative markup language that leverages a cross-platform compatible framework such as Mono. How does this differ from an HTML application running under ASP.NET with a JavaScript engine on the client? First, the application leverages the framework's presentation capabilities rather than generic HTML. This provides the user with a familiar and rich environment. Also, the programmer can create those applications faster and cheaper using rich framework controls such as trees, menus, and tabs, all of which have poor support under HTML.
Second, the burden on the programmer to be knowledgeable in the intricacies of at least three languages (server side, HTML, and JavaScript) and multiple object models, is mostly eliminated or reduced. To achieve this, a common declarative architecture is used for both client and server applications, managed by a common framework. HTML is strictly a presentation format. The more general purpose XAML parsers available today provide a format that can be used for non-presentation object graph construction as well. The developer can now use the same, consistent markup format with the same .NET framework for both client and server side development.
Imperatively Programmed Applets
The second scenario, providing a rich client experience, usually suffers from a lack of cross-platform compatibility and the burdening of the client application with business logic. Creating a cross-platform application is costly (usually separate development efforts), and unburdening the business logic from the application requires custom imperative coding to handle server side connectivity. The presentation layer and business logic that remains on the client is still imperatively coded and embedded in the client application, making it difficult to update the client with the same simplicity as a server-based web page.
One solution is to provide the client side with only a simple engine capable of parsing declarative markup for the presentation layer (similar to the JavaScript engine), client side component instantiation (which goes beyond JavaScript), and dynamic, runtime compilation of imperative code. This markup would be served to the client similar to how web pages are served to the browser, except that, in this case, the engine leverages a common framework to provide a rich client experience not limited by a specific platform and far richer than what JavaScript offers.
The advantage to the ISV should be obvious: the developer can utilize the same language on both client and server for imperative programming requirements, the same declarative language for the declarative aspects of both client and server, and the same framework to develop client and server applications. Security issues are resolved and "per use" cost models become possible through the use of encryption, digital signing, and non-anonymous connections.
Declarative Architecture
The above sections have referred to a declarative language that goes beyond what HTML has to offer, and also provides a unified solution for client and server application development. The following section explores the differences between declarative and imperative programming.
What Is Imperative Programming?
Imperative programming is what programmers do every day, whether it's in C, C++, Java, C#, VB, etc. It means writing instructions that control objects. Borrowing from the military term, it is the "Command And Control" portion of programming. Programmers write code that responds to user actions, performs decision making logic, executes processes and workflows, and changes the application state.
What Is Declarative Programming?
Declarative programming is something programmers do every day too but with less thought. It is the part of the code that defines the object graph, instantiates classes, and initializes application state. An object graph is one or more trees representing the hierarchical nature of objects, including associations between objects in the tree. Without this association, compositions of "things", like "a car has four wheels" could not be represented by a computer.
How Is Declarative Programming Used?
Declarative programming is platform neutral. A natural way of expressing declarative programming is with XML, whose structure is also platform neutral. Any website effectively uses declarative programming simply because it is written in HTML which is expressed using the XML structure. However, what HTML is lacking is two things. First, the ability to create a rich client look and feel. Second, the ability to create and manipulate complex and stateful object graphs supported by the underlying framework. HTML, even with JavaScript, is not up to this task, if for no other reason than it is pointless because of the stateless nature of web pages, relying entirely on the server to preserve session state.
Other Advantages Of Declarative Programming
Other advantages to declarative programming are:
- Separating declarative from imperative aspects of the application improves the maintainability of the application.
- Separates user interface aspects from business logic and data persistence aspects.
- Object graphs are constructed separately from the function of each object, which reduces the "work" that the application has to do.
- Interdependence between objects is significantly reduced which makes the application more resilient to change and growth.
These are motivation enough to consider separating the declarative and imperative aspects of an application into two distinct concerns.
Rich-Thin Clients
The benefits of declarative programming should be clear, but there still remains the issue of how the "rich" part of the rich-thin client is actually achieved. With the recent release of version 1.0 of Mono, "a comprehensive open source development platform based on the .NET framework that allows IT and ISV developers to build Linux and cross-platform applications with unprecedented productivity", it is possible to provide a rich user interface on non-WinTel platforms.
The second advantage that Mono provides is the unification of languages. The programmer can now utilize C# for the server-side business logic and data persistence layers, while at the same time use C# on the client side for performance gaining business logic implementation, in addition to managing the user interface state. Using another open-source project, MyXaml, provides developers the means to create applications that can run cross-platform in the .NET environment with runtime compiled C# code to handle both client and server imperative requirements.
Unified Client-Server Development
By moving away from a strictly imperative development approach on the server side, while at the same time moving away from the limited capabilities of HTML on the client side, the declarative advantage begins to take form. Both client and server can leverage the same declarative markup format, the same underlying .NET framework, and the same language for imperative programming requirements. As mentioned previously, the Mono/MyXaml combination are technologies that exist today that can achieve this result.
Distributed Server Environment
As with object graphs, the door is now open to create interconnections in complex "server graphs", in which business logic, data persistence, and other data services are distributed among multiple and redundant servers. For example, the rich-thin client might communicate to a business logic server, a web service, and a data persistence server, or the server graph might be changed so that only the business logic server communicates with the data persistence server.
Regardless of the configuration, there are several advantages to a distributed environment. First, the application is easier to maintain and upgrade. When the user connects with the application server, the server can automatically download any new presentation layer components and presentation layer logic (PLL). Also, the ISV need only update the servers to introduce new or changed business logic and data persistence schemes. Second, the system is more amenable to adding redundancy. Third, the underlying framework can have session specific data encryption and compression built into the client-server communications, alleviating many of today's security concerns. Declarative markup can also be encrypted and digitally signed, further reducing security concerns when running rich-thin clients.
Conclusion
As a result of the advances in cross-platform .NET framework support, declarative programming parsing, and runtime compilation capabilities, the days of the HTML web page are effectively numbered. An even more aggressive position is that ASP.NET will itself be eliminated, to be replaced with a unified client-server development language and declarative architecture. This is the position that this white paper takes. Although it recognizes that such changes will take a while and many of the ideas presented here need to be fully embraced by the developer community, the death of HTML and ASP.NET seems inevitable. However, given that the end user will benefit by having a rich user experience that is independent of the hardware platform, and that ISVs will benefit by reducing development cost and improving maintainability, this change seems inevitable.
References
