Um ano após receber um investimento de 10 milhões em capital de risco, a SpringSource (empresa por trás do framework Spring) tornou-se hoje um fornecedor de servidores, desafiando o mercado de Servidores Java EE já estabelecido com o SpringSource Application Platform (nota do editor - Bor Harrop, da SpringSource, divulgou mais informações técnicas em seu blog), um servidor de aplicação escrito em Sprint, OSGi e Apache Tomcat. O novo servidor de aplicação distancia-se dos padrões Java EE, expondo o modelo de programação Spring nativamente, além de um novo sistema de implantação e empacotamento, escrito sobre um núcleo OSGi. Foi disponibilizado o beta release sob a licença SpringSource Evaluation. A versão oficial será lançada em versões licenciadas e open source (sob GLPv3) em um mês.
A Plataforma SpringSource não é um servidor de aplicações Java EE. Mesmo suportando deploy de WARs, a implantação de EAR não é suportada, assim como outras especificações EE como o EJB. A Plataforma SpringSource foi concebida do zero com o foco concreto em suportar o vasto portfólio de aplicações em código aberto que utilizam o Spring. Mais especificamente, o servidor de aplicação foi construído no modelo de desenvolvimento do Portifólio Spring pensando nos Módulos Dinâmicos Spring para implantações baseadas em OSGi. SpringSource criou um "kernel" para logging, tracing, bootstrap, classloading, gerenciamento e outras funcionalidades sobre o ambiente de execução Equinox OSGi, da Fundação Eclipse. O Tomcat é incluso como um pacote OSGi para suportar funcionalidades web.
InfoQ falou com o co-fundador do framework Spring e CEO da SpringSource, Rod Johnson, para discutir sobre o novo servidor de aplicação. Explicando as necessidades para a nova plataforma, Rod indica algumas complicações com os ambientes de desenvolvimento/produção atuais, tais como a duplicação de metadados através de arquivos de configuração, o fato de que é comum em projetos construírem em essência um servidor sobre outro servidor (implantando suas aplicações juntamente com inúmeras ferramentas e frameworks numa mesma unidade). Entretanto, está se usando apenas uma porção do servidor de aplicação: o contêiner web. SpringSource quis fornecer, como resposta, uma plataforma mais simples para as necessidades atuais de desenvolvimento.
Sobre os benefícios do novo servidor de aplicações, Johnson enfatiza a modularidade: tanto para o servidor em si como para o modelo de empacotamento e implantação oferecido aos desenvolvedores. Potencializando OSGi e a natureza inter funcional das dependências através dos pacotes OSGi, um servidor de aplicação em execução possui apenas as funcionalidades necessárias para as aplicações que estiverem rodando, reduzindo logs e o tempo de startup. Este suporte a dependências ainda permite múltiplas versões de uma biblioteca coexistam para diferentes aplicações. Partes do servidor de aplicações podem ser facilmente atualizadas e reiniciadas sem reiniciar todo o sistema. No ponto de vista do desenvolvimento, a modularidade do servidor permite reimplantações extremamente granularizadas para serem rapidamente desempenhadas conforme o código muda.
Sobre OSGi e a utilização do Eclipse Equinox OSGi pela SpringSource, Johnson elogiou a base que a especificação OSGi e o ambiente de execução oferecem, mas observou que a OSGi pode ser um pouco baixo nível demais para o uso diário no desenvolvimento de aplicações. Johnson explicou que a SpringSource pretende permitir que os desenvolvedores facilmente agreguem valor com OSGi num contexto corporativo. O novo servidor de aplicação abstrai muito da complexidade da OSGi atrás da construção de um novo modelo de programação. Ele mencionou que o servidor de aplicações suportará uma nova unidade de instalação PAR, simplificando o uso do OSGi para aplicações corporativas. (mais informações abaixo)
Questionado sobre o suporte a bibliotecas legadas que nativamente não suportam OSGi, Johnson respondeu que foi realizado um trabalho significativo, para que o ambiente do servidor de aplicação e o classloading pudessem se comportar de maneira compatível a bibliotecas legadas. SpringSource também voltará a submeter patches a projetos como o Tomcat para quaisquer alterações que tenham sido feitas a fim de permitir a compatibilidade de uma biblioteca ao pacote OSGi.
Johnson explicou que a maior parte do código do servidor de aplicação seria disponibilizado sob licença GPLv3. Tudo que um programador tiver que se submeter em termos do servidor, programação e unidade de implantação será disponibilizado em formato código aberto. A SpringSource fornecerá uma versão comercial do servidor de aplicações que incluirá suporte, indenização, gestão e monitoramento de capacidades.
Sobre Java EE e de que forma o anúncio do Spring Application Plataform poderia afetar a continuidade do suporte a Java EE pelo Spring Portifolio, Johnson respondeu:
...O que nós fundamentalmente estamos tentando fazer é NÃO empurrar a comunidade de usuários Spring em alguma direção. Nós estamos apenas dando a eles esta chance. A filosofia Spring é a de que o usuário está sempre certo. Eles são espertos o suficiente para descobrir o que desejam. Não importando se eles farão qualquer escolha, acreditamos que eles ficarão gratos por possuírem a opção de considerar...
Johnson afirmou que SpringSource está comprometida em garantir que o Portfólio Spring e outros produtos da SpringSource sejam compatíveis com outras plataformas de aplicação. Johnson então comentou sobre a próxima especificação Java EE 6:
Java EE 6 é a respeito de modularidade e está guiando [Java EE] na direção certa. É bem provável que o SpringSource Application Server se tornará compatível com Java EE 6 de alguma forma. Existem três tipos de perfis: A, B e C. Eu posso dizer com confiança que nós não implementaremos o modelo 1.1 de Entity Beans, ou uma série de tecnologias legadas que constituem a opção 'C'. É extremamente provável que nós iremos implementar os perfis A e B. Eu não posso dizer isto com 100% de certeza porque as especificações não estão finalizadas.
Por último, InfoQ e Johnson falaram a respeito da visão da SpringSource Application Plataform. Em termos da mudança para o OSGi ele comentou:
O modelo tradicional de servidor de aplicações está se tornando obsoleto. BEA e a IBM estão refazendo seus servidores de aplicação incrementalmente utilizando OSGi. SpringSource está fornecendo suporte a OSGi neste momento. Você olha para o os números, e a maioria das pessoas não implantam uma aplicação em um super ultra servidor. Eles fazem num Tomcat. Eles escrevem código mais para o modelo de desenvolvimento Spring do que Java EE. O mercado já fez a sua escolha, a questão é por quanto tempo desenvolvedores precisarão lutar contra seus servidores.
- É o primeiro produto que possui tecnologia moderna sobre sua base. Compatibilidade Java EE não é mais uma necessidade primordial. Nós temos uma vantagem competitiva, porque temos uma base de código limpa e nova. Nós projetamos e entregamos para atender os requisitos de hoje, e não aqueles dos últimos 10 anos.
- Programação POJO é onde a indústria está. No passado, programação POJO foi enxertada em outros produtos chutando e gritando. No nosso caso, programação POJO é o modelo assumido que nós construímos.
- A tecnologia OSGi utilizada é fundamental para a próxima geração tecnológica.
Junto com Rod Johnson, a InfoQ também se encontrou com Rob Harrop da SpringSource, para alguns detalhes técnicos do novo servidor de aplicações. Em termos do que está dentro ou fora do contexto, comparado aos Application Servers Java EE tradicionais. Ele comentou:
...JPA e JMS são ambos suportados, mas não incluímos nenhuma implementação particular. No caso do JPA, nós suportamos Hibernate, OpenJPA e Toplink. Nós adicionamos o suporte a Load-Time Weaving no ambiente OSGi que honra os limites entre as aplicações e não polui acidentalmente bibliotecas compartilhadas. JNDI não está incluído, o Serviço de Registros OSGi é utilizado em preferência. Servlets são suportados através do Tomcat embutido. Tem algumas coisas em JEE que não serão inclusas no SpringSource Application Plataform, como os Entity Beans.
Depois disso, InfoQ perguntou sobre Spring Dynamic Modules. Spring-DM tem sido um projeto público há algum tempo. Partindo de uma visão de implantação modular, Harrop foi questionado se alguma coisa foi adicionada ao Spring-DM:
A plataforma introduz a noção de aplicações, formada por um ou mais bundles. Tais pacotes nestas aplicações são explicitamente determinados para evitar que aplicações colidam entre si. Isto é particularmente importante quando você tem aplicações que começam a publicar serviços no serviço de registros OSGi - você não vai querer tais serviços conflitando uns com os outros.A Introdução do Import-Library tornou-se muito mais fácil o uso de bibliotecas de terceiros em suas aplicações. Ao invés de ter um monte de declarações Import-Package, alguns dos quais poderão não ser totalmente intuitivos, você poderá usar Import-Library para puxar em todos os pacotes necessários para uma biblioteca lógica. Bibliotecas como Hibernate JPA também podem abranger vários pacotes, então utilizar Import-Library realmente faz a diferença.
Em termos de expandir a Spring DM para suportar execução direto na Plataforma, muito pouco foi adicionado à base de código.
Harrop descreveu o novo formato PAR:
Pacotes criados por Spring DM' são pacotes OSGi normais que incluem arquivos META-INF/spring/*.xml que são automaticamente transformados em um ApplicationContext para estes pacotes quando ele inicia. Spring DM provê um mecanismo para que diferentes pacotes importem e exportem serviços utilizando o Spring NamespaceHandler.Um PAR (Plataform ARchive) é essencialmente uma coleção de pacotes OSGi, alguns dos quais serão criados por Spring DM. Juntos, estes pacotes formam uma aplicação lógica. A programação é simplesmente OSGi puro, Spring e Spring DM - o PAR não modifica isso.
Sobre como as equipes utilizariam bibliotecas legadas/não-OSGi em comparação às técnicas que tem sido tipicamente utilizadas no passado como Buddy Classloaders, Rob respondeu:
É mais fácil dizer o que evitamos fazer. Buddy class loading, importação dinâmica e require-bundle são todos explicitamente evitados devido à dificuldade em se manter um espaço consistente entre classes. Nós também evitamos fornecer qualquer mecanismo proprietário alternativo.Em vez disso, nós adicionamos alguns ganchos de baixo nível no Equinox para tornar o trabalhado de carregamento de recursos em casos típicos, nós ampliamos o class loading para suportar load-time weaving e eliminar o carregamento semântico além de trabalharmos o classloader de contexto para permitir que terceiros vejam as classes como esperado. O PAR é a parte central disso, uma vez que ele define o escopo de visibilidade para o carregamente de classes por contexto e load-time weaving.
No pior dos casos, nós criamos versões diferentes das bibliotecas para fazê-las trabalharem no OSGi, e estamos disponibilizando através do SprintSource Enterprise Bundle Repository da mesma forma que submetemos todos os patches de volta aos projetos relevantes.
Finalmente, Harrop elucidou os benefícios da modularidade do servidor de aplicações revelando que ela permite ao próprio servidor de manter apenas um mínimo de recursos. A plataforma provê dependências em tempo de execução. Assim, uma instância somente possui instalado exatamente o que precisa.
Nos últimos dois anos houveram muitas discussões sobre se o padrão JavaEE está morto. Hoje vimos o lançamento do que pode potencialmente ser o próximo grande AppServer, sem suporte à JavaEE. Como você enxerga isto modificando nosso ambiente daqui para frente?