Introdução
Serviços WCF e WF no .NET Framework 4.0 e “Dublin”
Aaron Skonnard
Este artigo se baseia em uma versão de pré-lançamento do .NET Framework 4.0 e "Dublin". Todas as informações estão sujeitas a alterações.
Este artigo aborda:
|
Este artigo usa as seguintes tecnologias: .NET Framework 4.0, “Dublin” |
Sumário
Na direção do .NET Framework 4.0
Biblioteca de atividades básicas do WF
Modelo de programação de atividades do WF
Mais novos recursos do WCF no .NET Framework 4.0
A necessidade de "Dublin"
Um guia para "Dublin"
Criando um serviço de fluxo de trabalho do WCF para "Dublin"
Implantando aplicativos com "Dublin"
Gerenciamento de aplicativos em execução
Atualização de aplicativos em execução
Monitoramento de aplicativos em execução
De "Dublin" a "Oslo"?
E quanto ao BizTalk Server?
Na Conferência dos Desenvolvedores Profissionais (PDC) em outubro de 2008, a Microsoft divulgou os detalhes sobre várias melhorias que acompanharão o Microsoft .NET Framework 4.0, especificamente nas áreas do Windows Communication Foundation (WCF) e do Windows Workflow Foundation (WF). A Microsoft também apresentou algumas extensões para o Windows Server — intituladas "Dublin" — que fornecem uma experiência aprimorada de hospedagem e gerenciamento para os aplicativos WCF e WF.
A integração do WF e do WCF no .NET Framework 4.0 tornará mais simples o desenvolvimento de aplicativos distribuídos orientados a serviços. Será possível criar serviços de fluxo de trabalho com monitoração de estado usando um modelo completamente declarativo que oferece mais flexibilidade e agilidade nos negócios.
As novas extensões de hospedagem e gerenciamento apresentadas pelo "Dublin" complementam esses avanços de estrutura. A combinação de avanços na estrutura em si e nas ferramentas operacionais que oferecem suporte à estrutura significa que a funcionalidade do servidor de aplicativos no Windows Server dará um grande passo à frente.
Neste artigo, explorarei alguns dos principais novos recursos WCF e WF do .NET Framework 4.0, bem como as novas funcionalidades do servidor de aplicativos oferecidas pelas extensões “Dublin”.
Na direção do .NET Framework 4.0
O WCF e o WF são tecnologias complementares. Se você não estiver familiarizado com elas, uma maneira simples de pensar a respeito é: WCF na parte externa, WF na parte interna. O WCF é usado para expor a interface de serviço externa de um aplicativo e o WF é usado para descrever o fluxo, estados e transições internos de um aplicativo.
O .NET Framework 3.5 apresentou algumas integrações atraentes entre os dois, especificamente na forma das atividades Send e Receive do WF. Com essas atividades, é possível empregar o WF para simplificar o processo de coordenação de várias interações de serviços para atender a fluxos de trabalho complexos e de longa duração. É possível também usar essas atividades para estender o alcance dos seus fluxos de trabalho do WF habilitando-os com pontos de extremidade do WCF (consulte a Figura 1). Essencialmente, isso permite empregar o WF como a implementação dos seus serviços do WCF, que chamarei de serviços de fluxo de trabalho do WCF ao longo deste artigo.
Figura 1 Serviços de fluxo de trabalho do WCF
Embora seja possível implementar os serviços de fluxo de trabalho do WCF no .NET Framework 3.5, isso não é fácil. Para começar, a camada de integração entre o WCF e o WF deixa a desejar. No .NET Framework 3.5, os artefatos do WCF devem ser definidos e configurados usando o modelo de programação e configuração do WCF, enquanto o fluxo de trabalho é definido usando um modelo diferente. Por fim, o resultado são vários artefatos que devem ser implantados, configurados e gerenciados separadamente.
Outro motivo da dificuldade é o fato de a biblioteca de atividades básica atual se concentrar em atividades de controle de fluxo e lógica e não oferecer muito a respeito das atividades de trabalho. Portanto, é necessário escrever uma biblioteca de atividades personalizadas antes de ser possível implementar serviços de fluxo de trabalho do mundo real com o WF. Dada a complexidade do trabalho, alguns desenvolvedores desistiram antes de poderem aproveitar os benefícios do WF.
Além desses problemas, o WF atual também não oferece suporte de ferramenta a fluxos de trabalho somente de eXtensible Application Markup Language (XAML), que também são chamados de fluxos de trabalho declarativos porque são completamente descritos no arquivo XML sem nenhum arquivo code-behind. A abordagem somente de XAML cria algumas possibilidades atraentes de hospedagem e implantação de fluxo de trabalho. O poder de um fluxo de trabalho declarativo é que são somente dados, que podem ser armazenados em qualquer lugar e executados em um ambiente de tempo de execução do WF que conhece as atividades em uso.
Um fluxo de trabalho declarativo pode ser implantado em um tempo de execução na nuvem ou em uma estação de trabalho na sua mesa (supondo que as atividades tenham sido implantadas no host do tempo de execução). Fluxos de trabalho declarativos também têm um controle de versão mais fácil e podem ser usados em cenários de confiança parcial (pense em "nuvem"). O modelo somente de XAML também é mais fácil para construir ferramentas já que as ferramentas trabalham somente com arquivos XML.
No geral, o modelo somente de XAML sempre tem a visão definitiva do WF como uma tecnologia, o que fica evidente nos primeiros textos de seus arquitetos. No entanto, o suporte de ferramenta atual do WF não reconhece totalmente essa visão. Embora seja possível criar fluxos de trabalho somente de XAML com o .NET Framework 3.5, é necessário encontrar uma solução alternativa para os modelos atuais do Visual Studio e desistir de recursos importantes, como a depuração.
O objetivo principal do WCF e do WF no .NET Framework 4.0 é simplificar a experiência do desenvolvedor acerca de fluxos de trabalho e serviços declarativos, adotando totalmente um modelo somente de XAML. Além disso, a Microsoft queria dar um passo à frente tornando possível definir serviços de fluxo de trabalho declarativos. Ou seja, os serviços do WCF que são totalmente definidos em termos de XAML, incluindo as definições de contrato de serviço, configurações de ponto de extremidade e a implementação de serviço real (na forma de um fluxo de trabalho baseado em XAML).
Para fazer isso, a Microsoft fez inúmeras melhorias no .NET Framework 4.0, incluindo uma biblioteca de atividades de classe básica estendida, um modelo mais simples de programação de atividades personalizadas, um novo tipo de fluxo de trabalho de fluxograma e inúmeras melhorias específicas do WCF.
A biblioteca de atividades básica do WF
O .NET Framework 4.0 vem com uma biblioteca de atividades básica aprimorada contendo várias novas atividades (consulte a Figura 2). A Microsoft também planeja começar a tornar disponíveis atividades adicionais do WF por meio do CodePlex entre lançamentos principais do .NET Framework. Também será possível começar a observar mais atividades de trabalho (como a atividade PowerShellCommand) sendo exibidas em lançamentos futuros (ou no CodePlex) reduzindo, assim, a necessidade do desenvolvimento de atividades personalizadas. Como a Microsoft está usando o CodePlex, você tem uma boa oportunidade de dar sua opinião sobre as atividades adicionais que gostaria de ver.
.gif)
O .NET Framework 4.0 apresenta algumas atividades principais que oferecem mais opções de controle de fluxo, incluindo as atividades FlowChart, ForEach, DoWhile e Break. A nova atividade FlowChart é uma das adições mais interessantes porque oferece um bom meio-termo entre os modelos de controle de fluxo Sequential e StateMachine. A FlowChart permite usar uma abordagem passo a passo aprimorada com decisões e opções simples, mas que permite retornar a atividades anteriores no fluxo de trabalho. Os fluxogramas, em geral, parecem mais intuitivos para muitos usuários. A Figura 3 mostra a aparência do designer FlowChart no novo designer de fluxo de trabalho no Visual Studio 2010 (consulte a barra lateral “O novo Workflow Designer” para saber mais).
.gif)
Figura 3 O novo designer de atividades FlowChart
O .NET Framework 4.0 também apresenta algumas novas atividades de tempo de execução para invocar métodos CLR (MethodInvoke), atribuir valores a variáveis de fluxo de trabalho (Assign) e manter explicitamente uma instância de fluxo de trabalho em execução (Persist).
Por fim, o .NET Framework 4.0 vem com um novo conjunto de atividades baseadas no WCF que simplificam o processo de exposição de fluxos de trabalho como serviços ou de consumo de serviços de dentro de seus fluxos de trabalho. O .NET Framework 3.5 forneceu duas atividades — Send e Receive — para enviar e receber mensagens por meio do WCF. Na versão 4.0, você encontrará as atividades SendMessage e ReceiveMessage— destinadas a enviar e receber mensagens em um único sentido (de maneira semelhante a Send e Receive na versão 3.5) — bem como uma abstração em nível mais alto para operações de solicitação/resposta por meio das atividades ClientOperation e ServiceOperation. Um fluxo de trabalho que deseja expor uma operação de serviço deve usar a atividade ServiceOperation. Já um fluxo de trabalho que deseja consumir um serviço externo deve usar a atividade ClientOperation.
Além dessas atividades principais do WCF, o .NET Framework 4.0 também oferece suporte à correlação entre diferentes operações de um único sentido para garantir que uma mensagem específica volte para a instância de fluxo de trabalho correta. Ele vem com uma atividade para definir um novo escopo de correlação (CorrelationScope) e para inicializar os valores de correlação (InitializeCorrelation) antes de enviar uma mensagem de saída por meio do WCF.
O novo Workflow Designer
Um novo designer de fluxo de trabalho adicionado ao Visual Studio 2010 oferece uma experiência de usuário gráfica atraente para muitos dos recursos principais do WCF e WF discutidos neste artigo. Ele fornece recursos como uma navegação de fluxo de trabalho aprimorada (detalhando atividades compostas) com trilhas simples para voltar ao escopo, edição de atividades in loco (reduzindo a necessidade da janela Properties), funcionalidades de zoom e navegação de visão geral. Além disso, o novo designer oferece um modelo aprimorado para personalização e re-hospedagem. O Visual Studio 2010 também oferece um conjunto de modelos de projeto novos ou aprimorados que tornarão mais fácil começar rapidamente fluxogramas e fluxos de trabalho somente de XAML e oferecerá suporte total à depuração baseada em XAML ao se trabalhar com fluxos de trabalho e serviços declarativos.
Modelo de programação de atividades do WF
Mesmo com essas melhorias, às vezes ainda pode ser necessário escrever atividades personalizadas. Para tornar isso mais fácil, a Microsoft reformulou as classes base para atividades personalizadas. A nova classe base para atividades personalizadas é chamada de WorkflowElement e há outra classe que deriva dela, chamada Activity. A classe Activity torna fácil criar novas atividades personalizadas a partir de atividades existentes sem escrever códigos ou escrever poucos.
A Figura 4, por exemplo, mostra como definir uma nova atividade personalizada chamada CopyFile derivando de Activity e substituindo CreateBody. A implementação cria uma instância PowerShellCommand personalizada configurada para usar o comando copy-item interno. É possível também criar facilmente atividades personalizadas como essa usando o novo designer de fluxo de trabalho no Visual Studio 2010 por meio do designer de atividade gráfico, se preferir evitar totalmente esse tipo de código.
Figura 4 Uma atividade CopyFile personalizada
class CopyFile : Activity
{
public InArgument<string> Source { get; set; }
public InArgument<string> Destination { get; set; }
protected override WorkflowElement CreateBody()
{
return new PowerShellCommand
{
CommandText = "copy-item",
Parameters =
{
{ "path", new InArgument<string>(Source) },
{ "destination", new InArgument<string>(Destination) } ,
{ "recurse", new InArgument<bool>(false) }
},
};
}
}
Quando for necessário definir uma atividade personalizada do zero (algo que não seja baseado em atividades existentes), será necessário derivar de WorkflowElement e substituir o método Execute. Essa abordagem exige um pouco mais de código e é semelhante a como funciona a derivação de Activity atualmente. No entanto, a Microsoft simplificou ainda mais as coisas a respeito de escrever essas atividades personalizadas.
Uma das coisas que torna difícil escrever uma atividade personalizada é gerenciar o fluxo de dados da atividade e para ela. Por exemplo, atualmente não é possível definir um conjunto de argumentos digitados que sejam passados de uma atividade e para ela. Normalmente, os desenvolvedores escrevem classes personalizadas que serializam e desserializam os argumentos de uma fila de fluxo de trabalho (para saber mais, consulte o artigo de Michael Kennedy, "Aplicativos Web que dão suporte a operações de longa duração"). Escrever esse código de direcionamento não é difícil, mas é um trabalho extra que se desvia do objetivo principal de modelar o fluxo do aplicativo. O .NET Framework 4.0 estende o modelo de programação de atividade com três novos conceitos de fluxo de dados que prometem simplificar significativamente as coisas: argumentos, variáveis e expressões.
Argumentos são usados para definir como os dados fluem de uma atividade e para ela. Cada argumento tem uma direção de ligação específica, como entrada, saída ou entrada/saída. O exemplo a seguir mostra como criar uma atividade Audit simples com um único argumento de entrada chamado "AuditMessage":
public class Audit: WorkflowElement {
public InArgument<string> AuditMessage{ get; set; }
protected override void Execute(ActivityExecutionContext context) {
WriteToEventLog(AuditMessage.Get(context));
}
}
As variáveis fornecem uma maneira de declarar o armazenamento nomeado de dados. É possível definir variáveis em código, bem como em fluxos de trabalho baseados em XAML. As variáveis também podem ser definidas em escopos diferentes dentro de um fluxo de trabalho (dentro de elementos de fluxo de trabalho aninhados) e são parte de uma definição de programa de fluxo de trabalho em tempo de design, enquanto os valores são armazenados na instância do fluxo de trabalho em tempo de execução.
O exemplo a seguir mostra como escrever um fluxo de trabalho XAML que define uma mensagem nomeada de variável, atribui um valor a ela (usando a nova atividade Assign) e passa o valor da variável para a atividade Audit personalizada definida anteriormente:
<Sequence
xmlns="https://schemas.microsoft.com/netfx/2009/xaml/workflowmodel"
xmlns:p="https://schemas.microsoft.com/netfx/2008/xaml/schema"
xmlns:s="clr-namespace:Samples;assembly=Samples"
xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml">
<Sequence.Variables>
<Variable Name="message" x:TypeArguments="p:String" />
</Sequence.Variables>
<Assign x:TypeArguments="p:String" To="[message]"
Value="Audit message: something bad happened" />
<s:Audit Text="[message]" />
</Sequence>
Uma expressão é uma construção que considera um ou mais argumentos de entrada, executa alguma operação ou comportamento nesses argumentos de entrada e retorna um valor. Expressões são definidas derivando uma classe de ValueExpression, que por sua vez deriva de WorkflowElement. Portanto, expressões podem ser usadas em qualquer lugar em que uma atividade possa ser usada. As expressões também podem ser usadas como uma ligação para o argumento de outra atividade. Este exemplo define uma expressão Format simples:
public class Format : ValueExpression<string> {
public InArgument<string> FormatString { get; set; }
public InArgument<string> Arg { get; set; }
protected override void Execute(ActivityExecutionContext context) {
context.SetValue(Result,
String.Format(FormatString.Get(context), Arg.Get(context)));
}
}
É possível incorporar essa expressão nos seus fluxos de trabalho XAML como qualquer outra atividade. Por exemplo, o fluxo de trabalho a seguir ilustra como passar o resultado da expressão Format para a atividade Audit para escrever o resultado no log de eventos (isso supõe que o conteúdo de Audit é mapeado para o argumento de mensagem):
<Sequence
xmlns="https://schemas.microsoft.com/netfx/2009/xaml/workflowmodel"
xmlns:p="https://schemas.microsoft.com/netfx/2008/xaml/schema"
xmlns:s="clr-namespace:Samples;assembly=Samples"
xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml">
<Sequence.Variables>
<Variable Name="message" x:TypeArguments="p:String" />
</Sequence.Variables>
<s:Audit>
<s:Format FormatString="Audit message: {0}" Arg="[message]"/>
</s:Audit>
</Sequence>
Outro ponto importante é que não há nada de especial sobre a atividade raiz. Tudo que deriva de WorkflowElement pode ser usado na raiz ou em qualquer lugar dentro do fluxo de trabalho. Isso permite compor arbitrariamente estilos de fluxo de trabalho diferentes dentro uns dos outros (por exemplo, uma máquina de estado dentro de um fluxograma em uma seqüência).
A maioria dessas alterações no modelo de programação ajudam a tornar cidadãos de primeira classe os fluxos de trabalho declarativos porque não são mais necessários arquivos code-behind imperativos para definir as propriedades de fluxo de dados — isso pode ser feito agora declarativamente em XAML. No entanto, como essas alterações são bastante fundamentais, elas exigiram alterações significativas no tempo de execução do WF que acabam por interromper a compatibilidade com suas atividades do .NET Framework 3.x (consulte a barra lateral sobre migração de fluxos de trabalho para obter mais informações). No entanto, apesar disso, a Microsoft acredita que simplificar o modelo de programação do WF beneficiará muito os desenvolvedores do WF ao longo do tempo.
Migrando fluxos de trabalho para o .NET 4.0
O novo modelo de programação de atividade do .NET Framework 4.0 exigiu alterações significativas ao tempo de execução principal do WF. Como resultado, as atividades personalizadas criadas para o .NET Framework 3.0 e 3.5 não poderão ser executadas dentro do host de fluxo de trabalho do .NET Framework 4.0 sem alguns cuidados especiais.
Para facilitar a interoperabilidade, o .NET Framework 4.0 vem com uma atividade de interoperabilidade especial que torna fácil encapsular uma atividade personalizada do .NET 3.x dentro de um host do .NET 4.0. Essa abordagem não funciona para todas as atividades do .NET 3.x — ela não funciona especialmente para atividades raiz. Portanto, ao mudar para o Visual Studio 2010, será necessário recriar seus fluxos de trabalho usando o novo designer de fluxo de trabalho (porque ele também foi bastante alterado) e, em seguida, será possível encapsular suas atividades personalizadas do .NET 3.x usando a nova atividade de interoperabilidade de dentro de suas novas definições de fluxo de trabalho.
Mais recursos novos do WCF no .NET Framework 4.0
É fácil observar como um serviço WCF poderia ser implementado com um fluxo de trabalho, mas para verdadeiramente gerar um serviço de fluxo de trabalho declarativo também será necessária uma maneira de definir contratos de serviço e configurar definições de ponto de extremidade usando o modelo declarativo somente de XAML. É exatamente isso que o WCF no .NET Framework 4.0 oferece. Suponha que você tenha essa definição de contrato de serviço do WCF:
[ServiceContract]
public interface ICalculator
{
[OperationContract]
int Add(int Op1, int Op2);
[OperationContract]
int Subtract(int Op1, int Op2);
};
No .NET Framework 4.0, é possível definir o mesmo contrato declarativamente usando a seguinte definição XAML:
<ServiceContract Name="ICalculator">
<OperationContract Name="Add">
<OperationArgument Name="Op1" Type="p:Int32" />
<OperationArgument Name="Op2" Type="p:Int32" />
<OperationArgument Direction="Out" Name="res1" Type="p:Int32" />
</OperationContract>
<OperationContract Name="Subtract">
<OperationArgument Name="Op3" Type="p:Int32" />
<OperationArgument Name="Op4" Type="p:Int32" />
<OperationArgument Direction="Out" Name="res2" Type="p:Int32" />
</OperationContract>
</ServiceContract>
Agora que o contrato de serviço está definido no XAML, o próximo passo é definir como deseja projetar o contrato em trânsito. O .NET Framework 4.0 apresenta o conceito de uma projeção de contrato para separar a definição de contrato lógica da representação das mensagens que são enviadas e recebidas. Isso permite definir um contrato de serviço único que pode ser projetado de maneira diferente para oferecer suporte a diferentes estilos de mensagem.
Por exemplo, você pode ter uma projeção de contrato para mensagens baseadas em SOAP e outra projeção para mensagens de REST/POX, mas as duas são baseadas no mesmo contrato de serviço lógico. Veja como é possível definir uma projeção de contrato SOAP para o contrato de serviço recém-definido:
<Service.KnownProjections>
<SoapContractProjection Name="ICalculatorSoapProjection">
<!-- service contract definition goes here -->
</SoapContractProjection>
</Service.KnownProjections>
Com essa definição e projeção de contrato no lugar, será possível implementar a lógica de serviço em XAML. O elemento raiz da definição de serviço XAML é Service. O elemento Service contém as definições de contrato e projeção no elemento filho Service.KnownProjections. A implementação do serviço entra no elemento Service.Implementation (que é um fluxo de trabalho declarativo). Finalmente, a configuração de ponto de extremidade entra no elemento Service.Endpoints. A Figura 5 mostra a definição de serviço declarativo completa em XAML.
Figura 5 Serviço do WCF declarativo
<Service xmlns="clr-namespace:System.ServiceModel;assembly=System.WorkflowServiceModel"
xmlns:p="https://schemas.microsoft.com/netfx/2008/xaml/schema"
xmlns:ss="clr-namespace:System.ServiceModel;assembly=System.ServiceModel"
xmlns:sw="clr-namespace:System.WorkflowServiceModel;assembly=System.WorkfowServiceModel"
xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
xmlns:x2="https://schemas.microsoft.com/netfx/2008/xaml">
<Service.KnownProjections>
<SoapContractProjection x:Name="ICalculatorSoapProjection">
<ServiceContract x:Name="ICalculatorContract"
<OperationContract Name="Add" x:Name="Add">
<OperationArgument Name="Op1" Type="p:Int32" />
<OperationArgument Name="Op2" Type="p:Int32" />
<OperationArgument Direction="Out" Name="Result"
Type="p:Int32" />
</OperationContract>
</ServiceContract>
</SoapContractProjection>
</Service.KnownProjections>
<Service.Implementation>
<sw:WorkflowServiceImplementation>
<!-- place service implementation here -->
</sw:WorkflowServiceImplementation>
</Service.Implementation>
<Service.Endpoints>
<Endpoint Uri="http://localhost:8080/calc"
ContractProjection="{x2:Reference ICalculatorSoapProjection}">
<Endpoint.Binding>
<ss:BasicHttpBinding />
</Endpoint.Binding>
</Endpoint>
</Service.Endpoints>
</Service>
Uma desvantagem nesse estágio inicial é que não há um designer visual para ajudar na criação de serviços declarativamente. Espero que, conforme as CTPs (Community Technology Previews) forem distribuídas, a Microsoft forneça uma experiência de designer amigável ao desenvolvedor para trabalhar com a definição XAML.
Além do suporte a serviço declarativo e das atividades baseadas no WCF mencionadas anteriormente, o .NET Framework 4.0 vem com várias outras melhorias de nível inferior do WCF. Alguns desses recursos tornam possível gerenciar serviços de fluxo de trabalho com as novas extensões “Dublin”. Esses recursos incluem configuração aprimorada, correlação de mensagem, comunicação duplex durável, temporizadores duráveis e integração de rastreamento com o Rastreamento de Eventos para Windows (ETW). Outras funcionalidades que adicionam valor ao hospedar seus serviços em um ambiente gerenciado incluem pontos de extremidade de controle padrão e início automático. Você saberá mais a respeito desses recursos nos meses futuros.
A necessidade de “Dublin”
No mundo real, outro aspecto desafiador de se trabalhar com o WCF e o WF é descobrir onde hospedar seus serviços e fluxos de trabalho em um ambiente de servidor. Para o WCF, a resposta é normalmente bastante fácil — a escolha mais comum é o IIS e o Serviço de Ativação de Processos do Windows (WAS) no Windows Server 2008.
Atualmente, a combinação do IIS e do WAS oferece vários recursos principais, incluindo ativação em resposta a mensagens de entrada, monitoramento de processo e gerenciamento de integridade, reciclagem de processo, integração com CLR AppDomain, segurança interna e algumas funcionalidades de gerenciamento básicas disponibilizadas por meio do Gerenciador do IIS e de cmdlets do Windows PowerShell. Esses recursos combinados normalmente tornam o IIS/WAS a escolha certa para hospedagem de serviços do WCF em um ambiente de servidor porque a maioria das pessoas não deseja criar elas próprias esse tipo de coisa.
Embora o IIS/WAS ofereça uma base para hospedar aplicativos WCF, ele deixa a desejar em algumas áreas importantes. Sua maior limitação encontra-se na área de capacidade de gerenciamento de serviço. O IIS/WAS não fornece realmente funcionalidades de gerenciamento de serviço específicas do WCF, como diagnóstico de instâncias de serviço em execução, monitoramento e rastreamento de serviço. Por exemplo, um administrador não pode atualmente listar todos os serviços do WCF que estão configurados no IIS — não é possível consultar o status de todos os serviços hospedados. O IIS/WAS também não oferece suporte interno para simplificar implantações de redução ou tarefas comuns de configuração do WCF, o que, por sua vez, é um ponto fraco do WCF.
Os desafios de hospedagem são piores para os aplicativos WF em ambientes de servidor por causa do modelo com monitoração de estado por natureza exigidos para oferecer suporte a fluxos de trabalho de longa duração entre farms de servidores. Por causa dessas complexidades, a Microsoft não enviou um host de servidor do WF no .NET Framework 3.0 — os desenvolvedores tinham de escrevê-lo. Somente no .NET Framework 3.5, com a introdução da classe WorkflowServiceHost, foi possível hospedar fluxos de trabalho do WF como serviços WCF prontos, tornando possível hospedar seus fluxos de trabalho do WF também dentro do IIS/WAS.
O WorkflowServiceHost foi um bom começo, mas não vinha com suporte a ferramentas para gerenciar fluxos de trabalho com monitoramento de estado em um farm de servidores da Web inteiro nem fornecia ferramentas para monitorar e gerenciar instâncias de fluxo de trabalho em tempo de execução.
Em termos de recursos de gerenciamento de serviço e fluxo de trabalho, a maioria dos desenvolvedores espera uma experiência semelhante à fornecida pelo Biztalk Server, porém mais simples. Muitas organizações desejam a experiência de gerenciamento do BizTalk, mas não necessitam das funcionalidades de integração ou das semânticas de confiabilidade (e o impacto correspondente no desempenho) inerentes à MessageBox do BizTalk Server. Um modelo mais leve, criado especialmente para os aplicativos WCF e WF, seria mais adequado.
Um guia para “Dublin”
A Microsoft tem trabalhado em um novo conjunto de extensões para o Windows Server — intitulado "Dublin"— que fornece recursos de hospedagem e gerenciamento preciosos para seus aplicativos WCF e WF. O "Dublin" é essencialmente um conjunto de extensões de gerenciamento de serviços baseado no IIS/WAS que acompanhará o Windows Server. Ao usar as extensões "Dublin", seu serviço e seus fluxos de trabalho ainda serão hospedados no IIS/WAS, mas seus aplicativos terão funcionalidades e ferramentas de gerenciamento específicas do WCF e do WF que não existem atualmente no IIS/WAS.
As várias extensões "Dublin" acompanharão uma versão futura do Windows Server como parte da função do Windows Server Application Server. Portanto, o conjunto de recursos é muitas vezes chamado de Windows Application Server, embora não seja o nome oficial aprovado pela Microsoft. No restante deste artigo, chamarei as novas extensões do Windows Server Application Server simplesmente de "Dublin".
As funcionalidades principais fornecidas pelas extensões "Dublin" incluem suporte a gerenciamento para serviços confiáveis e duráveis e fluxos de trabalho de longa duração. O "Dublin" torna possível implantar um aplicativo em servidores individuais em um farm e fornece as ferramentas necessárias para tarefas específicas de gerenciamento de serviço. Discutirei essas funcionalidades em mais detalhes ao longo das próximas seções, mas antes vamos examinar a arquitetura geral, ilustrada na Figura 6.
.gif)
Figura 6 A arquitetura “Dublin”
Como é possível observar, o "Dublin" oferece vários bancos de dados de tempo de execução que formam a base da persistência e monitoramento de serviço. Há uma camada de componentes e serviços de tempo de execução fornecida pelo .NET Framework que se baseia nesses bancos de dados. O "Dublin" estende ainda mais esses tempos de execução para fornecer funcionalidades de hospedagem integrada, persistência, monitoramento e mensagens. Essa camada, em conjunto com os bancos de dados de tempo de execução subjacentes, constitui o que é chamado de "Dublin".
As camadas superiores na arquitetura são o que faz com que o "Dublin" possa ser usado por humanos. Há uma camada de API de gerenciamento que torna programáveis várias funcionalidades via cmdlets do Windows PowerShell. Além disso, há uma experiência do Gerenciador do IIS que deve ser familiar aos administradores do IIS atuais porque ela é baseada nos cmdlets do Windows PowerShell. Portanto, tudo o que é possível fazer no Gerenciador do IIS pode ser feito no Windows PowerShell.
A Microsoft adicionou inúmeras extensões de interface do usuário para executar as várias tarefas de hospedagem e gerenciamento descritas nesta seção. Há extensões para implantar e configurar, gerenciar e monitorar aplicativos. Essas extensões também oferecem um painel de tempo de execução do seu sistema mostrando coisas como instâncias de fluxo de trabalho em execução, suspensas e persistidas.
Criando um serviço de fluxo de trabalho do WCF para "Dublin"
O Visual Studio 2010 torna muito fácil criar serviços destinados às extensões "Dublin" por meio de um novo modelo de projeto (consulte a Figura 7). Esse modelo de projeto oferece um web.config pré-configurado com o provedor de persistência e o serviço de temporizador durável fornecidos pelo "Dublin".
.gif)
Figura 7 Criando uma nova biblioteca de serviço “Dublin”
Uma vez que o projeto tenha sido gerado, é possível concentrar-se na implementação do serviço de fluxo de trabalho do WCF usando as várias técnicas descritas anteriormente neste artigo. A nova experiência de designer de fluxo de trabalho torna possível implementar seu serviço inteiro usando a abordagem gráfica de desenvolvimento de fluxo de trabalho. Uma vez que o seu serviço de fluxo de trabalho completo tenha sido concluído, você estará pronto para implantar o serviço em um Windows Server habilitado com as extensões "Dublin".
É possível implantar seus serviços no IIS/WAS usando qualquer técnica normalmente usada para aplicativos Web (é possível implantá-los diretamente do Visual Studio, se o seu ambiente assim permitir). É possível também usar cmdlets do Windows PowerShell para automatizar essas tarefas. (Esses cmdlets permitem criar scripts de implantação automatizados para seus ambientes WCF e WF. Se desejar tentar usar qualquer um desses cmdlets, basta abrir o Windows PowerShell em um Windows Application Server e digitar "help <comando>" para aprender a usar esse comando específico.) Uma vez implantado, é possível começar a usar o Gerenciador do IIS para acessar as várias extensões "Dublin" realçadas na Figura 8.
.gif)
Figura 8 As extensões “Dublin” no Gerenciados de IIS
Implantar aplicativos com o "Dublin"
Muitos ambientes não permitem que os desenvolvedores implantem serviços diretamente em seus servidores gerenciados por motivos de segurança e isolamento. O "Dublin" fornece uma solução alternativa para implantar serviços por meio de seus recursos de exportação/importação de aplicativos.
É possível empacotar aplicativos WCF e WF para implantação em outros servidores selecionando o recurso de Exportação de Aplicativo no Gerenciador do IIS. Isso abrirá um diálogo solicitando a seleção de um aplicativo específico a ser exportado. Uma vez que um local tenha sido especificado, pressionar Exportar gerará um pacote de arquivo com uma extensão .zip contendo todo o código do WCF e WF, bem como todas as definições de metadados e configuração de um único aplicativo. Esse pacote pode ser movido em seguida e importado para outro servidor por meio das extensões "Dublin". Agora, basta enviar o arquivo .zip ao profissional de TI que gerencia seus servidores e deixá-lo tomar conta disso.
O cmdlet de Export-Application do Windows PowerShell realiza a mesma tarefa. A funcionalidade de Exportação de Aplicativo é também muito boa para ambientes de teste e validação de sistema.
É possível importar um aplicativo WCF e WF selecionando o recurso Importação de Aplicativo ou usando o cmdlet Import-Application (é possível também exibir o conteúdo de um pacote usando o cmdlet Get-PackageManifest). O recurso de importação solicitará a seleção do pacote (arquivo .zip) que desejar importar.
Durante o processo, é possível especificar o nome do aplicativo, o pool de aplicativo e o caminho físico do aplicativo, se desejado. Como o "Dublin" fornece uma configuração de persistência centralizada, ao implantar seus serviços de fluxo de trabalho em outro servidor, não será necessário se preocupar com a alteração da configuração de persistência no nível do aplicativo. Ele simplesmente usará o novo banco de dados de persistência com o novo servidor. Esses recursos tornam o processo de implantação de aplicativos WCF e WF em um ambiente de servidor bastante acessível para o administrador do sistema responsável por essas tarefas.
Uma vez que um aplicativo tenha sido implantado com êxito, será possível começar a configurar seus serviços por meio de outras extensões fornecidas pelo "Dublin". Por exemplo, em algumas situações o administrador do sistema pode precisar reconfigurar manualmente a configuração de tempo de execução dos bancos de dados de persistência e rastreamento. Com as extensões "Dublin", isso é bem simples. Basta selecionar Services na exibição padrão e será exibida uma lista de todos os serviços gerenciados, juntamente com um painel à direita que expõe várias opções de configuração de serviço (consulte a Figura 9). Essas opções permitem alterar facilmente as configurações de persistência, configurações de rastreamento e outras configurações do WCF relacionadas a segurança e limitação. Nunca será necessário tocar em um arquivo de configuração do WCF.
.gif)
Figura 9 Exibindo e configurando serviços com as extensões “Dublin”
Há vários cmdlets do Windows PowerShell para executar essas tarefas, incluindo Get-ServicePersistence, Set-ServicePersistence, Enable-ServiceTracking e Get-TrackingParticipant. Isso significa que é muito mais fácil automatizar a instalação e configuração de um ambiente de servidor de aplicativo.
Gerenciamento de aplicativos em execução
Durante o ciclo de vida de um aplicativo, os desenvolvedores e administradores de sistema necessitam da habilidade de monitorar a integridade do aplicativo para identificar e exibir instâncias de fluxo de trabalho problemáticas e finalizá-los quando necessário. O "Dublin" oferece inúmeras extensões destinadas a essas necessidades comuns de gerenciamento.
Se a opção Instâncias Persistidas for selecionada no Gerenciador do IIS (consulte a Figura 8), você será levado à exibição do painel que fornece uma visão geral das instâncias de fluxo de trabalho em execução que foram persistidas e potencialmente suspensas (consulte a Figura 10). A caixa Visão Geral exibe o número total de aplicativos e serviços implantados no servidor, site ou aplicativo (dependendo do escopo selecionado).
.gif)
Figura 10 Exibindo instâncias de fluxo de trabalho persistidas
A caixa Instâncias Persistidas exibe um resumo das instâncias de fluxo de trabalho em execução e persistidas, chamando as que podem ser bloqueadas ou suspensas (o que significa que foram finalizadas em erro). Como as instâncias suspensas são aquelas com as quais os humanos normalmente terão que lidar diretamente, elas fornecem várias outras caixas que tornam fácil isolar instâncias suspensas específicas com base no caminho virtual, nome do serviço ou tipo de exceção.
É possível clicar em qualquer um dos links (mostrados em azul) para exibir a lista de instâncias persistidas e exibir seus detalhes. Nesse ponto, é possível suspender, finalizar ou anular instâncias de serviço manualmente selecionando das ações mostradas no painel à direita (consulte a Figura 11). Suspender uma instância de serviço interrompe a execução da instância e impede que ela receba novas mensagens. Instâncias suspensas podem continuar mais tarde e, nesse ponto, voltarão a receber mensagens. Finalizar um serviço interrompe a execução da instância e a remove do armazenamento de persistência, o que significa que não poderá continuar. Por fim, anular uma instância de serviço limpa o estado da memória pertencente à instância determinada e reverte ao último ponto de persistência (que é armazenado no armazenamento de persistência).
.gif)
Figura 11 Exibindo instâncias de persistidas individuais
Os cmdlets Get-ServiceInstance e Stop-ServiceInstance do Windows PowerShell oferecem funcionalidades equivalentes a partir da linha de comando e fornecem inúmeras opções de linha de comando para identificar instâncias de serviço específicas.
Atualização de aplicativos em execução
Um dos aspectos especialmente problemáticos de trabalhar com sistemas reais é a necessidade de atualizá-los periodicamente. Para aplicativos distribuídos mais complexos pode ser complicado fazê-lo corretamente quando as alterações necessárias exigem atualizações do banco de dados, lógica de negócios e código de serviço simultaneamente. Normalmente, não é possível aplicar atualizações significativas atomicamente enquanto o aplicativo estiver em execução.
Uma maneira de abordar esse problema é colocar o aplicativo em estado offline enquanto estiver executando a atualização. No entanto, ao realmente pensar sobre isso, não há uma maneira fácil de colocar um aplicativo IIS/WAS em estado offline enquanto executa simultaneamente uma atualização em um site da Web. Essa é outra área na qual as extensões "Dublin" agregam valor por meio de um recurso offline simples.
É possível selecionar um aplicativo no Gerenciador do IIS e , em seguida, selecionar o comando Desabilitar Protocolos no painel à direita mostrado na Figura 8 (é importante observar que isso provavelmente será renomeado em um lançamento futuro). Fazer isso faz com que todas as instâncias dos serviços do aplicativo para interromper um estado bloqueado ou encerrar sua execução naturalmente, sem permitir que novas solicitações de entrada sejam processadas enquanto isso.
Nesse ponto, o fluxo de mensagens foi, basicamente, interrompido para esse aplicativo, o que significa que os clientes não poderão enviar mensagens para serviços sem receber erros (eles não serão enfileirados como seriam no BizTalk Server). A maneira pela qual isso funciona nos bastidores é bastante simples: a extensão "Dublin" simplesmente remove todos os manipuladores de protocolo desse aplicativo específico e salva-os para que possam ser facilmente restaurados uma vez que a atualização tenha sido concluída.
Uma vez que o aplicativo esteja offline, será possível executar qualquer atualização necessária. Ao concluir as atualizações e estar pronto para trazer o aplicativo ao estado online novamente, será possível selecionar o comando Restaurar Protocolos. Os cmdlets Disable-ApplicationMessageFlow e Enable-ApplicationMessageFlow do Windows PowerShell também podem ser usados para executar as mesmas tarefas a partir da linha de comando.
Monitoramento de aplicativos em execução
As empresas também necessitam da capacidade de monitorar aplicativos em execução para observar como a empresa está funcionando e quais alterações podem ser necessárias. Os tempos de execução do WCF e do WF já vêm com uma infra-estrutura de rastreamento interna na qual as extensões "Dublin" são baseadas, tornando fácil habilitar o monitoramento dentro dos seus aplicativos WCF e WF.
Figura 12 Configurando o rastreamento básico
Há dois jogadores principais na arquitetura de rastreamento do .NET Framework 4.0: perfis e participantes de rastreamento. Os desenvolvedores definem perfis de rastreamento que informam ao tempo de execução quais eventos devem ser rastreados e, em seguida, os participantes de rastreamento podem inscrever-se nesses eventos.
O "Dublin" vem com alguns perfis de rastreamento internos que tornam fácil rastrear um conjunto comum de eventos úteis. É possível habilitar facilmente o rastreamento para seu aplicativo navegando até um serviço específico no Gerenciador do IIS e selecionando Rastreamento no painel à direita.
Em seguida, a caixa de diálogo mostrada na Figura 12 será exibida, o que permite a configuração de algumas funcionalidades básicas de rastreamento para seus fluxos de trabalho e serviços. Uma vez que isso tenha sido configurado, as atualizações adequadas serão feitas na sua configuração e a infra-estrutura de rastreamento do WCF/WF será iniciada.
Se desejar, será possível também exibir dados de rastreamento por meio das extensões "Dublin". É possível selecionar Exibir Dados de Rastreamento enquanto inspeciona instâncias de serviço persistidas (consulte a Figura 11), o que executará uma consulte SQL em relação ao armazenamento de monitoramento para gerar uma lista de eventos de monitoramento para exibição (consulte a Figura 13). Ao desejar rastrear eventos personalizado, é possível definir perfis de rastreamento personalizados e configurá-los por meio da opção Perfis de Rastreamento na exibição principal do Gerenciador do IIS.
.gif)
Figura 13 Exibindo dados de rastreamento
Não tenho espaço para abordar todos os recursos do "Dublin" aqui — há muitos outros recursos atraentes que merecem uma discussão aprofundada (consulte a barra lateral "Recursos adicionais do Dublin" para saber mais) —, mas espero que você tenha um entendimento melhor sobre a função do "Dublin" e alguns dos recursos principais que oferecerá.
De "Dublin" a "Oslo"?
Se você tiver ouvido falar sobre a plataforma intitulada "Oslo," provavelmente está imaginando nesse ponto qual a relação do "Dublin" com essa iniciativa. Primeiramente, o "Oslo" é uma nova plataforma de modelagem em desenvolvimento pela Microsoft para simplificar a maneira de criar, compilar e gerenciar aplicativos distribuídos. A plataforma de modelagem consiste nestes três componentes principais: a linguagem de modelagem "Oslo" (também conhecida como "M"), o repositório "Oslo" e a ferramenta de modelagem "Oslo" (também conhecida como "Quadrant"). "Oslo" é, realmente, uma plataforma na qual qualquer outro aplicativo e tecnologia pode se basear para simplificar a experiência do usuário por meio de uma abordagem orientada a modelo.
Recursos adicionais do “Dublin”
O "Dublin" vem com vários outros recursos que não tive espaço para abordar neste artigo. Um que vale a pena realçar é o suporte para implantações de redução em farms de servidor que são integradas com soluções de balanceamento de carga existentes, como as destinadas a gerenciar instâncias de serviço persistidas no farm por meio de um banco de dados de persistência centralizado. A lógica de manipulação de erro permite que instâncias persistidas sejam executadas em qualquer nó no farm e impede condições de corrida quando vários nós competem pela mesma instância.
O outro componente importante é o Forwarding Service. Esse serviço torna possível interceptar todas as mensagens de entrada para executar roteamento central com base no conteúdo da mensagem. Especificamente, esse recurso oferece uma boa base para criar soluções sofisticadas de controle de versão de serviço.
O "Dublin" também vem com vários serviços principais para gerenciar o ciclo de vida de instâncias de serviço, incluindo o Durable Timer Server e o Instance Restart Service. O "Dublin" também aproveita o Ponto de Extremidade de Controle de Instância fornecido pelo .NET Framework 4.0 e o novo recurso de início automático do IIS/WAS, que permite iniciar serviços quando a máquina é iniciada em vez de aguardar pela primeira mensagem. Mais artigos sobre esses recursos serão exibidos nos próximos meses.
O "Dublin" será uma das primeiras tecnologias a alavancar a plataforma de modelagem "Oslo". Será possível exportar aplicativos "Oslo" do repositório e implantá-los facilmente no "Dublin," onde poderão aproveitar os vários recursos de hospedagem e gerenciamento discutidos neste artigo. Usar modelos para descrever e automatizar as implantações de aplicativo parece uma vitória para ambientes de TI complexos.
Conforme o "Dublin" e o "Oslo" continuam a amadurecer, é provável que a integração entre as duas tecnologias continue a crescer. A Microsoft declarou sua intenção de que as duas tecnologias sejam bastante complementares uma à outra.
E quanto ao BizTalk Server?
Outra pergunta comum é como o "Dublin" se relaciona ao BizTalk Server. Em muitos pontos, o BizTalk Server inspirou muitos dos recursos no "Dublin" atual. Embora as duas tecnologias ofereçam funcionalidades de gerenciamento semelhantes, há uma grande diferença entre as duas em termos de objetivo. O "Dublin" adiciona extensões de hospedagem e gerenciamento ao Windows Server criadas especificamente para os aplicativos WCF e WF, enquanto o BizTalk Server se destina à integração de aplicativos com sistemas diferentes da Microsoft usando uma variedade de formatos de mensagens, transportes e técnicas de mapeamento diferentes.
O objetivo principal do BizTalk Server sempre foi e continuará a ser a integração com sistemas diferentes da Microsoft (aplicativos de linha de negócios, sistemas herdados, dispositivos RFID e protocolos B2B). O BizTalk Server permanecerá com o objetivo nessas forças principais nos anos futuros. Em geral, você desejará continuar a usar o BizTalk Server quando seu objetivo principal forem esses tipos de cenários de integração de aplicativos empresariais (EAI).
No entanto, como muitos aplicativos WCF e WF não necessitam desses tipos de funcionalidades de integração, o BizTalk Server pode muitas vezes parecer um exagero. É exatamente nesse ponto que o "Dublin" entra em cena — como uma alternativa mais simples que oferece funcionalidades de gerenciamento semelhantes. No fim das contas, o "Dublin" será mais econômico para esses cenários do que o BizTalk Server já que as extensões "Dublin" serão enviadas como uma parte principal do Windows Server e não necessitarão da compra de adaptadores de integração desnecessários. É provável que uma versão futura do BizTalk Server seja baseada nas extensões "Dublin" para alavancar os investimentos de gerenciamento principais sendo feitos no Windows Server.
Um agradecimento especial para Eileen Rumwell, Mark Berman, Dino Chiesa, Mark Fussell, Ford McKinstry, Marjan Kalantar, Cliff Simpkins, Kent Brown, Kris Horrockse Kenny Wolf por sua grande ajuda neste artigo.
Aaron Skonnard é co-fundador da Pluralsight, uma empresa de treinamento em Microsoft .NET que oferece cursos de treinamento ministrados por instrutores e online. Aaron é autor de diversos livros, white papers e artigos, bem como dos cursos de treinamento em REST, Windows Communication Foundation e BizTalk Server. Entre em contato com ele em pluralsight.com/aaron.