Aplicativos EWS e a arquitetura do Exchange

Saiba mais sobre como o EWS funciona dentro da arquitetura do Exchange e descubra em quais protocolos o EWS depende.

O EWS (Exchange Web Services) é uma API multiplataforma que permite que os aplicativos acessem itens de caixa de correio, como mensagens de email, reuniões e contatos de Exchange Online, Exchange Online como parte de Office 365 ou versões locais do Exchange começando com Exchange Server 2007. Os aplicativos EWS podem acessar itens de caixa de correio local ou remotamente enviando uma solicitação em uma mensagem XML baseada em SOAP. A mensagem SOAP é inserida em uma mensagem HTTP quando enviada entre o aplicativo e o servidor, o que significa que, desde que seu aplicativo possa postar XML por meio de HTTP, ele pode usar o EWS para acessar o Exchange.

Visão geral da arquitetura do Exchange

Os diagramas a seguir mostram os métodos de autenticação e os caminhos de comunicação usados pelos aplicativos EWS ao se comunicar com o Exchange 2013 e Exchange Online. Na perspectiva do aplicativo EWS, os caminhos de comunicação são idênticos e os métodos de autenticação variam ligeiramente; a principal diferença é a visibilidade que você tem no back-end do Exchange.

Figura 1. Aplicativo EWS e a arquitetura local do Exchange

A Figura 2 mostra os mesmos caminhos de comunicação mostrados na Figura 1, conforme usado por aplicativos EWS ao se comunicar com Exchange Online.

Figura 2. Aplicativo EWS e a arquitetura de Exchange Online

Veja a seguir os componentes mostrados nos diagramas:

1. Aplicativo EWS – pode ser um cliente, portal ou aplicativo de serviço e pode ser instalado em um cliente ou em um servidor de Acesso ao Cliente local do Exchange. Se você usar a API Gerenciada do EWS para desenvolver o aplicativo EWS, os assemblies de API Gerenciada do EWS precisarão ser instalados no cliente e redistribuídos pelo aplicativo.

2. A mensagem SOAP XML – uma mensagem XML, em um envelope SOAP, inserida em uma mensagem HTTP/S que está em conformidade com o arquivo Services.wsdl no servidor de Acesso ao Cliente. O HTTPS é recomendado para o Exchange local e é necessário para Exchange Online.

3. Métodos de autenticação – as mensagens EWS incluem informações básicas, NTLM (autenticação integrada do Windows) ou autenticação OAuth como parte do conteúdo HTTP.

4. Balanceador de carga – O balanceador de carga distribui a mensagem para um servidor de Acesso ao Cliente na matriz do servidor do Client Access. Esse componente só está visível na arquitetura local do Exchange.

5. Matriz de servidor do Acesso ao Cliente – os servidores de Acesso ao Cliente são organizados em um grupo balanceado por carga chamado de matriz de servidor do Client Access. Servidores de acesso ao cliente individuais fornecem serviços de autenticação, redirecionamento limitado e proxy. Os próprios servidores de Acesso ao Cliente não fazem nenhuma renderização de dados e nenhum dado é enfileirado ou armazenado em um servidor de Acesso ao Cliente – ele é fino e sem estado; ele simplesmente autentica a solicitação, executa uma pesquisa de descoberta automática e, em seguida, proxies a solicitação para o servidor caixa de correio. O servidor de Acesso ao Cliente mantém uma relação 1:1 com o servidor da caixa de correio que hospeda os dados do usuário. O protocolo HTTP (protegido via SSL usando um certificado autoassinado) é usado entre o servidor de Acesso ao Cliente e o servidor mailbox. Esse componente só está visível na arquitetura local do Exchange.

6. Serviço de descoberta automática – O serviço De descoberta automática executa uma descoberta de serviço acessando Active Directory Domain Services (AD DS) para recuperar a versão da caixa de correio e o local do servidor da caixa de correio que está hospedando a cópia ativa dos dados do usuário.

7. Serviço EWS — O serviço EWS é descrito por três arquivos: Services.wsdl, Messages.xsd e Types.xsd, bem como os assemblies de API Gerenciada do EWS. Services.wsdl descreve o contrato entre o cliente e o servidor, Messages.xsd define as mensagens SOAP de solicitação e resposta e Types.xsd define os elementos usados nas mensagens SOAP. Messages.xsd e Types.xsd sempre contêm as versões mais recentes do esquema, embora existam versões anteriores do esquema. Observe que Services.wsdl, Messages.xsd e Types.xsd são disponibilizados no servidor de Acesso ao Cliente, mas não são realmente usados para validação de esquema – eles são fornecidos apenas para referência. Os assemblies de API Gerenciada do EWS são fornecidos para aplicativos cliente EWS do lado do servidor e são implantados em todas as funções Exchange Server, não apenas nos servidores de Acesso ao Cliente. Esse componente só está visível na arquitetura local do Exchange.

   A disponibilidade de recursos é baseada na versão do esquema do EWS que seu aplicativo tem como destino. Como os esquemas EWS são compatíveis com para trás e para frente, se você criar um aplicativo que tenha como destino uma versão de esquema anterior, como o Exchange 2007 SP1, seu aplicativo também funcionará em relação a uma versão de esquema posterior, como o serviço SP2 do Exchange 2010, bem como Exchange Online. Como os recursos e as atualizações de recursos são orientados pelo esquema, recomendamos que você use a base de código comum mais antiga direcionada aos recursos do EWS que você deseja implementar em seu aplicativo cliente. Muitos aplicativos podem ser direcionados à versão Exchange2007_SP1, pois o esquema do Exchange 2007 SP1 contém quase todas as funcionalidades principais do Exchange para trabalhar com itens e pastas no repositório do Exchange. Para obter mais informações, confira Recursos do cliente EWS.

8. DAG (Grupo de Disponibilidade de Banco de Dados) – os servidores de caixa de correio são organizados em um DAG altamente disponível, que pode ser implantado em um ou mais datacenters. O servidor da caixa de correio contém o banco de dados da caixa de correio e manipula todas as atividades para as caixas de correio ativas nesse servidor. Todos os componentes que processam, renderizam e armazenam dados estão no servidor da caixa de correio. Os clientes não se conectam diretamente ao servidor da caixa de correio; todas as conexões são tratadas pelo servidor de Acesso ao Cliente. Esse componente só está visível na arquitetura local do Exchange.

9. Exchange Online e Exchange Online como parte do Office 365 – a solução de mensagens hospedada que fornece recursos do Exchange como um serviço baseado em nuvem.

Quando um aplicativo EWS solicita informações do exchange store, uma mensagem de solicitação XML que está em conformidade com o padrão SOAP é criada e enviada para o servidor exchange. Quando o servidor exchange recebe a solicitação, ele verifica as credenciais fornecidas pelo cliente e analisa automaticamente o XML para os dados solicitados. Em seguida, o servidor cria uma resposta SOAP que contém dados XML que representam os objetos fortemente tipados solicitados e suas propriedades. Os dados XML são enviados de volta ao aplicativo em uma resposta HTTP. Em seguida, o aplicativo desserializa o XML e usa os dados para reformar os objetos fortemente tipado.

Protocolos e padrões que os aplicativos EWS devem dar suporte

Para se comunicar com um servidor exchange, os aplicativos EWS devem dar suporte aos seguintes protocolos e padrões.

Tabela 1. Protocolos

Protocolo	Como ele é usado
HTTP/S	Permite que aplicativos EWS acessem dados de banco de dados do Exchange pela rede, independentemente de o cliente estiver na Internet ou na intranet.
SOAP 1.0	Forma um envelope em torno do conteúdo de mensagens. O EWS implementa o protocolo SOAP usando diferentes partes do envelope SOAP para habilitar diferentes funcionalidades. O cabeçalho SOAP é usado para representação e para fornecer dados de versão. O corpo SOAP fornece informações sobre a operação a ser executada e os dados enviados à operação. O SOAP depende do WSDL para descrever as operações a serem chamadas.
WSDL 1.0	Descreve as associações, as operações e as propriedades usadas para chamar operações EWS, no arquivo Services.wsdl. Esse arquivo, juntamente com os arquivos de esquema referenciados, compreende o contrato entre um aplicativo EWS e o servidor Exchange e geralmente é usado junto com ferramentas específicas do fornecedor para criar aplicativos específicos da plataforma. O arquivo WSDL está localizado no diretório virtual do EWS, que está na raiz do site.
Segurança da Camada de Transporte (TLS)/SSL	Fornece comunicações web seguras na Internet ou na intranet. O TLS permite que os aplicativos autentiquem servidores ou, opcionalmente, servidores para autenticar aplicativos EWS. Ele também fornece um canal de segurança criptografando comunicações. TLS é a versão mais recente do protocolo SSL (Secure Sockets Layer).
XML/XSD	Fornece um formato de mensagem universal para a troca de informações entre o servidor exchange e o cliente. O XML fornece dados complexos do banco de dados do Exchange para aplicativos cliente, mas em uma estrutura definida. A beleza do XML é que ele permite a troca de dados mesmo quando um aplicativo EWS e um servidor não compartilham uma plataforma comum.

Além disso, os aplicativos EWS devem dar suporte aos seguintes padrões de autenticação:

• Autenticação básica no SSL, para aplicativos que visam Exchange Online ou Exchange local.

• Autenticação NTLM no SSL, para aplicativos que dão suporte ao Exchange local.

• Autenticação de token OAuth 2.0, para aplicativos parceiros confiáveis e interoperabilidade com o Lync Server 2013 e o SharePoint Server 2013.

Confira também

• Introdução ao uso dos serviços Web no Exchange

• Tipos de aplicativo EWS

• Visão geral de design do cliente EWS para o Exchange