Web Monitor Application Flow

The Web Monitor application is a .NET application that utilizes a set of simplified business objects to manage the process of monitoring multiple Web Monitor Sites. These business objects are then utilized in a Windows Forms interface, a Windows Service and also for the Web Administration interface.

Application Flow

The figure below shows Web Monitor's Application flow in some detail. As you can see Web Monitor uses various components through the Web Monitor API to handle most processing.

Figure 1 - Web Monitor Application Flow - The Web Monitor API provides low level access while
the form calls into the WebMontorSiteList Manager.

The Windows Service Implementation uses exactly the same mechanism except that it doesn't handle any of the events fired from the WebMonitorSiteList instead relying solely on the logging mechanisms to maintain logging status. The Web Administration interface as well as the Log Viewer can then parse the logs and display the latest results.

The following is a rough layout of application flow for the Windows Desktop application.

Application Startup

The application is launched using a startup class (startup.cs) which contains the static Main() method. This class fires the application and loads the WebMonitorMain form which hosts the main user interface. This form is used both when the application is launched in screen mode or in Task Tray mode and contains the visual display of site status as well as the toolbar and main menu.

Loading and Saving

The actual WebMonitorSite info is stored in an XML file which is actually a serialized class in XML format. The XML is a serialized version of the WebMonitorSerializer class which hosts an array of WebMonitorSite objects and a WebMonitorConfig object. This configuration is simply persisted to a file through the various methods on the WebMonitorSiteList object.

The WebMonitorSiteList object

The Web MonitorSiteList object serves as a business object style container for the current batch of sites to be monitored. It contains an array aSites[] and an oConfig member, and acts as a manager object for this array of sites. This is a non-UI class and performs all actions via its method interface.

It performs several functions:

Handles the storage of site list and configuration information in XML format
Handles adding, removing and updating of nodes sites
Starts a new thread and runs the monitoring operations of each site from this thread
Handles passing of any messages from the individual sites to the user interface for message display

Most of the code in WebMonitorMain which is essentially front end code communicates with the WebMonitorSiteList object.

The Monitoring Operations

The main method that starts monitoring is the CheckSitesAsync which starts a new thread that runs a controlled loop that fires each individual site check on another new thread using WebMonitorSite::CheckSiteAsync(). This method eventually calls the actual checking method WebMonitorSite::CheckSite() which performs the actual HTTP access operation and checks to see whether the request is successful. The SiteList object's site loop basically loops around to check and see whether a site needs checking and if it does fires the Urls via CheckSite as needed.

User Interface integration

The User interface is updated through events that are fired by the WebMonitorSite. This process is a little complicated because the messages originate on separate threads and must be marshalled through several different threads. WebMonitorSiteList::CheckSitesAsyncRun() actually attaches the WebMonitorSite message events to its own OnMessage() method which runs on the check thread. This method in turn fires a method on the WebMonitorMain form (OnMessage()) which is passed the Site object, a simple text message and a message ID which identifies what kind of message it is dealing with. Message states are:

0 - Processing
1 - Success
2 - Failed

These states are used by the user interface to show the appropriate icon in the treeview.

The form's OnMessage() event picks up the message and then marshals it back to the form's main thread using Invoke by calling the UpdateSite method, which updates the TreeView with the information.

Application Threads

The message display interface and message passing is probably the most complex due to the convoluted requirements of passing messages over multiple threads. The app basically has to deal with three types of threads: The main application thread (the forms run on this), the polling thread that simply checks for sites that need checking, and each of the actual site check threads which fire each. The main flow is this:

Application thread starts and calls the WebMonitorMainForm
WebMonitorSiteList.CheckSitesAsync is fired and starts the polling thread
Each site check fires a new thread on the WebMonitorSite object
Messages fired from the Site are passed back to the WebMonitorSiteList.OnMessage() method
The call is marshalled to the form's main thread via Form.Invoke()

Support forms

The SiteViewer and ConfigViewer forms are used to display editable information about each site and the general configuration. These forms are passed instances of the WebMonitorSiteList or an individual Site to display and edit. The forms are data bound to these objects directly using custom databinding controls found in wwDataControls. These controls allow controlsource style binding via property settings and a special form method called DataBind() on each.

Support classes

Web Monitor also includes a few helper classes that help with various operational tasks required for checking. Specifically the wwHTTP and wwSMTP classes provide simplified wrappers for accessing HTTP content and sending email. The wwSMTP class was created primarily to avoid any dependency on COM (CDCONTS for the .Net SMTP services) . The wwUtils class also contains a number of useful helper functions