ch4.htm

MAPI__SAPI__TAPI

  <tr>
    <td><b>Note</b></td>
  </tr>
  <tr>
    <td><blockquote>
      <p>Message types are stored as part of the address. These types were discussed earlier in 
      this chapter in the &quot;Addresses&quot; section.</p>
    </blockquote>
    </td>
  </tr>
</table>
</center></div>

<p>Figure 4.6 shows how the multiple message transports are used when messages are 
received by the MAPI Client. </p>

<p><a HREF="f4-6.gif">Figure 4.6 : Handling incoming messages with multiple message 
transports.</a> </p>

<p>Under the MAPI system, message transports provide another vital service. It is the 
responsibility of the message transport to enforce any security features required by the 
message format. For example, the MSN mail transport is responsible for prompting the user 
for a username and password before attempting to link with the MSN mail system. </p>

<p>It is important to note that the message transport is not responsible for storing the 
messages that have been received. The transport is only in charge of moving messages from 
one location to another. Message storage is discussed in the next section. </p>

<h3><a NAME="MessageStores">Message Stores</a></h3>

<p>Message stores are responsible for providing the filing system for the messages 
received via the message transport. The MAPI model dictates that the message store must be 
in a hierarchical format that allows multilevel storage. In other words, the system must 
allow users to create folders to hold messages, and these folders must also be able to 
hold other folders that hold messages. Under the MAPI model, there is no limit to the 
number of folder levels that can be defined for a message store (see Figure 4.7). </p>

<p><a HREF="f4-7.gif"><b>Figure 4.7 : </b><i>MAPI message stores are hierarchical filing 
systems.</i></a> </p>

<p>Under the MAPI model, storage folders can have properties that control how they are 
used and how they behave. For example, storage folders can be public or private. Folders 
can have properties that make the contained messages read-only to prevent modification. 
The options available depend on the implementation of the message store. In other words, 
the programmer who designs the message store can establish the scope of storage options 
and the MAPI Client will comply with those rules. </p>

<p>As in the case with message transports, MAPI clients can access more than one message 
store. Figure 4.8 shows the Windows Messaging Client that is currently accessing two 
different message stores. You can see that each store has its own set of folders and its 
own set of messages. </p>

<p><a HREF="f4-8.gif"><b>Figure 4.8 : </b><i>Accessing multiple message stores at the same 
time.</i></a> </p>

<p>The Windows Messaging Client that ships with Microsoft Exchange Server also allows you 
to create folder column, grouping, sort, and filter rules for personal and public folders. 
By doing this, you can create storage views that reflect the course of an ongoing 
discussion and allow for easy search and retrieval of data kept in the message store (see 
Figure 4.9). </p>

<p><a HREF="f4-9.gif"><b>Figure 4.9 : </b><i>A Microsoft Exchange folder with discussion 
properties.</i></a> </p>

<h3><a NAME="AddressBooks">Address Books</a></h3>

<p>The last of the main MAPI server objects is the <i>address book</i>. The MAPI address 
book contains all the directory information about a particular addressee. The book can 
contain data for individual users or groups of users (a distribution list). The minimum 
data stored in the address book is the user's display name, the transport type, and the 
user's e-mail address. </p>

<p>Additional information such as mailing address, telephone number, and other data may be 
available depending on the design of the address book. </p>

<p>Address books, like the other objects described in this chapter, work independently 
under the MAPI model. Also, the MAPI client can access more than one address book at a 
time. This means that several address books of various formats can all be viewed (and 
used) at the same time when composing messages (see Figure 4.10). </p>

<p><a HREF="f4-10.gif"><b>Figure 4.10 : </b><i>Accessing multiple address books at the 
same time.</i></a> </p>

<p>Along with storing addresses, the address book interface also acts to resolve display 
names used in the MAPI interface with the actual e-mail addresses and transport types for 
those display names. To do this, MAPI offers a ResolveName service that performs lookups 
upon request. The ResolveName service is able to look at all address books (regardless of 
their storage format) in order to locate the proper e-mail address. </p>

<p>Users are also able to designate one of the address books as the default or <i>personal</i> 
address book. This is the first address book in which new addresses are stored and the 
first address book that is checked when resolving a display name. The Windows Messaging 
Client and the Microsoft Mail client both ship with default personal address books. The 
Windows Messaging Client allows users to add new address books and designate their own 
personal address book container. </p>

<h2><a NAME="TheMAPISpooler"><font SIZE="5" COLOR="#FF0000">The MAPI Spooler</font></a></h2>

<p>The MAPI Spooler is a special process that interacts with both message stores and 
message transports. It is the spooler's job to route messages from the client to the 
proper transport and from the transport to the client. The spooler is the direct link 
between the client and the transport. All messages go through the MAPI Spooler. </p>
<div align="center"><center>

<table BORDERCOLOR="#000000" BORDER="1" WIDTH="80%">
  <tr>
    <td><b>Note</b></td>
  </tr>
  <tr>
    <td><blockquote>
      <p>Actually there are some cases in which a message moves directly from the message store 
      to the message transport. This occurs when service providers offer both message store and 
      message transport. E-mail service providers that offer these features are known as <i>tightly 
      coupled</i> service providers. </p>
    </blockquote>
    </td>
  </tr>
</table>
</center></div>

<p>Figure 4.11 illustrates the different paths messages can take when the MAPI Spooler is 
used. </p>

<p><a HREF="f4-11.gif"><b>Figure 4.11 : </b><i>The MAPI Spooler passes messages between 
the message store and the message transport.</i></a> </p>

<p>As each message is moved from the message store (the &quot;outbox&quot;) to the 
transport, the MAPI Spooler checks the address type to see which transport should be used. 
Once this is determined, the spooler notifies the transport and attempts to pass the 
message from the message store to the message transport. If the transport is not currently 
available, the MAPI Spooler holds onto the message until the transport is free to accept 
messages. This allows transport providers to act as remote connections without any 
additional programming or addressing on the client side. </p>
<div align="center"><center>

<table BORDERCOLOR="#000000" BORDER="1" WIDTH="80%">
  <tr>
    <td><b>Note</b></td>
  </tr>
  <tr>
    <td><blockquote>
      <p>In fact, the implementation used in the Microsoft Exchange version of MAPI treats all 
      connections as if they were remote-even when the message is moved from one user's 
      Microsoft Exchange outbox to another Microsoft Exchange user's inbox on the same network.</p>
    </blockquote>
    </td>
  </tr>
</table>
</center></div>

<p>In the case of messages that move along a constantly connected transport (that is, 
between two addresses on the same Microsoft Exchange Server), the spooler notifies the 
transport (Microsoft Exchange) and the transport accepts the message almost immediately. 
Often the user is not aware of any delay in the handling of the message. </p>

<p>In the case of messages that move from the Windows Messaging Client by way of an SMTP 
transport through a dial-up connection to the Internet, the MAPI Spooler holds onto the 
message until the user connects to the Internet account through Win95 Dial-Up Networking. 
Once the connection is made, the MAPI Spooler sends all local messages on to the Internet 
mail server, retrieves any waiting mail from the mail server, and passes these new 
messages to the appropriate message store. </p>

<p>The MAPI Spooler is also able to move a single message to several recipients when some 
of those recipients are not using the same message transport. For example, users can build 
distribution lists that contain names of users on the local Microsoft Exchange Server, 
users who have addresses on a local Microsoft Mail Server, and users who can only be 
contacted through a fax address. When the message is sent, it moves from the message store 
to the spooler, which then sorts out all the transports needed and passes the messages on 
to the correct transports at the first available moment. </p>

<p>The MAPI Spooler is also responsible for marking messages as read or unread, notifying 
the sender when a message has been successfully passed to the transport, and, when 
requested, notifying the sender when the recipient has received (or read) the message. The 
MAPI Spooler also reports when messages cannot be sent due to unavailable transports or 
other problems. </p>

<h2><a NAME="Summary"><font SIZE="5" COLOR="#FF0000">Summary</font></a> </h2>

<p>In this chapter, you learned about the general architecture of the MAPI system. You 
learned that there are two main components to the system: 

<ul>
  <li><font COLOR="#000000">The MAPI Client</font> </li>
  <li><font COLOR="#000000">The MAPI Server</font> </li>
</ul>

<p>You learned that the MAPI Client resides on the user's desktop and handles three main 
MAPI objects: 

<ul>
  <li><font COLOR="#000000">Messages and attachments</font> </li>
  <li><font COLOR="#000000">Storage folders</font> </li>
  <li><font COLOR="#000000">MAPI addresses</font> </li>
</ul>

<p>This chapter also reviewed the basic properties and features of MAPI messages, 
including message headers, folders, and address objects. </p>

<p>You learned that the MAPI Server usually resides on a standalone workstation connected 
to the network (although not always). Like the MAPI Client, the MAPI Server handles three 
main objects: 

<ul>
  <li><font COLOR="#000000">Message transports</font> </li>
  <li><font COLOR="#000000">Message stores</font> </li>
  <li><font COLOR="#000000">Address books</font> </li>
</ul>

<p>You learned that the MAPI model allows users to use multiple versions of message 
transports (such as Microsoft Exchange Server messages and SMTP Internet messages), 
message storage, and address books. You also learned about the MAPI Spooler. The MAPI 
Spooler is the process that moves items from the message store to the appropriate 
provider. </p>

<p>Now that you know the basic architecture of the MAPI system, it's time to build some 
applications that use the system. In the next chapter, you'll learn how to use the 
Microsoft Exchange Forms Designer to build MAPI-enabled applications that work within the 
Microsoft Exchange interface. </p>

<hr WIDTH="100%">

<p align="center"><a HREF="ch3.htm"><img SRC="pc.gif" BORDER="0" HEIGHT="88" WIDTH="140"></a><a
HREF="#CONTENTS"><img SRC="cc.gif" BORDER="0" HEIGHT="88" WIDTH="140"></a><a
HREF="index.htm"><img SRC="hb.gif" BORDER="0" HEIGHT="88" WIDTH="140"></a><a
HREF="ch5.htm"><img SRC="nc.gif" BORDER="0" HEIGHT="88" WIDTH="140"></a></p>

<hr WIDTH="100%">
<layer src="http://www.spidersoft.com/ads/bwz468_60.htm" visibility="hidden" id="a1" width="600" onload="moveToAbsolute(ad1.pageX,ad1.pageY); a1.clip.height=60;visibility='show';">
</layer>
</body>
</html>