Introdução ao Modelo Multicamadas

Este artigo apresenta os conceitos envolvidos na tecnologia de multicamadas, bem como os elementos necessários para a composição de um ambiente baseado neste método e suas características.

Guia do artigo:

• Modelo de uma camada
• Modelo de duas camadas
• Modelo multicamadas
• Apresentação
• Regras de negócios
• Banco de dados
• Vantagens do desenvolvimento em multicamadas
• Modularização
• Facilidade de redistribuição
• Clientes leves
• Economia de licenças de acesso ao banco de dados
• Economia de conexões no servidor
• Escalabilidade
• Independência de localização
• Independência de linguagem de programação
• Independência de sistema gerenciador de banco de dados

Inicialmente é feito uma explanação sobre o histórico e evolução dos sistemas distribuídos, bem como o funcionamento básico do modelo de uma camada, a técnica de duas camadas e finalmente o modelo multicamadas.

Além disso, é abordado um comparativo de multicamadas em relação a duas camadas, apontando os benefícios que um sistema utilizando este modelo pode trazer.

Modelo de uma camada

Também chamado de sistemas centralizados ou de arquitetura uni processada, o modelo de uma camada era caracterizado por manter todos os recursos do sistema (banco de dados, regras de negócios e interfaces de usuário) em computadores de grande porte, os conhecidos mainframes. Os terminais clientes não possuíam recursos de armazenamento ou processamento, sendo conhecidos como terminais burros ou mudos. Nesta arquitetura, o mainframe tinha a responsabilidade de realizar todas as tarefas e processamento.

Modelo de duas camadas

Com o passar do tempo e com o surgimento dos computadores pessoais, cada vez mais microcomputadores estavam disponíveis nas mesas dos usuários, fato que foi tornando necessária a utilização do poder de processamento destas máquinas dentro do sistema. Também devido à grande expansão das redes de computadores, os métodos de desenvolvimento de software foram aos poucos evoluindo para uma arquitetura descentralizada, na qual não somente o servidor é o responsável pelo processamento, mas as estações clientes também assumem parte desta tarefa.

Dentro deste contexto que surgiu o modelo de duas camadas, justamente com o objetivo de dividir a carga de processamento entre o servidor e as máquinas clientes.

Igualmente conhecido como modelo cliente e servidor de duas camadas, esta técnica é composta por duas partes distintas: uma executada na estação cliente e outra no servidor.

A camada cliente tem a função de prover a interface para que os usuários possam manipular as informações, ou seja, através dela realiza-se a interação entre o usuário e o sistema. É desenvolvida para se conectar diretamente ao banco de dados, tendo como responsabilidade fazer as solicitações dos dados necessários ao servidor, sendo que este os processa e devolve o resultado.

Neste modelo, as regras de negócios (tais como funções, validações entre outros) podem ficar armazenadas no cliente, no servidor ou em ambos. Quando contidas no cliente, apresentam-se na forma de códigos da linguagem de programação que está sendo utilizada. Já quando localizadas no servidor, estão na forma de recursos do banco de dados, como triggers e stored procedures, por exemplo. O cliente recebe a denominação de “cliente gordo” quando a maior parte das regras são nele implementadas, enquanto que o servidor recebe a qualificação de “servidor gordo” quando as regras são nele desenvolvidas em maior número.

Em suma, a base do funcionamento desta técnica consiste em armazenar determinado volume de dados em um computador central e deixa-lo encarregado de manipulá-los e devolve-los à estação cliente que os requisitou. A Figura 1 mostra a arquitetura de duas camadas.

Como se pode observar na figura, existem três estações clientes que fazem as requisições diretamente ao servidor de banco de dados

Modelo multicamadas

Também conhecido como modelo cliente e servidor de várias camadas, este método é uma evolução da tecnologia de duas camadas e tem como princípio básico o fato de que a estação cliente jamais realiza comunicação direta com o servidor de banco de dados, mas sim com uma camada intermediária, e esta, com o banco de dados. Isto proporciona uma série de vantagens sobre a técnica de duas camadas, as quais serão explanadas adiante.

Um sistema multicamadas faz uso de objetos distribuídos aliados à utilização de interfaces para executar seus procedimentos, o que torna o sistema independente de localização, podendo estar tanto na mesma máquina como em máquinas separadas. Desta forma, a aplicação pode ser dividida em várias partes, cada uma bem definida, com suas características e responsável por determinadas funções. Em um aplicativo nestes moldes, pelo menos três camadas são necessárias: apresentação, regras de negócios e banco de dados.

A seguir, cada uma das partes do modelo é explicada.

Apresentação

A camada de apresentação fica fisicamente localizada na estação cliente e é responsável por fazer a interação do usuário com o sistema. É uma camada bastante leve, que basicamente executa os tratamentos de telas e campos e geralmente acessa somente a segunda camada, a qual faz as requisições ao banco de dados e devolve o resultado. É também conhecida como cliente, regras de interface de usuário ou camada de interface.

Regras de negócios

Em um sistema seguindo este modelo, a aplicação cliente nunca acessa diretamente a última camada que é a do banco de dados, pois quem tem essa função é a camada de regras de negócios, na qual podem se conectar diversas aplicações clientes.

Esta parte do sistema é responsável por fazer as requisições ao banco de dados e todo o seu tratamento, ou seja, somente ela que tem acesso direto ao banco de dados. É também conhecida como lógica de negócios, camada de acesso a dados, camada intermediária ou servidor de aplicação por geralmente se tratar de um outro computador destinado somente ao processamento das regras. O servidor de aplicação é, geralmente, uma máquina dedicada e com elevados recursos de hardware, uma vez que é nele que ficam armazenados os métodos remotos (regras de negócios) e é realizado todo o seu tratamento e processamento.

Banco de dados

É a última divisão do modelo, na qual fica localizado o sistema gerenciador de banco de dados. É também conhecida como camada de dados.

Adicionalmente a essas três divisões, também pode ser implementada uma camada somente para validação, na qual são executados todos os procedimentos necessários para garantira integridade dos dados digitados na camada de apresentação.

A Figura 2 ilustra o esquema de comunicação de um sistema multicamadas.

Na figura, na porção superior está localizado o servidor de banco de dados, o qual se comunica com os servidores de aplicação através de algum protocolo de rede (TCP/IP, por exemplo) e o acesso aos dados é realizado por meio da linguagem SQL (Structured Query Language). Na parte inferior estão as estações clientes, que fazem a comunicação com a camada intermediária através da utilização de interfaces. Este é basicamente o esquema de comunicação desta arquitetura e o mesmo não pode ser alterado.

Ainda pode-se observar na figura anterior que também é possível haver a interação entre os servidores de aplicação. Com isso é possível obter o recurso de escalabilidade que será detalhado adiante.

Outro recurso que pode ser utilizado e não está representado na figura é uma estação cliente, que possui melhores recursos de hardware, agir tanto como cliente quanto como servidor de aplicação. Este fato é plausível desde que a máquina possua os protocolos necessários para realizar tal função.

Vantagens do desenvolvimento em multicamadas

Uma aplicação desenvolvida neste modelo apresenta várias vantagens sobre a técnica de duas camadas, dentre elas pode-se destacar a modularização, a facilidade de redistribuição, os clientes leves, a economia de licenças de acesso ao banco de dados, a economia de conexões no servidor, a escalabilidade e a independência de localização, de linguagem de programação e de sistema gerenciador de banco de dados. A seguir será detalhado cada um desses benefícios.

Modularização

A modularização refere-se a separara lógica do negócio e regras de acesso ao banco de dados da camada de apresentação. Desta maneira, várias aplicações clientes podem compartilhar as mesmas regras, que ficam encapsuladas em uma camada de acesso comum.Assim sendo, as regras ficam centralizadas em um único local, ao contrário de em uma aplicação desenvolvida em duas camadas; na qual geralmente existe redundância nestas regras e uma mudança mesmo que pequena acarretará na redistribuição do aplicativo em cada estação cliente.

Um exemplo prático deste fato é a construção de um simples cadastro de clientes que deve ser disponibilizado com uma interface padrão baseada em formulários e outra baseada em um browser para acesso pela Internet. No modelo de duas camadas, se determinada validação for implementada na aplicação feita com formulários, esta deverá ser recodificada na outra aplicação justamente por não estar centralizada. Neste exemplo, a camada de regras de negócios poderia executar o papel de centralizadora, atendendo as duas situações descritas e solucionando a questão.

Outro problema comum que pode ocorrer é no controle de versão, pois se determinado usuário possui uma versão mais antiga do que outro, ocorrerá erros de dados lógicos no processamento das regras de negócios.

Facilidade de redistribuição

Como as estações clientes acessam uma mesma camada em comum, qualquer alteração realizada nas regras de negócios (geralmente um EXE ou uma DLL no servidor de aplicação) será vista por todas as aplicações clientes.

Clientes leves (thin-clients)

Ao contrário de em uma aplicação duas camadas na qual há a divisão das regras de negócios entre o cliente e o servidor, em multicamadas isto não ocorre, pois como a camada intermediária é a responsável por fazer todo o processamento das solicitações de dados no servidor de banco de dados, cabe à camada de apresentação somente exibir estes dados, tendo no máximo os códigos de tratamento de telas e campos.

Com isso, a aplicação cliente apresenta grande diminuição de código e todo o trabalho de instalação é bastante reduzido, possuindo somente uma configuração para o cliente ter acesso à camada intermediária. Por esta razão, há diminuição de custos, uma vez que não existe necessidade de fazer upgrade nas estações clientes que apresentam poucos recursos de hardware ou que são computadores antigos.

Economia de licenças de acesso ao banco de dados

Em um modelo construído em duas camadas, a estação cliente faz acesso direto ao servidor de banco de dados através de um conjunto de bibliotecas que ficam localizadas no computador cliente e que têm a função de viabilizar a comunicação entre ambos. Visto que muitos fabricantes de sistemas gerenciadores de banco de dados cobram taxas por licenças adicionais para utilização dessas bibliotecas, com o modelo multicamadas elas ficam localizadas somente na camada de acesso a dados, eliminando assim custos extras com licenças.

Economia de conexões no servidor

No modelo de duas camadas, se existirem, por exemplo, quinhentas estações clientes conectadas simultaneamente no servidor, o mesmo número de conexões no banco de dados serão realizadas, uma para cada cliente. Numa arquitetura multicamadas isso não ocorre, porque se uma conexão for realizada pelo servidor de aplicação, está será compartilhada por todas as máquinas que nele se conectarem.

Através desta característica,é possível solucionar eventuais problemas com o número de conexões no banco de dados desejadas maior que a quantidade de licenças de acesso disponíveis.

Escalabilidade

Com a utilização do modelo de duas camadas, é comum que ocorra uma queda de desempenho quando um grande número de máquinas clientes simultâneas se conecta ao servidor. Este fato é conhecido como gargalo de rede e mesmo que o servidor seja um computador potente e localizado em uma rede veloz, pode ocorrer o problema de gargalo de I/O (Input/Output) na máquina servidora.

Com o modelo multicamadas este problema pode ser evitado, uma vez que é possível ter a mesma regra de negócio dividida entre vários servidores através do balanceamento de carga, ou seja, quando algum deles ficar sobrecarregado o outro entra em ação para ajudá-lo. Se ocorrer algum problema com algum servidor e este não puder mais responder as requisições (ficar off-line, por exemplo), outro servidor poderá entrar em seu lugar.

Pode-se observar na figura anterior que existem dois servidores de aplicação com as regras de negócios do módulo de compras. Através disso, se um deles estiver sobrecarregado ou ficar desconectado, o outro entrará em ação como descrito anteriormente. Outra característica importante é que se o sistema for de grande porte, pode-se dividi-lo em vários servidores de aplicação, um para cada setor como mostrado na figura (vendas e compras), evitando assim o gargalo na rede e melhorando o desempenho.

Independência de localização

Visto que esta arquitetura utiliza objetos distribuídos, o servidor de banco de dados e o servidor de aplicação podem estar fisicamente distantes da aplicação cliente. Se alguma empresa, por exemplo, possuir cinco filiais geograficamente distribuídas, todas podem acessar o mesmo servidor de aplicação.

Independência de linguagem de programação

Como são utilizadas interfaces na construção da arquitetura, uma camada de regras de negócios construída sobre o protocolo COM, por exemplo, pode ser acessada por aplicações clientes desenvolvidas em diversas linguagens de programação que possuem suporte ao COM.

Independência de sistema gerenciador de banco de dados

Numa arquitetura multicamadas, o banco de dados é utilizado somente como um contêiner para armazenar as tabelas e dados, pois quando recursos como triggers e stored procedures são implementados, ocorre uma ligação direta da aplicação com o banco de dados, fato que pode tornar bastante trabalhoso o processo de migração no caso da aplicação mudar de banco de dados. Isto ocorre porque cada solução possui suas particularidades, ou seja, a construção de uma trigger ou stored procedure em determinada ferramenta geralmente será diferente de outra. Por isso, em sistemas multicamadas deve-se evitar usar tais recursos, deixando o servidor de aplicação encarregado deste controle.

Aplicações multicamadas podem ser utilizadas normalmente como um substituto do habitual modelo de duas camadas, pois como observado anteriormente, apresenta vantagens bastante significativas, principalmente no que diz respeito à organização, manutenção, custos, desempenho e portabilidade.

Se, por exemplo, determinada aplicação desenvolvida em duas camadas apresentar problemas relacionados à dispersão das regras de negócios entre cliente e servidor, à dificuldade de redistribuição do aplicativo nas estações clientes, à problemas em migrar de banco de dados devido às regras estarem armazenadas em formas de stored procedures ou triggers, e, principalmente, à queda de desempenho por causa do gargalo na rede; são fortes indícios de que a aplicação deve ser mudada para o modelo multicamadas, pois este, como visto anteriormente, possui recursos adequados para resolver os problemas supracitados e ainda, oferecer outras facilidades.

O desenvolvimento através do modelo multicamadas vem crescendo constantemente, sendo que seu uso é mais comumente indicado para sistemas complexos e de grande porte, que requerem grande volume de dados, alto grau de processamento, grande quantidade de usuários conectados simultaneamente e utilização em ambientes heterogêneos.

Confira também

Levantamento de requisitos

Curso

Cursos de Engenharia de Software

Cursos

Padrões de Projeto

Guia