Fundamentos da Arquitetura Cliente/Servidor

SUMRIO

1 - INTRODUO 2 - ARQUITETURA CLIENTE/SERVIDOR 2.1 - VANTAGENS 2.2 - DESVANTAGENS 2.3 - MODELOS DA ARQUITETURA CLIENTE / SERVIDOR 2.3.1 - Arquitetura C/S Simples 2.3.2 - Arquitetura C/S em Dois Nveis 2.3.3 - Arquitetura C/S Multinvel 2.3.4 - Arquitetura C/S Par-Par 3 - ALGUNS TIPOS DE PROCESSOS NUMA ARQUITETURA CLIENTE/SERVIDOR 3.1 - PROCESSAMENTO DISTRIBUDO 3.2 - CAMADAS DA ARQUITETURA CLIENTE / SERVIDOR 3.2.1 - Sistema de Trs Camadas para a Aplicao
3.2.1.1 - Apresentao Distribuda 3.2.1.2 - Apresentao Remota 3.2.1.3 - Lgica Distribuda 3.2.1.4 - Gerenciamento de Dados Centralizado 3.2.1.5 - Gerenciamento de Dados Distribudos

1 1 3 3 4 4 4 5 6 6 7 9 12
13 14 14 15 15

4 - REDES DE COMPUTADORES 4.1 - PROTOCOLOS 4.1.1 - O Modelo de Referncia OSI/ISO 4.1.2 - TCP/IP 4.2 - ASPECTOS DE CONEXO 4.3 - ASPECTOS DE SINCRONISMO E PASSAGEM DE MENSAGEM 4.4 - CONEXO TCP/IP 4.5 - SOCKETS 4.5.1 - Interfaces de Comunicao utilizando Sockets 5 - BANCOS DE DADOS ORIENTADOS A OBJETOS 5.1 - INTRODUO 5.2 - ALGUNS SGBDOOS E SUAS VERSES CLIENTE/SERVIDOR 5.2.1 - SGBDOO O2 5.2.2 - SGBDOO GemStone 5.2.3 - SGBDOO POET 6 - CONCLUSO REFERNCIAS BIBLIOGRFICAS

16 16 17 18 20 21 22 25 28 30 30 31 31 32 33 34 35

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

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

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 SERVIDOR CLIENTE 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.

Modelo de Distribuio de Processos

Apresentao Apresentao Apresentao Apresentao Apresentao Lgica de Negcio Lgica de Negcio Lgica de Nogcio Gerncia de Dados Apresentao

Rede

Lgica de Negcio Gerncia de Dados

Lgica de Negcio Gerncia de Dados

Lgica de Negcio Gerncia de Dados Gerncia de Dados

Gerncia de Dados

Apresentao Distribuda

Apresentao Remota

Lgica Distribuda

Gerenciamento de Gerenciamento de Dados Centralizado Dados Distribudo

Fonte: Gartner Group

Figura 6 - Arquitetura da Aplicao Cliente/Servidor

Processamento Distribudo
Processamento

Processamento Centralizado

Processamento 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 8 B C

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

Servidor de Arquivos
Cliente Aplicao Gerenciador de Banco de Dados Servidor Aplicao

Redirecionador do Sistema de Arquivos

Sistema de Arquivos

Hardware

Hardware

Figura 9 - Arquitetura Cliente/Servidor como Servidor de Arquivo

Neste tipo de estrutura, a camada de Aplicao passa a ser o Cliente do Sistema. Com isto, a camada de Servio do Sistema utilizada simplesmente como um redirecionador para acesso base de dados (RENAUD,1994). Neste tipo de configurao pode-se chamar este Sistema como falso Sistema Cliente/Servidor, por 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 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 Aplicao API do Gerenciador de Banco de Dados Servidor Gerenciador de 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. Podese 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 Negcio Lgica de Negcio Lgica de Nogcio Gerncia de Dados Apresentao

Rede

Lgica de Negcio Gerncia de Dados

Lgica de Negcio Gerncia de Dados

Lgica de Negcio Gerncia de Dados Gerncia de Dados

Gerncia de Dados

Apresentao Distribuda

Apresentao Remota

Lgica Distribuda

Gerenciamento de Gerenciamento de 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. Existe uma tcnica de tratamento cooperativo, Rede denominada de Revamping, que utilizado pela Apresentao Distribuda.
Apresentao Lgica de Negcio Gerncia de Dados Apresentao Distribuda

O Revamping uma tcnica de tratamento cooperativo que est dividida em trs tipos: simples, evoludo e o modificado (LEFEBVRE,1994).

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 Remota, e possui a implementao tanto do mdulo de gesto, quanto o de lgica na 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 se localize no Terminal X-Windows, ele realmente est se utilizando do Servidor X-Windows. O terminal real Cliente onde o usurio est conectado. Esta caracterstica muito encontrada em ambientes UNIX. O Servidor X-Windows fica responsvel pela manipulao das telas e interao com o usurio. 3.2.1.3 - Lgica Distribuda Outra representao a arquitetura da Lgica Distribuda. Ela representa o melhor modelo de implementao para arquitetura Cliente/Servidor. Nela, o balano entre os processamentos clientes e servidores so bem determinados. Neste tipo de arquitetura, a implantao de procedimentos armazenados (Stored Procedures) facilitam a performance na rede de comunicao, uma vez que somente o nome do procedimento armazenado no Servidor transmitido pela rede. Um ponto muito positivo para este tipo de estrutura se refere a prcompilao necessria para os procedimentos armazenados, aumentando consideravelmente o tempo de resposta. Quando os procedimentos
14

Apresentao Rede

Lgica de Negcio Gerncia de Dados Apresentao Remota

Fonte: Gartner Group

Apresentao Lgica de Negcio

Rede

Lgica de Negcio Gerncia de Dados Lgica Distribuda

Fonte: Gartner Group

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 gesto e lgica da Aplicao fica destinada ao Cliente, enquanto que somente o responsvel por prover o armazenamento e a persistncia dos dados permanece no Servidor, como por exemplo 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 da migrao de plataformas mainframes para plataformas desktop do tipo PC (Personal Computer).
Apresentao Lgica de Negcio

Rede

Gerncia de Dados Gerenciamento de Dados Centralizados

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

15

Fonte: Gartner Group

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
Modo Execuo Finalidade Principal

Cliente
Ativo Incio e final fixos 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 Oculta rede e servidores Comunicao com diferentes servidores Comunicao Cliente - Cliente

Servidor
Reativo Roda o tempo todo 1. Oferecer servios funcionais 2. Compartilhamento de dados na aplicao 3. Compartilhamento de dispositivos

Transparncia Inclui Exclui

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 Camada de Apresentao Camada de Sesso Camada de Transporte Camada de Rede Camada de Enlace Camada de Fsica
- Seleo de servios apropriados aplicao. - Formatao/Reformatao de dados. Ex.: Criptografia. - Interface do usurio para o estabelecimento de conexes. - Controle de intercmbio de mensagens entre usurios. - Controle de intercmbio de mensagens na rede. - Transmisso livre de erros. - 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 Aplicao Apresentao Sesso Transporte NetBEUI Rede Enlace Token Ring Fsica Par Tranado IEEE LLC Ethernet Coaxial IP PU 2.1 SDLC Canais Nomeados (Named Pipes) NetBIOS Internet RPC XDR sockets TCP LU 6.2 IBM APPC

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

Classe A B C D E

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

0 1 1 1 1

ID da Rede

ID do Host ID da Rede ID do Host ID da Rede Endereo de Multi-Transmisso Reservado ID do Host

0 1 0 1 1 0 1 1 1 0

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 A B C D E Num. de Redes 128 16.284 + 2M Endereo de Rede 0.0.0.0 - 127.0.0.0 128.0.0.0 - 191.255.0.0 192.0.0.0 223.255.255.255 224.0.0.0 239.255.255.255 240.0.0.0 255.255.255.255 Tabela 2 - Limite do nmero de redes e hosts em cada endereo IP Num. de Hosts + 16M 65.136 256 Endereo de Hosts 0.0.0 - 255.255.255 0.0 - 255.255 0 - 255

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
Tipo de Mensagem Rota Endereamento de Mensagem

Baseado em Conexo
Fluxo de dados Esttica Endereo de destino completo para estabelecer circuito; depois somente o ID do circuito Seqenciado, controle de erro e fluxo, entrega garantida Podem ser negociadas durante a preparao Explcito Preparao e liberao do circuito

Sem Conexo
Datagrama Dinmica Endereo de destino completo em todas as mensagens Sem garantias: mensagens podem ser perdidas ou chegar fora de ordem No disponveis Implcito Rota da mensagem

Confiabilidade

Opes Sincronismo Overhead 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 Solicitante Processo 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 APIs proprietrias (opcional) Aplicao Windows sockets APIs proprietrias (opcional) Aplicao (cont.) APIs proprietrias (opcional) Aplicao (cont.) APIs proprietrias (opcional) Aplicao (cont.)

6 5

Aplicao Windows sockets

Aplicao (cont.) Windows Socket API

Windows sockets Dynamic Link Library (Winsock.DLL)

APIs proprietrias

4 3 2 1

TCP/IP

DECNet

NetBEUI Driver de APIs padres

Appletalk

SPX/IPX

Driver de Protocolos Mltiplos (ODI, Packet Driver, NDIS) APIs de Hardware proprietrio Interface de Rede (Ethernet, Token Ring, Serial, etc.)

Figura 20 Protocolos do Windows NT

Modelo OSI/ISSO
Camadas superiores Camadas Inferiores Aplicao Apresentao Sesso Transporte Rede Link de Dados Fsica

Protocolo TCP/IP
Aplicao FTP, SMTP e DNS Telnet TCP e UDP IP, ARP e ICMP Link de Dados 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 prdeterminados, 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
Cliente Aplicao da Rede API ( TLI) TCP/IP Servidor Aplicao da Rede Winsock API TCP/IP

No Funciona
Cliente Aplicao da Rede Winsock API TCP/IP Servidor Aplicao da Rede Winsock API 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 NetBEUI SPX/IPX Apple Talk Plataforma Microsoft Novell 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

SERVIDOR
Socket() Bind() Listen() Accept() Send()/ Recv() CloseSocket()

CLIENTE
Socket()

Connect() Send()/ Recv() CloseSocket()

Figura 24 - Conexo Stream

Quando uma solicitao chega de um Cliente aps ativar a funo Connect(), o Servidor cria um processo filho mediante a funo Accept(), numa nova porta TCP/IP. O pedido do Cliente associado a esta porta, permitindo assim a transferncia de dados pelas funes Send()/Recv(), deixando, desta forma, a porta original de conexo do Servidor livre para efetuar novas conexes. 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 for desligado.

Por sua vez, para uma comunicao sem CLIENTE conexo, figura 25, a utilizao das funes de SERVIDOR 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 Send()/ Recv() Send()/ Recv() uma conexo Datagrama so as mesmas da 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 OSI/ISO Aplicao Apresentao Camadas superiores Camadas Inferiores Sesso Transporte Rede Link de Dados Fsica

Modelo Windows sockets Aplicao Windows sockets Winsock API Protocolo TCP/IP

Driver de rede 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 pendente Accept() Socket() abrir conexo Connect() conectado (escrevendo) Closesocket() socket fechado solicitao de fechamento fechamento pendente Closesocket()

Bind() e Listen()

chegada de dados Recv() Preparado para leitura dados recebidos

leitura de todos dados chegada de dados OOB

falha de envio leitura de todos dados OOB

Buffers de sada Send() No preparado para escrita falha de envio

Preparado p/ 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 2450

(3) Criao Processo Filho

Cliente

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 de OO BDO - Front End para um BDR BDO Esttico BDO Ativo

DB2

Sybase / Oracle

OpenODB / Persistence

O2 / Ontos / ODI / Objectivity / POET / Versant

GemStone / Itasca / Matisse / IDB

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. (ANDREWS,1991) Andrews, G. R. Concurrent Programming: Principles and Practice Benjamin/Cummings, Redwood City, CA, 1991. (AQUINO,1995) Botelho, Toms de Aquino Tinoco, Anlise de Desempenho da Arquitetura Cliente/Servidor Orientada a Objeto, Tese de Mestrado, IME, Dezembro/1995. (BANCILHON,1992) Bancilhon, F. et al Building an Object-Oriented Database System: The Story of O2, Morgan Kaufmann, 1992. (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. (CUSTER,1993) Custer, Helen Windows NT, Microsoft Press, Makron Books, So Paulo, 1993. (DAVIS,1994) Davis, Ralph Windows NT Networking Programming Addison Wesley, 1994 (DESCHAMPS,1997) Deschamps, Eduardo R.P. Sistema Gerenciador de Objetos em um Arquitetura Cliente/Servidor, Tese de Mestrado, IME, Abril/1997. (DUMAS,1995) Dumas, Arthur Programando WinSock, Axcel Books, Rio de Janeiro, 1995. Role in CORBA System

2.

3.

4.

5.

6.

7.

8.

9.

10. (GEMSTONE,1997) GemStone Inc. GemStones 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 http://www.poet.com/t_oovsre.htm. About Object Database

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 Cliente/Servidor Orientada a Objeto. Tese de Mestrado, IME, 1994.
36

para

Arquitetura