Fundamentos Da Arquitetura De Computadores | Modelo Cliente – Servidor | Servidor (Computação)\nSalvarSalvar Fundamentos Da Arquitetura De Computadores para ler mais tarde\n913 visualizações37 páginas\nTécnicas de Tolerância a Falhas Técnicas de Tolerância a Falhas em Sistemas Distribuídoshas Em Sistemas Distribuídos\nFundamentos da Arquitetura Cliente/Servidor\n2 - ARQUITETURA CLIENTE/SERVIDOR\n2.3 - MODELOS DA ARQUITETURA CLIENTE / SERVIDOR\n2.3.1 - Arquitetura C/S Simples\n2.3.2 - Arquitetura C/S em Dois Níveis\n2.3.3 - Arquitetura C/S Multinível\n2.3.4 - Arquitetura C/S Par-Par\n3 - ALGUNS TIPOS DE PROCESSOS NUMA ARQUITETURA CLIENTE/SERVIDOR\n3.2 - CAMADAS DA ARQUITETURA CLIENTE / SERVIDOR\n- Sistema de Três Camadas para a Aplicação\n3.2.1.1 - Apresentação Distribuída\n3.2.1.2 - Apresentação Remota\n3.2.1.3 - Lógica Distribuída\n3.2.1.4 - Gerenciamento de Dados Centralizado\n3.2.1.5 - Gerenciamento de Dados Distribuídos\n4 - REDES DE COMPUTADORES\n4.1.1 - O Modelo de Referência OSI/ISO\n4.1.2 - TCP/IP\n4.2 ASPECTOS DE CONEXÃO\n4.3 ASPECTOS DE SINCRONISMO E PASSAGEM DE MENSAGEM\n4.4 CONEXÃO TCP/IP\n4.5 - SOCKETS\n- Interfaces de Comunicação utilizando Sockets\n5 - BANCOS DE DADOS ORIENTADOS A OBJETOS\n5.2 - ALGUNS SGBDOOS E SUAS VERSÕES CLIENTE/SERVIDOR\n5.2.1 - SGBDOO O 2\n5.2.2 - SGBDOO GemStone\n5.2.3 - SGBDOO POET\nEste relatório tem por objetivo mostrar as características técnicas que envolvem a Arquitetura Cliente/Servidor, desde a sua concepção teórica até a implantação da comunicação entre Cliente e Servidor por meio de uma biblioteca de Sockets. No item 2 será definido a parte teórica da Arquitetura Cliente/Servidor bem como alguns aspectos de definição desta arquitetura, além de mostrar os modelos existentes para implantação desta arquitetura. Em 3 serão mostrados alguns tipos de processamentos existentes, porém enfocando o processamento distribuído. Em 4 serão vistos os conceitos básicos sobre Rede de Comunicação, enfatizando o protocolo TCP/IP e a biblioteca de Sockets. Em 5 são apresentadas as características técnicas de alguns SGBDOOs numa arquitetura Cliente/Servidor. Finalmente, em 6, é feita uma breve conclusão com respeito ao modelo de arquitetura apresentado.\nA arquitetura Cliente/Servidor vem sendo desenvolvida há vários anos, porém em pequenos passos. Primeiro, a realocação de aplicações em Mainframe para as chamadas plataformas abertas rodando, Sistema Operacional UNIX. Depois, com relação a abordagem dos dados, saindo de Sistemas de Arquivos ou Banco de Dados Hierárquicos locados em Mainframes para Sistemas de Banco de Dados Relacional, e posteriormente, a importância da capacidade gráfica dos pacotes de “front-end” existentes, facilitando a interação com o usuário\nVários aspectos sobre uma definição da arquitetura Cliente/Servidor podem ser descritos.\n⇒ O termo Cliente/Servidor refere-se ao método de distribuição de aplicações computacionais através de muitas plataformas. Tipicamente essas aplicações estão divididas entre um provedor de acesso e uma central de dados e numerosos clientes contendo uma interface gráfica para usuários 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 serviços aos outros. Este modelo permite aos usuários acessarem informações e serviços de qualquer lugar. ⇒ Cliente/Servidor é uma arquitetura computacional que envolve requisições de serviços de clientes para servidores. Uma rede Cliente/Servidor é uma extensão lógica da programação modular.\nPortanto, uma definição para a arquitetura Cliente/Servidor seria a existência de uma plataforma base para que as aplicações, onde um ou mais Clientes e um ou mais Servidores, juntamente com o Sistema Operacional e o Sistema Operacional de Rede, executem um processamento distribuído.\nUm sistema Cliente/Servidor poderia ser, então, entendido como a interação entre Software e Hardware em diferentes níveis, implicando na composição de diferentes computadores e aplicações. Para melhor se entender o paradigma Cliente/Servidor é necessário observar que o conceito chave está na ligação lógica e não física. O Cliente e o Servidor podem coexistir ou não na mesma máquina (RENAUD,1994). Porém um ponto importante para uma real abordagem Cliente/Servidor é a necessidade de que a arquitetura definida represente uma computação distribuída (MCKIE,1997). Algumas das características do Cliente e do Servidor são descritas a seguir:\nCliente, também denominado de “front-end” e “WorkStation”, é um processo que interage com o usuário através de uma interface gráfica ou não, permitindo consultas ou comandos para recuperação de dados e análise e representando o meio pela qual os resultados são apresentados. Além disso, apresenta algumas características distintas:\nÉ o processo ativo na relação Cliente/Servidor.\nInicia e termina as conversações com os Servidores, solicitando serviços distribuídos.\nNão se comunica com outros Clientes.\nTorna a rede transparente ao usuário.\nTambém denominado Servidor ou “back-end”, fornece um determinado serviço que fica disponível para todo Cliente que o necessita. A natureza e escopo do serviço são definidos pelo objetivo da aplicação Cliente/Servidor. Além disso, ele apresenta ainda algumas propriedades distintas:\nÉ o processo reativo na relação Cliente/Servidor.\nPossui uma execução contínua.\nRecebe e responde às solicitações dos Clientes.\nNão se comunica com outros Servidores enquanto estiver fazendo o papel de Servidor.\nPresta serviços distribuídos.\nAtende a diversos Clientes simultaneamente.\nOutras características dos processos Cliente e Servidor podem ser encontradas em\nAlguns tipos de serviços que um Servidor pode proporcionar são:\n! Servidor de Arquivos\n! Servidor de Impressora\n! Servidor de Banco de Dados\n! Servidor de Redes\n! Servidor de Telex\n! Servidor de Fax\n! Servidor X-Windows\n! Servidor de Processamento e Imagens\n! Servidor de Comunicação e etc.\nO estilo de interação entre o usuário e o Cliente não precisa, necessariamente, ser feita por poderosas interfaces gráficas. Porém, já que o poder de processamento local do Cliente está disponível, pode-se retirar todo seu proveito, através de interfaces gráficas - GUI (Graphical User Interface), para melhor rendimento do usuário no seu trabalho.\n• Confiabilidade Se uma máquina apresenta algum problema, ainda que seja um dos Servidores, parte do Sistema continua ativo.\n• Matriz de Computadores agregando capacidade de processamento A arquitetura Cliente / Servidor provê meios para que as tarefas sejam feitas sem a monopolização dos recursos. Usuários finais podem trabalhar localmente.\n• O Sistema cresce facilmente Torna-se fácil modernizar o Sistema quando necessário.\n• O Cliente e o Servidor possuem ambientes operacionais individuais / Sistemas Abertos Pode-se misturar várias plataformas para melhor atender às necessidades individuais de diversos setores e usuários.\nAlém destas vantagens, pode-se encontrar dentro de uma arquitetura Cliente/Servidor a interoperabilidade das estações Clientes e Servidoras entre as redes de computadores, a escalabilidade da arquitetura visando o crescimento e a redução dos elementos constituintes, a adaptabilidade de novas tecnologias desenvolvidas, a performance do hardware envolvido na arquitetura, a portabilidade entre as diversas estações que compõem a arquitetura e a segurança dos dados e processos (MCKIE,1997). Embora o avanço da arquitetura Cliente/Servidor tenha trazido uma variada gama de facilidades para o desenvolvimento de aplicações distribuídas, também possui algumas desvantagens:\n• Manutenção As diversas partes envolvidas nem sempre funcionam bem juntas. Quando algum erro ocorre, existe uma extensa lista de itens a serem investigados.\nescassez de ferramentas de suporte, não raras vezes obriga o desenvolvimento\nferramentas próprias. Em função do grande poderio das novas linguagens de\nprogramação, esta dificuldade está se tornando cada vez menor.\n• Treinamento A diferença entre a filosofia de desenvolvimento de software para o microcomputador de um fabricante para o outro, não é como a de uma linguagem de programação para outra. Um treinamento mais efetivo torna-se necessário.\n• Gerenciamento Aumento da complexidade do ambiente e a escassez de ferramentas de auxílio tornam difícil o gerenciamento da rede.\nExistem cinco tipos de modelos para a implantação da arquitetura Cliente/Servidor em processamentos distribuídos: (SALEMI,1993)\nA primeira abordagem para um sistema distribuído é a arquitetura Cliente/Servidor Simples. Nesta arquitetura, o Servidor não pode iniciar nada. O Servidor somente executa as requisições do Cliente. Existe uma clara função de diferenciação: Pode-se estabelecer que o Cliente é o mestre e o Servidor é o escravo, como mostra a figura 1.\nFigura 1 - Arquitetura Cliente/Servidor Simples\nA configuração usual Cliente/Servidor encontrada na maioria das empresas, é\naquela em que existem vários Clientes requisitando serviços a um único Servidor. Esta arquitetura se caracteriza como sendo centrada no Servidor (figura 2a). Porém na visão do usuário, ele imagina que existem vários Servidores conectados a somente um Cliente, ou seja, centrado no Cliente (figura 2b). Entretanto, com as várias ligações de comunicação possíveis, existe na realidade uma mistura de Clientes e Servidores (figura\nFigura 2 - (a) Arquitetura C/S em Dois Níveis - Centrado no Servidor\nFigura 2 - (b) Arquitetura C/S em Dois Níveis - Centrado no Cliente\nFigura 2 - (c) Arquitetura C/S em Dois Níveis - Comunicação Mista\nNesta arquitetura (figura 3), permite-se que uma aplicação possa assumir tanto o perfil do Cliente como o do Servidor, em vários graus. Em outras palavras, uma aplicação em alguma plataforma será um Servidor para alguns Clientes e, concorrentemente, um Cliente para alguns Servidores.\nFigura 3 - Arquitetura C/S Multinível\nEsta 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, não existindo nenhum Mestre ou Escravo: qualquer estação de trabalho pode iniciar um processamento, caso possua uma interface de comunicação entre o usuário e o processo Cliente.\nFigura 4 - Arquitetura C/S Par-Par\nA arquitetura Cliente/Servidor divide uma aplicação em processos, que são executados em diferentes máquinas conectadas à uma Rede de Computadores, formando um único sistema. O paradigma da tecnologia Cliente/Servidor, serve como um modelo, entre outros (ANDREWS,1991), para interação entre processos de softwares em execução concorrente. Os processos ou tarefas, a serem executadas são divididas entre o Servidor e o Cliente, dependendo da aplicação envolvida e das restrições impostas pelo Sistema Operacional de Rede (SOR). Quanto mais avançado for o Sistema Operacional de Rede, menor será a aplicação em si, uma vez que a implementação do código para acessar a rede já se encontra definido no SOR. Atualmente dois tipos de processamentos estão sendo divulgados, Processamento Distribuído e Processamento Cooperativo. A característica de cada um destes é descrita a seguir (KALOKATA,1997), e neste trabalho o enfoque será destinado ao processamento distribuído.\nProcessamento Distribuído A distribuição de aplicações e tarefas se faz através de múltiplas plataformas de processamento. O processamento distribuído implica que essas aplicações/tarefas irão ocorrer em mais de um processo, na ordem de uma transação a ser concluída. Em outras palavras, o processamento é distribuído através de duas ou mais máquinas e os processos, na maioria, não rodam ao mesmo tempo, por exemplo, cada processador realiza parte de uma aplicação em uma seqüência. Geralmente, o dado usado em um ambiente de processamento distribuído também é distribuído através de plataformas.\nProcessamento Cooperativo A cooperação requer dois ou mais processadores distintos para completar uma simples transação. O processamento cooperativo é relatado para ambos os processos cliente-servidor. É uma forma de computação distribuída onde dois\nou mais processadores distintos são requeridos para completar uma simples transação de negócios. Normalmente esses programas interagem e executam concorrentemente como diferentes processos. Os processos cooperativos também são considerados como um estilo de Cliente/Servidor através da arquitetura de mensagens, que devem obedecer a um determinado padrão.\nNo contexto do presente trabalho pretende-se utilizar as características do processamento distribuído. Este tipo de processamento apresenta duas configurações para uma\narquitetura Cliente/Servidor. A primeira, que é representada por três camadas, é responsável pela visualização da interação entre os aplicativos e o hardware, como pode ser visto na figura\nA segunda representação, também fornecida em três camadas, mostra como é tratada a divisão da funcionalidade de uma aplicação, segundo as configurações do Gartner Group, como pode ser visto na figura 6.\nFigura 5 - Sistema Cliente/Servidor\n3.1 - Processamento Distribuído\nO processamento distribuído, também denominado de processamento concorrente utiliza-se do mecanismo de passagem de mensagens para a comunicação entre processos, que podem ser de quatro tipos básicos; Filtro, Peer (não hierárquico), Cliente e Servidor (RENAUD,1994), como mostrado na figura 7 a seguir.\nModelo de Distribuição de\nFigura 6 - Arquitetura da Aplicação Cliente/Servidor\nFigura 7 - Processamento Distribuído\nCaracterísticas do Processo de Filtro:\n• Determina uma conversão na mensagem de comunicação entre o usuário e o host. Ex.: Ligação de um desktop com um mainframe através de um emulador de terminal.\nCaracterísticas do Processo Peer-to-Peer (não hierárquicos):\n• São processos “clones” rodando em todas as máquinas e prestando serviços uns para os outros.\n• Não existem processos servidores, estabelecendo um Servidor dedicado.\n• Cada processo pode ser Cliente e Servidor para outros processos.\nDurante a execução das consultas, os processos Cliente e Servidor são confundidos com os processos Peer-to-Peer, porque este processo foi desenvolvido com base na LU6.2 (Logical Unit versão 6.2) do SNA (Systems Network Architecture) da IBM (RENAUD,1994).\n• Os processos servidores tornam a estação Servidora dedicada ao seu trabalho.\n• Processos clientes são sempre clientes.\n• Processos servidores podem se tornar processos clientes de outros Servidores.\nO modelo que utiliza processos Cliente/Servidor depende do cliente para inicializar a\ncomunicação. Caso o Servidor comece a comunicação, o processo instalado fica sendo o Peer- to-Peer\nA característica básica 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 então liberado da ação do processamento da transação podendo realizar outros trabalhos.\nA arquitetura Cliente/Servidor é dividida em três camadas básicas, como ilustra a\nfigura 8. A camada de Aplicação consiste dos processos da aplicação, entre eles, os processos Cliente e Servidor. A camada de Serviços 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 estão localizados os periféricos ligados aos Clientes e Servidores.\nFigura 8 - Três Camadas da Arquitetura Cliente/Servidor\nA tecnologia Cliente/Servidor pode existir tanto no nível da camada de Aplicação,\nquanto no da camada de Serviços do Sistema. A coexistência do paradigma nestas camadas surge em função da hierarquia das atuações no sistema. Caso o “usuário” seja externo ao sistema, então os processos Cliente e Servidor compõem a camada da Aplicação, enquanto\nque, se o “usuário” for um programa de aplicação o Cliente é um processo redirecionador, e o Servidor será um processo respondedor da camada de Serviços do Sistemas.\nA utilização de sistemas Cliente/Servidor pela camada de aplicação utiliza Serviços do\nSistema não Cliente/Servidor (figura 8), entretanto, sistemas não Cliente/Servidor, ao nível da\naplicação utilizam Serviços do Sistema Cliente/Servidor (RENAUD,1994). Para sistemas Cliente/Servidor na camada de aplicação, a camada Serviços do Sistema oferece somente um mecanismo de IPC (InterProcess Comunication) para troca de mensagens. Por outro lado, a camada Serviços do Sistema configurada como Cliente/Servidor, é responsável por gerenciar o redirecionamento das solicitações de gravação/leitura, por exemplo. É importante notar que a diferença entre os sistemas Cliente/Servidor nas camadas\nde Aplicação e Serviços do Sistema, é o equilíbrio entre a quantidade de processamento tanto no lado do Cliente quanto no lado Servidor. Existem vários sistemas que podem ser baseados na estrutura Cliente/Servidor. O uso mais freqüente são as aplicações de Banco de Dados usando processos SQL (Structured Query Language) de front-end, para acessar remotamente, as bases de dados.\nA figura 9 mostra uma estrutura baseada num Servidor de Arquivos. Esta estrutura\nocasiona um maior fluxo de informações na rede, uma vez que todo o arquivo será transferido para o Cliente para então ser trabalhado.\nFigura 9 - Arquitetura Cliente/Servidor como Servidor de Arquivo\nNeste tipo de estrutura, a camada de Aplicação passa a ser o Cliente do Sistema. Com isto, a camada de Serviço do Sistema é utilizada simplesmente como um redirecionador para acesso à base de dados (RENAUD,1994). Neste tipo de configuração pode-se chamar este Sistema como falso Sistema Cliente/Servidor, por não haver um equilíbrio de processamento entre os dois lados Cliente e Servidor. O lado Servidor somente terá o trabalho de executar as rotinas comuns de I/O, não caracterizando assim, como um processamento intrínseco à aplicação.\nA figura 10 demonstra outra possibilidade de se estruturar um Sistema baseado na\narquitetura Cliente/Servidor, que consiste na utilização 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 informações trafegadas na rede diminui, já que, somente a resposta da consulta é retornada ao Cliente, ao invés de transferir todo o arquivo como era feito anteriormente.\nO Cliente, neste tipo de estrutura é o usuário, passando a ter uma visão da aplicação como se as partes, Cliente e Servidor, fossem algo único. A figura 11 exemplifica esta visão.\nAPI do Gerenciador de\nFigura 10 - Arquitetura Cliente / Servidor como Servidor de\nFigura 11 - Integração entre os processos clientes e servidores\nEste tipo de estrutura favorece o aumento da performance da rede de comunicação, possibilitando assim, um maior número de ligações simultâneas de diversos Clientes com diversos Servidores (RENAUD,1994). Embora a arquitetura Cliente/Servidor possa parecer uma nova versão do modelo de arquivos compartilhados, através da Rede Local baseada em microcomputadores, suas vantagens são inúmeras. Fundamentalmente, ambos os modelos provêem capacidade de processamento distribuído e permitem o compartilhamento de informação. Entretanto, no Modelo de Arquivos compartilhados baseado em Servidor de Arquivos, o Cliente além de executar a aplicação, executa também 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 através da rede para o Cliente processar localmente, ocasionando congestionamento na rede, enquanto que, no modelo Cliente/Servidor, o Cliente executa parte da aplicação, sendo deixado para o Servidor a tarefa da administração da Base de Dados, comumente exercida por algum SGBD. O Servidor envia para o Cliente, através da Rede, apenas o bloco de dados apropriado, como resultado da consulta efetuada pela aplicação.\nDesta forma, na arquitetura Cliente/Servidor, cada Servidor pode suportar um número maior de usuários, uma vez que é o Cliente que gerencia a aplicação e a interface com o usuário. Além do mais, com a crescente conectividade entre máquinas e sistemas operacionais, pode-se escolher para Cliente o ambiente de software e hardware que melhor se adeque às necessidades de cada aplicação do usuário, sem ter que se preocupar com o Servidor. A melhor divisão de tarefas entre o Cliente e o Servidor depende de cada aplicação 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, análise dos dados, e validação dos comandos é executada pelo Servidor, esta é uma decisão do construtor do Sistema em função das características do negócio do usuário. Estas diferenças serão mostradas no tópico a seguir.\n3.2.1 - Sistema de Três Camadas para a Aplicação\nOs Sistemas Cliente/Servidor têm sido utilizados basicamente nos Sistemas de Banco de Dados Distribuídos, Processamento de Transações e nos Sistemas de Suporte a Decisão. A maioria das aplicações tidas como críticas têm permanecido num mainframe. Pode- se definir como críticas aquelas aplicações cujos resultados são utilizados para decisões estratégicas e que, portanto, variam de empresa para empresa, dependendo do seu negócio. Quase que universalmente, os sistemas de finanças são considerados críticos para todas as empresas. Por outro lado, os sistemas de processamento de transações são críticos para as companhias de aviação. As aplicações de processamento de transações, apesar de serem tipicamente consideradas como críticas, têm sido freqüentemente migradas para arquitetura Cliente/Servidor, através do processo de “Downsizing”, como por exemplo os sistemas de entrada de pedidos, pontos de vendas e sistemas de reservas. As transações ocorrem nos Clientes e são formatadas e enviadas ao Servidor para armazenamento. Seria razoável imaginar que as primeiras aplicações a serem desenvolvidas em Sistemas Cliente/Servidor seriam relativamente simples, garantidas e não críticas. Porém, as empresas que se decidiram pelo modelo Cliente/Servidor testaram-no com aplicações de processamento de transações, 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 lógica e a parte de gestão. A primeira representação refere-se a distribuição da camada de Apresentação.\nModelo de Distribuição de Processos\nFigura 12- Arquitetura da Aplicação Cliente/Servidor\nEsta Arquitetura emula uma arquitetura Cliente/Servidor. Toda a gerência da\nApresentação é efetuada no Servidor, enquanto que no Cliente, somente a lógica da impressão dos caracteres no monitor é executada. O Cliente\nnão possui qualquer tipo de “inteligência”. Existe uma técnica de tratamento cooperativo, denominada de Revamping, que é utilizado pela Apresentação Distribuída.\ntratamento cooperativo que está dividida em três tipos: simples, evoluído e o modificado\nRevamping Simples Consiste em habilitar as telas de modo gráfico das aplicações centralizadas com diálogos em modo gráfico. Cada mapa de tela, gerado corresponde a uma janela de interface gráfica.\nRevamping Evoluído Este tipo não emite simplesmente uma réplica gráfica da janela a ser criada de uma aplicação não gráfica. Constrói uma aplicação inteiramente nova, inteiramente diferente da aplicação original. Assim, um diálogo na nova aplicação pode representar um empilhamento de várias janelas da aplicação centralizada.\nRevamping Modificado Este terceiro tipo se deriva do segundo, porém com o fato interessante de se poder manipular a aplicação centralizada instalando sistemas gráficos, visando retirar o melhor de sua performance.\nA segunda arquitetura é definida como Apresentação Remota, e possui a implementação tanto do módulo de gestão, quanto o de lógica na estação Cliente, ficando responsável, entre outras tarefas, pela manipulação das telas e pelas críticas dos dados que estão sendo inseridos. Uma ponto a ser observado, é quando se utiliza um Servidor X-Windows : embora o usuário se localize no Terminal X-Windows, ele realmente está se utilizando do Servidor X-Windows. O terminal real Cliente é onde o usuário está conectado. Esta característica é muito encontrada em ambientes UNIX. O Servidor X-Windows fica responsável pela manipulação das telas e interação com o usuário.\nOutra representação é a arquitetura da Lógica Distribuída. Ela representa o melhor modelo de implementação para arquitetura Cliente/Servidor. Nela, o balanço entre os processamentos clientes e servidores são bem determinados. Neste tipo de arquitetura, a implantação de procedimentos armazenados (Stored Procedures) facilitam a performance na rede de comunicação, 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 pré- compilação necessária para os procedimentos armazenados, aumentando consideravelmente o tempo de resposta. Quando os procedimentos\narmazenados não são utilizados, é necessário que sejam feitas compilações das sentenças das consultas antes de executá-las, evidenciando uma perda desnecessária no tempo de processamento para enviar a resposta ao Cliente. Porém, um ponto negativo para este tipo de arquitetura, é o fato de se ter que criar antecipadamente as consultas a serem utilizadas pelo sistema. Ao contrário, se o sistema utilizar interações com o usuário este tipo de arquitetura não é o mais recomendado, pois não se pode prever todos os tipos de consultas que os usuários possam a vir a fazer.\nNeste tipo de Arquitetura, toda a parte de gestão e lógica da Aplicação fica destinada ao Cliente, enquanto que somente o responsável por prover o armazenamento e a persistência dos dados permanece no Servidor, como por exemplo no caso de um SGBD, responsável direto pela gestão e lógica dos dados armazenados. Este tipo de arquitetura é a mais difundida, não criando, teoricamente, qualquer tipo de empecilho na hora da migração de plataformas mainframes para plataformas desktop do tipo PC (Personal Computer).\nGerenciamento de Dados Centralizados\nAo contrário do Gerenciamento de Dados Centralizados, o Gerenciamento de Dados Distribuídos permite a replicação e divisão dos dados por diversos sítios (sites). Os sistemas distribuídos não deixam de ser microsistemas centralizados, necessitando porém de estruturas como metadados para determinar a localização dos dados e suas replicações. Já existem no mercado sistemas que se instalam entre a parte lógica da aplicação e a gerência de dados, com a função de controlar a localização real dos dados.\nOutro ponto muito importante a ser verificado é o gerenciamento da concorrência 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 não são mutuamente exclusivas, mas sim complementares. É possível fazer vários tipos de associações entre Servidores e Clientes, dentro de uma rede de computadores. A tabela 1 mostra um resumo das características de sistemas Cliente/Servidor.\nInício e final fixos\nRoda o tempo todo\nManipulação de tela / janela\n1. Oferecer serviços funcionais\nInterpretação de menu / comando\n2. Compartilhamento de dados na aplicação\nEntrada de mouse / teclado\n3. Compartilhamento de\nEntrada de dados e validação\nProcessamento de ajuda\nOculta rede e servidores\nOculta detalhes de implementação\nComunicação com diferentes\ndos serviços Comunicação com diferentes\nservidores Comunicação Cliente - Cliente\nclientes Comunicação Servidor - Servidor\nTabela 1 - Principais tópicos de uma Arquitetura Cliente/Servidor\nNormalmente várias perguntas são 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 difíceis, na realidade elas são relativamente fáceis. Existem vários conceitos e aspectos comuns às comunicações Cliente/Servidor necessários ao entendimento do funcionamento da comunicação. Nesta seção será dada uma visão geral sobre os conceitos básicos de protocolos, passagem de mensagem, os aspectos de conexão e sincronismo de processo.\n4.1 - Protocolos\nHá duas décadas, diversos esforços vêm sendo traçados para se estabelecer um padrão único para redes de computadores. No entanto, foram definidos não apenas um, mas vários modelos de referência.\nEm março de 1977, foi constituído pela ISO um grupo de trabalho para estudar a padronização da interconexão de sistemas de computação. Foi definida, inicialmente, uma arquitetura geral, denominada MODELO DE REFERÊNCIA OSI (Open System\nInterconection), para servir de base para a padronização da conexão de sistemas abertos (TAROUCO,1986) (TANENBAUM,1996)\nO modelo OSI possui sete camadas, como apresentado na figura 13. Cada camada\nespecifica um grupo específico de tarefas de comunicação. A norma descreve o escopo funcional de cada camada e os requisitos para a interface com as camadas adjacentes (serviços).\n- Seleção de serviços apropriados à aplicação.\n- Formatação/Reformatação de dados. Ex.: Criptografia.\n- Interface do usuário para o estabelecimento de conexões.\n- Controle de intercâmbio de mensagens entre usuários.\n- Controle de intercâmbio de mensagens na rede.\n- Transmissão livre de erros.\n- Interface elétrica para transmissão bit a bit.\nFigura 13 - Camadas do Modelo de Referência OSI\nA figura 14 mostra que quando a mensagem passa da camada n +1 para a camada n\nsão acrescidos outros dados relevantes à camada n . Estes dados são retirados quando a mensagem chega na camada de mesmo nível na estação destino. Estes acréscimos podem ser informações tais como: tipo da mensagem, endereços, tamanho da mensagem , código de detecção de erro, etc.\nFigura 14 : Arquitetura de protocolos em camada\nO modelo OSI/ISO especifica todas as primitivas de comunicação para que haja troca de mensagens entre as camadas (AMARAL,1993) (COMER,1993) (DUMAS,1995) (RENAUD,1994) (TANENBAUM,1996). Cada camada adiciona um cabeçalho para que haja uma identificação na máquina destino. A figura 15 mostra os principais protocolos usados nas comunicações Cliente / Servidor baseados na Microsoft, Internet e IBM.\nFigura 15 - Comparação entre o modelo OSI / ISO e outros Protocolos\nTendo em vista os objetivos do trabalho pretendido pela presente tese, somente o protocolo de comunicação TCP/IP será descrito, em função da sua interação com sockets, já que este será o meio de comunicação adotado na implementação do protótipo aqui proposto. O leitor poderá referenciar-se a (COMER,1993) (DAVIS,1994) TANEMBAUM96] para obter maiores detalhes sobre os demais protocolos.\nO TCP/IP distingue-se dos demais protocolos pelo seu endereçamento universal. Cada máquina em uma rede possui um endereço que a identifica. A camada TCP é orientada à conexão, enquanto a camada IP trabalha sem conexão (COMER,1993) (DAVIS,1994) (DUMAS,1995). Cabe à camada IP o trabalho de distribuir os datagramas entre as máquinas de uma rede. Para fazer este serviço, ele possui um único endereço de 32 bits que contém informações suficientes para identificar univocamente uma rede e um determinado computador. Este endereço é comumente escrito em decimal de quatro bytes separados por um ponto. Por exemplo:\n11011111, 00000001, 00000010, 00000101, representaria o endereço 223.1.2.5. Existem 5 classes onde estes endereços são divididos. A figura 16 mostra estas classificações.(QUINN,1996) (RENAUD,1994)\nEndereço de Multi-Transmissão\nFigura 16 - Classes do protocolo TCP/IP\nO número de redes e hosts que podem ser endereçados pelas Classes A, B, C, D e E, bem como o escopo de seus endereços IP são definidos na tabela 2. Por exemplo, é possível endereçar 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 milhão de hosts podem ser endereçáveis pela classe B, já que certos endereços IP não podem ser utilizados por serem destinados a trabalhos específicos, como o endereçamento de Gateways e de Broadcasting.\nNum. de Redes\nNum. de Hosts\nEndereço de Hosts\n0.0.0 - 255.255.255\n0.0 - 255.255\nTabela 2 - Limite do número de redes e hosts em cada endereço IP\nCom isto, quando se tem um endereço de rede na classe B e deseja-se aumentar o número de redes possíveis, em detrimento da capacidade de máquinas que podem ser instaladas, ou vice-versa, utiliza-se a técnica da máscara de rede (NetMask). Esta técnica permite a criação de subredes através da modificação local da linha divisória que separa os bits de identificação das redes e dos hosts. Cada subrede também é representada pela notação de ponto decimal. Os bits da NetMask definidos como “um” identificam a porção da rede, enquanto os definidos por “zero”, representam os hosts. Por exemplo, caso uma empresa possua o endereço IP 166.78.4.139 da classe B, isto indica que o computador reside na rede 166.78 e que tem uma identificação de host 4.139. Porém, caso os administradores da rede decidam utilizar a NetMask 255.255.255.0 para aumentar o número de redes internas à empresa, é necessário que se faça uma combinação AND, do endereço IP original com a NetMask, alterando a identificação de rede para 166.78.4 e a identificação de host para 139. Pode-se dizer com isso, que o computador é o host 139 na subrede 166.78.4.0 (endereço de gateway).\n4.2 - Aspectos de Conexão\nExistem dois tipos de conexões usados para a comunicação. O primeiro é chamado sem conexão, onde cada mensagem encontra seu próprio 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 conexão. Logo, cada mensagem deve ter toda a informação de endereçamento necessária para a sua entrega. Dependendo do serviço de entrega usado, as mensagens podem chegar fora de ordem ou serem mal encaminhadas no trânsito. As mensagens numa comunicação sem conexão são chamadas de datagramas. Essa forma de comunicação também é conhecida como comutação de pacotes. Pode-se fazer uma analogia deste tipo de comunicação com o serviço de entrega dos correios. Não 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.\nA mensagem, que é dividida em vários pacotes, 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 reordenação da mensagem pela parte responsável da comunicação pela aplicação do host de destino. O outro tipo de comunicação é o baseado em conexão, onde um circuito\nprévio é estabelecido antes que a troca de dados se efetue. Quando um circuito estiver conectado, cada mensagem segue uma seqüência 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\npreciso, o controle de fluxo é usado para regular a velocidade com que as mensagens são enviadas. A comunicação baseada em conexão, conforme apresentado na figura 18, garante a transmissão das mensagens. Estas são também divididas em pacotes, sem perda para o seqüenciamento dos pacotes nos hosts destinos, diminuindo assim o trabalho de implementação na parte de comunicação do aplicativo.\nFigura 17 - Mensagem por Datagrama\nFigura 18 - Mensagem baseada em conexão\nQuando a comunicação é finalizada, torna-se necessário desfazer a conexão para poder liberar os recursos de rede utilizados. Deve-se notar que as mensagens sempre chegam ordenadas neste tipo de conexão. Um exemplo de comunicação baseado em conexão é o sistema telefônico.\nBaseado em Conexão\nEndereçamento de Mensagem\nEndereço de destino completo para estabelecer circuito; depois somente o ID do circuito\nEndereço de destino completo em todas as mensagens\nSeqüenciado, controle de erro e fluxo, entrega garantida\nSem garantias: mensagens podem ser perdidas ou chegar fora de ordem\nPodem ser negociadas durante a preparação\nPreparação e liberação do circuito\nRota da mensagem\nTabela 3 - Tipos de Conexão\n4.3 - Aspectos de Sincronismo e Passagem de Mensagem\nA comunicação entre Cliente e Servidor procede de forma implícita. Quando o Cliente\nespera a resposta da mensagem enviada para continuar o seu processamento, diz-se que o\nprotocolo utilizado é um protocolo com bloqueio, onde o sincronismo entre Cliente e Servidor está implícito no mecanismo de passagem de mensagem (TANENBAUM,1995). Caso o Cliente possa continuar suas tarefas, enquanto espera a resposta da mensagem, o protocolo de comunicação é 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.\nA teoria de programação concorrente é baseada na noção de processos de comunicação\nsendo executados em paralelo a outros processos. Esses processos se comunicam\ncompartilhando memória ou passando mensagens por meio de um canal de comunicação compartilhado (AMARAL,1993) (VIDAL,1994). O termo IPC (Interprocess Comunication) se refere às técnicas utilizadas na passagem de mensagem. No compartilhamento de memória, os processos concorrentes compartilham uma ou mais variáveis, e utilizam a mudança de estados dessas variáveis para se comunicarem. Essa técnica inclui espera ocupada, semáforos, regiões críticas condicionais e monitores (TANENBAUM,1995). Como esta técnica exige que os processos estejam na mesma máquina, não são considerados base para a programação Cliente/Servidor. Em técnicas baseadas na passagem de mensagem, os processos enviam e recebem mensagens explicitamente, em vez de examinar o estado de uma variável compartilhada (AMARAL,1993) (COMER,1993). O benefício principal da passagem de mensagem é que existe pouca diferença entre o envio de mensagens a processos remotos ou locais. Portanto, a passagem de mensagem é poderosa para criação de aplicações em rede. Outra vantagem é que mais informações podem ser trocadas numa mensagem do que por mudança no estado de uma variável compartilhada. A figura 19 mostra a troca de mensagem entre cliente e servidor sem o bloqueio por parte do cliente.\nPassagem geral de mensagens\nSend (Msg1, Respondedor)\nReceive (Msg1, Solicitante)\nSend (Resp1, Solicitante)\nReceive (Resp1, Respondedor)\nFigura 19 - Troca de mensagem sem bloqueio\n4.4 - Conexão TCP/IP\nUma vez que a base de comunicação iria ser efetuada por meio de sockets, foi estabelecido também que o protocolo de comunicação utilizado seria o TCP/IP, possibilitando assim uma possível conexão futura com a plataforma UNIX.\nPara este desenvolvimento, a plataforma a ser utilizada é o Windows NT 3.5 ou 3.51, que apresenta a robustez necessária para os processos multitarefas. A escolha deste ambiente\ntambém se deve ao fato dele suportar vários tipos de protocolos para comunicação, entre eles o TCP/IP (QUINN,1996).\nA figura 20 mostra os protocolos de comunicação do Windows NT.\nO protocolo TCP/IP é o protocolo padrão utilizado pela Internet, que possibilita a interligação de diversas plataformas. Existem vários serviços 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 referência à camada do modelo OSI/ISO. Na camada de Transporte pode-se notar a existência de dois padrões, o TCP, que é a\ncomunicação com conexão e o UDP, que é a comunicação sem conexão, como já foi mencionado anteriormente na seção 4.2. Para o desenvolvimento deste protótipo foi adotado o padrão TCP, onde o controle de erro e o seqüenciamento dos pacotes das mensagens são automaticamente tratados, o que não ocorre no padrão UDP, necessitando que estes tratamentos sejam desenvolvidos.\nO padrão TCP permite a abertura de uma conexão virtual entre a máquina fonte e a\ndestino em todas as camadas do modelo OSI/ISO.\nAplicação Windows sockets\nAPIs proprietárias (opcional)\nWindows sockets Dynamic Link Library (Winsock.DLL)\nDriver de APIs padrões\nDriver de Protocolos Múltiplos (ODI, Packet Driver, NDIS)\nAPIs de Hardware proprietário\nInterface de Rede (Ethernet, Token Ring, Serial, etc.)\nFigura 20 Protocolos do Windows NT\nFTP, SMTP e DNS\nTransporte Rede Link de Dados Física\nIP, ARP e ICMP\nLink de Dados Física\nFigura 21 Protocolo TCP/IP\nA Internet utiliza o padrão UDP, uma vez que as comunicações baseadas no protocolo\nTCP/IP se utilizam de portas de comunicação que, associadas aos sockets, permitem a troca de\nO protocolo TCP/IP disponibiliza 999999 portas (comprovação empírica), sendo que\nas portas de número 0 até a porta de número 1023 são reservadas para serviços pré- determinados, como por exemplo a porta 23, para o serviço Telnet, a porta 21 para o FTP, e\nassim por diante. Devido a este limite, caso a Internet utilizasse o padrão TCP, as máquinas que respondessem a um número muito grande de acessos, acabariam limitando a sua utilização. No padrão UDP, por sua vez, quando existe uma solicitação de comunicação, o endereço IP do remetente da mensagem segue junto com a mensagem para o destinatário, de forma que o disponibilizador do serviço possa posteriormente enviar a resposta do serviço solicitado.\nÉ importante salientar que, para que as comunicações transcorram normalmente, as\nAPIs não necessariamente precisam ser as mesmas, muito embora os protocolos devam ser os mesmos, como pode ser visto na figura 22.\nAPI ( TLI)\nFigura 22 - Mesmo protocolo para uma comunicação correta\nOs demais protocolos suportados pelo Windows NT, permitem a conexão com outros tipos de plataformas, como pode ser visto na tabela 4.\nTabela 4 - Demais protocolos do Windows NT\nO protocolo NetBEUI é de propriedade da Microsoft e permite a conexão com máquinas que estejam com os ambientes Windows 3.x, Windows NT 3.x / 4.0 e Windows 95 (DAVIS,1994). Ele é o responsável pela camada de Transporte e Rede, acrescentando uma extensão para a camada de Link de Dados. Conecta-se diretamente com o NetBIOS na camada de sessão (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 confiável e o outro para frames de informação não numerados usados em Datagramas. Os protocolos SPX/IPX são uma implementação dos protocolos XNS da Xerox. O protocolo SPX, igual ao SPP da Xerox, oferece um serviço de fluxo de dados confiável,\nenquanto que o IPX, igual ao IDP, oferece um serviço de datagrama, permitindo a conexão entre máquinas do tipo PC que estejam rodando o Sistema Operacional de Rede da Novell\nPor sua vez, o protocolo Apple Talk permite a conexão com máquinas da plataforma Macintosh, e é um protocolo totalmente particular. Os principais protocolos usados por máquinas Macintosh são os DDP - Datagram Delivery Protocol, ATP - AppleTalk Transaction Protocol e ADSP - AppleTalk Data Stream Protocol (RENAUD,1994).\nO Socket teve origem na Universidade de Berkeley, como sendo a API (Application\nProgramming 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 comunicação e é implementado como um inteiro positivo (ROBERTS,1995). Existe uma diferença sutil, porém importante, entre descritores de arquivos e socket.\nUm descritor de arquivo é ligado a um arquivo ou dispositivo específico quando criado pelo comando open. Um descritor de socket não é ligado a local algum quando criado pelo comando socket. Uma aplicação pode decidir ligar-se a um endereço explicitamente usando um comando bind, ou pode fornecer endereços dinamicamente quando envia datagramas usando o comando send. Portanto, sockets podem ser usados como uma interface para transportes de rede baseados em conexão e sem conexão (COMER,1993) (DUMAS,1995).\nO socket, que é um manipulador (handle), está associado a um largo conjunto de dados\narmazenados na implementação do protocolo de rede. O termo socket é usado no S.O. UNIX para fornecer uma interface tipo arquivo às redes. Quando uma operação para criar um socket é chamada, o sistema retorna um manipulador, como descritor de socket. Esse descritor é\nusado em todos os outros comandos relacionados ao socket e é intercambiável com o descritor de arquivo usado em funções read e write. Os dados associados ao socket incluem várias informações, como o endereço IP das máquinas que estão se conectando, as portas dos dois lados da conexão TCP e o estado da conexão corrente.\nA camada de sockets dentro do contexto da comunicação corresponde a camada de\nSessão do Modelo OSI/ISO, que tem como função o gerenciamento das sessões de comunicação processo a processo entre os hosts. Ela é também responsável por estabelecer e\nencerrar as conexões entre os aplicativos cooperantes (DUMAS,1995). Dentro do protocolo TCP/IP, a camada TCP abrange a camada de Sessão e Transporte do Modelo OSI/ISO, favorecendo diretamente a programação dos sockets sobre o protocolo TCP/IP.\nPara o ambiente Windows foi desenvolvido o Windows Sockets - Winsock, visando facilitar a interconexão entre as estações Windows, através do protocolo TCP/IP, que é base para o acesso a Internet. Windows Sockets é uma interface aberta para programação em rede sob o Microsoft Windows (QUINN,1996).\nA especificação da interface do Windows sockets define claramente a divisão entre a\naplicação de rede e o protocolo da rede.\nA sua versão mais recente é o Winsock 2 (revisão 2.0.8 - 19/05/95). A versão 2.0 da\nespecificação do Windows sockets se associa a arquitetura que o Windows NT utiliza para\nsuportar múltiplos protocolos de fornecedores variados (QUINN,1996).\nO Winsock API aumenta a funcionalidade dos sockets de Berkeley, ao acrescentar\nextensões específicas do Windows para suportar a natureza orientada a mensagens do S.O. baseado no Windows. Todas as aplicações que hoje em dia acessam a Internet diretamente da residência do usuário, usando FTP, E-mail, Finger, Telnet, SMTP, entre outros, utilizam os sockets como base de comunicação, através 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 programação para o protocolo TCP/IP via sockets\nPara o ambiente Windows, o relacionamento entre as aplicações e o ambiente de rede, pode ser demonstrado na figura 23.\nFigura 23 - Relacionamento da biblioteca dos sockets no ambiente Windows\nNa API do sockets é possível determinar se a comunicação que se vai estabelecer é com conexão - STREAM, ou sem conexão - DATAGRAMA. Para se trabalhar numa comunicação baseada em conexão, na camada de transporte do TCP/IP, o protocolo utilizado é o TCP, determinando que somente após o estabelecimento de uma comunicação é possível efetuar troca de mensagens. Para a abertura de uma conexão com sockets, é necessário que várias funções da biblioteca Winsock sejam chamadas. A figura 24 demonstra a seqüência de operações tanto no lado Servidor quanto no lado Cliente. No caso de se estabelecer uma conexão Stream, o Servidor é primeiramente inicializado. A função Socket() define o descritor no qual a aplicação se associará quando desejar transmitir uma mensagem. Posteriormente a função Bind() interliga o descritor ao endereço IP da máquina servidora e a porta TCP/IP na qual as transmissões irão ocorrer. A função Listen() permite ao Servidor ficar “escutando” qualquer solicitação de conexão.\nFigura 24 - Conexão Stream\nQuando uma solicitação chega de\nCliente após ativar a função Connect(),\nServidor cria um processo filho\nmediante a função Accept(), numa nova porta TCP/IP. O pedido do Cliente é associado a esta porta, permitindo assim a transferência de dados pelas funções Send()/Recv(), deixando, desta forma, a porta original de conexão do Servidor livre para efetuar novas conexões. Ao término da comunicação, o Cliente utiliza a função CloseSocket() para fechar a conexão, liberando a porta do processo filho do Servidor para ser ligada a outro processo de comunicação. O\nServidor só irá utilizar esta função quando\nPor sua vez, para uma comunicação sem conexão, figura 25, a utilização das funções de sockets tornam-se mais fáceis de se implementar. Porém, é necessário lembrar que a utilização de comunicação baseada em Datagramas determina que as rotinas de recuperação das seqüências dos pacotes entregues a rede devem ser programadas, aumentando assim a possibilidade de falhas na implantação do sistema. A seqüência e as funções definidas para uma conexão Datagrama são as mesmas da conexão Stream, excluindo apenas as funções Listen(), Accept() e Connect(). Isto ocorre pelo fato do protocolo baseado em Datagrama não\nutilizar uma conexão real entre as máquinas origem e destino, implementando, automaticamente dentro das funções de troca de mensagens, Send()/Recv(), um cabeçalho com o endereço IP da máquina no qual será feita a comunicação. Um ponto a ser observado, é que, para a transmissão, tanto na função Send() ou Recv(), os sockets somente operam com dados do tipo Char. Para a transmissão de dados puramente do tipo caracter, o sistema desenvolvido baseado em sockets não impõe nenhuma restrição. Entretanto, para sistemas desenvolvidos sob o paradigma da Orientação a Objeto, que manipula tanto objetos simples, como complexos ou longos, é necessário que, ao se transmitir, se faça uma conversão da classe do objeto para o tipo Char. No momento em que a informação chega ao seu destino, é necessário que o receptor faça a reconversão, isto é, do tipo Char para o tipo original do objeto. Esta peculiaridade para a transmissão de dados de tipos diferentes de Char, faz com que o destinatário da mensagem possua o conhecimento prévio de todos os tipos possíveis de objetos que podem ser transmitidos.\nFigura 25 - Conexão Datagrama\n4.5.1 - Interfaces de Comunicação utilizando Sockets\nWindows sockets é um dos mecanismos existentes para o desenvolvimento de aplicações em rede por meio de troca de mensagens. A compatibilização entre as bibliotecas de sockets de diferentes fornecedores permite a troca de bibliotecas sem afetar as aplicações. Como dito anteriormente, a API do Winsock representa uma barreira bem definida entre as aplicações de rede e os protocolos utilizados. Para o desenvolvimento das interfaces de comunicação entre Cliente e Servidor foram utilizadas bibliotecas (PEDRIANA,1996) disponibilizadas na Internet, e, consequentemente, adaptadas para a comunicação entre os objetos do SIGO, uma vez que, a comunicação original se baseava somente na troca de mensagens de dados do tipo Char. Esta biblioteca foi construída em Borland C++ 4.5 e se constitui da comunicação entre máquinas Clientes e\nServidor por intermédio de sockets. Esta biblioteca veio ao encontro dos interesses do projeto, já que o modo de comunicação baseado em RPC (Remote Procedure Call) não se constituía num ambiente confiável para operações que envolvessem objetos (AQUINO,1995).\nA figura 26 mostra a relação do Modelo Windows sockets com o Modelo OSI/ISO.\nModelo Windows sockets\nRede Link de Dados Física\nDriver de rede Interface de rede\nFigura 26 - Relação do Modelo Windows sockets com o Modelo OSI / ISO\nPode-se notar que a interação da aplicação com o protocolo TCP/IP faz-se somente pela API que o Windows sockets disponibiliza, minimizando assim maiores possibilidades de geração de erros.\nPara que se estabeleça uma comunicação no padrão TCP, faz-se necessário seguir uma seqüência de operações pré-definidas como ilustrado na figura 2.21. O diagrama de estado da seqüência de conexão Stream Socket, pode ser visto na figura 27. O Servidor deve ser sempre colocado “no ar”, antes de qualquer tentativa de comunicação. Para esta abertura de conexão com sockets, é necessário que várias funções da biblioteca Winsock sejam chamadas.\nA função Socket define o socket, que é um descritor a partir do qual a aplicação se\nassociará quando desejar transmitir uma mensagem. O Servidor, por sua vez, executa outras duas funções que são disparadas em seqüência: a função Bind, que associa o número de uma porta com o endereço IP da máquina servidora, e a função Listen, que fica “escutando” na porta selecionada esperando que haja uma solicitação de conexão.\nQuando a função Connect for ativada pelo Cliente, uma solicitação de conexão para o Servidor é enviada e, caso a resposta a esta solicitação seja afirmativa, o Cliente e o Servidor passam para o estado de conectado.\nler dados OOB\nFigura 27 - Diagrama de estado do Stream Socket\nUma vez estabelecida a conexão, a troca de mensagem passa a ser efetuada e a função Recv retira do buffer de leitura as informações que foram trocadas entre o Cliente e o Servidor. Caso não se consiga enviar alguma mensagem pela função Send, por causa do estouro da capacidade do buffer, os dados são armazenados e retransmitidos posteriormente. Os dados OOB (Out-of_Band) possuem um nível de prioridade de transmissão acima dos outros dados. Isto possibilita uma alteração na seqüência a ser transmitida, porém esta interferência na seqüência fica transparente ao usuário. Ao término da comunicação, o Cliente utiliza a função CloseSocket para fechar a conexão, liberando a porta do processo filho do Servidor para ser ligada a outro processo de comunicação. O Servidor só irá utilizar esta função 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 conexão (2a) e solicita uma conexão (2b), quando a conexão é 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\noriginal da conexão do Servidor livre para efetuar novas conexões, como pode ser visto na figura 28.\n(1) Servidor no ar Porta 2450\n(2 b) Solicitação de Conexão\n(2a) Cliente no ar Nome do servidor e Porta\n4 o ) Comunicação Cliente/Servidor\nFigura 28 - Criação de Processo Filho para a comunicação\nCaso ocorra uma perda de conexão, tanto por parte do Cliente quanto pelo Servidor sem antes ter sido efetuada a função CloseSocket, quem ainda estiver “no ar” não 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, é necessário o desenvolvimento de uma função de Time-out, de modo a proporcionar um nível de segurança ainda maior para as conexões. A função de Time-out fica checando se existe troca de informações nas conexões existentes, e permite que a função CloseSocket seja ativada automaticamente ao se verificar a inexistência de qualquer tipo de troca de mensagem após um determinado tempo, possibilitando assim a otimização das portas do protocolo TCP/IP.\nOs Sistemas Gerenciadores de Bancos de Dados Orientados a Objetos (SGBDOOs) surgiram da necessidade de suportar a programação orientada a objeto. Era necessário um repositório 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 após a conclusão de um processo. Os SGBDOOs tornaram-se importantes para certos tipos de aplicações com dados complexos, tais como CAD (Computer Aided Design) e CAM (Computer Aided Manufacturing) e o SIG (Sistemas de Informações Geográficas), servindo também para manipular BLOBs (Binary Large Objects), a exemplo de imagem, som, vídeo, texto e transações de longa duração (MARTIN,1994) (NAVATHE,1994) (KHOSHAFIAN,1993)\nA classificação dos Banco de Dados desde os relacionais (SGBDR) até os OO pode ser\nvista na figura 29 (POET,1997).\nOs SGBDOOs existentes tais como Versant, O 2 , Poet, GemStone, Itasca, entre outros,\njá incorporam características de comunicação baseadas na arquitetura Cliente/Servidor.\nSGBDR com um pouco de OO\nBDO - Front End\npara um BDR\nO2 / Ontos / ODI / Objectivity / POET / Versant\nGemStone / Itasca / Matisse / IDB\nFigura 29 - Classificação dos SGBDR e SGBDOO\nO sistema O 2 possui uma versão workstation e outra server, sendo que as duas versões\npossuem quase a mesma interface. A principal distinção é na implementação: a versão\nworkstation é monousuário, enquanto que o server é multiusuário, possuindo total controle nas ações com o disco. Só através do server pode-se fazer acesso a qualquer tipo de informação armazenada em disco (BANCILHON,1992).\nO O 2 é constituído por 8 módulos funcionais em sua arquitetura. Entre eles pode-se\ndestacar o módulo OM (Object Manager) que é composto pelo COM (Complex Object\nManager), MPM (Message-Passing Manager), TM(Transaction Manager), CM (Clustering Manager) e o IM (Index Manager).\nO OM possui uma camada intermediária na qual gerencia o buffer de objetos (BM -\nBuffer Manager) e a camada de comunicação (CM - Communications Manager). No server, o gerente de comunicações fica escutando as requisições das workstations e dispara o\nprocessamento dos módulos correspondentes.\nO gerente de comunicação do O2 é desenvolvido baseado em 4 critérios:\n◊ A simplicidade, que se traduz na portabilidade, é conseguida pela escolha de ferramentas bem definidas e o protocolo de comunicação utilizado para a conexão entre Cliente e Servidor é o TCP/IP.\n◊ A transparência resulta no fato de que o usuário final não reconhece de onde as informações estão sendo obtidas.\n◊ performance é obtida pela otimização do protocolo de comunicação que permite\ntransferência de objetos sem que resulte na criação de gargalos numa arquitetura\n◊ Finalmente, a confiança, que é obtida pelo mecanismo de detecção de falhas que consegue prevenir o travamento do sistema por possíveis finalizações anormais dos processos envolvidos na comunicação.\nQuando um processo é inicializado em uma workstation, um processo espelho é\ninicializado no server com o intuito de interagir com as camadas mais baixas do sistema. Após\na comunicação ser estabelecida, os objetos são transferidos independentemente de um lado\npara o outro. Contudo, quando uma quantidade grande de objetos é transferida, primeiramente eles são empacotados para minimizar os acessos a rede.\nO OODBMS GemStone (GEMSTONE,1997), que utiliza a técnica de objetos\ndistribuídos, oferece uma arquitetura Cliente/Servidor escalável e robusta com o seu sistema de controle de objetos. A comunicação do GemStone se baseia no ORB (Object Request Broker), que por sua vez utiliza o CORBA (Common Object Request Broker Architecture) para organizar os padrões dos objetos que servirão para a troca de mensagens. A OMG (Object Management Group) garante então, os padrões de interoperabilidade entre os sistemas de objetos gerenciados pelo CORBA, como visto nas figuras 30 e 31.\nOMG deliberou os seguintes padrões de trabalho para o Inter-ORB:\n◊ o GIOP (General Inter-ORB Protocol) que especifica o formato das mensagens e a representação dos dados para toda a intercomunicação do ORB. O GIOP garante, portanto, que a ordenação dos bytes transmitidos não são problemas entre os ORBs existentes.\n◊ o IIOP (Internet Inter-ORB Protocol) que permite a ligação entre o GIOP e o protocolo de comunicação TCP/IP.\nCORBA 2.0 possui ambos os protocolos de comunicação: o GIOP e o IIOP.\narquitetura de objetos distribuídos do CORBA estende os limites do GemStone para\nas linguagens de objetos adicionais, interfaces de programação de aplicações e para serviços não objetos. A adoção da padronização CORBA garante a interoperabilidade entre os diversos sistemas de objetos nas empresas.\nA grande migração da indústria de sistemas monolíticos para sistemas distribuídos, fez\ncom que a OMG focasse o CORBA como seu ponto de ação central, reunindo seus esforços\npara a padronizar os objetos componentes de sistemas de informações distribuídos.\nA plataforma Windows desenvolve seus aplicativos baseados na tecnologia de objetos\ndistribuídos através do COM (Component Object Model) e o OLE (Object Linking and Embedding).\nFigura 30 - Camada ORB para comunicação do GemStone\nFigura 31 - Padronização CORBA para a Comunicação de Objetos Distribuídos\nOutro OODBMS conhecido que também possui uma arquitetura Cliente/Servidor é o\nPOET. O POET Engine e a aplicação cliente coexistem como um processo sem qualquer sobrecarga na comunicação (POET,1997).\nA firmeza no gerenciamento dos dados junto com as facilidades da API disponíveis,\npermite ao usuário desenvolver aplicativos com características Cliente/Servidor, com uma total transparência da localização dos dados. Uma aplicação pode abrir múltiplos banco de dados, que podem ser locais ou remotos.\nO UOS (Universal Object Server) do POET emprega uma arquitetura Cliente/Servidor\nconvencional, na qual múltiplos clientes acessam um ou mais servidores através da rede. Esta estrutura de comunicação representa uma arquitetura Cliente/Servidor em dois níveis formando uma comunicação mista podendo ser vista na figura 2.2c.\nO UOS utiliza protocolos de rede padrão como o TCP/IP e o IPX/SPX, permitindo\nassim a operação transparente em redes homogêneas ou heterogêneas, fornecendo ao usuário o máximo de flexibilidade.\nO sistema POET suporta tanto single-threaded quanto multi-threaded. Os clientes\nsingle-threaded incluem um thread-safe API que permite a serialização 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 operação sequencial na qual são alocadas as informações pertinentes ao processo, tais como identificação do processo e área de memória utilizada em cada thread criado. Entretanto, Multi-threaded permite o compartilhamento destas informações, quando da criação de processos filhos no processo pai, otimizando assim, a utilização da memória (PHAM,1996). Os clientes incorporam a arquitetura de múltiplos leitores / único escritor, (multiple reader/single writer) usando consultas não bloqueadas e canais de comunicação simultâneos para um ou mais servidores POET\nAtualmente, a maioria das empresas está migrando para a computação distribuída, através de uma arquitetura Cliente/Servidor. Por ser uma área nova, é necessário o investimento em equipamentos, pessoal, treinamento e serviços para conseguir responder a demanda deste mercado globalizado. A importância e a credibilidade desta tecnologia podem ser verificadas em função de grandes empresas, tais como: Oracle, Sybase, Informix, Digital e IBM, que desenvolveram soluções para atender a essa nova plataforma. Esta oferece acesso a dados localizados em diferentes Servidores, sem que o usuário perceba que eles podem estar vindo até de países diferentes, realidade facilmente conseguida através da Internet. Esta facilidade permite uma integração entre micros, mainframes e redes, a fim de se obter o melhor que a computação distribuída pode oferecer. Este relatório apresentou as características básicas 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 avanço tecnológico nesta área, esta arquitetura foi implementada no SIGO (Sistema Gerenciador de Objetos) (MOURA,1997), transformando-o de um sistema monousuário em um sistema multiusuário (DESCHAMPS,1997).\n1. (AMARAL,1993) Amaral, W. H. “Arquitetura Cliente/Servidor Orientada a Objeto” Tese de Mestrado, IME, 1993.\n2. (ANDREWS,1991) Andrews, G. R. “Concurrent Programming: Principles and Practice” Benjamin/Cummings, Redwood City, CA, 1991.\n3. (AQUINO,1995) Botelho, Tomás de Aquino Tinoco, “Análise de Desempenho da Arquitetura Cliente/Servidor Orientada a Objeto”, Tese de Mestrado, IME,\n4. (BANCILHON,1992) Bancilhon, F. et al “Building an Object-Oriented Database System:\nThe Story of O 2 ”, Morgan Kaufmann, 1992.\n5. (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.\n6. (CUSTER,1993) Custer, Helen “Windows NT”, Microsoft Press, Makron Books, São Paulo, 1993.\n7. (DAVIS,1994) Davis, Ralph “Windows NT Networking Programming” Addison Wesley,\n8. (DESCHAMPS,1997) Deschamps, Eduardo R.P. “Sistema Gerenciador de Objetos em um Arquitetura Cliente/Servidor”, Tese de Mestrado, IME, Abril/1997.\n9. (DUMAS,1995) Dumas, Arthur “Programando WinSock”, Axcel Books, Rio de Janeiro,\n11. (HULQUIST,1997) Hultquist, Steve <ssh@vnet.ibm.com> “FAQ about Client/Server” http://non.com/news.answers/client-server-faq.html, 1997\n13. (KHOSHAFIAN,1993) Khoshafian, Setrag “Object Oriented Database”, John Wiley & Sons, Inc. , Canadá, 1993.\n14. (LEFEBVRE,1994) Lefebvre, Alain “L’Architecture Client-Serveur”, Armand Colin, 2 e édition, 1994.\n(MARTIN,1994) Martin, James “Princípios de Análise e Projeto baseados em Objetos” Ed. Campus, Rio de Janeiro, 1994.\n16. (MCKIE,1997) McKie, Stewart “Everything you wanted to know about Client/Server\ncomputing but were\n17. (MOURA,1997) Moura, A.M.C.; Freitas, Luciani et al; “SIGO: Ambiente para Desenvolvimento de Aplicações Não-Convencionais em Banco de Dados” Relatório Técnico, RT016/DE9/ABR97, IME, Rio de Janeiro, Abri/1997.\n18. (NAVATHE,1994) Navathe, Shamkant B. & Elmasri, Ramez “Fundamentals of Database Systems” 2nd Ed., Benjamin Cummings, CA, 1994.\n19. (PEDRIANA,1996) Pedriana, Paul “OWLSock - Implementation” <paulp@ccnet.com>, http://users.ccnet.com/~paulp/owlsock/html/download.htm.\n20. (PHAM,1996) Pham, Thuam Q. & Garg, Pankaj K. “Multithreaded Programming with Windows NT” Prentice Hall, 1996.\n22. (QUINN,1996) Quinn, Bob & Shute, Dave “Windows Sockets Network Programming” Addison Wesley, 1996\n23. (RENAUD,1994) Renaud, P. E. “Introdução aos Sistemas Cliente/Servidor” IBPI Press, RJ 1993.\n24. (ROBERTS,1995) Roberts, Dave “Developing for the Internet with Winsock” Coriolis Group Books, 1995.\n25. (RUMBAUGH,1994) Rumbaugh, James et al “Modelagem e Projetos baseados em Objetos” Ed. Campus, Rio de Janeiro, 1994.\n26. (SALEMI,1993) Salemi, Joe. “Banco de Dados Cliente/Servidor” . IBPI Press, 1993.\n27. (TANENBAUM,1995) Tanenbaum, Andrew S. “Distributed Operating Systems” Prentice Hall, 1995.\n28. (TANENBAUM,1996) Tanenbaum, Andrew S. “Computer Networks” Prentice Hall, Third Edition, 1996.\n29. (TAROUCO,1986) Tarouco, L. M. R. “Redes de Computadores”. McGraw-Hill ,SP\n30. (VIDAL,1994) Vidal, Paulo César Salgado. “Modelagem para Arquitetura Cliente/Servidor Orientada a Objeto”. Tese de Mestrado, IME, 1994.\nDocumentos semelhantes a Fundamentos Da Arquitetura De Computadores\nPopulares em Front And Back Ends\nArtigo OPE Joplin\numa placa sintonizadora de TV no XBMC com NEXTPVR.docx\nGuia Basico Design Magento v1.0\nPainel de Vagas Infovagas Maio\nCompiladores - aula01


Você sabe o que é o centro de negócios? | Portal de Negócios Hammertime\nInício » Dicas de Negócios » Você sabe o que é o centro de negócios?\nVocê sabe o que é o centro de negócios?\nO centro de negócios é uma iniciativa que algumas empresas tem para ajudarem o seus clientes e fornecedores a terem uma via de comunicação mais rápida com a empresa. Isso torna mais fácil as negociações que possivelmente existiriam entre ambos. É como se as empresas possuíssem um escritório virtual, onde o cliente ou fornecedor possa ter acesso a algumas informações importantes ou simplesmente entrar em contato com a empresa sem precisar ir presencialmente até ela, isso é um grande passo para a viabilização de muitos negócios. Sabemos que hoje em dia a internet é utilizada para muitas finalidades, então porque não usar para fazer negócios também? A internet está ai para ajudar.\nUma dessas empresas que possuem esse canal é a Petrobras, no site deles você consegue encontrar várias informações úteis tanto para você que quer ser um cliente ou um fornecedor da Petrobras.\nSe você quer ser um cliente da Petrobras, no site você consegue realizar pedidos de produtos, agendar a retirada e acompanhar o processo até que seja finalizado, esse monitoramento pode ser feito 24 horas por dia e 7 dias por semana, esse é uma das vantagens de ter um centro de negócios.\nSe você é um fornecedor, ou deseja ser um, da Petrobras você também pode acessar varias informações uteis através do site, você pode realizar transações, solicitar cotação, enviar propostas de negociações e gerenciar o pedido até o envio da nota fiscal eletrônica, tudo através do site da Petrobras.\nOutra vantagem de ter o seu centro de negócios online é que você consegue aumentar consideravelmente a capacidade produtiva da sua empresa e consequentemente a lucratividade dos seus negócios.\nPara as empresas que estão iniciando agora, ter um escritório virtual é uma ótima opção, além de ser mais barato que você alugar um ponto comercial, o escritório virtual disponibiliza equipamentos e serviços que todo o empreendedor precisa e você só para por eles, saiba mais como funciona no site da ANCN (Agencia Nacional dos Centros de Negócios e Escritórios Virtuais).


Aventuras na História · Redemoinho causa susto durante final de campeonato de futebol na Bolívia\nRedemoinho causa susto durante final de campeonato de futebol na Bolívia\nUm dos atletas chegou a ser arremessado pela coluna de ar — mas retornou ao campo para disputar o jogo\nWallacy Ferrari, sob supervisão de Fabio Previdelli Publicado em 22/07/2021, às 10h54\nJogadores correm de redemoinho no campo - Divulgação / YouTube / CNN Brasil\nEnquanto os jogadores de futebol se reuniam no centro do campo para cantarem o hino nacional boliviano, antes uma partida de futebol que decidiu a final da Liga Amadora Achocalla na Bolívia, um impressionante redemoinho de ar se formou no local.\nA cena foi registrada em vídeo e viralizou nas redes sociais por todo o país sul-americano, como informou a CNN Brasil. Confira as imagens que mostram o fenômeno climático:\nAs imagens registram o fenômeno climático se formando em um campo de várzea, resultando em correria dos jogadores que tentavam se esquivar da coluna de ar. Um deles chegou a ser arremessado, mas logo é amparado por um colega com ferimentos leves. Por fim, o redemoinho termina na outra ponta do campo.\nDe acordo com o jornal local Antena3, a movimentação de ar não passou de um susto para os jogadores, que pouco depois retomaram a formação e deram início a partida, sem danos materiais na estrutura esportiva.\nBruno diz que pressão midiática o impediu de voltar ao futebol: “Estou tentando me reerguer”\nMais próximo do que você imagina: a emocionante história de Nando


Eu, eu mesma… | Fabiana Bertotti Fabiana Bertotti\nSou tanta coisa e ninguém ao mesmo tempo que nem sei me descrever. Vibrarei o dia que for apresentada como “escritora”, mas este dia ainda não chegou e talvez demore um pouquinho… por hora me apresentam como jornalista, meu ofício do coração. Esposa do Bertotti, minha paixão. Irmã de Vagner e Aline, meus xodós mais novos e filha de Dalva e Joaquim, responsáveis por tudo. Também posso ser apresentada como amiga, louca, irreverente, bravinha, trabalhadora, sonhadora…\nQuero um mundo melhor, mas não acredito que ele virá sem uma “grande intervenção”. Reciclo o lixo, tento cuidar da saúde e vivo brigando com o espelho. Adoro aprender e sou viciada em livros. Bibliotecas e livrarias são meus lugares preferidos e estou buscando o equilíbrio – que no fundo acho mesmo é que nunca vou encontrar.\nVai lendo aí meus posts que logo você descobre mais de mim ou desiste de tentar me entender de uma vez.\nNa rádio Novo Tempo (Comentário do jornalista Felipe Lemos sobre o meu livro)\nEsta entrevista foi para o blog: Mulher Adventista, sobre o lançamento do meu livro\n(A entrevista abaixo eu concedi para a jornalista Suellen Timm, para o Canal da Imprensa há uns três ou quatro anos. É bem elogiosa, risos)\nRainha dos 15 minutos\nCriativa, proprietária de um vocabulário invejável, irônica, crítica e muito talentosa. Essas são algumas das características marcantes dessa ex-articulista do Canal da Imprensa. O talento para o jornalismo pode ser comprovado nas diversas mídias que Fabiana contribuiu após graduar-se no Unasp em 2004. Depois de formada, atuou na Rádio Novo Tempo de Florianópolis. Em seguida trabalhou como repórter e apresentadora no SBT de Santa Catarina. Atualmente exerce a função de diretora associada de comunicação de uma sede administrativa da Igreja Adventista do Sétimo Dia para a região Sul do País. Em entrevista ao Canal, a jornalista relembra alguns fatos que se escondem nos bastidores de nossa redação.\nCanal da Imprensa - Fale um pouco sobre o seu período como articulista do Canal. Quanto tempo escreveu para o site?\nFabiana Bertotti - Escrevi do começo ao final da minha graduação. Logo no começo, escrevia esporadicamente, já que novata não tinha muita moral mesmo. Mas o espaço foi se abrindo, até que fiquei como articulista especial, ou coisa parecida. Isso me deu abertura para escrever sobre assuntos que eu gostava mais, tinha certa liberdade. Era um veículo que juntava o pessoal mais ligado em política e impresso e deu muito certo.\nCI – Faz idéia de quantos textos já escreveu para o Canal? Desses, qual foi o que mais gostou e por quê?\nFabiana – Não tenho noção de quantos foram, mas são muitos. Fui uma das primeiras no Canal e já vi o veículo como um treinamento importante para a minha formação. Além disso, não há prazer maior para um jornalista do que ver seu texto publicado e lido por centenas de pessoas. Tenho alguns que são especiais. O “Egüinha, uma ova” foi um desses. O professor Ruben Holdorf mandou para vários jornais, sem me contar. Depois fiquei sabendo, pela tia de uma amiga, que o texto tinha sido utilizado como exemplo numa aula de Sociologia na PUC-RS, depois de ter sido publicado no jornal Zero Hora, do Rio Grande do Sul.\nCI – Qual foi o maior sufoco que passou no Canal?\nFabiana – Sufoco pode ser encarado de muitas formas. Acho que todo fechamento era um sufoco. Eu tinha mania de entregar tudo faltando pouco para fechar e o editor queria me matar. Guardadas as proporções, o Canal é exatamente como um organismo de mídia aqui fora, profissional e comercial, então a cobrança era séria. Claro, ficar trancada no prédio, porque o monitor fechou tudo e nos esqueceu lá na sala, também pode entrar na lista dos sufocos.\nCI – Você era uma articulista famosa pela agilidade ao escrever os textos, além de os artigos serem muito bem escritos. Durante o seu período na redação do Canal, você ajudava a escrever na última hora os textos que faltavam?\nFabiana – O “famosa” fica por sua conta, mas tinha facilidade sim em escrever rápido, o que ajudava meu amigo Fernando, editor num dos períodos do Canal, a fechar edições cujos autores (ir) responsáveis tinham comprometido. Devo confessar que gostava da adrenalina do fechamento, aquele estresse todo, a sensação de dever cumprido. Fiz muitos textos em 15 minutos e nem todos ficaram bons, devo admitir. O Fernando até dizia que eu era a “rainha dos 15 minutos”. Veja, pensar e escrever rápido é uma habilidade que nem todos podem herdar, mas escrever bem é para todos que se dedicarem. Acredito que textos soberbos, daqueles que você degusta com prazer e aflição, são para poucos abençoados, mas com esforço e dedicação, qualquer estudante pode escrever com primor. O segredo é ler, ler, treinar, treinar e treinar. Meu professor Ruben dizia que deveríamos escrever todos os dias, nem que fosse um e-mail. Ouvi isto há oito anos e nunca deixei de praticar.\nCI – Como avalia o desempenho da revista durante o período em que atuou?\nFabiana – Fomos felizes. Esta, sem dúvida, é uma afirmação compartilhada com meus parceiros daquela época. Tivemos problemas e sofremos retaliações, mas crescemos e a revista foi um espelho disso. Em muitas edições superamos nossas próprias expectativas e as dos outros e viramos referência. Tanto é que outro dia me peguei pesquisando um assunto no Google e fui levada a usar como referência um texto de um amigo, contemporâneo. Isto é credibilidade.\nCI – Quais foram os progressos que observou no Canal desde a época em que foi articulista até o momento?\nFabiana – Nossa, o Canal só melhora. Acho que ele nasceu para isto, constante evolução. O grupo de pessoas que fizeram o Canal de quatro anos atrás, quando eu saí, já era diferente de si mesmo, quando começou, oito anos antes. As condições de estágio, prática e tecnologias de que desfrutam os alunos hoje podem ser pilastras seguras para um trabalho mais e mais profundo, contudo, há o perigo de ser tão fácil, que não se dê o devido valor. Na minha época disputávamos uma máquina à tapa, então tudo era muito bem pensado e digerido. Hoje, com tanta facilidade, a superficialidade pode rondar o trabalho, o que desandaria o caldo.\nCI – Alguns estudiosos acreditam que o melhor lugar para se fazer crítica de mídia é dentro da universidade. Qual a sua posição sobre a idéia?\nFabiana – Como falei antes, é perigoso criticar. Eu sou, e fui ainda mais, crítica. Vemos os professores experientes criticarem e lá vamos dando nossos “pitacos” aqui e acolá. Mas a vida profissional de verdade é muito mais complexa do que lemos no quadro negro. Do confortável banco da inexperiência é fácil condenar quem está exposto. Falar de um jornalista, apresentador, de um repórter ao vivo, sem sentir a pressão que vem de cima. Além do mais, universidade é para isto mesmo, avaliar, criticar, mas sem perder as estribeiras. Também considerando que quem está na chuva não ganhou guarda-chuva para a função. Então, bom senso!\nCI – Por outro lado, também existem acadêmicos que são contrários a alunos escreverem textos de opinião porque acreditam que estudantes não têm ainda uma visão de mundo completa para se posicionar contra ou a favor de alguma coisa. Qual sua opinião a respeito disso?\nFabiana – São fases. No primeiro ano enxergarmos o mundo bem dualista. Como para alguns ainda existe o mundo vermelho do comunismo, para muitos as coisas ficam entre bem e mal, pronto. Com o passar do tempo, você descobre que as cores são mais variadas e que a combinação delas pode resultar em coisas que você ainda não entende. Opinar é bom e ajuda a concretizar em quem opina a sua própria visão, mas ela não pode ser estática, pois pessoas e coisas estão em constante mudança.\nCI – De que forma sua participação contribuiu para a sua formação profissional? O trabalho na redação do Canal pode ser considerado profissional, apesar da natureza acadêmica?\nFabiana – De forma profunda. Digo a quem quiser ouvir que a participação no Canal e em outras atividades práticas no curso de Jornalismo do Unasp foi fundamental para a segurança na hora de conseguir emprego. Lá fora, ninguém liga muito para o seu diploma, verdade seja dita. O editor quer saber se você sabe escrever, articular, entrevistar e tudo isto num tempo hábil para não comprometer o fechamento. Praticar isto durante quatro anos, aí no Canal, me deu este know-how. Não fiquei apreensiva, nervosa ou insegura nos meus testes de emprego, simplesmente fui e fiz, do jeito que tinha aprendido. Sem falar que quando está aí, você tem os quatro anos para ser burilada e saber exatamente onde focar.\nCI – Que dica daria para alunos de Jornalismo que queiram se destacar ou seguir carreira em jornalismo opinativo, especialmente crítica de mídia?\nFabiana – Primeiro ter opinião. Muitos estudantes, e digo isto por experiência e convivência, acham que falar mal dos outros, criticar o tempo todo, é ser inteligente, intelectual e outros rótulos que julgam importantes e distintivos. Mas não é assim. O espírito crítico é necessário, mas criticar tudo e todos torna a pessoa azeda e sem noção de realidade. Alguém assim se julga superior aos outros, sem necessidade de correções próprias e o fracasso o espera bem ali à frente. Avaliar as coisas tendo como parâmetro sua experiência de vida e a opinião de muitos outros mais entendidos do que você é uma chave que abre preciosas portas em direção ao sucesso nesta área.\nEvelyn disse:\t23 de dezembro de 2010 às 18:27\tOlá minha querida. Acho realmente que você é a “pessoainha” que descreve!!! Mas acho ainda que além das características acima “amiga, louca, irreverente, bravinha, trabalhadora, sonhadora…” Você é modesta, pois eu poderia mencionar vários outros adjetivos e anexá-los a você! Não vou fazê-lo, pois iria parecer “puxa-saquismo” Então, quero apenas lhe dizer que o seu trabalho é maravilhoso, você escrever, atuar, aconselhar, agir. Sem dúvida é uma escritora!\nParabéns… e sem puxa-saquismo!!! mas… sou sua fã!\nEvelyn Tupan/Ji-Paraná RO\n» Reply to this Comment «\tJAMES disse:\t23 de março de 2011 às 1:49\tBORING!\n» Reply to this Comment «\tNazaré souza disse:\t6 de julho de 2012 às 22:49\té de pessoas como vc qi o mundo ta precisando\nqi o Senhor te abençoe…


Revista Multticlique 151 by Revista MulttiClique - issuu\nFlagramos os caras mais inteligentes do ‘showbizz’. Alguém poderia imaginar, por exemplo, que o bruto Dolph Lundgren tem o mesmo QI que Albert Einstein?\n-listSet-list Paris Is Burning Ladyhawke\nEnquanto Berlim, na Alemanha, chama a atenção dos turistas, o sofisticado Schlosshotel já entrou na rota dos fashionistas.\nDestaques para os 278 quartos e para o restaurante gourmet Vivaldi, onde se pode saborear pratos imaginativos da culinĂĄria mediterrĂ˘nea e francesa.\nMembro do ‘The Leading Hotels of The World’, foi decorado por Karl Lagerfeld que transformou a mansão de 1914 em um verdadeiro templo de luxo.\nElegĂ˘ncia e bom gosto estĂŁo presentes em todos os detalhes deste hotel, com estilo barroco numa ĂĄrea residencial em Berlim.\nU O L E V Ó M O T AU E T R A E D A OBR ops\nTeardr e p u o C 3 o T2\nOO Talbot Lago T23 Coupe Teardrops de 1938 é uma obra prima, um dos maiores objetos de desejo entre os colecionadores de carros antigos em todo o mundo. E sua excepcional beleza é resultado da criação do italiano Joseph Figoni, que projetou a carroceria de muitos dos automóveis\nmais cobiçados, como Delahaye, Bugatti, Renault, Delage, Panhard, Alfa Romeo, Rolls Royce... Os exemplos de seus trabalhos são de tirar o fôlego.\nAcredita-se que apenas 16 unidades do Teardrops foram construídas. Uma delas, a das fotos, foi leiloada pela RM Auctions por US$ 2.640 milhões. Sua última restauração, em 2010 foi perfeita. O leilão foi muito disputado. Motivo: o Talbot Lago T23 Coupe Teardrop 1938 é uma obra-prima da arte francesa e suas linhas de proporções suaves e elegantes representam o design francês da pré-guerra.\nFicha técnica: o Teardrop T23 é alimentado por um motor de seis cilindros em linha de 3996 cc que gera 115 cv de potência. Tem carburadores duplos e câmbio de quatro marchas. A suspensão dianteira é independente, com feixe de mola transversal, a traseira é com molas semi-elípticas e têm freios a tambor nas quatro rodas.\nOS 10 STY L PODEROS O\nEx-assi stente d Anna Wintou e r, n Vogue americ a Kate Y ana, oung ĂŠ adept a de u m estilo m inimal is e sofis ticado ta ao vestir c elebrid ades como , Nata lie Portma n, Mic h Willian s, Rac elle hel Weisz e Alici a Keys .\nLISTS MA IS OS DE HO LLYWOOD ra\ne l r a sc\nComentadĂssimos, os looks de Leslie Fremar sĂŁo garimpados nas araras de labels como Dior, Prada, Stella McCartney e Azzedine Alaia.\nso s n a h\nPetra Flannery é a stylist responsável por transformar a novata Emma Stone em um ícone fashion. Com produções incríveis, costuma apostar na ousadia para vestir suas jovens clientes.\nA ex-stylist da â€˜The New York Times Magazineâ€™ Elizabeth Stewart ganhou status de estrela no mundo da moda ao conquistar seguidoras como Freida Pinto, Jessica Chastain e Viola Davis.\ntewart S h t e b a e liz\nelch W a l Kar\nA dupla Kemal Harris e Karla Welch, conhecida por investir nos acessórios em suas produções, é fã de maisons como Gucci, Marchesa, Prabal Gurung e Miu Miu.\nle b i e\nA namorada de Mick Jagger Linren Scott ĂŠ uma das stylists mais procuradas de Hollywood. Entre suas clientes estĂŁo as sempre bem vestidas Nicole Kidman, Sarah Jessica Parker e Gwyneth Paltrow.\nltr a p h t ne\nott c S n L'Wre\nResponsรกveis pelos looks ousados e sensuais de clientes de peso, como Jennifer Lopez e Rihanna, as stylists Mariel Haenn e Rob Zangardi arrasam nos tapetes vermelhos.\ner f i n\ndi r a g n a Rob Z\nMariel H aenn\nRachel Zoe ĂŠ uma das maiores e mais poderosas formadoras de tendĂŞncias do planeta fashion. E conta com clientes como Anne Hathaway, Cameron Diaz, Kate Hudson, Miley Cyrus, Eva Mendes, Liv Tyler e Demi Moore.\nn o s ud\nAlém de ‘curadora’ do visual das principais trend setters de 2012, entre elas as irmãs Dakota e Elle Fanning, Samantha McMillen também foi a responsável pela repaginada de Kristen Stuart.\nnin n a f\nle l i cM\nEXY O nome dela é Malika Favre, a dama do colorismo. Com linhas limpas, fluidas e um nervosismo sedutor, seu trabalho tem um certo ‘je ne sais quoi’ que nos conquistou.\nCom fãs famosos como Rooney Mara, a francesa consegue expressar em suas coleções toda a sensualidade das formas.\nDepois de trabalhar com clientes como Vogue, Chloé e Wallpaper Magazine, o seu compromisso é com a auto-expressão.\nARTE Extra, extra. A designer Sarah Illenberger bolou esta coleĂ§ĂŁo que transforma objetos do cotidiano em verdadeiras obras de arte.\nA alemĂŁ passou dois anos modelando e criando combinaĂ§Ăľes super divertidas.\nDepois de interpretada, a arte pode passar sensações ainda mais liberais em relação a realidade. Muito louco!\nRevista Multticlique 151


Controle financeiro de clínicas: veja como aumentar sua rentabilidade\nAumente a rentabilidade da sua clínica com nossas dicas de controle financeiro\nCarolina Sossai Cardoso 13 de maio de 2022\tLeitura: 5 min\nOs pacientes são prioridades na sua clínica, certo? Afinal, os profissionais de saúde trabalham para oferecer uma melhor qualidade de vida e bem-estar para eles.\nPorém, um consultório médico também é uma empresa que precisa se manter no mercado. Logo, é preciso ter uma gestão eficiente — que engloba diferentes setores do negócio.\nUm deles é o controle financeiro. Será que ele é uma das suas preocupações? As suas finanças estão da forma como você esperava? Você tem capital para investir no futuro do seu negócio?\nGeralmente, lidar com o lado financeiro de uma empresa requer bastante atenção e cuidado para não gastar os recursos ou tomar decisões erradas que afetem toda a sua estrutura.\nJá que os médicos sabem bem a importância de uma cirurgia. Vale ter em mente que o financeiro também requer a mesma atenção! Cada centavo pode impactar uma empresa de formas diferentes.\nContinue a leitura e descubra como melhorar a gestão financeira da sua clínica!\nTenha em mente a importância do controle financeiro na clínica\nO controle financeiro é uma as estratégias utilizadas nos negócios que ajudam muito em momentos de crise, por exemplo. Além disso, ele um recurso importante para o gestor tomar as medidas certas diante dos indicadores da clínica.\nEm um cenário como o da pandemia do coronavírus, muitos médicos tiveram suas rendas afetadas de forma negativa. Nesse contexto, aqueles que realizam um maior controle financeiro têm mais facilidade de lidar com a situação e identificar quais gastos podem ser cortados ou não — evitando prejuízos.\nEm um cenário positivo, a gestão financeira auxilia na identificação de ações para a empresa realizar investimentos, compras de materiais ou outras atividades. Além de tudo, não há forma mais prática de compreender se o objetivo financeiro do seu negócio está sendo atingido.\n💡 Leia também: Dicas de como manter seu faturamento mensal em dia\nPrimeiramente, eu te pergunto: você já montou um planejamento financeiro para sua clínica?\nUm dos primeiros cuidados em relação a saúde financeira de uma empresa é o planejamento dos valores que entram e sai do consultório. Se você já tem um plano montado, está fazendo da maneira correta?\nMuitos gestores costumam se dedicar a essa atividade somente no início do ano. Você faz isso também? Entretanto, saiba que o ideal é se dedicar ao planejamento financeiro antes do ano terminar, por volta de setembro ou outubro.\nAfinal, a ideia aqui é planejar e traçar as ações para o próximo ano. Assim, sempre que o ano vira, sua clínica ou consultório apresenta um bom controle financeiro e está preparada para mais uma jornada.\nAlgumas dicas seu planejamento financeiro são:\nEstabeleça objetivos e metas para seus investimentos;\nMapeie os passos da sua clínica;\nPlaneje projetos de expansão;\nOrganize melhorias na estrutura do consultório;\nFaça um levantamento financeiro para estipular seu progresso.\nAcompanhe os principais indicadores de controle financeiro\nLogo acima deste conteúdo, citamos a palavra indicador financeiro da clínica…Mas, você sabe o que são?\nBasicamente, essas métricas são formas de mensurar e determinar o estado financeiro da sua clínica. Alguns dos principais indicadores são:\nRetorno sobre investimento (ROI) — muito usado em ações de marketing médico;\nLucro bruto e líquido.\nAgora que você conhece esses exemplos, é importante entender o motivo pelo qual eles são relevantes para o controle financeiro do seu negócio.\nDe modo geral, acompanhar esses indicadores são uma das formas mais simples de visualizar os principais aspectos financeiros do consultório. Por isso, é fundamental manter essas informações em dia e organizadas.\nDessa forma, o responsável pelas finanças pode consultar esses dados e identificar quaisquer mudanças nessas pilares e tomar as melhores decisões para a empresa.\n💡 Já conhece a ferramenta de gestão financeira da 4Medic? Clique aqui para saber mais.\nOutra dica fundamental para melhorar o controle financeiro de uma clínica é realizar um fluxo de caixa adequado. Isso é essencial para garantir que uma baixa nos lucros ou ganhos no seu faturamento não seja uma surpresa no final do mês.\nAntes de aplicar essa dica, que tal conhecer os maiores erros de fluxo de caixa? Assim, você sabe o que NÃO deve fazer para seu negócio enfrentar dificuldades.\nAlém disso, esse controle financeiro favorece no pagamento das contas da empresa, bem como no repasse financeiro e outras atividades. Com ele, também é possível prevenir atrasos e organizar as despesas.\nPrevenir é o melhor remédio, certo? Então, não deixe de preparar um fundo de reserva para sua clínica como método de controle financeiro. A pandemia é um exemplo da importância dessa ação para um negócio.\nNão importa qual é o seu segmento, invista em uma reserva de emergência para sua clínica a fim de cobrir quaisquer problemas ou imprevistos ao longo da sua jornada.\nDessa forma, sua empresa sofrerá menos impacto quando uma crise econômica se instalar e reduzir o poder aquisitivo das pessoas.\nFaça um bom uso da tecnologia\nSe a gestão financeira da sua clínica não está funciona, certamente, você está enfrentando problemas na empresa. Não há ninguém que fica tranquilo quando algum problema financeiro está abalando o seu serviço.\nMuitas vezes, algumas erros e problemas prejudicam o controle financeiro por esta tarefa ser realizada de forma inadequada.\nSabe os consultórios que utilizam papéis, canetas e calculadoras para controlar as finanças? Provavelmente, já enfrentaram situações em que algum papel foi perdido, rasurado ou simplesmente algum dado foi inserido ou calculado de forma errada, precisando refazer todo o processo.\nHoje, tudo que fazemos já está automatizado graças a tecnologia. Os softwares médicos são um exemplo claro de que é possível otimizar o serviço de saúde e ainda oferecer um melhor atendimento aos pacientes. Isso porque, ao utilizar essas ferramentas, você agiliza o serviço da clínica, reduz erros, diminui gastos e facilita o trabalho dos profissionais e das secretárias.\nEssas vantagens seriam um sonho não é mesmo? Então, aproveite para experimentar um sistema de gestão para clínicas e descobrir seus benefícios na prática! É só clicar no banner.\nViu como o controle financeiro é fundamental para melhorar a gestão dos valores que entram e sai da sua clínica?\nAtualmente, qualquer negócio que deseja sobreviver no mercado, ter uma boa rentabilidade e se destacar deve criar um planejamento financeiro e organizar seu fluxo de caixa. Aplique nossas dicas e veja como seu negócio pode se transformar.\nTags: financeiro | gestão médica\nAnterior Sofre com buracos na agenda médica? Veja como evitá-los!\nPróximo Aprenda a ser uma ótima recepcionista de clínica e fidelize mais pacientes\nAtendimento de qualidade: o segredo para reter mais pacientes na sua clínica Continue Lendo\nSofre com buracos na agenda médica? Veja como evitá-los! Continue Lendo