No último artigo, começamos a falar sobre a evolução da tecnologia, abordando o sistema de Banco de Dados, integridade referencial, restrições ou constrains, controle de transação, acesso multiusuário, segurança dos dados, e Stored Procedures e Gatilhos (triggers). Hoje, seguiremos com o assunto, tratando sobre microinformática, Windows e redes. Acompanhe!

Microinformática

No início da década de 80 tivemos a revolução da microinformática. Com recursos limitados, pouca memória, lentos e pouco espaço para armazenagem de dados, sistemas operacionais CP/M e depois DOS e linguagens como Basic e Assembly, os primeiros microcomputadores foram questionados por todos que trabalhavam nos equipamentos de grande porte e nos modernos minicomputadores nacionais (Cobra, Labo, Edisa, SID e Sisco, entre outros), frutos da Reserva de Mercado que se instalara no país.

Foi o surgimento do PC-IBM (Personal Computer), em 1983, que possibilitou verdadeiramente o processo de downsizing, ou seja, a transferência de grandes sistemas dos mainframes para os micros.

E para tal não se podia pensar em fazer todo o processo em um único micro, ou mesmo em um conjunto deles, mas totalmente desconectados entre si. Até que houveram tentativas deste tipo, fazendo-se a transferência de dados através do transporte físico em disquetes. Mas foram as Redes que definitivamente resolveram estes problemas. Inicialmente pensou-se no mais óbvio. Simplesmente conectar-se os micros através de cabos, cada um armazenando parte dos dados, mas todos acessando os vários discos espalhados pela rede.

Era a rede peer-to-peer, que ainda apresentava a vantagem de uma escalabilidade gradual, pois bastava acrescentar-se novas máquinas com discos à medida que aumentassem as necessidades. Mas esta descentralização de dados não deu certo.

Bastava uma máquina parar e toda rede ficava prejudicada. Em cada uma era preciso ter todos os controles de I/O (input e output) de dados armazenados, o que consome muitos recursos de memória e processamento e era impossível coordenar todos os arquivos do aplicativo, espalhados pela rede. Amplus e Novell foram as empresas que mais investiram nesta solução, econômica, porém altamente instável.

A alocação de um Servidor dedicado foi a próxima solução. Reserva-se uma única máquina, mais parruda, no máximo uma segunda para espelhamento de dados, para gerenciar e manter toda a base de dados. As estações ficavam com o processamento e controle de teclado e tela, o Servidor armazenava os dados.

O Clipper, da Nantucket/CA e sucessor do Dbase, foi quem se sobressaiu nesta época, que se iniciou em 1987 com a versão Summer e só teve sua trajetória interrompida com a chegada do Windows, da Microsoft, já em meados da década de 90. Isso depois de uma sofisticada Versão 5, ainda DOS, e que continha comandos e recursos agora já bem comparáveis aos velhos mainframes. E até com uma pincelada de Windows, através do Five-Win, biblioteca espanhola, que dava ao Clipper funções gráficas de extremo bom gosto.

Windows

Windows é um sistema orientado a eventos. É gráfico, portanto o desenvolvimento é visual. Além disso, as linguagens disponíveis são orientadas a objeto. Contrariamente ao que ocorre com a programação procedimental, onde a sequência das ações é controlada pelo programa, em Windows, quem controla esta sequência é o usuário, através do mouse. Com ele, é possível clicar qualquer botão ou campo habilitado na tela e a resposta tem que ser específica para aquele evento. Windows envia ao programa uma mensagem, comunicando-lhe sobre o evento. Tratado o evento, o programa devolve o comando para Windows. Windows pode, grotescamente, ser considerado uma super aplicação enquanto que os programas são meras sub-rotinas que estão sob seu controle.

O fato de ser gráfico faz com que boa parte dos programas sejam desenvolvidos de forma Visual, ou seja, ao invés de escrever-se o código fonte, insere-se os elementos na tela a partir de uma janela de CLASSES. Os elementos criados são os OBJETOS, instâncias das Classes. Customiza-se os Objetos alterando-se suas propriedades e métodos. É a OOP – Object-Oriented Programming (Programação Orientada a Objetos).

A partir deste trabalho, é gerado um código fonte, que pode ou não ser modificado. Mas a programação Visual resolve apenas parte dos problemas de aplicação: telas, controles, menus, relacionamentos, etc. A parte de procedimentos, ou seja, as regras de negócios, precisam ser escritas na forma tradicional.

Redes

Mas voltando às redes, um grave problema ainda persistia. O fato de praticamente todo o processo ser realizado na estação e o servidor ser um mero repositório de dados fazia com que fosse intenso o tráfego na rede. Razoável em redes locais – LAN (Local Area Networks), onde a velocidade de transmissão logo atingiu 10 mega bits por segundo (Mbps), mas extremamente lenta quando utilizava as linhas telefônicas, a no máximo 9,6 kbps.

O processamento remoto exigia uma série de soluções alternativas, como o Metaframe e o Cisasync, que por serem complexas, não resolviam todos os problemas. O Metaframe simulava uma estação local escrava do terminal remoto, usando para isto um servidor de comunicação e o Cisasync fazia o espelhamento de dois servidores remotos, mantendo-os atualizados e cada um atendendo as estações de sua localidade.

Por outro lado, a arquitetura cliente-servidor caminhava a passos largos impulsionada pelo progresso e, principalmente, pelo barateamento das soluções SQL. Oracle, IBM, Sybase, Borland pressionadas pela agressiva entrada do SQL Server da Microsoft, também baixavam seus preços e viabilizaram a arquitetura para a microinformática. Processamento centralizado com servidores robustos e estações leves, por vezes disk-less, ou seja, sem discos de alta capacidade, já pensando na multiplicidade de novos e simples dispositivos de acesso, lembrando as antigas configurações de mainframes com seus terminais burros.

Mas as Stored Procedures do SQL ainda não eram a solução perfeita. Incompatíveis entre si, trabalhosas em seu código e sobrecarregando o Servidor de Dados, forçaram mais um desmembramento. Surgia o Servidor de Aplicações que forma, juntamente com a Estação e o Servidor de Dados, a arquitetura de 3 camadas (3-thiers) depois expandida para multi-camada (multi-thier) com o desmembramento dos Servidores de Aplicação.

Cada um cuidando de uma parte da aplicação, sendo que neles pode-se programar em qualquer linguagem. É o início de uma forte tendência para a distribuição de carga do processamento denominada computação de grade (OGSA – Open Grid Services Architectutre).

Houve também uma evolução no hardware das máquinas, passando de 8 bits, depois para 16, 32 e agora 64 bits. O Windows acompanhou esta evolução, conforme surgiam novas versões.

As principais diferenças para o usuário e o programador que esta evolução traz são as seguintes:

Nas arquiteturas de 16 bits havia a restrição de páginas de memória de até 64k. Isto gerava a necessidade de segmentação dos programas em overlays de até 64k, além da restrição de espaço de variáveis também de 64k. Estes problemas deixaram de existir a partir das arquiteturas de 32 bits.

Outro problema encontrado nas arquiteturas de 16 bits era o fato de poderem trabalhar com multitarefa, porém não de forma preemptiva. Isto significa que o próprio processo era o responsável por sinalizar o Windows, na versão 3.1, que o seu tempo de processamento acabou podendo ocasionar o travamento de todo o sistema caso um processo estivesse, por exemplo, em looping.

A alocação da memória era outro fator que poderia ocasionar o bloqueio de todo o sistema no caso de um determinado processo tentar invadir o espaço de memória reservado para outro processo.

Com a versão do Windows para 32 bits estes problemas foram solucionados. A alocação da memória deixou de ser realizada através de páginas de 64k, possibilitando uma alocação integral da memória. A partir desta versão, o Windows passou a ser um sistema multitarefa preemptivo e incorporou um recurso para a proteção de memória que não permite a alocação de espaços reservados.

A proteção de memória passou a gerar os conhecidos erros GPF (tentativa de invasão) apenas para o processo que tentasse alocar um espaço de memória já reservado, preservando a execução dos demais processos.

Como se vê, as mudanças são rápidas, muitas empresas concorrentes tentando resolver problemas complexos que surgem quando se quer melhorar o que por vezes já está bom. Mas não se pode desistir, é preciso ser persistente. É a máxima que diz: a concorrência é a mola da evolução.