Glenn Johnson – Senior Vice President – Magic Software Americas – http://unipaas.blogspot.com
Uma integração mainframe geralmente se refere à necessidade de compartilhar informações em tempo real ou batch entre uma aplicação de software que roda em um mainframe e outros ambientes de computação, como sistemas cliente/servidor distribuídos ou sistemas midrange.
O interesse em realizar a integração mainframe com JD Edwards, SAP, Salesforce.com, Microsoft SharePoint, Lotus Notes e outros softwares C/S e Web ou soluções Software-as-a-Service (SaaS) continua em alta demanda.
Embarcar em um projeto de integração mainframe requer uma cuidadosa avaliação das opções de integração disponíveis. Para a maioria das organizações de TI que rodam aplicações mainframe, é desejável manter a lógica de negócios atual e o poder de processamento do mainframe tanto quanto possível. No entanto, na maioria dos cenários, a integração para SaaS e ambientes não-mainframe requer um servidor de integração que fique fora do mainframe, bem como um padrão de integração disponível no mainframe.
Uma série de padrões de integração mainframe está disponível para ajudá-lo a conseguir a integração de aplicações em toda a empresa.
Os desafios a serem considerados na integração mainframe incluem diferenças fundamentais entre os sistemas, tais como padrões texto EBCDIC versus ASCII.
Encontrar informações metadados sobre as estruturas do arquivo também é fundamentalmente diferente entre mainframe e outros sistemas. No mainframe, a maioria da programação é realizada em COBOL e os dados são definidos e contidos internamente no COBOL-Copybook. Freqüentemente, o copybook é a única fonte de metadados também. Além disso, deve ser levado em consideração se o processamento no mainframe ocorre em processos online, processos batch ou alguma combinação. A questão não é se você pode integrar, mas como o processo de negócio deve ser desenhado para lidar com dados síncronos em tempo real, semi-síncronos em tempo quase real e assíncronos em ambientes batch. O processamento de eventos nem sempre é fácil e exige uma análise cuidadosa quando o objetivo é atingir uma arquitetura dirigida a eventos ou, pelo menos, processos dirigidos a eventos ou triggers.
Padrões de Integração Mainframe que podem ser utilizados com iBOLT.
Adaptadores de banco de dados mainframe. Um adaptador de banco de dados conecta-se diretamente ao banco de dados mainframe e procura mudanças na base de dados ou responde às triggers do banco de dados. Esses adaptadores podem normalmente ler, escrever, apagar e atualizar os dados na base de dados do mainframe, assim como fornecer os dados do mainframe através de certos protocolos.
Adaptadores de banco de dados são soluções muito poderosas e de “low-level”, mas têm a desvantagem de exigir que o arquiteto de integração tenha profundo conhecimento das estruturas de dados utilizadas e os processos da aplicação.
Enquanto a leitura de um banco de dados é menos problemática, gravar diretamente em um banco de dados é problemático e poderia mesmo anular as obrigações de suporte do fornecedor da solução.
Adaptadores mainframe ODBC.Outra abordagem é o uso de um driver ODBC, tais como um nativo para o servidor SNA ou um dos diversos disponíveis a partir de fornecedores de softwares de terceiros. O driver ODBC tem a vantagem de ser mais amplamente acessível por software de terceiros, mas no final tem as mesmas limitações fundamentais ou riscos associados com adaptadores de base de dados ou acesso direto.
FTP. File Transfer Protocol (FTP) utiliza o TCP / IP e fornece uma maneira de transmitir arquivos entre os diversos sistemas, incluindo mainframes, sistemas Linux, IBM i, sistemas UNIX e servidores Windows. Em mainframes IBM, o sistema operacional z/OS inclui capacidades tanto para pegar e colocar comandos para transferir arquivos. Existem sérias limitações para a integração baseada em FTP, no entanto: 1) A quantidade de análise necessária para a obtenção de dados relevantes é normalmente extensa. 2) Riscos de segurança não são superficiais e requerem atenção meticulosa. 3) FTP é ineficiente dos recursos por exigir uma conexão de dados separada para cada arquivo transferido. 4) Análise de diretórios FTP também é complexa. 5) Pelo alto volume de requisitos integração, a gestão de todos os arquivos FTP pode se tornar problemática.
APIs proprietárias. APIs proprietárias podem, a princípio, parecer atraentes baseada na especificidade da sua integração para uma aplicação específica. Isso também pode ser um ponto fraco, porém, devido ao alto investimento em icenciamento e trabalho para fazer estas APIs funcionarem e por elas terem essencialmente uma única finalidade. Se mais tarde você descobrir que precisa de um outro ponto de integração, você está de volta ao ponto inicial para pesquisar o padrão de integração correto. Uma abordagem melhor parece implicar em uma solução generalizada de integração em ambos os lados do mainframe e o lado não-mainframe do cenário de integração.
Emulação 3270. Outra opção para integração mainframe é a emulação 3270. Adaptadores disponíveis irão publicar um Webservice seguro que permite a comunicação bidirecional com sistemas e aplicações mainframe via interface do usuário stream conhecido como 3270. As vantagens desta abordagem são a quantidade relativamente pequena de trabalho de integração necessário para o lado mainframe. Um usuário experiente pode em poucas horas ser treinado no emulador para encontrar o fluxo correto para revelar os dados ou conduzir às transações e outros I/O necessários. Todavia, as possibilidades de integração serão limitadas aos fornecidos pela aplicação para o usuário. Se há uma necessidade de ir além destes limites, então este pode não ser o melhor padrão de integração. Além disso, o risco de uma concepção inadequada de integração deve ser cuidadosamente considerado. Até mesmo usuários experientes podem desconhecer completamente as ramificações de uma interação particular.
Messaging Queues (MQ). Com JMS ou WebSphere MQ no mainframe, um protocolo de mensagens que pode ser observado e inclui capacidades de transferir mensagens e aumenta significativametne a capacidade de integração do sistema. Em muitos aspectos, messaging é a melhor porta para integração. Mas não deve ser confundida com a solução total, mesmo com MQ, você tem apenas parte da solução. E, nem todos os sistemas são preparados para lidar com MQ. Por esta razão, outros protocolos como o CICS podem ser preferíveis não apenas por sua maior presença, mas também devido à forte base de conhecimento em mainframe da comunidade de TI que o utiliza.
CICS. Sistema de Controle de Informações do Cliente (CICS) é um server de transações mainframe concebido principalmente para uma interação rápida, alto volume de processamento online e pode também realizar processos background. Com um adaptador CICS, um motor de integração como o iBOLT Integration Suite pode ser criado para aparecer como outro servidor CICS para um sistema mainframe. O suporte CICS para a operação multi-região (MRO), prevê um simples e seguro ponto de entrada para o ambiente da aplicação mainframe sem a necessidade de muito esforço de programação. Algumas soluções de integração CICS utilizam a interface Weservices CICS no mainframe para o mundo exterior. Um padrão ideal CICS utiliza o adaptador para conectar a um broker de integração, eliminando assim a necessidade de desenvolvimento de múltiplas interfaces e simplificando a integração com os sistemas fora do mainframe.
Para gerenciar a integração em sistemas fora do mainframe, o iBOLT Integration Suite está disponível e inclui editor de topologia, editor de processos de negócios, editor de fluxos, e monitor. Mais informações no iBOLT Integration Suite está disponível no site da Magic Software.