Universidade do Minho
Escola de Engenharia Departamento de Informática
Paulo Jorge da Silva Maia
Ruby on Rails versus Java WEB
Universidade do Minho Escola de Engenharia Departamento de Informática
Paulo Jorge da Silva Maia
Ruby on Rails versus Java WEB
Estudo comparativo arquitetural e metodológico
Master dissertation
Master Degree in Computer Science
Dissertation supervised by F. Mário Junqueira Martins
A G R A D E C I M E N T O S
Gostaria de expressar os meus agradecimentos a todas as pessoas, que de forma direta ou indireta, contribuíram para a realização e conclusão desta dissertação. No entanto, gostaria de realçar e deixar um agradecimento especial às seguintes pessoas. Ao meu orientador Professor F. Mário Martins, pela orientação, disponibilidade, e sobretudo pela paciência despendida durante a realização desta dissertação.
Aos meus pais, pelas oportunidades que me proporcionam a longo de todo o meu per-curso académico, pela confiança depositada em mim durante a licenciatura e o mestrado, pelo incentivo e compreensão que sempre me deram.
Por fim, também gostaria de deixar os meus agradecimentos a todos os meus colegas e amigos que me acompanharam durante o percurso académico, em especial ao André Nogueira e ao Diogo Barbosa, que sempre me ajudaram a melhorar.
A B S T R A C T
The methodological development of multi-tier Web applications, satisfying the MVC mo-del and implementing a layer containing data persistence supported by relational databases, has been supported mainly by two major development platforms: Java WEB and .NET. The emergence of the open source Framework Ruby on Rails, when the creation of Web applica-tions is a key area of Engineering Software, requires a detailed analysis of the characteristics of this third platform. This work is fundamental to comparatively study the software te-chnologies and architectures proposed by Ruby on Rails versus tete-chnologies Java Web (i.e Apache Struts2), and the methodologies and supporting technologies underlying both de-velopment environments.
R E S U M O
O desenvolvimento metodológico de aplicações Web multi-camada, satisfazendo o modelo MVC e contendo uma camada de persistência de dados suportada por bases de dados relacionais, tem sido suportada fundamentalmente por duas grandes plataformas de de-senvolvimento: Java Web e .NET. O aparecimento do open source Framework Ruby on Rails, num momento em que a criação de aplicações Web é uma área fundamental da Engenharia de Software, obriga a uma análise detalhada das características desta terceira plataforma. Este trabalho tem por objetivo fundamental estudar de forma comparativa as arquiteturas de software e tecnologias propostas por Ruby on Rails versus as tecnologias Java Web (i.e Apache Struts2) e, ainda, comparar as metodologias e tecnologias de suporte ao desenvolvimento subjacentes a ambos os ambientes.
C O N T E Ú D O 1 i n t r o d u c ã o 3 1.1 Motivação 3 1.2 Objetivos 3 1.3 Estrutura do Documento 4 2 l i n g ua g e n s e f r a m e w o r k s 7
2.1 Breve introdução histórica das Linguagens 7
2.2 Frameworks de desenvolvimento Web 7
3 e s ta d o d a a r t e 9
3.1 O Modelo MVC 9
3.2 Implementações MVC 10
3.2.1 Action-Based (Push-MVC) 10
3.2.2 Component-Based (Pull-MVC) 10
3.3 Java Platform, Enterprise Edition - JEE 11
3.3.1 Linguagem de Programação Java 11
3.3.2 Componentes (APIs) 14
3.3.3 Diferença entre Application Server e Container 16
3.3.4 Apache Struts2 - Framework 18
3.3.5 Componentes - Apache Struts2 18
3.4 Ruby on Rails 19
3.4.1 Ruby on Rails - Framework 20
3.4.2 Linguagem de programação Ruby 21
3.4.3 Componentes 23
3.4.4 Metodologia 27
4 i n t e g r at e d d e v e l o p m e n t e n v i r o n m e n t - ide 29
4.1 Características essenciais de um Editor/IDE 29
4.2 JetBrains Rubymine 30
4.3 Netbeans 31
5 a p l i c a ç õ e s d e s e n v o lv i d a s 33
5.1 Affable Bean 33
5.2 Serviço de Taxis e Rent-a-Car - SeTaRe 34
5.2.1 Descrição de AirPort Taxi Transfers 35
5.2.2 Descrição de Rental Cars 35
viii Conteúdo 5.4 Implementação 37 5.4.1 Serviço de Rent-a-Car 37 5.4.2 Serviço de Táxis 39 6 a ná l i s e c o m pa r at i va 41 6.1 Método de Comparação 41 6.1.1 Investigação 41 6.1.2 Implementação 41 6.1.3 Avaliação 42 6.2 Critérios de Avaliação 42
6.2.1 Critérios de Avaliação – Fase I 43
6.2.2 Critérios de Avaliação – Fase II 44
6.3 Síntese de Critérios 45 7 r e s u lta d o s 47 7.1 Configuração Inicial 47 7.2 Documentação e Comunidade 52 7.3 Complexidade 53 7.4 Design Patterns 54
7.4.1 Model View Controller - MVC 54
7.4.2 Convention over Configuration - CoC 57
7.4.3 Inversion of Control - IoC 59
7.4.4 Don’t Repeat Yourself - DRY 63
7.5 Ecossistema do framework 63
7.5.1 Bibliotecas 63
7.5.2 Internacionalização - I18n 64
7.5.3 Asynchronous JavaScript and XML - AJAX 65
7.5.4 Scaffolding 66 7.5.5 Segurança 67 7.5.6 Testes 69 7.6 Extensibilidade 70 7.7 Suporte e Manutenção 71 8 c o n c l u s ã o 73
L I S TA D E F I G U R A S
Figura 1 Modelo MVC 10
Figura 2 Esquema de compilação e execução Java 12
Figura 3 Diagrama estrutural da plataforma Java 14
Figura 4 Modelo esquemático da metodologia Agile 28
Figura 5 The Affable Bean - Aplicação de compras online 33
Figura 6 Aplicações utilizadas no levantamento de requisitos 34
Figura 7 Diagrama de Casos de Uso - SeTaRe 36
Figura 8 Página Index - Aluguer de Carros 37
Figura 9 Página de resultados - Aluguer de Carros 38
Figura 10 Página de pagamento - Aluguer de Carros 38
Figura 11 Página Index - Aluguer de Taxis 39
Figura 12 Página de resultados - Aluguer de Taxis 39
Figura 13 Página de pagamento - Aluguer de Taxis 40
Figura 14 Estrutura de ficheiros em Struts2 48
Figura 15 Estrutura do ficheiros Rails 50
Figura 16 Arquitetura MVC - Struts2 55
Figura 17 Arquitetura MVC - Rails 56
L I S TA D E TA B E L A S
Tabela 1 Alguns dos Application Servers Java mais utilizados no mercado 17
Tabela 2 Síntese dos critérios a avaliar 45
Tabela 3 Mapeamento URL relativa a uma Action Class 57
Tabela 4 Mapeamento do Action Result Code numa View Template (JSP) 58
Tabela 5 Rotas RESTful geradas automaticamente 58
L I S TA D E L I S TA G E N S
3.1 Procura utilizando métodos da Classe . . . 24
3.2 Procura utilizando clausula where. . . 24
3.3 Método do objeto order(linha) . . . 24
7.1 Criação de Setare através do generator rails new . . . 49
7.2 Criação de um Controller e View utilizando generator Rails . . . 50
7.3 Configuração da Base de Dados em Rails . . . 51
7.4 Criação de Model através de Rails generator . . . 51
7.5 Definição de rotas http em Rails . . . 58
7.6 Definição dos Beans com Spring . . . 61
7.7 Struts2 Action com IoC. . . 61
7.8 Injeção de Dependências em Ruby . . . 62
7.9 Definição de dependências utilizando Maven. . . 64
7.10 Definição de dependências utilizando RubyGems . . . 64
7.11 Definição de formato de resposta em Struts2 . . . 66
7.12 Tipos de formatos de resposta em Rails . . . 66
7.13 Utilização do generator scaffold . . . 66
7.14 Conversão SQL resultante do uso de Query Builder de Rails . . . 67
7.15 Proteção contra SQL Injection com Named Queries . . . 68
1
I N T R O D U C Ã O
1.1 m o t i va ç ã o
Recentemente toda a comunidade informática, em especial nos Estados Unidos, vem se-guindo com curiosidade o aparecimento do Framework open-source Ruby on Rails (Rails), uma plataforma de desenvolvimento de aplicações Web tendo por base a linguagem de pro-gramação orientada pelos objetos Ruby, satisfazendo o modelo MVC e com capacidade de gerir persistência. Esta plataforma foi divulgada ao público em 2005. Assim, no universo do desenvolvimento de aplicações Web, que continua a ter uma expansão muito signifi-cativa, dado que a maioria das empresas estão atualmente a converter as suas aplicações desktop para aplicações Web e até para aplicações móveis, surge a necessidade de analisar e avaliar, quer do ponto de vista arquitetural quer do ponto de vista da metodologia de desenvolvimento, esta nova alternativa, tanto mais que a mesma reclama ser, do ponto de vista da eficácia de desenvolvimento, muito superior a .NET e superior às tecnologias Java Web. Rails é um Meta-Framework constituído por Frameworks mais pequenos que abordam camadas e aspetos específicos típicos das aplicações Web.
1.2 o b j e t i v o s
O desenvolvimento de novos projetos Web, tem entre outros aspetos, ser rico em funcionali-dades, extensível e de fácil manutenção. Uma grande parte dos Frameworks Web existentes são adequados apenas para projetos de pouca complexidade. Entre estes, existe um número particularmente elevado de Frameworks Web open-source, o que faz com que exista alguma apreensão quanto à utilização dos mesmos no desenvolvimento de aplicações em situações do mundo real. Portanto como pré-requisito, pretende-se que o Framework de desenvol-vimento escolhido seja amplamente utilizado, de modo que este já seja considerado uma plataforma estável.
A presente dissertação tem como propósito, comparar o Framework Ruby on Rails (Rails) que apresenta uma expansão significativa no desenvolvimento de aplicações Web, com um Framework que tem como base as tecnologias Java Enterprise Edition (JEE). De uma
4 Capítulo 1. introducão
maneira geral, Rails é conhecido por focar-se no desenvolvimento rápido e ágil, enquanto JEE foca-se na flexibilidade e integração com IT empresarial. Desta forma pretende-se que a escolha do Framework JEE para comparar com Rails, seja tomada mediante as necessidades do projeto a desenvolver.
JEE apresenta uma vasta oferta de Frameworks de desenvolvimento web, desde nível mais baixo de abstração utilizando a API Java Servlets, Frameworks pure-MVC, ou até mesmo Full-Stacks.
Considerou-se que uma boa opção de tecnologia JEE escolhida como base de comparação com Rails seria o Framework Apache Struts2 (Struts2), que é um Pure-MVC Framework.
Tendo em conta que existem como outras opções Frameworks Full-Stack, o principal ar-gumento na escolha deste Framework nesta comparação, surge da necessidade de entender qual o valor acrescentado em utilizar um Framework em que nós oferece ferramentas es-pecíficas para cada tarefa, mas que nos restringe em termos de flexibilidade, enquanto que podemos utilizar um Framework mais simplificado, mas que nos oferece a liberdade de pa-rametrizar quais os componentes tecnológicos que pretendemos incorporar sem restrições a uma determinada tecnologia, como é o caso de Struts2.
No âmbito do estudo, foram ainda desenvolvidas duas aplicações Web, uma utilizando Rails e outra utilizando Struts2, que permitiram tecer considerações com base em determi-nados critérios de avaliação que foram definidos.
1.3 e s t r u t u r a d o d o c u m e n t o
A presente dissertação apresenta num capítulo inicial o Estado da Arte, este por sua vez, encontra-se divido em três subcapítulos, que abordam na ordem descrita, o modelo MVC, a plataforma JEE e por último a Framework Rails.
No subcapítulo do Modelo MVC é dedicado à importância da implementação do modelo MVC e à forma como este revolucionou a estrutura das aplicações, sendo demonstrado, como é feita a implementação do modelo.
No subcapítulo JEE - Struts2, e de Rails, são abordadas de uma forma geral todas as componentes inerentes às respetivas plataformas, sendo introduzidas historicamente, de-monstrando a evolução das mesmas até ao atual momento. Em cada um dos subcapítulos são também abordados isoladamente nas respetivas secções os aspetos e características das linguagens de desenvolvimento, e os diversos componentes que as caracterizam.
Após a caracterização dos Frameworks, existe ainda um capítulo dedicado à importância dos IDEs, abordando a importância dos mesmos no desenvolvimento de aplicações, onde são abordados os dois IDEs escolhidos, nomeadamente RubyMine para o desenvolvimento em Rails e Netbeans para o desenvolvimento de aplicações em Struts2.
1.3. Estrutura do Documento 5
De seguida, é apresentado um capítulo que apresenta as aplicações desenvolvidas, assim como o conjunto de principais requisitos de que são resultado, e as funcionalidades que implementam.
Depois de demonstradas as aplicações desenvolvidas encontram-se um capítulo que de-monstra como foi definido o método comparativo, bem como os critérios de avaliação ine-rentes.
De seguida, é apresentado o capítulo de resultados que surge como o mais importante da presente dissertação que abrange cada critério de avaliação definido, expondo as formas de implementação e comparando-as.
considera-2
L I N G U A G E N S E F R A M E W O R K S
2.1 b r e v e i n t r o d u ç ã o h i s t ó r i c a d a s l i n g ua g e n s
Quando usamos os termos Ruby e Java, devemos salientar que estas apenas são lingua-gens. Java foi inicialmente desenvolvida pela Sun Microsystems e lançada no ano de 1995. Ruby foi desenvolvida como sendo um projeto do Governo japonês lançado também no ano de 1995. Contudo, uma aplicação Web não é apenas construido recorrendo à lingua-gem, mas através da linguagem conjugada com um Framework de desenvolvimento. O objetivo do Framework é facilitar a construção de uma aplicação, fornecendo ferramentas pré-construídas e técnicas bem definidas e procedimentos para fazer as coisas como a vali-dação da entrada de utilizadores, gestão de conexões à base de dados, gestão dos pedidos de encaminhamento de utilizadores para o bloco de código pretendido que irá processar o pedido, fornecendo a estrutura (scaffolding) de uma aplicação rapidamente, etc. Prati-camente todos as aplicações Web modernas são desenvolvidos recorrendo a um ou mais Frameworks. O uso de um Framework permite que o programador se concentre apenas nós requisitos da aplicação e não nos aspetos comuns a todas as aplicações (e.g forma como de-terminada linguagem acede à base de dados). Usando um Framework, este permite que o programador se concentre na implementação da lógica de negócio, e não nos aspetos mais comuns que praticamente todas as aplicações partilham, acelerando o desenvolvimento.
2.2 f r a m e w o r k s d e d e s e n v o lv i m e n t o w e b
Existem duas grandes categorias concetuais de Frameworks:
• Frameworks Full-Stack
8 Capítulo 2. linguagens e frameworks
Full-Stack
Frameworks Full-Stack abordam o desenvolvimento Web das aplicações Web do início ao fim. Têm normalmente uma infraestrutura ou componentes que abordam o paradigma MVC, que tratam da interação com a base de dados, implementando o CRUD da aplicação. De uma forma geral possuí toda a tecnologia que trata da interação entres os diversos com-ponentes da aplicação, deixando apenas a parte lógica para a equipa de desenvolvimento.
• VANTAGENS
As equipas de desenvolvimento não precisam de preocupar-se em como integrar com a base de dados, ou como integrar com um sistema de mensagens. É um conjunto de bibliotecas conjuntas que adotam um estilo de desenvolvimento padronizado, que assegura que o programador não tenha de escrever o código de configuração (Glue-Code) para interligar as camadas.
• DESVANTAGENS
Alguns Frameworks sugerem ou obrigam determinadas tecnologias, o que significa que se perde alguma liberdade de escolha. Assim torna-se difícil mudar alguns com-ponentes, e caso seja necessário, acaba por se perder algumas funcionalidades proje-tadas para funcionar com o conjunto completo.
Frameworks Pure-MVC
Os Frameworks MVC são tipicamente os mais populares no desenvolvimento Web, estes são estruturados em torno da estrutura de uma aplicação Web reutilizável. Reutilização é discutida com o modelo, com objetos de domínio do negócio, ou com controlador que trata de processar os pedidos.
• VANTAGENS
São geralmente referidos como Frameworks leves, o que significa que existe uma me-nor complexidade, e menos rígidos quanto à utilização de determinadas tecnologias, ficando ao encargo do programador saber se quer integrar ou não.
• DESVANTAGENS
Geralmente tem de ser escrito o código de configuração da aplicação(Glue-Code) sem-pre que um novo plugin é adicionado.
3
E S TA D O D A A R T E
3.1 o m o d e l o m v c
O grande desafio das equipas de desenvolvimento de aplicações é cada vez mais, produ-zir aplicações seguras, eficientes, de fácil manutenção, reutilizáveis e em prazos cada vez menores.
Em 1979, Trygve Reenskaug surgiu com uma nova arquitetura para o desenvolvimento de aplicações. Na sua implementação, as aplicações repartiam-se em três tipos de compo-nentes: Models, Views e Controllers.
O sucesso para o desenvolvimento de aplicações com tecnologia orientada a objetos está intimamente ligada à arquitetura que usamos para construir uma aplicação.
A organização em camadas é a chave para a independência entre os componentes e esta independência é que vai atingir os objetivos de eficiência, escalabilidade, reutilização e facilidade de manutenção.
A arquitetura MVC fornece uma maneira de dividir a funcionalidade envolvida na ma-nutenção e apresentação dos dados de uma aplicação. Esta foi originalmente desenvolvida para mapear as tarefas tradicionais de entrada, processamento, e saída para o modelo de in-teração com o utilizador. Usando o modelo MVC torna-se mais fácil mapear estes conceitos no domínio de aplicações Web multi-camadas.
Na arquitetura MVC o Model representa os dados da aplicação e as regras do negócio que comandam o acesso e a modificação dos dados.
A View liga o conteúdo de uma parte particular do Model e encaminha para o Controller as ações do utilizador, obtendo os dados do Model por via do Controller definindo como os dados devem ser apresentados.
O Controller define o comportamento da aplicação, interpretando as ações do utilizador e encaminhando para determinado Model. Num cliente de aplicações Web essas ações do utilizador poderiam ser cliques de botões ou seleções de menus. As ações realizadas pelo Model incluem ativar processos de negócio ou alterar o estado do Model. Com base na ação do utilizador e no resultado do processamento do Model, o Controller seleciona determinada View a ser mostrada como parte da resposta à solicitação do utilizador. Normalmente um
10 Capítulo 3. estado da arte
Figura 1: Modelo MVC
Controller trata de um conjunto de funcionalidades relacionadas. Na figura 1, pode ser
observado o esquema abstrato das ligações entre os diversos componentes M-V-C. [1]
3.2 i m p l e m e n ta ç õ e s m v c
Existem algumas formas de implementar a estrutura do modelo MVC. No entanto, existem dois tipos principais de arquiteturas concorrentes sobre como um Framework MVC deve ser implementado. Os dois tipos mais comuns de implementação que podem ser encontrados são:
3.2.1 Action-Based (Push-MVC)
Os Frameworks baseados em ações são os mais comuns. A ideia é que, quando um pedido vem do cliente para o servidor, existe um gestor de pedidos que funciona como um con-trolador. Este gestor envia os dados do pedido para o model, que de seguida envia para a view.
3.2.2 Component-Based (Pull-MVC)
Frameworks baseados em componentes focando-se num desenvolvimento rico do interface. Afasta-se do ligeiramente do conceito de processamento de pedido e adota um conceito baseado na geração da View. Com Frameworks MVC baseados em componentes, é da responsabilidade da view obter dados a partir dos vários Controllers e gerir-se a si própria. Em vez de ter o Controller, a dar todos os dados pretendidos, é a view que tem a função de extrair (puxar) todos os dados dos Controllers.
3.3. Java Platform, Enterprise Edition - JEE 11
3.3 java p l at f o r m, enterprise edition - jee
As aplicações Web de hoje em dia já possuem regras de negócio bastante complicadas. Codificar essas regras representam já um grande trabalho. Além dessas regras, conhecidas como requisitos funcionais de uma aplicação, existem outros requisitos que precisam ser alcançados através da infraestrutura que são por exemplo, a persistência na base de dados, transações, acesso remoto, web services1, gestão de threads, gestão de conexões HTTP, cache de objetos, gestão de sessões web, entre outros. Estes são chamados de requisitos não-funcionais.
Se tivéssemos de ser os responsáveis por escrever código que trate desses outros requisi-tos, teríamos muito mais trabalho a fazer. Tendo isto em vista, a empresa tecnológica Sun criou uma série de especificações que, quando implementadas, podem ser usadas pelos programadores para tirar proveito e reutilizar toda a infraestrutura já preparada.
Java Platform, Enterprise Edition ou apenas Java EE, é uma plataforma de desenvolvi-mento para servidores da linguagem de programação Java.
O nome J2EE era usado nas versões mais antigas, até a 1.4. Hoje, o nome correto é Java EE, por uma questão de marketing, mas basta uma rápida pesquisa na Internet para encontrar muitas referências ao antigo termo J2EE.
Esta plataforma fornece uma API e um ambiente em tempo de execução para o desenvol-vimento de softwares empresariais, incluindo serviços de rede web, aplicações de larga es-cala, aplicações multi-camadas, aplicações escaláveis e seguras. Java EE estende a Java Plat-form, Standard Edition (Java SE), fornecendo uma API para mapeamento objeto-relacional, arquiteturas multi-camada distribuídas e web services. A plataforma incorpora um desenho amplamente baseado em componentes modulares que executam num Application Server (será abordada a importância dos Application Servers no subcapítulo3.3.3).
3.3.1 Linguagem de Programação Java
Java é uma linguagem de programação orientada a objetos desenvolvida na década de 90 por uma equipa de programadores chefiada por James Gosling, na empresa Sun Microsys-tems. Ao contrário das linguagens convencionais, que são compiladas para código nativo, a linguagem Java é compilada para bytecode que é executado por uma máquina virtual.
12 Capítulo 3. estado da arte
Figura 2: Esquema de compilação e execução Java
Máquina Virtual
Java é multi-plataforma. Quando um programa Java é compilado, um código intermediário é gerado, chamado de bytecode2
. Este bytecode é interpretado pelas máquinas virtuais java (JVMs) para a maioria dos sistemas operativos. A máquina virtual é a responsável por criar um ambiente multi-plataforma, ou seja, se alguém construir um sistema operacional novo, basta criar uma máquina virtual java que traduza os bytecodes para código nativo. Todas as aplicações java poderão depois ser executadas sem problemas.
Entre outras funções, a máquina virtual java também é responsável por carregar de forma segura todas as classes do programa, verificar se os bytecodes aderem a especificação JVM e se eles não violam a integridade e a segurança do sistema.
A figura3mostra como acontece a compilação e a execução de um programa Java. A
par-tir do código Java que está num arquivo .java, o compilador javac gera o bytecode arquivo.class. Após isto uma máquina virtual java executa o bytecode e o programa.
2 Bytecode: o código de um programa de computador escrito na linguagem Java é compilado para uma forma intermediária de código denominada bytecode, que é interpretada pelas Máquinas Virtuais Java (JVMs).
3.3. Java Platform, Enterprise Edition - JEE 13
As três grandes edições
Java divide-se em três grandes edições:
• Java 2 Standard Edition (J2SE): É a tecnologia Java para computadores pessoais (desk-top), e arquiteturas com poder de processamento e memória consideráveis. Várias APIs acompanham esta versão e tantas outras podem ser transferidas opcionalmente no site da Sun. É com elas que a maioria das aplicações são construídas e executadas. O J2SE possui duas divisões:
– Java Development Kit (JDK) ou Standard Development Kit (SDK): um conjunto de ferramentas de desenvolvimento, que suporta a construção de aplicações em Java.
– Java Runtime Edition JRE: uma versão mais leve da JDK pois é preparada para o ambiente de execução, ou seja, é esta versão que executa nos sistemas construídos com SDK.
• Java 2 Mobile Edition (J2ME): É a tecnologia Java para dispositivos móveis com limi-tações de memória ou processamento. Possui APIs simples e leves para economizar espaço, memória e processamento. São utilizadas para sistemas móveis, palm tops, pocket pcs, smartphones, javacards entre outros. O J2ME divide-se em dois grupos de bibliotecas:
– Connected Limited Device Configuration (CLDC): Para telemóveis e smartpho-nes, que são mais limitados
– Connected Device Configuration (CDC): Para Palmtops e Pocket pcs e alguns dispositivos mais poderosos.
• Java Enterprise Edition (JEE): É a tecnologia Java para aplicações empresariais que podem estar na Internet ou não. Possui um grande número de APIs onde a segurança é a principal preocupação.
A Plataforma JEE baseia-se na plataforma Java SE, desta forma, na figura 3 abaixo, é
14 Capítulo 3. estado da arte
Figura 3: Diagrama estrutural da plataforma Java
3.3.2 Componentes (APIs)
As aplicações multi-camada são por norma difíceis de programar, pois implicam complexas linhas de código para abordar transações, manutenção de estados, processos e concorrência, recursos e outros detalhes de baixo nível. A arquitetura JEE é baseada em componentes e independente da plataforma, tornando as aplicações fáceis de escrever porque a lógica do negócio é organizada em componentes reutilizáveis. Além disso, o servidor JEE fornece serviços subjacentes sob a forma de um container para cada tipo de componente. Desta forma sem ser necessário desenvolver estes serviços, o programador torna-se livre para se concentrar em resolver o problema em questão. O JEE possui dezenas de APIs para imple-mentar todo o tipo de serviços existentes na web. Algumas das principais especificações ou APIs disponibilizadas pelo JEE [2]:
• Java Servlets: A API Java Servlet (javax.servlet) proporciona ao programador a possi-bilidade de adicionar conteúdo dinâmico num servidor web utilizando a plataforma Java. Desta forma o programador possui uma interface para o servidor web (ou ser-vidor de aplicação), através de uma API. As aplicações baseadas em Servlets geram conteúdo dinâmico (normalmente HTML) e interagem com os clientes, utilizando o modelo requisição-resposta (Request-Response).
• JavaServer Pages (JSP): é uma tecnologia que ajuda os programadores a criarem pá-ginas web geradas dinamicamente baseadas em HTML, XML ou outros tipos de
do-3.3. Java Platform, Enterprise Edition - JEE 15
cumentos. É similar ao PHP, mas usa a linguagem de programação Java. Para imple-mentar e executar JavaServer Pages, é necessário um servidor web compatível com um Servlet Container (este assunto será abordado com maior pormenor no subcapítulo
3.3.3), como Apache Tomcat, Jetty ou Glassfish.
• Java Server Faces (JSF): É uma especificação para criar interfaces gráficas de aplicações web. O seu objetivo é sistematizar o que as interfaces web têm em comum, apoiando o programador nesse sentido. Com relativa facilidade permite desenvolver interfaces web ricas e interativas (cujas aplicações são denominadas RIA - Rich Internet Applica-tion). Executa do lado do servidor e é totalmente orientada ao componente, para além de uma série de componentes (abstrações dos componentes HTML), prevê validação, gestão de estado, conversores, modelo de eventos, etc.
• Enterprise Javabeans Components (EJB): É um modelo do lado do servidor que en-capsula a lógica de negócio da aplicação.
• Java Database Connectivity (JDBC): é um conjunto de classes e interfaces que fazem o envio de instruções SQL para uma qualquer base de dados relacional.
• Java Persistence Arquitecture (JPA): É uma especificação que descreve a gestão dos dados relacionais nas aplicações.
• Java API for XML Web Services (JAX-WS): Simplifica a criação e instalação de web-services e clientes de web-web-services.
• Java API for XML Binding (JAX-B): Permite mapear as classes Java em representações XML. JAXB fornece duas grandes funcionalidades: a capacidade de converter objetos Java em XML e vice-versa.
• Java Autenthication and Authorization Service (JAAS): O principal objetivo de JAAS é a separação de preocupações na autenticação do utilizador, para que possam ser geridas independentemente.
• Java Transaction API (JTA): Especifica interfaces Java entre um gestor de transações e as partes envolvidas no sistema de distribuição das transações (gestor de recursos, servidor da aplicação, e aplicações transacionais).
• Java Message Service (JMS): É uma API da linguagem Java para middleware3 orien-tado à mensagens. Através da API JMS duas ou mais aplicações podem se comunicar por mensagens.
16 Capítulo 3. estado da arte
• Java Naming and Directory Interface (JNDI): É uma API para acesso a serviços de di-retórios, que permite que aplicações cliente descubram e obtenham dados ou objetos através de um nome.
• Java Management Extensions (JMX): É uma tecnologia Java que fornece ferramentas para a gestão e monitorização de aplicações, objetos do sistema, dispositivos e redes orientadas a serviço.
Para além das especificações acima mencionadas existem muitas mais, que podem ser encontradas no o site do Java Community Process4
, explicando tudo sobre as Java Specification Requests (JSR), isto é, os novos pedidos de bibliotecas e especificações para Java, tanto para Java SE, e Java EE.
A última versão disponível da especificação do JEE é a versão 7, lançada em 12 de ju-nho de 2013. É uma versão ainda muito recente, com poucas ferramentas e servidores disponíveis. A versão mais usada no mercado é a versão 6, de 2009.
Das APIs anteriormente mencionadas JSP, JPA e Servlets são sem dúvida as especifi-cações essenciais que qualquer programador Java precisa para desenvolver apliespecifi-cações web. Mesmo usando frameworks e bibliotecas que facilitam o trabalho para a Web, conhecer bem estas especificações é certamente um diferencial, e fará com que se entenda motivações e dificuldades, auxiliando decisões arquiteturais e a modelação.
3.3.3 Diferença entre Application Server e Container
Para desenvolver aplicações JEE, baseamo-nos nas suas especificações, contudo é necessário utilizar um servidor que as implemente. Neste contexto é importante distingir o conceito Application Server e Container.
Existem diversos servidores famosos compatíveis com a especificação do J2EE 1.4, JEE 5 e 6, e já alguns para JEE 7. O JBoss é um dos líderes do mercado e tem a vantagem de ser gratuito e open source. Alguns softwares implementam apenas uma parte dessas especificações do JEE, como o Apache Tomcat, que só implementa JSP e Servlets (como foi referido no subcapítulo anterior, estas são duas das principais especificações), portanto não é totalmente correto chamar-lhe servidor. [2]
A tabela1abaixo mostra alguns dos servidores com maior relevância no mercado atual.
3.3. Java Platform, Enterprise Edition - JEE 17
Empresa Nome do Servidor Gratuito Versão da Plataforma
Oracle/Sun GlassFish Server Open Source Edition 4.0 X JEE 7
RedHat JBoss Application Server 7.x X JEE 6
Apache Apache Geronimo X JEE 6
Oracle/BEA Oracle WebLogic Server 8.x - JEE 6
IBM IBM WebSphere Application Server - JEE 6
SAP SAP NetWeaver Application Server - JEE 6 Web Profile
Tabela 1: Alguns dos Application Servers Java mais utilizados no mercado
Desta forma, a partir do JEE 6 foi criado o termo "application server web profile", para poder-se referenciar poder-servidores que não oferecem tudo, mas um grupo menor de especificações, consideradas essenciais para o desenvolvimento web.
Dentre as várias especificações, o JEE possui algumas funcionalidades específicas para lidar com o desenvolvimento web que são Servlet, JSP, JSTL e JSF.
Ao servidor que suporta estas funcionalidades nucleares dá-se o nome de Servlet Contai-ner. Este não é necessariamente JEE Web Profile nem o JEE completo. É indicado a quem não precisa de tudo o que o JEE ofereçe e está interessado apenas na parte web (boa parte das aplicações de médio porte encaixam-se nessa categoria). No mercado atual Apache Tomcat, é talvez o servlet container mais famoso.
Mapeamento Objeto-Relacional como auxiliar do Model
Atualmente em JEE existem duas importantes ORMs que são Hibernate e EclipseLink, que apresentam diferenças na sua implementação. Tal como foi referido anteriormente existem determinadas APIs que apenas podem ser implementadas por um servidor com suporte às funcionalidades completas do JEE. Os EJBs são um dos casos, em que é necessário um servidor como Glassfish ou JBoss. Caso seja usado o Framework Hibernate poderá ser imple-mentado utilizando Apache Tomcat, pois este não implementa EJBs. No caso de EclipseLink é necessário um servidor que ofereça todas as potencialidades.
• No caso de se pretender implementar o Framework ORM EclipseLink, o IDE permite-nos que sejam geradas automaticamente, as Entity Classes a partir da base de dados, implementando desta forma a JPA (Java Persistence Architecture) para cada tabela e as Session Beans para cada classe Entidade anteriormente gerada, implementando Enter-prise Java Beans em forma de Session facades para cada entidade, com os métodos de acesso básicos (CRUD5
) incluídos .
• No caso de se pretender implementar o Framework ORM Hibernate, este não ne-cessita obrigatoriamente que exista um servidor aplicacional para que possa ser
im-18 Capítulo 3. estado da arte
plementado, como acontece no caso do EclipseLink, podendo ser ser implementado por um Servlet Container. Contudo, existe algum esforço de configuração acrescido, dado que terão que ser implementados manualmente os DAOs6
que são uma direta correspondência às Session Facades (Session Beans) criadas pelo EclipseLink.
3.3.4 Apache Struts2 - Framework
Apache Struts2 é um Framework Web open-source de desenvolvimento de aplicações Java EE. Este utiliza e estende a API Java Servlet, encorajando que as aplicações desenvolvidas adotem a arquitetura do padrão MVC.
O Framework Struts foi originalmente desenvolvida por Craig R. McClanahan em 2001, passando depois a ser gerida pela Apache Software Foundation em 2002. Struts proporci-onou uma excelente estrutura para desenvolvimento de aplicações através da combinação da API Java Server Pages e de Servlets, permitindo criar um ambiente de desenvolvimento extensível. No entanto, com a crescente demanda de aplicação web, Struts não se conseguiu manter firme, e necessitou de ser reestruturado. Em 2005 Struts funde-se com o Framework WebWork da OpenSymphony (outro Framework Java EE) uniu esforços conjuntos para de-senvolver um Framework avançado com todos os recursos de desenvolvimento possíveis para tornar o desenvolvimento completamente amigável criando assim o Apache Struts2. [3]
3.3.5 Componentes - Apache Struts2
Struts2 é um Framework pure-MVC. Desta forma, os componentes que o constituem repre-sentam papéis importantes na implementação do padrão MVC [4]
• StrutsPrepareAndExecuteFilter - Constitui o Controller, verificando cada pedido e encaminhando para a devida localização onde deverá ser processado.
• Actions - Representam o Model e são responsáveis pelo comportamento que será exe-cutado a fim de responder um determinado pedido.
• Interceptors - Estes componentes atuam como filtros que executam antes e após o pedido ser processado. São utilizados para desempenhar as funções comuns (e.g validações de login e de sessão).
6 DAO (Data Access Objects), é um padrão para persistência de dados que permite separar regras de negócio das regras de acesso à base de dados.
3.4. Ruby on Rails 19
• ActionContext - Representa o contexto de execução de uma Action, contendo todos os dados relacionados com a Action e do próprio Framework (ValueStack, Session, Re-quests,etc.).
• ValueStack - Representa a área de armazenamento que mantém todos os dados asso-ciados com o processamento do pedido. Desta forma não é necessário passar os dados de forma individual entre os vários componentes (classes) que estão envolvidos neste processamento.
• Object-Graph Navigation Language - OGNL - É a linguagem de expressões que permite obter e atualizar propriedades dos objetos, permitindo a manipulação de propriedades existentes na ValueStack.
• Results - Cada Action define um ou mais Results. Após a execução de uma Action, o Result indica o template que será responsável pela apresentação dos dados aos utilizados, constituindo a View.
3.4 r u b y o n r a i l s
Ruby on Rails (vulgarmente chamado de apenas Rails) é um excelente exemplo de um pro-jeto open-source bem sucedido. No entanto, não podemos discutir Rails sem antes discutir a linguagem de programação Ruby.
É um equívoco comum pensar que Ruby e Ruby on Rails são a mesma coisa. Embora intimamente relacionados, estes são distintos. Quando alguém diz Ruby, refere-se nor-malmente à linguagem de programação em si. Ruby on Rails é uma full-stack7
para o desenvolvimento de aplicações Web que foi criada com recurso a Ruby.
Rails ajudou a impulsionar movimentos como o Test Driven Development, mais conhe-cido como TDD8
, Pair Programming e outras metodologias ágeis. Desempenhou um papel importante no que diz respeito à adoção de Ruby no que diz respeito à escolha dos progra-madores.
Neste capítulo, pode ler-se uma breve história sobre a linguagem Ruby e aprender algu-mas das características. Em seguida, será apresentado como Rails passou a ser considerada por muitos uma das estruturas mais reconhecidas e emergentes para o desenvolvimento de aplicações web. Depois de apresentar os principais conceitos envolvidos no framework Rails são dedicadas secções à estrutura e componentes do Framework.
7 Full-Stack, é entendido como sendo uma super-Framework, que agrega Frameworks mais pequenas e especifi-cas que permitem assim desenvolver aplicações, sem ter de recorrer a outras fontes externas.
8 Test Driven Development (TDD), é uma técnica de desenvolvimento de software que se baseia num ciclo curto de repetições, primeiro o programador escreve um caso de teste automatizado que define uma melhoria
20 Capítulo 3. estado da arte
3.4.1 Ruby on Rails - Framework
História
Em 2001, David Heinemeier Hansson (o criador de Ruby on Rails) foi contratado por Jason Fried para construir uma ferramenta de gestão de projetos baseado em ambiente web, o que acabou se tornando a 37signals9
software como um serviço denominado por Base-Camp10 . Hansson decidiu iniciar o projeto através do desenvolvimento de uma framework web personalizada usando a linguagem de programação Ruby para evitar o que ele via como codificação repetitiva inerente as plataformas como Java. Ruby era quase desconhecido na época. A framework que Hansson criou mais tarde foi lançada como um projeto open-source, independente da ferramenta de gestão de projetos. O nome deste framework web open-source dado foi Ruby on Rails.
Em 2005, Hansson chamou a atenção da comunidade com um famoso vídeo chamado "Fazer um blog em 15 minutos.", onde mostrava uma introdução sobre desenvolvimento com Rails. No mesmo ano, a sua criação fez com que ganhasse o prémio Google-O’Reilly Best Hacker. O sucesso de Ruby on Rails é considerado por muitos, como o maior respon-sável pela aceitação em massa da linguagem Ruby. Desde então foram criados frameworks direcionados para a programação em linguagem Ruby, dando especial ênfase à framework MERB11
, que dividia alguns dos programadores. No entanto, em 23 dezembro de 2008 , foi anunciado (por Hansson no site de Ruby on Rails) que MERB seria fundida em Rails 3, sendo assim terminada a duplicação desnecessária em ambas as comunidades, e fechando o debate sobre quando escolher um sobre o outro. As melhores ideias, de ambos os la-dos foram escolhidas para criar um projeto melhor e mais forte. Este é um bom exemplo de como funciona a comunidade open-source de Ruby, sendo esta uma vantagem em com-paração com, por exemplo, o mundo Java, onde se pode encontrar dezenas de diferentes frameworks para os mesmos fins. Pela razão de existirem tantas opções, os programadores acabam confusos e por fazerem parte de diferentes comunidades ficam divididos. O apa-rente problema é existir por parte das comunidades, um objetivo comum, mas "remam"em direções opostas e devido a isso, á menos colaboração e o progresso é mais lento. Embora, com uma incrível crescente exponencial nos últimos anos, o que pode levar a novas e dife-rentes formas de pensar, essa grande divisão não parece estar a acontecer na comunidade Rails. [5]
9 37signals é uma empresa de aplicações web privada com sede em Chicago, Illinois. A empresa foi co-fundada em 1999 por Jason Fried, Carlos Segura, e Ernest Kim.
10 Base-Camp é uma ferramenta de gestão de projetos baseado na web desenvolvido pela 37signals e lançado em 2004.
3.4. Ruby on Rails 21
Princípios
A filosofia Rails inclui vários princípios de orientação [6]:
• MVC - Model View Controller: Rails usa a arquitetura MVC destina-se a ser utilizado com uma metodologia de desenvolvimento ágil, oferecendo aos programadores um ambiente de desenvolvimento de aplicações Web rápida.
• CoC - Convetion over Configuration: Através de um boa convenção de nomes dados aos Models, Contollers e Views o Rails ajusta cada pormenor, sem que seja necessário recorrer a extensos arquivos de configuração.
• DRY - Don‘t Repeat Yourself: Escrever o mesmo código várias vezes é uma coisa má, por isso DRY é um princípio de desenvolvimento de software que visa reduzir a repetição de informações de todos os tipos.
• REST - Representational State of Transfer): Um padrão para aplicações Web que permite organizar a aplicação em torno de recursos e normas HTTP descobrindo qual é o caminho mais rápido.
3.4.2 Linguagem de programação Ruby
‘Ruby is simple in appearance, but is very complex inside, just like our human body”
Yukihiro Matsumoto, criador da Linguagem Ruby Ruby é uma linguagem de programação dinâmica e orientada a objetos open-source. Não é apenas livre para usar, mas também de copiar, modificar e distribuir. Ruby foi criado por Yukihiro Matsumoto (também conhecido como Matz) ao abrigo de um projeto do Governo japonês e lançado publicamente em 1995. Ruby obteve uma aceitação em massa por parte dos utilizadores em 2006. O ideal seguido por Matsumoto foi misturar partes de suas lin-guagens favoritas (Perl, Smalltalk, Eiffel, Ada, e Lisp), equilibrando a programação funcional com a programação imperativa para criar uma linguagem multi-paradigma. O objetivo era criar uma linguagem natural. Matsumoto acredita que as pessoas desejam expressar-se quando programam. Os programadores não querem lutar contra a linguagem. As lingua-gens de programação devem fazer-se sentir ao programador de maneira natural. Ruby está baseada no “Princípio da menor surpresa”, o que significa que a linguagem se comporta da maneira que se espera. [7]
Interpretador Ruby
22 Capítulo 3. estado da arte
memória muito complexa, nem características modernas de interpretadores como a com-pilação em tempo de execução (conhecida como JIT12
). Hoje a versão mais difundida é a 2.0, também conhecida como YARV (Yet Another Ruby VM), já baseada em uma máquina virtual com recursos mais avançados.
Com a popularização da linguagem Ruby, principalmente após o surgimento do Ruby on Rails, implementações alternativas da linguagem foram a surgindo. A maioria delas segue uma tendência natural de serem baseados numa Máquina Virtual invés de serem interpretadores simples. Algumas implementações possuem até compiladores completos, que transformam o código Ruby em alguma linguagem intermediária a ser interpretada por uma máquina virtual.
A principal vantagem das máquinas virtuais é facilitar o suporte em diferentes platafor-mas. Além disso, ter código intermediário permite otimização do código em tempo de execução, feito através da JIT.
Alguns dos interpretadores alternativos mais conhecidos são [8]:
• JRuby - Foi a primeira implementação alternativa completa da versão 1.8.6 do Ruby e é a principal implementação da linguagem Java para a JVM. Com o tempo ganhou compatibilidade com as versões 1.8.7 e 1.9.3 na mesma implementação. Como roda na JVM, não é um simples interpretador, já que também opera nos modos de compilação AOT (Ahead Of Time) e JIT (Just In Time). Uma de suas principais vantagens é a interoperabilidade com código Java existente, além de aproveitar todas as vantagens de uma das plataformas de execução de código mais maduras (Garbage Collector, Threads nativas, entre outras).
• IronRuby - A comunidade .Net também não ignorou o sucesso da linguagem e pa-trocinou o projeto IronRuby, que era mantido pela própria Microsoft. IronRuby foi um dos primeiros projetos verdadeiramente de código aberto dentro da Microsoft. Em 2010 a Microsoft parou de manter o projeto e a versão atual do IronRuby, 1.1.3, implementa apenas até o Ruby 1.9.2.
• Rubinius - Criada por Evan Phoenix, Rubinius é um dos projetos que tem recebido mais atenção da comunidade Ruby, por ter o objetivo de criar a implementação de Ruby com a maior parte possível do código em Ruby. Além disso, trouxe ideias de máquinas virtuais do SmallTalk, possuindo um conjunto de instruções (bytecode) pró-prio e implementada em C/C++. O Rubinius está sempre atualizado com as últimas versões do Ruby e roda no MacOS X e em sistemas Unix/Linux. No Windows ainda não é suportada.
• Ruby Enterprise Edition - Foi criada para melhorar a performance de aplicações Rails e diminuir a quantidade de memória utilizada, Ninh Bui, Hongli Lai e Tinco
3.4. Ruby on Rails 23
Andringa, modificaram o interpretador Ruby e lançaram com o nome de Ruby En-terprise Edition. As principais modificações no REE foram no comportamento do Garbage Collector, fazendo com que funcione com o recurso de Copy on Write13
dispo-nível na maioria dos sistemas operativos baseados em UNIX.
Principais características
Em Ruby, tudo são objetos. Mesmo os tipos de dados básicos, como números ou valores booleanos, o que faz com que todas as operações que são realizadas num objeto sejam métodos, e que cada método retorne um objeto.
Ruby é uma linguagem dinâmica com tipagem forte, interpretada em tempo de execução com Duck-Typing14
O Ruby suporta somente a herança simples, mas dispõe da estrutura funcional Module que implementa o conceito de módulos (Modules), que agem como coleções de métodos. As classes podem conter determinados módulos, herdando todos os seus métodos. Desta forma ruby consegue obter a capacidade da herança múltipla.
3.4.3 Componentes
Active Model
Em geral, nas aplicações que são desenvolvidas, pretendemos que as informações sejam guardadas numa base de dados relacional. Sistemas de entrada de dados, guardam enco-mendas, linhas de encomenda, detalhes dos clientes, etc, em tabelas de base de dados. Até mesmo as aplicações que normalmente utilizam texto não estruturado, como web-blogs, frequentemente utilizam bases de dados como sendo o seu back-end para armazenamento de dados.
Embora não seja imediatamente aparente a partir do SQL15
aceder aos dados, os bancos de dados relacionais são concebidos em torno de teoria dos conjuntos matemáticos. Ape-sar disso ser bom do ponto de vista conceptual, torna-se difícil combinar bases de dados relacionais com linguagens de programação orientadas a objetos. Falar de objetos é falar de conjuntos de dados e de operações, e falar de bases de dados é falar de atribuições de
13 Copy on Write é uma estratégia de otimização, que decorre do entendimento que, quando várias tarefas separa-das usam cópias idênticas da mesma informação, ou seja, os dados armazenados na memória do computador ou armazenamento em disco, não é necessário criar cópias separadas das informações de cada processo, em vez disso são atribuídos apontadores para o mesmo recurso.
14 Duck typing, em linguagens de programação orientadas por objetos é um estilo de escrita dinâmica na progra-mação, em que os métodos de objetos e as suas propriedades determinam a validade da semântica, invés de herdar de uma determinada classe ou implementação de uma interface específica.
24 Capítulo 3. estado da arte
valores. Operações que são fáceis de expressar em termos relacionais são por vezes difíceis de codificar num sistema orientado a objetos, sendo que o inverso também é verdadeiro.[9] Com o evolução das programação orientada a objetos, os programadores têm trabalhado na melhor forma de conciliar os pontos de vista relacional e orientados a objetos dos seus dados. O Rails mapeia os dados relacionais em objetos.
Mapeamento Objeto-Relacional - ORM16
As bibliotecas ORM mapeiam as tabelas da base de dados em classes. Se a base de dados tem uma tabela Orders, a aplicação vai ter uma classe chamada Order. As linhas nesta tabela correspondem a objetos da Classe, uma encomenda (order), em particular é representada como um objeto da Classe Order. Dentro desse objeto, os atributos são usados para obter e definir as colunas individuais. O objeto Order possui métodos para obter e definir os valores. As classes Rails que envolvem as tabelas da base de dados fornecem um conjunto de métodos à classe que executam operações ao nível das tabelas. Podemos por exemplo precisar de encontrar a encomenda com um ID em particular, sendo que isto pode ser implementado como um método da classe que retorna o objeto Order correspondente. Em código Ruby pode ser feito como é demonstrado no excerto de código3.1abaixo.
1 order = Order . find (1)
2 puts " Customer #{ order . customer_id }, amount =$ #{ order . amount }"
Código 3.1: Procura utilizando métodos da Classe
Por vezes os métodos de classe podem também devolver coleções de objetos, como pode ser visto no excerto de código3.2.
1 Order . where (: name => 'dave ' ). each do | order | 2 puts order . amount
3 end
Código 3.2: Procura utilizando clausula where
Os objetos que correspondem a linhas individuais de uma tabela têm métodos que atuam sobre essa mesma linha. Um exemplo de um método usualmente utilizado é save(), que é a operação que guarda a linha na base de dados. Um exemplo é demonstrado no excerto de código abaixo.
1 Order . where (: name => 'dave ' ). each do | order | 2 order . pay_type = " Purchase order "
16 Object-Relational Mapping, é uma técnica de desenvolvimento utilizada para reduzir a impedância da pro-gramação orientada aos objetos utilizando bancos de dados relacionais. As tabelas do banco de dados são representadas através de classes e os registos de cada tabela são representados como instâncias das classes correspondentes.
3.4. Ruby on Rails 25
3 order . save 4 end
5 %
Código 3.3: Método do objeto order(linha)
Desta forma a camada ORM mapeia as tabelas em Classes, linhas em objetos, e colunas em atributos desses objetos. Os métodos da Classe são utilizados para executar operações ao nível das tabelas, e os métodos de instância executam operações em linhas das tabelas. Active Record
Active Record é a camada ORM nativa de Rails. Esta segue o modelo ORM padrão (tabelas mapeadas para classes, linhas para objetos, e colunas para atributos de objeto). Difere da maioria das outras bibliotecas ORM na forma como está configurado. O Active Record diminui a quantidade de configuração que o programador necessita de fazer. Active Record alivia-nos das dificuldades de lidar com a base de dados subjacente, deixando-nos livres para trabalhar na lógica de negócio da aplicação.
Action Pack: Action Controller e Action View
A View e o Controller são partes do MVC que estão intimamente ligadas. O Controller fornece os dados à View, e recebe os eventos das páginas geradas pelas Views. Devido a estas interações, o suporte para as Views e para os Controllers são agrupados no mesmo pacote como um componente único. Pensar que Rails baralha o conceito da View com o de Controller devido à combinação dos dois num único componente é errado. Na realidade é o contrário, pois permite ter a separação de que precisamos exatamente para escrever aplicações web com clareza no código de controlo e na lógica de apresentação.
Action View
Em Rails a View é normalmente responsável pela criação de toda ou quase toda a parte da resposta que é exibida no web-browser, processado por uma aplicação, ou até enviada como email. Na sua forma mais simples, a View é um pedaço de código HTML que exibe texto estático. Contudo esta foi desenvolvida essencialmente para se poder incluir conteúdo dinâmico criado por um determinado método de uma ação no controlador. Em Rails, o conteúdo dinâmico é gerado por templates, destes existem três tipos. O esquema de templates mais comum, é o chamado ERB ou Ruby embebido, incorpora pedaços de código Ruby dentro da View, esta é em alguns aspetos semelhante ao modo como é feito noutros frameworks web, como PHP ou JSP. Embora esta abordagem seja muito flexível, alguns
26 Capítulo 3. estado da arte
do MVC. Ao incorporar código na View, corre-se o risco de adicionar lógica que deve ser feita apenas no Model ou no Controller. Como em tudo, enquanto o seu uso for criterioso e com moderação esta é uma boa prática, mas o seu excessivo uso pode tornar-se um problema. A manutenção de uma separação clara das preocupações é parte do trabalho do programador.
Tal como é usado conjuntamente com HTML o ERB pode também ser usado para cons-truir fragmentos de JavaScript17
no servidor, que serão posteriormente executados no web-browser. Desta forma é permido ao programador criar mais facilmente interfaces AJAX18 dinâmicas.
Em Rails é também possível construir documentos XML19
, através do construtor XML fornecido por Rails que utiliza código Ruby. Desta forma a estrutura do código XML gerado segue automaticamente a estrutura do código.
Action Controller
Em Rails o Controller, é o centro lógico da aplicação da aplicação. Coordena a interação entre o utilizador, as views e o model. Contudo Rails trata da maioria das interações, permitindo que o código que o programador escreva se concentre apenas nas funcionalidades ao nível da aplicação. Desta forma o código do controller torna-se bastante fácil de desenvolver e de manter. O controller, é também importante, pelo seu papel no auxilio de outros serviços como encaminhar pedidos externos para ações internas, tratando dos URLs com bastante facilidade. Gere a cache20, o que aumenta a performance substancialmente. Gere módulos auxiliares, que estendem as capacidades dos templates de visualização sem aumentar a complexidade do código. Gere as sessões, dando aos utilizadores a impressão de interação contínua com a aplicação.
Action Mailer
É um Framework para a criação de serviços de e-mail, que pode ser usada para enviar e-mails com base em modelos flexíveis, ou para receber e processar e-mails recebidos.
17 JavaScript é uma linguagem de programação interpretada que foi originalmente implementada como parte dos web-brwosers para que scripts pudessem ser executados do lado do cliente e interagissem com o utilizador sem a necessidade deste script passar pelo servidor.
18 AJAX, Asynchronous Javascript and XML é o uso metodológico de tecnologias como Javascript e XML, pro-vidas por web-browsers, para tornar páginas Web mais interativas com o utilizador, através de solicitações assíncronas de informações.
19 XML: eXtensible Markup Language é uma recomendação da W3C para gerar linguagens de marcação para necessidades especiais.
20 Cache é um dispositivo de acesso rápido, interno a um sistema, que serve de intermediário entre um operador de um processo e o dispositivo de armazenamento ao qual esse operador acede.
3.4. Ruby on Rails 27
Active Support
Active Support é o componente de Rails responsável pelo fornecimento de extensões de linguagem Ruby e ferramentas de utilizade variada. Através do Active Support é possi-vel oferecer uma linha de fundo mais rica ao nípossi-vel da linguagem, orientada tanto para o desenvolvimento de aplicações Rails, e ao seu desenvolvimento.
3.4.4 Metodologia
Rails é um Framework Agile21. É difícil ou até talvez impossível encontrar em alguma
comunidade a disponibilizar tutoriais que ensinem outras metodologias que não sejam ágeis. A razão é simples e subtil, pois agilidade é parte da forma como foi desenvolvida o Framework.
Olhando para os valores expressos no manifesto Agile, podemos observar um conjunto de quatro preferências [10]:
• Indivíduos e interações sobre processos e ferramentas
• O Software funciona sobre documentação
• A colaboração com o cliente é mais do que negociação de contratos
• Responder a mudanças é mais importante do que seguir um plano
Rails é sobre os indivíduos e as suas interações, não existindo conjuntos de ferramentas pesadas, nem configurações complexas, e sem complexos processos de elaboração. Desta forma trata-se de pequenos grupos de programadores a utilizar os seus editores favoritos e a usar código Ruby. Isto leva à transparência, o que o programador desenvolve reflete-se imediatamente no que o cliente vê, tratando-se de um processo intrinsecamente interativo. Rails encoraja a colaboração do cliente. Quando os clientes vêm o quão rapidamente um projeto responde à mudança, eles começam a confiar que a equipa de desenvolvimento consegue desenvolver o que é necessário, e não apenas o que foi solicitado.
28 Capítulo 3. estado da arte
Figura 4: Modelo esquemático da metodologia Agile
Tudo isto prende-se à ideia de o projeto ser capaz de responder à mudança. A maneira que o Rails honra o princípio DRY significa que as alterações em aplicações Rails, tem um impacto muito menor do que se as mesmas alterações fossem necessárias em outras estruturas.
4
I N T E G R AT E D D E V E L O P M E N T E N V I R O N M E N T - I D E
No desenvolvimento de software para além da Linguagem e da Framework utilizados, é por vezes esquecida a importância do ambiente de desenvolvimento ou IDE. Desde à muito que os IDE’s no que diz respeito a POO, tornaram-se ferramentas muito importan-tes no desenvolvimento. Contudo existe ainda alguma controvérsia à volta desta questão, pois alguns entusiastas existentes em qualquer comunidade defendem que um verdadeiro programador não necessita de IDE. Esta é uma discussão que não será abordada neste ca-pítulo, embora irão ser demonstrados algumas das mais valias inerentes ao uso de um IDE no desenvolvimento de aplicações em Rails.
Ruby on Rails, é um projeto open-source e foi concebido com à particularidade de não ser necessário um qualquer IDE especifico para o desenvolvimento de aplicações web de alto-nível, podendo o programador usufruir da totalidade das funcionalidades recorrendo a um simples editor de texto. Com a exponencial utilização deste Framework, foram criados plugins específicos para Rails que muniram aquilo que era apenas um editor de texto com funcionalidades que apenas poderiam ser encontradas nos IDE’s. A escolha do ambiente de desenvolvimento deve ser pessoal e aquela que cada utilizador se sinta mais confortável, seja um simples editor de texto ou um IDE complexo.
4.1 c a r a c t e r í s t i c a s e s s e n c i a i s d e u m e d i t o r/ide
Embora a escolha do editor ou IDE seja pessoal existem algumas funcionalidades essenciais que devem de ser asseguradas em ambos as tecnologias:
• Suporte para a verificação de sintaxe da linguagem Ruby e HTML.
• Suporte indentação automática. Isto é mais do que uma característica estética, a auto-indentação no código enquanto se escreve é a melhor maneira de detetar determinada condição termina no sitio certo. Ser capaz de re-indentar é importante quando dese-jamos refazer o código e mover código de sitio.
30 Capítulo 4. integrated development environment - ide
• Boa navegação pelos arquivos. Uma aplicação minimamente complexa contém deze-nas de arquivos contidos em diversos diretórios. É necessário portanto, um ambiente que ajude à rápida navegação entre os diferentes ficheiros.
• Suporte à inserção de código é uma importante funcionalidade. Ter auto complete dos principais métodos e estruturas do código é importante ao fim de dois ou três cliques. Alguns nomes tendem a ser longos, um bom editor vai deixar digitar os primeiros caracteres e em seguida sugerir conclusões possíveis.
4.2 j e t b r a i n s r u b y m i n e
A maioria dos programadores de Ruby on Rails não usam IDE,(embora alguns dos am-bientes após alguns plugins implementados num editor de texto consigam chegar perto), e verifica-se que este não é tanto um problema como se poderia pensar. Com outras lin-guagens menos expressivas, os programadores dependem de IDE’s para fazer muito do trabalho duro que consiste em gerar código, ajudar com a navegação, e compilando de uma forma incremental para se irem observando os alertas de erro. Contudo foram sendo criados IDEs específicos, tanto gratuitos como pagos, que tentavam dar mais valias ao uso de um pacote completo de funcionalidades, as quais nem sempre poderiam ser obtidas através de plugins.
Os IDE’s com maior popularidade são:
• Aptana Studio, que é desenvolvido em cima do conhecido Eclipse
• Komodo, trata-se de um IDE de linguagens dinâmicas como é o caso de Ruby
• Rubymine, um IDE de uso comercial, mas que se encontra disponível gratuitamente no âmbito de projetos académicos ou projetos open-source
• NetBeans - Ruby on Rails plugin, contudo o seu suporte foi descontinuado depois da versão 7.0.
O IDE escolhido para o desenvolvimento das aplicações em Ruby on Rails foi o Ruby-mine, por ser mais completo em relação a qualquer um dos anteriores referidos. Para além das funcionalidades comuns a quase todos os IDE’s o Rubymine permite um conjunto de funcionalidades que não se consegue obter nos outros [11]:
• Refactoring - facilmente se consegue renomear uma variável ou método, ou extrair um excerto de código de um método assim escrevendo um código mais limpo, o que atualmente não pode ser feito por nenhum plugin para editores de texto normais.
4.3. Netbeans 31
• Executar Rake tasks e os Generators de Ruby on Rails. Não é uma coisa muito impor-tante, mas ser capaz de executa-los diretamente no RubyMine poupa tempo e evita a linha de comandos.
• Debugger - apresenta o mais completo debugger de código Ruby, sendo uma funciona-lidade também inexistente, nos editores de texto. Desta forma, quando as aplicações são complexas e um erro persiste, o debug visual evita os habituais prints para identi-ficar o problema.
• Controlo de Versões - permite efetuar o controlo de versões dos mais conceituados sistemas (SVN, GIT, GitHub,etc.), sem que para isso seja necessário instalar outros softwares. Oferece também um ambiente gráfico agradável que permite a resolução de eventuais conflitos.
• Visualizador de Base de Dados - é possível consultar o modelo de dependências ine-rente as relações entre tabelas definidas nos Modelos.
4.3 n e t b e a n s
O NetBeans é um IDE open-source para desenvolvimento de aplicações escrito em Java. Este foi o ambiente de desenvolvimento escolhido para o desenvolvimento das aplicações Java Web.
Por ser um ambiente de desenvolvimento maduro, e de referência a nível mundial, não foram pensadas outras opções, pois este oferece uma gama de ferramentas que garantem um ambiente de trabalho profissional, em que encontrando-se à disposição todas as fun-cionalidades enunciadas no subcapitulo 4.1 e 4.2, para o desenvolvimento de aplicações
móveis, desktop e web, utilizando a linguagem Java [12].
Tal como referido no capitulo anterior, o NetBeans também apresentava suporte ao de-senvolvimento de aplicações Ruby on Rails, contudo foi descontinuado, por essa razão foi
5
A P L I C A Ç Õ E S D E S E N V O LV I D A S
Tal como foi referido na introdução da presente dissertação, o estudo comparativo das tecnologias baseou-se no desenvolvimento de duas aplicações web, sendo que cada uma das aplicações foi implementada em RoR e JEE.
5.1 a f f a b l e b e a n
Affable Bean foi a primeira aplicação desenvolvida. Teve origem num tutorial de desen-volvimento web disponibilizado pela comunidade do IDE Netbeans e visa demonstrar a implementação de uma aplicação web standard de E-Commerce, fornecendo um serviço de compra de produtos alimentares [13]. Este tutorial foi utilizado como projeto de iniciação, pois são demonstrados alguns dos aspetos importantes das tecnologias JEE.
34 Capítulo 5. aplicações desenvolvidas
Dada a escolha do Framework Struts2 para desenvolvimento em JEE, este projeto surgiu ao mesmo tempo como conveniente e auxiliar no estudo do Framework Struts2, pois Affable Bean implementa a API Java Servlets, que é o principal responsável pela implementação MVC em Struts2.
No que diz respeito ao desenvolvimento em Rails, o desenvolvimento deste projeto foi também de grande relevância, pois dado não existir nenhum conhecimento prévio da lin-guagem Ruby nem do Framework Rails em si, este foi um ótimo projeto para iniciar a prática de desenvolvimento.
Pelas razões acima mencionadas, Affable Bean não foi diretamente considerada para fins comparativos de avaliação e conclusão, contudo é de salientar que teve um importante papel na aprendizagem das diferentes tecnologias.
5.2 s e r v i ç o d e ta x i s e r e n t-a-car - setare
Após a implementação de Affable Bean, e com a aquisição de conhecimentos básicos sobre as duas tecnologias foi possível implementar com melhores práticas de desenvolvimento a segunda aplicação SeTaRe. A ideia da conceção desta aplicação, nasceu da necessidade de desenvolver uma aplicação com alguma complexidade algorítmica, para que se pudessem comparar mais objetivamente as tecnologias. Dado que, o objetivo da aplicação desen-volvida apenas foi servir de objeto de comparação entre as tecnologias, a idealização e conceção da aplicação foi baseada em aplicações já existentes. Desta forma efetuou-se uma análise das aplicações web de aluguer de automóveis e de taxis para que as aplicações finais desenvolvidas fossem o mais possível um template. Após a análise das aplicações existentes no mercado, foram escolhidas com base na popularidade de utilização, as aplicações web AirPort Taxi Transfers [14] e Rental Cars [15], de aluguer de táxis e de carros respetivamente mostradas na figura6.
5.3. Modelação UML 35
5.2.1 Descrição de AirPort Taxi Transfers
No lado esquerdo da figura6, encontra-se uma aplicação web com o objetivo de permitir ao
utilizador reservar um táxi. Para tal, é feita uma pesquisa de táxis livres usando uma lista de países disponíveis e das cidades associadas, o número de passageiros desejados e a data em que se pretende o serviço. Também é dada a hipótese de reservar um táxi com uma data de retorno, ou seja, o mesmo táxi irá fazer o percurso inverso na data escolhida. Há que apontar que os táxis existentes em cada cidade podem variar, isto é, algumas cidades poderão não conseguir responder às necessidades do utilizador, quer em termos de número de passageiros ou preço dos táxis desocupados.
5.2.2 Descrição de Rental Cars
No lado direito da figura 6, encontra-se outra aplicação web com um objetivo semelhante
à anterior. Neste website, é dado ao utilizador a hipótese de alugar carros, como normal-mente acontece nos aeroportos onde existem agências que fornecem este serviço. O aluguer do carro é feito, como anteriormente, através de uma pesquisa de carros disponíveis usando para tal uma lista de países e de cidades associadas a cada país como filtro. A única dife-rença para a pesquisa, referida acima, é que os carros pertencem sempre a uma ou mais agências de aluguer e que cada agência nem sempre se encontra em todos as cidades dis-poníveis no sistema. Há que referir também a possibilidade de devolver o carro alugado numa cidade diferente daquela onde foi alugado.
5.3 m o d e l a ç ã o u m l
Tal como acontece na conceção de qualquer projeto de engenharia de software, depois de entender quais os principais requisitos da aplicação e antes de iniciar o processo de desen-volvimento em si, é necessário efetuar algum trabalho de modelação das funcionalidades pretendidas.
Para representar melhor os requisitos de SeTaRe, foi utilizado um diagrama de Casos de Uso UML. A figura7demonstra de um alto nível de abstração o conjunto de
funcionalida-des que o sistema terá de implementar agrupados por dois tipos de utilizadores (atores), registados em sistema, e os não registados. Decidiu-se que a aplicação estaria protegida por um mecanismo que autenticação, e que apenas utilizadores devidamente registados e
