Hospedando e Consumindo Serviços WCF.: Artigos Técnicos Sobre o Windows Vista

Hospedando e consumindo serviços WCF. https://msdn.microsoft.com/pt-br/library/bb332338(d=printer).
aspx
Hospedando e consumindo serviços WCF.

Artigos técnicos sobre o Windows Vista.
Publicado em: 10 de abril de 2007
Por Chris Peiris, Dennis Mulder
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
1 de 33 03/12/2015 22:07
Hospedando e consumindo serviços WCF. https://msdn.microsoft.com/pt-br/library/bb332338(d=printer).aspx
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
Inicio da pagina
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:
2 de 33 03/12/2015 22:07
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.
3 de 33 03/12/2015 22:07
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
4 de 33 03/12/2015 22:07
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.
Inicio da pagina
Hospedando internamente seu serviço
5 de 33 03/12/2015 22:07
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
{
6 de 33 03/12/2015 22:07
[ServiceContract()]
interface ITradeTrackingService
{
[OperationContract()]
void PublishQuote(Quote quote);
}
}
Inicio da pagina
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.ServiceProcess;
using QuickReturns.StockTrading.ExchangeService;
7 de 33 03/12/2015 22:07
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:
8 de 33 03/12/2015 22:07
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.
9 de 33 03/12/2015 22:07
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:
10 de 33 03/12/2015 22:07
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
11 de 33 03/12/2015 22:07
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.
Inicio da pagina
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
12 de 33 03/12/2015 22:07
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.
13 de 33 03/12/2015 22:07
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
14 de 33 03/12/2015 22:07
<%@ServiceHost Language="C#"
Service="QuickReturns.StockTrading.ExchangeService.TradeServiceInline"
%>
using System;
using System.Collections;
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"
15 de 33 03/12/2015 22:07
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
16 de 33 03/12/2015 22:07
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.Activation;
{
public class TradeServiceCustomHostFactory : ServiceHostFactory
{
protected override ServiceHost CreateServiceHost(
Type serviceType, Uri[] baseAddresses)
{
TradeServiceCustomHost customServiceHost =
new TradeServiceCustomHost(serviceType, baseAddresses);
return customServiceHost;
}
}
public class TradeServiceCustomHost : ServiceHost

{
17 de 33 03/12/2015 22:07
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, é
18 de 33 03/12/2015 22:07
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
{
[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single,
ReturnUnknownExceptionsAsFaults=true)]
[AspNetCompatibilityRequirements(
RequirementsMode=AspNetCompatibilityRequirementsMode.Allowed)]
public class TradeService : ITradeService
{
...
19 de 33 03/12/2015 22:07
}
}
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.
20 de 33 03/12/2015 22:07
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.
21 de 33 03/12/2015 22:07
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.
22 de 33 03/12/2015 22:07
Figura 5-13. Caixa de diálogo Editar alias em Compartilhamento na Web
a. 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.
b. 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
23 de 33 03/12/2015 22:07
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.
24 de 33 03/12/2015 22:07
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.
25 de 33 03/12/2015 22:07
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
26 de 33 03/12/2015 22:07
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
27 de 33 03/12/2015 22:07
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.
Inicio da pagina
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
28 de 33 03/12/2015 22:07
{
// 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);
}
public interface ITradeServiceChannel : ITradeService, IClientChannel
{
}
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
29 de 33 03/12/2015 22:07
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.
30 de 33 03/12/2015 22:07
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
31 de 33 03/12/2015 22:07
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.
Inicio da pagina
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
32 de 33 03/12/2015 22:07
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 [email protected] 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/.
Inicio da pagina
© 2015 Microsoft
33 de 33 03/12/2015 22:07

Hospedando e Consumindo Serviços WCF.: Artigos Técnicos Sobre o Windows Vista

Enviado por

Direitos autorais:

Formatos disponíveis

Hospedando e Consumindo Serviços WCF.: Artigos Técnicos Sobre o Windows Vista

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Hospedando e Consumindo Serviços WCF.: Artigos Técnicos Sobre o Windows Vista

Enviado por

Direitos autorais:

Formatos disponíveis

Hospedando e consumindo serviços WCF. https://msdn.microsoft.com/pt-br/library/bb332338(d=printer).

Hospedando e consumindo serviços WCF.

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

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

Microsoft .NET Framework 3.0

Microsoft Internet Information Services

Microsoft Visual Studio 2005

Baixar o código de exemplo.

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

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

Aplicativos Web (ASP.NET) hospedados no IIS

Hospedagem interna em qualquer aplicativo gerenciado .NET

Hospedagem em um serviço do Windows

Hospedagem em versões diferentes do IIS

Compreendendo os domínios do aplicativo .NET

Os principais benefícios são os seguintes:

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

Recursos do ambiente de hospedagem

O relacionamento entre os processos e os domínio do aplicativo é semelhante ao relacionamento entre os aplicativos e

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

Requisitos do ambiente de hospedagem

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

As vantagens da hospedagem interna são as seguintes:

As desvantagens da hospedagem interna são as seguintes:

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

Listagem 5-1. ServiceContract para o TradeTrackingService

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

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

protected override void OnStart(string[] args)

protected override void OnStop()

As vantagens são as seguintes:

Gerenciamento: Em geral, os operadores do Windows conhecem profundamente o Gerenciador de Controle de Serviço

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

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

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.

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.

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

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

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

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.

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

4. Crie o projeto de configuração.

Principais recursos do IIS 5.1 e 6.0

Figura 5-9. Arquitetura principal do IIS 6.0

Hospedando serviços WCF no IIS

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

public void PublishQuote(Quote quote)

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

<% @ServiceHost language="C#"

Configurando serviços WCF no IIS

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