Projeto Eclipse Virgo Aprovado

Hoje o dm Server fornece o estado da arte em plataforma de servidores para aplicações empresariais modulares com desenvolvimento baseado em OSGi e o modelo de programação Spring Dynamic Modules (agora padronizado como OSGi Blueprint Service). O Enterprise OSGi e o dm Server fizeram enormes avanços. E, no entanto, é justo dizer que a adoção do OSGi para o desenvolvimento de aplicações empresariais não vem sem um custo. Como muitas novas tecnologias, um investimento inicial deve ser feito e que será pago ao longo do tempo. Hal Hildebrand, vendo essa situação, postou recentemente em seu blog sobre o OSGi Value Proposition.

 

Há um grande interesse em torno do Enterprise OSGi e do dm Server. Este interesse é mais forte entre os pioneiros, e os projetos com os requisitos que correspondem de perto a natureza dinamicamente modular do OSGi Service Platform. Para uma equipe de desenvolvimento de mainstream, que só quer construir um aplicativo empresarial o mais rápido possível, e com tão pouco incomodo quanto possível, os custos associados à adoção ao OSGi Corporativo podem superar os benefícios de curto prazo. Esta situação tem de ser resolvida antes do Enterprise OSGi poder tornar-se de fato a abordagem de desenvolvimento de aplicações corporativas mainstream. Por favor, note que eu estou falando sobre o desenvolvimento de aplicações empresariais aqui, se você está escrevendo software de infra-estrutura e a necessidade de criar um "stackless stack" (Kirk Knoerschild, James Governor), então o OSGi já é a abordagem de fato, e totalmente suportado pelo dm Server e associado ao sub-projeto dm-kernel.

A complexidade dos softwares está crescendo exponenciamente. Você sabia que:

• em 1990, havia 120 bilhões de linhas de código
• em 2000, havia 250 bilhões de linhas de código
• O número de linhas de código dobrou em 7 anos
• 50% do tempo de desenvolvimento é gasto para entender o código
• 90% do custo do software é manutenção e evolução

Vamos colocar isso em perspectiva para entender o significado nos próximos 7 anos. Entre 2010 e 2017, nós produziremos mais código que o montante já escrito.

 

Soma-se tudo isso, e veremos os pontos chaves. Nós precisamos de uma solução que ajude-nos a entender sistemas complexos. Nós precisamos de uma solução que ajude-nos a gerenciar a complexidade. Nós precisamos de uma solução que ajude-nos a deixar mais fácil a manutenção. Nós precisamos de uma solução que ajude-nos a entender a evolução natural dos softwares. Nós precisamos de uma solução que nos permita negociar com o mudança natural da arquitetura que ocorre quando um sistema cresce para acomodar a demanda. Por muito tempo, o principal ingrediente tem faltado. Mas não por muito tempo, porque a empresa conseguirá o OSGi!