Desenvolvimento

Ξ 7 comentários

Cuidados ao selecionar as tecnologias de suas aplicações

publicado por Caio Azevedo

Em minhas recentes atividades como arquiteto de soluções Microsoft, deparei em alguns clientes com uma situação no mínimo inusitada. Todos tinham como meta construir suas aplicações seguindo as tecnologias do momento – Multicamadas, Web Services, Orientação a Objetos, etc. E eis que, como tantos outros, insidiam nos mesmos erros – talvez por falta de experiência, maturidade ou mesmo conhecimento, o certo é que, tentar de qualquer forma e a qualquer custo inserir todas, ou pelo menos boa parte dessas tecnologias em seus modelos de aplicação, é uma prática cada vez mais comum no ambiente corporativo, e as consequências podem ser desastrosas, pondo em risco todo o projeto.  E ai já vi diversas situações, do uso excessivo e indiscriminado de uma tecnologia, à ilusão de se estar utilizado uma delas, a saber – Web Services e Orientação a Objetos respectivamente.

Problemas com modelos de aplicações não são novidades, desde os tempos da fórmula IIS * COM+ * SQL Server, a conhecida arquitetura Windows DNA – deparavamos com alguns cenários realmente assustadores, onde na maioria das vezes o grande problema era a utilização do mais velho ainda, paradigma Cliente – Servidor. A seguir temos alguns cenários que certamente estavam fadados ao fracasso:

01. Acesso aos dados [via ADO] diretamente nas páginas, e para piorar, sem preocupação com as propriedades de otimização dos objetos Connection, RecordSet e Command, transformando uma aplicação Web em um típico cliente / servidor com os cursores no servidor [um desastre total];

02. Sub utilização de componentes [Visual Basic 6.0], uma vez que nenhuma das features do COM+ [Pool de Ativação, Controle de Transações, Segurança, etc] eram utilizadas, lhes restando somente a tarefa de executar stored procedures, caracterizando mais um caso de desuso de tecnologia, ou pior a ilusão de um ambiente em 3 camadas, já que as regras de negócio, ou ao menos parte delas, estão em sua implementação.

Consequências

Não dá outra, clientes vendo seu investimento [tempo e dinheiro] indo para o espaço, todo seu planejamento comprometido porque “o sistema não funciona”, um verdadeiro fracasso. Tecnicamente temos alguns sintomas: (para os ambientes descritos)

– Sobrecarga de processamento – ora no IIS [via dllhost.exe], ora no COM+ [com altíssimos tempos de ativação dos componentes]

– Constantes “travamentos” da aplicação, e não menos comum de todas as demais aplicações do servidor.

– Conseqüentemente surge, como já cansei de ouvir – “soluções baseadas em COM+ não funcionam.

No “admirável mundo novo” do ambiente Microsoft .net, as aplicações podem ser modeladas das mais variadas maneiras, bem mais que no mundo DNA [o que sendo bem pessimista, só aumenta as chances de erros], sendo assim, uma boa dica para iniciar a modelagem de uma aplicação .net, seria delimitar todo o cenário, seus pré-requisitos técnico-operacionais, funcionalidades, infra-estrutura do ambiente de produção, políticas de contingência, dentre outras variáveis que certamente induzirão arquitetos, analistas, desenvolvedores, DBAs e a equipe de infra a cometerem erros que podem comprometer todo projeto, a seguir temos alguns casos, facilmente encontrados em qualquer ambiente corporativo.

Como já dissemos um erro comum no desenvolvimento de aplicações, é a ilusão de se utilizar uma tecnologia/paradigma quando na verdade se está bem longe disso. Já demonstramos um caso quando falamos do mundo DNA 3-tiers, quando apesar dos recursos, a equipe responsável continuava com o paradigma Cliente x Servidor 2-tiers. Nos dias de hoje, o que vemos são aplicações, ditas orientada a objetos com multicamadas, onde não temos qualquer construção com herança de objetos [por exemplo, na implementação de classes proprietárias para repositório de dados – pessoa, cliente, usuário] – um desperdício dos recursos e funcionalidades que a OO disponibiliza. Dentro desse cenário ainda encontramos uma “camada de apresentação” implementada de tal forma que detalhes do banco de dados [string de conexão, nome de tabelas, atributos, etc] precisam ser conhecidas. Ora, uma aplicação multicamadas tem, dentre seus atrativos, prover um considerável nível de abstração entre as camadas o que não é o caso. Assim, em um cenário com esses “detalhes de construção”, a aplicação aparentemente OO x Multicamadas, só não pode ser considerada Estruturada, pois a ferramenta de desenvolvimento não permite [qualquer assembly .net precisa de pelo menos uma classe].

Dentre as questões estruturais do desenvolvimento de softwares no nível arquitetural destacamos a escalabilidade [geralmente relacionada ao desempenho] – podendo ser do tipo horizontal ou vertical, e que varia basicamente em função do parque tecnológico disponível e das perspectivas de demanda para a aplicação. Imaginemos uma situação onde, a infra é definida com um pool de 4, 5 servidores potentes, configurados para implementar um Web Farm. Para que modelar uma solução distribuída, com Web Services, “desperdiçando” um ou vários desses servidores para “camada de regras de negócio”, sob o argumento que estamos diante de uma aplicação n-camadas ? Pois bem, estamos diante de um problema conceitual [sendo bem eufemista] – Aplicações multicamadas, não implicam necessariamente em aplicações distribuídas. Para piorar a situação desse cenário, a comunicação entre as “camadas” é feita com Web Services, um exemplo típico de modismo. Uma modelagem nessa forma tem um custo absurdo e não justificável.

A seguir tomaremos esse caso como exemplo, de qualquer forma, não seria mais interessante deixar todos os componentes de regras de negócio no modelo de deploy padrão .net, “folder” bin], assim faríamos melhor uso do ambiente descrito.

Para exemplicar essa terrível tendência, lançarei mão dos Web Services, uma poderosa tecnologia – eu diria que uma das mais importantes desde o advento da internet, no entanto seu uso sem critérios pode ser catastrófico [como no cenário acima]. Os Web Services, como toda grande idéia, prima pela simplicidade, permitindo que funcionalidades, até então restritas a um ambiente fechado [uma intranet por exemplo], estejam acessíveis para todos, em qualquer lugar, por diversos dispositivos e independente das plataformas envolvidas, sendo assim, se você resolver utilizá-los no seu modelo de aplicação antes de mais nada procure dentre esses três itens, uma justificativa para tal. Como nem tudo são flores, os Web Services tem seu custo, para realizar suas proezas ele se basea em três pilares – Serialização, XML e HTTP, o resto são conceitos e siglas, no fundo os Web Services são objetos serializados [Estruturas, DataSets, Arrays, Classes, etc], transmitidos entre as partes [através o já conhecido protocolo HTTP, livre dos firewalls], em um formato de dados que já se tornou padrão e amplamente difundido [viva o XML] e os custos ??? simples, o processo de serializar/deserializar tem seus custos de processamento [o menor de todos é bem verdade], a transmissão dos dados serializados via HTTP fatalmente acarreta um custo elevado, por concorrer com as requisições dos usuário POST/GET de páginas HTML e ASPX e principalmente pelo formato dos dados, XML, que contém um conjunto de metadados para compor as mensagens, tornando-as ainda maiores.

Sendo assim, aquele cenário “distribuído”, tendo Web Services como meio de comunicação está deveras comprometido. Uma alternativa para esse ambiente, distribuído e sobretudo interno, seria o uso de Remoting uma tecnologia, que atende a demanda [se considerarmos, a real necessidade de um ambiente distribuído], sem os custos dos web services. Essa proeza é possível pela substituição de tecnologia nos três pilares do Web Service:

– Serialização – No Remoting, em sua melhor configuração para performance, a serialização binária, ao invés da XML é a mais indicada, tornando os dados trafegados significativamente menores. [o remoting também suporta serialização XML]

– HTTP – Aqui substituímos o protocolo de transporte para TCP, em uma porta específica, o que por definição é mais eficaz que o HTTP, além de evitar a concorrência com as aplicações e suas páginas estáticas e dinâmicas.

Ao executarmos os dois cenários, percebemos através dos contadores utilizados, um sensível ganho de performance na versão Remoting, no entanto em um cenário real, onde nosso web service concorre com as demais aplicações web e sobretudo, onde o processamento do componente de negócio é considerável, essa diferença tende a aumentar, e outra, para que utilizar uma tecnologia, se temos alternativas mais elegante e performática ?? – modismo, hábito, facilidade na implementação ?, são nesses “detalhes” que distinguimos bons e maus projetos de software.

Pessoal, de maneira alguma sou contra o uso de Web Services, mas sua utilização em um ambiente intra-domínio, com dois ou mais servidores, trocando todo e qualquer tipo de mensagem – operações DML, pesquisas ao banco de dados para carregar controles, instância dos componentes de regras de negócio, entre outras, definitivamente não será bem sucedida quando a demanda atingir um patamar considerável.

Bom pessoal, eis um exemplo dentre tantos outros que encontramos em qualquer ambiente corporativo, muito cuidado com os modelos de aplicação utilizados em seus projetos, façamos uma reflexão no que já temos implementado, como poderíamos modificar, detectando pontos críticos e sugerindo mudanças em próximos projetos, o que não se podemos admitir é a incidência de erros dessa natureza passivamente.

Nota: Se alguém estiver interesado nos códigos utilizados na demonstração, sinta-se a vontade para entrar em contato.

 

  •  
  •  
  •  
  •  
  •  
  •  
  •  

Compare preços de Uber, 99 e Taxi

Minimum Way

Autor

MBA - FGV Administração de Empresas, Graduado em Ciência da Computação, apaixonado por ciências exatas e fotografia. Web System Manager da Samsung e Arquiteto de Softwares. Palestrante, tecno-colunista e instrutor da treinando .net. Criador do aplicativo smartBuy Certificado Microsoftt - MCP, MCAD, MCSD, MCTS e MCPD. LinkedIn.

Caio Azevedo

Comentários

7 Comments

  • Parabéns pelo post Caio. Você é fera!!

  • Show de bola Caião. Imagino o quanto vc ainda tenha a dizer sobre tudo isso, dá pra passar um fim de semana inteiro. Parábens.

  • Olá Caio, obrigado pela resposta.
    Realmente a maioria das nossas aplicações não trabalham com componentes COM+. Sempre desenvolvemos buscando a máxima otimização através de chamadas diretamente pela camada principal. Entendo que este não seria o melhor plano de negócio, mas todo o projeto foi montado na base do “…vamos trocar o pneu do carro com o carro andando…” e aí não teve jeito. Gostaria estudar a possibilidade de migração desse cenário, mas acredito que precisaremos de um plano de negócio e analisarmos qual impacto terá para esta alteração. Agradeceria se indicasse assuntos de referência para pesquisa.

    • Olá Alexandre,

      É meu amigo, esse cenário de trocar pneu com o carro em movimento é uma regra no nosso dia a dia infelizmente (sem falar no parto em um mês com nove mulheres).

      Quanto às referências, sinceramente não conheço e eu procurei bastante, no máximo encontrei alguns trabalhos acadêmicos – que são ótimos. Mas, o que de fato você precisa é de um time de profissionais experientes e que sejam suficientemente maduros para não se empolgar com tecnologias emergentes, a saber em nossos dias: SOA, Cloud Computing, WebPortals, dentre outros – é claro que elas são excelentes só precisam ser usadas na hora e lugar corretos.

      Grande abraço..
      Caio

  • Parabéns Caio,

    Sopa de letrinhas e coleções de siglas bonitas não fazem um sistema robusto e eficiente. Não se pode usar um trator em uma corrida de velocidade e também não podemos usar um Fusca e/ou Fiat Uno para puxar um tronco. É importante escolher as ferramentas certas para o trabalho. Portanto, é MUITO importante saber QUAL é o trabalho a ser feito. Não importa se você usa RUP ou SCRUM! O que importa é saber para onde devemos ir, antes de dar o passo!

    Att.

    • É isso ai Willian você de fato captou o espírito da coisa, isso já valeu o trabalho de ter escrito o artigo.
      Muito obrigado pelo post e grande abraço..
      Caio Azevedo

  • Salve Caio,

    Estamos em 2015 e este assunto está mais do que atualizado, o uso indevido de “SOA” nas aplicações continua sendo muito comum. Me lembro que nos primórdios alguém escreveu um livro indicando o uso de tabelas html para se formatar layout e isso se tornou padrão até que um dia alguém criou o padrão tableless, creio que já passou da hora de escrevermos um livro chamado SOALess e acabarmos com essa modinha.

    Abraço.

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade




Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.