Microsoft's MAPI, with wide industry support, is set to be the desktop messaging standard
Tom Sheldon
If the Earth is ever conquered by aliens, we may be forced to adopt their technology standards. That will be a relief for network administrators, who are trying to figure out what direction they should take with messaging systems. In the meantime, Microsoft's MAPI (Messaging API) appears poised to make Chicago a universal E-mail client, allowing potentially any Windows application to interoperate with a variety of back-end mail systems.
E-mail and messaging in general are critically important to enterprise computing. The Electronic Messaging Association predicts that the number of E-mail users will triple in 1995, with 25 million users sending 15 billion messages a year. Messaging goes we
ll beyond the exchange of E-mail. It is a key component of groupware and work-flow applications, which allows applications to exchange information automatically. For example, the approval of a sales order by a manager might initiate a forms-routing sequence over the network. Messaging also provides a way to get information from database systems. A remote user might request information from a system with an E-mail message and receive a reply in his or her mailbox.
MAPI solves a critical problem for developers by separating the messaging requirements of applications from messaging services with an intermediary layer called the MAPI subsystem. Windows applications can use MAPI calls through the subsystem to interact with any MAPI-compliant messaging system. MAPI eliminates the need of the client application to know how a particular messaging system provides services. Companies can use MAPI to build on existing messaging systems or install new ones.
MAPI is part of Microsoft's WOSA (Windows Open Ser
vices Architecture), which Microsoft calls ``a blueprint to establish Windows workstations as universal clients that fit seamlessly into heterogeneous corporate computing environments.'' WOSA extends the Windows API set to give desktop applications access to many types of back-end services. The other components of WOSA include ODBC (Open Database Connectivity), as well as network file services, print services, and licensing services.
By providing transport independence, MAPI lets organizations continue to use their existing messaging services while migrating users to Windows-based messaging applications. With MAPI and Chicago, you can integrate a diversity of messaging applications on the desktop. Through Chicago's Info Center, for example, you can potentially access E-mail, faxing, voice mail, BBSes, and on-line information services like CompuServe. In fact, a single inbox can serve all these applications and any underlying messaging system.
Microsoft chose a client/server approach for MAPI to
help reduce bottlenecks that increased messaging generates on a LAN. A client/server architecture distributes tasks between the client side and the server side. Servers store the procedures and executable modules most commonly used by clients.
Using RPCs (remote procedure calls), clients call the procedures and servers return the results to the client. Because the executable code for the procedure is already at the server, the client just needs to send a command to invoke it. This dramatically reduces the I/O between individual users and servers and helps reduce network traffic. The store-and-forward nature of messaging complements the RPC method of client/server interaction in the network.
Management is also simplified with the client/server architectural approach when commonly used procedures and information are stored at a single server. You can upgrade these servers to high-performance systems to further boost messaging performance. When messaging services are based at a central location, th
ey tend to be more consistent and up-to-date. For example, global directories and document-conversion routines are easier to maintain and update if they are located in one place.
Front and Back
MAPI provides programming interfaces for two classes of software systems. Front-end applications use MAPI to access messaging services, and back-end systems make their services available to front-end applications through the MAPI functional layer. Essentially, if you create a MAPI-compliant user application, it will interface with any MAPI-compliant messaging system. Likewise, if you create back-end messaging systems, you simply make the services MAPI-compliant. In the past, the developer of a workgroup application had to create a version for each messaging system that his or her customers might use. (See the text box ``Programming with MAPI'' on page 168.)
MAPI does for messaging what the Windows printer system did for printing. The printer system separates the printer driver from the application,
so developers don't have to write printer drivers for every printer on the market. Instead, printer drivers are included with Windows or supplied by printer manufacturers. In the same way, MAPI separates messaging applications from back-end messaging systems.
David Knight, vice president of marketing at messaging-system vendor Isocor (Brentwood, CA), uses the analogy of a stereo system. ``The amplifier has all sorts of switches and can modify and route signals, but it has two sets of jacks: the RCA jacks for plugging things in, and the speaker jacks for connecting the speakers. That is very analogous to MAPI, which is a whole subsystem that sits under your client in your desktop. You carry it around with you in your PC. Applications are on one side, and an output provider module--at least one--is on the other side. The provider modules are like the speakers of the stereo. You can play any kind of music and the speakers don't care.''
MAPI Architecture
MAPI is an architectural approach, not
just a set of APIs. It exists as a subsystem of the entire operating system. Developers must write MAPI-compliant client applications to one of three client-side interfaces: CMC (Common Messaging Calls), Simple MAPI, or Extended MAPI. MAPI defines four groups of services that are accessible by MAPI-compliant applications: the message store, address-book management, message transport services, and configuration management.
Both Simple MAPI and CMC were designed with simplicity in mind. This lets developers quickly and easily provide mail-enabling features in their applications. CMC is a cross-platform component that is available for Windows/DOS, Macintosh, and Unix systems.
Extended MAPI was designed to create message-intensive applications like work flow, data collection, and message management. It uses an object-oriented design and provides access to a variety of public and private message stores. Extended MAPI also supports high message volumes and complex addressing requirements. Developers c
an write to any of these interfaces to create applications that work with any back-end MAPI service provider.
Microsoft categorizes client applications in three general groups. First, messaging-aware applications are those that don't require messaging services. However, they let you customize the interface to include messaging options on menus. The ``Send'' option on the File menu in Microsoft Word for Windows is a good example of a MAPI customization. Second, messaging-enabled applications are those that require messaging services (e.g., Microsoft Mail) and that typically run over a network or on-line services.
The third category covers messaging-based workgroup applications (e.g., work-flow software), which operates over a network and makes extensive use of message stores, address books, and message-transport functions. These three categories correspond to CMC, Simple MAPI, and Extended MAPI.
Microsoft recommends that software developers use CMC when creating cross-platform, message-awa
re applications that don't need to support a previous version of Simple MAPI. You would use CMC or Simple MAPI to add messaging features to nonmessaging applications (e.g., a word processor or spreadsheet). Use Extended MAPI if an application is dependent on messaging and requires message stores and address books.
CMC and Simple MAPI
The X.400 API Association (XAPIA) developed CMC after work done by Microsoft on Simple MAPI. Many vendors are implementing CMC. It replaces the Simple Messaging Interface in VIM (Vendor-Independent Messaging) 2.0. Because MAPI and VIM support CMC, developers can write mail-enabled applications to a single client interface. CMC also provides a level of interoperability between MAPI and VIM.
CMC provides a basic set of 10 function calls, including send, receive, and address lookup. XAPIA is working on a new version, CMC 2.0, which will provide more complex messaging (e.g., document-attachment and directory-synchronization services). It should be available late t
his year. Such advanced functions were left out of the original specification to promote wide acceptance from vendors wanting to add their own custom features.
Simple MAPI is designed for Windows-only applications. Its messaging functions provide features such as send, address, and receive messages. (See the table ``CMC and Simple MAPI Functions'' on page 174.) Simple MAPI also supports the attachment of files and OLE objects to messages. With file-attachment capabilities, Simple MAPI can be used to create forms-routing programs. Windows' Schedule+ groupware accessory uses Simple MAPI to exchange schedules among users. Microsoft Word, Excel, and other applications also use Simple MAPI message features.
One of Simple MAPI's limitations is that it has a single-folder message store. In Microsoft Mail, this translates to the Inbox. Extended MAPI provides a hierarchical storage structure that allows folders within folders and the integration of message stores from different messaging systems.
E
xtended MAPI
Extended MAPI goes well beyond the simple mail-enabling APIs available in Simple MAPI and CMC by using object-oriented programming methods for its messaging functions. Messages, folders, and attachments are objects that you access through MAPI object structures. When a calling program opens an object, it gets a pointer to reference the object for future use.
While each object type allows different calls or operations, many calls can be made to different objects (i.e., polymorphism) to reduce the development time and code required for applications. According to Microsoft, the MAPI object model is consistent with both present and future object-oriented models for Windows, recognizing each service-provider DLL as a separate object.
Messages are stored in the hierarchical MAPI message store, which is organized into a tree of folders. Messages can have attachments, such as complete files or file pointers, OLE objects or object pointers, MAPI messages, and arbitrary binary data (e.
g., sound or images). Folders, messages, and attachments are made up of properties that store data values, such as the time a message was sent, user name, subject material, and other information.
The value of the properties may be in the form of text, numbers, dates, or binary information. This use of properties simplifies message exchange with other messaging services. It also provides a way to create custom properties for workgroup applications or other special-purpose applications where messages have special significance for the application or its users.
The Messaging Subsystem
The MAPI messaging subsystem provides functions for creating a common user interface to send, receive, and save messages. It provides functions for storing messages in an outbox, forwarding messages at a later time, and providing notification of message delivery. The subsystem also provides functions for managing message stores, address books, and access to different transport providers. MAPI's services operate i
n the background. Because they take place when the foreground application is idle, they have little effect on system performance.
When a user logs on to a MAPI-compliant application, MAPI.DLL is loaded. It includes a message spooler that queries service providers to determine what functions and services are available for the application. MAPI.DLL receives calls from applications that use CMC, Simple MAPI, or Extended MAPI and routes messages to the appropriate message-store and address-book service providers. It places messages in message stores as they are created, and you access the address book to choose recipients for the message.
When the user or an application submits the message for delivery, the message spooler examines the message address and exposes the message to available transport providers, one of which may take on the task of delivering the message, if appropriate. The messaging subsystem can store messages and forward them when a particular messaging service becomes available. It
thus operates as a clearinghouse for messages.
A security feature authorizes user access to messaging services. Users are verified (by user name/password) when they access a MAPI-related option, either the first time they make that access or every time, depending on the level of security required. For some operating systems (e.g., Windows NT), greater security is available. A unified log-on is supported, so you can access multiple workgroups with a single log-on.
Spooler and Transport Providers
The spooler handles the sending and receiving of messages between applications and the back-end messaging services in the same way a print spooler routes jobs to each printer. The spooler interfaces with messaging-transport service providers, which are user-installable drivers that create the connection to the underlying messaging services. The spooler directs inbound messages to message stores and manages undeliverable messages.
If a messaging service is temporarily unavailable, the spooler
automatically sends the message when the messaging service becomes available. The spooler performs its operations in the background, when foreground applications are idle, to minimize performance loss. Transport providers are implemented as user-installable drivers, which are installed for each messaging service that you or applications need.
In some cases, an underlying message system might not be able to accurately represent and deliver the contents of a MAPI message. In this case, the MAPI TNEF (Transport Neutral Encapsulation Format) is used to pass both text and binary message data over the system. Any unsupported MAPI properties are placed in a binary file that is attached to the message. The receiving system then decodes and restores the MAPI properties. According to Chris Williams, product manager at Microsoft, TNEF allows message transmission at ``full fidelity'' with no degradation, even if the message transport does not directly support MAPI capabilities.
The MAPI Message Store
Extended MAPI uses message stores for all its operations. A message store is a hierarchical storage system in which folders can contain other folders and messages can be stored at any level in the hierarchy. Every message store has at least one folder that is called the root folder.
Your local message store and message stores that you may access on the network or from remote systems are stored in collections. As you create messages, they are placed in the message store with messages from other users. You can place copies of a single message in multiple folders, and each copy becomes an individually modifiable message. A deleted-mail folder holds messages that are marked for deletion. During a typical session, you can copy and move messages from one message store to another. Before disconnecting from a network or remote system, you can copy or move messages into their local store for later use.
Messages can have attachments (e.g., files and OLE objects). If you receive a message with an OLE obje
ct attachment such as an Excel spreadsheet, you can edit the object by activating it in the message. That message and object can be stored for later viewing or forwarded to the recipient or another user. Messages are objects with properties that hold information like the time the message was sent and the name of the recipient. The values of these properties are accessible by MAPI client or server applications.
Folder operations that are available in Extended MAPI include the ability of clients to examine the folder hierarchy, examine folder messages by subject or other property, search the folder hierarchy for specific information or properties, and manipulate the structure of the message store. The message store has search features that help you locate messages in folders. You can search based on the properties of message objects (e.g., user, subject, time, date, and custom properties).
A MAPI notification engine goes beyond simple polling processes that check for messages at specified time int
ervals. It lets clients specify various system events. When those events occur, the MAPI subsystem notifies messaging applications or service providers to take appropriate actions.
MAPI Address-Book Providers
The MAPI address book provides message address information for all possible recipients. A typical desktop will contain your PAB (Personal Address Book) and optional address books for network or remote systems. Although a service provider typically utilizes its own addressing method, the MAPI address book hides the addressing differences by providing a unified addressing scheme for the client. You install a driver for each service provider to which you need access. Dialog boxes let you pick ``human-readable'' names from a list. These names are converted in the background to internally used messaging addresses.
The structure of the address book itself is organized into containers that hold recipients and recipient lists. Containers are like folders that hold other containers or recipien
ts. They are used for organizational purposes. Distribution lists indicate recipients that are referred to by a single name. While a typical address book might use a single container to hold its list of recipients, multiple containers or hierarchies of containers are also possible. For example, an address book might have Local User and Remote User containers. Each different network messaging system will have containers that appear in the top-level address book.
You can customize a PAB, for example, to form a collection of address-book entries from other address books. If you frequently send messages to network or remote systems, you can copy the addresses to the PAB. This is not only convenient, it also places the address locally, in case the system holding a remote address book goes down. A local PAB also reduces LAN traffic.
Chicago's Info Center
MAPI's messaging-system independence is most apparent when working with Chicago's Info Center. It provides a single place where you can read an
d send E-mail, send and receive faxes, access workgroup servers, move messages and documents, and organize all types of information. It presents a single user interface, while providing connections to a diversity of information services (e.g., the Internet, CompuServe, and MCI Mail). At this writing, however, it is not clear which services the Info Center will support in its first release.
The Info Center is a ``viewer'' that works as a client to any E-mail or information system when the appropriate MAPI drivers are available. ``MAPI will just call the appropriate service provider,'' says Isocor's Knight. ``I can send the same message to 10 people, even if each one is on a different system. One can be voice-only, and it would do a text-to-speech conversion. Then it could do a fax for the next guy, MCI for the next person, and maybe France Telecom for the next.''
Any information or messaging service provider can develop a MAPI driver. Chicago users will be able to access those services through th
e MAPI-compliant Info Center. According to Microsoft, over 60 vendors are creating MAPI drivers for their E-mail systems, voice-mail applications, workgroup applications, and information systems.
To work with the system, you log on to Chicago and choose View Inbox or Compose New Message from the Start menu. You can compose OLE 2.0-compatible messages with special fonts and styles and attach files and OLE objects. It doesn't matter if the underlying message system doesn't understand these formats, because MAPI will automatically encapsulate the special information into a binary file that is readable by a MAPI-compliant recipient. You can also access multiple message stores and address books using the same interface.
What About VIM and X.400?
Although MAPI appears to have gained industrywide acceptance, other companies have developed VIM, which is a cross-platform API. Like Extended MAPI, it simplifies the creation of messaging-reliant and mail-enabled applications by providing message-store
, transport, and directory functions. Developers need only write their mail-enabled or messaging-reliant applications to one interface.
According to Ed Owens, director of technology relations at Lotus's cc:Mail division and chairman of XAPIA, over 300 software developers have obtained the new VIM toolkit. A number of applications are already on the market that use it. ``In theory, VIM is independent of both the message transport and environment on which you run it, but in reality,'' says Owens, ``the current implementation of VIM is only on Lotus messaging products like Notes and cc:Mail.''
Owens notes that Lotus is developing a VIM-over-MAPI layer, so people writing to VIM will be able to run in a MAPI environment. He says that future Lotus products will provide a service-provider interface to tack up under MAPI. Third parties will have a voice on which way to go.
While the VIM camp accuses MAPI of running only under Windows, Knight claims it's only a temporary problem. Isocor is develop
ing MAPI for Unix and similar operating systems. ``We do not have customers clamoring for VIM,'' he says. ``MAPI is already a worldwide phenomenon because it's exactly what users have been looking for: an open client/server messaging architecture that preserves the investment in backbone technology.''
``One of the problems with VIM is that Lotus has stated that it is implementing VIM on the server side,'' says Janie Chang, director of product marketing at Infonet Software Solutions (Burnaby, British Columbia, Canada), a provider of X.400 and X.500 messaging systems. ``What that means is that they want people to write applications that run over their transport, which is the cc:Mail and Lotus Notes transport.''
There are three important standards for implementing back-end messaging services and backbones: the international X.400 standard, the Internet's SMTP, and Novell's MHS. A backbone minimizes the number of gateways required by clients to access a message system and provides centralized manage
ment. X.400 and SMTP are public standards. MHS is a proprietary standard. X.400 is a specification defined by the International Telecommunications Union that outlines how to build interoperable messaging systems. SMTP is used on the Internet and Unix networks as a store-and-forward messaging system.
While X.400 is an industry-accepted standard, SMTP has gained more popularity as a de facto standard for use with the Internet. However, Microsoft and others are developing X.400 servers that MAPI clients can plug into. Microsoft's Exchange Server implements a client/server architecture that is based on the X.400 messaging standard. It also supports X.400 message stores, which are facilities for housing data and information in the form of messages, documents, and folders.
X.400 is important because of its ability to provide interoperability and rich features. Chang notes that ``the industry must mature so that certain types of information become the normal types of information that get transmitted. T
hat is why X.400 is such a good carrier, because as a transport, it has already-defined multimedia body parts, plus very rich information when it comes to confirmations, such as receipt and delivery notification.''
MAPI's Inside Track
As part of Chicago and with the support of most messaging-system vendors, MAPI has the inside track to become the solution of choice for implementing enterprise-wide messaging systems. It stands to help stabilize the messaging environment so that organizations will be more willing to undertake sophisticated messaging projects like work-flow automation.
``Architecturally, MAPI makes the most sense,'' says Chang. ``It's probably the closest thing we have seen from a PC software vendor that actually allows the plug-and-play concept of messaging.''
What MAPI Does
-- Manage message routing via a common user interface
-- Manage message stores
-- Manage address books for one or more messaging systems using the
same user interface
-- Mana
ge different messaging transport systems
-- Perform message store-and-forward functions if a message system
is unavailable
-- Notify of message delivery or sending
Extended MAPI Capabilities
-- Access arbitrary properties in messages and recipients
-- Customize messages and message formats using properties
-- Develop custom features for address books
-- Notify of events
-- Access and search the folder hierarchy
-- Perform MAPI memory management
-- Substitute custom forms, such as a time sheet or calendar
-- Provide ``smart-form'' capability, which links field information
on custom forms with other applications
Transport-Provider Responsibilities
-- Verify credentials, as the underlying messaging system requires
-- Access outbound messages passed by the spooler
-- Translate message formats, as the messaging system requires
-- Generate delivery or nondelivery reports
-- Inform the spooler of incoming messages
-- Pass i
ncoming data to the spooler
Current and Future MAPI-Supported Messaging Services
-- Microsoft Mail
-- Novell MHS
-- Microsoft's Exchange Server
-- DEC's All-In-1
-- IBM Profs
-- AT&T EasyLink
-- CompuServe
-- MCI Mail
-- Hewlett-Packard
-- SoftSwitch
-- Banyan
-- The Internet
CMC And Simple MAPI Functions
Much similarity exists between CMC and Simple MAPI functions. Microsoft recommends using Simple MAPI to maintain backward compatibility with existing applications that have been written using Simple MAPI. CMC should be used by developers wanting cross-platform support.
CMC FUNCTION MAPI FUNCTION DESCRIPTION
CMC_Logon MAPILogon Establishes a session
with the messaging service.
CMC_Logoff MAPILogoff Terminates a session with
the messaging service.
CMC_Free MAP
IFree Frees the memory allocated by
the messaging service.
CMC_Send MAPISendMail Sends a standard mail message.
Messages can be sent without any
user interaction or can be prompted
via a common user interface
(i.e., a dialog box).
CMC_SendDocuments MAPISendDocuments Sends a standard mail message.
This call always prompts with a
dialog box for the recipient's
name and other sending options.
It is primarily intended for use
with a scripting language such as a
spreadsheet macro.
CMC_List MAPIFind
Next Lists information about messages
meeting specific criteria.
CMC_Read MAPIReadMail Reads a specified mail message.
CMC_ActOn MAPISaveMail, Saves or deletes a specified mail
MAPIDeleteMail message.
CMC_LookUp MAPIAddress, Handles addressing chores,
MAPIDetails, such as creating addresses, looking
MAPIResolveName up addresses, and resolving
friendly names with E-mail names.
CMC_QueryConfiguration Determines information about
the installed CMC service.
Illustration: Message-Enabled Applications
The Windows applications at the top communicate with the MAPI messaging subsystem (MAPI.DLL) using CMC, Simple MAPI, or Extended MAPI calls. The messaging subsystem responds to the calls and routes messa
ges through an SPI (service-provider interface) to a service provider, such as the message-store SPI, the address-book SPI, or the transport-service SPI. A message spooler handles outgoing messages by passing them to the appropriate transport driver, where the matching transport service transfers the messages.
Illustration: Windows Messaging System
The MAPI subsystem resides in Chicago. It provides the link between applications and back-end messaging services with a functional layer called the messaging subsystem. MAPI provides an additional number of Windows APIs that allow applications to use messaging services, including common dialog boxes, message management, and the ability to exchange messages with any back-end MAPI-compliant messaging service. Drivers are installed for each back-end messaging service you need to access.
Illustration: Address-Book Structure
The Extended MAPI address book gives you a view of your own PAB or the address books of other messaging s
ystems, such as their local network. The address book is hierarchical in structure and contains lists of either users or distribution lists. A distribution list contains a group of users that will receive whatever message is addressed to the distribution list.
editors@bix.com
.
MAPI Blooms in Chicago
