Como estamos chegando a um ponto chave com o projeto OSGI Distribuído, me parece que é uma boa hora para revisar o que já foi feito até o momento, para identificar os passos restantes e falar sobre o por que estamos fazendo isto em primeiro lugar.
Em Novembro nós publicamos um update para os drafts que lançamos previamente dos documentos de design (Requisições para Comentários ou RFCs em uma terminologia OSGI) para o próximo release 4.2 da Especificação OSGI. Neste mês nós lançamos no Apache CXF o código fonte da implementação de referência para um dos novos designs importantes para este release, RFC 119, OSGI Distribuído.
O projeto OSGI Distribuído foi iniciado como parte do próximo release da Especificação OSGI por conta do release atual da Especificação OSGI ter tido sucesso no ambiente embedded, e foi concebido para ser adotado no âmbito corporativo. Por exemplo, o framework OSGI está por trás dos plugins do Eclipse e de todos os servidores de aplicação, e a maioria dos fornecedores de ESBs tem adotado OSGI também.
A OSGI Alliance patrocinou um workshop público em Setembro de 2006 para levantar futuros requisitos para uma possível edição corporativa (Peter Kriens escreveu em seu blog uma resenha excelente sobre o evento). A release atual da Especificação OSGI tem se tornado desde então parte do Java SE, inclusa pela JSR 291, e a questão levantada por nós que atendemos ao workshop foi quando é que a Especificação OSGI deveria se tornar uma alternativa viável para o Java EE, se sim, quais os requisitos que ela deveria atender. Um dos requisitos chaves é a habilidade dos serviços OSGI de invocar serviços que estejam rodando
O trabalho iniciou formalmente em Janeiro de 2007 com a primeira reunião do Expert Group Corporativo. OSGI Distribuído se manteve entre os tópicos principais discutidos na sessão. A principio nós recebemos muitas criticas dizendo que estávamos “reinventando a roda”, “criando um outro CORBA”, mas tudo isto é baseado em um mal entendido. O draft prévio do documento de design (RFC 119) e o código RI no Apache CXF deveria ajudar a esclarecer o fato de que não estávamos fazendo isto. Nós estamos simplesmente estendendo o framework OSGI para configurar os sistemas de software computacionais distribuídos existentes. Nós usamos o termo “software distribuído” ou DSW na RFC 119 como uma referência genérica para qualquer tipo de protocolo e sistema de formato de dados capaz de invocar serviços remotos. Remoto significa
Algumas pessoas sugeriram que escolhêssemos um tipo particular de software distribuído e padronizá-lo. Uma vantagem poderia ser a capacidade de explorar capacidades especificas de um protocolo, como código executável serializável, mais isto poderia reduzir chances de escolha e criar um lock em potencial em dada situação. Ao invés disso, nós definimos um mecanismo de configuração geral que poderia ser utilizado em qualquer software distribuído.
Em adição a implementação de referência do Apache CXF, o projeto Eclipse ECF e o produto Infinflow da Paremus almejam implementar este design, e temos ouvido algumas pessoas dizerem que o projeto Eclipse Riena esta também considerando implementa-lo. Então, acho que estamos no caminho correto com o OSGI Distribuído. Mas nós continuamos muito interessados em feedbacks, e ainda a tempo para mudar o que atualmente esta em vigor na especificação. O design do OSGI Distribuído também inclui service discovery e uma extensão dos metadados SCA para configuração de múltiplos componentes de sistemas de software distribuído. Nenhum destes itens estão disponíveis ainda para o publico, mas em breve estarão.
Para explicar onde estamos no processo, é melhor darmos um overview de como a OSGI Alliance trabalha. O processo é muito similar ao do Java Community Process. Na verdade, a especificação OSGI iniciou com a JSR 8, e basicamente continua representando uma evolução do esforço da JSR original. O processo OSGI iniciou com documentos RFPs (Request for Proposal) que detalham estes requisitos. Uma vez que a RFP é aprovada, uma ou mais Requisições para Comentários (RFCs) são criados com designs que atendem estes requisitos. Após a RFC ser aprovada, as especificações são alteradas para incluir o design. As RFPs e as RFCs são ambos produtos dos experts groups, entretanto, eles tendem a ser direcionados para indivíduos ou pequenos times em um grupo.
Quando falamos sobre a parte da especificação do processo, entretanto, a OSGI Alliance é única porque ela paga Peter Kriens para escrevê-la. E isto é muito bom, porque Peter tem participado do esforço da OSGI desde o inicio, e ele assegura a qualidade e consistência da especificação. Mas isto remove também um típico problema político que outros consórcios enfrentam quando eles “passam a caneta” para um mais membros (tipicamente representantes de fornecedores que competem com um ou mais membros).
A versão atual da implementação de referência foi feita para provar o design descrito na RFC 119, e para permitir que a RFC passasse por uma votação EG. Na fase de especificação nós esperamos discussões sobre o design conforme ele é incorporado na especificação, o que pode resultar em mudanças futuras para a RI.
Os experts groups da OSGI estão agora começando a trabalhar com Peter na alteração da especificação para a R4.2, que esta agendada para publicação de forma preliminar em Março ou Abril, e a forma final
As outras partes maiores da próxima release inclui várias extensões para o núcleo do framework, o modelo de componentes dos Serviços Blueprint derivados do Spring para desenvolvimento de serviços OSGi, e vários bits de Java EE mapeados para bundles OSGi (JTA, JDBC, JPA, JNDI, JMX, JAAS, e Aplicações Web). O mapeamento Java EE não está tão longe de se implementar quanto as melhorias no núcleo, o Spring/Blueprint, ou o trabalho com OSGI Distribuído, mas uma prévia é esperado que seja publicada em conjunto com o release final R4.2.
Os últimos dois anos tem resultado na documentação dos requisitos e design do OSGI Distribuído no draft do release prévio e ilustrado no código de implementação de referência no Apache CXF. Este último é uma das novas funcionalidades significantes do próximo release da especificação OSGI R4.2 corporativo, por volta do meio de 2009. Junto com as extensões para o núcleo do framework OSGI, o modelo de componentes dos Serviços Blueprint derivados do Spring, e o mapeamento das tecnologias chave do Java EE, o próximo release representa um passo maior rumo a especificação OSGI e a comunidade.