Service Provider Basics

There are three common types of service providers:

• Address book providers
• Message store providers
• Transport providers

Address book and message store providers have many similarities. They register a unique identifier with MAPI that they use for constructing entry identifiers for their objects. They provide a hierarchy of objects and properties that clients can access and manipulate. For their container objects, they support a hierarchy table and a contents table. They support event notification on these tables and optionally on individual objects so that clients can be informed of changes that occur during the session. When operations become lengthy, they can display a progress indicator to inform the user of the operation's status. Clients can communicate with address book and message store providers either indirectly through MAPI using the IAddrBook and IMAPISession interfaces or directly using one of the following service provider interfaces:

Transport providers differ from address book and message store providers in the way they communicate with MAPI and with clients. Transport providers typically wait for MAPI to prompt them for information rather than initiate communication. Unlike the other providers, transport providers do not support a variety of objects and tables that are commonly accessed by clients. However, they do support a status object, as do all service providers, and publish its properties in the status table. Whereas address book and message store providers call IMAPISupport::SetProviderUID to register unique identifiers for constructing their entry identifiers, transport providers call IXPLogon::AddressTypes to register unique identifiers as well as address types for assuming responsibility for the delivery of particular messages.

Another type of service provider that developers can create is a messaging hook provider. Because messaging hook providers are active processes, they more closely resemble client extensions to the MAPI spooler than a type of service provider. The MAPI spooler is the only process not driven directly by client actions. Another difference between a messaging hook provider and the other types of service providers is that a messaging hook provider uses a session object instead of a support object. MAPI provides the other types of service providers with a customized support object.

Your service provider should have three header files: one public header file and two internal files. Use the public header file for configuration and for documenting properties and their values. Include in one of the internal header files all the necessary public MAPI headers; this header file should be included in all of your service provider source files. Use the other internal file to define resource identifiers.

Assign file names for your provider's executable files that are six characters or less in length. This is to allow a suffix to be appended to the end of the name to identify the platform.

Address book, message store, and transport providers perform the following tasks:

• Supply an entry point function. For information about implementing an entry point function, see Implementing a Service Provider Entry Point Function.
• Supply a provider and logon object to handle logon and initialization. For more information about implementing these objects, see Starting a Service Provider.
• If the provider belongs to a message service, supply a message service entry point function. For more information about implementing message services, see Implementing a Message Service.
• Support configuration by implementing a property sheet. For more information about property sheets, see Implementing a Property Sheet.
• Implement a status object and support the status table. For an overview of status objects and the status table, see Status Objects and Status Table. For more information about implementing a status object, see Implementing a Status Object.
• Handle shut down.