Export (0) Print
Expand All

.NET Compact Framework Mobile Web Server Architecture

.NET Compact Framework 1.0

Nicholas Nicoloudis & Dennis Pratistha

Monash University, Caulfield, Australia

July 2003

Applies to
   Mobile Web Server
   Pocket PC
   Compact Listener Library

Summary: Get technical insight on the implementation of Mobile Web Server architecture. Understand use cases, the web server framework and future developments in the architecture. (11 printed pages)

Download MobileWebServerSampleSetup.exe.


Architecture Overview
Web Server Interaction Diagram
Future Work

This paper has been produced to provide technical insight on our Mobile Web Server architecture implementation. An academic paper related to this project has been published for the First International Conference on Web Services; the paper can be found at http://plato.csse.monash.edu.au/MobileWebServer/pervasive3.pdf. Initially, this project started as a basic web server that was capable of running on a Pocket PC. We developed a basic architecture that abstracted the processing of different web types into modules. The process began with the development of two modules, a standard HTTPFile module, and a SOAPModule. These modules implemented a basic interface to permit the dynamic invocation of post and get methods. The following section will investigate the architecture of the web server and provide a basic overview on the interaction of classes.

Architecture Overview

Figure 1: Mobile Web Server Architecture

The mobile sever consists of six packages (Figure 1). The core of the Mobile Web Server application is the Compact Listener Library. Both the HTML and SOAP modules depend on the Compact Listener to implement and inherit from the same base classes. This is required since dynamic loading and invocation is provided at run-time. The Mobile Web Server uses and depends on the Compact Listener to provide, listen for, and validate requests. The Mobile Web Server Interface depends on the Configuration classes to display information; it executes the Mobile Web Server in a separate process.

In designing the web server architecture, several primary and secondary system requirements were identified. These requirements represent the functionality that the system needs to perform in order to satisfy client requests, such as listening for client connections and encapsulating raw requests. All identified operations are illustrated in a high level use case diagram (Figure 2) to provide a clear understanding of the functionality required to be implemented in the web server. The summary of the main use cases (name, actors, type and overview) are discussed below.

Listen For Client Request
Actors: Compact Listener
Type: Primary and Abstract
Overview: Listens for client connections on a predefined port.
Receive Raw Client Request
Actors: Compact Listener
Type: Primary and Abstract
Overview: Once client connection is established raw request is received as a continuous stream of bytes.
Encapsulate HTTP Request
Actors: Compact Listener
Type: Primary and Abstract
Overview: Determines the type of the request received. If request received is an HTTP request, the request is encapsulated inside an object otherwise it is discarded.
Activate Compact Listener
Actors: Core Processor
Type: Primary and Abstract
Overview: Activates the Compact Listener to start listening for client connections on a specific port and register to accept incoming HTTP requests.
Load Process Modules
Actors: Core Processor
Type: Primary and Abstract
Overview: Reads the Module Index File to determine the modules required by the system. These modules are then loaded and stored in system memory.
Instantiate Process Modules
Actors: Core Processor
Type: Primary and Abstract
Overview: Creates an instance of the loaded modules and generates a map to store the instantiated modules with a predefined key. This map will be used by the system to lookup the required module to process the incoming client request.
Receive HTTP Request
Actors: Core Processor
Type: Primary and Abstract
Overview: Compact Listener notifies availability of new HTTP request through an event. Once event is received it starts the receiving process.
Validate Request
Actors: Core Processor
Type: Primary and Abstract
Overview: Verifies and validates all incoming data received from the Compact Listener (i.e. determine if requested data exists on local storage).
Resolve Request Type
Actors: Core Processor
Type: Primary and Abstract
Overview: Resolves the MIME type of each request and forwards it to the appropriate Supporting Module to perform the required operations.

Figure 2: Use case diagram

The web server framework (Figure 3) is partitioned into three distinct components: Compact Listener, Core Server, and Supporting Modules. Compact Listener is the highest level component; it is responsible for managing client requests on a particular port. Core Server is the primary component of the framework that receives encapsulated HTTP requests from the Compact Listener. It performs the necessary validations and determines the appropriate Supporting Modules to forward these requests to. Lastly, the Supporting Modules represents the implementation of a particular internet protocol (that is, HTML, SOAP and others).

Figure 3: Web Server Components

The Compact Listener consists of several classes that are responsible for tasks relating to the listening, receiving and encapsulation of raw client requests. Listening is activated by providing the port number to listen to (default for HTTP is port 80) and the maximum number of requests on queue. Upon receiving a new connection, the raw packets are processed and encapsulated in a HttpProcessorWebRequest object that is then passed to the Core Server class to determine the Supporting Modules to execute. The HttpProcessorWebRequest object represents the details relating to a client connection, these are listed in Figure 4. The HttpProcessorWebResponse class performs the necessary operations (that is, it generates the HTTP headers and converts results to a stream of bytes) required to send results of the execution back to the client.

Figure 4: HttpProcessWebRequest Object

Core Server

The Core Server is the main component of the framework. It has four main responsibilities:

  • Activating the Compact Listener to start the listening process.
  • Receiving encapsulated HTTP requests.
  • Verifying the validity of requests (i.e. requested data exists locally and Supporting Module exists for the requested MIME type).
  • Activating the appropriate Supporting Module to execute the operation.

Request Validation

There are four steps involved in determining whether the client request delivered by the Compact Listener is valid. First, the IP of the requesting host is extracted and validated amongst the denied IP address list. Then the requested URL is inspected to determine its validity and the file’s existence on local storage. The requested file is located by mapping the logical path into a physical path starting from its public directory. Since the proposed system is designed to host relatively few and simple web services, we assumed that there is no need to provide virtual directories (i.e. web directories located in various locations of local storage); one public directory (structured as a hierarchy) is sufficient.

After requested file is located on the local directory, the second step involves the web Configuration generating a map, which associates the supported MIME types with a Supporting Module. This map is created by retrieving the contents of the configuration file stored in an XML format (Figure 5: Configuration File) and instantiates all the Supporting Modules.

Figure 5: Configuration File

The map consists of the key and module object and its related mime types. The system then verifies whether the requested operation is supported. This is accomplished by looking up the requested file extension in the map (refer to Table 1). The located module object is then retrieved and used for processing the requested operation.

Key Value
Jpg HttpFileProcessor object
Gif HttpFileProcessor object
Html HttpFileProcessor object
Htm HttpFileProcessor object
asmx SOAP object

Table 1: Module Association Map

Finally, the module object is inspected to determine whether the requested method type (i.e. GET or POST) is supported. If the method type is not supported, an appropriate HTTP error message is returned to the client to indicate the failure of the request. Otherwise, the requested operation is forwarded to the module to perform the required operations and send the results of the operation back to the client.

Security verification to determine the access rights to certain data was excluded in this implementation. As discussed in section 4.1, our lightweight web services infrastructure is mainly aimed at demonstrating the suitability and possibility of hosting services from a mobile device. It was considered unnecessary to include any security mechanism at this stage.

Supporting Modules

As the internet is still evolving and in constant development, providing support for extensibility to address future compatibility is required. In addition, the vast majority of users requires different functionality and supported internet architectures to support their everyday use. For this reason, providing the flexibility of allowing users to customize the particular internet protocols required are essential. The proposed system addresses these requirements by abstracting the functionality of processing various internet protocols and isolating it into a separate component referred to as Supporting Modules. These Supporting Modules represents a plug-in architecture that is completely separated from the Core Server. The Supporting Modules are required to provide functionality relating to the processing of a particular internet protocol. In addition, it must implement the IHttpModule interface that represents the binding contract between the Core Server and each Supporting Module. The IHttpModule interface (Figure 6) consists of two method headers; ActivateGET and ActivatePOST, which are used to support GET and POST operations, respectively.

Figure 6: IHttpModule Interface

The current version of the proposed web server provides Supporting Modules for SOAP and HTML operations. These modules are represented as DLLs that represent a binary unit of an entity. However, users may provide support for additional internet protocols to fulfil their requirements. This is accomplished by developing the modules required to process the protocol operations and registering it with the configuration file illustrated in Figure 1.

Soap Module

The Soap Module addresses the requirements of processing web service remote invocation by clients. The current implementation supports GET, POST and SOAPAction operations. Typically GET and POST operations are utilized for browser request, returning an XML string to represent the results of operation. SOAPAction is used to identify SOAP packets requested by applications utilizing the particular web service.

Additionally, the SOAP Module provides facilities to automatically generate WSDL files from a requested web service. Therefore, it eliminates the need for developers to manually create the WSDL files confirming to their web service application. A WSDL file is used to define the entry points and contracts as well as describe the service of the application, thus allowing other web services or applications to utilize the web service correctly.

Html Module

The Html Module is a relatively simple component that supports the processing of HTML, GIF and JPEG web requests. As client requests are received, the required file is retrieved from local storage. This file is then converted to a stream of bytes in order to send it back to the client. Executing this module does not require heavy processing in comparison to processing web service remote invocations. This is due to the absence of performing complex operations to instantiate and process web service applications.

Web Server Interaction Diagram

Identifying the common tasks to be performed by the web server and the computations involved in processing those tasks is essential in developing a fully functional and efficient system. The processing of these tasks is illustrated using an interaction diagram in a simplified level to demonstrate the main communications involved between the processes and components of the system. The interaction diagram illustrates the steps involved in processing a web service remote invocation (Figure 7) and HTML web request (Figure 8). These operations are described below:

  • Web Service Remote Invocation – An application utilizing the hosted web service performs remote invocation to make use of the functionality offered. The web service is retrieved from the local storage and instantiated by the server. Requested operation is processed by the instantiated web service and the results sent back to the client.
  • HTML Web Request – A web site hosted on the web server is requested by a client. The requested file is retrieved from local storage and performs the necessary operations (i.e. converting into a stream of bytes) before sending results back to client.

Figure 7: Web Service Remote Invocation Interaction Diagram

Figure 8: HTML Web Request Interaction Diagram

Future Work

This mobile web server was a simple implementation, but there can be many modifications and enhancements made to provide greater functionality. A few basic enhancements that can be implemented immediately are listed below:

  • Combining the CustomURI and Request class so it can be passed to the HttpProcessorWebRequest. This will reduce the amount of parameters being passed.
  • Automatic shutting down of the socket once there is no more information to process or send.
  • Removing or combining the IHttpModule interface with the HttpBaseModule class. This should be considered since the interface provides no real functionality. The ActivteGet, ActivatePost and Error methods can be enforced by implementing abstract methods in the HttpBaseModule class.

Later work also includes storing sessions for requests and server side memory state so variables or application state can be processed and used by supporting modules.

© 2015 Microsoft