Guia Spring Framework

Primeiros passos com o Spring Boot

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (9)  (0)

Conheça a nova ferramenta do ecossistema Spring que garante ganho de produtividade, qualidade e satisfação em seus novos projetos.

Fique por dentro
Ao ler este artigo você irá saber como o Spring Boot se encaixa no contexto histórico do Java EE e Spring e também entender as relações entre eles, além de conhecer as motivações por trás desse projeto da Spring IO.

Também irá aprender como construir uma aplicação com o Spring Boot e como customizá-la de acordo com suas necessidades. A partir disso, você poderá adotar em seus projetos uma solução que reduzirá a quantidade de configurações e opinará pelas tecnologias a serem utilizadas visando a alta produtividade.

Há pouco mais de um ano – em abril de 2014 – a Spring IO disponibilizava a primeira versão não-beta do Spring Boot, a 1.0.0, depois de mais de dezoito meses de desenvolvimento e maturação.

Desde então, o projeto tem evoluído em grande velocidade e, na data de escrita deste artigo, já se encontra na versão 1.2.5, com a 1.3.x batendo a porta.

O Spring Boot é um projeto-chave para a Spring IO, mas, por ser recente, muitos desenvolvedores ainda não tiveram um primeiro contato com ele e muitos dos já introduzidos ainda desconhecem algumas ou várias de suas possibilidades e recursos.

É uma ferramenta de alavancagem de produtividade e qualidade. Assim, se você é um desenvolvedor que lida com aplicações baseadas em Spring, deve ao menos conhecê-la.

Ao ler este artigo você entenderá as motivações por trás desse projeto, assim como sua importância, não só para a Spring IO, como para a indústria de software atual.

Também irá aprender, se já não sabe, como dar seus primeiros passos no uso do Spring Boot, assim como orientá-lo em casos excepcionais às suas configurações pré-fixadas.

Portanto, mesmo àqueles que não estão envolvidos com o Spring em seu dia a dia, ou o fazem muito esporadicamente, este artigo trará muita informação útil, de uma forma ou de outra.

Com a finalidade de exercício dos conceitos, mecanismos e pontos apresentados, este artigo também traz um pequeno projeto web que expõe um serviço REST de consulta de aeroportos pelo mundo através dos critérios país, cidade ou código da International Air Transport Association, IATA. É uma aplicação um tanto mais complexa que um 'Hello World!', mas simples ao ponto de não perdermos de vista nosso foco, a compreensão e uso do Spring Boot.

Para construir e executá-la é preciso apenas do JDK, do Maven e estar conectado à Internet, para que o mesmo descarregue as dependências do projeto. Apesar de ser inteiramente funcional com o Java 6 e 7, replicamos aqui a recomendação do documento de referência do Spring Boot em utilizá-lo com o Java 8 – como veremos, entretanto, configurá-lo a uma ou outra versão é tão simples como escrever o número dela.

Quanto ao Maven, é necessário que seja a versão 3.2+. É possível também utilizar o Gradle (1.12+), mas como o primeiro é mais conhecido e já faz parte do dia a dia da maior parte dos desenvolvedores, nosso projeto irá adotá-lo.

Apesar de código e recursos em arquivo não somarem muito mais que uma dezena de itens, recomenda-se o uso de uma IDE, preferencialmente o Spring Tool Suite (STS) – mas só pelo fato de ele possuir uma integração natural com componentes Spring, como o próprio Boot, o que facilita a execução e depuração com o mínimo esforço.

Para entendermos por que o Spring Boot foi criado, precisamos conhecer um pouco da história do Spring Framework. E para que possamos entender, de fato, o Spring Framework, precisamos conhecer um pouco da história do J2EE, Java 2 – Enterprise Edition. Comecemos, então, a discorrer sobre essas histórias e suas relações, a começar pelo J2EE. É provável que alguns dos leitores já saibam delas, mas vale a pena ver de novo.

J2EE, Java 2 – Enterprise Edition

O J2EE, parte da plataforma Java, é similarmente uma plataforma, mas específica para o desenvolvimento de aplicações Java em arquitetura de multicamadas, modular e distribuída, executadas em servidores de aplicações.

Ela não é exatamente um produto, mas um conjunto de especificações, originalmente desenvolvido pela Sun Microsystems (casa original do Java, hoje na Oracle, como sabemos), e lançado evolutivamente em versões.

A partir da versão 1.3 a especificação da plataforma passou ao domínio da JCP (Java Community Process), que a controla através de JSRs (Java Specification Requests), como a JSR-58, que especifica o J2EE 1.3 (2001), a JSR-151, que especifica o J2EE 1.4 (2002), e assim por diante.

O Java EE – passemos a utilizar a sigla atual a partir daqui – inclui diversas especificações de API, como o JDBC, e-mail, JMS, web services, RMI, JTA, JPA, JSF, JMX, JNDI, manipulação de XML, etc. e como usá-las de maneira coordenada. Há também especificações únicas a seus componentes, como EJB, servlets, portlets e diversas tecnologias de serviços web. Todas essas especificações estão interligadas com o propósito de permitir a criação de aplicações corporativas – termo comum que usamos para designar uma aplicação Java EE – portáveis entre os servidores de aplicação, os quais disponibilizam todas as especificações como infraestrutura de maneira uniforme, além de garantir escalabilidade, concorrência e gerenciamento dos componentes e aplicações entregues (deployed) neles.

O objetivo é permitir ao desenvolvedor manter o máximo possível de seu foco na construção do negócio de sua aplicação e alavancar produtividade e qualidade. Observe na Figura 1 a visão geral do Java EE. A Figura 2 apresenta uma visão mais detalhada e integrada.

Figura 1. Visão geral da pilha Java EE.

Figura 2. Visão integrada da pilha Java EE.

Java EE – Do discurso à realidade

Não há como negar que o Java EE tenha sido e seja um sucesso. Diferentemente do CORBA, Common Object Request Broker Architecture, da OMG, e do DCOM/COM+, da Microsoft, – só para citar duas das propostas próximas em intenção e modelo de mais destaque na época do surgimento do Java EE – sua adoção pelo mercado e pelos desenvolvedores foi significativamente maior.

Além de contar com a força crescente da plataforma Java à época, a estratégia de delegar a especificação comunitária à JCP pela Sun Microsystems e seu foco em dominar, ou ao menos estar entre os mais importantes nomes do mercado de soluções para o desenvolvimento e execução de aplicações corporativas, impulsionaram a consolidação e evolução autossustentável da plataforma Java EE.

Não há também como negar que o Java EE tenha tido muitos problemas em seus primeiros anos. Todos ou boa parte deles vêm sendo tratados a cada nova versão das diversas especificações. De qualquer forma, no entanto, o desconforto causado deu espaço a novos modelos de desenvolvimento, manutenção e execução de aplicações corporativas, como é o caso do Spring Framework.

O desconforto deveu-se principalmente a três fatores. O primeiro deles é que apesar de todo o cuidado e visão das especificações, o como elas eram implementadas e coordenadas em um servidor de aplicações Java EE ficou bastante vago e até mesmo ausente em alguns aspectos nas primeiras versões, afetando definições de segurança, representação de campos CMP (Container Managed Persistence) na classe de bean, ordem de deployment de módulos, para citar alguns. As diversas implementações tentaram endereçar da melhor maneira possível algumas das lacunas de definição citadas. Alguns exemplos comerciais e open source de servidores de aplicação são:

· IBM – WebSphere;

· WebLogic/BEA – WebLogic;

· Adobe – JRun;

· JBoss/Red Hat – JBoss AS (recentemente substituído pelo WildFly;

· Apache – Geronimo, TomEE;

· Object Web – JOnAS;

· Caucho Technology – Resin.

Essa quantidade de opções, apesar de vibrante, afetava um dos pilares conceituais do Java EE: a portabilidade. Cada produto tinha seu conjunto de ferramentas e especializações de configurações e o resultado final é que o único artefato portável era o código da aplicação. Iniciou-se, então, um programa de certificação para servidores de aplicação, mas sua adoção foi lenta.

O JBoss AS, por exemplo, só se tornou certificado a partir de sua versão 4. Apesar de ser ideal estar 100% fiel à especificação, é mais importante manter a base de usuários e clientes que simplesmente ter um selo de conformidade.

O código de " [...]

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Ficou com alguma dúvida?