Linguagem Interpretada para Aplicativos em Ambiente Paravirtualizado

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

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

BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO
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................................
______________________________________________________________________
Prof. ..............................
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

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.

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.

“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)

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.

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.

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

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

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

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

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

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
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
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
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
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
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
- 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
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
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
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
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
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
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
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
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
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
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

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
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
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
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
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
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
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
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
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
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
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
mantendo o funcionamento dos serviços sem a necessidade de reinstalação de uma nova
máquina.

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
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
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
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
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
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
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
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
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
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
== 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
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
# 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
...
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
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
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
Figura 21 – Módulo carregado com sucesso
Fonte: O autor
Figura 22 – Módulo não carrega sem extensions.dfn
Fonte: O autor

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
Figura 24 – Ligação realizada
Fonte: O autor
A figura 23 mostra que o teste com o arquivo .dfn foi realizado com sucesso.

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
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
<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
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
<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
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
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
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) {
return NULL;
}
return t;
}
/*
*/
void dfn_hashdelete(Hash * h)
{
int i;
for (i = 0; i < nhash(h); i++)

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) {
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
}
}
}
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
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
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
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;
}

Linguagem Interpretada para Aplicativos em Ambiente Paravirtualizado

Linguagem Interpretada para Aplicativos em Ambiente Paravirtualizado

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Semelhante a Linguagem Interpretada para Aplicativos em Ambiente Paravirtualizado

Semelhante a Linguagem Interpretada para Aplicativos em Ambiente Paravirtualizado (20)

Linguagem Interpretada para Aplicativos em Ambiente Paravirtualizado