Perfis

O Integrate pode ser visualizado de três perspectivas diferentes, que variam de acordo com o perfil do usuário:

• desenvolvedor de mediador
• modelo genérico
• modelo estendido


• desenvolvedor JDBC


• usuário final da solução de integração

Desenvolvedor de mediador

O desenvolvedor de um mediador é o primeiro usuário natural do Integrate, posto que o mesmo se oferece como um framework que auxilia a confecção de soluções de integração, e, como tal, apresenta-se como uma estrutura semi-completa, que, para que possa ser utilizado, exige configuração prévia e a implemetação de algum código. Conforme descrito na apresentação do Integrate, o mediador a ser desenvolvido deve seguir a arquitetura de mediadores e tradutores (ver conceitos e referências aqui). De acordo com a arquitetura do Integrate, dois modelos podem ser implementados: o genérico e o estendido.

O modelo genérico permite a confecção de mediadores que disponibilizam alguma interface para seus usuários, independente do modelo de dados que utilize internamente, e apenas utiliza o Integrate para obter os dados das fontes de dados que se deseja integrar.

O modelo estendido atende cenários onde aplicações clientes existentes, que fazem requisições em JDBC e que não podem ser alteradas, necessitam de alguma solução de integração. Neste caso, o mediador presta serviço ao Integrate, gerando as subconsultas para as fonte de dados e integrando os dados retornados de cada uma delas em um esquema único (aquele conhecido pela aplicação que enviou a requisição).


Modelo genérico

O modelo genérico do Integrate possibilita utilização a partir de sua distribuição original, sem a necessidade inicial de implementação de classes extras (uma exceção, ver sobre "Desenvolvedor JDBC"). Neste modelo de solução, o Controlador disponibiliza serviços que podem ser utilizados pelo mediador, ou seja, as requisições partem do mediador para o Integrate.

Neste cenário, em tempo de execução, o mediador é responsável por receber as requisições dos seus usuários, requisitar os serviços do Integrate para obter os registros das fontes de dados desejadas, e, após providenciar a integração dos dados, entregar o resultado final ao seu usuário. Neste caso, a troca de mensagens entre a interface com seu usuário e o mediador é definida pela solução de integração desenvolvida. Já as mensagens entre o mediador e o Integrate são feitas de acordo com os retornos do métodos definidos no Controlador, bastando o mediador ser desenvolvido de acordo com estes retornos.

Durante o desenvolvimento do mediador, este pode utilizar os serviços de lookup disponibilizados pelo Integrate na definição do esquema global. Além de serviços que retornam coleções de objetos JDBC, o Integrate também pode retornar coleções de esquemas em formato XML Schema. Mais detalhes podem ser vistos na página sobre Lookup.


Modelo estendido

O modelo estendido atende cenários onde a aplicação cliente envia requisições JDBC e não pode ser alterada. O Integrate intercepta estas requisições e as repassa ao Controlador para que este obtenha os dados das fontes de dados, integre-os, e os devolva à aplicação cliente, tudo isso de maneira transparente, sem que esta perceba. Para a requisição em vários formatos distintos, e para a integração dos dados, o Controlador requisita serviços de um mediador, ou seja, as requisições partem do Integrate para o mediador.

Diferentemente do modelo anterior, o modelo estendido exige do desenvolvedor do mediador pelo menos a implementação da interface Mediator (ver também sobre "Desenvolvedor JDBC"). A implementação desta interface padroniza as chamadas feitas pelo Controlador e o formato do retorno destas requisições. A interface é exibida na figura abaixo:


Neste cenário, o mediador deve efetuar dois serviços principalmente. O primeiro é a geração de subconsultas. A partir de uma consulta SQL original (enviada pela aplicação cliente e interceptada pelo Integrate), o mediador deve gerar as subconsultas para as fontes de dados a serem integradas, já que deve conhecer os esquemas de todas as fontes de dados manipuladas pela solução e possuir conhecimento necessário para providenciar esta geração. De acordo com diversas ferramentas que inspiraram o Integrate, conhecimento semântico se faz necessário para manipular as diferenças entre os esquemas, provavelmente amparado por ontologias. Este serviço deve ser executado pelo método transformSQL(). O segundo é a integração da coleção dos resultados retornados das fontes de dados. Por conhecer os esquemas, deve ter inteligência para executar as devidas conversões de cada um dos formatos recebidos para o formato aguardado pela aplicação cliente, tarefa executada pelo método integrate(). Os métodos start() e stop() permitem ao mediador inicializar e finalizar algum recurso interno antes de disponibilizar os serviços acima, como por exemplo a inicialização de algum banco de dados interno ou a leitura de arquivos de configuração.


Arquivos de configuração do Integrate

Para ambos os o cenários, o Integrate exige a definição dos arquivos integrate-datasources.xml, do integration.xml e do integrate-config.xml. Para o cenário genérico, se o mediador for utilizar o serviço de lookup, será necessário configurar os arquivos *TypeConf.xml para cada uma das fontes de dados envolvidas.



Desenvolvedor JDBC

O modelo de dados do Integrate é o relacional, e, principalmente, para atender ao cenário estendido, trabalha usando JDBC. Portanto, o Integrate acessa as fontes de dados através de drivers JDBC reais, disponibilizado pelo fabricante do SGBD. O Integrate opera apenas como um proxy, e, através dos Tradutores, repassa as requisições para estes drivers e recebe os resultados obtidos por eles.

O Integrate disponibiliza Tradutores para fontes de dados relacionais utilizando JDBC (WrapperJDBC). Outro formato coberto pelo Integrate são os arquivos CSV. O Integrate oferece um driver JDBC que manipula este formato (WrapperCSV). Para mais detalhes, consulte aqui a página que comenta este driver.

Fontes de dados que não são relacionais ou que não dispõem de um driver JDBC exigem que um Tradutor seja implementado, para que esta possa ser acessada pelo Integrate. Esta implementação também deve ser feita caso o usuário opte em não usar os Tradutores disponibilizados pelo Integrate. Este  tradutor deve ser implementado antes  da utilização do Integrate, pois é através dele que o Integrate acessa as fontes de dados.

Se o mediador necessitar dos serviços de lookup, então é necessário também a implementação da interface Lookup.
Assim como os tradutores, o Integrate disponibiliza implementações desta interface para os formatos JDBC (LookupJDBC) e CSV (LookupCSV). Se o usuário do Integrate  optar por não utilizá-las ou se necessitar de implementações para outros formatos, deve implementar esta interface antes de utilizar o serviço.

Para que o serviço de lookup funcione corretamente, o driver JDBC da fonte de dados deve implementar a interface java.sql.DatabaseMetaData.


Esquemas em XML Schema

Um dos serviços disponibilizados pelo Integrate é a geração dos esquemas das fontes de dados em formato XML Schema. Para que este serviço funcione corretamente, o Integrate utiliza uma classe que faz os mapeamentos dos tipos de dados da fonte de dados para os tipos da especificação JDBC (outros detalhes, consulte sobre o arquivo *TypeConf.xml). Isto exige do desenvolvedor JDBC a implementação da interface DataSourceTypes, que gera este mapeamento.

O Integrate disponibiliza a implementação desta interface para as seguintes fontes de dados: MS-Access, Firebird, HSQLDB, MySQL e PostgreSQL, além de outra utilizada pelo driver JDBC para arquivos CVS. Para outros formatos e SGBDs, é necessário implementá-la.


Arquivos de configuração do Integrate

Como o Integrate é quem solicita os serviços a estas implementações, o desenvolvedor JDBC não necessita configurar nenhum arquivo durante a confecção de suas classes.



Usuário final da solução de integração

Para uma solução de integração que utilize o modelo genérico, com o mediador criado (além de possíveis implementações de tradutores e lookups), o usuário final pode utilizar o sistema fazendo requisições através da interface definida pelo mediador. Antes de iniciar as requisições, o Integrate exige que o usuário defina a configuração dos arquivos integrate-datasources.xml, integration.xml e integrate-config.xml. Para soluções que utilizem o modelo estendido, além da configuração dos arquivos citados, exige-se a alteração da URL de conexão utilizada pela aplicação cliente.



Última atualização: 28/06/2009