Fundamentos da Arquitetura Cliente/Servidor

SUMRIO

1 - INTRODUO 1

2 - ARQUITETURA CLIENTE/SERVIDOR 1
2.1 - VANTAGENS 3
2.2 - DESVANTAGENS 3
2.3 - MODELOS DA ARQUITETURA CLIENTE / SERVIDOR 4
2.3.1 - Arquitetura C/S Simples 4
2.3.2 - Arquitetura C/S em Dois Nveis 4
2.3.3 - Arquitetura C/S Multinvel 5
2.3.4 - Arquitetura C/S Par-Par 6
3 - ALGUNS TIPOS DE PROCESSOS NUMA ARQUITETURA CLIENTE/SERVIDOR 6
3.1 - PROCESSAMENTO DISTRIBUDO 7
3.2 - CAMADAS DA ARQUITETURA CLIENTE / SERVIDOR 9
3.2.1 - Sistema de Trs Camadas para a Aplicao 12
3.2.1.1 - Apresentao Distribuda 13
3.2.1.2 - Apresentao Remota 14
3.2.1.3 - Lgica Distribuda 14
3.2.1.4 - Gerenciamento de Dados Centralizado 15
3.2.1.5 - Gerenciamento de Dados Distribudos 15
4 - REDES DE COMPUTADORES 16
4.1 - PROTOCOLOS 16
4.1.1 - O Modelo de Referncia OSI/ISO 17
4.1.2 - TCP/IP 18
4.2 - ASPECTOS DE CONEXO 20
4.3 - ASPECTOS DE SINCRONISMO E PASSAGEM DE MENSAGEM 21
4.4 - CONEXO TCP/IP 22
4.5 - SOCKETS 25
4.5.1 - Interfaces de Comunicao utilizando Sockets 28
5 - BANCOS DE DADOS ORIENTADOS A OBJETOS 30
5.1 - INTRODUO 30
5.2 - ALGUNS SGBDOOS E SUAS VERSES CLIENTE/SERVIDOR 31
5.2.1 - SGBDOO O2 31
5.2.2 - SGBDOO GemStone 32
5.2.3 - SGBDOO POET 33
6 - CONCLUSO 34

REFERNCIAS BIBLIOGRFICAS 35

1
 Fundamentos da Arquitetura Cliente/Servidor

1 - Introduo

Este relatrio tem por objetivo mostrar as caractersticas tcnicas que envolvem a
Arquitetura Cliente/Servidor, desde a sua concepo terica at a implantao da
comunicao entre Cliente e Servidor por meio de uma biblioteca de Sockets.
No item 2 ser definido a parte terica da Arquitetura Cliente/Servidor bem como
alguns aspectos de definio desta arquitetura, alm de mostrar os modelos existentes para
implantao desta arquitetura. Em 3 sero mostrados alguns tipos de processamentos
existentes, porm enfocando o processamento distribudo. Em 4 sero vistos os conceitos
bsicos sobre Rede de Comunicao, enfatizando o protocolo TCP/IP e a biblioteca de
Sockets. Em 5 so apresentadas as caractersticas tcnicas de alguns SGBDOOs numa
arquitetura Cliente/Servidor. Finalmente, em 6, feita uma breve concluso com respeito ao
modelo de arquitetura apresentado.

2 - Arquitetura Cliente/Servidor

A arquitetura Cliente/Servidor vem sendo desenvolvida h vrios anos, porm em

pequenos passos. Primeiro, a realocao de aplicaes em Mainframe para as chamadas
plataformas abertas rodando, Sistema Operacional UNIX. Depois, com relao a abordagem
dos dados, saindo de Sistemas de Arquivos ou Banco de Dados Hierrquicos locados em
Mainframes para Sistemas de Banco de Dados Relacional, e posteriormente, a importncia da
capacidade grfica dos pacotes de front-end existentes, facilitando a interao com o usurio
(MCKIE,1997).
Vrios aspectos sobre uma definio da arquitetura Cliente/Servidor podem ser
descritos.
O termo Cliente/Servidor refere-se ao mtodo de distribuio de aplicaes
computacionais atravs de muitas plataformas. Tipicamente essas aplicaes
esto divididas entre um provedor de acesso e uma central de dados e
numerosos clientes contendo uma interface grfica para usurios para
acessar e manipular dados.
Cliente/Servidor geralmente refere-se a um modelo onde dois ou mais
computadores interagem de modo que um oferece os servios aos outros.
Este modelo permite aos usurios acessarem informaes e servios de
qualquer lugar.
Cliente/Servidor uma arquitetura computacional que envolve requisies
de servios de clientes para servidores. Uma rede Cliente/Servidor uma
extenso lgica da programao modular.

Portanto, uma definio para a arquitetura Cliente/Servidor seria a existncia de uma

plataforma base para que as aplicaes, onde um ou mais Clientes e um ou mais Servidores,
juntamente com o Sistema Operacional e o Sistema Operacional de Rede, executem um
processamento distribudo.
1
 Um sistema Cliente/Servidor poderia ser, ento, entendido como a interao entre
Software e Hardware em diferentes nveis, implicando na composio de diferentes
computadores e aplicaes.
Para melhor se entender o paradigma Cliente/Servidor necessrio observar que o
conceito chave est na ligao lgica e no fsica. O Cliente e o Servidor podem coexistir ou
no na mesma mquina (RENAUD,1994). Porm um ponto importante para uma real
abordagem Cliente/Servidor a necessidade de que a arquitetura definida represente uma
computao distribuda (MCKIE,1997).
Algumas das caractersticas do Cliente e do Servidor so descritas a seguir:
(SALEMI,1993) (HULQUIST,1997)

Cliente
Cliente, tambm denominado de front-end e WorkStation, um
processo que interage com o usurio atravs de uma interface grfica ou
no, permitindo consultas ou comandos para recuperao de dados e
anlise e representando o meio pela qual os resultados so apresentados.
Alm disso, apresenta algumas caractersticas distintas:
o processo ativo na relao Cliente/Servidor.
Inicia e termina as conversaes com os Servidores, solicitando servios
distribudos.
No se comunica com outros Clientes.
Torna a rede transparente ao usurio.

Servidor
Tambm denominado Servidor ou back-end, fornece um determinado
servio que fica disponvel para todo Cliente que o necessita. A natureza e
escopo do servio so definidos pelo objetivo da aplicao
Cliente/Servidor. Alm disso, ele apresenta ainda algumas propriedades
distintas:
o processo reativo na relao Cliente/Servidor.
Possui uma execuo contnua.
Recebe e responde s solicitaes dos Clientes.
No se comunica com outros Servidores enquanto estiver fazendo o papel
de Servidor.
Presta servios distribudos.
Atende a diversos Clientes simultaneamente.

Outras caractersticas dos processos Cliente e Servidor podem ser encontradas em

(KALAKOTA,1997).

Alguns tipos de servios que um Servidor pode proporcionar so:

! Servidor de Arquivos
! Servidor de Impressora
! Servidor de Banco de Dados
! Servidor de Redes
! Servidor de Telex

2
 ! Servidor de Fax
! Servidor X-Windows
! Servidor de Processamento e Imagens
! Servidor de Comunicao e etc.

O estilo de interao entre o usurio e o Cliente no precisa, necessariamente, ser feita

por poderosas interfaces grficas. Porm, j que o poder de processamento local do Cliente
est disponvel, pode-se retirar todo seu proveito, atravs de interfaces grficas - GUI
(Graphical User Interface), para melhor rendimento do usurio no seu trabalho.

Dentre as muitas vantagens da arquitetura Cliente/Servidor, pode-se citar:

(SALEMI,1993)

2.1 - Vantagens

Confiabilidade
Se uma mquina apresenta algum problema, ainda que seja um dos Servidores,
parte do Sistema continua ativo.

Matriz de Computadores agregando capacidade de processamento

A arquitetura Cliente / Servidor prov meios para que as tarefas sejam feitas sem
a monopolizao dos recursos. Usurios finais podem trabalhar localmente.

O Sistema cresce facilmente

Torna-se fcil modernizar o Sistema quando necessrio.

O Cliente e o Servidor possuem ambientes operacionais individuais /

Sistemas Abertos
Pode-se misturar vrias plataformas para melhor atender s necessidades
individuais de diversos setores e usurios.

Alm destas vantagens, pode-se encontrar dentro de uma arquitetura Cliente/Servidor a

interoperabilidade das estaes Clientes e Servidoras entre as redes de computadores, a
escalabilidade da arquitetura visando o crescimento e a reduo dos elementos constituintes, a
adaptabilidade de novas tecnologias desenvolvidas, a performance do hardware envolvido na
arquitetura, a portabilidade entre as diversas estaes que compem a arquitetura e a
segurana dos dados e processos (MCKIE,1997).
Embora o avano da arquitetura Cliente/Servidor tenha trazido uma variada gama de
facilidades para o desenvolvimento de aplicaes distribudas, tambm possui algumas
desvantagens:

2.2 - Desvantagens

Manuteno
As diversas partes envolvidas nem sempre funcionam bem juntas. Quando algum
erro ocorre, existe uma extensa lista de itens a serem investigados.

3
 Ferramentas
A escassez de ferramentas de suporte, no raras vezes obriga o desenvolvimento
de ferramentas prprias. Em funo do grande poderio das novas linguagens de
programao, esta dificuldade est se tornando cada vez menor.

Treinamento
A diferena entre a filosofia de desenvolvimento de software para o
microcomputador de um fabricante para o outro, no como a de uma
linguagem de programao para outra. Um treinamento mais efetivo torna-se
necessrio.

Gerenciamento
Aumento da complexidade do ambiente e a escassez de ferramentas de auxlio
tornam difcil o gerenciamento da rede.

2.3 - Modelos da Arquitetura Cliente / Servidor

Existem cinco tipos de modelos para a implantao da arquitetura Cliente/Servidor em

processamentos distribudos: (SALEMI,1993)

2.3.1 - Arquitetura C/S Simples

A primeira abordagem para um sistema distribudo a arquitetura

Cliente/Servidor Simples. Nesta arquitetura, o Servidor no pode iniciar nada. O
Servidor somente executa as requisies do Cliente. Existe uma clara funo de
diferenciao: Pode-se estabelecer que o Cliente o mestre e o Servidor o escravo,
como mostra a figura 1.

CLIENTE

SERVIDOR

Figura 1 - Arquitetura Cliente/Servidor Simples

2.3.2 - Arquitetura C/S em Dois Nveis

A configurao usual Cliente/Servidor encontrada na maioria das empresas,

aquela em que existem vrios Clientes requisitando servios a um nico Servidor. Esta
arquitetura se caracteriza como sendo centrada no Servidor (figura 2a). Porm na viso
do usurio, ele imagina que existem vrios Servidores conectados a somente um
Cliente, ou seja, centrado no Cliente (figura 2b). Entretanto, com as vrias ligaes de
comunicao possveis, existe na realidade uma mistura de Clientes e Servidores (figura
2c).

4
 CLIENTE CLIENTE CLIENTE

SERVIDOR

Figura 2 - (a) Arquitetura C/S em Dois Nveis - Centrado no Servidor

SERVIDOR SERVIDOR SERVIDOR

CLIENTE

Figura 2 - (b) Arquitetura C/S em Dois Nveis - Centrado no Cliente

SERVIDOR SERVIDOR SERVIDOR

CLIENTE CLIENTE CLIENTE

Figura 2 - (c) Arquitetura C/S em Dois Nveis - Comunicao Mista

2.3.3 - Arquitetura C/S Multinvel

Nesta arquitetura (figura 3), permite-se que uma aplicao possa assumir tanto o
perfil do Cliente como o do Servidor, em vrios graus. Em outras palavras, uma
aplicao em alguma plataforma ser um Servidor para alguns Clientes e,
concorrentemente, um Cliente para alguns Servidores.

SERVIDOR SERVIDOR SERVIDOR

CLIENTE

SERVIDOR

CLIENTE CLIENTE CLIENTE

Figura 3 - Arquitetura C/S Multinvel

5
2.3.4 - Arquitetura C/S Par-Par

Esta arquitetura pode ser vista como o caso mais geral da arquitetura
Cliente/Servidor, ilustrado na figura 4. Cada um dos nodos desta arquitetura assume
tanto o papel de Cliente quanto de Servidor. Na verdade, torna-se pouco funcional lidar
com quem o Cliente ou o Servidor. o caso onde o processo interage com outros
processos em uma base pareada, no existindo nenhum Mestre ou Escravo: qualquer
estao de trabalho pode iniciar um processamento, caso possua uma interface de
comunicao entre o usurio e o processo Cliente.

CLIENTE CLIENTE

SERVIDOR SERVIDOR

Figura 4 - Arquitetura C/S Par-Par

3 - Alguns Tipos de Processos numa Arquitetura Cliente/Servidor

A arquitetura Cliente/Servidor divide uma aplicao em processos, que so executados

em diferentes mquinas conectadas uma Rede de Computadores, formando um nico
sistema. O paradigma da tecnologia Cliente/Servidor, serve como um modelo, entre outros
(ANDREWS,1991), para interao entre processos de softwares em execuo concorrente.
Os processos ou tarefas, a serem executadas so divididas entre o Servidor e o Cliente,
dependendo da aplicao envolvida e das restries impostas pelo Sistema Operacional de
Rede (SOR). Quanto mais avanado for o Sistema Operacional de Rede, menor ser a
aplicao em si, uma vez que a implementao do cdigo para acessar a rede j se encontra
definido no SOR.
Atualmente dois tipos de processamentos esto sendo divulgados, Processamento
Distribudo e Processamento Cooperativo. A caracterstica de cada um destes descrita a
seguir (KALOKATA,1997), e neste trabalho o enfoque ser destinado ao processamento
distribudo.

Processamento Distribudo
A distribuio de aplicaes e tarefas se faz atravs de mltiplas plataformas
de processamento. O processamento distribudo implica que essas
aplicaes/tarefas iro ocorrer em mais de um processo, na ordem de uma
transao a ser concluda. Em outras palavras, o processamento distribudo
atravs de duas ou mais mquinas e os processos, na maioria, no rodam ao
mesmo tempo, por exemplo, cada processador realiza parte de uma aplicao
em uma seqncia. Geralmente, o dado usado em um ambiente de
processamento distribudo tambm distribudo atravs de plataformas.

Processamento Cooperativo
A cooperao requer dois ou mais processadores distintos para completar uma
simples transao. O processamento cooperativo relatado para ambos os
processos cliente-servidor. uma forma de computao distribuda onde dois
6
 ou mais processadores distintos so requeridos para completar uma simples
transao de negcios. Normalmente esses programas interagem e executam
concorrentemente como diferentes processos. Os processos cooperativos
tambm so considerados como um estilo de Cliente/Servidor atravs da
arquitetura de mensagens, que devem obedecer a um determinado padro.

No contexto do presente trabalho pretende-se utilizar as caractersticas do

processamento distribudo. Este tipo de processamento apresenta duas configuraes para uma
arquitetura Cliente/Servidor. A primeira, que representada por trs camadas, responsvel
pela visualizao da interao entre os aplicativos e o hardware, como pode ser visto na figura
5.
A segunda representao, tambm fornecida em trs camadas, mostra como tratada a
diviso da funcionalidade de uma aplicao, segundo as configuraes do Gartner Group,
como pode ser visto na figura 6.

Processamento Cliente-Servidor

Cliente Servidor

Aplicao Aplicao

Servios do Sistema Servios do Sistema

Hardware Hardware

Figura 5 - Sistema Cliente/Servidor

3.1 - Processamento Distribudo

O processamento distribudo, tambm denominado de processamento concorrente

utiliza-se do mecanismo de passagem de mensagens para a comunicao entre processos, que
podem ser de quatro tipos bsicos; Filtro, Peer (no hierrquico), Cliente e Servidor
(RENAUD,1994), como mostrado na figura 7 a seguir.

7
 Modelo de Distribuio de
Processos
Apresentao Apresentao Apresentao Apresentao Apresentao

Lgica de Lgica de Lgica de

Rede Negcio Negcio Nogcio

Gerncia de
Dados
Apresentao

Lgica de Lgica de Lgica de

Negcio Negcio Negcio

Gerncia de Gerncia de Gerncia de Gerncia de Gerncia de

Dados Dados Dados Dados Dados

Apresentao Apresentao Lgica Gerenciamento de Gerenciamento de

Distribuda Remota Distribuda Dados Centralizado Dados Distribudo

Fonte: Gartner Group

Figura 6 - Arquitetura da Aplicao Cliente/Servidor

Processamento Distribudo

Processamento

Processamento Processamento
Centralizado Distribudo

Filtro Peer-to-Peer Cliente/Servidor

Figura 7 - Processamento Distribudo

Caractersticas do Processo de Filtro:

Determina uma converso na mensagem de comunicao entre o usurio e o
host. Ex.: Ligao de um desktop com um mainframe atravs de um emulador
de terminal.

A B C

8
 Caractersticas do Processo Peer-to-Peer (no hierrquicos):
So processos clones rodando em todas as mquinas e prestando servios uns
para os outros.
No existem processos servidores, estabelecendo um Servidor dedicado.
Cada processo pode ser Cliente e Servidor para outros processos.

A A

Durante a execuo das consultas, os processos Cliente e Servidor so confundidos

com os processos Peer-to-Peer, porque este processo foi desenvolvido com base na LU6.2
(Logical Unit verso 6.2) do SNA (Systems Network Architecture) da IBM (RENAUD,1994).

Caractersticas do Processo Cliente / Servidor:

Existem processos distintos: o processo cliente diferente do processo
servidor.
Os processos servidores tornam a estao Servidora dedicada ao seu trabalho.
Processos clientes so sempre clientes.
Processos servidores podem se tornar processos clientes de outros Servidores.

A B

O modelo que utiliza processos Cliente/Servidor depende do cliente para inicializar a

comunicao. Caso o Servidor comece a comunicao, o processo instalado fica sendo o Peer-
to-Peer
A caracterstica bsica da arquitetura Cliente/Servidor a que processos Clientes
enviam pedidos a um processo Servidor, que retorna o resultado para o Cliente. O processo
Cliente fica ento liberado da ao do processamento da transao podendo realizar outros
trabalhos.

3.2 - Camadas da Arquitetura Cliente / Servidor

A arquitetura Cliente/Servidor dividida em trs camadas bsicas, como ilustra a

figura 8. A camada de Aplicao consiste dos processos da aplicao, entre eles, os processos
Cliente e Servidor. A camada de Servios de Sistemas compreende o Sistema Operacional
(SO) e o Sistema Operacional de Rede (SOR), destinando-se ao controle do hardware. Por
ltimo a camada de hardware, onde esto localizados os perifricos ligados aos Clientes e
Servidores.

Aplicao

Servios do
Sistema

Hardware

9
 Figura 8 - Trs Camadas da Arquitetura Cliente/Servidor
A tecnologia Cliente/Servidor pode existir tanto no nvel da camada de Aplicao,
quanto no da camada de Servios do Sistema. A coexistncia do paradigma nestas camadas
surge em funo da hierarquia das atuaes no sistema. Caso o usurio seja externo ao
sistema, ento os processos Cliente e Servidor compem a camada da Aplicao, enquanto
que, se o usurio for um programa de aplicao o Cliente um processo redirecionador, e o
Servidor ser um processo respondedor da camada de Servios do Sistemas.
A utilizao de sistemas Cliente/Servidor pela camada de aplicao utiliza Servios do
Sistema no Cliente/Servidor (figura 8), entretanto, sistemas no Cliente/Servidor, ao nvel da
aplicao utilizam Servios do Sistema Cliente/Servidor (RENAUD,1994).
Para sistemas Cliente/Servidor na camada de aplicao, a camada Servios do Sistema
oferece somente um mecanismo de IPC (InterProcess Comunication) para troca de
mensagens. Por outro lado, a camada Servios do Sistema configurada como Cliente/Servidor,
responsvel por gerenciar o redirecionamento das solicitaes de gravao/leitura, por
exemplo. importante notar que a diferena entre os sistemas Cliente/Servidor nas camadas
de Aplicao e Servios do Sistema, o equilbrio entre a quantidade de processamento tanto
no lado do Cliente quanto no lado Servidor.
Existem vrios sistemas que podem ser baseados na estrutura Cliente/Servidor. O uso
mais freqente so as aplicaes de Banco de Dados usando processos SQL (Structured Query
Language) de front-end, para acessar remotamente, as bases de dados.
A figura 9 mostra uma estrutura baseada num Servidor de Arquivos. Esta estrutura
ocasiona um maior fluxo de informaes na rede, uma vez que todo o arquivo ser transferido
para o Cliente para ento ser trabalhado.

Neste tipo de estrutura, a camada de

Servidor de Arquivos Aplicao passa a ser o Cliente do Sistema.
Cliente Servidor
Com isto, a camada de Servio do Sistema
Aplicao
Gerenciador de Banco Aplicao
utilizada simplesmente como um
de Dados redirecionador para acesso base de dados
Redirecionador do Sistema de Arquivos
(RENAUD,1994). Neste tipo de
Sistema de Arquivos configurao pode-se chamar este Sistema
como falso Sistema Cliente/Servidor, por
Hardware Hardware
no haver um equilbrio de processamento
entre os dois lados Cliente e Servidor. O
lado Servidor somente ter o trabalho de
executar as rotinas comuns de I/O, no
caracterizando assim, como um
Figura 9 - Arquitetura Cliente/Servidor como Servidor
de Arquivo processamento intrnseco aplicao.

A figura 10 demonstra outra possibilidade de se estruturar um Sistema baseado na

arquitetura Cliente/Servidor, que consiste na utilizao de um Servidor de Banco de Dados
dedicado, podendo coexistir normalmente com o Servidor de arquivos. Neste momento, com
um Servidor de Banco de Dados exclusivo, o fluxo de informaes trafegadas na rede
diminui, j que, somente a resposta da consulta retornada ao Cliente, ao invs de transferir
todo o arquivo como era feito anteriormente.

10
 O Cliente, neste tipo de estrutura o usurio, passando a ter uma viso da aplicao
como se as partes, Cliente e Servidor, fossem algo nico. A figura 11 exemplifica esta viso.

Servidor de Banco de Dados

Cliente Servidor

Aplicao
Gerenciador de
API do Gerenciador de Banco de Dados
Banco de Dados

Servios do Sistema Sistema de Arquivos

Hardware Hardware

Figura 10 - Arquitetura Cliente / Servidor como Servidor de

Banco de Dados

Processo Cliente Aplicao Processo Servidor

Servios do Sistema Servios do Sistema

Hardware Hardware

Figura 11 - Integrao entre os processos clientes e servidores

Este tipo de estrutura favorece o aumento da performance da rede de comunicao,

possibilitando assim, um maior nmero de ligaes simultneas de diversos Clientes com
diversos Servidores (RENAUD,1994).
Embora a arquitetura Cliente/Servidor possa parecer uma nova verso do modelo de
arquivos compartilhados, atravs da Rede Local baseada em microcomputadores, suas
vantagens so inmeras. Fundamentalmente, ambos os modelos provem capacidade de
processamento distribudo e permitem o compartilhamento de informao. Entretanto, no
Modelo de Arquivos compartilhados baseado em Servidor de Arquivos, o Cliente alm de
executar a aplicao, executa tambm o motor da Base de Dados, que por sua vez acessa essas
Bases de Dados remotamente como se fossem locais. O Servidor de Arquivos envia arquivos
inteiros atravs da rede para o Cliente processar localmente, ocasionando congestionamento
na rede, enquanto que, no modelo Cliente/Servidor, o Cliente executa parte da aplicao,
sendo deixado para o Servidor a tarefa da administrao da Base de Dados, comumente
exercida por algum SGBD. O Servidor envia para o Cliente, atravs da Rede, apenas o bloco
de dados apropriado, como resultado da consulta efetuada pela aplicao.
11
 Desta forma, na arquitetura Cliente/Servidor, cada Servidor pode suportar um nmero
maior de usurios, uma vez que o Cliente que gerencia a aplicao e a interface com o
usurio. Alm do mais, com a crescente conectividade entre mquinas e sistemas
operacionais, pode-se escolher para Cliente o ambiente de software e hardware que melhor se
adeque s necessidades de cada aplicao do usurio, sem ter que se preocupar com o
Servidor.
A melhor diviso de tarefas entre o Cliente e o Servidor depende de cada aplicao em
si. Se o Servidor for apenas um Sistema Gerenciador de Banco de Dados, deixando para o
Cliente o resto do processamento, ou se algumas tarefas como controle de acesso, anlise dos
dados, e validao dos comandos executada pelo Servidor, esta uma deciso do construtor
do Sistema em funo das caractersticas do negcio do usurio. Estas diferenas sero
mostradas no tpico a seguir.

3.2.1 - Sistema de Trs Camadas para a Aplicao

Os Sistemas Cliente/Servidor tm sido utilizados basicamente nos Sistemas de Banco

de Dados Distribudos, Processamento de Transaes e nos Sistemas de Suporte a Deciso.
A maioria das aplicaes tidas como crticas tm permanecido num mainframe. Pode-
se definir como crticas aquelas aplicaes cujos resultados so utilizados para decises
estratgicas e que, portanto, variam de empresa para empresa, dependendo do seu negcio.
Quase que universalmente, os sistemas de finanas so considerados crticos para todas as
empresas. Por outro lado, os sistemas de processamento de transaes so crticos para as
companhias de aviao.
As aplicaes de processamento de transaes, apesar de serem tipicamente
consideradas como crticas, tm sido freqentemente migradas para arquitetura
Cliente/Servidor, atravs do processo de Downsizing, como por exemplo os sistemas de
entrada de pedidos, pontos de vendas e sistemas de reservas. As transaes ocorrem nos
Clientes e so formatadas e enviadas ao Servidor para armazenamento.
Seria razovel imaginar que as primeiras aplicaes a serem desenvolvidas em
Sistemas Cliente/Servidor seriam relativamente simples, garantidas e no crticas. Porm, as
empresas que se decidiram pelo modelo Cliente/Servidor testaram-no com aplicaes de
processamento de transaes, e na maioria dos casos ficaram satisfeitas com os resultados.
Como pode ser visto pela figura 12, o Gartner Group apresenta cinco maneiras de se
implementar a arquitetura Cliente/Servidor. Cada camada dividida entre a parte lgica e a
parte de gesto. A primeira representao refere-se a distribuio da camada de Apresentao.

12
 Modelo de Distribuio de
Processos
Apresentao Apresentao Apresentao Apresentao Apresentao

Lgica de Lgica de Lgica de

Rede Negcio Negcio Nogcio

Gerncia de
Dados
Apresentao

Lgica de Lgica de Lgica de

Negcio Negcio Negcio

Gerncia de Gerncia de Gerncia de Gerncia de Gerncia de

Dados Dados Dados Dados Dados

Apresentao Apresentao Lgica Gerenciamento de Gerenciamento de

Distribuda Remota Distribuda Dados Centralizado Dados Distribudo

Fonte: Gartner Group

Figura 12- Arquitetura da Aplicao Cliente/Servidor

3.2.1.1 - Apresentao Distribuda

Esta Arquitetura emula uma arquitetura Cliente/Servidor. Toda a gerncia da

Apresentao efetuada no Servidor, enquanto que no Cliente, somente a lgica da impresso
dos caracteres no monitor executada. O Cliente
Apresentao no possui qualquer tipo de inteligncia.
Rede
Existe uma tcnica de tratamento cooperativo,
denominada de Revamping, que utilizado pela
Apresentao Distribuda.

Apresentao O Revamping uma tcnica de

tratamento cooperativo que est dividida em trs
Lgica de Negcio tipos: simples, evoludo e o modificado
(LEFEBVRE,1994).
Gerncia de Dados

Apresentao Distribuda

Fonte: Gartner Group

Revamping Simples
Consiste em habilitar as telas de modo grfico das aplicaes centralizadas com
dilogos em modo grfico. Cada mapa de tela, gerado corresponde a uma janela
de interface grfica.
13
 Revamping Evoludo
Este tipo no emite simplesmente uma rplica grfica da janela a ser criada de
uma aplicao no grfica. Constri uma aplicao inteiramente nova,
inteiramente diferente da aplicao original. Assim, um dilogo na nova
aplicao pode representar um empilhamento de vrias janelas da aplicao
centralizada.

Revamping Modificado
Este terceiro tipo se deriva do segundo, porm com o fato interessante de se
poder manipular a aplicao centralizada instalando sistemas grficos, visando
retirar o melhor de sua performance.

3.2.1.2 - Apresentao Remota

A segunda arquitetura definida como

Apresentao
Apresentao Remota, e possui a implementao
tanto do mdulo de gesto, quanto o de lgica na Rede
estao Cliente, ficando responsvel, entre outras
tarefas, pela manipulao das telas e pelas crticas
dos dados que esto sendo inseridos.
Uma ponto a ser observado, quando se
utiliza um Servidor X-Windows : embora o usurio
Lgica de Negcio
se localize no Terminal X-Windows, ele realmente
est se utilizando do Servidor X-Windows. O Gerncia de Dados
terminal real Cliente onde o usurio est
conectado. Esta caracterstica muito encontrada Apresentao Remota
em ambientes UNIX. O Servidor X-Windows fica
Fonte: Gartner Group
responsvel pela manipulao das telas e interao
com o usurio.

3.2.1.3 - Lgica Distribuda

Outra representao a arquitetura da Lgica

Apresentao Distribuda. Ela representa o melhor modelo de
implementao para arquitetura Cliente/Servidor.
Lgica de Negcio Nela, o balano entre os processamentos clientes e
servidores so bem determinados. Neste tipo de
arquitetura, a implantao de procedimentos
Rede
armazenados (Stored Procedures) facilitam a
performance na rede de comunicao, uma vez que
somente o nome do procedimento armazenado no
Lgica de Negcio
Servidor transmitido pela rede. Um ponto muito
positivo para este tipo de estrutura se refere a pr-
Gerncia de Dados compilao necessria para os procedimentos
armazenados, aumentando consideravelmente o
Lgica Distribuda tempo de resposta. Quando os procedimentos
Fonte: Gartner Group
14
armazenados no so utilizados, necessrio que sejam feitas compilaes das sentenas das
consultas antes de execut-las, evidenciando uma perda desnecessria no tempo de
processamento para enviar a resposta ao Cliente. Porm, um ponto negativo para este tipo de
arquitetura, o fato de se ter que criar antecipadamente as consultas a serem utilizadas pelo
sistema. Ao contrrio, se o sistema utilizar interaes com o usurio este tipo de arquitetura
no o mais recomendado, pois no se pode prever todos os tipos de consultas que os
usurios possam a vir a fazer.

3.2.1.4 - Gerenciamento de Dados Centralizado

Neste tipo de Arquitetura, toda a parte de Apresentao

gesto e lgica da Aplicao fica destinada ao
Lgica de Negcio
Cliente, enquanto que somente o responsvel por
prover o armazenamento e a persistncia dos
dados permanece no Servidor, como por exemplo Rede
no caso de um SGBD, responsvel direto pela
gesto e lgica dos dados armazenados. Este tipo
de arquitetura a mais difundida, no criando,
teoricamente, qualquer tipo de empecilho na hora Gerncia de Dados
da migrao de plataformas mainframes para
Gerenciamento de Dados
plataformas desktop do tipo PC (Personal Centralizados
Computer). Fonte: Gartner Group

3.2.1.5 - Gerenciamento de Dados Distribudos

Ao contrrio do Gerenciamento de Dados Centralizados, o Gerenciamento de Dados

Distribudos permite a replicao e diviso dos dados por diversos stios (sites). Os sistemas
distribudos no deixam de ser microsistemas centralizados, necessitando porm de estruturas
como metadados para determinar a localizao dos dados e suas replicaes. J existem no
mercado sistemas que se instalam entre a parte lgica da aplicao e a gerncia de dados, com
a funo de controlar a localizao real dos dados.

Apresentao

Lgica de Negcio

Gerncia de Dados

Rede

Gerncia de Dados

Gerenciamento de Dados
Distribudos
Fonte: Gartner Group
15
 Outro ponto muito importante a ser verificado o gerenciamento da concorrncia entre
processos, quase sempre a cargo dos Sistemas Operacionais das plataformas, tais como o
Windows NT e o UNIX (CUSTER,1993) (PHAM,1996), (TANENBAUM,1995). O trabalho
de gerenciamento para o compartilhamento dos dados se deve exclusivamente aos SGBDs.
Os tipos de arquiteturas apresentadas no so mutuamente exclusivas, mas sim
complementares. possvel fazer vrios tipos de associaes entre Servidores e Clientes,
dentro de uma rede de computadores.
A tabela 1 mostra um resumo das caractersticas de sistemas Cliente/Servidor.

Atributo Cliente Servidor

Modo Ativo
Execuo Incio e final fixos
Finalidade Principal 1. Manipulao de tela / janela
2. Interpretao de menu /
comando
3. Entrada de mouse / teclado
4. Entrada de dados e validao
5. Processamento de ajuda
6. Recuperao de erro
Transparncia Oculta rede e servidores
Inclui Comunicao com diferentes
servidores
Exclui Comunicao Cliente - Cliente
Reativo
Roda o tempo todo
1. Oferecer servios funcionais
2. Compartilhamento de dados na
aplicao
3. Compartilhamento de
dispositivos
Oculta detalhes de implementao
dos servios
Comunicao com diferentes
clientes
Comunicao Servidor - Servidor

Tabela 1 - Principais tpicos de uma Arquitetura Cliente/Servidor

4 - Redes de Computadores

Normalmente vrias perguntas so feitas para se tentar entender como clientes e

servidores se comunicam, que tipo de protocolo utilizado, e como um cliente encontra o
servidor desejado dentro de uma rede de computadores. Embora estas perguntas possam
parecer muito difceis, na realidade elas so relativamente fceis.
Existem vrios conceitos e aspectos comuns s comunicaes Cliente/Servidor
necessrios ao entendimento do funcionamento da comunicao. Nesta seo ser dada uma
viso geral sobre os conceitos bsicos de protocolos, passagem de mensagem, os aspectos de
conexo e sincronismo de processo.

4.1 - Protocolos

H duas dcadas, diversos esforos vm sendo traados para se estabelecer um padro

nico para redes de computadores. No entanto, foram definidos no apenas um, mas vrios
modelos de referncia.

16
4.1.1 - O Modelo de Referncia OSI/ISO

Em maro de 1977, foi constitudo pela ISO um grupo de trabalho para estudar a
padronizao da interconexo de sistemas de computao. Foi definida, inicialmente, uma
arquitetura geral, denominada MODELO DE REFERNCIA OSI (Open System
Interconection), para servir de base para a padronizao da conexo de sistemas abertos
(TAROUCO,1986) (TANENBAUM,1996)
O modelo OSI possui sete camadas, como apresentado na figura 13. Cada camada
especifica um grupo especfico de tarefas de comunicao. A norma descreve o escopo
funcional de cada camada e os requisitos para a interface com as camadas adjacentes
(servios).

Camada de Aplicao - Seleo de servios apropriados aplicao.

Camada de Apresentao - Formatao/Reformatao de dados. Ex.: Criptografia.
Camada de Sesso - Interface do usurio para o estabelecimento de conexes.
Camada de Transporte - Controle de intercmbio de mensagens entre usurios.
Camada de Rede - Controle de intercmbio de mensagens na rede.
Camada de Enlace - Transmisso livre de erros.
Camada de Fsica - Interface eltrica para transmisso bit a bit.

Figura 13 - Camadas do Modelo de Referncia OSI

A figura 14 mostra que quando a mensagem passa da camada n +1 para a camada n

so acrescidos outros dados relevantes camada n . Estes dados so retirados quando a
mensagem chega na camada de mesmo nvel na estao destino. Estes acrscimos podem ser
informaes tais como: tipo da mensagem, endereos, tamanho da mensagem , cdigo de
deteco de erro, etc.

Figura 14 : Arquitetura de protocolos em camada

17
 O modelo OSI/ISO especifica todas as primitivas de comunicao para que haja troca
de mensagens entre as camadas (AMARAL,1993) (COMER,1993) (DUMAS,1995)
(RENAUD,1994) (TANENBAUM,1996). Cada camada adiciona um cabealho para que haja
uma identificao na mquina destino.
A figura 15 mostra os principais protocolos usados nas comunicaes Cliente /
Servidor baseados na Microsoft, Internet e IBM.

Microsoft Internet IBM

Aplicao Canais Nomeados RPC APPC
Apresentao (Named Pipes) XDR
Sesso NetBIOS sockets LU 6.2
Transporte TCP
NetBEUI
Rede IP PU 2.1
Enlace IEEE LLC SDLC
Token Ring Ethernet
Fsica Par Tranado Coaxial

Figura 15 - Comparao entre o modelo OSI / ISO e outros Protocolos

Tendo em vista os objetivos do trabalho pretendido pela presente tese, somente o

protocolo de comunicao TCP/IP ser descrito, em funo da sua interao com sockets, j
que este ser o meio de comunicao adotado na implementao do prottipo aqui proposto.
O leitor poder referenciar-se a (COMER,1993) (DAVIS,1994) TANEMBAUM96] para obter
maiores detalhes sobre os demais protocolos.

4.1.2 - TCP/IP

O TCP/IP distingue-se dos demais protocolos pelo seu endereamento universal. Cada
mquina em uma rede possui um endereo que a identifica. A camada TCP orientada
conexo, enquanto a camada IP trabalha sem conexo (COMER,1993) (DAVIS,1994)
(DUMAS,1995). Cabe camada IP o trabalho de distribuir os datagramas entre as mquinas
de uma rede. Para fazer este servio, ele possui um nico endereo de 32 bits que contm
informaes suficientes para identificar univocamente uma rede e um determinado
computador.
Este endereo comumente escrito em decimal de quatro bytes separados por um
ponto. Por exemplo:
11011111, 00000001, 00000010, 00000101, representaria o endereo 223.1.2.5.
Existem 5 classes onde estes endereos so divididos. A figura 16 mostra estas
classificaes.(QUINN,1996) (RENAUD,1994)

18
 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Classe
A 0 ID da Rede ID do Host
B 1 0 ID da Rede ID do Host
C 1 1 0 ID da Rede ID do Host
D 1 1 1 0 Endereo de Multi-Transmisso
E 1 1 1 1 0 Reservado
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Figura 16 - Classes do protocolo TCP/IP

O nmero de redes e hosts que podem ser endereados pelas Classes A, B, C, D e E,

bem como o escopo de seus endereos IP so definidos na tabela 2.
Por exemplo, possvel enderear at 65.136 hosts para cada rede da classe B.
Portanto, 65.136 x 16.382 = 1.067.057.952. Isto quer dizer que mais de 1 milho de hosts
podem ser endereveis pela classe B, j que certos endereos IP no podem ser utilizados por
serem destinados a trabalhos especficos, como o endereamento de Gateways e de
Broadcasting.

Classes Num. de Redes Endereo de Rede Num. de Hosts Endereo de Hosts

A 128 0.0.0.0 - 127.0.0.0 + 16M 0.0.0 - 255.255.255

B 16.284 128.0.0.0 - 191.255.0.0 65.136 0.0 - 255.255
C + 2M 192.0.0.0 - 256 0 - 255
223.255.255.255
D 224.0.0.0 -
239.255.255.255
E 240.0.0.0 -
255.255.255.255
Tabela 2 - Limite do nmero de redes e hosts em cada endereo IP

Com isto, quando se tem um endereo de rede na classe B e deseja-se aumentar o

nmero de redes possveis, em detrimento da capacidade de mquinas que podem ser
instaladas, ou vice-versa, utiliza-se a tcnica da mscara de rede (NetMask). Esta tcnica
permite a criao de subredes atravs da modificao local da linha divisria que separa os
bits de identificao das redes e dos hosts. Cada subrede tambm representada pela notao
de ponto decimal. Os bits da NetMask definidos como um identificam a poro da rede,
enquanto os definidos por zero, representam os hosts.
Por exemplo, caso uma empresa possua o endereo IP 166.78.4.139 da classe B, isto
indica que o computador reside na rede 166.78 e que tem uma identificao de host 4.139.
Porm, caso os administradores da rede decidam utilizar a NetMask 255.255.255.0 para
aumentar o nmero de redes internas empresa, necessrio que se faa uma combinao
AND, do endereo IP original com a NetMask, alterando a identificao de rede para 166.78.4
e a identificao de host para 139. Pode-se dizer com isso, que o computador o host 139 na
subrede 166.78.4.0 (endereo de gateway).

19
4.2 - Aspectos de Conexo

Existem dois tipos de conexes usados para a comunicao. O primeiro chamado

sem conexo, onde cada mensagem encontra seu prprio caminho at o seu destino
(COMER,1993) (DUMAS,1995) (QUINN,1996). Cada mensagem independente de todas as
outras mensagens, podendo atingir rotas diferentes at o seu destino. A Internet utiliza este
tipo de conexo.
Logo, cada mensagem deve ter toda a informao de endereamento necessria para a
sua entrega. Dependendo do servio de entrega usado, as mensagens podem chegar fora de
ordem ou serem mal encaminhadas no trnsito.
As mensagens numa comunicao sem conexo so chamadas de datagramas. Essa
forma de comunicao tambm conhecida como comutao de pacotes. Pode-se fazer uma
analogia deste tipo de comunicao com o servio de entrega dos correios.
No existe uma rota preestabelecida quando se utiliza o envio de mensagem por meio
de datagrama. A figura 17 mostra os diversos caminhos que as mensagens podem percorrer.

A mensagem, que
dividida em vrios pacotes,
HOST 1
pode seguir caminhos
distintos, tanto do host 1 para
o host 2, quanto no sentido
inverso, podendo, inclusive,
chegar ao seu destino em
tempos diferentes, havendo
assim, a necessidade de
reordenao da mensagem
pela parte responsvel da
comunicao pela aplicao
do host de destino.
HOST 2 O outro tipo de
comunicao o baseado em
Figura 17 - Mensagem por Datagrama conexo, onde um circuito
prvio estabelecido antes
que a troca de dados se efetue. Quando um circuito estiver conectado, cada mensagem segue
uma seqncia e sempre direcionada ao longo do mesmo circuito (COMER,1993)
(DUMAS,1995) (QUINN,1996).
Logo, cada mensagem s precisa de um identificador de circuito para ser direcionada
para o seu destino. O recebimento de cada mensagem normalmente confirmado e, se for o
preciso, o controle de fluxo usado para regular a velocidade com que as mensagens so
enviadas.
A comunicao baseada em conexo, conforme apresentado na figura 18, garante a
transmisso das mensagens. Estas so tambm divididas em pacotes, sem perda para o
seqenciamento dos pacotes nos hosts destinos, diminuindo assim o trabalho de
implementao na parte de comunicao do aplicativo.

20
 HOST 1 Quando a comunicao
finalizada, torna-se necessrio
desfazer a conexo para poder
liberar os recursos de rede
utilizados.
Deve-se notar que as
mensagens sempre chegam
ordenadas neste tipo de
conexo. Um exemplo de
comunicao baseado em
conexo o sistema telefnico.

HOST 2
A tabela 3 a seguir
compara os dois tipos de
comunicao.
Figura 18 - Mensagem baseada em conexo

Caracterstica Baseado em Conexo Sem Conexo

Tipo de Mensagem Fluxo de dados Datagrama
Rota Esttica Dinmica
Endereamento de Mensagem Endereo de destino completo para Endereo de destino completo em
estabelecer circuito; depois todas as mensagens
somente o ID do circuito
Confiabilidade Seqenciado, controle de erro e Sem garantias: mensagens podem
fluxo, entrega garantida ser perdidas ou chegar fora de
ordem
Opes Podem ser negociadas durante a No disponveis
preparao
Sincronismo Explcito Implcito
Overhead Preparao e liberao do circuito Rota da mensagem
Tabela 3 - Tipos de Conexo

4.3 - Aspectos de Sincronismo e Passagem de Mensagem

A comunicao entre Cliente e Servidor procede de forma implcita. Quando o Cliente

espera a resposta da mensagem enviada para continuar o seu processamento, diz-se que o
protocolo utilizado um protocolo com bloqueio, onde o sincronismo entre Cliente e Servidor
est implcito no mecanismo de passagem de mensagem (TANENBAUM,1995).
Caso o Cliente possa continuar suas tarefas, enquanto espera a resposta da mensagem,
o protocolo de comunicao um protocolo sem bloqueio. Isto ocorre quando o sistema
operacional do Cliente multitarefa ou multiprocessamento, possibilitando ao Cliente
executar outras tarefas enquanto aguarda a resposta do Servidor.
A teoria de programao concorrente baseada na noo de processos de comunicao
sendo executados em paralelo a outros processos. Esses processos se comunicam
21
compartilhando memria ou passando mensagens por meio de um canal de comunicao
compartilhado (AMARAL,1993) (VIDAL,1994). O termo IPC (Interprocess Comunication)
se refere s tcnicas utilizadas na passagem de mensagem.
No compartilhamento de memria, os processos concorrentes compartilham uma ou
mais variveis, e utilizam a mudana de estados dessas variveis para se comunicarem. Essa
tcnica inclui espera ocupada, semforos, regies crticas condicionais e monitores
(TANENBAUM,1995). Como esta tcnica exige que os processos estejam na mesma
mquina, no so considerados base para a programao Cliente/Servidor.
Em tcnicas baseadas na passagem de mensagem, os processos enviam e recebem
mensagens explicitamente, em vez de examinar o estado de uma varivel compartilhada
(AMARAL,1993) (COMER,1993). O benefcio principal da passagem de mensagem que
existe pouca diferena entre o envio de mensagens a processos remotos ou locais. Portanto, a
passagem de mensagem poderosa para criao de aplicaes em rede. Outra vantagem que
mais informaes podem ser trocadas numa mensagem do que por mudana no estado de uma
varivel compartilhada.
A figura 19 mostra a troca de mensagem entre cliente e servidor sem o bloqueio por
parte do cliente.

Passagem geral de mensagens

Processo Processo
Solicitante Respondedor

Send (Msg1, Respondedor)

Receive (Msg1, Solicitante)

Send (Resp1, Solicitante)

Receive (Resp1, Respondedor)

Figura 19 - Troca de mensagem sem bloqueio

4.4 - Conexo TCP/IP

Uma vez que a base de comunicao iria ser efetuada por meio de sockets, foi
estabelecido tambm que o protocolo de comunicao utilizado seria o TCP/IP, possibilitando
assim uma possvel conexo futura com a plataforma UNIX.

22
 Para este desenvolvimento, a plataforma a ser utilizada o Windows NT 3.5 ou 3.51,
que apresenta a robustez necessria para os processos multitarefas. A escolha deste ambiente
tambm se deve ao fato dele suportar vrios tipos de protocolos para comunicao, entre eles
o TCP/IP (QUINN,1996).
A figura 20 mostra os protocolos de comunicao do Windows NT.
O protocolo TCP/IP o protocolo padro utilizado pela Internet, que possibilita a
interligao de diversas plataformas. Existem vrios servios que utilizam o protocolo
TCP/IP, entre eles pode-se encontrar o FTP, Telnet, E-mail, Ping e Finger, como pode ser
visto na figura 21, junto com sua referncia camada do modelo OSI/ISO.
Na camada de Transporte pode-se notar a existncia de dois padres, o TCP, que a
comunicao com conexo e o UDP, que a comunicao sem conexo, como j foi
mencionado anteriormente na seo 4.2. Para o desenvolvimento deste prottipo foi adotado o
padro TCP, onde o controle de erro e o seqenciamento dos pacotes das mensagens so
automaticamente tratados, o que no ocorre no padro UDP, necessitando que estes
tratamentos sejam desenvolvidos.
O padro TCP permite a abertura de uma conexo virtual entre a mquina fonte e a
destino em todas as camadas do modelo OSI/ISO.

7 Aplicao Windows sockets Aplicao Windows sockets

Aplicao Windows sockets APIs proprietrias (opcional) APIs proprietrias (opcional)

6 Aplicao Windows sockets Aplicao (cont.)

APIs proprietrias (opcional) Aplicao (cont.) APIs proprietrias (opcional)

5 Aplicao (cont.) Aplicao (cont.)

Windows Socket API

Windows sockets Dynamic Link Library (Winsock.DLL)

APIs proprietrias

4
TCP/IP DECNet NetBEUI Appletalk SPX/IPX
3
Driver de APIs padres

2 Driver de Protocolos Mltiplos (ODI, Packet Driver, NDIS)

APIs de Hardware proprietrio

1 Interface de Rede (Ethernet, Token Ring, Serial, etc.)

Figura 20 Protocolos do Windows NT

Modelo Protocolo TCP/IP

OSI/ISSO
Aplicao Aplicao
Apresentao FTP, SMTP e DNS
Camadas superiores Sesso Telnet
Camadas Inferiores Transporte TCP e UDP
Rede IP, ARP e ICMP
Link de Dados Link de Dados
Fsica Fsica
Figura 21 Protocolo TCP/IP

23
 A Internet utiliza o padro UDP, uma vez que as comunicaes baseadas no protocolo
TCP/IP se utilizam de portas de comunicao que, associadas aos sockets, permitem a troca de
mensagens.
O protocolo TCP/IP disponibiliza 999999 portas (comprovao emprica), sendo que
as portas de nmero 0 at a porta de nmero 1023 so reservadas para servios pr-
determinados, como por exemplo a porta 23, para o servio Telnet, a porta 21 para o FTP, e
assim por diante. Devido a este limite, caso a Internet utilizasse o padro TCP, as mquinas
que respondessem a um nmero muito grande de acessos, acabariam limitando a sua
utilizao.
No padro UDP, por sua vez, quando existe uma solicitao de comunicao, o
endereo IP do remetente da mensagem segue junto com a mensagem para o destinatrio, de
forma que o disponibilizador do servio possa posteriormente enviar a resposta do servio
solicitado.
importante salientar que, para que as comunicaes transcorram normalmente, as
APIs no necessariamente precisam ser as mesmas, muito embora os protocolos devam ser os
mesmos, como pode ser visto na figura 22.

Funciona No Funciona
Cliente Servidor Cliente Servidor
Aplicao da Aplicao da Aplicao da Aplicao da
Rede Rede Rede Rede
API ( TLI) Winsock API Winsock API Winsock API
TCP/IP TCP/IP TCP/IP SPX/IPX

Figura 22 - Mesmo protocolo para uma comunicao correta

Os demais protocolos suportados pelo Windows NT, permitem a conexo com outros
tipos de plataformas, como pode ser visto na tabela 4.

Protocolo Plataforma
NetBEUI Microsoft
SPX/IPX Novell
Apple Talk Mcintosh
Tabela 4 - Demais protocolos do Windows NT

O protocolo NetBEUI de propriedade da Microsoft e permite a conexo com

mquinas que estejam com os ambientes Windows 3.x, Windows NT 3.x / 4.0 e Windows 95
(DAVIS,1994). Ele o responsvel pela camada de Transporte e Rede, acrescentando uma
extenso para a camada de Link de Dados. Conecta-se diretamente com o NetBIOS na camada
de sesso (RENAUD,1994), que oferece as funcionalidades de transporte e rede do NetBEUI,
como por ser visto na figura 15. Possui dois tipos de frames, um para fornecer um fluxo de
dados confivel e o outro para frames de informao no numerados usados em Datagramas.
Os protocolos SPX/IPX so uma implementao dos protocolos XNS da Xerox. O
protocolo SPX, igual ao SPP da Xerox, oferece um servio de fluxo de dados confivel,

24
enquanto que o IPX, igual ao IDP, oferece um servio de datagrama, permitindo a conexo
entre mquinas do tipo PC que estejam rodando o Sistema Operacional de Rede da Novell
(RENAUD,1994).
Por sua vez, o protocolo Apple Talk permite a conexo com mquinas da plataforma
Macintosh, e um protocolo totalmente particular. Os principais protocolos usados por
mquinas Macintosh so os DDP - Datagram Delivery Protocol, ATP - AppleTalk
Transaction Protocol e ADSP - AppleTalk Data Stream Protocol (RENAUD,1994).

4.5 - Sockets

O Socket teve origem na Universidade de Berkeley, como sendo a API (Application

Programming Interface) de desenvolvimento do protocolo TCP/IP para o ambiente UNIX
(COMER,1993). Ele um dos mecanismos que o IPC possui para a troca de mensagens entre
processos.
Um Socket similar a um descritor de arquivo. Ele identifica o ponto final (endpoint)
para a comunicao e implementado como um inteiro positivo (ROBERTS,1995).
Existe uma diferena sutil, porm importante, entre descritores de arquivos e socket.
Um descritor de arquivo ligado a um arquivo ou dispositivo especfico quando criado pelo
comando open. Um descritor de socket no ligado a local algum quando criado pelo
comando socket. Uma aplicao pode decidir ligar-se a um endereo explicitamente usando
um comando bind, ou pode fornecer endereos dinamicamente quando envia datagramas
usando o comando send. Portanto, sockets podem ser usados como uma interface para
transportes de rede baseados em conexo e sem conexo (COMER,1993) (DUMAS,1995).
O socket, que um manipulador (handle), est associado a um largo conjunto de dados
armazenados na implementao do protocolo de rede. O termo socket usado no S.O. UNIX
para fornecer uma interface tipo arquivo s redes. Quando uma operao para criar um socket
chamada, o sistema retorna um manipulador, como descritor de socket. Esse descritor
usado em todos os outros comandos relacionados ao socket e intercambivel com o descritor
de arquivo usado em funes read e write.
Os dados associados ao socket incluem vrias informaes, como o endereo IP das
mquinas que esto se conectando, as portas dos dois lados da conexo TCP e o estado da
conexo corrente.
A camada de sockets dentro do contexto da comunicao corresponde a camada de
Sesso do Modelo OSI/ISO, que tem como funo o gerenciamento das sesses de
comunicao processo a processo entre os hosts. Ela tambm responsvel por estabelecer e
encerrar as conexes entre os aplicativos cooperantes (DUMAS,1995).
Dentro do protocolo TCP/IP, a camada TCP abrange a camada de Sesso e Transporte
do Modelo OSI/ISO, favorecendo diretamente a programao dos sockets sobre o protocolo
TCP/IP.
Para o ambiente Windows foi desenvolvido o Windows Sockets - Winsock, visando
facilitar a interconexo entre as estaes Windows, atravs do protocolo TCP/IP, que base
para o acesso a Internet. Windows Sockets uma interface aberta para programao em rede
sob o Microsoft Windows (QUINN,1996).
A especificao da interface do Windows sockets define claramente a diviso entre a
aplicao de rede e o protocolo da rede.

25
 A sua verso mais recente o Winsock 2 (reviso 2.0.8 - 19/05/95). A verso 2.0 da
especificao do Windows sockets se associa a arquitetura que o Windows NT utiliza para
suportar mltiplos protocolos de fornecedores variados (QUINN,1996).
O Winsock API aumenta a funcionalidade dos sockets de Berkeley, ao acrescentar
extenses especficas do Windows para suportar a natureza orientada a mensagens do S.O.
baseado no Windows.
Todas as aplicaes que hoje em dia acessam a Internet diretamente da residncia do
usurio, usando FTP, E-mail, Finger, Telnet, SMTP, entre outros, utilizam os sockets como
base de comunicao, atravs do protocolo TCP/IP (ROBERTS,1995).
Os Sistemas Operacionais Windows NT e Windows 95 j possuem dentro de suas
bibliotecas, as rotinas para suportar a programao para o protocolo TCP/IP via sockets
(DAVIS,1994).
Para o ambiente Windows, o relacionamento entre as aplicaes e o ambiente de rede,
pode ser demonstrado na figura 23.

Aplicao 1 Aplicao n

Winsock.DLL

TCP/IP

Network card

Figura 23 - Relacionamento da biblioteca dos sockets no ambiente Windows

Na API do sockets possvel determinar se a comunicao que se vai estabelecer

com conexo - STREAM, ou sem conexo - DATAGRAMA.
Para se trabalhar numa comunicao baseada em conexo, na camada de transporte do
TCP/IP, o protocolo utilizado o TCP, determinando que somente aps o estabelecimento de
uma comunicao possvel efetuar troca de mensagens.
Para a abertura de uma conexo com sockets, necessrio que vrias funes da
biblioteca Winsock sejam chamadas. A figura 24 demonstra a seqncia de operaes tanto no
lado Servidor quanto no lado Cliente.
No caso de se estabelecer uma conexo Stream, o Servidor primeiramente
inicializado. A funo Socket() define o descritor no qual a aplicao se associar quando
desejar transmitir uma mensagem. Posteriormente a funo Bind() interliga o descritor ao
endereo IP da mquina servidora e a porta TCP/IP na qual as transmisses iro ocorrer. A
funo Listen() permite ao Servidor ficar escutando qualquer solicitao de conexo.

26
 Quando uma solicitao chega de
SERVIDOR CLIENTE um Cliente aps ativar a funo Connect(),
Socket() Socket() o Servidor cria um processo filho
mediante a funo Accept(), numa nova
Bind() porta TCP/IP. O pedido do Cliente
associado a esta porta, permitindo assim a
Listen() transferncia de dados pelas funes
Send()/Recv(), deixando, desta forma, a
Accept() Connect() porta original de conexo do Servidor livre
para efetuar novas conexes.
Send()/ Recv() Send()/ Recv() Ao trmino da comunicao, o
Cliente utiliza a funo CloseSocket() para
CloseSocket() CloseSocket()
fechar a conexo, liberando a porta do
processo filho do Servidor para ser ligada
Figura 24 - Conexo Stream
a outro processo de comunicao. O
Servidor s ir utilizar esta funo quando
for desligado.
Por sua vez, para uma comunicao sem
conexo, figura 25, a utilizao das funes de SERVIDOR CLIENTE
sockets tornam-se mais fceis de se implementar. Socket() Socket()
Porm, necessrio lembrar que a utilizao de
comunicao baseada em Datagramas determina Bind()
que as rotinas de recuperao das seqncias dos
pacotes entregues a rede devem ser programadas,
aumentando assim a possibilidade de falhas na
implantao do sistema.
A seqncia e as funes definidas para
uma conexo Datagrama so as mesmas da Send()/ Recv() Send()/ Recv()
conexo Stream, excluindo apenas as funes
CloseSocket() CloseSocket()
Listen(), Accept() e Connect(). Isto ocorre pelo
fato do protocolo baseado em Datagrama no
Figura 25 - Conexo Datagrama
utilizar uma conexo real entre as mquinas
origem e destino, implementando,
automaticamente dentro das funes de troca de
mensagens, Send()/Recv(), um cabealho com o endereo IP da mquina no qual ser feita a
comunicao.
Um ponto a ser observado, que, para a transmisso, tanto na funo Send() ou
Recv(), os sockets somente operam com dados do tipo Char.
Para a transmisso de dados puramente do tipo caracter, o sistema desenvolvido
baseado em sockets no impe nenhuma restrio. Entretanto, para sistemas desenvolvidos
sob o paradigma da Orientao a Objeto, que manipula tanto objetos simples, como
complexos ou longos, necessrio que, ao se transmitir, se faa uma converso da classe do
objeto para o tipo Char. No momento em que a informao chega ao seu destino, necessrio
que o receptor faa a reconverso, isto , do tipo Char para o tipo original do objeto.
Esta peculiaridade para a transmisso de dados de tipos diferentes de Char, faz com
que o destinatrio da mensagem possua o conhecimento prvio de todos os tipos possveis de
objetos que podem ser transmitidos.

27
4.5.1 - Interfaces de Comunicao utilizando Sockets

Windows sockets um dos mecanismos existentes para o desenvolvimento de

aplicaes em rede por meio de troca de mensagens. A compatibilizao entre as bibliotecas
de sockets de diferentes fornecedores permite a troca de bibliotecas sem afetar as aplicaes.
Como dito anteriormente, a API do Winsock representa uma barreira bem definida entre as
aplicaes de rede e os protocolos utilizados.
Para o desenvolvimento das interfaces de comunicao entre Cliente e Servidor foram
utilizadas bibliotecas (PEDRIANA,1996) disponibilizadas na Internet, e, consequentemente,
adaptadas para a comunicao entre os objetos do SIGO, uma vez que, a comunicao original
se baseava somente na troca de mensagens de dados do tipo Char. Esta biblioteca foi
construda em Borland C++ 4.5 e se constitui da comunicao entre mquinas Clientes e
Servidor por intermdio de sockets. Esta biblioteca veio ao encontro dos interesses do projeto,
j que o modo de comunicao baseado em RPC (Remote Procedure Call) no se constitua
num ambiente confivel para operaes que envolvessem objetos (AQUINO,1995).
A figura 26 mostra a relao do Modelo Windows sockets com o Modelo OSI/ISO.

Modelo Modelo Windows

OSI/ISO sockets
Aplicao
Apresentao Aplicao Windows
sockets
Camadas Sesso Winsock
superiores API
Camadas Transporte Protocolo TCP/IP
Inferiores
Rede
Link de Dados Driver de rede
Fsica Interface de rede
Figura 26 - Relao do Modelo Windows sockets com o Modelo OSI / ISO

Pode-se notar que a interao da aplicao com o protocolo TCP/IP faz-se somente
pela API que o Windows sockets disponibiliza, minimizando assim maiores possibilidades de
gerao de erros.
Para que se estabelea uma comunicao no padro TCP, faz-se necessrio seguir uma
seqncia de operaes pr-definidas como ilustrado na figura 2.21. O diagrama de estado da
seqncia de conexo Stream Socket, pode ser visto na figura 27.
O Servidor deve ser sempre colocado no ar, antes de qualquer tentativa de
comunicao. Para esta abertura de conexo com sockets, necessrio que vrias funes da
biblioteca Winsock sejam chamadas.
A funo Socket define o socket, que um descritor a partir do qual a aplicao se
associar quando desejar transmitir uma mensagem. O Servidor, por sua vez, executa outras
duas funes que so disparadas em seqncia: a funo Bind, que associa o nmero de uma
porta com o endereo IP da mquina servidora, e a funo Listen, que fica escutando na
porta selecionada esperando que haja uma solicitao de conexo.

28
 Quando a funo Connect for ativada pelo Cliente, uma solicitao de conexo para o
Servidor enviada e, caso a resposta a esta solicitao seja afirmativa, o Cliente e o Servidor
passam para o estado de conectado.

nomeado e
escutando
recebido requisio
de conexo

conexo fechamento
Bind() e
pendente pendente
Listen()
solicitao de
Accept() fechamento Closesocket()
Socket()

Connect() Closesocket()
abrir conectado socket
conexo (escrevendo) fechado

chegada falha de Buffers de

de dados leitura de envio sada
Recv() todos Send()
dados leitura de
Preparado chegada todos No preparado
para leitura de dados dados para escrita
OOB OOB
dados falha de
Preparado p/ envio
recebidos
ler dados OOB

Figura 27 - Diagrama de estado do Stream Socket

Uma vez estabelecida a conexo, a troca de mensagem passa a ser efetuada e a funo
Recv retira do buffer de leitura as informaes que foram trocadas entre o Cliente e o
Servidor. Caso no se consiga enviar alguma mensagem pela funo Send, por causa do
estouro da capacidade do buffer, os dados so armazenados e retransmitidos posteriormente.
Os dados OOB (Out-of_Band) possuem um nvel de prioridade de transmisso acima
dos outros dados. Isto possibilita uma alterao na seqncia a ser transmitida, porm esta
interferncia na seqncia fica transparente ao usurio.
Ao trmino da comunicao, o Cliente utiliza a funo CloseSocket para fechar a
conexo, liberando a porta do processo filho do Servidor para ser ligada a outro processo de
comunicao. O Servidor s ir utilizar esta funo quando ele for desligado.
Portanto, primeiro o Servidor posto no ar (1), em seguida o Cliente escolhe o nome
de Servidor e a porta no qual sera feita a conexo (2a) e solicita uma conexo (2b), quando a
conexo aceita, o Servidor cria um processo filho, numa nova porta TCP/IP (3), associando
o pedido do Cliente esta porta, permitindo assim a troca de mensagens (4), deixando a porta

29
original da conexo do Servidor livre para efetuar novas conexes, como pode ser visto na
figura 28.

(1) Servidor no ar
Porta 2450
(2 b) Solicitao de Conexo
Servidor
(2a) Cliente no ar
Nome do
servidor e Porta
(3) Criao 2450
Cliente
Processo Filho

Servidor 4o ) Comunicao Cliente/Servidor

Processo Filho
do Servidor
Porta 1111
Figura 28 - Criao de Processo Filho para a comunicao

Caso ocorra uma perda de conexo, tanto por parte do Cliente quanto pelo Servidor
sem antes ter sido efetuada a funo CloseSocket, quem ainda estiver no ar no poder
reutilizar a porta que estava sendo utilizada at que o seu fechamento se d de forma correta.
Para evitar que problemas desta natureza possam vir a ocorrer, necessrio o
desenvolvimento de uma funo de Time-out, de modo a proporcionar um nvel de segurana
ainda maior para as conexes.
A funo de Time-out fica checando se existe troca de informaes nas conexes
existentes, e permite que a funo CloseSocket seja ativada automaticamente ao se verificar a
inexistncia de qualquer tipo de troca de mensagem aps um determinado tempo,
possibilitando assim a otimizao das portas do protocolo TCP/IP.

5 - Bancos de Dados Orientados a Objetos

5.1 - Introduo

Os Sistemas Gerenciadores de Bancos de Dados Orientados a Objetos (SGBDOOs)

surgiram da necessidade de suportar a programao orientada a objeto. Era necessrio um
repositrio de dados para guardar os objetos criados pelas linguagens OO tais como a
Smalltalk e a C++, entre outras. Esses objetos eram conhecidos como objetos persistentes
(MARTIN,1994) (NAVATHE,1994), ou seja, dados que permanecem no sistema aps a
concluso de um processo.
Os SGBDOOs tornaram-se importantes para certos tipos de aplicaes com dados
complexos, tais como CAD (Computer Aided Design) e CAM (Computer Aided
Manufacturing) e o SIG (Sistemas de Informaes Geogrficas), servindo tambm para
manipular BLOBs (Binary Large Objects), a exemplo de imagem, som, vdeo, texto e
transaes de longa durao (MARTIN,1994) (NAVATHE,1994) (KHOSHAFIAN,1993)
(RUMBAUGH,1994).

30
 A classificao dos Banco de Dados desde os relacionais (SGBDR) at os OO pode ser
vista na figura 29 (POET,1997).
Os SGBDOOs existentes tais como Versant, O2, Poet, GemStone, Itasca, entre outros,
j incorporam caractersticas de comunicao baseadas na arquitetura Cliente/Servidor.

SGBDR Puro SGBDR com um pouco BDO - Front End BDO Esttico BDO Ativo
de OO
para um BDR

DB2 Sybase / Oracle OpenODB / O2 / Ontos / ODI / GemStone / Itasca

Persistence Objectivity / POET / / Matisse / IDB
Versant

Figura 29 - Classificao dos SGBDR e SGBDOO

5.2 - Alguns SGBDOOs e suas verses Cliente/Servidor

5.2.1 - SGBDOO O2

O sistema O2 possui uma verso workstation e outra server, sendo que as duas verses
possuem quase a mesma interface. A principal distino na implementao: a verso
workstation monousurio, enquanto que o server multiusurio, possuindo total controle
nas aes com o disco. S atravs do server pode-se fazer acesso a qualquer tipo de
informao armazenada em disco (BANCILHON,1992).
O O2 constitudo por 8 mdulos funcionais em sua arquitetura. Entre eles pode-se
destacar o mdulo OM (Object Manager) que composto pelo COM (Complex Object
Manager), MPM (Message-Passing Manager), TM(Transaction Manager), CM (Clustering
Manager) e o IM (Index Manager).
O OM possui uma camada intermediria na qual gerencia o buffer de objetos (BM -
Buffer Manager) e a camada de comunicao (CM - Communications Manager). No server, o
gerente de comunicaes fica escutando as requisies das workstations e dispara o
processamento dos mdulos correspondentes.
O gerente de comunicao do O2 desenvolvido baseado em 4 critrios:
A simplicidade, que se traduz na portabilidade, conseguida pela escolha de
ferramentas bem definidas e o protocolo de comunicao utilizado para a conexo
entre Cliente e Servidor o TCP/IP.
A transparncia resulta no fato de que o usurio final no reconhece de onde as
informaes esto sendo obtidas.
A performance obtida pela otimizao do protocolo de comunicao que permite
a transferncia de objetos sem que resulte na criao de gargalos numa arquitetura
Cliente/Servidor.
Finalmente, a confiana, que obtida pelo mecanismo de deteco de falhas que
consegue prevenir o travamento do sistema por possveis finalizaes anormais dos
processos envolvidos na comunicao.

Quando um processo inicializado em uma workstation, um processo espelho

inicializado no server com o intuito de interagir com as camadas mais baixas do sistema. Aps
a comunicao ser estabelecida, os objetos so transferidos independentemente de um lado
31
para o outro. Contudo, quando uma quantidade grande de objetos transferida, primeiramente
eles so empacotados para minimizar os acessos a rede.

5.2.2 - SGBDOO GemStone

O OODBMS GemStone (GEMSTONE,1997), que utiliza a tcnica de objetos

distribudos, oferece uma arquitetura Cliente/Servidor escalvel e robusta com o seu sistema
de controle de objetos. A comunicao do GemStone se baseia no ORB (Object Request
Broker), que por sua vez utiliza o CORBA (Common Object Request Broker Architecture)
para organizar os padres dos objetos que serviro para a troca de mensagens. A OMG
(Object Management Group) garante ento, os padres de interoperabilidade entre os sistemas
de objetos gerenciados pelo CORBA, como visto nas figuras 30 e 31.
A OMG deliberou os seguintes padres de trabalho para o Inter-ORB:
o GIOP (General Inter-ORB Protocol) que especifica o formato das
mensagens e a representao dos dados para toda a intercomunicao do
ORB. O GIOP garante, portanto, que a ordenao dos bytes transmitidos
no so problemas entre os ORBs existentes.
o IIOP (Internet Inter-ORB Protocol) que permite a ligao entre o GIOP e
o protocolo de comunicao TCP/IP.

O CORBA 2.0 possui ambos os protocolos de comunicao: o GIOP e o IIOP.

A arquitetura de objetos distribudos do CORBA estende os limites do GemStone para
as linguagens de objetos adicionais, interfaces de programao de aplicaes e para servios
no objetos.
A adoo da padronizao CORBA garante a interoperabilidade entre os diversos
sistemas de objetos nas empresas.
A grande migrao da indstria de sistemas monolticos para sistemas distribudos, fez
com que a OMG focasse o CORBA como seu ponto de ao central, reunindo seus esforos
para a padronizar os objetos componentes de sistemas de informaes distribudos.
A plataforma Windows desenvolve seus aplicativos baseados na tecnologia de objetos
distribudos atravs do COM (Component Object Model) e o OLE (Object Linking and
Embedding).

Figura 30 - Camada ORB para comunicao do GemStone

32
 Figura 31 - Padronizao CORBA para a Comunicao de Objetos Distribudos

5.2.3 - SGBDOO POET

Outro OODBMS conhecido que tambm possui uma arquitetura Cliente/Servidor o

POET. O POET Engine e a aplicao cliente coexistem como um processo sem qualquer
sobrecarga na comunicao (POET,1997).
A firmeza no gerenciamento dos dados junto com as facilidades da API disponveis,
permite ao usurio desenvolver aplicativos com caractersticas Cliente/Servidor, com uma
total transparncia da localizao dos dados.
Uma aplicao pode abrir mltiplos banco de dados, que podem ser locais ou remotos.
O UOS (Universal Object Server) do POET emprega uma arquitetura Cliente/Servidor
convencional, na qual mltiplos clientes acessam um ou mais servidores atravs da rede. Esta
estrutura de comunicao representa uma arquitetura Cliente/Servidor em dois nveis
formando uma comunicao mista podendo ser vista na figura 2.2c.
O UOS utiliza protocolos de rede padro como o TCP/IP e o IPX/SPX, permitindo
assim a operao transparente em redes homogneas ou heterogneas, fornecendo ao usurio o
mximo de flexibilidade.
O sistema POET suporta tanto single-threaded quanto multi-threaded. Os clientes
single-threaded incluem um thread-safe API que permite a serializao das chamadas para
API do POET. Portanto, quando ocorre uma chamada, esta chamada fica em estado de
bloqueio. Os clientes multi-threaded suportam sistemas operacionais multi-threaded,
incluindo o Windows NT, OS/2 e UNIX
Single-threaded uma operao sequencial na qual so alocadas as informaes
pertinentes ao processo, tais como identificao do processo e rea de memria utilizada em
cada thread criado. Entretanto, Multi-threaded permite o compartilhamento destas
informaes, quando da criao de processos filhos no processo pai, otimizando assim, a
utilizao da memria (PHAM,1996).
Os clientes incorporam a arquitetura de mltiplos leitores / nico escritor, (multiple
reader/single writer) usando consultas no bloqueadas e canais de comunicao simultneos
para um ou mais servidores POET

33
6 - Concluso

Atualmente, a maioria das empresas est migrando para a computao distribuda,

atravs de uma arquitetura Cliente/Servidor. Por ser uma rea nova, necessrio o
investimento em equipamentos, pessoal, treinamento e servios para conseguir responder a
demanda deste mercado globalizado.
A importncia e a credibilidade desta tecnologia podem ser verificadas em funo de
grandes empresas, tais como: Oracle, Sybase, Informix, Digital e IBM, que desenvolveram
solues para atender a essa nova plataforma. Esta oferece acesso a dados localizados em
diferentes Servidores, sem que o usurio perceba que eles podem estar vindo at de pases
diferentes, realidade facilmente conseguida atravs da Internet. Esta facilidade permite uma
integrao entre micros, mainframes e redes, a fim de se obter o melhor que a computao
distribuda pode oferecer.
Este relatrio apresentou as caractersticas bsicas da arquitetura Cliente/Servidor.
A arquitetura Cliente/Servidor demonstra que veio realmente para ficar, e nada indica
que um novo modelo esteja prestes a tirar o seu lugar.
Para acompanhar o avano tecnolgico nesta rea, esta arquitetura foi implementada
no SIGO (Sistema Gerenciador de Objetos) (MOURA,1997), transformando-o de um sistema
monousurio em um sistema multiusurio (DESCHAMPS,1997).

34
Referncias Bibliogrficas

1. (AMARAL,1993) Amaral, W. H. Arquitetura Cliente/Servidor Orientada a Objeto

Tese de Mestrado, IME, 1993.

2. (ANDREWS,1991) Andrews, G. R. Concurrent Programming: Principles and Practice

Benjamin/Cummings, Redwood City, CA, 1991.

3. (AQUINO,1995) Botelho, Toms de Aquino Tinoco, Anlise de Desempenho da

Arquitetura Cliente/Servidor Orientada a Objeto, Tese de Mestrado, IME,
Dezembro/1995.

4. (BANCILHON,1992) Bancilhon, F. et al Building an Object-Oriented Database System:

The Story of O2, Morgan Kaufmann, 1992.

5. (COMER,1993) Comer, Douglas E. & STEVENS, David L. Internetworking With

TCP/IP Vol.III: Client/Server Programming and Application (Socket Version). Prentice
Hall, Englewood Cliffs, New Jersey, USA, 1993.

6. (CUSTER,1993) Custer, Helen Windows NT, Microsoft Press, Makron Books, So

Paulo, 1993.

7. (DAVIS,1994) Davis, Ralph Windows NT Networking Programming Addison Wesley,

1994

8. (DESCHAMPS,1997) Deschamps, Eduardo R.P. Sistema Gerenciador de Objetos em

um Arquitetura Cliente/Servidor, Tese de Mestrado, IME, Abril/1997.

9. (DUMAS,1995) Dumas, Arthur Programando WinSock, Axcel Books, Rio de Janeiro,

1995.

10. (GEMSTONE,1997) GemStone Inc. GemStones Role in CORBA System

http://gemstone.com/Products/WP/corbawp.htm.

11. (HULQUIST,1997) Hultquist, Steve <ssh@vnet.ibm.com> FAQ about Client/Server

http://non.com/news.answers/client-server-faq.html, 1997

12. (KALAKOTA,1997) Kalakota, Ravi FAQ about Client/Server

<kalakota@uhura.cc.rochester.edu> http://non.com/news.answers/client-server-faq.html.

13. (KHOSHAFIAN,1993) Khoshafian, Setrag Object Oriented Database, John Wiley &
Sons, Inc. , Canad, 1993.

14. (LEFEBVRE,1994) Lefebvre, Alain LArchitecture Client-Serveur, Armand Colin, 2e

dition, 1994.

35
15. (MARTIN,1994) Martin, James Princpios de Anlise e Projeto baseados em Objetos
Ed. Campus, Rio de Janeiro, 1994.

16. (MCKIE,1997) McKie, Stewart Everything you wanted to know about Client/Server
computing but were afraid to ask Eye on Technology,
http://www.duke.com/controller/Issues/DecJan/Clientse.htm

17. (MOURA,1997) Moura, A.M.C.; Freitas, Luciani et al; SIGO: Ambiente para
Desenvolvimento de Aplicaes No-Convencionais em Banco de Dados Relatrio
Tcnico, RT016/DE9/ABR97, IME, Rio de Janeiro, Abri/1997.

18. (NAVATHE,1994) Navathe, Shamkant B. & Elmasri, Ramez Fundamentals of Database

Systems 2nd Ed., Benjamin Cummings, CA, 1994.

19. (PEDRIANA,1996) Pedriana, Paul OWLSock - Implementation <paulp@ccnet.com>,

http://users.ccnet.com/~paulp/owlsock/html/download.htm.

20. (PHAM,1996) Pham, Thuam Q. & Garg, Pankaj K. Multithreaded Programming with
Windows NT Prentice Hall, 1996.

21. (POET,1997) POET Software About Object Database

http://www.poet.com/t_oovsre.htm.

22. (QUINN,1996) Quinn, Bob & Shute, Dave Windows Sockets Network Programming
Addison Wesley, 1996

23. (RENAUD,1994) Renaud, P. E. Introduo aos Sistemas Cliente/Servidor IBPI Press,

RJ 1993.

24. (ROBERTS,1995) Roberts, Dave Developing for the Internet with Winsock Coriolis
Group Books, 1995.

25. (RUMBAUGH,1994) Rumbaugh, James et al Modelagem e Projetos baseados em

Objetos Ed. Campus, Rio de Janeiro, 1994.

26. (SALEMI,1993) Salemi, Joe. Banco de Dados Cliente/Servidor . IBPI Press, 1993.

27. (TANENBAUM,1995) Tanenbaum, Andrew S. Distributed Operating Systems Prentice

Hall, 1995.

28. (TANENBAUM,1996) Tanenbaum, Andrew S. Computer Networks Prentice Hall,

Third Edition, 1996.

29. (TAROUCO,1986) Tarouco, L. M. R. Redes de Computadores. McGraw-Hill ,SP

1986.

30. (VIDAL,1994) Vidal, Paulo Csar Salgado. Modelagem para Arquitetura

Cliente/Servidor Orientada a Objeto. Tese de Mestrado, IME, 1994.
36