Atualmente, cerca de 60 a 80% de todas as informações corporativas residem em mainframes e, a despeito da revolução da Internet e do protocolo IP, as vendas deste tipo de computador continuam ascendentes. 

Existem diversas razões para a durabilidade das máquinas heavy metal: o custo mais baixo de administração dos usuários, alta performance, confiabilidade, alta disponibilidade, forte apelo à segurança e excelente controle de acesso, além da incomparável escalabilidade. Em adição, os fabricantes de mainframe passaram a explorar estas vantagens, reposicionando suas máquinas para aplicações Internet e transformando-as em verdadeiros "super-servidores". Mais importante, porém, é o fato de que muitíssimos processos de negócios das companhias foram encapsulados em lógicas de aplicação de mainframes; sendo eles, o repositório, de fato, do grosso da experiência e do conhecimento das corporações. 

Entretanto, não há dúvida de que, levando-se em conta as novas gerações de interface gráfica com o usuário (GUI), as aplicações legadas de mainframe deixam muito a desejar em termos de amigabilidade, o que tende a elevar de forma preocupante os custos de treinamento e o nível de exigência profissional da parte dos usuários. 

E o que é pior: é muito difícil e caro modificar ou personalizar estas aplicações, especialmente por este tipo de operação exigir programadores com conhecimentos cada vez mais raros, como os de linguagem Cobol, e de alto custo de contratação. Esta inflexibilidade de interface e de linguagem faz com que os mainframes dificultem o passo das corporações para as rápidas mudanças que se fazem cada vez mais necessárias. 

Cinco Rs - Esta realidade motivou incontáveis tentativas para estender ou revisitar as aplicações de mainframe, através do seu uso como matriz de dados ou transações e lógicas de negócios, utilizando-se um dos cinco métodos que nós chamamos os Cinco Rs. A seguir, um resumo deles: 

Refaceamento (Refacing): trata-se da recolocação da emulação de tela, numa base de um para um, com a interface gráfica, sem qualquer mudança na aplicação legada.

Re-direcionamento (Repurposing): é o método de se capturar, encapsular e apresentar as lógicas de negócios baseadas em telas usando-se diversas novas telas e sistemas empresariais, sem mudanças na aplicação legada. 

Restruturação (Restructuring): pode-se modificar as aplicações empresariais separando-se telas/negócios/lógicas de dados; 

Reengenharia: utilizar uma aplicação usual como início ou construir uma nova a partir desta; 

Reposicionamento (Replaicing): apela para uma aplicação não de prateleira (como uma ferramenta SAP, por exemplo), que reposicione a aplicação empresarial em novas bases, mais próximas da camada do usuário. 

Tecnologia sreen-craping - Um dos mais recentes e bem sucedidos métodos de extensão das aplicações de mainframe é conhecido como screen-scraping (N.E.: escovação de tela) podendo ser utilizando tanto para refaceamento quanto para reposicionamento. 

O screen-scraping é também conhecido como navegação baseada em tela, ou captura de dados. Consiste em se ler o fluxo de dados enviado para o que seria um terminal de mainframe (ou via um cliente emulador de terminal, ou via um programa de servidor) e transformar isto numa apresentação gráfica, mais parecida com o que o usuário espera de uma aplicação de desktop. Ao fazer isto, evita-se a necessidade de qualquer mudança na aplicação de mainframe, tornando-o ao mesmo tempo mais amigável. Em outras palavras, esta técnica possibilita substanciais modificações na seqüência e conteúdo das apresentações de tela, combinando diferentes telas de mainframe numa única tela gráfica realmente prática e adequada ao serviço. 

Como já foi notado, o screen-scraping de tela é usado no refaceamento e no redirecionamento de aplicações de mainframe. No caso do refaceamento, trata-se simplesmente de permutar as telas de emulação de terminal, numa base um a um, por interfaces gráficas. 

Já o redirecionamento de aplicações explora o fato de que a lógica de negócios de uma aplicação legada é, em grande medida, exposta pela seqüência de telas evocadas pelas ações do usuário do emulador de terminais. Neste caso, pode-se capturar e encapsular esta lógica, através da combinação de múltiplas telas, em uma forma mais confortável para o uso. 

Mudando a face do screen scraping - Ultimamente o screen scraping vem caindo em desprestígio em alguns meios, nos quais é freqüentemente tido como um mal necessário, por ser demasiado lento, incômodo e de manutenção difícil.

Entretanto, este tipo de avaliação é, na verdade, baseado em aplicações de vários anos atrás, sem considerar que, como tudo no mundo da informática, o screen-scraping conta hoje com opções de excelente custo-performance e conforto de uso. 

Na realidade, o acesso baseado em telas possui uma série de vantagens que o fazem uma poderosa ferramenta para melhorar e estender a utilidade das aplicações legadas. Entre elas, podemos destacar: habilidade de prover dados críticos para os usuários em tempo real; rápido desenvolvimento sem mudanças no host (N.E.: hospedeiro); baixo custo; redução nos custos de treinamento e help-desk. Essencialmente, o acesso screen-based de hoje é muito diferente de um simples screen scraping de ontem - e estas diferenças não são apenas cosméticas. 

Hoje, a nova tecnologia suporta inúmeros ambientes de desenvolvimento; permitem que as aplicações legadas sejam acessadas a partir de diferentes plataformas (incluindo Internet e intranet); são mais escaláveis, fáceis de usar e requerem treinamento mínimo. Assim, não é de se surpreender que, de acordo com uma análise encomendada pela Attachmate e feita por uma firma independente, muitos profissionais de Tecnologia da Informação (TI) ainda ancorem grande parte de suas aplicações criticas nesta técnica. 

O que estes profissionais perceberam, enfim, é que em muitos casos, esta solução simples e rápida pode oferecer o melhor dos dois mundos: a confiabilidade dos mainframes associada à facilidade de sua implementação de um lado e, de outro, uma forma rápida e barata de se implementar a interface gráfica. 

A Survey.com, uma empresa independente de pesquisa de mercado, conduziu uma sondagem junto a profissionais de TI para verificar sua atitude diante da técnica de escovação de tela. Um total de 536 pessoas responderam; destas, 13% estavam envolvidas em administração, manutenção ou gerenciamento de mainframe e outros sistemas legados. Muitas estavam diretamente envolvidas em acessar informações armazenadas nestes sistemas. 

Quase 60% destes profissionais usam alguma tecnologia de captura de dados para integrar os sistemas legados com novos desenvolvimentos ou novas aplicações cliente-servidor. Cerca de 45% enviam dados para o servidor através de uma aplicação cliente, e um número semelhante modifica aplicações do host. Isto mostra que, embora muitas empresas usem vários métodos para a integração de sistemas legados, o trabalho a partir das telas é ainda o mais popular método para a atualização de aplicações de mainframe. 

A propósito, nenhuma surpresa, considerando-se as facilidades do método quando se trata de acessar dados. Porém quando a necessidade é o envio de dados em tempo real (e aqui estão incluídas, por exemplo, as aplicações de vendas assistidas por computador), aí esta técnica apresenta seu ponto fraco. Seja como for, ao se partir para métodos capazes de operar mudanças nas aplicações de host, deve-se considerar o que isto significa em termos de esforço e risco. 

Não reinventemos a roda - A razão fundamental para a contínua popularidade do acesso a dados baseado em telas foi claramente colocada pelas empresas que responderam a pesquisa Survey.com. "As aplicações legadas já têm todas as funções desenvolvidas: devemos reinventar a roda?, é o que estas empresas se perguntam". 

Como se  viu, não é surpreendente que cerca de 60% das empresas pesquisadas pela Survey.com responderam que  utilizam o acesso de tela "para evitar mudanças nas aplicações de host". Aliás, muitos sistemas legados  possuem aplicações de interface que, simplesmente, não podem ser reescritas, a não ser através de  serviços de programadores Cobol, o que torna o seu custo proibitivo e eleva o seu TCO (N.E.: custo total de propriedade) às alturas. 

Acesso screen-based... sem preconceito - Com todas estas vantagens, alguns se perguntam de onde viria então aquele relativo desprestígio do acesso baseado em tela em certas paragens. 

Ocorre que quanto esta técnica se tornou conhecida, muitos anos atrás, os produtos de tela baseados na emulação de terminais exigiam altos conhecimentos em HLLAPI e suas variantes EHLLAPI, WinHLLAPI, as APIs desenvolvidas pela IBM e outros para acessar buffers (N.E.: memórias intermediárias) de telas de terminais 3270 e 5250. Era altamente difícil integrar aplicações de tela com outras fontes de dados ou aplicações de desktop. A performance era sempre pobre, assim como a escalabilidade, de modo que os primeiros produtos baseados em tela não podiam acessar mais de uma tela por vez. 

Talvez, o maior complicador, porém, fossem as mudanças necessárias para o sistema sustentar as telas de aplicações legadas, que envolviam complexas modificações de código e sua redistribuição. Contudo, nos modernos sistemas de acesso baseado em tela, todas estas objeções já foram por água abaixo. Já não se exige conhecimento em HLLAPI e suas variantes. Por exemplo, o ambiente de desenvolvimento NavDesigner, que vai incluído no Attachmate e-Vantage HostPublishing System, permite simplesmente indicar áreas as da tela ou das telas que devem conter os dados desejados. 

O NavDesigner, em conjunção com um mecanismo de navegação oculto, oferece automaticamente as tarefas exigidas para o acesso aos dados. Isto é mais ou menos o que se fazia através de códigos HLLAPI nos primeiros programas screen-scraping, só que agora de forma totalmente automática. 

Além disto, as tecnologia de integração extensiva, que estão embutidas no ambiente Windows, incluindo recursos de OLE, COM, e DCOM, eliminaram as dificuldades de integração. Os dados obtidos a partir de programas de captura de tela, assim como de aplicações client-servidor, podem ser facilmente integrados com outras aplicações na linguagem e ambiente escolhidos pelo programador. 

Juntamente com estes avanços, há a moderna tecnologia de OOP. Por exemplo: o Attachmate Enterprise Access Objects garante acesso de duas vias client based (N.E.: baseadas no terminal-cliente) para informações de sistemas legados a partir de uma vasta gama de aplicações de front-office. 

Quanto a performance e escalabilidade, hoje, os sistemas de acesso baseados em tela são quase tão rápidos quanto as formas de acesso tradicional. Um exemplo é dado pelo Attachmate HostPublishing System Server (HPS). Ele é capaz de carregar até 40 transações por segundo e até 5 mil usuários simultâneos através de um servidor Microsoft de Internet (IIS), só não superando esta marca por limitações do próprio IIS. 

É bem verdade que a habilidade de suportar múltiplas telas continua crítica em alguns níveis. Porém, a dificuldade não está na solução de acesso e sim na capacidade da própria aplicação legada em apresentar telas de forma consecutiva. Ocorre, porém, que a Attachmate está projetando a próxima geração de ferramentas para acessos baseados em tela que vão ser capazes de antecipar as ações do usuário em alguns níveis e enviar informações para um cachê, tal como se elas fossem requisitadas por múltiplas seções em vias paralelas. Finalmente, muitos profissionais de TI se preocupam com os impactos das mudanças nas aplicações legadas, seja pelos esforços de programação ou da sua distribuição em código. 

De fato, qualquer mudança em níveis abaixo dos das telas requer mudanças na aplicações de mascaramento. Mas, o impacto disto pode ser consideravelmente mitigado por bom design. Por exemplo, tanto no Attachmate cliente quando no seu servidor de screen-based access (N.E.: acesso baseado em telas), o código gerado pelo NavDesigner é baseado em um arquivo de navegação, que liga áreas da tela à dos objetos que elas representam. 

Em muitos casos, havendo mudanças, só este arquivo é alterado. Assim, o uso de programação orientada a objeto acaba por redistribuir o impacto das mudanças para um subsistema menor, restringindo o impacto  das mudanças para a aplicação.

(*) Roberto Rebouças é gerente técnico para a América Latina da Attachmate Corporation.