Com o anúncio recente do GlassFish v3 “Prelude”, o servidor Java EE 6 baseado em OSGi da Sun, o uso do OSGi alcançou quase todos servidores de backend. Um boletim de imprensa publicado recentemente pela OSGi alliance listou os fornecedores e tecnologias que usam OSGi:
- IBM's WebSphere
- Oracle's Weblogic
- Paramus' Infiniflow Service Fabric
- ProSyst's ModuleFusion
- Red Hat's JBoss
- SpringSource's SpringSource Application Platform
- Sun Microsystem's GlassFish Enterprise Server
Peter Kriens afirmou que o servidor Jonas, possivelmente foi o primeiro servidor JEE baseado em OSGi, mas não foi mencionado nesta lista porque não é membro da OSGi Alliance. Ele também citou que o SAP NetWeaver também migrará para OSGi.
Como previamente publicado pela InfoQ, a principal razão destes sistemas estarem migrando para o OSGi é de permitir a maior modularidade. Isto permite a um sistema ser decomposto em unidades mais gerenciáveis (e testáveis), e ao mesmo tempo fornecendo maior reusabilidade das bibliotecas componentes. No momento, as grandes empresas (IBM, Oracle) estão usando o OSGi internamente e não expondo diretamente aos usuários, mas outros (SpringSource) estão construindo de forma que seus proprios containers estão abertos à extensão, e não apenas as aplicações.
Projetos construidos com Maven também estão componentizados de forma similar, levando alguns a questionar o que o OSGi acrescenta em termos de modularidade. Existem 2 diferenças fundamentais entre as modulares do Maven e do OSGi em tempo de execução:
- As dependências do Maven são artefatos específicos; OSGi pode importar pacotes Java de artefatos arbritários descobertos em tempo de execução
- A natureza de build-time do Maven build-time significa que não há implicações no comportamento dinâmico de tempo de execução.
Servidores de Aplicações como SpringSource's DM Server aproveitam-se da natureza dinâmica do OSGi quando fazendo deploy de Spring Beans dentro de um container OSGi, permitindo que os serviços sejam parados e reiniciados em tempo de execução. A estrutura dinâmica do módudlo Spring encarrega-se do relacionamento e do tempo de execução automaticamente de forma transparente.
Projetos Open Source também estão migrando para o OSGi. Estimulados pelo servidor OSGi Apache Felix , outros projetos da Apache estão gerando metadados OSGi em seus builds, ou, pelo menos migrando completamente, como o Apache Tuscany, que migrou recentemente. Para aqueles projetos open source que não criam metadados em seus códigos, há um grande número de repositórios de pacotes OSGi (SpringSource Enterprise Bundle Repository, OBR, Eclipse Orbit, Felix bundle repository etc.) para fornecer Jars open source anotados com metadados OSGi.
Em conseqüência do crescimento do OSGi, tanto sistemas web quanto sistemas de backend estão sendo construidos diretamente em OSGi. O uso que o Linked In faz de OSGi foi discutido em seu blog de engenharia, e uma cópia da apresentação da Reunião de Software de Colorado 2008 está disponivel. É possivel até mesmo executar os serviços OSGi no Amazon EC2 e até no iPhone.
Se diretamente ou indiretamente, a possibilidade de usar OSGi em aplicações corporativas está crescendo bastante. Com o framework Spring tornando-se uma espécie de padrão popular para o desenvolvimento de aplicações e os benefícios do servidor Spring DM, construir aplicações dinâmicas e modulares, ficou do jeito que a indústria gosta.