Universidade Católica De Moçambique

Faculdade de Gestão De Turismo e Informática

Desenho e Implementação de Aplicações Corpotativas

Evolução da Arquitectura de Aplicaçoes Corporativas

Modelo de Aplicações com Multiplas Camadas ( Multi Tier Application Model)

Pemba, Maio de 2022

 Universidade Católica De Moçambique

Faculdade de Gestão De Turismo e Informática

Augusta Bela Rai - No 706200212

Focas de Manuel Justo - No 706200009
Horacio Luís Mauca - No 706200050
Irene Yahaia Abibo – No 706190083
Wacate Infalume - No 706200063

Curso: Licenciatura em Tecnologia de

Informação

Ano Curricular: 3o

Disciplina: DIAC

Docente: Celso de Sousa

Pemba, Maio de 2022

Indic
e
1. Introdução.......................................................................................................................3
1.1 Contextualização..........................................................................................................3
1.2 Problematização...........................................................................................................3
1.3 Objectivos........................................................................................................................3
1.3.1 Gerais.........................................................................................................................3
1.4.2 Especificos.................................................................................................................4
2. Evolução da Arquitetura de aplicações corporativas.........................................................5
a) Contexto histórico.......................................................................................................5
b) Arquitetura Monolítica...............................................................................................8
Vantagens...........................................................................................................................9
Desvantagens......................................................................................................................9
c) Arquitetura cliente-servidor.......................................................................................9
Vantagem........................................................................................................................9
Desvantagens................................................................................................................10
d) Arquiteturas Distribuídas..........................................................................................10
Como são configurados os componentes lógicos e físicos?.................................................11
3.1 Estilos de Arquitetura.................................................................................................11
3.2 Como os componentes são distribuídos.....................................................................12
3.3 Arquiteturas centralizadas..........................................................................................12
3.4 Divisão de Responsabilidades....................................................................................12
3.4.1 Cliente Magro......................................................................................................12
3.4.2 Cliente Gordo.......................................................................................................12
4. Evolução das arquiteturas................................................................................................12
4.1 Primeira camada:........................................................................................................12
4.2 Segunda camadas:......................................................................................................13
5. Terceira camadas:.............................................................................................................13
5.1 N camadas :................................................................................................................13
5.2 Modelo multicamadas................................................................................................14
5.3 Apresentação (View)..................................................................................................14
5.4 Regras de negócios (Control).....................................................................................15
5.5 Banco de dados (Model).............................................................................................15

1
6. Vantagens do desenvolvimento em multicamadas..........................................................15
6.1 Modularização............................................................................................................16
6.2 Facilidade de redistribuição........................................................................................16
6.3 Clientes leves (thin-clients)........................................................................................16
6.4 Economia de licenças de acesso ao banco de dados...................................................17
6.5 Economia de conexões no servidor............................................................................17
6.6 Escalabilidade.............................................................................................................17
6.7 Independência de localização.....................................................................................18
6.8 Independência de linguagem de programação...........................................................18
6.9 Independência de sistema gerenciador de banco de dados.........................................18
7. Conclusão.........................................................................................................................20
8. Bibliografia......................................................................................................................21

2
 1. Introdução
O presente trabalho da cadeira de desenho e implementação de aplicações corporativas tem
como tema Evolucao da arquitetura de aplicações corporativas, assim como é sabido que a
arquitetura da aplicação define a articulação lógica dos componentes e serviços em
software sem estabelecer uma escolha definitiva sobre a maneira de aplicação.

As abordagens existentes ao desenvolvimento de software têm vindo a alterar-se ao longo

dos anos. Verifica-se a necessidade de assegurar uma crescente adaptação à exigência do
mercado das tecnologias de informação e a cada vez mais exigentes padrões de qualidade
do processo e ciclo de desenvolvimento. As empresas pretendem assegurar uma resposta
adequada aos requisitos dos seus clientes, com elevados níveis de usabilidade, fiabilidade,
desempenho e suporte dos produtos de software que desenvolvem, ao mesmo tempo que
agilizam os processos e o desempenho das equipas de desenvolvimento.

1.1 Contextualização

Desde a década de 1970, as pessoas que trabalham em SI / TI têm procurado maneiras de

envolver os empresários - para habilitar funções e processos de negócios - e para
influenciar o investimento em sistemas e tecnologias de informação de negócios - com
vista aos benefícios amplos e de longo prazo da empresa.

1.2 Problematização

Partindo do que é observado nas instituições, e levando em consideração a excessiva

utilização de recursos tecnológicos na construção do mundo profissional e a integração dos
serviços para um sistemas computacional , a presente pesquisa reúne vários exemplos de
arquiteturas de aplicações corporativas, coletados no intuito de responder ao problema de
pesquisa: Quais são as arquiteturas de aplicações corporativas e os seus componentes ?

1.3 Objectivos
1.3.1 Gerais

 Abordar da evolução da arquitetura de aplicações corporativas

3
  Desbruçar do modelo de aplicações com múltiplas camadas (Multi Tier Application
Model)

1.4.2 Especificos
 Contexto histórico
 Arquitetura Monolíticas, Arquiteturas Cliente servidor, Arquiteturas distribuídas
 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.

4
2. Evolução da Arquitetura de aplicações corporativas
a) Contexto histórico

Com as necessidades por cima contextualizadas, levou com que em 1980, o Business
Systems Planning (BSP) da IBM ser promovido como um método para analisar e projetar a
arquitetura de informações de uma organização, com os seguintes objetivos:

1. Entender os problemas e oportunidades com os aplicativos atuais e arquitetura

técnica;
2. Desenvolver um estado futuro e um caminho de migração para a tecnologia que
apóia a empresa;
3. fornecer aos executivos de negócios uma estrutura de direção e tomada de decisão
para despesas de capital de TI;

4. fornecer ao sistema de informação (SI) um plano de desenvolvimento.

Em 1982, quando trabalhava para a IBM e com a BSP, John Zachman delineou sua
estrutura para "Arquitetura de Sistemas de Informação" de nível empresarial. Na época e
em artigos posteriores, Zachman usou a palavra empresa como sinônimo de negócios.
"Embora muitas metodologias populares de planejamento de sistemas de informação,
abordagens de design e várias ferramentas e técnicas não excluam ou não sejam
inconsistentes com a análise de nível empresarial, poucas delas abordam explicitamente ou
tentam definir arquiteturas empresariais."

Em 1987, John Zachman, que era um especialista em marketing da IBM, publicou o artigo,
A Framework for Information Systems Architecture .

O artigo forneceu um esquema de classificação para artefatos que descrevem (em vários
níveis de abstração) o quê, como, onde, quem, quando e por quê dos sistemas de
informação. Como a IBM já empregava o BSP, a Zachman não precisava fornecer um
processo de planejamento. O artigo não menciona a arquitetura corporativa.

Em 1989, o Instituto Nacional de Padrões e Tecnologia (NIST) publicou o NIST Enterprise

Architecture Model . Este era um modelo de referência de cinco camadas que ilustrava a
inter-relação dos domínios de negócios, sistema de informação e tecnologia.

5
Em 1990, o termo "Arquitetura Corporativa" foi formalmente definido pela primeira vez
como uma arquitetura que "define e inter-relaciona dados, hardware, software e recursos
de comunicação, bem como a organização de suporte necessária para manter a estrutura
física geral exigida pelo arquitetura".

Em 1992, um artigo de Zachman e Sowa começou assim "John Zachman introduziu uma
estrutura para arquitetura de sistemas de informação (ISA) que foi amplamente adotada por
analistas de sistemas e designers de banco de dados." O termo arquitetura corporativa não
apareceu. O artigo tratava do uso da estrutura ISA para descrever “ o sistema geral de
informações e como ele se relaciona com a empresa e seu ambiente circundante”. A
palavra empresa foi usada como sinônimo de negócio.

Em 1993, o livro de Stephen Spewak Enterprise Architecture Planning (EAP) definiu um

processo para definir arquiteturas para o uso de informações em apoio ao negócio e o plano
para implementar essas arquiteturas. A missão empresarial é o principal motivador. Em
seguida, os dados necessários para cumprir a missão.

O Planejamento de Arquitetura Corporativa é uma abordagem centrada em dados para o

planejamento de arquitetura. O objetivo é melhorar a qualidade dos dados, o acesso aos
dados, a adaptabilidade às mudanças de requisitos, a interoperabilidade e o
compartilhamento de dados e a contenção de custos. O EAP tem suas raízes no Business
Systems Planning (BSP) da IBM.

Em 1994, o Open Group selecionou o TAFIM do DoD dos EUA como base para o
desenvolvimento do TOGAF, onde arquitetura significava arquitetura de TI. Portanto,
surgiu o desejo de racionalizar um estado de TI confuso. Até a versão 7, o TOGAF ainda
estava focado em definir e usar um Modelo de Referência Técnica (ou arquitetura de base)
para definir os serviços de plataforma exigidos das tecnologias que uma empresa inteira
usa para dar suporte a aplicativos de negócios.

Em 1996, a Lei de Reforma do Gerenciamento de TI dos EUA , mais comumente

conhecida como Ato Clinger-Cohen , determinou repetidamente que o investimento de
uma agência do governo federal dos EUA em TI deve ser mapeado para benefícios
comerciais identificáveis. Além disso, tornou-se o CIO da agência responsável por “...

6
desenvolver, manter e facilitar a implementação de uma arquitetura de TI sólida e
integrada para a agência executiva”.

Em 1997, Zachman renomeou e redirecionou sua estrutura ISA como uma estrutura EA;
permaneceu um esquema de classificação para artefatos descritivos, não um processo para
sistemas de planejamento ou mudanças em sistemas.

Em 1998, o Conselho Federal de CIOs começou a desenvolver o Federal Enterprise

Architecture Framework (FEAF) de acordo com as prioridades enunciadas em Clinger-
Cohen e emitido em 1999. FEAF era um processo muito semelhante ao ADM do TOGAF,
no qual “A equipe de arquitetura gera um plano de sequenciamento para a transição de
sistemas, aplicativos e práticas de negócios associadas com base em uma análise de lacuna
detalhada [entre as arquiteturas de linha de base e de destino]. ”

Em 2001, o conselho CIO dos Estados Unidos publicou um guia prático para a
arquitetura empresarial federal , que começa, “Uma arquitetura corporativa (EA)
estabelece o roteiro de toda a agência para cumprir a missão de uma agência por meio do
desempenho ideal de seus processos de negócios centrais com informações eficientes
ambiente de tecnologia (TI). "Nesse ponto, os processos em TOGAF, FEAF, EAP e BSP
estavam claramente relacionados.

Em 2002/3, em sua Enterprise Edition , o TOGAF 8 mudou o foco da camada de

arquitetura de tecnologia para as camadas superiores de negócios, dados e aplicativos. Ele
introduziu a análise estruturada, após a engenharia de tecnologia da informação , que
apresenta, por exemplo, mapeamento de unidades organizacionais para funções de
negócios e entidades de dados para funções de negócios. Hoje, as funções de negócios são
frequentemente chamadas de capacidades de negócios. E muitos arquitetos corporativos
consideram sua função de negócios / hierarquia / mapa de capacidade como o artefato
fundamental da Arquitetura Corporativa. Eles relacionam entidades de dados, casos de uso,
aplicativos e tecnologias às funções / capacidades.

Em 2006, o popular livro Enterprise Architecture As Strategy relatou os resultados do

trabalho do Center for Information System Research do MIT. Este livro enfatiza a

7
necessidade dos arquitetos corporativos se concentrarem nos principais processos de
negócios ("As empresas se destacam porque [decidiram] quais processos devem executar
bem e implementaram os sistemas de TI para digitalizar esses processos") e envolver os
gerentes de negócios. com os benefícios que a integração e / ou padronização de processos
interorganizacionais estratégicos podem fornecer.

Um projeto de pesquisa de 2008 para o desenvolvimento de certificados profissionais em

arquitetura empresarial e de soluções pela British Computer Society (BCS) mostrou que a
arquitetura empresarial sempre foi indissociável da arquitetura de sistemas de informação,
o que é natural, uma vez que os empresários precisam de informação para tomar decisões e
transportar nossos processos de negócios. [9]

Em 2011, o TOGAF 9.1. a especificação diz: "O planejamento de negócios no nível de

estratégia fornece a direção inicial para a arquitetura corporativa." Normalmente, os
princípios de negócios, objetivos de negócios e direcionadores estratégicos da organização
são definidos em outro lugar.

Em outras palavras, a Arquitetura Corporativa não é uma estratégia de negócios,

planejamento ou metodologia de gerenciamento. A Arquitetura Corporativa se esforça para
alinhar a tecnologia de sistemas de informações de negócios com a estratégia, objetivos e
motivadores de negócios dados. A especificação TOGAF 9.1 esclareceu que, "Uma
descrição completa da arquitetura corporativa deve conter todos os quatro domínios da
arquitetura (negócios, dados, aplicativos, tecnologia), mas as realidades de recursos e
restrições de tempo muitas vezes significam que não há tempo, financiamento ou recursos
suficientes para construir uma descrição de arquitetura abrangente, de cima para baixo,
abrangendo todos os quatro domínios de arquitetura, mesmo se o escopo da empresa for
menor do que a extensão total da empresa como um todo. "

Em 2013, TOGAF é o framework de Arquitetura mais popular (julgado pelos números de

certificação publicados) que alguns assumem que define EA. No entanto, alguns ainda
usam o termo Arquitetura Corporativa como sinônimo de Arquitetura de Negócios, ao
invés de cobrir todos os quatro domínios da arquitetura - negócios, dados, aplicativos e
tecnologia.

8
b) Arquitetura Monolítica

Arquitetura Monolítica é um sistema único, não dividido, que roda em um único processo,
uma aplicação de software em que diferentes componentes estão ligados a um único
programa dentro de uma única plataforma.

Vantagens

● Mais simples de desenvolver: a organização fica concentrada em um único sistema;

● Simples de testar: é possível testar a aplicação de ponta a ponta em um único lugar;
● Simples de fazer o deploy para o servidor: a alteração é simplesmente feita e
pronto;
● Simples de escalar: como é só uma aplicação, se for preciso adicionar mais itens, é
simplesmente ir adicionando o que for necessário.
Desvantagens

● Manutenção: a aplicação se torna cada vez maior de acordo com o seu tamanho, o
código será cada vez mais difícil de entender e o desafio de fazer alterações rápidas
e ter que subir para o servidor só cresce;
● Alterações: para cada alteração feita, é necessário realizar um novo deploy de toda
a aplicação;
● Linha de código: uma linha de código que subiu errada pode quebrar todo o sistema
e ele ficar totalmente inoperante;
● Linguagens de programação: não há flexibilidade em linguagens de programação.
Aquela que for escolhida no início do projeto terá que ser seguida, sempre. Se o
desenvolvimento de uma nova funcionalidade exigir outra linguagem de
programação, existem duas possibilidades: ou todo o código é alterado ou a
arquitetura do sistema precisará ser trocada.
c) Arquitetura cliente-servidor

Refere-se a uma estrutura de aplicação distribuída que distribui as tarefas e cargas de

trabalho entre os fornecedores de um recurso ou serviço, designados como servidores, e os
requerentes dos serviços, designados como clientes.

Vantagem

● Na maioria dos casos, a arquitetura cliente-servidor permite que os papéis e

responsabilidades de um sistema de computação possam ser distribuídos entre
9
 vários computadores independentes que são conhecidos por si só através de uma
rede. Isso cria uma vantagem adicional para essa arquitetura: maior facilidade de
manutenção. Por exemplo, é possível substituir, reparar, atualizar ou mesmo
realocar um servidor de seus clientes, enquanto continuam a ser a consciência e não
afetado por essa mudança;
● Todos os dados são armazenados nos servidores, que geralmente possuem controles
de segurança muito maiores do que a maioria dos clientes.
● Os servidores podem controlar melhor o acesso a recursos, para garantir que apenas
os clientes com credenciais válidas possam aceder e alterar os dados;
● Como o armazenamento de dados é centralizado, as atualizações dos dados são
muito mais fáceis de administrar em comparação com o paradigma P2P.
● Funciona com vários clientes diferentes de capacidades diferentes.
Desvantagens

● Clientes podem solicitar serviços, mas não podem oferecê-los para outros clientes,
sobrecarregando o servidor, pois quanto mais clientes, mais informações que irão
demandar mais banda.
● Um servidor poderá ficar sobrecarregado caso receba mais solicitações simultâneas
dos clientes do que pode suportar.
● Este modelo não possui a robustez de uma rede baseada em P2P. Na arquitetura
cliente-servidor, se um servidor crítico falha, os pedidos dos clientes não poderão
ser cumpridos.

d) Arquiteturas Distribuídas

Segundo (Nuno Preguiça e Sérgio Duarte, pag 04 ), a palavra Arquitetura significa a

arte de edificar. É a estrutura de um sistema, que consiste de componentes de software,
das propriedades externamente visíveis desses componentes e dos relacionamentos
entre estes componentes ( forma de comunicação ).

A arquitetura pode envolver a arquitetura do software e a arquitetura do sistema. São

conceitos diferentes:

● A arquitetura do software cuida da estrutura e organização dos componentes

lógicos ( serviços, páginas, scripts, etc. )

10
 ● A arquitetura do sistema cuida da estrutura e organização dos componentes físicos (
servidores, roteadores, terminais, etc. )

Apesar de serem conceitos diferentes existe uma relação entre eles.

Ocorre que a arquitetura do sistema vai sempre depender da arquitetura do software.

Cada componente é uma unidade modular ( hardware ou software ) com interfaces

requeridas e fornecidas bem definidas que é substituível dentro do seu ambiente. Os
componentes geralmente implementam uma das três funções abaixo em um sistema
distribuído:

● Processamento - Oferecem as funcionalidades ou serviços do sistema distribuído

( comportamento);
● Estado - Mantém informação ou dados do sistema distribuído;
● Interação - Realizam a interconexão com os demais componentes, possibilitando a
comunicação entre eles. Também cuidam da coordenação e mediação da interação
entre os componentes.

Como são configurados os componentes lógicos e físicos?

Os componentes são configurados em conjunto para formar a arquitetura do sistema.
Existem basicamente componentes e conectores.

Os componentes são os elementos modulares que integram o sistema de software.

Os conectores são os elementos que estabelecem a comunicação entre os componentes

dentro da arquitetura.

3.1 Estilos de Arquitetura

A forma como os componentes são configurados é definida como sendo o estilo

arquitetural do sistema.

Vejamos alguns desses estilos:

11
 ● Arquitetura de Objetos
● Arquitetura cliente-servidor
● Arquitetura em Camadas

3.2 Como os componentes são distribuídos

Em geral existem, 3 abordagens:

● Arquiteturas centralizadas
● Arquiteturas híbridas
● Arquiteturas descentralizadas

3.3 Arquiteturas centralizadas

São comumente referidas como cliente servidor, onde vários clientes solicitam serviços a
um servidor. Claro que um servidor pode ser cliente de um outro servidor que ofereça um
serviço.

3.4 Divisão de Responsabilidades

Como os componentes são distribuídos, como decidir o que fica no cliente e o que fica no
servidor?

3.4.1 Cliente Magro - Maior segurança pois a regra de negócio fica no servidor, ficando o
cliente magro responsável apenas pela apresentação dos dados.

3.4.2 Cliente Gordo - Maior responsividade na interface com o usuário

4. Evolução das arquiteturas

4.1 Primeira camada:

a) Vantagens : Todo o processamento centralizado no mainframe ( apresentação, lógica

de negócio, persistência de dados);

12
b) Desvantagens: Terminais burros apenas apresentavam os dados.

4.2 Segunda camadas:

a)Vantagens

● Também conhecida como cliente servidor. Surgiu nos anos 90. Composta pela
camada cliente e a camada servidor;
● Algum processamento local aproveitando capacidade dos PC:
● Melhor interface com o usuário;
● Libera o servidor de validação de entrada de dados e outros processamentos que
podem ser feitos no cliente.

a) Desvantagens

● Enormes problemas de atualização e manutenção da camada cliente;

● Escalabilidade limitada;
● Cada cliente com uma conexão com o servidor

5. Terceira camadas:
Composta pela camada de apresentação, camada de lógica de negócio e camada de dados.
Muito flexível podemos trocar uma camada sem afetar a outra camada. Problemas de
atualização e manutenção da camada cliente são reduzidos drasticamente. Aumento da
escalabilidade e confiabilidade.

5.1 N camadas : Composta por várias camadas que são conectadas via protocolos da web (
http, shttp, soap, RMI, etc. ).

a) Vantagens

● Melhor modularização da aplicação com camadas com responsabilidades bem

definidas;

13
 ● Compartilhamento de serviços e reaproveitamento de codigo ( SOA )

b) Desvantagens

● Maior complexidade de implementação (tolerância a falhas, transações distribuídas,

pool de conexões de banco de dados, balanceamento de carga);
● Maior esforço para administração do ambiente ( aplicação, banco de dados, etc. );
● Maior flexibilidade possível;
● Alto custo com infraestrutura

Em geral, sistemas distribuídos são altamente complexos.

5.2 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.

5.3 Apresentação (View)

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
14
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.

5.4 Regras de negócios (Control)

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.

5.5 Banco de dados (Model)

É 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.

6. 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
15
programação e de sistema gerenciador de banco de dados. A seguir será detalhado cada um
desses benefícios.

6.1 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.

6.2 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.

6.3 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.

16
6.4 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.

6.5 Economia de conexões no servidor

No modelo de duas camadas, se existirem, por exemplo, quinhentas estações clientes

conectadas simultaneamente no servidor, os mesmos números de conexões no banco de
dados serão realizados, 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.

6.6 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á-

17
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.

6.7 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.

6.8 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.

6.9 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á

18
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.

19
7. Conclusão
Com as investigações feitas em relação ao tema da Evolucao da arquitetura de aplicações
corporativas constatou-se que Uma das características da nova geração do milénio (Keith
H & Václav T, 2000) é ser constituída por novos consumidores informados e que exigem
cada vez mais produtos de software entregues em tempos cada vez menores, com mais
funcionalidades e maior qualidade a nível de construção e apresentação. Por essa razão, a
quantidade de produtos de software disponibilizada nos últimos anos tem crescido
consideravelmente. Com esse aumento, tornase necessária uma maior exigência na
qualidade das aplicações e no cuidado na escolha da arquitetura.

Quando as aplicações são desenvolvidas para utilização empresarial, têm particularidades

de negócio que podem variar de empresa para empresa (Ouyang, et al., 2009). A nível
organizacional, para que um software tenha sucesso é necessário que dê resposta às
necessidades reais dos utilizadores, retornando informação útil de negócio em tempo útil e
com qualidades

20
8. Bibliografia

Zachman Framework - uma estrutura de arquitetura, baseada no trabalho de John Zachman

na IBM na década de 1980

O Conselho de oficiais da informação principal (1999). Federal Enterprise Architecture

Framework Versão 1.1 Arquivado em 2012-02-13 na Wayback Machine . Setembro de
1999.

TOGAF Versão 9 do Open Group (2008). Van Haren Publishing, 1 de novembro. 2008.p.
73

RODRIGUES, Anderson Haertel. Sistemas Multicamadas com Delphi DataSnap e

dbExpress. Florianópolis: Visual Books, 2002.

BHERING, Luiz Fernando Campos. Mini-curso Multicamadas. Revista Active Delphi.

São Paulo, n.17, p.20-21, 2005.

21