Um framework extensível para interoperabilidade dinâmica entre componentes distribuídos

Texto

(1)UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO. UM FRAMEWORK EXTENSÍVEL PARA INTEROPERABILIDADE DINÂMICA ENTRE COMPONENTES DISTRIBUÍDOS. Sidney Cassemiro do Nascimento. SÃO CRISTÓVÃO/ SE 2013.

(2) UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO. Sidney Cassemiro do Nascimento. UM FRAMEWORK EXTENSÍVEL PARA INTEROPERABILIDADE DINÂMICA ENTRE COMPONENTES DISTRIBUÍDOS. Dissertação apresentada ao Programa de PósGraduação em Ciência da Computação (PROCC) da Universidade Federal de Sergipe (UFS) como parte de requisito para obtenção do título de Mestre em Ciência da Computação.. Orientador: Prof. Dr. Tarcisio da Rocha. SÃO CRISTÓVÃO/ SE 2013.

(3) FICHA CATALOGRÁFICA ELABORADA PELA BIBLIOTECA CENTRAL UNIVERSIDADE FEDERAL DE SERGIPE. N244f. Nascimento, Sidney Cassemiro do Um framework extensível para interoperabilidade dinâmica entre componentes distribuídos / Sidney Cassemiro do Nascimento ; orientador Tarcisio da Rocha. – São Cristóvão, 2013. 131 f. : il.. Dissertação (mestrado em Ciência Universidade Federal de Sergipe, 2013.. da. Computação). –. 1. Middleware. 2. Componente de software. 3. Interconexão em rede. 4. Sistemas distribuídos. I. Rocha, Tarcisio da, orient. II. Título. CDU 004.4.

(4) Sidney Cassemiro do Nascimento. UM FRAMEWORK EXTENSÍVEL PARA INTEROPERABILIDADE DINÂMICA ENTRE COMPONENTES DISTRIBUÍDOS. Dissertação apresentada ao Programa de PósGraduação em Ciência da Computação (PROCC) da Universidade Federal de Sergipe (UFS) como parte de requisito para obtenção do título de Mestre em Ciência da Computação.. BANCA EXAMINADORA. Prof. Dr. Tarcisio da Rocha, Presidente Universidade Federal de Sergipe (UFS). Prof. Dr. Markus Endler, Membro Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio). Prof. Dr. Admilson de Ribamar Lima Ribeiro, Membro Universidade Federal de Sergipe (UFS).

(5) UM FRAMEWORK EXTENSÍVEL PARA INTEROPERABILIDADE DINÂMICA ENTRE COMPONENTES DISTRIBUÍDOS. Este exemplar corresponde à redação da Dissertação de Mestrado, sendo a defesa do mestrando Sidney Cassemiro do Nascimento para ser aprovada pela Banca examinadora.. São Cristóvão - SE, 29 de julho de 2013. ______________________________________ Prof. Dr. Tarcisio da Rocha Orientador. ______________________________________ Prof. Dr. Markus Endler Membro. ______________________________________ Prof. Dr. Admilson de Ribamar Lima Ribeiro Membro.

(6) Dedicatória Este trabalho é dedicado aos meus pais, Cassemiro e Yoshiko (in memoriam), e a minha amada esposa Norma, pelo amor incondicional, pelo apoio e por estarem sempre presentes.. i.

(7) Agradecimentos Primeiramente à Deus, por sempre me dar força diante das dificuldades e por ter conseguido dar mais um passo na caminhada de minha vida. À minha esposa Norma, que desde o primeiro momento sempre sonhou com este dia, pelo apoio, companheirismo e todo amor. Ao meu pai e minha mãe (in memorian), sempre presente em todos os momentos, com seu amor, apoio em cada etapa da minha vida e constante incentivo, expresso minha gratidão. Ao meu orientador, Prof. Dr. Tarcisio da Rocha, pela oportunidade, pelas contribuições e apoio, e principalmente, pela confiança depositada em mim durante todo esse trabalho. Aos meus familiares, em especial aos meus filhos e irmãs, por compartilharem comigo mais esta conquista, e à minha caçulinha Tarsila pelos momentos de descontração que me proporcionou. Ao Programa de Pós-Graduação em Ciência da Computação (PROCC) da Universidade Federal de Sergipe (UFS), que propiciou a aquisição de novos conhecimentos. Aos professores e colaboradores do PROCC da UFS, pelo apoio recebido durante o desenvolvimento desta pesquisa. Ao graduando Felipe Carvalho pelo apoio na implementação do framework proposto. Aos colegas do mestrado pela convivência e amizade durante todo o curso. Aos amigos da Ajusoft, pela amizade e companheirismo. À Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES) pelo aporte financeiro. Enfim, a todos aqueles com quem convivi durante esse tempo, em especial aos nossos amigos, pelas alegrias e palavras de estímulos.. ii.

(8) Resumo A popularização do middleware ocorrida nos últimos anos promoveu o surgimento de diferentes modelos tecnológicos. Devido a essa diversidade, a interoperabilidade entre diferentes modelos de componentes de software torna-se imprescindível para promover a integração entre partes heterogêneas. A heterogeneidade de middleware é um desafio para o desenvolvimento de sistemas distribuídos. Os problemas envolvidos com a interoperabilidade são tratados, em geral, pela adoção de sistemas de middleware capazes de intermediar e estabelecer a comunicação entre plataformas distintas. Nesse contexto, esta dissertação propõe, então, um framework padrão para interoperabilidade entre diferentes modelos de componentes de software. Para diminuir o acoplamento da plataforma proposta, foi implementado um framework distribuído com uma arquitetura extensível para suportar novos modelos de componentes e novos tipos de binding na forma de plugins independentes. O framework proposto possibilita a reutilização de componentes heterogêneos (i.e. OpenCOM e Fractal) na composição de sistemas distribuídos complexos, bem como a interoperabilidade entre componentes distribuídos de tais modelos. Para confirmar os benefícios em desempenho, usabilidade e extensão, está dissertação apresenta um estudo de caso de uma aplicação distribuída baseada no Servidor Web Comanche usando composição de componentes heterogêneos para avaliar a viabilidade do framework proposto.. iii.

(9) Abstract. The popularization of middleware occurred in recent years promoted the emergence of different technological models. Because of this diversity, interoperability between different models of software components becomes essential to promote the integration of heterogeneous parts. The heterogeneity of middleware is a challenge for the development of distributed systems. The problems involved with interoperability are treated in general by adopting middleware systems able to mediate and establish communication between different platforms. In this context, this dissertation proposes then a standard framework for interoperability between different models of software components. To decrease the coupling of the proposed platform, was implemented a distributed framework with a extensible architecture to support new component models and new types of binding as independent plugins. The proposed framework enables the reuse of heterogeneous components (i.e. OpenCOM and Fractal) in the composition of complex distributed systems, as well as interoperability between distributed components of such models. To confirm the benefits in performance, usability and extension, this dissertation presents a case study of a distributed application based on Comanche Web Server using composition of heterogeneous components to assess the feasibility of the proposed framework.. iv.

(10) Lista de Figuras 2.1. Arquitetura em Camadas da RMI (RUIXIAN, 2000). . . . . . . . . . . . . .. 2.2. Elementos do modelo de programação no nível do kernel (COULSON et al.,. 7. 2008). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 13. 2.3. Estrutura de um componente Fractal (BRUNETON et al., 2006). . . . . . . . .. 15. 2.4. Padrão de interoperabilidade utilizado pelo middleware tradicional (BLAIR et al.,. 2.5. 2011). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Padrão de interoperabilidade utilizado por plataformas de interoperabilidade (BLAIR et al., 2011). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2.6. 18. Padrão de interoperabilidade utilizado por pontes de software (BLAIR et al., 2011). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2.7. 17. 18. Padrão de interoperabilidade utilizado por soluções de interoperabilidade transparentes (BLAIR et al., 2011). . . . . . . . . . . . . . . . . . . . . . . .. 19. 2.8. Padrão de interoperabilidade utilizado por soluções de mobilidade lógica. .. 19. 3.1. Arquitetura do VCF (OBERLEITNER; GSCHWIND; JAZAYERI, 2003). . . . . .. 22. 3.2. Componentes de diferentes modelos cooperam no SCIRun2 (PARKER et al., 2006). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3.3. 25. Interoperabilidade entre os componentes CCA e Fractal (MALAWSKI et al., 2007). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 26. 3.4. Arquitetura do PBJIM (WU; TAO; XU, 2007). . . . . . . . . . . . . . . . . .. 27. 3.5. Camada de integração MGDA (VENTICINQUE et al., 2007). . . . . . . . . .. 29. 3.6. A abordagem baseada em geração de código Fraclet (ROUVOY; MERLE, 2009). 30. 4.1. Arquitetura dos componentes da aplicação OpenCOM. . . . . . . . . . . .. v. 35.

(11) 4.2. Organização dos componentes distribuídos em uma rede utilizados em uma aplicação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4.3. 36. Organização dos componentes de diferentes modelos distribuídos em uma rede. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 38. 4.4. Arquitetura geral do framework InteropFrame. . . . . . . . . . . . . . . . .. 40. 4.5. Arquitetura do framework distribuído InteropFrame. . . . . . . . . . . . . .. 41. 4.6. Diagrama dos elementos do framework distribuído. . . . . . . . . . . . . .. 42. 5.1. Arquitetura do Servidor Web Comanche . . . . . . . . . . . . . . . . . . .. 45. 5.2. Arquitetura do Servidor Web Comanche com Distribuição de Parte dos Serviços 46. 5.3. Arquitetura do Servidor Web Comanche com componentes distribuídos . .. 5.4. Arquitetura do Servidor Web Comanche com componentes distribuídos no. 48. framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 49. 6.1. Resultados do worktime relacionado a Fractal com Fractal . . . . . . . . .. 53. 6.2. Médias do worktime relacionado a Fractal com Fractal . . . . . . . . . . .. 53. 6.3. Resultados do workload relacionado a Fractal com Fractal . . . . . . . . .. 54. 6.4. Médias do workload relacionado a Fractal com Fractal . . . . . . . . . . .. 54. 6.5. Resultados do worktime relacionado a OpenCOM com OpenCOM . . . . .. 55. 6.6. Médias do worktime relacionado a OpenCOM com OpenCOM . . . . . . .. 55. 6.7. Resultados do workload relacionado a OpenCOM com OpenCOM . . . . .. 56. 6.8. Médias do workload relacionado a OpenCOM com OpenCOM . . . . . . .. 56. 6.9. Resultados do worktime relacionado a OpenCOM com Fractal . . . . . . .. 57. 6.10 Médias do worktime relacionado a OpenCOM com Fractal . . . . . . . . .. 58. 6.11 Resultados do workload relacionado a OpenCOM com Fractal . . . . . . .. 58. 6.12 Médias do workload relacionado a OpenCOM com Fractal . . . . . . . . .. 59. 6.13 Comparativo das médias do worktime . . . . . . . . . . . . . . . . . . . .. 59. 6.14 Comparativo das médias do workload . . . . . . . . . . . . . . . . . . . .. 60. 6.15 Resultados do worktime relacionados à complexidade da interface . . . . .. 61. 6.16 Médias do worktime relacionados à complexidade da interface . . . . . . .. 61. 6.17 Resultados do workload relacionados à complexidade da interface . . . . .. 62. 6.18 Médias do workload relacionados à complexidade da interface . . . . . . .. 62. vi.

(12) 6.19 Arquivos do InteropFrame que devem ser adicionados ao Build Path do projeto 63. vii.

(13) Lista de Tabelas 3.1. Estratégias utilizadas por modelos para interoperabilidade. . . . . . . . . .. viii. 31.

(14) Lista de Siglas ACL - Agent Communication Language ADL - Architecture Description Languages AM - Agentes Móveis CBSE - Component-Based Software Engineering CCA - Common Component Architecture CD - Configurador Distribuído CERNET - China Education e Research Network CGSP - ChinaGrid Platform Support CSGrid - Chinese e-Science Grid COM - Microsoft’s Component Object Model CORBA - Common Object Request Broker Architecture DG-ADAJ - Desktop Grid Adaptive Distributed Applications in Java EJB - Enterprise JavaBeans IDE - Integrated Development Environment GB - Geradores de Bindings GC - Gerador de Código GCM - Grid Component Model GRS - General Running Service HTTP - HyperText Transfer Protocol ISGC - International Symposium on Grids and Clouds JADE - Java Agent DEvelopment Framework JIT - Just-In-Time JSE - Java Platform, Standard Edition JUDE - Java and UML Developer Environment ix.

(15) MAGDA - Mobile AGents Distributed Applications MC - Montador de Código MDA - Model-driven Architecture OASIS - Organization for the Advancement of Structured Information Standards P2P - Peer-to-Peer PBJIM - Plugin-based Job Interoperation Mechanism PMC - Plugins de Modelos de Componentes RC - Repositório de Componentes REST - REpresentational State Transfer RMI - Remote Method Invocation SCA - Service Component Architecture SOAP - Simple Object Access Protocol SSO - Single Sign-On UDDI - Universal Description, Discovery and Integration UML - Unified Modeling Language XML - Extensible Markup Language WSDL - Web Services Definition Language WSRF - Web Service Resource Framework WWW - World Wide Web W3C - World Wide Web Consortium. x.

(16) Sumário 1. 2. 3. Introdução. 1. 1.1. Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1. 1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3. 1.3. Contribuições desta Dissertação . . . . . . . . . . . . . . . . . . . . . . .. 4. 1.4. Organização da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . .. 4. Conceitos Básicos. 6. 2.1. Invocação Remota de Métodos . . . . . . . . . . . . . . . . . . . . . . . .. 6. 2.2. Serviços Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 8. 2.3. Reflexão Computacional . . . . . . . . . . . . . . . . . . . . . . . . . . .. 9. 2.4. Geração Automática de Código . . . . . . . . . . . . . . . . . . . . . . . .. 10. 2.5. Componentes Distribuídos . . . . . . . . . . . . . . . . . . . . . . . . . .. 10. 2.5.1. Middleware Baseados em Componentes . . . . . . . . . . . . . . .. 11. 2.5.2. O Modelo OpenCOM . . . . . . . . . . . . . . . . . . . . . . . .. 12. 2.5.3. O Modelo Fractal . . . . . . . . . . . . . . . . . . . . . . . . . . .. 14. 2.6. Soluções de Middleware para Interoperabilidade . . . . . . . . . . . . . . .. 16. 2.7. Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 20. Trabalhos Relacionados. 21. 3.1. Vienna Component Framework . . . . . . . . . . . . . . . . . . . . . . . .. 21. 3.2. Meta-framework para padrões de componentes . . . . . . . . . . . . . . .. 22. 3.3. SCIRun2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 23. 3.4. Interoperabilidade entre modelos de componentes em grade . . . . . . . . .. 24. 3.5. PBJIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 26. xi.

(17) 3.6. 4. tes móveis em grade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 27. 3.7. Fraclet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 29. 3.8. Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 30. Solução Proposta: InteropFrame. 34. 4.1. Aplicação distribuída . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 34. 4.1.1. Exemplo de Aplicação OpenCOM . . . . . . . . . . . . . . . . . .. 34. 4.1.2. Exemplo de Aplicação OpenCOM distribuída . . . . . . . . . . . .. 36. 4.1.3. Exemplo de um Cenário com Componentes Distribuídos Heterogêneos 37. 4.2. 5. Integração de componentes distribuídos e modelos de programação de agen-. O InteropFrame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 39. 4.2.1. Descrição Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 39. 4.2.2. Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 40. Cenário Proposto para Avaliação. 44. 5.1. Web Server Comanche . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 44. 5.2. Servidor Web Comanche Com Componentes Distribuídos Heterogêneos . .. 46. 5.3. Implementação do Servidor Web Comanche com Partes Distribuídas Usando o InteropFrame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 6. 48. Resultados Experimentais. 51. 6.1. Avaliação de Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . .. 51. 6.1.1. Ambiente de execução . . . . . . . . . . . . . . . . . . . . . . . .. 52. 6.1.2. Experimento: Fractal com Fractal . . . . . . . . . . . . . . . . . .. 52. 6.1.3. Experimento: OpenCOM com OpenCOM . . . . . . . . . . . . . .. 54. 6.1.4. Experimento: OpenCOM com Fractal . . . . . . . . . . . . . . . .. 56. 6.1.5. Comparativo dos Experimentos . . . . . . . . . . . . . . . . . . .. 58. 6.1.6. Influência da Complexidade da Interface no Desempenho . . . . . .. 59. Avaliação de Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . .. 62. 6.2.1. Instalação do InteropFrame . . . . . . . . . . . . . . . . . . . . . .. 62. 6.2.2. Esforço de Desenvolvimento . . . . . . . . . . . . . . . . . . . . .. 63. 6.2.3. Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 66. 6.2. xii.

(18) 6.3. 6.4. 7. Avaliação de Extensibilidade . . . . . . . . . . . . . . . . . . . . . . . . .. 67. 6.3.1. Extensão para suportar outros modelos de componentes . . . . . .. 67. Extensão para suportar outros mecanismos de comunicação . . . . . . . . .. 69. 6.4.1. 70. Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Conclusões e Trabalhos Futuros. 71. 7.1. Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 71. 7.2. Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 72. Referências. 73. A Implementação do Exemplo de Aplicação OpenCOM distribuída. 79. A.1 Implementação do Componente Factorial . . . . . . . . . . . . . . . . . .. 79. A.2 Implementação do Componente Multiplication . . . . . . . . . . . . . . .. 80. A.3 Implementação do Componente Calculator . . . . . . . . . . . . . . . . .. 83. A.4 Implementação do Componente ProxyFactorial . . . . . . . . . . . . . . .. 86. A.5 Implementação do Componente SkeletonFactorialImpl . . . . . . . . . . .. 87. A.6 Implementação do Componente SkeletonFactorial . . . . . . . . . . . . . .. 88. A.7 O Programa Servidor AppSkeletonServer . . . . . . . . . . . . . . . . . . .. 89. A.8 O Programa Cliente AppCalculatorScientific . . . . . . . . . . . . . . . . .. 91. B Manual de uso e Documentação. 94. B.1 InteropFrame: Manual de uso e Documentação . . . . . . . . . . . . . . .. xiii. 94.

(19) Capítulo 1 Introdução Esta introdução inicia apresentando a motivação desta dissertação. Em seguida, serão apresentados os objetivos deste trabalho, as principais contribuições e a estrutura deste documento.. 1.1. Motivação. A necessidade de soluções para o suporte à interação entre as partes de aplicações distribuídas fez surgir os middlewares. O termo middleware se refere a uma camada de software que fornece uma abstração de programação para ajudar no desenvolvimento de aplicações distribuídas, assim como o mascaramento da heterogeneidade das redes, do hardware, de sistemas operacionais e linguagens de programação subjacentes (COULOURIS; DOLLIMORE; KINDBERG,. 2007). As tecnologias de middleware simplificam o desenvolvimento de aplica-. ções distribuídas e fornecem uma infraestrutura de software bem integrada e em rede. A popularização de sistemas de middleware ocorrida nos últimos anos promoveu o surgimento de diferentes modelos tecnológicos, como por exemplo, paradigmas de middleware e plataformas para ambientes distribuídos contemporâneos. Devido a essa diversidade, a interoperabilidade entre modelos de componentes torna-se imprescindível para promover a integração entre partes heterogêneas. Desta forma, torna-se interessante a busca de soluções que facilitem a integração de componentes legados, de modo a permitir a interoperabilidade entre as diversas soluções já disponibilizadas. A heterogeneidade (isto é, variedade e diferença) de modelos de componentes para os 1.

(20) 1.1 Motivação. 2. mais diversos domínios de aplicações é um desafio para o desenvolvimento de sistemas distribuídos. Um desses desafios é quando as partes que devem compor esses sistemas são desenvolvidas em plataformas que usam modelos de componentes diferentes. Essa falta de padronização limita a reutilização e a composição de componentes. Essas plataformas devem convergir através do emprego de padrões abertos para permitir a interoperabilidade entre diferentes modelos de componentes. De acordo com (EMMERICH, 2000), é desejável que um middleware seja interoperável com outras implementações do mesmo middleware ou até mesmo diferentes tipos de middleware, a fim de facilitar a construção de sistemas distribuídos. Existem muitos componentes distribuídos prontos, implementados em diferentes plataformas de middleware. Além disso, novos componentes podem ser desenvolvidos e reutilizados em conjunto, sem se preocupar onde o componente está sendo executado e nem em que plataforma foi desenvolvido, para facilitar o desenvolvimento de aplicações distribuídas. Apesar de aparentar se uma abordagem custosa, a mesma pode ser menos dispendiosa do que recodificar os componentes legados. A implementação de interoperabilidade entre componentes de modelos distintos como parte das aplicações sem o uso de um framework pode aumentar consideravelmente a complexidade no desenvolvimento das mesmas. Isso ocorre porque, além de lidar com os negócios da aplicação, os desenvolvedores teriam que criar soluções para promover a interoperabilidade entre as partes heterogêneas. Uma alternativa a essa abordagem é a adoção de um framework que faça uso da abstração da complexidade da programação distribuída em uma camada de software separada e reutilizável. Esse framework encapsularia as soluções necessárias para os problemas da interoperabilidade, tornando-os transparentes aos desenvolvedores. Desta forma, o desenvolvimento de sistemas distribuídos compostos por componentes implementados em diferentes plataformas de componentes seria acelerado e simplificado. Recentemente, pesquisadores nas subáreas de middleware e interoperabilidade foram convidados a submeter trabalhos ao International Symposium on Grids and Clouds (ISGC) 2013 reportando contribuições de pesquisa inovadoras, projetos em andamento e resultados experimentais relacionados a soluções de middleware interoperáveis. As tecnologias de middleware hoje devem convergir através do emprego de padrões abertos para permitir a.

(21) 1.2 Objetivos. 3. interoperabilidade entre tecnologias e infraestruturas ou a reutilização de componentes de outras tecnologias - convergência, colaboração e inovação são e devem ser um elemento chave deste esforço (ACADEMIA SINICA GRID COMPUTING CENTRE (ASGC), 2012). Segundo (STAHL; VOLTER, 2006), alcançar a interoperabilidade entre os sistemas desenvolvidos de forma independente tem sido um dos objetivos fundamentais de pesquisadores e desenvolvedores de middleware. Com relação às barreiras para a interoperabilidade, (BLAIR et al., 2011) apresentou uma classificação das dimensões da heterogeneidade: (i) os formatos de dados e conteúdo; (ii) os protocolos de aplicação; (iii) os protocolos de middleware e (iv) as propriedades não funcionais. Os problemas envolvidos com a interoperabilidade são tratados, em geral, pela adoção de sistemas de middleware capazes de intermediar e estabelecer a comunicação entre plataformas distintas. Dentre esses problemas, podem-se destacar: (i) os técnicos: onde os componentes dos sistemas não conseguem interagir devido às diferenças de padrões de comunicação, transporte, armazenamento e representação de comunicação e (ii) os semânticos, ocasionados pela diversidade de representação da informação transmitida. Neste trabalho, o foco principal é com um dos muitos problemas de interoperabilidade: a ligação (binding) entre componentes remotos de modelos heterogêneos. Entende-se, neste estudo, o binding como uma vinculação entre dois componentes a partir do qual eles poderão se comunicar. Um framework é uma abstração que fornece um grau muito elevado de reutilização dos componentes de software. Desta forma, um framework para interoperabilidade entre diferentes modelos de componentes de software pode ser usado, como padrão aberto, para promover flexibilidade e padronização no desenvolvimento de aplicações distribuídas, permitindo reutilização e composição de componentes desenvolvidos em modelos de programação distribuída distintos.. 1.2. Objetivos. O presente trabalho tem como objetivo geral propor um framework padrão para interoperabilidade entre diferentes modelos de componentes de software. Objetivos Específicos.

(22) 1.3 Contribuições desta Dissertação. 4. Para alcançar o objetivo primário anterior, alguns objetivos específicos têm que ser atendidos, a saber: • Especificar uma arquitetura de um framework para interoperabilidade entre diferentes modelos de componentes de software para a programação distribuída. Este framework deve ser capaz de ser extendido dinamicamente para dar suporte a novos modelos de componentes; • Implementar a arquitetura proposta com os requisitos necessários para permitir que seja usado por desenvolvedores na construção de aplicações distribuídas, incluindo a habilidade de lidar com reutilização e composição de componentes desenvolvidos em modelos de programação distribuída distintos; • Testar o framework proposto com diferentes cenários.. 1.3. Contribuições desta Dissertação. As principais contribuições desta dissertação são: • A definição de uma arquitetura de um framework extensível e flexível para interoperabilidade dinâmica entre diferentes modelos de componentes de software para a programação distribuída; • A disponibilização de um framework padrão para auxiliar desenvolvedores de software na tarefa de implementação de aplicações distribuídas com modelos de componentes distintos; • A disponibilização dos códigos-fonte do projeto do framework padrão para a comunidade acadêmica e a indústria para que novas pesquisas possam tomar esse projeto como base.. 1.4. Organização da Dissertação. As demais partes desta dissertação de mestrado estão organizadas da seguinte forma:.

(23) 1.4 Organização da Dissertação. 5. • O capítulo 2 apresenta a fundamentação teórica necessária para nortear o entendimento sobre o tema abordado na dissertação; • O capítulo 3 apresenta alguns trabalhos acadêmicos relacionados à interoperabilidade entre modelos de componentes de software distintos; • O capítulo 4 apresenta a solução proposta para o problema em questão; • O capítulo 5 descreve o cenário proposto para a avaliação que foi conduzida para determinar a eficácia do framework proposto; • O capítulo 6 apresenta resultados experimentais de testes de desempenho que foram aplicados à plataforma. • E finalmente, o capítulo 7 apresenta as considerações finais do documento e possíveis desdobramentos para pesquisas futuras..

(24) Capítulo 2 Conceitos Básicos A fim de fundamentar o projeto e implementação do framework proposto, será apresentado neste capítulo o embasamento teórico que foi utilizado no decorrer dessa pesquisa. Muitos desses fundamentos estão relacionados e foram usados na construção da solução proposta. Inicialmente foram explorados os conceitos de invocação remota de métodos, serviços web, reflexão computacional, geração automática de código, componentes distribuídos, entre outros. Em seguida, será apresentada uma discussão geral sobre a relação entre os conceitos básicos e a solução proposta neste trabalho.. 2.1. Invocação Remota de Métodos. Segundo Coulouris, Dollimore e Kindberg (2007), uma das formas de se estabelecer comunicação entre objetos remotos distribuídos é através de invocação a método remoto. Os objetos que podem receber invocações a métodos remotos são chamados de objetos remotos e implementam uma interface remota. A diferença entre objetos remotos e objetos locais é que os objetos remotos estão localizados em máquinas virtuais diferentes (HAROLD, 2004). Devido à possibilidade de falhas isoladas tanto nos objetos invocadores quanto nos invocados, as invocações remotas têm semânticas diferentes das invocações a métodos locais. Entretanto, elas podem ser feitas de modo a serem bastante semelhantes às invocações locais, mas transparência total não é necessariamente desejável. De acordo com Reilly e Reilly (2002), cada serviço RMI é definido por uma interface, que descreve os métodos dos objetos que podem ser executados remotamente. Esta inter6.

(25) 2.1 Invocação Remota de Métodos. 7. face deve ser compartilhada por todos os desenvolvedores que escrevem software para esse serviço - que funciona como um modelo para aplicações que irão utilizar e fornecer implementações do serviço. Várias implementações da interface podem ser criadas, e os desenvolvedores não precisam estar cientes de que a implementação está sendo usada e nem aonde está localizada. A arquitetura da RMI consiste de quatro camadas (RUIXIAN, 2000), conforme mostrada na Figura 2.1:. Figura 2.1: Arquitetura em Camadas da RMI (RUIXIAN, 2000). A primeira camada é a de aplicação, onde se encontram as implementações das aplicações clientes e servidores. O stub e o skeleton, representam o lado cliente e servidor, respectivamente, e estão localizados na segunda camada proxy - que é responsável por todas as chamadas para o objeto remoto, empacotamento dos parâmetros (marshalling) e retorno do objeto. A terceira camada é a de referência remota que corresponde a uma abstração entre a camada proxy e a quarta e última camada de transporte. A aplicação cliente não interage diretamente com o servidor. Na realidade, a aplicação cliente interage apenas com o objeto stub - que corresponde ao proxy do lado cliente para o objeto remoto e a interface de aplicação para o objeto remoto. O stub passa a chamada para o objeto remoto junto à camada de referência remota no cliente, que repassa para a camada de transporte. Em seguida, a camada de transporte no cliente passa os dados através da rede para a camada de transporte no lado servidor que se comunica com a camada de referência remota no servidor, que repassa a chamada para o skeleton - que corresponde ao proxy do.

(26) 8. 2.2 Serviços Web. lado servidor para os objetos remotos e têm comportamento semelhante de uma classe stub. O skeleton se comunica com o próprio servidor que faz a chamada do método para o objeto remoto. No outro sentido (servidor-cliente), o fluxo é simplesmente inverso. Na plataforma Java, o mecanismo padrão para dar suporte a invocação de métodos remotos é a RMI (Remote Method Invocation). Em particular, ela permite que os objetos invoquem métodos em objetos remotos usando a mesma sintaxe das invocações locais (COULOURIS; DOLLIMORE; KINDBERG,. 2007). Na RMI Java, supõe-se que os parâmetros de um. método são parâmetros de entrada e o resultado de um método é um único parâmetro de saída. Ela permite a passagem de qualquer objeto Java serializável em invocações de métodos definidos na interface do componente. Todos os tipos primitivos e objetos remotos são serializáveis. A verificação de tipo se aplica igualmente às invocações remotas e locais. O código para empacotar e desempacotar argumentos e para enviar mensagens de requisição e resposta pode ser gerado automaticamente por um compilador de interface, a partir da definição da interface remota.. 2.2. Serviços Web. As interfaces de serviços disponibilizadas na WWW (World Wide Web) para comunicação entre aplicações são denominadas de serviços web (web services) (W3C, 2012d). Segundo Deitel e Deitel (2010), um serviço web é um componente de software armazenado em um computador que pode ser acessado por um aplicativo (ou outro componente de software) em outro computador por uma rede. Um serviço web fornece uma interface de serviço que permite aos clientes interagirem com servidores de uma maneira mais geral do que acontece com os navegadores web (COULOURIS; DOLLIMORE; KINDBERG, 2007). Um cliente normalmente acessa as operações de um serviço web por meio de solicitações e respostas formatadas em XML (Extensible Markup Language) (W3C, 2012a) - um formato textual usado para representação e empacotamento de dados - e, normalmente, transmitidas por HTTP (HyperText Transfer Protocol) (W3C, 2012b) - um protocolo para transportar mensagens entre clientes e servidores pela Internet. Atualmente, existem duas arquiteturas de serviços web (PETERSON; DAVIE, 2007): • SOAP (Simple Object Access Protocol) (W3C, 2012c) - baseada em dois frameworks.

(27) 2.3 Reflexão Computacional. 9. que foram padronizados pelo W3C (World Wide Web Consortium) denominados de WSDL (Web Services Definition Language) (W3C, 2012e) - um framework para especificação de protocolos de aplicação (interfaces) e SOAP - um framework para especificação de protocolos de transporte (PETERSON; DAVIE, 2007). O SOAP é um protocolo independente de plataforma que utiliza a XML para fazer chamadas de procedimento remoto, geralmente via HTTP (DEITEL; DEITEL, 2010). Serviços web podem ser publicados através de UDDI (Universal Description, Discovery and Integration) (OASIS, 2012) - um framework de plataforma independente para descrever e integrar os serviços de negócios usando a Internet. A UDDI é baseada na arquitetura SOAP. • REST (REpresentational State Transfer) - baseada na arquitetura Web com algumas extensões para suportar serviços web (PETERSON; DAVIE, 2007). A REST fornece uma arquitetura de rede que utiliza os mecanismos de solicitação/resposta tradicionais da Web como solicitações GET e POST (DEITEL; DEITEL, 2010). Os serviços web são considerados como recursos identificados por URIs (Uniform Resource Identifier) e acessados via HTTP (PETERSON; DAVIE, 2007). A URI é uma cadeia de caracteres que é usada para identificar um recurso, onde um recurso pode ser qualquer coisa que tenha uma identificação, tal como um documento, uma imagem ou um serviço (PETERSON; DAVIE,. 2.3. 2007).. Reflexão Computacional. De acordo com Buzato, Rubira e Lisboa (1997), a reflexão é definida como sendo a capacidade de observar e manipular o comportamento de um sistema computacional através de um processo chamado de reificação. Neste contexto, a reflexão pode ser vista como a capacidade que um sistema pode ter de "voltar a si próprio" a sua computação, ou seja, a capacidade de conhecer, analisar e alterar a sua própria representação (ROCHA, 2008). Conforme Maes (1987), um sistema reflexivo incorpora estruturas que representam aspectos dele mesmo. Segundo o OW2 (2004), a reflexão é a capacidade de um componente (vista como um programa) para manipular os dados como as entidades que representam o seu estado de execução durante a sua própria execução. Esta manipulação pode assumir duas formas (OW2, 2004): (i) introspecção - a capacidade de um componente para observar e raciocinar sobre o.

(28) 2.4 Geração Automática de Código. 10. seu estado de sua própria execução e (ii) intercessão - a capacidade de um componente para modificar o seu estado de sua própria execução, ou a de alterar a sua própria interpretação ou semântica. A reflexão computacional tem sido usada como recurso para a criação de middleware aberto capaz de ser personalizado para diferentes requisitos de acordo com a função que o middleware está resolvendo. Desta forma, a reflexão pode ser utilizada para adaptar um determinado middleware dinamicamente à diferentes situações em tempo de execução. Sem o uso da reflexão, o middleware teria de ser modificado e recompilado para suportar requisitos heterogêneos.. 2.4. Geração Automática de Código. Um gerador de código é um sistema desenvolvido para criar automaticamente código fonte de alto nível em linguagens de programação como .NET, C++, C#, Java e outros (ADAMATII, 2006). A geração automática de código ajuda a aumentar a eficácia da produção de software complexo, reduzindo o custo e tempo associado com o esforço de codificação (KORNECKI; JOHRI,. 2006).. Algumas plataformas utilizam mecanismos ou ferramentas para automação de geração de código para melhorar a produtividade e eficiência nos processos de desenvolvimento de software, como por exemplo, O MDA (Model-driven Architecture) (OMG, 2012) - que é uma abordagem para desenvolvimento de sistemas dirigido a modelos e o Acceleo (ACCELEO, 2012) - que é um plugin do Eclipse que baseado em MDA permite a geração automática de código a partir de modelos, como por exemplo, um modelo UML ou um metamodelo definido pelo usuário.. 2.5. Componentes Distribuídos. Definido de forma geral, componente é um bloco construtivo modular para software (PRESSMAN,. 2010). Mais formalmente, (SZYPERSKI, 1997) um componente é uma unidade de. composição com interfaces especificadas contratualmente e com dependências de contexto explícitas. Um componente de software pode ser implementado de forma independente ou.

(29) 2.5 Componentes Distribuídos. 11. através de composição de componentes de terceiros. Um modelo de componentes define um conjunto de normas para a implementação do componente, atribuição de nomes, interoperabilidade, customização, composição, evolução e implantação (CRNKOVIC; STAFFORD; SZYPERSKI, 2011). Uma interface é um contrato que especifica a funcionalidade do componente. De acordo com Crnkovic, Stafford e Szyperski (2011), uma interface de componente define um conjunto de propriedades funcionais de um componente. A especificação estrutural de uma interface de componente relaciona os métodos providos e os requeridos, e a associação destes a cada canal de comunicação da interface. As interfaces podem ser distinguidas de acordo o papel (SCHREINER, 2009): (i) Interfaces providas - que expõem os serviços oferecidos no componente e (ii) Interfaces requeridas (receptáculos) - que representam os serviços que o componente requer de outros componentes.. 2.5.1. Middleware Baseados em Componentes. As soluções baseadas em componentes foram desenvolvidas para superar uma série de limitações que foram observadas no desenvolvimento de aplicações que trabalham com middleware de objetos distribuídos, como por exemplo, dependências implícitas de objetos, complexidade de programação, falta de separação de interesses de distribuição e falta suporte para a implantação de configurações de objetos (COULOURIS et al., 2011). Segundo Coulouris et al. (2011), a principal característica dos objetos distribuídos é que eles permitem a adoção de um modelo de programação orientada a objetos para o desenvolvimento de sistemas distribuídos e, com isso, ocultam a complexidade subjacente da programação distribuída. Nesta abordagem, as entidades que se comunicam são representadas por objetos distribuídos. Os objetos se comunicam através de invocação remota de métodos, eventos distribuídos ou outro paradigma de comunicação, por exemplo, serviços web. Diversas plataformas de middleware que permitem a implementação de sistemas baseados em componentes estão disponíveis, como por exemplo, o EJB (Enterprise JavaBeans), o CORBA Component Model, o COM (Component Object Model), o .NET Framework, o OpenCOM e o Fractal Component Model. Dentre as plataformas a serem suportadas pelo framework proposto está as tecnologias OpenCOM e Fractal, apresentadas nas próximas.

(30) 2.5 Componentes Distribuídos. 12. subseções. As mesmas foram escolhidas, devido as características suportadas, como por exemplo, baixo peso, reflexão computacional e reconfiguração dinâmica.. 2.5.2. O Modelo OpenCOM. O OpenCOM é um modelo de componentes de baixo peso projetado para o desenvolvimento de middlewares em dispositivos de computação com poucos recursos (processamento, memória, armazenamento). Além de ser um modelo de baixo peso, o OpenCOM provê a capacidade de reconfiguração dinâmica de middlewares tanto no domínio estrutural quanto no comportamental (ROCHA, 2008). O OpenCOM é fundamentado em três tecnologias: • Componentes - O modelo permite a especificação da estrutura de sistemas através do uso de componentes e conexões entre componentes (ROCHA, 2008). Cada componente pode possuir um conjunto de interfaces (ou interfaces providas) - através das quais o componente exporta seus serviços - e um conjunto de receptáculos (ou interfaces requeridas) - através dos quais o componente requisita serviços de outros componentes; • Reflexão computacional - O modelo foi projetado para dar apoio à reflexão computacional - que é a capacidade que um sistema tem de observar sua própria representação/estrutura ou até mesmo modificá-la; • Frameworks de componentes - O modelo também permite a criação de frameworks de componentes. Um framework de componentes é definido no OpenCOM como uma subarquitetura de componentes sobre a qual pode ser checado um conjunto de propriedades arquiteturais desejadas (ROCHA, 2008). Essa subarquitetura também pode ser vista como um componente complexo que é composto de outros subcomponentes interconectados. Cada componente OpenCOM implementa quatro interfaces (GRACE, 2007): • ILifeCycle - fornece operações de inicialização e finalização que são chamadas quando um componente é criado ou destruído, ou seja, define ações que devem ser tomadas no início e no final do ciclo de vida do componente;.

(31) 2.5 Componentes Distribuídos. 13. • IConnections (opcional) - oferece métodos para modificar as interfaces ligadas aos receptáculos de um componente. Esta interface deve ser implementada por todos os componentes que possuem receptáculo; • IMetaInterface - suporta inspeção dos tipos de interfaces e receptáculos declarados pelo componente; • IUnknown - é equivalente à interface do mesmo nome no Microsoft COM, isto é, ele é usado para obter a referência para a interface solicitada na instância do componente. Uma visão de alto nível de um exemplo dos elementos do modelo de programação baseado em componentes OpenCOM é ilustrado na Figura 2.2. Ela mostra um componente (Client) que possui um receptáculo conectado à interface provida de outro componente (Server).. Figura 2.2: Elementos do modelo de programação no nível do kernel (COULSON et al., 2008). O ambiente de execução do OpenCOM permite a execução de sistemas baseados em componentes localizados na mesma máquina (ROCHA, 2008). Esse ambiente é composto pelo OpenCOM Runtime e o System Graph. OpenCOM implanta um kernel de tempo de execução (OpenCOM Runtime) padrão que gerencia a criação e a exclusão de componentes, e age de acordo com solicitações para conexão e desconexão dos componentes (GRACE, 2007), processando e armazenando informações sobre sistemas implementados com componentes OpenCOM (ROCHA, 2008). Além disso, um grafo (System Graph) dos componentes atualmente em uso é mantido para apoiar a introspecção de uma estrutura da plataforma (GRACE, 2007), onde os componentes são mantidos e executados (ROCHA, 2008)..

(32) 2.5 Componentes Distribuídos. 14. As funcionalidades do ambiente de execução do OpenCOM são acessadas através da interface IOpenCOM. As principais operações em tempo de execução são: criar uma nova instância de um componente e inseri-lo em tempo de execução; excluir uma instância do componente que foi criado anteriormente; conectar um receptáculo do componente em uma interface requerida do componente de origem, desconectar um receptáculo de uma interface; devolver os metadados armazenados no metamodelo de arquitetura sobre um componente individual; e retornar o nome do componente registrado exclusivamente para uma referência de um determinado componente.. 2.5.3. O Modelo Fractal. O Fractal é apresentado em (OW2, 2004) como um modelo de componentes modular e extensível, que pode ser usado para projetar, implementar, implantar e reconfigurar sistemas e aplicações (OW2, 2004). O objetivo geral do Fractal é reduzir os custos de implantação, desenvolvimento e manutenção de softwares, e em particular os projetos do consórcio ObjectWeb (OW2, 2004). Segundo Bruneton et al. (2006), o Fractal é um modelo de componentes de baixo peso, hierárquico e reflexivo com compartilhamento de componentes que proporciona os benefícios da programação baseada em componentes para o desenvolvimento de sistemas distribuídos. Este modelo tem sido utilizado na construção de uma ampla gama de plataformas de middleware (COULOURIS et al., 2011). O modelo de componentes Fractal suporta várias linguagens de programação, como por exemplo, Java e C, e de forma experimental .NET, SmallTalk e Python. Um componente Fractal é uma entidade de execução que está encapsulada, com identificação distinta e que suporta uma ou mais interfaces (BRUNETON et al., 2004). A interface é um ponto de acesso a um componente, que implementa um tipo de interface que representa as operações suportadas (BRUNETON et al., 2006). As interfaces podem ser de dois tipos: (i) interfaces servidoras - que correspondem a pontos de acesso que aceitam solicitações de serviços de um outro componente, e (ii) interfaces cliente - que correspondem a pontos de acesso que invocam os serviços de um outro componente. Internamente, um componente Fractal é composto por duas partes (OW2, 2004): (i) uma camada de controle ou membrana - que possui as interfaces externas que permitem a introspecção para monitoramento e controle dos componentes em execução, bem como a capa-.

(33) 2.5 Componentes Distribuídos. 15. cidade de reconfiguração estática e dinâmica dos componentes, e (ii) a camada de conteúdo - que é composto por outros componentes também conhecidos como subcomponentes que estão sob o controle do componente de controle envolvente. As interfaces da membrana podem ser externas acessíveis por outros componentes ou internas acessíveis somente pelos subcomponentes. A Figura 2.3 mostra a estrutura básica de um componente Fractal.. Figura 2.3: Estrutura de um componente Fractal (BRUNETON et al., 2006). A especificação Fractal fornece quatro formas para implementação da camada de controle, que podem ser combinadas e extendidas para produzir componentes com diferentes características de reflexão (BRUNETON et al., 2006), a saber: • Atributo - um atributo é uma propriedade configurável de um componente, utilizado para configurar o estado do componente. O componente deve implementar a interface AttributeController para ler e escrever os seus atributos de fora do componente; • Binding - permite o controle das conexões (ligações) e desconexões das interfaces clientes junto as interfaces servidoras entre os componentes. O componente deve implementar a interface BindingController para possibilitar conexões e desconexões das suas interfaces; • Conteúdo - permite a adição e remoção de subcomponentes na camada de conteúdo. O componente deve implementar a interface ContentController para adicionar e remover subcomponentes; • Ciclo de vida - permite o controle explícito sobre o comportamento das fases de inicialização e finalização dos componentes para prover à reconfiguração dinâmica dos.

(34) 2.6 Soluções de Middleware para Interoperabilidade. 16. mesmos. As operações disponíveis são: start e stop para iniciar e parar a execução do componente, respectivamente. O componente deve implementar a interface LifeCycleController para fornecer reconfigurações dinâmicas. No modelo Fractal os componentes são classificados e definidos de acordo com sua estrutura (OW2, 2004): • Componente base - um componente simples sem nenhuma interface de controle; • Componente primitivo - um componente com interfaces de controle, mas que não expõe o seu conteúdo; • Componente composto - um componente que expõe seu conteúdo; • Subcomponente - um componente que está contido em outro componente; • Supercomponente - um componente que contém subcomponente(s). Devido ao compartilhamento de componentes, um componente pode ter vários supercomponentes; • Componente de ligação - um componente que permite à comunicação entre outros componentes.. 2.6. Soluções de Middleware para Interoperabilidade. De acordo com (WEGNER, 1996), interoperabilidade é a capacidade de dois ou mais componentes de software cooperarem apesar das diferenças de linguagem, interface e plataforma de execução. Em outra definição, interoperabilidade é a capacidade que um ou mais sistemas possuem para: conectar-se, compreender e trocar dados com o outro para um determinado propósito (BLAIR et al., 2011). Tradicionalmente, existe uma separação de interoperabilidade sintática (assinatura de operações) e semântica (o "significado" das operações) (VALLECILLO; HERNANDEZ; TROYA,. 2000). A primeira trata das questões em nível de ligação, enquanto a. segunda abrange os aspectos comportamentais em nível semântico da interoperabilidade de componentes. No estudo introdutório do estado da arte da pesquisa sobre soluções para interoperabilidade de middleware por (BLAIR et al., 2011), algumas abordagens foram organizadas de acordo com as seguintes categorias:.

(35) 2.6 Soluções de Middleware para Interoperabilidade. 17. • Middleware Tradicional - não permite interoperabilidade entre os diferentes estilos middleware e implementações específicas. Buscam um padrão comum / plataforma para todo o sistema distribuído. Estas tecnologias resolvem desafios de interoperabilidade para a maioria das diferentes extensões focando a interoperabilidade entre sistemas e máquinas com hardware e linguagens de programação heterogêneos. A figura 2.4 ilustra o padrão de interoperabilidade utilizado pela abordagem de middleware tradicional que fornece uma infraestrutura de software bem integrada e em rede para simplificar o desenvolvimento de aplicações distribuídas. Esta abordagem é inviável para ambientes pervasivos e dinâmico, onde os sistemas interagem espontaneamente, porque todas aplicações seriam obrigadas a serem implementadas usando o mesmo middleware;. Figura 2.4: Padrão de interoperabilidade utilizado pelo middleware tradicional (BLAIR et al., 2011). • Plataformas de Interoperabilidade - reconhecem que a heterogeneidade de middleware é inevitável e, portanto, permite que clientes se comuniquem com um middleware encontrado dinamicamente. A figura 2.5 mostra o padrão de interoperabilidade utilizado por plataformas de interoperabilidade que fornecem uma tecnologia de middleware independente para o cliente, servidor ou peer a ser implementado, a fim de garantir que a aplicação pode interoperar com todos os serviços, independentemente das tecnologias de middleware que empregam. Essas soluções dependem de uma escolha em tempo de projeto para desenvolver aplicações que visem o uso de plataformas de interoperabilidade e, portanto, são inadequadas para outros casos de interoperabilidade, por exemplo, quando duas aplicações desenvolvidas sobre os diferentes middleware legado precisam de interoperabilidade espontânea em tempo de execução;.

(36) 2.6 Soluções de Middleware para Interoperabilidade. 18. Figura 2.5: Padrão de interoperabilidade utilizado por plataformas de interoperabilidade (BLAIR et al., 2011). • Pontes - suportam a tradução bidirecional (comunicação) entre diferentes plataformas de middleware. Assim, os clientes em um domínio middleware podem interoperar com servidores em outro domínio middleware. A figura 2.6 ilustra o padrão de interoperabilidade utilizado por pontes de software que atuam como um mapeamento um-para-um entre os domínios; elas levam mensagens de um cliente em um formato e, em seguida, esta é empacotada para o formato do middleware servidor; a resposta é então mapeada para o formato da mensagem original. Esta abordagem tem como desvantagem o esforço necessário para estabelecer pontes entre todos os diferentes protocolos de middleware;. Figura 2.6: Padrão de interoperabilidade utilizado por pontes de software (BLAIR et al., 2011). • Soluções de Interoperabilidade Transparentes - permitem que duas aplicações legadas se comuniquem de forma transparente, sem qualquer alteração para estas aplicações. A figura 2.7 apresenta o padrão de interoperabilidade utilizado por soluções de interoperabilidade transparentes. Nessa abordagem, as mensagens de protocolo específico, o comportamento e os dados são capturados pelo framework de interoperabilidade e traduzido para uma representação intermediária. Em seguida, um mapeador subsequente traduz a representação intermediária para a representação do middleware legado específico. A utilização desta solução permite que um middleware possa ser mapeado para qualquer outro através do desenvolvimento destes dois elementos tradu-.

(37) 2.6 Soluções de Middleware para Interoperabilidade. 19. tores, ou seja, não é necessário o mapeamento direto para outro protocolo. O desafio com esta abordagem é o problema do maior divisor comum, que pode ocorrer devido à necessidade de identificar entre todos os protocolos um subconjunto de funcionalidades similares a serem suportadas pela solução. Desta forma, quando o número de protocolos aumenta este subconjunto torna-se menor, restringindo o que é possível ser suportado pela abordagem.. Figura 2.7: Padrão de interoperabilidade utilizado por soluções de interoperabilidade transparentes (BLAIR et al., 2011). • Mobilidade Lógica - supera heterogeneidade pela migração de aplicativos e serviços para o ambiente local de execução, assumindo que o ambiente tem os mecanismos para interpretar este código. A mobilidade lógica é caracterizada pelo uso de código móvel a ser transferido de um dispositivo e executado em outro. A figura 2.8 ilustra o padrão de interoperabilidade utilizado por soluções de mobilidade lógica. A abordagem para resolver interoperabilidade é, por conseguinte, simples; um serviço divulga o seu comportamento e também o código para interagir com ele. Quando um cliente descobre o serviço desejado ele baixa e usa o código que é dinamicamente disponível para ele em tempo de execução. Os padrões de interoperabilidade utilizados por soluções de mobilidade lógica necessitam que todos os aplicativos estejam em conformidade com a mesma plataforma para que o software implantado possa ser executado.. Figura 2.8: Padrão de interoperabilidade utilizado por soluções de mobilidade lógica..

(38) 2.7 Discussão. 2.7. 20. Discussão. Neste capítulo foram relacionados os principais conceitos necessários para o entendimento e desenvolvimento do framework proposto neste trabalho. Muitos desses fundamentos estão relacionados com a solução proposta e foram usados diretamente, dentre os quais podemos destacar: (i) a invocação remota de métodos e serviços web que foram usadas como mecanismos para ligação entre componentes remotos e (ii) a reflexão computacional aliada a geração automática de código que foram usadas como recurso para inspecionar e adaptar a estrutura interna dinamicamente de templates para criação automática de proxies que promovem a ligação transparente entre componentes remotos de modelos heterogêneos suportados pelo framework proposto. Nesse contexto, dentre as diferentes abordagens de se contornar o problema da interoperabilidade discutidas neste capítulo, a solução proposta se aproxima mais das chamadas de soluções de interoperabilidade transparente apresentada na seção anterior..

(39) Capítulo 3 Trabalhos Relacionados Neste capítulo apresentaremos os principais trabalhos acadêmicos relacionados à interoperabilidade entre modelos de componentes de software distintos. Em seguida, será apresentada uma discussão sobre esses trabalhos, destacando as diferenças e similaridades com relação à abordagem proposta.. 3.1. Vienna Component Framework. No artigo de apresentação do VCF (Vienna Component Framework), os autores (OBERLEITNER; GSCHWIND; JAZAYERI,. 2003) propuseram um framework que permite a composição. entre diferentes modelos de componentes em um novo aplicativo. O VCF foi implementado na linguagem de programação Java. A figura 3.1 ilustra a arquitetura do VCF. A abordagem é baseada na construção de componentes de fachadas para cada modelo de componentes que abstraem as diferenças entre os modelos suportados pelo VCF. Este framework fornece suporte para os modelos de componentes COM (Microsoft’s Component Object Model), CORBA (Common Object Request Broker Architecture), EJB (Enterprise JavaBeans) e JavaBeans. Cada modelo de componentes é representado por um plugin. Suporte para um novo modelo de componentes pode ser adicionado através da implementação de um novo plugin. Cada plugin de um modelo de componentes fornece a funcionalidade para acessar os recursos do modelo de componentes correspondente. Cada plugin pode opcionalmente implementar um recurso de geração de código. Os plugins de modelos de componentes não são utilizados diretamente, 21.

(40) 3.2 Meta-framework para padrões de componentes. 22. mas são acessados por meio de componentes de fachadas. O VCF também fornece um modelo de programação genérico para construir novos componentes. O programador pode implementar estruturas com metaclasses baseadas na sintaxe JavaBean padrão para representar os componentes VCF, que podem ser transformados para outro modelo de componentes suportado por um plugin. O VCF impõe cerca de 5 a 20% de sobrecarga de acesso, dependendo do modelo de componentes, para os componentes no lado do servidor em comparação com o acesso aos componentes usando seus modelos de componente nativo. O artigo não aborda a comunicação entre componentes distribuídos, ele apenas apresenta como solução a capacidade de que um componente de um determinado modelo possa ser integrado localmente a outros componentes de um outro modelo.. Figura 3.1: Arquitetura do VCF (OBERLEITNER; GSCHWIND; JAZAYERI, 2003).. 3.2. Meta-framework para padrões de componentes. Um meta-framework que fornece um modelo comum para o desenvolvimento de padrões que lidam com as características semânticas dos componentes foi descrito em (JOLOLIAN; NGATCHOU; SEKER, 2004).. O artigo apresentou uma proposta de um meta-framework para o. problema da integração de componentes em nível semântico de compatibilidade. Os padrões no nível semântico devem garantir que a modalidade de interação, comportamento e dados utilizados pelos componentes são compatíveis. O modelo é baseado na modelagem de um componente, decompondo-o em seus três elementos fundamentais: dados, função e controle..

(41) 3.3 SCIRun2. 23. Segundo os autores, os padrões podem ser usados como base para o desenvolvimento de frameworks de integração de componentes. No entanto, os padrões devem ser estabelecidos em um modelo de domínio que especifique os tipos de serviços e dados que são necessários para lidar com os problemas dentro do domínio especificado. O modelo de domínio é baseado em uma análise de domínio e faz uso de padrões existentes dentro do domínio. Estes frameworks de integração serão capazes de gerar adaptadores que mediam incompatibilidades entre os componentes, não só no de nível ligação, mas também no nível semântico. Os adaptadores de componentes poderão se ligar aos componentes em tempo de execução para mediar as disparidades e permitir a comunicação entre os componentes. Entende-se, no trabalho, um adaptador como um componente de software introduzido de forma transparente entre dois componentes para mediar as interfaces incompatíveis. Os autores ressaltam que o desenvolvimento de adaptadores de componentes pode ser uma tarefa difícil e levar um tempo considerável. Para a implementação dos adaptadores é necessária a compreensão das interfaces envolvidas e a geração do código apropriado que possa interagir com os dois componentes durante a execução da tradução necessária. Os autores consideram que para tornar o desenvolvimento de software baseado em componente uma abordagem viável, deve ser possível gerar automaticamente e dinamicamente os adaptadores. O artigo não mostra a arquitetura do framework nem cita a existência de uma implementação que a valide. O texto apresenta apenas uma visão geral conceitual da abordagem proposta pelos autores.. 3.3. SCIRun2. O SCIRun2 (ZHANG; DAMEVSKI; PARKER, 2004) é um framework que permite a integração de diferentes modelos de componentes em um ambiente único. Os autores (PARKER et al., 2006) apresentaram o framework SCIRun2, baseado no CCA (Common Component Architecture) (ARMSTRONG et al., 2006). O CCA é um modelo de componentes para computação de alto desempenho, voltado para resolução de problemas de ambientes da computação científica. Frameworks que aderem ao modelo CCA permitem a criação e a conexão entre componentes para construir aplicações..

(42) 3.4 Interoperabilidade entre modelos de componentes em grade. 24. Neste trabalho, foi proposto um conceito de meta-componentes, onde os componentes de software podem ser manipulados de uma forma mais abstrata e eficaz, oferecendo uma arquitetura de plugin para os modelos de componentes, e uma abordagem baseada em pontes entre eles, permitindo a interoperabilidade entre os diferentes modelos de componentes. Componentes pontes pertencem a um modelo de componentes interno especial que é usado para construir uma conexão entre os componentes de diferentes modelos de componentes, podendo ser gerados manualmente ou automaticamente. SCIRun2 integra múltiplos modelos de componentes em um ambiente único e gerenciado através de uma interface visual comum centrada no usuário. Desta forma, uma série de ferramentas podem ser combinadas em um único ambiente sem a necessidade de adoção global de um modelo de componentes comum subjacente. A figura 3.2 demonstra um exemplo simples de como SCIRun2 lida com diferentes modelos de componentes usando uma abordagem baseada em pontes entre eles. Dentro SCIRun2, os dois frameworks estão ocultos: o CCA framework e o CORBA Object Request Broker (ORB). Os dois componentes CCA, Driver e Integrator são ligados de uma maneira simples através do modelo de componentes CCA. O componente CORBA Function não pode ser conectado diretamente ao componente CCA Driver, porque nem o CCA nem o CORBA permitem uma conexão com um componente de um modelo diferente. O componente ponte é criado e usado para construir uma ligação entre os componentes de modelos distintos. SCIRun2 suporta computação distribuída através de objetos distribuídos. Componentes criados em computadores diferentes podem trabalhar em conjunto através de uma rede, sendo que a comunicação entre os componentes é feita com RMI (Remote Method Invocation). Componentes tipo ponte podem implementar transformações entre os modelos de componentes e, portanto, têm o potencial de introduzir os gargalos de desempenho.. 3.4. Interoperabilidade entre modelos de componentes em grade. Os autores (MALAWSKI et al., 2007) apresentaram um estudo de caso de um projeto genérico de modelos de componentes em grade (grid). Eles definem um framework que permite a dois componentes de sistema, um executando em um ambiente CCA (Common Component.

(43) 3.4 Interoperabilidade entre modelos de componentes em grade. 25. Figura 3.2: Componentes de diferentes modelos cooperam no SCIRun2 (PARKER et al., 2006). Architecture), e outro executando em um ambiente Fractal, de interagir, como se fossem elementos do mesmo sistema. O modelo proposto pelos autores possibilita a interoperabilidade entre dois modelos de componentes para aplicações em grade: o GCM (Grid Component Model) e o CCA. O GCM é baseado no Fractal e está sendo desenvolvido como um modelo de componentes padrão voltado à programação para computação em grade. A abordagem é centrada no uso de mediadores e adaptadores baseados no padrão de projeto Adapter (Wrapper) para criar uma camada de interoperabilidade ad-hoc entre frameworks de componentes selecionados sem sobrepor a eles outro framework de interoperabilidade universal. A figura 3.3 ilustra a interoperabilidade entre os componentes CCA e Fractal. Neste exemplo, o sistema CCA é composto por três componentes CCA que são criados e ligados entre se por um framework CCA. Este sistema CCA está dentro de um invólucro (wrapper) como um componente Fractal de tal maneira que ele pode ser ligado a outros componentes Fractal. No entanto, também é possível ver o sistema Fractal a partir da perspectiva CCA como um "wrapped", ou seja, a solução é simétrica. Este modelo evita a introdução da noção de um novo modelo de componentes e permite que os componentes de modelos distintos que precisem interoperar sejam executados em seus frameworks nativos. No entanto, esta solução não possibilita a ligação entre os componentes em tempo de execução..

(44) 3.5 PBJIM. 26. Figura 3.3: Interoperabilidade entre os componentes CCA e Fractal (MALAWSKI et al., 2007).. 3.5. PBJIM. O PBJIM (Plugin-based Job Interoperation Mechanism) que foi proposto em (WU; TAO; XU, 2007) se baseia no uso de virtualização de serviços e de mecanismos de plugin para interoperabilidade entre sistemas de grade heterogêneos. O PBJIM permite a interoperabilidade entre dois diferentes sistemas de grade, ChinaGrid e China National Grid, que foram construídos com base em dois middlewares de grade distintos, respectivamente, CGSP (ChinaGrid Platform Support) e VEGA. O CGSP é um middleware de grade para a construção e desenvolvimento do sistema de grade ChinaGrid. O VEGA é baseado na tecnologia de Web Service que vê uma grade como um sistema de computador distribuído. No PBJIM, o gerenciamento da interoperabilidade entre sistemas de grade heterogêneos é obtido através do CSGrid (Chinese e-Science Grid), que é baseado em CERNET (China Education e Research Network), que visa integrar middlewares de grade. O PBJIM promove a interoperabilidade entre sistemas de grade heterogêneos, mantendo a sua independência, sem a necessidade de qualquer alteração neles. O PBJIM suporta quatro tipos de serviços: serviços web, serviços WSRF (Web Service Resource Framework), GRS (General Running Service) e serviços de workflow (fluxo de trabalho). A figura 3.4 mostra a arquitetura do PBJIM. Para fornecer uma interoperabilidade flexível e escalável entre as plataformas de grade heterogêneas, PBJIM adota uma estrutura de três.