Middleware e Integração
O Problema da Heterogeneidade
e a Tecnologia de Middleware
Rodrigo Alves Costa
[email protected]
Roteiro

Heterogeneidade



Integração de Dados




Ilhas de Informação
Relevância
Arquitetura
Middleware
Projeto BDFint
Conclusões
Rodrigo Alves Costa
[email protected]
Uma cena comum...



Organizações crescem e seus centros
de custo incham de forma
independente
Dados distribuídos em linhas
funcionais e departamentais
Dados e serviços fragmentados!
Rodrigo Alves Costa
[email protected]
Ilhas de informação






Dados organizados e gerenciados em
diferentes SGBDs
De diferentes empresas
Em diferentes sistemas operacionais
Que usam diferentes protocolos de rede
Fontes de dados autônomas e
independentes
Heterogeneidade é a palavra!
Rodrigo Alves Costa
[email protected]
Relevância
• 40% do custo do projeto é Integração
• Sempre existem múltiplos Domínios de
Tecnologia
• Aplicações Distribuídas por Hardware
• Não existe Tecnologia única para tudo
Rodrigo Alves Costa
[email protected]
O que fazer?

Integração pode ocorrer em três pontos da
aplicação

Camadas de apresentação


Funcionalidades


Sistemas utilizam interfaces de diversas aplicações
distintas para acessar processos ou informações
Um sistema completa o outro: compartilhamento de
métodos e objetos (distribuídos)
Dados

Sistemas que compartilham informações
heterogêneas mas que têm objetivos comuns
Rodrigo Alves Costa
[email protected]
Integração de Dados




Extração de dados de
uma base
Possibilidade de
modificação de tais
dados
Atualização da base
Replicação em outras
fontes
Rodrigo Alves Costa
[email protected]
Integração de Dados

Potencialidades:




Combinar dados de múltiplas fontes para análise e tomada de
decisão
Prover múltiplas aplicações com acesso à leitura a uma fonte de
informações comum
Permitir que dados sejam extraídos de uma fonte e
reformatados e atualizados em outra
Prós e contras do modelo:




O modelo provê uma flexibilidade maior do que os outros
modelos
Integração rápida quando os BD são facilmente acessíveis
através de interfaces ou quando o middleware realiza a
integração de dados
Permite que dados sejam reutilizados através de outras
aplicações
Sensível a mudanças Rodrigo Alves Costa
[email protected]
Integração no mundo real
O desenvolvimento deve ser orientado ao serviço,
não aos dados!

SODA (Services Oriented Development of
Applications)
 Aplicações devem fazer o melhor uso possível da
lógica existente

Rodrigo Alves Costa
[email protected]
Integração no mundo real
Rodrigo Alves Costa
[email protected]
Exemplo típico...

Projeto MENTAS


Realização de um ambiente de
desenvolvimento orientado à engenharia
Análise comparativa de motores



Diversos sistemas locais desenvolvidos,
diversas fontes distintas, diversas
ferramentas de simulação desenvolvidas
As fontes na intranet da Mercedes-Benz
devem ser vistas como fontes locais
Necessidade de integração
Rodrigo Alves Costa
[email protected]
Arquitetura de Cinco Níveis

Proposto por Sheth e Larson (1995)
Visão 1
Camada de
Integração
Visão 2
Visão n
Middleware
MDC
Comunicação
Tradutor
Sistema
Local
Tradutor
Sistema
Local
Rodrigo Alves Costa
[email protected]
Tradutor
Sistema
Local
Middleware




Camada de software que tenta solucionar o
problema da heterogeneidade
Fornece uma alternativa para simplificar a
vida dos usuários
Visão transparente dos recursos e serviços
Facilita a comunicação de pedidos entre
componentes de software por meio de
interfaces definidas ou mensagens.
Rodrigo Alves Costa
[email protected]
Middleware – Tipos

São implementados sob diferentes perspectivas
Para definir a forma mais adequada de implementação,
deve-se realizar uma análise técnica da aplicação

Ambiente de distribuição, tipos de dados, propósito de
integração são alguns fatores a serem analisados
Chamadas de procedimentos remotos (Remote Procedure
Calls);





Para aplicações distribuídas que se integram no nível de
procedimento.
Levam em consideração fatores como existência remota de
informação
Exemplo: Projeto BDFint
Rodrigo Alves Costa
[email protected]
Middleware – Tipos

Middleware de acesso a banco de dados;



Para aplicações que acessam dados
distribuídos em arquivos ou bancos de
dados.
Integra no nível de dados e permite consultas
ou mudanças dos dados por meio da rede.
Exemplos são: ODBC e JDBC.
Rodrigo Alves Costa
[email protected]
Middleware – Tipos

Middleware orientado a mensagem (MOM);



Provê a habilidade de integrar aplicações por
meio do uso de mensagens.
Habilidade para criar, manipular, armazenar e
comunicar essas mensagens.
Exemplos: MQSeries da IBM, MQIntegrator
da IBM, SagaVista da Saga e Talarian da
Smart Sockets.
Rodrigo Alves Costa
[email protected]
Middleware – Tipos

Tecnologia de objetos distribuídos;



DOT (Distributed Object Technology),
estende o conceito da tecnologia orientada a
objeto para processamento distribuído.
Interfaces são desenvolvidas para aplicações
que fazem software parecer como objetos.
Exemplos: CORBA, COM e DCOM.
Rodrigo Alves Costa
[email protected]
Middleware – Tipos

Monitores de processamento de transação.




TPMs (Transaction Processing Monitors)
preservam a integridade da transação.
Suportam características como rollback,
refazer, armazenar histórico de erro e
replicação para eliminar pontos de falha.
Asseguram que uma transação mantenha as
propriedades ACID (Atomicidade,
Consistência, Isolamento e Durabilidade).
Exemplo: Tuxedo da BEA.
Rodrigo Alves Costa
[email protected]
Federação



Distribuição no nível dos Dados
Conectividade no nível de Middleware
Arquitetura única

Todos os participantes da integração são servidor e
cliente
Rodrigo Alves Costa
[email protected]
Projeto DWFint

Abrange:
Integração de dados e esquemas utilizando
Agentes
 Distribuição de dados heterogêneos
Desenvolvimento de uma ferramenta para
desenvolvedores e analistas




Suporte ao desenvolvimento integrado de software
Suporte de todo o ciclo de vida de um software



Modelagem de funcionalidades
Dados de aplicação
Códigos-Fonte
Rodrigo Alves Costa
[email protected]
Agentes no DWFint

Sociedade de Agentes


Troca de mensagens e automatização do processo de
integração
Arquitetura geral de agentes divida em 3 ambientes:
Ambiente de Manutenção da Federação
Ambiente Gerador da Federação
Ambiente Comum da Federação
Rodrigo Alves Costa
[email protected]
Analistas/
Desenvolvedores
Estado Atual

Ambiente Comum da Federação finalizado


Agentes e Wrappers controladores
Ambiente para a sociedade de agentes integrado com
troca de mensagens JADE
Rodrigo Alves Costa
[email protected]
Trabalhos futuros

Refinamento do middleware utilizado no
DWFint


Ex: XPERANTO (Wisconsin University)
Implementação dos ambientes de Manutenção
e Finalização do Ambiente Gerador
 Agente Interligador


Gera um Modelo de Dados Canônico integrado
(XMI MOF)
Agente Integrador

Integra os diversos MDCs de diversas fontes
em um MDC comum para visualização
Rodrigo Alves Costa
[email protected]
Conclusões

Diversas demandas para middleware





Multimídia, Mobilidade, Tempo real, ...
O desenvolvimento de sistemas distribuídos de
integração deve suportar transparência de plataformas
(portabilidade)
Os serviços de Middleware devem ser baseados em
gerência de dados, suportando transações
Os sistemas de integração e suas abordagens para
Middleware devem suportar a mudança de requisitos
funcionais e não funcionais
Sistemas de integração tendem a ser complexos, é
imprescindível a redução da complexidade para o
suporte de novos participantes
Rodrigo Alves Costa
[email protected]
Referências
[1] Sheth, A. P., Larson, J. A.. 1990. Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous
Databases. Computing Surveys, 22(3):183-236.
[2] Inmon, W. H.. 1997. Como construir um Data Warehouse. Rio de Janeiro: Editora Campus.
[3] Ciferri, C. D. A.; Sousa, F. F.. 2000. Distribuindo os dados do Data Warehouse In: Anais do XV Simpósio Brasileiro de Banco de
Dados. Pg. 346-360. PUC – RS: CEFET-PB, João Pessoa.
[4] Pedersen, T. B. et. al.. 2000. “Aspects of Data Modeling and Query Processing for Complex Multidimensional Data”. Ph.D.
Dissertation Faculdade de Engenharia e Ciências, Universidade de Aalborg, Alemanha.
[5] Batini, C., Lenzerini, M. and Navathe, S. B.. 1986. A Comparative Analysis of Methodologies for Database Schema Integration.
Database Systems Research and Development Center, Computer and Information Sciences Department, University of
Florida, Gainesville, Florida.
[6] Heuser, C. A.. 1998. Projeto de banco de dados. 1a. edição. Sagra Luzzatto. Pg. 11-39.
[7] Navathe, S. B. & Savasere, A.. 1996. A Schema Integration Facility using Object-Oriented Model, In: Object Oriented
Multidatabase Systems, Cap. 04, Prentice Hall.
[8] Spaccapietra, S. & Parent, C.. 1994. View Integration: A Step Forward in Solving Structural Conflicts, In: IEEE Trans. On Software
Eng., vol 6, No. 2.
[9] Salgado, A. C., Lóscio, B. F.. Integração de Dados na Web. In: Anais da XX Jornada de Atualização em Informática.
[10] Samos, José et. al.. 1998. Database Architecture for Data Warehousing: An Evolutionay Approach. In: Proceedings 9th
International Conference on Database and Expert Systems Applications, DEXA'98, Vienna, Austria, Springer LNCS 1460, pp.
746-756.
[11] Booch, G., Rumbaugh, J., Jacobson, I.. 1998. UML, guia do usuário, tradução de Fábio Freitas da Silva. Campus.
[12] Sun Microsystems, The source for Java (TM) Tecnology.
Disponível em: http://java.sun.com
[13] OMG XML Metadata Interchange (XMI) Specification, February 02, 2000.
Disponível em http://www.omg.org.
[14] Bray, T., Paoli, J. and Sperberg-McQueen, C. M.. 1998. Extensible Markup Language (XML) 1.0, World Wide Web Consortium.
Disponível em: http://www.w3.org/TR/REC-xml
Rodrigo Alves Costa
[email protected]
Referências
[15] Rational Software, “Rational Rose ®: Visual Modeling, UML, Object Oriented, Component-based”.
Disponível em: http://www.rational.com/products/rose/index.jsp
[16] Introduction to the Booch Method.
Disponível em: http://www.hsr.ch/div/Booch/BoochReference/
[17] Schildt, H.. 1996. C, completo e total, tradução de Roberto Carlos Mayer. São Paulo: Makron Books.
[18] Melo, R. N., Silva, S. D. da, Tanaka, A. K..1997. Bancos de dados em aplicações cliente/servidor. Rio de Janeiro: Infobook, 2a.
tiragem.
[19] Ribeiro, A. C., Florentini, A. C.. O padrão XMI: uma proposta para sua utilização em Bibliotecas Digitais, disponível em
http://genesis.nce.ufrj.br/dataware/
[20] Wood, L., Apparao, V., Byrne, S., Champion, M., Isaacs, S., Jacobs, I., Hors, A. L., Nicol, G., Robie, J., Sutor, R., Wilson, C.,
“Document Object Model (DOM) Level 1 Specification Version 1.0”. World Wide Web Consortium, 1998.
Disponível em: http://www.w3.org/TR/REC-DOM-Level-1
[21] SAX: The Simple API for XML.
Disponível em: http://www.saxproject.org/
[22] JDOM. Disponível em: http://www.jdom.org/
[23] Bryan, M.. 1988. SGML: An Author's Guide to the Standard Generalized Markup Language. Wokingham/Reading/New York:
Addison-Wesley.
[24] Grose, T.. 2001. XMI Application Framework. Disponível em: http://www.alphaworks.ibm.com/tech/xmiframework
[25] Kim, W.. 1995. Modern Databases Systems – Object Model, Interoperability, and Beyond. Addison-Wesley.
[26] Campos, V. V. de S., Souza, F. da F. de, Costa, R. A.. 2002. Integração de Fontes Heterogêneas de Dados utilizando a Web e
XMI. In: CSITeA’02. Foz do Iguaçu – Brazil.
Rodrigo Alves Costa
[email protected]