Desenvolvimento em Camadas
RESUMO
Desde o surgimento da arquitetura cliente/servidor, o desenvolvimento de software em camadas passou a ser adotado como base de arquitetura de sistemas.
Com o surgimento da Internet, os cuidados com a arquitetura adotada passaram a ganhar importância na medida em que é responsável por fatores como escalabilidade e estabilidade de sistemas que atendem a centenas ou milhares de usuários simultaneamente.
Este white paper revê os conceitos do desenvolvimento em camadas e relata algumas das decisões de arquitetura adotadas na migração de um sistema de Aprovação de Crédito de arquitetura Windows DNA para Microsoft .NET.
Os itens tratados neste documento são:
Nesta página
 | RESUMO |
| INTRODUÇÃO |
| “CAMADAS E CAMADAS” (LAYERS E TIERS) |
| MODELOS DE APLICAÇÕES |
| MIGRAÇÃO DE WINDOWS DNA PARA MICROSOFT.NET |
| CONCLUSÕES |
| REFERÊNCIAS |
INTRODUÇÃO
A decomposição de sistemas complexos em camadas é uma das técnicas mais utilizadas por arquitetos de software. A técnica foi emprestada da arquitetura de computadores, que utiliza camadas para chamadas de sistema operacional, device drivers, instruções do processador, até as portas lógicas contidas nos chips. Os protocolos de rede também têm utilizado a mesma técnica de camadas: por exemplo, o FTP é baseado em TCP, que por sua vez utiliza o protocolo IP, que utiliza Ethernet.
Martin Fowler, em seu livro Patterns of Enterprise Application Architecture, descreve os benefícios da decomposição em camadas:
| • | É possível compreender uma única camada coerentemente como um todo, sem a necessidade de muito conhecimento das outras camadas. Por exemplo, é possível compreender como construir um FTP baseado em TCP, sem conhecer os detalhes de como funciona Ethernet; |
| • | As camadas podem ser substituídas por implementações alternativas dos mesmos serviços básicos. Um serviço de FTP pode ser executado sem alterações sobre Ethernet ou sobre PPP; |
| • | A dependência de camadas é reduzida. Se um provedor de banda larga altera seu sistema físico de transmissão, desde que o IP continue funcionando, não há alterações no serviço de FTP; |
| • | As camadas são bons lugares para padronização. TCP e IP são padrões porque definem como suas camadas devem operar; |
| • | Uma vez construída, a camada pode ser utilizada por outros serviços de nível mais alto. TCP/IP pode ser utilizado por FTP, telnet, SSH, http. De outra forma, todos esses protocolos deveriam implementar seu próprio protocolo de nível inferior. Porém, a técnica de camadas oferece alguns perigos: |
| • | Camadas encapsulam algumas, mas nem todas as coisas. Como resultado, pode haver alterações em cascata. O exemplo clássico é a aplicação corporativa desenvolvida em camadas que precisa de mais um campo a ser exibido na interface com o usuário e que deve ser adicionado a todas as camadas inferiores; |
| • | Camadas extras podem prejudicar o desempenho. Em cada camada, as informações devem ser transformadas de uma representação para outra. Todavia, o encapsulamento de funções pode oferecer ganhos de eficiência como compensações. |
Mas a parte mais difícil da arquitetura em camadas é decidir quais camadas devem existir e qual a responsabilidade de cada uma delas.
“CAMADAS E CAMADAS” (LAYERS E TIERS)
Evolução das camadas em aplicações corporativas
A noção de camadas ganhou destaque na década de 90, com o surgimento de sistemas cliente/servidor. O cliente mantinha a interface de usuário e outros códigos da aplicação. O servidor tipicamente era um banco de dados relacional. Essa arquitetura de duas camadas facilita o desenvolvimento de aplicações com acesso intensivo a dados, na medida em que as ferramentas mais populares, como Visual Basic e Delphi possuíam controles de interface com usuários especialmente desenvolvidos para utilização de comandos SQL.
Se toda a responsabilidade da aplicação fosse simplesmente a exibição e atualização de dados, os sistemas cliente/servidor funcionariam perfeitamente. O problema surge com a lógica de domínio (domain logic): regras de negócio, validações, cálculos. É comum escrevê-los no cliente, mas isto é deselegante, ineficaz e geralmente embute a lógica diretamente nas telas de interface de usuário. À medida que a lógica de domínio torna-se mais complexa, o código torna-se mais difícil de ser trabalhado.
Além disso, ao embutir a lógica nos componentes de apresentação, a duplicação de código é quase uma certeza.
Uma das alternativas é colocar a lógica de domínio em stored procedures do banco de dados. Todavia, as stored procedures possuem mecanismos limitados de estruturação, o que leva novamente a código deselegante e ineficaz. Além disso, muitos apreciam os bancos de dados relacionais por possuir o padrão SQL, o que permitiria a troca de fornecedor do gerenciador de bancos de dados. Mas stored procedures são totalmente proprietárias, o que elimina esse benefício.
Ao mesmo tempo em que a arquitetura cliente/servidor ganhava popularidade, o mesmo ocorria com o mundo de orientação a objetos. A comunidade de objetos tinha a resposta para o problema de lógica de domínio: vá para o sistema de três camadas. Nesta abordagem, temos a camada de apresentação para interface com usuário, uma camada de domínio para a lógica de domínio, e uma camada de dados. Desta forma, toda a intrincada lógica de domínio pode sair da interface com o usuário e ser implementada numa camada onde pode ser estruturada adequadamente com objetos.
Certamente aqui se apresentaram alguns desafios, tanto para o desenvolvimento dos sistemas em termos de ferramental quanto conceitual, no tocante à representação dos dados dos objetos em modelos relacionais, por exemplo, além da necessidade de servidores de aplicação que contivessem recursos para garantir consistência, desempenho e escalabilidade, entre outros requisitos.
A onda mais recente que impactou a arquitetura de sistemas foi a popularização da Internet. O mundo todo desejava implantar sistemas com acesso por navegadores. Mas se toda a lógica de negócio estava enterrada num cliente rico, toda ela deveria ser construída novamente para atender uma interface Web.
Por outro lado, as ferramentas que surgiram para construção de sistemas Web eram menos amarradas a SQL e, portanto mais sensíveis a uma terceira camada.
Layers e Tiers
Ao discutir a utilização de camadas, há sempre confusão com os termos layer e tier. Freqüentemente são utilizados como sinônimos, mas muitos vêem tier como uma implicação de separação física. Sistemas cliente/servidor são freqüentemente descritos como sistemas two-tier: O cliente é um desktop e o servidor é, em geral, um SGBD. A utilização de layer reforça o fato de que não é necessário que as camadas estejam em máquinas diferentes. Uma camada de lógica de domínio pode ser executada num desktop ou num servidor de banco de dados. Nesta situação, há dois nós, mas três layers diferentes. Com um banco de dados local, as três layers podem ser executadas num único laptop, mas ainda haverá três layers diferentes.
Resumindo, layers são tidos como camadas lógicas enquanto tiers o são para camadas físicas.
As três camadas...
A camada de apresentação cuida da interação entre o usuário e o software. Pode ser tão simples quanto um sistema de linha de comando, ou um cliente rico com interface gráfica ou ainda um sistema baseado em navegadores de Internet. As responsabilidades primárias da camada de apresentação são exibir a informação para o usuário e interpretar os comandos emitidos pelo usuário em ações para as camadas de domínio e de dados.
A camada de dados cuida de toda interação com SGBDs e outras fontes de dados. Pode ser um monitor de transações, outras aplicações, sistemas de mensagens e assim por diante. Para a maior parte das aplicações corporativas, a fonte de dados é um banco de dados cuja responsabilidade é a persistência de dados não voláteis.
A camada de lógica de domínio, também chamada de camada de negócio, cuida das necessidades da aplicação no domínio em que ela se insere. Envolve cálculos baseados em dados digitados e em informações armazenadas, validação de informações vindas da camada de apresentação, e qual fonte de dados deve ser acionada, baseado em comandos recebidos do usuário.
A camada de domínio pode ser arranjada de tal maneira que se interponha separando as outras duas. Contudo, pode ser também que a camada de apresentação faça acesso à camada de dados diretamente. Apesar de ser menos “puro”, pode ser prático em alguns casos.
Uma aplicação pode possuir várias interfaces em cada uma das três camadas. Por exemplo, pode existir uma interface da camada de apresentação para ser utilizada por usuários da aplicação como linha de comando e outra para usuários da aplicação como interface gráfica, ou mesmo uma interface para ser utilizada por outro sistema, como um Web Service. O mesmo se aplica às demais camadas, permitindo abstrair fontes de dados e/ou permitir a aplicação de conjuntos diversos de regras de negócios. A construção de aplicações deste modo, todavia, não é trivial, e seu desenvolvimento deve considerar questões de custo, tempo de desenvolvimento, desempenho, entre outras.
Junto com a separação em camadas caminha uma regra importante sobre dependências: as camadas de domínio e de dados nunca devem ser dependentes da camada de apresentação. Esta regra facilita a utilização de diferentes camadas de apresentação baseados na mesma fundação, sem sérias alterações. O relacionamento entre domínio e dados é mais complexo e depende dos padrões de arquitetura utilizados para a camada de dados.
Uma das tarefas mais árduas é reconhecer o que é lógica de domínio e o que é outra forma de lógica. Um teste informal é adicionar uma camada radicalmente diferente à aplicação, como uma interface de linha de comando a uma aplicação Web. Se houver alguma funcionalidade que precise ser duplicada, é sinal que a lógica de domínio vazou para a camada de apresentação. Similarmente, é necessário duplicar algum código ao substituir o banco de dados relacional por arquivos XML?
MODELOS DE APLICAÇÕES
Há pelo menos duas formas mais comuns de se estruturar a camada de domínio: o modelo simples, Transaction Script, e o modelo completo, Domain Logic.
O modelo simples (Transaction Script) é geralmente utilizado em aplicações onde são embutidos comandos de script nas páginas HTML, como ASP, PHP e JSP, ou construindo-se stored procedures mais complexas nos SGBD’s. Esse modelo comumente nos remete às aplicações cliente/servidor, onde as regras de negócio se misturam aos elementos de apresentação e de armazenamento e busca de dados.
O modelo completo (Domain Logic) envolve a modelagem de objetos de negócio e o desenvolvimento da aplicação seguindo-se o padrão tradicional de orientação a objetos e componentização clássica. Por ser um modelo mais completo em termos de suas preocupações com reutilização, e mais puro no tocante ao uso de recursos da orientação a objetos, também se apresenta com maior complexidade e exige um processo de concepção mais apurado.
Além de disponibilizar o ferramental necessário para a implementação de aplicações utilizando-se os dois modelos clássicos supracitados, a plataforma .NET oferece também um conjunto de facilidades para a implementação de um terceiro modelo, batizado na literatura [1] por Table Module. A experiência tem mostrado que o desenvolvimento de aplicações de complexidade moderada tem sido notavelmente acelerado através da adoção deste modelo, sem sacrificar nenhuma das boas práticas de reutilização, modularidade, escalabilidade e facilidade de manutenção oferecidos pela orientação a objetos tradicional. Além disso, este modelo permite a utilização do mesmo acervo de componentes desenvolvido para o modelo de orientação a objetos tradicional.
Por experiência, temos observado que a relação 80-20 também se aplica no caso da escolha do modelo a ser utilizado para a implementação da Camada de Negócios/Aplicação: em torno de 80% dos problemas normalmente tem uma solução de complexidade moderada e pouca perspectiva de evolução ao longo do tempo, o que os torna candidatos naturais à aplicação do modelo Table Module.
Figura 1: produtividade, esforço, complexidade e custo de manutenção
MIGRAÇÃO DE WINDOWS DNA PARA MICROSOFT.NET
O sistema de Análise de Crédito
Para ilustrar a utilização do desenvolvimento em camadas, iremos relatar a experiência de migração de um sistema de Análise de Crédito para Pessoas Físicas, implementado em Arquitetura Windows DNA para Microsoft.NET.
Originalmente, em 1997, o sistema foi concebido como uma aplicação cliente/servidor, em duas camadas, utilizando Visual Basic e MS SQL Server. E como descrito nas seções anteriores, parte das regras de negócio foi implementada em código de stored procedures e parte foi implementada em código Visual Basic, mesclando as camadas de apresentação e de negócios.
Para facilitar a atualização de versões, utilizar estações menos poderosas e atualizar tecnologicamente o sistema, a versão cliente/servidor foi migrada para arquitetura Windows DNA, utilizando Active Server Pages (ASP), MS Visual Basic 6.0, SQL Server 2000 e COM+. As regras de negócio permaneceram ainda implementadas parte na camada de apresentação e parte em stored procedures. Os componentes COM+ implementaram principalmente o acesso a dados, mapeando chamadas de stored procedures e acesso a transações do legado existente no Mainframe.
O aumento de mercado de Crédito Pessoal causou o crescimento do número de pontos geográficos onde a Análise de Crédito ocorre. Em um ano, a rede de varejo que mais utiliza o sistema aumentou o número de lojas de 20 para 100 em todo o Brasil, considerando o ramo de lojas que atendem somente a produtos financeiros. Essa demanda gerou a necessidade de atualização da arquitetura utilizada no sistema para utilização de tecnologias que melhorem a produtividade de desenvolvimento de novas funcionalidades, e principalmente a escalabilidade e estabilidade do sistema.
A migração de parte do sistema foi realizada pelo Centro de Inovação Microsoft do Senac como Prova de Conceito da Tecnologia .NET. Houve apoio do Centro de Inovação Microsoft de Curitiba, que ministrou os treinamentos da tecnologia e trouxe boas práticas utilizadas em sistemas desenvolvidos por eles.
Devido ao tempo disponível de três semanas, onde uma delas foi ocupada com treinamento, o escopo da Prova de Conceito foi limitado à migração de apenas algumas etapas da Análise de Crédito: Recepção, Pré-Análise, Análise e Geração de Contrato. A arquitetura utilizada pode ser estendida para as outras etapas de Análise existentes no sistema e que devem ser desenvolvidas pela empresa proprietária do software. O resultado obtido na Prova de Conceito foi submetido a um teste de desempenho para avaliação de ganhos de escalabilidade e serviu como parâmetro de comparação entre as arquiteturas e tecnologias utilizadas.
A divisão em camadas
Na camada de apresentação, o Sistema de Análise de Crédito passou a utilizar páginas ASP.NET em substituição a ASP clássico. Na camada de acesso a dados, o esquema de tabelas e as stored procedures não foram alteradas e ainda carregam boa parte das regras de negócio. A camada de negócios ganhou mais corpo com a migração de código que estava implementado em páginas ASP para classes C#. Os acesso aos bancos de dados do sistema seguiu com o modelo Table Module, com utilização de objetos de ADO.NET 2.0, o que permitiu alta produtividade de desenvolvimento. Em alguns trechos do sistema, onde os processos de negócio eram notadamente importantes, foi utilizado o modelo Domain Model, com classes especialmente criadas para implementação das intrincadas regras de concessão de crédito.
A figura 2 mostra o esquema de classes e tecnologias Microsoft utilizadas no sistema.
A camada de apresentação apresenta dois pacotes:
| • | Um pacote para interface dos usuários de loja, onde as páginas ASP.NET oferecem interação entre o usuário e o sistema. |
| • | Um pacote de Web Services para utilização do sistema por outras redes de varejo. |
Figura 2: esquema de classes do Sistema de Análise de Crédito
Camada de Dados
O sistema de Análise de Crédito utiliza duas fontes principais de acesso a dados:
| • | Informações gerenciadas pelo próprio sistema, com dados de propostas, contratos, clientes, limites e regras para concessão de crédito, hospedados em MS SQL Server. Para acesso a essas fontes de dados, foi criada uma classe para ser utilizada pelas classes da camada de negócio. A manipulação de dados foi toda baseada diretamente em ADO.NET, com preferência para utilização de DataReader ao invés de DataSet por ser um componente mais leve e com todas as características necessárias. Apesar de não ser a abordagem mais pura para uma camada de acesso a dados, esta opção possibilitou alto grau de produtividade da equipe de desenvolvimento. Atualmente, não há necessidade de isolamento da camada de acesso a dados em outro servidor, requisito obrigatório em algumas instituições financeiras. Isso causaria a necessidade de uma arquitetura com acesso remoto e uma modelagem mais elaborada com utilização do Design Pattern de Data Transfer Object (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpatterns/html/DesDTO.asp), por exemplo. |
| • | Informações gerenciadas pelo sistema de Processamento de Cartões de Crédito, hospedadas no Mainframe, controladas pelo CICS como monitor de transações e armazenadas em arquivos VSAM. Para acesso a essa fonte de dados, o sistema manteve a classe SOCKET para acesso às transações do CICS. Essa interface com o Mainframe foi desenvolvida internamente pela equipe de plataforma alta da referida rede de varejo. Em outros casos, onde não houver imposição da interface com o Mainframe a ser utilizada, pode ser cogitada a utilização do MS Host Integration Services (http://www.microsoft.com/hiserver). |
Os componentes COM+ que fornecem serviços de acesso a dados ainda permaneceram ativos por serem utilizados pelas etapas do processo não migrados para .NET.
Camada de Negócio
O sistema de Análise de Crédito é parametrizado, permitindo que novas regras sejam incluídas e que o fluxo de trabalho seja alterado conforme o produto ou perfil do cliente. Todos esses parâmetros são persistidos nas bases de dados e interpretados pelas classes de lógica de domínio, por exemplo para determinação do próximo passo do fluxo de trabalho. Algumas classes de negócio, por exemplo, apesar de não possuírem regras complexas e na prática atuarem como classes de acesso a dados, foram criadas nesta camada como estrutura para futuras necessidades. Essa decisão foi tomada com base em informações dos especialistas da Área de Negócio, que indicaram o desejo de novas funcionalidades que afetariam tais classes.
Vemos que neste sistema, a camada de negócios tem alto grau de acoplamento à camada de dados. Utilizando o teste informal citado na seção “As três camadas...”, vemos que não poderemos substituir o banco de dados relacional por arquivos XML sem que haja muitas alterações e novos testes na camada de negócio. O acoplamento entre dados e negócio ocorre na implementação das propriedades das classes que possuem internamente os nomes das stored procedures utilizadas para leitura e alteração, e dos nomes dos respectivos parâmetros.
Mesmo assim, a criação destas camadas de acesso a dados e de negócios, trouxe melhorias à situação anterior, onde os acessos a dados existiam também na camada de apresentação.
Camada de Apresentação
Cada etapa da Análise de Crédito pode apresentar campos diferentes a serem preenchidos ou informados para o usuário, de acordo com o contrato e a política de crédito utilizada. O sistema já possuía essa funcionalidade, e a migração de Windows DNA com ASP clássico para ASP.NET favoreceu uma melhor estrutura com separação da camada de apresentação da camada de negócios. Uma classe para apresentação é o ponto de contato para que as páginas sejam construídas dinamicamente, conforme a etapa do processo a ser manipulada pelo usuário.
Um dos requisitos da migração foi a adequação do sistema para escalabilidade horizontal para atender o aumento do número de propostas analisadas por dia. A arquitetura física idealizada está descrita na próxima seção. O cuidado principal a ser tomado para habilitar a aplicação como escalável horizontalmente é o gerenciamento de sessões de usuário. Normalmente, existe um equipamento de Load Balancing para distribuição de requisições http na frente dos servidores onde é executada a camada de apresentação.
| • | Se o equipamento utilizado tiver suporte para afinidade de sessões, que garante que o usuário é atendido pelo mesmo servidor em cada requisição http, não há alterações a serem feitas e o sistema pode utilizar os recursos do objeto Session de ASP.NET sem maiores preocupações. | ||||
| • | Se o equipamento de load balancing não suportar afinidade de sessões, surgem duas opções:
|
No sistema de Análise de Crédito, optou-se pelo mínimo de dependência de infra-estrutura como requisito para escalabilidade horizontal. Como o sistema depende fortemente de informações anteriores, era inviável a transformação de todo o sistema para a não utilização de variáveis de sessão. Foi criada então uma classe para armazenar as informações importantes para a sessão em Cookies do navegador. Por ser uma aplicação executada na Intranet corporativa, esta é uma configuração aceitável do ponto de vista de segurança.
A camada de apresentação também foi beneficiada pela utilização do Microsoft AJAX (anteriormente chamado Atlas), http://ajax.asp.net, que permitiu que o usuário interagisse com o sistema de maneira muito mais agradável e ágil. A utilização desse framework foi intensiva nas páginas que possuem controles com conteúdo dependente de alguma escolha do usuário. Sem esse recurso, a página toda era enviada ao servidor e o usuário tinha a percepção de que toda a página foi atualizada. Isso também diminuiu o tempo de interação do usuário com o sistema, reduziu a utilização de CPU do servidor e o tráfego de rede também melhorou.
Arquitetura Lógica
A arquitetura do sistema precisa levar em consideração o tempo de convivência entre três edições diferentes do Sistema de Análise de Crédito:
| • | Cliente/Servidor, que é uma aplicação Windows Desktop, baseada em VB 5.0 e ainda utilizada em lojas de varejo; |
| • | Windows DNA, que é uma aplicação Web, baseada em ASP e COM+, utilizada nas lojas da financeira; |
| • | Microsoft .NET, baseada em ASP.NET e Web Services, inicialmente utilizada nas lojas da financeira, mas com intenção futura de substituição da edição Cliente/Servidor nas lojas de varejo. |
Existe ainda uma aplicação de simulação de geração de propostas de clientes com baixo risco de crédito. Essa aplicação recebe os dados de novas propostas geradas por uma Central de Telemarketing terceirizada. O arquivo de propostas é lido por um robô, que simula as mesmas chamadas de COM+ executadas pelo módulo de geração de propostas. Existe intenção de que no futuro, a Central de Telemarketing faça a geração de propostas utilizando Web Services.
Figura 3: visão geral da arquitetura lógica (clique na imagem para ampliar)
A Figura 3 mostra 4 regiões de rede:
| • | Telemarketing Terceirizado: especialmente criada para captação de propostas de baixo risco. As propostas geradas pelos operadores da Central são transmitidas em arquivos via FTP; | ||||||||||
| • | Lojas de Varejo: o ponto principal de estratégia de negócio é a aprovação de crédito imediato com emissão do plástico na própria loja e ativação do cartão de crédito através de uma compra consecutiva. Neste ambiente ainda é utilizada a edição Cliente/Servidor, mas que demanda a presença de dois servidores em cada uma das 120 lojas de varejo: um servidor local de banco de dados e um gateway para o Mainframe/CICS; | ||||||||||
| • | Lojas da Financeira: essas lojas possuem infra-estrutura totalmente independente das lojas de varejo e utilizam a versão Windows DNA do sistema de Análise de Crédito. Não demanda os dois servidores das lojas de varejo, mas possui dois pontos de atenção que serão mitigados com a implantação da edição .NET:
| ||||||||||
| • | Datacenter: detalhado na Figura 4, possui os seguintes elementos:
|
Figura 4: arquitetura lógica do datacenter
Arquitetura Física
A arquitetura idealizada (Figura 5) para o sistema contempla servidores IIS 6.0 em Load Balancing para hospedar a camada de apresentação e oferecer os serviços aos usuários de lojas. Atualmente, essa camada é disponibilizada no mesmo servidor em que é executada a camada de negócio.
A médio prazo, as classes de negócio deverão ser migradas para Web Services, que poderão ser hospedados em outro Web Farm, para atendimento da camada de apresentação e de outras redes de varejos que desejem utilizar os serviços oferecidos pelo sistema de Análise de Crédito.
O MS SQL Server atualmente já é disponibilizado em Cluster para tolerância a falhas. Um dos nós do cluster hospeda os bancos de dados transacionais do sistema. O outro nó é responsável pelo armazenamento de dados históricos e pelo processamento de relatórios gerenciais.
Com essa arquitetura física, o sistema pode aumentar seu poder de processamento com a inclusão de novos elementos de hardware de custo acessível, sem alterações em código e com muita rapidez.
Figura 5: arquitetura física
5.8 Desempenho
A arquitetura utilizada na migração trouxe benefícios percebidos pelos desenvolvedores:
| • | Organização; |
| • | Abstração do acesso a dados e de regras de negócios; |
| • | Execução de tarefas em paralelo com mais confiança e independência. |
Além dessas melhorias, comparamos o desempenho do sistema em arquitetura Windows DNA com a versão migrada. Para isso, simulamos três navegadores digitando propostas de adesão de cartão de crédito, durante cinco minutos. O hardware utilizado como servidor foi um Celeron 2.5 GHz, com 512 MB RAM, com utilização de 100% de CPU durante os testes, o que inviabilizou a simulação de um número maior de navegadores; o cliente foi executado em um Pentium IV com 1GB RAM.
O hardware utilizado nos testes foi o mesmo utilizado pelos desenvolvedores, que implica que os números aqui apresentados não são resultados de ambiente de produção e que apenas foi utilizado para:
| • | Comparação entre um sistema que utiliza arquitetura Windows DNA e outro que utiliza .NET; |
| • | Comparação entre um sistema que possui uma arquitetura em camadas, mesmo que esta não siga todas as recomendações de melhores práticas; |
| • | Avaliação do potencial de ganho que pode ser obtido se o processo de migração for concluído para todo o sistema. |
O gráfico abaixo, mostra que em número de requisições por segundo, o sistema em .NET é quatro vezes superior ao seu antecessor. Além disso, mostra uma curva de resposta bem mais estável que o do sistema em ASP clássico.
Figura 6: comparação de requisições por segundo entre as versões DNA e .NET
A latência do sistema e o tempo para conclusão de cada interação também foram melhores na edição .NET. Enfim, em todos os aspectos de desempenho, o sistema migrado para .NET foi superior, demonstrando além dos benefícios qualitativos, o objetivo de melhoria de escalabilidade do sistema foi alcançado.
|
|
| ||||||
Test Started | 29/3/2006 17:44:19 | 29/3/2006 17:51:47 | ||||||
Test Duration | 00:00:05:00 | 00:00:05:00 | ||||||
Test Iterations | 154 | 1.886 | ||||||
Total number of requests | 5640 | 24.541 | ||||||
Average requests per second | 18,80 | 81,80 | ||||||
Average time to first byte (msecs) | 155,66 | 29,04 | ||||||
Average time to last byte (msecs) | 157,01 | 34,86 | ||||||
Average time to last byte per iteration (msecs) | 5.750,17 | 453,64 |
Tabela 1: comparação entre as versões DNA e.NET
CONCLUSÕES
A estratégia de reescrever a aplicação por módulos foi bem sucedida em vários aspectos. No curto prazo de três semanas, foram percorridas as tecnologias .NET para as camadas de apresentação, de negócios e de dados que resultou numa primeira iteração do sistema que pôde ser testada do ponto de vista funcional e de desempenho. A opção de simplesmente migrar as páginas ASP para ASP.NET já seria o suficiente para obter ganhos de desempenho, mas não utilizaria todo o potencial das tecnologias .NET, nem ajudaria na modelagem do sistema em camadas.
A convivência na aplicação entre os novos módulos reescritos e os módulos que permaneceram em Windows DNA ocorreu sem maiores transtornos, uma vez que a comunicação entre eles foi implementada através de recursos http (cookies) ou de bancos de dados, livrando a necessidade de dependência de recursos de sessão ou quaisquer outros particulares de ASP ou ASP.NET.
A reestruturação parcial de um sistema que já está em produção demanda grandes doses de engenharia e de conhecimento de negócio. Muitas vezes algumas estruturas, que do ponto de vista tecnológico poderiam ser remodeladas, não puderam ser melhoradas devido ao seu alto grau de acoplamento a outras camadas do sistema e a restrições de regras de negócio.
Apesar das limitações, o teste de desempenho mostra um caminho adequado para que os objetivos reais de desempenho e escalabilidade sejam atingidos.
Do ponto de vista de produtividade de desenvolvimento, a equipe sentiu-se bastante motivada com os benefícios do Visual Studio 2005 e do .NET Framework 2.0, o que os encorajou a enfrentar as próximas iterações da migração que se seguirão.
REFERÊNCIAS
Patterns of Enterprise Application Architecture
Chapter 1: Layering
Chapter 2: Organizing Domain Logic
By Martin Fowler et al Addyson Wesley
A Guide to Building Enterprise Applications on the .NET Framework- Building the Next Generation of Service-based Software Systems
How To Set Up TCP/IP for Network Load Balancing in Windows Server 2003
http://support.microsoft.com/default.aspx?scid=kb;en-us;323431
Microsoft Patterns and Practices Developer Center
http://msdn.microsoft.com/practices/