News

Microsoft: MAPI Has a Future in Exchange and Outlook

• By Stephen Swoyer
• July 30, 2002

When Steshenko heard that Microsoft’s Exchange and Office teams had major revisions in store for the next version of Microsoft Outlook, he became concerned. After all, MAPI currently functions as the primary means by which Exchange and Outlook communicate with one another. It’s also the API by means of which Natural Data’s software accesses information stored in the Exchange repository.

But MAPI is based on technology that’s more than five years old. More than that, it’s a proprietary protocol that’s maintained exclusively by Microsoft.

“The main problem is that MAPI is [a] proprietary API of Microsoft and does not meet the requirements of Internet standards. These are two obstacles that prevent MAPI [from being] promoted and developed,” Steshenko says.

Microsoft deep-sixed Exchange’s Internet Messaging Service (IMS) in the move from Exchange 5.5 to Exchange 2000, which boasts native support for SMTP, POP and IMAP, among other Internet-standard protocols. Was Microsoft contemplating a similar move away from MAPI in the transition to Exchange Titanium and Outlook 10? If so, Steshenko reasoned, Natural Data – and a number of other software vendors – could be in serious trouble.

“MAPI has [a] closed architecture design. There is no mechanism that gives the possibility to re-write the current implementation of the particular MAPI interface inside [of a] service provider,” he says.

MAPI is pervasive in other Microsoft applications, as well. Word and Excel, for example, exploit MAPI hooks whenever they encapsulate a document or spreadsheet inside of an e-mail. A host of third-party applications exploit MAPI to access information about mail users that’s stored in Microsoft Exchange. Natural Data itself uses MAPI to pull data from Microsoft Exchange and deposit it in a SQL Server repository. MAPI also helps Steshenko and Natural Data synchronize data between the two repositories, as well.

Finally, competing e-mail and messaging products such as Novell GroupWise and Lotus Notes exploit MAPI. As a result, Steshenko argues, any changes to MAPI’s implementation in Outlook or Exchange could affect the development efforts of many software vendors.

“During [the] last few years, Microsoft made announce[ments] about its ‘Kodiak’ and ‘Yukon’ projects. Now the announcement about [the] ‘Titanium’ project appeared,” he says. “Many companies invested and continue investing money in development with MAPI. Some information ahead [of time] about … Microsoft [dropping MAPI] would allow [these companies] to minimize [their] financial losses.”

According to Jim Bernardo, a product manager with Microsoft’s Exchange team, MAPI isn’t going anywhere anytime soon. “MAPI is still the primary protocol for Outlook and Exchange,” he says. “MAPI will remain the primary protocol going forward in the foreseeable future.”

At the moment, Bernardo points out, MAPI is central to the operation of Microsoft Outlook and Exchange.

“Internally, on Exchange 2000, we do a lot of things a little closer to the metal, [so instead of having MAPI inside of the information store,] we’ll have a layer on top of the store that is MAPI,” he says. “Not as much of MAPI is called internally to Exchange server, but Outlook is almost all MAPI.”

Gordon Brown, a program manager with the Exchange team, says that because MAPI is a “very wide, very, very rich API,” Microsoft doesn’t have much incentive – if any – to introduce changes to it in the next versions of Outlook and Exchange. “I personally haven’t heard any requests for [new features] that people want,” he says.

That’s because MAPI has effectively been frozen since the late 1990s. “There just hasn’t been a lot of need to enhance it over the years,” Brown says. The upshot of it all is that the original Exchange client – which was code-named “Capone” – can still use MAPI to interoperate with Exchange 5.5 and Exchange 2000.

Not that MAPI is without its share of shortcomings. First of all, it depends upon Remote Procedure Call (RPC) for its transport. This means that it’s a somewhat chatty protocol, especially over low-bandwidth connections. As a result, telecommuters or employees who work from home and who use dial-up connections typically experience sub-par performance when they invoke Outlook over a WAN. “There is a lot of chattiness in the beginning of it when you log on,” Bernardo says. “A lot of the chattiness is around establishing the session, and doing the handshake between the client and the server."

And for an ostensibly mature protocol, Steshenko suggests, MAPI is not without its quirks. “There are also some discrepancies between MSDN documentation of MAPI and the real implementation of Outlook service providers. There are a lot of things undocumented,” he asserts. “Many weird behaviors [are] exposed by Outlook MAPI providers [that have] never been explained by Microsoft.”

Because it relies upon RPC, MAPI has trouble passing through firewalls – not a good thing in an era when Web services are purporting to guarantee seamless access to enterprise resources across all manner of transport. Moreover, as .NET becomes more pervasive across Microsoft’s product lines, MAPI increasingly becomes the odd API out. Brown acknowledges that MAPI and .NET don’t seem like a natural fit, but insists that retaining support for the legacy API is still a no-brainer. “.NET services are more Web-based, so it’s not a natural fit, but it’s not something that we’re going to phase out. We’d basically have to create a whole new client in order to get rid of MAPI.”

To that end, he says, Microsoft has released a .NET XML Web services toolkit for Exchange. The hope is that MAPI developers –such as Natural Data’s Steshenko – will download the toolkit and experiment with Web-enabling their applications.

This is something that Steshenko’s already thought at great length about. “I think using SOAP with IIS it’s possible to make MAPI ‘Internet enabled,’” he agrees.