Concepts with Symbian OS (779878), страница 57
Текст из файла (страница 57)
All messages that are of the ‘email’class of messages might be viewed the same way – through an emailviewer that can present the textual message with tools to view headerinformation as well as any attachments to the email. There is a common composition (editing) interface that you can use to compose newmessages or edit draft messages. There is a set of user-interface definitions – some icons for email applications to display, for example – thatcan be accessed. Finally, email is transported to a server via SMTP andreceived from a server via POP3 or IMAP4.
(Since there are three transportfunctions, one could argue that there are actually three message types foremail. Symbian OS views it this way as well.)If we expand our view to other types of messages, we can see that theframework established for Symbian OS works for any type of messagewe have encountered. Fax, SMS and BIO messages all have this format,albeit with different implementations for each component.13.2The Symbian OS Messaging ModelWe examine Symbian OS as an example of an operating system built tohandle messaging in its basic design.When building the messaging system, Symbian OS designers wereguided by the need to put together a generic framework that could handlethe components of many different message types.
They built a frameworkthat viewed all messages as composed of generic components. Throughthe use of object orientation, each message type is handled by a separateimplementation of those generic components. Symbian OS messagearchitecture brings these implementations together under a commonmessaging application and a common API.Symbian OS uses message type modules (MTMs) to define messagetypes. An MTM is composed of four classes that are used as base classesfor specific message-handling implementations:• the user-interface MTM is defined as the CBaseMtmUi class anddefines user-interface capabilities, such as viewing and editing messages• the client-side MTM defined as the CBaseMtm class handles theinterface between the internal representation of a message’s data andthe user-interface MTM276MESSAGING• the user-interface-data MTM is represented by the CBaseMtmUiDataclass and provides access to user-interface-data properties (e.g., icons)• the server-side MTM is defined in the CBaseServerMtm class andprovides message-transport capability.Each message type, then, has an implementation of each of theseMTMs, subclassing their definitions from the classes above.
Some messagetypes can share MTMs; IMAP email and POP email, for example, canshare the same user interface MTM while having different server-side andclient-side MTMs.Some Perspective on this ArchitectureThis way of modeling messages is powerful and very effective. Throughvarious MTM implementations, Symbian OS supports its four main message formats (email, SMS, fax and BIO formats) as well as several formatsthat work behind the scenes to implement other protocols.It is interesting to examine the disparity between the various formsof messaging under the MTM framework.
Fax messaging, for instance,is vastly different from SMS messaging, yet both fit comfortably in thismodel. Although a fax has different delivery requirements from an SMSmessage and must be viewed as an image, where SMS can be viewed astext, both can still be integrated with the same messaging application ona Symbian OS device.The large number of different forms of messaging results in a largenumber of MTM implementations. Any messaging application must beable to sift through these implementations to find the necessary MTMsas quickly as possible.
Symbian OS helps in this endeavor by providinga registry of installed MTMs that are accessible to an application. Thisregistry allows MTM components to be identified and instantiated quicklyand easily.Now consider this structure from a programmer’s perspective. Imagineyou are a programmer who wants to implement the sending of an SMSmessage as a small part of a larger application. It would be quite dauntingfor you to use the MTM framework in all its glory to send a ‘simple’ SMSmessage. In fact, you might just reject the idea as not worth the time andeffort.
The designers of the MTM model understood that a complicatedstructure might frustrate programmers who want to do simpler tasks,so they added something to the architecture called send-as messaging.Send-as messaging provides a simple interface that allows applicationsTHE SYMBIAN OS MESSAGING MODEL277to create outgoing messages by using a single API.
By using send-asmessaging, a programmer uses one interface for any message and simplyinforms the OS what type of message to send; the OS implementationfigures out which MTMs to use and how to send the message. This isa powerful idea and it reinforces the modularity of the MTM structure.It has proven to be an easy and effective interface. It is so effective, infact, that many applications use it to transport data other than traditionalmessages.
The Agenda engine, for example, uses send-as messaging tosend vCalendar objects over the IR interface.Message Server FunctionsSymbian OS considers the data repository for messages as a resource thatcan be shared between processes. Therefore, following Symbian OS andmicrokernel standards, there is a server that protects this repository andmanages access to it. Any application that wants to handle messages insome way must become a client and make requests to the message server.The message server implements two valuable functions.• Access to the message-data repository : as clients request messageaccess, the message server delegates temporary, exclusive accessto message data.
The message server must keep the message datarepository correctly ordered and must cope with anomalous messageevents correctly. For example, access failures or incomplete sessionsmust not corrupt the message data.• Access to MTMs : the message server must enable applications toidentify requests, such as the sending of a message, that requireprotocol-specific functionality and load the appropriate MTM.The message server accepts requests from client applications thatrequire access to messages and MTMs.
These requests are handledasynchronously, as they might require a large amount of time to perform(fax messages, for example, typically take much more time to process thanemail messages). Requests can include changing the structure or contentsof the local folders, sending and receiving messages through differentservices, changing the structure or contents of remote mailboxes, andMTM-specific requests.
Note that actions such as delivery and storageconcepts such as local folders and remote mailboxes are all managed bythe message server.278MESSAGINGThe RootServiceServicefoldersfolders...Servicefoldersmore foldersFigure 13.4 The Symbian OS message model structureStorage and Message StructureThe Symbian OS message store has a specific structure. The diagram inFigure 13.4 shows an overview of this structure.Messages are stored in folders, which are accessed as children ofservices.
A service can be viewed as a message source: an ISP is a service,as is local, on-device storage. Folders can be user-defined or systemdefined; for example, in and out boxes are defined by the system and areapplicable under the local storage service. Folders can have subfolders,which can have subfolders, etc. This hierarchical organization of thestorage structure means that access to messages requires a walk throughthe storage tree before access is granted to a message.Messages themselves also have a structure, shown in the table below:Message ComponentType of dataGeneric message headerMessage-index-entry dataMTM-specific informationMTM-stream dataMessage bodyRich text data in message storeAttachmentsAttachment files stored in themessage’s storeTHE SYMBIAN OS MESSAGING MODEL279Message-index entries have a specific format.
That format is quite largeand we will not reproduce it here. Suffice to say that both delivery andcontent-header information is stored here and that this information variesby MTM. The MTM-stream data is specifically formatted for the type ofMTM that is used for the message. Obviously, this information also variesby MTM. The message body is a formatted object that contains text aswell as formatting information.
Details about attachments are found inthe message header – the index portion – but the data files themselves arestored in their own format in the message store after the message body.Manipulating MessagesTo appreciate the Symbian OS message architecture in motion, let’s takean overview look at what it takes to send and receive messages.To access messages, we must create and manipulate several SymbianOS objects. First, we must create a session with the message server.
Next,we must initialize contact with the message-system registry in such a waythat we can create MTMs later to handle messages. Finally, we access themessage system by walking through the message structure tree: we accessthe system root, then find the message’s service, then the message’s folder(and possibly subfolders), and then we access the message.A session with the message server is initiated by system calls from theclient. Sessions can be opened synchronously or asynchronously.After establishing a server session, the next step is to open the registryso that we can access MTM objects when we need them. There are threekinds of access into the registry: one to access client-side MTMs, one toaccess user-interface MTMs, and one to access user-interface-data MTMs.Each access is implemented by its own class and their own system calls.They are derived from the same base classes and have similar definitions.Once we have a valid message-server session established and we haveaccess to the registry, we can access the message-tree structure.
Let’s lookat the characteristics of an entry in the message tree. An entry includesthe following properties:• an entry ID• the header information• an ‘owning service’, i.e., the parent of an entry• a certain number of children (for the root and inner-tree nodes)• file storage• an MTM list.280MESSAGINGBehind the ScenesStop for a moment and consider what is going on behind the scenesof remote-message transfer. The implementation of this is different fordifferent message types.Consider a session with a remote email server. The local device’s copyand move operations access the server through the existing socket andpass commands to the server through this socket. These operations donot need additional connections as one already exists.Finally there are implementations of different MTMs, which includefunctions that are specific to each MTM and do not generalize to allMTMs.
For example, an email-message MTM that uses POP3 wouldneed functions to connect to and disconnect from the POP3 server. ABIO-message MTM would not need a function to connect to a serverbecause there is no server for BIO messages (they are pushed to a device).On the other hand, a BIO-message MTM needs a function to process theBIO-message content. This applies to SMS and fax messages as well. EachMTM implementation requires its own system calls.The messaging architecture provides a way for MTM components tooffer protocol-specific functionality not provided by base-class-interfacefunctions.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
