Share via

  • Article

Introduction to Exchange Web Services in Exchange 2007, Part 3

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

Topic Last Modified: 2007-07-23

By Michael Mainer, Programming Writer

This is the last of a three-part series that introduces Exchange Web Services in Microsoft Exchange Server 2007. In part one of this series, I explained how Web services technology and Exchange Web Services simplify and improve Exchange 2007 application development. In part two, I introduced the operations that you can perform by using Exchange 2007 and the Exchange Web Services API. In this third and final article, I will describe the use of autogenerated proxy objects in Exchange 2007 client application development.

What are proxy objects?

Essentially, proxy objects are programmable objects that act as an interface to a service; in this case, Exchange Web Services. The proxy objects provide access to all the possible types that are exposed by Exchange Web Services. They also provide the code that is used to form the Simple Object Access Protocol (SOAP) messages, send the messages to the computer that is running Microsoft Exchange, and receive the corresponding responses.

The proxy types that define the proxy objects are created by using the WSDL and schema files. The WSDL and schema files define the contract between the client and server; the proxy types are an abstraction of that contract. They handle all the dirty work that is required to create and send the Web service requests that conform to the contract in the WSDL and schema files.

The proxy objects that are created from the WSDL and schema files provide the following functionality:

  • They serve as convenient containers for the information that describes the Microsoft Exchange data.
  • They handle the XML serialization of the requests to be sent.
  • They handle the XML deserialization of the responses returned from the server.

Where do proxy objects come from?

Proxy classes are generated by tools that are developed for use in specific development environments. These are generally referred to as proxy generators, and both Microsoft and third parties provide them. Microsoft Visual Studio 2005 provides a proxy generator via the Add Web Reference dialog box; the Microsoft .NET 2.0 Framework SDK includes the wsdl.exe proxy generator in the Bin directory. Both proxy generators provide the same functionality, with some minor differences. Because they both use the System.Xml.Schema namespace, you too can create a .NET proxy generator, if you are so inspired. You might, for example, need custom proxy classes, or you might have to modify the autogenerated classes to meet the business requirements of an application.

Note

The Exchange Server 2007 SDK proxy documentation is based on the object model generated by the .NET 2.0 Framework–provided wsdl.exe, version 2.0.50727.42.

So, proxy generators are used to create the proxy types based on the WSDL and schema files. The WSDL and schema files are located in the in the EWS virtual directory of the Microsoft Exchange server.

Why use proxy types?

The proxy types that are created by code generators such as wsdl.exe produce an object model that handles the supplied parameters and serializes information into an XML stream. This XML stream is sent to the server in a SOAP request, and then returned in a SOAP response. If proxy-generated code is not available or is not appropriate for the application, you can use the XML DOM to construct and parse the SOAP messages. Using the proxy classes is much easier than parsing the XML because all the object information is conveniently stored in the proxy objects. Essentially, the proxy objects hold the data that is used to communicate with the Web service. You do not have to worry about the serialization and parsing of the data that is transmitted between client and server. This leaves you more time to focus on the development of the business logic specific to your application.

Generally, the use of proxy types is based on the availability of the tools to generate them. In some cases, autogenerated proxies may not provide the best performance for an application. If you do use a proxy generator to develop an application, consider the business requirements and available tools to determine which proxy generator to use.

Proxy objects and Web service methods

The ExchangeServiceBinding proxy object encapsulates the Web methods on the Microsoft Exchange server that receive the requests and return the responses. The ExchangeServiceBinding class contains a set of methods that correspond to each Web service method that is implemented in Exchange Web Services. The ExchangeServiceBinding class is the worker class that performs the work of serializing and deserializing the SOAP messages that are sent between client and server. For more information about the ExchangeServiceBinding, see Setting Up the ExchangeServiceBinding Proxy Class.

Using proxy objects

The following workflow describes the use of the proxy objects in a client application:

  1. The client application instantiates an object that represents the request to be performed. This object is the container for all the parameters that are used to perform the operation. The CreateItemType is an example of such an object.
  2. The client application supplies the request container with all the parameters that are used to fulfill the request.
  3. The client application calls the method on the ExchangeServiceBinding that corresponds to the type of request to be sent.
  4. The ExchangeServiceBinding object serializes information in the request container into a SOAP XML message, sends the request via HTTP or HTTPS, and receives a response. The response is deserialized from the SOAP XML message into a response object.
  5. The client application uses the response data.

The proxy types that are created by proxy generators may contain artifacts that are difficult to use. Each proxy generator is unique. Proxy generators made by the same organization may produce different results. I suggest that you compare the outputs of two proxy generators to learn more about the object models that they produce. You might also encounter some issues when you use proxy objects to develop against Exchange Web Services.

Looking ahead…

The Microsoft Exchange Server 2007 SDKincludes some examples that show you how to use proxy classes that are created by using the Add Web Reference dialog in Visual Studio 2005. The SDK also includes information about why the proxy object model contains strange constructs. You can find relevant proxy-related information in the following topics:

Also stay tuned for more information about new Exchange Web Services functionality in Exchange Server 2007 Service Pack 1 (SP1).

With the use of proxy types, programming with Web services has never been easier. So go out and seize the day, Microsoft Exchange programmers. Create that exciting new application that you’ve been thinking about.