Universidade de So Paulo Instituto de Matemtica e Estatstica Departamento de Cincia da Computao MAC 499 Trabalho de Formatura Supervisionada

MobMed - Inovando a Prtica Mdica Atravs de Sistemas Mveis de Informao

Aluno: Alexandre Murakami NUSP: 300954 Prof. Orientador: Fabio Kon 2o semestre de 2003

ndice
1 Natureza da organizao e da atividade...............................................................................4 2 Objetivos do trabalho...........................................................................................................5 3 Estimativa inicial de prazos.................................................................................................6 4 Ferramentas e tcnicas utilizadas.........................................................................................7 4.1 Celulares........................................................................................................................7 4.1.1 Mensagens..............................................................................................................7 4.1.2 WAP e i-mode........................................................................................................8 4.1.3 Symbian e Brew.....................................................................................................8 4.2 PDAs............................................................................................................................9 4.3 Tablet PC.....................................................................................................................11 4.4 WiFi e Bluetooth.........................................................................................................12 4.5 XML............................................................................................................................13 4.6 J2ME...........................................................................................................................14 4.6.1 Exemplo de aplicao MIDP...............................................................................15 4.6.2 Plataformas compatveis com MIDP...................................................................16 4.6.3 ME4SE.................................................................................................................17 4.6.4 Diferenas entre MIDP 1.0 e MIDP 2.0...............................................................17 4.6.5 Bouncy Castle......................................................................................................17 4.6.6 Ofuscador.............................................................................................................18 4.6.7 Parsers XML para MIDP.....................................................................................18 4.6.8 Waba e SuperWaba..............................................................................................19 4.6.9 Impresses finais sobre o J2ME...........................................................................19 4.7 Java Servlets................................................................................................................20 4.8 Java Server Pages (JSP) e JavaBeans..........................................................................21 4.8.1 JavaBeans.............................................................................................................22 4.9 JavaServerFaces e Struts.............................................................................................23 4.9.1 Arquiteturas de sites.............................................................................................23 4.9.2 JavaServer Faces..................................................................................................24 4.9.3 Struts....................................................................................................................25 4.9.4 Impresses sobre o JavaServer Faces e o Struts..................................................26 4.10 Web Services.............................................................................................................27

Pgina 2 de 42

4.10.1 SOAP..................................................................................................................27 4.10.2 WSDL................................................................................................................27 4.10.3 UDDI..................................................................................................................27 4.10.4 A arquitetura Java para Web Services................................................................28 4.10.5 Tipos de dados usados em Web Service............................................................29 5 Arquitetura MobMed.........................................................................................................30 5.1 Viso geral da arquitetura...........................................................................................30 5.2 Arquitetura do Broker.................................................................................................30 5.3 Sistema de identificao de dispositivos.....................................................................32 5.4 Sistema de comunicao.............................................................................................35 5.5 Prximos passos para o projeto...................................................................................36 6 Relacionando a experincia obtida no trabalho com o BCC..............................................38 6.1 Desafios e frustraes encontrados.............................................................................38 6.2 Disciplinas cursadas no BCC mais relevantes para o projeto.....................................38 6.3 Interao com membros da equipe que tenham agido como mentores do trabalho....38 6.4 Diferenas notadas entre a forma de cooperao com colegas do BCC nas tarefas em grupo das disciplinas e a forma de trabalho conjunto na empresa....................................38 6.5 Observaes sobre a aplicao de conceitos estudados nos cursos no contexto prtico de aplicaes reais.............................................................................................................39 6.6 Se o aluno fosse continuar atuando na rea em que exerceu o estgio, que passos tomaria para aprimorar os conhecimentos tcnicos/metodolgicos/comerciais/cientficos/etc relevantes para esta atividade? ........39 7 Fontes.................................................................................................................................40 7.1 Computao mvel aplicada a medicina.....................................................................40 7.2 Celulares......................................................................................................................40 7.3 PDAs..........................................................................................................................40 7.4 Tablet PC.....................................................................................................................40 7.5 J2ME...........................................................................................................................41 7.6 Java (Servlets, JSP, JSF, Struts e Web Services)........................................................41 7.7 Outros..........................................................................................................................42

Pgina 3 de 42

1 Natureza da organizao e da atividade

Este trabalho de formatura sobre o projeto de iniciao cientfica desenvolvido pelo aluno no Servio de Informtica (Unidade de Pesquisa e Desenvolvimento) do Instituto do Corao (InCor). O InCor faz parte do complexo do Hospital das Clnicas e est associado Faculdade de Medicina da USP. O Servio de Informtica do InCor vm desenvolvendo projetos de pesquisa e desenvolvimento em Processamento de Imagens Mdicas e Sistemas Distribudos h mais de dez anos. Fazem parte do Servio de Informtica, entre outros, um pesquisador ps-doc, 3 doutores, alm de diversos doutorandos e mestrandos. Os pesquisadores do Servio de Informtica orientam alunos de diversas instituies de ensino, lecionam em cursos de Ps-Graduao da Escola Politcnica da USP (Dep. de Engenharia Eltrica) e participam ativamente das sociedades cientficas correlatas (SBEB - Sociedade Brasileira de Engenharia Biomdica e SBIS - Sociedande Brasileira de Informtica em Sade.

Pgina 4 de 42

2 Objetivos do trabalho
Atuei como aluno de iniciao cientfica em um projeto de pesquisa do Servio de Informtica (Unidade de Pesquisa e Desenvolvimento) do Instituto do Corao. O projeto chamado de MobMed - Inovando a Prtica Mdica Atravs de Sistemas Mveis de Informao e tem financiamento do CNPq. O Instituto do Corao (InCor) desenvolveu, em projetos anteriores, o Pronturio Eletrnico do Paciente (PEP). O PEP armazena, de maneira eletrnica, todos os dados dos pacientes do hospital. Ele disponibiliza informaes textuais (laudos, histrico clnico, diagnsticos), permite a execuo de ordens mdicas (prescrio eletrnica, pedidos de exames etc.) e controles de enfermagem (medicamentos, procedimentos etc.). Alm disso, possui um visualizador de imagens mdicas estticas e dinmicas (tomografia, ultra-som etc.) e um visualizador de sinais vitais (permite obter, em tempo real, os sinais vitais de um paciente da UTI). O PEP pode ser acessado pela Intranet do InCor. O objetivo do projeto MobMed permitir o acesso ao PEP atravs de dispositivos portteis. Ser criada uma rede sem fio (WiFi) dentro do hospital. Essa rede ser acessada atravs de computadores portteis, como handhelds e tablet PC's. O acesso tambm ser disponibilizado via celular. O projeto deve usar ferramentas de arquiteturas abertas e padres bem definidos de interfaceamento (XML, DICOM, HL7). A minha funo no projeto auxiliar o desenvolvimento de uma soluo no lado do dispositivo (cliente). Essa soluo deve permitir, num primeiro momento, a visualizao de dados textuais. O sistema deve, de maneira transparente ao usurio, identificar o dispositivo sendo utilizado para que as informaes sejam mostradas da melhor maneira possvel. importante tambm que haja uma preocupao com a segurana e o sigilo dos dados, especialmente por se tratar de um ambiente de comunicao sem fio. Tambm faz parte do meu trabalho auxiliar no projeto e implementao do software do servidor que faz o interfaceamento com os dispositivos (chamado, neste projeto de broker). Ele deve receber os dados vindos de outros aplicativos (que fazem consultas a bancos de dados, por exemplo) e convert-los para um formato adequado ao dispositivo cliente.

Pgina 5 de 42

3 Estimativa inicial de prazos

O cronograma de atividades do projeto MobMed prev, para o final deste ano (2003), a implementao de um prottipo para visualizao de dados textuais (sem entrada de dados). Para isso, foram definidas algumas atividades a serem cumpridas at o final do ano. As atividades com as quais eu estou diretamente relacionado so: Definio de uma arquitetura macro do sistema. Modelo lgico do broker. Definio de interfaces internas (XML). Definio da interface com o usurio. Implementao do prottipo. Implantao dos equipamentos de teste.

As atividades previstas esto atrasadas em relao ao cronograma estipulado. Foi definida uma arquitetura do sistema, bem como o modelo lgico do broker. Entretanto, alteraes podem se tornar necessrias nessas duas partes ainda. As interfaces internas e a interface com o usurio ainda no foram definidas. O prottipo est em fase inicial de implementao. Parte dos equipamentos para teste foram adquiridos e esto em funcionamento. Detalhes sobre o trabalho desenvolvido e os planos para o futuro sero apresentados posteriormente, em Arquitetura MobMed.

Pgina 6 de 42

4 Ferramentas e tcnicas utilizadas

Para o desenvolvimento do projeto, foram estudados diversos tpicos e ferramentas. A principal fonte de informao foi a internet (veja lista de sites na seo Fontes). Os principais assuntos estudados foram: Dispositivos portteis (PDAs, tablet PCs). Tecnologias de comunicao sem fio (tecnologias para celulares, WiFi, BlueTooth etc.) XML. Java para Internet (Servlets, JSP, JSF, Struts etc.) e para dispositivos portteis (J2ME).

4.1 Celulares
Os celulares so divididos segundo o protocolo de comunicao utilizado. A primeira gerao de celulares (1G) possua comunicao analgica e no permitia a transmisso de dados digitais. uma tecnologia em desuso. A segunda gerao de celulares (2G) usa comunicao digital e atualmente a tecnologia mais usada no pas. Celulares 2G permitem, alm da comunicao por voz, transmisso de dados digitais a baixa velocidade (14,4 Kbps), acesso a internet (WAP) e envio de mensagens SMS. Os protocolos mais utilizados so o TDMA (Time Divison Multiple Access), CDMA (Code-Division Multiple Access) e GSM. Esses protocolos permitem uma taxa de transmisso de cerca de 10 Kbps. Algumas extenses desses protocolos permitem taxas de transmisso da ordem de algumas dezenas de Kbps. o caso do CDMA 1xRTT, com taxa de transmisso de 144 kbps (adotada, por exemplo, pela Vivo), e do GPRS, extenso do GSM, com conexo permanente e taxa de transmisso da ordem de 50 kbps (adotada pela TIM). Esses protocolos so conhecidos como gerao 2,5G e esto comeando a ser implantados no pas. H ainda uma terceira gerao de celulares (3G), com taxas de transmisso ainda maiores, da ordem de centenas de kbps. O protocolo mais famoso o EDGE, a terceira gerao do GSM. Entretanto, ainda no h previses sobre quando essa tecnologia vai ser implantada no pas.

4.1.1 Mensagens
SMS (Short Message Service) um servio disponvel em celulares que permite o envio e recebimento de mensagens curtas de texto (at 160 caracteres). A maioria dos celulares modernos dispe desse recurso, embora ele no seja muito difundido no pas. Atualmente, dois novos padres tm sido adotados nos celulares mais modernos. So o EMS (Enhanced Message Service) e o MMS (Multimedia Message Service). Alm do envio de mensagens de texto, eles permitem o uso de imagens, som e vdeo nas mensagens.

Pgina 7 de 42

4.1.2 WAP e i-mode

WAP (Wireless Application Protocol) o equivalente ao HTTP para telefones celulares. O padro WAP define uma linguagem de markup (WML) semelhante ao HTML. Define tambm uma linguagem de script (WMLScript), semelhante ao JavaScript. As pginas WAP so bastante limitadas quanto aos recursos grficos e interao com o usurio. WAP possui, por exemplo, um protocolo de conexo segura, mas no permite, entre outras coisas, o uso de cookies. Para acessar uma pgina WAP, o usurio precisa de um telefone celular com um browser WAP. Celulares com essas caractersticas so bastante comuns atualmente. Entretanto, o uso de WAP no muito difundido entre os usurios de celulares no pas, apesar de ser uma tecnologia relativamente antiga. Outra tecnologia de Internet para celulares o i-mode. O i-mode foi desenvolvido no Japo pela empresa NTT DoCoMo e, diferentemente do WAP, tornou-se um sucesso comercial naquele pas. Semelhante ao WAP, possui uma verso simplificada do HTML, chamada de cHTML. As verses mais modernas de i-mode possuem suporte a aplicativos java e multimdia. O i-mode s disponvel no Japo.

4.1.3 Symbian e Brew

Symbian um sistema operacional para celulares desenvolvido por um consrcio de empresas de comunicao. Seu objetivo criar um padro para uso nos celulares de gerao 2,5G e 3G. Algumas das suas principais caractersticas: -

32 bits multitarefa; robusto; interface grfica flexvel; baixo consumo de memria e processamento; suporte a vrias tecnologias de comunicao celular: CDMA e suas extenses (cdma200 1x e WCDMA), GSM (GPRS, EDGE, EDGE RGPRS etc.) e outros;
suporte a vrios protocolos de comunicao (TCP/IP, Ethernet etc.)

navegao pela internet (WAP e HTML); mensagens (SMS, EMS, email etc.); suporte a multimdia (sons, imagens e vdeo); desenvolvimento de aplicativos em C++ e Java (Personal Java, JavaPhone e MIDP); sincronizao de dados (over-the-air usando SyncML, com PC usando porta serial, Bluetooth, infravermelho etc.) segurana (suporte a protocolos de criptografia).

Por enquanto, existem pouqussimos celulares no mundo que adotaram o padro Symbian. Brew tambm um sistema operacional, desenvolvido pela Qualcomm. Semelhante ao Symbian, tambm possui suporte a vrias tecnologias de comunicao celular, WAP, mensagens, C++ e Java (MIDP 1.0) entre outros. Sua principal caracterstica

Pgina 8 de 42

disponibilizar um sistema para download de aplicativos OTA. A Vivo anunciou uma parceria com a Qualcom para disponibilizar celulares Brew, mas o sistema ainda no entrou em operao.

4.2 PDAs
O PDA (Personal Digital Assistant), tambm conhecido como handheld ou palmtop, um computador porttil de pequenas dimenses (um pouco maior que uma calculadora). A maioria dos PDAs possui uma tela de cristal lquido sensvel ao toque e uma caneta para entrada de dados. Alguns PDAs possuem um pequeno teclado. Os PDAs possuem baixo poder de processamento e pouca memria quando comparados a um micro de mesa. Podemos dividir os PDAs em trs grupos, segundo o sistema operacional adotado: PDAs com sistema Palm OS PDAs com sistema Windows CE ou Pocket PC PDAs com sistema operacional prprio

O sistema Palm OS foi desenvolvido pela Palm Computing, empresa fabricante de PDAs, para ser usado em seus produtos. Algumas outras empresas, como a Sony, adotaram o sistema Palm OS em seu PDAs. Os computadores Palm, baratos e populares, dominam cerca de 70% do mercado nacional de PDAs. Atualmente ele est em sua verso 5.0. Alguns PDAs que utilizam o sistema Palm OS: Palm, HandSpring, Sony Cli.

Figura 1 - Palm m130

J o sistema Windows CE o sistema desenvolvido pela Microsoft para uso em PDAs. O Windows CE possui uma interface semelhante ao Windows para micros de mesa e roda verses reduzidas dos programas mais populares da Microsoft (Office, Internet Explorer, Media Player etc.). Atualmente ele est na sua verso 3.0 (a Microsoft j divulga em seu site informaes sobre a nova verso 4.2). PDAs com Windows CE so, em geral, mais poderosos e mais caros que os PDAs da Palm. Os processadores mais comuns para esse tipo de PDA so o SH3 da Hitachi, o MIPS e o StrongArm da DEC. Algumas verses do Windows CE so conhecidas como Pocket PC (em geral, rodam sobre o novo processador Strong Arm). Alguns PDAs que rodam Windows CE: iPaq da Compaq, Cassiopeia da Casio,

Pgina 9 de 42

Figura 2 - iPaq srie H3900 da Compaq

A maioria dos PDAs possui mdulos de expanso, permitindo a instalao de cartes de memria, modems, conexes de rede sem fio, etc. Alguns modelos mais novos possuem conexo wireless (BlueTooth) embutida. interessante notar que existem browsers para internet tanto para Palm OS quanto para Windows CE. Para efeito ilustrativo, seguem os dados tcnicos do PDA iPaq srie H3900 (adaptado do site da PalmLand, preo obtido no site da HP do Brasil):
Compaq iPAQ H3900 Processador

Intel Xscale PXA250 de 400 MHz padro StrongArm

Microsoft Windows Pocket PC 2002 calendrio, contatos e tarefas Microsoft Pocket Internet Explorer Microsoft Pocket Word (com spellchecker) Microsoft Pocket Excel MSM Menssenger Microsoft Reader Microsoft Windows Media Player 8 Terminal Services Client VPN Client File Explorer

calculadora, solitarie, Inbox (com spellchecker for email)

Software na ROM

Tela

Display TFT colorido (16 bits, 65.536 cores) - 5,74cm larg. e 7,67cm alt.

Pgina 10 de 42

Escrita

Caneta touch screen

H3950 com 64 MB de memria RAM e 32 MB de memria Flash ROM; H3970 com 64 MB de memria RAM e 48 MB de memria Flash ROM

Memria

Slots de expanso

Som

Drive de memrias MMC/SD Expanso para cartes CompactFlash via jaqueta opcional USB Porta serial ( RS2323C ) 115 kbps (Opcional) IrDA , 115 kbps ( Infra vermelho ) Entrada de fonte de alimentao MP3 , WMA estreos

Portas externas

Bateria de ltio-polmero Bateria de lithium Polymer, recarregvel, e com autonomia de at 12 horas

Bateria

Conectividade

USB com o PC (Base serial opcional) IR entre palmtops Modem opcional

O modelo H3970 possui recursos de Bluetooth integrado

Dimenses x Peso

133 x 84 x 16 mm x 190 g HP3950: R$ 2.400,00 HP3970: R$ 2.600,00

Preo:

4.3 Tablet PC
O tablet PC um computador porttil, semelhante a uma prancheta, dotado de uma tela de cristal lquido e uma caneta para entrada de dados. Os tablet PCs atuais possuem uma configurao semelhante a de um notebook, um pouco mais leve e, em geral acrescenta ao notebook os seguintes recursos: caneta ativa sensvel presso; reconhecimento de escrita; reconhecimento de voz; conexo WiFi embutida.

H dois tipos de Tablet PCs. O primeiro tipo, chamado de conversvel, possui um design muito semelhante ao de um notebook. Entretanto, quando aberto, permite que a tela seja rodada em 180o e fechada, tomando a forma de uma prancheta. O segundo tipo, menos comum, possui um teclado destacvel.

Pgina 11 de 42

Figura 3 - Acer TravelMate C100 - exemplo de tablet conversvel

Praticamente todos os Tablet PCs atualmente produzidos utilizam o sistema operacional Windows XP Tablet Edition. Trata-se do sistema operacional Windows XP acrescido de softwares para uso de caneta digital, reconhecimento de escrita, voz e outros recursos. Portanto, qualquer sistema desenvolvido para PCs de mesa roda sem problemas em um tablet PC.

Figura 4 - Compaq Tablet PC TC100

Como exemplo de configurao, podemos citar o micro Compaq Tablet PC TC1000. Ele possui um processador Transmeta Crusoe TM5800 de 1 GHz, sistema operacional Windows XP Tablet PC Edition, 256Mb a 768Mb de memria, 30Gb a 60Gb de disco rgido, tela TFT de 10,4 polegadas, bateria com autonomia para 4 horas de uso, transmissor e antena para redes sem fio padro 802.11b e portas USB 2.0. O preo no Brasil varia entre R$ 10.500 (256Mb, 30Gb) e R$ 13.000 (512Mb, 60Gb).

4.4 WiFi e Bluetooth

Para comunicao local sem fio, h duas tecnologias que se sobressaem, WiFi e Bluetooth. A tecnologia Bluetooth foi desenvolvida por um consrcio de empresas de comunicao em 1998. Ela usa sinais de rdio de curto alcance (de 10 a 30 metros) para conectar computadores de mesa ou portteis, PDAs, celulares e outros aparelhos eletrnicos.

Pgina 12 de 42

J o padro WiFi, conhecido tambm como 802.11, foi desenvolvido pela IEEE (Institute of Electrical and Electronics Engineers). Ele usa sinais de rdio de curto alcance para conexo entre computadores numa rede sem fio. H dois padres: 802.11a e 802.11b. O 802.11a opera a 54Mbps com alcance de 50 metros, enquanto que o padro 802.11b opera a 1 Mbps com um alcance de at 300 metros (100 metros em ambiente fechado). Os padres Bluetooth e Wifi tm objetivos diferentes. O Bluetooth serve, por exemplo, para sincronizar um PDA com um computador de mesa sem o uso de cabos. J o Wifi mais adequado para a montagem de uma rede sem fio, formada por computadores de mesa e computadores mveis.

4.5 XML
XML (eXtensible Markup Language) uma linguagem de markup, como HTML. O objetivo da linugagem XML de armazenar informaes. A seguir, apresentado um trecho de arquivo XML:
<bilhete> <remetente>Joo</remetente> <destinatrio>Cludia</destinatrio> <mensagem>Vamos nos encontrar para o almoo s 12:30.</mensagem> </bilhete>

Como se pode ver, um arquivo XML muito semelhante a um arquivo HTML. Entretanto, ele possui algumas diferenas bsicas como, por exemplo: XML no possui um conjunto de tags definidas pela linguagem. As tags so criadas de acordo com a aplicao. Todo documento XML possui uma tag raiz. No caso do exemplo anterior, a raiz a tag <bilhete>. Alm disso, no so permitidas tags mal formadas, isto , todas as tags devem ser fechadas e no deve haver violaes na hierarquia das tags.

Podem ser definidas gramticas XML para uma determinada aplicao. Por exemplo, suponhamos que um programa de mensagens troque mensagens XML semelhantes ao exemplo anterior. Podemos ento definir um tipo de mensagem padro que todas as mensagens devem seguir. Os dois padres mais usados para definir uma gramtica XML so o XML Schema e o DTD (Document Type Definition). Mensagens XML podem ser transformadas de uma gramtica para outra automaticamente. Para isso, existe a tecnologia XSL (eXtensible Style sheet Language). Um sistema XSL formado basicamente de um arquivo XML descrevendo a transformao a ser efetuada e um programa interpretador. A tecnologia XML tornou-se rapidamente um padro para troca de informaes via internet, devido sua simplicidade de uso e implementao. Atualmente existem bibliotecas para manipulao de XML disponvel para as principais linguagens de programao, alm de diversos produtos e ferramentas. No caso especfico de Java para XML, h dois tipos de bibliotecas bastante utilizadas: SAX e DOM. Um parser SAX uma classe Java que l um arquivo XML e executa comandos conforme as tags so encontradas. Para cada tipo de tag, h um cdigo associado. J um parser DOM l um arquivo XML e converte-o para uma rvore de objetos Java, que podem ser facilmente manipulados.
Pgina 13 de 42

4.6 J2ME
A plataforma Java definida pela Sun Microsystems atualmente dividida em quatro grandes grupos (veja a figura). J2SE (Java 2 Standard Edition) o grupo principal, destinado a computadores pessoais domsticos (end-user). J2EE (Java 2 Enterprise Edition) mais abrangente que a J2SE, sendo destinada a aplicaes do lado do servidor. J2ME (Java 2 Micro Edition) tem o objetivo de disponibilizar aplicativos Java em dispositivos portteis, como PDAs, pagers e celulares. Finalmente, JavaCard uma tecnologia destinada a rodar em smart-cards e outros dispositivos extremamente limitados.

Figura 5 - A plataforma Java (fonte: http://www.sun.com/developers/evangcentral/presentations/Toronto/BillDay_J2ME_XYZ.pdf)

A J2ME dividida em configuraes e perfis. So especificadas duas especificaes, CDC e CLDC. CDC (Connected Device Configuration) lida com dispositivos com mais memria e poder de processamento do que a CLCD. Ela feita para dispositivos com conexo de rede permanente e um mnimo de 2Mb de memria disponvel para as aplicaes Java (usualmente PDAs com maior poder de processamento). J a CLDC (Connected Limited Device Configuration) feita para dispositivos com menos de 512 kb de memria disponvel para aplicaes Java e uma conexo de rede limitada e no-permanente (PDAs com menor poder de processamento, pagers e celulares). Ela define uma mquina virtual Java reduzida, chamada de KVM, e um conjunto reduzido de APIs.

Pgina 14 de 42

Cada uma das configuraes citadas dividida em perfis, de acordo com o tipo de equipamento e aplicao desejados. Somente alguns perfis foram implementados at o momento. O MIDP (Mobile Information Device Profile) foi o primeiro perfil implementado e j est na sua verso 2.0. Ela roda sobre a configurao CLDC e especifica algumas APIs para interface, conexo de rede e armazenamento de dados. Outra especificao importante a Personal Profile, em fase final de desenvolvimento. Ela deve rodar sobre a configurao CDC, substituindo a antiga tecnologia Personal Java. Personal Java uma verso reduzida da J2SE, destinada a rodar em dispositivos de pouca memria e baixo poder de processamento. Atualmente, ela no recebe mais o suporte da Sun. importante observar que a CLDC est includa na CDC, isto , qualquer aplicao baseada na CLDC pode rodar sobre uma plataforma CDC sem nenhuma adaptao. Alguns dos recursos do MIDP so: Criao de conexes de vrios tipos: serial, sockets, HTTP, HTTP segura (somente na verso 2.0). Exibio de arquivos de imagens, vdeo e som (Media Profile) Gravao local de dados.

importante ressaltar que a MIDP no possui suporte a Bluetooth. Esse suporte feito, dentro do J2ME, atravs de um pacote opcional (Bluetooth API). A especificao desse pacote foi concluda. Entretanto, no foi encontrada nenhuma implementao da Bluetooth API para PC ou para algum PDA. Talvez a nica implementao dessa API existente at o momento a existente no Symbian 7.0.

4.6.1 Exemplo de aplicao MIDP

O desenvolvimento de uma aplicao MIDP semelhante a qualquer outra aplicao Java. Aps a criao de um cdigo fonte (arquivo .java), compila-se o cdigo, gerando um arquivo .class, que pode ser rodado sobre uma mquina virtual KVM. A Sun disponibiliza em seu site um toolkit simples para aplicaes MIDP, denominada J2ME Wireless Toolkit, compatvel com o MIDP 2.0. Esse toolkit pode ser usado sozinho (em conjunto com um editor de texto para a criao do cdigo-fonte) ou acoplado IDE Sun One Studio (conhecida como Forte for Java). H ainda outras IDEs disponveis, como o JBuilder Mobile Set (compatvel com MIDP 1.0) e o WebSphere da IBM. Os programas para MIDP so usualmente conhecidos como MIDlets. A seguir, apresentado o cdigo de um MIDlet HelloWorld (retirado do tutorial da Sun: http://wireless.java.sun.com/midp/articles/wtoolkit/)
import javax.microedition.lcdui.*; import javax.microedition.midlet.*; public class HelloMIDlet extends MIDlet implements CommandListener { private Form mMainForm; public HelloMIDlet() { mMainForm = new Form("HelloMIDlet");

Pgina 15 de 42

mMainForm.append(new StringItem(null, "Hello, MIDP!")); mMainForm.addCommand(new Command("Exit", Command.EXIT, 0)); mMainForm.setCommandListener(this); } public void startApp() { Display.getDisplay(this).setCurrent(mMainForm); } public void pauseApp() {} public void destroyApp(boolean unconditional) {} public void commandAction(Command c, Displayable s) { notifyDestroyed(); } }

Todos os midlets so derivados da classe MIDlet e implementam quatro mtodos, alm do construtor: startApp(), pauseApp() e destroyApp(). O mtodo startApp() executado no incio da execuo do programa. O mtodo pauseApp() chamado quando o programa entra em modo de pausa (os midlets podem ter trs estados possveis: modo de inicializao, modo de execuo e modo de pausa). O mtodo destroyApp() executado no final do programa. O construtor do programa cria um formulrio mMainForm. Os formulrios so as telas dos midlets. Depois, o construtor adiciona uma string ao formulrio. Podem ser adicionados vrios tipos de itens aos formulrios: strings, caixas de texto, listas de opes, choice groups, figuras (formato PNG), entre outros. Em especial, no possvel definir botes no MIDP. Ao final do construtor, adicionado um comando ao formulrio. Cada comando geralmente associado a um boto do dispositivo em questo (por exemplo, aos botes Yes e No de um celular). A execuo de um comando feita por um objeto CommandListener associado a ele. No caso, a prpria classe HelloMIDlet. O CommandListener deve implementar o mtodo commandAction(), que processa o comando. A figura a seguir mostra o midlet HelloMIDlet rodando no simulador do J2ME Wireless Toolkit:

Figura 6 - Tela do programa HelloMIDlet

4.6.2 Plataformas compatveis com MIDP

Alguns modelos de celulares modernos possuem suporte para MIDP 1.0, embora ainda no sejam muito comuns.

Pgina 16 de 42

A Sun disponibiliza gratuitamente uma mquina virtual MIDP (verso 1.0) para o Palm OS. Essa mquina virtual foi testada sobre um emulador de Palm OS rodando sobre Windows 2000. No foi constatado nenhum problema. O nico incoveniente foi o fato do MIDP no ser da ltima verso disponvel (verso 2.0). Por razes de estratgia de mercado, a Sun no produziu uma mquina virtual MIDP para o sistema Windows CE. Algumas empresas criaram mquinas virtuais prprias, mas no so softwares gratuitos (ex: J9 da IBM, Kada, MicroJBlend).

4.6.3 ME4SE
Como opo para rodar J2ME no Windows CE, pode-se usar o ME4SE sobre o Personal Java. Como foi citado anteriormente, Personal Java era uma antiga tecnologia para computadores pequenos, a ser substituda pelo Personal Profile do J2ME. A Sun produzia mquinas virtuais Personal Java para Windows CE, a ltima verso foi para Windows CE 2.1. Essa verso do Personal Java compatvel com PDAs com processadores MIPS e SH3 e ainda roda nas verses mais atuais do Windows CE. No existe uma verso para PDAs com processadores StrongArm (que utilizado nos PDAs mais modernos). Neste caso, pode-se usar a mquina virtual Jeode, compatvel com Personal Java, apesar de no ser um software gratuito. Os PDAs iPaq da Compaq (que usam processador StrongArm) j vm com o Jeode para ser instalado. O ME4SE uma biblioteca open-source que permite rodar programas MIDP sobre o Personal Java ou sobre o J2SE. O ME4SE foi testado em um PC com J2SE e funcionou sem problemas. Tambm foi testado sobre um emulador de Personal Java para PC. Para rodar um programa MIDP no ME4SE, deve-se incluir o arquivo me4se.zip e a biblioteca sixlegs png no classpath da mquina virtual java. Depois, deve-se usar a seguinte linha de comando: java org.me4se.MIDletRunner seuMIDlet A biblioteca ME4SE, somada com a biblioteca sixlegs png, ocupam 283 kB, o que um tamanho razovel para um dispositivo rodando Personal Java. O nico problema do ME4SE que a verso suportada do MIDP a 1.0.

4.6.4 Diferenas entre MIDP 1.0 e MIDP 2.0

Alguns recursos importantes foram implementados na nova verso do MIDP. Entre elas, vale destacar: Conexes seguras (HTTPS) e uso de certificados. Media API, que permite a reproduo de sons e vdeos.

Como se pode notar, seria muito adequado que o padro MIDP 2.0 pudesse ser adotado. Entretanto, praticamente ainda no existem devices com suporte para esse padro. Esperase que implementaes do MIDP 2.0 surjam nos prximos anos.

4.6.5 Bouncy Castle

Bouncy Castle uma biblioteca de criptografia para Java. Ela implementa os principais algoritmos de criptografia usados comercialmente. O Bouncy Castle open source (licena

Pgina 17 de 42

MIT). H tambm uma verso do Bouncy Castle que roda em MIDP 1.0 (verso lightweight). O Bouncy Castle apresenta o problema de ser muito grande (350 kB na verso lightweight) para um dispositivo MIDP. Uma opo reduzir o tamanho do MIDlet usando um ofuscador. At o momento, no pude testar o Bouncy Castle. Entretanto, ele fica como uma opo possvel para uma implementao de esquemas de segurana no MIDP 1.0.

4.6.6 Ofuscador
Os arquivos de classe Java contm muitas informaes sobre o cdigo fonte original. Um programa Java compilado pode ser facilmente descompilado, tornando o cdigo fonte acessvel a qualquer pessoa. O ofuscador um utilitrio cujo objetivo evitar o acesso ao cdigo fonte a partir do programa compilado. O ofuscador reescreve o cdigo de mquina do programa, tornando-o impossvel de ser descompilado. Um bom ofuscador produz um cdigo to eficiente quanto o cdigo original. O ofuscador tambm remove do cdigo todas as classes, interfaces, propriedades e mtodos no utilizados pelo programa. Isso reduz bastante o tamanho em bytes do programa. Por isso, os ofuscadores so muito utilizados para a produo de MIDlets, onde h severas restries quanto ao tamanho do cdigo. O ofuscador mais utilizado na atualidade o RetroGuard, da RetroLogic. O RetroGuard distribudo como open source (licena GNU). Para teste, foi compilado um programa MIDP (um parser XML) que utilizava a biblioteca kXML. O arquivo JAR original possua cerca de 40 kb. Usando o ofuscador, o programa passou a ter 36 kB, sem perdas aparentes de eficincia.

4.6.7 Parsers XML para MIDP

Um parser XML um algoritmo capaz de ler um arquivo XML e extrair dele as informaes necessrias para o funcionamento de um programa. Os parsers XML para Java so implementados como bibliotecas. Para MIDP, h dois parsers razoavelmente populares, o kXML e o NanoXML. Ambos possuem licena open source. O NanoXML um parser de um nico passo, isto , ele possui um mtodo que recebe uma String XML e retorna uma rvore de objetos contendo elementos XML. A raiz da rvore uma instncia da classe kXMLElement, e cada n da rvore outra instncia da mesma classe. J o kXML um parser incremental, isto , ele faz o parsing aos poucos. O formato de um programa que usa kXML algo como (adaptado de http://developer.java.sun.com/developer/J2METechTips/2001/tt0725.html#tip2):
import org.kxml.*; import org.kxml.parser.*;

...
try { Reader r = .....; XmlParser parser = new XmlParser( r );

Pgina 18 de 42

... boolean keepParsing = true; while( keepParsing ){ ParseEvent event = parser.read(); switch( event.getType() ){ case Xml.START_TAG: ..... // handle start of an XML tag break; case Xml.END_TAG: ..... // handle end of an XML tag break; case Xml.TEXT: ..... // handle text within a tag break; case Xml.END_DOCUMENT: ..... // end of document; keepParsing = false; break; } } } catch( java.io.IOException e ){ // handle exception.... }

4.6.8 Waba e SuperWaba

Waba uma linguagem baseada em Java desenvolvida para PDAs. Ela utiliza a sintaxe Java, mas possui bibliotecas e uma mquina virtual prpria. Como vantagem sobre a J2ME, ela possui mquinas virtuais tanto para Palm OS quanto para Windows CE, alm de ser open source. Entretanto, posui recursos relativamente limitados, quando comparado com a J2ME. A partir da criao do Waba, surgiram vrias iniciativas de desenvolvimento da linguagem. A mais conhecida e utilizada o SuperWaba. O SuperWaba, curiosamente criado por um brasileiro, possui bem mais recursos que o Waba original e tambm open source (licena LGPL). O SuperWaba visto por alguns como uma alternativa ao J2ME, com a vantagem da compatibilidade com o Windows CE. A mquina virtual SuperWaba foi testada em um emulador de Palm OS para Windows 2000. O SuperWaba rodou sobre a verso 3.5 do Palm OS, mas o emulador acusou uma chamada de sistema invlida. Quando foi testado com o Palm OS 5.0 (a ltima verso), o SuperWaba travou o emulador.

4.6.9 Impresses finais sobre o J2ME

O J2ME possui muitos recursos, alm de ser simples de ser usado. A presena de uma biblioteca grfica semelhante ao Swing, recursos como multimdia, suporte a XML e outros tornam o MIDP a plataforma ideal para o desenvolvimento de aplicaes para celular. Entretanto, ainda no se sabe se ele vai ser adotado como um padro de linguagem para dispositivos pequenos. O perfil MIDP praticamente o nico perfil J2ME implementado

Pgina 19 de 42

at agora (embora existam alguns outros perfis, como o Personal Profile, com a especificao completada pela Sun). Pode-se dizer, com algumas restries, que o J2ME to somente o MIDP. O MIDP foi implementado em alguns poucos (e caros) modelos de celulares. A usabilidade de um programa Java em um celular discutvel, j que a tela pequena e o teclado dos celulares atuais tornam a interface do celular muito pouco amigvel. No Japo, excepcionalmente, h vrios modelos de celular com suporte para MIDP (j que este foi o padro adotado para o i-Mode). H uma mquina virtual MIDP implementada para Palm OS. Entretanto, o desenvolvimento de aplicaes MIDP para Palm discutvel, j que a interface do MIDP foi desenvolvida para celulares, e utiliza muito pouco da capacidade do PDA. J para Windows CE, por motivos de estratgia de mercado, nem h suporte para MIDP. O Personal Java, padro considerado obsoleto pela Sun, ainda a nica opo de Java para Windows CE. O Personal Profile, que prometeu ser o seu sucessor, ainda est s no papel.

4.7 Java Servlets

No incio da Internet, todas as pginas eram compostas por arquivos HTML. Isso logo representou um problema, pois pginas desse tipo possuem uma capacidade limitada de interao com o usurio. Para resolver esse problema, surgiram os scripts CGI. Scripts CGI so programas que rodam no servidor e montam uma pgina dinamicamente. Isso permite, por exemplo, que o resultado de uma busca em um banco de dados seja mostrada numa pgina de internet. Java Servlets a tecnologia Java desenvolvida para substituir a programao CGI. Um servlet um programa Java rodando no servidor que monta uma pgina de Internet dinamicamente. As vantagens dos servlets sobre a programao CGI so: Servlets so mais eficientes que programas CGI. Um processo CGI iniciado no servidor toda vez que feita uma solicitao http. No caso de um servlet, a mquina virtual Java permanece rodando durante todo o tempo. Durante uma solicitao http, somente um novo thread Java criado, o que muito mais rpido do que iniciar um processo CGI. A linguagem Java bastante conhecida, tornando o aprendizado de Java Servlets fcil e rpido. Java Servlets possui uma ampla biblioteca de recursos, permitindo entre outras coisas, manipulao de cookies, sesses, cabealhos http de maneira simples. Praticamente todos os servidores para Internet possuem suporte a Java Servlets.

A seguir apresentado um exemplo de Java Servlet (adaptado de http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/):

import java.io.*; import javax.servlet.*; import javax.servlet.http.*;

Pgina 20 de 42

public class HelloWWW extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); PrintWriter out = response.getWriter(); out.println("<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 " + "Transitional//EN\">\n" + "<HTML>\n" + "<HEAD><TITLE>Hello WWW</TITLE></HEAD>\n" + "<BODY>\n" + "<H1>Hello WWW</H1>\n" + "</BODY></HTML>"); } }

4.8 Java Server Pages (JSP) e JavaBeans

Java Servlets resolvem o problema de criar pginas dinmicas. Entretanto, as pginas criadas por servlets so produzidas dentro do cdigo, atravs de uma srie de comandos do tipo println. Isso torna difcil a produo do layout da pgina. Usualmente, o layout de uma pgina de internet deve ser feito por diagramadores e artistas grficos, e no por programadores. Assim, seria mais adequado se houvesse um jeito de separar cdigo e interface. Para tentar solucionar esse problema, a Sun criou a tecnologia de Java Server Pages (JSP). Uma pgina JSP semelhante a uma pgina HTML, acrescida de algumas linhas de cdigo Java. O cdigo Java inserido dentro de tags especiais. As pginas JSP produzidas so instaladas no servidor como se fossem pginas HTML. Durante o primeiro acesso pgina, o servidor converte a pgina JSP em um servlet. Linhas de cdigo HTML so convertidas em comandos println, enquanto que linhas de cdigo Java so inseridas no cdigo do servlet. O servlet assim produzido ento utilizado para atender s requisies http. A seguir, apresentado um exemplo de pgina em JSP:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML> <HEAD> <TITLE>Contador JSP</TITLE> </HEAD> <BODY> <!- Declarao --> <%! int n = 0; %> <!- Scriplet --> <% n = n + 1; %> <!- Expresso --> Essa pgina foi acessada <%= n %> vezes. </BODY> </HTML>

O cdigo JSP permite o uso de vrios tipos diferentes de tags (como foi mostrado no exemplo acima). Alm disso, permitida a criao de bibliotecas de tags prprias. So as

Pgina 21 de 42

chamadas taglibs. A Sun padronizou uma taglib padro chamada STL (Standard TagLib). A implementao mais implortante dessa taglib a da Apache.

4.8.1 JavaBeans
Para fazer a separao entre interface e programa, complementando as pginas JSP, usada a tecnologia de JavaBeans. Um JavaBean nada mais do que uma classe Java que segue uma definio especial. Num JavaBean, existe o conceito de propriedade. Uma propriedade equivalente a uma varivel interna da classe. A propriedade pode ou no estar associada a uma varivel Toda propriedade deve possuir dois mtodos de acesso, set() e get(). O nome do mtodo composto pela palavra set (ou get) seguida do nome da propriedade. O mtodo set() deve possuir um nico parmetro (o novo valor do parmetro), e no deve retornar nenhum valor. O mtodo get() no recebe parmetros e retorna o valor da propriedade. A seguir, apresentado um exemplo de JavaBean.
package meu; public class MeuBean { protected int numVisitas; public MeuBean() { numVisitas = 0; } public int getNumVisitas() { return (++numVisitas); } public void setNumVisitas (int numVisitas) { this.numVisitas = numVisitas; } }

Um JavaBean pode ser referenciado em uma pgina JSP. Dessa forma, pode-se separar a interface do programa. A pgina JSP fica responsvel pela gerao da interface, enquanto que a funcionalidade do programa passada para o JavaBean. A pgina a seguir trabalha em conjunto com o JavaBean apresentado anteriormente:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML> <HEAD> <TITLE>Contador JSP</TITLE> </HEAD> <BODY> <h1>Contador JSP</h1> <jsp:useBean id="bean" class="meu.MeuBean" scope="session" /> Esta pgina foi acessada <jsp:getProperty name="bean" property="numVisitas" /> vez(es).<p> </BODY> </HTML>

Pgina 22 de 42

4.9 JavaServerFaces e Struts

4.9.1 Arquiteturas de sites
A tenologia JSP foi rapidamente adotada como um dos principais padres para criao de sites na Internet. Um primeiro padro de arquitetura de sites que surgiu foi o que hoje chamamos de Modelo 1. Nele, as requisies de pgina so recebidas por pginas JSP, que passam as informaes necessrias aos JavaBeans. Estes fazem o processamento necessrio e retornam o resultado para a pgina JSP, gerando a sada para o usurio. A figura a seguir mostra essa arquitetura.

Figura 7 - Modelo 1 (retirado de http://www.orbeon.com/oxf/doc/intro-mvc)

O Modelo 1, apesar de apropriado para pequenas aplicaes, mostrou-se bastante inadequado para aplicaes maiores. A adoo de tal modelo leva a uma grande quantidade de cdigo Java inserido dentro das pginas JSP. Esse cdigo necessrio para o processamento inicial dos dados enviados pelas requisies de pgina. Alm disso, as pginas JSP precisavam fazer todo o controle do fluxo do programa. Uma segunda arquitetura, chamada de Modelo 2, passou a ser adotada. Nela, Servlets recebem as requisies de pgina e fazem todo o processamento inicial, controlando o fluxo da aplicao Web. O processamento de informaes continua sendo feito por JavaBeans. Ao final do processamento, o Servlet passa o controle para uma pgina JSP, que monta a pgina HTML de sada. Essa arquitetura conhecida como MVC (Model View Controller).

Figura 8 - Modelo 2 (retirado de http://www.orbeon.com/oxf/doc/intro-mvc)

Pgina 23 de 42

4.9.2 JavaServer Faces

O JavaServer Faces (JSF) uma nova tecnologia da Sun que adota a idia do Modelo 2. Um site JSF possui pginas JSP e JavaBeans. Alm disso, acrescido de alguns recursos que (segundo a Sun) organizam e facilitam a construo e manuteno do site. Usualmente, uma pgina JSP convertida em um servlet (durante o primeiro acesso da pgina). Quando feita uma requisio HTPP, esta tratada pelo servlet correspondente. Em JSF, toda requisio HTTP tratada por um servlet especial, o FacesServlet. O FacesServlet faz o processamento inicial e s depois passa o controle ao servlet da pgina JSP. O objetivo disso deixar ao JSP somente a tarefa de gerar a interface e, ao FacesServlet e aos JavaBeans, todo o resto do processamento. Em pginas JSP, possvel a introduo de algum cdigo Java. A separao entre interface e cdigo no , portanto, bem definida. Com JSF, proibido o uso de cdigo Java nas pginas JSP, garantindo, dessa forma, a clara separao entre interface e cdigo. Normalmente, a associao entre uma pgina JSP e um JavaBean feita dentro da pgina JSP, atravs da tag <jsp:useBean>. O exemplo a seguir retirado do sample carDemo, includo no Java Web Services Developer Pack:
<jsp:useBean id="CurrentOptionServer" class="cardemo.CurrentOptionServer" scope="session" <jsp:setProperty name="CurrentOptionServer" property="carImage" value="current.gif"/> </jsp:useBean>

No JSF, essa associao pode ser feita em separado, no arquivo de configurao da aplicao (em XML). Veja o exemplo:
<managed-bean> <managed-bean-name> CurrentOptionServer </managed-bean-name> <managed-bean-class> cardemo.CurrentOptionServer </managed-bean-class> <managed-bean-scope> session </managed-bean-scope> <managed-property> <property-name>carImage</property-name> <value>current.gif</value> </managed-property> </managed-bean>

A associao entre pgina JSP e JavaBean no mais feita dentro da pgina JSP. Ela feita no arquivo de configurao da aplicao. No JSF, os formulrios so definidos utilizando-se tags JSP, e no atravs de cdigo HTML. O exemplo abaixo mostra uma pgina JSP assim escrita (retirado do Java Web Services Tutorial da Sun):
<HTML> <HEAD> <title>Hello</title> </HEAD> <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %> <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %> <body bgcolor="white"> <h:graphic_image id="wave_img" url="/wave.med.gif" /> <h2>Hi. My name is Duke.

Pgina 24 de 42

I'm thinking of a number from 0 to 10. Can you guess it?</h2> <f:use_faces> <h:form id="helloForm" formName="helloForm" > <h:graphic_image id="wave_img" url="/wave.med.gif" /> <h:input_number id="userNo" numberStyle="NUMBER" valueRef="UserNumberBean.userNumber"> <f:validate_longrange minimum="0" maximum="10" /> </h:input_number> <h:command_button id="submit" action="success" label="Submit" commandName="submit" /><p> <h:output_errors id="errors1" for="userNo"/> </h:form> </f:use_faces>

Cada item do formulrio pode ser associado a um JavaBean. No exemplo acima, a caixa de texto userNo associada propriedade UserNumberBean.userNumber. Assim, quando o usurio entra com um nmero nessa caixa de texto, o JavaBean associado automaticamente atualizado. A validao dos dados do formulrio tambm pode ser feita automaticamente. A tag <f:validate_longrange> especifica os limites do nmero a ser digitado na caixa userNo. Mensagens de erro produzidas por entradas invlidas so mostradas pela tag <f:output_errors>. Outro recurso importante a associao de command listeners aos itens de formulrio, de maneira semelhante aos elementos de uma janela Swing. Pode-se, por exemplo, associar um boto a um mtodo JavaBean que vai avaliar o sucesso ou fracasso de uma operao de login. As tags de formulrio (chamados de componentes no JSF) so transformadas em cdigo HTML durante a gerao da pgina. Essa transformao feita por um objeto RenderKit. O RenderKit para converso em HTML j vem pronto no JSF, na forma de uma taglib. Para produzir outros formatos de pgina (WML, por exemplo), preciso escrever um RenderKit prprio ou, ento, componentes prprios. Em pginas JSP (assim como em qualquer pgina HTML), os links so definidos dentro da pgina. No JSF, os links so definidos em um arquivo XML em separado. Cada link associado a um evento. Na ocorrncia de um certo evento, o link associado acionado. No exemplo mostrado, o boto do formulrio gera o evento sucess, o que vai ocasionar a mudana de pgina. Outra possibilidade associar um boto a uma propriedade JavaBean. O JavaBean vai fazer o processamento adequado e gerar um ou outro evento conforme o resultado. Dessa forma, pode-se criar vrios destinos para uma mesma pgina. Por exemplo, suponhamos que um usurio aperte um boto Ok aps digitar seu login e senha. Esse boto vai chamar um mtodo em um JavaBean, que vai avaliar o acesso do usurio. De acordo com o resultado, O JavaBean gera um evento sucess ou um evento error, selecionando a pgina destino.

4.9.3 Struts
Semelhante ao JavaServer Faces, o Struts tambm uma tecnologia que adota o Modelo 2. O Struts foi desenvolvido pelo projeto Apache (a mesma organizao que criou o servidor TomCat). O projeto Struts mais antigo que o JSF e possui uma verso estvel.

Pgina 25 de 42

De maneira semelhante ao JSF, o Struts utiliza pginas JSP e JavaBeans. Tambm possui um servlet (chamado de ActionServlet) que faz o controle do site. O servlet possui um arquivo de configurao XML, com funes muito semelhantes ao arquivo de configurao do JSF. Os eventos no Struts so chamados de actions e esto associadas a classes Action definidas pelo usurio. A grande diferena entre o Struts e o JavaServer Faces est na criao da interface. Tanto no Struts quanto no JSF, as interfaces so produzidas em pginas JSP, utilizando tags especiais (definidas atravs de taglibs). No JSF, associadas s tags, h classes do tipo RenderKit que fazem a converso da tag em HTML. No caso do Struts, essa converso feita dentro da prpria taglib. Dessa maneira, o JSF permite a converso de uma mesma pgina JSP em diferentes formatos, bastando trocar o RenderKit. J no Struts, isso no possvel. Cada taglib possui associado um tipo especfico de sada. O Struts possui uma taglib padro para gerao de pginas HTML. Alm disso, h taglibs (produzidas por grupos independentes) para gerao de pginas WAP e outros formatos XML.

4.9.4 Impresses sobre o JavaServer Faces e o Struts

Tanto o JavaServer Faces quanto o Struts apresentam uma arquitetura bastante interessante, trazendo prontas vrias estruturas que antes deviam ser implementadas. Em especial, a associao entre componentes da interface e JavaBeans e o sistema de navegao de pginas bem interessante. Pessoalmente, acredito que o Modelo 2 tem grandes chances de se tornar um padro para criao de sites dinmicos. Entretanto, o JSF, entretanto apresenta vrias restries para a sua utilizao imediata. O JavaServer Faces ainda est numa verso de teste (chamada pela Sun de Early Access 4). Por isso, ainda traz alguns bugs estranhos. Por exemplo, numa pgina com formulrio, ao se clicar num boto, era de se esperar que os dados digitados fossem carregados para seus respectivos JavaBeans. Entretanto, s vezes, isso no ocorre. Os dados digitados so trocados por dados digitados anteriormente (ou so apagados) e a mesma pgina recarregada. Veja o link http://forum.java.sun.com/thread.jsp? forum=427&thread=413255&message=1855192 - 1855192. Outro problema do JSF a ausncia de uma IDE (Integrated Development Enviroment), como JBuilder ou Netbeans. Por se tratar de uma verso de testes, a nica verso do JSF a disponibilizada pela prpria Sun. Por isso, um site JSF ainda deve ser feito sem a ajuda de ferramentas de desenvolvimento. Pginas JSF ficariam muito mais fceis de serem criadas se houvesse um editor grfico, como feito nas linguagens de programao visuais. Toda a configurao do sistema tambm deve ser feita manualmente, escrevendo o cdigo dos arquivos de configurao. Vale ainda ressaltar que a definio do JSF ainda est passando por grandes transformaes. Basta verificar as diferenas entre as verses Early Acces 3 e Early Acces 4. Muitas tarefas que antes deveriam ser codificadas em Java foram incorporadas ao ncleo do JSF, necessitando apenas de um trabalho extra de configurao. As mudanas foram to grandes a ponto de invalidar todos os tutoriais introdutrios da verso antiga. Por tudo isso, para projetos pequenos e de curto prazo (at seis meses ou um ano), ainda no vale a pena desenvolver um aplicativo em JSF. Entretanto, para projetos de durao
Pgina 26 de 42

maior, o uso de JSF pode ser bem interessante. A arquitetura JSF traz uma srie de vantagens sobre os mtodos atuais e espera-se que, em alguns anos, tenhamos uma verso mais madura e definitiva do produto. O Struts um projeto mais antigo que o JSF e est em sua segunda verso estvel. Alm disso, existem algumas ferramentas de desenvolvimento para o Struts, embora sejam escassas (patches para Netbeans e Eclipse). A grande desvantagem do Struts em relao ao JSF o seu fraco suporte gerao de pginas no HTML. H taglibs para o Struts que permitem a gerao de pginas HTML e WAP. H tambm algumas ferramentas para a gerao de pginas XML e uso de XSL. Entretanto, essas ferramentas ainda no esto totalmente maduras.

4.10 Web Services

Web Services um termo utilizado atualmente para designar um conjunto de protocolos e regras que, juntos, permitem a realizao de chamadas de procedimento remoto atravs da Internet. O principal elemento do Web Services o protocolo SOAP.

4.10.1

SOAP

SOAP (Simple Object Access Protocol) um protocolo para troca de informaes em um sistema distribudo. Cada mensagem SOAP formada por um texto XML e consiste em trs partes: um envelope descrevendo o que a mensagem contm e como process-la, um conjunto de regras para expressar tipos de dados definidos em uma aplicao e uma conveno para representar chamadas remotas de procedimento (e suas respostas). Mensagens SOAP so transmitidas via HTTP (requisies GET e POST). Graas sua simplicidade, SOAP (e Web Services, consequentemente) vem se tornando um padro popular de computao distribuda. Seu sucesso deve-se principalmente simplicidade de implementao, quando comparado a seus antecessores, como DCE e COBRA. J existe um grande nmero de plataformas de desenvolvimento compatveis com Web Services, destacando-se a plataforma Java, da Sun, e a .NET, da Microsoft. Essas plataformas tornam as operaes de comunicao transparentes ao desenvolvedor.

4.10.2

WSDL

WSDL (Web Services Description Language) basicamente um arquivo XML disponibilizado por um servidor de Web Services. Esse arquivo segue um padro para descrio dos servios disponveis pelo servidor e como acess-los. Entre outras informaes, pode-se saber qual o formato e contedo das mensagens, o endereo onde o servio est disponvel, e o protocolo de comunicao utilizado. Em geral, as ferramentas de desenvolvimento criam automaticamente os arquivos WSDL, restando pouco trabalho ao desenvolvedor quanto a este aspecto.

4.10.3

UDDI

O UDDI (Universal Description, Discovery and Integration) um protocolo que permite que Web Services disponveis na Internet sejam facilmente encontrados e utilizados. uma espcie de pginas amarelas. Toda vez que se deseja disponibilizar um Web Service pblico, pode-se cadastr-lo no UDDI. O UDDI basicamente formado de arquivos XML contendo uma descrio da empresa e do servio que ela disponibiliza. Evidentemente, o
Pgina 27 de 42

cadastro no UDDI no obrigatrio. Entretanto, quando se deseja tornar pblico um Web Service, o UDDI a melhor maneira de divulg-lo.

4.10.4

A arquitetura Java para Web Services

A Sun criou um conjunto de APIs Java para desenvolvimento de Web Services e aplicaes Web. Este conjunto conhecido como Java Web Services Development Pack (JWSDP). O JWSDP composto por APIs, por exemplo, para processamento de XML, criao de Web Services, manipulao de mensagens SOAP, criao de Servlets, pginas JSP e JavaServer Faces. Alm disso, traz integrado um servidor Tomcat. A principal API para criao de Web Services chamada de JAX-RPC (Java API for XML Remote Procedure Call). Ela permite, segundo a Sun, a construo de servidores e clientes de Web Services de maneira simples e rpida. Para construir um servidor de Web Services, preciso criar uma interface (estendendo a interface javax.xml.rpc.Remote) do servio. Cada uma das funes traduzida para um mtodo Java. A seguir, mostrado um exemplo retirado do Tutorial Web Services da Sun:
package helloservice; import java.rmi.Remote; import java.rmi.RemoteException; public interface HelloIF extends Remote { public String sayHello(String s) throws RemoteException; }

Depois, basta fazer uma implementao dessa interface numa classe Java:
package helloservice; public class HelloImpl implements HelloIF { public String message ="Hello"; public String sayHello(String s) { return message + s; } }

A compilao de um Web Service no feita atravs de um comando javac. So usados programas parte, chamados de wscompile e wsdeploy. Esses programas criam automaticamente uma srie de outras classes, contendo toda a implementao do sistema de baixo nvel (montagem do WSDL, criao de mensagens SOAP, comunicao etc.) do servio. Dessa forma, boa parte dos detalhes da implementao de um Web Services tornase transparente ao desenvolvedor. A implementao de um cliente pode ser feita de trs maneiras diferentes. H dois mtodos estticos e um mtodo dinmico. Nos mtodos estticos (static stub e dinamic proxy), os programas so compilados atravs do wscompile. Durante a compilao, o servio acessado para a obteno de suas caractersticas (seu WSDL). Essas caractersticas so usadas para a criao automtica das classes de baixo nvel. No mtodo dinmico (dii client), a compilao normal (no usado o wscompile e o servio no acessado). Os mtodos estticos so mais simples de serem implementados. Entretanto, qualquer mudana na interface do Web Service torna necessria a recompilao de todo o sistema. O mtodo

Pgina 28 de 42

dinmico no tem esse problema, mas ele mais difcil de ser implementado (a configurao do sistema de comunicao deve ser feita pelo desenvolvedor).

4.10.5

Tipos de dados usados em Web Service

A W3C (World Wide Web Consortium organizao que regulamenta os padres na Internet) especifica vrios tipos de dados que podem ser usados em mensagens SOAP. Basicamente, so os tipos de dados primitivos (nmeros inteiros, reais, strings etc.) e vetores de tipos primitivos. Num primeiro momento, esses tipos de dados so suficientes para o sistema MobMed, j que o objetivo aqui a visualizao de dados textuais. Entretanto, para outras etapas do projeto, pretende-se implantar a transmisso de imagens e vdeo. A W3C no especifica um padro para transmisso de dados no textuais (j que as mensagens SOAP seguem um padro XML). Surgiram ento algumas solues para tentar contornar esse problema. As solues mais usadas so as seguintes: Codificao de dados usando base-64: A base-64 um conjunto de 64 letras, nmeros e smbolos usados para codificar dados. Esse formato permite que dados no textuais sejam transmitidos via texto (na forma de uma string). Mensagem SOAP com anexos: A plataforma Java da Sun utiliza mensagens SOAP com arquivos anexados. Esses arquivos anexados seguem a mesma codificao usada para anexos em email (formato MIME). Formato DIME: A plataforma .Net da Microsoft lanou um formato de arquivo anexado chamado de DIME, muito semelhante ao formato MIME.

Pgina 29 de 42

5 Arquitetura MobMed
5.1 Viso geral da arquitetura
O sistema MobMed foi dividido em trs grandes partes. A primeira parte composta pelos clientes, os diversos dispositivos que vo acessar o sistema. A segunda parte so os aplicativos, composto, entre outros, por bancos de dados do Pronturio Eletrnico e sistemas de interfaceamento com equipamentos mdicos. A terceira parte, denominada Broker, integrar as duas partes citadas acima. Ela receber requisies feitas pelos diversos dispositivos, encaminhando-as para os aplicativos. Da mesma maneira, o broker receber os resultados dos aplicativos e converter os dados para um formato adequado para cada dispositivo. A figura a seguir mostra um esquema simplificado do sistema.

BD

aplicativo

aplicativo

Dispositivo externo

Broker

celular

PDA

Tablet PC

desktop

Figura 9 - Arquitetura do sistema MobMed

A minha parte do projeto consiste principalmente no projeto e implementao do broker, alm da definio e criao das interfaces com os dispositivos.

5.2 Arquitetura do Broker

A figura a seguir mostra um esboo da arquitetura do Broker.

Pgina 30 de 42

aplicativos
XML Identificao de dispositivos Sistema de comunicao

JavaBean

JavaBean

JavaBean

JavaBean

XML Sistema de VoiceXML voz

JSP ou Servlet

JSP (WML?)

JSP (HTML)

JSP (HTML) HTML

WML? J2ME/XML?

HTML

telefone

celular

PDA

PC tablet PC notebook

Figura 10 - Arquitetura do broker

O broker est sendo implementado usando-se Struts. O servlet do Struts, que no mostrado na figura, far o controle da navegao entre as pginas e a administrao dos JavaBeans. A interface com os dispositivos ser feita atravs de pginas JSP, podendo, em alguns casos, serem usados servlets. Sero usadas pginas HTML onde for possvel. Como no h grandes diferenas entre o acesso por um desktop, um tablet ou um notebook, esses dispositivos iro acessar o mesmo conjunto de pginas HTML. Eventualmente, podem ser feitos pequenos ajustes nas pginas (tipos de letra, presena ou no de figuras, layout etc.) de acordo com o dispositivo. Os PDAs tambm usaro pginas HTML como interface. Entretanto, como a tela e a capacidade de um PDA so bem inferiores s dos outros dispositivos, os PDAs acessaro um conjunto prprio de pginas HTML. Ainda no foi definida uma interface para celulares. Uma alternativa possvel o uso de pginas WAP. Pginas WAP (WML) so simples de fazer. Alm disso, grande parte dos celulares existentes no mercado possui um browser Wap. Entretanto, pginas WAP tm recursos bastante limitados. Outra alternativa a criao de um programa cliente em J2ME (seria uma espcie de browser). O programa cliente receberia pginas num cdigo XML prprio e se comunicaria com o broker via HTTP. Entretanto, h o trabalho extra de se criar o programa cliente J2ME. Alm dos dispositivos citados, faz parte do projeto MobMed o uso de um sistema de VoiceXML. Um sistema VoiceXML faz a converso de comandos de voz (recebidos por
Pgina 31 de 42

telefone) em dados XML. Alm disso, tambm converte dados XML em voz sintetizada. Dessa maneira, os dados do pronturio eletrnico podem ser acessados atravs de um telefone comum. Esta parte do projeto, entretanto, est sendo desenvolvida por outras pessoas. O processamento do broker ser feito dentro de diversos JavaBeans. Os JavaBeans recebero as requisies vindas dos dispositivos, encaminhando-as para o aplicativo adequado, atravs de um sistema de comunicao. Os JavaBeans tambm recebero as respostas dos aplicativos, disponibilizando os dados para as pginas JSP de resposta. H ainda um sistema de identificao de dispositivos e um sistema de comunicao com os aplicativos. Descreverei estas duas partes a seguir.

5.3 Sistema de identificao de dispositivos

O sistema de identificao de dispositivo tenta descobrir as caractersticas do dispositvo que est tentando acessar o MobMed e, a partir da, adequar as interfaces e as funcionalidades do sistema. Num primeiro momento, esse sistema foi desenvolvido para os dispositivos que acessam o sistema via pginas HTML. O sistema armazena uma lista de dispositivos cadastrados, com as respectivas caractersticas. Essa lista armazenada em um arquivo XML e carregada no DeviceListBean. Dados sobre o dispositivo sendo usado na sesso so armazenados no DeviceBean. As caractersticas armazenadas so, por enquanto, nome do dispositivo, dados sobre a tela do usurio (resoluo e nmero de cores), se o dispositivo tem suporte a javascript, e qual a pgina inicial a ser acessada. Cada dispositivo acessa uma pgina inicial diferente. A idia inicial de ter uma pgina para PDAs e outra pgina para telas maiores (desktop, notebook, tablet etc.), j que uma pgina de PDA muito diferente das demais. Essas pginas poderiam sofrer pequenas variaes (tipos de letra, figuras) para adaptar-se ao dispositivo. Esse sistema de pequenas adaptaes, entretanto, ainda no foi totalmente implementado. Quando o usurio entra no sistema, ele acessa uma pgina "index.jsp". Esta faz o redirecionamento para o Action IDDeviceAction. Alm disso, a pgina index.jsp tenta coletar, usando javascript, algumas informaes sobre a tela do dispositivo. O IDDeviceAction vai receber e armazenar as informaes coletadas pelo javascript. Alm disso, ele vai procurar um cookie enviado pelo dispositivo. Esse cookie foi criado num acesso anterior, caso o dispositivo tenha sido devidamente identificado anteriormente. No IDDeviceAction, pode ocorrer um dos quatro casos: O cookie encontrado e o javascript funciona. Neste caso, o dispositivo registrado no cookie comparado com as caractersticas obtidas pelo javascript. Se as caractersticas estiverem corretas, o dispositivo aceito e o usurio redirecionado para a pgina inicial do dispositivo. Caso contrrio, ser apresentada uma tela informando sobre o novo dispositivo detectado e pedindo a confirmao do usurio. O usurio pode aceitar o dispositivo identificado, selecionar outro dispositivo j registrado ou registrar um novo tipo de dispositivo.

Pgina 32 de 42

O cookie encontrado e o javascript no funciona. Neste caso, o dispositivo registrado no cookie aceito e o usurio redirecionado para a pgina inicial do dispositivo. O cookie no encontrado e o javascript funciona. Neste caso, as caractersticas obtidas pelo javascript so usadas para tentar encontrar, na lista de dispositivos cadastrados, um dispositivo compatvel. Se for encontrado tal dispositivo, apresentada uma tela informando sobre o dispositivo detectado e pedindo a confirmao do usurio. O usurio pode aceitar o dispositivo identificado, selecionar outro dispositivo j registrado ou registrar um novo tipo de dispositivo. O cookie no encontrado e o javascript no funciona. Neste caso, uma mensagem de erro ser exibida. O usurio poder selecionar manualmente um dos dispositivos registrados ou registrar um novo tipo de dispositivo.

A partir do IDDeviceAction, h, portanto, trs destinos possveis, conforme foi citado anteriormente: O dispositivo foi devidamente identificado pelo cookie. Nesse caso, feito o redirecionamento para o action DeviceConfirmadoAction. Este action grava o cookie no browser do dispositivo e faz o redirecionamento para a pgina inicial do dispositivo. No foi identificado nenhum dispositivo. Nesse caso, feito o redirecionamento para a pgina deviceNaoEncontrado.jsp. Essa pgina permite que o usurio utilize um dos tipos de device j cadastrados ou que o usurio cadastre um novo tipo de device. Se o usurio utilizar um tipo j cadastrado, feito o redirecionamento para o action DeviceConfirmadoAction. Caso contrrio, feito o redirecionamento para a pgina novoDevice.jsp. Essa ltima permite o cadastro de um novo tipo de device. Um dispositivo foi automaticamente identificado pelo javascript. Nesse caso, feito o redirecionamento para a pgina confirmaDevice.jsp. Essa pgina mostra ao usurio qual o dispositivo identificado pelo javascript e pede uma confirmao do usurio. Se for feita a confirmao, feito o redirecionamento para o action DeviceConfirmadoAction. Caso contrrio, feito o redirecionamento para a pgina de dispositivo no identificado (deviceNaoEncontrado.jsp).

A figura a seguir mostra um esquema do funcionamento do sistema.

Pgina 33 de 42

confirmaDevi ce.jsp
Um dispositivo foi identificado por JavaScript. Pede confirmao do usurio.

Index.jsp
Identifica caractersticas do dispositivo usando JavaScript.

IDDeviceAct ion
Tenta identificar o dispositivo atravs das informaes JavaScript e do cookie.

DeviceCon firmadoAct ion

Envia o cookie e redireciona para a pgina inicial.

Pgina inicial do dispositivo

deviceNaoEn contrado.jsp
Usurio escolhe um dos dispositivos cadastrados ou cadastra um novo dispositivo.

novoDe vice.jsp
Cadastra um novo dispositivo

Figura 11 - Sistema de identificao do dispositivo

O programa javascript usa, por enquanto, as seguintes caractersticas para identificar o dispositivo: resoluo da tela; nmero de cores; se o dispositivo possui suporte a javascript.

Alguns problemas podem ocorrer com o uso dessas caractersticas. Se o usurio mudar a resoluo da tela, o dispositivo no ser automaticamente identificado no seu prximo acesso. Isso em geral, no constitui um problema grave, j que dificilmente mudada a resoluo do computador. No caso do Tablet, entretanto, isso pode ocorrer. O Tablet possui duas posies de trabalho: tela deitada e em p. Em cada uma das posies, ele usa uma resoluo de trabalho diferente. Mesmo assim, acredito que esse fato no v prejudicar em muito a usabilidade do sistema. Como todo dispositivo diferente deve ter um cadastro diferente, pode acontecer da lista de dispositivos ficar muito grande, o que dificultaria o uso do sistema. Entretanto, testes adicionais devem ser feitos para que se possa chegar a alguma concluso. Outro fato que deve ser notado quanto segurana no sistema. Nesta primeira verso, no houve ainda nenhuma preocupao com a segurana. O arquivo XML com a lista dos dispositivos no pode ser acessado de fora do servidor (ele est na pasta WEB-INF do

Pgina 34 de 42

aplicativo). Entretanto, da maneira como o sistema foi criado, qualquer pessoa pode cadastrar um dispositivo, o que pode no ser a melhor soluo. Em verses posteriores, esta lista pode ser transferida para um aplicativo fora do broker, aumentando a segurana e simplificando o cdigo do broker.

5.4 Sistema de comunicao

O sistema de comunicao faz a interface entre os diversos JavaBeans do broker e os diversos aplicativos existentes. Foi decidido que seria usado um nico tipo de protocolo entre o broker e os diversos aplicativos. Inicialmente, o protocolo de comunicao escolhido foi o Web Service, por ser mais simples e de fcil implementao, alm de usar um protocolo simples (mensagens SOAP) e de grande aceitao no mercado. A API de Web Services para Java chama-se JAX-RPC. Inicialmente, foi feito um prottipo de um sistema cliente-servidor de Web Service em Java. Esse prottipo usava clientes dii dinmicos (ver A arquitetura Java para Web Services). Entretanto, durante os testes, foram constatados problemas na converso de tipos em Java. A documentao do JAX-RPC especifica que podem ser usados, nas chamadas remotas, dados de tipo primitivo (inteiros, nmeros reais, strings etc.), vetores, JavaBeans e mais algumas classes Java especiais (Hashtable, ArrayList etc.). Esses dados so automaticamente convertidos em XML pelo JAX-RPC. Entretanto, o que foi constatado durante esse teste que, para que essa converso pudesse ser feita de maneira adequada, era preciso usar clientes estticos, o que no era desejado. A definio dos tipos vlidos parece ser no recursiva, isto , a API funciona bem para vetores de tipos primitivos e JavaBeans de tipos primitivos, mas no funciona para vetores de JavaBeans ou JavaBeans com vetores. Dessa maneira, foi introduzida uma camada de software extra que faz a converso de dados. Quando um cliente faz uma chamada, uma classe chamada WSClient faz a converso dos parmetros de entrada (lista de Object) em uma string XML. Essa string passada para o servidor usando uma chamada Web Service normal (a classe responsvel pela chamada Web Service chama-se WSCall). No servidor, a chamada recebida pela classe WSService, que converte a string XML de volta aos parmetros de entrada (lista de Object). Depois a chamada redirecionada para o servio desejado. Da mesma forma, o sistema tambm faz a converso dos valores de retorno da chamada. A figura a seguir ilustra o caminho da chamada remota.

Pgina 35 de 42

Servio (mtodo)
Lista de Object

Servidor

WSService
Mensagem SOAP (contendo string XML)

WSCall
String XML

WSClient
Lista de Object

Cliente

Cliente
Figura 12 - Sistema de comunicao

O sistema de comunicao foi implementado de maneira que sua utilizao seja simples para o programador. No lado do cliente, basta criar uma instncia da class WSClient e invocar o mtodo call(), passando como parmetros a URL onde o servio est disponvel, o nome do servio e uma lista Object de parmetros do servio. No lado do servidor, basta seguir o mesmo mtodo usado na construo de um servio JAX-RPC comum. Entretanto, deve-se estender a classe de interface e a classe de implementao das classes WSServiceInterface e WSService, respectivamente. Automaticamente, criado um mtodo remoto receive() que faz a converso das strings XML em listas de Object. A existncia desse mtodo relativamente transparente ao programador. Alm disso, os mtodos remotos criados pelo programador tambm ficam disponveis como servios Web Services comuns. O sistema suporta os seguintes tipos de dados: tipos primitivos, vetores e JavaBeans. Para que o cliente possa receber como resultado da chamada um JavaBean, preciso especificar de antemo qual o tipo de dado a ser retornado. Se o usurio no souber o tipo de retorno, a converso automtica de tipo pode no ser possvel. Nesse caso, o usurio ainda pode ter acesso string XML retornada pela chamada remota.

5.5 Prximos passos para o projeto

Pretendo continuar trabalhando no projeto MobMed, agora como aluno de mestrado. Acredito que a arquitetura aqui apresentada ainda no est madura e precisa de
Pgina 36 de 42

modificaes. H ainda muitos problemas pendentes, alguns deles so apresentados a seguir: O Struts, ferramenta utilizada na construo do projeto, permite a criao de pginas HTML e WAP. Aparentemente, h meios de produzir outros formatos de pginas, usando-se transformaes XSL em conjunto com o Struts. Entretanto, isso ainda no est bem definido no projeto. Falta definir uma soluo de interface com o celular (WAP ou J2ME?). O sistema est sendo desenvolvido para aplicaes on-line. Entretanto, essa pode no ser a melhor soluo, especialmente para PDAs e celulares. Talvez, em verses mais maduras, seja necessrio o desenvolvimento de uma soluo off-line, com sincronizao de dados. A necessidade de tal sistema ser avaliada futuramente, aps a implementao de um primeiro prottipo. No houve nenhuma preocupao com segurana nessa primeira verso do MobMed. Entretanto, num sistema que lida com informaes mdicas, esse um fator crucial. Solues mais seguras devero ser desenvolvidas em verses posteriores.

Pgina 37 de 42

6 Relacionando a experincia obtida no trabalho com o BCC

6.1 Desafios e frustraes encontrados
O trabalho que venho desenvolvendo no InCor tem sido bastante gratificante para mim. Durante o desenvolvimento do trabalho, tive a oportunidade de entrar em contato com vrias tecnologias utilizadas em aplicaes reais. O carter inovador do projeto tambm altamente estimulante e desafiador. Uma frustrao encontrada no projeto foi no ter conseguido avanar mais na implementao. Gastei muito tempo estudando as tecnologias apresentadas ao longo deste relatrio. Isso foi necessrio para que eu atingisse o nvel de conhecimento tcnico necessrio para o desenvolvimento do projeto. Entretanto, muito pouco foi desenvolvido e implementado at o momento. Outro problema que vejo neste projeto a distncia entre os desenvolvedores de sistemas e os usurios finais (mdicos, enfermeiros etc.). Isso dificulta a definio do projeto. Acredito, entretanto, que essa distncia ir diminuir no meu trabalho medida que surjam prottipos para teste.

6.2 Disciplinas cursadas no BCC mais relevantes para o projeto

No meu caso, acredito que as disciplinas mais importantes foram as disciplinas bsicas de programao, como MAC122 Introduo ao desenvolvimento de algoritmos, Laboratrio de Programao I e II, Estrutura de Dados etc. Embora no tenha usado de maneira formal nenhuma metodologia de projeto, considero a disciplina de Engenharia de Software muito importante. Possivelmente, com o avano do projeto, podem se tornar importante a disciplina de Banco de Dados. Uma fonte de frustrao foi o fato de no ter cursado nenhuma disciplina de Orientao a Objetos, j que o uso de linguagens orientadas a objetos um padro na computao atual. Alm disso, acredito que a disciplina de Programao Extrema poderia acrescentar bastante conhecimento sobre desenvolvimento de software.

6.3 Interao com membros da equipe que tenham agido como mentores do trabalho
Durante o meu projeto, estive sob a orientao do Dr. Srgio S. Furuie, diretor da Unidade de Pesquisa e Desenvolvimento do Servio de Informtica do InCor. Tambm trabalhei junto ao aluno de mestrado Luiz Kobayashi, da Escola Politcnica. Ambos mantiveram-se sempre disponveis para tirar dvidas e discutir os assuntos do projeto.

6.4 Diferenas notadas entre a forma de cooperao com colegas do BCC nas tarefas em grupo das disciplinas e a forma de trabalho conjunto na empresa
interessante notar que o trabalho no departamento onde atuei , de certa forma, bastante individual. Cada pessoa trabalha de maneira mais ou menos independente em um projeto.

Pgina 38 de 42

Quando h projetos que envolvem diversas pessoas, a comunicao entre os membros da equipe feita atravs de reunies ocasionais ou conversas entre os membros da equipe. Entretanto, cada membro da equipe trabalha de maneira mais ou menos independente em uma parte do projeto. No BCC, havia basicamente trs tipos de trabalho: individuais, em dupla ou em grupos de quatro ou cinco pessoas. Nos trabalhos individuais, cada aluno trabalhava de maneira independente, obviamente. Nos trabalhos em dupla, era comum a prtica de programao pareada, pouco comum nas empresas. Em alguns trabalhos em grupo, cada aluno produzia uma parte do projeto; em outros trabalhos, o projeto era desenvolvido pelo grupo como um todo, em reunies.

6.5 Observaes sobre a aplicao de conceitos estudados nos cursos no contexto prtico de aplicaes reais
Durante o desenvolvimento do meu projeto, os conceitos mais utilizados foram aqueles relacionados a programao e desenvolvimento de software. Outros conceitos estudados no foram diretamente utilizados, embora os considere bastante importantes para a minha formao geral. Vale notar que o BCC tem como objetivo dar uma formao terica sobre computao, enquanto que o meu projeto tem carter prtico. Ele seria mais um trabalho de Engenharia do que de Cincia da Computao. No caso, considero a definio de Cincia da Computao como o estudo e desenvolvimento das reas de conhecimento relacionadas Computao e, para Engenharia, como a aplicao desse conhecimento em aplicaes prticas.

6.6 Se o aluno fosse continuar atuando na rea em que exerceu o estgio, que passos tomaria para aprimorar os conhecimentos tcnicos/metodolgicos/comerciais/cientficos/etc relevantes para esta atividade?
Pretendo continuar desenvolvendo o meu projeto no InCor, agora como aluno de mestrado. Acredito que seria importante uma melhor definio da metodologia de desenvolvimento do trabalho. A aplicao de algumas tcnicas de desenvolvimento de software, como testes automatizados e uma definio mais cuidadosa de requisitos, arquitetura do sistema etc., poderia auxiliar no andamento do projeto. Entretanto, no acredito na aplicao direta de um mtodo terico de trabalho, como mtodo de cascata ou mtodo de espiral. O desenvolvimento de um projeto envolve muitos fatores no previstos na teoria de engenharia de software. Tambm considero importante um melhor conhecimento e envolvimento com outras atividades desenvolvidas no departamento. Acredito que isso v ocorrer aos poucos, com o tempo.

Pgina 39 de 42

7 Fontes
A principal fonte de informao deste trabalho foi a internet. A seguir, apresentada uma lista de sites utilizados como fonte de informao:

7.1 Computao mvel aplicada a medicina

Dodero, G; Gianuzzi ,V; Coscia, E; Virtuoso S. Wireless networking with a PDA: the Ward-In-Hand. Itlia, novembro de 2001. (pgina da internet: http://www.disi.unige.it/person/DoderoG/wih/nettab.pdf) Arshad, U; Mascolo, C; Mellor, M. Exploiting Mobile Computing in Health-care. Londres, Reino Unido. (pgina na internet: http://www.cs.ucl.ac.uk/staff/c.mascolo/www/iwsawc.pdf) Projeto Ward-In-Hand: http://www.wardinhand.org/ Textos da Sun: http://www.sun.com/mobility/enterprise/feature_story.html

7.2 Celulares
operadora Vivo: www.vivo.com.br operadora Tim: www.timbrasil.com.br WirelessBR (artigos diversos sobre tecnologias de comunicao sem fio): http://wirelessbr.sites.uol.com.br/index.html I-mode: http://www.nttdocomo.com/ Symbian: www.symbian.com Descrio da ltima verso do Symbian (7.0): http://www.symbian.com/technology/symbos-v7s-det.html Brew: http://www.qualcomm.com/brew Texto sobre monitoramento de pacientes em UTI usando WAP: http://helyr.sites.uol.com.br/monitor_uti/monitor_uti.html

7.3 PDAs
Palm Computing: http://www.palm.com Microsoft Windows CE 4.2 .NET: http://www.microsoft.com/windows/embedded/ce.net/ Compaq do Brasil: http://www.compaq.com.br Emulador de Palm OS: http://www.palmos.com/dev/tools/

7.4 Tablet PC
Microsoft Windows XP Tablet Edition: http://www.microsoft.com/windowsxp/tabletpc/

Pgina 40 de 42

IDGNow: http://idgnow.terra.com.br/idgnow/pcnews/2003/01/0071 um texto de Dan Bricklin, criador do VisiCalc, sobre suas impresses sobre o tablet PC: http://danbricklin.com/log/tabletpc.htm Acer: http://global.acer.com/products/tablet_pc/tmc110.htm Compaq: http://h18000.www1.hp.com/products/tabletpc/tc1000.html

7.5 J2ME
site oficial Java: http://java.sun.com/j2me tutorial MIDP da Sun: http://wireless.java.sun.com/midp/articles/wtoolkit/ Diferenas entre MIDP 1.0 e MIDP 2.0: http://wireless.java.sun.com/midp/articles/midp20/ Especificao da Bluetooth API: http://www.jcp.org/en/jsr/detail?id=82 Bill Days J2ME Archives (contm diversos programas MIDP, textos e links sobre o assunto): http://billday.com/j2me/ ME4SE: http://me4se.org Plataformas disponveis para MIDP: http://www.javamobiles.com/jvm.html Artigos sobre segurana em MIDP: http://wireless.java.sun.com/midp/articles/security4 Bouncy Castle (pacote de criptografia para J2ME): http://www.bouncycastle.org/ RetroGuard (ofuscador Java): http://www.retrologic.com/retroguard-main.html kXML (parser XML para J2ME): http://kxml.enhydra.org/ (at verso 1.21) e http://www.kxml.org (kXML 2). NanoXML (parser XML para J2ME): http://web.wanadoo.be/cyberelf/nanoxml/ kNanoXML (parser NanoXML para J2ME): http://www.ericgiguere.com/nanoxml/ site oficial Waba: http://www.wabasoft.com site oficial SuperWaba: http://www.superwaba.com.br/

7.6 Java (Servlets, JSP, JSF, Struts e Web Services)

Tutorial Java Web Services da Sun (aborda XML, Servlets, JSP, JSF e Web Services): http://java.sun.com/webservices/downloads/webservicestutorial.html Tutorial sobre Servlets e JSP (por Marty Hall): http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/index.html Referncia JSTL (extrado do livro JSTL in Action, de Shawn Bayern): http://www.manning.com/bayern/appendixA.pdf

Pgina 41 de 42

Tutorial JavaServer Faces (contm um preview do futuro livro Core JavaServer Faces, por David Geary e Cay S. Horstmann): http://horstmann.com/corejsf/ Site oficial do Struts: http://jakarta.apache.org/struts

7.7 Outros
licenas open source: http://www.opensource.org Tutoriais diversos: http://www.w3schools.org

Pgina 42 de 42