Creating the Physical Design for Maintenance

In the real world, a lack of maintenance can accelerate deterioration. Software has a very short lifespan, and if it is not properly maintained, unsatisfied clients and users immediately seek other venues. Through monitoring the application and determining sensitive weaker areas, you can catch bugs before complaints start rolling in from clients.

In Chapter 9, you created the physical exception-handling specifications. Your maintenance plan should consider automatically reviewing errors found in the Windows event log and/or an RDBMS and raising red flags for redundant or critical messages. Reviewing the exception list is an excellent way to discover bugs, but often it doesn't uncover performance-related issues, which can be just as much of a hindrance as exceptions. For example, requests could be taking five times longer than normal to fill, which cannot be detected through exception handling, but is highly visible through application monitoring.

Application Monitoring

.NET monitoring is commonly implemented with Windows Management Instrumentation (WMI). WMI offers advanced and robust techniques supplied through the Windows platform.

Here is an outline of the application-monitoring process:

1. Analysis You must devise a strategy and gather requirements before you can implement a solution.

2. Application instrumentation You should build applications to expose timers, counters, and other related performance maintenance components.

3. Common infostructure service technology You should take advantage of Systems Management Server (SMS), Application Center Service (AC), and Microsoft Operations Manager (MOM) because they all offer built-in support for WMI, making integration with your application-monitoring process easier.

4. Development technology WMI code is written in Visual Studio .NET or other development tools.

5. Management After deploying the application, you should manage the application-monitoring process created previously to watch for performance-related issues.

Windows Management Instrumentation

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 local area network (LAN), which is more convenient than accessing system application programming interfaces (APIs). WMI is accessed through the System.Management namespace. All WMI classes inherit from the ManagementBaseObject class.

WMI has the capability to perform the following functionality:

• Monitor the operational state of an application.

• Determine the health of system resources and components.

• Measure internal performance through queries.

• Allow configuration of application settings, such as timeout values, maximum concurrent users, and database connection strings.

By using WMI and Windows Management Instrumentation Query Language (WQL), you can uncover extensive information about processors, devices, COM+ components, and operating system details. WQL is a subset of American National Standards Institute Query Language (ANSI SQL) and provides a means to query information from a requested machine through WMI. A WQL query looks like this:

 SELECT * FROM Win32_Processor 

WQL queries an operating system similarly to the way SQL queries a database, except WQL does not allow the NULL, TRUE, and FALSE keywords.

WMI can query through 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