Desenvolvendo aplicações corporativas

Click here to load reader

  • date post

    03-Jul-2015
  • Category

    Documents

  • view

    377
  • download

    1

Embed Size (px)

Transcript of Desenvolvendo aplicações corporativas

UNIVERSIDADE TECNOLGICA FEDERAL DO PARAN DEPARTAMENTO ACADMICO DE INFORMTICA ESPECIALIZAO EM TECNOLOGIA JAVA

ALESSANDER FECCHIO

JAVA EE 5: DESENVOLVENDO APLICAES CORPORATIVAS

CURITIBA 2006

UNIVERSIDADE TECNOLGICA FEDERAL DO PARAN DEPARTAMENTO ACADMICO DE INFORMTICA ESPECIALIZAO EM TECNOLOGIA JAVA

ALESSANDER FECCHIO

JAVA EE 5: DESENVOLVENDO APLICAES CORPORATIVAS

Trabalho apresentado como requisito para a obteno de ttulo de especialista em tecnologia Java, da Universidade Tecnolgica Federal do Paran. Orientadora: Prof. Ana Cristina B. Kochem Vendramin.

CURITIBA 2006

SUMRIO1 Introduo.................................................................................................................................. 8 2 O Java........................................................................................................................................ 9 2.1 Uma breve histria do Java..................................................................................................9 2.2 Nomenclatura e versionamento do Java ..............................................................................12 2.3 Conceitos fundamentais da estrutura da plataforma Java .....................................................13 2.3.1 Java uma linguagem interpretada.............................................................................14 2.3.2 Edies do Java .........................................................................................................15 3 Viso geral do Java EE.............................................................................................................. 17 3.1 Modelo de desenvolvimento do Java EE.............................................................................17 3.2 Componentes Java EE.......................................................................................................18 3.2.1 Clientes Java EE........................................................................................................19 3.2.2 Componentes web.....................................................................................................19 3.2.3 Componentes de negcios.......................................................................................... 19 3.2.4 Outros componentes..................................................................................................19 3.3 Containers Java EE...........................................................................................................20 4 Tecnologias empregadas...........................................................................................................22 4.1 Ambiente de desenvolvimento integrado.............................................................................22 4.1.1 Utilizao de recursos do sistema...............................................................................23 4.1.2 Aproveitamento do cdigo j desenvolvido................................................................... 23 4.1.3 Adequao do IDE ao tipo de aplicao a ser desenvolvida..........................................24 4.1.4 Controle de verses...................................................................................................24 4.2 Servidor de aplicaes.......................................................................................................24 4.3 MVC.................................................................................................................................25 4.4 Banco de dados.................................................................................................................27 4.4.1 MySql........................................................................................................................27 4.4.2 PostgreSQL...............................................................................................................28 4.4.3 Derby........................................................................................................................29 5 Uma Aplicao prtica da tecnologia Java EE.............................................................................30 5.1 Ambiente de desenvolvimento............................................................................................31 5.1.1 Pr-requisitos.............................................................................................................31 5.1.2 Instalao dos software..............................................................................................31 5.2 Integrao do NetBeans com o SJSAS...............................................................................32 5.3 Criao do banco de dados................................................................................................34 5.3.1 Conceitos sobre acesso a bancos de dados no Java....................................................37 5.4 Configurao do SJSAS.....................................................................................................43 6 Enterprise Java Beans...............................................................................................................46 6.1 Beans...............................................................................................................................47 6.2 Session beans...................................................................................................................47 6.2.1 Statefull beans...........................................................................................................47 6.2.2 Stateless beans.......................................................................................................... 48 6.3 Interfaces..........................................................................................................................48 6.4 Anotaes.........................................................................................................................49 6.5 Container para aplicaes cliente.......................................................................................49 6.6 Java Web Start..................................................................................................................50 6.7 Contexto...........................................................................................................................50 6.8 Tipos de arquivo ................................................................................................................51 6.9 Persistncia de dados........................................................................................................51 6.10 Facades..........................................................................................................................52 7 Uma aplicao simples..............................................................................................................53 7.1 Session bean..................................................................................................................... 53 7.2 Interfaces..........................................................................................................................53 7.3 Aplicao cliente................................................................................................................54 7.4 Construo da aplicao com o NetBeans..........................................................................55 7.4.1 Criao de um projeto................................................................................................56 7.4.2 Criao do bean.........................................................................................................57 7.4.3 Programao do bean e das interfaces........................................................................58 7.4.4 Programao da aplicao cliente...............................................................................58

7.4.5 Deploy da aplicao...................................................................................................60 7.4.6 Execuo do cliente...................................................................................................61 8 Prova de Conceito - uma aplicao completa..............................................................................62 8.1 Projeto..............................................................................................................................62 8.1.1 Diagrama de casos de uso.......................................................................................... 63 8.1.2 Diagrama de seqncia..............................................................................................63 8.2 Arquivos de configurao...................................................................................................64 8.3 Mdulo EJB.......................................................................................................................65 8.3.1 Criao dos entity beans............................................................................................. 65 8.3.2 Entidade....................................................................................................................69 8.3.3 Entidades para chaves primrias.................................................................................71 8.3.4 Criao dos session beans.........................................................................................72 8.3.5 Persistncia...............................................................................................................74 8.3.6 Interfaces................................................................................................................... 75 8.4 Completando a aplicao EJB............................................................................................76 8.5 Acesso aos EJB num cliente desktop..................................................................................77 8.5.1 Listagem....................................................................................................................77 8.5.2 Incluso.....................................................................................................................77 8.5.3 Pesquisa.................................................................................................................... 78 8.5.4 Atualizao................................................................................................................78 8.5.5 Excluso....................................................................................................................79 8.5.6 Criao de usurios.................................................................................................... 79 8.6 Acesso ao EJB numa aplicao web...................................................................................80 8.7 Documentao..................................................................................................................83 9 Concluso................................................................................................................................87 Referncias.................................................................................................................................89 Apndice A - Script para criao das tabelas no banco de dados....................................................91 Apndice B - Mdulo EJB.............................................................................................................93 Apndice C - Mdulo cliente desktop........................................................................................... 113 Apndice D - Mdulo aplicativo web............................................................................................119

LISTA DE FIGURASFigura 1: O aparelho Star 7 [JAVA NET]......................................................................................... 9 Figura 2: Verses de Duke - o mascote Java [JAVA NET]..............................................................10 Figura 3: Esquema bsico de programao, compilao e execuo de um programa.....................15 Figura 4: Edies do Java e suas mquinas virtuais.......................................................................16 Figura 5: Diagrama das camadas do Java EE................................................................................18 Figura 6: Tipos de container do Java EE 5 [BALL 2006].................................................................21 Figura 7: Inicializao do SJSAS a partir do NetBeans...................................................................32 Figura 8: Mensagem de inicializao do Java DB...........................................................................33 Figura 9: Mensagem de inicializao do SJSAS.............................................................................33 Figura 10: Mensagem indicando que o SJSAS foi iniciado..............................................................33 Figura 11: Tela principal do ASADMIN..........................................................................................34 Figura 12: Menu para iniciar e parar o Java DB..............................................................................35 Figura 13: Mensagem de incio do Java DB...................................................................................35 Figura 14: Configuraes do banco de dados Maxigroupware......................................................... 35 Figura 15: Nova conexo criada....................................................................................................36 Figura 16: Componentes disponveis na conexo com o banco de dados........................................36 Figura 17: Mensagens de criao das tabelas................................................................................ 37 Figura 18: Step 1 of 2 - Criao do pool de conexes.....................................................................41 Figura 19: Step 2 of 2 - Propriedades do pool de conexes............................................................41 Figura 20: Novo pool criado..........................................................................................................42 Figura 21: Criao de um recurso JDBC........................................................................................42 Figura 22: Recurso JDBC criado...................................................................................................43 Figura 23: Alterao da porta padro do container web..................................................................45 Figura 24: Acesso de um bean por um cliente remoto....................................................................48 Figura 25: Criao de uma aplicao Enterprise no NetBeans........................................................56 Figura 26: Mdulos criados pelo assistente Enterprise Application..................................................57 Figura 27: Criao de um session bean no NetBeans.....................................................................57 Figura 28: Programas criados pelo assistente de session beans.....................................................58 Figura 29: Atualizao das interfaces............................................................................................58 Figura 30: Criao de uma classe Java simples.............................................................................59 Figura 31: Criao de uma nova classe Java .................................................................................59 Figura 32: Nova classe criada.......................................................................................................60 Figura 33: Diagrama de casos de uso..........................................................................................63 Figura 34: Diagrama de seqncia................................................................................................63 Figura 35: Arquivos de configurao da aplicao enterprise..........................................................64 Figura 36: Criao de entidades a partir do banco de dados...........................................................65 Figura 37: Escolha do datasource e das tabelas para criao das entidades...................................66 Figura 38: Nomenclatura e empacotamento das entidades.............................................................67 Figura 39: Criao da persistence unit...........................................................................................67 Figura 40: Entidade criadas no projeto ..........................................................................................68 Figura 41: Entidades criadas no projeto.........................................................................................69 Figura 42: Criao de session beans.............................................................................................72 Figura 43: Assistente para criao de session beans...................................................................... 73 Figura 44: Empacotamento e escolha das interfaces a serem criadas.............................................73 Figura 45: Session bean e interface criados...................................................................................74 Figura 46: Regras de navegao da aplicao web........................................................................81 Figura 47: Acesso ferramenta AutoComment..............................................................................84 Figura 48: Ferramenta AutoComment............................................................................................84 Figura 49: Gerao da documentao...........................................................................................85 Figura 50: Mensagem de sucesso ao gerar a documentao..........................................................85 Figura 51: Pgina inicial da documentao....................................................................................86

LISTA DE SIGLASAPI CRUD CVS DBCP EAR EJB GCS GPL GUI HTML IDE J2EE J2ME J2SE JAR Java EE 5 JCE JDBC JDK JFC JMS JNDI JPA JSF JSP JVM JWS LCD MVC PCMCIA PDA SJSAS UML WAR WSDP Application Programming Interface Create, Recover, Update, Delete Concurrent Version System Database Connection Pool Enterprise Archive Enterprise Java Beans Gerncia de Configurao de Software General Public License Graphic User Interface Hyper Text Meta Language Integrated Development Environment Java 2 Enterprise Edition Java 2 Micro Edition Java 2 Standard Edition Java Archive Java Enterprise Edition 5 Java Cryptography Extension Java Database Connectivity Java Development Kit Java Foundation Classes Java Message Service Java Naming and Directory Java Persistence API Java Server Faces Anncio da tecnologia Java Server Pages Java Virtual Machine Java Web Start Liquid Crystal Display Model-View-Controller Personal Computer Memory Card International Association Personal Digital Assistant Sun Java System Application Server Unified Modeling Language Web Archive Java Web Services Developer Pack

RESUMO

O desenvolvimento de aplicaes corporativas utilizando a verso enterprise do Java sempre foi considerada de grande complexidade, entre outros motivos pela grande quantidade e pela extenso de seus arquivos de configurao. Uma vez que a especificao Java deixa em aberto a possibilidade de cada fornecedor implementar suas prprias caractersticas aos servidores de aplicao, os arquivos de configurao acabam por no seguir um padro. A verso enterprise do Java, chamada de Java EE 5, tem por objetivo simplificar o desenvolvimento de aplicaes e abstrair os desenvolvedores da complexa configurao dos servidores. O objetivo deste trabalho demonstrar a utilizao da tecnologia Java EE 5 para o desenvolvimento de aplicaes corporativas. O documento inclui demonstraes de uso dos principais tpicos relacionados tecnologia, como persistncia de dados, EJB, aplicaes cliente desktop e web, bem como a utilizao de servidores de aplicao Java. Com isto, espera-se desmitificar a idia de que o desenvolvimento em Java EE 5 uma tarefa rdua mesmo para desenvolvedores experientes.

Palavras-chave: Java, EJB, enterprise, persistncia de dados, servidor de aplicaes.

8

1 INTRODUO O Java considerado como um dos maiores fenmenos da informtica em todos os tempos, pela velocidade com que novos recursos so criados e disponibilizados para a comunidade de desenvolvedores e usurios. Nascida inicialmente como uma linguagem de programao para atender a um nicho de mercado, o Java hoje utilizado em aplicativos de todos os tipos, e tambm embarcado em milhares de aparelhos ao redor do mundo. possvel encontr-lo em pequenos aplicativos ou utilitrios, complexos sistemas corporativos , ou em processadores de computadores de bordo de automveis, por causa de sua fantstica flexibilidade. Esta flexibilidade peculiar linguagem fez com que ela se desenvolvesse muito rapidamente, gerando outras tecnologias dela dependentes, como por exemplo os servidores de aplicao. Se por um lado esta gama de tecnologias ajudou a resolver problemas dos mais diversos, por outro lado criou duas dificuldades aos profissionais de informtica: a escolha da melhor tecnologia a ser adotada, e no caso de escolher mais de uma, como integr-las da maneira mais eficaz. As questes inerentes integrao destes componentes no so fceis de responder. Muitas empresas, pelos mais diversos motivos, optam por utilizar apenas uma tecnologia para desenvolver toda sua aplicao. Mas nem sempre isto possvel num cenrio onde se desenvolvem aplicaes que precisam ser executas em ambientes distintos, como web , estaes de trabalho e dispositivos mveis. Tem-se ento o problema da interoperabilidade. Apesar da padronizao Java ser muito rgida, e de tecnologias especficas para um ambiente (como o desktop, tambm chamado de estao de trabalho) serem capazes de se comunicar com outras (como a internet), nem sempre a comunicao simples. O objetivo deste trabalho demonstrar como estas tecnologias podem ser integradas, fornecendo maneiras de criar um ambiente robusto, gil e seguro para a disponibilizao de aplicaes corporativas.

9

2 O JAVA

2.1 UMA BREVE HISTRIA DO JAVA O ano era 1991. O local, um pequeno escritrio localizado na rua Sand Hill Road, em Menlo Park. L, um grupo de treze pessoas liderado por James Gosling, Patrick Naughton e Mike Sheridan isolou-se da Sun Microsystems e trabalhou arduamente num projeto secreto conhecido apenas pelo codinome Green Project [JAVA]. O grupo, conhecido por Green Team, tinha a funo de antecipar e planejar o que estava por vir na rea da computao. Eles acreditavam que um ponto importante nesta evoluo seria a convergncia entre computadores e dispositivos pessoais comuns (como geladeiras, por exemplo). O resultado apareceu dezoito meses depois, na forma de um controlador de dispositivos (uma espcie de controle remoto), atravs do qual um usurio poderia controlar sua geladeira, sua torradeira, sua TV a cabo, e quaisquer dispositivos prontos para a tecnologia. Conforme ilustra a Figura 1, o aparelho desenvolvido, conhecido como *7 (Star 7), era uma handheld wireless, utilizando um processador SPARC, com tela Liquid Crystal Display (LCD) colorida de 5 polegadas touchscreen, rede de 900 MHz, Personal Computer Memory Card International Association (PCMCIA), codecs de udio e vdeo. O aparelho tinha um novo gerenciamento de energia e, para controlar tudo isso, uma verso do UNIX era executada em menos de 1 MB de RAM inclusive os drivers [JAVA NET].

Figura 1: O aparelho Star 7 [JAVA NET]

10 Segundo os responsveis pelo projeto, o Star 7 tambm possua...a new small, safe, secure, distributed, robust, interpreted, garbage collected, multi-threaded, architecture neutral, high performance, dynamic programming language... [JAVA NET]

Ou, numa traduo livre:...uma linguagem de programao pequena, segura, distribuda, robusta, interpretada, com memria auto-gerenciada, multi-threaded, de arquitetura neutra, de alto desempenho e dinmica...

Esta linguagem foi batizada de Oak (carvalho, em ingls) - uma rvore que James Gosling podia ver de sua janela, enquanto trabalhava. Um segundo produto nasceu daquela equipe: um cartoon, criado e desenhado por Joe Palrang, chamado Duke (ver Figura 2). Duke era o assistente utilizado para o Star 7, e sua funo era ensinar o usurio a utilizar os recursos do equipamento. Com o fim do produto e o tempo passando, acabou se transformando no mundialmente mascote Java [JAVA NET].

Figura 2: Verses de Duke - o mascote Java [JAVA NET]

O Star 7 carecia de um nicho de mercado onde poderia ser inserido. Inicialmente, a equipe pensou que uma boa idia seria controlar vdeo sob demanda atravs da TV a cabo e para isso, chegou a construir um prottipo. O grande problema era que a indstria de TV a cabo no tinha como oferecer o que o Star 7 podia controlar. Nem mesmo infraestrutura existia e seria carssimo para que apenas um grupo de empresas a construsse. Ironicamente, o vdeo sob demanda e o controle da televiso digital hoje uma realidade no mundo, e tanto a Oak como o Star 7 estavam fadados ao desaparecimento. Entretanto, um fato viria a mudar este aparente fracasso para uma das mais estrondosas vitrias do mundo da informtica: a internet. A rpida evoluo da internet fez com que uma imensa infraestrutura de

telecomunicaes e transmisso de dados fosse disponibilizada, calcada inicialmente na malha de cabos e fios das empresas de telecomunicaes. A infraestrutura que declarou o fim do Star 7, repentinamente fora criada.

11 James Gosling, foi novamente incumbido de um projeto, dessa vez de preparar a Oak para a internet. Em 1995, ele conclui seu trabalho, lanando uma nova verso do Oak , rebatizada de Java [WIRED]. Java foi inteiramente desenvolvida para atuar em ambientes heterogneos, como o da internet. Assim, Java poderia ser executado diretamente nos browsers (navegadores de internet), na forma de applets1 . Os browsers, que antes eram limitados a um contedo esttico, podiam agora exibir tambm contedo dinmico. Isso fez com que o Java crescesse como nenhuma outra linguagem de programao cresceu na histria da informtica, rapidamente sendo alado categoria de plataforma [WIKIPEDIA 01]. Dez anos depois, no s a linguagem, mas toda a plataforma evoluiu muito, e alguns nmeros bem interessantes podem mostrar este crescimento [JAVA 01]:

4 milhes de desenvolvedores ao redor do mundo; mais de 700 milhes de computadores; mais de 700 milhes de celulares e outros dispositivos; mais de 1 bilho de smart cards; impressoras, web cams, jogos, sistemas de navegao de automveis e muitos outros.

Hoje, o Java pode ser encontrado na internet, em computadores, laptops e telefones celulares, e em equipamentos onde as pessoas nem imaginam, como geladeiras, fornos de microondas e cartes de crdito. A linha do tempo da Tabela 1 demonstra sua evoluo. Ano 1991 1992 1994 Fato

Lanamento do Green Project Lanamento da linguagem Oak, do Star7 e do Duke Lanamento do WebRunner, o primeiro navegador a suportar contedo dinmico

1995

Nascimento do Java. Pai: James Gosling. Me: Sun Microsystems; Anncio oficial na SunWorld. Lanamento do Java Development Kit (JDK) 1.0; Primeira JavaOne (conferncia de desenvolvedores); JavaBeans , Servlets e outras tecnologias anunciadas; Application Programming Interface (API) Java Card anunciada.

1996

1

Um applet um programa escrito em Java, embutido numa pgina web (dinmica ou esttica), que executado na JVM da estao cliente.

12 Ano 1997 Fato

Lanamento do JDK 1.1; Lanamento do Java Servlet Developers Kit; Anncio da tecnologia Enterprise Java Beans (EJB); Incluso da tecnologia Java Foundation Classes (JFC) na plataforma Java. Anncio das JFC/"Project Swing"; Visa lana o primeiro smart card com tecnologia Java Card; Lanamento do Java 2 para Linux; Lanamento da plataforma Java 2. Liberao do cdigo fonte da plataforma Java 2; Anncio da tecnologia Java Server Pages (JSP); Diviso oficial da plataforma Java 3 edies: Java 2 Standard Edition (J2SE), Java 2 Enterprise Edition (J2EE), Java 2 Micro Edition (J2ME);

1998

1999

Liberao da plataforma J2EE; Liberao da plataforma J2SE para Linux. Liberao da plataforma J2SE 1.3; Liberao da plataforma J2SE 1.3 para Apple Mac OS X. Liberao da Java Web Start 1.0. Lanamento do JDK 1.4; Lanamento do Java Web Services Developer Pack (WSDP); Lanamento da J2EE 1.4 Beta. Lanamento do Java 5.0. Java 10 aniversrio; Aproximadamente 4,5 milhes de desenvolvedores utilizam Java. Lanamento do Java Enterprise Edition 5 (Java EE 5), nova verso do J2EE

2000

2001 2002

2004 2005

2006

Tabela 1: Evoluo da plataforma Java. [JAVA 02]

2.2 NOMENCLATURA E VERSIONAMENTO DO JAVA Como possvel notar na Tabela 1, com o lanamento da verso 5 do Java, houve uma grande mudana em sua nomenclatura, e a compreenso destes nomes e acrnimos torna-se necessria para o completo entendimento da estrutura do Java.

13 As edies do Java (discutidas na seo 2.3.2) foram lanadas em 1999, pouco tempo depois do lanamento do Java 2. O prprio nome Java 2 na realidade no se refere verso 2 do Java, e sim verso 1.2. Esta estranha alterao de nome foi feita como uma jogada de marketing, para mostrar que a linguagem havia sido radicalmente alterada, da sintaxe de alguns comandos at a estrutura interna da Java Virtual Machine (JVM). Assim, havia o JDK 1.2 e o JRE 1.2 que eram a base do Java 2. Esta diferena entre a verso do software e a verso da linguagem gerava muita confuso. Em 2004, o Java 5 foi lanado, e com ele o novo padro de nomenclatura, desta vez bem simplificado. A comunidade pde participar da definio da nomenclatura, e junto com o departamento de marketing da Sun, chegaram concluso que o melhor caminho para a simplificao seria simples: tirar o 2 e expandir o acrnimo. No existe Java 3 e nem o Java 4. A verso passou diretamente da verso 2 para a 5. O motivo simples: existe um nmero de verso utilizado internamente pela Sun e existe o nome comercial. A verso utilizada internamente pela Sun atualmente a 1.5. Para sincronizar a verso interna com a verso comercial, optou-se por retirar a expresso "1." da verso comercial, gerando assim o Java 5. Oficialmente, a partir de junho de 2005, a nova nomenclatura foi adotada, sendo que de imediato, as seguintes alteraes foram realizadas:

J2SE 6.0 foi chamado de Java SE 6 e J2SE 7.0 ser chamado de Java SE 7, quando lanado;

J2EE 5.0 foi chamado de Java EE 5; J2ME foi chamado de Java ME, pois no tem um nmero de verso.

Outro ponto importante do versionamento que verses intermedirias do software no mais sero lanadas, somente sero disponibilizadas verses para correo de erros. Novos recursos e implementaes sero sempre lanadas com as verses principais (Java 6, etc).

2.3 CONCEITOS FUNDAMENTAIS DA ESTRUTURA DA PLATAFORMA JAVA Para se entender a plataforma Java, necessrio primeiro conhecer sua estrutura. Por definio, plataforma um ambiente de hardware ou software no qual um programa executado [JAVA 03]. Java uma plataforma apenas de software, sendo executada numa outra plataforma, composta de hardware e software (o sistema operacional, dependente do hardware onde executado).

14 A plataforma Java composta de duas partes:

A JVM, responsvel pela execuo dos programas; A Java API, conjunto de classes responsveis por prover os mais diversos recursos, como acessar bancos de dados.

2.3.1 Java uma linguagem interpretada O Java segue a filosofia Write Once, Run Everywhere (Escreva uma vez, execute em todos os lugares). Um programa escrito em Java puro pode ser executado em todas as plataformas disponveis, do desktop ao mainframe. Para que seja executado em todas as plataformas, o programa Java depende da JVM, ou seja, Java uma linguagem interpretada. O diferencial para as linguagens interpretadas mais conhecidas (como o antigo BASIC), que a VM no interpreta o programa original. Ao ser compilado, um programa Java gera um cdigo intermedirio, que no um programa fonte, nem um executvel. Este cdigo intermedirio chamado de byte code que pode ser interpretado pela VM [JAVA 03]. Como a execuo do byte code depende apenas da VM, qualquer sistema operacional que tenha uma VM pode execut-lo sem precisar ser reescrito. Por isto, Java considerado multi plataforma. O processo pode ser melhor compreendido atravs da Figura 3.

15

Figura 3: Esquema bsico de programao, compilao e execuo de um programa

O fato de ser interpretado, fez com que o Java fosse conhecido como uma linguagem lenta, de baixo desempenho. Atualmente, os avanos da informtica e o empenho dos especialistas da Sun em otimizar este componente conseguiram tornar o Java quase to rpido quanto o C++, embora essa afirmao seja fonte de muitas discusses em listas e fruns na internet. Existem trs tipos de VM:

Java Card VM, utilizada em smart cards [JAVA CARD]; KVM, utilizada em dispositivos mveis como celulares e Personal Digital Assistant (PDA) [KVM];

JVM, utilizada em computadores e alguns tipos de dispositivos mveis [JVM].

Cada uma das VMs tem como base uma tecnologia diferenciada, formada por uma ou mais API. Por exemplo: a KVM utiliza a API para dispositivos mveis.

2.3.2 Edies do Java Uma edio do Java uma verso da plataforma que contm os recursos necessrios para atender um determinado segmento do mercado. Cada edio formada por dois conjuntos de API. Um deles chamada de core, sendo o conjunto de bibliotecas que deve ser suportada por todas as implementao compatveis com a edio. O outro opcional, sendo fornecido com a edio, e

16 pode ou no ser implementado por uma edio compatvel. Opcionalmente, os pacotes adicionais podem se tornar parte do core, se houver demanda do mercado. O objetivo que as classes que pertencem ao core estejam disponveis em todos os sistemas operacionais que possam executar o Java. Portanto, se um programa utiliza apenas as classes do core, ele 100% portvel, podendo ser executado em qualquer plataforma. Existem trs edies do Java:

Java ME: utilizada em dispositivos mveis, normalmente com pequeno poder de processamento, como celulares, PDAs e impressoras, entre outros. Oferece funcionalidades que vo desde criar interfaces simples at protocolos complexos de rede, passando por um robusto modelo de segurana [JAVA ME];

Java SE: utilizada para desenvolver e distribuir aplicativos em desktops e servidores. Com ela tambm possvel desenvolver software embarcado e para ambientes de real-time. Alm disso, contm a base para o Java EE [JAVA SE];

Java EE: utilizada para o desenvolvimento de aplicaes corporativas, de grande porte, executadas num servidor. formada pelo Java SE e um conjunto de bibliotecas complementares, e prov servios como web services, modelos de componentes, API para gerenciamento e mensagens, entre outros recursos. a edio utilizada para o desenvolvimento deste trabalho [JAVA EE].

A Figura 4 demonstra as edies do Java, e a JVM utilizada por cada uma delas.

Figura 4: Edies do Java e suas mquinas virtuais

17

3 VISO GERAL DO JAVA EE O Java EE a edio mais abrangente do Java, pois engloba todas as tecnologias para desenvolvimento em ambientes de servidor e desktop. No desenvolvimento deste trabalho, utilizado o Java EE 5, nova verso da plataforma corporativa do Java. O grande objetivo dessa verso simplificar o desenvolvimento de aplicaes corporativas, sem entretanto alterar os recursos disponveis na verso 1.4. As principais alteraes do Java EE 5 em relao a sua verso anterior so [JAVA EE]:

Uso de annotations (anotaes), que insere grande parte das configuraes da aplicao dentro do prprio cdigo;

A verso 3.0 do EJB foi bastante simplificada; Java Server Faces (JSF), um poderoso framework que possibilita o uso de componentes similares aos de Graphic User Interface (GUI) em aplicaes web;

Tecnologia de web services simplificada; Java Persistence API, uma camada de persistncia objeto-relacional que pode ser utilizada tambm fora do contexto Java EE 5.

3.1 MODELO DE DESENVOLVIMENTO DO JAVA EE O Java EE utiliza um modelo de mltiplas camadas para aplicaes corporativas. Uma aplicao dividida em componentes de acordo com sua funo, e os componentes podem ser instalados em vrios servidores, de acordo com a camada:

Componentes da camada cliente so executados na estao cliente; Componentes da camada web so executados no servidor Java EE; Componentes da camada de negcios so executados no servidor Java EE; Componentes da camada de sistemas de informao (normalmente um banco de dados) so executados num servidor prprio.

A Figura 5 mostra um diagrama das camadas do Java [BALL 2006].

18

Figura 5: Diagrama das camadas do Java EE

3.2 COMPONENTES JAVA EE Aplicaes Java EE so formadas por componentes. Componentes so unidades de software funcionais e independentes, cujas classes e arquivos se comunicam com outros componentes. A especificao Java define trs componentes [BALL 2006]:

Clientes Java EE; Java Servlets e JSP, que so componentes web da aplicao; Enterprise Java Beans, que so componentes de negcios.

Cada um destes componentes pode acessar qualquer tecnologia Java disponvel no servidor Java EE (ou em um container, se for o caso). Uma descrio dos trs componentes apresentada a seguir.

3.2.1 Clientes Java EE Os clientes Java EE so executados na estao de trabalho, e so divididos em dois tipos:

19

Aplicaes desktop, que podem ter uma GUI ou uma interface por linha de comando. Podem interagir com os componentes de negcio, acessando-os direta ou indiretamente (por meio de conexes HTTP);

Um conjunto de navegador web e applet.

3.2.2 Componentes web Os componentes web so executados no servidor (que pode ser um servidor Java EE ou simplesmente um container JSP). H dois tipos de componentes web:

Java Servlets: classes que recebem uma requisio e a processam dinamicamente, gerando contedo HTML como sada;

JSP: documentos texto plano, que so executados no servidor.

3.2.3 Componentes de negcios Os componentes de negcio so executados no servidor Java EE, e contm as regras de negcio da aplicao. Entre outras funes, acessam bancos de dados, processam dados e os reenviam, para os clientes ou para o prprio banco de dados. So os Enterprise Java Beans.

3.2.4 Outros componentes Existe ainda um outro tipo de componente, chamado Java Bean, que no considerado um componente Java EE. Normalmente eles so utilizados para controlar o fluxo de dados entre uma aplicao cliente e os componentes no servidor. Java Beans possuem propriedades e mtodos get e set para acess-los. Utilizados desta maneira, so fceis de implementar, mas devem seguir a especificao Java quanto nomenclatura utilizada.

3.3 CONTAINERS JAVA EE Cada tecnologia disponvel no servidor Java EE deve ser executada em um container. Um container um pequeno servidor dentro do servidor Java EE, especializado em um determinado servio. Por extenso, um servidor Java EE pode ser considerado um conjunto de containeres. O mais famoso exemplo de container o Tomcat, muitas vezes chamado de servidor JSP [TOMCAT]. Na realidade, ele um container responsvel pela execuo de Servlets e JSP. Ficou to conhecido como servidor por ser um bom substituto aos tradicionais servidores Java EE,

20 complexos de administrar e grandes consumidores de recursos de hardware. Ele tornou-se o padro de fato em containeres JSP, sendo utilizado atualmente por grande parte dos servidores Java EE do mercado. Quando uma aplicao desenvolvida, seus mdulos devem ser empacotados e distribudos para seus respectivos containeres. Empacotamento o processo pelo qual todos os programas, bibliotecas e arquivos de configurao so colocados num nico arquivo compactado chamado package [BALL 2006]. Uma das funes do servidor Java EE receber o pacote e distribuir cada mdulo para seu respectivo container. Uma vez que o container dependente do servidor Java EE e no da aplicao, um componente pode se comportar de maneiras diferentes, de acordo com a configurao do container. Um exemplo: um EJB distribudo para um servidor Java EE de testes e tambm para um de produo. Com os servidores configurados para acessar bancos de dados diferentes, o EJB acessaria diferentes informaes, sem que precisasse ser alterado. Os tipos de container do Java EE so (ver Figura 6):

Container EJB: executa os EJB. O container, por sua vez, executado dentro do servidor Java EE;

Container web: executa JSP e servlets. executado dentro do servidor Java EE; Container da aplicao cliente: executado na estao cliente, e responsvel pela execuo de aplicaes desktop;

Container applet: executa os applets carregados em navegadores web, na estao cliente. Normalmente, formado pelo navegador e um plugin Java.

21

Figura 6: Tipos de container do Java EE 5 [BALL 2006]

22

4 TECNOLOGIAS EMPREGADAS O que mostrado a partir deste ponto uma prova de tecnologia utilizando os principais recursos da plataforma Java EE de maneira integrada. O foco no a linguagem de programao em si, embora em alguns momentos a discusso de alguns pontos seja necessria. O objetivo principal demonstrar como realizar a integrao entre componentes distribudos por plataformas to diferentes , como o desktop e um container EJB. A seguir, so discutidos todas as tecnologias e software necessrios aplicao, e os motivos pelos quais so utilizados neste trabalho.

4.1 AMBIENTE DE DESENVOLVIMENTO INTEGRADO Todo desenvolvedor tem preferncia por algum Integrated Development Environment (IDE), seja porque consome menos memria, possui mais recursos, ou porque geram

automaticamente quase a totalidade do cdigo. Tambm existem desenvolvedores que no utilizam IDEs, preferindo editores mais simples, que normalmente no geram cdigo automaticamente. IDE um aplicativo que agrega vrias ferramentas com o nico objetivo de desenvolver software . A maioria dos IDE possui ferramentas que permitem:

Editar o cdigo fonte e format-lo dentro de padres prprios ou definidos pelo usurio;

Automatizar tarefas repetitivas, como gerar os pacotes de distribuio da aplicao; Compilar, executar, testar e depurar o cdigo; Navegar pela estrutura do projeto; Verificar erros de digitao e possveis erros de compilao, propondo solues alternativas;

Integrar-se com ferramentas externas, como versionadores, servidores de aplicao e utilitrios de construo e distribuio;

Refactoring (propagao das alteraes efetuadas em um componente para todas as suas ocorrncias no projeto por exemplo, renomear uma classe);

Auditoria e otimizao do cdigo, para garantir a aderncia a padres e convenes de mercado;

23

Suporte a plugins (extenses), componentes normalmente desenvolvidos por terceiros, que podem adicionar funcionalidades ainda no existentes no IDE.

O processo de escolha de um IDE no deve considerar apenas os aspectos tcnicos. Um ferramenta, apesar de ser tecnicamente a melhor, pode no ser a mais adequada ao trabalho desenvolvido. So comuns os casos de desenvolvedores que utilizam mais de um IDE, cada qual com caractersticas nicas. Alm das especificaes tcnicas, algumas caractersticas operacionais tambm devem ser analisadas. Algumas delas so listadas a seguir.

4.1.1 Utilizao de recursos do sistema O IDE no deve consumir exageradamente os recursos do sistema, como memria. Isso diminui a produtividade, pois desde o acesso aos menus do aplicativo at o processo de compilao o IDE prejudicado com a perda de desempenho.

4.1.2 Aproveitamento do cdigo j desenvolvido Um problema muito comum ao adotar uma nova ferramenta de desenvolvimento que o cdigo desenvolvido com a ferramenta antiga no funciona como esperado no novo IDE. O problema neste caso no o cdigo (que continua sendo executado sem erros), mas a maneira como os IDE geram o cdigo, que nem sempre compreendido por outros IDE. Isto acontece porque cada ferramenta possui um padro de gerao de cdigo. A grande dificuldade em migrar programas de uma ferramenta para outra no est no que se v, e sim no que no se v. Quando um IDE abre uma classe para edio, realiza-se tambm uma srie de verificaes, que vo desde o classpath da aplicao at a busca por erros de compilao e dependncias. Adicionalmente, nos arquivos que possuem um editor grfico (caso das GUI), feito tambm uma anlise da estrutura do programa, que busca identificar como o cdigo fonte pode ser transformado em elementos visuais. Se esta estrutura estiver incorreta, o IDE no a reconhecer, no podendo executar o editor visual, embora o programa seja executado sem problemas. Existe outro fator complicador: muitas vezes, as ferramentas disponibilizam recursos que no so padro no Java. Um bom exemplo so os gerenciados de layout . O SpringLayout , por exemplo, no implementado por nenhum IDE de mercado atualmente. O IDE que mais se aproxima de uma implementao o NetBeans, com o Matisse gerenciador baseado no SpringLayout . Algum que desenvolva uma aplicao utilizando o Matisse no pode edit-la em nenhum IDE que no seja o NetBeans.

24 4.1.3 Adequao do IDE ao tipo de aplicao a ser desenvolvida Ao desenvolver aplicativos para um determinado ambiente, natural que a ferramenta escolhida para seu trabalho deva possuir recursos adequados plataforma. Como exemplo, o IDE Java Studio Creator, da Sun, foi criado especificamente para o desenvolvimento de aplicaes para a internet. Se o foco for desenvolver aplicativos para telefones celulares, o NetBeans oferece grande quantidade de recursos (desde que a extenso apropriada seja instalada). J o principal nicho de utilizao do JDeveloper - a t s u a v e r s o 9 e r a o desenvolvimento de aplicaes corporativas que utilizassem o banco de dados Oracle. Para o desenvolvimento deste trabalho optou-se pela utilizao do IDE NetBeans, na verso 5.5 - projeto de cdigo aberto mantido pela Sun. A escolha se deve ao fato do NetBeans ser compatvel com o tipo de aplicao desenvolvida, sendo um dos nicos com suporte completo ao desenvolvimento de EJB na verso 3.0. Alm de possuir um equilibrado conjunto de ferramentas, como desenvolvimento de diagramas UML e monitoramento de memria. Existe tambm a questo mercadolgica. A Sun a principal patrocinadora do NetBeans, e todas as suas outras ferramentas de desenvolvimento so nele baseados. Precisando popularizar o NetBeans (e conseqentemente seus outros IDE), a Sun une esforos no sentido de dot-lo de recursos visando a facilidade de uso e o baixo consumo de recursos.

4.1.4 Controle de verses Praticamente todos os IDEs de hoje possuem um pequeno gerenciador de verses, o suficiente para desenvolvimento de pequenas aplicaes. Entretanto, quando o desenvolvimento de software feito em grandes equipes, necessrio que o controle de verses seja centralizado. Para isso, utiliza-se aplicativos de Gerncia de Configurao de Software (GCS). desejvel que a ferramenta utilizada possa ser integrada com algum software de GCS. Normalmente isso no considerado um problema, uma vez que praticamente todos os IDEs so compatveis pelo menos com o Concurrent Version System (CVS), um software livre de GCS que est entre os mais utilizados no mundo [SAVANNAH].

4.2 SERVIDOR DE APLICAES Muitas vezes os desenvolvedores se deparam com um dos grandes problemas do desenvolvimento Java: a compatibilidade entre as ferramentas disponveis no mercado. Este problema ainda maior quando se trata de uma tecnologia nova, como o Java EE 5. No pela tecnologia em si, mas pelo suporte que as ferramentas de desenvolvimento do a ela.

25 Como exemplo, possvel citar o servidor de aplicaes. No incio do desenvolvimento deste trabalho, apenas o GlassFish e o Sun Java System Application Server (SJSAS) tinham suporte completo especificao Java EE 5 - e isto porque o SJSAS baseado no GlassFish. Outros servidores so compatveis apenas com alguns dos novos recursos da especificao. A seguir, so apresentados os principais motivos pela escolha do SJSAS para o desenvolvimento deste trabalho [GLASSFISH]:

homologado pela Sun, dando suporte completo especificao Java EE 5; Consome poucos recursos do equipamento onde executado, por no implementar recursos avanados de gerenciamento, como clustering e computao em grade;

Foi desenvolvido especialmente para a verso 5 do Java, tirando proveito de todos os novos recursos da linguagem;

Fcil administrao; gratuito para ambientes de desenvolvimento e produo.

Um dos problemas causados pelo pioneirismo da implementao da especificao que no existe ainda uma grande comunidade de desenvolvedores, de modo que o suporte em caso de problemas nem sempre rpido.

4.3 MVC MVC o acrnimo de Model-View-Controller, uma arquitetura de software que separa as camadas de modelo de dados (Model ), interface com o usurio (View) e lgica de negcio (Controller), de modo que as alteraes em uma camada causem o menor impacto possvel nas outras [SUNONE]. A camada do modelo onde os processamentos so realizados, desde clculos de impostos sobre as vendas at a verificao se uma data vlida. Embora pelo padro MVC no exista uma camada especfica para o acesso ao banco de dados, estas operaes so implicitamente realizadas pela camada do modelo. A camada de visualizao responsvel por transformar as informaes do modelo em componentes visuais, de modo que o usurio possa compreend-las, como uma lista dos filmes melhor avaliados de uma vdeo locadora. Na camada de controle, as aes ordenadas pelo usurio na camada de visualizao so interpretadas pela aplicao, indicando qual ao da camada do modelo deve ser executada.

26 Esta separao garante certa independncia entre as camadas, pois um elemento nunca est presente em duas camadas distintas. Por exemplo, pode-se garantir que uma atualizao no banco de dados seja realizada unicamente na camada de modelo. Desta maneira, no caso de alguma alterao no banco de dados, apenas um ponto da aplicao deve ser alterado. Do mesmo modo, caso uma tela seja alterada na camada de visualizao, ela em nada influencia nas demais camadas. Este padro de arquitetura provocou o surgimento dos frameworks, software construdos para fornecer infraestrutura a outros software. Eles so criados para que os desenvolvedores possam se preocupar com os requisitos da aplicao a ser desenvolvida, e no com a infraestrutura necessria para ele. Por exemplo, numa aplicao de comrcio eletrnico, o desenvolvedor deve estar focado em como um pedido dever ser finalizado, e no em como navegar sem erro entre as pginas deciso tomada pela camada de controle. Ultimamente, o padro MVC tem sido fortemente empregado em aplicativos para a web , onde a complexidade pde desenvolvimento maior que em ambientes cliente-servidor. Por este motivo, vrias implementaes distintas apareceram, inclusive no ambiente Java. Duas delas despontam como as mais utilizadas: Struts (mais antiga e mais utilizada, atuando no nvel de pginas) e JSF (atua no nvel de componentes) [PLUGMASTERS]. O Struts um projeto da Fundao Apache. uma camada de controle MVC baseada unicamente em tecnologias padro Java alm de vrias bibliotecas da famlia Commons. Seu ponto forte o componente de controle, sendo facilmente integrado a outras tecnologias, de modo a prover as camadas de modelo e visualizao. Na camada de modelo, pode interagir com tecnologias como JDBC, EJB e camadas de persistncia como o Hibernate. Sua camada de visualizao pode ser construda utilizando JSP, JSF ou outros frameworks de apresentao [STRUTS]. JSF uma especificao aberta, que pode ser implementada por qualquer pessoa ou empresa. De fato, alm da implementao de referncia da prpria Sun (mantenedora da especificao), a Fundao Apache tambm possui uma implementao chamada MyFaces. Este framework est ganhando muitos adeptos, entre outros motivos por possuir uma configurao mais simplificada que os demais frameworks disponveis hoje. Mas existe outro ponto que o diferencia dos demais. Desde o incio de seu projeto, o objetivo do JSF sempre foi tratar cada parte da aplicao como um componente, que por sua vez atende a todo o modelo de desenvolvimento Java, como por exemplo o tratamento de eventos, que podem ocorrer at mesmo dentro de uma pgina JSP, com a diferena de que este evento disparado no servidor, e no no cliente.

27 Para que os componentes de visualizao (como listas, botes e caixas de texto) pudessem tirar proveito desta caracterstica, eles passaram a ser desenhados no servidor, e no mais pelo navegador web . Todos os componentes do Hyper Text Meta Language (HTML, a linguagem utilizada para se construir pginas da internet) foram substitudos por componentes JSF. Por estas caractersticas, o JSF foi utilizado para o desenvolvimento deste trabalho, utilizando a implementao de referncia da Sun.

4.4 BANCO DE DADOS Atualmente, existem diversos bancos de dados gratuitos e livres disponveis no mercado. Dentre eles, os mais conhecidos so o MySql, o PostgreSQL e mais recentemente o Derby (desenvolvido e mantido pela Fundao Apache). Identificar qual o melhor deles uma tarefa bastante subjetiva, pois possuem caractersticas prprias que os levam a ser mais interessantes para uso em algumas reas, em detrimento de outras.

4.4.1 MySql O MySql um produto desenvolvido pela MySql AB (http://www.mysql.com). Foi criado para satisfazer a necessidade de maior flexibilidade e desempenho para acesso aos dados da empresa, que utilizava o mSQL. Segundo a empresa, o nome MySql no tem origem muito clara. Enquanto alguns dizem que o nome se deve ao fato de que um grande nmero de bibliotecas tinham o prefixo my, outros dizem que uma homenagem filha de um dos fundadores da empresa, Monty Widenius, que se chama My. Assim, a origem real do nome MySql um mistrio para a prpria empresa [MYSQL]. Sem concorrentes de peso no chamado "mundo livre", sua utilizao foi disseminada pelo mundo todo, especialmente durante a expanso da internet (o chamado boom da internet). Entre os motivos para o sucesso do MySql pode-se citar:

o seu alto desempenho; o fato de ser gratuito para utilizao em websites; ser leve, consumindo poucos recursos de processamento e memria dos servidores.

A necessidade de alcanar alto desempenho fez com que muitos recursos tpicos de bancos de dados como transaes e stored procedures fossem deixado de lado em suas primeiras verses, e alguns deles ainda no foram implementados nas verses mais recentes.

28 O MySql licenciado de duas maneiras:

pela General Public License (GPL), se o software desenvolvido tambm utilizar uma licena livre;

pela licena comercial da MySql AB, se o software for liberado por uma licena nolivre ou for obtido lucro com ele.

4.4.2 PostgreSQL O PostgreSQL, inicialmente chamado de Postgres, foi criado na Universidade de Berkley (Califrnia) em 1986, pelo professor Michael Stonebraker, em substituio ao Ingres, banco de dados que na poca foi comprado pela Computer Associates. Postgres tem o significado de "aps o Ingres"). Ele foi desenvolvido pelo professor e seus alunos por oito anos, perodo no qual os principais recursos de bancos de dados relacionais foram incorporados. O Postgres foi ento comercializado e se tornou o Illustra, que foi comprado pela Informix, que por sua vez foi comprado pela IBM [POSTGRESQL]. Em 1995, aps a substituio da linguagem interna do Postgres, ele foi rebatizado de Postgres95, e no ano seguinte seu cdigo foi aberto, sendo que um grupo de alunos de Berkeley continuou a desenvolv-lo. Aps alguns anos e muitas modificaes, foi novamente rebatizado, desta vez como PostgreSQL. Sua primeira verso foi a 6.0, em memria aos longos anos de desenvolvimento anteriores, que lhe deram a reputao de um banco de dados robusto e confivel. Atualmente, o PostgreSQL est na verso 8.1. Sendo um banco de dados livre, seguro, rpido e disponvel em vrias plataforma, o PostgreSQL despertou o interesse de grandes corporaes, que viram nele uma alternativa no s econmica, mas principalmente tecnicamente vivel aos carssimos bancos de dados proprietrios. Por causa disto, vrias delas (como a Fujitsu Australia, Red Hat e Sun Microsystems) esto contribuindo com o projeto, seja financeira ou tecnicamente.

29 4.4.3 Derby Em 1996 a Cloudscape Inc., empresa baseada em Oakland (Califrnia), foi fundada com o objetivo de desenvolver tecnologias para bancos de dados em Java. A primeira verso de seu produto foi lanada em 1997, com o nome de JBMS, sendo mais tarde rebatizado de Cloudscape. Em 1999, a Cloudscape foi adquirida pela Informix, que dois anos depois foi comprada pela IBM. O banco de dados foi novamente renomeado, desta vez para IBM Cloudscape, que continuou a desenvolv-lo, mas desta vez com foco em bancos de dados embarcados. Em 2004, a IBM cedeu o cdigo do IBM Cloudscape para a Fundao Apache, que o transformou no Derby. Em julho de 2005, o Derby foi lanado oficialmente. Dentre as principais caractersticas do Derby pode-se citar [DERBY]:

livre para qualquer tipo de uso; totalmente desenvolvido em Java, o que garante sua execuo em mltiplas plataformas;

facilidade de uso para desenvolvedores e usurios finais, que no precisam administr-lo;

pequeno o banco de dados completo, com o motor e driver JDBC embarcado, tem apenas 2 MB, o que garante alto desempenho e baixa utilizao dos recursos da mquina, permitindo seu uso at mesmo em telefones celulares;

baseado nos padres Java e ANSI SQL, incluindo a sintaxe SQL, transaes, concorrncia, triggers e backup on-line.

Tendo sido desenvolvido como um banco de dados embarcado, o Derby facilmente integrado em diversas ferramentas, entre elas o SJSAS, que o utiliza inclusive para armazenar os dados internos do servidor no impedindo sua utilizao para qualquer tipo de aplicao. Da mesma maneira, o NetBeans 5.5, acessa diretamente o Derby do SJSAS, permitindo operaes como criao de bancos de dados e tabelas e realizao de consultas, entre outras. Por todas estas caractersticas, o Derby foi utilizado no desenvolvimento deste trabalho.

30

5 UMA APLICAO PRTICA DA TECNOLOGIA JAVA EE A aplicao base para este trabalho um software gerenciador de projetos. Foram desenvolvidos apenas os mdulos necessrios para a demonstrao das tecnologias envolvidas. A mesma linha foi adotada quanto aos recursos do servidor de aplicaes Java EE, onde apenas foram configurados os recursos necessrios para o desenvolvimento do aplicativo. importante frisar que o objetivo deste trabalho no ser uma referncia para o ensino da linguagem de programao Java . O objetivo dar subsdios para o incio do desenvolvimento de aplicaes que englobam vrias das tecnologias disponveis na plataforma Java EE 5. Parte-se do pressuposto, ento, que o leitor j possua conhecimentos da linguagem de programao Java em ambientes desktop e web , bem como familiaridade com algum IDE e o framework JSF. Por conta disto, o enfoque maior o que, e no como fazer. De fato, pouco cdigo foi escrito o trabalho foi em grande parte feito pelo prprio IDE. Baseado neste cdigo, os principais conceitos e configuraes sero discutidos. O aplicativo a ser desenvolvido bastante simples, e ao final do desenvolvimento, os principais recursos tratados tero sido (no necessariamente nesta ordem): 1. Banco de dados 1.1. Utilizao do Derby a partir do NetBeans; 1.2. Pool de conexes controlado pelo servidor de aplicaes; 1.3. Recursos de acesso ao banco de dados controlado pelo servidor de aplicaes; 1.4. Utilizao de camada de persistncia; 1.5. Utilizao da Java Persistence API (JPA). 2. Camada de negcios 2.1. Beans 2.1.1. Interfaces locais e remotas; 2.1.2. Anotaes. 2.2. Entidades 2.2.1. Para tabelas simples; 2.2.2. Para tabelas com chaves estrangeiras; 2.2.3. Para tabelas com chaves compostas;

31 2.2.4. Interfaces locais e remotas; 2.2.5. Facades. 2.3. Arquivos de configurao; 2.4. Utilizao da Java Cryptography Extension (JCE). 3. Camada de visualizao (desktop) 3.1. Acesso aos componentes de negcio a partir da aplicao desktop; 3.2. Utilizao do container de aplicaes cliente do SJSAS. 4. Camada de visualizao (web ) 4.1. Utilizao de EJB a partir da aplicao web ; 4.2. Acesso aos recursos do contexto Faces;

5.1 AMBIENTE DE DESENVOLVIMENTO Para a construo do aplicativo, fundamental que o ambiente de desenvolvimento esteja configurado. Ao final do procedimento a seguir, o ambiente deve estar instalado, integrado e em funcionamento. A correta configurao do NetBeans fundamental para o desenvolvimento do projeto, pois praticamente todas as operaes sero realizadas atravs dele. Todo o desenvolvimento foi realizado na plataforma Windows XP Professional, com o Service Pack 2 instalado.

5.1.1 Pr-requisitos

JDK 1.5.0_03 ou acima. Neste trabalho, foi utilizada a verso 1.5.0_08, disponvel em http://java.sun.com/javase/downloads/index.jsp;

NetBeans 5.5, disponvel em http://www.netbeans.org/downloads.. SJSAS, disponvel no endereo http://java.sun.com/javaee/downloads/index.jsp. Ao final da pgina, escolha o componente Sun Java System Application Server Platform Edition 9, Multi-language.

5.1.2 Instalao dos software O s software podem ser instalados em qualquer pasta do computador. Entretanto, importante que seja criada uma varivel de ambiente chamada JAVA_HOME, cujo contedo o caminho para a pasta de instalao do JDK. Todos eles podem ser instalados com as configuraes default.

32 5.2 INTEGRAO DO NETBEANS COM O SJSAS O NetBeans e o SJSAS so patrocinados pela Sun, e por isso so facilmente integrados:

No NetBeans, acesse o menu Tools / Server manager; Clique no boto Add Server; Na tela que abrir, deixe os valores default e clique em Next; No campo Platform location, informe a pasta de instalao do SJSAS; Se j no estiver marcada, marque a opo Register Local Default Domain. A URL localhost:4848...\domain1 localizada automaticamente;

Clique em Next e, na prxima tela digite o usurio e senha de administrao, informados durante a instalao do SJSAS.

A partir deste momento, possvel iniciar e parar o SJSAS atravs do NetBeans. Para testar a integrao, o seguinte procedimento pode ser realizado:

Selecione a aba Runtime (est localizada no topo esquerdo da rea de trabalho do NetBeans), abra o n Servers, acesse o menu de contexto e selecione Start, conforme ilustra a figura a seguir.

Figura 7: Inicializao do SJSAS a partir do NetBeans

Na rea de mensagens do NetBeans sero abertas duas janelas, uma chamada Java DB Database Process e a outra Sun Java System Application Server.

O procedimento de inicializao termina quando as mensagens das Figuras 8 e 9 forem mostradas na rea de output.

Figura 8: Mensagem de inicializao do Java DB

33

Figura 9: Mensagem de inicializao do SJSAS

Num navegador web, acesse o endereo http://localhost:8080 . Se o SJSAS foi carregado corretamente, uma tela com a mensagem abaixo deve ser mostrada.

Figura 10: Mensagem indicando que o SJSAS foi iniciado

O container web do servidor de aplicaes por padro utiliza a porta 8080 para que as aplicaes seja mostradas aos usurios. Entretanto, o SJSAS possui uma aplicao que responde na porta 4848, utilizada para administrao e configurao do servidor, chamada de Admin Console (Painel de Administrao). Para acess-la, basta utilizar o endereo http://localhost:4848. Informe o usurio admin e a senha informada durante a instalao, e uma pgina como ilustra a Figura 11 mostrada. Sempre que for necessrio configurar algum parmetro no SJSAS, o procedimento deve se feito atravs do Painel de Administrao.

Figura 11: Tela principal do ASADMIN

34 5.3 CRIAO DO BANCO DE DADOS A criao do banco de dados e das tabelas necessrias ao aplicativo feita atravs do prprio NetBeans. Este procedimento adotado pois o banco utilizado, o Derby, embarcado no servidor de aplicaes, e no possui nenhum tipo de ferramenta visual. Entretanto, o NetBeans possui um mdulo bsico de acesso a banco de dados que permite executar instrues SQL, criar e excluir tabelas, alm de outras opes. Este mdulo utiliza conexes JDBC, e compatvel com praticamente todos os principais produtos do mercado, entre eles o Derby. Uma observao se faz necessria. A Sun utiliza o Derby embarcado em vrios de seus produtos, como o SJSAS. Seu principal objetivo ser um banco de dados para desenvolvimento, para que programadores testem suas aplicaes sem a necessidade de possuir uma infraestrutura complexa. No procedimento a seguir, vrias figuras fazem aluso ao Java DB, nome pelo qual a Sun chama sua verso customizada do Derby. O primeiro passo criar um banco de dados para utilizar na aplicao.

Inicie o banco de dados. Para isto, acesse o menu Tools / Java DB Database / Start Java DB Server (ver Figura 12). Se o SJSAS j tiver sido iniciado esta opo estar desabilitada, pois o Java DB inciado juntamente ao servidor de aplicaes.

Figura 12: Menu para iniciar e parar o Java DB

Verifique na rea de sada do NetBeans (parte inferior da tela) se o banco foi iniciado (ver Figura 13).

Figura 13: Mensagem de incio do Java DB

Acesse o menu Tools / Java DB Database / Create Java DB Database. Na tela a seguir, informe os dados constantes na Figura 14 e clique em OK.

35

Figura 14: Configuraes do banco de dados Maxigroupware

O local de gravao do banco de dados indicado no campo Database Location. Para alterar o local onde o Java DB cria os bancos de dados, basta seguir as instrues constantes na prpria tela.

Com o banco de dados criado, criada tambm uma conexo para acess-lo (ver Figura 15). Acesse seu menu de contexto, e escolha a opo Connect... Informe a senha, se necessrio.

Figura 15: Nova conexo criada

Expanda a conexo, e vrios componentes do banco de dados sero mostrados, conforme ilustra a Figura 16.

Figura 16: Componentes disponveis na conexo com o banco de dados

36 O segundo passo criar as tabelas do banco de dados. A criao pode ser feita de duas maneiras: 1. 2. Atravs da opo Create table, do menu de contexto da opo Tables; Atravs de scripts SQL.

Neste trabalho foi utilizado um script simples, que cria as trs tabelas necessrias aplicao. O contedo do script est disponvel no Apndice A. Para executar o script:

Acesse o menu de contexto de qualquer componente da conexo (incluindo ela mesma) e escolha a opo Execute command;

Na janela que se abrir no NetBeans, digite o contedo do script e execute-o. Para isto, clique no boto sero mostradas. da barra de ferramentas. As mensagens da Figura 17

Figura 17: Mensagens de criao das tabelas

Acesse o menu de contexto do n Tabelas e escolha a opo Refresh. As tabelas criadas sero mostradas.

As tabelas de projetos e usurios foram criadas com uma chave primria do tipo autoincremento, ou seja, o prprio banco de dados controla a gerao dos cdigos de projetos e usurios. O problema desta abordagem que campos de auto-incremento no so comuns a todos os bancos de dados (por exemplo, Oracle e PostgreSQL utilizam as chamadas sequences ). Esta abordagem foi utilizada apenas para fins didticos, e no a maneira ideal de se controlar esta informao. O correto criar seu prprio gerenciador de identidades, garantindo que ele seja compatvel com todos os bancos de dados. Entretanto, esta implementao no faz parte do escopo deste trabalho.

37 5.3.1 Conceitos sobre acesso a bancos de dados no Java Quando se fala em acessar bancos de dados utilizando Java, necessrio conhecer trs conceitos, nos quais se baseiam a conexo, a pesquisa e a utilizao destes dados, otimizando os recursos disponveis de mquina. Estes conceitos so:

Conexo direta via Java Database Connectivity (JDBC); Pool de conexes; Camadas de persistncia.

5.3.1.1 Conexo direta via JDBC JDBC o mecanismo bsico de acesso ao banco de dados. Todos os acessos so realizados atravs de conexes JDBC. uma API completa que permite realizar desde simples consultas at o gerenciamento completo do banco de dados. Cada banco de dados tem um driver especfico para acess-lo. Este driver (normalmente desenvolvido pelo prprio fabricante do banco de dados) especfico para o banco, no havendo nenhum driver genrico. No desenvolvimento tradicional, a cada acesso ao banco de dados associada uma conexo. Desta maneira, se num determinado mtodo forem executados cinco acessos ao banco, sero criadas cinco conexes. Estas conexes somente sero liberadas atravs de comandos no prprio programa, ou ento quando o banco o banco de dados enviar um sinal de timeout . Se muitas conexes forem executadas simultaneamente (como num ambiente corporativo), o banco pode no suportar a carga, perdendo desempenho. Criar uma conexo pode consumir vrios segundos, enquanto a instruo SQL executada por ela pode consumir apenas milissegundos. Num ambiente internet, por exemplo, com milhares de usurios, o consumo de recursos seria enorme. Por esta ineficincia, a conexo via JDBC pouco utilizada. Seu principal uso a execuo de pesquisa complexas, nas quais as camadas de persistncia normalmente tm baixo desempenho. Para resolver este problema, so utilizados os pools de conexo.

5.3.1.2 Pool de conexes O conceito de pool de conexes bastante simples. Ao invs de criar as conexes sob demanda, gerando sobrecarga ao banco de dados, cria-se um conjunto de conexes durante a carga da aplicao. Estas conexes vo sendo utilizadas pela aplicao. Aps o uso, as conexes so

38 liberadas. Quando todas as conexes do pool so utilizadas, novas conexes so recusadas, ou ento so adicionadas novas conexes ao conjunto j existente, aumentando sua capacidade (o comportamento depende da configurao do pool) [IMASTERS]. No so necessrias grandes quantidade de conexes dentro do pool, pois parte-se do princpio que embora uma aplicao possa ter milhares de usurios, poucos deles faro acesso ao banco de dados num determinado momento, e o tempo utilizado para o acesso muito pequeno (alguns milissegundos). Isto garante que sempre haja uma conexo disponvel para uso. Como as conexes no precisam mais ser criadas com grande freqncia, o desempenho do acesso ao banco de dados muito superior, e apenas o crescimento do nmero de conexes feito sob demanda. As conexes extras criadas sero canceladas pelo banco quando expirar seu timeout , no sobrecarregando nem o servidor de aplicaes, nem o de banco de dados. Um pool de conexes pode ser facilmente implementado, sendo que existem boas bibliotecas gratuitas disponveis hoje, como o DBCP (acrnimo para Database Connection Pool), da Fundao Apache [DBCP].

5.3.1.3 Camadas de persistncia Conceitualmente, uma camada de persistncia permite o armazenamento em meio fsico das informaes contidas num objeto. Para uma melhor compreenso, tome-se por exemplo a tabela Projeto , criada no banco de dados Maxigroupware. Sempre que um objeto do tipo Projeto precisar ser gravado no banco de dados, deve-se obter os dados do objeto e executar um comando no banco de dados, j com os dados do projeto, para gravao. O tratamento manual desta operao pode provocar uma grande quantidade de problemas. Por exemplo, se a estrutura da tabela for alterada no banco de dados, deve-se alterar, recompilar e redistribuir o programa para os usurios. O objetivo da camada de persistncia abstrair o desenvolvedor deste problema. Utilizando vrios recursos do Java, ao receber um objeto do tipo Projeto, ela sabe perfeitamente quais dados obter do objeto, e a quais campos da tabela eles devem ser associados. Tambm gerencia um pool de conexes prprio e centraliza o acesso ao banco de dados, facilitando a manuteno do sistema. O grande problema das camadas de persistncia que, s vezes, ela pode ser ineficiente. Sendo bibliotecas genricas, devem trabalhar da maneira mais padronizada possvel, e

39 portanto no pode utilizar os recursos avanados tpicos de cada banco. Prendendo-se a padres SQL, muitas vezes no seguidos pelos fornecedores de banco de dados, as camadas de persistncia tm a o seu ponto fraco.

5.3.1.4 Pool de conexes no servidor de aplicaes Como citado anteriormente, o pool de conexes otimiza bastante o acesso ao banco de dados, mas apresenta um problema. Cada aplicao deve controlar seu prprio pool. Aparentemente, esta uma tarefa simples, mas se for levado em considerao um ambiente corporativo, pode-se chegar a alguns nmeros interessantes. Por exemplo: um ambiente com 80 aplicaes, todas acessando o mesmo banco de dados. Para cada uma delas deveria ser criado um pool com 10 conexes. Seriam utilizadas 800 conexes ao banco. Para minimizar o problema, possvel criar um pool no na aplicao, mas no prprio servidor de aplicaes, e compartilhar este pool entre vrias aplicaes diferentes, otimizando o acesso ao banco. No exemplo acima, poderia ser criado um nico pool, com 10 conexes servindo a todas as aplicaes. Deixariam de ser utilizadas 790 conexes. Obviamente, existem limitaes. A principal delas que cada pool pode acessar apenas um banco de dados de cada vez o que no impede que seja criado um pool para cada banco. Neste caso (e ainda utilizando o exemplo acima), num ambiente com 20 bancos diferentes, seriam criados 20 pools, totalizando 200 conexes. Ainda assim, deixariam de ser criadas 600 conexes.

5.3.1.5 Criao do pool de conexes ao banco de dados Novamente utilizado o painel de administrao do SJSAS.

No menu principal, acesse a opo Resources / JDBC / Connection Pools; Na tela mostrada, clique no boto New; Na nova tela mostrada (ver Figura 18) informe os dados abaixo: Name..................: MaxigroupwarePool ResourceType.....: javax.sql.DataSource DatabaseVendor. . : Derby

Clique em Next; Na tela seguinte (ver Figura 19), preencha apenas as seguintes propriedades: No menu aparece o nome do novo pool conforme pode ser visto na Figura 20. Clique sobre ele para edit-lo e exclua todas as propriedades no listadas no item anterior. Clique em Save.

40

Figura 18: Step 1 of 2 - Criao do pool de conexes

Figura 19: Step 2 of 2 - Propriedades do pool de conexes

41

Figura 20: Novo pool criado

5.3.1.6 Criao do recurso JDBC O recurso JDBC o elo de ligao entre a aplicao e o pool de conexes. Quando for necessrio se conectar ao banco de dados, este recurso que deve ser referenciado, o que automaticamente seleciona o pool de conexes correto. Para criar o recurso JDBC:

Acesse o menu Resources / JDBC / JDBC Resources (ver Figura 21 ). Depois, clique em New...;

Figura 21: Criao de um recurso JDBC

42

Na tela mostrada, informe: JNDI Name. . : jdbc/maxigroupware Pool Name...: MaxigroupwarePool

Clique em OK; O recurso foi criado (ver Figura 22).

Figura 22: Recurso JDBC criado

Uma considerao sobre o JNDI Name. JNDI significa Java Naming and Directory Interface. O nome JNDI utilizado para organizar e localizar componentes num ambiente de computao distribudo, de maneira anloga a um ndice de pginas amarelas encontrado em listas telefnicas. Como conseqncia, o nome JNDI o mtodo mais importante de acesso aos recursos do servidor de aplicaes. Dentro do servidor de aplicaes, os componentes so agrupados em categorias. Podese compar-las a um diretrio localizado no servidor de aplicaes, dentro do qual esto diversos recursos do mesmo tipo. A primeira parte do nome JNDI indica a pasta a ser pesquisada. Por conveno, o nome do diretrio com os recursos de banco de dados comea com jdbc/. Assim, para localizar o recurso JDBC chamado maxigroupware , utilizamos o endereo jdbc/maxigroupware.

5.4 CONFIGURAO DO SJSAS O SJSAS em sua verso gratuita no pode ser considerado um servidor de aplicaes corporativo, devido inexistncia de recursos como computao em grade, balanceamento de carga e alta escalabilidade, entre outros. Por isto, considerado um servidor departamental. Isto no impede que ele seja utilizado em ambientes com grande quantidade de processamento, mas no existem garantias quanto ao desempenho em caso de sobrecarga. Outra caracterstica que aps sua instalao, ele est pronto para ser utilizado. Suas configuraes iniciais sugerem sua utilizao num ambiente no muito pesado, e para isto ele uma

43 tima opo. Vale ressaltar que o SJSAS baseado no GlassFish, projeto de cdigo aberto patrocinado pela Sun, e que o GlassFish nas prximas verses ser distribudo com recursos avanados de escalabilidade e tolerncia a falhas [GLASSFISH WIKI]. Com isto, nenhuma configurao realmente necessria para este trabalho. Entretanto, foi alterada a porta padro do servidor HTTP. Por padro, todas as requisies HTTP so feitas na porta 80 do servidor, e por este motivo, no necessrio inform-la nos endereos web. Por exemplo, quando o endereo http://localhost digitado, a ausncia do nmero da porta identifica que deve ser utilizada a porta 80. Por outro lado, containeres web como o Tomcat utilizam por padro a porta 8080, mesmo respondendo a requisies HTTP. Por isso, necessrio indicar a porta na URL (por exemplo: http://localhost:8080). Para facilitar a digitao das URL utilizadas nos exemplos, a porta padro do container web do SJSAS foi alterada para 80, dispensando a informao da porta nos endereos. Todas as configuraes do SJSAS sero feitas a partir de sua pgina de administrao.

Num navegador, acesse o endereo http://localhost:4848/asadmin. Informe o usurio admin e a senha informada durante a instalao do servidor de aplicaes (ou outra, se ela foi alterada). mostrado o painel de administrao.

No menu esquerda, acesse: Configuration / HTTP Service / HTTP Listeners / httplistener-1;

Altere a opo Listener Port para 80; Clique no boto Save; Para testar a configurao, acesse o endereo http://localhost em um navegador. Uma tela com o contedo mostrado na Figura 10 deve ser mostrada.

Veja as opes na Figura 23.

44

Figura 23: Alterao da porta padro do container web

45

6 ENTERPRISE JAVA BEANS O Java EE no uma tecnologia simples. Ao contrrio, ela muito complexa, o suficiente para no ser tratada como uma tecnologia monoltica, mas formada por partes menores, chamadas de componentes . O conceito de componente deve ser bem compreendido antes de qualquer desenvolvimento em Java EE. A universidade de Princeton (localizada em Princeton, nos Estados Unidos) possui um interessante servio chamado de WordNet, que essencialmente um dicionrio lxico [PRINCETON]. L, o conceito de componente :...um artefato que uma parte individual de uma entidade composta, especialmente uma parte que possa ser separada de ou anexada a um sistema....

Entretanto, componentes de software vo alm disto. Eles so uma parte concreta do sistema, um cdigo escrito para representar o comportamento de um conceito abstrato. Por exemplo um componente chamado AmortizaFinanciamento deve conter todo o cdigo necessrio para realizar a amortizao de um financiamento (com todas as particularidades que o processo de amortizao possui), e interagir com elementos como pessoas, empresas, e at mesmo outros componentes [SRIGANESH 2006]. Um componente independente, e se for bem construdo pode ser reutilizado por outros componentes e sistemas. Quando distribudo, deve ser empacotado juntamente com todos os recursos necessrios para seu funcionamento, como arquivos e configuraes, de modo que ele possa existir por si s, sem depender da aplicao original. Desta maneira, um sistema pode ser formado por vrios componentes reutilizados, cada um com sua funcionalidade especfica. Com um bom conjunto de componentes reutilizveis, possvel montar um sistema inteiro simplesmente definindo as ligaes entre eles.

6.1 BEANS Beans so componentes reutilizveis, que realizam algum tipo de trabalho quando acionados pelas aplicaes clientes, encapsulando a lgica do negcio [JAVABEANS]. Podem, por

46 exemplo, consultar um preo, processar o cancelamento de nota fiscal, ou apenas armazenar os itens de um carrinho de compras de uma aplicao de comrcio eletrnico. Desta maneira, no necessrio (nem recomendvel) desenvolver a lgica de negcio nas aplicaes cliente. Isto permite acessar os beans de vrias maneiras: numa aplicao web , numa aplicao desktop ou atravs de web services. Existem dois tipos de beans [BALL 2006]:

Session beans: realizam operaes para os clientes, e podem conter web services; Message driven beans: atuam como listeners para algum tipo de mensagem, definidas pela API Java Message Service (JMS).

Neste trabalho, so utilizados apenas os Session Beans que, deste em ponto em diante so tratados simplesmente como beans.

6.2 SESSION BEANS Um session bean representa uma nica instncia do cliente, dentro do servidor de aplicaes. A nica maneira de um cliente acessar as informaes da aplicao so os mtodos dos beans , o que abstrai o cliente completamente da complexidade da aplicao. Um bean nico e atende somente a um cliente que o acessa atravs de uma sesso (da o nome de session bean). Um bean no pode ser compartilhado entre sesses, nem persistido (gravado em banco de dados, por exemplo). Uma vez que o cliente finaliza a sesso, o bean no mais associado a ela, e simplesmente destrudo. Existem dois tipos de beans, classificados quanto maneira que tratam seus estados [BALL 2006]: stateless (os mais comuns) e statefull.

6.2.1 Statefull beans O estado de um bean consiste nos valores de suas variveis no decorrer da sesso. Um statefull bean mantm esses valores enquanto durar a sesso do cliente. Se a aplicao cliente remove o bean ou ento encerrado (por exemplo, o navegador fechado), a sesso termina e o bean destrudo. Caso contrrio, mesmo que o bean termine de ser utilizado, ele permanece disponvel no servidor, e pode ser acessado a qualquer momento, juntamente com os dados previamente informados.

47 6.2.2 Stateless beans Num stateless bean, as variveis podem ter um estado, mas ele somente vlido durante a execuo do mtodo que chamou o bean. Quanto a execuo termina, o estado das variveis no retido. exceo de quando um mtodo executado, todas as instncias de um stateless bean so iguais, permitindo ao container EJB alocar qualquer instncia para qualquer cliente. Esta caracterstica permite que eles sejam utilizados por vrios clientes, e por isto so utilizados em aplicaes que tenham grande nmero de usurios simultneos, otimizando a carga do servidor e conseqentemente seu desempenho. Outra caracterstica deste tipo de bean que ele o nico que pode implementar web services.

6.3 INTERFACES Um cliente no pode acessar um bean diretamente. Por mais mtodos que um bean possua, o cliente s pode acessar os que forem declarados em suas interfaces. Isto importante, pois um bean pode ter mtodos para seu uso prprio, que no so visveis ao cliente. A Figura 24 mostra os passos para um cliente remoto acessar um bean.

Figura 24: Acesso de um bean por um cliente remoto

Interfaces so fundamentais para a construo de aplicativos de fcil manuteno. Alm de abstrair os clientes da complexidade da aplicao, permitem que o bean seja alterado sem afetar os clientes. Se uma interface for escrita e algum dia for alterada, todos os clientes que a utilizam devero ser alterados tambm. Existem trs tipos de interfaces para acesso aos beans: remotas, locais e web services. Os web services no so tratados neste trabalho. As interfaces locais so utilizadas quando um bean acessado por outro bean, e ambos estejam na mesma JVM. Por exemplo: aps realizar uma operao, um bean deve enviar um e-mail para o responsvel pelo processo. O bean que envia a mensagem acessado somente para este tipo

48 de uso. Sendo acessado somente pelos beans j criados no container EJB, ele somente necessita da interface local. A s interfaces remotas so utilizadas quando aplicaes externas ao container EJB acessam os beans l mantidos. Por exemplo, se uma aplicao web precisa acessar um bean, somente pode faz-lo a partir de uma interface remota, pois a aplicao web executada em outro container. Como ltima observao, necessrio ressaltar que um bean pode implementar as duas interfaces, sendo ento referenciados por clientes remotos ou locais.

6.4 ANOTAES Nas verses anteriores da especificao J2EE (nome do Java EE, at a verso 1.4), todas as configuraes necessrias aplicao era feita em arquivos XML. Nestes arquivos, chamados de deployment descriptors (descritores de publicao) eram especificados os beans constantes da aplicao, se estes eram stateless o u statefull, se eram acessados remota ou localmente, entre outras informaes. Esta quantidade de informaes gerava arquivos muito grandes e de alta complexidade, o que por extenso tornava o desenvolvimento J2EE extremamente difcil e demorado. Na especificao Java EE 5, um dos principais objetivos simplificar o desenvolvimento e aumentar a produtividade. Para isso, parte das configuraes antes descritas em arquivos XML so agora inseridas na prpria codificao do programa, atravs das annotations (anotaes), e o trabalho pesado ficou a cargo do servidor de aplicaes. Como resultado direto, os arquivos de configurao tiveram seus tamanhos (e complexidade) reduzidos drasticamente. As anotaes no Java so sempre precedidas do smbolo da arroba (@).

6.5 CONTAINER PARA APLICAES CLIENTE O servidor de aplicaes possui um container desenvolvido especificamente para executar aplicaes cliente. O principal objetivo facilitar a distribuio e execuo da aplicao em ambiente distribudo. Neste container, o prprio servidor de aplicaes se encarrega de fornecer as bibliotecas necessrias sua execuo. Quando se desenvolve um cliente, este normalmente faz referncias a vrias bibliotecas (por exemplo, um componente para desenho de telas). O IDE envia as bibliotecas necessrias juntamente com a aplicao e todas as configuraes necessrias, como o classpath. O servidor de

49 aplicaes ento se encarrega de prover toda a infraestrutura necessria para a execuo da aplicao.

6.6 JAVA WEB START Outro motivo para utilizar o container de aplicaes cliente, que normalmente os clientes so desenvolvidos utilizando uma interface grfica, como o Swing. O container se encarrega de automaticamente disponibilizar a aplicao atravs do Java Web Start (JWS), sem que seja necessrio escrever uma nica linha de cdigo. O JWS uma tecnologia que permite distribuir e atualizar as aplicaes cliente para todos os usurios. Seu funcionamento bastante simples: quando o usurio acessa a aplicao pela primeira vez, o JWS copia a aplicao e todas as bibliotecas necessrias execuo para estao, e depois a executa. Quando o usurio carrega a aplicao pela segunda vez, ao invs de copiar toda a aplicao, o JWS copia apenas os arquivos alterados desde a ltima execuo da aplicao pelo usurio. A tecnologia JWS permite que:

o usurio sempre tenha a ltima verso do aplicativo; seja definida apenas uma origem para a aplicao, acabando com o problema de enviar ao usurio algum tipo de mdia (CD ou disco flexvel) ou de deixar a cargo do usurio a instalao da nova verso.

6.7 CONTEXTO Um contexto uma rea do servidor de aplicaes onde ficam armazenadas as informaes dos EJB disponveis. Basicamente, um mapa relacionando objetos a seus respectivos nomes, para que seja possvel localiz-los no container EJB [JNDI]. Para acessar um EJB, necessrio primeiro criar um contexto, identificando o servidor e a porta disponvel para acess-lo. S ento pode-se pesquisar o EJB, cujo nome sempre relativo a este contexto.

6.8 TIPOS DE ARQUIVO Cada mdulo de uma aplicao enterprise possui um tipo de arquivo diferente, que o servidor de aplicaes utiliza de maneiras diferentes. Embora estes arquivos possuam extenses

50 diferentes, todos eles so arquivos compactados no formato ZIP, que possuem internamente uma estrutura de pastas e arquivos definida pela especificao Java. Graas a este padro, o servidor ou container onde o arquivo est sendo publicado sabe interpret-lo corretamente, e tomar as aes necessrias para disponibiliz-lo. Estes arquivos so [BALL 2006]:

JAR: tipo mais comum de arquivo do Java, o Java ARchive tem por finalidade agrupar classes para criar bibliotecas. Normalmente uma aplicao Java pode conter vrias centenas de classes e o empacotamento em uma biblioteca facilita a disponibilizao do aplicativo.

WAR: os Web ARchives so arquivos que contm aplicaes web completas, j prontas para disponibilizao num container JSP/Servlet como o Tomcat ou num servidor de aplicaes como o SJSAS.

EAR: so os Enterprise ARchives, que contm aplicaes empresariais completas. Um EAR normalmente formado por vrios mdulos, que podem ser arquivos JAR e/ou WAR. Estes arquivos somente so manipulados corretamente por servidores de aplicao.

6.9 PERSISTNCIA DE DADOS A persistncia de dados um dos pontos mais importantes de qualquer sistema. Por melhor que seja seu desempenho, se o acesso ao banco de dados for lento, o sistema tambm o ser. Por isto, a especificao Java EE 5 tem diversos recursos para facilitar este acesso [BALL 2006]:

Entity beans - ou simplesmente entidades, so os objetos responsveis pelo acesso direto aos bancos de dados utilizados numa aplicao. Uma entidade representa uma tabela, e cada uma de suas instncias corresponde a um registro desta tabela;

A JPA fornece meios para gerenciar o mapeamento objeto-relacional de objetos Java para um banco de dados. O mapeamento objeto-relacional relaciona cada propriedade da entidade com uma coluna da tabela.

Um PersistenceContext um conjunto de instncias de entidades no qual para cada entidade existe apenas uma instncia com um determinado valor de chave primria.

A API EntityManager usada para executar operaes no banco de dados, como incluso, excluso, alterao e consulta. Uma vez realizada a operao no EntityManager, o PersistenceContext e o banco de dados so automaticamente atualizados.

51

O conjunto de