Architecture

Introduction

As it isn't possible to create Windows Services in managed code, another solution has to be created.

The main goals for this library are:
  • Provide a similar functionality to Windows Services
  • Enable developers to customize newly created managed services as much as possible
  • Offer an Infrastructure, which can be used easily by other developers

Note: As this project is supposed primarily to be used with Windows Mobile, it shall work with Windows Embedded CE and Windows XP/Vista as well. It hasn't been tested yet.

How to create an Infrastructure similar to Windows Services?

A Windows Service like library has to offer the following:
  • Control a Managed Service
    • Start
    • Stop/Quit
    • Suspend
    • Resume
  • Offer a possibility to control a service from an external application

As well a technology should be used, which is already existent and generally available in the Windows System. The best would be, if applications could "talk" to each other on a very easy and in a leightweight way.

Under the hood

Such a technology is Windows Messages. It is primarily used by the OS to inform graphical components (like controls etc.) to do something. This can be a repaint, a click or any other well known message. The .NET (Compact) Framework uses it as well. It is just covered/wrapped by the Framework.
Some additional information on Windows Messages can be found here.

Simplified a Message consists of a destination address, a command and two additional parameters. The command itself is an Integer. The additional parameters are Pointers or Integer values. The destination is a HANDLE.
If you are interested in diving deeper into this topic, I recommend reading this.

As Messages can be sent across applications and can contain commands, which we need for Stopping, Suspending and Quitting a Service this technology suits well.

As a receiver a MessageWindow is used. A MessageWindow has to offer a type of information, which the sender can adress the message to.
In general the Name of the Form is used. But unfortunately this can change as well as another MessageWindow could use the same. That could lead to a little bit of a problem.
For that case this library uses GUIDs. A GUID is a (so said) Globally Unique Identifier. More information on GUIDs can be found here.

These ingredients are sufficient for creating Managed Services for Windows Mobile.

Abstract Architecture

All necessary components are already available within the class Microsoft.WindowsCE.Forms.MessageWindow.
This class offers the method WndProc(ref Microsoft.WindowsCE.Forms.Message m), which can be overridden by a derived class.
WndProc itself is the receiver for Windows Messages, which are passed by reference as a parameter.

This library contains an internal class ServiceMessageWindow, which is derived from the class MessageWindow. It contains additional functionality for managing commands("messages"). Those can be added or removed, as well as checked for existence.

If a Message is received, it is checked, if an according command has been registered. If yes, an implemented event (OnRegisteredMessage) is fired. If not, the message is forwarded to the base class.

The ServiceMessageWindow class is wrapped by the abstract class ServiceApplication. It is abstract, because no instance is allowed to be created. It has to be derived for the own implementation.
ServiceApplicationDependency.png
ServiceApplication already contains the registration for the Suspend, Resume and Quit command. Therefore the class registers for the event from ServiceMessageWindow. By this the commands for Suspend, Resume and Quit can be caught and processed.
Additionally this class contains a method Run. This method is an endless running method (until it is aborted by Quit), which processes Application.DoEvents(). If that wouldn't be the case, Window Messages could probably not be processed.
ServiceApplicationClass.png

Changelog

Please note, that due to the 1.0 Alpha 2 release, the Window Messages Prefix has changed from WM_* to UM_*. Please read Change WM_* Prefix to UM_* for further information.

Last edited Jun 5, 2008 at 8:13 AM by PeterNowak, version 7

Comments

No comments yet.