Export (0) Print
Expand All
1 out of 2 rated this helpful - Rate this topic

Selecting Development Technologies for Exchange

Topic Last Modified: 2009-07-24

You can use numerous programming technologies and languages when you are writing applications for Microsoft Exchange Server 2007. Some technologies are contained in Microsoft Exchange, and others are part of Microsoft Windows. Some technologies enable your applications to work with data that is stored in Exchange, and others manage and control the computer that is running Microsoft Exchange. In many cases, more than one programming technology or language can be used to accomplish a given task, making it possible for you to use the technologies and languages with which you are familiar. For example, you can set properties on items in the Exchange store by using WebDAV, Microsoft ActiveX Data Objects (ADO), or Collaboration Data Objects (CDO).

This section is designed to assist you in selecting the most appropriate technologies for your applications that access and control Microsoft Exchange. Understanding the needs of your project as well as the Microsoft-recommended technologies can help you make better-informed development technology decisions, so that implementing, deploying, and maintaining your applications will also be easier.

Microsoft Exchange can perform a variety of roles within an application, depending on the application architecture and functionality. At its core, Microsoft Exchange not only transports messages, but also maintains mailboxes and public folders, executes form-based applications, and more. The following table briefly describes the more common roles that Microsoft Exchange plays in applications.

Exchange Role Description

Message transport

To applications that send messages, Exchange appears as a standard mail server. The application has several application programming interfaces (APIs) available to transfer messages including MAPI, several variations of CDO, and so on. In addition, using CDO or SMTP event sinks, applications can respond as messages are processed by Exchange.

Mailbox storage

To applications that access data stored in mailboxes, Exchange appears as a hierarchical arrangement of folders, items, and properties. That stored information can be accessed using a mix of database and component object styles. Queries can be performed on the data, and Exchange manages access to the stored data based on user and store permissions. Applications that deal with mailbox data typically use CDO or WebDAV.

Public folder storage

To applications that use public folders, messages and other data stored in Exchange represent the items used by application. Standard document types such as e-mail messages, documents, forms and spreadsheets can be stored in public folders, and properties set on them to instruct the application how to process them. Exchange public folders provide a centralized location where users across the enterprise can access the application data. Using APIs such as CDO and WebDAV, applications access the public folder data using a mix of database and component object styles. Exchange store events and CDO for Workflow (CDOWF) can be used to make you application respond to events that occur with folders and items in the Exchange store.

Application execution platform

The Exchange store can also act as an application platform when using technologies such as Exchange Web forms. Entire applications can be built as Web forms that handle form data stored in Exchange. The Web forms are applied to a particular content type, or to items in a specified folder, and are rendered by Exchange into HTML for display in a client Web browser, or as part of Microsoft Outlook Web Access. Alternatively, Outlook forms and MAPI forms can also be used, depending on the application requirements.

Managed Enterprise Server

To applications that manage Exchange servers and stores, Exchange appears as a managed server. Applications can configure, control and monitor current activity and the health of Exchange servers across the organization. Exchange management applications use APIs such as Windows Management Instrumentation (WMI), CDO for Exchange Management (CDOEXM), Incremental Change Synchronization (ICS) and Active Directory Service Interfaces (ADSI) to manage Exchange servers.

When asked to describe how developers choose technologies, they may respond that "I use what I know", "I check whether I can use Microsoft Visual Basic," or "I use what is standard for our company." These types of first-level decisions can often reveal a single "best" technology for the application. Sometimes, however, several technologies might meet your needs. When there is no obvious choice, further investigation is needed. The typical decision-making process can be summarized into four steps:

  1. Collect the major project requirements.
  2. Discard technologies that are clearly unsuitable.
  3. Plan how to compare the remaining candidates.
  4. Experiment, prototype, and evaluate the remaining technologies.

The differences between how people compare technologies usually focus on the selection criteria used in steps 2 and 4.

Possibly the most frequently ignored is step 4. Many times the choices are clear by the end of step 2, making further investigation unnecessary. When the competing technologies have differences that are less clear, or they are unfamiliar, you should carefully consider how well the candidate technologies meet the project requirements. These more-detailed considerations often include things like whether the technology can be used remotely from the Exchange server, what types of Exchange objects can be accessed, and even how long the application will be in use.

Sometimes, even matching project requirements to technology features will leave more than one candidate to choose from. In such cases it may be useful to construct prototypes and experiments to determine whether a technology is easier to use, has better performance, and so on. When you are creating early prototypes, the sample applications and snippets in the Microsoft Exchange Server 2007 Software Development Kit (SDK) can provide a good set of ready-made examples.

The topics in this section describe the application development technologies that can be used to access data in Exchange and to control Exchange. However, this section does not include all of the technologies that Microsoft makes available, nor can this section give you an easy answer to a complicated technology selection decision.

When you are selecting development technologies for Exchange applications, not only are there many technologies to choose from, there are also many different areas in which to compare them. The other topics in this section are arranged as follows:

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.