Desenvolvimento - Sistemas
O EAI como abordagem de integração de sistemas corporativos para a obtenção de vantagem competitiva
Com o objetivo de conter custos durante as mudanças de negócios, as indústrias de tecnologia freqüentemente necessitam integrar suas aplicações com sistemas legados sob diferentes plataformas. Esta necessidade tem criado um mercado conhecido atualmente como Mercado de Integração de Aplicações.
por Leonardo Grandinetti ChavesO termo EAI ou Enterprise Application Integration é novo mas sugere toda essa integração. É ainda, o termo formal que contempla a integração de aplicações corporativas e um conjunto de ferramentas e tecnologias. Como a dependência das corporações em relação à tecnologia têm crescido e se tornado mais complexa, a necessidade por um método de integração de aplicações em um único arsenal de processos de negócios tem sido a prioridade. Depois da criação de ilhas de negócio, usuários e dirigentes de grandes corporações têm demandado uma ponte que possa unir os diversos sistemas espalhados pelos departamentos das empresas. Eles estão demandando a unificação das aplicações. O crescimento do EAI , ou Enterprise Application Integration, permite o compartilhamento de processos e dados e vem atender a esta demanda.
O termo EAI ou Enterprise Application Integration é novo mas sugere toda essa integração. É ainda, o termo formal que contempla a integração de aplicações corporativas e um conjunto de ferramentas e tecnologias. Como a dependência das corporações em relação à tecnologia têm crescido e se tornado mais complexa, a necessidade por um método de integração de aplicações em um único arsenal de processos de negócios tem sido a prioridade. Depois da criação de ilhas de negócio, usuários e dirigentes de grandes corporações têm demandado uma ponte que possa unir os diversos sistemas espalhados pelos departamentos das empresas. Eles estão demandando a unificação das aplicações. O crescimento do EAI , ou Enterprise Application Integration, permite o compartilhamento de processos e dados e vem atender a esta demanda.
A integração de aplicações permite o compartilhamento de informações dentro da mesma organização ou com parceiros. Isto gera vantagem competitiva. A maior parte das organizações utilizam vários tipos e “gerações” de sistemas desenvolvidos ao longo dos anos. Mainframes, servidores Unix, servidores NT e outros constituem a base tecnológica para a maioria das corporações. Estes sistemas possuem valor nas empresas mas o seu valor agregado pode significar pouco se estes não puderem “conversar” com outros sistemas. A necessidade de integração destes sistemas têm se intensificado com a popularidade de pacotes tais como SAP, Peoplesoft ou Baan.
A demanda inicial das empresas é compartilhar os dados e processos sem precisar fazer grandes mudanças nas aplicações ou nas estruturas de dados. Apenas, procura-se com EAI, um método de acoplar os sistemas. Esta integração pode ser tanto funcional quanto viável economicamente, trazendo lucros e vantagem competitiva para as corporações.
Faz-se necessário entender que o EAI e as soluções de middleware tradicional não possuem o mesmo significado. Onde o middleware tradicional facilita a integração de aplicações individuais e "discretas" transações entre elas, o EAI possibilita à corporação gerenciar a relação entre múltiplas transações que constituem o processo de negócio.
O middleware tradicional resolve o problema de forma limitada. A primeira limitação do middleware é que utiliza as técnicas de filas de mensagens ou chamadas remotas de procedimentos apenas providas para soluções ponto-a-ponto. Qualquer ligação adicional torna-se um emaranhado de ligações complexas de middleware com outros sistemas. Middlewares tradicionais exigem alterações significativas nos sistemas origem e destino exigindo a agregação da camada de middleware na aplicação ou no depósito de dados. Por exemplo, na integração de um sistema de contabilidade sob o ambiente do Windows 2000 com um sistema de patrimônio que funciona no mainframe, deve-se selecionar o produto de middleware de filas de mensagens que permita aos sistemas compartilhar informação. Para fazer isso, você provavelmente será forçado a alterar o sistema fonte (origem dos dados) e o sistema destino(destino dos dados) para fazer uso do middleware. Isto deve ser feito porque a camada de middleware provê apenas uma interface , uma ligação e os programas devem ser alterados para acomodar o middleware. Isto demanda alto custo e pode ter alto risco.
Um outro exemplo para uma ligação deste tipo são as aplicações ligadas pelo middleware orientado por mensagens (ou MOM , que significa message-oriented middleware). Se você faz a interligação da aplicação A com a aplicação B, qualquer ligação adicional faz crescer a complexidade do gerenciamento de mensagens entre os processos e pode implicar na alteração dos fontes das aplicações. Podemos citar o produto IBM Mqseries , por exemplo.
Novas tecnologias estão sendo desenvolvidas enquanto o Message Brokers, ou corretores de mensagens, oferecem o serviço de entrega de mensagens. Assim , o middleware ponto-a-ponto enquanto agrega valor para a corporação não estabelece uma solução definitiva.
As organizações devem compreender tanto os processos de negócios quanto os dados. Devem selecionar quais processos e dados requerem integração. Este processo pode ser visto por várias dimensões, incluindo:
Nível dos dados;
Nível de interface das aplicações;
Nível dos métodos;
Nível de interface do usuário
O Nível dos dados de EAI é o processo, as técnicas e tecnologias que permitem mover ,transportar dados entre diferentes fontes e destinos e eventualmente tratar os dados fazendo as atualizações necessárias mantendo-se a integridade( replicação, por exemplo). Isto inclui a transformação e aplicação lógica dos dados de negócio que podem ser extraídos ou lidos (através de triggers, stored procedures, etc). Esta tecnologia que permite mover a informação entre diferentes bancos de dados possui um custo relativamente baixo comparada com as demais técnicas de EAI que demandam codificação de aplicações.
O Nível de interface de aplicação refere-se à utilização das interfaces das aplicações e dos pacotes de sistemas. Utilizando-se das interfaces, os desenvolvedores podem empacotar muitas aplicações permitindo o compartilhamento lógico e de informação. As únicas limitações resumem-se às características técnicas e funções destas interfaces. Exemplos deste tipo de EAI podem ser aplicados aos pacotes de aplicações tais como SAP, Peoplesoft e Baan. Para integrarmos os sistemas pela empresa , precisamos utilizar estas interfaces para acessarmos tanto os dados quanto os processos, extraindo informação, substituindo , colocando no formato adequado para a aplicação destino e transmitindo. Diversas tecnologias podem fazer isto. Podemos exemplificar com os Message Brokers explicados anteriormente.
O Nível dos métodos de EAI é o compartilhamento de lógica de negócios. Por exemplo, o método de atualização do registro de um consumidor pode ser acessado à partir de um enorme número de aplicações e as aplicações podem se utilizar de outros métodos sem precisarmos reescrever um método em cada aplicação. O mecanismo de compartilhamento de métodos pelas aplicações incluem objetos distribuídos, servidores de aplicação, monitores de transação ou uma aplicação única que combina a ação de outras duas.
Com o EAI, podemos tratar a demanda de integração de todos os métodos e arquiteturas acima citados.
No Nível de interface de usuário, os desenvolvedores possibilitam um ponto comum de integração para os usuários. Embora, esta pareça a forma mais primitiva, não é a menos necessária. A interface gráfica para o usuário, o ambiente visual é o melhor exemplo para este tipo de EAI. Aplicações que funcionam no ambiente de mainframe podem ser exibidas de forma visual ao usuário.
O middleware tradicional que inclue monitores de transação, servidores de aplicação propiciam benefícios nos sistemas distribuídos e no EAI que não são vistos nas ferramentas tradicionais de desenvolvimento. Escalabilidade, tolerância à falha e uma arquitetura que termina por centralizar o processamento das aplicações são características notórias do middleware tradicional.
Os servidores de transação permitem a centralização do processamento da informação à partir de muitas fontes, tais como bancos de dados e aplicações. Ainda, asseguram a entrega de informação de uma aplicação para outra e suportam uma arquitetura distribuída. Contudo, os custos de implementação de servidores de aplicação podem inviabilizar sua utilização na EAI. Os servidores de aplicação são métodos evasivos porque exigem alterações nas aplicações.
Os servidores de aplicação resumem-se a APIs dentro da aplicação. Os desenvolvedores podem incluir toda sorte de camada de middleware. Apesar dos servidores de aplicação serem classificados como middleware, eles são muito mais que do que uma camada de conexão de middleware. Alocam uma posição para o código da aplicação funcionar e como resultado uma posição para processamento do negócio e para os objetos. Alocam também uma posição onde os métodos podem ser compartilhados entre as aplicações. Os servidores de aplicação podem ser usados para garantir as regras de negócio e manter a integridade dos dados ou criar aplicações inteiras construindo muitos serviços de transações sendo invocados do lado cliente. Servidores de aplicação não fornecem apenas o serviço de alocação para lógica de aplicação , mas coordenam serviços e recursos WEB.
Os servidores de aplicação têm sido muito usados possibilitando a utilização e aproveitamento dos objetos distribuídos (os OTMs , ou Object Transaction Monitor são popularmente conhecidos como servidores de aplicação). Novas demandas resultaram em evoluções dos produtos agregando cada vez mais tecnologia. Podemos citar os seguintes produtos: Netscape Application Server (parte do iPlanet da Sun ), Weblogic, Microsoft Transaction Server (parte integrante do AppCenter) e o NetDynamics.
Os padrões mais utilizados são o Java dentro da iniciativa Enterprise JavaBeans (fechado no Corba) e o Activex. A tendência de modelos de arquitetura é combinar tanto o Java quanto o Corba resultando um modelo para objetos distribuídos como o J2EE (Java 2 Enterprise Edition) embora os modelos mais populares atualmente sejam Corba e COM++.
Os objetos distribuídos podem atuar no Nível dos Métodos do EAI dependendo do domínio do problema. Existem porém ,alguns problemas na utilização de objetos distribuídos em aplicações de missão crítica (load-balancing, concurrency control; por exemplo) . Isso significa pouca escalabilidade embora possibilitem múltiplas camadas dentro do contexto do EAI. Para tentar resolver este problema, os monitores de transação e os application servers são a melhor escolha mas possuem um risco e custo e ser considerado.
A componentização deve merecer especial atenção nos serviços que devem ser oferecidos pela WEB no contexto do EAI. Podemos desenvolver alguma aplicação utilizando o padrão EJB ou COM, encapsular aplicações CICS ou Cobol em componentes de negócio. Não devemos nos esquecer de modelar as classes que traduzem o ambiente de negócios . Em tempo, os componentes são apenas a implementação destas classes. O problema da componentização é combinar os recursos necessários para a sua implementação à partir de um único provedor de soluções (exceções à IBM e Microsoft).
O EAI não é homogêneo e oferece uma gama de opções e ferramentas. Além disso, por ser uma solução complexa, os produtos não fornecem uma solução acabada. Podemos listar os seguintes participantes do mercado de EAI levando-se em conta que cada um pertence à um nível ou a diversos níveis do EAI: Active Software, Arkona Software, BEA Systems, Bluestone Software, Constellar Software, Crosswords Software, Extricity Software, Frontec, IBM, Microsoft Corporation, NEON, Oberon Software, Progress Software, SmartDB, TIBCO, TSI Software, Vitria, Sybase, Intellicorp, Saga Systems, Alier, Cycle Software, Extricity Software, Mint Technologies, Muscato Corp, OpenConnect Systems, Viewlocity, Visual Edge Software.
Um tipo de ferramenta tem o seu foco sobre o compartilhamento de fontes de dados. Produtos das empresas Agent Software(Cupertino,CA), DataMirror Corp. (Markham, ON), Oberon Software(Cambridge, MA), e SmartDB Corp(Palo Alto, CA) extraem e transformam dados que podem ser intercambiáveis entre os pacotes de ERP e outras aplicações.
Um segundo tipo de ferramenta de EAI confia nos recursos de entrega de mensagens para suportar compartilhamento direto de dados entre programas sem a necessidade de usar um arquivo ou um banco de dados intermediário. As empresas que fornecem este tipo de recurso são a Neon(New Era of Networks, Englewood, CO), Active Software(Santa Clara, CA), Viewlocity(Atlanta,GA), e a Vitria Technology que permitem serviços de quebra de mensagens para distribuir as aplicações em utilização pela rede das corporações.
O crescimento do XML pode ser o precursor de uma nova classe de ferramentas de programação. Enquanto, a integração de ERP é solucionada para resolver problemas específicos, novos recursos de desenvolvimento estão prometendo estender além deste nível. Provedores estão redefinindo o mercado de integração que inclue não somente o intercâmbio de dados feito ponto-a-ponto, mas algo como a ligação das mais diversas fontes de dados, modelos de objetos e arquiteturas incluindo aí neste caso a Internet.
A necessidade de maior integração é uma demanda de origem econômica. Quantos milhares de dólares uma empresa de telefonia pode economizar ao integrar seus sistemas financeiros e CRM ?
O mercado de provedores de soluções EAI está em processo de maturação. As soluções de EAI possuem alta complexidade, exigem grandes investimentos e não se justificam para empresas de pequeno porte. A integração de processos necessitam às vezes de ajuda externa, com consultorias que exigem muitas horas de mapeamento e diagnóstico da melhor solução.
O importante é reconhecer que o EAI é um acrônimo novo que sintetiza e permite a implementação de um plano estratégico de integração de aplicações que é crítico para as empresas atualmente. As corporações que não integrarem suas aplicações não se tornarão empresas competitivas.
- Gerenciamento de Defeitos com TMap Next - Parte 5Softwares
- Como Criar e Configurar uma Private Cloud no System Center Virtual Machine Manager 2012 - Part...Virtualização
- Enhanced Mitigation Experience Toolkit–Evite ataques de HackersSegurança
- Introdução ao Windows Phone 7Mobile (MS)
- Embate entre IT PROs e desenvolvedores, como melhorar o relacionamentoSystem Center e Gerenciamento