Message -Server and Store Overview

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:

Storing -Messages
Handling -Client Requests
Caching
Searching -and Sorting Messages

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.

- Logical structure of Messaging Middleware architecture - - - 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).

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 Store

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:
- access the various types -of storage associated with an entry
- discover and access -other entries that the entry owns (its children)
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.

Typical uses

Configuring the Message -Server ans Store
Writing MTMs
Searching and sorting -messages
Processing emails in -chunks

-Messaging -Framework -Message Server -and Store Concepts -Message Server -and Store Tutorials + + + + + +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:

Storing +Messages
Handling +Client Requests
Caching
Searching +and Sorting Messages

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.

+ Logical structure of Messaging Middleware architecture + + + 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).

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 Store

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:
- access the various types +of storage associated with an entry
- discover and access +other entries that the entry owns (its children)
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.

Typical uses

Configuring the Message +Server ans Store
Writing MTMs
Searching and sorting +messages
Processing emails in +chunks

+Messaging +Framework +Message Server +and Store Concepts +Message Server +and Store Tutorials

\ No newline at end of file