📄 ch3.htm
字号:
<HTML>
<HEAD>
<TITLE>Chapter 3 -- What is MAPI</TITLE>
<META NAME="GENERATOR" CONTENT="Mozilla/3.0b5aGold (WinNT; I) [Netscape]">
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#CE2910">
<!-- Spidersoft WebZIP Ad Banner Insert -->
<TABLE width=100% border="0" cellpadding="0" cellspacing="0">
<TR>
<TD>
<ILAYER id=ad1 visibility=hidden height=60></ILAYER>
<NOLAYER>
<IFRAME SRC="http://www.spidersoft.com/ads/bwz468_60.htm" width="100%" height="60" marginwidth=0 marginheight=0 hspace=0 vspace=0 frameborder=0 scrolling=no></IFRAME>
</NOLAYER>
</TD>
</TR>
</TABLE>
<!-- End of Spidersoft WebZIP Ad Banner Insert-->
<H1><FONT COLOR=#FF0000>Chapter 3</FONT></H1>
<H1><B><FONT SIZE=5 COLOR=#FF0000>What is MAPI</FONT></B>
</H1>
<P>
<HR WIDTH="100%"></P>
<P>
<H3 ALIGN=CENTER><FONT COLOR="#000000"><FONT SIZE=+2>CONTENTS<A NAME="CONTENTS"></A>
</FONT></FONT></H3>
<UL>
<LI><A HREF="#MAPIServicesandWindows" >MAPI Services and Windows</A>
<UL>
<LI><A HREF="#Flexibility" >Flexibility </A>
<LI><A HREF="#Consistency" >Consistency</A>
<LI><A HREF="#Portability" >Portability</A>
</UL>
<LI><A HREF="#Messages" >Messages</A>
<UL>
<LI><A HREF="#TextMessages" >Text Messages</A>
<LI><A HREF="#FormattedDocumentsandBinaryFiles" >Formatted Documents and Binary Files</A>
<LI><A HREF="#ControlMessages" >Control Messages</A>
</UL>
<LI><A HREF="#MAPIApplications" >MAPI Applications</A>
<UL>
<LI><A HREF="#ElectronicMailClients" >Electronic Mail Clients</A>
<LI><A HREF="#MessageAwareApplications" >Message-Aware Applications</A>
<LI><A HREF="#MessageEnabledApplications" >Message-Enabled Applications</A>
<LI><A HREF="#OtherTypesofMessageApplications" >Other Types of Message Applications</A>
</UL>
<LI><A HREF="#Summary" >Summary</A>
</UL>
<HR>
<P>
Before getting into the details of how the Messaging Application
Programming Interface (MAPI) works and how to write MAPI applications,
we'll take a moment to review the general architecture of Microsoft's
messaging API and how this set of message services fits into the
overall Windows operating system. As you will see a bit later
in this chapter, MAPI is more than a handful of e-mail APIs-it
is a defined set of message services available to all programs
that run in the Windows operating environment.
<P>
We'll also discuss the various kinds of applications and message
types commonly used under MAPI services. In this chapter, you'll
learn about the three general types of MAPI messages: text messages,
formatted documents and binary files, and control messages. Each
of these message types has a distinct set of properties and uses
within the MAPI framework. This chapter describes each of the
message types and shows how you can use them within the MAPI architecture.
<P>
There are also three common types of MAPI applications: electronic
mail clients, message-aware applications, and message-enabled
applications. Each of these application types is defined and illustrated
in this chapter. You'll also learn the relative strengths of each
type of MAPI application.
<H2><A NAME="MAPIServicesandWindows"><FONT SIZE=5 COLOR=#FF0000>MAPI
Services and Windows</FONT></A></H2>
<P>
The MAPI service set is more than a set of API commands and functions
that you can use to send e-mail from point to point. The MAPI
interface is actually a carefully defined set of messaging services
available to all Windows programs. This pre-defined set has three
key attributes:
<UL>
<LI><FONT COLOR=#000000>Flexibility </FONT>
<LI><FONT COLOR=#000000>Consistency </FONT>
<LI><FONT COLOR=#000000>Portability </FONT>
</UL>
<P>
Because the MAPI service set contains these three characteristics,
it has become the <I>de facto</I> messaging interface standard
for Windows applications.
<P>
Access to MAPI services is the same for all versions of the Windows
operating system. But even though your Windows programs use the
same methods for accessing MAPI services, MAPI services can vary
from system to system. Also, MAPI architecture allows software
designers to create their own service providers (SPs) to support
the MAPI service set.
<P>
These services are also available within all existing flavors
of the Windows operating system. Even more important, the methods
of access to these message services is the same, regardless of
the version of Windows you are working with. This means that programs
using MAPI services that were written under Windows 3.1 will still
be able to access those same MAPI services under Windows 95.
<H3><A NAME="Flexibility">Flexibility</A></H3>
<P>
Probably the most important aspect of the MAPI service architecture
is its flexibility. Microsoft has implemented MAPI within the
Windows Open Systems Architecture (WOSA). This architecture is
designed to allow customization at both the client (user) side
and the server (provider) side. In other words, you can use MAPI
not only to create your own end-user software to read, write,
create, and send messages, but also to construct custom server-side
software to store and transport those same messages. As part of
the WOSA model, MAPI services are implemented in a tiered format
(see Figure 3.1).
<P>
<A HREF="f3-1.gif" ><B>Figure 3.1 : </B><I>The tiered implementation of MAPI services.</I></A>
<P>
The first layer is the <I>client</I> layer. This is what the end-user
most often sees. At this level a set of well-defined services
are available. These services are accessed when the client layer
makes a service request to the second layer-the <I>MAPI DLL</I>.
The MAPI DLL takes the service request from the client and forwards
it on to the third layer in the tier-the s<I>ervice provider</I>.
The service provider is responsible for fulfilling the client
request and sending the results of that request back to the DLL
where it is then forwarded to the client that made the initial
request. Throughout the process, the DLL layer acts as a broker
between the client side and the server side.
<P>
The primary advantage of this layered implementation is the ease
with which users can interchange client and server components.
Since the only constant required in the mix is the DLL layer,
any client can be matched with any server component to provide
a working message service. It is very common to switch client-side
components in a messaging service. Each e-mail reader is a MAPI
client application. Any application that sports a send button
is actually a MAPI client. Any specialized program written to
manipulate messages at the end-user level is a MAPI client.
<P>
While interchanging MAPI clients is rather commonplace, interchanging
MAPI service providers is not. In a network environment, a single
service provider will usually be designated as the default provider
of MAPI services. It is no longer rare to have several MAPI service
providers available at the same time, however. In fact, the Microsoft
Mail Exchange client that ships with Windows 95 is specifically
designed to be able to access more than one service provider.
It is possible to use the Windows Exchange client to access messages
via Microsoft Mail Server, Microsoft FAX, or through the Microsoft
Network (MSN). You can even install third-party service providers
into the Exchange client (such as the one provided by CompuServe)
to access messages stored in other mail systems (see Figure 3.2).
<P>
<A HREF="f3-2.gif" ><B>Figure 3.2 : </B><I>Microsoft Exchange can link to multiple service providers.</I></A>
<H3><A NAME="Consistency">Consistency</A></H3>
<P>
The MAPI service set contains a set of services that encompasses
all the basic messaging tasks:
<UL>
<LI><FONT COLOR=#000000>Message service logon and logoff</FONT>
<LI><FONT COLOR=#000000>Reading, creating, and deleting text messages</FONT>
<LI><FONT COLOR=#000000>Adding and deleting message binary file
attachments</FONT>
<LI><FONT COLOR=#000000>Addressing and transporting the completed
messages</FONT>
</UL>
<P>
The exact behavior and properties of each of these services are
defined as part of MAPI. All vendors who supply a MAPI-compliant
set of tools provide these services in the exact same manner.
This way, any program that uses MAPI services can be assured that
there are no special API variations to deal with when moving from
one vendor's MAPI product to another. This means the programs
you write today using your current implementation of MAPI services
will function under other implementations of the MAPI service
set (see Figure 3.3).
<P>
<A HREF="f3-3.gif" ><B>Figure 3.3 : </B><I>Consistency of MAPI services across vendor implementations.</I></A>
<H3><A NAME="Portability">Portability</A></H3>
<P>
This leads to the second strength of Microsoft's MAPI service
set-portability. Microsoft supports MAPI services on all versions
of its Windows operating systems. If you write a program for the
Windows 3.1 version of MAPI services, that same program can still
access the MAPI services under any other version of Windows that
supports your executable program. This is a key issue when you
consider how many versions of Windows are currently in use and
how quickly new versions of the operating system are developed
and deployed.
<P>
Not only will you be able to move your MAPI-related programs to
various Windows platforms, you can also allow programs to access
MAPI services from more than one platform at once. In other words,
users of more than one version of Windows can all be accessing
MAPI services from a central location at the same time (see Figure
3.4).
<P>
<A HREF="f3-4.gif" ><B>Figure 3.4 : </B><I>Portability of MAPI across Windows platforms.</I></A>
<P>
Microsoft has announced plans to move several of its service sets
(MAPI included) beyond the Windows operating environment, too.
As this happens, Microsoft has pledged that the same set of functions
and routines used under the Windows environment will be available
in other operating systems.
<H2><A NAME="Messages"><FONT SIZE=5 COLOR=#FF0000>Messages</FONT></A>
</H2>
<P>
The primary role of the MAPI service is to transport and store
messages. This section identifies three common message types supported
by MAPI services:
<UL>
<LI><FONT COLOR=#000000>Text messages</FONT>
<LI><FONT COLOR=#000000>Formatted documents or binary files</FONT>
<LI><FONT COLOR=#000000>Control messages</FONT>
</UL>
<P>
The most basic message form is the text message, commonly thought
of as e-mail. Most electronic message systems also support the
second type of message-formatted documents or binary files. These
are usually included as attachments to a text message.
<P>
The third message type is a <I>control message</I>. Control messages
are usually used by the operating system to pass vital information
such as system faults, potential failure conditions, or some other
type of status information. Control messages can also be passed
between programs in order to implement a level of distributed
processing in a computer network.
<P>
The following sections review each message type in more detail.
<H3><A NAME="TextMessages">Text Messages</A></H3>
<P>
The text message is the most common MAPI message. In fact, all
MAPI messages have a default text message component. A text message
contains the letters and words composed by users to communicate
with other message system users.
<P>
All MAPI service providers must supply a simple text message editor
as part of their MAPI implementation. All MAPI message providers
support plain ASCII text characters as a message body. Many also
support rich-text messages that contain formatting characters
such as font and color. The Microsoft Mail client supplied for
Windows 3.11 and Windows for Workgroups supports plain ASCII text.
The Microsoft Mail Exchange client supplied for Windows 95 supports
rich-text formatting.
<H3><A NAME="FormattedDocumentsandBinaryFiles">Formatted Documents
and Binary Files</A></H3>
<P>
The second MAPI message type is the formatted document or binary
file, which is usually a file containing non-printable characters
such as a spreadsheet, a word-processing file, graphics, or even
an executable program. Binary files are supported by MAPI services
as attachments to text messages. The MAPI service set allows multiple
attachments to a single text message. This means you can send
several binary files to the same e-mail address using a single
message body.
<P>
All MAPI service providers support the use of binary attachments
to a message body. However, the transport of binary attachments
across multiple message servers may not be supported. For example,
if you compose a message that contains attached binary files,
address it to an associate at a distant location, and attempt
to send the message using a service provider that supports only
Simple Mail Transfer Protocol (SMTP) format, your attached binary
files will not be successfully transported to the recipient.
<H3><A NAME="ControlMessages">Control Messages</A></H3>
<P>
The third type of MAPI message is the control message. Control
messages are usually used by the operating system to deliver system
status information, such as a component failure or other system-related
problem. These messages are usually addressed directly to the
system administrator.
<P>
Control messages can also be used to pass data or other control
information between programs. Control messages of this type can
contain requests for information that is to be collected by one
program and returned to another for further processing. Or the
control message can contain actual data to be manipulated by another
program. Since MAPI services can stretch across the LAN or across
the globe, control messages can be passed to systems halfway around
the globe as easily as to systems across the room.
<P>
It is possible to designate one or more workstations on a network
as <I>batch job</I> computers. These machines wait for control
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -