Export (0) Print
Expand All

Select the right Exchange development technology


Find information to help you select the right development technology to use to develop against Exchange.

Last modified: November 05, 2013

Applies to: EWS Managed API | Exchange Online | Exchange Server 2003 | Exchange Server 2007 | Exchange Server 2010 | Exchange Server 2013 | Office 365

In this article
How Exchange interacts with applications
Evaluating technologies
In this section
Additional resources

You can use a number of different programming technologies and languages when you write applications for Exchange. Some technologies are included in Exchange Server 2013 or earlier versions, and others are part of the Windows Server operating system. Some technologies enable your applications to work with data that is stored in Exchange, and others manage and control the Exchange server. In many cases, you can use more than one programming technology or language to accomplish a task, which makes it possible for you to use the technologies and languages that you are familiar with. For example, you can set properties on items in the Exchange store by using MAPI, Exchange Web Services (EWS), or the EWS Managed API.

Use the information in this section to help you select the most appropriate technologies for your applications that work with Exchange. Understanding the needs of your project as well as the technologies that we recommend can help you make better-informed development technology decisions, so that it will be easier for you to implement, deploy, and maintain your applications.

Exchange interacts with custom applications in a variety of ways, depending on the application architecture and functionality. At its core, Exchange not only transports messages, but also maintains mailboxes, executes form-based applications, and more. The following table describes the more common ways that Exchange interacts with custom applications.

Table 1:  Exchange interactions with custom applications

Exchange interaction


Message transport

Exchange serves as a standard mail server for applications that send messages. Exchange includes several APIs that transfer messages, including MAPI and EWS. In addition, applications can use transport agents to respond as messages are processed and delivered by Exchange.

Mailbox storage

Exchange provides a hierarchical structure of folders, items, and properties for applications that access data stored in mailboxes. You can access that stored information by using a combination of database and component object styles. You can perform queries on the data, and Exchange manages access to the stored data based on user and store permissions. Applications that handle mailbox data typically use EWS or the Microsoft Office Outlook Object Model.

Managed enterprise server

Exchange functions as a managed server for applications that manage Exchange servers and stores. Applications can configure, control, and monitor current activity and the health of Exchange servers across the organization. Exchange management applications use the Exchange Management Shell and Active Directory Service Interfaces (ADSI) to manage Exchange servers.

How do you choose technologies? For some developers, their answer might be "I use what I know," "I see if I can use Visual Basic," or "I use what is standard for our company." These types of first-level decisions rarely reveal a single "best" technology for the application. Sometimes, however, several technologies might meet your needs. When there is no obvious choice, you can investigate further. The typical decision-making process involves the following 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 are typically based on the selection criteria they use for steps 2 and 4.

Step 4 is possibly ignored the most frequently. 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 can 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 code examples that are available in the Exchange content sets can provide a good set of ready-made examples.

The articles in this section describe some of the common application development technologies that you can use to access data in Exchange and to manage Exchange servers.

When you are selecting development technologies for Exchange applications, not only are there many technologies to choose from, but there are also many different areas in which to compare them. The topics in this section are organized into the following categories:

© 2014 Microsoft