Uma aplicação completa passo-a-passo integrando Android + Java EE + Java SE

Transcrição

1 : : : : Mais uma vez provamos que o slogan mais famoso do Java é verdadeiro: Java is Everywhere. Neste artigo apresentamos, de forma didática, uma aplicação completa passando por edições como Java EE e Java SE. Para o módulo móbile, escolhemos Android. Para integração entre os módulos, escolhemos utilizar webservice RESTful e este por sua vez acessa o EJB central, que contém as operações e regras de negócio da empresa. Além de um módulo central e um móbile, a aplicação é composta de mais dois módulos web e desktop. Este artigo mostrará como essas tecnologias são utilizadas em conjunto para a criação de uma única aplicação. Java de ponta (6aanos ponta depois) Uma aplicação completa passo-a-passo integrando Android + Java EE + Java SE Cristine Tellier (criscat.br@gmail.com): SCJP e SCWCD, trabalha há oito anos com desenvolvimento de projetos Java SE e Java EE para o mercado financeiro. Atualmente, é engenheira de Soluções na BV Sistemas, empresa de tecnologia da holding Votorantim Finanças. Odair Bonin (odair.bonin@gmail.com): É formado em Ciência da Computação e trabalha com Java há 9 anos. SCJP, participou de grandes projetos em fábricas de softwares e projetos para mobilidade. Atualmente é analista de engenharia de software da BV Sistemas, empresa de tecnologia da holding Votorantim Finanças. 8 m meados de 2005, a edição número 12 da revista MundoJ nos trouxe artigos mais do que especiais. Sob o título de capa Java de Ponta a Ponta, a edição conta com artigos sobre as novidades do Java, novidades da modelagem ágil entre outros temas. A própria edição traz um artigo sobre o 10º aniversário do Java, e uma linha do tempo desde o início até meados de 2005 foi traçada e comentada sobre as novidades que aconteciam com Java. Revisão do esboço inicial da plataforma J2EE 5.0 e Disponibilização do Netbeans 4.1 estavam entre as novidades. A versão Java 5.0 (Tiger) tinha 6 meses de vida. Porém, a matéria principal de capa mostrava o desenvolvimento de um sistema que usava em conjunto as plataformas J2ME, J2EE e J2SE. Para mostrar a integração entre as plataformas, foi desenvolvido o sistema Pizza Delivery, que permite ao cliente fazer um pedido de pizza pela internet através de um módulo web. Este módulo web, desenvolvido em JSP sem frameworks adicionais, acessa um módulo central para obter o cardápio disponível. O módulo central

2 concentra todas as regras de negócio e operações disponíveis do sistema, e foi desenvolvido utilizando EJB 2.1 e Entity Beans CMP para a camada de persistência. O container J2EE escolhido foi o JBoss Após fechar o pedido de uma pizza, ele é direcionado a um entregador através do módulo gerenciador, um módulo desktop desenvolvido em Swing. O entregador também possui acesso ao sistema através de um módulo instalado em seu celular. Desenvolvido com J2ME, este permite ao entregador visualizar informações dos pedidos como o endereço do cliente, e também marcar que a entrega foi efetuada. Desta forma, um possível relatório de entregas com informações detalhadas poderia ser extraído. O objetivo deste artigo é explicar passo-a-passo o desenvolvimento de um sistema completo incluindo módulos das plataformas Java EE, Java SE e Android. Demonstraremos de forma didática a integração entre as plataformas, combinando recursos atuais das versões do Java e comparando ao artigo escrito em Para os desenvolvedores iniciantes, o artigo permitirá uma visão ampla do que atualmente é tido como referência nas plataformas abordadas. Veremos como podemos realizar esta integração. Evolução do Java de 2005 até 2011 Em 2005, a Sun Microsystems, até então detentora da plataforma Java, investia pesado em todas as suas edições (J2SE, J2ME e J2EE). O lançamento da versão J2SE 5.0 (Tiger) acabava de ocorrer, e quase que ao mesmo tempo a versão 6.0 (Mustang) era disponibilizada para o desenvolvimento colaborativo no site java. net. O esboço inicial do J2EE 5.0 estava sendo revisado, enquanto que a IDE Netbeans lançava a sua versão 4.1. A edição J2ME estava em destaque, sendo adotado por diversos segmentos da indústria como empresas de monitores cardíacos, monitoramento de poços de petróleo e gás, e se entendia à segurança nacional americana, com o seu sofisticado sistema de monitoração e alerta de emergência contra ataques químicos e biológicos de alto risco. A TV digital estava sendo idealizada como sendo uma central multimídia, pelo consórcio DVB (Digital Video Broadcasting) que em conjunto com a Sun Microsystems estava especificando a plataforma MHP (Multimedia Home Platform), uma plataforma baseada na tecnologia Java que seria implementada em receptores de TV Digital. Passados 6 anos, muita coisa mudou, mas sem perder a essência. A mais significante mudança foi a passagem do Java para as mãos da Oracle, que em meados de 2009 comprou a Sun Microsystems por US$ 7,9 bilhões, realizando uma transação de grande impacto no mercado. Naquele momento, surgiram muitas perguntas a serem respondidas, como: Java deixará de ser uma plataforma livre? Oracle não investirá em Java na mesma proporção que a Sun, deixando de realizar o JavaOne? Enfim, todas elas foram e ainda estão sendo respondidas ao longo do tempo. Hoje, a Oracle estampa em seu site sua visão sobre o Java, dita por Steven Harris, vice-presidente Senior Oracle: Java is critical for our success, sendo comprovada por seu grande investimento na plataforma. Uma das novidades da Oracle foi a primeira realização no Brasil do maior evento Java mundial, o JavaOne, em dezembro de Mas nem toda a mudança feita pela Oracle foi bem-vinda pela comunidade Java. Em relação às certificações, por exemplo, a Oracle aplicou as mesmas regras que exigem em suas certificações em banco de dados: a de exigir um curso como pré-requisito na certificação SCJD e SCEA. A partir de agosto de 2011, para estas duas certificações, pelo menos um curso é obrigatório. Seguindo a estratégia que já vinha sendo feita pela Sun, a Oracle avançou nas edições do Java, porém com foco maior no mundo corporativo. As próximas seções falam brevemente sobre esses avanços para cada uma das plataformas. Java SE A Standard Edition é uma edição que está sempre recebendo atualizações por ser o core da plataforma Java. Como estratégia de marca, foi removido o 2 do nome da edição, se tornando apenas Java SE. Recentemente a versão Java SE 7 Developer Preview foi lançada para a comunidade de desenvolvedores para que estes testassem a versão. A versão 7 tem data de lançamento prevista para o dia 28/07/2011. A lista de features desta versão está disponível no site openjdk.java.net/projects/jdk7/features/ mas podemos destacar melhorias na linguagem Java (JSR334: Project Coin), suporte a linguagens tipadas dinamicamente, com melhoria nos níveis de performance próximas à própria linguagem Java (JSR 292), JDBC 4.1, e suporte total ao Windows Vista. Para o Java SE 8, já estão sendo aprovadas JSRs, como, por exemplo, o Projeto Lambda (JSR 335), que permitirá ao Java suportar expressões Lambda (closures). Porém ainda é muito cedo para previsões, visto que para o próprio Java SE 7 as funcionalidades previstas foram alteradas diversas vezes. A API destinada ao desenvolvimento de aplicações Desktop, Java Swing, é parte integrante do core Java SE e também evoluiu nas últimas versões. Alguns problemas de incompatibilidade ao utilizar componentes AWT (conjunto de componentes nativos para um determinado sistema operacional) junto com componentes Swing (ligthweigth) foram resolvidos. Além de melhoria de performance na renderização dos componentes, houve também uma concentração no desenvolvimento de Look-And-Feel para Swing. Um grande diferencial nas aplicações Java para desktop é que ela pode ser executada independente do sistema operacional. A tecnologia Java Web Start permite, além de executar o aplicativo, obter sempre a sua última versão a partir do servidor de aplicativos, contornando assim o problema de ter que atualizar todas as aplicações a cada nova versão. Java EE Mesmo antes de a Oracle adquirir a Sun Microsystems, a edição Java EE era uma das edições mais revistas e atualizadas entre todas as edições. Por ser voltada ao ambiente corporativo, suas características devem acompanhar as necessidades das empresas. Desde as versões antigas dos Beans Java EE, a parte de persistência tem grande importância e destaque nas evoluções que seguiram. A 9

3 : : : : especificação JPA foi introduzida junto ao lançamento da especificação EJB 3, com a clara intenção de substituir os EntityBeans da versão anterior. Juntamente com esta especificação, as anotações substituíram as extensas configurações por XML, que se tornaram opcionais e são mais usadas para permitir customizações em tempo de deploy. Com isto, a praticidade das anotações é introduzida a cada nova API ou framework que surge, como é o caso do JSF. Apesar de suas primeiras versões também utilizar de XML para suas configurações, a evolução natural para anotações é vista em suas últimas versões. A mais recente notícia, até a escrita desta matéria, é a apresentação da especificação Java EE 7 como JSR-342. Com unanimidade de votos do comitê executivo, a especificação Java EE 7, JSR-342 foi aprovada e traz muitas novidades para o mundo corporativo. O líder da especificação, Roberto Chinnici (Oracle), destaca as novidades da edição e, segundo ele mesmo, o foco principal para este release é o suporte a Cloud Computing. Este é um assunto muito interessante às empresas, pois permite que grandes sistemas sejam processados em plataformas compartilhadas, reduzindo o custo de hardware e infraestrutura. Conceitos como PAAS (Platform as a Service) são tidos como modelos de negócios graças ao Cloud. Porém, há ainda algumas preocupações a este modelo. Uma delas é a portabilidade das aplicações entre os provedores Cloud, pois ainda não há uma norma capaz de garantir essa portabilidade. Com isto, alguns provedores podem, de certa forma, evitar que uma aplicação migre para outro provedor, o chamado vendor Lock-In. Esperamos que esta nova JSR-342 consiga resolver esse tipo de problema, fazendo com que as aplicações não dependam de APIs proprietárias. A edição número 47 da revista MundoJ (Cloud Computing: levando suas aplicações Java nas nuvens) traz informações em todos os aspectos sobre Cloud Computing. Além de ampliar ainda mais a adequação da plataforma Java EE para ambientes na nuvem, a especificação Java EE 7 traz também novidades que acompanham os padrões web mais recentes, como suporte a HTML 5. Também contará com uma moderna API Client para JAX-RS 2.0 (muito pedida pela comunidade). Tendo em vista a facilidade de desenvolvimento, a API JMS 2.0 será revisitada, trazendo a adição de uma API para configuração de Injeção de Dependência. Apesar de a edição Java EE ser dependente da edição Java SE 7, muitos desenvolvimentos já serão feitos tendo em vista o Java 8. Desta forma, muitas empresas já poderão desenvolver seus aplicativos e tirar proveito de novos recursos da linguagem, logo que ela for lançada. Algumas JSRs aguardam votação para se unir à especificação Java EE 7: lets. Otimizada para Cloud, conta também com algumas melhorias como IO assíncrono baseado em Java NIO2. da especificação JSP 2.0. Mas foi sugerida a separação, para que sejam focadas suas melhorias. Facilidade de uso é um dos principais temas. 1.1, e a última manutenção foi realizada em abril/2002. Extensões para suporte a Cloud, facilidade para o desenvolvimento e melhoria no relacionamento com outras APIS é o destaque desta JSR. de desenvolvimento, tanto na parte gráfica quanto em linha de código, é o foco desta JSR. Introdução a URLs abreviadas (shorthands URL), suporte de features HTML 5, melhor integração com portlets, melhorias no ciclo de vida e segurança além de alguns fixes são os destaques. Ainda existem duas JSRs candidatas à inclusão na edição Java EE 7: Concurrency Utilities for Java EE (JSR-236) e JCache (JSR-107). Até a escrita desta edição, ambas estavam com status Inativo no JCP, o que significa que o líder de cada especificação não publicou um milestone, ou draft para a especificação em 18 meses. Caso atinja 24 meses, o JCP pode retirar as JSRs dos processos. Um dos principais avanços (e benefícios) da plataforma Java EE foi o desenvolvimento da JSR-299, que especifica uma API para injeção de dependência nativa de qualquer recurso Java. Injeção de dependência (DI Dependency Injection) é um design pattern utilizado quando é necessário manter o menor nível de acoplamento possível entre os componentes de uma aplicação. As instâncias dos componentes são construídas externamente à classe, e controladas por um gerenciador. Assim como num passatempo de ligar pontos, baseado numa configuração esse gerenciador (container) liga os componentes entre si de modo a construir a aplicação. Assim, as dependências não são definidas programaticamente. O container fica responsável por injetar em cada componente suas dependências. Entenda-se por injetar passar uma classe que será usada para a classe que irá consumi-la, sem a necessidade de instanciá-la programaticamente. Basicamente, a implementação da injeção de dependência pode ser feita de três formas: Por construtor (constructor injection): as dependências são injetadas direto no seu construtor. Por propriedade (setter injection): as dependências são injetadas via setter em alguma propriedade. Por interface (interface injection): o objeto a ser injetado fornece uma abstração (interface ou classe abstrata) e a injeção é realizada via instância da abstração. Apesar de a injeção de dependência por construtor ser o mais comumente usado, não existe regra que defina qual das três abordagens é a melhor. Assim como quase tudo nas aplicações, depende da situação-problema. 10

4 CDI A injeção de dependência e contextos (CDI), especificada pela JSR- 299 como parte do Java EE 6 fornece uma arquitetura que permite a injeção de componentes Java EE, tais como session beans e managed beans do JSF (Java Server Faces). Alguns outros componentes também podem ter beans injetados via CDI: interceptors, servlets (filters e listeners inclusive), message-driven beans. As classes gerenciadas pelo CDI (os beans) são associadas a contextos para que seu ciclo de vida seja gerenciado automaticamente. Além disso, o CDI oferece várias funcionalidades: fornecedores, qualificadores, decoradores, interceptadores, alternativas e eventos, que flexibilizam e agilizam o desenvolvimento. Todas essas funcionalidades melhoram o baixo acoplamento inerente ao modelo do CDI. E o melhor de tudo é que essas facilidades são oferecidas de modo typesafe. Sem confiar em identificadores baseados em strings, o CDI usa a informação de tipagem do próprio Java, incrementada como um novo padrão denominado anotações qualicadoras, para interligar os componentes beans, dependências, interceptors e decorators, e consumidores de eventos. A injeção de dependência já existia a partir da especificação do EJB 3, porém ela era muito mais restrita e só podia ser usada em EJBs. A por exemplo, permite que o container faça a injeção de qualquer session bean. Outra anotação de injeção de dependência que permite ao container injetar uma instância do EntityManager. Como vemos, as anotações trazidas na especificação EJB 3 são mais específicas e restritas a cada tipo de objeto, o que não é a intenção de CDI que permite a injeção de praticamente qualquer objeto em vários tipos de objetos gerenciados pelo container. Mais detalhes sobre CDI podem ser obtidos no artigo CDI Injeção de Dependência e Gerenciamento de Contextos no Java EE 6 na edição 40 da revista. Com o lançamento de sua primeira versão, em 2004, o JSF chegou com um paradigma interessante: a orientação por componentes. Este modelo de desenvolvimento atraiu muitos desenvolvedores acostumados com desenvolvimento Swing para desktop. Em meados de 2009, a versão 2.0 foi lançada e trouxe novidades que simplificam a vida e aumenta a produtividade inerente a um sistema. Java ME Diferente do que a sigla possa levar a interpretar, Java ME não quer dizer Java Mobile Edition, mas sim Java Micro Edition. Java ME é a plataforma Java voltada ao desenvolvimento de aplicações para dispositivos com recursos limitados de hardware. E, consequentemente, inclui o desenvolvimento para dispositivos móveis. Assim como as demais versões, a plataforma J2ME é uma coleção de APIs do JAVA definidas através da JCP (Java Community Proccess). Em 1999, numa Conferência Java, a plataforma foi subdividida em J2EE (Java 2 Enterprise Edition), J2SE (Java 2 Standard Edition) e J2ME (Java 2 Micro Edition). Em 2000, começaram a surgir os primeiros celulares com suporte ao JME. Em 2002, foi lançada a segunda versão da MIDP (Mobile Information Device Profile), utilizada até hoje. Como parte de uma estratégia de marketing, na mudança da versão do Java 1.4 para 1.5, algumas siglas foram alteradas. Na ocasião, foi retirado o 2 da sigla, alterando de J2ME para Java ME, apresentando uma sigla mais moderna para a plataforma. A arquitetura Java ME é dividida em máquina virtual, configurações, perfis e pacotes (APIs) opcionais. As definem a JVM (Java Virtual Machine) e um conjunto de APIs básicas: com maior capacidade computacional. positivos com menor capacidade computacional. (profiles) são um conjunto de APIs que complementam uma configuração, provendo funcionalidades para cada categoria de dispositivos, definindo interface do usuário, ciclo de vida as aplicações etc.: para dispositivos móveis. em rede sem GUI. necessitam de um suporte completo para interface ou applet (PDAs, consoles). As estendem as funcionalidades básicas provendo padrões para tecnologias específicas, tais como bluetooth, web services e multimídia. A Sun Microsystems desenvolveu a API LWUIT (Ligthweigth UI Toolkit), uma API inspirada em Swing, porém, direcionada para dispositivos móveis. A API permite maior agilidade no desenvolvimento de aplicações móveis, uma vez que é construída da mesma forma como se constrói aplicações Swing para Desktop. A API teve lançamento oficial no JavaOne de 2008, e resolveu alguns problemas de incompatibilidade do Java ME entre os fabricantes de celulares. 11

5 : : : : Android Android não poderia ser uma alternativa de plataforma operacional para o projeto de 2005 pelo simples fato de ainda não existir em 2005! A história de Android inicia em 2006, através do projeto de uma empresa startup americana: a Android Inc, que surgiu com o seu projeto de uma nova plataforma operacional para o mundo dos dispositivos móveis. Google, seguindo com sua estratégia de incorporar startups com projetos inovadores e almejando participar do mercado de dispositivos móveis, adquire Android Inc com todos os seus engenheiros (Andy Rubin, integrante desta equipe, tornou-se recentemente VP do Google e comanda atualmente o time de desenvolvimento do negócio Android). Em novembro de 2007, a Google anuncia o lançamento do Android, um sistema operacional baseado em Linux para dispositivos móveis. Esse evento foi resultado da ação colaborativa das empresas sob a OHA (Open Handset Alliance) junção do Google e mais 33 parceiros. Uma semana depois, o Android SDK foi apresentado aos desenvolvedores, mas ainda não era opensource. Quase um ano mais tarde, em outubro de 2008, o Android tornou-se open source, tendo seu código publicado como AOSP (Android Open Source Project). Logo em seguida, foi lançado o primeiro aparelho celular com Android, o HTC G1 que incluía funções do GPS, uma câmera de 3.1MP, e uma variedade de aplicativos do Google. A seguir, estão listadas as versões já lançadas do Android: de 2009) para tablets A Google costuma se referir ao Android OS como uma pilha de softwares (figura 1). A base da pilha é o kernel. O próximo nível de software inclui as bibliotecas do Android e a camada de runtime. A camada seguinte é o framework de aplicação. E no topo da pilha estão as aplicações propriamente ditas. Em termos de arquitetura, o android incorpora uma jvm chamada dalvik. Porém, este é parte do sistema operacional, o que evita que fabricantes possam customizar para o seu hardware próprio. Em meados de 2010, a Oracle acionou o Google na justiça americana alegando que houve violação de patentes relacionadas ao Java no lançamento da plataforma Android, pelo fato do Google escrever uma JVM do zero, a Dalvik, e da plataforma ser focada no Java. Na ocasião, Larry Ellison, presidente da Oracle, disse à imprensa: Sem consentimento, autorização, aprovação ou licença, o Google conscientemente, propositalmente e ilegalmente copiou, preparou, publicou e distribuiu material com copyright da Oracle America, partes e trabalhos derivados. O Android da Google infiringe o Copyright do Java da Oracle America e a Google não está licenciada para isso. Figura 1. Pilha de softwares da plataforma Android (retirada de guide/basics/what-is-android.html) Contestando a acusação da Oracle, o Google diz que não infringe qualquer patente e alega certa hipocrisia por parte da Oracle. O efeito deste episódio causou o cancelamento, por parte do Google, das participações nas conferências JavaOne, a conferência mais famosa patrocinada pela Oracle. Em nota, o Google lamenta não poder participar, mas enfatiza que é uma conferência importante para a comunidade, e diz que é uma das melhores formas de integração e aprendizado. Este episódio causou impacto na comunidade Java, provocando revolta em muitos desenvolvedores e entusiastas. O rumo dado à plataforma Java também causou um desconforto por certo período de tempo, pois a empresa não se pronunciou tão rapidamente. Atualmente, o processo encontra-se em andamento e ainda não teve um desfecho favorável a nenhuma das partes. Aplicação Taxi GO Essa seção tem o objetivo de apresentar a aplicação que mostrará o desenvolvimento e integração de aplicações Java desenvolvidas para diferentes plataformas. Optamos por um cenário simples, onde o foco principal é mostrar a integração das diferentes tecnologias contidas em Java. Não abordaremos aspectos como segurança, desempenho e controle de transações, que em uma aplicação real é essencial. Imaginamos uma empresa de táxi que necessita de um sistema que possibilite a solicitação de uma corrida realizada por um cliente via celular, um sistema de BackOffice que verifica as filas de pedido de corrida e um outro, também de BackOffice, que gerencia as corridas, selecionando a Unidade que atenderá cada corrida. Para este cenário, foi idealizada uma aplicação móbile destinada à plataforma Android, onde se é possível encontrar o local de origem via GPS. Um módulo de BackOffice verifica como andam as solicitações de corridas realizadas pelos clientes, incluindo o local de onde a solicitação foi realizada. Em um módulo Desktop, é possível visualizar as corridas, assim como indicar a unidade de atendimento. Como vemos na figura 2, o sistema central é composto por uma 12

6 camada de EJBs, responsável por implementar as regras de negócio e operações tratadas pelo sistema. Para distribuir o acesso a estas operações, uma camada de WebServices REST foi construída. Na figura, CorridaResource e UnidadeResource são recursos REST, e possuem uma URI única, o que torna possível o acesso através de um endereço como ou por exemplo. O acesso externo é feito pelos módulos móbile e swing. Ambos acessam recursos REST para executar as operações. Já o módulo web, por estar no mesmo contexto e, consequentemente, no mesmo container web, pode acessar diretamente os EJBs. Como container Java EE, utilizamos o GlassFish na versão 3.1. Em 2005, este container não poderia ser uma opção, pois o lançamento de sua primeira versão foi em O GlassFish foi desenvolvido pela Sun Microsystems, e agora é continuado pela Oracle. A aplicação foi desenvolvida utilizando o Eclipse como IDE, e foi dividida em três projetos, conforme descritos na tabela 1. O código-fonte pode ser baixado a partir do site da revista. TaxiGOAndroid TaxiGOServices TaxiGOManager Projeto Android, para o dispositivo móvel. Projeto do tipo Dynamic Web, e engloba os módulos central e web. Inclui os EJBs, resources REST, assim como toda a parte de persistência. Projeto Java SE swing, contendo o módulo para desktop. Tabela 1. Projetos Eclipse. Módulo central O módulo central é o módulo que concentra todas as regras de negócio e persistência. Por esse módulo ser responsável por processar um grande número de requisições de diversos tipos de cliente, serão utilizadas tecnologias da plataforma Java EE. O módulo deve permitir que os módulos-clientes acessem operações como: inclusão de um pedido de uma corrida, listagem das corridas pendentes (que aguardam um motorista para atendê-la) e a finalização de uma corrida, marcando assim o tempo total do trajeto realizado por uma unidade. Persistência de dados Persistência de dados é um tema sempre em destaque, por se tratar de uma das partes mais importantes dos sistemas. Sempre vemos novidades relacionadas a este tema, com objetivo de melhorias em performance e facilidade para o desenvolvimento. Por isto, esta parte do módulo poderia ser implementada de diferentes maneiras utilizando diferentes soluções. Para este projeto, optamos pelo uso do JPA 2.0, com a implementação do Hibernate. Atualmente, JPA é uma API padrão do Java EE no que se diz respeito à persistência de dados. Nesta última versão, algumas features interessantes foram liberadas na linguagem JPQL (Java Persistence Query Language). É possível realizar um select com formatação de datas e incluir Collections nos parâmetros IN das queries. O suporte a Criteria (baseado no Hibernate) foi uma das grandes novidades. Com esta API, é possível construir queries dinâmicas baseadas em um objetoexemplo. A API adiciona nós á query na medida em que atributos do objeto forem sendo preenchidos. Figura 2. Sistema Táxi GO. Para identificar as partes do sistema, descrevemos os módulos como: gócio e persistência. corrida. ridas pendentes. mento das corridas. O EntityManager será injetado nos EJBs que fornecem os serviços para aplicação e o utiliza para fazer o acesso aos dados. As anotações foram utilizadas nas entidades para mapear como cada uma deveria ser persistida. As próximas seções apresentam com mais detalhe como esses recursos foram implementados. 13

7 : : : : Em 2005, a versão para a API JDBC era a 3.0. Já existiam frameworks de mapeamento objeto-relacional, mas, porém os Entity Beans eram o mais próximo que se tinha de mapeamento em uma API padrão. As opções de frameworks para persistência mais elaborados eram Hibernate (versão 2), OJB, os próprios Entity Beans da especificação EJB 2, entre outros. Na matéria de 2005, foi escolhido Entity Beans CMP, que eram Entity Beans gerenciados pelo container. Os Entity Beans apresentavam sérios problemas de escalabilidade e não suportavam diversos tipos de mapeamento, como herança e certos tipos de composição. Em 2006 a Sun lançou uma API oficial, junto com a especificação do EJB3.0 (JSR-220) chamada JPA. Esta API viria substituir os Entity Beans da versão do EJB2. A partir do lançamento da API, muitos outros frameworks aderentes a mesma foram lançados, como OpenJPA e o Toplink, por exemplo. Com o uso de anotações, muitas das configurações feitas por XML se tornaram opcionais, aumentando a produtividade. Hoje, a API JPA está na versão 2.0 e foi lançada em dezembro/2009. Muitas funcionalidades como Criteria e Validation foram adicionadas. Criteria permite a construção dinâmica de uma querie JP QL, baseada em um objeto de exemplo. À medida que valores são preenchidos em seus atributos, sem intervenção programática, a API consegue selecionar os objetos parecidos com o de exemplo. A API validation traz uma série de anotações que permite validar os dados contidos nas classes, geralmente as que serão são exemplos de anotações desta API. Ao optar por JPA, economizou-se esforço de desenvolvimento, como com construção de queries para o CRUD e preocupações comuns no acesso ao banco de dados. Entidades Para o cenário proposto, foram levantadas apenas três entidades: Passageiro, Unidade e Corrida. O modelo de dados para o armazenamento dessas entidades está representado na figura 3. Em uma aplicação real haveria provavelmente mais entidades, porém o artigo irá focar em um exemplo mais simples para poder focar nas tecnologias utilizadas. A entidade Passageiro representa o cliente, este que solicitará um táxi. A entidade Unidade representa o próprio táxi com os seus respectivos atributos, como nome do motorista, placa ou ID. A entidade Corrida, por sua vez, representa o trajeto realizado pelo táxi para o cliente em questão. Esta entidade guarda informações tanto do passageiro quanto da unidade (motorista), portanto o seu relacionamento de n-para-um é feito para essas duas outras entidades. Não precisamos mapear os relacionamentos como bidirecional, pois não será interessante para o sistema saber em quais corridas o cliente já esteve presente, e quais corridas uma determinada unidade um dia já atendeu. Listagem 1. Corrida public class Corrida implements Serializable { private static final long serialversionuid private int hora_solicitacao ) private Date hora_finalizacao ) private Date lat_origem ) private double lon_origem ) private double lonorigem; private String qru; private String status; private Passageiro_ ) private Unidade_id ) private Unidade unidade; Figura 3. Modelo de dados para o TaxiGO. //construtor, getters e setters omitidos 14

8 Um exemplo de entidade está apresentada na Listagem 1. Analisando a classe Corrida, vemos que ela possui duas Entity Como optamos por utilizar JPA para gerenciar a camada de persistência, a é necessária para que a classe seja reconhecida pelo EntityManager como uma classe de entidade persistente. Já a indica qual é o elemento raiz do XML que será gerado. A anotação está contida no pacote javax. xml.bind.anotação, e é parte da API JAXB. A API de referência foi desenvolvida sob a JSR 222, e sua última versão até o momento desta matéria é Com esta API, faremos a transformação da Classe para o XML que é transferido entre os sistemas clientes e o sistema central. Com essas anotações, as classes de entidade podem ser mapeadas para o banco de dados sendo gerenciadas pelo EntitManager, e pode ser, de forma fácil, transformadas para o formato XML. Para se relacionar com as outras entidades, a classe Corrida utiliza as anotações de mapeamento Como vemos na classe, a fica acima do atributos que corresponde ao lado Um quando se diz Muitospara-um. Por sua vez, a indica por qual atributos o EntityManager deverá selecionar os dados na hora de realizar o join entre as tabelas no banco de dados. Todas as classes de entidade são desenvolvidas da mesma forma e podem ser acessadas no código-fonte disponível para download no site da revista. EJB Listagem 2. Classe public class CorridaEJB taxipu ) private EntityManager em; public Corrida find(integer pk){ try { Object o = (Corrida) em.find(corrida.class, pk); em.refresh(o); detach(o); return o; catch (Exception e) { return null; public void persist(corrida t){ try{ em.persist(t); em.flush(); catch(exception e){ public void merge(corrida t){ try{ em.merge(t); em.flush(); catch(exception e){ Para concentrar as operações principais do sistema e suas regras de negócio, criamos uma camada de negócios onde se encontram os EJBs do sistema. Esse tipo de componente é utilizado para conter serviços que representam processo de negócio. Os EJBs utilizados, que no caso são Session Beans, fazem parte da especificação EJB 3.1, que é parte integrante da versão Java EE 6. Nesta versão, EJBs podem estar contidos em um projeto de estrutura web (arquivos WAR), e por isto unimos todas as partes do módulo central em um único projeto web. public List<Corrida> getbystatus(string status){ CriteriaBuilder cb = em.getcriteriabuilder(); CriteriaQuery<Corrida> cq = cb.createquery(corrida.class); Root<Corrida> root = cq.from(corrida.class); Predicate bystatus = cb.equal(root.get( status ), status); cq.where(bystatus); List<Corrida> corridas = em.createquery(cq).getresultlist(); return corridas; Além disto, a especificação conta com novas anotações, Singleton que faz com que o container garanta apenas uma instância do EJB. Chamadas assíncronas, timer service integrado, e um EJB mais leve (EJB Lite) são itens importantes que fazem parte desta atualização e que não foram utilizados no exemplo. Uma novidade do EJB 3.1 que foi usada no projeto, é que para EJBs que serão chamados apenas localmente, não é preciso mais ter uma interface anotada como este é o caso de nossa aplicação, pode-se observar que os EJBs não implementam nenhuma interface. Os acessos externos serão feitos no sistema a partir de uma camada adicional que disponibilizará os serviços via WebServices Restful. Como podemos ver, a classe CorridaEJB apresentada na Listagem 2 é anotada Esta anotação indica ao container que deve ser tratada como um EJB do tipo Stateless. Seu ciclo de vida é gerenciado pelo container e suas instâncias poderão viver em um pool de objetos que o container gerencia. Nesta classe, anotamos também a instância do EntityManager, que será injetada pelo container. Indicamos isto ao container adicionando a PersistentContext, seguida no nome da unidade de persistência configurada no arquivo persistence.xml Analisando o método getbystatus(), podemos ver que este utiliza de uma feature nova da versão JPA 2.0. Criteria é uma API que permite a construção de queries dinâmicas, utilizando um objetoexemplo. Para demonstrar o uso da API, fizemos a execução de uma consulta simples, obtendo todos os registros de Corrida que contém um determinado status. A primeira linha CriteriaBuilder cb = em.getcriteriabuilder();, obtém do EntityManager o construtor de queries dinâmicas. Na linha Root<Corrida> root = cq.from(corrida.class); indicamos qual é o elemento principal na consulta, no caso a classe Corrida. Em seguida, em Predicate bystatus = cb.equal(root.get("status"), 15

9 : : : : status); informamos que o atributo status de nossa classe deve ser levado em consideração na consulta, e que devem ser buscados valores iguais (equal) ao informado na variável status. Ao final, adicionamos esse critério a consulta através do comando cq.where(bystatus); Podemos ver mais detalhes sobre as novidades do EJB 3.1 na edição número 31 da revista. No artigo em 2005, os EJBs estavam na versão 2.1. Uma série de passos deveriam ser seguidos ao implementar um EJB, o que incomodava muita gente. Qualquer EJB Session Bean deveria implementar a interface ServiceBean, que obrigava o desenvolvedor a escrever métodos relacionado ao ciclo de vida do EJB, como ejbcreate(), ejbactivate() e ejbremove(), muitas vezes sem necessidade. O Session Bean deveria possuir também uma interface representando os métodos disponíveis. Para o acesso no mesmo container, a interface deveria extender outra interface, a EJBHome. Para acesso remoto, deveria extender EJBObject. A configuração era realizada por XML, já que ainda não existiam as annotations. O XML (ejb-jar.xml) descrevia os EJBs da aplicação, assim como suas interfaces local e remota. Para ajudar nessa tarefa de configuração, era muito comum o uso da ferramenta o XDoclet. A ferramenta lia tags descrita em comentários JavaDoc gerava o código-fonte das interfaces local e/ou remota, seguindo um template de código definido. Na versão de 2005, esta ferramenta facilitou na geração das interfaces Local e Remota. A evolução dos EJBs se deu em todos os aspectos, desde suas configurações até o padrão de estruturas de pastas. Hoje, em sua versão 3.1, não é mais necessária uma estrutura de pastas específicas para um projeto EJB. Podemos colocar EJBs em arquivos WAR (web-archive), o que antes era possível apenas em arquivos JAR (contidos ou não em um arquivo EAR). O uso de anotações e convenções de código eliminou quase por completo as configurações XML, que agora são opcionais. Para informar ao container um session bean stateful, basta utilizar a acima da classe, assim como stateless utilizando a Na versão 3.0 já deixou de ser obrigatório escrever métodos que não dizem respeito a regras de negócio e operações. Para interceptar o ciclo de vida, foram disponibilizada anotações para serem utilizadas em PostActivate por exemplo. A criação de uma interface local ou remota passou a ser opcional, tornando o session bean praticamente um POJO com anotações EJB. Um EJB pode ser facilmente utilizado como um recurso REST, e por isto adicionamos a A classe. Com isto, além de ser uma interface de serviços aos outros módulos do sistema, fornecendo uma forma de ser acessado por uma URL, poderia ser chamado através de RMI por algum outro sistema interessado em consumir EJBs. Dessa forma, temos duas camadas EJB, uma responwebservices baseados em SOAP, apresentando maior flexibilidade e facilidade no desenvolvimento. Na arquitetura REST, funcionalidades são consideradas Recursos (Resources), que são acessadas através de URIs únicas. Para facilitar o entendimento, os recursos do sistema com suas respectivas URIs estão representadas na tabela 2. Note que a URI, no geral, é formada pelo nome da entidade relacionada à ação correspondente. Figura 4. Combinando JPA + JAXB + REST. Poderíamos ter criado uma camada DAO com classes convencionais e ter separado todas as responsabilidades de operações em banco de dados nesta camada. Outra opção seria a utilização de DAOs genéricos, fazendo com que operações de CRUD em comum a todas as entidades ficassem em apenas uma classe DAO. Na aplicação-exemplo optamos por utilizar o próprio EJB como implementação dos DAOs. O container injeta uma instância do EntityManager, realizando trabalhos como a criação da conexão e o controle de transações. Desta forma, cada entidade de domínio no sistema deve ter o seu EJB com os métodos de todas as operações possíveis. Por exemplo, temos o EJB CorridaEJB, que trata qualquer operação relacionada a corridas. Suas regras de negócio estão explícitas neste ponto, e quando o método precisa de uma operação no banco de dados, o EntityManager é utilizado. RESTFul Em 2000, Roy Fielding, um dos principais autores da especificação do protocolo HTTP, escreveu sua tese de doutorado baseada em uma técnica de engenharia de software para sistemas distribuídos na web. Em sua tese, ele descreve o Representational State Transfer (REST), um conjunto de princípios arquiteturais que permite troca de mensagens entre sistemas heterogêneos. Para o REST, os verbos HTTP (GET, POST, PUT, DELETE) definem a ação que será realizada. Hoje em dia, webservices REST são uma alternativa aos Cadastrar Unidade Atualizar Unidade Selecionar Corrida Finalizar Corrida Consultar Corridas Pendentes Consultar Corrida Solicitar Corrida /unidade/cadastrar /unidade/atualizar /corrida/selecionar /corrida/finalizar /corrida/consultarpendentes /corrida/consultar/{idcorrida /corrida/solicitar Tabela 2. URIs definidas para os serviços do TaxiGO. Na Listagem 3 é mostrada a classe CorridaResource, que é responsável por oferecer os métodos disponíveis relacionados a uma corrida. A indica qual será a URI raiz do recurso representado pela classe. Através desta anotação, indicamos que qualquer URI acessada após /corrida, será de responsabilidade desta classe. Em cada método da classe, devemos indicar por qual verbo HTTP será acessado, como no exemplo a e que tipo de informação este método produz e consome, através das Note que a é usada novamente para configurar a URI específica do método. 16

10 sável pelas regras de negócio e suas operações, tratando de forma específica assuntos como persistência de dados, e outra responsável pela interface entre os módulos clientes e as operações do sistema em si. Como podemos ver, essa classe possui um atributo do tipo CorridaEJB que é injetado pelo container, como indica a A Listagem 3 mostra como exemplo o método solicitar(). Este é um dos principais métodos deste sistema, uma vez que é responsável por reservar uma corrida para um cliente. Foi configurada a URI / solicitar para este método. Ele será acessado somente se for chamado pelo verbo PUT, indicado pela O método espera por um objeto do tipo Corrida como parâmetro. A API JAXB converte, a partir do XML recebido no request, para uma instância da classe Corrida, com os atributos preenchidos. Este método não tem efetivamente um retorno, mas podemos informar ao cliente que a operação foi executada com sucesso. O retorno do método é uma classe do tipo Response, onde podemos responder qualquer status esperado pelo protocolo HTTP. No caso de alguma exceção ocorrer, este método responde ao cliente com um erro do tipo Internal Server Error (Erro 500 do protocolo HTTP). O Enum Response.Status contém todos os status do protocolo HTTP. Para este método, é esperado um objeto do tipo Corrida com as informações sobre o cliente preenchidas, inclusive as coordenadas geográficas que serão extraídas do GPS do celular. O servlet REST receberá um XML, e a API JAXB irá converter para a classe Corrida que é recebida como parâmetro. O método precisa adicionar as informações sobre o momento da solicitação, o que é feito obtendo a data e hora corrente do sistema (System.currentTimeInMillis()). O método também marca a corrida como pendente, uma vez que em primeiro momento aguardará por um motorista disponível. O método consultar() foi desenvolvido com o objetivo de possibilitar a consulta de uma corrida através de seu ID, portanto sendo um método idempotente (ver quadro para detalhes) deve ser anotado como Vemos que o método recebe um parâmetro do tipo Integer idcorrida, mas com uma diferença de possuir a Esta anotação faz com que, ao ser chamado, o servlet do REST forneça essa informação diretamente ao método. A informação é parametrizada no atributo da que nesse caso é "/consultar/{idcorrida". Os atributos entre chaves {, indicam que o valor será passado para Listagem 3. Classe /corrida public class CorridaResource private /solicitar ) public Response solicitar(corrida corrida){ try{ Calendar cal = Calendar.getInstance(); cal.settimeinmillis(system.currenttimemillis()); corrida.sethorasolicitacao(cal.gettime()); corrida.setstatus( Pendente ); corridaservice.persist(corrida); catch(exception e){ return Response.serverError().build(); /consultar/{idcorrida ) public Response consultar(@pathparam( idcorrida ) Integer idcorrida){ try{ Corrida corrida = corridaservice.find(idcorrida); return Response.ok(corrida).build(); catch(exception e){ return Response.serverError().build(); //Outros métodos omitidos algum parâmetro do método. No exemplo, o atributo da anotação {idcorrida está ligada ao com o mesmo nome. Por exemplo, para consultar a corrida de ID 13, chamamos a URI corrida/consultar/13. Internamente, o REST extrai esse parâmetro e passa para o método. Em 2005, os módulos conversavam através de um módulo central, da mesma forma que hoje. Porém, este módulo central era composto por servlets e EJB 2.1. Para o envio de uma informação entre o módulo cliente móbile, por exemplo, strings eram esperadas no request, para que o método doget() do servlet capturasse e tratasse a informação. Ao receber essa informação, o método realizava um lookup para o EJB responsável pela operação, e este convertia em byte array para responder ao cliente. Esta conversão para byte[] é direcionada ao cliente móbile. Um XML ou string delimitada poderia ser retornada, porém algum tratamento da informação seria necessária no cliente. Por exemplo, se retornasse um XML, um parse deveria ser realizado, e para isto provavelmente um API seria utilizada, aumentando assim o tamanho da aplicação MIDP. O XML gerado como resposta pelo servidor era montado manualmente, de forma que se formasse uma string concatenada contendo as tags do XML e os valores das informações. Atualmente, com o avanço no processamento dos dispositivos móveis, assim como a sua capacidade de armazenamento, não é mais necessária uma solução direcionada a estes dispositivos. Android, por exemplo, possui um parser nativo de XML entre as suas APIs, não sendo necessárias APIs de terceiros para realizar o tratamento no XML. E, por isto, escolhemos realizar esta integração com webservices REST, uma vez que este retorna um XML comum ao dispositivo. Desta forma, os clientes do módulo central acessarão todos da mesma forma, sem exceção. Também não é necessário o lookup explícito aos EJBs, pois este é injetado diretamente ao recurso REST através da Todo este trabalho, que antes era feito manualmente, passou a ser feito pelo container. O XML gerado pelo servidor não é mais manipulado pelo desenvolvedor. A API que implementa a especificação REST converte automaticamente para a classe desejada aumentando a produtividade e reduzindo a complexidade inerente ao tratar dados em XML. Alguns métodos HTTP são idempotentes e outros não. Um método é dito idempotente quando uma requisição causa o mesmo efeito que várias requisições sucessivas. O método GET é um método idempotente, portanto espera-se que as regras de negócio sob este método não cause nenhum efeito colateral se chamado sucessivas vezes. Como próprio nome do método (GET), subentende-se que este apenas irá obter algum recurso (consultas). 17

11 : : : : Módulo web Em 2005, o mais popular framework web era o Struts. Sua popularidade era maior do que qualquer outro framework, e possuía a maior comunidade de desenvolvedores. Muitas empresas até hoje utilizam este framework, inclusive a sua primeira versão lançada em No artigo anterior, não foi utilizado nenhum framework no desenvolvimento da solução. Neste artigo, vamos falar um pouco além da integração entre as plataformas, demonstrando a escolha de uma opção atual para o front-end web. Para o módulo web do TaxiGO, escolhemos o JSF em sua versão 2.0, que é uma API que faz parte da especificação Java EE 6. A implementação de referência usada neste artigo é a Mojarra e é apoiada pela JBoss. O front-end web tem como objetivo mostrar as corridas que estão sendo solicitadas em tempo real. Como é um front-end web, pode ser acessado por navegadores tanto pelo desktop como pelo celular. Juntamente com o JSF, escolhemos uma biblioteca de componentes visuais para deixar as páginas mais atraentes: o PrimeFaces. O PrimeFaces vem sendo muito utilizado por sua diversidade de componentes e sua facilidade no momento da configuração. Para se ter uma ideia, basta ter o jar do primefaces no class-path da aplicação que já é possível declarar e utilizar os seus componentes. Como o objetivo aqui é mostrar a integração entre o módulo web e os EJBs da aplicação, não vamos nos aprofundar nos assuntos JSF e Primefaces. O artigo Frameworks RIA para JSF Lado a Lado, da edição número 42 da revista, compara os frameworks para JSF, entre eles o primefaces. Listagem 4. Classe CorridaBean (Managed Bean corridabean public class CorridaBean { private List<Corrida> private CorridaEJB corridaservice; public List<Corrida> getcorridaslist() { corridaslist = corridaservice.getbystatus( Pendente ); return corridaslist; public void setcorridaslist(list<corrida> corridaslist) { this.corridaslist = corridaslist; public void atualizacorridas(){ getcorridaslist(); Como podemos ver na Listagem 6, a classe é anotada pelas Estas anotações são novidades do JSF 2, pois nas versões anteriores do JSF as configurações eram feitas em arquivos XML. A indica que a classe é um Bean Gerenciador do JSF. Esta anotação pertence ao pacote do jsf, mas poderíamos utilizar outras anotações da especificação CDI por exemplo, fazendo com que o Bean se tornasse um Bean gerenciado por alguma implementação CDI. Este Bean é responsável por intermediar a comunicação entre a página web e o módulo central, que contém as regras de negócio e operações do sistema. Neste Bean é possível ter métodos Listeners (métodos que escutam eventos dos componentes da página), métodos que acessam dados para mostrar nos componentes, entre outros. Nesta mesma classe, vemos que a é utilizada acima do atributo CorridaEJB. Com isto, o container Java EE pode injetar uma instância do EJB diretamente no atributo, e gerenciando o seu ciclo de vida. Desta forma, temos um ManagedBean mais clean, delegando tarefas para o EJB. Lembrando que o EJB está na mesma estrutura deste módulo web. Está permitida pela plataforma Java EE 6, e nas versões anteriores o EJB teria a sua própria estrutura e não funcionaria desta forma. Na Listagem 5, vemos a página index.xhtml do módulo web. Esta é a página responsável por mostrar as corridas pendentes que estão sendo solicitadas pelos clientes. Ela basicamente contém um data- Table listando as informações das corridas. O datatable utilizado é uma taglib do framework Primefaces, pois apresenta uma table interessante e atraente para mostrar informações. Além de fornecer parâmetros para ordenação, paginação header e footer, também já vem com meios para obter informações com Ajax. Um parâmetro interessante é o Lazy Loading, que permite carregar as informações à medida que vê avanço nas páginas da listagem. Além da taglib <p:datatable>, utilizando também a <p:gmap>, responsável por renderizar um mapa GoogleMaps. Basta informar latitude e longitude no parâmetro Center, que será renderizado um mapa GoogleMaps onde o ponto central será as informações pas- tanto a visão Satélite quanto o desenho do mapa. Para que as informações sejam atualizadas sem nenhuma intervenção, utilizamos a taglib <p:poll>. Este é um dos padrões de Ajax Reverso, onde a página fica solicitando, de tempos em tempos, os dados do servidor. Para informar o intervalo de tempo em segundos, é necessário o parâmetro intervalo. Precisamos informar também qual método será chamado no bean, e este é feito no parâmetro listener. O parâmetro update informa qual o componente da página será atualizado após a chamada receber o retorno do server. 18

12 Listagem 5. Página index.xhtml. <?xml version= 1.0 encoding= UTF-8?> <!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN > <html xmlns= xmlns:p= xmlns:h= xmlns:f= > <h:head> <title>taxigo - Corridas pendentes</title> <script type= text/javascript src= ></script> </h:head> <h:body> <p align= center > <p:graphicimage url= images/logo_web.png alt= TaxiGO Web /> </p> <h:form> <p:datatable var= corrida value= #{corridabean.corridaslist id= gridcorridas > <p:column> <f:facet name= header > Id </f:facet> <h:outputtext value= #{corrida.id /> </p:column> <p:column> <f:facet name= header > Hora Solicitacao </f:facet> <h:outputtext value= #{corrida.horasolicitacao > <f:convertdatetime pattern= dd/mm/yyyy HH:mm /> </h:outputtext> </p:column> <p:column> <f:facet name= header > Passageiro </f:facet> <h:outputtext value= #{corrida.passageiro. /> </p:column> <p:column> <f:facet name= header > Mostrar no mapa </f:facet> <p:commandbutton type= button image= ui-icon ui-icon-pin-s value= Mostrar no mapa onclick= dlg.show() /> <p:dialog widgetvar= dlg width= 625 height= 450 modal= true > <p:gmap center= corrida.latorigem, corrida.lonorigem zoom= 17 type= HYBRID style= width:825px;height:450px widgetvar= mymap /> </p:dialog> </p:column> </p:datatable> <p:poll interval= 10 listener= #{corridabean.atualizacorridas update= gridcorridas /> </h:form> </h:body> </html> Figura 5. Módulo web mostrando as corridas pendentes em um datatable. Módulo cliente móbile Para o módulo cliente móbile, escolhemos a plataforma Android por esta plataforma oferecer componentes atraentes para uma aplicação direcionada a dispositivos móveis. A aplicação do celular contém apenas uma tela de interface para o usuário onde são realizadas todas as funcionalidades. Uma das funções é comunicar-se com a central, enviando a informação sobre a localização do usuário (latitude e longitude) obtida através do GPS ou da rede da operadora, e a conta Google que o usuário está utilizando no dispositivo. A comunicação é realizada através do protocolo HTTP, enviando informações no formato XML para o WebService RestFul disponibilizado no sistema central. 19

13 : : : : Listagem 7. XML recebido pelo sistema central. <corrida> <horasolicitacao> t16:38:23-03:00</horasolicitacao> <id>1</id> <latorigem> </latorigem> <logradouro> R. Cotoxó : São Paulo, Santo André - Brasil </logradouro> <lonorigem> </lonorigem> <passageiro> <celular/> < >odair.bonin@gmail.com</ > </passageiro> <status>confirmada</status> <unidade> <id>2</id> <nomemotorista>benedito Ruy</nomeMotorista> <numero>137</numero> <placa>dlp-2913</placa> </unidade> </corrida> Como podemos ver na classe TaxiGOService representada na Listagem 6, no envio da informação o XML é montado concatenando-se os dados necessários. A comunicação é feita através da classe HttpClient, uma API nativa do Android que permite uma conexão a um servidor através do protocolo HTTP. O método solicitar() recebe como parâmetro um objeto do tipo Corrida, usado para concatenar as informações com o XML. Este método chama o método solicitar() do sistema central, exposto sob a URI /corrida/ solicitar. Como o método espera que o acesso seja feito através do método HTTP PUT, deve-se utilizar a classe HttpPut para enviar o XML. Para realizar este envio, é necessário adequar o seu conteúdo a um tipo de classe Entity. Como estamos enviando informações do tipo String (XML) então setamos o conteúdo em uma classe do tipo StringEntity. Para cada tipo de conteúdo há uma classe respectiva, como, por exemplo, o ByteArrayEntity para dados binários. O conteúdo do XML será enviado no corpo da requisição HTTP. Precisamos também setar informações adicionais como chartset e content-type ao cabeçalho PUT, e isto se faz adicionando o valor application/xml; charset=utf-8 para a propriedade Content-Type do Header. O resultado esperado é a resposta do serviço do sistema central. Como informamos lá no sistema central que os métodos produzem informação do tipo XML, então devemos esperar um XML na resposta. Este XML precisa ser transformado em uma instância de um objeto, e para isto utilizamos a API SAX, também nativa. O método privado parsexml() é responsável por receber o XML e devolvê-lo em forma de uma classe, porém a lógica de parsing do XML está na classe CorridaHandler usada no método. Um dos benefícios de se utilizar SAX como parse XML é a capacidade de poder analisar um XML sob demanda, sem a necessidade de ter que construir a árvore inteira em memória. O código-fonte dessa classe está disponibilizado com o resto da aplicação no site da revista MundoJ. Listagem 6. Classe TaxiGOService, resposável por tratar o envio e retorno de informações. public class TaxiGOService { private HttpClient httpclient = new DefaultHttpClient(); private String urlservice; public TaxiGOService(String urlservice) { this.urlservice = urlservice; public Corrida solicitar(corrida corrida) throws Exception{ String xml = getxml(corrida); try { HttpPut put = new HttpPut(urlService + /corrida/solicitar ); ResponseHandler<String> handler = new BasicResponseHandler(); StringEntity myentity; myentity = new StringEntity(xml, UTF-8 ); put.addheader( Content-Type, application/xml; charset=utf-8 ); myentity.setcontenttype(put.getfirstheader( Content-Type )); put.setentity(myentity); String result = httpclient.execute(put, handler); Log.d( result, result); return parsexml(result); catch (Exception e) { Log.d( ErroTaxiGOService, e.getlocalizedmessage()); return null; public Corrida consultar(integer idcorrida){ HttpGet get = new HttpGet(urlService + /corrida/consultar/ + idcorrida); ResponseHandler<String> handler = new BasicResponseHandler(); String result; try { result = httpclient.execute(get, handler); Log.d( result, result); return parsexml(result); catch (Exception e) { Log.d( Erro ao consultar corrida, e.getlocalizedmessage()); return null; private Corrida parsexml(string xml) throws Exception { SAXParserFactory spf = SAXParserFactory.newInstance(); SAXParser sp = spf.newsaxparser(); XMLReader xr = sp.getxmlreader(); CorridaHandler passageirohandler = new CorridaHandler(); xr.setcontenthandler(passageirohandler); sp.parse(new ByteArrayInputStream(xml.getBytes()), passageirohandler); Log.d( handler, passageirohandler.getcorrida().getid() + ); return passageirohandler.getcorrida(); private String getxml(corrida corrida){ String ret = <corrida> + <latorigem> + Location.convert(corrida.getLatOrigem(), Location.FORMAT_DEGREES).replace(,,. )+ </latorigem> + <lonorigem> + Location.convert(corrida.getLonOrigem(), Location.FORMAT_DEGREES).replace(,,. ) + </lonorigem> + <logradouro> + corrida.getlogradouro() + </logradouro> + <passageiro> + <celular> + corrida.getpassageiro().getcelular().trim() + </celular> + < > + corrida.getpassageiro().get ().trim() + </ > + </passageiro> + </corrida> ; return ret; 20

14 Desenhando a interface O desenvolvimento de interfaces gráficas no Android é feito através de um padrão XML. Com este XML, o compilador gera uma classe de onde é possível acessar os componentes da tela. Utilizamos o site para desenhar a interface principal. O site permite arrastar-e-soltar os componentes gráficos em uma área predefinida, e ao final gerar o XML. A Listagem 8 mostra o XML gerado para a interface do módulo móbile. A interface contém apenas labels, botões e um progress bar. Escolhemos usar o layout absoluto, representado na tag <AbsoluteLayout>. Para este tipo de layout, informações posicionais x e y são informadas em pixels, pois são com estas informações que os componentes são posicionados na tela. Pode parecer complicado desenvolver um layout assim, mas utilizando uma ferramenta que facilita o desenho da tela (droiddraw), esta dificuldade fica em segundo plano. Os labels são representados pelas tags <TextView> e permite somente a visualização do texto, sem edições. Para edições, é usado o EditText. Todos os componentes precisam ter um ID, para que este seja manipulado via código. O padrão de nomeação dos componentes é descrito como "@+id/nome_componente. Automaticamente, o sdk relacionará um id inteiro a este componente, e este poderá ser acessado pela classe R como R.id.nome_componente, por exemplo. Figura 6. TaxiGO Android. Na figura 6, vemos a interface visual do módulo Android.Bem simples, ela apenas conta com o botão novo endereço, que solicita o sinal do GPS, e espera pelas informações de latitude e longitude. Quando essas informações chegam, o botão Chamar taxi! é desabilitado. Quando acionado, envia as informações para o módulo central, e mostra o resultado da requisição no label Solicitacao. Localizando a posição via GPS Para realizar a solicitação de um táxi à central, é necessário informar o local de origem do passageiro. A aplicação pode utilizar um dispositivo GPS, muito encontrado em smartphones, ou a rede da operadora para realizar esta localização. A classe responsável Listagem 8. Arquivo main.xml, representando interface principal. <?xml version= 1.0 encoding= utf-8?> <AbsoluteLayout android:layout_width= fill_parent android:layout_height= fill_parent xmlns:android= > <TextView android:layout_width= 286px android:layout_height= 26px android:text= Iniciando... android:layout_x= 1px android:layout_y= 2px > </TextView> <ProgressBar android:layout_width= 15px android:layout_height= 17px android:visibility= invisible android:layout_x= 297px android:layout_y= 10px > </ProgressBar> <TextView android:layout_width= 286px android:layout_height= 26px android:text= Longitude: aguarde... android:layout_x= 20px android:layout_y= 64px > </TextView> <TextView android:layout_width= 286px android:layout_height= 26px android:text= Longitude: aguarde... android:layout_x= 19px android:layout_y= 102px > </TextView> <Button android:layout_width= 132px android:layout_height= 39px android:text= Novo endereço android:layout_x= 4px android:layout_y= 380px > </Button> <TextView android:layout_width= 288px android:layout_height= 97px android:text= aguarde... android:layout_x= 22px android:layout_y= 158px > </TextView> <TextView android:layout_width= wrap_content android:layout_height= wrap_content android:text= Endereco android:layout_x= 20px android:layout_y= 137px > </TextView> <Button android:layout_width= 137px android:layout_height= 40px android:text= Chamar taxi! android:layout_x= 178px android:layout_y= 379px android:enabled= false > </Button> <TextView android:layout_width= 288px android:layout_height= 60px android:text= Solicitacao android:layout_x= 18px android:layout_y= 277px > </TextView> </AbsoluteLayout> A classe principal é o Midlet, que é a que inicia a aplicação. A aplicação é portável para vários dispositivos, porém a interface gráfica não é muito bonita. Para a transferência de dados, é acessado um Servlet através da API Conector, e array de bytes é trafegado sob o protocolo http. A classe Activity é a principal da aplicação e representa uma interface gráfica. Ela é indicada no arquivo AndroidManifest.xml. A aplicação funciona apenas em celulares com sistema operacional Android e possui uma interface mais rica. Para transferência de dados, é acessado um web service REST que direciona a requisição para o método de um EJB. 21

15 : : : : por gerenciar a localização é a LocationManager, classe nativa do Android. Através dela, a API nos fornece informações do status do GPS ou rede, entre outras informações. Para saber onde está o usuário precisamos de um listener para o GPS que implemente a interface LocationListener. A cada atualização de informação trazida do dispositivo GPS ou rede, o método onlocationchanged() é chamado. Ele recebe uma classe do tipo Location, que fornece informações importantes, como latitude e longitude. Na Listagem 9, podemos analisar o método onlocationchanged(). Este método é responsável por obter a posição do GPS com informações de latitude e longitude. O método também obtém o endereço, com informação de logradouro, range de números que o dispositivo possa estar (pois a localização não é tão precisa). Quando o GPS encontra nova localização, este método é chamado e recebe um parâmetro do tipo Location. Esta classe fornece as informações de latitude e longitude. A classe GeoCoder, do pacote android.location, fornece uma maneira de saber o logradouro, chamando o método getfromlocation(location.getlatitude(), location.getlongitude(), 1). O último parâmetro é um número inteiro, que informa quantos endereços na volta do local informado o método pode trazer. Ele retorna um array de classes do tipo Address. O recomendado é recuperar entre um e cinco endereços. Listagem 9. Método onlocationchanged() da classe Listener, demonstrando como obter a posição por GPS. public void onlocationchanged(location location) { this.location = location; txtlog.settext( Pesquisando local... ); double lat = location.getlatitude(); double lng = location.getlongitude(); txtlat.settext( Latitude: + lat); txtlon.settext( Longitude: + lng); locationmanager.removeupdates(this); try { List<Address> addresses = geocoder.getfromlocation( location.getlatitude(), location.getlongitude(), 1); Address a = addresses.get(0); txtlog.settext( Endereço encontrado! ); txtendereco.settext(a.getthoroughfare() + : + a.getfeaturename() a.getadminarea() +, + a.getlocality() a.getcountryname()); btnchamartaxi.setenabled(true); catch (Exception e) { finally{ pgbar.setvisibility(progressbar.gone); Módulo gerencial O módulo gerencial é composto por uma aplicação Swing, cujo objetivo é gerenciar as corridas solicitadas pelos clientes. Ao solicitar uma corrida, esta fica com status pendente aguardando uma unidade livre para atendê-la. Uma tela lista as corridas neste status para que o atendente possa atribuir uma unidade à solicitação. Ao atribuir uma unidade, o passageiro recebe a informação de que a unidade escolhida pelo atendente o atenderá. Inicialmente, o módulo deve acessar o sistema central, solicitando as corridas pendentes. Em cada corrida pendente, o operador deve indicar qual unidade atenderá esta corrida e, neste momento, o sistema móbile receberá a informação que será atendida. Para realizar o deploy da aplicação, não precisamos instalar em cada estação. Para isto, usamos a tecnologia Java Web Start, que permite que as aplicações sejam transferidas ao desktop e executadas automaticamente. Ela possibilita, inclusive, baixar e instalar o próprio JRE na estação, caso não tenha instalado. Para utilizar Java Web Start, é necessário criar um arquivo JNLP (Java Networking Launching Protocol), que é um ar- quivo onde informamos as configurações de nossa aplicação. Os arquivos do aplicativo, assim como as suas dependências, ficam em uma pasta acessível no container web. Ao acessar o arquivo.jnlp, a JRE local da estação interpreta as informações do arquivo e solicita a transferência dos arquivos. Por padrão, aplicativos Java Web Start rodam no modo "restrito", o que significa que eles não têm acesso a alguns recursos do sistema, como arquivos locais. Mas os editores podem eliminar essas restrições, assinando suas aplicações Web Start com o jarsigner ferramenta que vem com o JDK. Ao acessarmos a URL desktop/taxigodesktop.jnlp, por exemplo, a aplicação é transferida do servidor para a estação, e inicia a aplicação. Uma grande vantagem de se usar esta tecnologia é que se atualizarmos a versão do aplicativo e deixarmos disponível no servidor, na próxima vez que a estação acessar a mesma URL receberá a aplicação atualizada. A Listagem 10 mostra o código que recupera as informações de corridas pendentes. Para acessar o módulo central, utilizamos classes que pertencem a lib jersey-client.jar, criada para encapsular a conexão a um Resource REST. A classe WebResource, do pacote 22

16 Listagem 10. Arquivo JNLP para o módulo desktop. <?xml version= 1.0 encoding= utf-8?> <jnlp codebase= > <information> <title>taxigomanager</title> <vendor>mundoj</vendor> <description>modulo desktop para o TaxiGO</description> </information> <resources> <j2se version= 1.5+ /> <jar href= TaxiGOManager.jar /> <jar href= lib/jersey-client-1.5.jar /> <jar href= lib/jersey-core-1.5.jar /> </resources> <application-desc main-class= br.com.mundoj.manager.view.main /> <security> <all-permissions /> </security> </jnlp> Listagem 11. Listando as corridas pendentes. public List<Corrida> getcorridas(){ List<Corrida> corridaslist = null; try { Corrida[] corridas = corridaresource.path( corrida ). path( pendentes ).accept(mediatype.application_xml). get(corrida[].class); corridaslist = Arrays.asList(corridas); catch (Exception e) { return corridaslist; com.sun.jersey.api.client, fornece métodos como get e put, para enviar ou recuperar informações. A API cliente REST recupera as informações e converte o XML recebido em uma instância de uma classe. Como estamos recuperando um array de Corrida (Corrida[]), no caso do método get, devemos informar para que tipo será convertida as informações do XML no parâmetro da chamada. E o JavaFX? JavaFX é um plataforma de software multimídia, baseada em Java, para a criação e disponibilização de RIA (Rich Internet Applications), que pode ser executada em vários dispositivos diferentes qualquer dispositivo que rode JRE ou JME pode rodar aplicativos criados com JavaFX. Para o desenvolvimento das aplicações utiliza-se uma linguagem tipada estática, o JavaFX Script, orientada a objetos e com uma sintaxe simples. Através do JFX é possível acessar as APIs do Swing e do AWT de forma fácil para construir interfaces ricas. Apesar de parecer uma evolução natural, utilizar JavaFX para a aplicação desktop ou móvel não pareceu a melhor alternativa. O JavaFX hoje ainda é pouco utilizado, mesmo se mostrando tão promissor. Após a compra da Sun pela Oracle, teve-se a impressão de que a morte do JavaFX era apenas questão de tempo. Algumas notas no site do JavaFX dão a entender que a linguagem será toda reestruturada, e o que vir a ser feito em uma possível versão do JavaFX 2.0 não será compatível com o Java- FX Script atual. Em vista dessa indecisão sobre o futuro da plataforma, não utilizar o JavaFX tanto na aplicação desktop quanto na aplicação móbile mostrou-se a opção mais coerente. Considerações finais Neste artigo, passamos pelas atuais plataformas do Java, desde o pioneiro Desktop até a plataforma Android, destinada aos dispositivos smartphones, passando pela plataforma web que hoje em dia é o foco de muitas tecnologias. Detalhes de cada plataforma foram abordados a fim de mostrar suas particularidades. A tecnologia Java evolui cada vez mais ao longo do tempo desde o seu lançamento, e hoje em dia vimos que é mais fácil e prático construir aplicações mesmo que possuam detalhes de certa complexidade. Essas complexidades são absorvidas pela própria plataforma, e isto a torna uma tecnologia completa, robusta e confiável. Figura 7. Gerenciador de corridas desktop. Não houve grandes mudanças na forma com que uma aplicação desktop é desenvolvida com Java. Como vimos, tirando a parte que acessa o WebService REST, esta aplicação poderia ter sido escrita da mesma forma em Referências 23