Artigos técnicos sobre o Windows Vista.

Avanade Austrália, http://www.chrispeiris.com/

Avanade Países Baixos, http://www.dennismulder.net/

Aplica-se a:

Microsoft .NET Framework 3.0

Windows Vista

Microsoft Internet Information Services

Microsoft Visual Studio 2005

 

Resumo: Este artigo discute as opções de hospedagem e consumo dos serviços WCF (Windows Communication Foundation) Os serviços Web ASMX tradicionais eram hospedados apenas no Microsoft IIS (Serviços de Informações da Internet). As opções de hospedagem para os serviços WCF foram aprimoradas significativamente no Microsoft .NET Framework 3.0. Discutiremos a extensão do modelo de hospedagem para incluir as opções de serviços do Windows e hospedagem interna (self-hosting). Também exploraremos em detalhes as opções de hospedagem IIS (versões 5.1, 6.0 e 7.0) e WAS (Serviços de Ativação do Windows) disponíveis para os serviços WCF. O conteúdo deste artigo baseia-se no Capítulo 5 de Pro WCF: Practical Microsoft SOA Implementation, publicado pela Apress. Esse livro é de autoria de uma equipe global de consultores da Avanade. Ele é dirigido ao público leitor de nível básico a intermediário e faz parte da série da Apress que discute o WPF (Windows Presentation Foundation), o WCF (Windows Communication Foundation) e o WF (Windows Workflow Foundation) (27 páginas impressas).

Baixar o código de exemplo.

Baixar a descrição do estudo de caso do QuickReturns.

Conteúdo

Nesta página

Introdução
Explorando as opções de hospedagem
Hospedando internamente seu serviço
Hospedando nos serviços do Windows
Hospedando por meio dos Serviços de Informações da Internet
Consumindo serviços WCF
Conclusão

Introdução

Quando a sua empresa depende de uma arquitetura orientada a serviços, você precisa verificar se eles são robustos. O elemento mais importante por trás da robustez do seu aplicativo é o local/a forma de hospedagem do seu serviço. Ao considerar os serviços de hospedagem, faça as seguintes perguntas: Quais são os requisitos de disponibilidade dos meus serviços? Como irei gerenciar e implantar meus serviços? Preciso oferecer suporte às versões anteriores dos meus serviços?

É essencial saber como tratar esses requisitos da empresa para desenvolver serviços bem-sucedidos. Conforme foi descrito no Capítulo 3, é necessário hospedar serviços no seu próprio host. O WCF não vem com o próprio host, mas com uma classe chamada ServiceHost que permite hospedar serviços WCF facilmente no seu próprio aplicativo. Não é necessário se preocupar com os detalhes de transporte de rede para poder tornar seus serviços acessíveis. Basta configurar os pontos de extremidade dos serviços, de forma declarativa ou por meio de programação, e chamar o método Open de ServiceHost. Todas as funcionalidades genéricas em relação a ligações, canais, distribuidores e escutas descritas no Capítulo 3 estão integradas a ServiceHostBase e ServiceHost. Isso significa que a responsabilidade do aplicativo usado para hospedar seu serviço, o aplicativo em que ServiceHost é executado, é bem menor do que se poderia esperar.

Este capítulo descreve os tipos de aplicativos que podem ser usados para hospedar o ServiceHost. Além disso, você saberá quais são as diferenças de consumir esses serviços hospedados em diferentes aplicativos.

Ao concluir este capítulo, você conhecerá os seguintes conceitos:

• As diferentes opções de hospedagem disponíveis para você

• As vantagens e desvantagens de cada opção de hospedagem

• Orientação sobre quando escolher cada opção de hospedagem

• Orientação arquitetural sobre como a Microsoft implementou as diferentes opções de hospedagem e os pontos de extensibilidade de cada opção

Explorando as opções de hospedagem

Na plataforma Microsoft .NET, é possível criar vários tipos de aplicativos gerenciados do Windows com o Microsoft Visual Studio.NET:

• Aplicativos WinForms

• Aplicativos de console

• Serviços do Windows

• Aplicativos Web (ASP.NET) hospedados no IIS

• Serviços WCF dentro do ISS 7.0 e WAS no Windows Vista ou Windows Server codinome Windows Server 2008

Ao examinar os modelos de projetos que acompanham o Microsoft Visual Studio 2005, você encontrará outras opções disponíveis. Por motivos óbvios, não consideramos nenhum dos outros modelos opções viáveis a serem usadas no mundo dos serviços. Vale notar, entretanto, que o WCF não o impede de executar seu serviço em outro tipo de aplicativo, contanto que ele forneça um domínio do aplicativo .NET. (Se você não conhece os conceitos por trás de um domínio do aplicativo .NET, consulte a seção a seguir "Compreendendo os domínios de aplicativo .NET.) Tudo gira em torno dos requisitos que você tem para o seu host. Para resumir as opções, pense nas três categorias genéricas de host a seguir para seus serviços WCF:

• Hospedagem interna em qualquer aplicativo gerenciado .NET

• Hospedagem em um serviço do Windows

• Hospedagem em versões diferentes do IIS

Como você pode imaginar, todas elas têm modelos de projeto associados no Visual Studio, conforme mencionado anteriormente nesta seção, e possuem suas próprias características. Para entender melhor qual host é mais apropriado à sua situação, é necessário conhecer os requisitos e os recursos que os hosts normalmente possuem. Depois de entendermos isso, examinaremos cada opção de hospedagem individualmente.

Compreendendo os domínios do aplicativo .NET

Supondo que você conheça a função dos processos do Windows e saiba como interagir com eles a partir do código gerenciado, é necessário investigar o conceito de um domínio do aplicativo .NET. Para executar o código gerenciado .NET em um processo, você cria assemblies. Esses assemblies não são hospedados diretamente de um processo do Windows. Em vez disso, o CLR (Common Language Runtime) isola esse código gerenciado, criando partições lógicas separadas em um processo chamado domínio do aplicativo. Um único processo pode conter vários domínios do aplicativo, cada um hospedando partes diferentes de um código encapsulado em assemblies. Essa subdivisão de um processo tradicional do Windows oferece vários benefícios fornecidos pelo .NET Framework

Os principais benefícios são os seguintes:

• Os domínios do aplicativo fornecem a natureza neutra do sistema operacional da plataforma .NET, extraindo-se o conceito de um executável ou de uma biblioteca.

• Os domínios do aplicativo podem ser controlados e (des)carregados conforme desejado.

• Os domínios do aplicativo fornecem isolamento para um aplicativo ou dentro de um processo no qual residem vários aplicativos. Os domínios do aplicativo dentro de um processo são independentes e, como tal, permanecem funcionais quando um deles apresenta falha.

Recursos do ambiente de hospedagem

Um aplicativo .NET requer um processo de hospedagem do Windows. Dentro desse processo do Windows, é possível hospedar vários domínios do aplicativo .NET. Um domínio do aplicativo é o meio usado pelo .NET CLR para isolar o código gerenciado no Windows. O CLR cria automaticamente um domínio do aplicativo padrão em cada processo de trabalho em que é inicializado. O domínio do aplicativo padrão não é descarregado até que seja fechado o processo no qual ele é executado. O CLR controla o fechamento do domínio do aplicativo padrão. Na maioria dos hosts, nenhum código é executado dentro desse domínio. Em vez disso, os hosts (ou processos) criam um novo domínio do aplicativo para que ele possa ser fechado independentemente do processo. Em vários aplicativos, é desejável que o código do lado do cliente e o do lado do servidor sejam executados em diferentes domínios do aplicativo. Em geral, esse desejo surge por razões de segurança e isolamento.

O relacionamento entre os processos e os domínio do aplicativo é semelhante ao relacionamento entre os aplicativos e domínios do aplicativo e o ServiceHost do WCF. Como mostra a Figura 5-1, todo processo possui pelo menos um domínio do aplicativo, e todo domínio do aplicativo pode hospedar zero ou mais instâncias ServiceHost do WCF. O WCF requer pelo menos um domínio do aplicativo hospedado dentro de um processo do Windows.

Figura 5-1. Processos, domínios do aplicativo e o relacionamento ServiceHost do WCF

Observação Embora seja possível criar várias instâncias ServiceHost, é mais fácil manter uma instância ServiceHost por domínio do aplicativo. É possível usar vários pontos de extremidade para expor diversas interfaces de serviço em um único host. Hosts mais avançados, como IIS e WAS, não criam várias instâncias de ServiceHost para fornecer isolamento e diferentes contextos de segurança.

Portanto, a principal responsabilidade do host é fornecer um processo de trabalho do Windows e um domínio do aplicativo ao ServiceHost do WCF. Além disso, o WCF conta com os recursos de segurança e configuração fornecidos por um domínio do aplicativo. Um processo do Windows sempre é executado sob a identidade padrão que o WCF usa prontamente. Entretanto, o WCF é acompanhado de recursos para impressionar os usuários em vários níveis (abordados no Capítulo 7 do livro). Se você não usar esses recursos, o processo do Windows sob o qual o seu serviço é executado fornecerá o contexto de segurança. Como vimos nos capítulos anteriores, por padrão, o WCF conta com os recursos de configuração do .NET Framework que estão acessíveis por meio do domínio do aplicativo.

Alguns hosts são acompanhados de recursos adicionais para os aplicativos de gerenciamento que executam. O mais notável deles, o IIS, vem com reciclagem automática de processos, regulagem de recursos, log, indicadores de integridade e outros recursos. Esses tópicos serão descritos com mais detalhes no decorrer do capítulo. (Diferentes versões IIS possuem diferentes recursos de gerenciamento para os quais o WCF oferece suporte. O IIS 5.1 no Windows XP, particularmente, vem com várias limitações na interface de gerenciamento do usuário.)

Requisitos do ambiente de hospedagem

A Microsoft fez um bom trabalho ao garantir que você, como desenvolvedor de serviços, não tivesse de se preocupar muito com o ambiente de hospedagem. O ServiceHost elimina todas as dificuldades tecnológicas para que você possa se concentrar na lógica de seu serviço em vez dos meandros envolvidos nos serviços de hospedagem. Com base nos seus requisitos, é necessário escolher um host. O WCF foi criado basicamente como um modelo de programação, e uma das principais decisões da criação foi torná-lo indiferente ao host. O ServiceHost não se importa em ser instanciado, contanto que seja executado quando você desejar que seus serviços fiquem disponíveis. Em outras palavras, ele requer um processo que execute um domínio do aplicativo . NET.

É necessário considerar alguns requisitos ao escolher um tipo de aplicativo (como se será um aplicativo de console, um aplicativo WinForms etc.). O ServiceHost deve ser instanciado para fornecer o ambiente de hospedagem em que seus serviços residem. Os aplicativos .NET típicos, como aplicativos de console e WinForms, são executados em computadores desktop do usuário. Esses ambientes não são executados todo o tempo; é possível hospedarem seus serviços, mas não são como os típicos hosts prontos para empresas. Os hosts prontos para empresa são considerados ao oferecer suporte para uma arquitetura orientada ao serviço de grande escala, em que os serviços expõem as principais funcionalidades da empresa das quais vários sistemas dependem. Os hosts prontos para empresa, em geral, preenchem requisitos como alta disponibilidade. Por isso, não consideramos os aplicativos de console ou WinForms como tal.

Os serviços normalmente são executados em servidores e gerenciados e controlados por operadores. Com freqüência, os operadores que gerenciam servidores não gostam de iniciar aplicativos de console ou aplicativos WinForms manualmente quando os servidores são reiniciados. Para que os aplicativos do seu serviço estejam prontos para serem executados em um centro de dados, a única opção viável para os cenários orientados ao serviço da empresa é hospedar os serviços no IIS ou como um serviço do Windows.

Às vezes, é necessária uma comunicação entre processos no computador desktop do usuário. Nesse cenário, o serviço está ativo somente quando o usuário usa o aplicativo. Os aplicativos típicos nos quais existem requisitos de comunicação entre processos são os aplicativos de console e os aplicativos WinForms. Esses aplicativos são adequados para hospedar esses tipos de serviços.

Para determinar qual host é o mais adequado ao seu cenário, consulte os seus requisitos não-funcionais. Normalmente, os requisitos não-funcionais especificam os requisitos técnicos para seu aplicativo a fim de garantir que eles atendam à sua qualidade e sustentabilidade. Para aplicativos WCF, isso se resume aos seguintes tópicos:

• Disponibilidade: quando você deseja poder dispor do seu serviço?

• Confiabilidade: o que acontece quando seu serviço apresenta alguma falha? Como isso afeta os outros consumidores?

• Gerenciamento: você precisa de fácil acesso às informações sobre o que está acontecendo no host em que seus serviços WCF residem?

• Controle de versão: você precisa oferecer suporte às versões anteriores do serviço? Você sabe quem consome seus serviços?

• Implantação: qual é o seu modelo de implantação? Você está instalando por meio do processo do Microsoft Installer e dos pacotes de implantação do Visual Studio ou o xcopy é suficiente?

• Estado: os seus serviços não têm monitoração de estado? Você precisa de sessões?

Com base nesses requisitos não-funcionais, é possível decidir qual host atende às suas necessidades. Para ajudá-lo nessa escolha, o restante deste capítulo tratará dos diferentes ambientes de hospedagem, incluindo suas vantagens e desvantagens.

Note O modelo de programação WCF é indiferente ao local em que é executado, por isso, é sempre possível alternar para um host diferente posteriormente, sem haver necessidade de alterar a implementação do seu serviço. Normalmente, inicia-se com um cenário de hospedagem interna em um aplicativo de console para testar e estabelecer um protótipo de seus serviços.

Hospedando internamente seu serviço

A maneira mais fácil e flexível de hospedar serviços WCF é pela hospedagem interna. Para poder hospedar internamente seus serviços, é necessário atender a dois requisitos. O primeiro é o tempo de execução do WCF e o segundo é um aplicativo gerenciado .NET para hospedar o ServiceHost. Cabe a você escrever o código que inicia e pára o host.

As vantagens da hospedagem interna são as seguintes:

• É fácil de usar: com apenas algumas linhas de código, o serviço pode ser executado.

• É flexível: é possível controlar facilmente a duração dos seus serviços pelos métodos Open() e Close() de ServiceHost<T>.

• É fácil de depurar: a depuração dos serviços WCF hospedados em um ambiente de hospedagem interna fornece uma maneira familiar de depurar, sem ter de anexar aplicativos diferentes que ativem seu serviço.

• É fácil de implantar: em geral, para implantar simples aplicativos do Windows, basta usar o xcopy. Não é necessário nenhum cenário complexo de implantação em farms de servidores e assim por diante. Para implantar um simples aplicativo do Windows que sirva como ServiceHost do WCF.

• Oferece suporte todas as ligações e transportes: a hospedagem interna não o limita a ligações prontas nem a qualquer tipo de transporte. No Windows XP e no Windows Server 2003, o IIS o limita somente a HTTP.

As desvantagens da hospedagem interna são as seguintes:

• Disponibilidade limitada: o serviço está disponível somente quando o aplicativo é executado.

• Recursos limitados: os aplicativos de hospedagem interna possuem um suporte limitado para alta disponibilidade, fácil gerenciamento, robustez, recuperação, controle de versões e implantação de cenários. O WCF pronto, pelo menos, não fornece nenhuma dessas vantagens, por isso, em um cenário de hospedagem interna, é necessário implementar esses recursos à parte; o IIS, por exemplo, vem com vários deles por padrão.

Em outras palavras, não se deve considerar a hospedagem interna para cenários empresariais. A hospedagem interna é adequada durante as fases de desenvolvimento ou demonstração do seu projeto empresarial. Outro exemplo apropriado para hospedar internamente seus serviços é quando se deseja que os aplicativos em um desktop de usuário se comuniquem ou em um cenário ponto a ponto, conforme descrito no Capítulo 12 do livro.

Vimos vários exemplos de cenários de hospedagem interna no Capítulo 3. Todos os exemplos usavam aplicativos de console simples. Para ilustrar melhor a questão em um cenário real, este capítulo apresenta um aplicativo WinForms que hospeda um serviço de rastreamento das ofertas publicadas para os agentes da Market Makers no estudo de caso da QuickReturns Ltd.

Para esse cenário, há dois aplicativos WinForms distintos. Um é aplicativo Market Makers Manager que a Market Makers pode usar para publicar as ofertas e comercializar seus títulos. O outro é um aplicativo WinForms separado que rastreia as ofertas publicadas. Ele faz isso expondo um serviço que implementa o contrato ITradeTrackingService, conforme descrito na Listagem 5-1. O aplicativo Market Makers Manager chama esse serviço quando publica uma oferta com êxito por meio do TradeService.

Listagem 5-1. ServiceContract para o TradeTrackingService

using System.ServiceModel;
using QuickReturns.StockTrading.ExchangeService.DataContracts;

namespace QuickReturns.StockTrading.TradeTrackingService.Contracts
{
    [ServiceContract()]
    interface ITradeTrackingService
    {
        [OperationContract()]
        void PublishQuote(Quote quote);
    }
}

	

Hospedando nos serviços do Windows

Hospedar um serviço WCF em um serviço do Windows é uma escolha lógica. Não se deve confundir os serviços do Windows com os serviços WCF. Os dois usam a palavra serviço, mas possuem significados diferentes. Um serviço do Windows é um processo gerenciado pelo sistema operacional. O Windows vem com o Gerenciador de Controle de Serviço, que controla os serviços instalados no sistema operacional. O Windows usa os serviços para oferecer suporte aos recursos dos sistema operacional, como sistema de rede, USB, acesso remoto, enfileiramento de mensagens e assim por diante. É possível usar o Visual Studio 2005 para criar um serviço do Windows usando o modelo de projeto do Serviço do Windows mostrado na Figura 5-2.

Figura 5-2. Modelo de projeto do Serviço do Windows no Visual Studio 2005

O modelo de projeto do Serviço do Windows gera um projeto com dois arquivos: o arquivo service1.cs, que contém a implementação do serviço, e o arquivo program.cs, que instancia e basicamente hospeda o serviço do Windows. Para hospedar seu serviço WCF dentro de um serviço do Windows, é necessário apenas implementar os métodos Start() e Stop() do serviço do Windows, conforme mostrada na Listagem 5-2. Como o paradigma de início dos serviços do Windows é semelhante ao início dos seus serviços dentro do ServiceHost do WCF, a duração do serviço WCF fica vinculada à duração do serviço do Windows.

Listagem 5-2. Serviço do Windows hospedando o ServiceHost do WCF

	using System;
using System.ServiceModel;
using System.ServiceProcess;
using QuickReturns.StockTrading.ExchangeService;

namespace QuickReturns.StockTrading.ExchangeService.Hosts
{
    public partial class ExchangeWindowsService : ServiceBase
    {
        ServiceHost host;

        public ExchangeWindowsService()
        {
            InitializeComponent();
        }

        protected override void OnStart(string[] args)
        {
            Type serviceType = typeof(TradeService);
            host = new ServiceHost(serviceType);
            host.Open();
        }

        protected override void OnStop()
        {
            if(host != null)
               host.Close();
        }
    }
}

	

Portanto, escrever um serviço do Windows que hospede seu serviço WCF é muito fácil e apresenta vários benefícios quando comparado ao cenário de hospedagem interna descrito anteriormente neste capítulo. Entretanto, escrever um serviço do Windows que hospede seu serviço WCF também apresenta algumas desvantagens que devem ser entendidas.

As vantagens são as seguintes:

• Início automático: o Gerenciador de Controle de Serviço do Windows permite definir o tipo de inicialização como automático, para que o serviço seja iniciado assim que o Windows inicie, sem um logon interativo no computador.

• Recuperação: o Gerenciador de Controle de Serviço do Windows possui um suporte interno para reiniciar serviços quando ocorre uma falha.

• Identidade de segurança: o Gerenciador de Controle de Serviço do Windows permite escolher uma identidade de segurança específica sob a qual o serviço será executado, incluindo contas internas de serviço de rede e de sistema.

• Gerenciamento: Em geral, os operadores do Windows conhecem profundamente o Gerenciador de Controle de Serviço e outras ferramentas de gerenciamento que podem funcionar com a instalação e configuração do serviço do Windows. Isso irá melhorar a aceitação dos serviços do Windows em ambientes de produção; entretanto, para permitir a manutenção desses serviços, provavelmente será necessário adicionar alguns recursos de login e instrumentação.

• Suporte para todas as ligações e transportes: a hospedagem interna não o limita a usar qualquer uma das ligações e ou dos transportes prontos. No Windows XP e no Windows Server 2003, o IIS o limita somente a HTTP.

Algumas das desvantagens dos serviços do Windows são as seguintes:

• Implantação: os serviços devem ser instalados com o utilitário Installutil.exe do .NET Framework ou por meio de uma ação personalizada em um pacote de instalação.

• Recursos limitados: os serviços do Windows ainda possuem um conjunto limitado de recursos prontos para oferecer suporte a alta disponibilidade, facilidade de gerenciamento, robustez, recuperação, controle de versões e implantação de cenários. Basicamente, é necessário implementar esses recursos à parte por meio de código personalizado, enquanto que o IIS, por exemplo, vem com vários deles por padrão. Os serviços do Windows adicionam a capacidade de recuperação e alguns recursos de segurança, mas ainda é necessário realizar algumas tarefas à parte.

Para poder instalar um serviço no Gerenciador de Controle de Serviço, é necessário adicionar um instalador ao projeto. O Visual Studio 2005 permite fazer isso facilmente:

1. Abra o modo de exibição Designer da classe Service no projeto de serviço do Windows.

2. Clique no plano de fundo do designer para selecionar o serviço em si, em vez de um de seus conteúdos.

3. Na janela Properties (Propriedades), clique no link Add Installer (Adicionar Instalador) na área cinza da lista de propriedades, como mostra a Figura 5-3. Por padrão, é adicionada uma classe de componente ao seu projeto, contendo dois instaladores. O componente é chamado ProjectInstaller, e os instaladores que ele contém são um para o seu serviço e outro para o processo associado a ele.

   

   Figura 5-3. A função Add Installer de um projeto de serviço do Windows

4. Acesse o modo de exibição Designer para ProjectInstaller e clique em ServiceInstaller1.

5. Na janela Properties (Propriedades), defina a propriedade ServiceName como QuickReturns Exchange Service.

6. Defina a propriedade StartType como Automatic (Automático), como mostra a Figura 5-4.

   

   Figura 5-4. A janela Properties do QuickReturns Exchange Service

7. Acesse o modo de exibição do Designer para ProjectInstaller e clique em serviceProcessInstaller1.

8. Na janela Properties, defina a propriedade Account (Conta) como Network Service (Serviço de Rede), como mostra a Figura 5-5.

   

   Figura 5-5. A janela Properties do QuickReturns Exchange Service

Para poder criar uma configuração que possa ser usada ao instalar o seu serviço do Windows, é necessário adicionar à solução um projeto de configuração e implantação do Visual Studio. As seguintes etapas descrevem como adicionar à sua solução um projeto de configuração e implantação:

1. Selecione File (Arquivo) | Add (Adicionar) | New Project (Novo Projeto).

2. Na caixa de diálogo New Project, selecione a categoria Other Project Types (Outros tipos de projeto), em seguida, Setup and Deployment (Configuração e implantação) e Setup Project (Configurar projeto), com mostra a Figura 5-6.

   

   Figura 5-6. Modelo de projeto de configuração do Visual Studio 2005

3. No Solution Explorer, clique com o botão direito do mouse no projeto de configuração, aponte para Add e escolha Project Output (Saída de projeto), como mostra a Figura 5-7. A caixa de diálogo Add Project Output Group (Adicionar grupo de saída de projeto) é exibida.

   

   Figura 5-7. Adicionando a saída do projeto de serviço do Windows

4. Selecione o projeto de serviço do Windows.

5. Na caixa de listagem, selecione Primary Output (Saída Principal) e clique em OK.

Um item de projeto é adicionado ao projeto de configuração para saída primária do seu serviço do Windows. Agora, adicione uma ação personalizada para instalar o arquivo executável. Para adicionar uma ação personalizada ao projeto de configuração, siga estas etapas:

1. No Solution Explorer, clique com o botão direito do mouse no projeto de configuração, aponte para View(Exibir) e escolha Custom Actions (Ações Personalizadas), como mostra a Figura 5-8. O modo de exibição Custom Actions é aberto.

   

   Figura 5-8. Abrindo o modo de exibição Custom Actions

2. Clique com o botão direito do mouse em Custom Actions e selecione Add Custom Action (Adicionar ação personalizada).

3. Clique duas vezes na pasta de aplicativo na caixa de listagem para abri-la, selecione Primary Output (Saída Principal) no projeto de serviço do Windows e clique em OK. A saída primária é adicionada aos quatro nós das ações personalizadas: Install, Commit, Rollback e Uninstall.

4. Crie o projeto de configuração.

Ao compilar o projeto, a saída é um arquivo do Microsoft Installer (.msi) que pode ser usado para instalar as informações do serviço no Gerenciador de Controle de Serviços do Windows.

Observação Este capítulo descreve os princípios básicos da criação de serviços do Windows e de instaladores desses serviços. Configurar seus serviços do Windows para serem executados em uma conta Localsystem irrestrita ou em uma conta apropriada do Network Service nem sempre é o mais acertado em termos das melhores práticas de segurança. Normalmente, os operadores possuem a capacidade de escolher as credenciais durante a configuração ou de ajustar as configurações de identidade de segurança depois da instalação, por meio do snap-in do Console de Gerenciamento do Gerenciador de Controle de Serviço que pode ser acessado pelo Gerenciamento do Computador do Windows. Consulte o Capítulo 7 deste livro, a Ajuda do MSDN ou um livro dedicado ao desenvolvimento do .NET para obter mais detalhes e as melhores práticas em relação ao desenvolvimento dos serviços do Windows.

Hospedando por meio dos Serviços de Informações da Internet

O desenvolvimento do serviço Web no IIS não é mais exclusividade do ASP.NET. Quando o ASP.NET 1.0 foi lançado, era acompanhado de uma estrutura de serviço Web A Microsoft aproveitou o pipeline HTTP do ASP.NET para tornar os serviços Web uma realidade na plataforma Windows. Infelizmente, essa grande união entre ASP.NET e os serviços Web apresenta diversas limitações no mundo orientado aos serviços, e a dependência do HTTP é a grande culpada. Executar o pipeline HTTP do ASP.NET em um host diferente é difícil e, portanto, um cenário incomum. Mesmo assim, os serviços Web do ASP.NET (também conhecidos como serviços ASMX) permanecem extremamente orientados à Web em termos de cenários de implantação e dependências de configuração. A Microsoft, inicialmente, lançou diversas versões do WSE (Web Services Enhancements) para compensar algumas limitações dos serviços Web do ASP.NET e, especialmente, resolver as limitações na implementação dos protocolos WS-*. Entretanto, o WSE dependia muito da implementação dos serviços Web do ASP.NET.

Como vimos nos capítulos anteriores, os serviços WCF adotam uma abordagem totalmente diferente para tornar a orientação aos serviços uma realidade. O modelo de programação unificado do WCF baseia-se em um modelo estritamente em camadas para romper o paradigma orientado para a Web e desconectar o modelo de serviço e a camada de canal dos transportes com suporte. Esse modelo permite ao WCF oferecer suporte a vários hosts diferentes dos quais o IIS é o mais importante.

O WCF foi criado para oferecer suporte ao Windows XP, Windows Server 2003, Windows Vista e Windows Server 2007. Desde o IIS 5.1, que foi lançado com o Windows XP, houve muitas alterações. No entanto, a Microsoft teve êxito ao oferecer suporte às versões anteriores do WCF. Isso foi possível por causa dos recursos que o Microsoft.NET Framework e o CLR proporcionam, que fazem parte do WCF. Nas seções seguintes, veremos as diferenças nos modelos de processo das diferentes versões do IIS e as conseqüências para os seus serviços WCF.

Principais recursos do IIS 5.1 e 6.0

Para explicar as diferenças, primeiro, é necessário conhecer os principais recursos do IIS. O IIS há muito tempo oferece suporte a diversos sites e aplicativos em um único computador. Para permitir isso, o IIS introduziu um modelo de endereço comum que é dividido em três áreas principais:

• Sites (Observação: o IIS 5.1, lançado com o Windows XP, oferece suporte somente para um único site.)

• Aplicativos

• Diretórios virtuais

Os sites são ligados a um esquema, endereço de rede e combinação de portas específicos. O IIS oferece suporte não apenas a HTTP, mas também, dependendo da versão, a FTP, NNTP e SMTP. É possível executar diversos aplicativos no mesmo site e sob o mesmo esquema, rede e combinação de portas. Um URI típico para um aplicativo é http://localhost/MyApplication. Um diretório virtual é simplesmente uma pasta mapeada para o espaço da rede do site, que poderia estar em algum lugar do sistema de arquivos. Dessa forma, é possível manter o conteúdo real ou o código de um aplicativo separado dos outros que fazem parte do mesmo site.

No IIS 6.0, a Microsoft fez alterações significativas no modelo de processo IIS. O modelo de processo IIS foi dividido em pools de aplicativos que podem ser compartilhados por sites e aplicativos, em que cada aplicativo executa seu próprio domínio. Um pool de aplicativos é um processo de trabalho separado do Windows chamado W3wp.exe e é iniciado somente quando há necessidade. Em outras palavras, o IIS vem com um modelo de ativação de aplicativo que permite iniciar um pool de aplicativos ao receber uma solicitação para um aplicativo específico ligado ao pool. Isso permite ao IIS hospedar vários milhares de aplicativos em um servidor sem manter vários milhares de processos em execução. A arquitetura de ativação do IIS é um modelo interessante no mundo dos serviços, conforme veremos na seção "Serviços de ativação do Windows" deste capítulo.

A Figura 5-9 mostra a arquitetura principal do IIS 6.0 na parte inferior da pilha do protocolo HTTP e, sobre ela, pelo menos, quatro processos diferentes.

Figura 5-9. Arquitetura principal do IIS 6.0

• Lsass.exe: responsável pelos recursos de segurança no IIS - a implementação da Autenticação do Windows e do SSL (Secure Sockets Layer).

• Inetinfo.exe: o processo que hospeda os serviços não-HTTP e o IIS Admin Service, incluindo a Metabase.

• SvcHost.exe: o processo que pode hospedar os serviços do sistema operacional; no caso do IIS, ele hospeda o serviço Web (HTTP).

• W3wp.exe: um processo de trabalho. O IIS pode ter vários processos W3wp.exe, um para cada pool de aplicativos. Para oferecer suporte a cenários Ambiente Web em que um aplicativo é dividido em processos separados, é necessário ter várias instâncias do mesmo processo de trabalho. Isso pode fornecer benefícios adicionais de desempenho e escalabilidade.

Observação Estamos descrevendo a arquitetura do IIS 6.0, porque essa foi a versão mais usada antes da liberação do WCF. Além disso, o WCF oferece suporte ao IIS 6.0, e o modelo é bastante semelhante à implementação que escolhida com o IIS 7.0 e os Serviços de Ativação do Windows, conforme veremos no restante deste capítulo. A principal diferença entre o IIS 5.1 e o IIS 6.0 é a limitação na quantidade de sites e pools de aplicativos. O IIS 5.1 oferece suporte apenas para um site ligado a um pool de aplicativos.

Hospedando serviços WCF no IIS

Para hospedar um serviço WCF no IIS, é necessário um novo arquivo físico com a extensão .svc. O arquivo associa um serviço com sua implementação e é o meio usado pelo IIS para criar o ServiceHost para você. O IIS assume a interação entre seu serviço e o ServiceHost; você não precisa mais instanciar e iniciar o ServiceHost sozinho. A primeira linha do arquivo .svc contém uma diretiva colocada na diretiva <% Page %> do ASP.NET que informa ao ambiente de hospedagem a qual serviço esse arquivo aponta. O código de serviço pode residir embutido, como mostra a Listagem 5-3, em um assembly separado, registrado no GAC, em um assembly que reside na pasta Bin do aplicativo ou em um arquivo C# que reside na pasta App_Code do aplicativo. O cenário mais comum é definir os pontos de extremidade em um arquivo de configuração. No IIS, você deve definir os pontos de extremidade no arquivo Web.config, como é explicado na próxima seção.

A Listagem 5-3 mostra um exemplo de arquivo .svc com base no serviço TradeService que vimos anteriormente. Ele tem o código de serviço embutido. A Listagem 5-4 mostra um exemplo de arquivo .svc em que o código reside na pasta App_Code.

Listagem 5-3. Arquivo ExchangeServiceInline.svc com código embutido

<%@ServiceHost Language="C#"
Service="QuickReturns.StockTrading.ExchangeService.TradeServiceInline" 
%>

using System;
using System.Collections;
using System.ServiceModel;
using QuickReturns.StockTrading.ExchangeService.Contracts;
using QuickReturns.StockTrading.ExchangeService.DataContracts;

namespace QuickReturns.StockTrading.ExchangeService
{
    [ServiceBehavior(InstanceContextMode=InstanceContextMode.Single,
                    IncludeExceptionDetailInFaults=true)]
    public class TradeServiceInline : ITradeService
    {
        public Quote GetQuote(string ticker)
        {
             ...
        }

        public void PublishQuote(Quote quote)
        {
             ...
        }
    }
}

	

Listagem 5-4. Arquivo ExchangeService.svc com código externo

<% @ServiceHost language="C#"
Service=" QuickReturns.StockTrading.ExchangeService.TradeService"
CodeBehind="~/App_Code/TradeService.cs" %>

	

Configurando serviços WCF no IIS

Hospedar no IIS significa que você terá de definir a configuração do WCF no arquivo Web.config do aplicativo em que deseja hospedar seu serviço. A configuração do serviço no arquivo Web.config é semelhante à dos serviços de hospedagem interna. A Listagem 5-5 mostra um exemplo de um arquivo Web.config para o serviço TradeService.

Listagem 5-5. Web.config usado para configurar um serviço hospedado no IIS

<?xml version="1.0"?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
   <system.serviceModel>
      <services>
         <service 
name="QuickReturns.StockTrading.ExchangeService.TradeService"
                  behaviorConfiguration="tradeServiceBehavior">
         <endpoint name="basicHttpBinding"
                   address=""
                   binding="basicHttpBinding"
                   contract="QuickReturns.StockTrading.ExchangeService.?
                             Contracts.ITradeService"/>
         <endpoint name="mexHttpBinding"
                   contract="IMetadataExchange"
                   binding="mexHttpBinding"
                   address="mex" />
      </service>
      <service 
name="QuickReturns.StockTrading.ExchangeService.TradeServiceInline"
               behaviorConfiguration="tradeServiceBehavior">
            <endpoint name="basicHttpBinding"
                      address=""
                      binding="basicHttpBinding"
                      contract="QuickReturns.StockTrading.ExchangeService.?
                                Contracts.ITradeService"/>
            <endpoint name="mexHttpbinding"
                      contract="IMetadataExchange"
                      binding="mexHttpBinding"
                      address="mex" />
         </service>
      </services>
      <behaviors>
         <serviceBehaviors>
            <behavior name="tradeServiceBehavior" >
               <serviceMetadata httpGetEnabled="true" />
            </behavior>
            <behavior name="returnFaults"
                      returnUnknownExceptionsAsFaults="true"/>
         </serviceBehaviors>
      </behaviors>
   </system.serviceModel>
</configuration>


	

Observe que o atributo address do serviço está vazio. O arquivo .svc determina o endereço básico do serviço. Entretanto, você pode fornecer uma cadeia de caracteres adicional que definiria o endereço do ponto de extremidade relativo ao arquivo .svc. Por exemplo, você pode usar o seguinte:

 

http://localhost:8080/QuickReturns/Exchange.svc/ExchangeService

 

O atributo name do serviço especificado no arquivo config funciona como uma chave de pesquisa para o ExchangeService.svc correspondente. Ele informa ao ambiente de hospedagem a qual serviço essa configuração pertence. Os outros atributos no nível do ponto de extremidade são os mesmos explicados anteriormente.

No IIS, os arquivos de configuração Web podem ser aninhados em sites, aplicativos e diretórios virtuais. O WCF leva todos os arquivos de configuração em conta e mescla os serviços com seus pontos de extremidade. Isso significa que arquivos Web.config aninhados são aditivos, sendo que o último arquivo lido no fim da hierarquia tem precedência sobre os arquivos nos níveis superiores.

Acessando o ServiceHost no IIS

O comportamento padrão de hospedagem dos seus serviços WCF no IIS é que o IIS controla a instanciação do ServiceHost. Isso o impede de ter um código de inicialização e desligamento antes que uma mensagem atinja seu serviço. A vantagem não ter código de inicialização e desligamento é, obviamente, menos código que potencialmente apresente erros. O IIS fornece um ambiente de hospedagem mais fácil, em termos de linhas de código, do que um aplicativo de console. Entretanto, às vezes, é necessário encontrar uma forma de contornar essa limitação. Para fazer isso e influenciar o IIS a instanciar ServiceHost, você pode construir sua própria fábrica que crie um host personalizado. Assim, você poderá acessar qualquer evento ou substituir qualquer método que desejar.

Para oferecer suporte à ativação ServiceHost , é necessário implementar sua própria Factory que é herdeira da ServiceHostFactory, que é uma classe de fábrica capaz de instanciar seu host personalizado. A classe é fornecida para interligar os eventos para ServiceHost; você pode usar essa classe e colocar o tipo como o atributo Factory no arquivo .svc, como mostra a Listagem 5-6. Ao substituir o método CreateServiceHost da classe ServiceHostFactory, é possível realizar tarefas semelhantes às feitas nos cenários de hospedagem interna, como vimos no Capítulo 3. Entre outras coisas, isso permite abstrair a lógica para criar a descrição da configuração externa ou criar uma classe base mais adequada para sua biblioteca básica, seu projeto, departamento ou sua empresa usar.

A Listagem 5-7 mostra o código de TradeServiceCustomHost e TradeServiceCustomHostFactory e cria o host.

Listagem 5-6. Arquivo .svc com uma CustomServiceHostFactory

<% @ServiceHost Language="C#" Debug="true"
   Service="QuickReturns.StockTrading.ExchangeService.TradeService"
   Factory="QuickReturns.StockTrading.ExchangeService.
TradeServiceCustomHostFactory" %>

	

Listagem 5-7. TradeServiceCustomHostFactory e TradeServiceCustomHost

using System;
using System.ServiceModel;
using System.ServiceModel.Activation;

namespace QuickReturns.StockTrading.ExchangeService
{
   public class TradeServiceCustomHostFactory : ServiceHostFactory
   {
      protected override ServiceHost CreateServiceHost(
         Type serviceType, Uri[] baseAddresses)
      {
         TradeServiceCustomHost customServiceHost =
            new TradeServiceCustomHost(serviceType, baseAddresses);
         return customServiceHost;
      }
   }

   public class TradeServiceCustomHost : ServiceHost
   {
      public TradeServiceCustomHost(Type serviceType, params Uri[] 
baseAddresses)
         : base(serviceType, baseAddresses)
      {
      }

      protected override void ApplyConfiguration()
      {
         base.ApplyConfiguration();
      }
   }
}

	

Reciclando

Quando você hospeda serviços WCF no IIS, eles desfrutam de todos os recursos dos aplicativos ASP.NET. Você deve ficar atento a esses recursos porque eles podem causar um comportamento inesperado no mundo dos serviços. Um dos principais recursos é a reciclagem de aplicativo, incluindo a reciclagem de domínio do aplicativo e a reciclagem de processo. Por meio do Console de Gerenciamento do IIS, é possível configurar diferentes regras quando se deseja que a reciclagem aconteça. É possível definir alguns limites de memória, tempo e quantidade de solicitações processadas, como mostra a Figura 5-10. Quando o IIS recicla um processo de trabalho, todos os domínios de aplicativo dentro desse processo também são reciclados. Normalmente, quando arquivos críticos em um aplicativo Web baseado no ASP.NET são alterados, o domínio do aplicativo também é reciclado. Isso acontece, por exemplo, ao alterar o arquivo Web.config ou assemblies na pasta Bin.

Figura 5-10. Configurações de reciclagem de pool de aplicativos

Observação O processo de reciclagem descrito aqui aborda a reciclagem no Windows Server 2003. Para habilitar a reciclagem de processo no Windows XP e no IIS 5.1, você pode baixar a ferramenta de reciclagem de processo do IIS 5.0 no site da Microsoft. A ferramenta de reciclagem de processo é executada como um serviço em um computador com o IIS 5.0 ou 5.1.

Depois de modificar um arquivo .svc, o domínio do aplicativo também é reciclado. O ambiente de hospedagem tentará fechar todas as conexões abertas de serviços WCF apropriadamente, no tempo oportuno. Quando os serviços não fecham a tempo por algum motivo, são forçados a abortar. Por meio das definições de configuração HostingEnvironmentSettings, é possível influenciar o comportamento da reciclagem, como podemos ver na Listagem 5-8. A configuração idleTimeout determina o tempo ocioso, em segundos, para um domínio de aplicativo ser reciclado. A configuração shutdowntimeout determina o tempo, em segundos, para fechar adequadamente um aplicativo. Depois desse intervalo, ela força os aplicativos a fecharem.

Listagem 5-8. Web.config com a seção hostingenvironment para configurações de reciclagem

<system.web>
    <hostingEnvironment idleTimeout="20"
                        shutdownTimeout="30"/>
</system.web>

	

Ao usar as sessões WCF, é essencial entender esses recursos de reciclagem. Esse é o caso típico dos cenários de segurança e de serviços de mensagens confiáveis, como veremos nos Capítulos 6 e 8 deste livro. Por padrão, o WCF armazena o estado da sessão na memória. É uma implementação diferente do estado de sessão do ASP.NET e não vem com uma configuração para alternar para o armazenamento persistente de estado de sessão. Entretanto, em cenários de segurança e de serviços de mensagens confiáveis, você pode, e deve, se beneficiar com a implementação do ASP.NET. O uso dos recursos de compatibilidade do ASP.NET do WCF proporciona as implementações do servidor de estado e do SQL Server do estado de sessão do ASP.NET para oferecer cenários prontos para empresa. Na próxima seção, veremos como tirar proveito do modo de compatibilidade do ASP.NET do WCF.

Modelo de compatibilidade do ASP.NET

Ao hospedar seus serviços WCF em um ambiente com balanceamento de carga ou mesmo um Ambiente Web em que as solicitações subseqüentes em uma sessão podem ser processadas por diferentes hosts ou processos no ambiente, você precisa de armazenamento persistente fora do processo para seu estado de sessão. O WCF pronto para uso não oferece suporte a armazenamento persistente para estado de sessão. Em vez disso, o WCF armazena todo seu estado da sessão na memória. Quando seus serviços WCF estiverem hospedados no IIS, você poderá obter cenários de reciclagem, conforme descrito na seção anterior. Em vez de criar todo o armazenamento persistente para sessões novamente, o WCF depende a implementação do ASP.NET para o estado de sessão. Esta abordagem tem uma limitação séria: você limita seus serviços a HTTP.

O estado de sessão ASP.NET não é o único recurso que tem suporte no modo de compatibilidade do ASP.NET. Ele também oferece suporte a recursos como HttpContext, globalização e personificação, assim como acontece com os serviços Web do ASP.NET (ASMX). Consulte a Ajuda do MSDN para obter os recursos específicos do ASP.NET a fim de habilitar o estado de sessão fora do processo.

Para ver a limitação do modo de compatibilidade do ASP.NET, é necessário marcar seus serviços explicitamente com o atributo AspNetCompatibilityRequirements, como mostra a Listagem 5-9.

Listagem5-9. Atributo AspNetCompatibilityRequirements

namespace QuickReturns.StockTrading.ExchangeService
{
    [ServiceBehavior(InstanceContextMode=InstanceContextMode.Single,
                    ReturnUnknownExceptionsAsFaults=true)]
    [AspNetCompatibilityRequirements(
     RequirementsMode=AspNetCompatibilityRequirementsMode.Allowed)]
    public class TradeService : ITradeService
    {
    ...
    }
}

	

O atributo AspNetCompatibilityRequirementsMode possui os seguintes valores permitidos.

Tabela 5-1. Valores para o atributo AspNetCompatibilityRequirementsMode

Valor	Descrição
NotAllowed	Indica que seus serviços talvez nunca sejam executados no modo de compatibilidade do ASP.NET. É necessário definir isso nos cenários em que a implementação do seu serviço não funcione no modo de compatibilidade do ASP.NET, como em cenários em que seus serviços não sejam criados para HTTP.
Allowed	Indica que seus serviços podem ser executados no modo de compatibilidade do ASP.NET. Escolha esse valor somente quando souber que seu serviço pode funcionar nesse modo.
Required	Indica que seu serviço deve ser executado no modo de compatibilidade do ASP.NET. Escolha esse valor quando seu serviço exigir armazenamento persistente de sessão.

Quando você escolhe a opção Required (Necessário), o WCF confirma se todos os pontos de extremidade com suporte para os serviços são HTTP e, quando não são, lança uma exceção durante a inicialização do ServiceHost. Além do atributo AspNetCompatibilityRequirements, é necessário definir aspNetCompatibilityEnabled, como mostra a Listagem 5-10.

Listagem 5-10. Configuração com a compatibilidade do ASP.NET habilitada

<?xml version="1.0"?>
<configuration 
xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
   <system.serviceModel>
      <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
      <services>
      ...
      </services>
      <behaviors>
      ...
      </behaviors>
  </system.serviceModel>
</configuration>

	

Observação O código de exemplo que vem com este livro contém o serviço TradeService hospedado no arquivo ExchangeServiceInline.svc que é configurado para executar o modo de compatibilidade do ASP.NET. Você o encontrará abrindo o arquivo de solução do Capítulo 5 (consulte o link de download do código de exemplo).

Windows XP e IIS 5.1

O IIS 5.0, que vem como parte do Windows 2000, dividia o modelo de processo do IIS e apresentava processos de trabalho. O principal motivo para essa alteração era isolar os aplicativos de forma que o IIS pudesse hospedar diferentes aplicativos que fossem menos interdependentes. O IIS 5.0 foi lançado com o Windows 2000, e o IIS 5.1 foi lançado com o Windows XP. O WCF não oferece suporte aos serviços de hospedagem no Windows 2000 com o IIS 5.0; por isso, examinaremos melhor apenas o IIS 5.1. Ele oferece suporte para o IIS 5.1, mas com a limitação de apenas um site, sendo que cada aplicativo é executado em um processo de trabalho chamado aspnet_wp.exe. O IIS 5.1 é uma ótima versão para desenvolver sites do ASP.NET e serviços WCF. Ele não está pronto para o uso empresarial porque possui limites de conexão e é executado apenas em uma versão cliente das versões anteriores do Windows ou do Windows XP. Neste capítulo, falaremos sobre o IIS 5.1.

Na Figura 5-11, podemos ver o modelo de processo do IIS 5.1. A arquitetura é dividida em duas partes. O W3svc.exe à esquerda hospeda uma escuta HTTP, inicia os processos de trabalho e gerencia a configuração. Os processos de trabalho no outro lado permitem ao IIS 5.1 hospedar aplicativos .NET gerenciados, nos quais ASPNET_ISAPI.dll é responsável por criar domínios de aplicativo .NET gerenciados. Observe que, no Windows XP, o serviço do Windows W3svc.exe é hospedado no processo SvcHost.exe, junto com os serviços SMTP e FTP.

Figura 5-11. Arquitetura do modelo de processo do IIS 5.1

Observação Você não é obrigado a fazer com que o IIS execute os serviços ASP.NET e WCF. Por exemplo, é possível usar o servidor de desenvolvimento do ASP.NET que é fornecido com o Visual Studio 2005. Quando o Windows XP foi lançado, o Visual Studio não tinha esse recurso. Era necessário trabalhar com o IIS 5.1 para poder desenvolver aplicativos Web no Windows XP.

Windows Server 2003 e IIS 6.0

No Windows Server 2003, a Microsoft introduziu a pilha HTTP do modo kernel chamada HTTP.SYS. O HTTP.SYS foi inserido na arquitetura do IIS 6.0 por meio do W3svc.exe. O W3svc.exe é um componente do modo de usuário que associa a implementação do modo kernel do HTTP.SYS e o conecta ao processo e ao sistema de gerenciamento de configuração que já existia no IIS 5.1. E, desde o IIS 6.0, o conceito de pools de aplicativos tornou-se mais generalizado. Embora no IIS 5.1 somente aplicativos (ASP.NET) gerenciados pudessem ser hospedados em pools de aplicativos separados, no IIS 6.0, isso é possível com todos os tipos de aplicativos. O ASPNET_ISAPI.dll ainda é responsável por iniciar os domínios de aplicativo no mundo ASP.NET gerenciado. A Figura 5-12 ilustra o modelo de processo no IIS 6.0.

Figura 5-12. Arquitetura de hospedagem do modelo de processo do IIS 6.0

As etapas detalhadas a seguir mostram como hospedar um serviço WCF do .NET 3.0 no IIS 6.0. Usaremos o exemplo descrito anteriormente para hospedá-lo no IIS 6.0.

1. Abra a pasta que contém ExchangeServiceIISHost da pasta de código de exemplo.

2. A próxima etapa é criar um diretório virtual a partir dele no IIS. Você pode navegar pelo Gerenciador do IIS, mas, para simplificar, clique com o botão direito do mouse na pasta e selecione Propriedades.

3. Quando for exibida a caixa de diálogo de propriedades, clique na guia Compartilhamento na Web. Clique no botão de opção Compartilhar esta pasta e será exibida da caixa de diálogo Editar alias. Renomeie o alias de ExchangeServiceIISHost para ExchangeService. É possível habilitar Pesquisa no Diretório para facilitar as ações de exibir e clicar nos itens do site. Em geral, essa configuração é apenas para desenvolvimento; consulte a Figura 5-13 para obter as configurações de Compartilhamento na Web.

   CUIDADO Essa configuração permite aos usuários navegar em todos os arquivos do site, como no Windows Explorer. Embora seja um bom recurso, tenha cuidado com ele na produção.

   

   Figura 5-13. Caixa de diálogo Editar alias em Compartilhamento na Web

   1. Agora, basta clicar em OK várias vezes para descartar as caixas de diálogo. O site se tornará disponível por meio da URL http://localhost/ExchangeService. Entretanto, ainda é necessário verificar a versão do ASP.NET que está configurada para esse site. Se você tem apenas o .NET 2.0 instalado — quer dizer, o .NET 1.1 nunca foi instalado —, não há mais nada a fazer; entretanto, não custa verificar. Portanto, no Gerenciador do IIS (Iniciar | Painel de Controle | Ferramentas Administrativas | Serviços de Informações da Internet). Ao exibir a caixa de diálogo Propriedades, clique na guia ASP.NET e alterne a versão do ASP.NET, usando a caixa suspensa, para a versão suportada do .NET 3.0, 2.0.50727, a versão RTM.

   2. Há apenas mais uma etapa em nosso exemplo que é para fornecer acesso a recursos ao que chamamos de solicitações anônimas. As solicitações anônimas são aquelas que não possuem nenhuma identidade ou entidade de segurança do Windows associada à solicitação HTTP.

Clique na guia Segurança de diretório e em Editar na seção Anonymous access and authentication control (Acesso anônimo e controle de autenticação) da caixa de diálogo. Verifique se a opção Acesso anônimo está habilitada. Isso permitirá que nosso exemplo seja executado sem examinarmos como fornecer credenciais de autenticação nas solicitações.

Agora, se você navegar até o local http://localhost/ExchangeService usando o Internet Explorer, poderemos ver uma listagem de diretório (desde que as configurações sejam as mesmas da figura anterior). Se você clicar no Service.svc, será levado para a tela de ajuda padrão gerada pelo System.ServiceModel.Activiation.HttpHandler para extensões *.svc.

Siga as mesmas etapas em um aplicativo cliente, gerando uma classe de proxy diretamente pelo uso do utilitário Svcutil.exe ou clicando com o botão direito do mouse no projeto e gerando o proxy por meio do recurso do suplementoAdd Service (Adicionar Serviço), como mostraremos posteriormente neste capítulo na seção "Consumindo serviços WCF".

A solução que acompanha este exemplo possui um cliente de console que faz uma chamada no serviço WCF que acabamos de criar.

Hospedando no IIS 7.0

O IIS 7.0 estabeleceu outra grande evolução no mundo de servidor Web. Como podemos ver na Figura 5-14, foram feitas duas grandes alterações. Primeiro, agora os adaptadores de escuta específicos de protocolo oferecem suporte aos quatro transportes WCF, em vez de apenas HTTP o IIS 6.0. Além disso, um novo serviço de sistema operacional, chamado WAS, está disponível. O W3svc.exe e o WAS são executados dentro de um host de sistema operacional chamado SvcHost.exe. Para permitir o uso do poder do modelo de processo do IIS 6.0 com o WCF, essas alterações foram necessárias. Você poderia perguntar: "Por quê?". Bem, os serviços WCF também funcionam no IIS 5.1 e no IIS 6.0, portanto quais benefícios você poderia obter generalizando o modelo de processo e os recursos de ativação no IIS? Simples: ao generalizar o conceito de ativação para torná-lo indiferente ao protocolo, em vez de vinculá-lo ao HTTP, você expande os recursos de ativação da plataforma para praticamente todos os transportes.

Figura 5-14. Arquitetura do modelo de processo do IIS 7.0

Com a liberação do Windows Vista e do Windows Server codinome “Longhorn”, a Microsoft moveu os recursos de configuração e gerenciamento de processos do IIS e tornou-os disponíveis de forma geral dentro do sistema operacional. Isso permite que qualquer aplicativo criado sobre esse modelo use o poder dos processos de trabalho de geração e ativação de tempo de execução com base nas mensagens recebidas.

Os adaptadores de escuta específicos de protocolo para HTTP, TCP/IP, pipes nomeados e MSMQ residem em seus próprios processos e estão ligando transportes específicos ao WAS. Os adaptadores de escuta pedem ao WAS para ativar os processos de trabalho e passar a comunicação real ao manipulador específico de protocolo dentro desses processos de trabalho. Assim, agora, o WAS possui todos os recursos que costumavam fazer parte do W3svc.exe. Ao dividir essa responsabilidade em processos separados, os outros três transportes também se beneficiam dos recursos de ativação e modelo de processo que costumavam ser criados no IIS 6.0, mas apenas para HTTP. Resumindo, com o IIS 7.0, é possível hospedar qualquer serviço WCF em qualquer transporte pronto para uso fornecido dentro do ISS. Na próxima seção, você saberá como a ativação do WAS funciona e a que deve ficar atento quando desejar hospedar seus serviços WCF dentro do IIS 7.0 e do WAS no Windows Vista ou no Windows Server codinome “Longhorn”.

Para hospedar o TradeService que você tem usado em todo este livro dentro do IIS 7.0, tudo que precisa fazer é configurar o IIS e colocar o arquivo .svc criado para o IIS 6.0 no site que você criará. As etapas a seguir permitem configurar o IIS 7.0, o WAS e o .NET Framework 3.0 no Windows Server codinome “Longhorn” e colocar seu TradeService em execução dentro do IIS 7.0.

1. Inicie o Gerenciador de Servidores (que está em Ferramentas Administrativas).

2. Adicione a função Servidor Web (IIS) a servidor.

3. Observe que a instalação do servidor Web adiciona o WAS automaticamente.

4. Na tela Detailed Settings (Configurações detalhadas) do IIS, selecione ASP.NET e, em Security (Segurança), selecione Basic and Windows Authentication (Autenticação básica e do Windows). Mantenha o resto nas configurações padrão.

   Isso instalará o IIS e o WAS.

5. Por padrão, o Windows Server codinome Windows Server 2008 não vem com o .NET Framework 3.0 instalado. Para instalar o .NET Framework 3.0, abra o Add Features Wizard (Assistente para adição de recursos) (Painel de Controle | Programas | Windows Resources (Recursos do Windows).

6. Clique em Add Features (Adicionar recursos) e selecione .NET Framework 3.0 (para experimentar o transporte MSMQ do WCF). Selecione também MSMQ.

Agora, está tudo pronto para executar seus serviços WCF no IIS 7.0. A próxima etapa é criar um aplicativo no IIS para executar seu serviço. Para isso, é necessário usar o Gerenciador dos Serviços de Informações da Internet (IIS). Para obter a ferramenta de gerenciamento do IIS, vá para Ferramentas Administrativas, no menu Iniciar. Em seguida, navegue até seu servidor, os seus sites e, finalmente, o seu site Web padrão. Clique com o botão direito do mouse no site Web padrão e selecione Adicionar Aplicativo, como ilustra a Figura 5-15.

Figura 5-15. Criando um novo aplicativo no Gerenciador do IIS

Agora, você precisa de uma pasta no computador local em que deseja hospedar os arquivos .svc de aplicativo. Conforme ilustra a Figura 5-16, você pode dar um nome ao aplicativo em que o serviço pode ser atingido (http://localhost/<nomeescolhido>) e a pasta em que os arquivos residem, e selecionar o pool de aplicativos.

Figura 5-16. Configurando as propriedades para um novo aplicativo no Gerenciador do IIS

Se você fez tudo corretamente, seu serviço estará acessível pelo IIS 7.0. Faça um teste, navegando até o novo aplicativo criado, por exemplo.

http://localhost:8080/QuickReturns/Exchange.svc/ExchangeService

Serviços de Ativação do Windows

O WAS permite hospedar qualquer serviço WCF, oferecendo suporte a qualquer transporte dentro do modelo IIS. O WAS assume a criação de processos de trabalho e fornece a configuração do serviço do Windows W3svc.exe original que você conhece do IIS 6.0 (e executa dentro do processo Inetinfo.exe). O WAS e o IIS agora compartilham o armazenamento de configuração que define sites, aplicativos, pools de aplicativos e diretórios virtuais. Nesta seção, descreveremos o processo de ativação com o WAS, como mostra a Figura 5-17.

Por padrão, quando nenhuma solicitação é feita para um servidor iniciado recentemente, o Windows executa cinco serviços (se todos os protocolos estiverem habilitados). Esses serviços do Windows são os seguintes:

• WAS

• Serviço de Publicação na World Wide Web (hospedando o adaptador de escuta)

• Adaptador de escuta NET.TCP

• Adaptador de escuta NET.PIPE

• Adaptador de escuta NET.MSMQ

Figura 5-17. Ativação de processos de trabalho com WAS para uma solicitação HTTP

Quando os adaptadores de escuta iniciam, fazem o registro no WAS e recebem a configuração do WAS/IIS para seus protocolos específicos. Dessa forma, os adaptadores de escuta tomam conhecimento dos sites e dos aplicativos aos quais devem oferecer suporte. Cada adaptador de escuta começa a escutar as portas apropriadas fornecidas com a configuração e, assim, podem expedir as solicitações recebidas para o aplicativo apropriado.

Assim que entrar a primeira solicitação, o adaptador de escuta chamará o WAS para ativar o processo de trabalho, incluindo um domínio de aplicativo .NET para o aplicativo específico ao qual é destinada a solicitação.

A solicitação é repassada para o chamado manipulador de protocolo de domínio de aplicativo dentro do processo de trabalho para manipular a solicitação e retornar a resposta ao cliente. Não importa se a solicitação é de um serviço WCF, ASP.NET ou outro para IIS 7.0. O processo de ativação é criado para permitir que os processos de trabalho sejam iniciados quando a solicitação chega.

Para iniciar o ServiceHost do WCF dentro do domínio de aplicativo, o manipulador de protocolo de domínio de aplicativo deve chamar o método estático conhecido como EnsureServiceAvailable. Esse método é indiferente a protocolo e ativa o serviço inteiro, incluindo todos os pontos de extremidade e transportes (e não apenas o transporte para o manipulador de protocolo que chama o método).

Observação Dentro dos adaptadores de escuta e manipuladores de protocolo, acontece algo realmente incrível com HTTP e TCP em particular. Os soquetes são abertos dentro dos adaptadores de escuta hospedados em um processo separado. Então, quando a primeira solicitação chega, o soquete virtualmente passa do adaptador de escuta para o manipulador de protocolo de domínio de aplicativo, a fim de poder manipular a primeira solicitação e as subseqüentes!

Opções de hospedagem

Na seção anterior deste capítulo, você aprendeu as diferentes opções existentes para hospedar seus serviços. Além disso, você aprendeu quais requisitos comerciais (ou não-funcionais) podem ser abordados em cada cenário de hospedagem. Em geral, você pode aplicar uma abordagem do tipo: "Por que não IIS?". O que queremos dizer com isso? O IIS fornece a melhor compatibilidade em termos de recursos, em especial, nos cenários em que seus serviços expõem as principais funcionalidades da empresa das quais vários sistemas dependem. Quando optar pelo IIS e tiver de escolher entre o IIS 6.0 e o IIS 7.0, obviamente, você deverá ficar com o último por causa dos novos recursos de ativação. Nos cenários em que é necessária a comunicação entre processos, os aplicativos WinForms e os de console são opções viáveis. Os serviços do Windows são basicamente a única alternativa para o IIS e, em geral, são usados quando se cria um produto de servidor ou é necessário um controle avançado sobre a ativação e a duração dos serviços.

Na próxima seção, veremos quais são as opções disponíveis para consumir seus serviços e o que a opção de hospedagem significa para o lado do consumidor.

Consumindo serviços WCF

Nas seções anteriores, você aprendeu sobre as diferentes opções de hospedagem disponíveis. O cenário de hospedagem escolhido pode ter sua influência no lado do consumidor. Você pode consumir serviços WCF de diversas maneiras. Se estiver usando WCF no lado do cliente, será muito produtivo porque o WCF vem com ferramentas que podem gerar classes de proxy para chamar serviços WCF. O WCF fornece os padrões e as ferramentas para oferecer suporte basicamente por meio do SvcUtil.exe. Você o usará como a ferramenta básica de interpretação de dados. Isso, aliado à capacidade da estrutura do WCF de aproveitar a reflexão para interrogar tipos adornados com atributos apropriados, tornam a geração e o uso da estrutura do WCF menos complicados que as estruturas existentes. Além disso, o Visual Studio 2005 vem com recursos fáceis de usar para adicionar referências de serviço aos projetos e gerar diretamente as classes de proxy para você.

Basicamente, você tem as seguintes opções:

• Recuperar o WSDL do serviço e programar um proxy para chamar o serviço. Esse é o cenário típico quando não se tem o WCF no lado do cliente. Para este cenário, consulte o Capítulo 13.

• Usar os recursos do Add Service Reference (Adicionar referência de serviço) do Visual Studio 2005 e permitir que ele gere um proxy para ser usado no seu cliente.

• Usar a ferramenta SvcUtil.exe para gerar classes de proxy.

Nos cenários a seguir, veremos as duas últimas opções: o Visual Studio 2005 e o SvcUtil.exe.

Proxies de serviço

Um service proxy permite trabalhar com serviços de forma orientada ao objeto. As classes de proxy abstraem o modelo de comunicação usado pelo serviço, de forma que você, como desenvolvedor de cliente, não seja diretamente informado de que está se comunicando com um serviço (remoto). É como se você chamasse um código local. A classe de proxy implementa a interface do serviço e permite que você chame os métodos na interface, como se fossem locais. Os proxies são gerados para qualquer tipo personalizado que seja usado na interface de serviço. A Listagem 5-11 contém peças de um proxy gerado para o serviço TradeService no exemplo QuickReturns Ltd. Ele ilustra que, no lado do cliente, há um Quote disponível que é mapeado para o objeto Quote no lado do servidor, embora sejam classes distintas. O objeto Quote serializa de acordo com o contrato, de forma que ele pode ser serializado na versão do lado do serviço do contrato de dados Quote. Além disso, é possível ver os métodos GetQuote e PlaceQuote chamando uma classe de base que, finalmente, fará a chamada no limite de serviço pelo transporte configurado.

Listagem 5-11. Proxy de exemplo gerado para o serviço TradeService

namespace SimpleClientWithProxy.ExchangeService
{
   [DataContract()]
   public partial class Quote : object, IExtensibleDataObject
   {
      // Left out the Quote Datamembers in printed code, see sample 
code
   }
}

[GeneratedCode("System.ServiceModel", "3.0.0.0")]
[ServiceContract()]
public interface ITradeService
{
   [
      OperationContract(Action = 
"http://tempuri.org/ITradeService/GetQuote",
         ReplyAction = 
"http://tempuri.org/ITradeService/GetQuoteResponse")]
   Quote GetQuote(string ticker);

   [
      OperationContract(Action = 
"http://tempuri.org/ITradeService/PublishQuote",
         ReplyAction = 
"http://tempuri.org/ITradeService/PublishQuoteResponse")]
   void PublishQuote(Quote quote);
}

[GeneratedCode("System.ServiceModel", "3.0.0.0")]
public interface ITradeServiceChannel : ITradeService, IClientChannel
{
}

[GeneratedCode("System.ServiceModel", "3.0.0.0")]
public partial class TradeServiceClient : ClientBase<ITradeService>, 
ITradeService
{
   // Left out some constructors in printed code, see sample code

   public SimpleClientWithProxy.ExchangeService.Quote
      GetQuote(string ticker)
   {
      return base.Channel.GetQuote(ticker);
   }

   public void PublishQuote(
      SimpleClientWithProxy.ExchangeService.Quote quote)
   {
      base.Channel.PublishQuote(quote);
   }
}


	

Usando o Visual Studio 2005

Semelhante à criação de proxy ASP.NET, se você clicar com o botão direito do mouse no projeto do IDE, verá três opções para adicionar referências, como mostra a Figura 5-18.

Figura 5-18. Adicionando uma referência a um serviço WCF

A opção que você procura é Add Service Reference. Esta opção de menu é um invólucro do utilitário SvcUtil.exe (que é explicado na próxima seção), que realmente gera um processo com os parâmetros necessários. Ao selecionar Add Service Reference, você verá a caixa de diálogo mostrada na Figura 5-19.

Figura 5-19. Caixa de diálogo Add Service Reference

Ao clicar em OK na caixa de diálogo, o complemento cria o SvcUtil.exe, gerando a classe de proxy e o arquivo de configuração necessários (ou modificando-o) e adicionando as referências necessárias ao projeto. As referências do projeto agora serão listadas nos assemblies do WCF.

Observação Para que isso funcione, é necessário que o ServiceHost do Windows esteja em execução ou que a URL seja alterada a fim de que aponte para qualquer serviço hospedado no IIS (uma URL apontando para um dos arquivos .svc).

Agora você está pronto para programar sua primeira chamada na camada de serviço. O arquivo da solução do exemplo foi modificado das seguintes maneiras, para ajudá-lo a analisar o código:

• Set Startup Projects na solução tem vários projetos selecionados.

• No projeto Web ExchangeServiceIISHost, Use dynamic ports está definido como false e Port Number tem uma configuração de código embutido.

É necessária uma breve explicação dos objetos adicionados ao projeto. Durante a chamada de SvcUtil.exe (Add Service Reference), adicionamos automaticamente os itens e as referências a seguir ao projeto. Alguns servem apenas para ajudar a integração do Visual Studio; outros são necessários para o uso direto do serviço por meio do proxy.

• Service references: dentro dessa pasta, adicionamos dois itens. Primeiro, um arquivo de "mapa" oferece suporte para a geração e regeneração de proxy por meio do complemento do Visual Studio. Depois, o ExchangeService.cs representa a implementação concreta da classe de proxy que aproveita o namespace System.ServiceModel para fornecer uma classe de integração simples.

• Configuração: o segundo item é o arquivo App.config. Um arquivo App.config (automaticamente renomeado durante o processo de criação do Visual Studio como <assembly name>.config) fornece os parâmetros de configuração de tempo de execução do WCF. O que você notará se olhar dentro desse arquivo é uma grande quantidade de configurações, muitas das quais são padronizadas ou supérfluas. Uma abordagem geral é gerar o arquivo e gerenciá-lo usando o utilitário de edição SvcConfigEditor.exe do WCF. Esse utilitário é localizado no diretório SDK Bin do Windows. Também é possível encontrá-lo no menu Ferramentas do Visual Studio. A Figura 5-20 mostra a implementação da ferramenta.

Figura 5-20. SvcConfigEditor.exe

Como você pode ver na tela do SvcConfigEditor.exe na Figura 5-20, é possível gerenciar uma grande quantidade de propriedades detalhadas na configuração. Essa é uma das grandes qualidades do WCF: a capacidade de controlar vários aspectos de uma implementação sem afetar a implementação principal do serviço. Um exemplo é o conceito de que a implementação de um serviço não ser alterada para migrar de um protocolo baseado em HTTP para outro orientado a mensagens. Para obter mais informações sobre os recursos da ferramenta, consulte o Capítulo 3, o Capítulo 6 deste livro ou a ajuda do MSDN.

Implementação da linha de comando

Um método alternativo é aproveitar o utilitário SvcUtil.exe diretamente, em vez do complemento do Visual Studio. Novamente, o complemento do Visual Studio chama o SvcUtil.exe, com parâmetros, para gerar o proxy ao ser executado diretamente do programa. Você pode ver a linha de comando e os resultados disso exibindo a janela Saída e definindo Show output na lista suspensa como Service Reference.

Para gerar manualmente, escolha a janela CMD, selecionando Iniciar | Todos os Programas | Microsoft Windows SDK | CMD. Esse prompt de comando é útil porque seu caminho é definido como o diretório binário em que as ferramentas e os utilitários do SDK estão localizados.

Você usará a ferramenta da linha de comando SvcUtil.exe para gerar duas saídas que poderiam ser usadas no projeto SimpleClientWithProxy. Entretanto, o código de exemplo que vem com este capítulo usou o método Add Service Reference descrito na seção anterior. As etapas descritas aqui explicam como gerar as mesmas saídas que Add Service Reference. Os arquivos de saída que ele gera são o arquivo de código-fonte de proxy do cliente e o arquivo de configuração de aplicativo. Esses arquivos são mesclados no projeto cliente. O SvcUtil.exe pode gerar os dois. Para este exemplo, o seguinte comando (é uma única linha, apesar do que é mostrado aqui) produz uma um arquivo de classe proxy e de configuração:

Listagem 5-12. Comando para produzir o arquivo de classe proxy e de configuração

svcutil /config:app.config /out:"ExchangeService.cs" /language:csharp 
/n:*,
SimpleClientWithProxy.ExchangeService 
"http://localhost/ExchangeService/?
ExchangeService.svc"

	

CUIDADO Para este trabalho, é necessário que uma versão do ServiceHost do Windows esteja em execução ou que a URL seja alterada a fim de que aponte para qualquer serviço hospedado no IIS (uma URL apontando para um dos arquivos .svc discutidos neste capítulo). Além disso, seu serviço requer o ponto de extremidade metadataexchange, conforme descrito no Capítulo 3. No código que vem com este capítulo, esse ponto de extremidade está configurado, mas fica fora do código embutido neste capítulo!

O comando é bastante auto-explicativo. O comutador /n indica em qual namespace deverá ficar a classe de proxy gerada. O último parâmetro é a URL do ponto de extremidade do serviço em que estão as informações de esquema. Observe que ?wsdl pode ser substituído por ?mex, porque o SvcUtil.exe oferece suporte para os dois métodos de descoberta. Você pode obter mais ajuda executando svcutil.exe /? Do prompt de comando.

A próxima etapa é pegar os arquivos de saída ExchangeService.cs e App.config e mesclá-los no projeto. Você pode apenas adicionar o primeiro arquivo, ExchangeService.cs, diretamente ao projeto escolhendo Add Existing Item (Adicionar Item Existente) do menu Project (Projeto) no Visual Studio 2005.

Você deve adicionar o segundo arquivo ao projeto como arquivo de configuração de aplicativo (App.config). Se o projeto não tiver o arquivo App.config, você pode adicioná-lo escolhendo novamente Add Existing Item no menu Project. Se já existir um App.config, você deve mesclar a seção system.serviceModel, assegurando-se de pegar todos os elementos filho apropriados.

Conclusão

Agora que conhece tudo sobre as alternativas de hospedagem, você pode criar aplicativos WCF e hospedá-los em qualquer lugar que desejar. Além disso, você pode explicar os benefícios de hospedagem no ambiente mais recente disponível, o IIS 7.0 no Windows Vista ou no Windows Server codinome Windows Server 2008 com o WAS.

Sobre os autores

Chris Peiris é um ávido editor no espaço de integração de aplicativo. Ele trabalha para a Avanade Austrália como Arquiteto de Soluções. Faz palestras freqüentes em conferências de desenvolvedores profissionais sobre tecnologias da Microsoft. Chris já escreveu muitos artigos, resenhas e colunas para várias publicações online, incluindo 15Seconds, ASPToday, Wrox (Apress) e Developer Exchange (DevX). Também é co-autor de diversos livros sobre WCF, serviços Web, UDDI, C#, IIS, Java e assuntos de segurança. Suas paixões atuais são WCF, WinFX, IBM Message Broker, BizTalk e outras implementações EAI. A lista completa de suas publicações e os detalhes para contato estão disponíveis em http://www.chrispeiris.com/.

Dennis Mulder começou sua carreira em 1997, decidindo dedicar-se à tecnologia Microsoft. Em agosto de 2004, começou a trabalhar para a Avanade, um empreendimento conjunto entre a Microsoft e a Accenture. Atualmente, está interessado em algumas áreas da plataforma Microsoft, especificamente de orientação a serviços, integração e fábricas de software. Como consultor estabelecido nos Países Baixos, Dennis trabalha com clientes empresariais para resolver seus desafios, aproveitando o poder da plataforma Microsoft. Dennis faz palestras freqüentes em conferências da Microsoft holandesa e grupos de usuários, e tornou-se um palestrante INETA desde 2006. Ele pode ser contatado pelo email dennism@avanade.com ou por seu blog em http://www.dennismulder.net/.

A Avanade é uma consultora de TI global dedicada a usar a plataforma Microsoft para ajudar as empresas a alcançarem um crescimento lucrativo. Por meio de soluções comprovadas que estendem as tecnologias da Microsoft, a Avanade ajuda as empresas a aumentarem receita, reduzirem os custos e reinvestirem em inovação para ganhar uma vantagem competitiva. Nossos consultores agregam valor a cada cliente de acordo com os requisitos, os prazos e o orçamento de cada um, combinando inteligência, inovação e o talento de nossa força de trabalho global. Para obter mais informações, visite http://www.avanade.com/.