Waldemir Cambiucci - Solutions Architect - Microsoft Brasil : WinDNA

Evoluindo frameworks domésticos : por onde começar?

wcamb — Fri, 07 Nov 2008 00:36:00 GMT

Olá pessoal, tudo certo?

Esta semana estive com alguns arquitetos, falando sobre como evoluir os frameworks domésticos que estão em produção nas empresas, mas que ainda utilizam recursos do .NET 2.0 ou algum namespace do .NET 3.0 apenas. Essa discussão é grande e veja que ainda existem empresas usando VB5, VB6, ASP, .NET 1.0, 1.1 ou .NET 2.0 em suas aplicações. Mas vamos focar os frameworks neste post.

Realmente, desde o lançamento do .NET 2.0, tivemos uma série de novos pacotes e namespaces, que ajudam no desenvolvimento de aplicações cada vez mais sofisticadas. Parte dessa evolução foi demandada pelo mercado, como REST e AJAX. Outras, foram evoluções importantes para o modelo de programação na plataforma Microsoft, como o próprio WCF - Windows Communidation Foundation. Vale lembrar também que a própria plataforma amadureceu, diante dos vários cenários presentes no mercado.

Como já vimos em posts passados (esse, por exemplo), existem diversos desafios na construção e manutenção de bibliotecas, blocos de aplicações e frameworks de desenvolvimento, sejam horizontais ou verticais. Um dos grandes desafios é a manutenção de sua atualização diante de novos recursos do mercado, como por exemplo, novos frameworks associados ao .NET na plataforma Microsoft.

Para contextualizar nossa discussão, veja o diagrama abaixo, onde destaco o .NET Framework e sua evolução:

Note que novos recursos foram sendo adicionados na pilha .NET ao longo de suas versões. Ainda, alguns novos pacotes estão faltando no desenho acima, como o SYNC Framework, o Velocity, o Geneva Framework, etc. Para todas as versões acima, estamos trabalhando sobre a mesma CLR - Common Language Runtime, o que significa que não existe quebra de compatibilidade para uma aplicação durante sua evolução de upgrade. O próprio Visual Studio 2008 já compila para .NET 2.0, 3.0 e 3.5 como framework alvo.

Semana passada vimos uma nova enxurrada de frameworks, pacotes de desenvolvimento e serviços que estarão disponíveis em breve para nossas aplicações. Poderemos integrar o ambiente cliente, o ambiente enterprise e o ambiente na nuvem, utilizando recursos distintos e complementares, compondo soluções de acordo com nossas necessidades. Só para para lembrar, veja o que está chegando com a plataforma de serviços Azure... :)

Bastante coisa, não é mesmo? Mas voltemos para nossa pergunta básica: Como evoluir nosso velho framework de desenvolvimento doméstico de todo dia?

Algumas recomendações que faço nesse momento são:

Se você ainda trabalha com Web Services na plataforma .NET 2.0 (extensões .asmx), ou ainda possui soluções via .NET Remoting, comece com algumas provas de conceito sobre o WCF - Windows Communication Foundation. Podemos resumir que WCF é hoje a infra-estrutura recomendada para a comunicação entre sistema, processos e aplicações na plataforma Microsoft. Uma evolução natural de seu framework em NET 2.0 para .NET 3.x é substituir .NET Remoting e Web Services por interfaces em WCF. Avalie os bindings diferentes para cada serviço e selecione o que melhor responde às necessidades de seu negócio. Veja as considerações sobre balanceamento de carga com o WCF também. O WCF é parte integrante do .NET desde a versão 3.0 e com certeza é uma primeira abordagem de evolução, pelo ganho de desempenho e modelo de programação unificado que oferece. Não deixe de conferir também, os vários cenários possíveis para serviços com WCF, aqui;
Se você ainda trabalha com páginas ASP, avalie o ASP.NET com AJAX. Veja alguns exemplos disponíveis no link : http://www.asp.net/community/projects/. Existem boas idéias que podem ser aproveitadas em seus projetos. Ainda, avalie exemplos com AJAX para ganhos de produtividade e performance, otimizando suas requisições junto ao servidor ou mesmo melhorando a usabilidade na navegação do usuário sobre suas páginas. Finalmente, navegar dados via ASP.NET Dynamic Data ou exporta um banco de dados através da interface ADO.NET Data Services, com consultas via REST é uma outra boa recomendação para prova de conceito. Não deixe de testar essas soluções;
Se você possui um framework que prevê interfaces WinForms com .NET, ou formulários VB6 com Win32, por exemplo, avalie os recursos de usabilidade e navegação obtidos com o WPF - Windows Presentation Foundation. Além de um conjunto muito mais rico de controles gráficos e interação com o usuário, o desenvolvimento sobre WPF permite maior integração entre os times de design e desenvolvimento, devido o uso de documentos em XAML - Extensible Application Markup Language, que permitem a renderização gráfica baseada em parsers, integrados ao .NET Framework, na ferramenta de design ou no próprio Visual Studio;
Se você ainda utiliza o ADO.NET 2.0 para navegar seus dados e manipular suas estruturas de retorno a partir de consultas ao banco de dados, através de um camada DAL - Data Access Layer - tradicional, avalie consultas utilizando LINQ - Language Integrated Query, do .NET 3.5. Verifique o tipo de legibilidade de código que você pode obter com o LINQ, assim como consultas sobre coleções com o XLINQ sobre XML, ou o uso integrado do ADO.NET Entity Framework (EF), permitindo a construção de soluções multi-banco. Sua prova de conceito com LINQ e Entity Framework também poderá avaliar performance, tempo de resposta e aderência ao SLA esperado pela aplicação, comparando com uma DAL simples. Vale citar que manutenção e independência de banco de dados são pontos de destaque nessa infra-estrutura LINQ + EF (veja sua necessidade de ORM - Object Relational Mapping e camadas de persistência). LINQ é parte do .NET desde a versão 3.5 e o ADO.NET Entity Framework, desde a versão 3.5 SP1. Veja mais aqui;
Se você ainda possui regras de negócio no COM+ (1.0 e 1.5) ou algumas regras em Web Services publicados no IIS, avalie a exportação de suas regras como serviços WCF, hosteados no WAS - Windows Process Activation Services. Muita calma nesse momento, devido questões de transação, interoperabilidade com componentes legados, etc. Mas entre os benefícios do host WAS para serviços WCF temos um melhor desempenho para o tratamento de requisições e instâncias, assim como maior flexibilidade na seleção de protocolos de transporte e adoção de um modelo orientado a mensagens, mais flexível quanto a integração com outras plataformas. Sobre o Windows Server 2008, WAS torna-se é uma recomendação de fato. Veja mais aqui;

Com certeza, esse é um post apenas para dar algumas idéias, iniciar uma discussão. Cada empresa encontrará sua melhor abordagem, de acordo com uma série de fatores próprios, como:

maturidade do framework em produção na empresa;
maturidade da equipe de desenvolvimento usuária do framework;
maturidade da equipe de arquitetura responsável pelo framework;
existência de templates e bons exemplos de código utilizando o framework;
maturidade do processo de desenvolvimento de software e existência de disciplinas de ALM - Application Lifecycle Management;
seleção de arquiteturas de referência e boas práticas de desenvolvimento, que sejam suportadas pelo framework, etc.

O mais importante é definir uma estratégia de evolução, procurando atender as principais necessidades do usuário, seja desempenho, usabilidade, velocidade para adição de novas funcionalidades, riqueza de interface, funcionalidades de integração com a web ou simplesmente, a competição com o mercado.

A discussão é boa! O desafio também é bom!

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

Waldemir.

Do Windows DNA para o mundo orientado a serviços : a visão Software + Serviço e a Cloud Computing.

wcamb — Wed, 23 Apr 2008 06:46:00 GMT

Olá pessoal, tudo certo?

Continuando nosso assunto de evolução de uma plataforma WinDNA para uma arquitetura baseada em serviços, vamos falar um pouco sobre Software + Services (S+S).

E indo direto ao ponto, podemos definir essa visão de software + serviço como uma estratégia que engloba software em diferentes localidades, com diferentes qualidades de entrega (ou compromissos e garantias) e com software implementado nos 4 principais universos de programação de hoje em dia: desktop, web, mobile e enterprise. E tudo isso acontecendo ao mesmo tempo, ou seja, um cenário de composição, de colaboração, de convivência.

E como sempre diz o mestre Gebara, nada como um bom exemplo para clarear alguns conceitos: vejamos um cenário de Software+Service para o serviço de mensagens (emails).

Para contas críticas, destinadas para as mensagens importantes da corporação, com criptografia, manutenção histórica de threads, etc., podemos implementar uma infra-estrutura local, com servidores dedicados e cuidar das melhores práticas de operação e higiene de mensagens para nossa empresa. Veja que a responsabilidade sobre essa infra-estrutura será nossa e o custo de operação é total também nosso.

Para caixas postais não tão críticas, mas que são usadas no dia-a-dia da empresa, podemos pensar numa solução de menor complexidade, onde parte das caixas postais estão locais e algumas funcionalidades adjacentes são contratadas da web, como gateways, repositórios de arquivos, filtros, etc.

Podemos pensar também em caixas postais mais ordinárias, que não exigem grandes cuidados com backups ou histórico de mensagens. Essas contas podem ser implementadas em provedores de email na web, de forma gratuíta ou de baixo custo.

Finalmente, podemos pensar em cenários onde para caixas postais estratégicas, a empresa prefira contratar um serviço inteiramente online, que forneça garantias para a qualidade do serviço prestado, como backup, cotas em disco, filtros, criptografia, etc.

Deu para perceber que nessa nova arquitetura de TI, nossa infra-estrutura de mensageria e caixas postais apresenta diferentes níveis de qualidade para os serviços oferecidos. De acordo com a criticidade da caixa postal ou demanda do serviço, podemos contratar um nível de qualidade mais adequado, pagando mais ou menos pela funcionalidade desejada.

A mesma discussão valeria para espaço de armazenamento em disco, por exemplo, onde podemos usar storages locais para dados importantes, com rígidas políticas de backup e contingência ou considerar o uso de espaços contratados na web, como o SkyDrive Live da Microsoft (com 5 Gb gratuítos) ou ainda o Amazon Simple Storage Service (Amazon S3).

Essa é a visão Software + Service: compor diferentes qualidades de serviço (SLA - Service Level Agreement) de acordo com a necessidade.

Evoluindo o diagrama do último post, bastaria indicar nossos serviços consumidos da nuvem para exemplificar esse cenário:

Claro, o mundo não é tão simples assim e diversas questões devem surgir nessa discussão, como segurança, autenticação e controle de acesso, tarifação, disponibilidade, tempo de resposta e latência, controle de versionamento, protocolos de transporte, contratos de serviços, mensagens, entre outras. Todas essas questões fazem parte do universo S+S e serão inevitáveis durante a definição da arquitetura final.

O importante é considerar essas alternativas, de acordo com a relevância do negócio e possíveis economias decorrentes da aplicação desse tipo de arquitetura.

Já falamos sobre Software + Service em discussões passadas, como no post sobre SaaS, veja:

SaaS - Software as a Service - Uma visão sobre o software como serviço.
Ref.: http://blogs.msdn.com/wcamb/archive/2008/03/09/saas-software-as-a-service-uma-vis-o-sobre-o-software-como-servi-o.aspx

Ainda como referência sobre o assunto, não deixe de reler a edição número 13 do "The Architecture Journal", onde temos o artigo:

Implications of Software + Services Consumption for Enterprise IT
Ref.: http://msdn2.microsoft.com/en-us/arcjournal/bb906061.aspx

Como mensagem final arrisco: não vamos mais decidir sobre uma abordagem ou outra, se software local ou na rede, se comprado (on premise) ou contratado (in the cloud). A tendência é pela composição, com soluções híbridas e o desafio é reconhecer quais serão os custos e economias envolvidos em nossa nova TI, enquanto suportamos a chamada Cloud Computing.

Com certeza, existem diversos benefícios envolvidos na visão Software+Services e caberá a nós, arquitetos, avaliar o impacto para nossas empresas.

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

Waldemir.

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.