Embora utilizemos o exemplo de comércio eletrônico, CRM, e-procurement, etc., como situações onde podemos utilizar a tecnologia ASP ou ASP.NET, não são somente nestas situações que a tecnologia pode ser utilizada. Hoje em dia, com o aumento da complexidade das redes de computadores baseadas em PCs, existe uma tendência bastante acentuada em favor do desenvolvimento de aplicações que seguem o modelo Web. São aplicações que são acessadas através de um Navegador (Browser), tal com o Internet Explorer, Google Chrome ou Firefox. Neste tópico iremos falar um pouco sobre aplicações Cliente/Servidor tradicionais e os problemas deste tipo de modelo.

Falaremos sobre aplicações de 2, 3 ou n camadas, e onde a tecnologia ASP  ou ASP.NET se encaixa perfeitamente, neste mundo de desenvolvimento de aplicações habilitadas para a Web.

A Complexidade de Gerenciamento do Modelo Cliente/Servidor e Aplicações de 2 Camadas:

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 (computadores de grande porte) dominava absoluto. Neste modelo, conforme indicado pela Figura 13.10, 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.

Figura 13.10 – O Modelo Cliente/Servidor tradicional.

Conforme pode ser visto na Figura 13.10, 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 13.11:

Figura 13.11 – O modelo de desenvolvimento em duas 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 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 às 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, ao longo de toda a rede da empresa. O gerenciamento desta tarefa é algo extremamente complexo e oneroso.
• Lógica do Negócio: As regras que definem a maneira como os dados serão acessados e processados 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 dígito verificador de um CPF ou CNPJ, até funções mais complexas, como descontos escalonados para os maiores clientes, de acordo com o volume da compra. Questões relativas à 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 as devidas adaptações, por uma empresa brasileira. Isso acontece porque a legislação dos EUA é diferente da legislação brasileira. Em síntese, as regras para o sistema de recursos humanos são diferentes. Com isso, 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. Desta forma faz-se necessária a geração de uma nova versão do programa, cada vez que uma determinada regra de negócio for alterada, 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 às alterações. Agora temos mais problemas no modelo de 2 camadas: Qualquer alteração nas regras do negócio, o que ocorre com grande freqüência, é suficiente para gerar a necessidade de atualizar a aplicação, em centenas ou milhares de computadores. O gerenciamento desta tarefa é algo extremamente complexo e oneroso.

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 TCO (Total Cost Ownership – Custo Total de Propriedade) muito elevado.

A outra camada vem a ser o Banco de dados, o qual fica armazenado em um 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.

Em busca de soluções para os problemas do modelo de duas camadas é que surge a proposta do modelo de 3 camadas, conforme analisaremos a seguir.

O Modelo de Aplicações em 3 Camadas:

Como uma evolução do modelo de 2 camadas, surge o modelo de 3 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 das regras. A Figura 13.12 nos dá uma idéia geral do modelo em 3 camadas:

Figura 13.12 – O modelo de desenvolvimento em três 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 a aplicação 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. Já melhorou um pouco, em relação ao modelo Cliente/Servidor de 2 Camadas.
• 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 à nova versão da regra, 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, o que reduz consideravelmente os custos de manutenção e implementação da aplicação.
• 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 que os dados somente são acessados através do Servidor de aplicação, e não diretamente pela aplicação cliente.

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 (o que ocorre com bastante frequência). 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. A seguir, iremos falar um pouco sobre o modelo de 4 camadas.

Aplicações em 4 Camadas:

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 à aplicação é feito através de um navegador, como o Internet Explorer. Google Chrome ou Firefox.  A Figura 13.13 nos dá uma idéia geral do modelo em quatro camadas:

Figura 13.13 – O modelo de desenvolvimento em quatro 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 ao Banco de dados, sem antes passar pelo servidor de aplicações. Com isso as quatro camadas são as seguintes:

• Cliente: Neste caso o cliente é o navegador utilizado pelo usuário, quer seja o Internet Explorer, quer seja o Google Chrome, o Firefox, ou outro navegador qualquer.
• Apresentação: Passa para o Servidor Web. A interface pode ser composta de páginas HTML, ASP ou ASP.NET, ou qualquer outra tecnologia capaz de gerar conteúdo dinâmico 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. Assim não existe a necessidade de reinstalar a aplicação em todos os computadores da rede, cada vez que houver mudanças na interface da aplicação. Fica muito mais fácil garantir que todos estão tendo acesso à 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 à 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 da rede da empresa, cada vez que houver alterações na interface do programa.  Neste ponto a atualização das aplicações é uma tarefa mais gerenciável, muito diferente do que acontecia no caso do modelo em 2 camadas e com um custo muito menor.

Os servidores de Aplicação, Web e 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, conforme analisaremos no próximo tópico. Hoje em dia, com a disponibilidade das tecnologias de Virtualização, os diferentes servidores podem ser servidores virtuais, em cima de um único servidor físico de grande capacidade, sem nenhum problema. Para os desenvolvedores e para os usuários, tudo transcorre de maneira transparente.

Questões a Considerarmos nos Modelos de 3 ou Mais Camadas:

Muitas são as vantagens dos modelos de 3 ou mais camadas, em relação a facilidade de gerenciamento e atualização das aplicações. Porém considerações devem ser feitas em relação a desempenho e dimensionamento dos equipamentos que atuarão como servidores.

A partir do momento em que estamos deslocando funcionalidades (tipicamente lógica e apresentação), do cliente para um ou mais servidores, também estamos deslocando a necessidade de capacidade de processamento em termos de memória RAM, processador, acesso a disco, interface de rede e outros. Funções que antes eram executadas pelos clientes, utilizando memória e processador da estação cliente, agora foram deslocadas para os servidores, com isso consumindo memória e processador do servidor. Um dos fatores-chave para o sucesso deste modelo é o correto dimensionamento dos equipamentos servidores.

Para fazer o dimensionamento dos servidores, precisamos ter uma estimativa do número de usuários que irão acessar a aplicação simultaneamente,  o nível de exigência de cada usuário, os recursos necessários pelos softwares do servidor, dentre outros. Para determinar o nível de recursos necessários em cada um dos servidores, você precisa fazer um estudo bem detalhado, de tal forma que o servidor não fique sub-dimensionado. Quando o servidor não está corretamente dimensionado, a tendência é que o acesso à aplicação fique bastante lento, o que causa insatisfação entre os usuários.