Introdução
Usando o WWF, você pode criar fluxos de trabalho baseados em Processor Flow e implantá-los em qualquer tipo de aplicativo .NET. Além disso, este artigo discute alguns problemas exclusivos enfrentados pelos desenvolvedores ASP.NET – problemas que podem ser resolvidos através do uso de fluxos de trabalho, como manutenção de estado e navegação de página.
Em setembro de 2005, a Microsoft revelou o Windows Workflow Foundation (WWF, Windows Workflow Foundation) em sua conferência semestral de desenvolvedores profissionais. Como um dos pilares da API WinFX, o WWF fornece aos desenvolvedores uma estrutura comum para desenvolver aplicativos orientados a processos e centrados em fluxo de trabalho.
Atualmente, algumas organizações estão tentando automatizar processos de negócios inteiros. A resposta padrão é montar uma equipe de desenvolvedores para desenvolver o código correspondente; Embora esta abordagem funcione bem para estas organizações, existem alguns problemas inerentes. Para entender esse assunto em profundidade, é necessário entender as características básicas de um fluxo de trabalho.
Um fluxo de trabalho é essencialmente um método para arquivar as atividades envolvidas na conclusão de uma unidade de trabalho. Normalmente, durante o processamento, o trabalho “flui” através de uma ou mais atividades. Estas atividades podem ser realizadas por máquinas ou por seres humanos e podem ser tão simples como definir a ordem das páginas numa aplicação da Internet, ou tão complexas como gerir um documento ou produto que deve ser visto, alterado e aprovado por qualquer número de pessoas. complexo.
Como muitos fluxos de trabalho devem permitir o envolvimento humano, eles podem levar muito tempo para serem concluídos, variando de algumas horas a meses ou mais. Por exemplo, as pessoas envolvidas no processo podem não estar disponíveis, não serem locais ou estarem ocupadas com outras tarefas, portanto, o fluxo de trabalho deve ser capaz de persistir durante todos os períodos de inatividade; Além disso, os processos implementados de forma independente por meio de codificação podem ser difíceis de serem compreendidos por pessoas não técnicas e difíceis de serem alterados pelos desenvolvedores. Este e outros fatores são exatamente o objetivo de frameworks genéricos de fluxo de trabalho como o Windows WF - que visam facilitar a criação, alteração e gerenciamento de fluxos de trabalho - seja fornecendo-lhes uma interface visual ou definindo um conjunto comum de APIs realizadas.
Você pode colocar fluxos de trabalho do WWF em qualquer tipo de aplicativo .NET – incluindo Windows Forms, aplicativos de console, serviços do Windows e aplicativos Web ASP.NET. Cada tipo requer considerações especializadas. Embora alguns exemplos existentes sejam suficientes para ilustrar como hospedar fluxos de trabalho em Windows Forms e aplicativos de console, este artigo se concentrará nos problemas enfrentados pelos desenvolvedores ASP.NET que desejam integrar fluxos de trabalho em seus próprios aplicativos.
Nota do autor: O código fornecido neste artigo foi criado usando o Windows WF Beta 1 e o Visual Studio 2005 Beta 2. Você pode encontrar informações sobre como instalar o Windows WF em www.windowsworkflow.net . Embora este artigo discuta alguns dos princípios básicos do Windows WF, há outros recursos disponíveis nesta área. Presumo que o leitor conheça pelo menos um pouco sobre o Windows WF. O objetivo deste artigo é analisar detalhadamente o Windows WF e o ASP.NET, em vez de discutir o Windows WF em alto nível.
1. Padrões WF e MVC do Windows
Ao desenvolver um aplicativo ASP.NET, uma maneira comum de usar o WWF é implementar uma abordagem model-view-controller (MVC). Em essência, o objetivo do MVC é separar a camada de apresentação, a lógica do aplicativo e a lógica do fluxo do aplicativo.
Compreender isso será muito benéfico ao desenvolver um aplicativo ASP.NET. Considere um local de fluxo de trabalho de tickets de suporte técnico. Suponha que um usuário empresarial inicie esse fluxo de trabalho preenchendo um formulário Web ASP.NET e clicando em um botão enviar. Em seguida, o servidor notifica um funcionário usando um aplicativo Windows Forms e o Help Desk que “um novo ticket está disponível”. O funcionário do suporte técnico trabalhará no problema e finalmente fechará o ticket. Se você usar o Windows WF para desenvolver esse cenário de fluxo de trabalho, toda a lógica e o fluxo de processamento poderão estar contidos no próprio fluxo de trabalho, e o aplicativo ASP.NET não precisará entender essa lógica.
Este tipo de local fornece algumas evidências sólidas – separar a descrição da lógica é uma coisa boa. Como esse processo de manipulação de solicitações de suporte técnico é tão mundano, se você usar código C# ou VB.NET para implementar essa lógica em vários aplicativos .NET diferentes, você correrá o risco de duplicar a codificação ou pior - usar leads de código completamente diferentes. diferentes implementações do mesmo processo de negócios. Mas se você usar o WWF para implementar esse processo, os desenvolvedores de aplicativos que precisam desse processo só precisarão modificar as etapas em um local – o próprio fluxo de trabalho – sem se preocupar em alterar a lógica do aplicativo. A duplicação de código e onde implementar esse processo pode ser facilitada com o uso do Windows WF.
Ao implementar uma arquitetura MVC em ASP.NET usando o Windows WF, os desenvolvedores devem tentar construir fluxos de trabalho que sejam independentes do aplicativo - enquanto o fluxo de trabalho ainda estiver hospedado no aplicativo. Isso ajudará a manter a lógica independente da descrição e a manter um alto grau de independência entre a sequência de etapas de trabalho e o fluxo da página na aplicação web.
Um novo desenvolvedor do WWF pode tentar desenvolver um fluxo de trabalho com um número fixo de atividades em uma determinada ordem e, em seguida, desenvolver um conjunto de formulários Web ASP.NET que fluam de um formulário para outro na mesma ordem. Infelizmente, embora isso pareça lógico, na verdade é muito improdutivo porque você implementará a lógica do fluxo de trabalho novamente. A página da Web X não precisa saber se precisa ir para a página Y ou para a página Z para implementar esta etapa do fluxo de trabalho corretamente. Em vez disso, o fluxo de trabalho (modelo) deverá informar ao ASP.NET (o controlador) o que fazer em seguida. O ASP.NET deverá então decidir qual página exibir. Dessa forma, cada página mal precisa entender todo o processo; basta saber como realizar uma atividade diferente e deixar que o fluxo de trabalho cuide de como a página flui de um lugar para outro. Essa separação oferece aos desenvolvedores muita flexibilidade ao lidar com o fluxo da página. Por exemplo, se você decidir alterar a ordem em que as páginas são exibidas, poderá fazer isso facilmente no fluxo de trabalho, sem alterar uma única linha de código no aplicativo ASP.NET.
2. Um exemplo simples de fluxo de trabalho MVC
Para ilustrar essa ideia, mostrarei um aplicativo e fluxo de trabalho ASP.NET simples. Este fluxo de trabalho simplificado descreve um processo que coleta algumas informações privadas de um aplicativo externo e as exibe. As etapas são as seguintes:
1. Invocar um método - isso significa solicitar o nome de uma pessoa; esse fluxo de trabalho usa a atividade InvokeMethod (veja a Figura 1).
2. Aguarde até que um evento seja disparado - isso significa receber um nome nesta etapa, o fluxo de trabalho utiliza a atividade EventSink;
3. Obtenha um endereço de e-mail do anfitrião usando uma chamada semelhante.
4. Esperar por um evento significa receber um endereço.
5. Após receber o nome e e-mail, o fluxo de trabalho inicia uma atividade InvokeMethod para enviar as informações pessoais ao aplicativo chamador. Numa situação do mundo real, este último passo não é muito importante. Mais provavelmente, você chamará um serviço Web para enviar os dados para outro sistema ou colocá-los em um banco de dados.
Figura 1. Exemplo de fluxo de trabalho: este fluxo de trabalho descreve o processo implícito em um exemplo de aplicativo ASP.NET
Para implementar esse fluxo de trabalho no ASP.NET, você precisa de uma página para coletar nomes de pessoas, uma página para coletar endereços de email e uma página para exibir dados pessoais. Lembre-se de que o formulário de login de dados não deve ter ideia do que aconteceu antes ou depois dele. O mesmo vale para páginas de exibição. No entanto, o aplicativo ASP.NET deve saber qual página exibir para o usuário; esse é o objetivo da introdução dos controladores. Este exemplo usa um manipulador HTTP para implementar a solução. Esse manipulador personalizado, denominado WorkflowController, é responsável pelas seguintes tarefas:
· Obter uma referência ao horário em que o fluxo de trabalho está em execução.
· Obtenha uma referência para uma instância de fluxo de trabalho existente ou inicie uma nova instância de fluxo de trabalho (isso depende se uma instância de fluxo de trabalho foi iniciada).
·Estabelecer comunicação entre controlador e fluxo de trabalho.
·Trate de eventos deste fluxo de trabalho.
·Diga ao ASP.NET qual página precisa ser exibida, dependendo de qual camada do fluxo de trabalho está sendo executada no momento.
Como você viu, esse manipulador personalizado lida essencialmente com todo o trabalho relacionado ao WWF e ao controle de página - mantendo páginas ASP.NET individuais "silenciosas" sobre as ações que ocorrem em segundo plano. A única coisa com que um formulário web precisa se preocupar é executar a tarefa específica em questão e passar os dados necessários ao controlador.
Por padrão, o WWF funciona em um modelo assíncrono. Isso significa que quando um host de aplicativo inicia uma instância de fluxo de trabalho, o controle é imediatamente retornado ao host enquanto o fluxo de trabalho continua sendo executado em outro thread. Isso pode ser útil em um aplicativo Windows Forms - onde a capacidade de resposta contínua da interface do usuário é altamente desejável. Ao utilizar este modelo assíncrono, o fluxo de trabalho pode ser executado em segundo plano enquanto o usuário pode continuar a operar o aplicativo. Entretanto, em uma aplicação web, esse tipo de comportamento pode não ser esperado, uma vez que o controle normalmente só será devolvido ao usuário após o servidor ter concluído uma unidade de trabalho. Esta é exatamente a personificação da escalabilidade do Windows WF. No Windows WF, os desenvolvedores podem usar ou criar "serviços de tempo de execução" para monitorar e até mesmo modificar o tempo de execução do fluxo de trabalho. Os exemplos incluem:
· Serviço de persistência - armazena o estado do fluxo de trabalho entre a execução e os tempos ociosos
· Serviço de rastreamento - envia informações sobre a execução do fluxo de trabalho para alguma mídia
· Serviço de transação - ajuda a manter a integridade dos dados durante a execução do fluxo de trabalho
Além disso, os serviços de threading permitem que os desenvolvedores controlem como as instâncias do fluxo de trabalho são executados. Conforme discutido anteriormente, o tempo de execução do fluxo de trabalho executará, por padrão, a instância de forma assíncrona em um thread independente do host. Mas como isso provavelmente não é o que o ASP.NET espera, você precisará trocar o serviço de thread de fluxo de trabalho padrão. Felizmente, a Microsoft forneceu uma solução para este ASPNetThreadingService. Para implementar essa alteração, você pode adicionar ASPNetThreadingService ao serviço de tempo de execução do fluxo de trabalho codificando manualmente ou concluir esta tarefa no arquivo web.config. O aplicativo de exemplo neste artigo usa o modo de configuração. Na seção runtime/services do fluxo de trabalho do web.config (consulte a Listagem 1), adicione uma linha semelhante a esta:
<add type=
"System.Workflow.Runtime.Hosting.ASPNetThreadingService,
System.Workflow.Runtime, Versão=3.0.00000.0,
Cultura = neutra, PublicKeyToken = 31bf3856ad364e35"/>
3. Implementar a lógica do controlador
Em seguida, você precisa implementar a lógica do controlador com um processador HTTP. Para construir este controlador, tudo que você precisa fazer é criar uma classe chamada manipulador WorkflowController - que implementa a interface do manipulador IHttp. Até agora, você não viu nada de especial sobre o Windows WF - esse é um recurso específico do ASP.NET (continue lendo).
Nesta classe de processador WorkflowController, o método de interface do processador IHttp denominado ProcessRequest manipula uma solicitação da Web do aplicativo ASP.NET. Aqui, você precisa obter uma referência a uma instância de tempo de execução de fluxo de trabalho estático, criar manipuladores de eventos para o fluxo de trabalho e iniciar a execução do fluxo de trabalho. Antes de iniciar uma instância de fluxo de trabalho, você precisa verificar se o valor da cadeia de consulta da solicitação contém um GUID que representa um ID de instância de fluxo de trabalho. Se esse ID estiver presente, você saberá que já existe uma instância em execução, portanto poderá obter uma referência a essa instância e continuar a execução. Se esse ID não existir, será necessário criar uma nova instância e iniciar o processo de execução chamando o método Iniciar Workflow no tempo de execução do fluxo de trabalho.
Depois que uma instância é iniciada, os manipuladores de eventos gerenciam a comunicação dentro e fora do fluxo de trabalho. Como o objetivo deste artigo não é discutir serviços de comunicação local, não discutirei esse tópico em detalhes aqui, mas analisarei suas técnicas de implementação de alto nível e discutirei novamente como isso funciona em uma aplicação ASP.NET. Para facilitar o processamento da comunicação, você precisará de diversas interfaces .NET – usadas para descrever informações que entram e saem do fluxo de trabalho e do host. Você os encontrará no código-fonte do projeto WorkflowClassLibrary anexado a este artigo. Você também encontrará classes que implementam essas interfaces e as funcionalidades correspondentes necessárias para implementar o mecanismo de fluxo de trabalho.
Vamos dar uma breve olhada no arquivo web.config. Observe que perto do elemento ASPNetThreadingService discutido anteriormente, usamos três elementos para descrever a classe de serviço de comunicação:
<add type="Workflow.RuntimeServices.GetNameService,
Workflow.Library, Versão=1.0.0.0, Cultura=neutra,
PublicKeyToken=c4620ae819b5257e"/>
＜adicione type="Workflow.RuntimeServices.GetEmailService,
Workflow.Library, Versão=1.0.0.0, Cultura=neutra,
PublicKeyToken=c4620ae819b5257e"/>
＜adicione type="Workflow.RuntimeServices.SendDataService,
Workflow.Library, Versão=1.0.0.0, Cultura=neutra,
PublicKeyToken=c4620ae819b5257e"/>
Há também um elemento aqui que instrui a biblioteca de tempo de execução do fluxo de trabalho a usar o SqlStatePersistenceService. Este serviço adicional armazena a persistência de um estado de fluxo de trabalho em um banco de dados do SQL Server entre solicitações de página. . Você deve criar esse banco de dados manualmente em antecipadamente, mas a Microsoft fornece um script SQL para fazer isso. Você o encontrará na pasta C:WINDOWSMicrosoft.NETFrameworkv2.0.50215Windows Workflow FoundationSQL. Assim como os serviços de modelo, você pode adicionar esses serviços programaticamente. , mas você também pode implementá-lo na configuração, o que reduzirá bastante a quantidade de código a ser escrito e fornecerá flexibilidade - mesmo depois que o código for produzido. Há uma linha na configuração que adiciona um HttpModule - que suporta o tempo de execução do Windows WF. biblioteca no ASP.NET também há uma linha que define o controlador do manipulador Http discutido anteriormente. Como você pode ver nesta configuração, há muitas coisas nela
. estrutura extensível para desenvolvedores desenvolverem aplicativos baseados em fluxo de trabalho. Tornou-se e continuará a se tornar uma tecnologia de aplicativo importante. A menos que você seja uma empresa de serviços de tecnologia ou ISV, o software deve fornecer processos operacionais e de negócios. , os desenvolvedores podem tornar o processo de desenvolvimento fácil e flexível.
