Waldemir Cambiucci - Solutions Architect - Microsoft Brasil : WF

Algumas palavras sobre Projetos de Missão Crítica

wcamb — Fri, 06 Nov 2009 22:01:00 GMT

Olá pessoal, tudo certo?

Essa semana acompanhei algumas discussões no forum do Grupo .NET Architects. Entre vários assuntos, um em especial chamou minha atenção: projetos de Missão Crítica.

O que você entende por um Projeto de Missão Crítica?

Do wikipedia temos que o termo Missão Crítica refere-se a qualquer fator (equipamento, processo, procedimento, software, etc.) que seja crucial para o sucesso ou completude de uma atividade ou projeto. Também pode se referir a um projeto cujo o sucesso é vital para a missão da organização ou negócio da empresa.

Falando em projetos, vejamos alguns exemplos que considero de Missão Crítica:

- Um sistema de controle e coleta de dados de um projeto em Física Experimental para criação de estado de plasma, rodando sobre sistema operacional Debian/Linux, com processos em C, usando pilha TCP, pode ser considerado de missão crítica para o laboratório, devido as restrições e riscos envolvidos na monitoração e controle de equipamentos;

- Um núcleo de negociação para o mercado financeiro, tratando milhões de operações/dia, envolvendo mensageria em banco de dados, cache distribuído, gerenciamento de recursos em memória, etc., com requisitos rígidos de baixa latência, também é um exemplo de missão crítica;

- Um SDCD – Sistema Digital de Controle Distribuído – para monitoração e atuação de bicos de óleo em caldeiras para a geração de vapor num planta industrial, também é um belo exemplo. Vapor é um elemento chave em diversos processos industriais, de petroquímicas a processamento de atum em lata :)

- Um monitor transacional de alto desempenho, aplicando conceitos como ACID, MUTEX, CRITICAL SESSIONS, SEMÁFOROS, árvores de falhas, etc, é outro exemplo. Uma leitura obrigatória sobre o assunto é o livro Transaction Processing, confira aqui!

- Um sistema SaaS – Software as a Service – sobre algum provedor em nuvem, para uma solução multi-inquilino com interfaces Web, responsável pelo núcleo de faturamento da empresa, é de missão crítica, com requisitos de disponibilidade, responsividade e desempenho. Imagine um sistema SaaS para a venda de ingressos do show de Eric Clapton ou B.B. King! :)

- Um sistema de automação para controle de caixas margem de via, por exemplo, para determinação de presença de trens de metrô e vagões em trechos da via, abertura de portas, desvios de ramais, movimento, etc. O próprio controle do carrossel de composições na via também é crítico. Qual é o trem mais seguro? Um trem parado ou um trem na oficinal, fora da via? :)

- Um sistema para contabilidade e bilhetagem de chamadas em telefonia celular, também é crítico;

- Em muitos cenários, até mesmo um sistema de emails é um sistema de missão crítica para a empresa. Algumas corporações simplesmente param ou perdem negócios em casos de falha em suas caixas postais, por mais commodities que possam parecer. Impacto financeiro a vista!;

- Um sistema de controle de equipamentos médicos, como scanners, tomógrafos, dispositivos de ultra-som, leitores dopplers em tempo real (opa!), entre outros mais sofisticados em medicina, são extremamente críticos em seus resultados.

Considero todos os exemplos acima como sistemas de Missão Crítica em diferentes níveis, pois envolvem riscos para o negócio da empresa.

Assim, podemos destacar três tipos de riscos envolvidos:

Riscos Materiais;
Riscos Financeiros;
Riscos envolvendo Vidas Humanas;

Alguns sistemas de Missão Crítica podem envolver requisitos de Tempo Real (Real Time), isto é, janelas de atuação e tempos resposta bem definidos, que devem ser respeitados. Nesses casos, o número de processos envolvidos, o volume ou o número de chamadas disparadas não deve interferir no tempo de resposta do sistema.

Qual é o tempo de resposta envolvido no tempo real (em milisegundos, por exemplo)? Dependerá do cenário que estamos tratando, seja um canal de feeders de notícias com filtros sobre política ou mensagens para a abertura de cofres em sistemas de segurança bancário.

Normalmente, condições de tempo real estão envolvidas em cenários de missão crítica, mas não são obrigatórias.

Meu ponto aqui é que não podemos considerar como Missão Crítica apenas o aspecto de desempenho e tempo de resposta envolvidos. Para algumas indústrias, outros atributos são tão importantes quanto, como o impacto financeiro, disponibilidade e riscos diversos.

Quão crítico é o sistema em que você está trabalhando hoje? Ele envolve riscos financeiros, riscos humanos ou riscos materiais?

Em resumo, qual é o impacto de uma falha em seu sistema para a execução do negócio de sua empresa? Aspectos como recuperação de falhas, tratamento de exceções, árvore de falhas, etc., tornam-se importantes em muitos casos.

Uma vez identificado o cenário de missão crítica, como conduzir o projeto?

Algumas perguntas são recorrentes neste momento, como:

Qual é o melhor sistema operacional para cada cenário?
Qual é a melhor linguagem de programação para cada cenário?
Qual é a melhor abordagem de patterns para cada cenário?
Quais são as restrições de memória e disco para o SO? Poucos recursos? Desktops? Servidores?
Quais são as necessidades de comunicação com dispositivos e periféricos diversos nesse ambiente de missão crítica?
Quais são os drivers disponíveis para o SO escolhido? Teremos que implementar esses drivers? Existem fornecedores no mercado?
Quais são as latências de rede e pilhas de transporte suportados? O TCP é suficiente? IPv6? Vamos precisar adotar protocolos de Tempo Real (RTP – Real Time Transport Protocol)? Vamos implementar bindings customizados para a entrega de mensagens com baixa latência? Transporte customizado?
Qual a necessidade por tempo real, paralelismos de processos, high performance computing, cluster computing ou grid computing?

Sem falar ainda em questões adjacentes, como:

Qual será o suporte necessário para a solução?
Como será evolução da pilha de software ao longo do tempo?
Qual é o perfil de profissionais capacitados, exigidos para o projeto?
Quais são os guias de desenvolvimento e patterns disponíveis?
Quais são as ferramentas para a construção de software, metodologias, documentação, etc.

Através aqui do blog, temos acompanhado a plataforma Microsoft e seu suporte para aplicações de missão crítica em diferentes níveis.

Existem diversos recursos que atendem esses cenários, seja sobre a plataforma .NET ou mesmo sobre código não gerenciado, com processos em C++ sobre Windows Server. No ambiente gerenciado, recursos como interfaces de serviços em WCF – Windows Communication Foundation, mensageria com MSMQ, paralelismo, sincronização e sistemas de integração com baixa latência são alguns exemplos. Em todos os casos, o impacto para o negócio da empresa está presente.

Em breve, teremos ainda novos recursos disponíveis na plataforma Microsoft, como o Dublin (para hospedagem de serviços e processos sobre o Windows Server), o Velocity (para cache distribuído e aplicações de alto desempenho), novos recursos sobre WCF 4 e WF 4, além da integração com a plataforma de alta escalabilidade e disponibilidade do Windows Azure, que já está em contagem regressiva para seu lançamento, durante o PDC 2009.

Finalizando, procure identificar em quais cenários de Missão Crítica você está pessoalmente envolvido e como será a evolução destes nos próximos meses. Você vai perceber que sua TI tem um impacto direto para o sucesso de sua empresa!

Por enquanto é só! Até o próximo post :)

Waldemir.

Architecture in a Box: WF – Windows Workflow Foundation

wcamb — Tue, 13 Oct 2009 11:05:00 GMT

Olá pessoal, tudo certo?

Como você já percebeu, estou aproveitando o mês de outubro para consolidar diversos temas que temos visto ultimamente numa única série chamada “Architecture in a Box”.

As sessões são nível 200/300 e falam de temas como WCF, SOA, MDD, OSLO, WEB, RIA, entre outros.

A sessão de hoje fala de WF – Windows Workflow Foundation, um framework da plataforma .NET que permite a construção de processos, máquinas de estado e workflows. Em cenários de composição de regras e serviços no domínio da aplicação, WF é uma excelente alternativa, que vale ser estudada!

View more documents from Waldemir Cambiucci.

Em breve, teremos o lançamento do WF 4.0, que oferece ainda novos recursos para a construção de workflows, ampliando os cenários de composição. Veja alguns links sobre WF 4.0 abaixo:

The Workflow Way: Understanding Windows Workflow Foundation (muito bom!)
Ref.: http://msdn.microsoft.com/en-us/library/dd851337.aspx

A Developer's Introduction to Windows Workflow Foundation (WF4) in .NET 4 Beta 1
Ref.: http://msdn.microsoft.com/en-us/library/ee342461.aspx

Na sessão de hoje, apresento alguns tópicos sobre o WF 4.0 no final, aproveitem.

Por enquanto é só! Até o próximo post :)

Waldemir.

Um universo de material para estudo...

wcamb — Thu, 04 Jun 2009 19:57:00 GMT

Olá pessoal, tudo certo?

No princípio era só o MSDN e todos os DevCenters de tecnologias estavam disponíveis a partir dele:

MSDN Brasil
Ref.: http://msdn.microsoft.com/pt-br/default.aspx

Com o passar do tempo, mais e mais tecnologias foram sendo lançadas e um Universo de material ficou disponível (em português):

Microsoft na Nuvem
- Plataforma Azure
Ferramentas e Linguagens
- Visual Studio
- Visual Studio Express
- Visual Studio Team System
- Visual Basic
- Visual C#
- Visual C++
Desenvolvimento Web
- ASP.NET
- Silverlight
- Internet Explorer
Desenvolvimento .NET
- .NET Framework
- .NET Compact Framework
Desenvolvimento Windows
- Windows Cliente
- Windows Mobile
- Windows Embedded
Melhores Práticas
- Arquitetura
- Patterns & Practices
Desenvolvimento Enterprise
- SQL Server
- Segurança
- Microsoft Solutions Framework
Desenvolvimento Office
- Office
- SharePoint

Ao longo do tempo, o .NET Framework também evoluiu…

E diversos arquitetos se perguntaram onde encontrar mais informações sobre toda essa evolução. A resposta foi dada abaixo:

.NET Framework
Ref.: http://msdn.microsoft.com/pt-br/netframework/default.aspx

Alguns tiveram um interesse maior sobre serviços e interfaces e como o WCF - Windows Communication Foundation poderia ajudá-los…

WCF – Windows Communication Foundation – Media Center
http://www.msdnbrasil.com.br/microsoft.MediaCenter/Default.aspx_x_CATEGORY_x_WCF.aspx

Outros se perguntaram sobre processos, workflows e máquinas de estado, lugares comuns para o WF - Windows Workflow Foundation.

WF – Windows Workflow Foundation
http://www.msdnbrasil.com.br/microsoft.MediaCenter/Default.aspx_x_CATEGORY_x_Windows%20Workflow%20Foundation.aspx

Tudo em português!!! Artigos, webcasts, treinamentos, centros de estudo, um mundo de leitura gratuíto e disponível para todos!!!

E para as interfaces desktop ou web? O WPF – Windows Presentation Foundation também ganhou seu lugar:

WPF – Windows Presentation Foundation
http://www.msdnbrasil.com.br/microsoft.MediaCenter/Default.aspx_x_CATEGORY_x_WPF.aspx

E para os mais exigentes, que buscam soluções sofisticadas, o WindowsClient.NET também surgiu:

Ref.: http://windowsclient.net/default.aspx (esse está em inglês!)

Finalmente, arquitetos e equipes de desenvolvimento se perguntaram por onde começar. Como criar seu roadmap de capacitação e certificação e seguir os primeiros passos pelos vários caminhos da plataforma Microsoft? Eis que uma nova porta se abriu:

Centro de Capacitação e Recursos para Certificação do MSDN
Ref.: http://msdn.microsoft.com/pt-br/bb188199.aspx

E o universo de estudos em constante expansão gerou mais uma fronteira chamada rampup…

Ref.: http://msdn.microsoft.com/pt-br/rampup/default(en-us).aspx

Quem tem ouvidos para ouvir, ouça!!! ;)

Feliz o arquiteto e o desenvolvedor que aproveitar cada material de estudo acima disponível, pois eis que o tempo chegou para a construção de soluções mais sofisticadas, compatíveis com o mundo de serviços, de interfaces RIA, de soluções compostas e aplicações na nuvem.

Um abraço grande a todos e bom estudo!!!

Por enquanto é só! Até o próximo post :)

Waldemir.

Artigo: Uma introdução ao Software + Serviços, SaaS e SOA

wcamb — Tue, 02 Jun 2009 22:38:00 GMT

Olá pessoal, tudo certo?

Boas Novas: já está no ar meu novo artigo sobre SOA, SAAS e Software + Services no MSDN Brasil. Ele acabou de ser publicado e está disponível na URL abaixo:

Uma introdução ao Software + Serviços, SaaS e SOA
por Waldemir Cambiucci
Maio de 2009
Ref.: http://msdn.microsoft.com/pt-br/library/dd875466.aspx

Entre outros assuntos, o artigo trata os principais aspectos envolvidos na visão Software + Serviços, usando como base os pilares abaixo:

Não deixe de conferir e fazer seus comentários!

Por enquanto é só! Até o próximo post :)

Waldemir.

Cloud Sequential Workflow : um template para workflows na nuvem

wcamb — Thu, 07 May 2009 02:58:00 GMT

Olá pessoal, tudo certo?

Semana passada, estive explorando o CTP de Março do Windows Azure e encontrei alguns templates bem interessantes. Entre os projetos disponíveis temos:

Cloud Service/Web Cloud Services
Cloud Service/Worker Cloud Services
Cloud Service/Web and Worker Cloud Services
Cloud Service/Roles/Cgi Web Role
Cloud Service/Roles/Web Role
Cloud Service/Roles/Worker Role
CloudWorkflow/CloudSequentialWorkflow

Um deles é especialmente indicado para a coordenação de chamadas a serviços na nuvem, o template “Cloud Sequential Workflow”.

Apenas para relembrar, o .NET Framework suporta dois tipos de workflows no Windows Workflow Foundation (WF), o Sequential Workflow e o State Machine Workflow.

Um workflow sequencial (ou Sequential Workflow) pode ser entendido como um fluxo de trabalho previsível. Ou seja, sua execução pode ser feita através de condições, loops, delays, a partir de eventos disparados externamente mas no final, o workflow sequencial irá executar suas atividades, condições e regras sempre na sequência, avançando sempre para o final do fluxo e sua completude. Assim, o workflow está no controle do processo. Podemos usar esse tipo de workflow quando queremos implementar a tomada de decisoes dentro do próprio workflow, a partir dos shapes de condições, regras e atividades.

Um workflow de máquina de estado (ou State Machine Workflow) é um workflow orientado a eventos. Isto significa que o workflow de máquina de estado depende de eventos externos para determinar sua completude ou término. Não temos uma ordem predeterminada de estados executados. Podemos definir os estados possíveis do workflow, assim como as transições possíveis entre seus estados. O workflow irá sempre de um estado para outro, esperando por novos eventos para determinar o próximo estado de transição. Geralmente, as decisões que determinam o estado do workflow acontecem fora do workflow. A máquina de estado define assim a estrutura do workflo, mas o controle reside fora do próprio workflow. Podemos usar um workflow de máquina de estado quando o processo de decisão ocorre fora do workflow, em eventos externos.

Já vimos aqui no blog que o .NET Services do Azure Services Platform possui o Workflow Services, um conjunto de capacidades que permite a hospedagem de workflows do tipo sequencial na nuvem. Veja mais aqui.

Através do template “Cloud Sequential Workflow” podemos construir workflows do tipo sequencial, coordenando o recebimento de chamadas e envio de mensagens para o .NET Services / Service Bus, consumindo os serviços publicados ali. Esse tipo de coordenação torna-se muito interessante quando pensamos na integração de sistemas que usam a nuvem como ponto central, orquestrando mensagens entre serviços. Veja mais sobre esse tipo de cenário no projeto MEBA – Multi-Enterprise Business Application da Microsoft, aqui.

Um exemplo de workflow recebendo uma mensagens via http e fazendo a troca de mensagens com serviços no Service Bus é ilustrado a seguir:

Para a construção de workflows como esse, o Microsoft .NET Services SDK (March 2009 CTP) oferece uma série de shapes novos que são colocados na Toolbox do Visual Studio 2008, como vemos abaixo:

Entre os principais shapes, destacamos o CloudServiceBusSend e o CloudServiceBusReceive, que permitem a comunicação com serviços publicados no Service Bus.

Ainda, podemos controlar a sequência de execução através de shapes como IfElse, blocos de sequencia Sequence, Suspend, Terminate e While, para loops e controles de iterações.

Para iniciar seus experimentos, comece instalando o SDK do .NET Services, abaixo:

Microsoft .NET Services SDK (March 2009 CTP)
Ref.: http://www.microsoft.com/downloads/details.aspx?FamilyID=8d1d1d5e-1332-4186-b33f-26d053759e49&displaylang=en

Confira também o blog do time:

Ref.: http://blogs.msdn.com/netservices/

E os artigos (em inglês) a seguir:

Ref.: An Introduction to Microsoft .NET Services for Developers
Ref.: A Developer’s Guide to the Microsoft® .NET Service Bus
Ref.: A Developer’s Guide to the Microsoft® .NET Access Control Service
Ref.: A Developer’s Guide to the Microsoft® .NET Workflow Service

Esse post foi só uma visão rápida sobre o assunto. Em posts futuros, vamos falar mais desse template de workflows na nuvem e alguns exemplos mais interessantes. Aguardem!

Por enquanto é só! Até o próximo post :)

Waldemir.

Webcast sobre WCF + WF : integrando serviços e workflows

wcamb — Fri, 17 Apr 2009 19:56:00 GMT

Olá pessoal, tudo certo?

Já está no ar um webcast sobre WCF+WF, que fiz recentemente para o pessoal do Dev Center de .NET Framework, no MSDN.

Esse webcast fala sobre alguns templates de WCF e WF, destacando também os mecanismos de integração entre serviços e workflows, vale conferir:

Ref.: http://download.microsoft.com/download/B/6/7/B6790106-5A1F-452F-952C-616D604C67E2/WEBCAST_WCFWF_20090329.zip

Por enquanto é só! Até o próximo post :)

Waldemir.

Sequential Workflow Service Library : integrando serviços WCF com workflows WF no .NET 3.5

wcamb — Wed, 18 Mar 2009 01:15:00 GMT

Olá pessoal, tudo certo?

Em breve teremos a chegada do .NET 4.0, com uma série de inovações e melhorias em seus recursos. Entre os benefícios, a dupla WCF (Windows Communication Foundation) e WF (Windows Workflow Foundation) promete maior integração e aderência ao modelo híbrido de programação enterprise/cloud (local e nuvem).

Um desenho conhecido aparece abaixo, onde nosso workflow encapsula chamadas para outros serviços externos, enquanto ele mesmo é exportado como um serviço, para outros participantes da solução.

Esse tipo de cenário é bem interessante para arquiteturas de serviços, onde pequenas orquestrações podem coordenar chamadas diversas para serviços da infra-estrutura. Assim, desenhos como esse abaixo são comuns em muitas empresas:

Com o .NET 3.0 era possível o consumo de serviços a partir de workflows em WF somente através de interfaces Web Services. Esse tipo de interação era obtida com os shapes de invocação e tratamento de Web Services, como o InvokeWebService, WebServiceInput, WebServiceOutput e WebServiceFault.

Com o .NET 3.5, a integração WCF + WF aumentou, com templates interessantes como o Sequential Workflow Service Library, objeto deste post.

Nesses últimos dias, tenhos conversado com muitas empresas que têm perguntado sobre essa integração entre interfaces de serviços e workflows em soluções para diversos cenários.

Como criar um SERVIÇO como um WORKFLOW?

Para a criação de um serviços como workflow, o .NET 3.5 oferece o template Sequential Workflow Service Library, que oferece uma interface de publicação WCF para um workflow WF.

Através deste template, temos a disposição todos os shapes e recursos do WF para a coordenação de atividades e chamadas para outros serviços ou mesmo outros workflows da solução. Ao mesmo tempo, esse workflow implementa uma interface IWorkflow, que exporta um contrato de serviço, permitindo que aplicações clientes disparem mensagens para consumo. No template, a interface IWorkflow implementa um método GetData(..) exemplo, o mesmo implementado pelo template de WCF Service Library.

A figura ao lado ilustra o template Sequential Workflow Service Library como oferecido pelo Visual Studio e o .NET 3.5.

Podemos adicionar novas interfaces de serviços através da adição de novos contratos de operação ou mesmo contratos de dados na interface IWorkflow, conforme a necessidade.

Ao mesmo tempo, podemos adicionar novos shapes de WF ao workflow, para o tratamento dos valores de entrada e execução da lógica de negócio desejada, preparando o valor de retorno do serviço.

Um exemplo de serviço WCF implementado como um WF é dado a seguir, veja:

Arquivo: workflow1.cs

No serviço acima, temos uma primeira atividade codeActivity1 que recebe o valor de entrada do serviço na variável InputValue. Os argumentos de entrada (InputValue) e saída (ReturnValue) do serviço são de fato oferecidos pelo template, como vemos a seguir:

No exemplo acima, o valor InputValue é colocado na propriedade myCond, que é testada na condição do shape ifElseActivity1. Para teste, foi criada uma cláusula declarativa de condição myCond, que verifica se o valor de myCond é igual a 0. Se for, a atividade codeActivity2 é executada, caso contrário, a atividade codeActivity3 é executada. No final, codeActivity4 adiciona uma string na mensagem de retorno do serviço, que feito através da propriedade ReturnValue do serviço.

O código completo deste serviço é dado a seguir:

   1: using System;   2: using System.Workflow.Activities;   3:     4: namespace myWorkflowService   5: {   6:     public sealed partial class Workflow1 : SequentialWorkflowActivity   7:     {   8:         // Minha variável interna para teste de condição no workflow.   9:         public int myCond = 0;  10:    11:         public Workflow1()  12:         {  13:             InitializeComponent();  14:         }  15:    16:         // These variables are bound to the input and output parameters of the ReceiveActivity.  17:         private String returnValue;  18:         private Int32 inputValue;  19:    20:         public Int32 InputValue  21:         {  22:             get { return inputValue; }  23:             set { inputValue = value; }  24:         }  25:    26:         public string ReturnValue  27:         {  28:             get { return returnValue; }  29:             set { returnValue = value; }  30:         }  31:    32:         private void codeActivity1_ExecuteCode(object sender, EventArgs e)  33:         {  34:             this.myCond = InputValue;  35:         }  36:    37:         private void codeActivity2_ExecuteCode(object sender, EventArgs e)  38:         {  39:             ReturnValue = "passei pelo IF";  40:         }  41:    42:         private void codeActivity3_ExecuteCode(object sender, EventArgs e)  43:         {  44:             ReturnValue = "passei pelo ELSE";  45:         }  46:    47:         private void codeActivity4_ExecuteCode(object sender, EventArgs e)  48:         {  49:             ReturnValue = ReturnValue + " - Fim!";  50:         }  51:     }  52: }

Para testes, podemos usar o WCF Test Client do Visual Studio para exercitar chamadas ao serviço, alterando os valores de entrada do método GetData, como vemos abaixo:

Desse modo, vimos um bom exemplo de template que pode ser usado em nossas aplicações e soluções envolvendo os conceitos de interfaces de serviços e workflows, integrando os recursos do WCF e do WF no .NET 3.5.

Em posts futuros, vamos falar um pouco mais sobre a integração WCF+WF no .NET 4.0 e as novidades que estarão chegando, fiquem ligados!

Por enquanto é só! Até o próximo post :)

Waldemir.

Interoperabilidade e Comunicação na plataforma Microsoft : o que e quando usar?

wcamb — Wed, 11 Feb 2009 20:59:00 GMT

Olá pessoal, tudo certo?

No post anterior vimos que a interoperabilidade na plataforma Microsoft pode ser organizada em 3 níveis básicos de complexidade:

Interop in the Framework
Interop in the Box
Interop in the Cloud

Os recursos assim agrupados permitem um melhor entendimento das necessidades de cada solução, seja através da customização com WCF, WF, seja via um motor de mensageria e transformação com o BizTalk Server ou um barramento de mensanges com o ESB Guidance, ou até mesmo um modelo de integração entre empresas através da nuvem, no chamado ISB - Internet Service Bus, como .NET Services do Azure.

Falamos também de 4 componentes importantes para a interoperabilidade no ambiente enterprise (local). Vejamos:

O que usar?

Microsoft® BizTalk® Server (BTS) : BizTalk oferece uma pilha ampla de adaptadores, orquestração, mensageria e protocolos para a construção de soluções preparadas para EAI - Enterprise Application Integration. Através de ferramentas de mapeamento de mensagens, manipulação de schemas, transformação, monitoração e regras de negócio, o ambiente BTS permite a construção de soluções de mensageria em cenários de elevado volume de mensagens e vazão;
Microsoft Host Integration Server (HIS) : HIS oferece uma plataforma para a conectar aplicações com sistemas da plataforma IBM zSeries e iSeries. Ainda, HIS suporta a conexão de dados entre Microsoft Message Queuing (MSMQ) e o IBM WebSphere MQ;
Microsoft Message Queuing (MSMQ) : o MSMQ permite a conexão de entre aplicações usando um modelo de fila de mensagens. MSMQ oferece a garantia de entrega de mensagens, mensagens baseadas em prioridades e segurança. Ele suporta a integração com sistemas parcialmente conectados ou temporariamente offline. MSQM também suporta cenários de mensageria síncrona e assíncrona;
Microsoft Enterprise Service Bus (ESB) Guidance : o ESB Guidance é uma unidade lógica que oferece uma arquitetura desacoplada baseada em mensagens, usando para isso a infra-estrutura do BizTalk Server. O ESB Guidance é na verdade um conjunto de templates e patterns que extendem as funcionalidades do BTS, adicionando características como roteamento de mensagens, repositório de serviços, garantia de entrega, segurança de mensagens, registro de serviços e tratamento unificado de exceções;

Cada uma das tecnologias acima aplica patterns de arquitetura importantes para diversos cenários de integração em TI. Porém, cada cenário exige uma tecnologia mais adequada que a outra. Adotar um modelo síncrono de mensageria quando nossa solução permite cenários parcialmente conectado pode ser desastraso, por exemplo. Então, surge a pergunta:

Quando usar?

Considere o uso de BizTalk Server quando:

quando a solução interage com múltiplos web services via uma orquestração, como parte de uma arquitetura orientada a serviços (SOA), suportando as latências de I/O devido a transformação de mensagens, persistência de mensagens para tracing ou latência devido subscrição/distribuição de mensagens;
quando a solução deseja suportar processos business-to-business (B2B), incluindo padrões de indústria como EDIFACT, ANSCI X12, HL7, HIPAA, or SWIFT.
quando a solução exige a execução de serviços em paralelo, com mecanismos facilitadores para esse tipo de orquestração e sincronização entre processos;
quando a solução exige alta confiabilidade e infra-estrutura dedicada para escalabilidade, com garantia de entrega e recuperação de mensagens;
quando a solução necessita medir KPI's - Key Performance Indicators de negócio, através de um motor de análise como BAM - Business Analysis Manager, que deve fornecer uma visibilidade em tempo real sobre os dados processados pela solução;
quando a solução deseja abstrair a lógica de negócios e aplicações através de políticas, que podem ser alteradas de acordo com as necessidades de negócio da solução;

Considere o uso de Host Integration Server quando:

quando a solução precisa suportar interação com aplicações IBM zSeries ou iSeries;
quando a solução deve integrar BizTalk com DB2, WebSphere MQ, Aplicações Host (em plataforma alta) ou servidores de arquivos;
quando a solução deve integrar mensageria MSMQ com WebSphere MQ;

Considere o uso de Message Queuing quando:

quando a solução deve suportar interação entre aplicações baseada em mensagens;
quando a solução precisa integrar plataformas Microsoft e Não-Microsoft, suportando a conversação assíncrona;
quando a solução precisa suportar conversação SRMP - SOAP Reliable Messaging Protocol entre as aplicações envolvidas;

Considere o uso de Enterprise Service Bus Guidance quando:

quando a solução necessita suportar a abordagem de mensageria com itinerário de mensagens ou roteamento entre sistemas envolvidos;
quando a solução deve suportar a resolução dinâmica de roteamento de mensagens;
quando a solução deve usar transformação de mensagens dinâmicamente;
quando a solução deve suportar um gerenciamento de exceções de forma unificada e robusta, para a integração de sistemas EAI;
quando a solução necessita de uma abordagem de repositóio de serviços, para publicação de funcionalidades envolvidas;

O mapa acima é uma relação parcial de benefícios ou aspectos de arquitetura que justificam cada tecnologia para uma dada solução. Claro, para alguns cenários, podemos abrir mão dos pacotes acima e simplesmente implementar nossos próprios componentes de integração, interoperabilidade ou orquestração usando frameworks como o WCF - Windows Communication Foundation e o WF - Windows Workflow Foundation, sempre considerando o esforço de nosso próprio desenvolvimento.

No final, podemos construir uma matriz de decisão, que pode nos ajudar no momento de análilse de uma solução e as tecnologias mais indicadas. Fica a dica para ampliar esse estudo e detalhamento destacando os aspectos mais importantes para sua própria solução.

Por enquanto é só! Até o próximo post :)

Waldemir.

Cenários de implementação de serviços com WCF - Parte 6 : Serviços para Workflow

wcamb — Thu, 17 Jul 2008 23:57:00 GMT

Serviços para Workflow

Olá pessoal, tudo certo?

Mais um cenário, importante na discussão sobre orquestração, coordenação de processos e fluxos de trabalho: serviços para workflows.

Em arquiteturas orientadas a serviços, é comum o uso de serviços de negócios que encapsulam um série de funcionalidades, disponibilizando esses recursos através de um firewall (em intranets) ou diretamente para clientes na internet. Como benefícios dessa publicação temos um melhor reuso, manutenção, isolação, tolerância a falhas, distribuição e escalabilidade.

Interfaces WCF tornam esse encapsulamento mais fácil, através da definição clara de contratos de mensagens e questões sobre o transporte e segurança. Porém, não temos uma definição sobre a ordem das chamadas ou execução desses serviços dentro da aplicação. Com o .NET 3.0 foi introduzido também o WF - Windows Workflow Foundation, que oferece mecanismos para a construção de workflows e pode ser hosteado em aplicações Windows. Com o uso de workflows ou fluxos de trabalhos, é possível coordenadar as atividades de negócio e requisições de serviços, sendo o método ideal para organizar chamadas para serviços WCF em processos de longa duração.

O .NET 3.5 trouxe novas funcionalidades e entre elas, uma maior facilidade para o consumo de serviços WCF a partir de fluxos de trabalho em WF. Isso tornou a integração WCF + WF muito mais direta e de fácial programação. Também com o .NET 3.5 temos o recurso de serviços duráveis, onde o estado de uma instância de serviço é automaticamente salvo entre chamadas. Isso torna possível a re-hidratação de uma mesma instância de serviço em diferentes máquinas.

A figura a seguir ilustra uma integração WF / WCF, onde um fluxo de trabalho consome uma funcionalidade exportado por um serviços WCF:

Podemos publicar um workflow em qualquer tipo de aplicações Windows. Alguns exemplos de implementação são:

Uma aplicações cliente Windows que oferece um workflow que coordena chamadas para serviços WCF remotos, publicados no IIS, WAS ou um Windows NT Service;
Uma aplicação ASP.NET que inicia um workflow para coordenar chamadas para serviços WCF remotos publicados em Windows NT Services atrás do firewall de um intranet.

Um video interessante sobre exportação de WF como services WCF é encontrado aqui:

Building WCF Services Using Workflow Foundation
Ref.: http://www.microsoft.com/uk/msdn/nuggets/nugget/285/wf-v35-building-wcf-services-using-workflow-foundation.aspx

Para finalizar, outro cenário típico para a aplicação de workflows é a aprovação e geração de documentos. Um artigo que ilustra bem esse exemplo é dado a seguir:

Crie fluxos de trabalho para obter dados e criar documentos
Ref.: http://msdn.microsoft.com/pt-br/magazine/cc534981.aspx

Nesses últimos dias, passamos pelas principais características de cada cenário, comuns em ambientes corporativos e soluções de negócio.

Aproveito para agradecer ao amigo Rogério Cordeiro, pelas discussões e questões levantadas até aqui. Em breve, vamos ter algumas surpresas como resultado dessas discussões.

Por enquanto é só! Até o próximo post :)

Waldemir.

Technorati Tags: SOA,WCF,Services,Workflow

Do Windows DNA para o mundo orientado a serviços : uma proposta para estudo.

wcamb — Fri, 18 Apr 2008 14:17:00 GMT

Olá pessoal, tudo certo?

No último post, começamos nosso papo sobre evolução de uma arquitetura WinDNA para uma plataforma mais atual. Vimos que antes de tudo, precisamos ter uma visão clara sobre os cenários envolvidos, assim como conhecer as novas tecnologias oferecidas pelo mercado. Nesse aspecto, novos frameworks estão disponíveis na plataforma Microsoft e cabe a nós, arquitetos, conhecê-los e exercitá-los, afim de melhor decidir sobre cada alternativa de evolução para nossas aplicações.

Considerando a disposição de componentes na plataforma WinDNA, podemos estudar uma alternativa de solução, conforme a figura a seguir:

Camada de apresentação : ASP.NET com Microsoft AJAX versão 1.0 e Silverlight 2.0.

Para uma aplicação tipicamente Web, a construção de uma interface rica (RIA - Rich Internet Application), que traga as funcionalidades e recursos da Web 2.0 é recomendável. E sobre recursos pensamos não somente em wikis, fóruns, webparts, controles gráficos, streaming, etc, mas também em novas abordagens de apresentação e UX - User Experience. Pensando ainda na composição de serviços e workflows, conceitos de aplicações compostas ou mashups também é uma capacidade que deve ser avaliada para nossa arquitetura.

Nesse ponto, a infra-estrutura ASP.NET com AJAX e Silverlight 2.0 oferece essa gama de recursos para a construção de interfaces poderosas em .NET. Claro, devemos avaliar qual a aderência de nossa aplicação para todas essas inovações. Mas os novos recursos de administração do IIS 7.0 devem ser avaliados, independente do grau de ousadia de nossa nova interface. O IIS 7.0 seria nossa infra-estrutura de suporte às páginas e requisições HTTP/HTTPS, etc. sobre o Windows Server 2008.

Para saber mais sobre o IIS 7.0 e esses recursos, não deixe de ver a série especial sobre o produto no blog do Danilo Bordini, onde temos:

IIS 7.0 (Internet Information Services): Parte 7: Delegação
IIS 7.0 (Internet Information Services): Parte 6: Configuração
IIS 7.0 (Internet Information Services): Parte 5: Extensibilidade
IIS 7.0 (Internet Information Services): Parte 4: Segurança
IIS 7.0 (Internet Information Services): Parte 3: Pilares
IIS 7.0 (Internet Information Services): Parte 2: Evolução da Plataforma
Série Especial - IIS 7.0 (Internet Information Services)

Ref.: http://blogs.technet.com/dbordini/archive/tags/Internet+Information+Services+_2800_IIS_2900_/default.aspx

e para saber mais sobre o Silverlight 2.0 e o AJAX 1.0, veja os links:

Ref.: http://silverlight.net/

Ref.: http://www.asp.net/ajax/

E sempre é bom acompanhar como está a evolução do modelo ASP.NET MVC Framework, ainda em Preview 2 (Model-View-Controller). Veja aqui:

Ref.: http://www.microsoft.com/downloads/details.aspx?FamilyID=38CC4CF1-773A-47E1-8125-BA3369BF54A3&displaylang=en

Camada de colaboração de processos : Windows Workflow Foundation (.NET 3.5)

Em alguns cenários, podemos pensar na implementação de processos de negócio através de fluxos de controle ou mesmo máquinas de estado. Quando falamos em fluxos de controle (ou workflows), pensamos num cenário onde a execução de atividades é sequencial, a partir de eventos que são tratados numa ordem esperada. Temos uma atividade inicial e uma atividade final bem definida. Quando falamos em máquinas de estado, a execução das atividades é orientada por eventos, que podem ocorrer numa ordem aleatória. Assim, nosso desenvolvimento é baseado no estado corrente, com transições por eventos, sendo mais flexível para mudanças externas.

A implementação de um processo de negócio através de um workflow ou máquina de estados pode ser feita através do WF - Windows Workflow Foundation. Como vimos em posts anteriores, podemos ainda integrar esses processos com serviços do WCF - Windows Communication Foundation, ou ainda outros processos de negócio.

Finalmente, lembre-se que um processo pode ter interação humana para aprovações ou submissões, o que pode caracterizar execuções de longa duração. A interação de serviços ou outras camadas com esse tipo de processo precisa ser bem pensada e sinalizada para toda a arquitetura.

Algumas perguntas: Quais são os processo de longa duração e de curta duração presentes em nossa arquitetura? Podemos implementar parte da lógica e regras de negócio em processos com WF?

Para saber mais sobre WF e processos, veja:

Ref.: http://msdn2.microsoft.com/en-us/netframework/aa663322.aspx

Camada de serviços e negócicos : Windows Communication Foundation e serviços hosteados no WAS - Windows Process Activation Service

Surge então a discussão sobre a camada de serviços. O que é mesmo um serviço? :)

Podemos pensar na implementação de classes de negócio, com suas business entities e business process, utilizando a infra-estrutura do WCF para sua exportação e publicação de interfaces. Quando surge o WCF em nossa arquitetura, precisamos discutir alguns pontos importantes:

Qual será o template de serviço que usaremos? Nesse template, precisamos considerar o tratamento de exceção, a propagação de mensagens de erro, exportação de contadores de performance, e também aspectos de comportamento do serviço, contrato de dados, suporte transacional, mensagens tratadas, etc.

Qual será o transporte tratado pelo serviço? A definição do binding (para nosso endpoint) é tão importante quanto a definição do próprio serviço. Através do binding correto, garantimos a melhor performance para a interação entre camadas, processos e serviços.

Qual será o host para execução de serviços? Aqui, surge o WAS, já comentado em posts anteriores. Veja:

Windows Process Activation Service (WAS) - Um mecanismo de ativação de processos e serviços.
Ref.: http://blogs.msdn.com/wcamb/archive/2008/04/10/windows-process-activation-service-was-um-mecanismo-de-ativa-o-de-processos-e-servi-os.aspx

A importância da definição do host está associada ao processo de execução, mas também de administração, governança, distribuição e monitoração dos serviços em nossa arquitetura. Sem dúvida, cuidado muito especial é exigido.

Camada de negócio e aplicações LOB : COM+ 1.5 e MSDTC

Um ponto importante nessa arquitetura para estudo é que ainda podemos conviver com componente publicados no COM+, isto é, componentes COM que estão hosteados no Component Services (veja comexp.msc) e ainda aproveitam o MSDTC - Distributed Transaction Coordinator para o suporte transacional. Esses componente podem e devem permanecer em nossa arquitetura. Isso significa que é possível conviver com esse legado, seja através de camadas de interoperabilidade (interop .NET) ou simplemente consumindo esses componentes através de Web Services. Para alguns casos, teremos traduções entre ambiente gerenciado .NET e não-gerenciado, o que deve causar um certo delay, que deve ser avaliado.

A questão sempre será sobre a viabilidade (de custo, recursos e tempo) para a migração desses componentes (COM+ WinDNA) para .NET.

Camada de acesso a dados e LOB : bancos de dados legado e aplicações LOB

E para o acesso aos dados temos algumas alternativas, como:

ADO.NET 2.0, quando usamos o .NET 2.0 e seus recursos como Dataset, DataReader, Datatable, DataAdapter, DbConnection, DbCommand, etc.;
LINQ TO SQL, quando usamos .NET 3.5 e estamos falando com servidores da família SQL Server;
LINQ TO ENTITY, quando usamos ADO.NET Entity Framework (ainda em Beta 3), para falar com outros servidores de bancos de dados, através do providers oferecidos no mercado.

Já falamos sobre LINQ e Entity Framework em alguns posts anteriores, veja aqui:

Ref.: http://blogs.msdn.com/wcamb/archive/tags/LINQ/default.aspx

A decisão entre as tecnologias de acesso a dados e camadas de persistência acima vai depender da orientação do projeto, entre a especialização para um middleware de alto desempenho, focado num único banco, ou um middleware de abstração e mapeamento, que permitirá trocas futuras de bancos de dados sem impacto na aplicação, porém, com um custo de mapeamento de traduções que deve ser avaliado quanto a performance.

Mais uma vez, é importante lembrar que cada caso é um caso, sempre!

A estrutura em camadas acima foi colocada apenas como pretexto para a discussão dos frameworks e tecnologias disponíveis. Caberá a cada equipe de arquitetura avaliar internamente a aderência às suas próprias aplicações.

Porém, tenha em mente que sua nova plataforma precisa estar antenada com as tendências de colaboração e integração de Software + Serviços que temos observado.

Construir preparado para a mudança, já que tudo se move, tudo flui, é uma prática cada vez mais desejada, já dizia Heráclito de Éfeso, uns 500 a.C. :) Panta hrei!

Por enquanto é só! Até o próximo post :)

Waldemir.

Do Windows DNA para o mundo orientado a serviços : cada caso é um caso?

wcamb — Sun, 13 Apr 2008 01:26:00 GMT

Olá pessoal, tudo certo?

A partir dos últimos emails, tive uma grande discussão com o amigo Rogério Cordeiro (aqui do MSDN) sobre o uso de WCF, WF e outros frameworks na evolução de arquiteturas WinDNA usadas em algumas aplicações típicas. Cenários como Internet Banking, Interfaces de Corretoras, Acompanhamento de Pedidos ou Portais de Comércio Eletrônico são bons exemplos. Ao final da discussão, começamos a traçar um mapa sobre alternativas de arquiteturas e tecnologias para a evolução desse tipo de plataforma.

Se relembrarmos os tempos de Windows DNA - Windows Distributed interNet Applications Architecture (anunciado em setembro de 1999, você se lembra?), a camada de apresentação era implementada em páginas ASP/HTML, enquanto a lógica de negócio era implementada através de componentes COM+, hosteados no COM+ 1.0 do Windows NT 4.0 ou Windows 2000 Server. O controle e a coordenação de transações eram feitos através do MSDTC - Microsoft Distributed Transaction Coordinator e a camada de dados era isolada em servidores dedicados, acessados pelos componentes de negócio. E quando havia transações disparadas na plataforma alta (mainframes), o uso de COMTI e COMAREA era muito comum (saudades de uma TLB ? :)

A figura abaixo representa bem o famoso WinDNA:

Outro ponto importante nessa discussão era o modelo de threads implementado pelo Visual Basic 6.0, grande gerador de componentes COM na época. Tipicamente, VB6 gera componentes STA - Single Thread Apartment, o que provoca o enfileiramente de mensagens devido sua limitação no tratamento de múltiplas chamadas para a mesma thread. O modelo que liberava esse enfileiramento é conhecido como MTA - Multi Thread Apartment, que é obtido em componentes COM implementados em C++ ou agora em .NET.

Um bom artigo sobre o WinDNA está no link abaixo:

Windows DNA Architecture Design: A Scalable, Highly Available Business Object Architecture
Ref.: http://www.microsoft.com/technet/archive/ittasks/deploy/depovg/windna.mspx?mfr=true

E sobre as questões de STA e MTA, veja ainda no artigo:

Understanding COM Apartments
Ref.: http://www.codeguru.com/cpp/com-tech/activex/apts/article.php/c5529

De fato, muitas empresas implementaram os cenários acima em WinDNA e atualmente questionam quais são as alternativas rumo aos novos frameworks da Microsoft.

Mas sobre quais frameworks e tecnologias estamos falando? Vejamos nossas opções:

WCF - Windows Communication Foundation (.NET 3.x)
WF - Windows Workflow Foundation (.NET 3.x)
WPF - Windows Presentation Foundation (.NET 3.x)
Windows CardSpace (.NET 3.x)
ADO.NET Entity Framework (Beta 3)
ADO.NET Data Services (CTP)
Microsoft Sync Framework (CTP)
ASP.NET MVC Framework (Preview 2)
Microsoft ASP.NET AJAX 1.0

E ainda outras tecnologias como (misturei assuntos de propósito):

Virtualização;
LINQ to SQL, LINQ to XML, LINQ to Entities, LINQ to Objects;
Microsoft Silverlight 2 (Beta 1);
SaaS, Web 2.0, SOA, ESB, RIA;
IIS 7.0 e o Windows Process Activation Service (WAS);
Windows Server 2008, SQL Server 2008;
Service Broker, SSIS;
Fábricas de Software, Domain-Specific Languages, GAT/GAX;
Office Business Application (OBA);
e mais recentemente Software + Services (S+S), para ficar em algumas...

Assim, nossa discussão sobre evolução de uma arquitetura WinDNA típica torna-se um grande desafio. Nossas opções de tecnologias tornaram-se mais complexas e diversas nesses útimos 10 anos.

Mas para atacar esse desafio, vamos propor 2 etapas muito básicas. Como primeiro passo, precisamos de algumas questões para um processo de preparação e entendimento de nosso cenário atual. Vejamos:

Na evolução de nossa interface ASP, temos espaço para um novo padrão visual, caminhando para interfaces mais ricas (RIA), com interatividade e customização feita pelo usuário (WEB 2.0) e ainda com capacidade para compor funcionalidades de diferentes fontes de dados (Aplicações de Composição ou Mashups)?
Quantos componentes de negócio estamos tratando?
Conseguimos separar os componentes críticos em desempenho dos componentes de apoio?
Estamos utilizando algum framework de desenvolvimento para a construção dos componentes de negócio no WinDNA?
Conseguimos construir um inventário completo sobre esses componentes de negócio?
Na evolução de nossos componentes de negócio, é possível observar espaço para composição e coordenação de processos, na forma de workflows ou encadeamento de atividades?
Existe a necessidade de aplicação de regras de negócio, seja de forma dinâmica ou estática?
Na evolução de nossa conectividade com outros sistemas, quais são os cenários de transporte possíveis? Reconhecemos o uso de TCP, Named Pipes, MSMQ e Web Services?
Na evolução de nosso consumo de transações na plataforma alta, estamos utilizando chamadas via COMTI ou outros mecanismos de comunicação via APPC ou TCP com aplicações no mainframe?
Quais são os bancos de dados envolvidos? Conseguimos identificar um isolamento claro entre camada de negócio e camada de dados? Como está o uso de stored procedures e queries SQL pela arquitetura? Como estão os modelos de dados envolvidos?
Qual o inventário de sistema operacional presente na arquitetura atual?
Como está a infra-estrutura atual para as questões de disponibilidade da aplicação, como balanceamento de carga, balanceamento de componentes, farm de servidores, clusters, etc.?
Como são tratados os demais aspectos da aplicação como transação, recuperação, monitoração, segurança, tratamento de exceções, autenticação, controle de acesso, atualização de versões, etc.?

De fato, as questões acima irão nos ajudar para um maior entendimento sobre a arquitetura atual. Com certeza você irá adicionar novas questões, específicas para sua empresa.

O passo seguinte será mapear os recursos e benefícios de cada um dos novos frameworks Pós-WinDNA, afim de começar o mapeamento de tecnologias que irão oferecer a melhor solução para sua arquitetura. Um exemplo de aplicação seria esse:

Ao lado, uma aplicação Web (asp) com componentes COM+ 1.0 e acesso ao banco de dados e mainframe (usando HIS), uma foto tirada durante nossa discussão com o Rogério :-)

Como seria a evolução desse tipo de cenário?

Veremos algumas idéias em breve...

Para finalizar, não devemos esperar soluções mágicas ou soluções únicas para todos os cenários. Cada caso é um caso, sempre!

Esse texto foi só para iniciar a discussão. Vamos continuar o tema em posts futuros, por isso, comentários serão benvindos...

Por enquanto é só! Até o próximo post :)

Waldemir.

Integrando WCF e WF - Uma alternativa para a composição de serviços numa arquitetura SOA.

wcamb — Tue, 08 Apr 2008 03:37:00 GMT

Olá pessoal, tudo certo?

Cada vez mais tenho recebido perguntas sobre o uso de serviços baseados em WCF - Windows Communication Foundation. De fato, existem diversos aspectos de uma camada de serviços que o framework WCF atende muito bem. Entre as principais características aderentes ao modelo temos:

Framework dedicado para a comunicação entre sistemas;
Baseado em mensagens;
Multi-protocolo;
Multi-hosting;
Compatível com WS, WS-*, TCP, P2P, etc;
Adaptável e extensível, através da construção de novos dutos de transporte (bindings), adapters, endpoints, mecanismos de entrega de mensagens, etc;
Altamente configurável, o que permite um grande desacoplamento entre serviços e sua configuração, entre outros.

Existem ainda outros recursos importantes no WCF que adicionam ao modelo, como programação unificada para diversos métodos de conexão, controle de comportamentos (behaviors), endpoints e seus componentes, etc. A figura a seguir já é conhecida de todos e apresenta os atores de um serviço no WCF:

Do mesmo modo, o WF - Windows Workflow Foundation trás uma série de recursos para a composição de atividades, introduzindo os conceitos de fluxo de trabalho, permitindo aos desenvolvedores tratarem diversos cenários, como fluxos de trabalho seqüencial, fluxos simples, fluxos baseados em máquinas de estado, com interações humanas, etc.

Portanto, é inevitável que a pergunta sobre o uso integrado de ambos os frameworks aconteça. A pergunta que devemos fazer na sequência é: como isso pode ser feito? e ainda, quais são as armadilhas nessa implementação?

Para a primeira pergunta, um bom artigo que descreve um cenário de integração é este a seguir:

Integrating Windows Workflow Foundation and Windows Communication Foundation (by Jeremy Boyd)
Ref.: http://msdn2.microsoft.com/en-us/library/bb266709.aspx

O artigo apresenta um passo-a-passo que pode ser usado como exemplo na integração de serviços WF em WCF em cenários diversos. Vamos usá-lo como guia para apresentar alguns novos pontos de discussão que envolvem os dois framework.

Criar o modelo de processos desejado no WF, identificando os pontos de decisão e interação entre serviços;
Evitar o uso de muitos blocos de código em sequência (Code Shape). Sempre que possível, consolidar os blocos por linha de execucão no workflow do WF.
Trabalhar com um checklist de verificações para a integração WCF/WF. De fato, manter um desenho da integração desejada sempre atualizada é um fator crítico;
Definir os contratos de serviços de negócio envolvidos no projeto. Podemos identificar 3 grandes aspectos para um contrato de serviço:

As operações publicadas, que são os recursos que o serviço publica para seus consumidores (são os métodos da interface);
As mensagens que encapsulam os dados estruturados de cada solicitação e resposta, que são os argumentos e os tipos de retorno de cada método (são os contratos de mensagem ou os contratos de dados);
As definições de dados das entidades de negócio (business entities) que podem ser trocadas pelo serviço;

Quando necessário, hospedar e manter o tempo de execução do fluxo de trabalho. Isso é feito através da adição de uma classes de extensão ao WF, através da interface IExtension<ServiceHostBase>. Veja mais aqui: http://msdn2.microsoft.com/en-us/library/ms554840(VS.85).aspx;
Também, para fluxos de trabalho de longa duração, recomenda-se o uso de um modelo de persistência por SqlWorkflowPersistenceService. Isso garante a recuperação e manutenção do estado do fluxo enquanto sua duração. Veja mais aqui: http://msdn2.microsoft.com/en-us/library/system.workflow.runtime.hosting.sqlworkflowpersistenceservice.aspx;
Verificar os pontos de configuração da implantação, através da definição dos valores para o endpoint do serviço WCF (Address, Binding e Contract);
Para o consumo do serviço, podemos utilizar o padrão de fábrica ChannelFactory. Veja mais aqui: http://msdn2.microsoft.com/en-us/library/ms576132.aspx;
Ainda, o WCF suporta alguns fluxos de mensagens alternativos, como comunicação unidirecional e duplex bidirecional. Os canais duplex podem ser bastante eficientes para sistemas com conexão mais forte, nos quais os dados possam ser enviados em qualquer direção. Importante estudar o cenário para a definição do tipo de fluxo de mensagem mais indicado. Esse tipo de configuração é feita através da chamada DuplexChannelFactory. Veja mais aqui: http://msdn2.microsoft.com/en-us/library/ms576164.aspx.

Bastante coisa, não é mesmo?

Relembrando, o Windows Workflow Foundation (WF) oferece uma estrutura geral para a definição de fluxos de trabalho e um mecanismo de controle que permite hospedar esses fluxos de trabalho em execução, além de interagir com eles. Ainda, o Windows Communication Foundation (WCF) fornece uma estrutura geral de criação de sistemas conectados, através de um modelo de programação unificada, completo e consistente, que oferece um conjunto amplo de recursos para a definição de serviços, como vimos acima.

Assim, realmente podemos aplicar esses dois frameworks de forma combinada, criando uma plataforma flexível e adaptável. O WF permite modelar e encapsular a lógica de negócio e os processos de negócio, enquanto o WCF fornece a infra-estrutura de mensagens para a comunicação entre sistemas.

Os passos acima não são o guia definitivo para a implementação de integrações WCF + WF. A idéia do post foi apontar alguns temas envolvidos na construção de soluções sofisticadas, utilizando os dois frameworks. E para relembrar uma outra discussão já feita aqui no blog, segue o link abaixo:

Windows Workflow Foundation - Uma alternativa para a camada de processos numa arquitetura SOA.
Ref.: http://blogs.msdn.com/wcamb/archive/2008/02/01/windows-workflow-foundation-uma-alternativa-para-a-camada-de-processos-numa-arquitetura-soa.aspx

Em posts futuros, ainda vamos dar uma olhada no impacto dessa integração WCF + WF sobre o Windows Server 2008, especificamente com o uso do Windows Process Activation Service (WAS).

Por enquanto é só! Até o próximo post :)

Waldemir.

Windows Workflow Foundation - Uma alternativa para a camada de processos numa arquitetura SOA.

wcamb — Fri, 01 Feb 2008 16:47:00 GMT

Olá pessoal, tudo certo?

Nas últimas semanas, tenho conversado com alguns clientes que iniciaram suas primeiras visões sobre a camada de composição de processos e o consumo de serviços num ambiente SOA. Realmente, o assunto "Arquitetura Orientada a Serviços" ainda está bem presente no meio corporativo, pois muitas questões ainda estão em aberto.

Entre as considerações recorrentes nessa discussão temos:

O que é um serviço?
Quais são os patterns para criação de serviços?
Quais os mecanismos de conexão e comunicação entre serviços e aplicações LOB - Line Of Business?
Quais funcionalidades serão implementadas no formato de serviços?
Como organizar os sistemas e investimentos já existentes na organização?
Como publicar os serviços gerados?
Como consumir os serviços gerados?
Como administrar os serviços gerados?
O que é governança de serviços? ...entre outras...

Nesse post, vamos revisar alguns conceitos sobre a arquitetura SOA e falar um pouco sobre a implementação da Camada de Processos através do Windows Workflow Foundation, o WF do .NET Framework 3.0.

Quando pensamos no paradigma de distribuição e consumo de serviços, a figura abaixo é uma boa representação:

Vemos que num ambiente orientado a serviços, existirá uma camada de implementação e integração com fontes de dados, sistemas legados e aplicações linhas de negócio (LOB - Line of Business Applications). Acima dessa camada, pensamos um conjunto de serviços atômicos que exportam de maneira consistente as funcionalidades das aplicações. Nessa camada é que existem as grandes considerações sobre anatomia de serviços, publicação, barramento de serviços, etc.

E para consumir esses serviços, podemos pensar na composição e na colaboração de uma camada de processos. Uma camada de processos pode ser organizada através de orquestrações ou fluxos de atividades ou ainda máquinas de estado, que através de regras de negócio decidem quais serviços serão consumidos. Note que sobre uma camada de processos, aplicações compostas podem oferecer uma rica oferta de funcionalidades para usuários corporativos finais. Aqui temos os chamados Mashups Corporativos.

Em teoria, o cenário acima é perfeito. Porém, para a implementação dessa visão muitos cuidados são necessários e a escolha das tecnologias corretas se torna crítica.

O Windows Workflow Fountation (ou simplesmente WF) é um framework componente do .NET 3.0 que permite a construção de orquestrações ou fluxos de atividades. Pense numa atividade como um trecho de código, manipulação de dados, interação com usuário, chamadas para web services ou serviços WCF que sejam necessários para um processo. Assim, em WF, um conjunto de atividades coordena pessoas e/ou software de forma organizada através de um fluxo de trabalho.

A figura abaixo apresenta um visão sobre a arquitetura geral do WF:

Note que todo workflow ou fluxo de atividades criado em WF é executado por um host. Esse host pode ser um serviço Windows, uma aplicação .NET ou mesmo um serviço WCF em execução. E nessa arquitetura, o Runtime Engine é o módulo responsável pela execução do fluxo de atividades. Como parte integrante desse ambiente temos o Visual Designer, uma interface integrada ao Visual Studio 2005 (via extensions) ou 2008 (de forma nativa) que permite a construção de fluxos de atividades WF de forma visual. Veja na figura abaixo um exemplo de workflow construído no Visual Designer:

Ao final, um fluxo de atividades WF deve gerar um assembly .NET, seja uma .DLL ou um .EXE de acordo com o tipo de host gerado. Esse assembly será executado numa máquina, que proverá o workflow para os demais sistemas. De fato, o assembly irá encapsular uma classe em .NET, com a seguinte estrutura:

using System;
using System.ComponentModel;
using System.ComponentModel.Design;
using System.Collections;
using System.Drawing;
using System.Workflow.ComponentModel.Compiler;
using System.Workflow.ComponentModel.Serialization;
using System.Workflow.ComponentModel;
using System.Workflow.ComponentModel.Design;
using System.Workflow.Runtime;
using System.Workflow.Activities;
using System.Workflow.Activities.Rules;

namespace MyWorkflowConsoleApplication
{
    public sealed partial class MyWorkflow: SequentialWorkflowActivity
    {
        public MyWorkflow()
        {
            InitializeComponent();
        }

        private void codeActivity_ExecuteCode(object sender, EventArgs e)
        {
             Console.WriteLine("codeActivity_ExecuteCode");
        }
    }
}

Assim, uma vez dentro de um método ou trecho de código do workflow, temos acesso a todos os recursos e funcionalidades do .NET Framework, o que permite uma grande flexibilidade na construção e integração com outras aplicações. Note que da mesma forma, valerão as boas práticas de performance e recomendações para .NET no desenvolvimento de código de uma classe Workflow, como vista acima. Como boa prática, é importante evitar construções com um número excessivo de shapes de código. Assim, sempre que possível é melhor consolidar atividades num único shape ou simplesmente evitar um número elevado de chamadas para componentes externos, para que cada workflow seja simples e assim, com uma boa performance. Cada shape de código é implementado através de um método private void codeActivity_nonon(object sender, EventArgs e), como visto no exemplo acima. Lembre-se que um workflow com alta latência terá impacto na performance final da aplicação front-end que o consome.

Enfim, tivemos aqui apenas uma introdução sobre o tema Windows Workflow Foundation e seu uso como alternativa para orquestrações na camada de processos de uma arquitetura orientada a serviços.

Como boas referências para avançarmos sobre o estudo do WF, recomendo alguns links:

Hands-on Labs for Windows® Workflow Foundation in C# and VB.NET
Ref.: http://www.microsoft.com/downloads/details.aspx?familyid=2e575633-e357-4ee7-aaff-34138f00e830&displaylang=en

BPEL for Windows Workflow Foundation March CTP
Ref.: http://www.microsoft.com/downloads/details.aspx?FamilyId=6D0DAF00-F689-4E61-88E6-CBE6F668E6A3&displaylang=en

Visual Studio 2005 extensions for .NET Framework 3.0 (Windows Workflow Foundation)
Ref.: http://www.microsoft.com/downloads/details.aspx?familyid=5D61409E-1FA3-48CF-8023-E8F38E709BA6&displaylang=en

Windows Workflow Foundation, Part 1 – by Dino Esposito
Ref.: http://msdn.microsoft.com/msdnmag/issues/06/03/CuttingEdge/

Windows Workflow Foundation, Part 2 – by Dino Esposito
Ref.: http://msdn.microsoft.com/msdnmag/issues/06/04/cuttingedge/default.aspx

E um bom livro é o lançamento do Paul Andrew, veja abaixo:

Presenting Windows Workflow Foundation
Ref.: http://www.amazon.com/Presenting-Windows-Workflow-Foundation-Andrew/dp/0672328488

Em posts futuros vamos discutir mais questões de otimização e performance sobre a camada de orquestração e o desenvolvimento sobre o Windows Workflow Foundation. Como sempre, fiquem ligados.

Por enquanto é só! Até o próximo post :)

Waldemir.

Extensions e Addins para o Visual Studio 2005.

wcamb — Tue, 11 Dec 2007 02:15:00 GMT

Olá pessoal, tudo certo?

Conforme combinado, este é o post que fala de Extensions e Addins para o Visual Studio 2005, para trabalharmos com uma série de tecnologias, de .NET 3.5 a AJAX. Sobre seu ambiente de Visual Studio 2005, vamos prepará-lo para os seguintes cenários:

- Guias de Automação e Software Factories
- Recursos para o desenvolvimento Office (Visual Studio Tools for Office)
- Recursos para o desenvolvimento sobre o BizTalk Services SDK 1.0
- Recursos para a construção de serviços WCF - Windows Communication Foundation
- Recursos para a construção de workflows com o WF - Windows Workflow Foundation
- Recursos para o desenvolvimento AJAX
- Recursos do .NET Framework 3.0 e 3.5, Extensions, Samples e SDK's

Abaixo temos os links para download de cada um dos pacotes desejados. Veja que, de acordo com a necessidade, instale os pacotes que você irá mesmo utilizar:

1. Microsoft .NET Framework Version 2.0 Redistributable Package (x86)
https://www.microsoft.com/downloads/details.aspx?familyid=0856EACB-4362-4B0D-8EDD-AAB15C5E04F5&displaylang=en

2. Microsoft .NET Framework 2.0 Service Pack 1 (x86)
http://www.microsoft.com/downloads/details.aspx?FamilyID=79BC3B77-E02C-4AD3-AACF-A7633F706BA5&displaylang=en

3. Microsoft .NET Framework 3.0 Redistributable Package
http://www.microsoft.com/downloads/details.aspx?FamilyID=10CC340B-F857-4A14-83F5-25634C3BF043&displaylang=en

4. GAX - Guidance Automation Extensions
http://www.microsoft.com/downloads/details.aspx?FamilyId=C0A394C0-5EEB-47C4-9F7B-71E51866A7ED&displaylang=en

5. GAT - Guidance Automation Toolkit
http://www.microsoft.com/downloads/details.aspx?familyid=E3D101DB-6EE1-4EC5-884E-97B27E49EAAE&displaylang=en

6. Microsoft Visual Studio 2005 Tools for the 2007 Microsoft Office System (VSTO SE)
http://www.microsoft.com/downloads/details.aspx?FamilyId=5E86CAB3-6FD6-4955-B979-E1676DB6B3CB&displaylang=en

7. Visual Studio 2005 extensions for .NET Framework 3.0 (WCF & WPF), November 2006 CTP
http://www.microsoft.com/downloads/details.aspx?FamilyId=F54F5537-CC86-4BF5-AE44-F5A1E805680D&displaylang=en

8. Visual Studio 2005 extensions for .NET Framework 3.0 (Windows Workflow Foundation)
http://www.microsoft.com/downloads/details.aspx?familyid=5D61409E-1FA3-48CF-8023-E8F38E709BA6&displaylang=en

9. Microsoft .NET Framework 3.5
http://www.microsoft.com/downloads/details.aspx?FamilyId=333325FD-AE52-4E35-B531-508D977D32A6&displaylang=en

10. Microsoft .NET Framework 3.0 Service Pack 1
http://www.microsoft.com/downloads/details.aspx?familyid=EC2CA85D-B255-4425-9E65-1E88A0BDB72A&displaylang=en

11. Web Service Software Factory - Feb 2007
http://www.microsoft.com/downloads/details.aspx?FamilyId=DB996113-6E92-4894-9B7E-0DEBB614D72F%20&displaylang=en

12. Mobile Client Software Factory July 2006 (refresh)
http://www.microsoft.com/downloads/details.aspx?FamilyId=F9176708-9F57-4C0F-97FB-F9C65A9BBF22&displaylang=en

13. Smart Client Software Factory - May 2007
http://www.microsoft.com/downloads/details.aspx?familyid=2B6A10F9-8410-4F13-AD53-05A202FBDB63&displaylang=en

14. Service Factory - Modeling Edition (VS2005)
http://www.codeplex.com/servicefactory/Release/ProjectReleases.aspx?ReleaseId=8130

15. BizTalk Services SDK 1.0
http://labs.biztalk.net/GetStarted.aspx

16. Windows SharePoint Services 3.0 Tools: Visual Studio 2005 Extensions
http://www.microsoft.com/downloads/details.aspx?familyid=19F21E5E-B715-4F0C-B959-8C6DCBDC1057&displaylang=en

17. SharePoint Server 2007 SDK: Software Development Kit
http://www.microsoft.com/downloads/details.aspx?familyid=6D94E307-67D9-41AC-B2D6-0074D6286FA9&displaylang=en

18. Microsoft ASP.NET AJAX - Vários recursos para download
http://www.asp.net/ajax/downloads/

19. Basic Windows Communication Foundation Technology Samples
http://msdn2.microsoft.com/en-us/library/ms752239(VS.90).aspx

20. Windows Communication Foundation (WCF), Windows Workflow Foundation (WF) and Windows CardSpace Samples
http://www.microsoft.com/downloads/details.aspx?familyid=2611a6ff-fd2d-4f5b-a672-c002f1c09ccd&displaylang=en&tm

21. Visual Studio 2008 and .NET Framework 3.5 Training Kit
http://www.microsoft.com/downloads/details.aspx?FamilyID=8bdaa836-0bba-4393-94db-6c3c4a0c98a1&DisplayLang=en

Repare que alguns links são de comunidades ou podem ser atualizados. Assim, fica a dica para continuar acompanhando as próximas edições desses recursos.
É sempre bom lembrar que devemos ler todas as recomendações do processo de instalação para cada um dos links acima escolhidos.

Por enquanto é só. Bom divertimento e até o próximo post! :)

Waldemir.

Tech-Ed Brasil 2007 - Um resumo...

wcamb — Sun, 09 Dec 2007 17:15:00 GMT

Olá pessoal, tudo certo?

O evento Tech-Ed Brasil 2007 foi um sucesso! Mais de 130 sessões sobre temas importantes, de infra-estrutura a desenvolvimento, com uma grande participação de todos presentes. Muito obrigado a você que participou e fez suas perguntas, colaborando durante as várias apresentações e mesas redondas. Confira algumas fotos no blog do amigo René de Paula Jr.

Em breve devo publicar um post sobre algumas discussões que tivemos nas sessões de WCF - Windows Communication Foundation, WF - Windows Workflow Foundation e OBA - Office Business Application. Muitas pessoas pediram um roteiro de addins e extensões que precisamos aplicar no Visual Studio 2005, para trabalhar com os templates de WCF e WF. Isso para que ainda não experimentou o Visual Studio 2008, que tem todos esses recursos integrados ao ambiente.

Assim, fiquem ligados pois estou preparando o roteiro com os links para sua avaliação.

E para os arquitetos de plantão, fica aqui algumas dicas de livros importantes, que citei durante as sessões:

Programming WCF Services - o livro do peixinho... :)
http://www.amazon.com/Programming-WCF-Services-Juval-Lowy/dp/0596526997/ref=sr_1_7?ie=UTF8&s=books&qid=1197209103&sr=8-7

Presenting Windows Workflow Foundation
http://www.amazon.com/gp/product/0672328488
de Paul Andrew (veja o blog : http://blogs.msdn.com/pandrew/ )

Programming Windows Presentation Foundation
http://www.amazon.com/Programming-Windows-Presentation-Foundation/dp/0596101139/ref=pd_bxgy_b_img_b

Por enquanto é só! Até o próximo post! :)

Waldemir.