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.
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.
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.
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:
Because the MAPI service set contains these three characteristics, it has become the de facto messaging interface standard for Windows applications.
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.
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.
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).
Figure 3.1 : The tiered implementation of MAPI services.
The first layer is the client 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 MAPI DLL. The MAPI DLL takes the service request from the client and forwards it on to the third layer in the tier-the service provider. 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.
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.
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).
Figure 3.2 : Microsoft Exchange can link to multiple service providers.
The MAPI service set contains a set of services that encompasses all the basic messaging tasks:
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).
Figure 3.3 : Consistency of MAPI services across vendor implementations.
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.
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).
Figure 3.4 : Portability of MAPI across Windows platforms.
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.
The primary role of the MAPI service is to transport and store messages. This section identifies three common message types supported by MAPI services:
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.
The third message type is a control message. 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.
The following sections review each message type in more detail.
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.
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.
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.
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.
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.
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.
It is possible to designate one or more workstations on a network as batch job computers. These machines wait for control messages that direct them to perform time-consuming tasks, such as extended database searches or generating long reports, thus freeing up users' workstations for more immediate business. Once the task is complete, the batch job machine can send a completion notice via e-mail to the user who sent the original request. While it is true that OLE Automation servers are beginning to replace batch job computers that are controlled by MAPI messages, MAPI services are still a very powerful alternative.
Just as there are three types of MAPI messages, there are three general types of MAPI applications:
Electronic mail (e-mail) clients are the most common form of MAPI application. An e-mail client allows end-users direct access to the MAPI services supported by the back-end service provider. Figure 3.5 shows the Microsoft Exchange electronic mail client.
Figure 3.5 : The Microsoft Exchange Mail Client.
Typical services provided by a MAPI e-mail client include
Electronic mail clients can also provide additional services to make it easy to manipulate, store, and retrieve text messages and binary file attachments. Electronic mail clients may also have additional features for addressing and transporting messages, including the use of defined mailing lists and the capability to address messages as cc (courtesy copies) or Bcc (blind courtesy copies).
Message-aware applications are non-MAPI programs that allow users access to MAPI services. Typically, this access is implemented through the addition of a send option in a menu or button bar. Figure 3.6 shows the Microsoft Word 95 main menu with the Send menu item highlighted.
Figure 3.6 : Microsoft Word 95 is a message-aware application.
Message-aware applications usually treat e-mail services just like any other storage or output location, such as disk drives, printers, or modems. In these cases, the ability to send the standard output as an electronic mail message is an added feature for the application. As MAPI services become a standard part of the Windows operating system, message-aware applications will become the norm instead of the exception.
The last category of MAPI applications is message-enabled applications. Message-enabled applications are programs that offer message services as a fundamental feature. While message-aware applications provide message services as an additional feature and can operate well without them, message-enabled applications are specifically designed to use message services and most will not run properly unless message services are available on the workstation.
Here are some examples of message-enabled applications:
It is important to note that, in some cases, users of message-enabled applications may not even be aware that they are using the e-mail system as part of their application. MAPI services define properties and methods for logging users in and out of the message server without using on-screen prompts. MAPI also provides options for addressing and sending messages without the use of on-screen prompts or user confirmation. By using these features of MAPI services, you can design a program that starts a message session, reads mail, composes replies, addresses the new mail, and sends it to the addressee without ever asking the user for input.
There are two more types of message-enabled applications that deserve comment here. These two application types are
Electronic forms applications display a data entry screen that contains one or more data fields for the user to complete. These data fields act as full-fledged windows controls and can support all the events normally supported by Windows data entry forms. Once the form is completed, the data, along with additional control information, is sent to the addressee through MAPI services. When the addressee opens the new mail, the same formatted data entry form appears with the fields filled in (see Figure 3.7).
Figure 3.7 : The filled-in electronic form.
The message-driven application looks for data contained in a message and acts based on the data it finds. Message-driven applications can use any aspect of the message as control information for taking action. Message-driven applications can inspect the message body or subject line for important words or phrases, check the sender's name or the date and time the message was sent, or even scan attachments for important data. These applications can then use the data to forward messages to another person automatically, to set alerts to notify the user of important messages, or to start other programs or processes at the workstation.
Below are some examples of message-driven applications:
Filtering agents, remote update routines, and long-distance search tools are all examples of how MAPI services can be used to extend the reach of the local workstation to resources at far-away locations. The Windows MAPI services provide excellent tools for building programs that enable users to collect and/or disseminate data over long distances or to multiple locations. The next several chapters will explore the details of MAPI architecture, teach you how to incorporate MAPI services into your programs, and show you examples of real-life programs that take advantage of Windows MAPI services.
In this chapter, you learned that the Messaging Application Programming Interface (MAPI) is a part of the Windows Open Systems Architecture (WOSA) model. MAPI is designed to offer three key benefits over other messaging services:
You also learned the three general types of MAPI messages:
Finally, you learned about the various types of MAPI applications. These application types are
Two more application types reviewed in this chapter are
Now that you know the common types of MAPI messages and applications, it's time to review the details of MAPI architecture. That is the subject of the next chapter.