Cejug Classifieds

Arena PUJ – Sistema Online de Suporte ao
Prêmio Universitário Java
Leonardo Silveira¹, Felipe Gaúcho²
¹USIX Technology
²Ceará Java Users Group (CEJUG)
¹[email protected]
²[email protected]
Resumo - Este artigo apresenta o Prêmio Universitário Java
(PUJ), uma competição acadêmica entre trabalhos Java
realizados por alunos de cursos de graduação no Ceará. Além do
formato da competição e de como ela se encaixa no mercado
cearense de TI, o artigo descreve o Arena PUJ, um projeto de
software livre criado para desenvolver um sistema online de
gerenciamento e divulgação dos resultados das competições no
formato PUJ. Este texto descreve as demandas que motivaram o
projeto, o modelo das competições, e apresenta os primeiros
resultados obtidos com um protótipo desenvolvido sob a
plataforma Java Enterprise Edition (Java EE). O modelo
inovador de desenvolvimento e a interoperabilidade entre as
tecnologias adotadas no protótipo oferecem bons indicadores
sobre as tecnologias ditas “Web 2.0” e também as novas
tendências de projeto de software orientados à Cloud Computing.
Palavras chave — PUJ, Software Livre, Java EE, CEJUG,
Cloud Computing.
Abstract — This article presents "Premio Universitario Java"
(PUJ), an academic competition between java exercises made by
students from graduation courses on Ceará. This article describes
the competition format, how it's connected with IT market on
Ceará and also it describes the Arena PUJ, a free software/open
source online system made to manage and spread competitions
results which uses PUJ's format. This article describes the
demands which motivated the project conception, it's model and the
results obtained by a prototype application developed using the
Java Enterprise Edition (Java EE) platform. It's innovative model
and it's interoperability with adopted technologies on the prototype
offers good indicators about the so-called "Web 2.0" technologies
and also the new software project trends oriented to Cloud
Computing.
Keywords — PUJ, open-source,
Computing.
Java EE, CEJUG, Cloud
I. INTRODUÇÃO
O CEJUG [1] (Grupo de usuários Java do Ceará) promove
anualmente o Prêmio Universitário Java - PUJ, uma
competição que revela trabalhos de graduação produzidos com
a tecnologia Java em faculdades do Ceará. Iniciado em 2007,
o PUJ oferece à sociedade um indicador independente sobre a
qualidade do ensino Java nas faculdades locais, além de abrir
um espaço para revelar novos talentos em TI e para a
celebração dos bons professores e das boas instituições de
ensino superior no Ceará e no Brasil – visto que o formato da
competição começa a ser copiado em outros estados
brasileiros. A partir do apoio da indústria local e da boa
repercussão das três primeiras edições do PUJ, um grupo de
profissionais e estudantes do CEJUG decidiu criar um projeto
de software livre para melhorar a visibilidade e a organização
do PUJ. O projeto foi batizado de “Arena PUJ” e publicado
sob a licença LGPL[2] no portal Kenai[3]. Nas próximas
seções deste artigo descrevemos o modelo de competição do
PUJ e a arquitetura do Projeto Arena PUJ, apresentando
também o modelo de desenvolvimento adotado no Projeto e os
resultados já obtidos. O formato do artigo é um convite para
que os desenvolvedores contribuam nesta inovadora forma de
estimular qualidade em educação Java.
II.PRÊMIO UNIVERSITÁRIO JAVA
O objetivo do Prêmio Universitário Java é aproximar a
academia do mercado, colocando os trabalhos acadêmicos
produzidos em exposição para profissionais de TI e empresas
patrocinadoras. A competição consiste em três etapas
distintas:
1. Chamada de trabalhos: professores podem submeter os
trabalhos Java de seus melhores alunos.
2. Avaliação dos trabalhos: profissionais de mercado, alunos
e professores avaliam os trabalhos com notas entre um e dez e
uma pequena justificativa para cada nota.
3. Publicação dos resultados: o CEJUG divulga os
resultados, encerrando a competição e premiando os alunos
com os melhores trabalhos.
Algumas regras são obedecidas para garantir a qualidade e
segurança das informações, bem como para estimular a
competitividade saudável entre os estudantes. Para economizar
espaço neste texto, não iremos copiar aqui o regulamento
completo usado pelo CEJUG, mas dentre estas regras
destacam-se o fato que apenas professores podem submeter
trabalhos e de que a competição é toda virtual, não exigindo a
presença física de professores e/ou estudantes em nenhuma de
suas etapas. Ao submeter um trabalho o professor endossa a
autoria do trabalho, que precisa ter sido parte de alguma
disciplina regular de um curso de graduação do Ceará. Outro
detalhe importante é que o PUJ delimita as tecnologias aceitas
na competição mas não estabelece os tipos de trabalho que
podem ser submetidos pelos professores, ou seja, o PUJ avalia
a realidade do que está sendo produzido dentro da faculdade
sem interferir nos currículos destas faculdades. Reconhecemos
a liberdade das faculdades em escolher o que ensinar, bem
como na seriedade dos órgãos de governo em fiscalizar a
qualidade dos currículos adotados nas instituições de ensino.
Um dos objetivos do PUJ é oferecer um indicador
complementar ao currículo das universidades, permitindo ao
mercado de trabalho dar notas ao que está sendo produzido em
sala de aula. A sociedade em geral, incluindo alunos e seus
familiares e as empresas que buscam contratar bons egressos
de cursos universitários recebem os resultados como uma
opinião do mercado sobre o que é realmente implementado
com Java em sala de aula – e não apenas uma avaliação
institucional formal sobre o formato dos currículos. Outro
detalhe interessante é que os professores e alunos são
convidados a avaliarem os trabalhos de seus concorrentes,
estimulando a revisão aos pares e a identificação do que os
colegas de outras instituições de ensino estão produzindo
dentro de sala de aula. Isto estimula as instituições a
atualizarem continuamente seus conteúdos, e sugere aos
alunos a uma busca por melhor qualidade de ensino – pelo
menos se equiparando ao que de melhor seus pares
acadêmicos estão produzindo.
Papéis no PUJ
Os seguintes papéis são observados nas competições PUJ:
• Professores: são responsáveis por submeterem os trabalhos
e podem avaliar os trabalhos de seus concorrentes. Apesar de
alunos e professores serem considerados times em
competições PUJ, os professores normalmente não recebem
prêmios pela conquista de seus alunos.
• Alunos: são os autores dos trabalhos, e candidatos ao título
da competição e respectivos prêmios. Apesar de serem os
autores dos trabalhos, os alunos não podem submeter os
trabalhos diretamente ao PUJ, eles precisam do consentimento
de seus professores. Isto visa garantir a segurança das
informações e também valorizar a relação aluno-professor em
um processo saudável de ensino-aprendizado.
• Profissionais Seniores: são profissionais de destaque no
mercado brasileiro de java, selecionados pelo JUG[4] e
responsáveis por darem a opinião do mercado de software
sobre a qualidade do que vem sendo produzido dentro das
salas de aula das universidades. Estes profissionais doam o seu
tempo livre à competição visto que não é prevista nenhuma
remuneração ou premiação aos avaliadores do PUJ.
• JUG: o grupo de usuários é responsável pela comunicação
durante a competição, coletando os trabalhos e demais
informações relevantes sobre os participantes. Ao JUG
também cabe estabelecer o calendário da competição e
divulgar seus resultados, bem como zelar pela entrega dos
prêmios conquistados pelos alunos. Em situações excepcionais
o JUG pode intervir nas regras e nas avaliações, mas isto
nunca foi necessário. O ideal é que o JUG se mantenha o mais
imparcial possível, não interferindo nas avaliações ou
ajudando os professores e alunos durante a submissão.
Processo de avaliação
Os avaliadores são compostos por profissionais sênior do
mercado de TI brasileiro, bem como pelos professores que
submeteram os trabalhos e pelos alunos competidores. Há uma
distribuição de pesos para as notas dadas pelos avaliadores, a
saber: 1 – estudante; 3 – Professor; 7 – Profissional Sênior. A
nota final é calculada através de média harmônica. Outro
detalhe inovador é que o CEJUG não define critérios de
avaliação, a única recomendação é que os avaliadores usem
sua experiência profissional para avaliar os trabalhos e dar
uma pequena justificativa sobre cada nota. Este detalhe
também sugere a experiência dos profissionais como critério
mais importante no convite de participação aos avaliadores.
Submissão dos trabalhos
As submissões de trabalhos devem ocorrer em um período
estipulado pelo CEJUG, geralmente nas primeiras semanas de
um período letivo, aceitando trabalhos que foram
desenvolvidos nos semestres acadêmicos desde a última
competição PUJ. Cabe aos professores selecionar dentre os
trabalhos acadêmicos de seus alunos os com melhor
acabamento e qualidade técnica. Não deve haver nesta etapa
intervenção alguma por parte dos profissionais de mercado ou
por parte do JUG organizador da competição.
Premiação dos trabalhos
As premiações do PUJ são variadas, podem ser viagens para
congressos, licenças de software, livros técnicos ou cursos. Há
uma recomendação para não prover premiações em dinheiro,
pois elas poderiam desviar o foco da competição, que é
promover a educação e a integração entre a universidade e o
mercado de trabalho. A primeira edição da competição foi
realizada em 2007 e envolveu duas das maiores instituições de
ensino superior do Ceará. A edição seguinte teve maior
participação, contando com cinco instituições de ensino
superior adicionais, empresas patrocinadoras e dezenas de
trabalhos acadêmicos de alto nível.
A partir de 2010, outros JUGs brasileiros demonstraram
interesse em realizar competições no mesmo formato, e a
necessidade de uma ferramenta de gerenciamento das
competições se tornou evidente. Neste momento, alguns
profissionais começaram a avaliar os requisitos e a arquitetura
do projeto Arena PUJ.
III. REQUISITOS DO ARENA PUJ
A partir do formato de competição descrito acima, debates
técnicos permitiram a enumeração dos requisitos de um
sistema de suporte ao PUJ, dentre os quais destacamos:
• Gerenciamento dos documentos, em especial os trabalhos
java distribuídos em arquivos compactados.
• Cadastro e autenticação dos usuários do sistema, com
ênfase em tecnologias de autenticação distribuída, por
exemplo OpenId[5] ou Oauth[6].
• Sistema de votação, incluindo a coleta das notas e
justificativas e cálculo das médias parciais e finais.
• Sistema de notificação, com ênfase em mídias atuais como
Twitter[7], Google Buzz[8] e sistemas de emails.
Requisitos Não funcionais
Uma restrição natural do projeto é que ele deve ser
implementado com tecnologias Java devido à filosofia do
CEJUG em fomentar e divulgar o Java no Ceará. Não
questionamos a possibilidade de outras tecnologias oferecerem
soluções de igual qualidade técnica ao que buscamos produzir,
mas tratando-se de um projeto novo o CEJUG sempre
privilegia o Java. A partir deste princípio, alguns outros
aspectos foram debatidos, em especial a questão emergente do
Cloud Computing[9] uma tendência de mercado que promove
a integração de serviços distribuídos em máquinas distribuídas
na rede mundial de computadores (world wide web – www) e
conectadas pelo protocolo HTTP[10]. Seguindo esta forte
tendência, adotamos o estilo de arquitetura conhecido como
Representational State Transfer (REST[11]) e definimos que o
projeto seria baseado no conceito de produtor-consumidor,
onde serviços REST servem dados através do protocolo HTTP
e um conjunto de aplicações web consomem e formatam estes
dados para o usuário final – um ser humano. O REST faz
distinção entre consumidores humanos e máquinas, mas este
tópico vai além do escopo do nosso artigo.
Outro detalhe importante é que o Arena PUJ também é um
projeto escola, permitindo que membros do CEJUG
experimentem diversas tecnologias e tentem a seu modo
produzir uma solução de qualidade ao suporte de competições
PUJ. Para este fim, é importante que a configuração do projeto
seja flexível o bastante para absorver novas tecnologias com o
mínimo impacto no código já desenvolvido. Integração
contínua e o acesso público e permanente ao código produzido
são outros detalhes importantes a serem observados durante
montagem do projeto.
Diversas discussões foram realizadas entre os membros do
CEJUG e no final alguns requisitos não funcionais foram
estabelecidos:
• Ser desenvolvido total ou principalmente em Java.
• Parte servidora baseada em web-services REST (protocolo
HTTP).
(1.6 formalmente) da plataforma Java Enterprise: EJB 3.1,
JPA 2 e JSF 2. Ele provê serviços web no padrão REST (Em
detrimento aos Serviços que seguem a especificação
SOAP[17]). A implementação do contêiner EJB[18] utilizada
para o desenvolvimento do Arena é a implementação de
referência da SUN[19], o Glassfish[20], em sua versão 3; a
implementação do JPA[21] é o EclipseLink[22]; a
implementação do JSF[23] é também a de referência
(Mojarra[24]) e o framework Jersey[25] provê um webservice
no estilo REST que é consumido nos módulos de interface de
usuário do Arena.
O Arena possui separação clara entre a parte de negócio e a
apresentação dos fluxos possíveis; existem 5 módulos
experimentais de interface de usuário, com 3 destes bastante
usáveis, um feito com JSF, outro com técnicas tradicionais da
web e um terceiro com tecnologias web pretendidas para a
próxima versão do HTML[26]; um módulo a parte e
independente destes outros é responsável por servir através de
HTTP os serviços de listagem, votação e patrocínio do PUJ.
Por trás da fachada de serviço REST há os EJB's que cuidam
da camada de lógica e negócio e interagem com a parte de
persistência da aplicação por meio dos mapeamentos objetorelacional feitos pelo EclipseLink, a implementação de JPA
escolhida para o Arena. Há também Beans Assíncronos
participantes de barramentos JMS[27] responsáveis por tarefas
como envio de email de confirmação de cadastro.
• Ter integração contínua baseada em Hudson[12].
• Usar Maven[13] como ferramenta de compilação do código.
• Usar Kenai para a hospedagem do projeto e usar
Mercurial[14] ou GIT[15] como repositório de código.
IV. ARQUITETURA DO ARENA PUJ
O Arena é desenvolvido para dar suporte à competição
promovida pelo CEJUG, em substituição a uma série de
documentos e planilhas a preencher. Em sua concepção várias
tecnologias Java Enterprise Edition recentes foram avaliadas,
mais precisamente a versão 6 da especificação JEE[16] e suas
correlatas.
Requisitos do Projeto Arena PUJ
Para dar suporte à competição o aplicativo funciona como
sistema de votação e listagem dos competidores, além de
possuir um subsistema de autenticação para diferenciar
competidores e avaliadores de visitantes. A listagem hoje
possui um filtro capaz de mostrar todas as competições
passadas e seus participantes, bem como apresentar a
competição atual.
O arena também tem um espaço reservado para os
patrocinadores e para as instituições participantes na forma de
propaganda. Há um algoritmo que define de forma aleatória
quais e em que ordem aparecerão os patrocinadores.
Protótipo do Arena PUJ
Para validar a arquitetura acima descrita e, principalmente,
permitir o experimento de diversas tecnologias web 2.0, o
CEJUG desenvolveu um aplicativo Java EE 6 chamado Arena
PUJ e hospedado no portal Kenai.com. O aplicativo é
construído com as mais recentes implementações da versão 6
Fig. 1 Arquitetura do Arena PUJ
O módulo de interface arena-vaadin utiliza um framework
java (chamado Vaadin[28]) que permite abstrair a camada
web e suas tecnologias específicas e assim possibilitar que os
desenvolvedores produzam apenas código java. Este módulo
consome o serviço REST do módulo arena-http (que veremos
um pouco adiante) através de um cliente no lado do servidor.
O módulo encontra-se em seus estágios iniciais.
Outro módulo de interface é o arena-html5. Este utiliza
apenas tecnologias web da camada do cliente, sem uso de
códigos java para consumir o serviço REST. Este módulo usa
novidades do html5[29], especificação essa ainda em
desenvolvimento, além de muitos comportamentos dinâmicos
implementados em Javascript[30]. Este módulo é capaz de
listar os competidores das edições do PUJ e é um dos módulos
mais recentes do Arena.
O módulo arena-vraptor usa o framework java vraptor[31]
para a renderização dos componentes de tela. Este framework
dá ênfase a configuração por convenção e permite desenvolver
interfaces de usuário compatíveis com REST. Este módulo é
uma exceção à separação entre os módulos pela camada de
serviço, pois o módulo vraptor faz acesso direto à camada de
persistência. O arena-vraptor encontra-se em seus estágios
iniciais de desenvolvimento.
O módulo arena-jsf20 é feito com o que temos hoje de
padrão de interface de usuário em JEE. Com Java Server
Faces o desenvolvedor pode codificar apenas códigos java e
componentes JSF, que de forma resumida podem ser
chamados de xml's customizados e específicos de
renderização de aplicações web. O JSF também contempla a
abstração das tecnologias web da camada do cliente. Este
módulo é a segunda exceção ao uso da interface do serviço,
todavia este usa os ejb's de negócio para acessar os dados do
banco. O módulo JSF já possui a listagem de competidores em
operação dentre outras funcionalidades.
O último módulo de interface é o arena-dwr. Este faz uso de
tecnologias tradicionais da web, como html4[32] e Javascript
em conjunto com um framework java de RPC[33] (Remote
Procedure Call), o DWR[34] (Direct Web Remoting). As
chamadas DWR são usadas para alimentar o cliente de serviço
escrito em Java que repassa as requisições da tela do usuário
ao serviço REST. Este cliente por sua vez devolve à camada
DWR os dados e estes são “traduzidos” pelo framework em
objetos Javascript e entregues na camada do cliente web. Este
módulo foi o primeiro módulo funcional do Arena.
O módulo arena-http é o módulo padrão de serviço, é nele
que temos fachadas de serviço publicadas através do
framework Jersey que consomem os EJB's do Arena. Este
módulo não é uma interface de usuário, pois embora possua e
distribua conteúdo através de HTTP ele não é um módulo
destinado a usuário final; seu conteúdo pode ser lido por um
ser humano todavia não é destinado a isso; ele fornece dados
codificados em XML[35] (ou JSON[36] opcionalmente) para
aplicativos clientes, neste caso específico os módulos do arena
listados anteriormente.
O módulo arena-model contém todos os componentes de
negócio e de persistência de dados do Arena. Os EJB's deste
projeto estão contidos aqui, efetuando as operações de cada
fluxo lógico. A instanciação e o ciclo de vida destes objetos de
negócio são de responsabilidade do contêiner EJB, bem como
o tratamento de acessos concorrentes a estas instâncias.
Diferente dos outros módulos mostrados até aqui, este módulo
não é acessível publicamente através de HTTP, apenas
módulos residentes do Enterprise Archive (arquivo EAR[37])
podem fazer uso dos seus objetos de negócio, requisitando a
injeção de uma instância do objeto de negócio. O arena-model
interage com o gerenciador de entidades (EntityManager) da
parte de persistência da aplicação, provendo funcionalidades
básicas como listagem, atualização, remoção e salvamento
para cada tipo definido no domínio do Arena. As entidades,
embora salvas em uma base relacional, não são traduzidas
para código SQL[38] diretamente tampouco se faz uso de
JDBC[39] dentro do arena-model; usa-se mapeamentos JPA
entidade-relacional para abstrair a complexidade da mudança
de contexto objeto-relacional.
Outro módulo de negócio é o arena-mom. Este módulo
também é gerenciado pelo contêiner EJB e também possui
lógica de negócio, todavia a natureza dos objetos deste
módulo é assíncrona. São estes objetos os responsáveis de
receber notificações dos objetos do arena-model e efetuar
tarefas secundárias que usualmente não possuem garantias de
término. Especificamente o envio de emails de confirmação e
mensagens para a conta de twitter do Arena. Os objetos
assíncronos fazem parte do barramento da aplicação e
aguardam a ocorrência de novas mensagens no tópico do
barramento (BUS[40]) serem publicadas (pelos objetos do
outro módulo de negócio) e então a notificação é gerada. Os
objetos assíncronos recebem então a mensagem e os dados
desta são usados em suas tarefas específicas.
O módulo arena-client é um módulo de testes unitários.
Aqui vão classes de testes que garantem o correto
funcionamento de cada peça de código individualmente, desde
que tenha um teste escrito para esta peça. Testes funcionais
são escritos com Junit[41], um framework especializado de
testes que permite fazer medições precisas acerca de erros,
acertos e tempo consumido por cada mensagem de cada
objeto.
O último módulo é o arena-puj, que tem a função de
empacotar os outros módulos dentro dele na forma de EAR,
Enterprise Archive. Estes tipos de pacote são o que a
Especificação JEE recomenda como entregável final de
projetos Java enterprise. Ele não somente agrupa os outros
módulos, também define uma hierarquia de carregadores de
classe protegendo e isolando as definições de classes de cada
módulo umas das outras. Recursos como bibliotecas de
terceiros quando disponibilizadas dentro do EAR são também
disponibilizadas para os módulos nele contidos, pois tais
bibliotecas são incluídas no classloader[42] do pacote EAR,
que é o carregador de classes “pai” dos classloaders dos
outros módulos do Arena. De acordo com a especificação JEE,
cada módulo deve possuir seu classloader individual e estes
classloaders devem ter como classloader superior o
classloader do módulo EAR, que por sua vez tem o
classloader do contêiner de aplicações como superior.
Todo o código do Arena PUJ e seus módulos é distribuído
sob a licença “GNU Lesser General Public License”, que
garante o acesso aos fontes originais para todos que tiverem
acesso ao aplicativo executando. É uma licença que permite o
trânsito livre de desenvolvedores da comunidade no projeto
sem gerar a preocupação de apropriamento indevido do código
produzido sem manter os créditos do autor original.
V.CONCLUSÕES
O Arena PUJ serve para gerenciar (e promover) o PUJ,
Prêmio Universitário Java e testar as novas tecnologias JEE do
mercado por meio de um regime de desenvolvimento
colaborativo de código aberto, envolvendo a comunidade de
desenvolvedores Java do Ceará no processo. O modelo é
interessante enquanto regime de desenvolvimento além de ser
primoroso, tecnicamente falando, por sua gama de tecnologias
e baixa acoplação entre as camadas. É interessante notar como
a evolução da especificação JEE aproxima-se cada vez mais
da internet sem perder a capacidade de atender as redes
corporativas em analogia às versões anteriores da tecnologia.
REFERÊNCIAS BIBLIOGRÁFICAS
[1] CEJUG: Ceará Java User Group. Disponível em http://www.cejug.org.
Acessado em 01 de Março de 2010.
[2] LGPL: GNU Lesser General Public License. Disponível em
http://www.gnu.org/licenses/lgpl.html. Acessado em 01 de Março de 2010.
[3] Kenai: Project Kenai. Disponível em http://kenai.com/. Acessado em 01
de Março de 2010.
[4] JUG: Java User Group. Disponível em
http://java.sun.com/community/usergroups/. Acessado em 01 de Março de
2010.
[5] OpenId: OpenId Foundation. Disponível em http://openid.net/. Acessado
em 01 de Março de 2010.
[6] Oauth: Open Protocol to secure API authorization. Disponível em
http://oauth.net/. Acessado em 01 de Março de 2010.
[7] Twitter: Real-time Information Network. Disponível em
http://twitter.com/. Acessado em 01 de Março de 2010.
[8] Google Buzz: Real-Time Information Network. Disponível em
http://www.google.com/buzz. Acessado em 01 de Março de 2010.
[9] Cloud Computing:
[10] HTTP: Hyper Text Transfer Protocol. Disponível em
http://pt.wikipedia.org/w/index.php?
title=Hypertext_Transfer_Protocol&oldid=19085598. Acessado em 01 de
Março de 2010.
[11] REST: Representational State Transfer. Disponível em
http://pt.wikipedia.org/w/index.php?title=REST&oldid=18521273. Acessado
em 01 de Março de 2010.
[12] Hudson: Extensible Continuous Integration Server. Displnível em
http://hudson-ci.org/. Acessado em 01 de Março de 2010.
[13] Maven: Project Management and Build Automation Tool. Disponível em
http://en.wikipedia.org/w/index.php?title=Apache_Maven&oldid=341515281.
Acessado em 02 de Março de 2010.
[14] Mercurial: Distributed Source Control Management Tool. Disponível em
http://mercurial.selenic.com/. Acessado em 02 de Março de 2010.
[15] GIT: Distributed Version Control System. Disponível em http://gitscm.com/. Acessado em 02 de março de 2010.
[16] JEE: Java Enterprise Edition. Displnível em http://java.sun.com/javaee/.
Acessado em 02 de Março de 2010.
[17] SOAP: Simple Object Access Protocol. Disponível em
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/. Acessado em 02 de
Março de 2010.
[18] EJB: Enterprise Java Beans. Disponível em
http://java.sun.com/products/ejb/. Acessado em 02 de Março de 2010.
[19] SUN: Sun MicroSystems. Disponível em
http://en.wikipedia.org/w/index.php?
title=Sun_Microsystems&oldid=348174363. Acessado em 02 de Março de
2010.
[20] Glassfish: Reference Implementation Application Server. Disponível em
https://glassfish.dev.java.net/. Acessado em 02 de Março de 2010.
[21] JPA: Java Persistence API. Disponível em
http://java.sun.com/javaee/technologies/persistence.jsp. Acessado em 02 de
Março de 2010.
[22] EclipseLink: Eclipse Persistence Services Project. Disponível em
http://www.eclipse.org/eclipselink/. Acessado em 02 de Março de 2010.
[23] JSF: Java Server Faces. Disponível em
http://java.sun.com/javaee/javaserverfaces/. Acessado em 02 de Março de
2010.
[24] Mojarra: Project Mojarra. Disponível em
https://javaserverfaces.dev.java.net/. Acessado em 03 de Março de 2010.
[25] Jersey: Project Jersey. Disponível em https://jersey.dev.java.net/.
Acessado em 03 de Março de 2010.
[26] HTML: HyperText Markup Language. Disponível em
http://en.wikipedia.org/w/index.php?title=HTML&oldid=348178495.
Acessado em 03 de Março de 2010.
[27] JMS: Java Message Service. Disponível em
http://java.sun.com/products/jms/. Acessado em 03 de Março de 2010.
[28] Vaadin: Java Framework. Disponível em http://vaadin.com/home.
Acessado em 03 de Março de 2010.
[29] html5: HyperText Markup Language ver. 5. Disponível em
http://en.wikipedia.org/w/index.php?title=HTML5&oldid=347702904.
Acessado em 03 de Março de 2010.
[30] Javascript: ECMAScript Language. Disponível em http://www.ecmainternational.org/publications/files/ECMA-ST/ECMA-262.pdf. Acessado em
03 de Março de 2010.
[31] Vraptor: MVC Framework. Disponível em http://vraptor.caelum.com.br/.
Acessado em 04 de Março de 2010.
[32] html4: HyperText Markup Language ver. 4. Disponível em
http://www.w3.org/TR/1999/REC-html401-19991224/. Acessado dia 04 de
Março de 2010.
[33] RPC: Remote Procedure Call. Disponível em
http://en.wikipedia.org/w/index.php?
title=Remote_procedure_call&oldid=348142258. Acessado dia 04 de Março
de 2010.
[34] DWR: Direct Web Remoting. Disponível em
http://directwebremoting.org/dwr/index.html. Acessado dia 04 de Março de
2010.
[35] XML: eXtensible Markup Language. Disponível em
http://www.w3.org/XML/. Acessado dia 04 de Março de 2010.
[36] JSON: Javascript Object Notation. Disponível em http://www.json.org/.
Acessado dia 04 de Março de 2010.
[37] EAR: Enterprise Archive. Disponível em
http://en.wikipedia.org/w/index.php?
title=EAR_(file_format)&oldid=343489532. Acessado dia 04 de Março de
2010.
[38] SQL: Structured Query Language. Disponível em
http://en.wikipedia.org/w/index.php?title=SQL&oldid=347765204. Acessado
dia 04 de Março de 2010.
[39] JDBC: Java Database Connectivity. Disponível em
http://java.sun.com/javase/technologies/database/. Acessado dia 04 de Março
de 2010.
[40] BUS: Enterprise Service BUS. Disponível em
http://en.wikipedia.org/w/index.php?
title=Enterprise_service_bus&oldid=347926583. Acessado dia 04 de Março
de 2010.
[41] Junit: Unit Tests. Disponível em http://www.junit.org/. Acessado dia 04
de Março de 2010.
[42] Classloader: Java Class Loader. Disponível em
http://en.wikipedia.org/w/index.php?
title=Java_Classloader&oldid=343512895. Acessado dia 04 de Março de
2010.