Message Server and Store Overview
This section provides an overview of the functionality and the architecture of Message Server and Store.
Purpose
The following services that are provided by this component can be used by the client application:
Architecture
Message type-dependent operations, such as address handling, are called by client applications using client MTMs and UI MTMs. These MTMs then access the appropriate Message Store and alter it as required.
The following figure shows the logical structure of the Message Server. Dashed boxes indicate components that can be developed by third-parties.
- Application/App UI
This represents a message client application.
- User Interface MTM, Client-side MTM, UI Data MTM, Server-side MTM Bases
These are base classes required for implementing protocol-specific MTM components. User Interface and UI Data MTMs handle user interface functionality and resources. Client-side MTMs provide message data handling functions. Server-side MTMs provide message transport functions.
- Concrete User Interface MTM, Concrete Client-side MTM, Concrete UI Data MTM, Concrete Server-side MTM
These represent instances of MTM components written to implement a particular messaging protocol.
- Message Server
The Message Server handles all requests to access or manipulate message data. Where necessary, it passes requests to the protocol-specific message transport components, the Server-side MTMs.
- Session
Sessions allow client-side components to issue requests to the Message Server. There are a number of classes provided to clients that allow message entries to be manipulated.
The msgs.dll library provides a client-side session class called CMsvSession . Client applications typically create an instance of this class on start-up. Instances of Client MTMs, User Interface (UI) MTMs and high-level client library classes maintain a reference to the client application’s session object, to make requests if needed.
Message client applications, Client MTMs and UI MTMs manipulate entries through TMsvEntry and CMsvEntry classes. The entry currently being operated on is called the context. A client application can begin by setting the context to the root entry. By finding the children of this initial entry, and then their children in turn, any entry can be found.
Operations such as creating, deleting, sorting and accessing body text, or changing an index entry, which are independent of the message-type, are requested by client applications and MTMs through CMvsEntry or CMsvServerEntry. The Message Server may either perform such operations itself or delegate them to a server MTM.
Description
The Message Server is the core component in the Messaging Middleware module. It accepts asynchronous requests from clients through a kernel-maintained session. It performs the following functions:
Controls access to message data
In response to client requests, the Message Server delegates temporary, exclusive access to message data, so that more than one client cannot edit the same message at the same time. It is the responsibility of Message Server to keep the message data in workable order, and cope with events such as failure recovery.
Delegates requests to Server MTMs
Message Server must identify requests, such as sending a message that requires protocol-specific functionality, and load the appropriate Server MTM.
Message Server provides persistent storage of messages and messaging account settings by providing a Message Store. The Message Store contains message data in a variable number of entries in a tree view, each of which is referenced by a unique identifier. This concept is known as a dictionary file store. Each entry in the tree can represent an email account, folder of messages, message part and so on.
Message Store is secured in a protected data-caged area of Message Server. Message Server allows multiple read-only and a single read-write access to a message in the Message Store at given time. It also accepts copy and delete requests from clients trusted with WriteUserData capability. When a copy or delete is requested, the message server first flags itself as unavailable and then locks the files before attempting to process them.
Message settings are stored in the Central Repository and attachment information is stored in the Message Store. MTMs can create additional streams in the message store to hold MTM-specific message data. Usually, at least one stream is devoted to non-generic header information such as recipient information.
When Message Server starts, the Message Store is created unless there is already a Message Store present. Message Server initially creates the Message Store with just a root entry and then creates standard folders defined in the msgs.rsc resource file. Finally the Message Server runs mailinit.exe to customise of the Message Store. The behaviour of mailinit.exe is defined by the UI family of the device, such as Series 60 or UIQ. However, the typical behaviour is to load each of the UI MTMs and allow each to perform any message type specific initialisation. For example, the SMS plug-in typically creates a default service entry.
API summary
The storage abstractions through which client applications access the various types of storage are key to the Messaging Middleware module.
The CMsvEntry API access and acts on a particular Message Server entry. The main functions of this API are to provide means to:
CMsvServerEntry is similar to CMsvEntry, but used only by Server MTMs.
TMsvEntry encapsulates an index entry the Message Server index.
CMsvStore encapsulates an entry’s Message Store.
MMsvAttachmentManager class is a pure virtual interface class that defines the APIs to be used for attachment management in the Messaging Framework.