O USO DA TECNOLOGIA ESB PARA INTEGRAÇÃO DE DADOS ÁLLAN GEORGE VIEIRA DE GOIS

UNIVERSIDADE FEDERAL DE MATO GROSSO COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO O USO DA TECNOLOGIA ESB PARA INTEGRAÇÃO DE DADOS ÁLLAN GEORGE VIEIRA DE GOIS CUIABÁ MT 2008

UNIVERSIDADE FEDERAL DE MATO GROSSO COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO O USO DA TECNOLOGIA ESB PARA INTEGRAÇÃO DE DADOS ÁLLAN GEORGE VIEIRA DE GOIS Orientador: Prof. Dr. JOSIEL MAIMONE DE FIGUEREDO Projeto de Trabalho de Conclusão de Curso apresentado ao Curso de Ciência da Computação da Universidade Federal de Mato Grosso, como requisito para elaboração da Monografia do Curso de Ciência da Computação. CUIABÁ MT 2008

UNIVERSIDADE FEDERAL DE MATO GROSSO COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO CERTIFICADO DE APROVAÇÃO Título: O Uso da Tecnologia ESB para Integração de Dados Autor: Állan George Vieira de Gois Aprovada em / / Prof. Dr. Josiel Maimone de Figueiredo Instituto de Computação - UFMT (Orientador) Prof. Dr. Patrícia Cristiane de Souza Instituto de Computação - UFMT Sandro Luiz Brandão Campos Simetrya Tecnologia da Informação

DEDICATÓRIA Dedico esse trabalho aos meus familiares, que sempre me apoiaram nos momentos mais difíceis, aos meus amigos, que estiveram ao meu lado nessa longa caminhada em busca do conhecimento. Em especial, quero dedicar à mulher que amo, por sempre ter estado ao meu lado, me apoiando e sendo compreensível nos momentos difíceis ao longo desses anos.

AGRADECIMENTOS Agradeço à minha família por ter me apoiado ao longo dos anos, me proporcionando condições de cursar uma faculdade de qualidade, na qual pude me beneficiar, tanto da aquisição do saber qualificado de professores como da troca de experiências com outros colegas. Agradeço à todos, que estiveram ao meu lado durante esses anos, participando do meu crescimento intelectual em especial ao Prof. Dr. Josiel Maimone de Figueredo que me guiou nesse caminho difícil em busca do saber.

SUMÁRIO RESUMO...7 LISTA DE FIGURAS...8 LISTA DE SIGLAS E ABREVIATURAS...9 1 INTRODUÇÃO...10 1.1 APRESENTAÇÃO...10 1.2 OBJETIVOS...11 1.3 JUSTIFICATIVA...12 1.4 METODOLOGIA...12 1.5 CRONOGRAMA PROPOSTO...13 1.6 CRONOGRAMA EXECUTADO...15 2 EVOLUÇÃO DA INTEGRAÇÃO DE DADOS...17 2.1 CONTEXTO HISTÓRICO...17 2.2 ENTERPRISE RESOURCE PLANNING...18 2.3 ENTERPRISE APPLICATION INTEGRATION...19 2.4 SERVICE ORIENTED ARCHITECTURE...23 3 INTEGRAÇÃO UTILIZANDO BARRAMENTO DE SERVIÇOS...24 3.1 ENTERPRISE SERVICE BUS...24 3.1.1 CONTENT BASED ROUTING (CBR)...27 3.1.2 MOM (MESSAGE ORIENTED MIDDLEWARE) NA ARQUITETURA ESB...28 3.1.3 ENDPOINT...30 3.1.4 CENÁRIO COMUM PARA UTILIZAÇÃO DO ESB...32 4 TESTES UTILIZANDO O ENTERPRISE SERVICE BUS (ESB)...33 4.1 SERVIDOR DE APLICAÇÃO...33 4.2 INICIALIZANDO O SERVIDOR ESB...34 4.3 APLICATIVOS...36 4.4 CONFIGURANDO O SERVIDOR ESB...36 5 CONCLUSÃO...42 6 REFERÊNCIAS BIBLIOGRÁFICAS...43

7 RESUMO Nesse trabalho foi elaborado um estudo sobre as diferentes plataformas de integração que visam solucionar os problemas de comunicação e troca de informação entre diferentes softwares. Para que possa ser visualizado a integração, testes foram realizados utilizando conceitos existentes nas diferentes plataformas de integração. Utilizandose de um exemplo prático para que seja possível visualizar a eficiência e necessidade de uma plataforma que integre sistemas distintos. A análise de cada plataforma de integração traz a segurança na escolha da melhor opção para a integração, levando em conta o contexto histórico e a evolução tecnológica. Partindo de soluções como o ERP (Enterprise Resource Planning) que visa integrar de uma forma total a empresa, passando pelo surgimento do conceito de plataformas de integração que inicializa com a utilização do EAI (Enterprise Application Integration) e chegando ao ápice em termos de solução na área de integração com a utilizando do ESB (Enterprise Service Bus). Palavras-chave: Integração, Organização, Soluções, Evolução, ESB.

8 LISTA DE FIGURAS FIGURA 1 CAMADA DE INTEGRAÇÃO E ELEMENTOS DAS APLICAÇÕES (THEMISCOCLEOU, ET AL 2002)...20 FIGURA 2 TRANSPORTE DE DADOS NO NÍVEL DE DADOS (LINTHICUM, 1999)....21 FIGURA 3 INTERFACE DE APLICAÇÃO (LINTHICUM, 1999)....22 FIGURA 4 EXEMPLO DE UM WEBSERVICE (ZHANG, 2006)....24 FIGURA 5 IMPLEMENTANDO SOA SEM ESB (ZHANG, 2006)....25 FIGURA 6 UTILIZANDO ESB NA ARQUITETURA SOA (ZHANG, 2006)....26 FIGURA 7 EXEMPLO DE UM ITINERÁRIO (CHAPPELL, 2004).....27 FIGURA 8 MOM (MESSAGE ORIENTED MIDDLEWARES) (CHAPPELL, 2004).....29 FIGURA 9 ESTRUTURA DE UM ENDPOINT (CHAPPELL, 2004).....31 FIGURA 10 FIGURA 10 CONFIGURAÇÃO DO CLASS PATH.....34 FIGURA 11 VERIFICAÇÃO DA PORTA DE ACESSO.....34 FIGURA 12 FIGURA 12 INICIALIZAÇÃO DO WEBSERVICE.....35 FIGURA 13 INICIALIZAÇÃO DAS FILAS DE MENSAGENS ATRAVÉS DO JNDI.....35 FIGURA 14 INICIALIZANADO O JUDDI.....35 FIGURA 15 VARREDURA NOS ARQUIVOS DE CONFIGURAÇÃO.....35 FIGURA 16 CÓDIGO DE UMA CLASSE JMS (JAVA MESSAGE SERVICE)....37 FIGURA 17 XML DA FILA DE MENSAGENS.....38 FIGURA 18 TRANSFERÊNCIA DE INFORMAÇÃO DO PROVEDOR PARA AS CLASSES......39 FIGURA 19 INFORMAÇÕES ARMAZENADAS NO ESB......39 FIGURA 20 FLUXO DA INFORMAÇÃO UTILIZANDO A TECNOLOGIA ESB......40 FIGURA 21 ESTRUTURA DO ESB......41

9 LISTA DE SIGLAS E ABREVIATURAS API CBR EAI ERP ESB JMS JNDI MOM SOA SOAP XML Aplication Progam Interface Content-Based Routing Enterprise Application Integration Enterprise Resource Planning Enterprise Service Bus Java Message Service Java Naming and Directory Interface Message-Oriented Middleware Service - Oriented Architectural Simple Object Access Protocol Extensible Markup Language

10 1 INTRODUÇÃO 1.1 Apresentação Na história das organizações adquirir softwares tornou-se prática comum, em busca da adaptação ao mercado. Com o crescimento das empresas e o surgimento de novas tecnologias, novos softwares vão sendo adquiridos pelas empresas. Mas cada software é criado para resolver objetivos de negócios, objetivos esses ditados pelo contexto do momento, ou seja, por questões de tempo, know-how e também questões financeiras. Normalmente esses softwares são projetados isoladamente (ARTEIRO et al, 2007). Quando existem muitos softwares na empresa, manipular todas as informações, torna-se, muitas vezes, tarefa difícil, pois há vários locais armazenando diferentes informações que são importantes para a funcionamento interno e externo da empresa. Assim, a empresa tende a tornar-se um ambiente totalmente desorganizado e descentralizado o que faz com que a tomada de decisões seja difícil, provocando, conseqüentemente, a perda de competitividade e controle. Essas dificuldades podem ser evidenciadas de forma mais clara, por exemplo, quando a empresa necessita de um relatório mensal. Como fazer um relatório sobre quantos clientes compraram determinado produto, se existe na empresa um software para cadastrar cliente e outro para cadastro de produtos, inexistindo, contudo, qualquer ligação entre esses softwares? Dessa forma a integração de dados apresenta-se como uma solução necessária. A integração de dados tem como objetivo trazer informações confiáveis, que sejam disponibilizadas de forma ágil, e com o intuito de auxiliar no processo de análise de um determinado problema. Para que isso seja possível é necessário o uso das plataformas de integração. As plataformas de integração, em ambiente corporativo, têm suma importância pois através delas serão encontrados pontos de comunicação entre diferentes sistemas. É de responsabilidade das plataformas de integração criar padrões que tornem possível a busca, alteração e inserção da informação em qualquer software de plataforma tecnológica diferente (LINTHICUM, 1999),

11 proporcionando, através da utilização de processos e métodos estruturados, uma integração de dados. Dessa forma, a empresa que optar por essa solução alcançará melhor organização dos seus dados e, possivelmente, um maior poder de decisão. Por fim, podemos afirmar que a integração de dados em sistemas corporativos contribui de forma positiva no preparo da empresa diante das constantes mudanças tecnológicas. 1.2 Objetivos 1.2.1 Objetivo Geral Este trabalho tem como objetivo geral implantar uma infra-estrutura computacional que simule as funcionalidades de um sistema corporativo. Por isso o conhecimento das formas diferentes de integrar os dados através das plataformas de integrações torna-se necessária. 1.2.2. Objetivos Específicos 1. Estudar a arquitetura ESB ( Enterprise Service Bus ). 2. Estudar a arquitetura SOA ( Service Oriented Architecture ). 3. Estudar a arquitetura EAI ( Enterprise Application Integration ). 4. Conhecer produtos voltados a integração de dados. 5. Conhecer ferramentas voltadas a integração de dados. 6. Simular as funcionalidades de um sistema corporativo através do estudo das arquiteturas de integração e conhecimento de ferramentas e produtos.

12 1.3 Justificativa Organizar a informação dentro da empresa sempre será de grande relevância, por isso hoje as empresas precisam estar preparadas para as mudanças decorrentes do surgimento de novas tecnologias. A partir do momento que uma empresa realiza um estudo aprofundado sobre seus requisitos, está sujeita a encontrar softwares que trabalham de forma isolada. Então, para que seja possível um melhor gerenciamento, essas empresas procuram formas de integrar as diferentes tecnologias. Para que a comunicação seja possível entre esses softwares é necessário padrões criados pelas plataformas de integração. Essas, através de mensagens gerenciadas pela camada intermediária, sendo considerado camada intermediária toda a estrutura que faz parte da plataforma de integração, que tem por objetivo integrar dados antes inacessíveis por outros sistemas. Por fim, a simulação de um ambiente corporativo, utilizando plataformas de integração, visa uma experiência imprescindível para uma adaptação rápida às mudanças tecnológicas. 1.4 Metodologia O estudo neste trabalho, apresenta-se por meio de bibliografias existentes na área, visa obter um domínio sobre os diferentes conceitos existentes dentro das plataformas de integrações. Além disso, com o estudo de ferramentas e tecnologias existentes para solucionar o problema da integração de dados, visa-se a implantação de uma infra estrutura corporativa. Por meio da utilização de um servidor, será possível implantar essa infra estrutura e fazer as simulações necessárias à obtenção de um resultado satisfatório utilizando-se para isso de um ambiente criado que contenha as ferramentas e produtos necessários para a execução da simulação.

13 1.5 Cronograma Este cronograma representa os passos necessários para que ao final seja possível simular as funcionalidade de um ambiente utilizando a tecnologia ESB. Tabela 1 Cronograma Proposto Meses/Semanas Etapas Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 Etapa 1 Etapa 2 Etapa 3 Etapa 4 Etapa 5 Etapa 6 Etapa 7 Etapa 8 Etapa 1 Pesquisa bibliográfica Soluções Estudo das arquiteturas existentes dentro do conceito de plataforma de integração (Arquitetura EAI, Arquitetura SOA, Arquitetura ESB). Etapa 2 Elaboração do material de Apresentação Elaboração do material de apresentação do PTCC. Etapa 3 Apresentação Apresentação do PTCC. Etapa 4 Levantamento de Produtos Levantamento dos produtos utilizados para integração de dados. Etapa 5 Simulação Simulações buscando integrar os conceitos estudados com a utilização de um servidor, estes por sua vez representa o local onde pretende-se fazer a integração dos dados.

14 Etapa 6 Implantação Esta etapa visa implantar um ambiente definitivo logo após feitas todas as simulações necessárias. Etapa 7 Material de apresentação Elaboração do material de apresentação do TCC. Etapa 8 Apresentação Apresentação do TCC.

15 1.5 Cronograma Executado Este cronograma representa os passos que foram executados para que fosse possível utilizar a tecnologia ESB. Tabela 1 Cronograma Executado Meses/Semanas Etapas Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 Etapa 1 Etapa 2 Etapa 3 Etapa 4 Etapa 5 Etapa 6 Etapa 7 Etapa 8 Etapa 1 Pesquisa bibliográfica Soluções Estudo das arquiteturas existentes dentro do conceito de plataforma de integração (Arquitetura EAI, Arquitetura SOA, Arquitetura ESB). Etapa 2 Elaboração do material de Apresentação Elaboração do material de apresentação do PTCC. Etapa 3 Apresentação Apresentação do PTCC. Etapa 4 Levantamento de Produtos Levantamento dos produtos utilizados para integração de dados. Etapa 5 Simulação Simulações buscando integrar os conceitos estudados com a utilização de um servidor, estes por sua vez representa o local onde pretende-se fazer a integração dos dados.

16 Etapa 6 Implantação Esta etapa visa implantar um ambiente definitivo logo após feitas todas as simulações necessárias. Etapa 7 Material de apresentação Elaboração do material de apresentação do TCC. Etapa 8 Apresentação Apresentação do TCC.

17 2 EVOLUÇÃO DA INTEGRAÇÃO DE DADOS 2.1 Contexto Histórico A quantidade de informação dentro de uma empresa cresce proporcionalmente ao aumento de softwares utilizados. Esse crescimento gera dificuldade para visualizar o fluxo de dados da empresa, tornando assim, difícil obter informações confiáveis. A primeira solução proposta para amenizar esse problema é o uso do ERP. O ERP é um software modularizado e integrado que permite um gerenciamento poderoso das informações. Contudo, devido ao seu elevado custo, uma vez que as empresas eram obrigadas a abandonar seus antigos sistemas, o ERP perdeu força. Entende-se perder força como a diminuição da procura pela solução ERP, devido a novas tecnologias que surgem na área integração de dados que possibilita um custo menor de integração. No decorrer do trabalho será apresentado diferentes arquiteturas de integração, que tiveram em comum, a busca pela integração dentro dos limites tecnológicos existentes em suas respectivas época. Inicialmente, é apresentado um estudo sobre a arquitetura EAI, que visa facilitar a comunicação entre os aplicativos e diminuir a necessidade de alterações nos códigos fontes, através de seus message brokers em sua camada de integração. No entanto, a dificuldade de manutenção e reutilização de funcionalidades já implementadas, trouxeram a necessidade que novas tecnologias de integração surgissem. Com o passar dos anos, juntamente com a evolução da internet nasce o conceito de SOA. O SOA baseia-se na idéia de serviços para integrar os dados, de forma a tornar possível reutilizar as funcionalidades. Para isso o SOA usa os chamados webservices, que tem como objetivo gerenciar as chamadas entre aplicativos. O problema, é que, por ainda utilizar as conexões entre aplicativos ponto a ponto, com passar do tempo torna-se difícil gerenciar todas as conexões existentes. Assim nasce o conceito de ESB, que tem como objetivo tratar essas conexões de forma que o ESB seja responsável por rotear as mensagens e disponibilizar os

18 serviços a todos os aplicativos, tornando a comunicação totalmente abstrata em relação aos aplicativos. 2.2 Enterprise Resource Planning (ERP) O ERP (Enterprise Resource Planning) é uma plataforma de solução que utiliza módulos integrados (contabilidade, financeiro, recursos humanos, gestão de inventário). Considerado uma solução voltada para médias e grandes empresas, devido principalmente ao seu elevado custo e a necessidade de um estudo aprofundado sobre requisitos da empresa, o ERP é adaptável de forma condicionada ao escopo da empresa, podendo assim adicionar ou retirar módulos, de acordo com as suas necessidades (HOSSAIN et al, 2002). O ERP proporcionou nova perspectiva para as empresas, mas não conseguiu solucionar por completo os problemas existentes, uma vez que a integração de dados mostra-se mais complexa. Com o ERP as empresas eram obrigadas a abandonar seus softwares antigos e migrar para o ERP, através do estudo de requisitos da empresa e migração de dados. Isso, em determinados casos, mostrou-se desastroso, Em 1996, FoxMeyer Drug, empresa de distribuição de remédios avaliada em US $ 5 bilhões, declarou falência por não conseguirem implementar um sistema de ERP, ao longo de um período de três anos. (ADAM, 2004, p.06). FoxMeyer e outras empresas que sofreram essa situação serviram de exemplos para que outras empresas buscassem novas alternativas para a integração de dados. Nasce então o conceito de plataforma de integração. Podemos defini-la como a procura de uma padronização que visa facilitar o gerenciamento de dados, solucionando o problema de comunicação entre softwares distintos. Ademais, a sua utilização mostra-se vantajosa no sentido de representar uma evidente redução dos gastos relativos a área de TI, uma vez que tal custo alcançava 30% dos recursos destinados a referida área (LINTHICUM, 1999).

19 2.3 Enterprise Application Integration(EAI) A solução apresentada em relação a plataforma de integração é o EAI (Enterprise Application Integration) o qual começa a ser usado, em larga escala pelas empresas, no final dos anos 90 (JUNIOR, 2007). Segundo Linthicum (1999), para que seja possível a utilização da arquitetura EAI, a empresa interessada necessita, inicialmente, de um levantamento de requisitos que identifiquem os dados considerados importantes. Esse levantamento revela-se de suma importância, uma vez que o EAI também integrará os sistemas legados e possíveis softwares existentes em computadores pessoais (considerando softwares em computadores pessoais como sistemas inacessíveis por outros computadores). Nesse sentido, cabe a empresa descobrir o que há de importante nos referidos sistemas, no intuito de criar um padrão para a busca de dados, pois esse é o objetivo principal do EAI. Além disso, o EAI representa uma plataforma apta à solucionar os problemas existentes no transporte de dados. Estima-se que os gastos em grandes empresas estão concentrados principalmente no momento do transporte de dados, sendo considerado transporte de dados as trocas de informações e processos de negócios na empresa. A forma de comunicar softwares diferentes, até então empregado, era a utilização de middlewares tradicionais. Esses middlewares utilizam técnicas de filas de mensagens para ligações ponto a ponto, ou seja, a ligação entre uma aplicação A com uma aplicação B, a qual recebe mensagens em ordem de chegada. Ocorre que os middlewares tradicionais precisam estar acomodados tanto no aplicativo A quanto no aplicativo B. Para que isso se torne possível, é necessário alterar os aplicativos para que eles comandem as ações do middlewares. O EAI utiliza uma solução alternativa para a comunicação entre softwares e processamento de negócios, o chamado message-oriented middleware (MOM). A MOM tem como objetivo retirar das aplicações a responsabilidade de comunicação, a qual representava um fator de grande dificuldade para as empresas, principalmente no que diz respeito à manutenção. Para que isso seja possível, na camada de integração criada pelo EAI, o MOM utiliza os chamados message brokers,

20 mensagens que visam comunicar aplicações de uma forma ponto-a-ponto, tornandose o responsável pelo gerenciamento dessas mensagens. Podemos dividir a camada de integração em três partes: Camada de Transporte: Consiste na infraestrutura que busca levar os dados de uma aplicação para outra. Camada de Transformação: Infraestrutura responsável por transformar os dados da aplicação fonte para o formato da aplicação alvo. Camada de Automação de Processo: Responsável em integrar os processos de negócio e controlar essa integração através de mecanismos específicos. Ilustrado na Figura 1. Figura 1 - Camada de Integração e Elementos das Aplicações (THEMISTOCLEOU, et al 2002). A Figura 1 indica a possível troca de dado existente entre uma aplicação fonte e uma aplicação alvo, os quais estão ligados através de uma camada de integração EAI. Essas aplicações estão configuradas para transferir dados (objetos ou processos) entre os possíveis elementos da aplicação. Para isso a aplicação fonte utilizará a camada de transporte. Como em muitos casos os dados não são tratados da mesma forma entre aplicações, há a necessidade da utilização da camada de transformação para haver uma comunicação. Posteriormente, através da automação dos processos, será possível dizer a qual processo pertence o elemento transferido (serviços, lógica comercial, regras) ou seja, será a automação dos processo que validará essa integração ocorrida buscando incorporar os processos através do disparos de eventos.

21 A camada de integração (Figura 1) será aplicada nos diferentes níveis de integração existentes dentro do EAI. Conforme (LINTHICUM, 1999), a necessidade de dividir a integração em níveis distintos, advém da facilitação da integração. Os níveis existentes podem ser classificados em: Nível de dado : A utilização do EAI implantado a nível de dados tem como objetivo transferi-los de um banco para outro evitando assim reescrever dados. Será por meio da camada de integração (Figura 1) que isso será possível. Figura 2 - Transporte de dados no nível de dados (LINTHICUM, 1999). A Figura 2 indica como seria o transporte dos dados utilizando o nível de dados, onde o usuário, através de sua interface, solicita o envio de alguma informação através da parte lógica do sistema, chegando assim no banco de dados fonte, onde, posteriormente, será enviado à camada de integração (Figura 1). Já com os dados transformados, o banco de dados alvo faz a trajetória inversa para a integrálos. Nível Interface de Aplicação: Devido a necessidade da troca de informações entre softwares diferentes, o EAI utiliza um nível chamado Interface de Aplicações, que através de API's (Application Programming Interface), disponibilizam serviços referentes ao software, tornando possível a troca de informações entre aplicativos sem precisar ter um conhecimento interno do software que disponibiliza o serviço.

22 Figura 3 - Interface de Aplicação (LINTHICUM, 1999). Na Figura 3, observamos que a aplicação disponibiliza, através de API's, funcionalidades que ela é capaz de fazer. Verifica-se ainda que as referidas API's tornam possível a utilização de seus recursos por diferentes sistemas. Nível de métodos: As empresas, em determinadas situações, buscam uma integração que possibilite a reutilização de métodos. Esta torna-se possível através da criação de uma infraestrutura de sistemas distribuídos que permite o acesso de vários aplicativos a métodos existentes. Através da utilização dos frameworks, o EAI permite o acesso a subsistemas, arquitetura de aplicação e a reutilização de códigos existentes. O frameworks é definido por Freedman (1993) como uma classe abstrata em que seu objetivo é auxiliar na formação das classes concretas, ou seja, nos permite utilizá-lo para auxiliar na formação de aplicações que usufruam da infraestrutura. Como resultado a empresa tem uma redução de métodos redundantes, pois agora os aplicativos poderão buscar funcionalidades já implementados. Nível de Interface do Usuário: Em alguns casos o usuário é a única alternativa para avaliar mecanismos disponíveis ao acesso de dados. Por isso, se faz necessário o uso de uma interface EAI que facilite a comunicação entre o usuário e o sistema. A utilização dessa interface EAI é imprescindível quando não há uma ligação entre aplicativos ( banco de dados, Interface de aplicação).

23 A responsabilidade pela manipulação dos dados fica nas mãos do usuário, sendo assim não é preciso alterar nem o aplicativo fonte nem o aplicativo alvo. A interface EAI tem maior aplicação nos mainframes, que estão isolados, possibilitando a transferência dos dados para outros aplicativos e, conseqüentemente, criando um ponto de integração. 2.4 Service-Oriented Architectural (SOA) A conexão ponto a ponto na arquitetura EAI trouxe dificuldade de manutenção, tornando-se indispensável a criação de uma conexão sempre que necessário novos recursos envolvendo aplicativos diferentes, essa falta de reutilização dos trabalhos realizados e dependência de apenas um fornecedor fez com que as empresas buscassem novas tecnologias na área de integração de dados. Com o avanço da internet e seus respectivos serviços prestados, novas soluções são propostas para a auxiliar no problema da integração. Nesse sentido, SOA (Service- Oriented Architectural) apresenta-se como uma arquitetura que permite essa integração de dados. Baseado em serviços, SOA aplica os conceitos de orientado a objeto, componentes e tecnologia EAI. Os serviços representam as funcionalidades que estão disponíveis pelos diferentes aplicativos na integração, tornando-se disponíveis a todos por meio do encapsulamento, evitando assim o retrabalho, além de permitir que os aplicativos acessem os serviços habilitados (KEEN, 2004). Enquanto na arquitetura EAI não é possível reutilizar o serviço feito quando implementado uma camada de integração (Figura 1) de um aplicativo A para um aplicativo B, no SOA isso é perfeitamente possível, pois, apesar de basear-se numa conexão ponto a ponto como no EAI, o SOA consegue reutilizar estes serviços através da utilização dos webservices, de onde advém a idéia de encapsulamento. O webservice busca disponibilizar serviços utilizando uma linguagem padrão para a comunicação entre esses aplicativos diferentes. Para isso o webservice utiliza a linguagem XML. Conforme Zhang (2006) podemos visualizar o webservice da seguinte forma:

24 Figura 4 - Exemplo de um webservice (ZHANG, 2006). Através de um serviço de despacho, conforme se observa na figura 4, o webservice concentra todos os serviços prestados pelos aplicativos na conexão, de forma que, quando for necessário algum serviço através da utilização dos protocolos de comunicação (WSDL, UDDI, SOAP), o aplicativo faz uma solicitação buscando no serviço de despacho o serviço desejado; na sua existência, o aplicativo que fez a solicitação através da sua ligação ponto a ponto, se comunica diretamente com o serviço provedor. Ocorre que, o fato de ainda trabalhar com o conceito de ponto a ponto, torna o gerenciamento das ligações entre aplicativos e controle dos serviços disponíveis inadequado, com o passar do tempo. 3 INTEGRAÇÃO UTILIZANDO BARRAMENTO DE SERVIÇOS 3.1 Enterprise Service Bus (ESB) O conceito de ESB (Enterprise Service Bus) tem como objetivo organizar as ligações entre aplicações (Figura 5), permitindo maior flexibilidade e o aumento na capacidade de gerenciamento da arquitetura SOA (ZHANG, 2006). Como citado no item anterior inicialmente temos uma imagem desorganizada do ambiente SOA, pois existem múltiplas conexões ponto a ponto.

25 Conforme Zhang (2006), podemos demonstrar o ambiente SOA sem a utilização do ESB da seguinte forma: Figura 5 Implementando SOA sem ESB (ZHANG, 2006). O ESB tem como função a criação de uma central de chamadas, em que o solicitador de serviço fará uma chamada a essa central ESB, diferente da forma como funcionava antes, quando era necessário fazer uma ligação direta com o provedor do serviço. Assim a arquitetura ESB tenta diminuir a interação entre os aplicativos, que geravam necessidade de um maior detalhamento no código do serviço (detalhes da localização do serviço e qual o caminho que deve ser feito pela requisição). Isso pode ser demonstrado da seguinte forma: Figura 6 Utilizando ESB na arquitetura SOA (ZHANG, 2006).

26 Essa organização através do ESB tornou possível reutilizar componentes sem ter que criar uma nova conexão ponto a ponto, pois o barramento ESB contém todos os serviços existentes entre todos os provedores. O ESB mantêm o registro de todos os serviços disponíveis, utilizando-se para isso, uma fila de mensagens XML para transmitir ao solicitador, as mensagens desejadas. O ESB tem, assim como o SOA, um diretório de armazenamento das informações de serviços, contudo esses serviços não são codificados mais na parte lógica do negócio, ou seja, não há códigos de XML no provedor ou no solicitador, mas sim no barramento ESB. Com isso retira-se a codificação da parte lógica do negócio trazendo para o ESB tal responsabilidade. Por meio da utilização de mensagens itinerários, o ESB disponibiliza a informação ao solicitador. Champpell (2004) descreve as mensagens itinerários como sendo mensagens que contém um fluxo definido, as quais são compostas por vários pequenos processos de diferentes aplicações. Consoante se observa na figura abaixo: Figura 7 Exemplo de um itinerário (CHAPPELL, 2004). Como demonstrado (Figura 7), o itinerário possui várias etapas que descrevem um possível fluxo de trabalho. O itinerário contém tanto informações de rotas, quanto sobre qual aplicativo configurado para disponibilizar o serviço na etapa, criando assim um fluxo. O conhecimento de rota do itinerário permite maior agilidade para encontrar o solicitador e o prestador. Com isso, pode-se afirmar que o ESB é uma arquitetura altamente distribuída e totalmente descentralizada. 3.1.1 Content Based Routing Outro fator importante na arquitetura ESB está relacionado ao uso do CBR (Content-Based Routing), o qual permite uma difusão do conteúdo por roteamento e tem como objetivo determinar quais mensagens precisam de serviços especiais,

27 tomando como exemplo, um aplicativo X1 que precisa enviar mensagens para um aplicativo Y1. Para que isso se concretize, é necessário que a mensagem seja roteada para um serviço especial (no caso em tela, trata-se da transformação), pois esses aplicativos não se comunicam na mesma linguagem. Todavia, se um novo aplicativo M1 tentar mandar uma mensagem para Y1 sem necessitar de um serviço especial, deverá criar uma nova ligação entre esses aplicativos. Momento em que é necessário o CBR, que consiste numa camada por onde passam todas as mensagens, e através da sua configuração é determinado para onde é roteado cada mensagem. No exemplo em questão, a mensagem de X1 é enviada para o CBR, o qual está configurado para roteá-la à um serviço especial e deste para Y1; diferente da mensagem M1 que está configurada no CBR a ser roteado diretamente ao Y1 pois não necessita de um serviço especial. Cada decisão de roteamento necessário está identificado dentro de um diretório que define o que será feito com cada tipo de pacotes que chega a um ponto de roteamento, através da utilização de itinerários é determinado o processo que será executado (ZIYAEVA et al, 2008). Ao contrario dos sistemas tradicionais o CBR não vai adicionando pacotes junto da mensagem e transmitindo para frente pois ele tem influência sobre o endereçamento e roteamento da mensagem, por isso é necessário uma forma para manter a transparência na camada de transporte. O produtor (emissor da mensagem) produz as mensagens e transmite através do roteamento CBR mas esse produtor não conhece seu destino específico, o que definirá os locais para onde cada pacote irá trafegar é o interesse do receptor, obtendo assim uma transparência no transporte sabendo que ninguém conhece o produtor e nem o emissor (RADEMAKERS & DIRKSEN, 2009). Por fim podemos descrever o ESB como um conceito que através dele é possível direcionar mensagens de uma formz mais transparente, altamente distribuído por ser responsável pelas rotas existentes mantendo informações do mesmo, e tem sua capacidade de reusabilidade facilitada pois mantém centralizado o serviço o que facilita a busca.

28 3.1.2 MOM( Message Oriented Middleware) na Arquitetura ESB Uma funcionalidade vital para que o barramento ESB tenha um funcionamento adequado é a utilização do MOM. O MOM tem como objetivo fornecer canais virtuais para que os utilizadores do ESB possam trocar informações entre eles através de mensagens assíncronas e síncronas (HU et al, 2008), buscando uma transparência na comunicação o MOM também tem a responsabilidade de manter abstrato os conteúdos das mensagens, ou seja, receptores e emissores não sabem nada a respeito das transmissões de mensagens. Utilizando-se de uma API o cliente envia uma mensagem que deseja e a função de gerenciar essa mensagem, criar múltiplos canais entre clientes é do sistema de mensagens. O sistema de mensagens nada mais é do que um servidor de mensagens que tem uma capacidade avançada em rotear seguramente as informações e balancear as cargas existentes na transmissão. Segundo Champpell (2004) ao conjunto, sistema de mensagens e mensagens do cliente, damos o nome de MOM exemplificada na figura a baixo: Figura 8 MOM (Message Oriented Middlewares) (CHAPPELL, 2004). O ESB mantém um repositório onde guarda as informações da criação e gerenciamento das mensagens que são mantidas encapsuladas. O MOM utiliza-se dessa configuração para obter a mensagem e codificá-la para entrega ao receptor. O receptor e o emissor são definidos por CHAPPELL (2004) respectivamente como Produtor (emissor) e Consumidor (receptor), quando há a

29 necessidade de uma resposta por parte de um receptor, o mesmo utiliza-se de dados na mensagem recebida para retornar no canal virtual correto sua resposta. O envio da mensagem pelo Produtor (emissor) acontece de duas formas, sendo a primeira através de publicação, onde segundo ZHAO (2006) o Produtor envia através do canal virtual a mensagem e posteriormente os Consumidores (receptores) cadastram-se em uma fila para recebimento da mensagem. Caso não haja ninguém cadastrado a mensagem fica guardada no canal até que algum Consumidor se cadastre, independente do cadastro a mensagem não é descartada. A segunda forma de enviar mensagem é a utilização do ponto a ponto onde o Produtor já tem uma ligação direta e conhece seu Consumidor, esse canal é pré estabelecido e não pode cadastrar mais que um Consumidor. A vantagem da comunicação ponto a ponto é a garantia de entrega a um Consumidor coisa que não acontece no caso da publicação que pode haver ou não um Consumidor (JIANG et al, 2006) A mensagem MOM será composta por três partes, o cabeçalho, propriedade e o corpo da mensagem. O cabeçalho tem como função levar as informações de roteamento da mensagem, o tempo de duração, destino da mensagem e também informações que serão utilizadas pelo sistema e o próprio desenvolvedor da mensagem. A parte da propriedade utiliza-se de pares de nomes / valores que tem como função direcionar como a mensagem será utilizada. A última parte é o corpo da mensagem que leva as informações que serão utilizadas pelo destino. Dentre os padrões de MOM podemos citar o JMS (Java Message Service), surge com força no mercado no ano de 1998. O JMS é uma API (Application Programming Interface) que tem como objetivo determinar regras para o gerenciamento das entregas de mensagens dentro do MOM. Também tem como objetivos determinar regras nas relações pub / sub e ponto a ponto buscando oferecer de uma forma flexível as definições das mensagens e gerenciando também a forma de envio.

30 A API JMS busca garantir a interoperabilidade, ou seja, cabe ao protocolo JMS garantir que a mensagem que sai do cliente e passa pelo MOM não sofram alterações durante o trajeto até o seu destino (CHAPELL, 2004). Outro padrão utilizado é o protocolo SOAP (Simple Object Access Protocol), baseado em XML o SOAP busca auxilar na entrega de mensagens dando a elas uma codificação para evitar que indesejáveis tenham acesso ao conteúdo das mensagens. 3.1.3 Endpoint Um dos grandes pontos fortes do ESB é sua capacidade de ser altamente distribuído facilitando assim o trabalho de integração entre diferentes tecnologias, para que seja possível essa alta distribuição o SOA disponibiliza seus serviços para o barramento ESB através dos Endpoints (Martin et al, 2004). O Endpoint pode ser um pequeno serviço ou até um serviço complexo, cujo o objetivo é estar disponível para a utilização por outros aplicativos (JIANWU et al, 2006). Podemos citar como exemplo, um cálculo de folha de pagamento que sozinho não executa uma tarefa mas com a utilização de vários Endpoints, ao final pode estar disponibilizando todo um fluxo de serviço (CAMPBELL, 2004). Sabendo que, em uma grande empresa há diversos serviços que necessitam ser compartilhados e que esses serviços estão em diferentes plataformas tecnológicas, é imprescindível a existência de protocolos e padrões para tornar possível o tráfego desses serviços para o ESB. Para que isso aconteça é preciso construir os Endpoins utilizando padrões como JMS, SOAP, Web Service, que visam traduzir os parâmetros vindos dos softwares e posteriormente disponibilizar ao ESB. Segundo Champpell (2004), um Endpoint terá a seguinte estrutura:

31 Figura 9 Estrutura de um Endpoint (CHAPPELL, 2004). Endpoint ESB: Representa o protocolo que o parâmetro está utilizando. Interface Endpoint: É a interface que será utilizada para comunicar o Endpoint ao ESB, por exemplo o JMS, Web Service. Gerenciamento do Framework:Contém informações relativas ao gerenciamento do Endpoint como, disponibilidade e parâmetros de rede. Serviço: Dados que serão disponibilizados ao ESB, mantém informações do ciclo de vida do Endpoint, além de uma entrada e saída, as quais enviam mensagens para o ESB ou para o serviço. Conexão com ESB: Representa a forma como os dados chegarão ao ESB. É importante definir o exato papel, tanto do Endpoint, quanto do ESB, vez que este tem a função de rotear mensagens e eventos, bem como transações de envio e recebimento de mensagens, enquanto o Endpoint apenas disponibiliza serviços (FERGUSON & STOCKTON, 2005). Através dessa estrutura é possível garantir a modulação do serviço, pois a configuração do Endpoint não afeta, diretamente, o ESB e vice versa, ou seja, o sistema é flexível e apto à possíveis mudanças. 3.1.4 Cenário comum para utilização do ESB A utilização do ESB em um sistema corporativo pode ser impulsionada por objetivos estratégicos mas o motivo mais comum é a sugestão feita pela área de TI para que seja possível suprir as necessidades de flexibilidade da empresa e uma generalização dos dados visando facilitar projetos existentes e futuros (KEEN et al, 2004).

32 Ainda segundo KEEN (2004) existem drivers, tecnologias e questões necessárias para que haja um alto nível de utilização do padrão SOA com o ESB sendo estes: Drivers: Necessário devido à integração de diferentes tecnologias (por exemplo, J2EE e.net). Regras do cenário: Imprescindível discutir o acesso de cada sistema para garantir um padrão de interoperabilidade, ou seja, preferências na utilização da rede e níveis de acesso. Tecnologias de apoio a integração: Escolha de tecnologias que irão facilitar a integração: Webservices Tecnologias de mensagens (por exemplo, MOM). Adaptadores e/ou conectores (por exemplo, endpoints). Questões relevantes: Existem questões que terão que ser discutidas para chegar a melhor escolha possível para a integração, dentre elas estão: Tecnologias de interoperabilidade (por exemplo, JMS e SOAP). Apoio técnico para os sistemas já existentes. Necessário para buscar soluções de integração com esses sistemas. Requisitos de Segurança. Escolha de tecnologias para garantir a segurança de envio, recebimento e roteamento de mensagens dentro do ESB. Todos esses dados são importantes para que se tenha a padronização do ESB garantindo com isso segurança, flexibilidade e interoperabilidade para que se tenha uma confiabilidade no ESB. 4 Testes Práticos utilizando o Enterprise Service Bus (ESB) Para ser possível a construção de um teste utilizando ESB, se faz necessário, primeiramente, escolher um dos diversos servidores ESB.

33 O servidor ESB tem como função receber e fornecer serviços que serão disponibilizados. Para que isso ocorra, um servidor é inicializado de forma que, tanto consumidores como fornecedores possam utilizá-lo. Durante o estudo das plataformas de integração foram introduzidos conceitos sobre os níveis de integrações propostas pelo EAI, esses testes têm como objetivo mostrar uma integração de aplicação para aplicação a qual irá demonstrar o fluxo de informação através do gerenciamento camada ESB. 4.1 Servidor de Aplicação Através da utilização de um servidor de aplicação é possível manter o ESB acessível. O servidor de aplicação tem como objetivo oferecer uma infra estrutura com diversos serviços de camada como: 1. Ambiente de operação de componentes distribuídos 2. Gerenciamento de recursos 3. Controle de Transação 4. Autenticação e autorização 5. Persistência O servidor de aplicação selecionado para a execução dos teste foi o JBossESB, que se trata de uma extensão do JBoss que tem como objetivo utilizar as teorias de ESB para organizar e disponibilizar serviços.

34 4.2 Inicializando o Servidor ESB Por meio da figura podemos observar passo a passo o log de inicialização do nosso servidor JBossESB: Figura 10 Configuração do Class Path. Primeiramente o JBossESB verifica se está configurado o class path com o jdk1.5 pois ele é implementando em java, ou seja, para inicializa-lo é necessário a instalação de uma máquina virtual java conforme a Figura 10. O próximo passo é a busca pelo arquivo jboss-service.xml, a qual irá varrer toda a estrutura do JBossESB buscando as bibliotecas necessárias para a inicialização, bem como diretórios necessários dentro do ESB. Figura 11 Verificação da porta de acesso. Se estiver correto o jboss-service.xml o próximo passo será encontrar a porta de acesso a esse servidor conforme a Figura 11. Isto porque, para que possa existir a troca de informação entre Produtores ESB e ESB Consumidores é necessário uma porta para comunicação pré estabelecida na inicialização do servidor. Figura 12 Inicialização do WebService. A Figura 12 indica a pilha de WebServices chamado de JBossws, que visa inicializar a pilha e mapear todos WebServices existentes dentro do ESB.