Arquitetura de Aplicações em 2, 3, 4 ou N camadas

image_pdfimage_print

Fiz uma compilação de partes de textos e iremos aqui discutir cada um dos conceitos, mostrando as vantagens e desvantagens de aplicações em cada quantidade de camadas existentes, ou seja, toda sua evolução.

Modelo Cliente/Servidor

Cliente-servidor é um modelo computacional que separa clientes e servidores, sendo interligados entre si geralmente utilizando-se uma rede de computadores. Cada instância de um cliente pode enviar requisições de dado para algum dos servidores conectados e esperar pela resposta. Por sua vez, algum dos servidores disponíveis pode aceitar tais requisições, processá-las e retornar o resultado para o cliente. Apesar do conceito ser aplicado em diversos usos e aplicações, a arquitetura é praticamente a mesma.

O modelo Cliente/Servidor, foi criado tendo como base a descentralização dos dados e recursos de processamento, em oposição ao modelo Centralizado utilizado na época em que o Mainframe dominava absoluto. No modelo Cliente/Servidor, conforme indicado pela figura abaixo, em uma rede de computadores, existem uma ou mais máquinas que atuam como Servidores, disponibilizando recursos para as demais máquinas, as quais atuam como Clientes.

A máquina servidor é um host que está executando um ou mais programas de servidor que partilham os seus recursos com os clientes.

Um cliente não compartilha de seus recursos, mas solicita o conteúdo de um servidor ou função de serviço. Os clientes, portanto, iniciam sessões de comunicação com os servidores que esperam as solicitações de entrada.

Modelo Cliente-Servidor

Modelo Cliente-Servidor

Conforme pode ser visto na figura, temos Servidores para Arquivos, Banco de dados e outras funções, tais como: Servidores de impressão, Servidores Web, etc. Estas redes, tipicamente, são formadas por Servidores, os quais são equipamentos com um maior poder de processamento e armazenamento do que os clientes, os quais, na maioria dos casos, são Microcomputadores ligados em rede.

Aplicações em 2 Camadas

No início da utilização do modelo Cliente/Servidor, as aplicações foram desenvolvidas utilizando-se um modelo de desenvolvimento em duas camadas. Neste modelo, um programa, normalmente desenvolvido em um ambiente de desenvolvimento, como o Visual Basic, Delphi ou Power Builder, é instalado em cada Cliente. Este programa acessa dados em um servidor de Banco de dados, conforme ilustrado na figura abaixo:

2 Camadas

2 Camadas

No modelo de duas camadas, temos um programa que é instalado no Cliente, programa esse que faz acesso a um Banco de dados que fica residente no Servidor de Banco de dados. Na maioria dos casos, a máquina do Cliente é um PC rodando Windows, e a aplicação Cliente é desenvolvida utilizando-se um dos ambientes conhecidos, conforme citado anteriormente. Sendo a aplicação Cliente, um programa para Windows (na grande maioria dos casos), esta deve ser instalada em cada um dos computadores da rede, que farão uso da aplicação. É o processo de instalação normal, para qualquer aplicação Windows. No modelo de 2 camadas, a aplicação Cliente é responsável pelas seguintes funções:

  • Apresentação: O Código que gera a Interface visível do programa, que é utilizada pelo usuário para acessar a aplicação, faz parte da aplicação Cliente. Todos os formulários, menus e demais elementos visuais, estão contidos no código da aplicação Cliente. Caso sejam necessárias alterações na interface do programa, faz-se necessária a geração de uma nova versão do programa, e todos os computadores que possuem a versão anterior, devem receber a nova versão, para que o usuário possa ter acesso as alterações da interface. Aí que começam a surgir os problemas no modelo de 2 camadas: Uma simples alteração de interface, é suficiente para gerar a necessidade de atualizar a aplicação, em centenas ou milhares de computadores. O gerenciamento desta tarefa, é algo extremamente complexo e de custo elevado.
  • Lógica do Negócio: Aqui estão as regras que definem a maneira como os dados serão acessados e processados, as quais são conhecidas como “Lógica do Negócio”. Fazem parte das Regras do Negócio, desde funções simples de validação da entrada de dados, como o cálculo do digito verificador de um CPF, até funções mais complexas, como descontos escalonados para os maiores clientes, de acordo com o volume da compra. Questões relativas a legislação fiscal e escrita contábil, também fazem parte da Lógica do Negócio. Por exemplo, um programa para gerência de Recursos Humanos, desenvolvido para a legislação dos EUA, não pode ser utilizado, sem modificações, por uma empresa brasileira.. Alterações nas regras do negócio são bastante freqüentes, ainda mais com as repetidas mudanças na legislação do nosso país. Com isso, faz-se necessária a geração de uma nova versão do programa, cada vez que uma determinada regra muda, ou quando regras forem acrescentadas ou retiradas. Desta forma, todos os computadores que possuem a versão anterior, devem receber a nova versão, para que o usuário possa ter acesso as alterações . Mais problemas com o modelo de 2 camadas: Qualquer alteração nas regras do negócio, é suficiente para gerar a necessidade de atualizar a aplicação, em centenas ou milhares de computadores. O gerenciamento desta tarefa, é algo extremamente complexo e de custo elevado.
  • A outra camada, vem a ser o Banco de dados, o qual fica armazenado em Servidor da rede. Uma aplicação desenvolvida em Visual Basic, a qual acessa um Banco de dados em um servidor Microsoft SQL Server, é um típico exemplo de uma aplicação em 2 camadas.

Com a evolução do mercado e as alterações da legislação, mudanças nas regras do negócio são bastante freqüentes. Com isso o modelo de duas camadas, demonstrou-se de difícil manutenção e gerenciamento, além de apresentar um custo de propriedade muito elevado.

Isto sem contar com o problema conhecido como “DLL Hell” (Inferno das DLLs), onde diferentes aplicativos, instalam diferentes versões da mesma DLL e um conflito é gerado. É o caso típico onde a instalação de um programa, faz com que um ou mais programas, instalados anteriormente, deixem de funcionar. Em resumo, como diria um famoso comediante: “Uma verdadeira visão do Inferno”. Inferno para o usuário, que não tem os programas funcionando como deveriam; inferno para a equipe de desenvolvimento que não tem o seu trabalho reconhecido e, normalmente, tem que trabalhar apenas “apagando incêndios”; e inferno para a Administração/Gerência da rede que não consegue gerar os resultados esperados pela Administração da empresa, apesar dos elevados valores já investidos.

Resumindo:

    • Sistemas em camadas surgiram para:
      • Melhor aproveitar os PCs da empresa
      • Oferecer sistemas com interfaces gráficas amigáveis
      • Integrar o desktop e os dados corporativos
    • Em outras palavras, permitiram aumentar a escalabilidade de uso de Sistemas de Informação
    • Os primeiros sistemas cliente-servidor eram de duas camadas
      • Camada cliente trata da lógica de negócio e da UI
      • Camada servidor trata dos dados (usando um SGBD)

 

Pode parecer difícil de acreditar, mas um grande número de empresas ainda tem a maioria dos seus aplicativos baseados no modelo Cliente/Servidor de 2 camadas. Em busca de soluções para os problemas do modelo de duas camadas, é que surge a proposta do modelo de 3 camadas.

Aplicações em 3 Camadas

Modelo em três camadas, derivado do modelo ‘n’ camadas, recebe esta denominação quando um sistema cliente-servidor é desenvolvido retirando-se a camada de negócio do lado docliente. O desenvolvimento é mais demorado no início comparando-se com o modelo em duas camadas pois é necessário dar suporte a uma maior quantidade de plataformas e ambientes diferentes. Em contrapartida, o retorno vem em forma de respostas mais rápidas nas requisições, excelente performance tanto em sistemas que rodam na Internet ou em intranet e mais controle no crescimento do sistema.

Como uma evolução do modelo de 2 camadas, surge, com o crescimento da Internet, o modelo de três camadas. A idéia básica do modelo de 3 camadas, é “retirar” as Regras do Negócio do cliente e centralizá-las em um determinado ponto, o qual é chamado de Servidor de Aplicações. O acesso ao Banco de dados é feito através das regras contidas no Servidor de Aplicações. Ao centralizar as Regras do Negócio em um único ponto, fica muito mais fácil a atualização destas regras. A figura, nos dá uma idéia geral do modelo em 3 camadas:

3 Camadas

3 Camadas

Todo o acesso do cliente ao Banco de dados, é feito de acordo com as regras contidas no Servidor de aplicações. O cliente não tem acesso direto ao Banco de dados, sem antes passar pelo servidor de aplicações. Com isso as três camadas são as seguintes:

  • Apresentação: Continua no programa instalado no cliente. Alterações na Interface do programa, geram a necessidade de atualizar a aplicação em todos os computadores, onde esta está sendo utilizada. Porém cabe ressaltar, que alterações na interface, são menos freqüentes do que alterações nas regras do negócio.
  • Lógica: São as regras do negócio, as quais determinam de que maneira os dados serão utilizados. Esta camada foi deslocada para o Servidor de aplicações. Desta maneira, quando uma regra do negócio for alterada, basta atualizá-la no Servidor de aplicações. Após a atualização, todos os usuários passarão a ter acesso a nova versão, sem que seja necessário reinstalar o programa em cada um dos computadores da rede. Vejam que ao centralizar as regras do negócio em um Servidor de aplicações, estamos facilitando a tarefa de manter a aplicação atualizada.
  • Dados: Nesta camada temos o servidor de Banco de dados, no qual reside toda a informação necessária para o funcionamento da aplicação. Cabe ressaltar, novamente, que os dados somente são acessados através do Servidor de aplicação, e não diretamente pela aplicação Cliente.

Resumindo:

  • A arquitetura cliente/servidor em 2 camadas sofria de vários problemas:
    • Falta de escalabilidade (conexões a bancos de dados)
    • Enormes problemas de manutenção (mudanças na lógica de aplicação forçava instalações)
    • Dificuldade de acessar fontes heterogêneas (legado CICS, 3270, …)
  • Inventou-se a arquitetura em 3 camadas
    • Camada de apresentação (UI)
    • Camada de aplicação (business logic)
    • Camada de dados
  • Problemas de manutenção foram reduzidos, pois mudanças às camadas de aplicação e de dados não necessitam de novas instalações no desktop
  • Observe que as camadas são lógicas:
    • Fisicamente, várias camadas podem executar na mesma máquina
    • Quase sempre, há separação física de máquinas

Com a introdução da camada de Lógica, resolvemos o problema de termos que atualizar a aplicação, em centenas ou milhares de computadores, cada vez que uma regra do negócio for alterada. Porém continuamos com o problema de atualização da aplicação, cada vez que forem necessárias mudanças na Interface. Por isso que surgiram os modelos de n-camadas. Agora vamos falar um pouco sobre o modelo de 4 camadas.

Aplicações em 4 Camadas (Web Based)

Como uma evolução do modelo de três camadas, surge o modelo de quatro camadas. A idéia básica do modelo de 4 camadas, é retirar a apresentação do cliente e centralizá-las em um determinado ponto, o qual na maioria dos casos é um servidor Web. Com isso o próprio Cliente deixa de existir como um programa que precisa ser instalado em cada computador da rede. O acesso a aplicação, é feito através de um Navegador, como o Internet Explorer ou o Netscape Navigator. A figura nos dá uma idéia geral do modelo em quatro camadas:

4 Camadas

4 Camadas

Para acessar a aplicação, o cliente acessa o endereço da aplicação, utilizando o seu navegador. Por exemplo http://www.empresa-abc.com/sistemas/cadastro.asp . Todo o acesso do cliente ao Banco de dados, é feito de acordo com as regras contidas no Servidor de aplicações. O cliente não tem acesso direto ao Banco de dados, sem antes passar pelo servidor de aplicações. Com isso as quatro camadas são as seguintes:

  • Cliente: Nesta caso o Cliente é o Navegador utilizado pelo usuário, quer seja o Internet Explorer, quer seja o Netscape Navigator, ou outro Navegador qualquer.
  • Apresentação: Passa para o Servidor Web. A interface pode ser composta de páginas HTML, ASP, ou qualquer outra tecnologia capaz de gerar conteúdo para o Navegador. Com isso alterações na interface da aplicação, são feitas diretamente no servidor Web, sendo que estas alterações estarão, automaticamente, disponíveis para todos os Clientes. Com isso não existe a necessidade de reinstalar a aplicação em todos os computadores da rede cada vez que uma alteração for feita na camada de apresentação. Fica muito mais fácil garantir que todos estão acessando a versão mais atualizada da aplicação. A única coisa que o cliente precisa ter instalado na sua máquina, é o Navegador. O acesso ao Banco de dados, é feito através do Servidor de aplicações.
  • Lógica: São as regras do negócio, as quais determinam de que maneira os dados serão utilizados. Esta camada está no Servidor de aplicações. Desta maneira, quando uma regra do negócio for alterada, basta atualizá-la no Servidor de aplicações. Após a atualização, todos os usuários passarão a ter acesso a nova versão, sem que seja necessário reinstalar o programa em cada um dos computadores da rede. Vejam que ao centralizar as regras do negócio em um Servidor de aplicações, estamos facilitando a tarefa de manter a aplicação atualizada.
  • Dados: Nesta camada temos o servidor de Banco de dados, no qual reside toda a informação necessária para o funcionamento da aplicação.

Com o deslocamento da camada de apresentação para um Servidor Web, resolvemos o problema de termos que atualizar a aplicação, em centenas ou milhares de computadores, cada vez que a interface for alterada. Neste ponto a atualização das aplicações é uma tarefa mais gerenciável, muito diferente do que acontecia no caso do modelo em duas camadas.

Os servidores de Aplicação, servidor Web e servidor de Banco de dados, não precisam, necessariamente, ser servidores separados, isto é, uma máquina para fazer o papel de cada um dos servidores. O conceito de servidor de Aplicação, Web ou Banco de dados, é um conceito relacionado com a função que o servidor desempenha. Podemos ter, em um mesmo equipamento, um Servidor de aplicações, um servidor Web e um servidor de Banco de dados. Claro que questões de desempenho devem ser levadas em consideração.

Resumindo:

  • A arquitetura em 3 camadas original sofre de problemas:
    • A instalação inicial dos programas no desktop é cara
    • O problema de manutenção ainda persiste quando há mudanças à camada de apresentação
    • Não se pode instalar software facilmente num desktop que não está sob seu controle administrativo
      • Em máquinas de parceiros
      • Em máquinas de fornecedores
      • Em máquinas de grandes clientes
      • Em máquinas na Internet
  • Então, usamos o Browser como Cliente Universal
    • Conceito de Intranet
    • A camada de aplicação se quebra em duas: Web e Aplicação
    • Evitamos instalar qualquer software no desktop e portanto, problemas de manutenção
    • Evitar instalação em computadores de clientes, parceiros, fornecedores, etc.
  • Às vezes, continua-se a chamar isso de 3 camadas porque as camadas Web e Aplicação freqüentemente rodam na mesma máquina (para pequenos volumes)

Arquitetura em N Camadas

  • Os problemas remanescentes:
    • Não há suporte a Thin Clients (PDA, celulares, smart cards, quiosques, …) pois preciso usar um browser (pesado) no cliente
    • Dificuldade de criar software reutilizável: cadê a componentização?
    • Fazer aplicações distribuídas multicamadas é difícil. Tem que:
      • Implementar persistência (impedance mismatch entre o mundo OO e o mundo dos BDs relacionais)
      • Implementar tolerância a falhas com fail-over
      • Implementar gerência de transações distribuídas
      • Implementar balanceamento de carga
      • Implementar resource pooling
      • etc.
  • As empresas não querem contratar PhDs para implementar sistemas de informação!
  • O truque é introduzir middleware num servidor de aplicação que ofereça esses serviços automaticamente
  • Além do mais, as soluções oferecidas (J2EE, .Net) são baseadas em componentes
  • As camadas podem ter vários nomes:
    • Apresentação, interface, cliente
    • Web
    • Aplicação, Business
    • Dados, Enterprise Information System (EIS)
N Camadas

N Camadas

Fontes:

http://www.juliobattisti.com.br/artigos/ti/ncamadas.asp
http://jacques.dsc.ufcg.edu.br/cursos/j2ee/html/intro/intro.htm
http://pt.wikipedia.org/wiki/Modelo_em_três_camadas
http://pt.wikipedia.org/wiki/Cliente-servidor
http://pt.wikipedia.org/wiki/N_camadas

Sou bacharel em Sistemas de Informação pela Estácio de Sá (Alagoas), especialista em Gestão Estratégica da Tecnologia da Informação pela Univ. Gama Filho (UGF) e pós-graduando em Gestão da Segurança da Informação pela Univ. do Sul de Santa Catarina (UNISUL). Tenho interesse por todas as áreas da informática, mas em especial em Gestão, Segurança da Informação, Ethical Hacking e Perícia Forense. Sempre disposto a receber sugestões de assuntos para criar uma postagem.

5 Responses to “Arquitetura de Aplicações em 2, 3, 4 ou N camadas”

  1. Miriam disse:

    Gostei pela simplicidade das explicações.

  2. Josué Pereira disse:

    Parabéns! Bem contextualizado o artigo! gostei muito do resumo!

  3. rodrigo lopes disse:

    Muito Bom simples e objetivo o artigo
    Parabéns

  4. Deodoro disse:

    Meus parabéns!
    Muito intuitivo, didático e completo.

  5. Natanael disse:

    Excelente artigo! Me ajudou bastante no trabalho da faculdade.

    Meus parabéns!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Quer ficar atualizado?

Inscreva-se em minha newsletter e seja notificado quando eu publicar novos artigos de graça!