This section provides an overview of the functionality and the architecture of Message Server and Store.
The following services that are provided by this component can be used by the client application:
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.
Figure: Logical structure of Messaging Middleware architecture
Note: No lower-level communication components are shown, as the architecture is designed to be independent of any particular communication protocol. Instead, communication libraries are accessed as needed by Server MTMs. For example, an SMTP MTM would use TCP/IP, while the SMS MTM would use the Telephony Server (ETel).
This represents a message client application.
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.
These represent instances of MTM components written to implement a particular messaging protocol.
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.
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.
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.
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.