Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails

UNIVERSIDADE DO SUL DE SANTA CATARINA

GUILHERME SERNA MARTINS
MARCOS NUNES DE CASTRO

COMPARAÇÃO DE TECNOLOGIAS PARA WEB
JBOSS SEAM E RUBY ON RAILS

Tubarão
2010

GUILHERME SERNA MARTINS
MARCOS NUNES DE CASTRO

COMPARAÇÃO DE TECNOLOGIAS PARA WEB
JBOSS SEAM E RUBY ON RAILS

Trabalho de Conclusão de Curso apresentado
ao Curso de graduação em Ciência da
Computação/Sistema de Informação, da
Universidade do Sul de Santa Catarina, como
requisito parcial para obtenção do título de
Bacharel.em Sistemas de Informação/Ciência
da Computação.

Universidade do Sul de Santa Catarina

Orientador Profº. Eder Cachoeira

Tubarão
2010

AGRADECIMENTOS

Eu Guilherme, gostaria primeiramente de agradecer a Deus por me dar a oportunidade
de poder estar concluindo meus estudos. Quero deixar registrado meu eterno agradecimento
aos meus avós, Antonio Ruiz e Adair Ricardo Serna, pessoas especiais enviadas por Deus que
tanto me ajudam e que sem o apoio não poderia estar concluindo esta graduação.
Agradecer também a minha esposa Mayaha Barjona Martins que há cinco anos tem se
mostrado companheira, compreensiva e que eu muito amo e ao meu filho Arthur que torna
minha família completa.
Agradecer também a todos os professores que tornaram isto uma realidade.
Eu Marcos, agradeço todos meus familiares e amigos que me ajudaram na conclusão
deste projeto, e principalmente ao meu pai Claudionor e minha mãe Dulcemar pelo grande
incentivo e apoio dado a todo o momento nesta importante fase de minha vida.

RESUMO

Este projeto apresentará a comparação de dois frameworks para desenvolvimento de
aplicações web. O Primeiro é o framework JBoss Seam, escolhido devido a sua linguagem
base ser Java, linguagem essa muito bem consolidado, difundida e utilizada.
O outro framework se chama Ruby on Rails, que apesar de ser uma linguagem nova,
vem recebendo muitos elogios, que na maioria das vezes, se referem às facilidades que o
framework oferece. Para realizar as comparações, foi modelada uma aplicação e desenvolvida
utilizando-se os dois frameworks, Jboss Seam e Ruby on Rails. As comparações serão
avaliadas em curva de aprendizado, tempo de desenvolvimento, facilidade de manutenção,
performance e tamanho do código.

Palavras-Chave: Ruby, Ruby on Rails, Java, Jboss Seam, Framework, Aplicações web.

ABSTRACT

This project will present a comparison of two frameworks for web developing applica-
tions. The first framework is the JBoss Seam, chosen because its language is based on Java, a
language that very well established, disseminated and used.
The other framework called Ruby on Rails, which despite being a new language, has
received many accolades, which most often, refers to facilities that the framework offers. To
make comparisons, was modeled and developed an application using the two frameworks,
JBoss Seam and Ruby on Rails. The comparisons will be evaluated on the learning curve, de-
velopment time, maintainability, performance and code size.

Keywords: Ruby, Ruby on Rails, Java, JBoss Seam, Framework, Web applications.

LISTA DE GRÁFICOS

Gráfico 1 – Tempo de resposta na realização do login. Elaboração dos autores, 2010............63
Gráfico 2 – Utilização do processador na realização do login. Elaboração dos autores, 2010.63
Gráfico 3 – Tempo de resposta na realização do logout. Elaboração dos autores, 2010..........64
Gráfico 4 - Utilização do processador na realização do logout. Elaboração dos autores, 2010.
...................................................................................................................................................65
Gráfico 5 – Tempo de resposta na criação de um serviço. Elaboração dos autores, 2010........66
Gráfico 6 – Utilização do processador na criação de um serviço. Elaboração dos autores,
2010...........................................................................................................................................66
Gráfico 7 – Média do tempo de resposta na criação de um serviço. Elaboração dos autores,
2010...........................................................................................................................................67
Gráfico 8 - Média do tempo de resposta na criação de um serviço. Elaboração dos autores,
2010...........................................................................................................................................67
Gráfico 9– Tempo de resposta na contratação de um serviço. Elaboração dos autores, 2010.. 68
Gráfico 10 – Utilização do processador na contratação de um serviço. Elaboração dos autores,
2010...........................................................................................................................................69
Gráfico 11 – Tempo de resposta na criação de um usuário. Elaboração dos autores, 2010......70
Gráfico 12 – Utilização do processador na criação de um usuário. Elaboração dos autores,
2010...........................................................................................................................................70
Gráfico 13 – Tempo de resposta na criação de cem usuários. Elaboração dos autores, 2010.. 71
Gráfico 14 – Utilização do processador na criação de cem usuários. Elaboração dos autores,
2010...........................................................................................................................................72
Gráfico 15 – Tempo de resposta na criação de cem serviços. Elaboração dos autores, 2guatda.com/cmx.p010...72
Gráfico 16 – Utilização do processador na criação de cem serviços. Elaboração dos autores,
2010...........................................................................................................................................73
Gráfico 17 – Tempo de resposta na criação de mil serviços. Elaboração dos autores, 2010....74
Gráfico 18 – Utilização do processador na criação de mil serviços. Elaboração dos autores,
2010...........................................................................................................................................74
Gráfico 19 – Tempo de resposta na criação de mil serviços. Elaboração dos autores, 2010....75
Gráfico 20 – Utilização do processador na criação de mil usuários. Elaboração dos autores,
2010...........................................................................................................................................75
Gráfico 21 – Média do tempo de resposta na criação de cem usuários. Elaboração dos autores,
2010...........................................................................................................................................79
Gráfico 22 – Média do tempo de resposta na criação de mil usuários. Elaboração dos autores,
2010...........................................................................................................................................79
Gráfico 23 – Média do tempo de resposta na criação de cem serviços. Elaboração dos autores,
2010...........................................................................................................................................80
Gráfico 24 – Média do tempo de resposta na criação de mil serviços. Elaboração dos autores,
2010...........................................................................................................................................81

LISTA DE ILUSTRAÇÕES

Figura 1– Funcionamento do Compilador. Fonte: Azambuja (2004, p1).................................21
Figura 2– Funcionamento do Interpretador. Fonte: Azambuja (2004, p1)................................23
Figura 3 – Caso de Uso de Empresa. Fonte: Nossa (2010).......................................................86
Figura 4 – Caso de Uso de Cliente. Fonte: Nossa (2010).........................................................86
Figura 5 – Mapa do site. Fonte: Nossa (2010)..........................................................................91
Figura 6 – Tela de login. Fonte: Nossa (2010)..........................................................................92
Figura 7 – Tela de registro. Fonte: Nossa (2010)......................................................................93
Figura 8 – Tela inicial do usuário Empresa. Fonte: Nossa (2010)............................................94
Figura 9 – Tela para criar novo Serviço (Usuário Empresa). Fonte: Nossa (2010)..................94
Figura 10 – Tela para ver os Serviços oferecidos (Usuário Empresa). Fonte: Nossa (2010)....95
Figura 11 – Tela para ver Clientes (Usuário Empresa). Fonte: Nossa (2010)...........................95
Figura 12 – Tela inicial do usuário Cliente. Fonte: Nossa (2010)............................................96
Figura 13 – Tela para solicitar novo Serviço(usuário Cliente). Fonte: Nossa (2010)...............96
Figura 14 – Tela para ver os Serviços solicitados(usuário Cliente). Fonte: Nossa (2010).......97

LISTA DE QUADROS

Quadro 1 - Exemplo C++ e Delphi – Fonte Roesler (2010, p1)...............................................21
Quadro 2 - Exemplo Pascal e Visual Basic6 – Fonte Roesler (2010, p1).................................22
Quadro 3 - Exemplo Java e Ruby – Fonte Roesler (2010, p1).................................................23
Quadro 4 - Exemplo PHP e Python – Fonte Roesler (2010, p1)..............................................24
Quadro 5 - Exemplo Basic e Euphoria – Fonte Roesler (2010, p1).........................................25
Quadro 6 - Exemplo Lua e ActionScript – Fonte Roesler (2010, p1)......................................25
Quadro 7 - Exemplo de Comparação Java x Ruby – Elaboração dos autores, 2010................45
Quadro 8 - Exemplo de legibilidade de código Ruby on Rails – Elaboração dos autores, 2010
...................................................................................................................................................50
Quadro 9 – Script de criação do scaffold em Ruby on Rails – Elaboração dos autores, 2010. 50
Quadro 10 – Comando de migração para o banco de dados – Elaboração dos autores, 2010..50
Quadro 11 - Exemplo de Comparação Java x Ruby – Elaboração dos autores, 2010..............53
Quadro 12 Script para instalar plugin – Elaboração dos autores, 2010....................................53
Quadro 13 – Código para filtrar extensões de arquivos do paperclip – Elaboração dos autores,
2010...........................................................................................................................................54
Quadro 14 – Script para instalar plugin – Elaboração dos autores, 2010.................................54
Quadro 15 – Configuração do servidor de e-mail em Ruby on Rails – Elaboração dos autores,
2010...........................................................................................................................................54
Quadro 16 Configuração de envio de e-mail em Ruby on Rails – Elaboração dos autores,
2010...........................................................................................................................................55
Quadro 17 – Exemplo de mensagem a ser enviada em Ruby on Rails – Elaboração dos
autores, 2010.............................................................................................................................55
Quadro 18 – Exemplo de e-mail enviado em Ruby on Rails – Elaboração dos autores, 2010.56
Quadro 19 Comando para enviar e-mail em Ruby on Rails – Elaboração dos autores, 2010. .56
Quadro 20 - Exemplo da configuração do serviço de e-mail– Elaboração dos autores, 2010..57
Quadro 21 - Exemplo do método de envio de e-mail– Elaboração dos autores, 2010.............57
Quadro 22 - Exemplo do arquivo de renderização de e-mails – Elaboração dos autores, 2010
...................................................................................................................................................59
Quadro 23 - Exemplo do e-mail gerado – Elaboração dos autores, 2010.................................59
Quadro 24 - Exemplo do arquivo da view – Elaboração dos autores, 2010.............................60
Quadro 25 - Exemplo do método para download – Elaboração dos autores, 2010..................60
Quadro 26 – Configuração dos ambientes de desenvolvimento. Elaboração dos autores, 2010.
...................................................................................................................................................62
Quadro 27 - Métricas do ambiente de desenvolvimento Ruby on Rails. Elaboração dos
autores, 2010.............................................................................................................................76
Quadro 28 - Métricas do ambiente de desenvolvimento Jboss Seam. Elaboração dos autores,
2010...........................................................................................................................................76
Quadro 29 – Quadro de Conclusões. Elaboração dos autores, 2010........................................82
Quadro 30 - Requisitos F1 – Elaboração dos autores, 2010....................................................87
Quadro 35 - Requisitos F6 – Elaboração dos autores, 2010.....................................................88

Quadro 38 - Referencias Cruzadas – Elaboração dos autores, 2010.......................................90

SUMÁRIO

1.1.1 Objetivo Geral..........................................................................................................13
1.1.2 Específicos...............................................................................................................13
1.2 JUSTIFICATIVA.............................................................................................................14
1.3 RESUMO DA METODOLOGIA PARA DESENVOLVIMENTO DO TRABALHO. .15
1.5 DESCRIÇÃO DO DOCUMENTO.................................................................................16
6.1 APACHE HTTP SERVER..............................................................................................35
6.2 TOMCAT........................................................................................................................36
6.3 JBOSS.............................................................................................................................36
7.1 JBOSS SEAM.................................................................................................................40
7.2 RUBY ON RAILS..........................................................................................................42
11.4 Performance..................................................................................................................61
11.4.1 Teste - Login...........................................................................................................62
11.4.2 Teste – Logout........................................................................................................64
11.4.4 Teste – Contratar Serviço.......................................................................................68
11.4.5 Teste - Criar Usuário..............................................................................................70
11.4.6 Teste – Criar 100 Usuários.....................................................................................71
11.4.7 Teste – Criar 100 Serviços......................................................................................72
11.4.8 Teste – Criar 1000 Serviços....................................................................................73
11.4.9 Teste – Criar 1000 Usuários...................................................................................75

12

1 INTRODUÇÃO

Com o passar do tempo novas tecnologias vão sendo criadas, e com elas sempre
surgem novidades. Este processo ocorre desde os primeiros computadores e linguagens de
programação, e para cada nova tecnologia apresentada, existem pessoas interessadas em
estudá-las e analisá-las para sua experiência própria ou mesmo para substituir a sua tecnologia
atual. Foi assim desde as linguagens de programação ADA1, Fortran (1954), COBOL (1959),
etc.
Neste projeto, foi realizado um comparativo de duas tecnologias presentes
atualmente. JBoss Seam destaca-se por ser uma tecnologia baseada na plataforma Java EE e
por ser um framework que está contribuindo e investindo através de seus conceitos para o
desenvolvimento da plataforma JEE (JSR-299). JBoss Seam tem como objetivo eliminar a
complexidade existente na integração de frameworks como Java Server Faces, Java
Persistence, Enterprise Java Beans, AJAX, permitindo ao desenvolvedor focar-se na
implementação do negócio e abstraindo-o da árdua tarefa de realizar a integração entre as
tecnologias empregadas. Em contra partida encontramos Ruby On Rails, um framework2
gratuito e aberto que teve seu inicio em meados de 2004 e foi escrito na linguagem de
programação Ruby, linguagem esta que foi idealizada em 1993 em um bate-papo on-line
informal entre Matsumoto (Matz) e Keiju Ishitsuka, e destaca-se cada vez mais por tornar
fácil o desenvolvimento de aplicações para web.

1
Nome dado por Charles Babbage, o idealizador do computador em homenagem a sua esposa e programadora
Ada Lovelace.
2
Framework - “Um framework provê uma solução para uma família de problemas semelhantes Usando um
conjunto de classes e interfaces que mostra como decompor a família de problemas.” (Sauvé, 2010, p.1)

13

1.1 OBJETIVOS

1.1.1 Objetivo Geral

Apresentar um estudo comparativo dos frameworks Jboss Seam e Ruby on Rails
para desenvolvimento de aplicações Web.

1.1.2 Específicos

•Pesquisar técnicas de desenvolvimento de aplicações em JBoss Seam;
•Pesquisar técnicas de desenvolvimento de aplicações em Ruby on Rails;
•Realizar a comparação entre as tecnologias nos seguintes quesitos: Curva de
aprendizado, Tempo de desenvolvimento, Facilidade de manutenção, Performance e
Tamanho do código;
•Modelar uma aplicação e implementá-la em ambos os frameworks;
•Apresentar resultados alcançados e discuti-los;

14

1.2 JUSTIFICATIVA

Java é uma das principais linguagens de programação utilizada pela comunidade
de desenvolvimento do mundo todo e se destaca cada vez mais por ser uma linguagem
gratuita e com abrangente fonte de pesquisa na sua API e comunidades seguidoras.
Mas será que devemos ficar apenas nesse pensamento e deixar as outras
tecnologias vagando pela internet sem ao menos tentar achar alternativas de desenvolvimento,
quem sabe, melhor do que a você usa?
Pensando nisso resolvemos escolher dois frameworks de linguagens distintas para
realizar uma pesquisa fundamentada e após elaborar um comparativo sólido entre essas duas
tecnologias e destacar os seus pontos fortes e fracos.
Em Java, o framework escolhido foi o JBoss Seam. O principal motivo para a sua
escolha foi devido ao fato de o mesmo ser o principal responsável pela implementação da
JRS-299(Java Context and Dependency Injection). Muitas das idéias originadas com o
desenvolvimento deste framework estão sendo analisadas para tornar-se um padrão de
desenvolvimento na Plataforma JEE através desta JRS (Java Specification Requests). Várias
empresas como, Apache Software Foundation, Google Inc, Red Hat, Intel entre outras
gigantes do meio deram seu parecer aprovando este padrão de desenvolvimento.
Depois do JBoss Seam, o outro framework escolhido para a elaboração deste
projeto foi a Ruby on Rails, que vem se popularizando por ser conhecida como uma grande
ajudante no desenvolvimento de aplicativos para web com sua tão citada facilidade e
agilidade no seu desenvolvimento.
Para uma melhor distinção, temos de início o intuito de desenvolver um software
com as mesmas funcionalidades em ambas as linguagens, com isso ter-se-á um melhor
embasamento para a elaboração das conclusões.

15

1.3 RESUMO DA METODOLOGIA PARA DESENVOLVIMENTO DO TRABALHO

• Realizar estudo dos frameworks Jboss Seam e Ruby on Rails e suas linguagens, Java e
Ruby.
• Desenvolver uma aplicação para a comparação dos frameworks supracitados.
• Comparar os frameworks..

Mais detalhes sobre a metodologia utilizada será abordado no tópico 4.1.

16

1.4 RESULTADOS ESPERADOS

Os resultados esperados são:

• Obter através do desenvolvimento do aplicativo, subsídios para identificar a melhor
linguagem de programação para o nosso projeto proposto.
• Descobrir através da fase de desenvolvimento, facilidades que as linguagens nos
proporcionam na comparação JBoss Seam e Ruby on Rails.
• Realizar uma tabela com várias características e mensurá-las de acordo com os
benchmarks realizados durante o processo de desenvolvimento e execução.

1.5 DESCRIÇÃO DO DOCUMENTO

Capítulo 1: Introdução sobre o que o projeto irá abordar, os objetivos gerais e específicos,
justificativas, resumo da metodologia a ser seguida para a conclusão do projeto e os resultados
esperados.

Capítulo 2: Este capítulo irá fazer uma introdução a linguagem de programação e mostrar os
seus diferentes tipos.

Capítulo 3: Este capítulo mostrará a linguagem de programação Java.

Capítulo 4: Este capítulo mostrará a linguagem de programação Ruby.

Capítulo 5: Aqui irá falar sobre estrutura MVC.

Capítulo 6: Neste capítulo será abordado sobre os servidores web.

Capítulo 7: Explicará o que é framework, e mostrará os dois frameworks utilizados neste
projeto (Jboss Seam e Ruby on Rails).

Capítulo 8: Uma pequena tabela mostrará algumas características das linguagens Java e
Ruby.

17

Capítulo 9: Aqui será mostrado os pontos importantes que serão usados na comparação dos
frameworks JBoss Seam e Ruby on Rails, como curva de aprendizado, tempo de
desenvolvimento, facilidade de manutenção, performance e tamanho do código.

Capítulo 10: Este capítulo explana a metodologia utilizada para a comparação entre os
frameworks JBoss Seam e Ruby on Rails.

Capítulo 11: Neste capítulo está os resultados detalhados obtidos na comparação entre JBoss
Seam e Ruby on Rails.

Capítulo 12: Conclusões sobre a comparação realizada entre os frameworks JBoss Seam e
Ruby on Rails.

Capítulo 13: Aqui estão listados os trabalhos futuros pretendidos pelos autores.

18

2 INTRODUÇÃO A LINGUAGEM DE PROGRAMAÇÃO

O primeiro projeto de linguagem de programação na verdade era um algoritmo 3 que
permitia cálculos de funções matemáticas que foi desenvolvido pela inglesa Ada Lovelace
durante um período de nove meses entre os anos de 1842 e 1843, para um computador que
ainda estava sendo criado por Charles Babbage, e que recebeu o nome de ADA em
homenagem a esta programadora. Uma das primeiras linguagens de programação realmente
para computadores foi provavelmente Plankalkül (1945), criada por Konrad Zuse na
Alemanha Nazista
Conforme Faccat (2009, p.1):
Konrad Zuse percebeu que ainda não existia uma notação formal para a descrição de
algoritmos e começou a trabalhar em uma. O resultado foi uma linguagem chamada
Plankalkül (program calculus), uma extensão do cálculo proposicional e de
predicado de Hilbert.

Plankalkül já possuía chamadas da função (sub-rotinas), instruções condicionais,
estrutura de repetição (iteração), aritmética de ponto flutuante, matrizes (arrays), tipos de
dados compostos, tratamento de exceção, dentre outras características, mas que não teve
muito sucesso.
Para Fialho Jr (2002, p.123), Linguagem de Programação se define como:
Uma seqüência de linhas de instruções escritas por um programador, que são dadas
ao computador para que possa executar as tarefas solicitadas por estas instruções. As
linguagens de programação normalmente são escritas de forma compreensível pelos
seres humanos, porém devem passar por um compilador4 ou interpretador5 para
serem convertidas para uma linguagem de baixo nível, denominada linguagem de
maquina6 ou código de maquina, para que o computador possa entender as
instruções e, assim, executá-las.

Uma linguagem de programação é então um conjunto de palavras, compostas por
regras sintáticas e semânticas interpretável pela máquina, que permite ao programador que
informe ou especifique os comandos que o computador irá executar em determinadas ações

3
Um algoritmo é um conjunto determinístico de instruções que cumprem alguma tarefa, na qual partindo de um
estado inicial chegam a um determinado estado final. (Wangenheim, 2010, p.3)
4
Compilador é um tradutor que mapeia um programa escrito em linguagem de alto nível para um programa
equivalente em uma linguagem simbólica ou linguagem de maquina (Price & Toscane 2001, p.4).
5
Interpretador – Programa responsável pela conversão e posterior execução das instruções de um programa
que tenha sido escrito num tipo de linguagem interpretada. (Fialho JR, 2002, p.117).
6
Linguagem de máquina – “Trata-se de uma seqüência de instruções em códigos binários, totalmente
compreensível pelo computador [...] é o resultado obtido após a compilação ou interpretação que se faz de um
código fonte.” (Fialho Jr, 2002, p.123).

19

ou circunstancias. Estes conjuntos de palavras são denominados de “tokens” que se
adequados às regras impostas pelas linguagens se transformam em códigos-fonte 7, que por sua
vez é traduzido para linguagem de maquina, que nada mais são do que números binários
(“zeros” e “uns”) interpretados pelo processador, conhecido como linguagem de baixo nível.
Segundo Icea(2009, p.2), a linguagem de maquina “É constituída inteiramente de
números, o que torna praticamente impossível entendê-la diretamente. Cada CPU tem seu
conjunto único de linguagem de máquina, definido pelo fabricante do chip”.
Um dos principais objetivos da linguagem de programação é permitir que os
programadores tenham uma maior produtividade, criando condições para que eles interajam
mais facilmente com a máquina.
No decorrer dos tempos as linguagens de programação foram sofrendo diversas
modificações, onde muitas dessas ficaram desatualizadas a realidade computacional em
termos de hardware e outros artefatos que deixaram de existir, surgindo então as linguagens
de alto nível, com funções semelhantes ao idioma humano e de fácil entendimento. A primeira
linguagem de programação de alto nível amplamente usada foi Fortran, criada em 1954.
Em 1957 foi criada B-0, que daria origem a Flow-Matic (1958), antecessor imediato
de COBOL, de 1959. Lisp e ALGOL foram criadas em 1958. Prolog e Pascal começaram em
1970, C++ em 1983 seguido de Perl em 1987. Java teve seu inicio com o nome de Oak em
1991 que recebeu seu nome atual em 1995 com o Java 1. Ruby começou em 1993,
desenvolvido pelo japonês Yukihiro Matsumoto (Matz).

No capítulo a seguir serão mostrados os tipos existentes de linguagens de
programação, citando e exemplificando as mais populares.

2.1 TIPOS DE LINGUAGENS

As linguagens são definidas em basicamente três tipos, são eles:
• Linguagem compilada

7
Código-fonte são as linhas de programação que formam um software em sua forma original. Inicialmente, um
programador "escreve" o programa em uma certa linguagem —como C++ ou Visual Basic. (Folha Online, p. 1)

20

• Linguagem interpretada
• Linguagem de script

2.1.1 Linguagem Compilada

Segundo Nguyen (2009, p.1), “Uma linguagem compilada é uma linguagem que
requer um compilador para transformar o código fonte de programação em um programa
binário8 executável na linguagem de máquina [...]”.
O código fonte é traduzido para linguagem de máquina através do processo de
compilação e executado diretamente pelo sistema operacional ou pelo processador, usando um
programa de computador chamado compilador, para uma linguagem de baixo nível
(Programas Binários), ou seja, não existe nenhum tipo de interpretador neste tipo de
linguagem, tornando esse tipo de processamento muito mais rápido do que nas linguagens
interpretadas. A figura 1 mostra como é feito este processo de compilação, onde o código
fonte (Programa Fonte) é traduzido para linguagem de máquina (Programa Objetivo).

8
Sistema Binário é um Sistema numérico empregado em tecnologia digital, representado por dois valores: 0 e
1. (Fialho 2002, p.170).

21

Programa Fonte

Analisador Léxico

Analisador Sintático

Analisador
Semântico e Gerador Otimizador
Tabela de Símbolos
de Código
Intermediário

Gerador de Código

Programa Objetivo
Figura 1– Funcionamento do Compilador. Fonte: Azambuja (2004, p1)

Alguns exemplos de linguagens compiladas são:
• Ada • Delphi
• BASIC • Fortran
• C • Pascal
• C++ • Visual Basic
• COBOL • Visual Prolog
• Cobra

Exemplo simples de código fonte de algumas linguagens de programação compilada:
C++ Delphi
main() Begin
{ WriteLn('Hello World');
cout << "Hello World!" << endl; End.
return 0;
}
Quadro 1 - Exemplo C++ e Delphi – Fonte Roesler (2010, p1)

22

Pascal Visual Basic6
program HelloWorld(output); Private Sub Form_Load()
begin Print "Hello World"
WriteLn('Hello World!'); End Sub
end.
Quadro 2 - Exemplo Pascal e Visual Basic6 – Fonte Roesler (2010, p1)

Podemos citar como um exemplo neste tipo de linguagem o programa desenvolvido
em Delphi pela Sigma-Aldrich9, uma empresa de alta tecnologia, no setor de Ciências.
De acordo com Borland (2009, p.1), O programa desenvolvido é utilizado por seus
bioquímicos e biólogos na investigação científica e genomica, biotecnologia, farmacêutica,
em diagnósticos de doenças e identificação dos principais componentes de produtos
farmacêuticos e outros de alta tecnologia. A Companhia possui diversos clientes como
universidades, instituições governamentais, hospitais e indústrias.
Mais de um milhão de cientistas e tecnólogos utilizam seus produtos. A Companhia
atende mais de 150 países a partir de suas operações em 36 países
e possui 7.600 empregados proporcionando excelentes serviços a nível mundial.

2.1.2 Linguagem Interpretada

Linguagem interpretada é uma linguagem de programação, onde o código fonte não é
somente executado pelo compilador e sim por um programa de computador chamado
interpretador. O compilador lê o código-fonte e o interpreta diretamente durante o seu
processamento, avaliando o código e executando as operações (instruções digitadas pelo
programador) nele descritas. Em seguida é executado pelo sistema operacional ou
processador, por este fato as linguagens interpretadas em geral têm uma eficiência muito
menor do que as linguagens compiladas tradicionais.
A execução é de 10 a 100 vezes mais lenta do que em programas compilados. Além
disso, a solução como um todo normalmente ocupa bem mais espaço, pois além do
fonte do programa, é necessário o interpretador e muitas vezes uma série de outras
bibliotecas disponíveis, em cada máquina onde o programa for executado
(Azambuja, 2004).

A Figura 2 mostra como é feito este processo de Interpretação do Código Fonte.

9
Disponível em <http://www.sigma-aldrich.com>. Acesso em: 20 mai 2009.

23

Programa Fonte

Analisador Léxico

Analisador Sintático

Tabela de Símbolos Analisador Semântico

Interpretaçã
o
Figura 2– Funcionamento do Interpretador. Fonte: Azambuja (2004, p1)

Mesmo que um código em uma linguagem passe pelo processo de compilação, a
linguagem pode ser considerada interpretada, se o programa resultante não for executado
diretamente pelo sistema operacional ou processador.

Alguns exemplos de linguagens interpretadas são:
• ActionScript • PHP
• C# • Python
• Java • Ruby
• JavaScript • Scheme
• Lua • Smalltalk

Exemplo simples de código fonte de algumas linguagens de programação interpretada:
Java Ruby
class HelloWorld {
static public void main( String args[] ) {
System.out.println( "Hello World!" ); puts "Hello World!"
}
}
Quadro 3 - Exemplo Java e Ruby – Fonte Roesler (2010, p1)

24

PHP Python
<?php
echo 'Hello World!'; print "Hello World"
?>
Quadro 4 - Exemplo PHP e Python – Fonte Roesler (2010, p1)

Como exemplo de soluções com essas linguagens, podemos citar o caso de A.B.
Watley10, na qual tem como negocio serviços financeiros.
Segundo Huston(2009 SUN, p.1, tradução nossa), “Nossa nova tecnologia, tem
permitido a Watley competir como uma empresa completamente nova. Uma grande parte de
nosso sucesso nos serviços financeiros B2B deve-se a qualidade de nossos softwares e a nossa
migração de nossos sistemas do NT para o UNIX com o Sistema operacional Solaris. Nossa
plataforma UNIX e arquitetura empresarial claramente nos diferenciam das grandes empresas
corretoras e bancos”.
As tecnologias empregada nesta evolução de arquitetura foram, o Ambiente de
desenvolvimento Java, juntamente com outros produtos criados com esta tecnologia, por
exemplo, Sistema Operacional Solaris - Aplicações client-side desenvolvidas por A.B.Watley
sendo 100% puro Java client-side entre outras tecnologias da Sun.

2.1.3 Linguagem De Script

Linguagem de Script (também conhecido como linguagem de scripting, ou linguagem
de extensão) é uma linguagem de programação desenvolvida para um aplicativo específico
que é executado no interior de programas e/ou de outras linguagens de programação, não se
restringindo a esses ambientes.
Segundo Capron (2004 citado por Herculiani , 2007, p.40):

Linguagens de scripts representam uma forma nova de se programar. Nestas
linguagens é assumida a existência de um conjunto de componentes já
desenvolvidos em outras linguagens, de forma que o objetivo destas linguagens
passa a ser o de combinar estes componentes e não o de desenvolver programas a
partir de estruturas de dados elementares. Por esta razão, as linguagens de scripts são
também chamadas de linguagens de colagem 11 (glue languages) ou de linguagens de
integração se sistemas (system integration languages).

10
Disponível em < http://www.abwatley.com/>. Acesso em 20 mai 2009.
11
Linguagem de Colagem (Glue Language) Uma linguagem de colagem é usado para mesclar vários programas
em um único aplicativo. (Flynt (2003), Tradução nossa).

25

As linguagens de script servem para estender a funcionalidade de um programa e/ou
controlá-lo, acessando sua API e, são freqüentemente usadas como ferramentas de
configuração e instalação.
Todas as linguagens de script são linguagens interpretadas, porém, nem todas as
linguagens interpretadas são linguagens de script. Os programas escritos em linguagens de
script são, normalmente, referidos como scripts.
Alguns exemplos de linguagens de Script são:
• ActionScript • Lua
• BASIC • PHP
• C • Python
• Euphoria • Ruby
• JavaScript • Tcl

Exemplo simples de código fonte de algumas linguagens de programação script:
BASIC Euphoria
PRINT "Hello World!" puts(1, "Hello World!")
Quadro 5 - Exemplo Basic e Euphoria – Fonte Roesler (2010, p1)

Lua ActionScript
print "Hello world" trace ("Hello World");
Quadro 6 - Exemplo Lua e ActionScript – Fonte Roesler (2010, p1)

Este tipo de linguagem é usado para softwares pequenos produzidos em tempo curto
para fins específicos e relativamente simples.

O próximo tópico abordará a linguagem base para o framework JBoss Seam.

3 LINGUAGEM DE PROGRAMAÇÃO JAVA

26

Java, inicialmente chamada de OAK (tradução do inglês "Carvalho") foi criada por
James Gosling. Algum tempo depois foi descoberto que já havia uma linguagem chamada
Oak, então foi trocado para Java, seu nome atual. Teve seu desenvolvimento iniciado em 1991
com a Sun Micro systems em um projeto de codinome Green.
A principio a linguagem não teve grande sucesso devido à falta de mercado, pois o
setor eletrônico não se desenvolvia tanto quanto era esperado e o foco central da linguagem
naquele momento era a programação de produtos eletrônicos. No entanto, em 1993 com a
popularidade da internet a Sun viu um grande potencial para a linguagem que era a criação de
conteúdo dinâmico em paginas para internet.
Em 1995 a Sun anunciou formalmente a linguagem Java. Segundo JAVAFREE (2010,
p.1), “Desde seu lançamento, em maio de 1995, a plataforma Java foi adotada mais
rapidamente do que qualquer outra linguagem de programação na história da computação”.
Java é uma linguagem que possuem muitas características atrativas ao programador
como, por exemplo, Orientação a objetos. O modelo de Orientação a objetos do Java foi
baseado nas linguagens Smalltalk e Simula67. A Orientação a objetos é um paradigma de
análise, projeto e programação de sistemas de software onde o programador com esta nova
perspectiva começa a lidar não mais com uma programação sistemática e seqüencial mas sim
com a programação de objetos isolados que possuem atributos e métodos próprios e que
trabalham em harmonia para executar tarefas complexas e alcançar um resultado final. Outra
característica importante da linguagem Java é a sua portabilidade, que por trata-se de uma
linguagem interpretada, possui a capacidade de ser executada em qualquer ambiente
operacional que suporte a sua plataforma.
Trata-se de uma linguagem atualmente muito utilizada e contando com muitos canais
de acesso a informações, provendo aos programadores suporte para suas APIs. Javafree
(2009, p.1) diz que, “Atualmente Java é uma das linguagens mais usadas e serve para
qualquer tipo de aplicação, entre elas: web, desktop, servidores, mainframes, jogos, aplicações
móveis, chips de identificação, etc.”.
Java devido ao seu alto grau de maturidade possui muitas bibliotecas (APIs) com
diversas funcionalidades para os mais diversos tipos de ambientes e problemas, por exemplo
temos a disponibilidade de desenvolver aplicativos desde para um aparelho domestico como
microondas até um aparelho celular. Muitas APIs já estão implementadas para facilitar o
desenvolvimento de aplicações, APIs referentes a conexões de rede, conexões com banco de
dados, interfaces gráficas, gráficos 2d,3d, para aplicativos multimídia e muitas outras
funcionalidades.

27

JVM (Java Virtual Machine) é o interpretador java, que possibilita ao Java o poder de
ser uma linguagem multi-plataforma "write once, run anywhere", ou seja, uma vez
desenvolvido a aplicação a JVM conseguirá executá-lo em qualquer ambiente.

Generalizando e ignorando as diferenças entre implementações e versões, a JVM
roda realizando o Garbage Colection quando há a necessidade de mais memória para
a execução. Durante a execução, o programa pode perder a referencia á determinado
objeto – tornando este objeto um candidato a exclusão. Não há garantia que a JVM
irá liberar a memória. (Devdaily, 2009, p.1).

Java possui uma tecnologia chamada Garbage Colector12 (Coletor de Lixo), que
proporciona ao sistema que esta executando a aplicação Java uma melhor estabilidade. Esta
estabilidade é adquirida pois a JVM gerencia toda a memória alocada para determinado
programa em execução e quando determinado espaço de memória não é mais necessário para
o programa, este espaço é limpo e passa a ser utilizado para outro dado se necessário. Esta
tarefa é efetuada automaticamente pelo Garbage Colection.
Outras linguagens como C++ por exemplo, deixavam esta tarefa com o programador
que tinha que se preocupar em criar mecanismos que realizassem esta tarefa em runtime.
Podemos dividir a plataforma Java em três edições, J2SE, JEE e J2ME.
Segundo a Sun (2009, p.1, tradução nossa), “A plataforma Java SE é a plataforma para
rápido desenvolvimento e implantação de aplicações seguras, portáveis que rodam no servidor
e ou vários sistemas operacionais.”.
J2SE trata-se da Standard Edition OU JAVA SE. Cada edição conta com uma JVM,
API e ferramentas próprias para esta versão.
O JEE (Java Enterprise Edition) é adaptada para aplicações multicamadas baseadas em
componentes que são executados em um servidor de aplicação.
J2ME (Java Plataforma Micro Edition) é a plataforma desenvolvida para ser
introduzida em dispositivos de propósitos específicos, por exemplo, celulares, pdas, controles
remotos entre outros. Esta plataforma assim como as outras também possui um JVM e APIs e
ferramenta próprias.

O próximo capítulo irá falar sobre a edição da linguagem Java voltada para web,
conhecida como JEE.

12
Garbage Collections é o processo que automaticamente libera objetos que não são mais referenciados pelo
programa (Venners, 2009, p.1).

28

• JEE – JAVA ENTERPRISE EDITION

Segundo Prado (2009, p.1), "O JEE (Java Enterprise Edition) é a plataforma Java
voltada para redes, internet, intranets e semelhantes, sendo assim, ela contém bibliotecas
especialmente desenvolvidas para o acesso a servidores, a sistemas de e-mail, a banco de
dados, entre outras características.".
JEE é formada por componentes que podem ser estruturados para desenvolver uma
aplicação web.
Podemos citar, por exemplo, Servlets, JSP Pages, JavaBeans, JMS entre muitas outras
tecnologias disponibilizadas ao desenvolvedor. Esta plataforma foi projetada para possibilitar
a construção de aplicações multicamadas proporcionando o desenvolvimento de projetos
escaláveis e com mantenabilidade.
Bortolassi (2007, p.1) ressalta que, “A especificação JEE define quatro tipos de
“containers” ou “plataformas” ou simplesmente “componentes” (como é citado na
especificação) que um produto JEE deve suportar”.
Estes componentes são: Aplicação Cliente, Applet, Web Container (Web Server) e
Enterprise Java Beans.
Na especificação JEE uns dos principais componentes é o JEE Server, que tem como
objetivo proporcionar uma interface para os componentes utilizados nas aplicações, definindo
assim o conceito de containeres13. Antes de um componente Web, Enterprise Bean, Applet ou
aplicação cliente ser executado, ele necessita ser montado (assembled) dentro de um modulo
JEE e distribuído (assembled) em seu container apropriado. O processo de montagem
(assembler) envolve a configuração de cada componente no aplicativo JEE definindo
normalmente através de arquivos XML suas características como segurança, gerenciamento
de transação, Java Naming and Directory Interfaces lookups (JNDI) e conectividade remota.
Na especificação JEE, os containeres interagem entre si, executando assim as tarefas
determinadas pelo programador.

Esta plataforma é considerada um padrão, afinal qualquer desenvolvedor de
ferramentas que queira disponibilizar ferramentas para esta edição deve submeter-se a certos

13
Java EE containers fornece suporte de execução para componentes de aplicação Java EE. Componentes de
aplicações Java EE usam os protocolos e métodos do recipiente para acessar outros componentes de aplicações e
os serviços prestados pelo servidor .(Sun 2010, p.1).

29

padrões da especificação JEE para que o seu produto possa ser compatível com a plataforma.
Podemos citar algumas destas especificações:
• JDBC (Java Database Connectivity) que é utilizada para realizar a conexão com
um banco de dados.
• Servlets: Especificação na qual é disponibilizada ao programador recursos do
servidor para a criação de aplicações Web com conteúdo dinâmico.
• JSP: (Java Server Pages) Podemos declará-lo como uma evolução do Servlets, pois
o JSP é internamente tratado com um Servlet, mas é codificado em uma sintaxe
muito mais limpa e intuitiva. Proporciona as mesmas características do Servlets.
• JTA: (Java Transaction API) é uma API que padroniza o tratamento de transações
dentro de uma aplicação Java.
• EJBs: (Enterprise Java Beans) São os componentes de negocio. Através destes
componentes é possível abstrair o programador de todas as questões de infra-
estrutura, segurança, disponibilidade e estabilidade e permitir que o programador
esteja focado somente na lógica do negocio a ser desenvolvido.
• JCA (Java Connector Architecture): Trata-se de uma API que padroniza a ligação a
aplicações legadas.
• JPA (Java Persistence API) É uma API que padroniza o acesso a banco de dados
através de mapeamento Objeto – Relacional.

Urubatan (2007, p.1) diz que:
Atualmente os servidores de aplicação Web que suportam a especificação JEE 5.0
são, WebLogic v10, Apusic Application Server v5.0, SAP NetWeaver Application
Server Java EE 5 Edition, Sun Java System Application Server Plataform Edition 9,
TmaxSoft JEUS 6, Glassfish Application Server.

Agora que já foi apresentada a linguagem Java e sua edição para web (JEE),
mostraremos a segunda linguagem que será apresentada neste projeto, a linguagem de
programação Ruby.

4 LINGUAGEM DE PROGRAMAÇÃO RUBY

30

Ruby é uma linguagem de programação criada por um Engenheiro de Software
chamado Yukihiro “Matz” Matsumoto em fevereiro de 1993. Ruby é licenciada sobre a GPL e
foi liberada ao publico em 1995, mais ou menos um ano depois que o Java. A linguagem é
mantida por Matz e colaboradores por todo o mundo.
Ruby-Lang (2010, p.1) afirma que “O Ruby tem um sistema de threading
independente do Sistema Operativo. Portanto, para todas as plataformas nas quais o Ruby
corre, temos multithreading, independentemente de o Sistema Operativo o suportar ou não,
até em MS-DOS temos multithreading!”.
Assim como ouras linguagens de programação, Matz desenvolveu Ruby para melhorar
a facilidade de programar a permitir que os desenvolvedores se focassem no problema do
desenvolvimento ao invés da sintaxe da linguagem. Esta é uma das grandes diferenças se
comparado com outras linguagens.
Matz (2000, p.1, tradução nossa) diz tentar tornar o Ruby natural, não simples, de uma
forma que reflita a vida. “O Ruby é simples na aparência, mas muito complexo no interior, tal
como o corpo humano”.
Ruby-Lang (2009, p.1), “Em muitas linguagens, números e outros tipos primitivos não
são objetos”.
Ruby é considerado uma linguagem totalmente orientada a objetos, o que significa
que tudo que você manipula em Ruby é um objeto, incluindo dados que
normalmente são tipos primitivos em outras linguagens, como números inteiros e
números de ponto flutuante. (Santos, 2007, p.1).

Matz (2001, p.1) fala da época em que estava criando o Ruby, “Eu queria uma
linguagem interpretada que fosse mais poderosa que o Perl e mais orientada aos objetos do
que o Python"
Ruby também é super dinâmico, permitindo ao programador alterar classes e
introduzir novos métodos no momento de execução. Esta característica possibilita o
programador realizar coisas em que outras linguagens não seriam possíveis.

O Ruby é visto como uma linguagem flexível, uma vez que permite aos seus
utilizadores alterar partes da Linguagem. Partes essenciais do Ruby podem ser
removidas ou redefinidas à vontade. Partes existentes podem ser acrescentadas. O
Ruby tenta não restringir o programador. (Ruby-Lang, 2009, p.1).

Ruby-Lang (2009, p.1) afirma ainda que:
Os Blocos do Ruby são vistos como uma fonte de grande flexibilidade. Um
programador pode adicionar um fecho a qualquer método, descrevendo como esse
método se deve comportar. O fecho é chamado bloco e tornou-se uma das
características mais populares para os recém chegados ao Ruby vindos de outras
linguagens imperativas como o PHP ou o Visual Basic.

31

Será ressaltado no capítulo a seguir a estrutura MVC, utilizada para facilitar o
entendimento e a criação de um software.

32

5 ESTRUTURA MVC

MVC (Model-View-Controler) é um padrão de arquitetura de software. Desde os anos
80 a Engenharia de Software começou a se preocupar com a maneira que os softwares eram
desenvolvidos. As primeiras tentativas em tentar explicar como os softwares eram
desenvolvidos e arquitetados foram meio confusas. Durante a década de 90, houve um grande
esforço pela comunidade da Engenharia de Software no propósito de identificar e
compreender os fatores e aspectos fundamentais no desenvolvimento de software.
Com o aumento da complexidade das aplicações desenvolvidas, verificou-se que se
torna fundamental que os dados sejam divididos em camadas para simplificar esta
complexidade. Dividindo-se em camadas, torna-se mais claro para os desenvolvedores
focarem-se em determinada parte do projeto sem comprometer o desenvolvimento de outra
parte.
Sun (2009, p.1, tradução nossa) afirma que:
O padrão MVC proporciona vários benefícios de designer. MVC separa as
responsabilidades de desenvolvimento (persistência de dados e comportamentos,
apresentação e controle) diminuindo a duplicação de código e centralizando o
controle e fazendo a aplicação ser mais modificável.

E-Genial (2009, p.1) completa ainda dizendo:
O molde MVC oferece vantagens significativas no desenvolvimento de aplicativos,
através da separação das camadas, possibilitando implementar com maior facilidade
e clareza questões programáticas importantes como a persistência de dados, controle
de segurança, comunicação em rede e fluxo de visualização.

Muitos problemas podem surgir quando mistura-se o código de acesso a dados, código
da lógica de negocio e código da apresentação. A aplicação neste contexto torna-se difícil de
manter, pois esta mistura de códigos torna o objeto muito dependente de outras partes
forçando o desenvolvedor caso seja necessária uma simples modificação, editar o código em
um nível muito profundo e complexo fazendo com que as chances de ocorrer um erro em
outra parte do sistema seja muito provável. A complexidade neste nível aumenta
significantemente. Com a divisão do código pode-se realizar a modificação do layout de uma
pagina em uma aplicação Web, sem necessitar modificar nenhuma parte da lógica da
aplicação. Uma vez o projeto estando bem dividido pode-se por exemplo contratar um
designer profissional para a implementação do layout da pagina sendo que este profissional
não necessita ser um expert na área de programação de componentes da lógica do negocio.

33

Com o modelo MVC, torna-se mais definido separação das camadas do sistema, sendo
que o modelo requisita que seja cumprida determinada regra: O Controller despacha as
solicitações ao Model; A View observa o Model.
Devido os frameworks JBoss Seam e Ruby on Rails serem voltados para
desenvolvimento de aplicativos web, será realizado a seguir uma breve explanação sobre
Servidores web.

34

6 SERVIDORES WEB

Segundo Whatis (2009, p.1, tradução nossa), "Um Servidor Web é um programa que,
utilizando-se do modelo Cliente/Servidor e o protocolo HTTP, disponibiliza arquivos que
formam as paginas para usuários Web”. Em outras palavras, um Servidor Web é um programa
de computador que é responsável por aceitar requisições HTTP de clientes e enviar respostas
HTTP por meio de conteúdo pré-definidos como textos, imagens e links com outras
requisições.
Abaixo podemos verificar algumas das funcionalidades do Apache Web Server segundo
Focalinux(2007, p.1).

• Possui suporte a scripts cgi usando linguagens como Perl, PHP, Shell Script, ASP, etc.
• Suporte a autorização de acesso podendo ser especificadas restrições de acesso
separadamente para cada endereço/arquivo/diretório acessado no servidor.
• Autenticação requerendo um nome de usuário e senha válidos para acesso a alguma
página/sub-diretório/arquivo (suportando criptografia via Crypto e MD5).
• Negociação de conteúdo, permitindo a exibição da página Web no idioma requisitado
pelo Cliente Navegador.
• Suporte a tipos mime.
• Personalização de logs.
• Mensagens de erro.
• Suporte a virtual hosting (é possível servir 2 ou mais páginas com endereços/ portas
diferentes através do mesmo processo ou usar mais de um processo para controlar
mais de um endereço).
• Suporte a IP virtual hosting.
• Suporte a name virtual hosting.
• Suporte a servidor Proxy ftp e http, com limite de acesso, caching (todas flexivelmente
configuráveis).
• Suporte a proxy e redirecionamentos baseados em URLs para endereços Internos.
• Suporte a criptografia via SSL,Certificados digitais
• Módulos DSO (Dynamic Shared Objects) permitem adicionar/remover
funcionalidades e recursos sem necessidade de recompilação do programa.

Webdevelopersnotes (2009, p.1) fala que, "O mais famoso e popular de todos os
servidores Web é o Apache, desenvolvido pela Fundação Apache. Apache não é somente free,
mas ele também esta disponível para vários sistemas operacionais incluindo Windows,
Macintosh e Linux/Unix."

35

A seguir teremos um breve contato com este Web Server.

6.1 APACHE HTTP SERVER

Segundo Alecrim (2006, p.1), "Entre os servidores Web, o Apache é o mais conhecido
e usado. Este título foi adquirido devido a sua excelente performance, segurança,
compatibilidade com diversas plataformas e todos os seus recursos”.
O Apache Server é um software livre e que é desenvolvido e implementado por vários
voluntários e desenvolvedores no mundo todo.
Abaixo estão algumas características citadas por Focalinux (2009, p.1), que fazem esse
servidor Web o preferido entre os administradores de sistemas:

 Possui suporte a scripts cgi usando linguagens como Perl, PHP, Shell Script, ASP, etc.
 Suporte a autorização de acesso podendo ser especificadas restrições de acesso
separadamente para cada endereço/arquivo/diretório acessado no servidor.
 Autenticação requerendo um nome de usuário e senha válidos para acesso a alguma
página/sub-diretório/arquivo (suportando criptografia via Crypto e MD5).
 Negociação de conteúdo, permitindo a exibição da página Web no idioma requisitado
pelo Cliente Navegador.
 Suporte a tipos mime.
 Personalização de logs.
 Mensagens de erro.
 Suporte a virtual hosting (é possível servir 2 ou mais páginas com endereços/ portas
diferentes através do mesmo processo ou usar mais de um processo para controlar
mais de um endereço).
 Suporte a IP virtual hosting.
 Suporte a name virtual hosting.
 Suporte a servidor Proxy ftp e http, com limite de acesso, caching (todas flexivelmente
configuráveis).
 Suporte a proxy e redirecionamentos baseados em URLs para endereços Internos.
 Suporte a criptografia via SSL,Certificados digitais

36

Módulos DSO (Dynamic Shared Objects) permitem adicionar/remover
funcionalidades e recursos sem necessidade de recompilação do programa.

6.2 TOMCAT

Segundo Apache (2009, p.1), "Apache TomCat é uma implementação das tecnologias
Java Servlet e Java Server Page".
TomCat é um servidor Web Java, mais especificamente, um contêiner de servlets. O
servidor Web TomCat portanto, utiliza-se da plataforma Apache para o servidor Web e
implementa a funcionalidade de contêiner Servlet, ou seja, consegue administrar a inclusão de
componentes servlets e Java Server Pages no servidor em processá-los, permitindo assim os
benefícios da plataforma java para Web.

6.3 JBOSS

Segundo Jboss (2009), “O Servidor de Aplicação Jboss é uma implementação
opensource de um conjunto de serviços na especificação Java EE”.
Seu desenvolvimento foi iniciado em março de 1999 e primeiramente foi delineado
como um container EJB (Enterprise Java Beans), mas ao longo dos anos tornou-se um
servidor de aplicações completo que atualmente encontra-se em um alto grau de maturação.
Nada mais é do que uma aplicação desenvolvida para possibilitar a implantação de
aplicações web multi-camadas desenvolvidas com tecnologia Java. Não podemos resumi-lo a
apenas isso.
Jboss é uma plataforma que disponibiliza toda a infra-estrutura de uma aplicação de
pequena a grande dimensão com utilização de outras tecnologias da especificação JEE como
JSP, Servlets, JNDI, EJB entre muitas outras da especificação.
Pelo fato de ser desenvolvido em Java é multi-plataforma e fácil de se instalar em
qualquer sistema operacional que suporte Java. Devido ao seu código fonte ser

37

disponibilizado através da licença GNU, torna-se uma grande vantagem para o desenvolvedor,
tendo a possibilidade de alterar e configurar o servidor de acordo com as suas necessidades.
Jboss em 2002 conquistou o premio da JavaWorld na categoria Best Java Server
Application Server estando inclusive na frente de produtos comerciais cujas licenças não são
adquiridas por menos de milhares de dólares. Em meados de 2005 com a fama junto com
TomCat na briga de servidores Java e após especulações de que a grande Oracle teria a
intenção de adquirir o JBoss, a Red Hat anunciou a aquisição da fornecedora do código do
Jboss por cerca de 350 milhões de dólares em dinheiro e ações.
Um dos pontos importantes sobre o diferencial do Jboss de outros Servidores de
Aplicações existentes no mercado, trata-se de como foi projetada a sua arquitetura pensando-
se no seu desempenho.
Segundo RedHat (2009, p.1), “O servidor JBoss inicia apenas um container para o
JMX MBeans server, e então carrega sua configuração baseada nos serviços definidos no
arquivo de configuração jboxx-service.xml passado para o servidor através da linha de
comando”.
O Jboss é arquitetado através de microkernels JMX, onde todos os módulos que
compõem o servidor e ainda as próprias aplicações são componentes (Mbeans) que são
plugados ou substituídos em runtime não havendo assim a necessidade de se reiniciar o
servidor toda a vez que se deseja adicionar ou alterar algum componente do servidor. Esta
propriedade do servidor Jboss é denominada Hot Deploy que acaba proporcionando uma
grande robustez e flexibilidade ao servidor.
Este elevado grau de modularidade beneficia o desenvolvedor da aplicação de várias
maneiras. Um código já pequeno pode ser ainda mais minimizado para suportar as aplicações
que devem ter uma pequena exigência. Por exemplo, se Passivação EJB é desnecessária na
sua aplicação, basta ter o recurso fora do servidor. Se você decidir mais tarde implantar o
recurso, basta apenas ativar o recurso do servidor.
Esta facilidade permite que o desenvolvedor personalize o ambiente do servidor de
acordo com as necessidades de suas aplicações e economizando recursos de hardware do
servidor.
Podemos destacar alguns destes módulos, por exemplo, Jboss Server (Servidor), Jboss
JMX (Gerenciamento dos MBeans) Jboss CMP (Persistência), Jboss MQ (Filas de
Mensagens), Jboss SX (Segurança, Autorização e Autenticação), Jboss TX (Transações
Distribuídas), Jboss CX (Conectores), Servidor Web (TomCat, Jetty).

38

Jboss (2009) afirma que,
Jboss AOP não é somente um framework, mas também um conjunto de pacotes que
são aplicados por meio de anotações, expressões ou dinamicamente em tempo de
execução. Alguns desses pacotes incluem cachê, comunicação assíncrona,
transações, segurança e muitas outras funcionalidades.

O Jboss a partir da versão 4.0 já disponibiliza um framework denominado AOP
(Aspect-Oriented-Programming) que possibilita que os programadores adicionem facilmente
em seus projetos funcionalidades como transação, persistência e replicação de cache a partir
de seus objetos Java comuns sem a necessidade de se criar um EJB para tal. Portanto este
framework transforma um objeto comum Java em um EJB e permite que o desenvolvedor
possa focar-se no desenvolvimento da lógica de negocio.

A seguir, será definido o que é um framework, para que ele serve e suas vantagens. No
final do capitulo será citado alguns exemplos de frameworks mais conhecidos pelos
programadores.

39

7 FRAMEWORKS

O framework serve para resolver problemas semelhantes de um determinado domínio,
composto por um conjunto de classes e interfaces que devem ser flexíveis e extensíveis para
permitir a construção de aplicações com menos esforço, ditando apenas as semelhanças de
cada aplicação. Segundo Fayad e Schmidt (1997, p.1), “Framework é um conjunto de classes
que colaboram para realizar uma responsabilidade para um domínio de um subsistema da
aplicação”.
Um framework é criado a partir das similaridades funcionais de várias aplicações, elas
devem ter alguma similaridade grande, ou seja, pertencer a um mesmo domínio de problema.
Pode se dizer que um framework é uma aplicação quase completa, mas com alguns pedaços
faltando.

Algumas vantagens de se utilizar um Framework são:
• Maior facilidade para a detecção de erros e estabilizando a aplicação, visto que
frameworks são peças mais concisas de software
• Podemos nos concentrar mais com a abstração de soluções do problema que estamos
tratando, focando apenas no necessário, ao invés de inventar a roda.
• Torna mais eficiente a resolução dos problemas e a compatibilidade entre as
aplicações.
• Otimização de recursos.
• Menos manutenção.
• Como todos os itens acima ocasionam uma maior produtividade, podemos garantir
que também teremos um maior lucro, pois teremos uma antecipação da entrega, e
uma maior satisfação dos clientes.

Exemplos de Frameworks MVC mais conhecidos:
• VRaptor
• WebWork
• Struts
• Spring
• IBM SERVLETMANAGER
• Oracle9iAS MVC Framework

40

• WebFlow em WebLogic Portal 4.0 da BEA
• Tapestry
• Turbine

Exemplos de Frameworks conhecidos para Persistência com o Banco de Dados:
• Hibernate
• Prevayler
• TOPLINK
• COCOBASE

Agora que foi mostrado o que é um framework, falaremos sobre o Jboss Seam, que
será o framework utilizado neste projeto para linguagem de programação Java, mais adiante
falaremos também sobre o framework que será utilizado para a linguagem Ruby.

7.1 JBOSS SEAM

Jboss Seam trata-se de um framework que foi desenvolvido por Gavin King, criador
do Hibernate. O framework Jboss Seam tem a finalidade de realizar a integração entre
componentes EJB3 e JSF através de componentes visuais. Não há distinção entre a camada de
apresentação e os componentes de lógica de negocio no Seam.
Segundo Duckett (2008, p.1), Gavin King é o fundador do Hibernate e Jboss Seam,
projetos open source que pretendem fazer a vida de um desenvolvedor Web mais fácil [...].
Enterprise Java Beans (EJB3) são componentes de negocio e Java Server Faces (JSF)
são componentes visuais. A sua integração não é definida na especificação da plataforma
JavaEE 5 e o Jboss Seam foi desenvolvido a principio para solucionar este problema que
dificulta o desenvolvimento de aplicações Java para Web.
Sommers (2006) diz que, “Um dos principais problemas que o Seam tenta resolver é a
questão da profunda integração da plataforma EE 5 para o ponto de vista do modelo de
programação. A plataforma EE tem esses poderosos recursos, e seria ótimo se esses recursos
trabalhassem juntos dentro de um único ambiente”.

41

Adicionalmente á esta funcionalidade Jboss Seam é fornecida em sua API a
possibilidade de integração com outras tecnologias como AJAX, jBMP, Web Services, JMS,
Portlets etc.
Segundo Jcp (2009, p.1), "O propósito desta especificação é unificar componentes JSF
com componentes EJB, resultando em uma significante simplificação do modelo de
programação para aplicações baseadas na web".
Devido a sua grande aceitação junto à comunidade Java, foi criada um conceito
denominado JSR299 – WebBeans para padronizar o modelo de programação do Seam na
plataforma Java EE 5. As empresas envolvidas neste esforço são Jboss, Google, Oracle,
Borland e Sun.
Podemos dizer que o Jboss Seam faz todo o trabalho sujo da integração entre
componentes EJB3 com componentes JSF, permitindo que o desenvolvedor foque-se no
domínio de negocio que esta sendo desenvolvido.
Antes do Seam, a única maneira de gerenciar o estado de uma Aplicação Web era
através da sessão HTTP. Seam disponibiliza ao desenvolvedor, vários contextos de diferentes
granularidades de escopo de conversação libertando o desenvolvedor de certas limitações que
o HTTP session possuíam. Os contextos Seam são muito semelhantes aos contextos de uma
aplicação Web baseada em Java EE (componentes Servlets e JSP). Podemos entender por
contextos como espaços reservados no servidor para armazenagem de objetos dos usuários da
aplicação Web. Estes Objetos são referenciados por uma String única para cada usuário e
através dela podemos ter acesso aos dados deste objeto.
Jboss (2009, p.1) diz que, “Os contextos básicos do Seam são: Stateless context, Event
(or request) context, Page context, Conversation context, Session context, Business process
context, Application context”.
A usabilidade destes contextos é a mesma que os contextos JEE padrão porem, estes
novos contextos possuem um comportamento diferente e específico para determinadas
funções. Outra funcionalidade disponibilizada no framework Seam é o gerenciamento de
processos de negocio através do jBPM, permitindo um desenvolvimento otimizado para esta
tecnologia.
Os escopos existentes na especificação JEE são: page, request, session e application.
Jboss Seam define novos contextos para complementar os já existentes, são eles: stateless,
event, page, conversation, session, business process e application. A usabilidade destes
contextos é a mesma que os contextos JEE padrão porem, estes novos contextos possuem um
comportamento diferente e específico para determinadas funções. Outra funcionalidade

42

disponibilizada no framework Seam é o gerenciamento de processos de negocio através do
jBPM, permitindo um desenvolvimento otimizado para esta tecnologia.
Segundo RedHat (2009, p.1), "jBPM provê sofisticada funcionalidade para workflow14
e gerencia de tarefas".
A implementação de funcionalidade CRUD em aplicações JEE torna-se muito
facilitado através dos scripts de criação de projetos disponibilizado pelo Seam, onde por
exemplo indicamos o tipo de banco a ser utilizado alguns outros dados para a conexão e
automaticamente através de uma ferramenta de engenharia reversa o framework realiza a
leitura dos dados do banco de dado e cria as classes entities automaticamente para as tabelas.

Neste capitulo foi apresentado o framework Jboss Seam que se integra ao Java, o
capítulo a seguir falará sobre o framework que será utilizado neste projeto para a linguagem
de programação Ruby, conhecido como Ruby on Rails.

7.2 RUBY ON RAILS

Ruby on Rails trata-se de um framework desenvolvido por David Heinemeier
Hansson. Ruby on Rails foi escrito na linguagem Ruby e tem como objetivo proporcionar o
desenvolvimento ágil de aplicações web. Desde julho de 2004 este framework foi liberado
como um projeto open source e desde então vem sendo aperfeiçoado por uma comunidade
que a cada dia cresce e coopera para o desenvolvimento da mesma.
Segundo E-Genial (2009) Rails foi projetado para:
• Ser uma solução de desenvolvimento completa;
• Permitir que suas camadas se comunicassem da forma mais transparente possível;
• Ser uniforme, escrito totalmente apenas em uma linguagem;
• Seguir a arquitetura MVC (Model-View-Controller).

E-Genial (2009), afirma ainda que “O Rails, ou Ruby on Rails, ou ainda RoR, pode
também ser chamado de um "meta-framework", pois têm em sua estrutura outros 5
frameworks:

14
Workflow (em português: Fluxo de Trabalho) É a tecnologia que possibilita automatizar processos,
racionalizando-os e potencializando-os por meio de dois componentes implícitos: organização e tecnologia..
(Idoc 2010, p.1 ).

43

• Active Record;
• Action Pack;
• Action Mailer;
• Active Support;
• Active Resource”

De acordo com RailsGuide (2009, p.1) A filosofia Rails é fundamentada em alguns
princípios: DRY - Não repita você mesmo – Sugere que escrever o mesmo código várias
vezes é uma prática ruim. Convention Over Configuration (Convenção sobre a Configuração)
– diz que Rails supõe o que e como o programador deseja fazer alguma coisa ao invés de
deixá-lo implementar intermináveis arquivos de configuração.
A filosofia Convention over Configuration de Ruby on Rails, torna o processo de
desenvolvimento de uma aplicação Web mais fácil e rápida. Esta filosofia tem como objetivo
minimizar os arquivos de configurações tão difundidos em outros frameworks atualmente no
mercado. Por exemplo, suponhamos que a variável carro de uma aplicação web deve ser
persistida na coluna carro do banco de dados, então o programador necessita editar as
configurações em um arquivo XML realizando uma espécie de link entre essa variável e a
coluna do banco e dados. Dependendo da complexidade da aplicação e de suas camadas,
inúmeros arquivos de configuração deverão ser configurados tornando assim muito
dispendiosa o trabalho do programador.
Ruby on Rails escapa neste caso da configuração através da naming conventions. Por
exemplo, uma variável chamada "carro" esta automaticamente ligada a uma tabela chamada
"carros". Vários aspectos em Rails tentam minimizar estes inúmeros arquivos de configuração
permitindo que mais rapidamente já se inicie o processo de desenvolvimento propriamente
dito.
Outro aspecto levantado é o Dont Repeat Your Self que tem como principio evitar
informações duplicadas no código, permitindo que o desenvolvedor possa focar-se no que
realmente interessa e não ficar perdendo tempo em digitar informações repetidas devido à
burocracia da linguagem ou framework utilizado. Na programação de computadores a
repetição é ruim e nos levará ao erro.

Também referido como "Uma Vez e apenas Uma Vez", o DRY tem como principio
que você precisa apenas expressar uma peça particular de informação uma vez no
sistema. A duplicação é normalmente desnecessária especialmente em linguagens
dinâmicas como Ruby. (Brad Ediger, 2007, tradução nossa)

44

Em um projeto padrão com banco de dados, um arquivo de configuração ira indicar ao
programa como é que estão organizadas as tabelas do banco de dados, qual é a ligação entre
as tabelas, atributos, chaves primárias entre outros dados. A partir deste arquivo todo o
programa estará apto a persistir os dados e realizar outras ações. Caso o nome de um único
campo de uma tabela esteja errado, já não será possível executar o programa e o programador
deverá localizar onde esta o erro e arrumá-lo. Caso seja alterada alguma tabela, o
programador deverá alterar o respectivo arquivo atualizando as alterações realizadas no
banco. No entanto, se analisarmos, estes arquivos de configurações não passam de uma
repetição desnecessária e que tendem a nos levar ao erro, pois o aplicativo poderia acessar o
banco e realizar a verificação de todas as tabelas e seus atributos e deduzir a formatação que
está a base de dados.
Outro fator que não deve ser esquecido é que com esta repetição, toda alteração
realizada no banco deve ser refletida nos arquivos de configuração e dentro da lógica do
aplicativo, assim despendendo tempo do programador e mais trabalho para todos. Com esse
trabalho árduo é natural que o programador sinta-se desencorajado a realizar alterações e com
isso não respondendo adequadamente as necessidades de atualizações impostas por um
possível cliente.

Apresentado as linguagens Java e Ruby e seus frameworks Jboss Seam e Ruby on
Rails, será mostrado no próximo capítulo uma comparação com as características principais
de cara linguagem.

45

8 JAVA X RUBY

Como Java e Ruby são as linguagens de programação base que este projeto irá
abordar, Java para Jboss Seam e Ruby para Ruby on Rails, citamos abaixo uma lista com as
principais características dessas linguagens.

Características Java Ruby
Orientada a Objetos (OO) X X
Sintaxe Simples X
Tipos Primitivos X
Grande quantidade de Frameworks X
Linguagem Compilada X
Linguagem Interpretada X X
OpenSource X X
Suporte a Web X X
Programação Estática X
Programação Dinâmica X
Garbage Collector X X
Closures X
Metaprogramação X
MVC X X
Tratamento de Exceções X X
Quadro 7 - Exemplo de Comparação Java x Ruby – Elaboração dos autores, 2010.

46

9 PONTOS A SEREM COMPARADOS

9.1 CURVA DE APRENDIZADO

Quando falamos de curva de aprendizagem, estamos falando da dificuldade de se
adaptar a uma determinada linguagem de programação, seja ela de alto ou baixo nível. Muitas
pessoas não encaram tal linguagem de programação pela sua fama de curva de aprendizagem
ser muito grande, e ter um mundo novo e complexo ou não se ter muitos recursos para poder
se adaptar a essa linguagem, o que de fato não deve ser encarado desta maneira, pois varias
linguagem onde a curva de aprendizagem é alta, estão maduras o suficiente para uma
aplicação segura e com alto desempenho.

9.2 TEMPO DE DESENVOLVIMENTO

O tempo de desenvolvimento é um ponto importante a ser analisado. Este é um
aspecto que evidencia a produtividade de uma linguagem ou framework. O tempo necessário
para o desenvolvimento de um aplicativo está diretamente relacionado à simplicidade da
linguagem, robustez e facilidade de suportes, como api, livros e comunidades.

9.3 FACILIDADE DE MANUTENÇÃO

Segundo Anquetil (2008, p.1), A manutenção de software é uma atividade
extremamente importante na prática das organizações de software correspondendo a 90% ou
mais de toda atividade de programação de sistemas. Isto quer dizer que para se ter uma boa
manutenção, é necessário que a linguagem de programação permita isto, ou seja, a linguagem
tem que ser clara e de fácil entendimento, tanto para o próprio programador como para outros
programadores de fora que irão fazer a manutenção do software.
Para IEEE (1998, p.1) manutenção de software “é caracterizada pela modificação de
um produto de software já entregue ao cliente, para a correção de eventuais erros, melhora em
seu desempenho, ou qualquer outro atributo, ou ainda para adaptação desse produto a um
ambiente Modificado.”.

47

Esta fase envolve:
* Mudanças no software para corrigir defeitos e deficiências que foram encontrados durante a
utilização pelo usuário
* Novas funcionalidades para melhorar a aplicabilidade e usabilidade do software.

9.4 PERFORMANCE

Performance é uma característica que deve ser analisada durante todo o processo de
criação de um software. Se um software é produzido sem a preocupação com a performance,
o tempo de execução irá decair muito ou a necessidade de hardwares mais potentes será
requerida. Para se saber se o software tem essa característica, boa ou não, precisamos ter
como base outros softwares para poder se comparar as duas situações, só assim ficará claro a
diferença entre as duas aplicações e a sua performance perante a outra.
Para se calcular a performance de um software é feito um teste chamado Benchmarks,
que são testes de desempenho para várias características do software, desde a sua robustez até
seu tempo de resposta.

9.5 TAMANHO DO CÓDIGO

O Tamanho do código está relacionado à facilidade de manutenção e ao tempo de
desenvolvimento de uma aplicação. Pode-se através desta métrica verificar o nível de trabalho
empregado para o desenvolvimento de uma aplicação.

48

10 ANÁLISE COMPARATIVA DAS FERRAMENTAS JBOSS SEAM E RUBY ON
RAILS

10.1 METODOLOGIA PARA DESENVOLVIMENTO DO TRABALHO

Procurando obter conhecimento atualizado e útil no processo de desenvolvimento
deste projeto, os materiais de estudo e pesquisas foram obtidos através da Internet, e-books e
professores.
Devido ao fato de Ruby on Rails ser uma tecnologia totalmente nova aos autores,
primeiramente um estudo foi realizado para adquirir o conhecimento necessário no
desenvolvimento deste projeto. Durante o curso de graduação, teve-se um breve contato com
JEE, no entanto um estudo mais aprofundado das diversas tecnologias existentes no universo
JEE e principalmente em Jboss Seam foi realizado pela equipe.
O desenvolvimento de protótipos empregando as tecnologias estudadas foi algo
freqüente durante este projeto, pois somente através destes protótipos foi possível avaliar os
diversos fatores presentes no desenvolvimento e planejamento de determinado problema do
mundo real.
O estudo desenvolvido nos proporcionou o entendimento de algumas dificuldades
encontradas na fase de implementação, no ponto de vista das duas tecnologias, Jboss Seam e
Ruby on Rails. Através desse estudo foi apresentado uma comparação de aspectos relevantes
como Curva de aprendizado, Tempo de desenvolvimento, Facilidade de manutenção,
Performance e Tamanho do código. Através desse projeto, foi apresentada uma crítica de
ambas as tecnologias, evidenciando suas principais características positivas e seus pontos
negativos.
O desenvolvimento de uma pequena aplicação em ambos os frameworks, Jboss Seam
e Ruby on Rails, exemplificou alguns aspetos levantados durante os estudos. A visão geral do
sistema, assim como o caso de uso, requisitos funcionais e não funcionais, referencias
cruzadas, mapa do site e os wireframes podem ser vistos nos Apêndices A,B,C,D,E e F
respectivamente.
Para a comparação da curva de aprendizado, foi levado em conta a facilidade do
entendimento de cada framework até estar apto à desenvolver o aplicativo.
O tempo de desenvolvimento foi medido e comparado de acordo com as horas
necessárias para o aplicativo ficar totalmente completo em ambas as tecnologias.

49

Para a análise da facilidade de manutenção foi determinada a inclusão de duas
funcionalidades para cada aplicativo. As funcionalidades definidas foram, envio de e-mail e
upload/download de arquivos.
Uma das comparações mais complicadas de se realizar neste projeto, foi referente à
performance entre os dois frameworks. Esta comparação deveria ser realizada utilizando-se
um método que pudesse ser confiável e desejavelmente de uma forma única para ambos os
frameworks.
Através de pesquisas, foi localizado um aplicativo Web que possibilitaria esta
comparação entre os frameworks. Trata-se de um aplicativo Web denominado New Relic
(http://www.newrelic.com), que tem como objetivo o debug da aplicação em runtime. Este
aplicativo Web para debug permite a visualização de várias métricas do programa Web como,
por exemplo, uso de processador, tempo de resposta, tempo das transações com acesso ao
banco de dados, tempo de execução de eventos entre outras métricas relativas a outros
quesitos.
O New Relic é configurável em vários servidores Web estando, no entanto limitado às
plataformas Ruby e Java.
Para configuração do New Relic é necessário apenas realizar o download do Agente
New Relic e configurar o servidor Web utilizado conforme orientações da equipe do New
Relic para o que agente possa ser inicializado juntamente com o Servidor de Aplicativos.
Após a configuração ser realizada e o servidor inicializado, o agente New Relic registra as
métricas e envia para o servidor New Relic, permitindo então a visualização das métricas no
site do aplicativo.
Trata-se de uma ferramenta utilizada por grandes empresas para analise dos seus
aplicativos Web. Empresas como 37signals, at&t, ATLASSIAN, CBS Interactive, The
Washington Post entre mais de quatro mil utilizam-se deste aplicativo.
Por fim, foi comparado o tamanho do código necessário para o desenvolvimento das
aplicações em ambos os frameworks.

50

11 ANÁLISE DOS RESULTADOS

11.1 Curva de Aprendizado

• Ruby on Rails

Mesmo Ruby on Rails sendo algo totalmente novo para os autores desse projeto, a
curva de aprendizado foi considerada pequena, devido às facilidades que a linguagem Ruby
oferece e a grande legibilidade dos códigos.
Um exemplo de legibilidade do código pode ser visto abaixo:
class Service < ActiveRecord::Base
belongs_to :account
has_many :tasks, :dependent=>:destroy
validates_associated :account
validates_presence_of :name,:account,:description,:value
end
Quadro 8 - Exemplo de legibilidade de código Ruby on Rails – Elaboração dos autores, 2010

O bloco de código acima se refere ao model da classe de serviço.
belongs_to :account, indica que o serviço pertence a uma conta.
has_many :tasks, indica que serviço tem muitas tarefas(contratos) , e o dependent =>
:destroy indica que caso o serviço for deletado, a task(contrato) também será deletada.
Um exemplo de facilidade seria a criação da tabela da classe acima no banco de dados.
Para gerar essa tabela o seguinte comando é utilizado:

ruby script/generate scaffold Service account:references name:string description:text
Quadro 9 – Script de criação do scaffold em Ruby on Rails – Elaboração dos autores, 2010

Feito isso, basta apenas migrar os dados para o banco com o seguinte comando.

rake db:migrate
Quadro 10 – Comando de migração para o banco de dados – Elaboração dos autores, 2010

Outro ponto que abstrai bastante o programador das configurações são as convenções
que o Rails sugere, facilitando ainda mais a curva de aprendizado para o programador.

51

O tempo de aprendizado para poder estar apto a desenvolver o sistema de testes para
esse projeto em Ruby on Rails, foi de 9 semanas. Porém vale ressaltar que este ponto é
bastante relativo e varia muito de uma pessoa para outra.

• Jboss Seam

Devemos levar em consideração o fato que os autores deste projeto já tiveram contato
com a linguagem de programação Java durante o curso de graduação nas disciplinas
Programação I, II e III.
Mesmo contando com esta experiência na linguagem Java foi encontrada certa
dificuldade no aprendizado da utilização do framework Seam, tornando a curva de
aprendizagem um pouco mais acentuada, com tempo total de 14 semanas.
Devido ao fato de Jboss Seam abstrair um grande número de tecnologias, como por
exemplo, Java Server Faces, JPA, RichFaces, Hibernate torna-se necessário que o
desenvolvedor tenha uma breve noção sobre cada tecnologia e como cada uma esta
incorporada ao framework.
Um fator que interfere no aprendizado é a pouca documentação em português, dificultando a
assimilação da documentação disponível.

• Considerações finais da curva de aprendizado

Ruby on Rails no ponto de vista dos autores destacou-se neste quesito por sua maior
facilidade de aprendizado.

11.2 Tempo de Desenvolvimento

• Ruby on Rails

Depois de muito estudo, freqüentando fóruns, lendo livros e e-books, foi dado inicio
ao desenvolvimento do sistema para testes. O sistema apresentado é o mesmo desde o inicio
do estudo do framework, e o tempo gasto para o desenvolvimento do mesmo em Ruby on
Rails foi de vinte horas no total. Com o entendimento dos problemas que aconteceram

52

durante o desenvolvimento e o tempo gasto com buscas e pesquisas para resolver tais desvios,
os autores estimam um remake do mesmo projeto em aproximadamente dez horas de
desenvolvimento ou menos.

• Jboss Seam

A fase de desenvolvimento foi realizada concorrentemente à assimilação do conteúdo
de livros, sites e e-books. O processo de desenvolvimento no Jboss Seam teve seu start pela
implementação do banco de dados. Após o banco de dados estar implementado, através da
perspectiva Bottom-up foi realizado o Scaffolding com a ferramenta Seam-gen15. Após este
processo começou a ser desenvolvido e configurado conforme as necessidades da aplicação
definida.
Através da ferramenta Seam-gen, o desenvolvedor tem a capacidade de iniciar o
desenvolvimento rapidamente, pois vários dos pacotes de classes de componentes, artefatos
de configuração são automaticamente gerados para o ambiente definido na execução do
Seam-gen.
Após a realização destes passos, a assimilação do conteúdo teórico foi necessário para
dar continuidade ao desenvolvimento. Não se trata apenas do estudo do Framework Seam,
mas de todas as tecnologias inclusas.
As tecnologias inseridas neste projeto são JPA, RichFaces, Java Server Faces, Java
Mai e Hibernate. A integração entre estas tecnologias é realizado pelo Framework Seam, o
necessário então é saber utilizá-las de acordo com as necessidades.
O tempo necessário para o desenvolvimento do mesmo foi de 45 horas. Como já
citado e sendo importante salientar, o start do desenvolvimento se deu de uma forma rápida
através do Seam-gen, no entanto a continuação esqueleto criado foi o principal desafio. Com
a experiência adquirida durante a fase de desenvolvimento, é estimado que em
aproximadamente 20 horas fosse possível desenvolve-lo até a fase atual.

• Considerações finais do tempo de desenvolvimento
15
Seam-gen é uma fabrica de aplicações. Simplificando, é uma ferramenta que tem como finalidade criar o
projeto esqueleto, permitindo que o desenvolvedor tenha seu foco direcionado ao desenvolvimento com o
mínimo de tempo gasto realizando configurações e instalações. (Traduçao Nossa) – Manning Seam in Action
Capitulo 2 pagina 35

53

O desenvolvimento utilizando-se Ruby on Rails tornou-se mais fácil e mais rápido devido
à simplicidade do código e a agilidade que as convenções ao invés de configurações oferecem
e também pela não necessidade de reiniciar o servidor quando se modifica o código fonte.
Isso tudo simplifica e possibilita a agilidade o processo de desenvolvimento e aprendizado.

11.3 Facilidade de manutenção

Com o sistema pronto, o próximo passo era a comparação na facilidade de manutenção
de Ruby on Rails e JBoss Seam. Para abordar esse tópico, os autores dispuseram de
incrementar no sistema a possibilidade do usuário poder fazer upload de arquivos e envio de
e-mails. O cenário para essas opções ficou da seguinte maneira:
• O usuário Empresa pode fazer upload de arquivos para anexar aos seus serviços
oferecidos, tais como, Termo de Contrato, Formulários, fotos, etc.
• O usuário Cliente poderá então, apenas, fazer download desses anexos.
• A parte de e-mail foi implementada juntamente com o Contrato.
• Quando um Cliente contrata algum serviço de qualquer Empresa, um e-mail é enviado
para ambas as partes, com todos os dados desse contrato.
Quadro 11 - Exemplo de Comparação Java x Ruby – Elaboração dos autores, 2010

• Ruby on Rails

Em Ruby on Rails esses dois aprimoramento do sistema foi muito fácil. O tempo para
programar essas ferramentas foi de quatro horas contando com pesquisa e desenvolvimento.
Em Ruby on Rails, tanto no upload como no envio de e-mail, foi necessário a instalação
de plugins.
Para upload o plugin usado foi o paperclip, disponível em
(http://github.com/thoughtbot/paperclip). Para a instalação do plugin, deve-se abrir o prompt
de comando e entrar na pasta do projeto criado. Feito isso basta digitar a linha de comando
abaixo:

ruby script/plugin install git://github.com/thoughtbot/paperclip.git
Quadro 12 Script para instalar plugin – Elaboração dos autores, 2010

54

Isso irá baixar o plugin diretamente do repositório oficial do paperclip e instalá-lo.
Uma das configurações que o paperclip oferece e o filtro de tipo de arquivos para envio. Para
esse sistema, foi configurado o envio apenas de .pdf, .doc e .jpg. Esse filtro é feito apenas
com esse código abaixo:

validates_attachment_content_type :arquivo, :content_type =>
%w(application/msword, application/pdf, image/jpg)
Quadro 13 – Código para filtrar extensões de arquivos do paperclip – Elaboração dos autores, 2010

E para o envio de e-mail foi utilizado o plugin action_mailer_optional_tls, disponível
em (http://github.com/collectiveidea/action_mailer_optional_tls). Para a instalação do plugin,
deve-se abrir o prompt de comando e entrar na pasta do projeto criado. Feito isso basta digitar
a linha de comando abaixo:

ruby script/plugin install git://github.com/collectiveidea/action_mailer_optional_tls.git
Quadro 14 – Script para instalar plugin – Elaboração dos autores, 2010

Após instalado foram necessário apenas essas 4 configurações listadas abaixo:

1. Especificar o modo de envio dos e-mails:
config.action_mailer.default_content_type = 'text/html'
config.action_mailer.smtp_settings = {
:tls => true,
:address => "smtp.gmail.com",
:port => "587",
:authentication => :plain,
:user_name => "login@gmail.com",
:password => "senha"
}
Quadro 15 – Configuração do servidor de e-mail em Ruby on Rails – Elaboração dos autores, 2010

2. Criar uma classe informando quem receberá o e-mail, o assunto do e-mail e o
conteúdo.

55

class ContractNotifier < ActionMailer::Base
def create_notification(task)
recipients %("#{task.customer.name}" <#{task.customer.email}>,
"#{task.firm.name}" <#{task.firm.email}>)
subject "[Ruby on Rails] Novo serviço contratado!"
body :task => task
end
end
Quadro 16 Configuração de envio de e-mail em Ruby on Rails – Elaboração dos autores, 2010

Recipients se refere a quem será enviado o e-mail. Exemplo, “TCC” <tcc@unisul.br>.
Subject é o assunto do e-mail.
Body é o texto que será impresso no e-mail.

3. Criar uma classe com o nome de create_nofitication, que é o nome do método
criado no exemplo acima. Essa nova classe que irá constar o corpo do e-mail, ou
seja, todo texto que será enviado. Como no exemplo abaixo:

Olá <%= @task.firm.name %>,
O cliente <%= @task.customer.name %> contratou o seu serviço de "<%=
@task.service.name %>".
Dados do serviço:
Nome: <%= @task.service.name %>
Descrição: <%= @task.service.description %>
Valor: R$<%= @task.service.value %>
Dados do cliente:
Nome: <%= @task.customer.name %>
E-mail: <%= @task.customer.email %>
Endereço: <%= @task.customer.address %>
CPF: <%= @task.customer.account.cpf_cnpj %>
Telefone: <%= @task.customer.account.phone %>
---
Ruby on Rails - Sistema de Testes
Data: <%= Time.now %>
Quadro 17 – Exemplo de mensagem a ser enviada em Ruby on Rails – Elaboração dos autores, 2010

O código acima enviaria um e-mail como esse:

56

Olá Empresa01,
O cliente José Pereira contratou o seu serviço de "Programação para Web".

Dados do serviço:
Nome: Programação para Web
Descrição: Criação de sites na em geral.
Valor: R$400.0

Dados do cliente:
Nome: José Pereira
E-mail: josepereira@unisul.br
Endereço: rua De Sempre, Vila Nova, Imbituba, Santa Catarina, Brasil
CPF: 056102301-82
Telefone: (48)3255-0000

---
Ruby on Rails - Sistema de Testes
Data: Mon May 17 12:39:55
Quadro 18 – Exemplo de e-mail enviado em Ruby on Rails – Elaboração dos autores, 2010

4. Após essas configurações, basta chamar o método juntamente após a criação de
um contrato entre Cliente e Empresa, usando o exemplo abaixo:

ContractNotifier.deliver_create_notification(@task)
Quadro 19 Comando para enviar e-mail em Ruby on Rails – Elaboração dos autores, 2010

ContractNotifier = Nome da Classe com os dados de envio.
deliver = método do ActionMailer que informa que será enviado um e-mail.
create_notification = Nome do método dentro da classe ContractNotifier, que recebe como
parâmetro o serviço contratado no momento.

• Jboss Seam

A implementaçao destas funcionalidades através do framework Seam, foi
razoavelmente rápida. O tópico upload/download de arquivos foi mais trabalhoso para se
realizar.

57

O framework Seam prove suporte para se trabalhar com emails. As configurações
necessárias para se implementar esta funcionalidade são mínimas.
Primeiramente devemos configurar o acesso ao servidor SMTP desejado para o envio
do email. Esta configuração é realizada no arquivo Components.xml, localizado na pasta
WEB-INF. Abaixo pode-se verificar como deve ser esta configuração;

<mail:mail-session host="smtp.gmail.com" password="senhaemail"
port="587" username="email@gmail.com"/>
Quadro 20 - Exemplo da configuração do serviço de e-mail– Elaboração dos autores, 2010

Após realizada esta configuração, foi criado um componente Seam identificado como
emailService, na qual possui um método sendMessage() que realiza toda a ação de envio de e-
mail.
Abaixo o código fonte do método sendMessage();
@Asynchronous
public void sendMessage(@Duration
long delay, String template,List l,Cliente c,Servicos s) {
this.serv=s;
this.cli=c;
for (int i = 0; i < l.size(); i++) {
rep=(Representante)l.get(i);
System.out.println("Email representante: "+rep.getUsuario().getEmail());
try {
//Contexts.getEventContext().set("info", infoNeededForTemplate);
System.out.println("Renderizando");
renderer.render(template);

System.out.println("Renderizado");
} catch (Exception e) {
// suppress information.
//logger.error(e.getMessage());
e.printStackTrace();
}
}

}
Quadro 21 - Exemplo do método de envio de e-mail– Elaboração dos autores, 2010

Nota-se a inclusão da anotação @Asynchronous antes da definição do método. Está
anotação indica que este método será assíncrono e proporcionará ao usuário mais rapidez na
exibição da pagina. A objeto/método responsável pela renderização da pagina e envio é o
renderer.render(String template).
Durante a implementação desta funcionalidade foi verificado que o usuário ao
executar a ação de contratar um serviço, aguardava a renderização da pagina de email, a
conexão ao servidor SMTP configurado, o envio do email para somente após este processo ser

58

exibida a pagina de serviço contratado. Este processo tornava-se demorado no entanto, com a
adição desta anotação antes do método, a renderização do email é realizado em background e
o usuário não nota este comportamento durante a contratação do serviço.
A implementação do layout do e-mail é realizado através de uma taglib apropriada
(xmlns:m="http://jboss.com/products/seam/mail") para tal. Abaixo se pode visualizar o
arquivo que renderiza o email da aplicação;
<m:message xmlns="http://www.w3.org/1999/xhtml"
xmlns:m="http://jboss.com/products/seam/mail"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:s="http://jboss.com/products/seam/taglib"
xmlns:p="http://jboss.com/products/seam/pdf">

<m:from name="Sistema Web Seam"/>
<m:to name="#{emailService.rep.nome}">#{emailService.rep.usuario.email}</m:to>
<m:subject>Sistema Web - Seam</m:subject>

<m:body>

<h:outputText value="Novo Servico Solicitado! "
style="FONT-SIZE: x-large; FONT-WEIGHT: bold; COLOR: #0080ff;" />

<h:outputText value="Ola " />#{emailService.rep.nome},
<h:outputText value="O cliente " />#{emailService.cli.nome},<h:outputText
value="contratou o seu servico do tipo '" />#{emailService.serv.tipoServico.de-
scricao}<h:outputText
value="'." />
<h:outputText value="Dados do Servico: "
style="FONT-WEIGHT: bold; COLOR: #0080ff;" />
<h:outputText value="Tipo: " style="FONT-WEIGHT: bold;" />#{emailSer-
vice.serv.tipoServico.descricao}
<h:outputText value="Nome: " style="FONT-WEIGHT: bold;" />#{emailSer-
vice.serv.descricao}


<h:outputText value="Dados do Cliente: "
style="FONT-WEIGHT: bold; COLOR: #0080ff;" />
<h:outputText value="Nome:" style="FONT-WEIGHT: bold;" />#{emailService.-
cli.nome}
<h:outputText value="Email: " style="FONT-WEIGHT: bold;" />#{emailService.-
cli.usuario.email}
<h:outputText value="Endereco: " style="FONT-WEIGHT: bold;" />#{emailSer-
vice.end}
<h:outputText value="CPF: " style="FONT-WEIGHT: bold;" />#{emailService.-
cli.cpf}

Mensagem Automatica, por favor, nao responda.

59



<s:graphicImage id="image" value="/layout/seam.png"
fileName="seam.png">

</s:graphicImage>
Powered by SEAM FRAMEWORK
</m:body>
</m:message>
Quadro 22 - Exemplo do arquivo de renderização de e-mails – Elaboração dos autores, 2010

Abaixo podemos visualizar a pagina HTML enviada;

Novo Servico Solicitado!
Ola Roberto Carlos Bender,

O cliente Guilherme Serna Martins,contratou o seu servico do tipo 'Segurança'.

Dados do Servico:

Tipo: Segurança

Nome: Instalaçao de Cameras (C/S Audio)

Dados do Cliente:

Nome:Guilherme Serna Martins

Email: mawcor@gmail.com

Endereco: Rua Lucio Machado, Vila Nova, Imbituba, SC, Brasil, 88780000

CPF: 04999335913

Mensagem Automatica, por favor, nao responda.

Powered by SEAM FRAMEWORK

Quadro 23 - Exemplo do e-mail gerado – Elaboração dos autores, 2010

O tempo quantificado para o desenvolvimento desta funcionalidade foi de 1 hora e
meia.
Como já dito anteriormente, o upload e download de arquivos necessitou-se de um
tempo maior para se programar. Para tal foi necessário criar uma tabela no banco de dados

60

para registrar as informações de cada upload realizado. Na pesquisa por soluções, preferiria
que os dados ficassem salvos no sistema de arquivos do servidor ou local na rede, mas devido
ao tempo disponível para o desenvolvimento optei por realizar da forma como consegui fazer,
salvar os dados do arquivo em uma tabela do banco de dados.
Abaixo se pode ver o código fonte da renderizaçao do componente Upload;
<h:form enctype="multipart/form-data">

<rich:panel>
<f:facet name="header">Upload Attachment</f:facet>
<s:decorate id="fileUploadDecoration" template="layout/edit.xhtml">
<ui:define name="label">Attachment</ui:define>
<s:fileUpload id="file"
data="#{attachmentHome.instance.data}"
contentType="#{attachmentHome.instance.contentType}"
fileName="#{attachmentHome.instance.name}"
fileSize="#{attachmentHome.instance.size}" />
</s:decorate>
Quadro 24 - Exemplo do arquivo da view – Elaboração dos autores, 2010

Uma vez o atributo data da tag s:fileUpload configurada para o atributo data da
instancia attachmentHome basta apenas chamar o método persist() para realizar o upload do
arquivo.
Para a realização do download foi criado um outro componente Seam denominado
downloadAttachment, na qual esta definido o método download() abaixo;

public String download() {
Attachment attachment = entityManager.find(Attachment.class, attachmentId);
HttpServletResponse response = (HttpServletResponse)extCtx.getResponse();
response.setContentType(attachment.getContentType());
response.addHeader("Content-disposition", "attachment; filename="" +
attachment.getName() +""");
try {
ServletOutputStream os = response.getOutputStream();
os.write(attachment.getData());
os.flush();
os.close();
facesContext.responseComplete();
} catch(Exception e) {
log.error("nFailure : " + e.toString() + "n");
}

return null;
}
Quadro 25 - Exemplo do método para download – Elaboração dos autores, 2010

Através do método entityManager.find() e possível localizar o id do anexo solicitado e
por meio do os.write() obter os dados do arquivo solicitado.
O tempo quantificado para a realização desta funcionalidade foi de 3 horas.

61

• Considerações finais da facilidade de manutenção

Através destas implementações propostas procuramos avaliar a facilidade de adicionarmos
novas funcionalidades nos projetos atuais. Foi verificado que ambos os frameworks
permitiram inserir as funcionalidades propostas de forma fácil. No framework Ruby on Rails
estas funcionalidades foram obtidas através das instalações de plugins para permitir as
funcionalidades de Upload e envio de emails. Na plataforma JBoss Seam, no entanto foi
apenas necessário incluir taglibs apropriadas para tais funcionalidades não necessitando
realizar nenhuma instalação ou download de arquivos de terceiros.
Pode-se então concluir que tanto JBoss Seam quanto Ruby on Rails possuem facilidade de
manutenção equivalentes, sendo que JBoss Seam não necessita de instalação de plugins para
essas funcionalidades.

11.4 Performance

Performance é um termo muito complexo na qual envolve muitos fatores como,
Sistema Operacional utilizado, quantidade de memória, processador, tecnologia empregada,
fatores estes que podem ocasionar o mascaramento da realidade se não for corretamente
analisados.
Para a realização da comparação entre estas tecnologias de desenvolvimento definimos
alguns pontos importantes.
• Utilizar um único servidor para ambos os frameworks. Ou seja, mesmo hardware e SO
(Processador Intel Core 2 Quad Q8200, 2.33Ghz 4gb DDR2/800Mhz, Windows 7 32bits).

• Utilização do mesmo SGBD (PostgreSQL 8.4).

• Acessar a aplicação remotamente através da rede para não haver interferências externas no
servidor de aplicação.

Como já citado, utilizamos a aplicação Web New Relic para a medição das métricas de
desempenho em ambos ambientes.
Realizamos os seguintes testes nas aplicações:
• Autenticação no Sistema

• Logout no Sistema

62

• Criação de 1 serviço

• Contratar 1 serviço

• Criar 1 usuário

• Criar 100 Usuários

• Criar 1000 Usuários

• Criar 100 Serviços

• Criar 1000 Serviços

A configuração dos ambientes de desenvolvimento foram:

Jboss Seam Ruby on Rails
Versão da Linguagem Java 1.6.0_20 Ruby 1.8.7
Versão do Framework 2.2.0.GA Rails 2.3.8
IDE Eclipse GALILEO 3.5.2 NetBeans 6.8
Banco de Dados PostgreSQL 8.4 PostgreSQL 8.4
Servidor JBoss 5.1.0.GA Mongrel 1.1.5
Quadro 26 – Configuração dos ambientes de desenvolvimento. Elaboração dos autores, 2010.

11.4.1 Teste - Login

Neste teste proposto, iremos realizar o login no sistema. Na realização deste
procedimento, o sistema deverá verificar se as credenciais inseridas na pagina de login são
realmente de usuários cadastrados e após criar a sessão para o usuário.
Neste teste está sendo medido o desempenho do evento gerado ao se clicar no botão
Login.

63

Gráfico 1 – Tempo de resposta na realização do login. Elaboração dos autores, 2010.

Gráfico 2 – Utilização do processador na realização do login. Elaboração dos autores, 2010.

Considerações Finais

Podemos claramente notar a rapidez de execução na plataforma Ruby on Rails nesta
operação. A versão 1.9.1da linguagem Ruby obteve um resultado melhor em comparação com
a versão 1.8.7. A plataforma Java foi em média 849% mais lento que o Ruby on Rails (versão
1.9.1 do Ruby) em tempo de execução.

64

Java também obteve um processamento muito maior para executar esta tarefa
conforme pode-se verificar no Gráfico 2.

11.4.2 Teste – Logout

Este teste proposto tem como objetivo registrar as métricas do servidor no evento do
botão Sair, na qual o servidor deve processar este evento, realizando a finalização da sessão
do usuário e exibir a pagina de login.

Gráfico 3 – Tempo de resposta na realização do logout. Elaboração dos autores, 2010.

65

Gráfico 4 - Utilização do processador na realização do logout. Elaboração dos autores, 2010.


Neste processo verificamos a rapidez em que Ruby on Rails executa o logout no
servidor. Ruby on Rails executa está tarefa muito mais rapidamente que o ambiente Java,
obteve um tempo de resposta mais rápido e um processamento muito menor do que no
ambiente Java. Ruby on Rails executou a tarefa mais rapidamente e utilizando menos
processamento.

11.4.3 Teste – Criar Serviço

Neste teste, serão registradas as métricas do software na execução da criação de um
serviço. Trata-se da inclusão do registro no banco de dados e a exibição da pagina informando
que o serviço foi criado com sucesso.

66

Gráfico 5 – Tempo de resposta na criação de um serviço. Elaboração dos autores, 2010.

Gráfico 6 – Utilização do processador na criação de um serviço. Elaboração dos autores, 2010.


Podemos verificar que o ambiente Ruby on Rails obteve um tempo de resposta
muito melhor que o ambiente Java. Java obteve a média de 334,6 ms de tempo de resposta

67

contra 139 ms de Ruby on Rails utilizando a versão 1.8.7 da linguagem Ruby e 59,2 ms
utilizando a versão 1.9.1 da linguagem Ruby conforme pode-se verificar no Gráfico 7 abaixo.

Gráfico 7 – Média do tempo de resposta na criação de um serviço. Elaboração dos autores, 2010.

A plataforma Ruby destacou-se também por utilizar muito pouco o processador, uma
média de 0,37% na versão Ruby 1.8.7 e 0,0174% na versão 1.9.1 conforme verifica-se no
Gráfico 8 abaixo.

Gráfico 8 - Média do tempo de resposta na criação de um serviço. Elaboração dos autores, 2010.

68

Ruby on Rails obteve um tempo de resposta e processamento muito melhor que a
plataforma Java neste teste.

11.4.4 Teste – Contratar Serviço

Neste teste proposto, é registrado as métricas no evento de criação de um serviço.
Trata-se de uma inclusão no banco de dados do serviço contratado, do envio de uma
mensagem de e-mail ao usuário da empresa fornecedora do serviço e da exibição da página
informando que o serviço foi contratado com sucesso.

Gráfico 9– Tempo de resposta na contratação de um serviço. Elaboração dos autores, 2010.

69

Gráfico 10 – Utilização do processador na contratação de um serviço. Elaboração dos autores, 2010.


Podemos verificar neste teste que a plataforma Java obteve melhores resultados no
tempo de resposta à ação de contratação de serviço. Este cenário foi obtido devido á
facilidade encontrada na plataforma Java na configuração de eventos assíncronos.
O evento chamado para enviar o e-mail aos destinatários foi configurado para ser
executado de forma assíncrona, ou seja, o envio de e-mail é enviado após a renderização da
página de confirmação do serviço contratado. Esta característica permitiu que o Java se
sobressaísse sobre a plataforma Ruby on Rails, uma vez que na execução deste comando no
Ruby on Rails o usuário aguarda o envio de e-mail para somente após receber a confirmação.
Na plataforma Java, o envio de email é executado em background e o usuário obtém uma
resposta de que uma mensagem de e-mail será enviada.
Neste teste não foi possível realizar o teste com a versão 1.9.1 da plataforma Ruby
devido a incompatibilidades apresentadas com a versão 1.8.7.
Java neste teste se destacou no tempo de resposta devido a sua facilidade de
implementação da funcionalidade de eventos assíncronos através de anotações na assinatura
do evento de envio de email.

70

11.4.5 Teste - Criar Usuário

O teste proposto foi a criação de um usuário. Para a criação do usuário são inseridas
informações sobre o usuário do sistema, informações pessoais e endereço.

Gráfico 11 – Tempo de resposta na criação de um usuário. Elaboração dos autores, 2010.

Gráfico 12 – Utilização do processador na criação de um usuário. Elaboração dos autores, 2010.

71


Neste teste verificamos que Ruby on Rails obteve um melhor tempo de resposta e um
menos consumo de processamento.

11.4.6 Teste – Criar 100 Usuários

Neste teste são criados cem usuários através de um script. Poderemos verificar o
desempenho das plataformas na execução em massa de inclusões no banco de dados.

Gráfico 13 – Tempo de resposta na criação de cem usuários. Elaboração dos autores, 2010.

72

Gráfico 14 – Utilização do processador na criação de cem usuários. Elaboração dos autores, 2010.


Podemos verificar através dos resultados obtidos que a plataforma Java obteve
melhores resultados do que a plataforma Ruby.
A aplicação desenvolvida com o framework Jboss Seam obteve um desempenho muito
melhor do que o aplicativo desenvolvido com o framework Ruby on Rails.
Com a atualização da plataforma Ruby da versão 1.8.7 para a versão 1.9.1 obtivemos
uma diferença enorme dos resultados entre as plataformas Ruby. O desempenho da plataforma
Ruby 1.9.1 foi muito melhor no tempo de resposta. Pode-se notar também que a plataforma
Ruby 1.9.1 faz mais utilização do processador do que a versão 1.8.7.
Neste teste, Java obteve um resultado muito melhor do que a plataforma Ruby.

11.4.7 Teste – Criar 100 Serviços

Neste teste são criados cem serviços através de um script. Poderemos verificar o
desempenho das plataformas na execução em massa de inclusões no banco de dados.

Gráfico 15 – Tempo de resposta na criação de cem serviços. Elaboração dos autores, 2010.

73

Gráfico 16 – Utilização do processador na criação de cem serviços. Elaboração dos autores, 2010.


A plataforma Java obteve um resultado um pouco melhor do que a plataforma
Ruby. Assim como no exemplo anterior do item 10.2.4.6, a atualização da plataforma Ruby da
versão 1.8.7 para a versão 1.9.1 proporcionou uma grande diferença nos resultados. A versão
1.9.1 da linguagem Ruby obteve um desempenho muito melhor do que a versão 1.8.7.
Neste teste proposto, Java obteve melhor resultado no tempo de resposta em
comparação com a plataforma Ruby.

11.4.8 Teste – Criar 1000 Serviços

Neste teste proposto serão criados mil serviços através de um script desenvolvido.
Poderemos verificar o desempenho dos ambientes na execução de tarefas em massa.

74

Gráfico 17 – Tempo de resposta na criação de mil serviços. Elaboração dos autores, 2010.

Gráfico 18 – Utilização do processador na criação de mil serviços. Elaboração dos autores, 2010.


Assim como nos outros testes já mostrados, a atualização da plataforma Ruby da
versão 1.8.7 para a versão 1.9.1 proporcionou um alto ganho de desempenho. No entanto, a
plataforma Java continuou obtendo melhores resultados na execução de tarefas em massa.
Java neste teste obteve melhores resultados no tempo de resposta. No quesito uso do
processador, Ruby na versão 1.9.1 obteve melhor utilização do processador.

75

11.4.9 Teste – Criar 1000 Usuários

Neste teste proposto iremos realizar a criação de mil usuários através de um script
desenvolvido. Poderemos verificar a performance dos ambientes na execução de ações em
massa.

Gráfico 19 – Tempo de resposta na criação de mil serviços. Elaboração dos autores, 2010.

Gráfico 20 – Utilização do processador na criação de mil usuários. Elaboração dos autores, 2010.

76


Na criação de mil usuários, Java mostrou ter mais habilidade em executar tarefas em massa e
ser uma linguagem rápida. Ruby, no entanto teve um desempenho inferior obtendo maiores
tempo de resposta.

11.5 Tamanho do código

• Ruby on Rails

Ruby on Rails oferece um comando para verificar o tamanho de sua aplicação. Para
usá-lo você terá que entrar na pasta do projeto Rails, através do prompt de comando, e digitar
o seguinte código: rake stats
Com esse comando, o prompt exibirá uma tela semelhante a essa:
Nome Linhas Classes Métodos
Controllers 660 9 51
Helpers 26 0 1
Models 76 8 2
View 654 26 0
Total 1416 43 54
Quadro 27 - Métricas do ambiente de desenvolvimento Ruby on Rails. Elaboração dos autores, 2010.

• Jboss Seam

Abaixo foi feito um levantamento aproximado da quantidade de linhas do código fonte
e outras métricas do ambiente Jboss Seam neste projeto.

Nome Linhas Classes/Arquivos Métodos
Controllers 2961 34 274
Models 87 12 190
View 4998 43 0
Configurações 956 40 0
Total 9002 129 464
Quadro 28 - Métricas do ambiente de desenvolvimento Jboss Seam. Elaboração dos autores, 2010.

Considerações finais do Tamanho do código

77

Através das tabelas poderemos verificar que o ambiente Ruby on Rails possui valores
muito menores. Podemos então avaliar que o ambiente Ruby on Rails é mais rápido de se
realizar alterações e de se escrever tornando-o melhor para a implementação através de um
menor consumo de tempo na digitação e compreensão do código fonte.

78

12 CONCLUSÕES

Através do trabalho proposto foi realizado um estudo de dois frameworks atuais, Ruby
on Rails e Jboss Seam. De acordo com o propósito do trabalho, foi possível identificar fatores
positivos e negativos de cada framework proporcionando ao leitor a capacidade de optar ou
não pela utilização de um dos frameworks apresentados.
De acordo com o primeiro item da comparação mostrado no capitulo 3, a curva de
aprendizagem foi menos acentuada em Ruby on Rails do que no Jboss Seam.
Como já explicado no Capitulo 10.2.2 obteve-se o tempo de desenvolvimento mais rápido na
plataforma Ruby on Rails.
Foi definido para a medição da facilidade de manutenção, a inclusão de novos recursos ao
sistema. De acordo com o capitulo 10.2.3 as funcionalidades Envio de email e upload e
download de arquivos foram definidas para implementação. Tanto em Java como em Ruby on
Rails este item de comparação foi relativamente fácil e rápido.
Inicialmente foi analisada a curva de aprendizado, onde não foram encontradas muitas
dificuldades na linguagem Ruby e no Framework Ruby on Rails.
Verificou-se neste projeto que a plataforma Jboss Seam possui aproximadamente nove
mil e duas linhas de código e em Ruby on Rails possui aproximadamente mil duzentos e
sessenta e oito linhas de código. Jboss Seam, portanto possui aproximadamente seiscentos e
dez por cento mais linhas de código do que Ruby on Rails. Deve ser levado em consideração
o fato de que Jboss Seam através do Seam-gen realiza a criação de praticamente 70% do
código fonte automaticamente, ou seja, a argumentação de que a quantidade de código
implica no aumento da complexidade e diminuição da velocidade da implementação deve ser
muito bem avaliada, afinal grande parte é gerada automaticamente, sem praticamente nenhum
esforço do programador.
Percebeu-se que o framework Ruby on Rails teve dificuldades na manipulação de uma
grande carga de dados como se pode verificar nos gráficos 21 e 22 abaixo.

79

Gráfico 21 – Média do tempo de resposta na criação de cem usuários. Elaboração dos autores, 2010.

Gráfico 22 – Média do tempo de resposta na criação de mil usuários. Elaboração dos autores, 2010.

As figuras acima mostraram uma deficiência no framework Ruby on Rails utilizando-se a
versão 1.8.7 do Ruby, obtendo a marca de 238.105,2 ms para inserção de 1000 usuários no
banco de dados. Este resultado não foi satisfatório e devido a este fato uma nova solução foi
pesquisada e encontrada. Com a atualização da linguagem Ruby para versão 1.9.1, registrou-
se uma melhora surpreendente na performance da execução de grande carga de dados e
também nos outros testes executados. Cabe salientar que não houve alteração na versão do

80

framework Ruby on Rails. Através deste resultado, evidenciou-se a dependência que o
framework tem da performance de sua linguagem.
Com o aumento da carga de dados, verificou-se que Ruby on Rails na versão 1.8.7 não obteve
seu desempenho proporcional ao tempo esperado. No teste exibido no gráfico 21, obteve-se
13932,6 ms na execução dos dados. Com o aumento de carga em 10 vezes, o tempo estimado
seria de aproximadamente 139000 ms, o que não ocorreu de acordo com os resultados do
gráfico 22, obtendo-se um valor de aproximadamente setenta por cento maior do que o
esperado. Com a atualização do Ruby 1.8.7 para a versão 1.9.1, este resultado caiu de setenta
por cento a mais da versão 1.8.7 para aproximadamente quatorze por cento mais rápido do
que o tempo esperado com um ganho de desempenho de oitenta e cinco por cento.
Java, assim como a versão de Ruby 1.9.1 obteve um comportamento satisfatório,
atendendo proporcionalmente o aumento da demanda de carga. O desempenho obtido no
ambiente Java na criação de 100 usuário foi de 1257,4 ms. Na criação de 1000 usuários o
resultado estimado seria de 125740 ms no entanto obteve-se 10068,2 um rendimento de
aproximadamente vinte por cento a menos do que o esperado.
Abaixo pode-se verificar as médias obtidas nos testes de criação de 100 e 1000 serviços.

Gráfico 23 – Média do tempo de resposta na criação de cem serviços. Elaboração dos autores, 2010.

81

Gráfico 24 – Média do tempo de resposta na criação de mil serviços. Elaboração dos autores, 2010.

Assim como no exemplo anterior, pode-se claramente verificar a melhora de
performance da plataforma Ruby com a sua atualização para a versão 1.9.1.
O desempenho da plataforma Ruby na versão 1.8.7 foi de aproximadamente cinco por centro
melhor do que o resultado esperado.
O desempenho da plataforma Ruby na versão 1.9.1 foi de aproximadamente doze por cento
melhor do que o resultado esperado.
O desempenho da plataforma Java foi de aproximadamente cinqüenta e três por centro melhor
do que o resultado esperado.
Java destacou-se e nos surpreendeu com seu desempenho em relação ao Ruby on Rails
quando submetido ao processamento severo de grande quantidade de dados. Java conseguiu
efetuar as tarefas em um tempo muito menor do que o esperado e isso nos força a crer, ser o
Java uma linguagem com indicação para utilização em ambientes de grande processamento e
manipulação de dados.
Ruby, no entanto se mostrou veloz nas requisições e renderização de páginas, mas deficiente
no processamento de grande carga de dados.

Com as afirmações acima, obteve-se o seguinte quadro de comparações:
JBoss Seam Ruby on Rails
Maior facilidade no
aprendizado da tecnologia 14 semanas 9 semanas
Ruby on Rails.

82

Facilidade de manutenção
4 horas. 4 horas.
equivalentes.
Ruby on Rails se destacou
por sua simplicidade na
9002 linhas de código. 1416 linhas de código.
sintaxe e menor quantidade
de códigos
JBoss Seam destacou-se na
Criação de 1000 Usuários = Criação de 1000 Usuários =
manipulação de uma grande
10.068,2 ms 238.105,2 ms
carga de dados.
Dependência que os
Melhor performance do mesmo aplicativo, apenas
frameworks possuem de suas
atualizando a versão do ruby 1.8.7 para a versão 1.9.1.
linguagens.
Ruby on Rails foi veloz na
manipulação de requisições e Logout do sistema = 164 ms Logout do sistema = 64 ms
renderização de páginas.
Quadro 29 – Quadro de Conclusões. Elaboração dos autores, 2010.

83

13 TRABALHOS FUTUROS.

• Migrar o software desenvolvido da versão Ruby on Rails 2.3.8 para a versão Ruby on
Rails 3.0.

• Migrar o software desenvolvido da versão Jboss Seam 2.0 para a versão Jboss Seam
3.0

• Realizar testes no Sistema Operacional Linux.

85

APÊNCIDE A - Visão geral do Sistema

Trata-se de um sistema protótipo, para web, que permitirá o cadastro de usuários em
dois tipos diferentes, Empresa e Cliente.
A Empresa será capaz de se registrar e atualizar seu cadastro se necessário e através do
link “Criar novo Serviço” poderá oferecer seus serviços para os clientes que se cadastrarem
no sistema. Além dessa função no menu, a Empresa terá outros dois links para acesso, que
são:
-Ver meus Serviços solicitados: Mostra todos os serviços cadastrados da Empresa
logada.
-Ver meus Clientes: Lista todos os Clientes que contrataram o Serviço da Empresa
logada.
Caso o usuário for um Cliente, ele será capaz de “Solicitar um Serviço”, que listará
todos os serviços oferecidos de todas as empresas cadastradas no sistema. Também estará
disponível no menu de Cliente o link “Ver meus Serviços solicitados”, que mostrará todos os
serviço que o cliente logado contratou. Além da função “Editar Perfil” onde o Cliente irá fazer
todas as modificações necessárias para atualizar seu cadastro no sistema.

86

APÊNCIDE B - Casos de uso

Figura 3 – Caso de Uso de Empresa. Fonte: Nossa (2010)

Figura 4 – Caso de Uso de Cliente. Fonte: Nossa (2010)

87

APÊNCIDE C - Análise de requisitos funcionais e não funcionais.

F1 – Autenticação no Sistema Oculto ( )
Descrição: O sistema deve permitir que o usuário autentique-se e tenha autorização para
realizar as ações estabelecidas.
Requisitos não Funcionais
Nome Restrição Categori Desejável Permanente
a
NF 1.1 Dados Os usuários necessitarão saber Segurança ( ) (X)
de acesso seus logins e senha de acesso
cadastrados.
NF 1.2 Pagina Todo o processo de autenticação, Interface () (X)
Única assim como exibição de
mensagens de erros será exibido
em uma mesma pagina.
Quadro 30 - Requisitos F1 – Elaboração dos autores, 2010.

F2 – Exibir Informações Cadastrais Oculto ( )
Descrição: O sistema irá permitir que os usuários verifiquem os seus dados cadastrais.
Nome Restrição Categori Desejável Permanente
a
NF 2.1 Os usuários só terão acesso a Segurança ( ) (X)
Controle de esta função caso estejam
Acesso autenticados no sistema.
NF 2.2 Botão Em cada pagina haverá um Interface () (X)
Solicitar botão na qual permitira alterar os
Alteração dados cadastrais.

F3 – Solicitar Alteração Cadastral Oculto ( )
Descrição: O sistema irá permitir que os clientes possam alterar os seus dados cadastrais.
Nome Restrição Categoria Desejável Permanente
NF 3.1 Os usuários só terão acesso a Segurança () (X)

F4 – Solicitar novo Serviço Oculto ( )
Descrição: O sistema irá permitir que os clientes realizem contratos de serviços das empresas

88

NF 4.2 Tipos O sistema ira apresentar tipos Especificação ( ) (X)
de Serviços cadastrados de serviços na qual
o cliente poderá solicitar,
portanto pode-se futuramente
aumentar essa quantidade.

F5 – Ver meus Serviços solicitados Oculto ( )
Descrição: O sistema irá permitir que o cliente visualize os serviços que ele contratou.
NF 5.2 Dados Cada serviço contratado é Especificação ( ) (X)
do Serviço listado, mostrando o nome do
serviço, o valor do serviço e o
nome da empresa que ofereceu
tal serviço.

F6 – Criar novo Serviço Oculto ( )
Descrição: O sistema irá permitir que a empresa cadastre um novo serviço para oferecer aos
clientes.
NF 6.2 Cada serviço terá que ser Especificação ( ) (X)
Registro inserido o seu nome, descrição e
valor em reais.
NF 6.3 Edição Cada serviço cadastrado poderá
/ Exclusão posteriormente ser alterado ou
excluído pela Empresa.

F7 - Ver meus Serviços oferecidos Oculto ( )
Descrição: O sistema permitira que a empresa veja todos os seus serviços cadastrados.
NF 7.2 Dados Cada serviço cadastrado é Especificação ( ) (X)
do Serviço listado, mostrando o nome do
serviço,a descrição do serviço e

89

o valor em reais do serviço.

F8 - Ver meus Clientes Oculto ( )
Descrição: O sistema permitira que a empresa visualize todos os cliente que contrataram seus
serviços cadastrados.
NF 8.2 Dados O sistema exibirá todos os Especificação
do Serviço serviços que foram contratados.
NF 8.3 Dados O sistema exibirá todos os Especificação ( ) (X)
do Cliente clientes que contrataram os
serviços da empresa.

90

APÊNCIDE D - Referências Cruzadas

Nome Atores Descrição Referencias
Cruzadas
Autenticar Cliente O usuário deve inserir seu login e F1
Usuário ou senha para autenticação e ter seu
Empresa acesso permitido no sistema web.
Solicitar Cliente Cliente poderá contratar um serviço F1,F4,F5,F6
Serviços cadastrado no sistema.
Criar novo Empresa Empresa poderá cadastrar um novo F1,F4, F6, F7, F8
Serviço serviço que ela oferece.
Quadro 38 - Referencias Cruzadas – Elaboração dos autores, 2010.

91

APÊNCIDE E - Mapa do site

Figura 5 – Mapa do site. Fonte: Nossa (2010)

92

APÊNCIDE F - Wireframes

Página de Autenticação

Figura 6 – Tela de login. Fonte: Nossa (2010)

93

Página de registro

Figura 7 – Tela de registro. Fonte: Nossa (2010)

94

Página inicial do usuário Empresa

Figura 8 – Tela inicial do usuário Empresa. Fonte: Nossa (2010)

Criar novo Serviço

Figura 9 – Tela para criar novo Serviço (Usuário Empresa). Fonte: Nossa (2010)

95

Ver meus Serviços oferecidos

Figura 10 – Tela para ver os Serviços oferecidos (Usuário Empresa). Fonte: Nossa (2010)

Ver meus Clientes

Figura 11 – Tela para ver Clientes (Usuário Empresa). Fonte: Nossa (2010)

96

Página inicial do usuário Cliente

Figura 12 – Tela inicial do usuário Cliente. Fonte: Nossa (2010)

Solicitar novo Serviço

Figura 13 – Tela para solicitar novo Serviço(usuário Cliente). Fonte: Nossa (2010)

97

Ver meus Serviços Solicitados

Figura 14 – Tela para ver os Serviços solicitados(usuário Cliente). Fonte: Nossa (2010)

98

REFERENCIAS BIBLIOGRÁFICAS

ALECRIM, Emerson. Conhecendo o Servidor Apache (HTTP Server Project). Disponível
em <http://www.infowester.com/servapach.php> Acesso em 19 mai 2009.

ANQUETIL,Nicolas. Manutenção de Software. Disponível em
<http://www.ucb.br/prg/professores/anquetil/manutencao.php> Acesso em 23 jun 2009.

APACHE. Apache Tomcat. Disponível em <http://tomcat.apache.org> Acesso em 19 mai
2009.

AZAMBUJA. Trabalho da Semana do SBRC. Disponível em
<http://professores.faccat.br/azambuja/index_paradigmas.htm>. Acesso em 12 de maio de
2009, p.1.

BORLAND. Customer Profile, Sigma-Aldrich. Disponível em <http://www.borland.com/br/
customers/profiles/sigma_aldrich.html>. Acesso em 20 mai 2009.

BORTOLASSI,Giuliano. Conhecendo o JEE – Part2. Disponível em
<http://jeenoob.blogspot.com/2007/01/conhecendo-o-jee-part2.html> Acesso em 17 mai
2009.

DEVDAILY. Using the Runtime method to invoke the garbage collector. Disponível em
<http://www.devdaily.com/java/edu/pj/pj010008/pj010008.shtml> Acesso em 16 mai 2009.

DUCKETT, Chris. Developer Spotlight: Hitting the Seam with Gavin King. Disponível em
<http://www.builderau.com.au/program/java/soa/Developer-Spotlight-Hitting-the-Seam-with-
Gavin-King/0,339024620,339285612,00.htm> Acesso em 16 mai 2009.

EDIGER, Brad. Advanced Rails. O'Reilly, 2007. 354 p.

E-GENIAL. O QUE É RUBY ON RAILS?, Camadas MVC. Disponível em
<http://www.egenial.com.br/cursorails/ruby_on_rails> Acesso em: 20 mai 2009.

FACCAT. As primeiras máquinas. Disponível em <http://professores.faccat.br/assis/hcomp /
PrimeirasMaquinas.html> Acesso em 17 mai 2009.

99

FAYAD, Mohamed; Schmidt, Douglas. Object-Oriented Application Frameworks.
Communications of the ACM, New York, v. 40, n. 10, p. 32-38, Oct. 1997.

FIALHO JR, Mozart. Dicionário de Informática – Interpretador. 2 Ed. Goiânia: Terra,
2002, p.117.

______. Dicionário de Informática – Linguagem de Maquina. 2 Ed. Goiânia: Terra, 2002,
p.123.

______. Dicionário de Informática – Linguagem de Programação. 2 Ed. Goiânia: Terra,
2002, p.123.

______. Dicionário de Informática – Sistema Binário. 2 Ed. Goiânia: Terra, 2002, p.170.

FLYNT, Clif. Tcl/Tk, A Developer's Guide. 2. Ed. San Francisco, 2003.

FOCALINUX , Características do Apache. Disponível em <
http://focalinux.cipsga.org.br/guia/avancado/ch-s-apache.htm >. Acesso em 13 jun 2010.

FOLHA ONLINE. Entenda o que é o código-fonte de um programa. Disponível em <
http://www1.folha.uol.com.br/folha/informatica/ult124u7618.shtml >. Acesso em 5 mai.
2009.

HERCULIANI, Cristóvam Emilio. Desenvolvimento de um Software de autoria para
alunos deficientes não-falantes nas atividades de contos e recontos de histórias. Marilia,
2007, p.40.

HUSTON. A.B.WATLEY CASE STUDY. Disponivel em <
http://in.sun.com/sunnews/success/consolidation/onlinestock.html > . Acesso em 13 jun 2010.

ICEA. Instituto de Controle do Espaço Aéreo, Módulo V – Linguagens. Disponível em
<http://www.icea.gov.br/ead/anexo/23101.htm> Acesso em 17 mai 2009.

IDOC. Conceito de Workflow. Disponível em < www.idoc.inf.br/pdf/Workflow.pdf > Acesso
em 28 Jun 2010.

JAVAFREE. Java. Disponível em < http://javafree.uol.com.br/wiki/java > Acesso em 27 Jun
2010.

100

______. Tutorial Java 2: Características Básicas. Disponível em <http://www. javafree.org/
artigo/871496/Tutorial-Java-2-Caracteristicas-Basicas.html>. Acesso em 10 mai. 2009.

JBOSS. Chapter 3. The contextual component model. Disponível em
<http://docs.jboss.org/seam/1.2.1.GA/reference/en/html/concepts.html#d0e2518> Acesso em
18 mai 2009.

______. Framework for Organizing Cross Cutting Concerns. Disponível em
<http://www.jboss.org/jbossaop/>. Acesso em 20 mai 2009.

JCP. JSRs: Java Specification Requests. Disponível em <http://jcp.org/en/jsr/ detail?
id=299>. Acesso em 20 mai 2009.

MATZ. An Interview with the Creator of Ruby. Disponível em <
http://linuxdevcenter.com/pub/a/linux/2001/11/29/ruby.html >. Acesso em 13 jun 2010.

______. More code browsing questions. Disponível em < http://blade.nagaokaut.ac.jp/cgi-
bin/scat.rb/ruby/ruby-talk/2773 >. Acesso em 13 jun 2010.

NGUYEN, Binh. Compiled Language. Disponível em <http://linux.about.com/cs/linux101 /
g/compiledlanguag.htm>. Acesso em 13 de maio de 2009, p.1.

PRADO, Alexandro dos Anjos. JEE - Um caminho prazeroso e interessante! Disponível
em <http://www.devmedia.com.br/articles/viewcomp.asp?comp=3747>. Acesso em 14 de
maio de 2009.

PRICE, Ana Maria de Alencar & TORCANI, Simào Sirineu. Implementação de Linguagens
de Programação: Compiladores. Porto Alegre, 2001, 197 pgs.

RAILSGUIDE. Getting Started with Rails. Disponível em <http://guides.rubyonrails.org
/getting_started.html>. Acesso em 11 de maio de 2009.

REDHAT. Seam and jBPM: the todo list example. Disponível em <http://www.redhat.com /
docs/manuals/jboss/jboss-eap-4.2/doc/seam/Seam_Reference_Guide/Seam_Tutorial-
Seam_and_jBPM_the_todo_list_example.html> Acesso em 19 mai 2009.

101

______. Using JMX as a Microkernel. Disponível em <http://www.redhat.com/docs/en-US/
JBoss_Enterprise_Application_Platform/4.3.0.cp04/html/Server_Configuration_Guide/The_J
Boss_JMX_Microkernel-Using_JMX_as_a_Microkernel.html>. Acesso em 20 mai 2009.

ROESLER, Wolfram. The Hello World Collection. Disponível em <http://www.roesler-
ac.de/wolfram/hello.htm>. Acesso em 30 jun 2010.

Ruby-Lang. Ver tudo como objeto. Disponível em < http://www.ruby-lang.org/pt/sobre-o-
ruby/ >. Acesso em 13 jun 2010.

SANTOS, Elomar Nascimento dos. Um pouco mais sobre o Ruby. Disponível em
<http://www.elomarns.com/blog/ruby/um-pouco-mais-sobre-o-ruby> Acesso em 17 mai 2009.

SAUVÉ, Jacques Philippe. FRAMEWORKS. Disponível em <
http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/frame/oque.htm>. Acesso em 27 Jun.
2010.

SOMMERS, Frank. Gavin King Explains JBoss Seam. Disponível em
<http://www.artima.com/forums/flat.jsp?forum=276&thread=164452> Acesso em 17 mai
2009.

SUN. Web-Tier Application Framework Design. Disponível em
<http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-
tier/web-tier5.html>. Acesso em 14 de maio de 2009.

______. About the Java EE Containers. Disponível em < http://docs.sun.com/app/docs/doc/
819-3658/ablmt?l=en&a=view > Acesso em 26 Jun 2010.

______. Model-View-Controller. Disponível Disponível em <http://java.sun.com/blueprints/
guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html>. Acesso em 13 jun
2010.

URUBATAN, Rodrigo. Java EE 5 - servidores de aplicação. Disponível em
<http://www.urubatan.com.br/java-ee-5-servidores-de-aplicacao/> Acesso em 17 mai 2009.

VENNERS, Bill. Garbage Collection, Chapter 9 of Inside the Java Virtual Machine.
Disponível em <http://www.artima.com/insidejvm/ed2/gc.html> Acesso em 13 mai 2009.

102

WANGENHEIM, Aldo Von. O que é um Algoritimo?. Disponível em <
http://www.inf.ufsc.br/~awangenh/ICC/icc-aula2.pdf >. Acesso em 27 Jun. 2010.

WEBDEVELOPERSNOTES. What is web server - a computer of a program?. Disponível
em <http://www.webdevelopersnotes.com/basics/what_is_web_server.php> Acesso em 19
mai 2009.

WHATIS. Web server. Disponível em <http://whatis.techtarget.com/definition/
0,,sid9_gci213606,00.html> Acesso em 19 mai 2009.

Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails

Mais conteúdo relacionado

Mais procurados (20)

Semelhante a Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails (20)

Último (20)

Comparação de Tecnologias para Web - JBoss Seam e Ruby on Rails