Why implement Web services technology in Exchange 2007? Exchange Web Services replaces much of the functionality found in WebDAV, CDOEX, and ExOLEDB, thereby eliminating some of the problems with application architectures that are based on these earlier APIs. Exchange Web Services improves upon these earlier technologies in the following ways:

• By providing "anywhere access." As computing becomes mobile, applications need to be able to adapt to changes in locale. For example, an application that runs on a computer on an intranet may need to access information on an Exchange server that is behind a firewall in an external location. With Exchange Web Services, the API that is used to access information in the Exchange store is no longer limited by boundary; client applications can access the Exchange server from virtually any locale that has network access via HTTP.
  
• By providing for complex calendaring functionality, such as recurring meetings and the ability to send, modify, and cancel meetings. This functionality is not supported in WebDAV — you must use CDOEX to enable complex calendaring functionality in applications that work with Exchange 2000 Server or Exchange Server 2003. For more information about this limitation, see Available support for applications that use the WebDAV protocol to access Exchange 2000 Server or Exchange Server 2003.
  
• By providing strongly-typed objects. The structure provided by the WSDL and schema files provides the information you need to create strongly-typed objects. WebDAV provides a set of properties, but does not provide a schema to describe their use or data structure.
  
• By supporting remote access. ExOLEDB and CDOEX are not redistributable and must be run on the Exchange server.
  

Exchange Web Services in Exchange 2007 implements the following specifications:

• HTTP
  
• XML
  
• Simple Object Access Protocol (SOAP) 
  
• Web Services Description Language (WSDL)
  

Use of the HTTP protocol to transport messages provides Exchange 2007 clients access to Exchange database data over the network, regardless of whether the client is on the Internet or intranet. The use of HTTP eliminates some of the boundary limitations introduced by legacy APIs such as ExOLEDB and CDOEX - definitely a positive step!

XML provides the standard message format for the exchange of information between the Exchange server and the client. XML provides complex Exchange Server database data to client applications, but in a defined structure. The beauty of XML is that it allows for the exchange of data even when the client and server do not share a common platform.

Like Exchange Web Services, WebDAV uses XML and HTTP for the exchange of data between Exchange server and client. Unlike Exchange Web Services, however, WebDAV does not implement the SOAP protocol. The SOAP protocol forms an envelope around the messaging payload. Exchange Web Services implements the SOAP protocol by using different parts of the SOAP envelope to enable different functionality. The SOAP header is used for impersonation and to provide versioning data. The SOAP body provides information about the operation to run and the data that is submitted to the operation. SOAP relies on WSDL to describe the operations to call.

The Exchange Web Services WSDL file, services.wsdl, describes the bindings, the operations, and the properties that are used to call the many operations for Exchange Web Services. This file, along with the referenced schema files, comprises the contract between the client and the Exchange server, and is often used along with vendor-specific tools to create platform-specific applications. The WSDL file is located in the EWS virtual directory, which is at the root of the Web site.

No matter which client platform or vendor-specific products you use to develop Exchange Web Services client applications, the XML sent between the client application and server will always be the same. To build and send a request to the Exchange Web Services endpoint, the client:

1. Builds the XML elements used in the request. The XML elements identify the Web methods to run and the properties used in the request.
   
2. Creates the SOAP message from the XML elements. The SOAP message identifies the operation that corresponds to the Web method to run.
   
3. Serializes the XML message so that it can be used as the XML payload in the HTTP request.
   
4. Creates the HTTP or HTTPS request, including the appropriate headers, credentials, and the serialized XML payload.
   
5. Sends the request to the Exchange Web Services endpoint.
   

To receive a response from the Exchange Web Services endpoint, the client:

1. Deserializes the XML payload.
   
2. Parses the XML and extract the data.
   
3. Consumes the extracted data.
   

The following figure shows the steps involved in sending and receiving XML messages between the client application and the Exchange server.

This article is part one of a three-part series. Stay tuned for more information about Exchange Web Services operations and the use of autogenerated proxies. And soon you will be well on your way to using Exchange Web Services for your own application development!