aplicativos.
O último capítulo – CONCLUSÕES – trata das conclusões sobre as ferramentas utilizadas e dos resultados atingidos. Ficam também disponíveis algumas sugestões de continuação desse trabalho.
2 ASPECTOS TEÓRICOS
Esse capítulo traz a contextualização das tecnologias utilizadas no desenvolvimento do trabalho. Além de descrever a tecnologia Bluetooth e Java, também fala da utilização da API Bluetooth Java, utilizada por todo o trabalho.
2.1 Dispositivos Móveis
Dispositivos móveis são equipamentos capazes de processar e armazenar dados assim como computadores pessoais, mas se diferenciam desses pelo seu tamanho e capacidade de mobilidade. Seu maior ícone é o celular está presente na vida de grande parte da população.
Pode ser ainda dividido quanto às características específicas dependendo da forma como é analisado, como será visto no capítulo sobre a linguagem Java.
2.2 A Tecnologia Bluetooth
Bluetooth é uma tecnologia de comunicação por rádio de baixa freqüência e de alcance entre 1 e 100 metros usado, principalmente, para interligar equipamentos eletrônicos e efetuar troca de dados a pequenas distâncias. Foi inicialmente desenvolvida como uma nova forma de conexão para dispositivos móveis e que aliasse baixo custo na integração com seus produtos e um baixo consumo de energia. A baixa potência de seus transmissores, apesar de limitar a distância pode aumentar a autonomia das baterias dos equipamentos portáteis (BRUCE &
GILSTER, 2002). 981), rei viking que unificou a Dinamarca e a Noruega (BRUCE & GILSTER, 2002).
A idéia inicial era apenas interligar equipamentos sem a necessidade de cabos, utilizando ondas de rádio e circuitos baratos que pudessem ser incorporados sem muito ônus.
Mas logo se tornou uma concorrente a redes WLans.
Em 1999 o consórcio Bluetooth emitiu um documento de 1500 páginas da versão 1.0 da nova tecnologia. Pouco depois, o IEEE, que também estudava a área de redes sem fio, adotou a especificação do padrão Bluetooth e começou a alterá-la, a qual difere da padronização criada pelo SIG principalmente no que diz respeito ao foco dos estudos. O Bluetooth é um padrão completo, que vai desde a camada física até a camada de aplicação. O IEEE se compromete a padronizar apenas as camadas física e de enlace (TANENBAUM, 2003).
O padrão Bluetooth formalizado pelo IEEE está descrito dentro da pilha 802.15 de protocolos que formaliza as Pans. Isso não quer dizer que o SIG, como se conheceu, deixou de existir ou enfraqueceu, mas o que se espera é que futuramente os dois venham a se juntar em um único padrão. interligam por um nó de ponte. Várias piconets interligadas são denominadas uma scatternet (TANENBAUM, 2003).
Mas uma piconet não se limita a sete membros conectados apenas. Podem fazer parte da mesma piconet ainda 255 nós inativos. São ditos estacionados e ficam em estado de baixa energia. Eles podem apenas responder a um sinal de ativação passado pelo nó mestre. Com isso eles são ativados e tomam o lugar de algum outro nó ativo anteriormente (TANENBAUM, 2003).
A seguinte imagem exibe duas piconets, A e B, formando uma scatternet:
Figura 1 - Scatternet formada por duas piconets
O motivo para que seja utilizada a arquitetura tipo mestre/escravo é que seus arquitetos pretendiam disponibilizar circuitos Bluetooth por menos de cinco dólares (TANENBAUM, 2003).
2.2.2 Pilhas de protocolos do Bluetooth
Como descrevem Hopkins e Antony (2003), a pilha de protocolos Bluetooth é o agente de controle que atua sobre o dispositivo Bluetooth. Ela pode estar na forma de software, firmware, hardware ou um misto dos três. A pilha de protocolos permite a comunicação com outros dispositivos Bluetooth e também a comunicação com o próprio dispositivo. Os protocolos se dividem entre camadas e perfis.
A seguir estão descritas as camadas e o modo que elas agem conforme descrito por Hopkins e Antony (2003) e a Figura 2 exibe como elas estão organizadas:
A Interface de Controle do Nó (HCI) é a camada que entrega os dados diretamente para o dispositivo Bluetooth. Por ela trafega tudo a ser recebido ou enviado (voz e dados).
O Protocolo de Adaptação e Controle do Link, também chamado de L2CAP, faz o empacotamento de segmentos de dados antes de serem enviados e remonta os pacotes entrantes tal como um protocolo multiplexador. Se for detectado um segmento de dados muito grande, esse protocolo quebra-o em pedaços menores para o envio. Cuida apenas de dados, pois o áudio tem acesso direto à camada HCI.
O Protocolo de Descoberta de Serviço (SDP) é usado para descobrir os serviços que cada dispositivo Bluetooth oferece. Os serviços devem ser publicados para que outros dispositivos o conheçam. Um bom exemplo de serviço oferecido é dado por uma impressora. Ela oferece o serviço de impressão de documentos. A descoberta de serviços será mais bem tratada em capítulo posterior.
RFCOMM é uma porta de comunicação serial. Por ser Wireless é conhecida como Porta de Comunicação por Rádio Freqüência e é capaz de simular uma porta serial comum.
A camada de Especificação do Protocolo de Controle de Telefonia (TCS-BIN) é usada para envio de sinais de controle ao dispositivo quando algum aplicativo utiliza áudio, como uma chamada telefônica com uso de fones de ouvido sem fio.
O Protocolo de Acesso sem Fio (WAP) é utilizado para conexão de internet.
Foi um protocolo adotado pelo SIG para suprir necessidades do Bluetooth e requer que os protocolos PPP, IP e UDP estejam presentes.
OBEX é o protocolo usado para transferência de arquivos entre dispositivos Bluetooth. Foi inicialmente desenvolvido para ser utilizado na comunicação Infra-Vermelho e, assim como o Protocolo de Acesso sem Fio foi adotado para ser utilizado no Bluetooth.
O Protocolo de Encapsulamento de Redes Bluetooth (BNEP) possibilita transmitir outros protocolos de rede por meio do Bluetooth.
Finalmente, o Protocolo de Dispositivo de Interface Humana (HID) lista as regras para transmissão de informações de dispositivos como teclados e mouse.
2.2.2.1 Perfis da Pilha de Protocolos Bluetooth
Normalmente, o arquiteto da aplicação utiliza a estrutura dos protocolos de rede e tenta descobrir como utilizá-los para servir ao propósito de seu aplicativo. O protocolo em si não dá pistas de como e para qual propósito deve ser utilizado. Diferentemente disso, o padrão Bluetooth em sua versão 1.1 identificava 13 tipos de aplicações diferentes que poderiam ser usadas pelos projetistas. Para se comunicar, os dispositivos deveriam implementar as mesmas
Figura 2 - Camadas do Protocolo Bluetooth
funcionalidades. Os chamados perfis, listados na tabela abaixo mostram bem quais eram as idéias principais do consórcio Bluetooth.
Nome Descrição
Acesso genérico Procedimento de gerenciamento de enlaces Descoberta de serviço Protocolo para descobrir serviços oferecidos Porta serial Substitui um cabo de porta serial
Intercâmbio genérico de objetos Define o relacionamento cliente/servidor para movimentação de objetos
Acesso de LAN Protocolo entre um computador móvel e uma LAN fixa Rede dial-up Permite que um notebook se conecte através de um celular Fax Permite que um equipamento de faz móvel se comunique com
um telefone móvel
Telefonia sem fio Conecta um aparelho telefônico à sua estação-base local Intercomunicador Intercomunicação digital
Fone de ouvido Permite a comunicação de voz sem o uso das mãos Push de objetos Fornece um meio para intercambiar objetos simples
Transferência de arquivos Fornece um recurso mais geral de transferência de arquivos Sincronização Permite sincronizar um PDA com outro computador.
A base para todos os outros perfis está no perfil de acesso genérico e junto com o perfil de descoberta de serviço, que tenta descobrir quais os serviços disponíveis em outros aparelhos, forma a base do Bluetooth e todos os aparelhos devem utilizar, pelo menos, esses dois perfis.
O perfil de porta serial é utilizado pela maioria dos outros perfis, pois programas que já utilizem a comunicação por portas seriais podem facilmente migrar para a rede sem fio Bluetooth. Interage diretamente com a camada RFCOMM.
2.3 JAVA
Java é uma linguagem de programação orientada a objetos que é compilada para um código intermediário, o Bytecode, que é processado por uma máquina virtual no momento da execução do programa. O Java tem como importante característica a não dependência da
Tabela 1 - Os perfis do Bluetooth
plataforma onde irá ser executada, desde que exista uma máquina virtual Java para essa plataforma. Têm sido muito utilizada em dispositivos de comunicação móveis, aparelhos receptores de sinal de TV digital, computadores e todo tipo de aparelhos que tenha um microprocessador.
Em 1991, a Sun Microsystems® financiou um projeto de pesquisa corporativa interna com o codinome Green, que deu origem ao desenvolvimento de uma linguagem de programação baseada em C++ batizada de Oak pelo seu criador James Gosling. Mais tarde, foi descoberto que esse nome já era usado para outra linguagem e em uma cafeteria local o nome Java (cidade de origem de um café importado) foi sugerido e aceito.
Inicialmente, o projeto Green previa uma linguagem de programação que rodasse em tudo que pudesse ter um microprocessador. O projeto passava por dificuldades, pois o mercado de equipamentos eletrônicos inteligentes, alvos da nova linguagem a ser desenvolvida, não estava se desenvolvendo tão rapidamente como era previsto e havia o risco do projeto ser cancelado. Nessa mesma época, a World Wide Web explodia e a Sun viu possibilidade de utilizar o Java para criar conteúdo dinâmico para páginas Web. Isso deu nova razão de existir ao Java(DEITEL, H.; DEITEL P., 2005).
Segundo Mary Campione e Kathy Walrath (2010) a linguagem de programação Java tem as seguintes características:
Para ser executado, um código Java escrito recebe a extensão .Java. O código é então compilado pelo compilador Javac. Um arquivo .class é criado e contém um código na
linguagem da Máquina Virtual chamado Bytecode. Ao ser executado uma nova instância da Máquina Virtual é lançada e traduz o código em Bytecodes para a linguagem nativa do sistema. É pela tradução do Byitecode em código nativo em tempo de execução que o arquivo .class pode ser executado em qualquer sistema nativo que tenha uma Máquina Virtual Java desenvolvida sem modificações (Mary Campione e Kathy Walrath, 2010).
A Figura 3 mostra o esquema de construção de um programa em Java:
JRE é um Kit que contém a máquina Virtual Java e bibliotecas utilizadas apenas para executar uma aplicação Java.
A plataforma Java é composta da Máquina Virtual e das APIs. As APIs são conjuntos de classes prontas para serem adicionadas ao projeto. APIs com características parecidas são agrupadas em bibliotecas e recebem o nome de pacotes. A Figura 4 exibe a integração entre máquina virtual e a API Java.
Conforme Jandl (2003) para escrever um programa Java são necessários um editor de textos ASCII e um Kit de desenvolvimento Java (JDK).
Figura 3 - Processo de criação de um programa Java
Figura 4 - Plataforma Java
Ao invés de se usar um editor de texto comum, existe a opção de utilizar um IDE (Ambiente de Desenvolvimento Integrado) para facilitar a digitação. O editor do IDE facilita a digitação do código-fonte e agilizando o processo.
O Java Deveolpment Kit é composto por:
Um compilador para linguagem Java
Uma máquina virtual
Um programa para geração de documentação (Javadoc)
Um utilitário para criar arquivos compactados Java Archive (jar)
Uma extensa biblioteca de classes padronizadas Java
Um ambiente de execução Java
Os Kits de desenvolvimento mais utilizados atualmente são os oferecidos pela Sun Microsystems e se dividem em:
Java SE – Java Standard Edition é utilizado para desenvolver a maioria dos aplicativos. É o padrão para se começar a desenvolver em Java.
Java EE – Java Enterprise Edition inclui um servidor de aplicativos, um servidor web, APIs específicas, suporte a Enterprise JavaBeans, Java Servlets APIs e suporte a tecnologia Java Server Pages (JSP).
Java ME – Utilizada para escrever aplicativos para plataformas com menor poder de processamento e memória, como é o caso de aplicativos para celulares e Set-up Boxes.
Java FX – Java FX Script Technology é uma linguagem que possibilita o desenvolvimento com alta produtividade de conteúdo para o ambiente Java.
Em seguida são descritos os Kits usados no desenvolvimento desse projeto.
2.3.1 Java Standard Edition
Java SE é composto das Bibliotecas necessárias para se executar um programa Java, da máquina virtual Java e ferramentas para se escrever programas Java, como compiladores e debugadores. É a base para desenvolver aplicativos Java e deve estar instalada mesmo que outro Kit seja utilizado.
Como descrito no site da Oracle (2010), atualmente o Java SE se encontra na versão 6.
2.3.2 Java Micro Edition
Conforme Knudsen e Li (2005), Java ME é o Kit da plataforma Java da Oracle utilizado para desenvolvimento de aplicativos para dispositivos de tamanho, processamento e quantidade de memória reduzidos tais como celulares, smartphones, pagers e set-up boxes.
O Java ME divide os dispositivos em três categorias: Configuração, Perfis e APIs opcionais.
A configuração dos aparelhos se baseia na capacidade de processamento e memória.
Há duas famílias de configuração: CDC e CLDC. Dispositivos classificados como CDC tem no mínimo 512 KB de memória de acesso somente de leitura (ROM), 256 KB de memória de acesso volátil (RAM), algum tipo de conexão de rede e devem aceitar uma versão completa da JVM. São representados por aparelhos GPS e set-up Boxes.
CLDC são aparelhos como menor poder de processamento e memória. Devem ter um mínimo de 160 KB de ROM
Os Perfis de dispositivos têm como base a configuração, mas classificam os dispositivos quanto a características mais específicas como se o aparelho possui display, qual seu método de armazenamento estático e quais os métodos de conexão, por exemplo. Além de configuração e perfil, podem ser disponibilizadas APIs específicas para cada dispositivo.
A Figura abaixo mostra algumas das configurações e perfis mais comuns.
Figura 5 - Configurações e Perfis mais comuns
2.3.3 API Bluetooth Java
Como descrito por Ropkins e Antony (2003), para se tornar um padrão Java aceito pela comunidade de desenvolvedores e empresas da área uma nova tecnologia deve passar por alguns processos de testes e certificações a fim de garantir sua aplicabilidade e eficiência. A JCP é uma comissão formada por empresas líderes do setor e por técnicos renomados que criam regras e testes para padronizar a tecnologia recém criada. JSR é um documento que contém as especificações dessa nova proposta de padronização. A JSR-82 faz parte da JCP que trata da API Bluetooth e é liderada pela Motorola tendo ajuda de mais dezessete empresas do setor e ainda auxílio individual de Peter Dawson, Steven Knudsen e Bread Threatt.
A comissão encarrega-se da criação de normas que norteiem a utilização da tecnologia, a Implementação de Referência (RI) e de um Kit para desenvolvimento (TCK).
Qualquer empresa que se baseie na JSR pode utilizá-la para criar seu próprio Kit de Desenvolvimento de Software (SDK). Existem muitas empresas que desenvolvem seu próprio SDK Java para Bluetooth e algumas estão listadas abaixo e uma versão atualizada dessa lista pode ser conseguida em www.JavaBluetooth.com.
Ericson Não Não Java Standart Edition Win-32, Linux
Esmertec Sim Não Java Micro Edition Win-32, Palm OS,
Pocket PC, outros
Harald Não Não Java Standart Edition Win-32, Linux, outros
Possio Sim Sim Java Micro Edition Win-32, Linux Tabela 2 - Kits de Desenvolvimento e suas Empresas
Fazem parte dos aplicativos Java Bluetooth os seguintes componentes (Ropkins e para o dispositivo Bluetooth. Más, apesar de estar presente na JSR-82 como sendo um item a ser implementado, não define como isso deve ser feito. Isso leva os fabricantes a construírem cada um seu próprio BCC, seja usando Java, seja usando uma linguagem nativa como C ou C++. Além disso, as funcionalidades definidas para cada BCC também podem variar.
Algumas funcionalidades descritas na JSR-82 são:
Configurações básicas de segurança
Mantém lista dos dispositivos já pareados (o dispositivo não precisa estar pareado naquele instante)
Mantém lista dos dispositivos considerados seguros
Contem mecanismo para pareamento de dispositivos
Contem mecanismo para autorizar requisições de conexão
Suas configurações não devem ser modificadas a não ser por ele mesmo
2.3.3.1 Pilha de Inicialização
Para preparar o dispositivo para operar, a pilha de protocolos deve ser inicializada. A pilha é a última camada de contato com o hardware do dispositivo e o habilita para transferir os dados. Para isso é utilizada uma seqüência de comandos que podem variar em relação ao Kit de desenvolvimento utilizado. Alguns Kits já configuram a pilha de uma maneira padrão e não necessitam que o programador o faça.
2.3.3.2 Gerência do Dispositivo
Continuando com a descrição da API Java Bluetooth feita por Ropkins e Antony (2003) e baseando-se na API Java Standart edition, para se obter informações a respeito do dispositivo utilizado e dos dispositivos pareados foram criadas as classes LocalDevice e RemoteDevice. Essas classes fazem parte do Perfil de Acesso Genérico e é a partir delas que é obtido acesso às configurações dos dispositivos. A classe DeviceClass é utilizada para obter informações sobre como é classificada a configuração que o dispositivo próximos tem, como smartphones, celulares, computadores, pontos de acesso, etc.
Classe Javax.Bluetooth.LocalDevice:
Essa classe é usada para se obter informações e manipular o dispositivo Bluetooth em uso. Só é possível ter uma instância dela por Máquina Virtual (JVM) já que para cada dispositivo Bluetooth em funcionamento é lançada uma instância da JVM.
Para se instanciar um objeto apto a obter as informações do dispositivo é usado o
O método getBluetoothAddress() devolve o endereço Bluetooth do dispositivo. Esse endereço é constituído por uma string de 12 caracteres de números hexadecimais.
public boolean localDevice.setDiscoverable(int modo):
Habilita a opção de ficar visível para os outros dispositivos Bluetooth.
A tabela 3 exibe as opções para modo disponíveis:
Modo de Acesso
Nome Completo Descrição Valor
Inteiro NOT_DISCOVERABLE, GIAC OU LIAC são retornadas em forma de números inteiros.
Classe Javax.Bluetooth.RemoteDevice:
Oferece acesso a um único dispositivo que esteja próximo.
public final String getBluetoothAddress():
Esse método retorna o endereço do dispositivo.
public String getFriendlyName(boolean alwaysAsk):
Devolve um nome amigável do dispositivo remoto questionado.
Classe Javax.Bluetooth.DeviceClass:
Essa classe possui dois métodos usados para descobrir a qual classe o dispositivo questionado faz parte. Os métodos public int getMinorDeviceClass() e public int
Tabela 3 - Modos de visibilidade do dispositivo Bluetooth
getMajorDeviceClass() retornam um número inteiro que pode ser usado para descobrir a classe de dispositivos. A tabela 4 relaciona algumas dessas classes.
Classe Maior Classe Menor Descrição da Classe Maior Descrição da Classe Menor
256 4 Computer Desktop
1280 64 Periféricos de Computador Teclado 1280 128 Periféricos de Computador Mouse
1536 32 Dispositivo de Imagem Câmera
1536 128 Dispositivo de Imagem Impressora
2.3.3.3 Descoberta de Dispositivos
Classe Javax.Bluetooth.DiscoveryAgent:
Essa classe é utilizada para descobrir os dispositivos que estão disponíveis ao redor.
O objeto localDevice instanciado para obter as propriedades do dispositivo local é utilizado também para instanciar um objeto que fará a busca por outros dispositivos:
LocalDevice localDevice = LocalDevice.getLocalDevice()
DiscoveryAgent discoveryAgent = localDevice.getDiscoveryAgent()
Essa classe possui dois métodos para efetuar a busca por dispositivos:
public boolean startInquiry(int codAcesso, DiscoveryListener listener):
Com esse método é possível iniciar uma pesquisa por dispositivos próximos. O codAcesso pode ser uma das três constantes: NOT_DISCOVERABLE, LIAC ou GIAC. Um objeto de uma classe que implementa a interface DiscoveryListener deve ser passado como
Tabela 4 - Classes de dispositivos Bluetooth
segundo parâmetro. Eventos são repassados a esse objeto à medida que novos dispositivos são encontrados.
public RemoteDevice[] retrieveDevice(int opcao):
Retorna uma lista de objetos do tipo RemoteDevice que possam ter sido encontrados pelo método startInquiry(). A variável opcao pode conter as constantes CACHED (0) ou PREKNOWN (1). CACHED pode ser um dispositivo encontrado em uma pesquisa recente, enquanto que PREKNOWN pode ser um dispositivo freqüentemente acessado.
Interface Javax.Bluetooth.DiscoveryListener:
Essa interface deve estar implementada na classe principal do aplicativo para que essa classe seja avisada quando um novo dispositivo for encontrado.
public void deviceDiscovered(RemoteDevice btDevice, DeviceClass code):
Esse método é chamado pela máquina virtual quando o método startInquiry() retorna um dispositivo encontrado. O RemoteDevice é uma referência ao dispositivo encontrado, enquanto que DeviceClass é o tipo de dispositivo encontrado referente a tabela 4.
2.3.3.4 Descoberta de Serviços
Com as instruções acima é possível instanciar o próprio dispositivo, procurar por dispositivos novos e instanciar os novos dispositivos. Mas para que seja possível executar alguma ação útil é necessário saber quais os tipos de serviço que cada dispositivo encontrado pode oferecer. Como exemplo, uma impressora encontrada tem o serviço de impressão registrado no seu SDDB. SDDB é um banco de dados de pequeno porte usado para armazenar os serviços de cada dispositivo.
Outra forma de encontrar o serviço disponibilizado por um dispositivo é consultar a classe de dispositivos da qual ele faz parte. Mas o serviço registrado no SDDB é mais específico do que os baseados apenas na classe de dispositivo, portanto mais utilizado.
No SDDB ficam armazenados os registros dos serviços que cada dispositivo pode executar na forma de um ServiceRecord.
Entradas em um ServiceRecord são chamadas de atributos e contêm um ID e um valor a ele atribuídos.
Os valores dos atributos chamados DataElements podem ser do tipo int, boolean,
Os valores dos atributos chamados DataElements podem ser do tipo int, boolean,