Como funciona a arquitetura do Windows Workflow Foundation?

O Windows Workflow Foundation é um dos pilares do .NET Framework presente desde a versão 3.0. Ele foi desenhado para trabalhar em conjunto com os pilares de Apresentação (WPF), comunicação (WCF) e de gerenciamento de identidade (WCS que evoluiu para WIF).

O Windows Workflow Foundation foi desenhado para possibilitar uma manipulação mais eficiente das execuções das regras de negócio, em especial quando existe interação humana no decorrer. A colaboração é um dos principais motores do uso do WF.

O Windows Workflow Foundation foi imaginado inicialmente para quarto cenários básicos. Em todos os cenários os workflows são capazes de executar tarefas colaborativas como: roteamento de solicitações entre usuários, atribuição de atividades, definição de processos de aprovação, procedimento em escala (paralelização de atividades), colaboração com documentos e dados, entre outros.

 

SharePoint 2007 e Workflow

Os fluxos hospedados no SharePoint podem ser construídos no Visual Studio, no SharePoint Designer ou nativamente no próprio SharePoint. A escolha varia de acordo com a complexidade do fluxo em questão.

 

Workflow e Serviços WCF

É possível construir fluxos que fazem acesso a serviços WCF, ou serviços WCF que hospedem Workflows.

 

Apresentação de fluxo coordenado

Aplicações Windows, Web, Mobile ou quaisquer outras ferramentas de apresentação podem ser utilizadas como camadas de apresentação para workflows.

 

Projeto de workflow Re-hosting

Aplicações podem hospedar o Workflow Designer e possibilitar a edição de fluxos sem dependência de ferramentas como o Visual Studio. Isto é especialmente útil para usuários da área de processos.

 

Topologia

 

Divisão de camadas

Os workflows do .NET Framework possui uma topologia que garante que sempre sejam estruturados em pelo menos 3 camadas: Presentation Layer, Workflow Runtime e Business Logical Layer.

 

Presentation Layer

A camada de apresentação pode ser uma aplicação em ASP.NET, Windows Forms, WPF, Windows Mobile, Email ou outros. A apresentação pode exibir notificações enviadas pela Workflow Runtime para alertar sobre a mudança de alguma característica relevante de algum fluxo.

 

Workflow Runtime

Este é a principal camada sistêmica. Ela possui as definições específicas do workflow e suas regras. E ele é o responsável por realizar a persistência de seus dados e informações, além de persistir a história do fluxo.

 

Business Logical Layer

A camada de negócios é a responsável por aplicar regras inerentes ao negócio, chamadas a estruturas externas, chamadas a outros serviços, etc.

 

Conceitos importantes

Tasks / Notifications

O sistema possui duas formas de se comunicar com o humano em workflows do WF: Tarefas e Notificações. Quando o workflow solicita algo ao usuário ele gera uma tarefa, que cabe ao usuário resolver; quando o sistema deseja informar o usuário sobre alguma mudança ocorrida em algum fluxo faz-se uma notificação.

 

Activity

Atividades são blocos de códigos estruturados que possuem funções e parâmetros próprios. Um workflow é composto de várias atividades. A notificação ou a atribuição de uma tarefa para o usuário é uma atividade.

 

Persistence

A persistência é feita pelo WF quando as estruturas de código estão prontas para serem serializadas. Isto é especialmente importante em fluxos que podem demorar. Isto porque o workflow para de consumir a memória do computador para utilizar o banco de dados. Quando o dado em questão for novamente necessário ele é desserializado e reutilizado pelo workflow. O processo de serialização é conhecido como ‘Desidratação do código’ e o processo de desserialização é conhecido como ‘Reidratação do código’.

 

Tracking

À medida que as atividades vão acontecendo o Workflow Runtime pode armazenar estes dados para fins de auditoria, isto é chamado de tracking.

O que é ASP.NET?

ASP.NET é uma plataforma de desenvolvimento de sites e aplicações web. Criada pela Microsoft com base no .NET Framework oferece um grande leque de características para a provisão de sites. O Visual Studio .NET é a principal ferramenta de desenvolvimento para aplicações na plataforma .NET. É possível ainda criar sites com ferramentas gratuitas com o Visual Web Developer ou com o SharpDeveloper.

Existem implementações de estilos arquiteturais e estruturas específicas em cima do ASP.NET que trazem benefícios e características próprias. As principais estruturas de mercado hoje são ASP.NET WebForms e ASP.NET MVC.

Independentemente do estilo arquitetural, várias problemáticas acompanham a web como a criação de páginas que funcionem em todos os clientes, necessidade de entendimento de infraestrutura e protocolos HTTP / HTTPS, escalabilidade e segurança.

Os sites escritos em .NET comumente recebem a extensão .ASPX tornando fácil sua identificação. O ASP.NET prove de maneira mais eficiente recursos caraterísticos do protocolo HTTP quando hospedado no servidor Internet Information Server (IIS). Mas também pode ser portado para o APACHE com plugings de terceiros.

Hospedadas no IIS, página construídas em sites com ASP.NET WebForms são baseadas em formulários, com dinâmica semelhante à de aplicações Desktop. Assim como plataformas antigas como DELPHI, VB6, o ASP.NET WebForms tem foco na produtividade e na minimização do tempo médio de aprendizado, que pode ser bastante lucrativo, quando a qualidade não é o principal objetivo dos negócios.

Como o ASP.NET funciona sobre a arquitetura do .NET Framework, sua estrutura de funcionamento é baseado no paradigma orientado a objetos. Com isto, suas estruturas são baseadas em objetos com ciclos de vida próprios chamados Controles Web. Poderosos e extensíveis dão suporte a muitas necessidades comuns para aplicações web. Vale deixar claro que quanto maior a Automatização menor é a Flexibilidade, desta forma pode ser bastante penoso fazer extensões nos controles web existentes.

As páginas web funcionam de uma maneira bem peculiar: Toda comunicação é desconectada. Isto cria uma série de complicadores característicos como a complexa manutenção de estado. O ASP.NET WebForms faz automaticamente a manutenção do estado das páginas e controles com um custo de desempenho que deve ser controlado.

O desenvolvimento de páginas ASP.NET possui uma importante característica para separação dos interesses chamada Code-Behind. Com este recurso a página fica totalmente isolada da codificação de seus controles. Esta tecnologia é opcional mas é fortemente recomendada.  Outra tecnologia interessante é a MasterPage. Características visuais comuns a todas às páginas podem ser centralizadas numa masterPage e utilizadas em todas as paginas facilitando a manutenção.

As páginas construídas em ASP.NET possuem estruturas prontas para configuração como os arquivos GLOBAL.ASAX e WEB.CONFIG. Com estes arquivos é possível fazer controles característicos nas solicitações HTTP que chegam ao servidor HTTP, e parâmetros próprios da aplicação como String de Conexão ao banco de dados, nomes de usuários e outros. O Servidor IIS é preparado para entender estes arquivos como especiais. O próprio IIS possui arquivos de configuração como o MACHINE.config que tem características do WEB.config que velem para todas as aplicações web instaladas nele.

Como criar um Custom Configuration Section em .NET 2.0

Quando se cria uma aplicação em .NET naturalmente se utiliza arquivos de configuração .config para centralizar e organizar sua estrutura. Normalmente web.config e app.config.

Muitas vezes se utiliza as seções appSettings e connectionStrings para configurações manipulados via código. Mas também é possível customizar os blocos destas configurações.

O que é necessário?

1. Uma classe que herde de System.Configuration.ConfigurationSection
2. Uma referencia no config no elemento <configSections>
3. Utilização do configSectionCustomizado
4. Consumir o valor do configSectionCustomizado

Então vamos lá...

1 - Como criar a uma classe ConfigurationSection

using System.Configuration;

namespace ConfigSection

{

    public class AnselmeSection : ConfigurationSection

    {

        [ConfigurationProperty("AnselmeServer", DefaultValue = "anselme://mail.sx", IsRequired = true)]

        public String AnselmeServer

        {

            get

            {

                return (String)this["AnselmeServer"];

            }

            set

            {

                this["AnselmeServer"] = value;

            }

        }

    }

}

2 - Como criar uma referencia no <configSections>

<configSections>

      <section name="Anselme" type="ConfigSection.AnselmeSection, ConfigSection"/>

</configSections>

3 - Como utilizar o configSection customizado no .config ?

  <Anselme AnselmeServer="anselme://brazil.mail.op" />

4 - Como consumir este código?

namespace ConfigSection

{

    public partial class _Default : System.Web.UI.Page

    {

        protected void Page_Load(object sender, EventArgs e)

        {

            AnselmeSection config = (AnselmeSection)ConfigurationManager.GetSection("Anselme");

            string servidor = config.AnselmeServer;

        }

    }

}

Para mais detalhes, a referecia oficial é:
http://msdn.microsoft.com/en-us/library/2tw134k3.aspx