Introdução

 

Recentemente a Sun reagrupou as suas tecnologias Java em três edições: Java 2 Platform Enterprise Edition (J2EE), Java 2 Platform Standard Edition (J2SE), e Java 2 Platform Micro Edition (J2ME). Cada uma dessas edições está focada em um segmento de mercado específico.

Cada edição define um conjunto de ferramentas e suprimentos que podem ser usados com um produto particular:

-         JVMs para uma ampla gama de dispositivos

-         Bibliotecas e APIs especializadas para cada tipo de dispositivo

-         Ferramentas para desenvolvimento e configuração de dispositivos

 

O J2ME tem como alvo dois grupos distintos de produtos:

-         dispositivos pessoais, móveis e conectados à informação (information connected): telefones celulares, pagers e PDAs são os melhores exemplos para esta classe

-         dispositivos compartilhados, fixos e conectados à informação (information connected): exemplos típicos são as Internet TVs, telefones com Internet, comunicadores high-end e sistemas de navegação de carros.

A linha divisória entre estas duas categorias é tênue devido à crescente convergência tecnológica nas indústrias de informática, telecomunicações, equipamentos eletrônicos e entretenimento.A distinção entre os produtos de cada uma dessas indústria torna-se cada vez menor, e espera-se que no futuro os dispositivos usarão tecnologia wireless em detrimento das redes tradicionais atuais. Na prática, a divisão dos dois grupos é dada principalmente pela memória de programa disponível e pelo tamanho da tela.

 

Embora todos esses dispositivos tenham muitas coisas em comum, eles também diferem na forma, função e características. Para isso existe o conceito de configuração,. A especificação de uma configuração mínima em termos de hardware e bibliotecas padrão para o dispositivo, que é a Connected, Limited Device Configuration (CLDC), é prevista para a primeira categoria de produtos, e a Connected Device Configuration (CDC), para a segunda categoria de dispositivos.

Há ainda o conceito de perfil (profile). Um perfil é um conjunto de bibliotecas que são muito mais específicas a uma categoria de dispositivos do que as bibliotecas disponíveis pela configuração. Perfis são implementados ao topo da configuração.

Connected Limited Device Configuration

 

O CLDC tem como objetivo definir uma plataforma Java padrão, mínima para pequenos dispositivos com as seguintes características:

-         160kB a 512kB de memória disponível para a plataforma Java

-         processador de 16 a 32 bits

-         baixo consumo de energia, freqüentemente usando energia de baterias

-         conectividade a algum tipo de rede, em geral sem-fio. Conexão intermitente e banda limitada (em geral 9600bit/s ou menos)

 

Telefones celulares, pagers, PDAs, aparelhos domésticos e terminais de vendas são alguns dos dispositivos que podem suportar essa especificação.

 

Essa especificação é resultado do trabalho do grupo Java Community Process (JCP), que consiste de vários parceiros da indústria. As seguintes empresas se envolveram na definição da especificação

-         America Online

-         Bull

-         Ericsson

-         Fujitsu

-         Matsushita

-         Mitsubishi

-         Motorola

-         Nokia

-         NTT DoCoMo

-         Oracle

-         Palm Computing

-         RIM

-         Samsung

-         Sharp

-         Siemens

-         Sony

-         Sun Microsystems

-         Symbian

 

CLDC é uma tecnologia core que será usada como pase para um ou mais perfis. Um perfil J2ME define uma plataforma Java mais definida e focada para um mercado, categoria de dispositivo, ou indústria em particular.

 

Baseado na procura dos desenvolvedores desses tipos de dispositivos que, cada vez mais, querem desenvolver dispositivos que suportem conteúdo rico, dinâmico e interativo vindo de terceiros. Com a recente introdução dos telefones celulares com acesso à Internet, essa transição já está se encaminhando.

 

Como os recursos de software que cada dispositivo pode ter é muito variado, CLDC assume que um sistema operacional ou kernel mínimo esteja disponível para gerenciar o hardware. Este sistema operacional deve prover pelo menos uma entidade escalonável para rodar a Java virtual machine. Este sistema operacional não precisa suportar espaços de endereço separados ou processos, nem precisa garantir nenhum tipo de escalonamento real-time.

 

Esta especificação se aplica as seguintes áreas:

-         linguagem Java e características da máquina virtual

-         bibliotecas core Java  (java.lang.*, java.util.*)

-         entrada e saída

-         rede

-         segurança

-         internacionalização

 

A especificação CLDC não se aplica a:

-         gerência do tempo de vida da aplicação (instalação, execução, deleção)

-         interface com o usuário

-         tratamento de eventos

-         o alto-nível de aplicação (interação entre o usuário e a aplicação)

 

Essas características podem ser especificadas por perfis implementados ao topo do CLDC.

 

Ø      Arquitetura de Alto-Nível e Segurança

 

A arquitetura típica de um dispositivo CLDC é como abaixo.

 

Perfis

Bibliotecas CLDC

Java Virtual Machine

Sistema Operacional

 

No coração da implementação CLDC está a JVM que, à parte das diferenças específicas definidas na especificação, é de acordo com a especificação para JVMs e linguagem Java. A JVM tipicamente roda acima do sistema operacional que está fora do escopo da especificação.

Ao topo da JVM estão as bibliotecas, que são divididas em duas categorias:

-         as definidas pelo CLDC

-         as definidas pelos perfis

 

Ø     Gerência de Aplicações

 

Muitos dispositivos pequenos, de poucos recursos, não têm um sistema de arquivos ou qualquer outro mecanismo para guardar informação dinâmica baixada para o aparelho. assim, a implementação CLDC não requer que as classes Java baixadas de uma fonte externa permaneçam gravadas no dispositivo. A JVM pode simplesmente carregar os arquivos e discartá-los após.

Entretanto, em muitos dispositivos CLDC potenciais, é benéfico que seja possível executar a mesma aplicação Java várias vezes sem ter que baixá-la a toda hora. Isso é particularmente importante se a aplicação é baixada através de uma rede wireless, onde o custo para se baixar a aplicação é alto.

É assumido que o dispositivo CLDC tem a capacidade de gerenciar as aplicações Java residentes no aparelho. No nível mais alto, gerência de aplicações se refere à habilidade de:

-         inspecionar aplicações Java residentes no dispositivo

-         selecionar e executar aplicações Java

-         remover aplicações Java (se aplicável)

 

Devido as significantes variações entre os dispositivos, os detalhes da gerência de aplicações são muito específicos do dispositivo. Assim, geralmente a gerência de aplicações é feita em C ou alguma outra linguagem de baixo nível específica do sistema operacional.

 

Ø      Segurança

 

Uma das promessas da plataforma Java é dar segurança na troca de conteúdo entre aplicações em diferentes tipos de redes. Infelizmente, a quantidade de código usada para isso excede o tamanho de memória disponível para a JVM nos dispositivos CLDC. Assim, o modelo de segurança para CLDC é o de manter as coisas simples, permitindo soluções mais compreensíveis nas próximas versões da especificação.

É definido que a JVM não pode ser capaz de danificar o dispositivo em que está rodando. Para tanto, a JVM deve ser capaz de rejeitar arquivos de classe inválidos. Entretanto, é possível verificar se os programas são válidos. Há muitos outros fatores que não podem ser percebidos na validação, como acesso a dispositivos externos.

Para prover acesso controlado a recursos externos, a especificação Java provê o conceito do gerente de segurança. Entretanto ele requer muita memória para ser incluído em um dispositivo CLDC. Uma solução mais simples é necessária.

É usado então o modelo “caixa de areia” (sandbox), em que a aplicação é fechada em um ambiente onde são disponibilizadas apenas aquelas APIs definidas pelos perfis e classes licensiadas e suportadas pelo dispositivo.

Há também a necessidade de garantia por parte de implementação CLDC de que as classes do sistema não possam ser sobrescritas. Segurança na troca de dados e código entre servidores e dispositivos clientes, típico de redes wireless, não estão no escopo da especificação por serem dependentes do tipo de dispositivo.

 

Ø      Conformidade com a Especificação da Linguagem

 

A principal diferença entre a especificação completa da linguagem e a especificação CLDC é que a JVM no dispositivo CLDC não tem suport a ponto flutuante. Este suporte foi retirado por a maioria dos dispositivos alvos da especificação não possuirem suporte em hardware para ponto flutuante e o custo para o suporte em software seria muito elevado.

Assim, a JVM não pode permitir o uso de literais, tipo de dados, valores e operações em ponto flutuante.

 

Bibliotecas CLDC não incluem o método Object.finalize().

 

A JVM no CLDC deve suportar tratamento de exceções. Entretanto, o conjunto de exceções incluído nas bilbiotecas CLDC é reduzido, e conseqüentemente a capacidade de tratamento de erros é reduzida. Isso se deve por detalhes na recuperação de erros serem muito específicos do dispositivo e o número de classes de erro da especificação completa da linguagem ser muito grande para os dispositivos CLDC.

 

Ø      Conformidade com a Especificação da JVM

 

Como dito anteriormente, a JVM em dispositivos CLDC não possui suporte a ponto flutuante.

 

Muito foi eliminado da JVM nos dispositivos CLDC por as bibliotecas CLDC serem substancialmente mais limitadas. As seguintes características foram eliminadas:

-         Java Native Interface (JNI)

-         class loaders definidas pelo usuário

-         reflexão

-         thread groups e daemon threads

-         finalização (Object.finalize())

-         referências fracas

 

Aplicações escritas para CLDC não devem contar com nenhuma das características acima.

 

Um requerimento essencial para o CDLC é a capacidade de donwload dinâmico pela aplicações Java de conteúdo de terceiros. O mecanismo de carregamento dinâmico de classes na plataforma Java tem um papel central para habilitar isso.

A especificação CLDC define o uso de arquivos JAR para aplicações java que são representadas e distribuídas publicamente. Entretanto, em ambientes de rede fechados, formatos alternativos e mais compactos podem ser usados para preservar largura de banda.

 

Ø     Bibliotecas CDLC

 

O objetivo geral no desenvolvimento das bibliotecas CLDC é o de prover o conjunto mínimo necessário para um prático desenvolvimento de aplicações e definição de perfis para uma variedade de pequenos dispositivos. Dados a memória restrita e as características variadas dos dispositivos, é virtualmente impossível de se ter um conjunto de bibliotecas que agradaria todos.

Na definição das bibliotecas, foi usada a especificação Java original como base, dando-se bastante ênfase na conectividade.

 

A maioria das bibliotecas CLDC são um subconjunto das edições Java maiores (J2SE e J2EE) para garantir compatibilidade e portabilidade de aplicações.  Embora compatibilidade seja um objetivo muito desejado, as bibliotecas J2SE e J2EE possuem fortes dependências internas que dificultam a formação de subconjuntos destas bibliotecas. Por esta razão, algumas bibliotecas foram modificadas, especialmente na área de rede e I/O.

As bibliotecas  CLDC podem ser divididas em duas categorias:

-         as que são subconjunto das bibliotecas J2SE padrões

-         as que são específicas do CLDC (mas que podem ser mapeadas para J2SE)

 

Classes pertencentes à primeira categoria estão localizadas nos pacotes java.lang.*, java.util.* e java.io.*. Estas classes são derivadas do J2SE.

Classes pertencentes à segunda categoria estão localizadas no pacote java.microedition.*.

 

O CLDC inclui um suporte limitado à tradução de caracteres Unicode de e para uma seqüência de bytes. Em J2SE isso é feito usando objetos chamados Readers e Writers, e o mesmo mecanismo é usado aqui usando InputStreamReader e OutputStreamWriter.

Mobile Information Device Profile

 

O MIDP é a definição de uma arquitetura e APIs assoociadas necessárias para prover um ambiente de desenvolvimento aberto para MIDs (mobile information devices). O MIDP foi feito para rodar em cima do CLDC. Para tanto, um MID deve possuir as seguintes características mínimas de hardware (além daquelas que são requeridas pelo CLDC):

-         Display:

o       Tamanho da tela: 96x54;

o       Profundidade: 1 bit;

o       Formato do pixel (proporção de aspecto): 1:1;

-         Input:

o       “One handed keyboard” ou

o       “Two handed keyboard” ou

o       Touch Screen;

-         Memória:

o       128Kbytes para os componentes MIDP;

o       8Kbytes para dados das aplicações;

o       32Kbytes para o JAVA runtime;

-         Rede:

o       Duplex, sem fio, possivelmente intermitente e com largura de banda limitada.

 

Os MIDs possuem uma grande variedade de softwares de sistema. Por essa razão, o MIDP estabeleceu alguns requisitos mínimos de sistema:

-         Um kernel para controlar o hardware, que possua uma entidade escalonável para rodar a Máquina Virtual Java;

-         Um mecanismo para ler e escrever na memória para suportar as APIs;

-         Acesso de leitura e escrita à rede sem fio;

-         Um mecanismo que provenha um tempo-base utilizado no timestamping nas escritas na “persistent storage”;

-         Capacidade de escrever num display bit-mapped;

-         Um mecanismo para capturar entrada de um input device;

 

Como os MIDs possuem uma grande quantidade de potencialidades, o MIDPEG (grupo que elaborou o MIDP) limitou o conjunto de APIs necessárias para apenas aquelas necessárias para alcançar uma grande portabilidade. São as seguintes:

-         Aplicação;

-         Interface do Usuário;

-         Persistent Storage;

-         Rede;

-         Temporizadores (timers);

Ø      Arquitetura

 

A figura abaixo mostra como o MIDP se encaixa em um aparelho MID.

 

 

 

No nível mais abaixo está o hardware, e logo acima dele o seu sistema. Após, vem o CLDC, que é onde está a Máquina Virtual K (KVM). A KVM irá permitir que APIs Java de alto nível sejam construídas.

As APIs MIDP rodam em cima do CLDC, como foi explicado anteriormente e pode-se visualizar na figura. As classes OEM são classes não definidas pelo MIDP e podem ser utilizadas para funcionalidades específicas para determinado aparelho, o que significa que elas podem ou não ser portáveis para outros MIDs.

Quanto aos aplicativos, um MIDlet é aquele que usa APIs definidas pelo MIDP e CLDC, e são portáveis entre vários aparelhos. Uma aplicação OEM são aquelas que não fazem parte da especificação. Já as nativas são as que estão implementadas diretamente no sistema e não são escritas em Java.

 

Ø      Temporizadores

 

Aplicações que necessitem agendar tarefas para um tempo futuro pode utilizar as classes Timer e TimerTask, que incluem funções para uma execução ou várias execuções em determinados intervalos. Elas estão em java.util.Timer e java.util.TimerTask.

 

Ø      Rede

 

O MIDP herda a conectividade do CLDC e suporta um subconjunto do HTTP, que pode ser implementado com protocolos IP (TCP/IP) e não-IP (WAP e i-mode).

Como há uma grande variedade de redes sem fio, fica por responsabilidade do aparelho e da própria rede sem fio de providenciar o serviço de aplicação. Pode ser necessário um gateway para ligar a rede sem fio à internet. A aplicação cliente não deve precisar saber se há alguma rede não-IP sendo usada ou qualquer outra característica de outras redes. No entanto, essa possibilidade existe, o que faria o cliente e o servidor tirar vantagem deste conhecimento otimizando suas transmissões.

A interface HttpConnection possui funcionalidades que permitem a realização de funções específicas do HTTP. Qualquer aparelho que implemente MIDP deve suportar o HTTP 1.1, requisições HEAD, GET, POST e forms.

 

Ø      Persistent Storage

 

O MIDP disponibiliza um mecanismo para que as MIDlets possam guardar dados e lê-los mais adiante. É a chamada Record Management System (RMS).

-         Record Stores:

É uma coleção de registros que permanece o mesmo durante múltiplas chamadas do MIDlet. A plataforma é responsável por manter a integridade desses registros, mesmo após reboots ou trocas de baterias.

-         Records:

São vetores de bytes. Utilizados para armazenagem de diferentes tipos de dados. Eles são unicamente identificados pelo seu recordId, um valor inteiro.

 

 

 

Ø      Aplicações

 

O MIDP define um modelo de aplicação que permite que os recursos limitados dos MIDs sejam compartilhados por várias aplicações, as MIDlets. Este compartilhamento é viável mesmo com os limitados recursos e framework de segurança do MID pois eles são obrigados a compartilhar classes e estão sujeitos a um conjunto de políticas e controles que permitem isso.

Os elementos de uma MIDlet suite, dos quais se espera que implementem as funções necessárias pelos usuários para instalar, selecionar, rodar e remover midlets, são (seu conjunto forma o software de gerenciamento de aplicação):

-                     Ambiente de Execução: é compartilhado por todas as MIDlets que estão na mesma MIDlet suite, e qualquer MIDlet pode interagir com outra que esteja no mesmo pacote.

-                     Empacotamento do MIDlet suite: uma ou mais MIDlets podem ser empacotadas num único arquivo JAR, que contém as classes compartilhadas e os arquivos de recursos utilizados pelas MIDlets, além de um manifesto descrevendo seu conteúdo. Existem vários atributos pré-definidos que permitem identificação de uma MIDlet, como nome, versão, tamanho de dados, descrição, etc.

-                     Descritor de Aplicação: é utilizado para gerenciar a MIDlet e é usada pela própria MIDlet para atributos de configuração específica. O descritor permite que seja verificado que a MIDlet é adequada ao aparelho antes de se carregar todo o arquivo JAR da MIDlet suite. Ele também permite que parâmetros sejam passados para as MIDlets sem modificar os arquivos JAR.

-                     Ciclo de Vida da Aplicação:  uma MIDlet não deve possuir um método public void static main (). O software de gerenciamento de aplicação deve suprir a classe inicial necessária pelo CLDC para iniciar a MIDlet. Quando uma MIDlet é instalada, ela é mantida no aparelho e fica pronta para uso. Quando é rodada, uma instância é criada através de seu construtor público sem argumentos, e seus métodos são chamados para mudar passar pelos estados da MIDlet. Quando ela é terminada, é destruída, e os recursos utilizados por ela podem ser recuperados, incluindo os objetos criados e suas classes.

 

O software de gerenciamento de aplicação disponibilida um ambiente no qual a MIDlet é instalada, iniciada, parada e desinstalada. Também é responsável por manusear os erros que podem ocorrer durante alguma destas etapas.

O compartilhamento de dados e outras informações entre MIDlets é contralado pelas APIs individuais e suas implementações. Assim, por exemplo, os métodos da API de um sistema de gerenciamento de registros devem ser especificados para manusear com dados que podem ser compartilhados com outras MIDlets.

 

 

Bibliografia

Site do J2ME: java.sun.com/j2me Voltar ao Início