cco-12

138 visualizações

Publicada em

  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

cco-12

  1. 1. UNIVERSIDADE ANHEMBI MORUMBI DÊNIO ROBSON VAL SILVA FELIPE BARATOJO FLORES NEIDE SOARES SALES LINGUAGEM DE PROGRAMAÇÃO INTERPRETADA UTILIZADA NA CONFIGURAÇÃO DE APLICATIVOS VOLTADOS PARA SISTEMAS MULTI-PLATAFORMA COM IMPLEMENTAÇÃO EM AMBIENTE PARAVIRTUALIZADO São Paulo 2010
  2. 2. DÊNIO ROBSON VAL SILVA FELIPE BARATOJO FLORES NEIDE SOARES SALES LINGUAGEM DE PROGRAMAÇÃO INTERPRETADA UTILIZADA NA CONFIGURAÇÃO DE APLICATIVOS VOLTADOS PARA SISTEMAS MULTI-PLATAFORMA COM IMPLEMENTAÇÃO EM AMBIENTE PARAVIRTUALIZADO Orientador: Professor Msc. Luciano Freire São Paulo 2010 Monografia apresentada como exigência parcial para a obtenção do título de bacharel em Ciência da Computação pela Universidade Anhembi Morumbi
  3. 3. UNIVERSIDADE ANHEMBI MORUMBI BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO DÊNIO ROBSON VAL SILVA FELIPE BARATOJO FLORES NEIDE SOARES SALES LINGUAGEM DE PROGRAMAÇÃO INTERPRETADA UTILIZADA NA CONFIGURAÇÃO DE APLICATIVOS VOLTADOS PARA SISTEMAS MULTI-PLATAFORMA COM IMPLEMENTAÇÃO EM AMBIENTE PARAVIRTUALIZADO Aprovado ______________________________________________________________________ Prof. Msc. Luciano Freire Universidade Anhembi Morumbi ______________________________________________________________________ Prof................................ Universidade Anhembi Morumbi ______________________________________________________________________ Prof. .............................. Universidade Anhembi Morumbi Monografia apresentada como exigência parcial para a obtenção do título de bacharel em Ciência da Computação pela Universidade Anhembi Morumbi
  4. 4. UNIVERSIDADE ANHEMBI MORUMBI Dedicamos este trabalho de conclusão de curso a todos os nossos familiares que nos apoiaram, à Anhembi Morumbi por ter acreditado no Curso Superior em Ciência da Computação e ao orientador, Professor que, com dedicação e conhecimento, orientou-nos no decorrer deste trabalho.
  5. 5. AGRADECIMENTOS Agradecemos aos colegas que contribuíram e incentivaram para a realização deste trabalho e também aos professores que com sabedoria nos acompanharam nestes anos em que decorreu o curso e, em especial, ao nosso orientador que nos acompanhou em todas as etapas deste trabalho. Também aos amigos e à família pela compreensão de nossa ausência para a elaboração do mesmo.
  6. 6. “Nossas dúvidas são traidoras e nos fazem perder o que, com freqüência, poderíamos ganhar, por simples medo de arriscar.” (William Shakespeare)
  7. 7. RESUMO Esta monografia apresenta um breve estudo sobre a tecnologia da virtualização explorando os benefícios dos tipos de virtualização existentes, e principalmente da paravirtualização, com o objetivo de desenvolver uma linguagem interpretada para ser utilizada em aplicativos hospedeiros. São praticamente inexistentes as linguagens de programação voltadas à configuração e, embora a linguagem seja voltada a qualquer plataforma, a implementação foi realizada em um ambiente paravirtualizado por facilitar a criação de ambientes diversificados sem necessidade de hardware adicional, apresentando um desempenho razoável. Este trabalho não envolve a criação de um compilador, mas de uma linguagem, na condição de linguagem de extensão aplicada ao software hospedeiro Asterisk e às etapas para a implementação da mesma em um ambiente paravirtualizado. Para o desenvolvimento deste trabalho, foi necessária a realização de um estudo a respeito dos tipos de virtualização, através da análise de documentos da IBM, Xen, VmWare e outros fabricantes importantes, para que então optássemos pela utilização do Xen como software de virtualização. Quatro etapas principais foram necessárias para a conclusão do trabalho: a pesquisa a respeito das tecnologias existentes, tanto para virtualização como para utilização da linguagem interpretada; a criação do ambiente paravirtualizado; a criação da linguagem interpretada utilizada no aplicativo hospedeiro Asterisk e a junção do ambiente virtualizado criado com a linguagem desenvolvida. Palavras-Chave: Virtualização, Linguagem Interpretada, Xen, Asterisk.
  8. 8. ABSTRACT This monograph presents a brief study about virtualization technology by exploring the benefits of existing virtualization types, and mainly the paravirtualization with the goal of developing an interpreted language to be used in host applications. Practically it doesn’t exist programming languages directed to configuration and although the language is geared to any platform, the implementation was done in a paravirtualized environment by facilitating the creation of diversified environments without requiring additional hardware and showing reasonable performance. The work does not involve the creation of a compiler, but a language, as an extension language applied to the host software Asterisk, and the steps to implement it in a paravirtualized environment. To develop the work was necessary to carry out a study about the types of virtualization through documents from IBM, Xen, VmWare and other major manufacturers to take back the conclusion that we should use the Xen virtualization software. Four main steps were necessary for completion of the work: research on existing technologies, for both to use virtualization as the interpreted language; the creation of paravirtualized environment; the creation of the interpreted language used in the host application Asterisk, and the join of the virtualized environment created with the language developed. Key words: Virtualization, Interpreted Language, Xen, Asterisk.
  9. 9. LISTA DE FIGURAS Figura 1 - Várias máquinas virtuais em um único hardware.......................................... 17 Figura 2 – Tecnologia com mais impacto na transformação dos processos de negócio 20 Figura 3 - Emulação de hardware................................................................................... 21 Figura 4 - Virtualização completa .................................................................................. 22 Figura 5 - Paravirtualização............................................................................................ 23 Figura 6 - Virtualização de sistema operacional ............................................................ 24 Figura 7 – VmWare ESX ............................................................................................... 28 Figura 8 – Componentes do Xen.................................................................................... 32 Figura 9 – User mode Linux........................................................................................... 33 Figura 10 - Linguagem interpretada............................................................................... 38 Figura 11 - Linguagem compilada.................................................................................. 40 Figura 12 – Instalação Xen............................................................................................. 44 Figura 13 – Instalando o Hypervisor e Ferramentas 1 ................................................... 45 Figura 14 – Domínio 0 configurado ............................................................................... 45 Figura 15 – Processo de inicialização............................................................................. 47 Figura 16 – Tratamento de chamada .............................................................................. 47 Figura 17 – Compilação do módulo ............................................................................... 48 Figura 18 – Diretório de módulos do Asterisk ............................................................... 48 Figura 19 – Arquivo sip.conf.......................................................................................... 51 Figura 20 – Topologia final............................................................................................ 59 Figura 21 – Módulo carregado com sucesso .................................................................. 60 Figura 22 – Módulo não carrega sem extensions.dfn..................................................... 60 Figura 23 – CDR ............................................................................................................ 61 Figura 24 – Ligação realizada ........................................................................................ 62
  10. 10. LISTA DE TABELAS Tabela 1 – Ferramentas de virtualização.........................................................................26 Tabela 2 – Suporte Xen 3.0.............................................................................................30 Tabela 3 – Suporte Xen 2.0.............................................................................................31 Tabela 4 – Tipos de linguagens.......................................................................................35
  11. 11. LISTA DE ABREVIATURAS E SIGLAS AMD – Advanced Micro Devices AMD-V – Advanced Micro Devices Virtualization API (Application Programming Interface): Interface de Programação de Aplicações BIOS (Basic Input/Output System): Sistema básico de entrada/saída CD-ROM (Compact Disk Read Only Memory): Disco Compacto com Memória somente leitura CMS – Conversational Monitor System CPU (Central Processing Unit): Unidade de Processamento Central GHz – Gigahertz HD (Hard Disk): Disco Rígido IAX – Inter Asterisk Exchange IBM – International Business Machines IDC – International Data Corporation IDE (Integrated Development Environment): Ambiente de Desenvolvimento Integrado IETF – Internet Engineering Task Force Intel-VT (Intel Virtualization Technology): Tecnologia de Virtualização da Intel KVM – Kernel-based Virtual Machine MGCP – Media Gateway Control Protocol MIT – Massachusetts Institute of Technology PBX – Private Branch Exchanges PSTN – Public Switched Telephone Network RAM (Random Access Memory): Memória de Acesso Aleatório
  12. 12. SIP – Session Initiation Protocol SLA (Service Level Agreement): Acordo de Nível de Serviço TCP – Transmission Control Protocol TI – Tecnologia da Informação UDP – User Datagram Protocol UML – User Mode Linux USB – Universal Serial Bus VBS – Visual Basic Script VGA – Video Graphics Array VM (Virtual Machine): Máquina Virtual VMM (Virtual Machine Monitor): Monitor de Máquina Virtual VoIP (Voice over IP): Voz Sobre IP VT (Virtualization Technology): Tecnologia de Virtualização
  13. 13. SUMÁRIO 1 INTRODUÇÃO...................................................................................................................... 15 1.1 OBJETIVOS ..................................................................................................................... 15 1.2 JUSTIFICATIVA.............................................................................................................. 15 1.3 ABRANGÊNCIA.............................................................................................................. 16 1.4 ESTRUTURA DO TRABALHO...................................................................................... 16 2 VIRTUALIZAÇÃO ............................................................................................................... 17 2.1 INTRODUÇÃO SOBRE VIRTUALIZAÇÃO................................................................. 17 2.2 HISTÓRIA DA VIRTUALIZAÇÃO................................................................................ 18 2.3 NECESSIDADE DA VIRTUALIZAÇÃO ....................................................................... 19 2.4 EMULAÇÃO DE HARDWARE...................................................................................... 21 2.5 VIRTUALIZAÇÃO COMPLETA.................................................................................... 22 2.6 PARAVIRTUALIZAÇÃO................................................................................................ 23 2.7 VIRTUALIZAÇÃO DE SISTEMA OPERACIONAL..................................................... 24 2.8 HARDWARE COM SUPORTE À VIRTUALIZAÇÃO ................................................. 24 3 FERRAMENTAS PARA VIRTUALIZAÇÃO.................................................................... 26 3.1 BOCHS ............................................................................................................................. 26 3.2 QEMU............................................................................................................................... 27 3.3 VMWARE......................................................................................................................... 27 3.4 LINUX KVM.................................................................................................................... 29 3.5 HYPER-V ......................................................................................................................... 29 3.6 XEN................................................................................................................................... 29 3.7 UML.................................................................................................................................. 33 4 ASTERISK.............................................................................................................................. 35 4.1 SIP..................................................................................................................................... 35 4.2 MGCP ............................................................................................................................... 36 4.3 IAX.................................................................................................................................... 36 5. LINGUAGENS DE PROGRAMAÇÃO.............................................................................. 37 5.1 LINGUAGENS INTERPRETADAS................................................................................ 38 5.1.1 LINGUAGEM DE EXTENSÃO OU SCRIPT.......................................................... 39 5.2 LINGUAGENS COMPILADAS ...................................................................................... 40 6 METODOLOGIA .................................................................................................................. 41 6.1 VIRTUALIZAÇÃO .......................................................................................................... 41 6.2 LINGUAGEM INTERPRETADA ................................................................................... 42 6.3 TESTES FINAIS............................................................................................................... 42 7 DESENVOLVIMENTO ........................................................................................................ 44
  14. 14. 7.1 CONFIGURAÇÃO DO AMBIENTE............................................................................... 44 7.2 DETALHES DE IMPLEMENTAÇÃO DA PARAVIRTUALIZAÇÃO ......................... 44 7.3 INSTALAÇÃO ASTERISK ............................................................................................. 46 7.3.1 INTERAÇÃO ENTRE O ASTERISK E O MÓDULO DA LINGUAGEM DFN ..... 47 7.4 DESENVOLVIMENTO DA LINGUAGEM INTERPRETADA PARA SISTEMA MULTI-PLATAFORMA........................................................................................................ 51 7.4.1 VARIÁVEIS E TIPOS............................................................................................... 52 7.4.2 ATRIBUIÇÕES ......................................................................................................... 53 7.4.3 OPERADORES ARITMÉTICOS E RELACIONAIS............................................... 53 7.4.4 ORDEM DE PRECEDÊNCIA DOS OPERADORES............................................... 54 7.4.5 COMENTÁRIOS....................................................................................................... 54 7.4.6 FUNÇÕES DA LINGUAGEM.................................................................................. 54 7.4.6.1 FUNÇÕES DE MANIPULAÇÃO DE STRING.................................................... 54 7.4.7 CONTROLE DE FLUXO E LAÇOS ITERATIVOS................................................ 56 7.4.7.1 TOMADAS DE DECISÃO COM IF.................................................................... 56 7.4.7.2 LAÇOS ITERATIVOS COM TOMADA DE DECISÃO NO INÍCIO (WHILE) 57 7.4.7.3 LAÇOS ITERATIVOS COM TOMADA DE DECISÃO NO FIM (REPEAT/UNTIL).............................................................................................................. 57 7.4.8 ANALISADOR DE EXPRESSÃO............................................................................ 58 7.5 IMPLEMENTAÇÃO DA LINGUAGEM INTERPRETADA NO SISTEMA PARAVIRTUALIZADO ........................................................................................................ 59 8 CONCLUSÃO ....................................................................................................................... 63 REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................... 64 APÊNDICE A – CÓDIGO FONTE DA LINGUAGEM ....................................................... 68 APÊNDICE B – ARQUIVOS DE CONFIGURAÇÃO DO ASTERISK E MÓDULO DE CARGA.................................................................................................................................... 143 APÊNDICE C – ARQUIVO DE CONFIGURAÇÃO DO XEN ......................................... 147
  15. 15. 15 1 INTRODUÇÃO A virtualização possibilita a definição de diversas máquinas lógicas em apenas um único hardware, fazendo com que a utilização de recursos aumente, além de facilitar a consolidação e segurança de ambientes computacionais. Segundo Bernard Golden e Clark Scheffy (2008, p.06 e 07), muitos data centers possuem máquinas sendo utilizadas com apenas 10% a 15% de sua capacidade total de processamento e, além disso, a necessidade de máquinas distintas para aplicações diferentes aumenta ainda mais a infra-estrutura, dificultando a administração, aumentando os gastos com manutenção, gerenciamento e energia. Uma linguagem de programação interpretada como linguagem de extensão permite a utilização de aplicativos hospedeiros em ambiente multi-plataforma, pois esta não está vinculada à linguagem de máquina do ambiente e sim ao interpretador. A razão para o desenvolvimento deste trabalho baseia-se no fato de que hoje em dia são praticamente inexistentes linguagens de programação voltadas à configuração de aplicativos que exijam agilidade na administração, alta disponibilidade e resiliência. Alguns aplicativos já possuem essa tecnologia, como por exemplo, o software de PBX VoIP Asterisk, que pode fazer uso de linguagens de extensão como alternativa à utilização de arquivos de configuração para facilitar seu uso e administração. 1.1 OBJETIVOS O objetivo deste trabalho é desenvolver uma linguagem de programação interpretada (extensível) para permitir maior flexibilidade na parametrização de aplicativos que necessitem do uso de configuração para o seu funcionamento. Como exemplo, esta linguagem será voltada para o software Asterisk. Será utilizada a paravirtualização como ambiente de implementação do Asterisk e da linguagem desenvolvida facilitando a administração e possibilitando um SLA (Service Level Agreement) elevado. 1.2 JUSTIFICATIVA A justificativa deste trabalho consiste nas dificuldades práticas em criar ambientes configuráveis de forma flexível. São praticamente inexistentes as linguagens de programação voltadas à configuração, principalmente no âmbito dos sistemas embarcados. Esta linguagem, ou mais precisamente, interpretador, é direcionado a qualquer plataforma. Entretanto, neste trabalho a implementação será realizada em um
  16. 16. 16 ambiente paravirtualizado, visto que a paravirtualização é uma tecnologia que facilita a criação de ambientes diversificados, sem a necessidade de adquirir hardwares com suporte a virtualização, além de facilitar a implementação de máquinas adicionais com sistemas que podem ou não estar integrados uns com os outros e com confiabilidade. 1.3 ABRANGÊNCIA Este trabalho abrange o desenvolvimento da linguagem na forma de interpretador na condição de linguagem de extensão, que será implementada em um ambiente paravirtualizado. Não faz parte do escopo deste trabalho o desenvolvimento de um compilador, mas sim de uma linguagem que possa ser embutida em outros aplicativos, que neste caso será no software Asterisk. O próprio software Asterisk é quem agirá como interpretador. Embora a virtualização não seja uma condição obrigatória para o uso da linguagem, ela será utilizada na implementação da solução, dada sua flexibilidade. 1.4 ESTRUTURA DO TRABALHO A estrutura do trabalho está dividida nos seguintes capítulos: O capítulo 2 aborda a definição de virtualização e as técnicas existentes. O capítulo 3 aborda a explicação das ferramentas de virtualização mais conhecidas no mercado, tanto as livres quanto as pagas. O capítulo 4 mostra o que é o Asterisk e suas principais características. O capítulo 5 trata do conceito de linguagem interpretada com exemplos de aplicação. O capítulo 6 aborda a metodologia do trabalho. O capítulo 7 mostra a criação do ambiente paravirtualizado em preparação para implementação da linguagem interpretada, assim como os detalhes da criação da linguagem e utilização da API do Asterisk para que este entenda e interprete a linguagem desenvolvida. Além disso, haverá detalhes da implementação da linguagem no ambiente paravirtualizado, com considerações e resultados finais. O capítulo 8 aborda a conclusão do trabalho e trabalhos futuros.
  17. 17. 17 2 VIRTUALIZAÇÃO Em meio às muitas tecnologias que surgiram nos últimos anos, a virtualização é um conceito que está sendo cada vez mais utilizado na área de tecnologia da informação. De acordo com a IBM (2005), a virtualização simplifica a infra-estrutura, reduz a complexidade e os custos otimizando os recursos. Para qualquer área dentro de uma empresa, a virtualização pode ser útil, pois muitos sistemas podem estar baseados e implementados em sistemas virtualizados, aumentando a disponibilidade, resiliência e facilitando a administração. Sempre há prós e contras a respeito de qualquer conceito, inclusive a virtualização. Neste capítulo serão apresentados os conceitos, os tipos de virtualização mais conhecidos, os benefícios de se utilizar a tecnologia citada e a diversidade de ferramentas existentes. 2.1 INTRODUÇÃO SOBRE VIRTUALIZAÇÃO De acordo com Bernard Golden e Clark Scheffy (2008, p.06 e 07), hoje muitos data centers possuem máquinas sendo utilizadas com apenas 10% a 15% da capacidade total de processamento. Em outras palavras, 85% a 90% da capacidade das máquinas não são utilizadas. Além disso, a necessidade de novas aplicações e sistemas faz com que novos servidores e máquinas de todos os tipos sejam adquiridos e que os data centers precisem de cada vez mais espaço para disposição de servidores. Figura 1 - Várias máquinas virtuais em um único hardware Fonte: VmWare (2008)
  18. 18. 18 De maneira simples, a virtualização é uma técnica para se utilizar diversos sistemas operacionais distintos, mas em um único hardware, conforme ilustra a Figura 1. De acordo com Jones (2006), virtualizar significa pegar algo que está em uma forma e fazê-la parecer de outra forma. Virtualizar um computador significa fazê-lo parecer múltiplos computadores ou um computador completamente diferente. Dependendo do ponto de vista, também pode significar fazer com que muitos computadores pareçam um único computador. Isto pode ser chamado de Server Agregation (agregação de servidores) ou Grid Computing (grid de computadores). A virtualização emula componentes de hardware para o sistema operacional através de técnicas, hardwares e softwares de virtualização. Essas técnicas são hoje utilizadas tanto para desktops quanto para servidores. O conceito de virtualização não é algo recente, mas após uma longa jornada passou a evoluir de maneira considerável nos últimos anos. Surgiram então diversas abordagens, mostrando varias vantagens e desvantagens dependendo da técnica a ser utilizada. [...] Uma máquina virtual não pode ser comprometida pela operação de qualquer outra máquina virtual. Ela fornece um ambiente computacional privado, seguro e confiável para seus usuários. [...] Novas facilidades, como sistemas de banco de dados ou suporte a dispositivos especializados podem ser adicionados sem modificação ou corrompimento das atuais capacidades. [...] (CREASY, 1981, p.487) 2.2 HISTÓRIA DA VIRTUALIZAÇÃO De acordo com a IBM (2006), a virtualização não é um tópico novo, pois o conceito de virtualização surgiu por volta do ano de 1960, quando a IBM, em conjunto com o MIT (Massachusetts Institute of Technology), tratava de um projeto chamado M44/44X. A meta era avaliar os conceitos de sistema de compartilhamento de tempo (Compatible Time-Share System, como era chamado). A máquina principal era um IBM 704 (M44) e cada máquina virtual era uma imagem experimental da máquina principal (44X). O espaço de endereçamento do 44X residia na hierarquia de memória do M44 e, além disso, era utilizado um sistema de memória virtual e multiprogramação.
  19. 19. 19 Este Mainframe executava duas máquinas virtuais, uma para executar programas e outra para o sistema. O sistema operacional do Mainframe era chamado de Supervisor. Alguns anos depois a IBM desenvolveu os computadores da família 360. Foi lançado o Mainframe System/360. Nesse Mainframe o hardware era acessado pela interface chamada VMM (Virtual Machine Monitor). O VMM permitia a execução das máquinas virtuais onde cada máquina executava uma instância do sistema operacional principal. O VMM executava diretamente na camada de hardware, permitindo múltiplas máquinas virtuais (VMs). Cada VM podia executar uma instância do sistema operacional – nos dias mais antigos isto era o CMS, ou Conversational Monitor System. A VM continuou a avançar, e hoje podemos encontrá-la sendo executada no mainframe System z9. Isto fornece compatibilidade antiga até mesmo com a linha System/360. (JONES, 2006) De acordo com Manfrin (2010), na época, os Mainframes eram máquinas X86 com um grande poder de processamento, mas que não eram completamente aproveitadas, utilizando somente de 10 a 15% de sua capacidade, pois normalmente eram implementadas para aplicações específicas, diminuindo os riscos de ficarem fora de produção. 2.3 NECESSIDADE DA VIRTUALIZAÇÃO De acordo com a VmWare (2010), a virtualização foi praticamente abandonada durante os anos 80 e 90, quando aplicações cliente-servidor, servidores e desktops X86 começaram a ser distribuídos. A adoção de sistemas operacionais Linux e Windows como sistemas para servidores começaram a ser o padrão da indústria. Com esse crescimento de servidores e desktops X86, passou a surgir uma nova infra-estrutura de TI e novos desafios operacionais. A VmWare, uma das empresas que fornecem tecnologia de virtualização, informa que alguns desses desafios são: - Baixa utilização de infraestrutura. De acordo com a IDC (International Data Corporation), a distribuição de servidores x86 atinge uma média de utilização de 10% a 15% da capacidade total. As organizações geralmente executam uma aplicação por servidor para evitar riscos de vulnerabilidade, ou seja, para que problemas afetando uma aplicação, não afetem a disponibilidade de outra que esteja no mesmo servidor;
  20. 20. 20 - Aumento do custo da infraestrutura física. É necessário suprir os custos operacionais do crescimento da infraestrutura. A maioria dos ambientes computacionais precisa estar disponível em quase 100% do tempo, resultando em consumo de energia, resfriamento, e custos que não variam; - Aumento do custo de gerenciamento de TI. Devido aos ambientes computacionais se tornarem mais complexos, os custos associados ao nível de educação especializada e experiência requerida para o gerenciamento da infraestrutura aumentam consideravelmente; - Proteção insuficiente contra desastres e falhas. Organizações são afetadas devido à inacessibilidade a aplicações críticas. Ameaças a segurança por meio de ataques, desastres naturais e terrorismos aumentaram a importância do planejamento continuo dos negócios, tanto para desktops como para servidores; - Alta manutenção de desktops de usuários finais. Diversos desafios são apresentados às empresas quando gerenciam e fornecem segurança para desktops. Controlar e gerenciar um ambiente de desktop distribuído, com diretivas de acesso e segurança sem impactar na habilidade do usuário de trabalhar efetivamente, é complexo e caro. De acordo com uma pesquisa realizada com empresas de IT (Information Technology) e com LOB (Line Of Business – outras áreas de negócio) pela IDC (2008), a tecnologia que tem mais impacto na transformação dos processos de negócio na área de TI, conforme Gráfico 1, é a virtualização. Figura 2 – Tecnologia com mais impacto na transformação dos processos de negócio Fonte: IDC (2008)
  21. 21. 21 Devido a essas e outras necessidades, as técnicas de virtualização foram surgindo e evoluindo em grande escala. Segundo a Gartner (2008), é esperado que o número de computadores virtualizados cresça de menos de 5 milhões em 2007 para 660 milhões em 2011, e Pettey (2008) diz que a virtualização é o problema que terá maior impacto até 2012, modificando infraestruturas e operações e modificando também a maneira de comprar e de gerenciar. 2.4 EMULAÇÃO DE HARDWARE De acordo com Jones (2007), a emulação de hardware nada mais é do que a virtualização do hardware. Provavelmente quando se fala em virtualização, a emulação de hardware é indicada como a mais complexa. Através das camadas virtuais de hardware é possível criar diferentes ambientes utilizando a mesma máquina física, conforme ilustra a Figura 2. Com a emulação de hardware alguns benefícios são apresentados, como por exemplo: É possível simular diversos processadores, mesmo que o hardware real possua apenas um processador físico. Pode-se também executar diversas máquinas virtuais, cada uma simulando um processador diferente. Uma das utilizações mais importantes da emulação de hardware é no desenvolvimento de firmware e hardware. Ao invés de esperar até que o hardware esteja disponível, os desenvolvedores de firmware podem utilizar o hardware VM alvo para validar muitos aspectos de seus códigos atuais em simulação. (JONES, 2006) Este tipo de virtualização precisa de um software que entenda as instruções da arquitetura que se deseja emular. Esta é a técnica utilizada pelos desenvolvedores de emuladores de vídeo-game, na qual o software irá converter as instruções recebidas da Figura 3 - Emulação de hardware Fonte: IBM (2006)
  22. 22. 22 arquitetura em que se está emulando, para que o sistema operacional convidado (também conhecido por GuestOS) possa entender as instruções. 2.5 VIRTUALIZAÇÃO COMPLETA De acordo com a VmWare (2007) a virtualização completa é uma técnica utilizada para fornecer um ambiente de máquina virtual, que simula de maneira completa o hardware como réplica do hardware real. Segundo Menascé (2005), o sistema operacional executado através de virtualização completa, que pode ser chamado de sistema operacional convidado, não necessita de modificações, visto que é executado através do VMM, o monitor de máquina virtual. O VMM é uma camada de software mais próxima ao hardware. Esta camada, que está entre o hardware e o sistema operacional convidado concede uma abstração da máquina virtual, conforme ilustra a Figura 3. O VMM suporta um número muito grande de dispositivos. Por isso a Virtualização completa utiliza dispositivos genéricos para fazer com que a máquina virtual execute. O fato destes dispositivos não serem específicos faz com que o desempenho da máquina virtual não seja atingido em sua totalidade. A máquina virtual acredita ser executada em um hardware real. Logo, o VMM precisa testar as instruções passadas pela máquina virtual para que em seguida as execute diretamente no hardware. Isso também acontece quando o hardware fornece alguma instrução, pois o VMM primeiro interpreta e testa a instrução antes de passar para a máquina virtual. Além dos aspectos citados, o VMM ainda precisa controlar alguns aspectos relacionados à disputa de recursos, o que causa certa queda de desempenho, visto que os sistemas operacionais foram desenvolvidos para não coexistirem com outros tentando utilizar os mesmos recursos. Figura 4 - Virtualização completa IBM (2006)
  23. 23. 23 2.6 PARAVIRTUALIZAÇÃO Segundo Origuela (2006), a técnica de paravirtualização utiliza um conceito parecido com o da virtualização completa. Nesta, o sistema operacional convidado é alterado para interagir com o VMM, para então decidir quais instruções devem ser interpretadas nele ou diretamente no hardware. Os drivers de dispositivos de sistemas paravirtualizados entendem que estão sendo executados como um sistema virtualizado, por isso, durante as requisições, os drivers dos dispositivos da máquina convidada conversam com os drivers reais do sistema operacional principal. De acordo com Jones (2007) a técnica de paravirtualização não simula recursos de hardware, mas ao invés disso oferece uma interface de programação de aplicação (API) para as máquinas virtuais hospedadas, e para isso, o sistema operacional precisará ter sido modificado para suportar tal interface. A paravirtualização é suportada em sistemas que foram modificados para entender que certas requisições, que seriam feitas diretamente ao hardware físico, deverão na verdade ser realizadas primeiramente ao VMM ou Hypervisor, como é chamado muitas vezes, para que o VMM se comunique com o host e aja diretamente no hardware, para então devolver as respostas das requisições. A paravirtualização utiliza o conceito de domínios. Existe um domínio chamado domínio zero, onde reside o sistema operacional que tem acesso direto ao hardware. Este domínio precisa possuir um sistema que foi modificado para suportar paravirtualização como domínio zero, e é através dele que é realizado o gerenciamento das máquinas virtuais. Figura 5 - Paravirtualização Fonte: Uberhip (2007)
  24. 24. 24 Além do domínio zero, existe o domínioU, onde residem as máquinas virtuais. Cada máquina virtual que reside em um domínioU também precisa ter sido modificada. Cada domínioU executa uma instância completa de um sistema operacional. Para utilizar a paravirtualização, não é necessária a utilização de hardware com suporte à virtualização, pois os sistemas operacionais já são modificados para suportar esta técnica, conforme ilustra a Figura 4. De acordo com a IBM (2006), a paravirtualização oferece um desempenho muito próximo ao de sistemas não virtualizados. 2.7 VIRTUALIZAÇÃO DE SISTEMA OPERACIONAL De acordo com o arquiteto da Microsoft Chantry (2009), a técnica da Virtualização de sistema operacional utiliza um sistema operacional como sistema base. Os sistemas convidados compartilham os mesmos recursos e drivers do sistema operacional base, mesmo que pareçam computadores totalmente separados, conforme ilustra a Figura 5. Cada sistema operacional convidado terá o seu próprio sistema de arquivos, endereço IP, configurações de servidor e executarão aplicativos totalmente diferentes. Figura 6 - Virtualização de sistema operacional Fonte: Chantry (2009) 2.8 HARDWARE COM SUPORTE À VIRTUALIZAÇÃO Diversas técnicas de virtualização existem hoje e, além disso, muitos softwares são construídos com base em uma técnica. Além da construção de softwares com suporte à virtualização, existem hardwares que são produzidos para auxiliar tais softwares na execução de tarefas essenciais, de acordo com a Intel (2010).
  25. 25. 25 A Intel lançou a tecnologia Intel VT (Intel Virtualization Techonlogy) que está presente em diversos processadores para auxiliar softwares de virtualização e, de acordo com a Intel (2010), proporcionar a utilização máxima do sistema por meio de consolidação de ambientes em um único servidor ou PC. Além da Intel VT a empresa AMD possui a tecnologia chamada AMD-V. De acordo com a AMD (2009) a tecnologia foi desenvolvida para aumentar drasticamente o desempenho da aplicação virtualizada, possibilitando também a alternância mais rápida entre máquinas virtuais, para que mais máquinas virtuais possam ser hospedadas por servidor, maximizando os benefícios da virtualização. Os hardwares com suporte à virtualização auxiliam os softwares de virtualização para que os sistemas operacionais não precisem ser modificados para poderem ter um melhor desempenho durante sua execução. Alguns softwares de virtualização funcionam com um bom desempenho apenas quando o hardware possui suporte à virtualização. Entretanto, há softwares que não necessitam de hardware com suporte à virtualização, mas que conseguem um ótimo desempenho durante a execução de máquinas virtuais devido ao fato de os sistemas operacionais terem sido modificados para tal.
  26. 26. 26 3 FERRAMENTAS PARA VIRTUALIZAÇÃO Diferentes ferramentas estão disponíveis hoje e cada uma utiliza uma técnica de virtualização diferente. Na Tabela 1, pode-se visualizar as principais ferramentas disponíveis e os tipos de virtualização que utilizam. Cada ferramenta possui seus pontos fortes e fracos, incluindo ferramentas livres e pagas. Tabela 1 – Ferramentas de virtualização Fonte - O autor Ferramenta Tipo Bochs Emulação QEMU Emulação VMWare Virtualização completa Linux KVM Virtualização completa Hyper-V Virtualização completa – Paravirtualização Xen Paravirtualização – Virtualização completa UML Paravirtualização Linux V-server Virtualização de sistema operacional Open VZ Virtualização de sistema operacional 3.1 BOCHS A ferramenta Bochs (que se pronuncia Box) é um emulador de software que não possui interface gráfica. A ferramenta é livre e emula computadores Intel x86. De acordo com a Bochs (2009), o Bochs emula apenas máquinas i386, i486, Pentium, Pentium Pro da Intel e CPUs AMD64, além de periféricos comuns como discos, memória, monitor e dispositivos de rede. A ferramenta foi desenvolvida em C++ e seu código pode ser compilado em basicamente qualquer plataforma, seja em Windows, MacOS X ou em várias versões de Unix. O software foi escrito por Kevin Lawton que ainda o mantém. O Bochs foi criado para emular sistemas operacionais Linux, DOS e Windows 95/98/XP/2000/NT. O fato de ser compatível com diversas plataformas é um ponto forte e ao mesmo tempo fraco em relação a outras máquinas virtuais, visto que os equipamentos como BIOS, placas de vídeo, som e basicamente todos os componentes são emulados através
  27. 27. 27 do software, o que faz com que a portabilidade seja maior, mas a velocidade passa a ser menor. 3.2 QEMU De acordo com Bellard (2005), o próprio desenvolvedor do Qemu, o software suporta dois modos operacionais: a emulação em modo de usuário e a emulação em modo de sistema. A emulação em modo de usuário permite que um processo construído para executar em certa CPU possa ser executado em outra, utilizando um conversor dinâmico como técnica para emulação, para que as partes do código sejam convertidas de maneira que o processador execute o conjunto de instruções. A emulação em modo de sistema permite a emulação de um sistema integral, incluindo processador e periféricos de diferentes tipos. [...] o QEMU como um emulador do sistema PC fornece uma extensa variedade de periféricos.[...] Um emulador Vídeo Graphics Array (VGA) de hardware, mouse e teclado PS/2, disco rígido e interface de CD-ROM do Ambiente de Desenvolvimento embarcado (IDE) e emulação de disco flexível. [...] Inclui a emulação para um adaptador de rede NE2000, portas seriais, numerosas placas de som e um controlador Universal Serial Bus (USB).[...] (Jones, 2007) Bellard (2005) também informa que para otimizar a emulação alguns módulos, aceleradores Qemu podem ser instalados fazendo com que o desempenho quase nativo possa ser obtido, permitindo que o código emulado seja executado diretamente na CPU real (do host). A princípio, o Qemu foi desenvolvido para executar um sistema operacional em outro, como um Windows em um Linux ou um Linux em um Windows. Ele pode executar em diversos sistemas operacionais como Linux, Windows e MacOs X. O ponto forte do Qemu é o fato de possuir um conversor dinâmico, rápido e portátil, que traduz as instruções para a CPU convidada vindas da CPU host, fornecendo assim a emulação. O conversor pode fazer cache de trechos de código para minimizar a sobrecarga, tornando-o mais rápido. 3.3 VMWARE A empresa VmWare (2010) fornece uma variedade de ferramentas para virtualização, desde softwares gratuitos para virtualização de desktops e servidores, até
  28. 28. 28 plataformas abrangentes de nível empresarial para otimização de data centers e da infraestrutura de TI. As ferramentas gratuitas são limitadas, enquanto as pagas fornecem recursos bem mais avançados. Diversos produtos são disponibilizados pela VmWare (2010), como por exemplo o VmWare Workstation, VmWare Server, VmWare Player, que são ferramentas de virtualização que executam em um sistema hospedeiro. Existe outra plataforma chamada VmWare ESX, ilustrada na Figura 6, que por si mesma é um sistema operacional hospedeiro baseado em Linux. Figura 7 – VmWare ESX Fonte: VmWare (2010) Pelo fato de utilizar virtualização completa, todos os componentes de hardware são virtualizados, e o suporte para todos os dispositivos são fornecidos pelo próprio sistema operacional hospedeiro. O VmWare utiliza drivers genéricos para os dispositivos, chamado de VMDriver. Pelo fato de utilizar dispositivos genéricos, o desempenho das máquinas diminui. De acordo com a VmWare (2010), o desempenho do VmWare ESX chega a ser melhor do que as ferramentas que precisam de um sistema hospedeiro, mas a portabilidade diminui devido a limitações do próprio sistema. O VmWare possui ferramentas com interface gráfica que facilitam a administração das máquinas virtuais existentes. O VmWare faz uso do VMM, que intercepta e testa as instruções passadas pela máquina virtual para poder então executá-las diretamente no hardware. O mesmo acontece quando o hardware fornece alguma instrução, pois o VMM a interpreta e passa para a máquina virtual. Além disso, os recursos da máquina hospedeira são disputados
  29. 29. 29 pelas máquinas virtuais, e por isso o VMM também realiza o controle desses recursos, o que causa mais queda no desempenho. 3.4 LINUX KVM De acordo com os desenvolvedores do KVM (2010), KVM significa Kernel- based Virtual Machine. O Linux KVM é um framework de virtualização completa que utiliza as tecnologias de virtualização Intel-VT e AMD-V, que estão nos processadores mais recentes. O KVM é uma ferramenta livre e está presente no Kernel Linux 2.6.20, e é possível executar qualquer sistema operacional sem que nenhuma modificação seja realizada, desde que haja tecnologia de virtualização embutida no processador. Cada máquina virtual é tratada como um processo Linux, por isso pode-se manipular as máquinas com comandos de manipulação de processos. 3.5 HYPER-V Hyper-V é a solução de Virtualização completa Microsoft parecido com as ferramentas VmWare. Além disso, de acordo com a Microsoft (2010), a ferramenta suporta paravirtualização para sistemas operacionais que são modificados para tal. A Microsoft possui o Hyper-V Standalone como sendo o próprio sistema hospedeiro além de possuir a opção de ser executado em um host Windows Server 2008. Quando adquirido o Windows Server 2008 R2, o Hyper-V faz parte do sistema, não sendo necessário adquirir licenças. Para a utilização de alguns recursos, o Hyper-V necessita do System Center Virtual Machine Manager, que necessita de licenças para funcionar. A Microsoft (2010) informa que para o funcionamento do Hyper-V é necessário possuir as tecnologias de aceleração de virtualização nos processadores como Intel VT ou AMD-V. O Hyper-V é uma ferramenta que ainda está em aperfeiçoamento, mas possui alguns benefícios por ser desenvolvido pelo próprio fabricante do Windows, o que traz algumas compatibilidades e facilidades na administração. 3.6 XEN O Xen (2010) é uma ferramenta de paravirtualização que também suporta virtualização completa quando o hardware possui suporte a tecnologia Intel VT ou AMD-V, que foi desenvolvido em um projeto na Universidade de Cambridge, que mais tarde tornou-se a empresa XenSource Inc, e então foi adquirida pela Citrix System em outubro de 2007. O Xen possui um desempenho melhor do que os produtos que utilizam virtualização completa quando o hardware da máquina física não possui suporte a
  30. 30. 30 virtualização. Na virtualização completa, algumas tarefas que precisam ser executadas pelas máquinas virtuais não podem ser executadas diretamente no processador, pois são tratadas como um processo na camada de aplicação da máquina hospedeira. Com isso, o VMM intercepta as tarefas, e as executa. Isto causa certa perda de desempenho em hardwares sem suporte à virtualização. Já na paravirtualização, os sistemas operacionais a serem executados, precisam ser modificados para que estas tarefas específicas, que precisariam ser executadas na CPU, possam ser diretamente executadas no VMM, sem haver a tentativa de acesso direto a CPU e sem que o VMM as intercepte, trazendo ganho de desempenho. Uma grande vantagem do Xen é que ele pode executar máquinas virtuais em hardwares que não possuem suporte à virtualização, com um desempenho muito próximo ao da máquina nativa. Apesar disso, os sistemas operacionais precisam ser modificados para funcionarem. Hoje já existem diversos sistemas com suporte ao Xen, como o Linux, FreeBSD e Windows, mas alguns necessitam de tecnologia de hardware Intel VT ou AMD-V para utilizar a virtualização completa, e outros já possuem o código modificado para utilizar paravirtualização. Nas Tabelas 2 e 3 são citados os sistemas operacionais que suportam o Xen como servidor e como máquina convidada. Tabela 2 – Suporte Xen 3.0 Fonte: O autor OS Executar como Dom0 (host) Executar como domU (convidado) Linux 2.6 Sim Sim NetBSD 3.1 Não Sim NetBSD 4.0_Beta2 e atual Sim Sim FreeBSD 5.3 Não Sim FreeBSD 7 Não Sim Solaris 10 Não Sim Sistemas Operacionais não Modificados Não Sim, somente quando o hardware possui suporte Intel VT ou AMD-V
  31. 31. 31
  32. 32. 32 Tabela 3 – Suporte Xen 2.0 Fonte: O autor Sistema operacional Executar como Dom0 (host) Executar como domU (convidado) Linux 2.4 Sim Sim Linux 2.6 Sim Sim NetBSD 2.0 Não Sim NetBSD 3.0 Sim Sim Plan 9 Não Sim FreeBSD 5 Não Sim De acordo com a Xen (2008), cada máquina virtual é chamada de domínio. Existem dois tipos de domínio: o domínio 0 (chamado de domain0 ou dom0), que é o domínio de controle, e o domínio U (chamado domainU ou domU), que é o domínio sem privilégios, ou seja, o sistema operacional convidado. Cada domínio executa uma instância completa do sistema operacional. Figura 8 – Componentes do Xen Fonte: Carissimi (2008)
  33. 33. 33 Para que o Xen ofereça suporte tanto à virtualização completa quanto à paravirtualização, é utilizado o conceito dos domínios explicado anteriormente, com algumas modificações. O Xen reconhece os domínios U-PV, como domínios paravirtualizados e U-HVM (hosted virtual machines) como domínios virtualizados. Os domínios U-PV são os domínios que possuem os sistemas operacionais modificados, que sabem que existem outras máquinas virtuais e possuem drivers específicos para acesso à rede e disco e, além disso, sabem como interagir com o domínio 0. Os domínios U-HVM não são modificados, ou seja, não sabem que existem outras máquinas virtuais e por isso não possuem drivers específicos para o acesso a recursos, necessitando do hardware com suporte à virtualização para que o desempenho não caia, conforme ilustra a Figura 7. De acordo com a Xen (2008), para que o domínio U-HVM funcione, ele faz o uso do Qemu (o emulador de software), e os recursos de hardware que são disponíveis para o domínio são os mesmos oferecidos pelo Qemu. 3.7 UML UML (User mode Linux) permite que um sistema operacional Linux execute outro sistema operacional Linux como convidado através da paravirtualização. De acordo com Dike (2010), cada sistema operacional Linux convidado existe como um processo no host Linux. Isto permite que vários Kernels de versões diferentes possam ser executados em uma única versão de Kernel Linux, conforme ilustra a Figura 8. Figura 9 – User mode Linux Fonte: IBM (2006) Um dos grandes benefícios e foco do UML é poder realizar testes em versões de Kernels Linux diferentes sem prejudicar o host Linux principal. O UML também fornece mais recursos de hardware e software do que os da máquina física (host).
  34. 34. 34 Jones (2007) explica que os Kernels convidados executam no espaço de aplicação, e para funcionarem precisam ter sido compilados para tal, enquanto o Kernel Host reside diretamente no hardware.
  35. 35. 35 4 ASTERISK O Asterisk é um software livre que implementa recursos de PBX completo e muitas outras funções através da tecnologia de VoIP. Mark Spencer da Digium Inc. foi quem iniciou o projeto por volta do ano de 1999. Inicialmente o Asterisk foi desenvolvido para implementar apenas recursos em software como um PBX de código aberto, mas de acordo com Davenport (2010), hoje o Asterisk implementa não apenas recursos de sistemas PBX, mas também gateways VoIP, sistemas de Call Center, pontes de conferência, servidores voicemail e todos os tipos de aplicativos que envolvam comunicação em tempo real. O sistema roda em servidores Linux e faz VoIP através de três diferentes protocolos. De acordo com a Asterisk Brasil (2010), o Asterisk pode se integrar a praticamente todos os padrões de telefonia utilizando hardware de baixo custo. Ele é um servidor de comunicação que detém todos os níveis baixos de detalhes para envio e recebimento de dados utilizando alguns diferentes tipos de protocolos. Os protocolos utilizados pelo Asterisk são protocolos abertos como o SIP, MGCP e IAX, os quais realizam a sinalização das chamadas telefônicas na rede IP. Após a instalação do Asterisk, um servidor de comunicação passa a existir, mas para que ele realmente se comunique, é preciso criar aplicativos de comunicação realizando e alterando configurações, que o fará funcionar da maneira planejada. Estes aplicativos de comunicação são construídos através de scripts, arquivos de configuração, gravações de áudio, banco de dados, serviços web, etc. Para que um aplicativo de comunicação funcione, é preciso que o servidor de comunicação esteja conectado a serviços de comunicação como VoIP ou PSTN. Para que as pessoas acessem o sistema de comunicação, é preciso ter números de telefones ou URLs VoIP que enviem chamadas ao servidor. 4.1 SIP De acordo com a IETF (2010), o SIP é um protocolo IETF (RFC 2543, 1999) de aplicação parecido com o HTTP ou SMTP, que segue o modelo requisição-resposta para iniciar sessões de comunicação VoIP e outras sessões de texto e multimídia, como mensagens instantâneas, vídeo, jogos online e outros serviços. Para comunicação, ele utiliza a porta 5060 tanto UDP como TCP. Alguns recursos que o protocolo oferece na parte de telefonia são: transferências de chamada, conferências telefônicas e chamadas em espera. Por ser um protocolo flexível, é possível adicionar mais recursos ao SIP.
  36. 36. 36 4.2 MGCP De acordo com a Arango (1999), o MGCP também é um protocolo do grupo IETF que integra a arquitetura SS7 em redes VoIP. A arquitetura SS7 é uma rede de pacotes que se agrega à rede de telecomunicação, adicionando novas funcionalidades e serviços que estão presentes em centrais telefônicas. O SS7 é quem possibilita a comunicação de centrais telefônicas de maneira confiável e rápida. O MGCP possuiu um agente de chamada, um MG (Media Gateway), que é o responsável pela conversão de sinais entre circuitos, e pelo menos um SG (Signaling Gateway) conectado a um PSTN. 4.3 IAX De acordo com Guy (2009), o IAX é um protocolo desenvolvido para estabelecer conexão entre servidores Asterisk, que também já está presente em telefones VoIP. Ele foi desenvolvido pela Digium Inc., que é a empresa desenvolvedora do Asterisk. O IAX é parecido com o protocolo SIP citado anteriormente, com a diferença de que faz uso de uma única porta UDP de número 4569. O IAX já está na versão 2, mais conhecido por IAX2. Um dos grandes benefícios do IAX é que ele suporta entroncamento de chamadas, ou seja, é possível unir chamadas que se entroncaram em um único conjunto de pacotes e entregar informações para mais de uma chamada ao mesmo tempo.
  37. 37. 37 5. LINGUAGENS DE PROGRAMAÇÃO Linguagem de programação é um conjunto de regras que são utilizadas para definir um programa para ser utilizado no computador. Existem alguns tipos de linguagens: alto nível, nível intermediário ou baixo nível. De acordo com Carter (2002, p.46), a linguagem de baixo nível é uma linguagem em que o código é executado diretamente pelo processador. É formada por zeros (0) e uns (1). Por isso também é chamada de linguagem binária ou de máquina. A linguagem de nível intermediário é uma linguagem em que os códigos fonte são chamados de mnemônicos (assembly) onde cada instrução de máquina tem uma representação em texto (como ADD, SUB, ou LOAD). A linguagem de nível intermediário precisa ser transformada em linguagem de baixo nível, por isso era necessário um montador que realizasse a conversão. Tabela 4 – Tipos de linguagens Fonte: O autor Linguagem Compilada/Interpretada ADA Compilada BASIC Interpretada C Compilada C++ Compilada Cobol Compilada Fortran Compilada Java Intermediária (híbrida) MATLAB Interpretada (híbrida) LISP Intermediária (híbrida) Pascal Compilada PHP Interpretada Prolog Interpretada Prolog Interpretada Perl Interpretada Lua Interpretada
  38. 38. 38 A linguagem de alto nível é uma linguagem que é mais facilmente entendida pelo ser humano. Antigamente a programação era bem tediosa, pois para executar operações um pouco mais complexas eram necessárias muitas instruções e, além disso, as instruções disponíveis eram diferentes de máquina para máquina. Com isso surgiram as primeiras linguagens de alto nível como Pascal, COBOL e C. Através da linguagem de alto nível é possível desenvolver programas em muito menos instruções, ou seja, seu desenvolvimento é muito mais rápido do que era antigamente. Para que a linguagem de alto nível seja entendida pela máquina é preciso de alguém que a traduza. Existem algumas maneiras para realizar a tradução, seja através de um compilador ou interpretador. Na tabela 4, estão listadas algumas linguagens importantes e seus respectivos tipos. 5.1 LINGUAGENS INTERPRETADAS Linguagem interpretada é uma linguagem de programação que necessita de um interpretador para ser executada. O código-fonte de uma linguagem interpretada só será entendido pela máquina se houver o interpretador para traduzir a respectiva linguagem. De acordo com Louden (2004, p.04), um interpretador é um tradutor de linguagens, assim como o compilador. A diferença é que o interpretador executa o programa-fonte de imediato, traduzindo as instruções de programação conforme são lidas pelo programa, em vez de gerar um código-objeto que seja executado após o término da tradução. Figura 10 - Linguagem interpretada Fonte: Caldas (Slide 14) De acordo com Sebesta (2002, p. 154), algumas linguagens são tipicamente interpretadas, outras utilizam os dois métodos (compilação e interpretação) para serem executadas. Um interpretador compartilha muitas de suas operações com os compiladores, podendo existir compiladores híbridos que ficam entre os interpretadores e compiladores. Se uma linguagem for compilada e o código gerado não for entendido
  39. 39. 39 pelo sistema operacional e processador, necessitando de que algum mecanismo a interprete, esta linguagem também será uma linguagem interpretada. 5.1.1 LINGUAGEM DE EXTENSÃO OU SCRIPT Linguagem de extensão também pode ser chamada de linguagem de script. Essas linguagens normalmente controlam programas, pois são executadas dentro deles. De acordo com a Stanford University (2004), as linguagens de extensão são muito utilizadas em sistemas operacionais e também em muitos jogos. O Linux é um sistema operacional que utiliza bastante a linguagem de extensão para controlar aplicativos e rotinas do próprio sistema operacional. O Windows também utiliza linguagem de extensão. Um exemplo disso são os scripts VBS. Alguns jogos utilizam a linguagem de extensão para poder controlar ações de personagens. Pode-se dizer que toda linguagem de extensão é uma linguagem interpretada, mas que nem toda linguagem interpretada é uma linguagem de extensão. As linguagens de extensão são classificadas segundo sua complexidade: - Linguagem de Macro: São utilizadas para tarefas de automação com abrangência mais limitada. - Linguagens Embutidas: Permitem o acesso programável aos serviços da aplicação hospedeira (ou principal). São linguagens mais completas e mais complexas que a anterior. Figueiredo (2002) informa que a adoção de uma linguagem de extensão é um poderoso recurso no desenvolvimento de softwares, pois permite que muitos aspectos da aplicação hospedeira sejam controlados externamente. Esse controle consiste na edição de arquivos textos facilmente modificados pelo desenvolvedor sem a necessidade de recompilar a aplicação, tornando o desenvolvimento mais rápido e muito mais flexível. Uma linguagem de extensão deve ter como foco a produtividade do programador. Segundo Proebsting (2002), um dos problemas mais sérios no desenvolvimento de uma linguagem de programação é em como melhorar a produtividade do programador. Os hardwares atualmente possuem um poder de processamento suficientemente grande para não precisar de otimização massiva da linguagem internamente.
  40. 40. 40 5.2 LINGUAGENS COMPILADAS Linguagem compilada é uma linguagem onde o código fonte é executado diretamente pelo sistema operacional ou pelo processador. O código é traduzido para executar um conjunto de regras ou instruções, e esse processo chama-se compilação. Para isso, é utilizado um software próprio, chamado compilador, que efetua a tradução para linguagem de baixo nível, como linguagem de montagem ou código de máquina. De acordo com Louden (2004, p. 13), a geração do código é muito complexa, pois depende das informações da estrutura do ambiente de execução, através de tentativas de otimizar ou aperfeiçoar a velocidade ou tamanho do código fonte. A linguagem compilada elimina essa fase em vários passos, utilizando estruturas de dados intermediários. Após a compilação, cria-se um programa executável, armazenando as informações e não é necessário a recompilação. Figura 11 - Linguagem compilada Fonte: Caldas (Slide 14) A vantagem é que o usuário nunca terá acesso ao código fonte, evitando assim a alteração e danificação do programa.
  41. 41. 41 6 METODOLOGIA Neste capítulo serão apresentados a metodologia adotada e informações necessárias para atingir o objetivo proposto no trabalho, além de justificar a escolha das tecnologias utilizadas. Esta parte do trabalho foi dividida em etapas que ajudarão a construir um ambiente com suporte à paravirtualização, instalar e configurar o Asterisk em máquina virtual, desenvolver uma linguagem que possa ser interpretada pelo Asterisk, utilizar a API do Asterisk para que entenda a linguagem criada, e a execução de testes com VoIP utilizando o ambiente e linguagem criados. As etapas necessárias estão divididas da seguinte forma: 1. Ambiente virtualizado: - Escolha da tecnologia de virtualização que será utilizada; - Criação e configuração do ambiente virtualizado; - Instalação e configuração do Asterisk. 2. Linguagem interpretada: - Desenvolvimento da linguagem interpretada; - Fazer a integração da linguagem com o Asterisk através da API do próprio Asterisk. 3. Testes finais: - Realizar testes com VoIP utilizando a linguagem interpretada no Asterisk paravirtualizado. 6.1 VIRTUALIZAÇÃO A paravirtualização foi escolhida como técnica a ser utilizada para a implementação do ambiente devido aos benefícios que ela apresenta. Como principais benefícios pode-se citar que a paravirtualização pode ser implementada em qualquer máquina da plataforma x86 sem necessitar de hardware com suporte à virtualização (como Intel-VT ou AMD-V), por isso mais tipos de máquinas, inclusive máquinas mais antigas, poderão ser utilizadas para a aplicação da técnica. A ferramenta a ser utilizada para aplicação da técnica de paravirtualização será o Xen com o sistema operacional Linux distribuição Open Suse, pois apresenta algumas características que facilitarão a criação do ambiente como: um ótimo desempenho mesmo utilizando máquinas sem hardware com suporte à virtualização e máquinas de hardware comuns, software de código aberto, o que facilita ainda mais o acesso ao
  42. 42. 42 software, além disso, já existem diversos sistemas operacionais com suporte a paravirtualização e ao Xen. O Xen será instalado e configurado no sistema operacional Linux Open Suse como domínio 0. Uma máquina virtual será criada dentro do Xen. A máquina virtual também possuirá o sistema operacional Linux Open Suse. Nesta nova máquina virtual será instalado o software Asterisk em preparação para os próximos passos. 6.2 LINGUAGEM INTERPRETADA O desenvolvimento do Interpretador, aqui chamado de dfn, consistirá em uma linguagem feita em “C” para aplicações em “C/C++” que funcionará como extensão da aplicação hospedeira que no caso será o Asterisk. Essa abordagem permite que a aplicação seja expandida sem a necessidade de alteração de linha de código. Toda a nova lógica, portanto, será implementada na linguagem aqui proposta. A integração entre o interpretador e o Asterisk ocorrerá mediante o uso de funções específicas, previamente definidas, conforme o documento "Asterisk Coding Guideline" disponível no site do fabricante Asterisk (2010). 6.3 TESTES FINAIS Após a criação do ambiente paravirtualizado, o desenvolvimento da linguagem interpretada e configuração do Asterisk para entender a linguagem, será necessário juntar os dois primeiros passos citados na introdução do capítulo 6 e realizar testes no ambiente criado utilizando a linguagem desenvolvida. Estes testes envolverão o desenvolvimento de um código utilizando a linguagem criada que substituirá arquivos de configuração do Asterisk. Estes arquivos de configuração contêm instruções sobre tomada de decisão relacionados ao VoIP. Em vez de o Asterisk ler o arquivo de configuração padrão (extensions.conf), ele lerá o arquivo .dfn que será o motor da linguagem aqui proposta. Para isso o Asterisk precisará entender a linguagem, ou seja, interpretá-la. O Asterisk já deverá ter sido configurado para interpretá-la de acordo com o que foi mencionado no item 6.2. Ao final deste trabalho se chegará ao resultado da viabilidade do uso ou desenvolvimento de uma linguagem interpretada (extensível) para permitir maior flexibilidade na parametrização de aplicativos que necessitem do uso de configuração para o seu funcionamento e de que a paravirtualização garante um SLA elevado uma vez que na indisponibilidade de um hardware, outro poderá assumir como hospedeiro
  43. 43. 43 mantendo o funcionamento dos serviços sem a necessidade de reinstalação de uma nova máquina.
  44. 44. 44 7 DESENVOLVIMENTO A partir deste capítulo será abordada toda a estrutura de criação do ambiente paravirtualizado, assim como os detalhes do desenvolvimento da linguagem interpretada para sistema multi-plataforma. Para isso, foram necessários o estudo de tecnologias necessárias para implementação do Asterisk, para a criação de uma linguagem interpretada e de um ambiente virtualizado estável. 7.1 CONFIGURAÇÃO DO AMBIENTE Para a implementação do Xen e Asterisk em preparação para os testes com a linguagem criada será utilizada uma máquina Intel QuadCore Q9400 2.66GHz, 4GB de memória RAM, 2 HDs de 1TB em RAID-1, com sistema operacional Linux distribuição Open Suse 11.3. 7.2 DETALHES DE IMPLEMENTAÇÃO DA PARAVIRTUALIZAÇÃO Para implementação das máquinas virtuais foi criada uma máquina real com o sistema operacional Linux distribuição Open Suse 11.3 Português e interface KDE. Este sistema é o sistema que chamamos de domínio 0 (domain0 ou dom0), que é o domínio de controle, conforme explicado no item 3.6. É o domínio que possui o sistema Xen para o controle e alocação das máquinas virtuais. O OpenSuse 11.3 possui o Xen pré-instalado em um pacote que contém o Xen Hypervisor. Para instalar o Xen Virtualization é preciso selecionar no menu de seleção de Software e tarefas de sistema a opção Servidor hospedeiro de máquina virtual Xen, conforme mostra a figura 11. Figura 12 – Instalação Xen Fonte: O autor O particionamento foi dividido da seguinte forma: -Volume de Swap /dev/sda1 - Volume Raíz /dev/sda2 com ext4 - Volume /dev/sda3 para /home com ext4
  45. 45. 45 Para instalar o Hypervisor e Ferramentas foi necessário selecionar a opção “instalar o Hypervisor e suas ferramentas” após a instalação do sistema operacional conforme Figura 12. Figura 13 – Instalando o Hypervisor e Ferramentas 1 Fonte: O autor Ao instalar o Hypervisor e suas ferramentas é retornada a mensagem informando que o servidor VM (domínio 0) foi configurado com sucesso e que estará pronto para a criação de máquinas virtuais. Domínio 0 configurado e pronto para iniciar (ver figura 13): Figura 14 – Domínio 0 configurado Fonte: O autor Após a instalação foi realizada a criação da máquina virtual no domínio U-PV, que possui o sistema operacional modificado para executar a paravirtualização.
  46. 46. 46 Abaixo está o exemplo do arquivo de configuração utilizado e modificado para a manipulação da máquina virtual chamado vm_xen_tcc.conf localizado em /images/config/: # # Arquivo de configuração da máquina virtual a ser usada no trabalho # kernel = "/images/TCC/boot/vmlinuz-xen" ramdisk = "/images/TCC/boot/initrd-xen" builder='linux' memory = 512 name = "TCC_VM_DFN" #uuid = "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9" # Number of Virtual CPUS to use, default is 1 vcpus = 1 vif = [ 'mac=00:16:3e:00:00:11, bridge=br0' ] disk = [ 'file:/images/TCC/vdisks/sda_vdisk_12GB.img,xvda,w', 'file:/images/TCC/vdisks/sdb_vdisk_16GB.img,xvdb,w' ] root = "/dev/xvda2" vfb = [ 'vnc=1,vnclisten=0.0.0.0,vncunused=1,vncpasswd=reurbanisatus' ] # Set root device. #root = "/dev/hda1" # Extra arguments to pass to the kernel. extra = "xencons=xvc console=xvc0 video=tty" #on_poweroff = 'destroy' 7.3 INSTALAÇÃO ASTERISK O Asterisk lê as regras de chamadas e discagem a partir do arquivo "extensions.conf". A linguagem dfn substituirá a configuração do "extensions.conf". Na prática, o mecanismo do Asterisk será instruído a ler o arquivo "extensions.dfn" que conterá toda a lógica de atendimento e regras de discagem. As contas dos usuários continuarão a ser configuradas no arquivo sip.conf no caso de uso do protocolo SIP. Para o IAX2, o arquivo deverá ser o iax2.conf.
  47. 47. 47 Esse mecanismo não será alterado e não terá interação com a linguagem propriamente dita, uma vez que esse faz parte do processo de autenticação do Asterisk, uma camada anterior à execução do script de atendimento em dfn. 7.3.1 INTERAÇÃO ENTRE O ASTERISK E O MÓDULO DA LINGUAGEM DFN A implementação ou interface entre a linguagem dfn e o asterisk será feita no código pbx_dfn.c. O módulo final é o pbx_dfn.so e o mecanismo obedece o fluxo conforme as figuras 14 e 15. Figura 15 – Processo de inicialização Fonte: O autor Figura 16 – Tratamento de chamada Fonte: O autor
  48. 48. 48 Figura 17 – Compilação do módulo Fonte: O autor A figura 17 mostra a compilação do módulo do Asterisk utilizando o arquivo pbx_dfn e a Figura 18 exibe o diretório de módulos com o arquivo pbx_dfn.so. Figura 18 – Diretório de módulos do Asterisk Fonte: O autor
  49. 49. 49 O Asterisk lerá o arquivo extensions.dfn onde todas as regras de atendimento estarão declaradas. Como as regras de atendimento do Asterisk são baseadas em contexto, a linguagem dfn tratará essa regra como regra de entrada e executará as funções internas do Asterisk responsáveis pelo controle de chamadas, geração de CDRs, desligamento de chamadas, etc. Abaixo segue o trecho do código do pbx_dfn.c das partes mais importantes responsáveis pela integração entre o Asterisk e a linguagem dfn. A API do Asterisk trabalha com as funções load_module, unload_module, reload e AST_MODULE_INFO. Essas quatro funções são o coração da integração entre qualquer modulo e o Asterisk. Quando o modulo é carregado, o asterisk lê os parâmetros passados à macro AST_MODULE_INFO. A partir deste instante cada função é executada conforme a ação do Asterisk. Deve-se, obrigatoriamente, declarar o nome o arquivo padrão na variável config, o nome do módulo na variável registrar, todas como static para ponteiro do tipo char. static char *config = "extensions.dfn"; static char *registrar = "pbx_dfn"; A função load_module é a responsável pela carga do módulo da linguagem. Quando o módulo é carregado, a função deverá retornar 2 possíveis valores declarados como constantes (#define): AST_MODULE_LOAD_SUCCESS no caso de sucesso na carga ou AST_MODULE_LOAD_DECLINE para a situação de exceção ou erro no módulo. static int load_module(void) { int res; if ((res = load_or_reload_dfn_stuff())) return res; if (ast_register_switch(&dfn_switch)) { ast_log(LOG_ERROR, "Unable to register DFN Language Extension Modulen");
  50. 50. 50 return AST_MODULE_LOAD_DECLINE; } return AST_MODULE_LOAD_SUCCESS; } A função unload_module tem como objetivo a remoção do módulo da memória quando solicitado pelo usuário via console ou por situação de exceção interna do Asterisk. Duas outras funções internas devem ser chamadas: ast_context_destroy, que informa ao asterisk qual modulo será removido ou desregistrado e a função ast_unregister_switch que receberá o ponteiro da função do motor da linguagem propriamente dita. static int unload_module(void) { ast_context_destroy(NULL, registrar); ast_unregister_switch(&dfn_switch); dfn_free_extensions(); return 0; } A função reload tem como objetivo chamar a função load_or_reload_dfn_stuff que apenas remove e recarrega a linguagem dfn. static int reload(void) { return load_or_reload_dfn_stuff(); } AST_MODULE_INFO(ASTERISK_GPL_KEY, AST_MODFLAG_DEFAULT, "DFN Language Extension Module", .load = load_module, .unload = unload_module, .reload = reload, );
  51. 51. 51 Abaixo segue exemplo do arquivo de configuração dos módulos do Asterisk juntamente com os comentários explicativos de cada parte do arquivo e o arquivo sip.conf: [modules] ; autoload habilitado, instrui o Asterisk a carregar todos os arquivos *.so que encontrar em /var/lib/asterisk/modules autoload=yes ; Cada módulo precisa ser carregado antes do núcleo do Asterisk ser inicializado. ; ; A linha abaixo só deverá ser descomentada se o autoload for igual a "no". ;load => pbx_dfn.so ; Como o autoload está habilitado, caso não se pretenda carregar o módulo da linguagem dfn, ; deve-se remover o comentário da linha abaixo ;noload => pbx_dfn.so Figura 19 – Arquivo sip.conf Fonte: O autor 7.4 DESENVOLVIMENTO DA LINGUAGEM INTERPRETADA PARA SISTEMA MULTI-PLATAFORMA A linguagem aqui proposta, chamada de dfn, implementa as construções fundamentais para definição de controle de fluxo como if, elseif, else, endif, while, do, endwhile, repeat, until, funções, e tipos definidos de dados. Trata-se ainda de uma linguagem com tipagem dinâmica. As próximas seções procuram tratar da estrutura da linguagem, tipos de dados,
  52. 52. 52 sintaxes, etc. 7.4.1 VARIÁVEIS E TIPOS As varáveis do dfn deverão conter pelo menos um caractere e deve ser iniciado por uma letra obrigatoriamente, os caracteres seguintes poderão ser outras letras, números e sublinha. Letras maiúsculas e minúsculas são diferentes. Exemplo: Nomes válidos de variáveis: a=12 a21 = “Teste” meuValor=51 Minha_Variavel=”Ok” Nomes inválidos de variáveis: _12=21 21=22 *valor=12 Esses nomes não são admitidos como válidos no contexto da linguagem dfn. A linguagem possui os seguintes tipos de variáveis, sendo que sua conversão é automática, o que lhe confere uma tipagem dinâmica: Tipo null - esse tipo indica um valor indefinido. Por padrão todas as variáveis não declaradas são do tipo null, podendo, a partir desse conceito, verificar se uma variável foi ou não declarada no sistema. Tipo numeric - são variáveis que contêm somente números armazenados. Tipo string - São cadeias de caracteres contendo letras, números e caracteres especiais como "@", "%", etc. Tipo array - São variáveis com índice numérico onde cada índice aponta para a posição onde o valor é armazenado. Tipo hash - São arrays associativos, ou seja, o índice pode ser qualquer caractere ou cadeia de caractere, numérico ou string. Tipo function - Esse tipo de dado compreende as funções declaráveis pelo programador na linguagem. Toda função criada pelo usuário deverá ser iniciada
  53. 53. 53 pelo comando function, seguido do nome da função com os seus parâmetros entre parêntesis e separado por vírgula (caso haja mais de um). 7.4.2 ATRIBUIÇÕES Para atribuição deve-se usar o sinal de igual simples “=” entre a variável e o valor. A simples atribuição já é suficiente para a própria declaração da variável. A atribuição pode ser simples ou múltipla. Exemplo: Variável = Valor O “Valor” pode ser numérico, string, array ou qualquer outro tipo de dados permitido pela linguagem. Já a atribuição múltipla pode ser vista no exemplo a seguir: var1, var2, var3 = "Universidade Anhembi Morumbi", 1231, {1,2,3,"Eu sou um valor de um array"} No caso acima, a variável var1 é do tipo string, a var2 do tipo numérico e a var3 é um array de 4 elementos. A atribuição múltipla permite a troca de valores armazenados em uma única linha. Exemplo: var1 = "Teste1" var2 = "Teste2" # Resultado var1="Teste1" e var2="Teste2" – Aqui é um comentário print( "var1=",var1, " var2=", var2 ) # Faz a troca var1, var2 = var2, var1 # Resultado var1="Teste2" e var2="Teste1" print( "var1=",var1, " var2=", var2 ) 7.4.3 OPERADORES ARITMÉTICOS E RELACIONAIS Os operadores aritméticos são: adição, subtração, multiplicação e divisão. Exemplos: a = 6/3 b = 2*10 c = 5-1 d = 20+9 Os operadores relacionais disponíveis são: < Menor que > Maior que <= Menor ou igual a >= Maior ou igual a
  54. 54. 54 == Igual a != Diferente de 7.4.4 ORDEM DE PRECEDÊNCIA DOS OPERADORES Os operadores têm a ordem de precedência usual. Essa ordem pode ser mudada com o uso de parênteses A lista abaixo apresenta os operadores, em ordem decrescente de precedência: ^ not -(unário) * / + - 7.4.5 COMENTÁRIOS A linguagem provê recurso de inserção de comentários. Dessa forma o código poderá ser comentado conforme a necessidade do programador. Para isso deverá ser usado o caractere “#”. Exemplo: # Isso é um comentário Variavel=123 # Comentando o código. A partir do # a linguagem vai ignorar o trecho até o fim de linha (n) 7.4.6 FUNÇÕES DA LINGUAGEM Para criação da linguagem foi necessário definir e criar as funções de manipulação de string, conversão de tipos e funções básicas. 7.4.6.1 FUNÇÕES DE MANIPULAÇÃO DE STRING Função strlen( str ) DESCRIÇÃO Informa o tamanho de uma string. ARGUMENTOS str string a ser medida RETORNO Retorna o número de caracteres presentes na cadeia de caracteres. EXEMPLO print(strlen("Universidade Anhembi Morumbi")) # imprime o valor 28.
  55. 55. 55 Função strlower( str ) DESCRIÇÃO Todas as letras maiúsculas passadas na variavel str são trocadas pelas minúsculas correspondentes. ARGUMENTOS str string a ser transformada RETORNO Retorna a string transformada. EXEMPLO print(strlower("Teste")) # Imprime teste. Função strupper( str ) DESCRIÇÃO Todas as letras minúsculas passadas na variável str são trocadas pelas maiúsculas correspondentes. ARGUMENTOS str string a ser transformada RETORNO Retorna a string transformada. EXEMPLO print(strlower("Teste")) # Imprime TESTE. 7.4.6.2 FUNÇÕES DE CONVERSÃO DE TIPOS Função tonumber( var ) DESCRIÇÃO Tenta converter a variavel var em um valor numérico. ARGUMENTOS a expressão a ser transformada em valor numérico RETORNO Se for possível a conversão, retornará o valor numérico, caso contrário retornará <null> EXEMPLO print(tonumber("23 "), tonumber("7.1 X"), tonumber(22))
  56. 56. 56 # imprime os valores: 23, <null>, 22 Função tostring( var ) DESCRIÇÃO Tenta converter a variável var em um valor string. ARGUMENTOS a expressão a ser transformada em valor string RETORNO O correspondente em string EXEMPLO print(tostring( 22 )) # imprime os valores: "23" 7.4.7 CONTROLE DE FLUXO E LAÇOS ITERATIVOS Foi necessário a criação de controles de fluxo e laços iterativos que serão descritos a seguir. 7.4.7.1 TOMADAS DE DECISÃO COM IF O comando para tomada de decisão da linguagem DFN é o if. Sua forma é: if expr then bloco endif ou if expr then bloco1... else bloco2... endif ou ainda if expr1 then bloco1 elseif expr2 then bloco2
  57. 57. 57 ... elseif expr N then bloco N else bloco N+1 endif 7.4.7.2 LAÇOS ITERATIVOS COM TOMADA DE DECISÃO NO INÍCIO (WHILE) A linguagem DFN possui duas opções para construção de laços iterativos, o comando while permite que a tomada de decisão seja no inicio antes de entrar no laço. Sua forma geral é: while expr do bloco endwhile Isto é, enquanto a expressão expr produzir um valor diferente de null e, portanto, verdadeiro, os comandos do bloco são executados. Considere o código abaixo que calcula o fatorial de um número armazenado na variável n: fat = 1 i = n while i > 0 do fat = fat * i i = i – 1 endwhile Ao final da execução do código acima, fat armazena o valor do fatorial de n e i armazena o valor zero. 7.4.7.3 LAÇOS ITERATIVOS COM TOMADA DE DECISÃO NO FIM (REPEAT/UNTIL) Este tipo de laço é implementado pelo comando repeat/until. A validação da condição é feita após o bloco ser executado por, pelo menos, uma vez. Sua forma geral é: repeat bloco until expr O mesmo exemplo do fatorial acima pode ser reescrito usando o repeat/until conforme a seguir: fat = 1 i = 1
  58. 58. 58 repeat fat = fat * i i = i + 1 until i > n 7.4.8 ANALISADOR DE EXPRESSÃO O analisador de expressão adotado na linguagem foi baseado nas ferramentas bison com gerador de parser em conjunto com o gerador de analisador sintático flex a partir da gramática previamente definida. O código resultante foi modificado para otimização da linguagem. gerando dois fontes: y_tab.c e lex_yy.c, a implementação das funcionalidades foram escritas nos demais arquivos "C". A função de entrada é a dfn_execfile, ela recebe o ponteiro para o arquivo a ser executado e chama a função dfn_parse() que por sua vez chama o yyparse() que realiza toda a tradução ou interpretação do código junto com a função dfn_execute(). O trecho da função yyparse() é extremamente grande, assim como a dfn_execute(), e podem ser vistos no apendice deste documento. Segue o trecho responsável pela execução do arquivo fonte dfn: int dfn_execfile(char *filename) { int x, y; y = dfn_openfile(filename); if (y) return 1; x=dfn_parse(); if( x ){ dfn_closefile(); return 1; } dfn_closefile(); return 0; } Função dfn_parse(void)
  59. 59. 59 int dfn_parse(void) { Byte *initcode = maincode; err = 0; if (yyparse() || (err == 1)) return 1; *maincode++ = HALT; if (dfn_execute(initcode)) return 1; maincode = initcode; return 0; } 7.5 IMPLEMENTAÇÃO DA LINGUAGEM INTERPRETADA NO SISTEMA PARAVIRTUALIZADO O ambiente final criado para implementação e utilização da linguagem desenvolvida nos capítulos anteriores é exemplificado através da figura 20 com uma máquina host que porta a VM com o Asterisk instalado e configurado para utilizar a linguagem proposta interligada a telefones através de um switch e um aparelho ATA. Figura 20 – Topologia final Fonte: O autor
  60. 60. 60 Figura 21 – Módulo carregado com sucesso Fonte: O autor Figura 22 – Módulo não carrega sem extensions.dfn Fonte: O autor
  61. 61. 61 A figura 21 mostra que os módulos do Asterisk foram carregados com sucesso utilizando a linguagem DFN. A figura 19 mostra que o módulo foi carregado com sucesso e que o Asterisk está pronto para fazer e receber ligações. A figura 20 mostra que não é possível carregar os módulos do Asterisk sem utilizar o arquivo extensions.dfn. Figura 23 – CDR Fonte: O autor A figura 23 mostra o registro da chamada, também conhecido como CDR da ligação de teste realizada. Foram realizados testes simples de chamada entre dois ramais 4001 e 4002 onde o asterisk executou o código abaixo: arquivo: extensions.dfn Código: contexto = getcontext() # Obtém o contexto da ligação que está entrando exten = getexten() if contexto == "from-internal" then Dial(SIP/exten,50,RTt) # Encaminha a chamada para o Ramal obtido da variável extena endif
  62. 62. 62 Figura 24 – Ligação realizada Fonte: O autor A figura 23 mostra que o teste com o arquivo .dfn foi realizado com sucesso.
  63. 63. 63 8 CONCLUSÃO Levando-se em conta o que foi observado, pode-se concluir que uma linguagem de programação interpretada (extensível) facilita a parametrização de aplicativos que necessitam do uso de configuração para seu funcionamento, assim como é capaz de permitir a inclusão de novas funcionalidades ao aplicativo. A linguagem desenvolvida neste trabalho demonstrou que, apesar da dificuldade, em função de sua complexidade, para criar e integrá-la a um aplicativo hospedeiro, é possível e recomendável o seu uso, pois uma vez agregada esta funcionalidade ao hospedeiro, a linguagem embarcada expande a capacidade de funcionamento do aplicativo em si. O ambiente criado utilizando a paravirtualização demonstrou que é possível garantir um SLA elevado, uma vez que na indisponibilidade de um hardware, outro poderá assumir como hospedeiro de uma cópia da máquina paravirtualizada. Como trabalhos futuros pode-se apontar o estudo e criação de um ambiente altamente disponível (cluster) utilizando a paravirtualização como plataforma e o Asterisk como software hospedeiro. Além disso, pode-se realizar trabalhos relacionados a testes de desempenho utilizando paravirtualização e virtualização completa com hardwares que utilizam tecnologias Intel-VT ou AMD-V. A linguagem aqui proposta, possui potencial para a sua ampliação em trabalhos futuros como a implementação da geração dos CDRs para ambiente de telefonia VoIP. Trata-se de um recurso importante, pois os CDRs são os registros das chamadas realizadas em um ambiente de telefonia.
  64. 64. 64 REFERÊNCIAS BIBLIOGRÁFICAS AMD. Mais eficiência na plataforma de virtualização. Disponível em: <http://www.amd.com/br- pt/Processors/ProductInformation/0,,30_118_8796_14287,00.html>.Acesso em: 25 maio 2010. ARANGO, M. Media Gateway Control Protocol (MGCP). Disponível em inglês: <http://tools.ietf.org/html/rfc2705>. Acesso em 2 jul. 2010. ASTERISK, BRASIL. O que é o Asterisk? Disponível em: <http://www.asteriskbrasil.org/>. Acesso em: 20 set. 2010. ASTERISK. Asterisk Coding Guideline. Disponível em inglês: <http://www.asterisk.org/developers/coding-guidelines>. Acesso em 10 out 2010. BELLARD, Fabrice. QEMU, a Fast and Portable Dynamic Translator. Disponível em inglês: <http://www.usenix.org/publications/library/proceedings/usenix05/tech/freenix/full_pap ers/bellard/bellard.pdf>. Acesso em: 29 maio 2010. BOCHS. Welcome to the Bochs IA-32 Emulator Project. Disponível em inglês: <http://bochs.sourceforge.net/>. Acesso em: 25 maio 2010. CASSIMIRI, Alexandre. Virtualização: da teoria a soluções. Porto Alegre: Ufrgs, 2008. 207 p. Disponível em: <http://www.gta.ufrj.br/ensino/CPE758/artigos-basicos/cap4-v2.pdf>. Acesso em: 20 maio 2010. CALDAS, Anderson. Introdução a Linguagens de Programação. Alagoas: Universidade Federal de Alagoas, 2010. 18 slides. Disponível em: <http://www.lccv.ufal.br/downloads/cursos/curso-basico-de-c- 2010/arquivos/apresentacoes/Aula%2001.1%20- %20Introducao%20a%20Linguagem%20de%20Programacao%20C.pptx/>. Acesso em: 10 de jul. 2010. CARTER, Nicholas. Arquitetura de Computadores. Illinois, 2002. 236 p. CHANTRY, Darryl. Mapping applications to the cloud. Disponível em inglês: <http://msdn.microsoft.com/en-us/library/dd430340.aspx>. Acesso em: 28 abr. 2010. CREASY, R. J.. IBM Journal of Research and Development: The origin of the VM/370 time-sharing system. v. 25, n. 5, p. 483–490 Palo Alto, Ca, Usa: Ibm, 1981. Disponível em inglês: <http://pages.cs.wisc.edu/~stjones/proj/vm_reading/ibmrd2505M.pdf>. Acesso em: 25 abr. 2010. DAVENPORT, Malcolm. Asterisk as a Swiss Army Knife of Telephony. Disponível em inglês:
  65. 65. 65 <https://wiki.asterisk.org/wiki/display/AST/Asterisk+as+a+Swiss+Army+Knife+of+Tel ephony>Acesso em: 20 set. 2010. DIKE, Jeff. The User-mode Linux Kernel Home Page. Disponível em inglês: < http://user-mode-linux.sourceforge.net/>. Acesso em: 25 abr. 2010. FIGUEIREDO, Luiz Henrique de; IERUSALIMSCHY, Roberto; CELES, Waldemar. A Linguagem Lua e suas aplicações em jogos. Disponível em: <http://www.lua.org/doc/wjogos04.pdf>. Acesso em: 09 abr. 2010. GARTNER. Special Report Virtualization. Disponível em inglês: <http://www.gartner.com/it/products/research/virtualization/virtualization.jsp?ref=3_28 _08LR>. Acesso em: 25 abr. 2010. GOLDEN, Bernard; SHEFFY, Clark. Virtualization for Dummies. Indianapolis: Wiley, 2008. 50 p. Disponível em inglês: <http://www.pcworld.com.vn/Handler/FileDowload.ashx?fileId=5150>. Acesso em: 02 maio 2010. GUY, Ed. IANA Registration for IAX. Disponível em inglês: <http://tools.ietf.org/html/draft-ietf-enum-iax-05>. Acesso em: 02 jul. 2010. IBM. Compiled versus Interpreted languages. Disponível em inglês: <http://publib.boulder.ibm.com/infocenter/zos/basics/topic/com.ibm.zos.zappldev/zappl dev_85.htm>. Acesso em 21 set. 2010. IBM. IBM Systems Virtualization. Version 2 Release 1. Disponível em inglês: <http://publib.boulder.ibm.com/infocenter/eserver/v1r2/topic/eicay/eicay.pdf>. Acesso em 20 mai. 2010. IBM; JONES, M. Tim. Virtual Linux. Disponível em inglês: <http://www.ibm.com/developerworks/library/l-linuxvirt/>. Acesso em: 02 jun. 2010. IETF. Session Initiation Protocol (sip). Disponível em inglês: <http://datatracker.ietf.org/wg/sip/charter/>. Acesso em 05 jul. 2010. INTEL. Virtualization. Disponível em inglês: <http://www.intel.com/technology/virtualization/>. Acesso em: 25 maio 2010. JONES, M. Tim. Virtual Linux. An overview of virtualization methods, architetures and implementations. Disponível em inglês: <http://www.ibm.com/developerworks/linux/library/l-linuxvirt/>. Acesso em: 29 abr. 2010. KVM. Kernel Based Virtual Machine. Disponível em inglês: <http://www.linux-kvm.org>. Acesso em: 31 maio 2010.
  66. 66. 66 LOUDEN, C. Kenneth. Compiladores. Princípios e práticas. San Jose State University, 2004, 569 p. MANFRIN, Alexander. História: Conhecendo a origem da virtualização. Disponível em: <http://www.vmworld.com.br/br/index.php?option=com_content&view=article&id=80: historia-conhecendo-a-origem-da-virtualizacao&catid=50:virtualizacao>. Acesso em 20 maio 2010. MENASCÉ, Daniel A. Virtualization: Concepts, Applications, and performance modelling. Disponível em inglês: <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.6680&rep=rep1&type=p df>. Acesso em: 20 maio 2010. MICROSOFT. Hyper-V Server 2008 R2. Disponível em: <http://www.microsoft.com/brasil/servidores/hyper-v-server/default.mspx>. Acesso em: 31 maio 2010. ORIGUELA, Marcos. Paravirtualização com o Xen. Disponível em: <http://www.vivaolinux.com.br/artigo/Paravirtualizacao-com-o-Xen/>. Acesso em 29 maio 2010. PETTEY, Christy. Gartner Says Virtualization Will Be the Highest-Impact Trend in Infrastructure and Operations Market Through 2012. Disponível em inglês: <http://www.gartner.com/it/page.jsp?id=638207>. Acesso em: 25 abr. 2010. PROEBSTING, Todd A. Disruptive Programming Language Technologies: Microsoft Research. Disponível em inglês: <http://research.microsoft.com/en-us/um/people/toddpro/papers/disruptive.ppt>. Acesso em: 09 abr. 2010. QEMU. About. Disponível em inglês: <www.qemu.org>. Acesso em: 29 maio 2010. SEBESTA, Robert W. Conceitos de linguagem de programação. 5º Edição, 2002. 634 p. SHIELDS, Greg. The Shortcut Guide to Selecting the Right Virtualization Solution. San Francisco: Realtime Publishers, 2008. 72 p. Disponível em inglês: <http://nexus.realtimepublishers.com/sgsrvs.php>. Acesso em: 01 maio 2010. Stanford University. Interpreted Languages. Disponível em inglês: <http://pangea.stanford.edu/computerinfo/unix/programming/interpreted/>. Acesso em 10 ago. 2010. UBERHIP. Paravirtualization. Disponível em: <http://uberhip.com/godber/plug/Xen_Primer/assets/paravirtualization.png>. Acesso em: 02 maio 2010. VMWARE. Deploy the Most Advanced and Production-Proven Hypervisors. Disponível em inglês:
  67. 67. 67 <http://www.vmware.com/products/esx/index.html>. Acesso em: 30 maio 2010. VMWARE. History of Virtualization. Disponível em inglês: <http://www.vmware.com/virtualization/history.html>. Acesso em: 02 abr. 2010. VMWARE, Understanding Full Virtualization, Paravirtualization, and Hardware Assist. Disponível em inglês: <http://www.vmware.com/files/pdf/VMware_paravirtualization.pdf>.Acesso em 03 abr. 2010. XEN. What is in Xen. Disponível em inglês: <http://www.xen.org/>. Acesso em: 01 jun. 2010. XEN. Xen Architecture Overview. Disponível em inglês: <http://wiki.xen.org/xenwiki/XenArchitecture?action=AttachFile&do=get&target=Xen +Architecture_Q1+2008.pdf>. Acesso em: 2 jun. 2010.
  68. 68. 68 APÊNDICE A – CÓDIGO FONTE DA LINGUAGEM /* * dfn.c * * Programa criado para demonstracao de uso standalone da linguagem dfn */ #include <stdio.h> #include "dfn.h" #include "dfnlib.h" int main(int argc, char *argv[]) { if (argc < 2) { puts("Usage: dfn <filename.dfn>"); return 0; } dfn_execfile(argv[1]); return 0; } /* **DFN.h */ #ifndef dfn_h #define dfn_h typedef void (*dfn_CFunction) (void); typedef struct Object *dfn_Object; #define dfn_register(ref,func) (dfn_globalref(ref), dfn_pushcfunction(func)) void dfn_errorfunction(void (*fn) (char *s)); void dfn_error(char *s); int dfn_execfile(char *filename); int dfn_dostring(char *string); int dfn_call(char *functionname, int nparam); dfn_Object dfn_getparam(int number); float dfn_getnumber(dfn_Object object); char *dfn_getstring(dfn_Object object); char *dfn_copystring(dfn_Object object); dfn_CFunction dfn_getcfunction(dfn_Object object); void *dfn_getuserdata(dfn_Object object); dfn_Object dfn_getfield(dfn_Object object, char *field); dfn_Object dfn_getindexed(dfn_Object object, float index); dfn_Object dfn_getglobal(char *name); dfn_Object dfn_pop(void); int dfn_pushnil(void); int dfn_pushnumber(float n);
  69. 69. 69 int dfn_pushstring(char *s); int dfn_pushcfunction(dfn_CFunction fn); int dfn_pushuserdata(void *u); int dfn_pushobject(dfn_Object object); int dfn_globalref(char *name); int dfn_storefield(dfn_Object object, char *field); int dfn_storeindexed(dfn_Object object, float index); int dfn_isnil(dfn_Object object); int dfn_isnumber(dfn_Object object); int dfn_isstring(dfn_Object object); int dfn_istable(dfn_Object object); int dfn_iscfunction(dfn_Object object); int dfn_isuserdata(dfn_Object object); #endif /* ** hash.c */ #include <string.h> #include <stdlib.h> #include "objects.h" #include "hash.h" #include "inout.h" #include "table.h" #include "dfn.h" // Pseudofuncs #define streq(s1,s2) (strcmp(s1,s2)==0) #define strneq(s1,s2) (strcmp(s1,s2)!=0) // Encapsulando as funcoes de alocacao de memoria do C #define new(s) ((s *)malloc(sizeof(s))) #define newvector(n,s) ((s *)calloc(n,sizeof(s))) #define nhash(t) ((t)->nhash) #define nodelist(t) ((t)->list) #define list(t,i) ((t)->list[i]) #define ref_tag(n) (tag(&(n)->ref)) #define ref_nvalue(n) (nvalue(&(n)->ref)) #define ref_svalue(n) (svalue(&(n)->ref)) static int head(Hash * t, Object * ref) { if (tag(ref) == T_NUMBER) return (((int) nvalue(ref)) % nhash(t)); else if (tag(ref) == T_STRING) { int h; char *name = svalue(ref); for (h = 0; *name != 0; name++) { /* name as bin */ h <<= 8; h += (unsigned char) *name; h %= nhash(t); } return h; } else {
  70. 70. 70 dfn_reportbug("unexpected type to index table"); return -1; } } static Node *present(Hash * t, Object * ref, int h) { Node *n = NULL, *p; if (tag(ref) == T_NUMBER) { for (p = NULL, n = list(t, h); n != NULL; p = n, n = n- >next) if (ref_tag(n) == T_NUMBER && nvalue(ref) == ref_nvalue(n)) break; } else if (tag(ref) == T_STRING) { for (p = NULL, n = list(t, h); n != NULL; p = n, n = n- >next) if (ref_tag(n) == T_STRING && streq(svalue(ref), ref_svalue(n))) break; } if (n == NULL) return NULL; return n; } static void freelist(Node * n) { while (n) { Node *next = n->next; free(n); n = next; } } /* */ Hash *dfn_hashcreate(unsigned int nhash) { Hash *t = new(Hash); if (t == NULL) { dfn_error("not enough memory"); return NULL; } nhash(t) = nhash; markarray(t) = 0; nodelist(t) = newvector(nhash, Node *); if (nodelist(t) == NULL) { dfn_error("not enough memory"); return NULL; } return t; } /* */ void dfn_hashdelete(Hash * h) { int i; for (i = 0; i < nhash(h); i++)
  71. 71. 71 freelist(list(h, i)); free(nodelist(h)); free(h); } /* */ Object *dfn_hashdefine(Hash * t, Object * ref) { int h; Node *n; h = head(t, ref); if (h < 0) return NULL; n = present(t, ref, h); if (n == NULL) { n = new(Node); if (n == NULL) { dfn_error("not enough memory"); return NULL; } n->ref = *ref; tag(&n->val) = T_NIL; n->next = list(t, h); list(t, h) = n; } return (&n->val); } /* */ void dfn_hashmark(Hash * h) { int i; markarray(h) = 1; for (i = 0; i < nhash(h); i++) { Node *n; for (n = list(h, i); n != NULL; n = n->next) { dfn_markobject(&n->ref); dfn_markobject(&n->val); } } } /* */ #include "dfn.h" static void firstnode(Hash * a, int h) { if (h < nhash(a)) { int i; for (i = h; i < nhash(a); i++) { if (list(a, i) != NULL && tag(&list(a, i)->val) != T_NIL) { dfn_pushobject(&list(a, i)->ref); dfn_pushobject(&list(a, i)->val); return;
  72. 72. 72 } } } dfn_pushnil(); dfn_pushnil(); } void dfn_next(void) { Hash *a; Object *o = dfn_getparam(1); Object *r = dfn_getparam(2); if (o == NULL || r == NULL) { dfn_error("too few arguments to function `next'"); return; } if (dfn_getparam(3) != NULL) { dfn_error("too many arguments to function `next'"); return; } if (tag(o) != T_ARRAY) { dfn_error("first argument of function `next' is not a table"); return; } a = avalue(o); if (tag(r) == T_NIL) { firstnode(a, 0); return; } else { int h = head(a, r); if (h >= 0) { Node *n = list(a, h); while (n) { if (memcmp(&n->ref, r, sizeof(Object)) == 0) { if (n->next == NULL) { firstnode(a, h + 1); return; } else if (tag(&n->next->val) != T_NIL) { dfn_pushobject(&n->next- >ref); dfn_pushobject(&n->next- >val); return; } else { Node *next = n->next- >next; while (next != NULL && tag(&next->val) == T_NIL) next = next- >next; if (next == NULL) { firstnode(a, h + 1); return; } else { dfn_pushobject(&next->ref);
  73. 73. 73 dfn_pushobject(&next->val); } return; } } n = n->next; } if (n == NULL) dfn_error("error in function 'next': reference not found"); } } } /* ** hash.h */ #ifndef hash_h #define hash_h typedef struct node { Object ref; Object val; struct node *next; } Node; typedef struct Hash { char mark; unsigned int nhash; Node **list; } Hash; #define markarray(t) ((t)->mark) Hash *dfn_hashcreate(unsigned int nhash); void dfn_hashdelete(Hash * h); Object *dfn_hashdefine(Hash * t, Object * ref); void dfn_hashmark(Hash * h); void dfn_next(void); #endif /* ** inout.c */ #include <stdio.h> #include <string.h> #include "objects.h" #include "hash.h" #include "inout.h" #include "table.h" /* Exported variables */
  74. 74. 74 int dfn_linenumber; int dfn_debug; int dfn_debugline; /* Internal variables */ #ifndef MAXFUNCSTACK #define MAXFUNCSTACK 32 #endif static struct { int file; int function; } funcstack[MAXFUNCSTACK]; static int nfuncstack = 0; static FILE *fp; static char *st; static void (*usererror) (char *s); /* */ void dfn_errorfunction(void (*fn) (char *s)) { usererror = fn; } /* */ static int fileinput(void) { int c = fgetc(fp); int ntemp=c; return (c == EOF ? 0 : c); } /* */ static void fileunput(int c) { ungetc(c, fp); } /* */ static int stringinput(void) { st++; return (*(st - 1)); } /* */ static void stringunput(int c) { st--; } /* */ int dfn_openfile(char *fn) { dfn_linenumber = 1;
  75. 75. 75 dfn_setinput(fileinput); dfn_setunput(fileunput); fp = fopen(fn, "r"); if (fp == NULL) return 1; if (dfn_addfile(fn)) return 1; return 0; } /* */ void dfn_closefile(void) { if (fp != NULL) { fclose(fp); fp = NULL; } } /* */ int dfn_openstring(char *s) { dfn_linenumber = 1; dfn_setinput(stringinput); dfn_setunput(stringunput); st = s; { char sn[64]; sprintf(sn, "String: %10.10s...", s); if (dfn_addfile(sn)) return 1; } return 0; } /* */ void dfn_error(char *s) { if (usererror != NULL) usererror(s); else fprintf(stderr, "dfn: %sn", s); } /* */ int dfn_pushfunction(int file, int function) { if (nfuncstack >= MAXFUNCSTACK - 1) { dfn_error("function stack overflow"); return 1; } funcstack[nfuncstack].file = file; funcstack[nfuncstack].function = function; nfuncstack++; return 0; }

×