A OSGi Alliance disponibilizou uma versão inicial (early draft) da especificação para a próxima versão da plataforma OSGi. Sendo um esboço, as definições da especificação podem ser alteradas e alguns itens excluídos ou trocados até a versão final. O documento engloba especificações para:
- RFC 112 - OBR (Oscar Bundle Repository)
- RFC 152 - Subsistemas
- RFC 167 - Suporte a Service Loader
- RFC 169 - Atualização do JMX
- RFC 172 - Anotações de Serviços Declarativos
- RFC 174 - Bundle Collision Hook
- RFC 175 - Atualização em Versionamento (snapshot)
- RFC 176 - Serviços Declarativos 1.2
OBR
Um problema comum na implantação de sistemas é a obtenção de pacotes (bundles) para instalação dentro de um sistema OSGi, o que atualmente pode ser feito com o mvn: protocol através do download de um repositório remoto ou usando protocolos personalizados, como o P2 do Eclipse. Antes de existirem essas funcionalidades do Maven e do Eclipse, já existia o Oscar Bundle Repository, ou OBR.
Oscar era o nome do runtime do OSGi, antes de ser renomeado para Apache Felix. Ele provê um arquivo XML que contém informações do repositório, por exemplo com informações sobre quais conjuntos de pacotes contêm determinado pacote. Isso permite que um "resolver" determine o que deve ser recuperado para tornar uma certa funcionalidade disponível.
O OBR tem sido pouco usado, provavelmente porque nunca foi formalmente especificado. Assim algumas diferenças podem ocorrer, dependendo da versão da especificação do OBR usada. A RFC do OBR visa resolver esses problemas provendo uma descrição definitiva para o formato do repositório. Desse modo todos os runtimes OSGi poderão finalmente falar a mesma língua para a obtenção de pacotes.
Subsistemas
Embora o OSGi trabalhe no nível de pacote (e de serviço), permitindo a instalação de grupos de pacotes (o que é mais conveniente do que listar dependências individualmente), a especificação de subsistemas visa padronizar os conceitos de features e applications, permitindo que grupos de pacotes sejam referenciados e instalados como uma única unidade, de forma similar a arquivos WAR. Diferentes runtimes de OSGi (tais como Eclipse P2 e Apache Karaf) usam maneiras distintas de se referir a esses conceitos. Como resultado, não é possível instalar uma feature P2 dentro do Apache Karaf e vice-versa. Havendo uma representação padronizada, será possível trocar um conjunto de features compatíveis entre os dois tipos de repositórios.
Porém, existem algumas preocupações com a especificação atual de subsistemas. Nela, são definidos novos conceitos implícitos nas suas unidades de download. Assim uma feature tem de permanecer um elemento possível de ser baixada (de maneira similar às features do Eclipse hoje), ao invés de serem usadas capacidades/requisitos, para adicionar o conceito de feature dentro de um pacote isolado existente.
Suporte a Service Loader
O carregador de serviços (Service Loader) em Java é pouco modular e pode causar problemas para aplicações que o utilizam para a obtenção de serviços (tal como um parser de XML). Habilitando-se o suporte ao Service Loader em aplicações legadas, ganha-se um mecanismo para o registro e a obtenção de serviços.
Embora o mecanismo seja menos poderoso que fazer a resolução dos serviços OSGi diretamente, ele permite que o código legado, que continua sendo usado da maneira antiga, participe dos mecanismos de serviços OSGi e seja controlado por eles.
Como o Service Loader é definido como final em Java, a única maneira de fazê-lo funcionar é através da reescrita no momento do carregamento, para redirecionar chamadas do Service Loader. Desse mode, obtém-se uma solução mais integrada com o mecanismo de carregamento de classes do Java.
Atualização do JMX
O early-draft do OSGi atualiza o processamento de JMX em sintonia com novos recursos disponíveis na versão 4.3 do framework, tais como bundle wirings, propriedades e o uso de tipos genéricos onde for aplicável.
Declarative Services Annotations
Esse padrão define anotações padronizadas que podem ser usadas no código Java, como @Component e @Reference. Embora anotações como estas possam ser usadas no BND, a presença de anotações padrão suportadas no OSGi permitirá que outras ferramentas sejam capazes de utilizá-las.
Colisões entre bundles
Este recurso pode ser utilizado em situações que existam múltiplos pacotes com o mesmo nome simbólico e versão. Se o framework suporta a filtragem de recursos, é possível instalar o mesmo pacote nomeado duas vezes, em contextos diferentes. Para determinar se operação é correta, o recurso de bundle collisions pode ser usado para determinar se uma abordagem é válida ou não.
Versioning Update
Uma das maiores diferenças entre o versionamento do OSGi e o do Maven é a importância dada à versão não-qualificada (ex.: 1.2.3). No Maven, este é o maior valor possível, enquanto no OSGi é o menor valor. Abordagens que usam -SNAPSHOT no Maven (ou .qualifier no Eclipse) são trocadas por um timestamp dinâmico, com a expectativa de que a versão -SNAPSHOT seja sempre menor que a versão não-qualificada. Vários mecanismos têm sido criados para trabalhar entre os dois modelos, incluindo versões par/impar (para produção/desenvolvimento), sempre usando uma versão qualificada, ou identificadores embutidos no código, por exemplo RELEASE, para agir como versão principal.
Na atual versão da especificação, é permitido que duas faixas distintas sejam fornecidas: pre-release a release. Tal como acontece com as faixas release, as faixas pre-release são ordenadas lexicograficamente. Esta mudança é compatível com versões existentes.
Serviços Declarativos 1.2
A definição de serviços declarativos introduz uma opção "greedy" para o consumo de serviços. Se um novo serviço for fornecido com maior prioridade, então é considerada a troca da implementação usada por outra de maior prioridade.
Resumo
As especificações OSGi são geralmente bem pensadas e estas RFCs não fogem do padrão. Aqui foi apresentado um panorama do que já foi definido e pode ser incorporado no futuro.
Ao invés de tentar mudar o mundo, as especificações OSGi exibem a mesma modularidade encorajada pela plataforma. Ao tratar de questões específicas, como problemas do Service Loader causados por códigos não preparados para o uso de carregadores de classes, a novo padrão permite que sistemas existentes sejam atualizados para tirar proveito de novas funcionalidades da plataforma OSGi.
Uma das menores mudanças, mas talvez a mais impactante, será a habilidade de trabalhar com faixas de pre-releases. Isto vai permitir que os mundos Maven e OSGi se aproximem, sem a necessidade de usar tokens conhecidos para garantir que a ordem de dependências está correta.