Glenn Johnson – Senior Vice President – Magic Software Americas.
A integração com mainframe normalmente se refere à necessidade de compartilhar informações em tempo real ou em lotes entre uma aplicação de software rodando em um mainframe e outros ambientes de computação, tais como sistemas cliente servidor distribuídos ou sistemas de médio porte.
O interesse na realização da integração de mainframe com JD Edwards, SAP, Salesforce.com, Microsoft SharePoint, Lotus Notes e outros softwares baseados em servidores ou soluções de Software-as-a-Service continua em alta demanda. Iniciar um projeto de integração de mainframe requer uma avaliação cuidadosa das opções de integração disponíveis. Para a maioria das organizações de TI que rodam aplicativos de mainframe, será desejável manter grande parte da atual lógica de negócios e poder de processamento do mainframe tanto quanto possível. No entanto, na maioria dos cenários, a integração de SaaS e ambientes de não-mainframe requer um servidor de integração que fica fora do mainframe, bem como um padrão de integração disponível no mainframe.
Uma série de padrões de integração de mainframe estão disponíveis para ajudá-lo a alcançar a integração de aplicativos empresariais.
Os desafios a serem considerados na integração de mainframe incluem diferenças fundamentais entre os sistemas, tais como EBCDIC versus codificação de caracteres de texto ASCII. Encontrar informações de metadados sobre estruturas de arquivos também é fundamentalmente diferente entre mainframes e outros sistemas. No mainframe, a maioria da programação é realizada em COBOL e os dados estão definidos e contidos no COBOL Copybook. Muitas vezes, o Copybook é a única fonte de metadados também. Além disso, deve-se considerar 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 projetado para lidar com dados síncronos em tempo real, semi-síncronos, quase em tempo real e em ambientes assíncronos de lote. O processamento de eventos nem sempre é fácil e exige uma análise cuidadosa quando o objetivo é atingir uma arquitetura orientada a eventos ou, pelo menos processos orientado a eventos ou triggers.
Padrões de Integração Mainframe que podem ser usados com o iBOLT.
Adaptadores de banco de dados de mainframe. Um adaptador de banco de dados se conecta diretamente ao banco de dados de mainframe e procura por alterações no banco de dados ou responde aos gatilhos do banco de dados. Esses adaptadores podem, normalmente, ler, gravar, apagar e atualizar os dados no banco de dados de mainframe, bem como fornecer os dados do mainframe via certos protocolos. Adaptadores de banco de dados são muito poderosos e são soluções de baixo nível, mas têm a desvantagem bastante significativa de exigir do arquiteto de integração um ter amplo conhecimento das estruturas de banco de dados utilizadas e dos processos da aplicação. Enquanto a leitura de um banco de dados é menos problemática, a gravação direta em um banco é problemática e pode até mesmo anular a obrigatoriedade de suporte do fornecedor do software em questão.
Adaptadores Mainframe ODBC. Outra abordagem é a utilização de driver ODBC, como parte do servidor SNA ou um dos muitos disponíveis a partir de fornecedores de software de terceiros. O driver ODBC tem a vantagem de ser mais amplamente acessado por software de terceiros, mas no final tem as mesmas limitações fundamentais ou riscos associados aos adaptadores de banco de dados ou acesso direto.
FTP. File Transfer Protocol (FTP) utiliza o TCP / IP e fornece uma maneira de transmitir arquivos entre diversos sistemas, incluindo mainframes, sistemas Linux, sistemas IBM i, servidores UNIX e Windows. Em mainframes IBM, o sistema operacional z/OS inclui recursos para obter e colocar comandos para transferir arquivos. No entanto, sérias limitações existem para uma integração baseada em FTP: 1) A quantidade de análise necessária para chegar à informação relevante é geralmente extensa. 2) os riscos de segurança não são triviais e exigem atenção cuidadosa. 3) O FTP é ineficaz nos recursos, exigindo uma conexão de dados separada para cada arquivo transferido. 4) A análise dos diretórios FTP também é complexa. 5) Para os requisitos de integração de grande volume, gerenciar todos os arquivos FTP pode se tornar problemático.
APIs proprietárias. APIs proprietárias podem parecer atraentes à primeira vista com base na especificidade da sua integração para uma aplicação específica. Isso também pode ser um ponto fraco, porém, pois muito pode ser investido em termos de licenciamento e de trabalho para fazer estas APIs funcionarem e elas têm essencialmente um único propósito. Se, mais tarde, você descobrir que precisa de outro ponto de integração, você estará novamente a procurar o padrão de integração adequado. Uma abordagem melhor parece envolver uma solução de integração genérica tanto no lado do mainframe quanto no lado não-mainframe do cenário de integração.
Emulação 3270. Outra opção para integração com mainframes é a emulação 3270. Adaptadores disponíveis irão publicar um Web service seguro que permite a comunicação bi-direcional com sistemas de mainframe e aplicações através da interface de usuário conhecida como 3270. As vantagens desta abordagem são a quantidade relativamente pequena de trabalho de integração necessária do lado do mainframe. Um usuário experiente pode gastar algumas horas treinando o emulador para encontrar o fluxo de trabalho adequado para mostrar os dados ou realizar as transações e outros I/O necessários. No entanto, as possibilidades de integração estarão limitadas às fornecidas pelo aplicativo ao usuário. Se houver a necessidade de sair dessas limitações, então esse pode não ser o melhor padrão de integração. Além disso, o risco de concepção de integração inadequada deve ser cuidadosamente considerado. Mesmo usuários experientes podem ser completamente inconscientes das ramificações de uma interação particular.
Filas de Mensagens (MQ). Com JMS ou WebSphere MQ no mainframe, pode ser observado um protocolo de mensagens que inclui capacidades de troca de mensagens e melhora muito o sistema de integração. Em muitos aspectos, a mensageria é a melhor porta de entrada para a integração. Mas não deve ser confundida como solução total, pois mesmo com MQ, você só tem parte da solução. E, nem todos os sistemas estão equipados para lidar com MQ. Por esta razão, outros protocolos como o CICS podem ser preferíveis, não só por sua presença relativamente maior, mas também por causa da forte base de conhecimento da comunidade de TI de mainframe sobre o seu uso.
CICS. Customer Information Control System (CICS) é um servidor de transações de mainframe projetado principalmente para rápida interatividade, alto volume de processamento on-line e que pode também executar processos em background. Com um adaptador CICS, um mecanismo de integração como o iBOLT Integration Suite pode ser utilizado para aparecer como um outro servidor CICS para um sistema mainframe. O suporte CICS para operação multi-região (MRO) fornece um ponto de entrada simples e seguro para o ambiente de aplicativos de mainframe sem a necessidade de uma extensa programação. Algumas soluções de integração CICS utilizam Web Services para interface CICS no mainframe para o mundo exterior. Um padrão ideal utiliza o adaptador para se conectar a um broker de integração, eliminando assim a necessidade de desenvolvimento de interfaces múltiplas e simplificar a integração dos sistemas não-mainframe.
Para gerenciar a integração nos sistemas não-mainframe, o iBOLT Integration Suite está disponível e inclui um editor de topologia, editor de processos de negócios, editor de fluxo, e um monitor. Mais informações sobre o iBOLT Integration Suite estão disponíveis com a Magic Software Enterprises.