Choosing the Right Presentation Layer Architecture
Summary: The presentation layer is a vitally important part of an application. This article discusses the thin and smart client approaches and provides guidance on how to choose between them. (16 printed pages)
The Importance of the Presentation Layer
What Is a Thin Client?
What Is a Smart Client?
Choosing the Right Interaction Layer Architecture
Deployment and Update
About the Author
The presentation layer is a vitally important part of an application—an inappropriately architected presentation layer can lead to too much complexity, a lack of flexibility and an inefficient and frustrating user experience. Thin client applications have well known benefits over traditional rich client applications in terms of deployment and manageability and this has led to their popularity in recent years. However, with the advent of smart clients, the choice of presentation layer architecture is no longer straightforward. Rich clients have evolved into smart clients that can combine the central management advantages of thin clients with the flexibility, responsiveness, and performance of rich clients. This article discusses the thin and smart client approaches and provides guidance on how to choose between them.
The Importance of the Presentation Layer
The presentation layer of most applications is very often critical to the application's success. After all, the presentation layer represents the interface between the user and the rest of the application. It's where the rubber hits the road, so to speak. If the user can't interact with the application in a way that lets them perform their work in an efficient and effective manner, then the overall success of the application will be severely impaired.
Personally, I think the term presentation layer really does not do justice to the function and importance of this layer. It is rarely about just presenting information to user—it's often more about providing the user with interactive access to the application. Perhaps a more appropriate name for this layer is the user interaction layer. For simplicity, though, for this article I'll stick with the commonly accepted name for this layer.
In any case, you'll want to design this layer to provide the user with the right user experience, so that they can interact with the application in an effective and efficient way. Of course you also need to architect and then implement this layer in such a way that it adequately takes into account the development, maintenance, and operational needs of the business. Choosing the right architecture for the presentation layer of the application is vitally important in order to achieve all of these goals.
The two commonly adopted approaches to presentation layer architecture and design are the thin client approach and the smart client approach. Of course, many factors influence the decision about which approach is best for a particular application—for example, client platform requirements, application deployment and update, user experience, performance, clientside integration, offline capabilities, etc.—and each has inherent strengths and weaknesses and naturally supports a certain style of application. You'll find, however, that the distinction between them can blur, and this can easily lead to the wrong basic approach being applied leading to problems later on.
For example, it is possible to provide a rich user interface with a browser based presentation layer, just as it is possible to provide a completely dynamic user interface with a smart client. Neither would be very easy to achieve, and both would very likely result in unneeded complexity, a lack of flexibility and high development and maintenance costs.
Many organizations choose a thin-client architecture by default without duly considering the alternatives. While they will not be appropriate for all scenarios, a smart client architecture can offer significant advantages over a thin client approach without incurring the downsides traditionally associated with rich clients. Organizations should carefully consider each approach so that they adopt the right approach from the outset, minimizing the TCO over the lifetime of the application.
In the following sections, I'll examine the thin and smart client approaches and some of the technologies behind them. For each I'll describe the basic architecture and discuss some of the design options within each. After that I'll talk about the relative strengths and weaknesses of each approach in terms of a number of common factors and requirements that you should take into account when determining the most appropriate approach for your application.
What Is a Thin Client?
Many thin client technologies pertain to the server side and there are many Web server platforms and frameworks (ASP, ASP.NET, JSP, and others) to choose from. Each has particular features that try to make it easier to write thin client applications, but they all deliver the user interface to a browser on the client through a series of HTML pages. A thin client application is pretty easily defined as one that uses a browser to provide the execution environment for the application's (HTML defined) user interface.
In addition to rendering the user interface and allowing the user to interact with it, the browser also provides generic security, state management, and data handling facilities plus the execution environment for any client-side logic. For the latter, the browser typically provides a script engine and the ability to host other executable components; such as Java Applets, ActiveX and .NET controls, and so on, (though most definitions would not consider these executable components to be thin client technologies—see hybrid applications below).
An application architected to use a thin client presentation layer is decomposed into pages and each page is "deployed" to the client upon request. Each page contains the user interface description and, typically, a small amount of clientside script logic and a small amount of state/data (view-state, cookies, XML data islands, etc.). Figure 1 shows a schematic representation of a thin client presentation layer architecture.
The browser has a limited ability to interact with the client environment (hardware and other software applications running on the client). It does provide a mechanism that permits storage of small amounts of data on the client (via cookies), and sometimes the ability to cache pages, but typically these facilities are of limited use except as a way to provide simple session management or tracking, and rudimentary read-only offline capabilities, respectively.
The browser also provides the security infrastructure so that different applications (pages) can have more or fewer permissions assigned so that they can do different things around state (such as cookies), they can host components, and execute scripts. Internet Explorer implements these facilities through different zones, trusted sites, ratings, etc.
In an attempt to provide a richer and more responsive user interface, some Web applications have resorted to DHTML and similar technologies to facilitate a richer user interface. While these technologies are non-standard, in the sense that all browsers do not support them in the same way, they do provide the ability to include more advanced user interface elements such as drop down menus, drag and drop, and more with in a Web page.
Figure 1: Schematic Overview of Thin Client Architecture
Other Web applications have resorted to hosting complex components within the page including Java Applets, ActiveX and .NET components. These components provide either a more responsive user interface or client-side logic that cannot be implemented in script for performance or security reasons. This is where the thin client starts to overlap with smart client leading to so-called hybrid applications.
While you can certainly use such hybrid applications to leverage the strengths and weaknesses of each approach, in this document, I'll define the term thin client to mean a generic Web application that does not rely on such components but just utilizes the basic facilities provided by the browser environment. Since hybrid applications need to rely on smart client capabilities to avoid management and operational problems, I'll describe hybrid applications in a later section when I discuss smart client applications.
What Is a Smart Client?
Smart client applications are maybe not as easy to define as thin client applications because they can talk many different forms and are not limited to the one-size-fits-all approach of thin client applications. The essential difference between a smart client and a thin client is that a smart client does not rely on a browser to provide the execution, security and user interface environment for its operation. Also, smart clients, rather than HTML and Jscript, typically involve compiled code artifacts (components, assemblies, etc.) running on the client machine to provide the application's user interface and clientside logic.
How do smart clients relate to rich clients? Rich client applications have evolved into smart client applications. Rich clients offered many advantages over thin client applications including improved performance, responsiveness and flexibility, and the ability to work offline, but rich clients suffered from a number of operational problems when it came to deploying and updating them in a robust way. Thin client solutions of course excel in the deployment and update area and this is one of the main reasons for their popularity.
However, smart client applications represent a best-of-both-worlds approach by taking the manageability advantages of thin client applications and combining them with the benefits of rich client applications. Smart clients are rich clients done right, leveraging new technology and techniques to avoid the pitfalls of the traditional rich client applications.
For example, smart client applications built on the .NET platform can take advantage of a number of fundamental technologies that the .NET Framework provides to solve many of the problems traditionally associated with rich client applications. While it has always been possible to build rich client applications that minimized or avoided the deployment and security drawbacks, the facilities provided by the .NET Framework make it very much easier to do.
.NET provides the ability to deploy an application, or part of an application, from a Web server. This technology, known as No-Touch Deployment, lets you deploy applications via a URL. This allows you to release applications to a central location (i.e. to a Web server) so that the applications can be deployed automatically to the client on demand. All clients can be automatically kept up to date since the application checks for updates automatically each time the application runs and each client application downloads the new code if required.
Figure 2: Schematic Overview of a Smart Client Architecture
.NET also provides the Code Access Security (CAS) infrastructure. CAS assigns .NET code-specific permissions according to the evidence that it presents. CAS serves much the same function as the browser does in a thin client application, providing a sandbox environment in which the application operates. No-Touch Deployment integrates with (CAS). By default, applications that are deployed using No-Touch Deployment will be granted a restricted set of permissions according to the URL zone from which they were deployed. Network administrators can modify permissions using security policy so that the application can be granted, or denied, specific permissions according to the requirements.
Creating a smart client application with the .NET Framework provides less fragile applications. Traditionally, installing a rich client application could break other applications as it replaced important components and DLLs that were shared by other applications. .NET allows applications to be isolated, keeping all application artifacts in a local directory so that all assemblies are kept separate. Furthermore, such applications do not require any registration process when they are deployed, further reducing the risk of breaking other applications. In addition, the .NET Framework allows multiple versions of an assembly to be deployed side by side. This ensures that when an application executes, it runs with the exact versions of the assemblies that it was built and tested with.
An application architected to use a smart client for its presentation layer will typically provide a central deployment server, from which the smart client artifacts can be deployed to the clients, and a number of Web services to provide access to the backend business capabilities—business logic and data—and which are consumed by the smart client. Since the smart client is running code on the client, it can more cleanly separate the user interface from the client-side data and logic. In addition, depending on the permissions it has been granted, it can more freely interact with other client-side resources such as local hardware and other software running on the client. Figure 2 shows a schematic overview of this architecture.
What does a smart client look like? Smart client applications can take many forms and the architect of such an application faces a number of design choices. The first decision to be made is to choose the most appropriate application style—the way in which the smart client is presented to the user. In general, there are three ways to design a smart client application:
- Windows Applications. Traditional Windows style applications, typically built using Windows Forms or mobile applications built on the .NET Compact Framework.
- Office Applications. Microsoft Office programs that are extended to include smart client capabilities, connecting the user to line of business applications and business processes. Hybrid Applications. Applications that utilize a combination of thin and smart client technologies. For example, by hosting Windows Forms controls within a browser page or by hosting the browser within a Windows Forms application.
Choosing the right application style is crucial if you want to fully realize the benefits of a smart client approach. Deployment, security, development, and offline capabilities all affect the choice of smart client application style but perhaps the biggest factor to consider is the overall user experience. Each choice represents a different type of user experience and choosing the right one will give the user the right combination of flexibility and performance they need.
Users associate smart client applications with traditional Windows-style applications because they provide rich client functionality that includes toolbars, menubars, context menus, drag and drop support, context sensitive help, undo/redo, and more. Developers can build these kinds of smart client applications on the .NET Framework or the .NET Compact Framework using Windows Forms to provide these rich user interface features.
These developers can also take advantage of pre-built smart client functionality by leveraging the Application Blocks provided by the Microsoft Patterns and Practices group. These blocks provide the application with common smart client capabilities such as local data caching, seamless deployment and the ability to work offline.
Windows Forms applications provide the most control over the user experience, allowing the developer to craft the user interface and user interaction model to suit their exact needs. For applications which require a specific user experience which cannot naturally be provided by any of the Office applications, this approach will be the best fit.
Office 2003 Smart Client Applications
Microsoft Office programs provide an extremely compelling platform for building smart client solutions. Extending Office applications so that they form part of a distributed solution, connecting them to remote data sources and business services, not only benefits the users, it also brings efficiencies to the developers that write the applications, and to those that must deploy and manage them.
There are many users who are familiar with Office and use it everyday in their work. Extending Office applications by connecting them to remote data sources and business services means that the solution can benefit from the user's familiarity, obviating or drastically reducing the need to re-train the user. The user benefits too, since they can continue to use the application with which they are familiar.
Many organizations extensively use Microsoft Office. Most business PCs—yours, your customers, your service providers, and your suppliers—have Office applications installed. Using Office as the client for line of business systems can reduce the need to install and maintain incremental client applications to access backend data sources and services. And very often, data from line of business applications is copied into Office applications such as Word or Excel for further manipulation, editing, analysis, and presentation. Copying and pasting is time consuming and introduces the potential for errors. More importantly, the link to the data is lost so the user needs constant refreshes, repeating the copy and paste process, and possibly introducing concurrency problems.
Office applications can also provide a lot of the functionality that is required to display and manipulate data, allowing the user to interact with the solution using the full power of Office. This can save a huge amount of time and effort allowing you to develop and release a solution must faster. For example, Excel provides powerful capabilities to sort, manipulate, and display data. Reusing these capabilities in your smart client solution can be very cost effective.
Of course, users have the ability to integrate additional functionality into their Office applications for a while. In some cases this has led to ad-hoc but business-critical solutions that are difficult to manage because they aren't developed or maintained by the IT department. Building these solutions using smart client technologies allows them to be more easily deployed and updated and represents a way to retain the value of the solutions whilst solving some of the manageability issues. Office 2003 provides support for integrating smart client capabilities into Office application and connecting them to remote services that provide access to data and business processes. Some of the more important technologies Office 2003 supports for creating smart client solutions include:
- XML Support. Office 2003 provides a number of facilities that allow developers to more easily connect Office applications to remote data sources and business process through XML.
- Word, Excel and InfoPath can use XML to store the structure and contents of a document in human or machine-readable XML form. Microsoft has released W3Ccompliant XSD schemas for these file formats and these schemas are freely available for everyone to use in their own solutions. These schemas allow Word and Excel documents and InfoPath forms to be easily constructed on the server and provided to the client through XML Web services and users can readily display and edit these documents. This technology can also be used to provide document composition, indexing or searching functionality. And of course, since these documents are XML, they can be exchanged with any other system or process, providing a means for data interchange across heterogeneous systems. This technology is ideally suited to document-centric solutions.
- Word, Excel, and InfoPath can also consume XML messages or documents that conform to custom or user-defined schema. Users can use their Office applications as presentation layer services in datacentric solutions where the business processes or services already define the message schema. This type of smart client application maps elements and attributes in the message to specific areas of the document so that the Office application can display them appropriately and allow the user to edit the values whilst ensuring that the data entered by the user conforms to the underlying schema. Specific values can be queried, set, or referenced programmatically using an XPath query statement. "Extending Office applications so that they form part of a distributed solution, connecting them to remote data sources and business services, not only benefits the users, it also brings efficiencies to the developers that write the applications, and to those that must deploy and manage them." JOURNAL4 | Choosing the Right Presentation Layer Architecture 9
- Smart Documents. Smart document solutions help the user to interact with a document by providing additional data and guidance to the user according to their current location within the document. As the user interacts with the document, it can display relevant information or guidance to the user using the task pane, or it can automatically fill in missing data according to the current task. Connecting this experience to remote services to obtain live data or to enable interaction with business processes allows powerful and integrated applications to be built.
- Information Bridge Framework (IBF). IBF is a declarative solution that builds on smart document technology to allow documents to be connected to services through metadata. Smart tags within an Office application interact with the generic IBF infrastructure and the metadata associated with the available Web services to provide access to relevant data and business processes from within the document according to the documents contents and the user's current activity. For example, if a user receives a document that refers to a specific supplier, the IBF infrastructure can access data about that company and display it in the task pane. It can also provide access to available options, allowing the document to be connected to other business processes.
- Visual Studio Tools for Office (VSTO). VSTO provides access to the object models for Word and Excel to managed code extensions. Developers can build complex and comprehensive Office smart client solutions using VSTO to not only provide access to the full power of Word and Excel but also to all of the features of the .NET Framework, such as Windows Forms, that enable rich and responsive user interfaces to be easily integrated. VSTO also provides a superior development experience, allowing the developer to easily create and debug a solution. VSTO essentially provides the code behind the document to form a solution that leverages the facilities provided by the "host" application.
Hybrid smart client applications combine the smart client and thin client approaches. They can provide a way to extend an existing thin client application with smart client capabilities, or a way to integrate a browser-based application into a smart client application.
For example, a smart client application may host an instance of a browser so that certain content and application functionality can be provided using the thin client approach. This architecture can be very useful when the application needs to integrate an existing thin client application, or when it needs to leverage a key benefit of the thin client approach to provide linked dynamic content provided by a Web server. Of course, such content and functionality will only be available when the user is online but the smart client part of the application can be used to provide useful functionality when offline and enhance the application with access to the thin client functionality when online.
In some cases, the hybrid approach can be used to extend an existing thin client application by hosting smart client controls or components within a Web page. These components can provide a rich and responsive user interface and specific application functionality (for example, rendering and visualizing data) while the rest of the application is delivered in a thin client way. However, this architecture is not suitable for providing offline support since the hosting Web page will not be available without a connection, or for providing client-side integration of software or hardware unless suitable security policy changes are in place.
Choosing the Right Interaction Layer Architecture
Both the thin client and the smart client approaches clearly have their place. Each has its own strengths and weaknesses and the choice between them will depend on the requirements of a specific application or business need. The correct approach will provide the user with the right user experience so that they can interact with the application in an effective and efficient way, whilst adequately taking into account the development, maintenance, and operational aspects of the application.
Some organizations have a policy that dictates a thin client approach for all applications. Choosing a thin client approach by default can lead to significant technical problems for some applications because the browser platform is not able to easily support the requirements of moderately complex applications. Developing a thin client application to have the look, feel, and capabilities of a traditional rich client application can be extremely challenging and costly. Why? The browser imposes severe limitations on the developer in terms of state management, client-side logic, clientside data, and the provision of rich user interface features such as drag and drop, undo/redo, etc. Conversely, choosing a smart client approach for all applications is not appropriate since it can result in overly complex solutions for applications that just present data dynamically and require the benefits of a highly dynamic user interface. Also, if your application must support multiple client operating systems, a smart client approach may not be appropriate due to cross-platform restrictions.
Adopting a single approach for all applications is therefore likely to result in unnecessary cost, complexity, a lack of flexibility and reduced usability. Both approaches can likely co-exist within the enterprise, according to the requirements of specific applications and the needs of the business. Choosing one approach over the other should be decided on a per-application basis, although in some cases both approaches can be combined, either by integrating thin and smart client technologies appropriately or by adopting a dual channel approach where some class of users can access the application using a thin client while users with more stringent requirements use a smart client. Either way, the key is to leverage the appropriate technology at the appropriate time to fulfill the expectations of the users and the overall needs of the business.
The thin client approach has well-known benefits in terms of reach and ease of deployment and operation. However, with the advent of smart client technology, smart clients are catching up in this area and are now a viable alternative to thin clients for many scenarios. In particular, smart clients do not suffer from the deployment and management problems that rich client solutions suffered from, and smart client solutions add benefits in terms of flexibility, responsiveness, and performance.
So, if deployment and manageability are no longer the dominant factors that influence the decision between the two approaches, how does one choose between them? With the erosion of the relative benefits of the thin client approach in this area, the balance is changing and the factors which have to be considered have increased. Depending on the relative priority of the requirements, one approach will be more suitable than the other, and choosing the correct approach will result in a faster and less complex development process, improved ease of use, and higher user satisfaction.
The features, advantages and disadvantages of each approach are described above but how do these translate into a decision given the requirements of a specific application? Some of the more important factors that companies must consider include:
- Client platform requirements
- Deployment and update requirements
- User experience requirements
- Performance requirements
- Client-side integration requirements
- Offline requirements
This is not a comprehensive list of factors and your company's IT department may add other factors that are critically important to specific applications. In particular, this list of factors is focused on operational or functional requirements and development and design-time factors have not been included here. Still, these factors may be of sufficient importance to sway the balance between one approach and the other. Deciding on the right approach is a joint decision between the IT staff and business owners. The adopted approach should lead to a solution where both groups are happy: the IT from the management side, and the business owners from the functionality side.
Client platform flexibility can be important for a customer or partner facing applications where the principal users are external to the organization and for which a specific client platform cannot be mandated, or for applications that have to be accessible from non-Windows operating systems.
Thin clients offer the ability to target multiple client platforms, though this often requires the application to determine the exact type of target platform so that it can change its operation or behavior to accommodate the differences between the various browsers, especially when the target platform must include mobile devices. The thin client framework itself can handle many of these differences. For example, ASP.NET on the server can determine the target browser type and render content for each browser accordingly. Using some of the more advanced browser features, however, will likely result in having to develop specific code to handle the differences between browser types.
The smart client approach does not offer this capability although applications that target only Windows operating systems can use the .NET Framework and/or the .NET Compact Framework (for mobile applications) to deliver a smart client solution on a wide range of client devices, even for external users.
If your application must support external users or clients running non-Windows operating systems, then the thin client approach should be strongly considered.
Deployment and Update
Both the thin and smart client approaches involve deploying the user interface, application logic, and data to the client. In both cases, these artifacts are centrally located and managed and deployed to the client on demand. In the thin client approach, these artifacts are not persistent on the client and need to be "deployed" each time the user runs the application. In the smart client approach, the client can persist these artifacts to enable offline usage or to optimize the deployment and update process.
Since both approaches allow the company to centrally locate the application's artifacts, they both provide centralized management with respect to user authorization, application deployment, update, etc. Companies can use thin client and smart client to provide solutions to ensure that users only run the absolute latest version of the application, though the smart client allows for additional flexibility, such as the ability for different users to run different versions of the application (for example, pilot groups), or for the application to be run offline. In order to realize these benefits, however, the solution may require additional security policy changes and/or an update manager component to be deployed to the client.
If your scenario requires that the application runs offline then you should strongly consider the smart client approach. On the other hand, if the application would not benefit from having artifacts be persisted on the client, then the thin client approach may make more sense. In the latter case, applications that primarily present dynamic data, or where concurrency problems (with respect to application logic or data) would be severe, tend to be better served using a thin client.
Thin and smart client applications are each suited to specific user interface styles. Many thin client applications try to provide a rich user experience but they tend to fall short in certain important aspects due to the limitations of the browser when compared to a smart client platform. For instance, basic rich client features such as drag/drop and undo/redo are very difficult to develop in a thin client solution. The complexity associated with providing these features can be considerable and can reduce the cross-platform benefits of the thin client approach.
You should also consider how the user interacts with the application. Some applications are very linear because the user typically interacts with it in a pre-defined or similar way. Other applications are non-linear and the user may start one task only to suspend it, complete another task, and then go back to the original task. Managing the state required to provide such functionality can be challenging in a thin client solution. For example, thin client solutions have to be designed to handle the situation if the user presses the back button in the middle of an important transaction. Such a situation is easier to handle in a smart client application.
Smart clients can also take advantage of local resources to provide local data searching, sorting, visualization, and client-side validation to improve the usability of an application and enhance the user experience. Such features can lead to an increase in data quality and user satisfaction and productivity.
A significant difference between the two approaches is that smart client applications provide superior performance compared to their thin client counterparts.
At a basic level, a thin client typically uses script (which it must interpret on the fly) as the means to deliver and execute client-side application logic. In contrast, a smart client solution can deliver specific compiled code to the client. Additionally, and perhaps more importantly, client-side logic in a smart client application has fewer restricts in the way that it can interact with the user interface, local data storage, or with services located on the network. For these reasons, good smart client architecture allows the solution developer to more easily deliver a high performance solution.
The user's perception of performance depends on how they use the application and how they expect it to behave. Applications that are used infrequently or with which the user does not interact very much, for example, applications that simply obtain and display data, will not benefit from raw higher client-side performance. Applications that are heavily used, however, will appear to perform poorly if there is even a small delay for frequently used features. In a call center application, for example, a delay of four or five seconds to retrieve customer order details can easily add up to significant user dissatisfaction (and cost).
Of course, for functionality that sends or retrieves data over the network, both approaches will exhibit the same raw performance. However, a well-designed smart client solution can perform its network communication on a separate thread enabling the application to remain responsive while it sends and received data over the network. Such background work can be accomplished pro-actively, say in response to an incoming customer call. In addition, it is easier for smart client solutions to cache data locally, which can reduce the number of network calls or reduce the bandwidth required to perform the same function. These features can have a huge impact on the user's perceived performance of an application.
Smart client solutions can provide more rigorous client-side data validation. For example, because a smart client solution can cache data and logic locally, it is possible to cache read-only reference data that the application can use to provide field and cross-field validation. Applications that use such validation can provide early feedback to the user, improving the perceived performance of the application, reduce the number of times data gets transferred over the network, and ensure higher data quality. Thin client solutions may need to rely on complex scripts to provide the same level of functionality and may not be able to locally validate data with respect to other data that is not displayed on the current page.
A smart client solution can also take maximum advantage of the local processing, storage, and display capabilities to allow the user to query, sort, and visualize data on the client without the need to make a network call. This ability is especially evident when using an Office application such as Excel as the smart client host environment. This can result in a significant reduction in network calls to perform the same function for a thin client application.
Since the smart client solution user interface is typically provided by specific code running on the client, it can provide a more responsive user interface to the user. Rich client user interface features, such as drag and drop, undo/redo, context sensitive help, keyboard shortcuts, etc., can all help to improve the user experience, and with it the perceived performance of the application.
If performance is an important issue you should consider a smart client solution. A user's perceived performance of an application is often more important that the actual performance of individual operations. A good application's ultimate goal is to ensure that the user can perform their work effectively and efficiently in a way that user satisfaction is maintained.
Often an application requires access to client-side resources so that they can be integrated into the overall solution. Sometimes the client-side resources include hardware (a printer, telephone, barcode reader, etc.) or software (integration of other line-of-business or desktop applications).
Of course, both the thin client and smart client approaches operate within a sandbox. In the thin client case, the browser provides the sandbox; for a smart client, the .NET Framework runtime provides the sandbox. Integrating client-side resources into a thin client application typically requires using a hybrid application architecture to host a component within a page (for example an ActiveX control) to extend beyond the browser sandbox. This approach is not very flexible and often depends on the user to make security decisions about downloading components to run on the client under the user's login account.
The .NET Framework runtime utilizes a more flexible approach and grants managed code permissions based upon the evidence that it presents and the local security policy. By default, code downloaded from a Web server cannot interact with the local resources except in very limited and specific ways. However, your application logic can grant the code additional permissions to access to specific resources such as specific directories on the disk, access to other applications, local databases, etc.
This managed approach represents a more granular and more flexible mechanism for controlling the security aspects of an application, allowing the smart client to integrate other clientside resources without introducing a security risk. More importantly, the network administrator uses security policies to make security decisions rather than individual users, so the application code cannot perform actions or access resources for which it has not been granted permission.
Smart client applications often use code access security to control the caching of data and logic on the client. Such behavior is essential to providing offline capabilities and so these kinds of applications typically require security policy changes to grant specific permissions. Typically, this involves granting the application permission to cache the code and data on the local disk. If the solution requires access to clientside resources such as local hardware or other applications installed locally, then the smart client approach provides a secure and flexible solution.
As organizations become increasingly dependent on their IT systems and the data and services that they provide, it becomes more important for users to be able to work offline. Providing support for offline access to data and services, using the same application whether they are on or offline, enables the user to remain productive at all times and helps to ensure consistency and data quality.
While network connectivity is becoming more and more ubiquitous, it is important to note that having a network connection is typically not enough to guarantee access to an application and the data and services that it represents. Line of business applications inside the firewall may not be accessible to users when they are out of the office unless the organization invests in a VPN infrastructure. Even in this case, forging a connection can be time consuming and expensive. Ad-hoc or brief access to the application is often not appropriate or possible leading to lost opportunities or data inconsistencies.
Sometimes users can plan to be offline. For example, you might have a sales worker who is out of the office for a specific period of time or a user who works from home. Sometimes, however, it is difficult to plan for an offline scenario. For example, a user in a warehouse with a Tablet PC may have a wireless connection that periodically drops. Another consideration is the quality of a user's connection. As organizations become increasingly distributed over the globe, network connectivity can suffer from high latency or low bandwidth problems.
In each of these cases, a smart client solution can provide robust access to the application so that the effect of connectivity changes can be minimized or eliminated. By intelligently caching data and logic on the client, and automatically deploying updates to both when required, the application can provide the user with a seamless experience independent of its connected state. In addition, a smart client can ensure that all network calls are handled on a background thread so that the application never has to wait for the network to respond, again allowing the user to carry on working regardless of the state of the network.
Realizing these goals with a thin client solution is very difficult to achieve. Some solutions try to solve this problem by providing the Web application, or a subset of it, on the client using a local Web server. Such solutions are difficult to maintain and require a complex infrastructure to ensure that updates to the application and its data are handled appropriately. Such solutions reduce the centralized management benefits that are often cited as the main reason for the adoption of a thin client solution, and they impose all of the other drawbacks inherent in a thin client solution.
Choosing the right presentation layer architecture can be critical to the overall success of an application. The right architecture will provide the right balance between the user experience, ease of development and testing, and the operational requirements of the application. Users are increasingly demanding that their part of this equation is taken into account.
The thin and smart client approaches are both well-suited to particular styles of applications. Recent advances in technology have redressed some of the imbalance between these approaches so that they need not be inappropriately applied to situations for which they are not suited. It is important that the correct approach is applied from the outset to avoid unnecessary complexity, cost, lack of flexibility, and a poor user experience.
Blanket corporate policies that favor one approach over the other are prone to incur these problems. An organization must carefully consider the overall needs of the application and compare these to the capabilities of each approach. The factors that can influence this decision are many and varied and this article has only touched on some of the more common ones. Invariably, the decision will come down to a compromise between the various factors. Understanding these factors, and their relative priorities, can help ensure that your organization chooses the right presentation layer architecture.
- Smart Client Architecture and Design Guide—Microsoft Patterns and Practices.
- Overview of Office 2003 Developer Technologies—MSDN.
- Overview of Office 2003 Developer Tools and Programs—MSDN.
About the Author
David Hill is a Solution Architect on the Microsoft Architecture Strategy team. For the last two years, David has been helping customers and partners architect and build successful smart client solutions on the .NET platform. He was a key contributor to the Patterns and Practices Smart Client Architecture and Design Guide, and the Offline Application Block.
This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit the Architecture Journal website.