O que é e o que faz ?

Uma aplicação é confeccionada para usar uma fonte de dados, estabelecendo forte dependência entre ambas, na qual mudanças em um repercutem no outro. O Integrate é uma infra-estrutura para integrar informações registradas em fontes de dados heterogêneas, a partir de aplicações existentes, e que não exige a modificação nem das aplicações nem das fontes de dados.

É uma proposta na forma de framework a ser empregada por desenvolvedores de código de sistemas de integração de dados heterogêneos, e busca oferecer uma padronização tecnológica que facilite a geração deste tipo de sistemas. Este emprego exige que a infra-estrutura fornecida seja estendida para contemplar as especificidades do caso de integração em questão. A infra-estrutura disponibilizada é baseada na arquitetura de mediadores e tradutores [9].

Diversas propostas de integração ressaltam o significativo uso desta arquitetura, como Integra [4], MOMIS [6], CoDIMS [5], Garlic [7], TSIMMIS [8], LORIS [3], XQuare [11], XMF [1], dentre outros, que têm em comum a necessidade de acessar as fontes de dados após os devidos tratamentos semânticos. O Integrate implementa esta arquitetura, como pode ser visto na figura abaixo:



A maioria dos sistemas de integração pesquisados que influenciaram o Integrate fazem uso de uma interface própria para a interação com seus usuários. Esta interface utiliza internamente o modelo de dados do mediador e o esquema global definido por ele. Para este cenário, a infra-estrutura aqui proposta apresenta-se como uma solução para o problema. Trata-se de uma proposta genérica de solução. Outros detalhes podem ser vistos no item "Desenvolvedor de mediador - modelo genérico".

Para permitir a integração de dados onde as fontes de dados e as aplicações não sejam alteradas, estes cenários ficam inviabilizados. Para tentar solucionar este problema, o modelo de solução foi estendido, incluindo um interceptador, que age entre a aplicação cliente e o mediador, conforme a figura abaixo:



No modelo proposto a consulta original é interceptada e reescrita pelo mediador, uma para cada tradutor, e os resultados obtidos são integrados (também pelo mediador) antes de serem retornados à aplicação cliente. Outros detalhes podem ser vistos no item "Desenvolvedor de mediador - modelo  estendido".

Segue uma breve descrição dos módulos do modelo adotado.

Controlador - É responsável pela interação entre o mediador e os tradutores, sendo responsável pelo fluxo de atividades (workflow). Este módulo se assemelha ao componente “Controle”, proposto no CoDIMS [5].

Mediador - Módulo responsável pelo processamento semântico, onde se aplica toda a inteligência do modelo. No modelo tradicional (figura 1), este módulo é responsável pela interface com a aplicação cliente, e executa as subconsultas através dos serviços disponibilizados pelo Controlador, integrando os resultados antes de retorná-los à aplicação. Neste cenário, o Mediador solicita os serviços ao Controlador.

No modelo estendido (figura 2), este módulo oferece serviços de geração das subconsultas e de integração dos resultados parciais. Neste cenário, o Controlador solicita os serviços ao Mediador.

Tradutor - Módulo que interage diretamente com as fontes de dados. Há um tradutor para cada fonte de dados. Tradutores para alguns formatos mais comuns são fornecidos. O modelo de solução, contudo, permite que outros sejam implementados, possibilitando a integração de fontes de dados que fazem uso de outros formatos.

Interceptador - Este módulo é responsável pelo desvio de fluxo de controle entre a aplicação e a fonte de dados original, quando implementado o modelo de solução estendido. Após interceptar as requisições da aplicação cliente, este módulo as redireciona ao Controlador, que as repassa ao Mediador, para que este gere as subconsultas para as fontes de dados de interesse. Estas subconsultas são então direcionadas às respectivas fontes de dados, por meio dos tradutores.

No sentido inverso, os resultados obtidos das fontes de dados são repassados ao mediador para que sejam integrados. O resultado integrado é então entregue à aplicação cliente, no modelo e formato esperado por ela, conforme a fonte de dados original. A figura abaixo resume este processo.



Enquanto a (a) exibe o cenário tradicional, onde a aplicação acessa diretamente a fonte de dados usando o formato definido, o cenário da figura (b) ilustra as trocas de formato feitas durante o processo. As linhas tracejadas representam a requisição da aplicação A enviada no formato conhecido por ela (f_bd1) e interceptada pelo Interceptador. As requisições são redirecionadas ao mediador que retorna as subconsultas referentes às fontes de dados envolvidas nos seus respectivos formatos (no exemplo, formatos f_bd1 e f_bd2), que são posteriormente repassadas às fontes de dados correspondentes através dos tradutores. No sentido inverso, os resultados são novamente repassado ao mediador, que executa a integração no formato conhecido por A (f_bd1). Este resultado integrado é então entregue à aplicação pelo Interceptador.

Lookup - Interage com as fontes de dados para extrair os esquemas destas fontes. Disponibiliza uma API extensível para permitir que novas fontes de dados possam ser adicionadas, semelhante ao proposto em [2].

Metadados - Módulo responsável por manipular os arquivos de configuração do framework. Estes arquivos de configuração descrevem quais as fontes de dados serão consultadas por uma dada aplicação, entre outras.


Algumas definições.

• O modelo de dados adotado é o relacional. Além da solidez deste modelo, normalmente os dados a serem integrados estão armazenados em fontes de dados relacionais. A troca de mensagens é feita via JDBC, mas pode ser feita através de mensagens XML, em modelo definido pelo framework.

• O mediador é responsável pela definição do esquema global integrado. Para auxiliar esta tarefa, o framework disponibiliza serviços que facilitam a obtenção dos esquemas das fontes a serem integradas.

• É de responsabilidade do mediador a integração dos esquemas e dos resultados obtidos, além de fornecer as subconsultas que são repassadas aos tradutores, devido à questões semânticas inerentes.

Escopo

O principal resultado esperado do Integrate é disponibilizar uma infra-estrutura tecnológica que facilite o desenvolvimento de sistemas de integração que acessem informações registradas em fontes de dados heterogêneas.

Na solução aqui proposta, há ênfase nas funções atribuídas aos Tradutores e na interação entre estes e o Mediador. Em conseqüência, Mediadores propriamente ditos, ontologias e outras questões correlatas estão além do escopo do Integrate, e nestes casos pouca funcionalidade é oferecida.

Os serviços disponibilizados pelo Integrate permitem a criação de mediadores sem que estes conheçam necessariamente os detalhes de acesso às fontes de dados a serem integradas. Cabe ao Mediador as questões semânticas e a interação com as aplicações clientes, no cenário da figura 1. Cabe ao Integrate intermediar as conversões entre o Mediador e as fontes de dados, além da interação com as aplicações clientes, no caso do cenário estendido.

O escopo do Integrate é destacado na figura abaixo:



Como proposto, a interação entre a aplicação cliente e o Interceptador é realizada via JDBC. Por trabalhar internamente com o modelo relacional, o Integrate permite a troca de mensagens com o mediador através de JDBC.
Para que as trocas de mensagens não exijam do mediador o conhecimento de JDBC, um formato comum será posteriormente definido pelo Integrate, abstraindo do mediador este conhecimento.

Diante da complexidade pertinente à solução adotada, naturalmente nem toda aplicação pode se comportar adequadamente neste cenário.

Configurações e exemplos de uso podem ser vistos nos tutoriais. Um trabalho completo, contendo extensa documentação sobre os conceitos pertinentes, pode ser encontrado aqui.