|
Usuários |
|
74 Usuários Online
|
|
[Artigos]
Desvendando a programação "Client/Server" |
Publicado por Admin : Quinta, Dezembro 19, 2002 - 05:07 GMT-3 (12943 leituras)
 5 Comentários  Enviar para um amigo  Versão para impressão
|
O que é "Client/server"
A filosofia cliente/servidor nasceu do conceito de processamento distribuído, originalmente idealizados pelos desenvolvedores de sistemas operacionais de rede. É aquele tipo de invenção que começa direcionada para aplicações complexas, e um dia acaba vindo parar em nossas mãos, como a suspensão ativa e o telefone celular.
Mas a idéia é muito simples. Você
tem que envelopar 1.000 cartas, depois colá-las e pedir a
um ajudante que as leve até o correio. Ora, que tal pedir
para o ajudante ir colando algumas enquanto você ainda está
envelopando outras? Isto é processamento distribuído, ou serviço
distribuído. E é sobre este tão simples conceito que repousa
a filosofia da programação cliente/servidor.
Desta forma, a máquina cliente (a
máquina do usuário final) não fica encarregada de todo o processamento.
Ela funciona como front-end, sendo utilizada basicamente para
entrada e visualização de dados. O processamento mais pesado
é feito no servidor.
O servidor recebe pedidos, ou requisições,
do cliente e as processa, enviando imediatamente uma resposta.
Para quem leu o primeiro artigo da série "O Delphi e a Internet"
(publicado neste site) verá que os conceitos apresentados
naquele artigos são similares aos agora mencionados.
Mas como tudo isto acontece na prática?
É necessário haver uma aplicação servidora, instalada em uma
máquina, e uma aplicação cliente, instalada em outras máquinas.
As aplicações cliente fazem pedidos à aplicação servidora,
que as atende. Isto já deixa claro que o equipamento onde
será instalada a aplicação servidora deve ser provido de maiores
quantidades de recursos, tais como memória, disco e velocidade
de processamento.
No mundo comercial de hoje, o principal
objetivo das organizações é processar dados, e disparar processamentos
a estes relacionados. Assim, a aplicação servidora é na verdade
um servidor de banco de dados. Nele são concentrados todos
os dados da empresa, e podem ser concentrados ainda os processamentos
ligados a estes dados, sobre o que falaremos a frente.
O cliente é qualquer sistema que
acesse o servidor, e que em nosso caso será uma aplicação
Delphi. Como servidor (a título de exemplo) usaremos o Microsoft
SQL Server 6.5, por ser muito fácil de usar, bastante robusto
e relativamente barato.
Quais
são suas vantagens?
Mas talvez esteja
agora perguntando: para que serve toda esta tecnologia, toda
esta mudança nos métodos de programação? Qual será a real
vantagem de se usar estas técnicas, se é que realmente existem
alguma?
Existem várias vantagens. Uma delas
é a escalabilidade que a filosofia Client/Server oferece.
Imagine que trabalhe com uma rede de 50 máquinas ligadas a
apenas 1 servidor. Com o passar do tempo, cada vez mais sistemas
são adicionados a esta rede, que vai ficando cada vez mais
lenta. O processamento não é distribuído, ou seja, é feito
sempre na parte cliente, e o servidor serve apenas para centralizar
os dados. O que seria necessário para melhorar a performance
da rede? Como o processamento é feito basicamente no lado
cliente, precisaríamos acrescentar recursos aos 50 computadores
clientes, talvez memória. Se decidíssemos adicionar 16 MB
Ram em cada máquina, e se cada pente de 16 custasse R$ 35,00,
teríamos um custo total de R$ 1.750,00. E este custo aumentaria
muito se tivéssemos mais clientes na rede.
Agora vamos mudar de cenário. Nesta
rede rodam aplicações que adotaram a filosofia Client/Server.
Deste modo, a maior parte do processamento é feito no servidor,
digamos em nosso Sql Server. Assim, para melhorar a performance
de toda a rede, seria necessário acrescentar recursos basicamente
no equipamento servidor, que responderia mais rapidamente
aos clientes, desafogando assim toda a rede. Digamos então
que a decisão é adicionar 128 MB Ram ao equipamento servidor
(o que representa uma significativa melhora). Chegaríamos
a um custo de R$ 280,00, assumindo que compraríamos 8 pentes
de 16 MB Ram. Este custo ainda poderia diminuir um pouco,
levando-se em consideração que 2 pentes de 64 MB custariam
um pouco menos do que 8 pentes de 16 MB.
A escalabilidade que a filosofia
Client/Server oferece é uma de suas grandes vantagens.
Velocidade
Os programas que operam
com técnicas Client/Server trafegam uma quantidade muito menor
de dados pela rede. Isto se dá porque o cliente faz um pedido
ao servidor, e o pedido é todo processado por ele (o servidor),
retornando apenas uma pequena quantidade de dados para o cliente
como resposta. Assim, as únicas transações em rede são o pedido
do cliente e a resposta do servidor.
Isto deixa a rede muito mais leve,
com menos tráfegos de dados. O resultado final, é um ganho
na velocidade de todas as aplicações na rede. É claro que
isto significa para nós programadores uma mudança na forma
de programar, e até de analisar nossos sistemas. Em breve
falaremos mais diretamente sobre este assunto.
Segurança
A segurança é talvez
a mais notável vantagem da filosofia Client/Server. Os servidores
de banco de dados são muito robustos e preparados para fornecer
a maior segurança possível. Os métodos de armazenamento e
de cache já são em si mesmos uma grande fonte de segurança,
e contam com os algoritmos mais complexos que se possa imaginar
para garantir isso.
Os sistemas de Backup, manuais e
automáticos, disponibilizam à organização um grau ainda maior
de segurança, oferecendo também uma grande flexibilidade para
recuperar dados em pouco tempo.
Quanto a nós, programadores, passamos
a contar com um eficiente sistema de transações, que garantem
aos nossos sistemas que processamentos não serão interrompidos
no meio. Um exemplo disto é uma baixa de Nota Fiscal. Digamos
que ao dar a baixa da Nota, o sistema lance duplicatas a receber,
e lance também a saída no estoque. Se houver uma interrupção
de energia, ou qualquer outro problema durante o processamento,
pode acontecer que este seja interrompido no meio, deixando
a Nota baixada, as duplicatas geradas e sem os lançamentos
de saída no estoque. Este tipo de problema pode ser facilmente
evitado usando-se as técnicas de transações oferecidas pelos
sistemas gerenciadores de banco de dados, como o Sql Server.
Mudanças
de conceito
Mas algumas mudanças
conceituais devem ser feitas. Os velhos e bons grids que exibiam
todos os registros de uma tabela, e que permitiam ao usuário
"passear" por estes registros, deixa de existir na programação
Client/Server. O problema é que agora precisamos trafegar
a menor quantidade de dados possível na rede, o que significa
que não podemos abrir tabelas inteiras, ou usar comandos SQL
do tipo "select * from tabelatal". As tabelas estão centralizadas
no servidor, e se abrimos uma tabela, todos os seus registros
trafegam pela rede até chegar ao equipamento cliente. Só então
são aplicados filtros ou processamentos a estes dados.
O que queremos é aplicar os filtros
e processamentos na fonte dos dados, ou seja, no servidor.
É por isso que passaremos a programar usando basicamente componentes
TQuery, em nossos comandos SQL usaremos sempre a cláusula
WHERE.
Onde
ficam as regras de negócios?
"Regras de negócios"
é apenas um nome bonito para "rotinas de processamento". Assim,
a pergunta é: onde ficam nossas rotinas de processamento?
Sim, agora aquelas rotinas pesadas, tipo fechamento de mês,
recalculo de saldos e outras mais, podem ficar tanto no servidor
quanto no cliente.
Quando as regras de negócio ficam
no cliente, isto significa que as rotinas de processamento
ficam em nosso programa Delphi, acessando os dados no servidor.
A vantagem deste método é que o sistema inteiro pode ser migrado
para um banco de dados diferente, sem grandes traumas. A desvantagem
é que o processamento destas rotinas ficam um pouco mais lentos,
e dependem da máquina cliente – se for uma máquina rápida,
o processamento vai ser rápido, se for uma máquina lenta,
o processamento vai ser lento.
Quando as regras de negócio ficam
no servidor, isto significa que as rotinas de processamento
ficam no próprio servidor, acessando os dados ali mesmo. Neste
caso, as rotinas de processamento devem ser escritas na linguagem
que o servidor entenda, e armazenadas em unidades conhecidas
como Store Procedures. A grande vantagem é a velocidade de
processamento, que é muito maior. E a principal desvantagem
é que em caso de uma eventual migração para outro banco de
dados, seria necessário migrar todas as Store Procedures para
o outro banco de dados, o que pode envolver muito trabalho,
uma vez que as linguagens possuem muitas diferenças.
|
|
 Comentários | |
| | Comentários pertencem aos seus respectivos autores. Não somos responsáveis pelo seus conteúdos. |
por: asf : Mar 11, 2004 - 05:12
(Informações sobre o membro | Enviar uma mensagem)
http://
|
Muito legal, o texto utilizando uma linguagem prática e dinâmica, favorece o entendimento da máteria sobre Client/Server que tantos usuários acreditam que seja muito complicado.
Parabéns...
|
|
|
Edição 112 |
|
|
50 Programas Fontes |
|
|
Produtos |
|
|
