Autor: Nelson Naoki Umeda Há tempos, alguns profetas de plantão diziam que o mainframe estava com os seus dias contados. Contrariando essas previsões, o que se viu, de alguns anos para cá, foi que mainframes continuaram sendo vendidos. Porém, com uma diferença: compra mainframe aquela empresa que precisa consolidar grande volume de informações espalhadas pela rede, como, por exemplo, tratamento de banco de dados corporativo. Trata-se de uma aplicação típica de mainframe, pois exige grande capacidade de armazenamento, processamento rápido de massas de dados e segurança. Mataram o Mainframe Com a proliferação das LANs, a IBM percebeu a tempo que, para manter uma infra-estrutura já instalada e um número de usuários nada desprezível, ela teria que promover a integração entre os ambientes SNA e as redes locais. Surgiram soluções que substituíram as controladoras e terminais, através de gateways SNA nos servidores de suas LANs e, assim, este tipo de solução permitiu que redes locais se conectassem aos sistemas corporativos sem que houvesse alteração no protocolo de toda a rede e nas aplicações. Existe uma corrente no mercado que defende a manutenção a longo prazo desse tipo de estrutura, alegando que isso preservaria a base de aplicativos, o que também é um entrave a mais na migração para a plataforma cliente/servidor. No caso do Estado do Paraná, este tipo de solução tem sido adotado em quase todas as LANs administradas pela Celepar. Há pouco tempo o que mais se ouvia na empresa era que o mainframe ia morrer ou que já estava morto. Que o downsizing ia acabar com ele, que era só ver o número de LANs que estavam sendo instaladas. Esqueceram-se, estes profetas, que cada ponto de rede era um potencial usuário de emulador de terminal 3270, o que aumentou, consideravelmente, o número de usuários conectados ao mainframe, a ponto de saturar o mesmo. Sim, estão matando o mainframe de overdose! Futuro do Mainframe Porém, não podemos esquecer do terceiro milênio. Os sistemas legados precisam ser reescritos e preparados para o ambiente cliente servidor. A “estratégia da IBM é integrar o mainframe dentro do ambiente cliente/servidor, obviamente tendo o mainframe como grande servidor e, assim, executando as tarefas em que ele é bom”. Assim também pensa a Microsoft que pretende forjar links de ida e volta entre aplicações baseadas no BackOffice baseado em NT, como SQL Server e SNA Server, com aplicações de transação para mainframe. Também através da parceria com a Software AG (fabricante do Adabas) estão trabalhando na ferramenta de desenvolvimento de aplicação visual da Microsoft e tecnologia OLE. No futuro essas ferramentas podem gerar objetos OLE em vez de apenas procedimentos SQL Server (Previsto para 1997). Mainframe na Internet E na área da Internet, têm surgido produtos que permitem transformar o mainframe em um site Internet, tal como web3270, que permite ao usuário, via Netscape, executar uma aplicação VTAM, Roscoe por exemplo, e o web390, que permitirá a construção de aplicações Internet acessando mainframe como se acessa qualquer ambiente ou banco de dados, previsto para o segundo semestre de 1996. Ambiente Mainframe de Banco de Dados O mainframe é capaz de desempenhar muito bem o papel de servidor de grandes bases de dados, ou pode ter sua estrutura usada para viabilizar uma política de backup para toda a rede. Também é uma plataforma bastante adequada para rodar aplicações de missão crítica, função esta que ele já vem desempenhando há algum tempo. E para que sistemas cliente/servidor de missão crítica sejam bem sucedidos, precisamos incluir componentes do ambiente mainframe tradicional. Isto inclui gerenciamento de sistemas sólidos, segurança, backup/recuperação e uma abordagem disciplinada e cuidadosa do desenvolvimento e uso. No mainframe da Celepar temos, como gerenciador de banco de dados, o Adabas da Software AG, que é comercializado no Brasil pela Consist, e sistemas corporativos de clientes como DETRAN (Depto Estadual de Trânsito), SEAD (Secretaria de Estado da Administração), SEED ( Secretaria de Estado da Educação), SEFA (Secretaria de Estado da Fazenda), etc., cujos dados pela sua própria natureza e importância devem continuar centralizados no mainframe. São bases com dimensões corporativas, com mais de 60 Gb, que podem ser compartilhados entre sistemas legados e novos sistemas desenvolvidos na arquitetura cliente/servidor. Desta forma, para os sistemas cliente/servidor devemos disponibilizar ferramentas que permitam às aplicações cliente acessarem os dados no servidor mainframe. Este tem sido um dos objetivos do Projeto Cliente/Servidor no qual estou envolvido, mais especificamente na avaliação de alternativas de gateway para banco de dados. Gateway para o Main-frame Para tal, executamos testes com produtos Gateway de 2 fornecedores:
Produtos da Sybase A SYBASE, fornecedora do banco de dados relacional SQL Server, também tem a preocupação no sentido de se comunicar com o mainframe. Para tal disponibiliza dois produtos:
DB-Gateway A Celepar adquiriu no ano passado, devido à limitação imposta pela versão do CICS que possuíamos em nossa instalação, o DB-Gateway (junto com o banco de dados relacional SQL_Server versão 10). O DB-Gateway permite a um usuário Sybase se conectar ao mainframe de duas formas: - executar “query” usando comandos SQL dinâmico; - executar uma espécie de Remote Procedure Call (RPC) para ativar um programa Natural. Em ambos os casos, o DB-Gateway, utilizando-se do protocolo LU6.2, comunica-se com o MDI Access Server no mainframe, que é uma transação CICS. Este, por sua vez, no primeiro caso chama o Infohub para converter os comandos SQL para comandos Adabas e executá-los e, no segundo caso, inicia a execução do RPC que ativará o programa Natural desejado. Resumidamente, a primeira forma de comunicação é indicada para sistemas de suporte à decisão e a segunda é voltada para aplicações transacionais. A segunda forma, execução de RPC, está sendo utilizada no projeto DETRAN na construção das transações que necessitam acesso rápido ao mainframe. Em relação ao Net-Gateway, perde em termos de funcionalidade, ferramentas de administração e monitoração, além de utilizar um protocolo de rede proprietário que é o SNA. O esquema e o fluxo de comunicação entre os ambientes seria: 1) A aplicação cliente inicia um pedido (ex.: execução de um programa Natural). 2) O pedido é enviado via rede para o servidor Database Gateway que aloca uma conversação APPC com o CICS para processar o pedido e chama o MDI Access Server. 3) O MDI Access Server chama o núcleo Natural e executa o programa natural e se for um comando SQL, passa o controle para o InfoHub Server. 4) Os dados fluem de volta no mesmo caminho da execução do pedido.
MAP (Mainframe Access Products) O Net-Gateway da SYBASE é um produto mais moderno. Executa as mesmas funções do DB-Gateway porém se utiliza do protocolo TCP/IP para se comunicar com o mainframe/CICS. O Net-Gateway é um produto MAP. MAP (Mainframe Access Pro-ducts) é um conjunto de produtos que permite a usuários de desktop e workstations, comunicarem-se com o Mainframe em um ambiente Cliente/Servidor. Os dados no Adabas serão acessados por programas Natural que por sua vez serão "startados" via RPC (Remote Procedure Call), solicitado pelas estações clientes.
Componentes: - Open Server/Mainframe Open Server/Mainframe Open Server Mainframe e Net-Gateway são produtos da SYBASE que permitem que programas clientes, em plataformas remotas, acessem recursos no Mainframe (na forma de Remote Procedure Call - RPCs). A comunicação entre Open Server/Mainframe e Net-Gateway pode ser efetivada utilizando-se dos protocolos SNA LU6.2 ou TCP/IP. Net-Gateway É um produto SYBASE que permite a workstations comunicarem-se com Mainframe IBM atuando tanto como servidores como clientes. Na Celepar irá executar em ambiente UNIX, nas máquinas RISC. Consiste de dois programas: - Mainframe Server Gateway (MSG) - Usado quando o mainframe atua como Server para um cliente SYBASE. O MSG está disponível para os protocolos LU6.2 e TCP/IP, e roda no ambiente UNIX; - Mainframe Client Gateway (MCG) - Usado quando o mainframe atua como cliente do Servidor SYBASE. O MCG está disponível apenas para o protocolo LU6.2. e roda no ambiente UNIX. Omni SQL Access Modu-le for DB2 (DB2 Access Module) Permite que usuários remotos emitam comandos SQL para o Banco de Dados DB2 da IBM para processamento dinâmico. Na Celepar pode ser utilizado para acessar banco de dados Adabas via Infohub. Exemplo de uma Aplicação Cliente Comunicando com o Open Server/Mainframe: O MSG aparece para cliente como um servidor, mapeando cada pedido para o Mainframe e a transação associada. Uma transação do tipo “long-running” também é possível. Neste caso, uma transação Open Server/Mainframe pode receber um novo conjunto de parâmetros de entrada depois do conjunto de resultados anterior ter retornado ao cliente. Ou seja, tão logo ele conclua as tarefas pertinentes a uma requisição, ele fica esperando por uma nova requisição. Isto permite manter o núcleo Natural ativo entre as chamadas RPC, evitando o overhead de start do núcleo Natural. Fluxo da execução: 1) Estação Windows - Aplicação Cliente pede execução de uma RPC. ( via exec) 2) RISC 6000 - Via rede, LAN ou WAN, o pedido de execução chega no Net-Gateway. Este valida o login e passa a solicitação para o Open Server/Mainframe, através da controladora 3172 ligada a canal com o mainframe, utilizando o protocolo TCP/IP. 3) Mainframe IBM - A solicitação chega no CICS, via TCP/IP no mainframe. O CICS "starta" a transação Open Server que por sua vez irá chamar o núcleo do Natural para executar um programa Natural. - O programa Natural executa o acesso ao Adabas, recupera os dados e devolve a aplicação cliente, executando o caminho inverso. - Se a transação for do tipo long-running, o núcleo do Natural não é liberado, e fica aguardando uma nova requisição, evitando com isto o overhead do novo start do Núcleo Natural, conforme dito anteriormente. Uma rede SYBASE pode também conectar múltiplos clientes e múltiplos Servers, rodando em uma ou mais regiões CICS em um ou mais Mainframes. O esquema de comunicação entre os diversos ambientes pode ser visualizado na figura a seguir:
Produtos da Software AG
ENTIRE BROKER SDK - Envia
chamada remota em dois modos: ENTIRE NET-WORK 1)CONNECTIONLESS (Sem conexão) - Nenhum conceito de uma sessão entre o cliente e o servidor. - Mensagens são simplesmente enviadas e recebidas sem relacionamento entre qualquer outra mensagem. - A informação sobre a localização do servidor deve ser passada como parâmetro a cada vez que o servidor é chamado. 2)CONNECTION ORIENTED - Na comunicação orientada a conexão os dois parceiros da comunicação mantêm um relacionamento entre várias chamadas. - Requer que a sessão seja estabelecida com uma chamada connect e encerrada com uma chamada disconnect. - Cada conexão no servidor deve ser encerrada por uma desconexão correspondente, para garantir que todos os recursos sejam liberados corretamente. - A informação da localização do servidor é passada como parâmetro na chamada connect. Esta chamada retorna a identificação da sessão ou conexão. - Enquanto a conexão está estabelecida, os dois parceiros podem executar várias chamadas e usar a identificação da conexão como parâmetro para cada chamada. Por exemplo: um procedimento cliente pode enviar a um servidor de segurança um User_Id em uma chamada e a Password em uma segunda chamada. Usando a identificação da conexão, o servidor de segurança conhece para qual User_Id a Password enviada na segunda chamada se refere.
Entire Net-Work É o backbone da tecnologia de processamento distribuído da Software AG. É o “middleware” que provê serviço de comunicação comum e transparente para aplicações de banco de dados corporativos. Suporta os protocolos de rede TCP/IP, LU6.2, SPX, NETBIOS e DECnet. O programador da aplicação cliente, pode se comunicar com o Entire Broker SDK via uma API. Existem vários passos que o programador deve seguir para executar uma RPC. Primeiro, a aplicação cliente deve register (registrar) a si mesmo para o Entire Broker SDK run_time System e no final, quando não mais precisar emitir um RPC (usualmente antes de terminar), ele deve emitir um unregister. Uma vez a aplicação esteja registrada com sucesso, ele pode emitir uma chamada connectionless diretamente para qualquer número de servidores ou ele pode estabelecer sessões e emitir chamadas connection oriented. Exemplo: Fluxo lógico de uma aplicação comunicando-se com dois servidores. => register
to_run_time O Entire Broker SDK pode ser executado em dois ambientes: WINDOWS e UNIX. No ambiente UNIX, podemos construir uma interface de acesso a subprogramas Natural no Mainframe de tal maneira que se possibilite o acesso a partir das estações Windows sem que precisemos adquirir a cópia do ENTIRE NET-WORK for WINDOWS, que é o software de Middleware da Software AG. No lugar deste produto, podemos usar um software shareware obtido na Internet (tal como IPPORT.VBX) para executar esta função do Middleware. Esta solução tem as seguintes vantagens: 1) Dispensar a compra do ENTIRE NET-WORK nas estações WINDOWS. 2) Segurança (no Mainframe enxerga-se apenas uma conexão, com o UNIX, e os usuários se conectariam com o Servidor Natural no UNIX e não no Mainframe). 3) Integridade dos Bancos de Dados no Mainframe. Em ambientes corporativos temos a responsabilidade de manter as Bases Corporativas íntegras, portanto, o fato de termos algum tipo de sistema que não seja tão aberto é interessante. Os usuários somente podem executar os módulos pré-determinados. Teremos uma camada de interface que é conhecida somente por nós. Para utilizarmos o Entire Broker via UNIX, podemos nos basear em alguns conceitos da programação JAVA, que é baseada em applets (pequenos programas embutidos em documentos HTML). Umas poucas palavras sobre applets para melhor compreendermos a idéia: - Funcionamento: Quando o usuário web clicar em um determinado ponto da página, um applet será transferido de um servidor para a estação cliente e o programa entrará em execução. - Principais Componentes: Compilador JAVA, que compila um código fonte JAVA em uma linguagem intermediária, independente de máquina, denominada “architecture-neural byte codes”; o interpretador JAVA, que interpreta e executa os programas JAVA nas estações de trabalho; e utilitários como um disassembler, um gerador de documentos HTML, uma ferramenta de medição de performance. - Ambiente: Baseado em linguagem C++, aproveita a grande base de expertise de programadores nesta linguagem e no C. É uma linguagem orientada a objeto e este conceito deve ser bem explorado para se obter vantagens do conceito de applets. Assim, quando falamos em programação Broker SDK, no lugar dos applets temos os "stubs", que executam chamadas a subprogramas Natural, que por sua vez são embutidos em pequenas funções C. A diferença é que não será executado no cliente, mas sim no servidor, ativado por uma chamada da estação Cliente via IPPORT. Para cada subprograma Natural é criado um conjunto stub/função, modular, que executa um determinado objeto. Os principais componentes também são um compilador (que compila e gera os "stubs"); um servidor de EXECUÇÃO é uma espécie de interpretador run-time do Broker SDK que irá rotear, via Net-Work, a execução dos objetos. Assim como o JAVA, todo o processo do Broker SDK é baseado em C, e as chamadas a este objeto podem ser executadas das estações cliente via qualquer linguagem de programação de Quarta Geração tipo VB Script, SQL-WINDOWS, DELPHI, etc. (que podem chamar .VBX). Para utilizarmos o Entire Broker em uma aplicação Windows, devemos codificar a aplicação (conforme o fluxo mostrado acima) no formato de uma DLL, de tal forma que possamos declarar em qualquer linguagem de programação de 4a. Geração. Para criarmos a DLL basta criar um arquivo texto com o mapeamento dos dados (arquivo .idl) e através do pré-compilador gerar os stubs que executarão as chamadas aos subprogramas Natural. Aplicações de missão crítica em cliente/servidor exigem um nível de serviço à altura das expectativas dos usuários e da importância da aplicação para o negócio. ( Por exemplo: no projeto DETRAN o tempo de resposta tem que ser no mínimo igual ao da aplicação hoje existente). Neste contexto, a gerência de performance tem um papel extremamente importante. E por ser o ambiente mainframe já conhecido, com ferramentas de medições já dominadas que podem identificar precisamente onde está o problema de performance, fica mais fácil a tarefa de gerenciar o ambiente da aplicação em termos de performance. O mainframe com ferramentas diversas de administração, banco de dados robusto, grande capacidade de armazenamento e recuperação de dados, memória etc., é o ideal para atuar como servidor de dados das aplicações de missão crítica.
|
