Nota: Não confundir com Spring Boot.
Spring Framework
DesenvolvedorVMware
Lançamento inicial1 de outubro de 2002; há 23 anos
Lançamento estável
7.0.5 Edit this on Wikidata / 18 fevereiro 2026
Repositório
Escrito emJava
PlataformaJakarta EE
TipoFramework de aplicação
LicençaLicença Apache 2.0
Websitespring.io/projects/spring-framework Edit this on Wikidata

O Spring Framework é um framework de aplicação e um contêiner de inversão de controle para a plataforma Java.[1] Os recursos principais do framework podem ser usados por qualquer aplicação Java, mas existem extensões para a criação de aplicações web sobre a plataforma Jakarta EE. O framework não impõe nenhum modelo de programação específico.[2] O framework tornou-se popular na comunidade Java como um complemento ao modelo Enterprise JavaBeans (EJB).[3] O Spring Framework é um software livre e de código aberto.[4]:[5]

Histórico de versões

editar
Versão Data
0.9 2003
1.0 24 de março de 2004
2.0 2006
3.0 2009
4.0 2013
5.0 2017
6.0 22 de novembro de 2022
6.1 16 de novembro de 2023
6.2 14 de novembro de 2024
7.0 13 de novembro de 2025

A primeira versão foi escrita por Rod Johnson, que lançou o framework juntamente com a publicação de seu livro Expert One-on-One J2EE Design and Development em outubro de 2002. O framework foi lançado pela primeira vez sob a licença Apache 2.0 em junho de 2003. O primeiro lançamento de produção, a versão 1.0, foi lançado em março de 2004.[6] O Spring 1.2.6 ganhou um prêmio Jolt de produtividade e um JAX Innovation Award em 2006.[7][8] Spring 2.0 foi lançado em outubro de 2006, Spring 2.5 em novembro de 2007, Spring 3.0 em dezembro de 2009, Spring 3.1 em dezembro de 2011 e Spring 3.2.5 em novembro de 2013.[9] O Spring Framework 4.0 foi lançado em dezembro de 2013.[10] Melhorias notáveis no Spring 4.0 incluíram suporte para Java SE 8, Groovy 2,[11][12] alguns aspectos do Java EE 7 e WebSocket.[13]

Spring Framework 4.2.0 foi lançado em 31 de julho de 2015 e imediatamente atualizado para a versão 4.2.1, lançada em 1º de setembro de 2015.[14] Ele é "compatível com Java 6, 7 e 8, com foco em refinamentos principais e recursos modernos da web".[15]

Spring Framework 4.3 foi lançado em 10 de junho de 2016 e foi suportado até 2020.[16] Foi anunciado que seria "a última geração dentro dos requisitos gerais do sistema Spring 4 (Java 6+, Servlet 2.5+), [...]".[15]

Spring 5 foi construído sobre o Reactor Core compatível com Reactive Streams.[17]

Spring Framework 6.0 foi lançado em 16 de novembro de 2022 e veio com uma base Java 17+ e uma mudança para Jakarta EE 9+ (no espaço de nomes jakarta), com foco nas APIs Jakarta EE 10 recentemente lançadas, como Servlet 6.0 e JPA 3.1.[18]

Módulos

editar

O Spring Framework inclui vários módulos que fornecem uma variedade de serviços:

  • Contêiner principal do Spring: este é o módulo base do Spring[19] e fornece os contêineres Spring (BeanFactory e ApplicationContext).[20][21][22] Neste contexto, spring-core é o artefato[23] encontrado no módulo core[24] pertencente ao grupo org.springframework.[25] O artefato spring-core consiste no contêiner IoC, bem como nas classes utilitárias[23] usadas em toda a aplicação.[26]
  • Programação orientada a aspectos: permite implementar preocupações transversais.[27][28] O spring-aop é um artefato para o framework AOP.[24]
  • Autenticação e autorização: processos de segurança configuráveis que suportam uma variedade de padrões, protocolos, ferramentas e práticas através do subprojeto Spring Security (anteriormente Acegi Security System for Spring).[29][30]
  • Convenção sobre configuração: uma solução de desenvolvimento rápido de aplicações para aplicações empresariais baseadas em Spring é oferecida no módulo Spring Roo.
  • Acesso a dados: trabalho com sistemas de gerenciamento de banco de dados relacionais na plataforma Java usando Java Database Connectivity (JDBC)[31] e ferramentas de mapeamento objeto-relacional e com bancos de dados NoSQL[32]. O spring-jdbc é um artefato encontrado no módulo JDBC que suporta acesso JDBC incluindo classes de configuração de fonte de dados.[24]
  • Contêiner de inversão de controle: configuração de componentes da aplicação e gerenciamento do ciclo de vida de objetos Java, feito principalmente via injeção de dependência.[21]
  • Mensageria: registro declarativo de objetos ouvintes de mensagens para consumo transparente de mensagens de filas de mensagens via Java Message Service (JMS), melhoria do envio de mensagens sobre as APIs JMS padrão.[33]
  • Modelo–visão–controlador: um framework baseado em HTTP e servlet que fornece ganchos para extensão e personalização para aplicações web e serviços web REST (transferência de estado representacional).[34][35]
  • Framework de acesso remoto: marshalling declarativo no estilo chamada de procedimento remoto (RPC)[36] de objetos Java através de redes suportando invocação de método remoto Java (RMI),[37] CORBA e protocolos baseados em HTTP, incluindo serviços web como SOAP.[38][39]
  • Gerenciamento de transações: unifica várias APIs de gerenciamento de transações e coordena transações para objetos Java.[40][41]
  • Gerenciamento remoto: exposição e gerenciamento declarativos de objetos Java para configuração local ou remota via Java Management Extensions (JMX).[40][42]
  • Testes: classes de suporte para escrever testes de unidade[43] e testes de integração.[44]
  • Suporte WebFlux: suporte para usar runtimes reativos ou servidores web como UnderTow e Netty.[24][45]
  • Suporte Web Socket: suporte para comunicação usando o protocolo WebSocket. O artefato para este módulo é spring-websocket.
  • Suporte XML: suporte para mapeamento objeto-XML.[24] Bibliotecas como Jakarta XML Binding (JAXB) e XStream são suportadas.[24] O artefato para este módulo é spring-oxm.

Os módulos Spring são empacotados como arquivos JAR.[46] Esses artefatos podem ser acessados via Maven Central Repository usando Maven[47] ou Gradle.[48]

Contêiner de inversão de controle

editar

O contêiner de inversão de controle (IoC) é o contêiner central do Spring Framework.[1] Ele fornece um meio consistente de configurar e gerenciar objetos Java[1][4]: usando reflexão.[49] O contêiner é responsável por gerenciar os ciclos de vida dos objetos de objetos específicos:[4]: criar esses objetos,[50] chamar seus métodos de inicialização[49] e configurar esses objetos conectando-os entre si.[51]

Em muitos casos, não é necessário usar o contêiner ao usar outras partes do Spring Framework, embora seu uso torne a aplicação mais fácil de configurar e personalizar. O contêiner Spring fornece um mecanismo consistente para configurar aplicações[4]: e se integra com quase todos os ambientes Java, desde aplicações de pequena escala até grandes aplicações empresariais.

O programador não cria diretamente um objeto, mas descreve como ele deve ser criado, definindo-o no arquivo de configuração do Spring. Da mesma forma, serviços e componentes não são chamados diretamente; em vez disso, um arquivo de configuração Spring define quais serviços e componentes devem ser chamados. Essa IoC visa aumentar a facilidade de manutenção e teste.

Criando e gerenciando beans

editar

Objetos criados pelo contêiner são chamados de objetos gerenciados ou beans.[52] O contêiner pode ser configurado carregando arquivos XML[50][4]: ou detectando anotações Java específicas em classes de configuração. Essas fontes de dados contêm as definições de bean que fornecem as informações necessárias para criar os beans.

A anotação @Configuration é uma anotação específica do Spring que marca uma classe como a classe de configuração. A classe de configuração fornece os beans para o ApplicationContext do Spring.[53] Cada um dos métodos na classe de configuração Spring é configurado com a anotação @Bean. A interface ApplicationContext então retornará os objetos configurados com a anotação @Bean como beans. A vantagem da configuração baseada em Java sobre a configuração baseada em XML é melhor segurança de tipo e refatorabilidade.[53]

Tipos de inversão de controle

editar

Existem vários tipos de inversão de controle. Injeção de dependência e busca de dependência são exemplos de inversão de controle.[54] Objetos podem ser obtidos por meio de busca de dependência ou injeção de dependência.[4]:[55]

Injeção de dependência

editar

Injeção de dependência é um padrão onde o contêiner passa objetos[4]: por nome para outros objetos, via construtores,[4]: propriedades ou métodos de fábrica. Existem várias maneiras de implementar a injeção de dependência: injeção de dependência baseada em construtor, injeção de dependência baseada em setters e injeção de dependência baseada em campo.[56]

Busca de dependência

editar

Busca de dependência é um padrão onde um chamador pede ao objeto contêiner um objeto com um nome específico ou de um tipo específico.

Autowiring

editar

O Spring Framework tem um recurso conhecido como autowiring, que usa o contêiner Spring para satisfazer automaticamente as dependências especificadas nas propriedades JavaBean para objetos do tipo apropriado na fábrica atual.[57] Isso só pode ocorrer se houver apenas um objeto com o tipo apropriado.[57]

Existem várias anotações que podem ser usadas para autowiring de POJOs, incluindo a anotação específica do Spring @Autowire (bem como várias outras anotações específicas do Spring que ajudam a resolver ambiguidade de autowiring, como as anotações @Qualifier ou @Primary),[58][59] e as anotações Java padrão @Resource e @Inject.[60]

A anotação @Qualifier pode ser usada em uma classe que define um bean para informar ao Spring que priorize a criação do bean ao fazer autowiring por nome.[59]

A anotação @Primary pode ser usada em uma classe que define um bean para informar ao Spring que priorize a criação do bean ao fazer autowiring por tipo.[59]

A anotação @Resource é uma anotação que está em conformidade com o JSR 250, ou Common Annotations for the Java Platform, e é usada para autowiring de referências a POJOs por nome.[60]

A anotação @Inject é uma anotação que está em conformidade com o JSR 300, ou Standard Annotations for injection, e é usada para autowiring de referências a POJOs por tipo.[60]

Framework de programação orientada a aspectos

editar

O Spring Framework tem seu próprio framework de programação orientada a aspectos (AOP) que modulariza preocupações transversais em aspectos.[61] A motivação para criar um framework AOP separado é fornecer recursos básicos de AOP sem muita complexidade no design, implementação ou configuração. O framework Spring AOP aproveita ao máximo o contêiner Spring.

O framework Spring AOP é baseado no padrão proxy.[62][24] Ele é configurado em tempo de execução. Isso elimina a necessidade de uma etapa de compilação ou tecelagem em tempo de carga. Por outro lado, a interceptação permite apenas a execução de métodos públicos em objetos existentes em um ponto de junção.

Comparado ao framework AspectJ, o Spring AOP é menos poderoso, mas também menos complicado. O Spring 1.2 inclui suporte para configurar aspectos AspectJ no contêiner. O Spring 2.0 adicionou mais integração com o AspectJ; por exemplo, a linguagem de ponto de corte é reutilizada e pode ser misturada com aspectos baseados em Spring AOP. Além disso, o Spring 2.0 adicionou uma biblioteca Spring Aspects que usa o AspectJ para oferecer recursos comuns do Spring, como gerenciamento de transações declarativo[62] e injeção de dependência via tecelagem em tempo de compilação ou tempo de carga do AspectJ.[63] A SpringSource usa o AOP do AspectJ em outros projetos Spring, como Spring Roo e Spring Insight, com o Spring Security oferecendo uma biblioteca de aspectos baseada em AspectJ.

O Spring AOP foi projetado para trabalhar com preocupações transversais dentro do Spring Framework.[4]: Qualquer objeto que é criado e configurado pelo contêiner pode ser enriquecido usando Spring AOP.

Desde a versão 2.0 do framework, o Spring fornece duas abordagens para a configuração AOP:

  • abordagem baseada em esquema[64] e
  • estilo de anotação baseado em @AspectJ.[65]
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:mvc="http://www.springframework.org/schema/mvc" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:aop="http://www.springframework.org/schema/aop" 
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/context
        http://www.springframework.org/schema/context/spring-context.xsd
        http://www.springframework.org/schema/mvc
        http://www.springframework.org/schema/mvc/spring-mvc.xsd
        http://www.springframework.org/schema/aop 
        http://www.springframework.org/schema/aop/spring-aop.xsd">

A equipe do Spring decidiu não introduzir nova terminologia relacionada a AOP. Portanto, na documentação de referência do Spring e na API, termos como aspecto, ponto de junção, conselho, ponto de corte, introdução, objeto alvo (objeto aconselhado), proxy AOP e tecelagem têm todos os mesmos significados[carece de fontes?] que na maioria dos outros frameworks AOP (particularmente o AspectJ).

Framework de acesso a dados

editar

O framework de acesso a dados do Spring aborda dificuldades comuns que os desenvolvedores enfrentam ao trabalhar com bancos de dados em aplicações. Suporte é fornecido para todos os frameworks de acesso a dados populares em Java: JDBC, iBatis/MyBatis,[32] Hibernate,[32] Java Data Objects (JDO, descontinuado desde 5.x),[32] Jakarta Persistence API (JPA),[32] Oracle TopLink, Apache OJB e Apache Cayenne, entre outros.

Para todos esses frameworks suportados, o Spring fornece estes recursos:

  • Gerenciamento de recursos – adquirindo e liberando automaticamente recursos do banco de dados
  • Tratamento de exceções – traduzindo exceções relacionadas a acesso a dados para uma hierarquia de exceções de acesso a dados do Spring[66]
  • Participação em transações – participação transparente em transações em andamento[4]:
  • Desembrulhamento de recursos – recuperando objetos de banco de dados de wrappers de pool de conexões
  • Abstração para manipulação de BLOB (binary large object) e CLOB (character large object)

Todos esses recursos se tornam disponíveis ao usar classes modelo fornecidas pelo Spring para cada framework suportado.[67] Críticos disseram que essas classes modelo são intrusivas e não oferecem vantagem sobre o uso (por exemplo) da API Hibernate diretamente.[68] Em resposta, os desenvolvedores do Spring tornaram possível usar as APIs Hibernate e JPA diretamente. Isso, no entanto, requer gerenciamento de transações transparente, pois o código da aplicação não assume mais a responsabilidade de obter e fechar recursos do banco de dados,[69] e não suporta tradução de exceções.[70]

Juntamente com o gerenciamento de transações do Spring, seu framework de acesso a dados oferece uma abstração flexível para trabalhar com frameworks de acesso a dados. O Spring Framework não oferece uma API comum de acesso a dados; em vez disso, todo o poder das APIs suportadas é mantido intacto.[carece de fontes?] O Spring Framework é o único framework disponível em Java que oferece ambientes de acesso a dados gerenciados fora de um servidor de aplicações ou contêiner.[71]

Ao usar o Spring para gerenciamento de transações com Hibernate, os seguintes beans podem ter que ser configurados:

  • Um Datasource como com.mchange.v2.c3p0.ComboPooledDataSource ou org.apache.commons.dbcp.BasicDataSource[32]
  • Um SessionFactory como org.springframework.orm.hibernate3.LocalSessionFactoryBean com um atributo DataSource[72][4]:
  • Um HibernateProperties[4]: como org.springframework.beans.factory.config.PropertiesFactoryBean
  • Um TransactionManager como org.springframework.orm.hibernate3.HibernateTransactionManager com um atributo SessionFactory[72]

Outros pontos de configuração incluem:

  • Uma configuração AOP de pontos de corte.
  • Semântica de transação do conselho AOP.

Gerenciamento de transações

editar

O framework de gerenciamento de transações do Spring traz um mecanismo de abstração para a plataforma Java.[73] Sua abstração é capaz de:

  • trabalhar com transações locais e globais[4]: (transação local não requer um servidor de aplicações)
  • trabalhar com transações aninhadas[74]
  • trabalhar com savepoints[74]
  • trabalhar em quase todos os ambientes da plataforma Java

Em comparação, a Java Transaction API (JTA) suporta apenas transações aninhadas e globais, e requer um servidor de aplicações (e em alguns casos, a implantação de aplicações em um servidor de aplicações).

O Spring Framework fornece um PlatformTransactionManager[75] para várias estratégias de gerenciamento de transações:

  • Transações gerenciadas em uma conexão JDBC[73]
  • Transações gerenciadas em unidades de trabalho de mapeamento objeto-relacional[73]
  • Transações gerenciadas via JTA[73] JtaTransactionManager[76][4]: e UserTransaction[4]:
  • Transações gerenciadas em outros recursos, como bancos de dados de objetos

Além deste mecanismo de abstração, o framework fornece duas maneiras de adicionar gerenciamento de transações a aplicações:

  • Processualmente, usando o TransactionTemplate do Spring[77]
  • Declarativamente, usando metadados como XML ou anotações Java (@Transactional,[62] etc.)

Juntamente com o framework de acesso a dados do Spring — que integra o framework de gerenciamento de transações — é possível configurar um sistema transacional através da configuração sem ter que depender de JTA ou EJB. O framework transacional também se integra a mecanismos de mensageria[78] e cache.[79]

Framework modelo–visão–controlador

editar
Apresentação do Spring MVC/Web Reactive por Jürgen Höller

O Spring Framework possui seu próprio framework web modelo–visão–controlador (MVC),[35] que não foi originalmente planejado. Os desenvolvedores do Spring decidiram escrever seu próprio framework web como reação ao que perceberam como o design ruim do (então) popular framework web Jakarta Struts,[80] bem como deficiências em outros frameworks disponíveis. Em particular, eles sentiram que havia separação insuficiente entre as camadas de apresentação e manipulação de requisições, e entre a camada de manipulação de requisições e o modelo.[81]

Como o Struts, o Spring MVC é um framework baseado em requisições.[4]: O framework define interfaces de estratégia[4]: para todas as responsabilidades que devem ser tratadas por um framework moderno baseado em requisições. O objetivo de cada interface é ser simples e clara para que seja fácil para os usuários do Spring MVC escreverem suas próprias implementações, se assim desejarem. O MVC abre caminho para um código de front-end mais limpo. Todas as interfaces estão fortemente acopladas à API Servlet. Este forte acoplamento à API Servlet é visto por alguns como uma falha por parte dos desenvolvedores do Spring em oferecer um alto nível de abstração para aplicações baseadas na web. No entanto, este acoplamento garante que os recursos da API Servlet permaneçam disponíveis para os desenvolvedores, ao mesmo tempo que oferece um framework de alta abstração para facilitar o trabalho com ela.

A classe DispatcherServlet é o controlador frontal[82] do framework e é responsável por delegar o controle às várias interfaces durante as fases de execução de uma requisição HTTP.[83]

As interfaces mais importantes definidas pelo Spring MVC, e suas responsabilidades, estão listadas abaixo:[84]

  • Controller: fica entre Model e View para gerenciar requisições recebidas e redirecionar para a resposta apropriada.[85] Controller mapeará a requisição http para os métodos correspondentes.[86] Atua como um portão que direciona a informação recebida. Ele alterna entre entrar em Model ou View.
  • HandlerAdapter: responsável pela execução de objetos que tratam requisições recebidas.[87]
  • HandlerInterceptor: responsável por interceptar requisições recebidas.[87] Comparável, mas não igual a filtros de Servlet[4]: (o uso é opcional[4]: e não controlado por DispatcherServlet).
  • HandlerMapping: responsável por selecionar objetos que tratam requisições recebidas (handlers) com base em qualquer atributo ou condição interna ou externa a essas requisições.[83]
  • LocaleResolver: responsável por resolver e opcionalmente salvar a localidade de um usuário individual.[88]
  • MultipartResolver: facilita o trabalho com uploads de arquivos envolvendo requisições recebidas.[89]
  • View: responsável por retornar uma resposta ao cliente. O View não deve conter nenhuma lógica de negócios e deve apenas apresentar os dados encapsulados pelo Model.[35] Algumas requisições podem ir diretamente para View sem passar pela parte Model; outras podem passar por todos os três.
  • ViewResolver: responsável por selecionar uma View com base em um nome lógico para a View[90][91] (o uso não é estritamente obrigatório[4]:).
  • Model: responsável por encapsular dados de negócios.[90] O Model é exposto à visão pelo controlador.[4]: (o uso não é estritamente obrigatório).

Cada interface de estratégia acima tem uma responsabilidade importante no framework geral. As abstrações oferecidas por essas interfaces são poderosas, permitindo um conjunto de variações em suas implementações.[4]: O Spring MVC fornece implementações de todas essas interfaces e oferece um conjunto de recursos sobre a API Servlet. No entanto, desenvolvedores e fornecedores são livres para escrever outras implementações. O Spring MVC usa a interface Map do Java como uma abstração orientada a dados para o Model onde as chaves são esperadas como valores String.[carece de fontes?]

A facilidade de testar as implementações dessas interfaces é uma vantagem importante do alto nível de abstração oferecido pelo Spring MVC.[92][4]: O DispatcherServlet está fortemente acoplado ao contêiner de inversão de controle do Spring para configurar as camadas web das aplicações. No entanto, aplicações web podem usar outras partes do Spring Framework, incluindo o contêiner, e optar por não usar o Spring MVC.

Fluxo de trabalho do Spring MVC

editar

Quando um usuário clica em um link ou envia um formulário em seu navegador web, a requisição vai para o DispatcherServlet do Spring. O DispatcherServlet é um controlador frontal no Spring MVC.[83][93] O DispatcherServlet é altamente personalizável e flexível.[93] Especificamente, ele é capaz de lidar com mais tipos de handlers do que quaisquer implementações de org.springframework.web.servlet.mvc.Controller ou classes anotadas com org.springframework.stereotype.Controller.[93] Ele consulta um ou mais mapeamentos de handlers.[83] O DispatcherServlet escolhe um controlador apropriado e encaminha a requisição para ele. O Controller processa a requisição particular e gera um resultado. Isso é conhecido como Model. Esta informação precisa ser formatada em HTML ou qualquer tecnologia de front-end como Jakarta Server Pages (também conhecido como JSP)[83][94] ou Thymeleaf.[94] Esta é a View de uma aplicação.[83] Toda a informação está no objeto Model e View. Quando o controlador não está acoplado a uma visão particular, o DispatcherServlet encontra a View real (como JSP) com a ajuda do ViewResolver.[83][4]:

Configuração do DispatcherServlet

editar

A partir da versão 3.0 da Especificação Servlet, existem algumas maneiras de configurar o DispatcherServlet:[95]

  • Configurando-o em web.xml como mostrado abaixo:[95]
<servlet>
  <servlet-name>MyServlet</servlet-name>
  <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
</servlet>

<servlet-mapping>
  <servlet-name>MyServlet</servlet-name>
  <url-pattern>/</url-pattern>
</servlet-mapping>
  • Configurando-o em web-fragment.xml.[95]
  • Usando javax.servlet.ServletContainerInitializer.[95]
  • Implementando a interface org.springframework.web.WebApplicationInitializer.[95]
  • Usando a autoconfiguração embutida do Spring Boot, que usa a classe SpringBootServletInitializer.[95]

Framework de acesso remoto

editar

O framework de acesso remoto do Spring é uma abstração para trabalhar com várias tecnologias baseadas em RPC (chamada de procedimento remoto) disponíveis na plataforma Java, tanto para conectividade do cliente quanto para marshalling de objetos em servidores.[96] O recurso mais importante oferecido por este framework é facilitar a configuração e o uso dessas tecnologias o máximo possível, combinando inversão de controle e AOP.

O framework fornece recuperação de falhas (reconexão automática após falha de conexão) e algumas otimizações para uso no lado do cliente de beans de sessão sem estado EJB remotos.

O Spring fornece suporte para estes protocolos e produtos prontos para uso:

  • Protocolos baseados em HTTP
    • Hessian: protocolo de serialização binária,[97][4]: de código aberto[4]: e mantido por protocolos baseados em CORBA[carece de fontes?]. O Hessian é mantido pela empresa Caucho.[4]: O Hessian é adequado para necessidades de remoção sem estado, em particular, comunicação Java-para-Java.[4]:
    • Burlap: um protocolo binário baseado em XML que é de código aberto e também mantido pela empresa Caucho.[97][4]: A única vantagem de usar Burlap em vez de Hessian é que ele é analisável por XML e legível por humanos.[4]: Para comunicação Java-para-Java, o Hessian é preferido, pois é mais leve e eficiente.[4]:
    • RMI (1): invocações de método usando a infraestrutura RMI, mas específica do Spring[96]
    • RMI (2): invocações de método usando interfaces RMI em conformidade com o uso regular de RMI[96]
    • RMI-IIOP (CORBA): invocações de método usando RMI-IIOP/CORBA
  • Integração do cliente Enterprise JavaBean[98]
    • Conectividade de bean de sessão sem estado EJB local: conectando a beans de sessão sem estado locais
    • Conectividade de bean de sessão sem estado EJB remoto: conectando a beans de sessão sem estado remotos
  • SOAP
    • Integração com o framework de serviços web Apache Axis[99]

O Apache CXF fornece integração com o Spring Framework para exportação de estilo RPC de objetos no lado do servidor.[99]

Tanto a configuração do cliente quanto do servidor para todos os protocolos e produtos de estilo RPC suportados pelo framework de acesso remoto do Spring (exceto o suporte Apache Axis) são configuradas no contêiner principal do Spring.

Existe uma implementação alternativa de código aberto (Cluster4Spring) de um subsistema de remoção incluído no Spring Framework que visa suportar vários esquemas de remoção (1-1, 1-muitos, descoberta dinâmica de serviços).

Desenvolvimento rápido de aplicações por convenção sobre configuração

editar

Spring Boot

editar

A extensão Spring Boot é a solução de convenção sobre configuração do Spring para criar aplicações baseadas em Spring autônomas, de nível de produção,[100] que você pode "apenas executar".[101] Ela é pré-configurada com a "visão opinativa" da equipe Spring[102][103] da melhor configuração e uso da plataforma Spring e bibliotecas de terceiros, para que você possa começar com o mínimo de complicação. A maioria das aplicações Spring Boot precisa de pouca configuração Spring.[104]

Recursos principais:

  • Criar aplicações Spring autônomas
  • Incorporar Tomcat ou Jetty[105] diretamente (sem necessidade de implantar arquivos WAR)
  • Fornecer Project Object Models (POMs) 'iniciais' opinativos para simplificar sua configuração Maven/Gradle[106]
  • Configurar automaticamente o Spring sempre que possível[107]
  • Fornecer recursos prontos para produção[100] como métricas,[108] verificações de saúde[108] e configuração externalizada[109]
  • Absolutamente nenhuma geração de código[105] e nenhum requisito[106] de configuração XML.[110]
  • Integração suave e suporta todos os Padrões de Integração Empresarial.

Spring Roo

editar

Spring Roo é um projeto da comunidade que fornece uma abordagem alternativa, baseada em geração de código, para usar convenção sobre configuração para construir rapidamente aplicações em Java. Atualmente suporta Spring Framework, Spring Security e Spring Web Flow. O Roo difere de outros frameworks de desenvolvimento rápido de aplicações por focar em:

  • Extensibilidade (via complementos)
  • Produtividade da plataforma Java (em oposição a outras linguagens)
  • Evitar lock-in (Roo pode ser removido de qualquer aplicação em poucos minutos)
  • Evitar tempo de execução (com vantagens de implantação associadas)
  • Usabilidade (particularmente através dos recursos e padrões de uso do shell)

Framework de lote

editar

Spring Batch é um framework para processamento em lote que fornece funções reutilizáveis essenciais no processamento de grandes volumes de registros, incluindo:

  • registro/rastreamento
  • gerenciamento de transações
  • estatísticas de processamento de jobs[111]
  • reinicialização de jobs

Ele fornece serviços e recursos técnicos mais avançados que permitem jobs de lote de altíssimo volume[112] e alto desempenho[111] através de técnicas de otimização e particionamento.[111]

O Spring Batch executa uma série de jobs; um job consiste em um número de etapas e cada etapa consiste em uma tarefa "READ-PROCESS-WRITE" ou uma tarefa de operação única (tasklet). Uma tarefa de "operação única" também é conhecida como tasklet.[113] Isso significa fazer apenas uma única tarefa, como limpar os recursos antes ou depois de uma etapa ser iniciada ou concluída.

O processo "READ-PROCESS-WRITE" consiste nestas etapas: "ler" dados de um recurso (valores separados por vírgulas (CSV), XML ou banco de dados), "processá-los" e depois "escrevê-los" em outros recursos (CSV, XML ou banco de dados). Por exemplo, uma etapa pode ler dados de um arquivo CSV,[113] processá-los e escrevê-los no banco de dados. O Spring Batch fornece várias classes para ler/escrever CSV, XML e banco de dados.[114]

As etapas podem ser encadeadas para serem executadas como um job.[113]

Framework de integração

editar

Spring Integration é um framework para integração de aplicações empresariais que fornece funções reutilizáveis essenciais para arquiteturas orientadas a mensagens ou eventos.

  • roteadores – roteia uma mensagem para um canal de mensagens com base em condições[115]
  • transformadores – converte/transforma/altera o payload da mensagem e cria uma nova mensagem com o payload transformado[116]
  • adaptadores – integra com outras tecnologias e sistemas (HTTP, AMQP,[117] JMS, XMPP, SMTP,[118] IMAP, FTP bem como FTPS/SFTP, sistemas de arquivos, etc.)
  • filtros – filtra uma mensagem com base em critérios. Se os critérios não forem atendidos, a mensagem é descartada.[119]
  • ativadores de serviço – invocam uma operação em um objeto de serviço. O Spring suporta o uso da anotação @ServiceActivator para declarar o componente que requer essa funcionalidade.[120]
  • gerenciamento e auditoria
  • gateways - expõe uma interface ao cliente para os serviços solicitados. Um middleware de mensageria é responsável por provisionar essa interface. Esta interface desacopla o middleware de mensageria do cliente, ocultando as APIs JMS ou Spring Integration subjacentes. Gateways estão relacionados ao padrão Facade. A classe de Integração do Spring, SimpleMessagingGateway, fornece suporte essencial para gateways. SimpleMessagingGateway permite que a aplicação Spring especifique o canal que envia requisições e o canal que espera receber respostas. O foco principal do SimpleMessagingGateway é lidar com payloads, o que poupa o cliente dos detalhes intrincados das mensagens transmitidas e recebidas. SimpleMessagingGateway é usado junto com canais para permitir a integração com sistemas de arquivos, JMS, e-mail ou quaisquer outros sistemas que exijam payloads e canais.[121]
  • splitter - Separa um payload grande em payloads menores para suportar diferentes fluxos de processamento. O splitter é alcançado no Spring usando o componente splitter. O componente splitter geralmente encaminha as mensagens para classes com funcionalidade mais especializada. O Spring suporta a anotação @Splitter para declarar o componente que requer essa funcionalidade.[122]
  • aggregator - Usado para combinar múltiplas mensagens em um único resultado. De forma geral, o aggregator é o inverso do splitter. O aggregator publica uma única mensagem para todos os componentes a jusante. O Spring suporta a anotação @Aggregator para declarar o componente que requer essa funcionalidade.[122]

O Spring Integration suporta arquiteturas baseadas em pipe-and-filter.

Spring WebSocket

editar

Uma regra essencial para lidar com fluxos de dados de forma eficaz é nunca bloquear.[123] O WebSocket é uma solução viável para este problema.[123] O Protocolo WebSocket é um protocolo de transporte de baixo nível que permite canais de comunicação full-duplex sobre uma conexão TCP. O WebSocket atua como uma alternativa ao HTTP para permitir comunicação bidirecional entre o cliente e o servidor. O WebSocket é especialmente útil para aplicações que exigem trocas frequentes e rápidas de pequenos pedaços de dados, em alta velocidade e volume.[123]

O Spring suporta o protocolo WebSocket fornecendo a API WebSocket para a aplicação reativa. A anotação @EnableWebSocket fornece funcionalidade de processamento de requisição WebSocket quando colocada em uma classe de configuração Spring. Uma interface obrigatória é o WebSocketConfigurer, que concede acesso ao WebSocketConfigurer. Em seguida, a URL do WebSocket é mapeada para os handlers relevantes implementando o método registerWebSocketHandlers(WebSocketHandlerRegistry).[124]

Spring WebFlux

editar

Spring WebFlux é um framework que segue o paradigma de programação funcional, projetado para construir aplicações Spring reativas. Este framework usa extensivamente programação funcional e Reactive Streams. Um bom caso de uso para Spring WebFlux é para aplicações que exigem o envio e recebimento de informações instantâneas, como uma aplicação web com capacidade de chat.[125]

Embora aplicações que usam a tecnologia Spring WebFlux sejam geralmente menos legíveis do que suas contrapartes MVC, elas são mais resilientes e mais simples de estender.[126] O Spring WebFlux reduz a necessidade de lidar com as complicações associadas à sincronização do acesso a threads.[126]

O Spring WebFlux suporta server-sent events (SSE), que é uma tecnologia de push do servidor que permite ao cliente obter atualizações automáticas de um servidor através de uma conexão HTTP. Esta comunicação é unidirecional e compartilha várias semelhanças com o modelo publish/subscribe encontrado no JMS.[123]

Relação com Jakarta Enterprise Beans (EJB)

editar

O contêiner pode se tornar um contêiner EJB (Enterprise JavaBeans) 3.0 parcialmente compatível por meio do projeto Pitchfork.[carece de fontes?] Alguns[quem?] criticam o Spring Framework por não estar em conformidade com os padrões.[127] No entanto, a SpringSource não vê a conformidade com EJB 3 como um objetivo principal e afirma que o Spring Framework e o contêiner permitem modelos de programação mais poderosos.[128]

Vulnerabilidade Spring4Shell

editar

Uma vulnerabilidade de execução remota de código afetando certas versões do Spring Framework foi publicada em abril de 2022 sob CVE-2022-22965. Recebeu o nome de Spring4Shell em referência à recente vulnerabilidade Log4Shell, ambas tendo provas de conceito semelhantes nas quais os atacantes poderiam, em máquinas vulneráveis, obter acesso ao shell[129] ou até mesmo controle total.[130]

Ver também

editar

Referências

editar
  1. a b c Deinum et al. 2014, p. 47, §2 Spring Core Tasks.
  2. «Spring Framework Overview». docs.spring.io. Cópia arquivada em 19 de maio de 2026 
  3. Deinum et al. 2014, p. 694-698, §16-2 Integrating Two Systems Using JMS.
  4. a b c d e f g h i j k l m n o p q r s t u v w x y z aa ab ac ad ae Johnson & Hoeller 2004.
  5. Deinum & Cosmina 2021, p. 1, §1 Setting up a Local Development Environment.
  6. «Spring Framework 1.0 Final Released». Blog oficial do Spring Framework. 24 de março de 2014. Consultado em 1 de março de 2021. Cópia arquivada em 6 de fevereiro de 2026 
  7. Jolt winners 2006
  8. «JAX Innovation Award Gewinner 2006». Consultado em 12 de agosto de 2009. Arquivado do original em 17 de agosto de 2009 
  9. «Spring Framework 3.2.5 Released». Site oficial do Spring. 7 de novembro de 2013. Consultado em 16 de outubro de 2016. Cópia arquivada em 21 de fevereiro de 2026 
  10. «Announcing Spring Framework 4.0 GA Release». Spring blog. 12 de dezembro de 2013. Cópia arquivada em 25 de fevereiro de 2026 
  11. Walls 2016, p. 92-106, §5.
  12. Cosmina et al. 2017, p. 125-126, §4 Spring Configuration in Detail and Spring Boot.
  13. Cosmina et al. 2017, p. 1-18, §1 Introducing Spring.
  14. «Spring Framework 4.2 goes GA». Spring Blog. 31 de julho de 2015 
  15. a b «Spring Framework 4.2 goes GA». Spring Blog 
  16. «Spring Framework Versions: Supported Versions». github.com. Cópia arquivada em 9 de março de 2026 
  17. «Reactive Spring». Spring Blog. 9 de fevereiro de 2016 
  18. «Spring Framework 6.0 goes GA». Spring Blog. 16 de novembro de 2022 
  19. Walls 2019, p. 48.
  20. Documentação do Spring Framework para o Contêiner Principal
  21. a b Johnson et al. 2005, Chapter §2 - The Bean Factory and ApplicationContext.
  22. Deinum et al. 2014, p. 137, §3-1 Using Java Config to configure POJOs.
  23. a b Johnson & Hoeller 2004, p. 150, Introducing the Spring Framework - The Core Bean Factory.
  24. a b c d e f g Deinum & Cosmina 2021, p. 22-25, §2 Spring Framework Fundamentals - The Spring Framework.
  25. Walls 2016, p. 240, §Appendix D Spring Boot dependencies.
  26. Johnson et al. 2005, Chapter §1 Introducing the Spring Framework - Module Summary.
  27. Johnson et al. 2005, Chapter §4 - Spring and AOP.
  28. Deinum et al. 2014, p. 196-198, §3-17 AOP introductions for POJOs.
  29. Johnson et al. 2005, Acegi Security System for Spring.
  30. Deinum et al. 2014, p. 331, §7 Spring Security.
  31. Walls 2019, pp. 56-59.
  32. a b c d e f Deinum et al. 2014, p. 419-426, §10 Data Access.
  33. Deinum et al. 2014, p. 677-681, §15-4 Create Message-Driven POJOs in Spring.
  34. Johnson et al. 2005, Chapter §12 - Web MVC Framework.
  35. a b c Deinum et al. 2014, p. 217, §4 Spring @MVC.
  36. Deinum et al. 2014, p. 525-534, §12-3 Writing a Custom ItemWriter and ItemReader.
  37. Deinum et al. 2014, p. 627-632, §14-7 Expose and Invoke Services through RMI; §14-8 Expose and Invoke Services through HTTP.
  38. Deinum et al. 2014, p. 641-658, §14-10 Introduction to contract first SOAP Web Services,§14-11 Expose and invoke SOAP Web Services with Spring-WS,§14-12 Develop SOAP Web Services with Spring-WS and XML Marshalling.
  39. Johnson et al. 2005, Chapter §8 - Lightweight Remoting.
  40. a b Johnson et al. 2005, Chapter §9 - Supporting Services.
  41. Deinum et al. 2014, p. 475, §11 Spring Transaction Management.
  42. Deinum et al. 2014, p. 591, §14 Spring Java Enterprise Services and Remoting Technologies.
  43. Deinum et al. 2014, p. 737-739, §17-3 Unit Testing Spring MVC Controllers.
  44. Deinum et al. 2014, p. 739-743, §17-4 Managing Application Contexts in Integration Tests.
  45. Musib 2022, p. 358, §8.3 Introducing Spring WebFlux.
  46. Cosmina et al. 2017, p. 21-23.
  47. Cosmina et al. 2017, p. 24-25, §2 Accessing Spring Modules Using Maven.
  48. Cosmina et al. 2017, p. 26, §2 Accessing Spring Modules Using Gradle.
  49. a b Deinum et al. 2014, p. 53-62, §2-2 Create POJOs by Invoking a Constructor.
  50. a b Deinum et al. 2014, p. 48-52, §2-1 Manage and Configure POJOs with the Spring IoC Container.
  51. Deinum et al. 2014, p. 59-67, §2-3 Use POJO References, Auto-Wiring, and Imports to Interact with Other POJOs.
  52. Deinum et al. 2014, p. 112-116, §2-16 Use Property Editors in Spring.
  53. a b Walls 2019, p. 4-6, §1.1 Getting started with Spring - What is Spring.
  54. Cosmina et al. 2017, p. 37, §3 Introducing IoC and DI in Spring.
  55. What is the difference between the depencylookup and dependency injection - Spring Forum. Forum.springsource.org (2009-10-28). Recuperado em 2013-11-24.
  56. Deinum & Cosmina 2021, p. 26-32, §2 Spring Framework Fundamentals - Dependency Injection.
  57. a b Johnson & Hoeller 2004, p. 135–137, §6 Lightweight Containers and Inversion of Control - IOC Containers.
  58. Deinum et al. 2014, p. 145-151, §3-3 Use POJO References and Auto-Wiring to Interact with other POJOs.
  59. a b c Cosmina et al. 2017, p. 112-120, §3 Introducing IoC and DI in Spring - Autowiring Your Beans.
  60. a b c Deinum et al. 2014, p. 151-154, §3-4 Auto-wire POJOs the @Resource and @Inject annotation.
  61. Deinum et al. 2014, p. 99-104, §2-12 Aspect Orientated Programming.
  62. a b c Deinum et al. 2014, p. 492-494, §11-6 Managing Transactions Declaratively with the @Transactional Annotation.
  63. Deinum et al. 2014, p. 509-510, §11-11 Managing Transactions with Load-Time Weaving.
  64. Spring AOP XML Configuration
  65. AspectJ Annotation Configuration
  66. Deinum et al. 2014, p. 441-446, §10-5 Handling Exceptions in the Spring JDBC Framework.
  67. Deinum et al. 2014, pp. 426-441,463-465.
  68. Hibernate VS Spring
  69. Deinum et al. 2014, p. 463-466, §10-8 Persisting Objects with Spring's ORM Templates.
  70. Deinum et al. 2014, p. 446-462, §10-6 Problems with Using ORM Frameworks Directly.
  71. «Spring Data JPA for Abstraction of Queries». 6 de fevereiro de 2018. Consultado em 6 de fevereiro de 2018. Cópia arquivada em 10 de março de 2022 
  72. a b Deinum et al. 2014, p. 456-460, §10-7 Configuring ORM Resource Factories in Spring.
  73. a b c d Deinum et al. 2014, p. 464-468, §11-2 Choosing a Transaction Manager Implementation.
  74. a b Deinum et al. 2014, p. 494-499, §11-7 Setting the Propagation Transaction Attribute.
  75. Deinum et al. 2014, p. 482-484, §11-2 Choosing a Transaction Manager Implementation.
  76. Deinum et al. 2014, p. 484-486, §11-3 Managing Transactions Programmatically with the Transaction Manager API.
  77. Deinum et al. 2014, p. 486-489, §11-4 Managing Transactions Programmatically with a Transaction Template.
  78. Deinum et al. 2014, p. 677-685, §15-4 Create Message-Driven POJOs in Spring.
  79. Deinum et al. 2014, p. 685-686, §15-5 Cache and pool JMS connections.
  80. «Introduction to the Spring Framework». Arquivado do original em 30 de junho de 2019 
  81. Johnson, Expert One-on-One J2EE Design and Development, Cap. 12, et al.
  82. Patterns of Enterprise Application Architecture: Front Controller
  83. a b c d e f g Deinum et al. 2014, p. 217-232, §4-1 Developing a Simple Web Application with Spring MVC.
  84. Deinum & Cosmina 2021, p. 82-83, §4 Spring MVC Architecture - The Request Processing Summary.
  85. Deinum et al. 2014, p. 217-219, §4-1 Developing a Simple Web Application with Spring MVC.
  86. Walls 2019, pp. 18-19.
  87. a b Deinum et al. 2014, p. 236-239, §4-3 Intercepting Requests with Handler Interceptors.
  88. Deinum et al. 2014, p. 239-240, §4-4 Resolving User Locales.
  89. Deinum & Cosmina 2021, p. 75-76, §4 Spring MVC Architecture - Prepare a request.
  90. a b Deinum et al. 2014, p. 243-247, §4-6 Resolving Views by Names.
  91. Deinum & Cosmina 2021, p. 81, §4 Spring MVC Architecture - Render a view.
  92. Deinum et al. 2014, p. 723, §17 Spring Testing.
  93. a b c Deinum & Cosmina 2021, p. 73-74, §4 Spring MVC Architecture - DispatcherServlet Request Processing Workflow.
  94. a b Walls 2019, p. 35.
  95. a b c d e f Deinum & Cosmina 2021, p. 84-90, §4 Spring MVC Architecture - Bootstrapping DispatcherServlet.
  96. a b c Deinum et al. 2014, p. 627-632, §14-7 Expose and Invoke Services through RMI.
  97. a b Deinum et al. 2014, p. 632-635, §14-8 Expose and Invoke Services through HTTP.
  98. Deinum et al. 2014, p. 692-694, §16-1 Integrating One System with Another Using EAI.
  99. a b Deinum et al. 2014, p. 635-641, §14-9 Expose and invoke SOAP Web Services with JAX-WS.
  100. a b Walls 2016, p. vii, §foreword.
  101. «Spring Boot». spring.io. Cópia arquivada em 2 de abril de 2022 
  102. Walls 2016, p. 48, §2.4.
  103. Deinum & Cosmina 2021, p. 21-22, §2 Spring Framework Fundamentals.
  104. Walls 2016, p. 37-48, §2.3.
  105. a b Walls 2016, p. 7, §1.1.3.
  106. a b Walls 2016, p. x, §Preface.
  107. Walls 2016, p. 4-5, §1.1.2.
  108. a b Walls 2016, p. 124-139, §7.
  109. Walls 2016, p. 49-69, §3.1-§3.2.3.
  110. «About Spring Boot». Consultado em 18 de março de 2020. Cópia arquivada em 19 de fevereiro de 2026 
  111. a b c Deinum et al. 2014, p. 536-541, §12-7 Controlling Step Execution.
  112. Deinum et al. 2014, p. 714-717, §16-9 Staging Events Using Spring Batch.
  113. a b c Deinum et al. 2014, p. 518-524, §12-2 Reading and Writing.
  114. Deinum et al. 2014, p. 511-512, §12 Spring Batch.
  115. Deinum et al. 2014, p. 713-714, §16-8 Conditional Routing with Routers.
  116. Deinum et al. 2014, p. 704-707, §16-5 Transforming a Message from One Type to Another.
  117. Deinum et al. 2014, p. 686-690, §15-6 Send and Receive AMQP Messages with Spring.
  118. Deinum et al. 2014, p. 613-620, §14-4 Send E-mail with Spring’s E-mail Support.
  119. Deinum et al. 2014, p. 406, §9-2 Using Spring in Your Servlets and Filters.
  120. Deinum et al. 2014, p. 695-698, §16-2 Integrating Two Systems Using JMS.
  121. Deinum et al. 2014, p. 717-722, §16-10 Using Gateways.
  122. a b Deinum et al. 2014, p. 710-713, §16-7 Forking Integration Control: Splitters and Aggregators.
  123. a b c d Deinum & Cosmina 2021, p. 422-425, §11 The WebSocket Protocol.
  124. Deinum & Cosmina 2021, p. 425-432, §11 The WebSocket Protocol.
  125. Deinum & Cosmina 2021, p. 369, §10 Building Reactive Applications with Spring WebFlux.
  126. a b Deinum & Cosmina 2021, p. 421, §11 Securing Spring WebFlux Applications.
  127. Spring VS EJB3
  128. «Pitchfork FAQ». Consultado em 6 de junho de 2006. Cópia arquivada em 15 de maio de 2008 
  129. «Spring4Shell: critical vulnerability in Spring - Kaspersky official blog». Abril de 2022 
  130. Chirgwin, Richard (4 de abril de 2022). «VMware sprung by Spring4shell vulnerability». itnews.com.au. Consultado em 13 de fevereiro de 2024. Cópia arquivada em 13 de fevereiro de 2024 

Bibliografia

editar

Ligações externas

editar
O Wikilivro Java Programming tem uma página intitulada Spring framework