Partilhar via

BizTalk Server 2006 ou WF? Escolhendo a ferramenta de fluxo de trabalho correta para seu projeto

  • Artigo

Kent Brown

twentysix New York (www.26ny.com)

Novembro de 2007

Revisado em fevereiro de 2008

Aplica-se a:

   Microsoft BizTalk Server 2006

   Windows Workflow Foundation

Resumo : Este artigo fornecerá diretrizes para escolher entre o Microsoft BizTalk Server 2006 e o Windows Workflow Foundation em uma variedade de cenários de fluxo de trabalho de Integração Empresarial e de Aplicativo. (16 páginas impressas)

Conteúdo

Introdução

Processo para escolher a ferramenta de fluxo de trabalho correta

Cenários comuns de fluxo de trabalho

Está tudo no host

Recomendações de Workflow-Technology

Future-Proofing

Conclusão

Adendo

Confirmações

Mais informações

Introdução

O fluxo de trabalho é difundido nos processos de negócios cotidianos, de modo que uma necessidade comum é encontrar ferramentas de programação que dão suporte diretamente à criação de soluções de fluxo de trabalho. O Microsoft BizTalk Server 2006 e o Windows Workflow Foundation (WF) são as duas principais ferramentas da Microsoft para soluções de fluxo de trabalho de programação. No entanto, devido à aparente sobreposição entre eles, muitos arquitetos e desenvolvedores têm dificuldade em decidir qual tecnologia de fluxo de trabalho faz sentido para seus propósitos.

Isso é especialmente verdadeiro dado o fato de que o WF foi claramente identificado como a tecnologia de fluxo de trabalho preferencial daqui para frente, enquanto o BizTalk Server 2006 ainda é o produto de servidor premium para integração empresarial. Até que a orquestração do BizTalk Server dê suporte total ao WF, arquitetos e desenvolvedores precisam escolher cuidadosamente em qual tecnologia investir.

Um dos desafios na escolha da tecnologia certa para implementar o fluxo de trabalho é que o fluxo de trabalho pode significar muitas coisas, entre elas:

  • Fluxo de telas de interface do usuário com as quais um usuário interage para concluir uma tarefa.
  • Fluxo de lógica de negócios em um aplicativo ou serviço.
  • Interação de vários seres humanos para concluir um processo de negócios.
  • Coordenação de várias trocas de mensagens entre sistemas para processar uma transação comercial.
  • Coordenação de etapas para extrair, transformar e carregar dados (ETL) em um banco de dados.

Embora o espectro de cenários de fluxo de trabalho seja amplo, é útil agrupá-los em quatro categorias amplas: de Fluxo de Trabalho Humano, de Fluxo de Trabalho do Aplicativo, de Fluxo de Trabalho de Integração Empresarial e fluxo de trabalho de integração de dados.

Das quatro principais categorias de fluxo de trabalho, o Fluxo de Trabalho do Aplicativo e o Fluxo de Trabalho de Integração Empresarial são as duas áreas em que as pessoas acham mais difícil escolher uma tecnologia. Os cenários fluxo de trabalho de fluxo de trabalho humano e fluxo de trabalho de integração de dados são bastante simples, de uma perspectiva de seleção de ferramentas. O fluxo de trabalho humano requer uma interface do usuário e geralmente é centrado em documentos, de modo que o Microsoft Office SharePoint Server 2007 seja a plataforma recomendada para criar soluções de fluxo de trabalho humano. O Microsoft SQL Server Integration Services (SSIS) é a ferramenta recomendada para cenários de Integração de Dados.

Este artigo fornecerá diretrizes para escolher entre o BizTalk Server 2006 e o WF em cenários de fluxo de trabalho de aplicativo e fluxo de trabalho de integração empresarial.

O Mecanismo de Orquestração do Servidor BizTalk

O mecanismo de orquestração do BizTalk Server sempre foi um dos recursos atraentes do BizTalk Server. Quando foi introduzido, era a melhor ferramenta disponível da Microsoft para executar programação centrada em fluxo de trabalho. A orquestração do BizTalk Server fornece um ambiente de programação visual para desenvolver componentes para controlar fluxos de mensagens complexos e multissessão para concluir uma transação comercial específica.

Os artefatos de código de orquestração do BizTalk Server se assemelham muito aos diagramas de atividade de fluxograma ou UML (Unified Modeling Language) que um analista de negócios pode produzir para documentar um processo de negócios. Esses artefatos podem ser compilados e executados no runtime do mecanismo de orquestração, que fornece serviços como transações de longa execução e compensação, durabilidade, tolerância a falhas e recuperação de desastre, que são cruciais para a criação de sistemas que automatizam transações comerciais críticas.

Uma Base de Fluxo de Trabalho para o Futuro

Embora existam categorias distintas de cenários de fluxo de trabalho, há o suficiente em comum entre os cenários, de uma perspectiva de programação, para fazer valer a pena tentar estabelecer uma estrutura comum para o desenvolvimento de fluxo de trabalho. O mecanismo de orquestração no BizTalk Server é poderoso, mas nunca foi projetado para ser usado fora do BizTalk Server; portanto, não é possível redefinir a orquestração do BizTalk Server efetivamente para as outras categorias de fluxo de trabalho.

O WF, que é lançado no Microsoft .NET Framework 3.0, apresenta um modelo de programação visual centrado em fluxo de trabalho para o .NET Framework que foi projetado para ser geral e extensível o suficiente para ser usado em todos os cenários relacionados ao fluxo de trabalho na plataforma Windows daqui para frente. A equipe que produziu o WF conseguiu usar os melhores conceitos do mecanismo de orquestração do BizTalk Server, considerar os requisitos para o realm mais amplo dos cenários de fluxo de trabalho e criar uma estrutura flexível o suficiente para dar suporte a todos eles.

Como evidência da flexibilidade do WF, o Microsoft Office SharePoint Server 2007 o usa para implementar soluções de fluxo de trabalho humano. A intenção é que fornecedores de BPM de terceiros também criem suas soluções sobre o WF, em vez de criar seus próprios mecanismos de fluxo de trabalho proprietários; vários fornecedores já fizeram isso. Os desenvolvedores individuais também podem usar o WF para implementar o fluxo de trabalho de aplicativo personalizado em aplicativos do .NET Framework. O plano também é que uma versão futura do BizTalk Server implemente o mecanismo de orquestração no WF para implementar soluções de fluxo de trabalho de integração empresarial.

Figura 1. Usando a ferramenta de fluxo de trabalho correta: BizTalk Server 2006 vs. WF

Processo para escolher a ferramenta de fluxo de trabalho correta

Nosso método para fornecer diretrizes para ajudá-lo a decidir qual ferramenta de fluxo de trabalho se ajusta ao projeto será delinear os cenários de fluxo de trabalho mais comuns, para que você possa determinar o cenário ou a combinação de cenários que melhor se ajustam ao seu projeto. Em seguida, forneceremos diretrizes específicas para cada cenário sobre qual ferramenta – BizTalk Server 2006 ou WF – é a melhor opção e por quê. Além disso, usaremos o Modelo de APIO (Otimização de Infraestrutura da Plataforma de Aplicativo) — um modelo para classificar a maturidade das funcionalidades de desenvolvimento e plataforma de aplicativos de uma organização — para fornecer diretrizes específicas da organização nos cenários em que qualquer ferramenta pode ser usada efetivamente. Por fim, examinaremos o roteiro do BizTalk Server 2006 e do WF, para que você possa tomar as melhores decisões para a revisão futura dos aplicativos que você está criando hoje.

Cenários comuns de fluxo de trabalho

Mesmo depois de limitar nosso escopo às categorias de aplicativo e integração empresarial do fluxo de trabalho, ainda há uma ampla gama de cenários de fluxo de trabalho a serem considerados. Como mostra a Figura 2, em um lado do espectro estão cenários em que o WF claramente é a escolha certa. Um exemplo disso é a funcionalidade de fluxo de trabalho em um produto ISV (fornecedor de software independente), em que os custos de licenciamento e a complexidade de implantação do BizTalk Server 2006 seriam proibitivos. Nesse cenário, como ISV, você está no negócio de fazer software comercial, e o esforço de programação extra necessário para hospedar a isenção de royalties do WF é um investimento razoável.

Figura 2. Continuum de integração e fluxo de trabalho

Do outro lado do espectro estão as soluções de Integração Empresarial que são criadas dentro de um departamento de TI corporativo, onde claramente o BizTalk Server 2006 é a escolha certa. Nesse cenário, você deseja se concentrar na produção de valor empresarial, em vez de investir na criação do "encanamento" para tornar sua solução escalonável, confiável e gerenciável; portanto, o custo de licenciamento do BizTalk Server 2006 vale a pena, devido ao que ele fornece.

A maioria dos projetos está entre essas duas extremidades do espectro. Veja a seguir alguns cenários comuns em que os requisitos determinam uma solução de fluxo de trabalho:

  • controlador de página de interface do usuário — um requisito comum em aplicativos complexos é impor a navegação na tela da interface do usuário de acordo com as regras de negócios do caso de uso específico que está sendo implementado. O exemplo mais simples é um assistente que orienta o usuário por meio de um conjunto prescrito de telas para realizar uma tarefa. Geralmente, é um grafo mais complexo de possibilidades de navegação na tela que se baseiam nas ações do usuário e no estado dos dados.
    O padrão MVC (model-view-controller) é a técnica clássica para extrair essa lógica de navegação dos próprios formulários, de modo que eles sejam mais simples e reutilizáveis em diferentes casos de uso. O controlador no padrão MVC é realmente um fluxo de trabalho ou um computador de estado; portanto, é natural procurar uma ferramenta de fluxo de trabalho na implementação desses tipos de aplicativos.
  • de Lógica de Negócios de Execução Longa — quando muitas etapas são necessárias para concluir uma transação comercial, o usuário pode ter que parar no meio do processo ou aguardar ações de outros usuários ou sistemas antes de continuar. A capacidade de pausar temporariamente (ou "hibernar") um processo e reiniciá-lo, com base em eventos externos, é central para a ideia de fluxo de trabalho. Sem um mecanismo de fluxo de trabalho, os desenvolvedores são forçados a projetar e codificar manualmente os mecanismos para armazenar o estado de um processo incompleto e recuperar esse estado quando o processo é continuado. Com um mecanismo de fluxo de trabalho bem projetado, essa funcionalidade tem suporte nativamente sem trabalho adicional para os desenvolvedores.
  • fluxo de processo dinamicamente atualizável— embora pareça possível inicialmente codificar processos empresariais em etapas sequenciais bem definidas, os humanos geralmente devem modificar o fluxo no meio do fluxo para levar em conta situações da vida real. Em um processo de aprovação de despesas, o gerente do funcionário que enviou o relatório de despesas pode ser o aprovador padrão. No entanto, o gerente pode decidir delegar a tarefa a um secretário (por exemplo, porque o gerente está indo para jogar golfe) ou escalonar a aprovação para um superior (por exemplo, porque o gerente não tem certeza da política para uma despesa específica). Permitir que o usuário atualize o fluxo geralmente é mais simples do que tentar prever todas as possíveis permutações do fluxo antes do tempo.
  • Abstração de Regras da Lógica de Negócios— nesse cenário, sua meta é separar as regras de negócios de outra lógica de negócios. Um bom exemplo são as regras de validação de formulário. Em um programa de Aplicativo Hipotecário, o formulário aplicativo de empréstimo pode ter um conjunto de regras de validação de campo antes que o usuário possa pressionar o botão enviar para enviar um aplicativo de empréstimo. Se o mesmo formulário for usado pelo agente de empréstimos para revisar e aprovar o empréstimo, regras de validação adicionais serão necessárias, pois ele está em um estágio diferente no processo.
    Implementar as regras de validação separadamente do formulário facilita que o formulário seja reutilizado em diferentes cenários e imponha as regras de validação apropriadas simplesmente avaliando o conjunto apropriado de regras para esse cenário.
  • do Agregador de Serviços Web — os aplicativos geralmente devem agregar dados de vários serviços Web diferentes. Em muitas situações, a lógica de agregação em si pode e deve ser extraída do aplicativo e exposta como um serviço em seu próprio direito que pode ser reutilizado de outros aplicativos. Esses serviços geralmente são chamados serviços Web compostose são um elemento importante de uma arquitetura madura orientada a serviços. O cenário do Agregador de Serviço Web geralmente é síncrono e de execução curta.
  • de processo de negócios de execução longa — o cenário de processo empresarial de execução longa é usado neste artigo para designar processos baseados em servidor que integram vários aplicativos, enquanto lógica de negócios é usada para lógica em um único aplicativo. Os requisitos para esses processos de negócios de execução longa baseados em servidor para multithreading, comportamento assíncrono, persistência do estado do processo, correlação de mensagens para instâncias de processo, escalabilidade, confiabilidade, integridade transacional e assim por diante, são muito maiores do que para a lógica de negócios em um aplicativo.
  • processo de B2B (Business to Business)— o cenário de processo B2B é essencialmente o mesmo que o cenário de processo de negócios de execução longa, exceto que o primeiro está entre organizações além de aplicativos internos. Os requisitos de segurança, portanto, são primordiais. Além disso, você tem ainda menos controle sobre o formato de dados específico e o protocolo de transporte, pois eles podem ser ditados pelo seu parceiro de negócios; portanto, você precisa da capacidade de dar suporte a uma ampla gama de formatos e protocolos e à configuração de suporte dos intercâmbios específicos para um grande número de parceiros.
  • abstração de regras do processo empresarial— da mesma forma com a abstração de regras do cenário de lógica de negócios, esse cenário se aplica quando você deseja separar as regras de negócios do código principal no cenário de processo empresarial de execução longa e no cenário de processo B2B. Esse cenário requer um nível mais alto de desempenho e escalabilidade. Além disso, provavelmente exigirá ferramentas para permitir que os não programadores exibam e editem as regras.
  • repositório de regras corporativas— nesse cenário, o objetivo é criar um repositório central de regras compartilhadas que possa ser invocado de todos os aplicativos na empresa. Isso fornece consistência em todos os aplicativos em uma organização para aplicar regras de negócios importantes. Da mesma forma que a Abstração de Regras do cenário de Processo Empresarial, esse cenário requer alta escalabilidade e ferramentas para permitir que os não-programadores exibam e editem as regras. Além disso, esse cenário exige que o repositório de regras seja capaz de existir como sua própria entidade na empresa, com seu próprio mecanismo de hospedagem separado do mecanismo de fluxo de trabalho e com componentes ou APIs para executar as regras de vários aplicativos.
  • Barramento de Serviço Enterprise (ESB)/Agente de Mensagens— muitas organizações querem uma infraestrutura de comunicação padronizada para todos os serviços. As duas topologias mais comuns para essa infraestrutura são o ESB e o Agente de Mensagens. Mensagens de publicação/assinatura e roteamento de tópico base geralmente são recursos esperados dessa infraestrutura.

Modelo de Otimização de Infraestrutura da Plataforma de Aplicativo

Em alguns dos cenários de fluxo de trabalho, o BizTalk Server 2006 e o WF atendem satisfatoriamente aos requisitos técnicos. Para esses cenários, fazer a escolha certa de tecnologia de fluxo de trabalho requer a correspondência da solução às necessidades da organização específica. Para fazer recomendações que se aplicam à sua organização específica, usaremos o modelo de APIO (Otimização de Infraestrutura da Plataforma de Aplicativo), conforme mostrado na Figura 3.

Figura 3. Modelo de APIO (Otimização de Infraestrutura da Plataforma de Aplicativo)

O modelo APIO é uma técnica para criar a criação de perfil da maturidade de uma organização em relação à infraestrutura de aplicativos, à arquitetura e às práticas de desenvolvimento. O objetivo desse modelo é dar às organizações um roteiro para otimizar sua agilidade no fornecimento de soluções de TI para atender às necessidades da empresa.

O modelo APIO usa os quatro perfis a seguir da maturidade de uma organização:

  • Básico — as organizações tratam o software como um custo. Eles têm aplicativos em grande parte siloed com pouca integração ou reutilização. Os aplicativos que eles têm podem estar em uma variedade de plataformas. Eles não têm padrões consistentes para técnicas de infraestrutura ou desenvolvimento; eles não têm uma visão arquitetônica consistente.
  • Padronizados — as organizações ainda tratam o software como um custo, mas tomaram medidas para melhorar a eficiência. Eles têm uma visão arquitetônica e tentam considerar oportunidades de reutilização. Eles começaram a integrar alguns aplicativos, mas são principalmente integrações ponto a ponto.
  • Advanced— as organizações tratam o software como um habilitador de negócios. Eles têm arquitetos dedicados e uma visão arquitetônica clara. Eles têm muitos serviços e alcançam um alto nível de reutilização. Todos os principais processos de negócios são automatizados e monitorados. Eles usam uma plataforma de integração centralizada e empacotada.
  • dinâmico — as organizações tratam o software como um ativo estratégico. Eles têm um SOA muito maduro na visão e implementação. Eles têm processos claros para controle dinâmico de controle de versão e reimplantação de serviços. Ele pode se adaptar rapidamente às alterações de requisitos de negócios e pode se integrar rapidamente a novos parceiros de negócios.

Não é só onde você está, mas para onde você está indo

Um pouco implícita no modelo apio é a noção de que cada organização aspiraria a se mover em direção ao perfil dinâmico. Na realidade, depende da natureza do negócio e da filosofia da gestão em relação à tecnologia. Algumas empresas podem estar completamente satisfeitas em permanecer no perfil Básico ou Padronizado.

Você deve considerar o perfil atual, bem como as metas de curto e longo prazo, com a meta de curto prazo sendo a mais importante. Uma organização no perfil Básico, com o desejo de estar no perfil dinâmico eventualmente, pode optar por se concentrar inicialmente em entrar no perfil Padronizado; portanto, suas decisões de tecnologia devem ser consistentes principalmente com o perfil Padronizado.

Em geral, o BizTalk Server 2006 será uma melhor opção nas organizações que estão ou têm uma meta de curto prazo no perfil Avançado ou Dinâmico. Uma organização no perfil Básico que está relativamente satisfeita nesse perfil pode não ter a motivação estratégica para adotar o BizTalk Server 2006 nem os recursos para tirar proveito dele efetivamente; portanto, eles provavelmente não gostariam de fazer o investimento. No entanto, se uma organização no perfil Básico tomou a decisão de avançar para o perfil Avançado agressivamente, adotar o BizTalk Server 2006 pode ser um passo estratégico nessa direção.

O ponto de introduzir o modelo APIO na discussão é que ter uma boa ideia dos perfis apio atuais e direcionados da organização ajudará na decisão entre o WF e o BizTalk Server 2006, quando o cenário técnico poderia ser bem suportado por qualquer tecnologia. Duas organizações diferentes podem fazer escolhas diferentes: cada uma fazendo a escolha certa para seu perfil organizacional.

Está tudo no host

Um dos aspectos mais importantes a serem considerados ao escolher entre o BizTalk Server 2006 e o WF são os requisitos de hospedagem para seus fluxos de trabalho. Ao contrário do BizTalk Server 2006, o WF não fornece hospedagem "pronta para uso"; você deve implementar um host que estabeleça o processo do Windows e inicie o mecanismo de runtime de fluxo de trabalho no qual os fluxos de trabalho serão executados.

Para criar uma estrutura que possa dar suporte a todo o espectro de cenários de fluxo de trabalho de forma realista, o WF abstrai os principais comportamentos que um ambiente como o BizTalk Server 2006 fornece, para que vários hosts possam fornecer o comportamento desejado específico para esses serviços.

Os principais serviços que um host de fluxo de trabalho do WF fornece são os seguintes:

  • de serviço de agendamento — cria e gerencia os threads usados pelo mecanismo de runtime para executar instâncias de fluxo de trabalho.
  • de serviço do Lote de Trabalho de Confirmação — gerencia as transações usadas pelo mecanismo de runtime para operações de banco de dados.
  • serviço de persistência— manipula a persistência da instância de fluxo de trabalho quando ela é direcionada para fazer isso pelo mecanismo de runtime. Esse serviço é opcional. Se não for fornecido, as instâncias de fluxo de trabalho não serão mantidas e deverão ser executadas na memória durante todo o tempo de vida.
  • de serviço de acompanhamento — fornece a capacidade de registrar eventos de acompanhamento dentro de fluxos de trabalho. Esse serviço é opcional.

O que é preciso para criar um host de fluxo de trabalho

Dependendo do cenário de fluxo de trabalho e dos serviços que você deve fornecer aos seus fluxos de trabalho, a criação de um host WF pode ser trivial ou proibitiva. Para os cenários em que o fluxo de trabalho está dentro do contexto de um aplicativo, hospedar o WF é bastante simples. O aplicativo em si atua como o host do processo e há implementações padrão dos serviços principais que podem ser configuradas com esforço mínimo.

No entanto, a sofisticação necessária do host salta drasticamente quando você entra em cenários altamente escalonáveis baseados em servidor. A Tabela 1 mostra uma lista de serviços de host que podem ser necessários — a maioria dos quais são fornecidos no BizTalk Server 2006.

Tabela 1. Serviços de host

  • Configuração de expansão
  • Balanceamento de carga
  • Failover
  • Limitação
  • Gerenciamento de threads
  • Gerenciamento de memória
  • Isolamento de serviço
  • Configuração de exceção
  • Gerenciamento de mensagens com falha
  • Acompanhamento de mensagens
  • Arquivamento e limpeza
  • Identidade e representação
  • Modelo de implantação de vários ambientes
  • Monitoramento de integridade
  • Acompanhamento de utilização/desempenho
  • Gerenciamento de estado do processo composto
  • Script
  • Recuperação de desastre
  • Conformidade regulatória
  • Gerenciamento de configuração

Em que negócio você está, afinal?

Se você tiver a tarefa de criar um aplicativo específico com prazos apertados, provavelmente não quer que sua equipe se distraia por ter que criar um host complexo quando ele deve se concentrar na implementação da lógica de negócios necessária. Nesse caso, o BizTalk Server 2006 vale a pena o investimento para comprar, em vez de tentar criar, um host de fluxo de trabalho robusto. Se você faz parte da equipe de arquitetura central de uma grande empresa, pode optar por investir na construção de um host que possa ser usado em toda a organização. Mesmo assim, esse esforço não deve ser tomado de ânimo leve.

Recomendações de Workflow-Technology

Para cenários dentro de um aplicativo: WF

Para todos os cenários contidos em um aplicativo, incluindo Controlador de Página de Interface do Usuário, Lógica de Negócios de Execução Longa, Fluxo de Processo Dinamicamente Atualizável, Composição do Serviço Web e Abstração de Regras da Lógica de Negócios, o WF é a escolha certa de tecnologia de fluxo de trabalho.

Na maioria dos cenários centrados no aplicativo, o padrão de uso requer interação síncrona e de baixa latência entre o aplicativo e o fluxo de trabalho, o que não é a força do BizTalk Server 2006. O BizTalk Server 2006 não seria adequado para esses cenários, por motivos de desempenho; As orquestrações do BizTalk Server são executadas em servidores BizTalk dedicados e a invocação de um aplicativo cliente requer uma viagem de ida e volta pela rede. Além disso, o design do BizTalk Server 2006 de persistir cada mensagem para o banco de dados MessageBox para durabilidade introduz latência adicional, o que pode não ser aceitável no contexto de uma interface do usuário interativa, se o fluxo de trabalho precisar ser chamado de forma síncrona.

O WF é uma melhor opção para esses cenários; ele atende aos requisitos de fluxo de trabalho e é mais simples e mais barato que o BizTalk Server 2006. Os recursos de mensagens do BizTalk Server 2006, por exemplo, mapeamento e adaptadores, não são necessários nesses cenários. Os requisitos para serviços de hospedagem são modestos, de modo que hospedar o runtime do WF dentro do aplicativo não exige uma quantidade proibitiva de trabalho.

Para a maioria dos cenários de Business-Process: BizTalk Server 2006

Para a maioria dos cenários que envolvem processos de negócios baseados em servidor, o BizTalk Server 2006 é a escolha certa. Elas incluem Processo B2B, Abstração de Regras do Processo Empresarial, Repositório de Regras Corporativas e Barramento de Serviço Corporativo (ESB)/Agente de Mensagens.

Esses cenários exigem alta escalabilidade. Além disso, eles exigem a capacidade de exibir processos em execução e interrompê-los e reiniciá-los. Por fim, eles exigem suporte para dimensionamento para vários servidores. Nesses cenários, os recursos avançados de hospedagem do BizTalk Server 2006 são necessários e valem a pena o investimento.

Básico Padronizado Avançado Dinâmico

WF → BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

Figura 4. Cenário de processo empresarial de execução prolongada

O BizTalk Server 2006 geralmente será a melhor plataforma para o cenário de Processo Empresarial de Execução Longa. Esses processos tendem a ser assíncronos, de execução longa e com estado. Esses processos geralmente são críticos para a organização; portanto, eles exigem alta disponibilidade, visibilidade, segurança e capacidade de gerenciamento. A topologia "Farm" ou grupo do BizTalk Server 2006 permite que você gerencie uma matriz de servidores para fornecer escalabilidade e redundância.

O mecanismo de persistência do BizTalk Server 2006 para armazenar o estado do processo tem segurança robusta interna para proteger a privacidade do estado persistente, o que pode ser importante por razões regulatórias. O BAM (Business Activity Monitoring) do BizTalk Server 2006 fornece visibilidade adequada em nível de negócios para os processos em execução de forma segura. Por fim, esses cenários geralmente exigem suporte para formatos de mensagem heterogêneos e protocolos de transporte, incluindo sistemas herdados.

Por esses motivos, o BizTalk Server 2006 geralmente será a melhor opção para organizações que estão direcionando os perfis Padronizados, Avançados e Dinâmicos. Essas organizações geralmente consideram o cenário de Processo Empresarial de Execução Longa muito importante para os negócios e muito comum dentro da empresa; portanto, eles compram o BizTalk Server 2006 especificamente para estabelecer uma plataforma padronizada para eles.

No entanto, o WF pode ser uma opção melhor para organizações que estão no perfil apio básico. Essas organizações geralmente não estão procurando investir na criação de uma plataforma de aplicativo padronizada. Em vez disso, eles estão procurando minimizar os custos, e os custos de licenciamento e hardware do BizTalk Server 2006 podem ser proibitivos. A exceção a essa orientação é quando há requisitos para alta escalabilidade, monitoramento e suporte para uma ampla variedade de formatos de mensagem e protocolos de transporte. Nesse caso, embora a organização esteja relutante em investir em sua plataforma de aplicativos, o custo de compilar os recursos de hospedagem e mensagens do zero provavelmente excederia os custos do BizTalk Server 2006.

Básico Padronizado Avançado Dinâmico

WF

WF → BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

Figura 5. Cenário do Agregador de Serviços Web

As orquestrações do BizTalk Server e os fluxos de trabalho do WF têm forte suporte para serviços Web de consumo externo de um fluxo de trabalho e para expor o fluxo de trabalho como um serviço Web. Portanto, para criar soluções de Agregador de Serviço Web, assim como para soluções de Processo Empresarial de Execução Longa, a opção é determinada pelos requisitos de hospedagem e perfil organizacional.

Se o serviço Web agregador for apenas para agregar outros serviços Web, a capacidade do BizTalk Server 2006 de dar suporte a formatos de mensagem heterogêneos e protocolos de transporte adicionará pouco valor. No entanto, se o serviço também deve agregar dados de ambientes herdados que não são expostos como serviços Web, o BizTalk Server 2006 adicionará valor.

Como o padrão de uso é rápido, chamadas de solicitação/resposta síncronas, a durabilidade da mensagem fornecida pelo BizTalk Server 2006 geralmente não é importante. Na verdade, a latência introduzida pela persistência ao MessageBox é, na verdade, uma responsabilidade. O principal valor que o BizTalk Server 2006 fornece para esse cenário é a capacidade de gerenciar a implantação em muitos servidores e monitorar instâncias em execução. A funcionalidade BAM do BizTalk Server 2006 também pode ser útil para monitorar se os SLAs (contratos de nível de serviço) são atendidos.

Por esses motivos, o WF é uma boa opção para implementar agregadores de serviço Web, especialmente em organizações nos perfis Básico e Padronizado. Um exemplo no qual o BizTalk Server 2006 pode ser vantajoso é aquele em que você deve gerenciar um grande número de pontos de extremidade para diferentes organizações cliente. A configuração de Porta de Recebimento e Localização de Recebimento do BizTalk Server 2006 trata especificamente disso. Nesse caso, os certificados também podem ser importantes e o suporte do BizTalk Server 2006 para configurar e gerenciar certificados e aplicá-los à criptografia/descriptografia pode ser útil.

Future-Proofing

Você deseja garantir que seus investimentos em custos de licenciamento de software, no aprendizado de uma tecnologia de fluxo de trabalho e na criação de componentes de fluxo de trabalho específicos, forneçam o valor mais possível no futuro. Além de escolher o fluxo de trabalho certo para seu cenário de fluxo de trabalho específico e organização, você também deve levar em conta os mapas de estrada do produto para BizTalk Server 2006 e WF. Não há uma resposta simples para isso. Os comentários a seguir não fazem um argumento forte para escolher qualquer tecnologia; em vez disso, são pontos de dados para ajudar na sua decisão.

O que o BizTalk Server 2006 R2 adiciona

O BizTalk Server 2006 R2 adiciona dois recursos que podem afetar sua escolha de plataforma de fluxo de trabalho: os Adaptadores do WCF e os interceptadores BAM para WCF e WF.

Adaptadores do WCF

Se sua equipe adotou o Windows Communication Foundation (WCF) como a tecnologia padrão para implementar serviços na criação de seu SOA, o fato de que o BizTalk Server 2006 não tinha suporte do WCF pode tê-lo desqualificado como uma plataforma para criar e hospedar serviços Web compostos. Isso pode ter empurrado você para o WF, mesmo se o BizTalk Server 2006 fosse, de outra forma, uma ótima correspondência para seus cenários e perfil APIO.

Felizmente, com a introdução da grande integração do WCF no BizTalk Server 2006 R2, isso não é mais uma preocupação. O BizTalk Server 2006 agora tem forte integração com o WCF e é uma excelente plataforma para criar serviços compostos com serviços mais granulares e expor esses serviços compostos como serviços WCF.

Interceptador BAM para WF

O segundo recurso relevante do BizTalk Server 2006 R2 é a introdução do interceptador BAM para WF. Se o monitoramento de atividades comerciais for um recurso importante da sua solução, você pode ter sido empurrado para o uso do BizTalk Server 2006 , apenas para tirar proveito do BAM, quando o WF era um ajuste melhor para o seu cenário. Com o interceptador BAM para WF, você pode escolher WF se for a tecnologia de fluxo de trabalho certa para seu projeto e ainda usar o BAM como uma solução de monitoramento de atividade empresarial.

O BAM é um recurso do BizTalk Server 2006 que fornece uma estrutura para capturar eventos e dados de orquestrações e fluxos de mensagens do BizTalk Server e apresentar esses dados em um portal para fornecer ao usuário de negócios visibilidade de ponta a ponta no processo de negócios. Um aspecto poderoso da maneira como o BAM funciona para aplicativos BizTalk Server 2006 é que o monitoramento bam pode ser configurado (ou "instrumentado") depois que um aplicativo BizTalk Server 2006 foi implantado, sem exigir modificações nos artefatos de código do BizTalk Server 2006.

O BAM foi projetado como uma solução de monitoramento de atividade de negócios em toda a empresa; portanto, é possível que aplicativos não BizTalk Server 2006 alimentem eventos e dados no BAM. No entanto, as APIs para fazer isso exigem que um pouco de código seja gravado nos aplicativos externos. O interceptador BAM WF no BizTalk Server 2006 R2 fornece a capacidade de instrumentar fluxos de trabalho do WF para BAM de forma mais simples e sem a necessidade de modificações de código. Usando os interceptadores BAM, você pode acompanhar seus processos de negócios sem recompilar sua solução WF ou WCF; a integração é feita por meio de um arquivo de configuração.

Extensões do BizTalk Server 2006 para SDK do WF

As Extensões do BizTalk Server 2006 para O SDK do WF foram anunciadas e rebaixadas no TechEd 2007. Esse SDK fornece um mecanismo simples para hospedar fluxos de trabalho do WF no BizTalk Server 2006. Essa ferramenta destina-se a ser usada por desenvolvedores do .NET que estão criando fluxos de trabalho do WF hoje e procurando uma maneira fácil de obter uma hospedagem robusta e escalonável desses fluxos de trabalho.

O SDK fornece duas atividades personalizadas do WF — uma atividade btsReceive e uma atividade btsSend — que podem ser usadas em um fluxo de trabalho do WF para receber e enviar mensagens por meio do BizTalk Server 2006. Como desenvolvedor, você define o WCF DataContracts para as mensagens de entrada e saída e um ServiceContract para definir o padrão de troca de mensagens. No fluxo de trabalho do WF, as atividades btsReceive e btsSend são configuradas para usar oServiceContract definido, conforme mostrado na Figura 6.

Figura 6. atividades btsReceive e btsSend para uso no ServiceContract definido

Depois que o fluxo de trabalho do WF for concluído e compilado, clique com o botão direito do mouse no projeto de fluxo de trabalho e selecione Gerar de Orquestração para gerar automaticamente uma orquestração de wrapper (consulte a Figura 7) que iniciará o fluxo de trabalho do WF e roteará mensagens do BizTalk Server 2006 de e para ele.

A orquestração de wrapper gerada automaticamente contém esquemas para as mensagens definidas no ServiceContract. Ele também contém as formas de orquestração do BizTalk Server e o código para receber uma mensagem do BizTalk Server 2006, criar e iniciar a instância de fluxo de trabalho, passar mensagens de entrada para a instância de fluxo de trabalho, receber as mensagens de saída e encaminhá-las de volta para o mecanismo de mensagens do BizTalk Server 2006. Para concluir a hospedagem do fluxo de trabalho do WF, basta compilar e implantar a orquestração de wrapper e associá-la usando o mecanismo biztalk server 2006 normal.

Figura 7. Gerando uma orquestração de wrapper automaticamente

Além de aproveitar o mecanismo de hospedagem robusto e escalonável do BizTalk Server 2006 para fluxos de trabalho do WF, as Extensões do BizTalk Server 2006 para SDK do WF permitem que você aproveite a infraestrutura de mensagens do BizTalk Server 2006. Assim, você pode aproveitar os muitos Adaptadores disponíveis para obter mensagens dentro e fora do BizTalk Server 2006, bem como o processamento de pipeline, incluindo os recursos de mapeamento.

Por mais poderoso que seja, as Extensões do BizTalk Server 2006 para SDK do WF devem ser usadas como uma ferramenta para permitir que os desenvolvedores do WF implantem seus fluxos de trabalho em cima do BizTalk Server 2006, não como um substituto para orquestrações em cenários em que identificamos o BizTalk Server 2006 como a ferramenta adequada. Há algumas formas de WF que não funcionam quando são encapsuladas em uma orquestração. Isso ocorre porque hospedar seus fluxos de trabalho do WF dentro do BizTalk Server 2006 usando as Extensões do BizTalk Server 2006 para O SDK do WF não fornecerá o mesmo comportamento de hospedagem que as orquestrações nativas. O SDK tem uma lista de perguntas frequentes (incluída no Guia de Início Rápido) que descreve essas diferenças.

Conclusão

O BizTalk Server 2006 e o Windows Workflow Foundation são as principais ferramentas da Microsoft para implementar soluções de fluxo de trabalho nas categorias Fluxo de Trabalho de Integração Empresarial e Aplicativo. Para escolher qual é o ideal para seu projeto, primeiro você deve identificar quais dos cenários de fluxo de trabalho você está direcionando.

Em seguida, use a tabela na Figura 8 para ver a tecnologia de fluxo de trabalho recomendada para seu cenário. Para o fluxo de trabalho em um aplicativo, recomendamos wf. Para a maioria dos cenários B2B e processo de negócios baseados em servidor, recomendamos o BizTalk Server 2006.

Figura 8. Tecnologias de fluxo de trabalho específicas do cenário

Para o processo de negócios de execução longa e os cenários do Agregador de Serviço Web, qualquer tecnologia pode ser aplicada de forma afetiva. Para esses cenários, você deve avaliar o perfil apio de destino atual e de curto prazo da sua organização. As organizações que estão ou se movendo em direção aos perfis Avançado ou Dinâmico devem usar o BizTalk Server 2006 para esses cenários. As organizações nos perfis Básico e Standard podem usar o WF efetivamente para esses cenários.

Por fim, você deve considerar as datas de lançamento e o tempo de vida desejado da sua solução, em relação ao roteiro do produto para BizTalk Server 2006 e WF. Ao usar essa estrutura e as diretrizes neste artigo, você deve ser capaz de escolher o fluxo de trabalho certo para seu projeto.

Adendo

Dissipando equívocos sobre o BizTalk Server 2006 vs. WF

Veja a seguir alguns equívocos comuns sobre o WF e o BizTalk Server 2006 e os argumentos esclarecedores que usamos para dissipá-los:

  • WF é a substituição do BizTalk Server 2006.Não. Como o WF é a oferta "mais recente e maior" da Microsoft para fluxos de trabalho de programação, muitos que não estão familiarizados com o BizTalk Server 2006 inicialmente assumem que ele foi tornado obsoleto com o lançamento do WF. A resposta simples para corrigir essa impressão é que o WF é uma estrutura de desenvolvedor de baixo nível para criar todos os tipos de fluxos de trabalho, enquanto o BizTalk Server 2006 é um produto de servidor completo com recursos avançados para uma categoria específica de cenários de fluxo de trabalho: Integração Empresarial. (Consulte a Figura 1.)
    O WF fornece apenas um pequeno subconjunto dessa funcionalidade: fluxo de trabalho e regras de negócios. Embora o WF possa ser uma solução mais simples e econômica para cenários que não exigem todos os outros recursos que o BizTalk Server 2006 fornece, de forma alguma ele suplanta o BizTalk Server 2006 para os principais cenários de Integração Empresarial que o BizTalk Server 2006 foi projetado para dar suporte.
  • BizTalk Server está indo embora.Não. Um equívoco semelhante é a impressão de que, como o WF foi lançado como a ferramenta de fluxo de trabalho do futuro, e o BizTalk Server ainda não foi reescrito para usar o WF, a Microsoft não está mais investindo no BizTalk Server e eventualmente o substituirá por um novo produto baseado em WF. Esse não é o caso; O BizTalk Server tem sido um produto muito bem-sucedido e a área de Integração Empresarial que ele tem como destino continua sendo uma área com o qual a Microsoft está comprometida em dar suporte.
  • Você precisa escolher BizTalk Server 2006 em vez do .NET Framework.Não. Pode ser tentador para os desenvolvedores do .NET que não estão familiarizados com o BizTalk Server 2006 escolher wf em vez do BizTalk Server 2006, apenas com base em que eles preferem ir "puro" .NET. No entanto, esse não é realmente um critério útil; O BizTalk Server 2006 em si é criado no .NET Framework.
    Na verdade, o BizTalk Server 2006 representa mais de 2 milhões de linhas de código .NET que podem ser aplicadas à sua solução, economizando tempo, problemas e custos para desenvolver sua funcionalidade do zero. Além disso, a programação biztalk server 2006 em si é feita dentro do Microsoft Visual Studio .NET, e os componentes são compilados e implantados como assemblies .NET. Além disso, os projetos do BizTalk Server 2006 mais significativos combinam componentes do BizTalk Server 2006 com componentes personalizados do .NET; Portanto, o desenvolvimento do BizTalk Server 2006 deve ser considerado desenvolvimento especializado do .NET, em vez de algo que seja estrangeiro ou diferente.
    A verdadeira questão é se os recursos do BizTalk Server 2006 fornecem valor suficiente para seu cenário de fluxo de trabalho específico para justificar os custos de licenciamento. Você não quer usar uma marreta para pendurar imagens; nem você quer usar o martelo de um carpinteiro para esmagar grandes rochas.
  • a maioria dos recursos vence.uma escolha ruim. Poderíamos colocar uma matriz de recursos que compara os recursos granulares do WF com os do BizTalk Server 2006. No entanto, essa comparação não seria muito útil; O BizTalk Server 2006 tem um número tão grande de recursos direcionados especificamente ao espaço de Integração Empresarial. Se esse não for o cenário de destino, as comparações de recursos não terão sentido. O BizTalk Server 2006 provavelmente ganharia, em termos do número de caixas de seleção de recursos; no entanto, essa é uma comparação entre maçãs e laranjas, se esses recursos não estiverem relacionados ao cenário de fluxo de trabalho que você está direcionando.

Confirmações

Gostaria de agradecer a Paul Andrew e Kris Horrocks, e a todos que revisaram este artigo.

Mais informações

Sobre o autor

Kent Brown é o diretor e arquiteto sênior da Enterprise Integration Practice na Twentysix New York, uma parceira de consultoria da Microsoft Gold Certified em Nova York. Ele está animado com o BizTalk Server desde sua criação em 2000, e tem desempenhado um papel evangelista em torno do produto nos últimos sete anos. Kent é membro da equipe de especialistas técnicos virtuais do Microsoft BizTalk, bem como um MVP do Desenvolvedor de Sistemas Conectados da Microsoft. Ele é o fundador e líder do Nyc Connected Systems Users Group (http://www.NYCCSUG.org).