Analyzing Requirements and Defining Microsoft.NET Solution Architectures, Part X...

Creating the Physical Design (Deployment and Maintenance)

By: Chris Sully Date: August 28, 2005

Introduction

The aim of this series of articles is to provide an overview of issues surrounding the architecture of .NET Solutions. In doing so it is following Microsoft’s recommended approach and, in particular, looking at the requirements of the related Microsoft certification exam (70-300), which itself is one of the requirements for the MCSD .NET qualification. The main reference for this series of articles is the Que publication: 'Exam Cram2 .NET Solution Architectures'.

We’ve looked at the following thus far:

Article I: phase 1 of the process, the envisioning phase.

Article II: started on phase 2 (gathering and analysing requirements) focussing on business requirements.

Article III: continued with phase 2, focussing on user requirements and issues surrounding globalisation and localisation of your application.

Article IV: finished off phase 2, focussing on operational and infrastructure requirements

Article V: phase 3, developing specifications.

Article VI: phase 4, creating the conceptual design.

Article VII: phase 5, creating the logical design (application architecture).

Article VIII: phase 5, creating the logical design (logical data model)

Article IX: phase 6, creating the physical design.

In this article we continue our look at phase 6 with a look at the particular issues arising from a consideration of deployment and maintenance of the new system as well as a quick look at the physical data model, which should largely follow from the logical data model.

Creating the physical deployment design

Deployment

.NET offers XCOPY deployment for simple solutions. However, for more complex projects which employ the service layers discussed in earlier articles the ability to package these into deployable projects may become key to successful deployment. VS.NET is here to assist this process though a number of 3rd party tools are also available. There exist two overlapping areas: packaging the solution and distributing the solution.

Windows Installer is a built in installation program on Windows operating systems that maintains a database of registry and file information for every application installed. Windows Installer package .msi files are most commonly implemented with aid from Visual Studio .NET's setup and deployment projects.

VS.NET offers the following types of setup and deployment projects:

• Setup project – for deployment of business logic components, client applications and Windows service apps.
• Web setup project – for web applications (ASP.NET web forms apps and Web Services).
• Merge module project – for components to be shared between projects.
• CAB project – traditionally for ActiveX so for legacy application support.

The standard setup projects and web setup projects offer a GUI to support the following:

• Integration with Add/Remove programs in Control Panel to install, uninstall and repair installations.
• Roll back the system to its original state if the installation fails or the client cancels the install.
• Perform registry manipulation, create file associations, install assemblies in the GAC, run custom tasks, check H/W and S/W prerequisites, register assemblies for use with COM interop, etc.

Note that Windows Forms deployment has become simpler in .NET, now being easily achievable through HTTP thus providing easy deployment (including updates) but still with the rich client offline capabilities. The executable runs on the client machine in a sandbox satisfying security issues.

Typically the licensing process involves the following: a caller requests a class, and the class validates the caller against keys stored in the binary file. .NET offers utilities to aid in validating and creating licensed assemblies. These include a class called LicenseManager that validates the client caller and the License Compiler (LC.exe), a command line utility to obtain runtime keys and store them in binary format for inclusion in the licensed assembly (something VS.NET will do automatically for you for classes marked with the LicenseProvider attribute). After a class has been marked for validation you call the static Validate() method of the LicenseManager class in the constructor of your licensed class. The validate method returns your license which should be saved to a member-level variable of type License.

More complex custom licensing may also be required, which can be implemented by inheriting from the LicenseProvider class and overriding the IsKeyValid() and GetLicense() methods.

Data migration

Often there will be data from existing systems to be migrated to the new. This is no great problem as long as the legacy system supports OLEDB. If large volumes of data are involved bandwidth consideration/ estimating the time for migration may become key.

SQLServer 2000 has two utilities for data transfer between data sources: Bulk Copy Utility (BCP) and Data Transformation Services (DTS). DTS is GUI driven, whilst BCP is command line, and DTS has database mapping transformation facilities and can save a package to run as a scheduled job. DTS is preferred in most situations. BCP is only really suitable when you have one table to copy and no data transformations are required.

Upgrading

Physical specifications should include an upgrade plan to apply bug fixes and enhance solution capabilities. When an upgrade takes place, you are usually faced with patching or reinstalling the application. VS.NET does not support patching but other Windows Installer platform tools, such as Orca.exe and MsiMSP.exe can produce patch files.

When multiple applications need to use different versions of the same assembly on the same server you should implement versioning. If the assembly is accessible globally through the GAC, a side-by-side versioning scheme is automatically applied.

No patching or repackaging is necessary when a web deployed Windows form executable is built to retrieve automatic updates from a web server and it knows:

• When and how to check for updates
• Where the updates are found
• How to apply the updates

The suggested 'no touch deployment' uses an asynchronous thread. Updates are automatically loaded when the application is initialised and the client is online. You could also use an asynchronous thread to check for updates and when one is found and downloaded repaint the screen. You may want this thread to be fired on an hourly basis, for example, on a timer.

Creating the physical design for maintenance

Through monitoring your application and determining potential trouble spots you can catch bugs before complaints start rolling in from clients. The maintenance plan should include reviewing errors found in the Windows event log/ whatever logging facility your app uses and raising red flags for any critical issues found.

You should also consider engaging in application monitoring to identify actual or potential performance issues. Monitoring in .NET is commonly implemented via Windows Management Instrumentation (WMI), which offers advanced and robust techniques supplied throughout the Windows platform.

An outline of the application monitoring process:

1. Analysis – what do you want?
2. Application instrumentation – expose the information you wish to monitor.
3. Consider using supporting applications: Systems Management Server (SMS), Application Center service (AC), Microsoft Operations Manager (MOM) which offer built-in support for WMI, making integration easier.
4. Manage the application monitoring process.

WMI is an implementation of the Web Based Enterprise Management (WBEM) initiative originally designed for C++ and VB development. WMI provides a standard means of accessing health and performance information from servers on a LAN, which is more convenient than accessing standard system APIs. WMI functionality is accessible through the System.Management namespace. All WMI classes inherit from the ManagementBaseObject class.

WMI exposes functionality in the following areas:

• Monitoring the operational state of an application.
• Determining the health of system resources and components.
• Measuring performance through queries (via WQL, a subset of SQL).
• Allowing configuration of application settings, such as timeout values, maximum concurrent users, etc.

WMI can query via the following built-in providers to access provider specific health and maintenance information:

• Performance monitor provider
• Registry provider
• Registry event provider
• SNMP provider
• Windows event log provider
• Win32 provider
• Windows Driver Model (WDM) provider

The logical design should transfer fairly smoothly to the physical with a couple of extra areas to consider further: indexing, partitioning and data denormalisation.

Indexing allows you to find records more quickly, as long as the indexes are thin and exact. Remember that insertion performance will be slowed by index maintenance operations. Columns used in common table joins are good candidates for indexing.

Indexes can be clustered or non-clustered. Clustered indexes are physically sorted by columns in a table and hence you can have only one clustered index. SQL Server automatically creates a clustered index on the primary key. Non-clustered indexes create a separate instance of the row based on the clustered column. A non-clustered index provides excellent benefits over a full table scan if the majority of queries contain a WHERE clause on the indexed column. However, they consume resources which must be considered.

SQL Server offers the Index tuning wizard which will recommend index placement, tuning the database to your specific queries.

Data can be partitioned into more manageable chunks to improve performance and/ or resource utilisation. Options are:

• Horizontal partitions – division of a table based on its rows.
• Vertical partition – divide a table based on its columns.
• Disk partitions – divide a database across multiple physical disk drives.
• Database partitions – performed via federated databases (via linked servers) allows division of database tables across multiple servers hosting different instances of SQL Server.

As discussed in the logical design section denormalisation can improve overall performance of your application and is commonly practiced in data warehousing and reporting databases.

Validate Your Physical Design

How are we doing against the PASS MADE criteria?

Performance

For users this equates to responsiveness, for which the following checks for appropriate usage are applicable:

• Caching
• ViewState
• Asynchronous calls
• Database indexing
• Denormalisation

Availability

Have you guaranteed availability by best practice design? Is the application reliable enough to be in a production environment? Implementation of the following will assist in meeting this goal:

• Auditing and logging routines
• Exception handling
• Service layer architecture design to ensure proper coding practices though a multi-tier data flow design
• Asynchronous calls for long running transactions to minimise operations being cancelled by the user

Have you secured the application against interception of data and user attacks? Does the application pose any security threats to your network? Implementation of the following will assist in minimising potential issues:

• Authenticate users
• Authorise access only to users who need access to the specific resource and don't provide more access than is required
• Encrypt sensitive data being passed via http with SSL
• Setup firewalls between each service layer and another between the interface and the user in a web app. The UI and BSL will be in a DMZ.

What happens when you double the load? Identify bottlenecks in your application via load testing. Implementation of the following will assist in minimising potential issues:

• Server layers should be implemented in such a way that if you must run multiple versions of the same application, the service layers can handle hand shakes and tradeoffs smoothly.
• Web farms should be used to provide added scalability to a web application where applicable.
• ACID transactions should be employed to prevent invalid data.
• The solution should be scalable to their platforms, e.g. by exposing a service agent in the form of a Web Service

Implementation of the following will assist in minimising potential issues:

• Use tracing
• Catch, log and analyse exceptions
• Use WMI

Accessibility

Consideration of the following will assist in minimising potential issues:

• Support for accessibility aids
• Will state management choices impact on users?
• Should a platform independent service agent, such as a Web Service be implemented?

Deployability

Have you documented a deployment plan? Is it as simple as possible with the least possibility for error? Consideration of the following will assist in minimising potential issues:

• Have you chosen a suitable solution for your projects from XCOPY to msi files?
• Have you considered using Windows no touch deployment for your Windows Forms application?
• Have you planned for any data migration/ deployment?

Extensibility

Have you considered how your solution will be extended in the future to support enhancements and bug fixes? Can you implement new functionality without breaking previous versions? Implementation of the following will assist in minimising potential issues:

• Use XML standards to ensure that future objects can access prior code.
• Use the simpler versioning capabilities of .NET (GAC).
• Upgrade applications using the original setup project and Windows Installer will automatically determine what needs to be upgraded.
• Data partitions are an additional avenue for extensibility.

Finally:

• Does the proposed physical design fit all use cases and usage scenarios that you are required to support? Validate your uses cases against the completed physical design.
• Does your proof of concept deliverable demonstrate that your physical design is within an acceptable risk range? Is there anything else you can demonstrate to mitigate risk?

Next

We're not far from completing our run through of issues surrounding architecting .NET solutions. In the final couple of articles we'll take a step back from the phased approach to look at two areas that pervade the whole endeavour: standards and processes.

References

Exam Cram 2 .NET Solution Architectures
Cornish et al.
Que

http://msdn.microsoft.com/architecture/