Análise estátistica das variavéis aleatórias: RTT (Round-Trip Time), tempo de processamento no Stub e tempo de processamento no Skeleton do Middleware CORBA

Texto

(1)Pós-Graduação em Ciência da Computação. “Análise Estatística das Variáveis Aleatórias: RTT (Round-Trip Time), Tempo de Processamento no Stub e Tempo de Processamento no Skeleton do Middleware CORBA” Por. Thiago Sávio Carbone Dissertação de Mestrado. Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao. RECIFE, SETEMBRO/2005.

(2) UNIVERSIDADE FEDERAL DE PERNAMBUCO PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO. “Análise Estatística das Variáveis Aleatórias: RTT (Round-Trip Time), Tempo de Processamento no Stub e Tempo de Processamento no Skeleton do Middleware CORBA”. por. Thiago Sávio Carbone. Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco, como requisito parcial à obtenção do título de Mestre em Ciência da Computação. Área de Concentração: Redes de Computadores e Sistemas Distribuídos. Orientadora: Professora Doutora Marcília Andrade Campos. Recife CIn/UFPE Setembro,2005.

(3) Sumário LISTA DE FIGURAS.................................................................................................... II LISTA DE TABELAS ..................................................................................................III AGRADECIMENTOS ................................................................................................. IV RESUMO.........................................................................................................................V ABSTRACT .................................................................................................................. VI 1. INTRODUÇÃO ...................................................................................................... 1 1.1 MOTIVAÇÃO ...................................................................................................... 1 1.1.1 Vantagens do Middleware em Sistemas Distribuídos .............................. 2 1.1.2 Os Problemas do Middleware em Sistemas Distribuídos ........................ 3 1.2 OBJETIVOS ......................................................................................................... 3 1.3 ESTRUTURA DA DISSERTAÇÃO .......................................................................... 4. 2. AVALIAÇÃO DE DESEMPENHO ..................................................................... 5 2.1 INTRODUÇÃO ..................................................................................................... 5 2.2 TÉCNICAS DE AVALIAÇÃO ................................................................................. 6 2.2.1 Medições................................................................................................... 7 2.2.2 Simulações ................................................................................................ 8 2.2.3 Modelagem Analítica................................................................................ 9 2.2.3.1 Modelagem Baseada em Descrição.................................................... 11 2.2.3.2 Modelagem com Análise Estática ...................................................... 11 2.2.4 Modelagem Híbrida................................................................................ 11 2.3 SISTEMÁTICA PARA AVALIAÇÃO DE DESEMPENHO .......................................... 11 2.4 MÉTRICAS DE AVALIAÇÃO – UMA VISÃO GERAL ............................................. 13 2.4.1 Latência ou tempo de resposta ............................................................... 13 2.4.2 Taxa de Serviço ...................................................................................... 14 2.4.3 Disponibilidade ...................................................................................... 14 2.4.4 Confiabilidade ........................................................................................ 14 2.4.5 Utilização ............................................................................................... 15 2.5 AVALIAÇÃO DE DESEMPENHO DE UM MIDDLEWARE........................................ 15 2.6 FATORES QUE PODEM INFLUENCIAR NA AVALIAÇÃO DE DESEMPENHO DE UM MIDDLEWARE .............................................................................................................. 16. 3. MIDDLEWARE..................................................................................................... 18 3.1 INTRODUÇÃO ................................................................................................... 18 3.2 CATEGORIAS DE MIDDLEWARE ....................................................................... 20 3.2.1 Middleware Transacional ...................................................................... 20 3.2.2 Middleware Procedural.......................................................................... 21 3.2.3 Middleware Orientado a Mensagens ..................................................... 22 3.2.4 Middleware Orientado a Objetos ........................................................... 23 3.3 MIDDLEWARE ORIENTADO A OBJETOS - CORBA .......................................... 25 3.3.1 Conceito.................................................................................................. 25 3.3.1.1 Object Request Broker........................................................................ 26 3.3.1.2 A Interface ORB e o Repositório de Interfaces .................................. 28 3.3.1.3 Operações da Interface ORB............................................................... 29 3.3.1.4 Escondendo as Diferenças entre ORB´s ............................................. 29.

(4) 3.3.1.5 3.3.1.6 3.3.1.7 3.3.1.8 3.3.1.9 3.3.1.10 3.3.1.11 3.3.1.12 3.3.1.13 3.3.1.14 3.3.1.15 3.3.1.16 3.3.1.17 4. IDL - A Linguagem de Definição de Interface................................... 29 Invocação de um Objeto ..................................................................... 30 Stubs - Static Invocation Interface (SII) ............................................ 31 Dynamic Invocation Interface (DII) ................................................... 31 O Repositório de Interfaces ................................................................ 32 O Repositório de Interfaces - Lado Cliente .................................... 33 Implementação de Objeto - Estrutura............................................. 34 Skeletons - Static Invocation Interface (SII).................................. 35 Dynamic Skeleton Interface (DSI)................................................. 35 Object Adapter................................................................................ 36 O Repositório de Implementações.................................................. 36 O Repositório de Implementações - Lado Servidor ....................... 37 CORBAservices .............................................................................. 37. EXPERIMENTOS COM O MIDDLEWARE CORBA...................................... 40 4.1 DESEMPENHO DO MIDDLEWARE CORBA ....................................................... 40 4.2 CENÁRIOS DOS EXPERIMENTOS ....................................................................... 43 4.2.1 Variáveis aleatórias estudadas............................................................... 44 4.3 RESULTADOS PARA RTT, T1 E T3 .................................................................... 45 4.3.1 RTT ......................................................................................................... 46 4.3.2 Comparação entre RTT e T1 ................................................................... 50 4.3.3 Comparação entre T1 e T3 ...................................................................... 51 4.4 EXPERIMENTOS COM VARIÁVEL DO TIPO CHAR ................................................ 54 4.4.1 Cenário do experimento C = 1, 2........................................................... 54 4.4.1.1 Resultados Obtidos ............................................................................. 54 4.4.2 Cenário do experimento C = 1, 5, 10..................................................... 57 4.4.2.1 Resultados Obtidos ............................................................................. 58 4.4.2.2 Um Cliente.......................................................................................... 58 4.4.2.3 Cinco Clientes .................................................................................... 59 4.4.2.4 Dez Clientes........................................................................................ 60 4.4.2.5 Cálculo do Intervalo de Confiança ..................................................... 61. 5. CONCLUSÕES E TRABALHOS FUTUROS................................................... 63. REFERÊNCIAS BIBLIOGRÁFICAS ....................................................................... 65 ANEXOS ....................................................................................................................... 69 ANEXO 1 – INTERFACE IDL......................................................................................... 69 ANEXO 2 – CÓDIGO FONTE DO CLIENTE ..................................................................... 70 ANEXO 3 – CÓDIGO FONTE DO SERVIDOR ................................................................... 72 ANEXO 4 – CÓDIGO FONTE DO STUB ........................................................................... 74 ANEXO 5 – CÓDIGO FONTE DO SKELETON .................................................................. 77.

(5) II. Lista de Figuras Figura 2-1 Sistemática para Avaliação de Desempenho ................................................ 13 Figura 3-1 Camada Middleware no Contexto ................................................................ 19 Figura 3-2 Comunicação através de middleware ........................................................... 19 Figura 3-3 Papel do Middleware Transacional .............................................................. 21 Figura 3-4 Visão Geral de um Middleware Procedural.................................................. 22 Figura 3-5 Visão Geral dos Elementos de um Middleware Orientado a Mensagens..... 23 Figura 3-6 Visão Geral de um Midleware de Objetos.................................................... 24 Figura 3-7 Componentes da OMA .................................................................................. 26 Figura 3-8 Uma Requisição Enviada Através do ORB................................................... 27 Figura 3-9 Estrutura de um ORB .................................................................................... 27 Figura 3-10 Repositório de Interfaces e de Implementações ......................................... 32 Figura 3-11 Estrutura de uma Implementação de Objeto CORBA................................. 34 Figura 3-12 Estrutura de um Adaptador de Objetos....................................................... 36 Figura 3-13 Repositório de Interfaces e de Implementações ......................................... 36 Figura 3-14 OMG CORBA Arquitetura......................................................................... 37 Figura 4-1 Cenário dos Experimentos ............................................................................ 44 Figura 4-2 Gráfico Comparativo das Médias para RTT................................................. 48 Figura 4-3 Gráfico Comparativo para 1000 Requisições ............................................... 49 Figura 4-4 Gráfico Comparativo para 10000 Requisições ............................................. 49 Figura 4-5 Gráfico Comparativo entre as médias de RTT e T1 para 1000 Requisições. 50 Figura 4-6 Gráfico Comparativo entre as médias de RTT e T1 para 10000 Requisições50 Figura 4-7 Gráfico Comparativo entre as Médias de T1 e T3 ......................................... 52 Figura 4-8 Gráfico Comparativo entre T1 e T3 quando N = 1000 requisições ............... 53 Figura 4-9 Gráfico Comparativo entre T1 e T3 quando N = 10000 requisições ............. 53.

(6) III. Lista de Tabelas Tabela 1. Principais tipos primitivos das linguagens de programação........................... 45 Tabela 2 Indicadores Estatísticos para RTT quando N=1000, 10000 e C = 1, 5, 10, 15, 20 .................................................................................................................................... 47 Tabela 3 Intervalo de Confiança para a média de X = RTT - T1 ................................... 51 Tabela 4 Cálculo dos Indicadores Estatísticos para T1 e T3 ........................................... 52 Tabela 5 Intervalo de Confiança para T1 - T3 ................................................................. 52 Tabela 6 N = 1000 ......................................................................................................... 55 Tabela 7 N = 10000 ........................................................................................................ 55 Tabela 8 N = 1000, T = 15 ............................................................................................. 56 Tabela 9 N = 1000, T = 79 ............................................................................................. 56 Tabela 10 N = 10000, T = 15 ......................................................................................... 56 Tabela 11 N = 10000, T = 79 ......................................................................................... 57 Tabela 12 Comparação entre RTT e RTTm = 95%......................................................... 57 Tabela 13 N = 1000 ....................................................................................................... 58 Tabela 14 N = 10000 ..................................................................................................... 58 Tabela 15 N = 1000, T = 15 .......................................................................................... 59 Tabela 16 N = 1000, T = 79 ........................................................................................... 59 Tabela 17 N = 10000, T = 15 ........................................................................................ 60 Tabela 18 N = 10000, T = 79 ........................................................................................ 60 Tabela 19 N = 1000, T = 15 .......................................................................................... 60 Tabela 20 N = 1000, T = 79 .......................................................................................... 61 Tabela 21 N = 10000, T = 15 ........................................................................................ 61 Tabela 22 N = 10000, T = 79 ........................................................................................ 61 Tabela 23 Comparação entre. rtt (1,10 ). and. rtt (1,5). ...................................................... 62.

(7) IV. Agradecimentos Primeiramente, gostaria da agradecer a Deus pela sabedoria, ajuda, proteção e outras infinitas provas de presença. A meus pais, que sempre incentivaram e apoiaram minhas decisões. Agradeço ao carinho, à educação e aos conselhos que recebi durante toda a minha vida. Aos meus irmãos, que mesmo distantes, sempre torceram e me incentivaram nesta nova caminhada. À minha esposa, Ana Elsa, que sempre me apoiou e me incentivou a enfrentar os desafios e a superar os obstáculos que surgiram. Agradeço pela ajuda, paciência, companhia e amor doados em todo esse tempo que estamos juntos. Desejo muito sucesso. Ao meu filho Igor, um dos motivos para enfrentar esta nova caminhada. Ao amigo Erick, que inúmeras vezes ajudou e colaborou no desenvolvimento desse trabalho. À sabedoria e amizade provada nos momentos de reflexão e companheirismo. A amiga e orientadora Profª Marcília, por todo o ensino, incentivo e compreensão dispensados ao longo desta caminhada. Aos colegas de trabalho da Faculdade Sete de Setembro: Junior, Romildo, Marcus por todos os momentos de ajuda e compreensão e acima de tudo pela conversa amiga que me proporcionaram em momentos difíceis. Aos demais amigos, colegas e familiares que me suportaram em todos os momentos difíceis..

(8) V. Resumo O paradigma cliente-servidor tem sido usado na construção de aplicações para sistemas distribuídos. Adicionalmente, como os componentes implementados, usando-se de diferentes tecnologias, precisam interagir de forma colaborativa, isto torna os sistemas cliente-servidor heterogêneos; cabe então ao middleware prover, eficientemente, a interoperabilidade em tais sistemas. Este fato originou o surgimento de trabalhos de pesquisa na busca de uma modelagem matemática para analisar o comportamento de variáveis aleatórias presentes na comunicação cliente-servidor. Este trabalho apresenta, inicialmente, a análise estatística das variáveis RTT (Round-Trip Time ou tempo de processamento total de uma requisição), T1 (tempo de processamento no stub) e T3 (tempo de processamento no skeleton). A seguir também é estudada a variável RTT utilizando o tipo primitivo char. Os resultados obtidos com o experimento mostraram que (i) o número de clientes e RTT são grandezas diretamente proporcionais, isto é, a medida que o número de clientes aumenta RTT também aumenta; (ii) a maior parte do tempo de processamento de RTT é gasto no tempo de processamento no stub. Constatou-se então que RTT e o tempo de processamento no stub são estatisticamente os mesmos; (iii) as variações do número de requisições (N) influenciam em RTT; (iv) RTT aumentou significativamente quando o tipo primitivo foi apenas char variando o tamanho da requisição..

(9) VI. Abstract The paradigm client-host has been used in the construction of application to the systems distributed. In addition, as the implemented components, using different technologies, they need to interact as a collaborative form, this becomes the systems client-host heterogeneous; it is the competence of the middleware to provide, efficiently, the interoperability in these systems. This fact gave the origin for the beginning of research works, seeking a mathematical stereotype for analysing the behaviour of random variables presented between the communication client-host. This work presents, at first, the statistical analysis of the variables RTT (Round Trip Time or time of total processing from a requirement.), T1 (processing time in the stub) and T3 (processing time in the skeleton). Afterward, it’s also analysed the variable RTT using the primary type char. The results obtained with the experiment, revealed that (i) the number of clients and RTT are greatness directly proportional, that is, as the number of client increases, RTT also increases; (ii) the most part of the time of processing from RTT is spent in time of processing in the stub. So, it was said that, RTT and the time of processing in the stub are statistically the same;(iii) the variables of the number of requirements (N) influence in RTT;(iv) RTT increased meaningfully when the primary type was only char, varying the size of the requirement..

(10) 1. Capítulo 1 Este capítulo descreve, inicialmente, a motivação deste trabalho e os benefícios e problemas encontrados na utilização do middleware. Finalmente, na última parte do capítulo, são mostrados os objetivos e a estruturação desta dissertação.. 1 Introdução 1.1 Motivação O crescimento exponencial da Internet, a conectividade global e o domínio de novas aplicações, introduziram mudanças importantes no desenvolvimento de aplicações cliente-servidor. Sistemas de informação contemporâneos são distribuídos e heterogêneos. Heterogêneos sim, pois a tecnologia, de uma maneira geral, não para nunca de evoluir. Cada vez mais estamos a frente de novas aplicações, de novas plataformas que precisam comunicar-se entre si. Sistemas distribuídos sempre requer comunicação entre entidades de computação. Entidades de computação podem ser entendidas como uma parte do sistema que pode migrar para outra máquina que está fazendo parte desta interação. Esta comunicação pode ser estabelecida usando mecanismos de baixo nível, como por exemplo os sockets; para as gerações de sistemas de informação de alto nível, novos paradigmas se tornaram necessários e foram introduzidos em nosso dia-a-dia [JUR 99] . Linguagens procedurais introduziram um paradigma como RPC (Remote Procedure Call). Neste novo contexto, ajustar o conceito de RPC com o paradigma de objeto resulta em um modelo de objeto distribuído. Atualmente existem diversos modelos de objetos distribuídos. Os modelos mais conhecidos são o CORBA (Common Object Request Broker Architecture) [OMG 91] [OMG 95] e o RMI (Remote Method Invocation) [WAL 95]. O funcionamento básico destes modelos são similares – escondendo os detalhes dos métodos de invocações remotas [JUR 99]. Muitas aplicações que requerem computadores de alto desempenho estão sendo migradas para arquiteturas de sistemas distribuídos. Entretanto, a maioria dessas aplicações sofrem com problemas de escalabilidade e com a falta de desempenho, isto é,.

(11) 2. devido a outros fatores que estão envolvidos em um sistema distribuído, como por exemplo, o meio físico de comunicação utilizado, a velocidade da comunicação oferecida por este meio, mecanismos ou hardware de conversão de dados existentes na comunicação (switchs, routers, etc.) e até mesmo gerenciadores ou analisadores de tráfego, acabam influenciando no desempenho final de um sistema quando passam a utilizar a arquitetura de sistemas distribuídos. Na maioria das vezes, a escolha da plataforma para aplicações com arquitetura de sistemas distribuídos torna essencial para o conjunto final que se deseja alcançar, neste caso, desempenho e distribuição. [TAU 02] A motivação de nosso trabalho está voltada ao estudo da análise de desempenho das variáveis aleatórias (RTT, Stub e Skeleton) encontradas no middleware, e qual a influência das mesmas sobre o middlewware, mais especificamente, no middleware CORBA, objeto de nosso estudo. Em nossa revisão bibliográfica, podemos notar que a maioria dos estudos existentes nesta área, estão mais focados para a avaliação do tempo total, tempo que pode ser compreendido no intervalo de tempo no qual todo o processo de requisição e resposta é completado. Neste trabalho usaremos RTT para representação desta variável.. 1.1.1 Vantagens do Middleware em Sistemas Distribuídos A funcionalidade e a integração de aplicações de alto desempenho com sistemas de computação distribuída tem aumentado continuamente. Este aumento na integração deve-se ao grande número de plataformas middleware que contribuíram para resolver os problemas que apareciam para os programadores quando se tratava de um nível mais baixo da aplicação [TAU 02]. Em sistemas modernos, as plataformas de midlleware permitem que o desenvolvedor da aplicação trabalhe em um nível mais alto da aplicação. O middleware pode eficazmente esconder detalhes dos sistemas operacionais e tornar fácil a migração da aplicação de uma máquina para outra. Os middlewares para computação distribuída fornecem não somente a portabilidade, como também a facilidade paras os desenvolvedores darem continuidade em seus trabalhos, tornando o processo de desenvolvimento de uma aplicação mais rápido e eficaz. Segundo [KAU 96], os principais benefícios de um middleware são:.

(12) 3. . Aumento da longevidade das aplicações;. . Redução no tempo de resposta na escolha de novas aplicações;. . Habilidade de fazer melhorias contínuas nas aplicações;. . Custo reduzido das aplicações devido a reusabilidade dos múltiplos níveis da aplicação;. . Aumento na produtividade do programador;. . Qualidade melhorada da aplicação: confiabilidade, disponibilidade, vazão, manutenção e gerenciamento;. . A aplicação se torna mais adaptativa as arquiteturas computacionais;. . Aumento da escalabilidade.. 1.1.2 Os Problemas do Middleware em Sistemas Distribuídos Projetar sistemas distribuídos com enfoque em escalabilidade e desempenho é uma tarefa difícil. Faltam ferramentas de avaliação de desempenho que ajudem os desenvolvedores a definir qual a plataforma a ser utilizada. Com o uso destas ferramentas, com as quais os sistemas seriam previamente testados, os sistemas tornariam-se mais eficientes podendo utilizar melhor os recursos oferecidos pelo middleware [TAU 02].. 1.2 Objetivos Este trabalho tem como objetivo amplo, inicialmente, analisar as variáveis aleatórias RTT (tempo de processamento total), o tempo de processamento no Stub e o tempo de processamento no Skeleton do Middleware CORBA em cenários variados onde estão envolvidos clientes e servidor utilizando tipos primitivos das linguagens de programação, apresentados na Seção 4.3, e em seguida serão feitos experimentos onde será estudado o comportamento da variável RTT (tempo de processamento total) utilizando-se somente o tipo primitivo char variando-se o tamanho da mensagem. Cabe aqui salientar, que o estudo ou escolha destas variáveis está diretamente relacionado aos levantamentos feitos em nossa revisão bibliográfica apresentada na Seção 4.1. Estas revisões bem como seus resultados foram tomados como base para a desenvolvimento deste trabalho..

(13) 4. O trabalho proposto é relevante uma vez que, como mencionado anteriormente, análise de desempenho de middleware é uma área de pesquisa profícua considerando que a literatura científica ainda é insuficiente sobre o assunto.. 1.3 Estrutura da Dissertação A metodologia utilizada para estruturar esta dissertação segue o seguinte esquema: o conhecimento dos conceitos mais genéricos são apresentados, com ênfase no objetivo principal de estudo, análise estatística de variáveis aleatórias do middleware CORBA. Os cenários serão apresentados, os resultados obtidos analisados e finalmente, serão expostas as conclusões e orientações para trabalhos futuros. Seguindo esta estruturação, os capítulos estão organizados como se segue:. Capítulo 2 – Introdução a Avaliação de Desempenho: Este capítulo apresenta os conceitos básicos sobre avaliação de desempenho: técnicas, sistemáticas e as métricas utilizadas em um processo de análise e avaliação de desempenho. Conceitos estes que serão utilizados no desenvolvimento geral deste trabalho.. Capítulo 3 – Conceitos Básicos de Middleware: Este capítulo define middleware mostrando suas principais características, bem como, dando ênfase e exibindo um estudo detalhado do middleware CORBA.. Capítulo 4 – Experimento com o Middleware CORBA: Descreve-se o experimento realizado para obtenção dos resultados para os cenários considerados.. Capítulo 5 – Conclusões e Trabalhos Futuros: Este capítulo mostra as conclusões obtidas durante o desenvolvimento deste trabalho, assim como as principais contribuições que ele fornece para a área de análise de desempenho de middleware. Serão mostrados alguns possíveis trabalhos futuros..

(14) 5. Capítulo 2. Este capítulo apresenta os conceitos básicos sobre avaliação de desempenho. Técnicas, sistemáticas e as métricas utilizadas em um processo de análise e avaliação de desempenho.. 2 Avaliação de Desempenho 2.1 Introdução A análise de desempenho deve caracterizar cada estágio de uma aplicação, desde a fase do projeto, a migração para novas arquiteturas ou até mesmo uma otimização para uma plataforma em particular. Ao analisar o desempenho é necessário que caracterizemos as perdas de desempenho e o baixo poder de escalabilidade das aplicações, principalmente em sistemas distribuídos. As premissas para caracterizarmos o desempenho em sistemas distribuídos que se utilizam de um middleware para fazer a comunicação necessária entre as aplicações ou partes das mesmas, têm que envolver observações detalhadas de muitas métricas de avaliação de desempenho em diferentes níveis, tanto em nível de hardware como de software. Isto significa que métricas utilizadas em níveis mais altos da aplicação podem não ser aplicáveis em níveis mais baixos, neste caso, em nível de hardware. Em um nível mais elevado de abstração, o usuário olha para os componentes de tempo total da execução do sistema ou para o tempo total de comunicação. Entretanto, para podermos capturar as perdas de desempenho em sistemas distribuídos ou para predizermos o comportamento da aplicação em novas plataformas, a observação do uso dos recursos em um nível mais baixo torna-se necessário. Em sistemas de computação distribuída, a observação do nível mais baixo não pode ser considerada em uma única máquina e sim no conjunto que compõe o sistema como um todo. Neste caso, as caracterizações do tempo de trabalho e do desempenho fornecem uma base para a tomada de decisões com relação a arquitetura que será utilizada..

(15) 6. Podemos dizer então que, analisar o desempenho de sistemas computacionais, como um todo, consiste em um conjunto de técnicas e metodologias que permitem responder a questão de como se obter um alto desempenho de um sistema computacional a um baixo custo. A atividade de avaliação de desempenho compreende, entre outras:  Seleção de técnicas de avaliação, métricas de desempenho e cargas de trabalho;  A correta condução das medidas de desempenho e das simulações;  A utilização de técnicas estatísticas apropriadas para comparar as diversas alternativas;  O desenvolvimento dos experimentos de medição e simulação visando prover a maior quantidade de informação com o menor esforço;  A utilização de modelos de filas para analisar o desempenho dos sistemas. Contrário ao pensamento comum, a avaliação de desempenho não pode ser realizada de forma automatizada. Cada avaliação exige um conhecimento dos sistemas a serem modelados e uma cuidadosa seleção da metodologia, carga de trabalho ou workload e ferramentas. Definir o problema real e convertê-lo numa forma em que ferramentas e técnicas usuais podem ser utilizadas é a parte subjetiva do trabalho. Segundo [HU 97], a carga de trabalho ou workload é definido como o conjunto de todas as tarefas individuais, transações e dados a serem processados em um certo período de tempo. Em outras palavras, podemos dizer que o workload é a quantidade de trabalho ou carga computaciona1 submetida ao sistema. É fundamental escolhermos um workload adequado para evitar que conclusões precipitadas, e até mesmo erradas, possam ser geradas durante a avaliação de desempenho do sistema.. 2.2 Técnicas de Avaliação As técnicas de avaliação de desempenho podem ser utilizadas em duas situações distintas. Em [JAI 91], podemos notar que a primeira situação é onde os avaliadores estão interessados em comparar sistemas diferentes, mas com um mesmo propósito, e descobrir qual deles é o mais eficiente. Na segunda situação, os avaliadores desejam estudar parâmetros do sistema, onde o objetivo é descobrir qual o valor para cada um destes parâmetros que aumentam o desempenho do sistema..

(16) 7. Dentre as técnicas comumente utilizadas em avaliação de desempenho, podemos destacar: medições, simulações, modelagens analítica e híbrida.. 2.2.1 Medições Esta técnica pode ser aplicada somente se o programa estiver totalmente implementado. Normalmente, utilizamos as medições em conjunto com outras técnicas de modelagem, avaliação e predição de desempenho, exceto quando desejamos apenas avaliar ou comparar o desempenho de sistemas semelhantes. Neste caso, devemos considerar, ao planejar uma medição de desempenho, o propósito da medição, a seleção da carga de trabalho e sua implementação, os dados a serem coletados, a instrumentação utilizada na coleta destes dados e a forma de validação dos resultados. Todos os experimentos de medição de desempenho requerem três elementos básicos: o sistema sob teste, os geradores de carga de trabalho e a configuração que irá coletar os dados de desempenho.  Selecionando uma Carga de Trabalho. O desempenho de um sistema pode ser medido em qualquer tempo com qualquer carga de trabalho. Alguns administradores de sistemas coletam regularmente dados de desempenho como parte do monitoramento do estado geral do sistema. As medidas de desempenho e análises baseadas em sistemas e cargas reais parecem atrativas num primeiro momento, mas possuem diversas limitações. A carga aplicada a um sistema pode variar muito de dia para dia ou até mesmo de minuto a minuto, e existe a dificuldade, senão a impossibilidade, de executar a carga de um dia em particular em uma data posterior. Entretanto, a maioria das medidas de desempenho baseia-se em uma carga sintética, que possui características similares a uma carga real, mas é definida e implementada de maneira a ser reproduzida. Em muitos casos, a carga é descrita através de alguns parâmetros-chave, e o objetivo da medição é avaliar como as mudanças nos parâmetros de carga afetam o desempenho do sistema.  Configuração. O sistema sob teste pode ser configurado para coletar uma variedade de métricas. Muitos benchmarks simplesmente medem a latência ou tempo de resposta e a taxa de serviço ou a quantidade de tarefas que o sistema consegue realizar em um determinado tempo. Entretanto, a.

(17) 8. informação sobre a utilização do processador e de outros recursos é muito útil na identificação de pontos de contenção no sistema ou para futuros esforços de modelagem. Existem contadores implementados tanto em software quanto em hardware que fornecem informação útil de desempenho. Por exemplo, falhas de página podem ser gravadas em um contador na CPU, no kernel do sistema operacional ou em ambos. A partir dos valores medidos entre execuções consecutivas do programa, podemos perceber a variação do comportamento do desempenho da aplicação. Durante os testes experimentais, medimos os valores de algumas variáveis diretamente relacionadas com o desempenho do sistema como, por exemplo, o tempo de execução. Entre um teste e outro, modificamos o código do programa visando melhorá-lo. Esse processo se repete até que o resultado obtido com as alterações seja satisfatório. Um dos objetivos do processo descrito é encontrar informações ou padrões relacionados com a aplicação que poderão ser ajustados para melhorar o desempenho do sistema. Para alcançarmos o objetivo descrito anteriormente, podemos utilizar monitores de software ou de hardware. Os monitores são vistos como uma ferramenta de auxílio, utilizada para monitorar determinadas atividades de um sistema. Esses monitores coletam estatísticas de desempenho, analisam os dados obtidos e apresentam os resultados alcançados [JAI 91]. Geralmente, os monitores utilizam comandos de linguagem de alto nível para desempenhar suas funções. As variáveis medidas podem variar de um sistema para outro, por exemplo, em aplicações do tipo cliente/servidor podemos estar interessados em medir o tempo de resposta do servidor, enquanto que em um programa de multiplicação de matrizes desejamos obter o tempo total de execução. Pelo fato de inserirmos no código monitores, sobre cargas (overheads), etc. isto pode afetar, conseqüentemente o comportamento do sistema. Instruções adicionais devem ser executadas, provocando um aumento natural, mesmo que pequeno, no tempo de execução do programa. Por esse motivo, os dados coletados durante os testes experimentais podem não representar precisamente os valores reais.. 2.2.2 Simulações A simulação é utilizada tanto em avaliação de desempenho, quanto na validação de modelos analíticos. Ao contrário das medições, as simulações baseiam-se em modelos abstratos do sistema. Logo, não exige que o sistema esteja totalmente implementado.

(18) 9. para ser aplicada. Assim, os modelos utilizados durante a simulação são elaborados através das características essenciais do projeto do sistema, sendo que a complexidade variar de um sistema para outro. Durante uma simulação podemos controlar com maior eficiência os valores assumidos por parâmetros do sistema. Com isto, fica mais fácil obter informações relevantes para a avaliação de desempenho. Além disto, as simulações permitem propor modelos mais detalhados, gerando resultados mais precisos. Através de simulações, podemos verificar e prever o comportamento de programas sobre arquiteturas, ainda não utilizadas em testes. Para isto, existe uma técnica de simulação conhecida como execution-driven. Basicamente, esta técnica intercala execuções da aplicação na arquitetura real com simulações sobre a arquitetura desejada [HU 97]. Nessa técnica, uma aplicação paralela é vista como uma composição de eventos globais separados por computações locais. Uma computação local é restrita a um processo específico e não pode ser vista nem influenciada por outros processos. Já um evento global, pode ser visto e influenciado por outros processos. Este tipo de evento pode ocasionar a mudança do caminho de execução de um programa paralelo. As operações básicas de um evento global são o acesso à memória compartilhada e as atividades de sincronização [HU 97]. Apesar de ser uma técnica relativamente nova, esta tem se mostrado bastante eficiente.. 2.2.3 Modelagem Analítica A modelagem analítica utiliza um conjunto de equações e funções matemáticas para descrever o comportamento de uma aplicação. Os fatores que influenciam e interferem no comportamento da aplicação são modelados e representados através dos parâmetros de equações matemáticas. Essas equações são chamadas de modelos analíticos. Apesar desses modelos considerarem parâmetros específicos de uma arquitetura, podem ser facilmente adaptados para outras plataformas. Durante a construção dos modelos analíticos, devemos levar em consideração a sua complexidade e praticidade. Esses aspectos e a precisão desses modelos estão diretamente relacionadas com a quantidade de parâmetros existentes nas funções e equações elaboradas. Os modelos analíticos permitem uma análise ampla e aprofundada em relação aos efeitos causados pelos parâmetros definidos nas equações sobre a aplicação. Além.

(19) 10. disso, também podemos estabelecer possíveis relacionamentos entre cada um dos parâmetros considerados. A modelagem analítica, quando comparada às demais técnicas de avaliação de desempenho, apresenta menor custo de execução. Para validar os resultados alcançados através dos modelos elaborados, a modelagem analítica pode compará-los aos valores reais medidos em testes experimentais. Esses valores poderão comprovar as predições realizadas através dos modelos analíticos. Por outro lado, esses modelos também podem ser validados através de simulações [JAI 91]. Segundo [MEI 95], podemos seguir as seguintes modelagens dentro da modelagem analítica:  Modelagem com Parâmetros Escalares: o comportamento do sistema é modelado através de um conjunto de parâmetros escalares, que caracteriza o comportamento do sistema sob condições especificadas durante a sua elaboração. A precisão do modelo depende da quantidade de parâmetros considerados na modelagem. Parâmetros, como sobre carga do sistema (overhead) do sistema operacional, dificilmente são modelados e, se considerados, podem tomar o modelo complexo e difícil de ser aplicado.  Modelagem com Funções: expressa a influência de parâmetros relacionados com o software e o hardware sobre o tempo de execução da aplicação. Apesar dessa modelagem possibilitar o desenvolvimento de modelos precisos, quando comparada à modelagem com parâmetros escalares, a complexidade desses modelos pode ser maior. Isso acontece, pois é necessário descobrir o tipo de função matemática (linear, quadrática, logarítmica, etc) que melhor representa o comportamento dinâmico do sistema. Além disso, é preciso reconhecer e modelar os parâmetros que serão utilizados pelas funções, para que o modelo seja consistente.  Modelos Estatísticos: utiliza ferramentas de modelagem estatística, como os modelos de Markov, para caracterizar o comportamento do sistema paralelo. Nessa abordagem, os parâmetros definidos são ferramentas estatísticas. Normalmente, esses modelos são utilizados para analisar o comportamento de sistemas que possuem sua carga de trabalho definida. Os parâmetros estatísticos são utilizados para representar o comportamento assintótico do sistema..

(20) 11. 2.2.3.1 Modelagem Baseada em Descrição Essa modelagem está baseada em informações ou descrições oferecidas pelo usuário sobre a estrutura e o comportamento do sistema que está sendo modelado. Para a elaboração do modelo do programa, a modelagem baseada em descrição utiliza uma representação gráfica auxiliar (baseada em grafos), denominada task graph, que indica os potenciais pontos da aplicação. Por outro lado, alguns parâmetros relacionados às características do hardware também são considerados durante a elaboração do modelo [GUB 96] [LAI 02].. 2.2.3.2 Modelagem com Análise Estática Nessa técnica, o ponto de partida para o processo de modelagem é a própria aplicação. Essa modelagem obtém informações do sistema através de uma análise realizada pelo próprio compilador. Como a análise do programa acontece em tempo de compilação, dizemos que é uma modelagem estática. Existem ferramentas específicas para o desenvolvimento essa abordagem, no entanto, o alto custo associado inibe a sua aplicação [GUB 96] [LAI 02].. 2.2.4 Modelagem Híbrida Combina características de vários modelos distintos, utilizando conceitos e estratégias das diferentes técnicas de modelagem existentes. Essa abordagem vem sendo bastante utilizada e os resultados alcançados têm sido bastante satisfatórios [MON 02].. 2.3 Sistemática para Avaliação de Desempenho Para efetuar uma avaliação de desempenho, além de escolher e reconhecer a técnica a ser aplicada, outros aspectos também devem ser considerados. É importante definir e seguir um esquema sistemático, que descreva todos os passos envolvidos em cada etapa do processo de avaliação e predição de desempenho. Essas etapas compreendem atividades que vão desde a definição e compreensão do sistema até a apresentação dos resultados alcançados com os modelos de predição. Apesar de sabermos que as métricas, a carga de trabalho e a técnica de avaliação de desempenho escolhida variam de um sistema para outro, existe um conjunto de passos comum envolvidos nessas atividades [JAI 9l]..

(21) 12. Antes de iniciarmos o processo de avaliação, devemos definir os critérios que serão utilizados durante o estudo. Esses critérios são conhecidos como métricas de desempenho [HU 97] e permitem avaliar o desempenho de um sistema específico ou fazer comparações entre sistemas equivalentes. O tempo de resposta de um sistema é uma métrica que pode ser escolhida. Durante as definições dos critérios, freqüentemente, escolhemos as métricas mais fáceis de serem medidas e calculadas, ao invés das mais relevantes. Isso é um erro comum que deve ser evitado. Não existe um conjunto padrão de métricas que devem ser utilizadas, uma vez que essa escolha depende das particularidades de cada sistema. Após definidas as métricas de avaliação, devemos identificar as fontes de influência sobre o desempenho do sistema. Os parâmetros que representam essas fontes de influência identificadas podem ser divididos em duas categorias [JAI 91]: de sistema e de carga de trabalho. Os parâmetros de sistema, geralmente, não variam e podem estar relacionados tanto com o hardware quanto com o software. Já os parâmetros da carga de trabalho (workload) estão relacionados com as aplicações. Após a escolha dos parâmetros descritos anteriormente, devemos escolher a técnica de modelagem e avaliação de desempenho e projetar o experimento, definindo a seqüência do processo. O objetivo principal é alcançar o melhor resultado possível com um esforço reduzido, poupando tempo e trabalho. Durante o projeto do experimento, definimos o número de medições a serem realizadas, a estratégia de seleção dos dados e outras particularidades. Os resultados da avaliação dependem muito da qualidade do projeto elaborado. Por último, devemos analisar e interpretar os resultados alcançados durante os experimentos. Os resultados obtidos nas medições e simulações podem diferir a cada vez que o experimento é repetido. Por esse motivo, saber interpretá-los é fundamental em avaliação de desempenho. Simplesmente apresentar resultados e não compreendêlos restringe muito o trabalho realizado. A apresentação dos resultados e conclusões deve ser feita de forma fácil e prática, de modo que as pessoas possam compreender como o trabalho foi conduzido. A Figura 2.1, a seguir, ilustra a sistemática descrita acima..

(22) 13. Definir o Sistema e os objetivos do estudo. Apresentar os resultados. Analisar e interpretar os dados. Projetar o experimento. Listar serviços e saídas do sistema. Sistema Selecionar carga de trabalho (worload). Selecionar métricas. Listar parâmetros. Selecionar Fatores. Selecionar técnicas de avaliação. Figura 2-1 Sistemática para Avaliação de Desempenho. 2.4 Métricas de Avaliação – uma visão geral Todas as métricas de desempenho baseiam-se no comportamento do sistema ao longo do tempo. As principais métricas que podem ser observadas por um usuário ou uma outra entidade externa ao sistema são:. 2.4.1 Latência ou tempo de resposta Esta métrica mede o tempo entre a requisição de alguma ação e a obtenção do resultado. Sua resposta é medida em unidades de tempo decorrido. Por definição, a métrica de latência deve especificar um evento de início e um evento de término, ou seja, quando começar a medição do atraso e quando terminá-la. Por exemplo:  O tempo decorrido entre digitar um novo endereço em um navegador Web e a página ser completamente exibida;  O tempo que um pacote é mantido por um roteador até que seja retransmitido;  O tempo decorrido entre receber o pedido de um item em uma loja on-line e a atualização da “quantidade em estoque” que é reportado ao cliente..

(23) 14. 2.4.2 Taxa de Serviço Esta métrica mede a quantidade de trabalho realizado por unidade de tempo ou a taxa em que novos resultados são obtidos. Sua medida é realizada com base em unidades de tarefas executadas em um intervalo de tempo e é inversamente proporcional ao tempo de resposta por tarefa. Por exemplo:  O número de transações completas por minuto;  Quantidade de gigabytes de dados escritos em fita por hora;  O número de acessos à memória por segundo;  A quantidade de megabits transmitidos por segundo, entre outros. O termo “largura de banda” é normalmente usado para descrever a vazão máxima teórica de um fluxo de dados ou de outro componente. Por exemplo, o barramento de dados de 32 bits de largura, operando a um clock de 100 MHz, tem uma largura de banda aproximada de 3,2 bilhões de bits por segundo. Uma vez que os componentes impõem uma sobrecarga em termos de cabeçalhos de pacotes, os atrasos entre transporte dos blocos de dados, ou ainda, os protocolos de controle, a vazão útil é sempre menor que a largura de banda. A eficiência é definida como a razão entre a vazão útil e a largura de banda. Para algumas aplicações, a métrica de vazão pode ser normalizada sobre alguma outra característica do sistema como, por exemplo, custo ou consumo de energia. É prática comum especificar a vazão considerando as restrições de latência e vice-versa.. 2.4.3 Disponibilidade Esta métrica mede quanto tempo o sistema está disponível para uma operação usual ou, podemos dizer também que é a fração de tempo em que o sistema está disponível. Entretanto, sozinha, a métrica disponibilidade não é completa, podemos dizer que ela está associada a confiabilidade do sistema.. 2.4.4 Confiabilidade Esta métrica é usada para relatar o tempo médio entre falhas (Mean Time Between Failures ou MTBF), que indica na média o período em que um sistema é utilizável..

(24) 15. Uma outra métrica relacionada é o tempo médio para reparos (Mean Time To Repair ou MTTR), que quantifica o tempo necessário para recuperar o sistema de uma falha.. 2.4.5 Utilização A métrica de utilização, só pode ser observada de dentro do sistema. A informação de utilização é vital para entender e prever o desempenho do sistema. É importante ressaltar que há dezenas de métricas, dependendo do ambiente. Por exemplo, perda de pacotes em redes, tempo de consulta em um banco de dados ou capacidade de processamento do middleware. Sendo assim, podemos dizer que esta métrica é a fração de tempo em que um componente do sistema, por exemplo, a CPU, o disco rígido, etc. realizou o serviço em relação a um período de tempo observado. Portanto, os valores de utilização estão entre 0 e 1. Teoricamente, a vazão máxima de um sistema é atingida quando o mais utilizado dos dispositivos atinge a utilização igual a 1. Na prática, o tempo de resposta aumenta rapidamente quando a utilização atinge o máximo. Dessa forma, muitos sistemas são projetados para manter uma utilização abaixo da capacidade máxima, em geral entre 60% e 80%.. 2.5 Avaliação de desempenho de um Middleware Como apresentado anteriormente, as métricas para avaliação de desempenho baseiam-se no comportamento do sistema como um todo. Segundo [NIM 98], podemos definir os principais critérios de avaliação de desempenho de um middleware da seguinte maneira:  Vazão: estes testes visam verificar o número de requisições que podem ser processadas pelo ORB e o número de bytes que pode ser transferido em um período de tempo e sua eficiência pode ser avaliada pela variação na quantidade de clientes acessando o servidor. Este teste também pode mostrar as características de sincronização do ORB.  Latência: estes testes são utilizados para verificar o tempo que é necessário para atender a uma requisição do cliente ao servidor. No teste de latência pode ser observado o tempo de uma requisição ou o tempo de resposta ou o tempo total envolvido entre requisição e resposta. A latência é um importante.

(25) 16. parâmetro para aplicações onde o atraso na resposta para a primeira requisição é importante.  Escalabilidade: pode ser visto de duas maneiras diferentes, uma seria a escalabilidade em um sistema final e a outra seria a escalabilidade em um sistema distribuído numa rede. Em um sistema final, o número de objetos que podem ser suportados por este sistema é uma medida que pode ser observada. Em um sistema distribuído, o número de sistemas finais que fazem parte do cenário da aplicação pode ser um parâmetro a ser observado. Nestes testes é verificada a capacidade do servidor em processar eficientemente as requisições do cliente.  Confiabilidade: este teste se refere ao fator do servidor ser capaz de se recuperar caso ocorra uma falha no sistema e determinar qual o seria o tempo envolvido nesta recuperação. Este é um importante fator quando falamos de sistemas distribuídos que trabalham com alta carga de trabalho.  Marshalling e Demarshalling: marshalling refere-se a tradução do pedido da solicitação em uma mensagem de rede. Isto consiste na inicialização da requisição, passagem do objeto, do nome do objeto e dos argumentos que serão deste objeto. O tempo perdido neste processo todo é considerado um critério de avaliação. O processo de demarshalling é o oposto, ou melhor, é o processo contrário da operação marshalling.. 2.6 Fatores que podem influenciar desempenho de um Middleware. na. avaliação. de. Segundo [MYE 02], várias considerações devem ser discutidas quando se fala em desempenho de middleware, como por exemplo:  Tráfego da Rede: devido ao grande número de usuários, dispositivos e aplicações que podem estar atuando sobre uma rede e, muitas vezes, acessando a mesma informação, pode fazer deste fator um dos principais influenciadores no desempenho do sistema como um todo. Web sites com grande carga multimídia, imagens, etc. influenciam no desempenho de uma rede como um todo..

(26) 17.  Largura de Banda: este fator influencia diretamente no desempenho de uma maneira em geral, pois quanto mais lenta a comunicação mais fragmentados serão os pacotes transmitidos por esta rede.  Gerenciadores de Tráfego: toda e qualquer carga que é adicionada “desnecessariamente” sobre uma rede acaba afetando o seu desempenho. A maioria dos gargalos criados em uma comunicação surge destes gerenciadores.  Controladores de Tráfego: estes controladores controlam as entradas e saídas de uma interface de rede. Os mesmos podem ser vistos em dois grupos: o primeiro seria o controlador de largura de banda e o segundo seria o controlador de prioridades, que verifica quais “aplicações” possui prioridade no momento de utilização de uma rede.  Balanceamento de Carga: a carga de uma rede pode ser dividida de maneira desigual entre os usuários e/ou aplicações, como por exemplo: navegadores, servidores Web, servidores de transação, servidores de banco de dados e agora serviços com middleware..

(27) 18. Capítulo 3. Este capítulo apresenta os conceitos básicos de middleware. No final deste capítulo abordaremos com mais detalhes um tipo específico de middleware, um orientado a objetos, o CORBA.. 3. Middleware. 3.1 Introdução Na literatura atual, o termo middleware possui várias definições, como podemos observar a seguir:  O termo middleware caracteriza uma camada de software que possibilita comunicação entre aplicações distribuídas [ROS 04].  Pode também ser definido como o software que conecta aplicações, permitindo que estas troquem dados entre si [SLA 01].  É uma classe de software designada a ajudar a gerenciar a complexidade e a heterogeneidade inerentes em sistemas distribuídos. É definido como uma camada de software que fica entre o sistema operacional e a aplicação propriamente dita, como pode ser observado na Figura 3-1 [BAK 01]. Baseado nestes conceitos previamente apresentados, podemos considerar que todos demonstram o mesmo objetivo para a camada middleware, que seria o de diminuir a complexidade e a heterogeneidade dos diversos sistemas existentes, provendo serviços que realizam a comunicação entre estas categorias de aplicações de forma transparente às mesmas..

(28) 19. Figura 3-1 Camada Middleware no Contexto. A adaptação entre sistemas heterogêneos é necessária, por exemplo, quando um sistema atual deve interagir com sistemas obsoletos ou com diferentes empresas. Um middleware é dividido em componentes do ambiente de programação e do ambiente de execução.. Figura 3-2 Comunicação através de middleware.

(29) 20. A Figura 3.2 ilustra o processo de comunicação entre aplicações distribuídas através de um middleware. Todo o processo é transparente para as aplicações e a heterogeneidade existente é tratada também pelo middleware. Inicialmente, um middleware tinha a função básica de unir os componentes de um programa distribuído, ditando a maneira pela qual estes componentes interagiam. Atualmente, sua função é integrar aplicações completas entre e dentro de organizações. No que se refere à aplicações escritas em diferentes linguagens de programação, poucos middlewares suportam esta característica. Um exemplo de integração entre linguagens é o Commom Object Request Broker Architecture (CORBA), pois neste middleware é possível fazer o mapeamento de uma interface em muitas linguagens de programação [VIN 02]. Ao longo das últimas décadas, surgiram diversas iniciativas para se criar um padrão de middleware que resultasse em uma solução para a diversidade de sistemas atualmente em uso. Uma das funcionalidades do middleware é a de possibilitar que as aplicações possam ser escritas de modo mais independente possível do hardware e do sistema operacional, permitindo assim que um mesmo código de aplicação possa ser carregado e executado em diferentes equipamentos. Em resumo, o middleware é um software capaz de interpretar os aplicativos e traduzi-los na linguagem do sistema operacional em que reside. As diversas necessidades existentes em sistemas distribuídos fizeram com que muitos sistemas de middleware fossem desenvolvidos desde que o conceito de computação distribuída foi criado. Estes diversos produtos podem ser categorizados por conta deles apresentarem características comuns e resolverem problemas específicos de sistemas distribuídos.. 3.2 Categorias de Middleware As categorias de middleware de acordo com [NEU 02], [EMM 00], [BAK 03] são apresentadas a seguir:. 3.2.1 Middleware Transacional Esta categoria de middleware suporta transações envolvendo componentes que são executados em hosts distribuídos. Estes sistemas de middleware usam o protocolo de.

(30) 21. controle para transações distribuídas denominado two-phase commit e têm como finalidade principal atender as necessidades que aplicativos têm de realizar controle para transações distribuídas. A arquitetura típica destes sistemas de middleware está mostrada na Figura 3-3 e mostra que sistemas de middleware enquadrados nesta categoria têm a responsabilidade de gerenciar processos transacionais distribuídos entre diversas aplicações e bancos de dados diferentes.. Figura 3-3 Papel do Middleware Transacional. Um middleware transacional usualmente é utilizado em processos de sincronização de dados entre aplicações e instâncias de SGBDs diferentes, que interagem através de uma mesma rede física.. 3.2.2 Middleware Procedural Mecanismos de RPC (Remote Procedure Call) [BIR 84] constituem este tipo de middleware. A idéia de RCP nasceu no início dos anos 80 e desde então vários fabricantes de software vêm disponibilizando tal mecanismo como uma parte dos seus sistemas operacionais. Então, padrões de RPC foram estabelecidos e a maioria das implementações de sistemas operacionais, notadamente as famílias Unix e Windows, disponibilizam formas de RPC para acessar processos e programas que neles são executados. Na Figura 3.4, é mostrado claramente que o sistema operacional faz o papel de interpretar e de encaminhar as chamadas remotas de um determinado programa para outro através da rede. Por conta disto, sistemas baseados em RPC são dependentes de.

(31) 22. recursos internos do sistema operacional, necessitando muitas vezes de alterações para se tornarem portáveis de um sistema operacional para outro.. Figura 3-4 Visão Geral de um Middleware Procedural. 3.2.3 Middleware Orientado a Mensagens Um middleware orientado a mensagens, cuja abreviatura é MOM, suporta um tipo de comunicação entre sistemas que é baseado fundamentalmente na troca de mensagens. Esta troca normalmente se dá de forma assíncrona e quase sempre ordenada. Por conta disso, as mensagens são convenientemente processadas e os resultados destes processamentos disponibilizados para verificação futura. Mensagens podem ser tratadas por aplicações como eventos, em última instância. Estes eventos são ordenadamente tratados e processados. Estas mensagens podem ser priorizadas nas filas de processamento, descartadas caso estejam obsoletas, ou mesmo mantidas naquelas se houver motivo funcional para que isto aconteça. Os MOMs representam a categoria de sistemas de middleware mais versátil e difundida comercialmente, pois as suas características funcionais e sua robustez os tornam aptos a serem usados em uma ampla gama de aplicações e de funcionalidades. Na Figura 3-5 temos uma visão dos elementos que compõem este middleware..

(32) 23. Figura 3-5 Visão Geral dos Elementos de um Middleware Orientado a Mensagens. 3.2.4 Middleware Orientado a Objetos Este tipo de middleware é uma evolução dos sistemas de middleware procedurais. A idéia de chamada remota de procedimentos persiste, só que com mecanismos mais sofisticados associados aos conceitos de orientação a objetos (OO). Assim, nos mecanismos de chamada a procedimentos, denominadas em OO de métodos, são contemplados os conceitos de herança e de referências, aplicados em linguagens de programação que usam o paradigma OO..

(33) 24. Figura 3-6 Visão Geral de um Midleware de Objetos. A Figura 3.6 mostra uma visão geral das partes componentes de um middleware orientado a objetos. Neste contexto, surge um componente de conversão de chamadas e de objetos em dados a serem enviados pela rede – o stub. Além do stub, o skeleton aparece como o elemento que converte dados da rede em chamadas e objetos e converte o retorno de objetos e de exceções em dados a serem retornados para a aplicação cliente através da rede. Neste contexto, surgem elementos responsáveis por fazer com que as aplicações possam realizar chamadas remotas de métodos com parâmetros e retornos definidos como objetos de forma transparente e simples. Os mecanismos de transmissão e de recepção de dados são os usuais, normalmente utilizados por outros sistemas de middleware. Alguns produtos e padrões incluídos na classificação de middleware orientado a objetos incluem o CORBA (Common Object Request Broker Architecture), o COM (Component Object Model), o RMI (Remote Method Invocation) e o padrão EJB (Enterprise JAVA Beans) [SUN 0?]..

(34) 25. 3.3 Middleware Orientado a Objetos - CORBA 3.3.1 Conceito CORBA significa Common Object Request Broker Architecture, e define uma especificação que permite aos objetos de sistemas distribuídos comunicar-se entre si de forma transparente, não importando onde eles estejam, em que plataforma ou sistema operacional estejam rodando, em que linguagem de programação eles foram implementados e até mesmo qual protocolo de comunicação eles utilizam. O CORBA 1.1 foi inicialmente implementado em 1991 como sendo um produto intelectual do Object Management Group [OMG 91], um consórcio de mais de 800 companhias das mais diferentes áreas (IBM, Canon, DEC, Philips, Sun, Apple, etc, assim como grandes usuários como Citicorp, British Telecom, American Airlines, e outros), interessadas em prover uma estrutura comum para o desenvolvimento independente de aplicações, usando técnicas de orientação a objeto em redes de computadores heterogêneas. Ao contrário do que muitos pensam, a OMG produz especificações para o CORBA e não aplicações, que tornam a computação orientada a objeto possível. Este modelo baseado em objetos permite que métodos de objetos sejam ativados remotamente, através de um elemento intermediário chamado ORB (Object Request Broker) situado entre o objeto propriamente dito e o sistema operacional, acrescido de funcionalidades que tornam possível a comunicação através de rede. Introduzido como parte do CORBA 2.0 em dezembro de 1994, o Internet InterORB Protocol (IIOP) é o outro sucesso da OMG. Antes do IIOP, a especificação CORBA definia somente interação entre objetos distribuídos criados pelo mesmo fornecedor. Os objetos tinham que ser desenvolvidos por uma implementação específica. Usando-se IIOP, a segunda especificação CORBA torna-se a solução definitiva para a interoperabilidade entre objetos que não estão presos a uma plataforma ou padrão específico. Como uma arquitetura que provê uma estrutura para integração entre objetos diferentes, CORBA é um grande sucesso. Entretanto, ele é apenas um pedaço de um grande quadro, Figura 3-7, chamado Object Management Arquitecture (OMA) [OMG 95]. Seus principais componentes são:  Núcleo CORBA e ORB - manipulam requisições entre objetos;.

(35) 26.  Serviços CORBA - definem serviços ao nível de sistema que ajudam a gerenciar e manter objetos;  Facilidades CORBA - definem facilidades e interfaces no nível de aplicação manipulação de dados e armazenamento;  Objetos de Aplicação - são os objetos propriamente ditos no nível visível de aplicação.. Figura 3-7 Componentes da OMA. O ORB é o componente mais importante da arquitetura OMA. Ele permite que objetos façam e recebam requisições de métodos transparentemente em um ambiente distribuído e heterogêneo. O CORBA é uma especificação das interfaces do ORB, ou melhor, um modelo concreto para a especificação abstrata dada no documento que define a arquitetura OMA. [OMG 95] [OMG 97]. 3.3.1.1 Object Request Broker O ORB é a estrutura mais importante da arquitetura CORBA. Dele é a função de intermediar todas as transferências entre cliente e servidor, e fazer com que a transação seja transparente para cada uma das partes durante todo o processo. A Figura 3-8 mostra uma requisição oriunda de um cliente sendo enviada através do intermédio do ORB a uma implementação de objeto. O ORB é responsável pela localização do objeto ao qual se destina a requisição, assim como, o envio dos parâmetros da requisição no formato aceito por este objeto. Também é função do ORB, o retorno de parâmetros de saída da requisição para o cliente, se assim houver..

(36) 27. Figura 3-8 Uma Requisição Enviada Através do ORB. A interface com a qual o cliente tem contato é totalmente independente de qualquer fator relacionado à heterogeneidade do ambiente distribuído no qual se encontra, como por exemplo: a localização do objeto, a linguagem de programação utilizada para sua implementação e a ordenação de bytes da máquina na qual se executa o objeto. Entretanto, ORB diferentes podem apresentar características de implementação diferentes, resultando em serviços prestados a objetos e clientes com qualidades e propriedades diferentes. Na Figura 3-9 é explicitada a estrutura de um ORB e suas interfaces.. Figura 3-9 Estrutura de um ORB. A requisição de um serviço a um objeto pode ser feita pelo cliente, utilizando as rotinas stub geradas na compilação da descrição de interface do objeto ao qual se destina o pedido, quando tiver acesso a estas. Caso contrário, pode-se utilizar a interface de invocação dinâmica, Dynamic Invocation Interface – DII, sendo necessário para.