Rich Internet Application (RIA) Design Checklist

Design Considerations

• The application is designed for running in the browser sandbox.
• The application is designed for supporting multiple browsers and operating systems.
• The application detects when the browser plug-in is not installed and takes the appropriate action.
• The application provides alternative for clients that do not have RIA support.
• The application uses mechanisms to increase performance and responsiveness.

Business Layer

• Business logic is located on the server and exposed through Web services.
• Business logic is moved to the client, only when it improves the overall system performance or makes the UI more responsive.
• Business logic on the client is deployed in a separate assembly that the application can load and update independently.
• Logic that is duplicated on the client and the server is written in the same code language where possible.
• Sensitive business logic deployed on the client is encrypted.

Caching

• Components and objects that are not likely to change during a session are cached on the client using the browser cache.
• Information that changes during a session, or which should persist between sessions, is cached in specific RIA local storage.
• Application modules are intelligently divided for efficient installation, updates, and loading.
• The application loads stubs dynamically at start-up and then loads additional functionality in the background.
• The application uses events to intelligently pre-load modules just before they are required.
• The application checks the local RIA storage, before writing the data, and asks the user to increase the storage, if it is not large enough.

Communication

• Background threads and asynchronous execution are used for long-running code routines to avoid blocking the UI thread.
• Compatible bindings are used for the RIA applications and services it calls.
• The cross-domain configuration mechanism is used to allow the application to access a server other than the one from which it was downloaded.
• Sockets are used to proactively push data to the client where client polling would cause heavy server load.
• Sockets are used to push information to the server when this is significantly more efficient than using Web services; for example, real-time multi-player gaming scenarios utilizing a central server.

Controls

• Native RIA controls are used where possible.
• Third-party RIA-specific controls are used when an appropriate native control is not available.
• A windowless RIA control in combination with an HTML or Windows Forms control supporting required functionality is used when a native or third-party RIA control is not available.
• Control sub-classing is not used to extend functionality; instead behaviors are attached to existing controls where the RIA technology supports it.

Composition

• Composite View pattern is used to combine modular, atomic component parts to create composite views.
• Composition is used for interfaces that gather information from many disparate sources that are user-configurable or change frequently.
• RIA and the existing HTML are mixed on the same page to migrate an existing HTML application, in order to minimize application reengineering.

Data Access

• The number of round-trips to the server is minimized, while still providing a responsive user interface.
• Data is filtered at the server rather than at the client to reduce the amount of data that must be sent over the network.
• Services are used to access data for operation-based applications.

Exception Management

• Exceptions are not used to control business logic.
• Exceptions are caught only if they can be handled.
• Exception propagation strategy is designed to log and transform exceptions at boundary layers before passing to the next layer.
• The application uses try/catch blocks to trap exceptions in synchronous code.
• Exception handling for asynchronous service calls is located in the separate handler.
• Unhandled exceptions passed to the browser are trapped and a user friendly error message is displayed.
• The server is notified of client exceptions, whenever required.
• The application displays user-friendly error messages.

Logging

• Business critical and system critical events are logged.
• Each user has separate logs; the different user logs on the machine are combined.
• Client logs are transferred to the server for processing.
• The application checks the maximum size limit of isolated storage, before writing the data, and asks the user to increase the storage, if it is not large enough.
• The design enables logging and transferring logs to the server when exceptions are encountered.

Media and Graphics

• Streaming media and video are displayed in the browser and not by invoking a separate player utility.
• Media objects are positioned on whole pixels and presented in their native size to maximize performance.
• Adaptive streaming is used to gracefully and seamlessly handle varying bandwidth issues.
• The vector graphics engine is utilized to maximize drawing performance.
• The application considers the hardware acceleration limitations when designing graphics-intensive application.

Mobile

• RIA client for mobile device is designed considering the RIA plug-in implementation available for the device.
• A single or similar codebase is used to maximize cross-platform capabilities.
• The UI layout is designed considering the smaller screen size.

Portability

• The application design supports "write once, run everywhere" principle.
• The application does not use features available only on one platform, such as Windows Integrated Authentication to support multiple platforms.
• Development languages that are supported for both Rich Clients and RIAs are used.
• The application uses native RIA code libraries.

Presentation

• Media objects are positioned on whole pixels and presented in their native size to avoid anti-alias issues that may cause fuzziness.
• The browser's forward and back button events are trapped to avoid unintentional navigation away from your page.
• Deep linking methods are used for multi-page UIs to allow unique identification and navigation to individual application pages.
• The application manipulates the browser's address text box content, history list, and back and forward buttons in multi-page UIs to implement normal Web page-like navigation.

State Management

• Client’s isolated storage is used to persist state between sessions.
• Client state is stored on the server, if loss of state on the client would be catastrophic to the application’s function.
• Client state is stored on the server, if the client requires recovery of application state when using different accounts, or when running on other hardware installations.
• The client and server are synchronized at intelligent intervals, or at the end of a session when storing state on the server is necessary.
• Synchronization of stored state is verified between the client and server at startup, and inconsistencies are intelligently handled.
• RIA is designed for multiple concurrent sessions if multiple RIA instances can be initialized.

Validation

• Client-side validation is used for better user experience. Server-side validation is used for security. Client-specific validation rules are cached in isolated storage.
• All client-controlled data is revalidated it on the server.
• The validation strategy is designed to constrain, reject and sanitize data.
• Single service calls perform validation rules on the server when the rules require access to server resource.
• Large volumes of client-side validation code are located in a separate downloadable module.

Performance Considerations

• Components and objects that are not likely to change during a session are cached on the client using the browser cache.
• Information that changes during a session, or which should persist between sessions is cached in specific RIA local storage.
• The application loads stubs dynamically at start-up and then loads additional functionality in the background.
• Code routines that cause the heaviest server load or have the most impact on UI responsiveness are moved to or cached on the client.
• Scenario-based profiling is used to discover and target routines that cause the heaviest server load, or that have a major impact on UI responsiveness.
• Media objects are positioned on whole pixels and presented in native size.

Security Considerations

• Sensitive data stored locally is encrypted using the platform encryption routines.
• An exception management strategy is used to prevent exposure of sensitive information through unhandled exceptions.
• Sensitive business logic is implemented through Web services or obfuscated when stored on the client.
• Dynamic loading of resources, and overwriting or clearing objects from memory, is used to minimize the amount of time that sensitive data is available on the client.

Deployment Considerations

• The application can handle the scenario where the RIA browser plug-in is not installed.
• The application can manage redeployment of modules when still running on a client.
• The application is divided into logical modules that can be cached separately, and can be replaced easily without requiring the user to download the entire application again.
• The application components are versioned.

Distributed Deployment Considerations

• Business logic that is shared by other applications is deployed using the distributed pattern.
• A firewall is installed between the client and the business layer.
• Access to other domains is enabled using a crossdomain.xml file.
• The presentation layer does not initiate, participate in, or vote on atomic transactions.
• Business logic uses a message-based interface.
• Sensitive data passed between different tiers is protected.

Load Balancing Considerations

• The application avoids server affinity where possible.
• The application stores all state on the client and uses stateless business components.
• Load balancing is implemented for redirection of requests to the servers in an application farm.

Web Farm Considerations

• Clustering is used to reduce the impact of hardware failures.
• The database is partitioned across multiple database servers when the application has high I/O requirements.
• The Web farm routes all requests for the same user to the same server when the application must support server affinity.
• An out-of-process session service or a database server is used in the Web farm unless server affinity is implemented for all clients.