Construindo Aplicações, de um Jeito Workflow

David Chappell inicia seu artigo " O jeito Workflow" discutindo sobre o que significa escrever um ótimo software server-side:

Todos que escrevem códigos desejam construir um ótimo software. Se este software é uma aplicação Server-side, ser ótimo é ter boa escalabilidade, manipulando grandes cargas sem consumir muitos recursos. Uma grande aplicação, também deve ser o mais fácil possível de ser entendida, tanto pelos seus criadores quanto para as pessoas que a mantém. Atingir ambos objetivos não é fácil. Abordagens que ajudam escalar aplicações tendem a dividi-las, separando sua lógica em diferentes ramos que são complicados de se entender. Ainda, ao escrever lógicas unificadas, parte de um único executável, pode tornar a escalabilidade impossível.

Ele segue discutindo abordagens diferentes para alcançar este tipo de implementação:

• A implementação mais simples é criar uma aplicação monolítica, que é executada num processador único, numa maquina única. Esta construção tipicamente implementa o seguinte:

  • Estado principal, o qual aqui é representado por uma simples variável string.
  • Receber a entrada do mundo externo, como receber um request de um cliente. Uma aplicação simples pode apenas ler a partir da console, enquanto num exemplo mais comum pode receber uma requisição HTTP de um browser ou uma mensagem SOAP de outra aplicação.
  • Enviar a saída ao mundo externo. Dependendo de como é construído, a aplicação pode fazer isto via HTTP, mensagem SOAP, escrevendo na console, ou alguma outra forma.
  • Providenciar caminhos lógicos alternativos, usando statements de controles de fluxos como if/else ou while.
  • Trabalhar executando o código necessário, em cada ponto da aplicação.

  Esta abordagem simples possui muitas vantagens:

  • …a lógica pode ser desenvolvida de forma única e seqüencial. Isto ajuda as pessoas que trabalham no código entendê-lo, e ainda permite uma ordem de eventos explicita.
  • …trabalhar com estado de aplicações é fácil. O estado é guardando na memória do processo, e como o processo é executado continuamente até que seu trabalho seja feito, o estado está sempre disponível.

  As limitações deste caminho são:

  Quando a aplicação precisa esperar pela entrada, seja de um usuário através da console, ou um client WebService ou outro meio, tipicamente ele simplesmente causará um bloqueio. Tanto a thread quanto o processador terão seu uso parado até chegar o input, leve o tempo que levar. Como threads e processador são recursos relativamente escassos, aplicações que ficam presas a eles quando aguardam uma entrada, não têm boa escalabilidade.

• Uma aplicação que se encerra quando está aguardando uma entrada e se reinicia quando a entrada chega. Neste caso, a aplicação contém a mesma lógica que a anterior, porém, agora é quebrada em dois diferentes pedaços. Quando a primeira requisição do cliente chega, a parte apropriada é carregada e executada. Uma vez que a requisição é manipulada e a resposta e devolvida, este pedaço pode ser descarregado. Quando a segunda requisição chega, o pedaço que a manipula é carregado e executado. Esta implementação é típica em aplicações Web, onde uma determinada página fornece uma requisição específica e a aplicação fica esperando pela próxima requisição. As vantagens desta arquitetura são:

  • Esta abordagem não desperdiça recursos, enquanto a aplicação não seja atrelada a uma thread ou processador ou quando ela não precisa deles
  • …permite a aplicação rodar em diferentes processadores, em diferentes máquinas e em tempos diferentes. Melhor que estar preso em uma estrutura única... a aplicação pode ser executada em uma das diversas máquinas disponíveis.

  Estas vantagens chegam com o preço de uma complexidade extra:

  • …os vários pedaços de código devem de alguma forma compartilhar o estado. Como cada um é carregado sob demanda, executado e depois encerrado, seu estado deve ser guardado externamente, em uma base de dados ou em uma área de persistência.
  • … o código não mais provê uma visão unificada da lógica conjunta do programa... o controle de fluxo não fica evidente. De fato, o pedaço de código que manipula a segunda requisição do cliente pode precisar iniciar checado se a anterior já foi feita. Para uma aplicação que implementa qualquer tipo de processo de negócio relevante, entender e construir corretamente o controle de fluxo pode ser desafiador.

• Aplicações baseadas em Workflow. Este tipo de aplicação realiza as mesmas coisas que uma aplicação comum, incluindo manutenção do estado, interação com o mundo externo, controle do fluxo de execução, fazer o trabalho da aplicação. Em um workflow, contudo, todas estas coisas são feitas por atividades. Estas atividades correspondem funcionalmente a várias partes de um programa típico. Porém, ao invés de elementos próprios da linguagem para coordenar as execuções de atividades, as execuções das atividades são coordenadas pelo workflow runtime (coordenador de tarefas), que conhece como executá-las. As vantagens desta arquitetura são:

  • …proporciona ao desenvolvedor uma visão unificada do controle de fluxo. Assim como no caso simples de uma lógica principal ser definida em um fluxo coerente. Isto torna mais fácil de entender... O workflow por si só expressa o controle de fluxo permitido.
  • … o workflow não brinca com memória bloqueando uma thread e usando o processador enquanto aguarda por uma entrada. Outra vantagem é que um workflow persistente pode potencialmente se recarregado em uma máquina que não seja a que estava sendo executado originalmente. Por isto, diferentes partes do wokflow podem ser executadas em diferentes sistemas.

  Outras vantagens da abordagem “workflow” descritas por David incluem coordenação de tarefas paralelas, reuso em alto nível (reuso de atividades), visão e acompanhamento da execução do processo, etc.

O restante do artigo do David descreve especificações da implementação do Windows WF, seus cenários de uso e sua integração com outras tecnologias .NET, incluindo WCF, Dublin, ASP.NET, etc. Ele também destaca novas características do WF introduzidas no .NET 4.

Apesar do artigo descrever como Windows WF pode ser usado para construir aplicações de workflow, nas palavras de Tom Baeyens:

… explica a essência do workflow e das ferramentas de BPM… ferramentas de BPM são diferentes dos simples programas como Java, C, Cobol etc em 2 aspectos:
• O estado de tempo de execução pode ser persistido. Em qualquer ponto durante a execução de um processo, ela pode ser interrompida e guardada. Posteriormente o estado da execução pode ser resgatada da área de persistência e continuado.
• Representação gráfica. O Segundo aspect onde processos BPM diferem das aplicações comuns é que eles são feitos para serem representados graficamente com caixas e setas.

O artigo é uma boa leitura para todos que desejam entender como as ferramentas de workflow trabalham e quais são os tipos de aplicações apropriadas para o uso dessa abordagem.