MAPI Architecture

Many messaging systems are divided into a client side and a server side. The client side provides an interface to users and permits them to read, save, create, and send mail. The server-side programs carry out the client requests . For example, if a client issues a read request for a certain message, the server responds by transmitting the message to the client. The client software is sometimes referred to as the front end to the server software, which can be referred to as the back end. The front-end programs can be thought of as consumers and the back-end programs as producers .

Note ‚  

Do not confuse the front end and back end of a client/server system with the concept of front-end and back-end servers used in Exchange Server 2003. You can learn more about front-end and back-end servers in Chapter 4, ‚“Creating and Managing Exchange Clusters, ‚½ Chapter 9, ‚“Configuring the Information Store, ‚½ and Chapter 15, ‚“Securing Exchange Server 2003. ‚½

Historically, messaging systems have been implemented using ‚“closed ‚½ application programming interfaces (APIs). An API is a collection of instructions, also called function calls or services. When a user wants to read a message stored on the server, the client program issues the relevant API function call to the system interface, and the server responds accordingly .

The problem with the closed API model is that each model is proprietary, and thus each vendor has its own APIs. When someone wrote a client program to be used with one of these proprietary systems, it worked with only that system. With this architecture, multiple client programs were needed to connect to multiple messaging systems (see Figure 7.3).

Figure 7.3: Multiple client programs for multiple messaging systems

Microsoft decided to remedy this situation by creating a standard messaging architecture known as MAPI. MAPI provides a way for client messaging applications to communicate with multiple messaging systems (see Figure 7.4). Although MAPI is an acronym for Messaging Application Programming Interface, it is much more than an API. It is an architecture that specifies components , how they should act, and how they should interface with each other.

Figure 7.4: A single MAPI application accessing multiple messaging systems

Figure 7.5 illustrates the basic architecture of MAPI. The top layer, the client application layer, includes client applications that enable users to perform messaging activities. These client applications are the front-end programs that request services from the back-end server programs. Client applications can include different messaging services (such as e-mail, fax, voicemail, and paging), as long as they are written to the MAPI specification. The concept of having messages from multiple sources delivered to one place is referred to as the universal inbox .

Figure 7.5: The basic MAPI architecture

Previously, a single client program could not communicate with more than one server program, because the server programs all used different APIs. The MAPI architecture eliminates this limitation by providing a single layer through which the client programs and the server programs can communicate. This is the second layer and is called the MAPI subsystem (see Figure 7.6). The MAPI subsystem is referred to as middleware because it acts as a broker between two other layers .

Figure 7.6: The MAPI subsystem

Server programs can still use their own APIs on the back end. But the vendors of these programs must write a type of client component, called a service provider , that will interface their back-end system with the MAPI subsystem. Service providers constitute the third layer in the MAPI architecture (see Figure 7.7). Client software communicates with the MAPI subsystem, which communicates with a service provider, which communicates with the back-end message server. This is how a single client application, using multiple service providers, communicates with multiple back-end message servers.

Figure 7.7: MAPI service providers

The next sections provide additional details on the MAPI architecture.

Client Application Layer

Client applications that need to perform messaging functions can have those functions implemented through the use of MAPI function calls. Examples of these calls are MAPIReadMail, MAPISaveMail, and MAPISendMail. When these instructions are executed in a client application, they initiate an action in the MAPI subsystem, which then interfaces with service providers, which interface with a server messaging system, such as Microsoft Exchange Server or CompuServe Mail.

MAPI encompasses three major API sets:

Simple MAPI This is a set of 12 straightforward messaging functions, such as reading ( MAPIReadMail ) and sending ( MAPISendMail ) messages. It is included in messaging-aware applications such as Microsoft Word.

Common Mail Call (CMC) This is a set of 10 messaging functions similar to Simple MAPI. CMC is geared for cross-platform, operating system ‚ independent development. CMC was developed by the X.400 Application Programming Interface Association (XAPIA).

MAPI 1. x (also called Extended MAPI) This is the newer , more powerful MAPI standard. It includes the abilities of Simple MAPI but adds many other instructions for complex messaging functions, such as custom forms as the CDO Library API.

See Figure 7.8 for a depiction of these three APIs in the MAPI architecture.

Figure 7.8: The three MAPI API sets

These three API sets allow developers to create client messaging applications that fall into two broad categories:

Messaging-aware applications These are applications such as Microsoft Word that have some messaging functions included, such as a Send option on the File menu. Messaging is not essential to these applications. Simple MAPI or CMC is most conveniently used as the messaging API.

Messaging-based or messaging-enabled applications These are applications such as Microsoft Outlook that require messaging functionality. The comprehensive function call set of Extended MAPI is normally required to implement these applications.

MAPI Subsystem

The second layer of the MAPI architecture is the MAPI subsystem (see Figure 7.9). This component is shared by all applications that require its services and is therefore considered a subsystem of the operating system. Microsoft includes the MAPI subsystem with the 32-bit Windows 98, Me, NT, 2000, XP, and Server 2003 operating systems, and the file MAPI32.DLL is the primary function library for these operating systems. The MAPI subsystem for 16-bit Windows 3. x is loaded with the installation of the Exchange client, and the file MAPI.DLL is the primary function library.

Figure 7.9: MAPI subsystem

Note ‚  

The MAPI subsystem is also referred to as the MAPI runtime .

The MAPI subsystem provides a single interface for client applications. Communication with all MAPI-compliant server messaging systems is facilitated by interfacing with the MAPI sub-system . It is the middleware, or broker, in the messaging environment. The subsystem manages memory, administers profiles, routes client requests to the relevant service provider, and returns results from servers via service providers.

The MAPI subsystem also presents a single, virtual address book and a single, virtual storage area to the user. As you will learn in the next section, multiple service providers can create multiple address books and multiple message stores. The MAPI subsystem presents all of these through a unified interface. Consequently, even though both an e-mail program and a fax program are being used, the user can view all addresses in one virtual address book. Because all data can be kept in the same virtual storage area, users can organize information based upon logical categories (e.g., all communication from Jane) rather than by application (e.g., e-mail directory, fax directory, etc.).

MAPI Service Providers

The MAPI architecture ‚ s third layer contains components called service providers. These replaceable components (manifested as DLL files) communicate with the messaging system back end. There are three main types of service providers:

• Address book providers

• Message store providers

• Message transport providers

The following three sections discuss these service providers.

Note ‚  

A provider is sometimes called a driver .

Address Book Providers

An address book provider is a component that interacts with a database of message recipients. Some of these providers create their own address databases, called personal address books (PABs); others can access address books on a server. Address book providers can be written for many kinds of back-end systems, and because they all interface with the MAPI subsystem, a user can still have a single, virtual address book.

The following are three examples of address book providers:

Global Address List (GAL) This provider enables a client application to view an Exchange server ‚ s Global Address List (GAL). The GAL is a database of all the recipients in an Exchange organization, such as mailboxes, distribution lists, custom recipients, and public folders. The file extension of this address book is usually .gal .

Personal Address Book This provider, also called the Local Address Book, enables the creation of a customized address book. Users can include frequently used e-mail addresses, as well as custom recipients and distribution lists that the user creates. Message recipients are not the only type of information that can be stored. Phone and fax numbers , postal addresses, and other information can be stored here. This address book can be stored on the user ‚ s machine or on a server. The file extension of this address book is usually .pab .

Offline Address Book (OAB) This address book provider permits an Exchange server ‚ s GAL to be downloaded to a user ‚ s machine. This can be useful when working offline. The file extension of this local database is usually .oab .

See Figure 7.10 for a depiction of the address book providers in the MAPI architecture.

Figure 7.10: Address book providers

Message Store Providers

Message store providers are components that manage a database of messages. This entails client message storage, organization, and submission for sending and retrieving messages and attachments. Storage is organized in a hierarchical tree of folders. Views can be created to allow the user to see messages based on certain criteria, such as subject or date. Searches can also be conducted to retrieve specific information.

Message store providers can use server-based storage or client-based storage. Following are four examples of message store providers (see Figure 7.11):

Figure 7.11: Message store providers

Private folders This provider enables client access to an assigned mailbox on an Exchange server (i.e., the home server of the mailbox). The term private folders is another name for what are more commonly referred to as mailboxes. They are called ‚“private ‚½ because, more often than not, they are associated with a single user (even though several users can be given permission to use a single mailbox). All private folders are stored on an Exchange server in the Private Information Store, which is managed by the Information Store service. The advantages of this type of storage are compression, security, and centralized backup.

Public folders Public folders are the groupware component of Exchange Server. This provider allows a client to access the hierarchical tree of public folder storage to which everyone in the Exchange organization has access. Public folders are stored on Exchange servers in the Public Information Store, which is managed by the Information Store service.

Personal folders (PST, Personal Store) A personal folder store is a file-based storage container independent of the Exchange Server back end. The file that is composed of a set of personal folders has the .pst extension. A PST file can be stored on the user ‚ s local machine or on a shared directory on a network server. As with private folders, a user can create a hierarchical tree of folders within a personal folder store. In previous versions of Outlook, you were limited to 2 GB in size for PST files and the PST files themselves were stored in the American National Standards Institute (ANSI) format. Outlook 2003 now uses the Unicode format by default, thus allowing for PST files that can grow to 20 GB and beyond in size. Versions of Outlook previous to Outlook 2003 cannot use these new, larger PST files, however.

Personal folder stores can be assigned a password for protection. Personal folders can also be designated as the location to where incoming mail messages are moved. Although all mail is always first sent to private folders on an Exchange server, users can configure their private folders to route messages to their personal folders. Because of storage technologies used in the Private Information Store, information moved from that location to a personal folder would take up more space in the personal folder. Note also that moving information to personal folders may make backing up more complicated than if everything were stored on a server. Of course, personal folders can also be stored on a server that is included in regular backups .

Note ‚  

Passwords assigned to a personal folder cannot be viewed by the Exchange administrator. Therefore, if a user forgets this password, the information in that folder is inaccessible using tools provided in System Manager or Outlook. However, there are a number of third-party utilities that are usually able to crack personal folder and other application passwords.

Offline folders (OST, Offline Store) If mailbox storage is left in the default location (the Private Information Store) and offline access to that data is also needed, the user can utilize offline folders . An offline folder is a local copy of the user ‚ s private folders in the Private Information Store. The mailbox on the server remains the master copy. Offline folders have the . ost file extension.

Message Transport Providers

Message transport providers manage the physical transportation of messages between a MAPI client and a back-end system (see Figure 7.12). Like gateway components, they take a MAPI message, translate it to the format of the back-end system, and send it. They do the reverse for incoming messages. Message transport providers work with any of the Microsoft-supported network protocols, such as TCP/IP, IPX/SPX, and NetBEUI.

Figure 7.12: Message transport providers

The following are examples of back-end systems that have message transport providers:

• Microsoft Exchange Server

• Microsoft Network online service (MSN)

• Microsoft Fax

• Microsoft Mail

• Internet Mail CompuServe Mail

Message Spooler

The message spooler (also referred to as the MAPI spooler) is an independent process that manages the flow of messages between the message store and the transport providers. It is like a queue where incoming and outgoing messages are sent and from there are routed to the necessary providers. When a message is marked for sending, a message store provider will send it to the message spooler. The message spooler then selects, based on the destination address, a message transport provider that can send the message to the relevant messaging system.

Messaging Profiles

A messaging profile is a collection of configuration parameters for MAPI operations. The first time a user starts a MAPI-based application, the Profile Wizard runs and prompts for various operational parameters related to messaging. For example, the user is prompted to choose the information services to be used, such as Microsoft Exchange Server, Microsoft Fax, Internet Mail, and others. Information services are collections of the various providers described earlier. The user is also prompted to configure his personal address book information service. Other information in the profile relates to message handling, such as saving sent mail or generating a delivery receipt. When the MAPI subsystem starts, it reads this profile to see which services to load and how to operate (see Figure 7.13).

Figure 7.13: Messaging profile

A user can have several profiles for one particular machine. For example, a user ‚ s computer might be a laptop that is used both at the office and on the road. When the user is at the office, the user profile connects the user to an Exchange server at the office. When the user is traveling, a different profile connects the laptop to the Internet. Multiple profiles for a particular machine are also useful when several people use the same machine.

Common Features of MAPI-Based Applications

Many common features are found in MAPI-based applications, including the following:

Universal Inbox Information from multiple sources (e.g., Exchange Server, Internet, etc.) and of varying types (e.g., e-mail, faxes, documents, and voicemail) is delivered to a single Inbox folder.

Single address book A standard user interface to the address book is provided. Information from all the address books configured in the current profile is consolidated in one place.

Hierarchical storage Messages and other items can be organized into a user-customizable hierarchical tree of folders. Four special folders are always present in the default store. They are the Inbox, Deleted Items, Sent Items, and Outbox folders.

Custom views Information stored in folders can be sorted and viewed using many types of criteria, such as author, date, keyword, or type of content.

Rich-text formatting Users can create message content that uses the rich-text format, which includes underlining, italic, bolding, bullet points, colors, fonts, different character sizes, and letter strikethrough .