Eu li na Wikipedia e em outros sites sobre o OSGi , mas não vejo o quadro geral. Ele diz que é uma plataforma baseada em componentes e que você pode recarregar módulos em tempo de execução. Além disso, o "exemplo prático" dado em todos os lugares é o Eclipse Plugin Framework.

Minhas perguntas são:

1. Qual é a definição clara e simples de OSGi?

2. Que problemas comuns ele resolve?

Por "problemas comuns", quero dizer problemas que enfrentamos todos os dias, como "O que a OSGi pode fazer para tornar nosso trabalho mais eficiente / divertido / simples?"

Quais benefícios o sistema de componentes da OSGi oferece?
Bem, aqui está uma lista bastante:

Complexidade reduzida - Desenvolver com a tecnologia OSGi significa desenvolver pacotes: os componentes OSGi. Pacotes são módulos. Eles ocultam seus internos de outros pacotes e se comunicam através de serviços bem definidos. Ocultar internos significa mais liberdade para mudar mais tarde. Isso não apenas reduz o número de bugs, mas também torna o desenvolvimento de pacotes mais simples, porque pacotes de tamanho correto implementam uma parte da funcionalidade por meio de interfaces bem definidas. Existe um blog interessante que descreve o que a tecnologia OSGi fez pelo processo de desenvolvimento.

Reutilização - O modelo de componente OSGi facilita muito o uso de muitos componentes de terceiros em um aplicativo. Um número crescente de projetos de código aberto fornece seus JARs prontos para OSGi. No entanto, as bibliotecas comerciais também estão se tornando disponíveis como pacotes prontos.

Mundo real -A estrutura OSGi é dinâmica. Ele pode atualizar pacotes rapidamente e os serviços podem ir e vir. Os desenvolvedores acostumados a Java mais tradicional vêem isso como um recurso muito problemático e não conseguem ver a vantagem. No entanto, verifica-se que o mundo real é altamente dinâmico e ter serviços dinâmicos que podem ir e vir tornam os serviços uma combinação perfeita para muitos cenários do mundo real. Por exemplo, um serviço pode modelar um dispositivo na rede. Se o dispositivo for detectado, o serviço será registrado. Se o dispositivo desaparecer, o serviço não será registrado. Há um número surpreendente de cenários do mundo real que correspondem a esse modelo de serviço dinâmico. Portanto, os aplicativos podem reutilizar as poderosas primitivas do registro de serviço (registrar, obter, listar com uma linguagem de filtro expressiva e aguardar a exibição e desaparecimento de serviços) em seu próprio domínio. Isso não apenas salva o código de gravação, mas também fornece visibilidade global, ferramentas de depuração e mais funcionalidade do que seria implementado para uma solução dedicada. Escrever código em um ambiente tão dinâmico parece um pesadelo, mas, felizmente, existem classes e estruturas de suporte que tiram a maior parte, se não toda a dor.

Fácil implantação - A tecnologia OSGi não é apenas um padrão para componentes. Também especifica como os componentes são instalados e gerenciados. Essa API foi usada por muitos pacotes configuráveis ​​para fornecer um agente de gerenciamento. Esse agente de gerenciamento pode ser tão simples quanto um shell de comando, um driver de protocolo de gerenciamento TR-69, driver de protocolo OMA DM, uma interface de computação em nuvem para o EC2 da Amazon ou um sistema de gerenciamento IBM Tivoli. A API de gerenciamento padronizado facilita muito a integração da tecnologia OSGi em sistemas existentes e futuros.

Atualizações dinâmicas - O modelo de componente OSGi é um modelo dinâmico. Os pacotes podem ser instalados, iniciados, parados, atualizados e desinstalados sem desativar o sistema inteiro. Muitos desenvolvedores de Java não acreditam que isso possa ser feito com segurança e, portanto, inicialmente não o usam na produção. No entanto, depois de usá-lo no desenvolvimento por algum tempo, a maioria começa a perceber que ele realmente funciona e reduz significativamente os tempos de implantação.

Adaptável - O modelo de componente OSGi é projetado desde o início para permitir a mistura e combinação de componentes. Isso requer que as dependências dos componentes precisem ser especificadas e requer que os componentes vivam em um ambiente onde suas dependências opcionais nem sempre estão disponíveis. O registro de serviço OSGi é um registro dinâmico em que os pacotes configuráveis ​​podem registrar, obter e ouvir serviços. Esse modelo de serviço dinâmico permite que os pacotes configuráveis ​​descubram quais recursos estão disponíveis no sistema e adaptem a funcionalidade que eles podem fornecer. Isso torna o código mais flexível e resistente às alterações.

Transparência - Pacotes e serviços são cidadãos de primeira classe no ambiente OSGi. A API de gerenciamento fornece acesso ao estado interno de um pacote configurável, bem como como ele está conectado a outros pacotes configuráveis. Por exemplo, a maioria das estruturas fornece um shell de comando que mostra esse estado interno. Partes dos aplicativos podem ser interrompidas para depurar um determinado problema, ou pacotes de diagnóstico podem ser trazidos. Em vez de observar milhões de linhas de saída de log e longos tempos de reinicialização, os aplicativos OSGi geralmente podem ser depurados com um shell de comando ativo.

Controle de versão - a tecnologia OSGi resolve o inferno dos JAR. JAR é o problema que a biblioteca A trabalha com a biblioteca B; versão = 2, mas a biblioteca C só pode trabalhar com B; versão = 3. No Java padrão, você está sem sorte. No ambiente OSGi, todos os pacotes configuráveis ​​são cuidadosamente versionados e apenas os pacotes configuráveis ​​que podem colaborar são conectados juntos no mesmo espaço de classe. Isso permite que os pacotes A e C funcionem com sua própria biblioteca. Embora não seja aconselhável projetar sistemas com esse problema de controle de versão, ele pode salvar vidas em alguns casos.

Simples - a API OSGi é surpreendentemente simples. A API principal é apenas um pacote e menos de 30 classes / interfaces. Essa API principal é suficiente para gravar pacotes configuráveis, instalá-los, iniciar, parar, atualizar e desinstalá-los e inclui todas as classes de ouvinte e segurança. Existem muito poucas APIs que fornecem tanta funcionalidade para tão pouca API.

Pequeno - O OSGi Release 4 Framework pode ser implementado em um arquivo JAR de 300 KB. Essa é uma pequena sobrecarga para a quantidade de funcionalidade adicionada a um aplicativo, incluindo o OSGi. Portanto, o OSGi roda em uma grande variedade de dispositivos: de muito pequeno a pequeno, até mainframes. Ele requer apenas uma Java VM mínima para executar e acrescenta muito pouco a ela.

Rápido - Uma das principais responsabilidades da estrutura OSGi é carregar as classes dos pacotes configuráveis. No Java tradicional, os JARs são completamente visíveis e colocados em uma lista linear. Para pesquisar em uma classe, é necessário pesquisar nessa lista (geralmente muito longa, 150 não é incomum). Por outro lado, o OSGi pré-liga os pacotes e sabe para cada pacote exatamente qual pacote fornece a classe. Essa falta de pesquisa é um fator significativo de velocidade na inicialização.

Preguiçoso - o software preguiçoso é bom e a tecnologia OSGi possui muitos mecanismos para fazer as coisas apenas quando realmente são necessárias. Por exemplo, os pacotes configuráveis ​​podem ser iniciados com entusiasmo, mas também podem ser configurados para iniciar somente quando outros pacotes configuráveis ​​os estiverem usando. Os serviços podem ser registrados, mas criados apenas quando usados. As especificações foram otimizadas várias vezes para permitir esse tipo de cenário preguiçoso que pode economizar enormes custos de tempo de execução.

Seguro - Java possui um modelo de segurança refinado muito poderoso na parte inferior, mas ficou muito difícil de configurar na prática. O resultado é que a maioria dos aplicativos Java seguros são executados com uma opção binária: sem segurança ou recursos muito limitados. O modelo de segurança OSGi aproveita o modelo de segurança refinado, mas melhora a usabilidade (além de proteger o modelo original), fazendo com que o desenvolvedor do pacote especifique os detalhes de segurança solicitados de uma forma facilmente auditável, enquanto o operador do ambiente permanece totalmente responsável. No geral, o OSGi provavelmente fornece um dos ambientes de aplicativos mais seguros que ainda são utilizáveis, com exceção das plataformas de computação protegidas por hardware.

Não Intrusivo - Aplicativos (pacotes configuráveis) em um ambiente OSGi são deixados por conta própria. Eles podem usar praticamente qualquer instalação da VM sem o OSGi restringi-los. A melhor prática no OSGi é escrever objetos Java antigos simples e, por esse motivo, não há interface especial necessária para os serviços OSGi, mesmo um objeto Java String pode atuar como um serviço OSGi. Essa estratégia facilita a portabilidade do código do aplicativo para outro ambiente.

Corre em todo lugar - Bem, isso depende. O objetivo original do Java era executar em qualquer lugar. Obviamente, não é possível executar todo o código em qualquer lugar porque os recursos das Java VMs diferem. Uma VM em um telefone celular provavelmente não suportará as mesmas bibliotecas que um mainframe IBM executando um aplicativo bancário. Há duas questões para resolver. Primeiro, as APIs OSGi não devem usar classes que não estão disponíveis em todos os ambientes. Segundo, um pacote configurável não deve ser iniciado se contiver código que não está disponível no ambiente de execução. Esses dois problemas foram resolvidos nas especificações OSGi.

Fonte: www.osgi.org/Technology/WhyOSGi

Encontrei os seguintes benefícios do OSGi:

• Cada plug-in é um artefato com versão que possui seu próprio carregador de classe.
• Cada plug-in depende dos jars específicos que ele contém e também de outros plug-ins com versão específicos.
• Devido ao versionamento e aos carregadores de classe isolados, versões diferentes do mesmo artefato podem ser carregadas ao mesmo tempo. Se um componente do seu aplicativo depender de uma versão de um plug-in e outro depender de outra versão, ambos poderão ser carregados ao mesmo tempo.

Com isso, é possível estruturar seu aplicativo como um conjunto de artefatos de plug-in com versão que são carregados sob demanda. Cada plug-in é um componente independente. Assim como o Maven ajuda a estruturar sua construção, para que seja repetível e definido por um conjunto de versões específicas de artefatos pelos quais é criada, o OSGi ajuda a fazer isso em tempo de execução.

Não me importo muito com a hotplugability dos módulos OSGi (pelo menos atualmente). É mais a modularidade imposta. Não ter milhões de classes "públicas" disponíveis no caminho de classe a qualquer momento protege bem das dependências circulares: você precisa realmente pensar em suas interfaces públicas - não apenas em termos da construção da linguagem java "public", mas em termos de sua biblioteca / module: Quais (exatamente) são os componentes que você deseja disponibilizar para outros? Quais (exatamente) são as interfaces (de outros módulos) que você realmente precisa para implementar sua funcionalidade?

É bom que o hotplug venha com ele, mas prefiro reiniciar meus aplicativos habituais do que testar todas as combinações de hotplugability ...

• Analogamente, você pode mudar o motor do seu carro sem desligá-lo.
• Você pode personalizar sistemas complexos para os clientes. Veja o poder do Eclipse.
• Você pode reutilizar componentes inteiros. Melhor do que apenas objetos.
• Você usa uma plataforma estável para desenvolver aplicativos baseados em componentes. Os benefícios disso são enormes.
• Você pode criar componentes com o conceito de caixa preta. Outros componentes não precisam saber sobre interfaces ocultas, eles vêem apenas as interfaces publicadas.
• Você pode usar no mesmo sistema vários componentes iguais, mas em versões diferentes, sem comprometer o aplicativo. OSGi resolve o problema de Jar Hell.
• Com o OSGi, você desenvolve o pensamento de arquitetar sistemas com o CBD

Existem muitos benefícios (lembrei-os agora) disponíveis para todos que usam Java.

editado para maior clareza. A página OSGi deu uma resposta simples melhor do que a minha

Uma resposta simples: uma plataforma de serviço OSGi fornece um ambiente de computação padronizado e orientado a componentes para serviços de rede em cooperação. Essa arquitetura reduz significativamente a complexidade geral da criação, manutenção e implantação de aplicativos. A plataforma de serviço OSGi fornece as funções para alterar a composição dinamicamente no dispositivo de uma variedade de redes, sem a necessidade de reinicializações.

Em uma única estrutura de aplicativo, por exemplo, o IDE do Eclipse, não é importante reiniciar quando você instala um novo plug-in. Usando a implementação OSGi completamente, você poderá adicionar plug-ins em tempo de execução, obter a nova funcionalidade, mas não precisará reiniciar o eclipse.

Novamente, não é grande coisa para todos os dias, uso de aplicativos pequenos.

Mas, quando você começa a examinar as estruturas de aplicativos distribuídos para vários computadores, é aí que começa a ficar interessante. Quando você precisa ter 100% de tempo de atividade para sistemas críticos, é útil a capacidade de fazer hotswap de componentes ou adicionar novas funcionalidades em tempo de execução. É verdade que existem recursos para fazer isso agora, na maioria das vezes, mas o OSGi está tentando agrupar tudo em uma pequena estrutura agradável com interfaces comuns.

OSGi resolve problemas comuns, não tenho certeza sobre isso. Quero dizer, pode, mas a sobrecarga pode não valer a pena por problemas mais simples. Mas é algo a considerar quando você começa a lidar com aplicativos maiores e em rede.

Algumas coisas que me deixam louco no OSGi:

1) As implicações e seus carregadores de contexto têm muitas peculiaridades e podem ser um pouco assíncronas (usamos felix dentro da confluência). Comparado a uma mola pura (sem DM), onde [main] está praticamente rodando em tudo sincronizado.

2) As classes não são iguais após uma carga quente. Digamos, por exemplo, você tem uma camada de cache de tangosol no hibernar. É preenchido com Fork.class, fora do escopo OSGi. Você carrega um jarro novo e o Fork não mudou. Class [Fork]! = Class [Fork]. Também aparece durante a serialização, pelas mesmas causas subjacentes.

3) Clustering.

Você pode contornar essas coisas, mas é uma grande dor e faz com que sua arquitetura pareça falha.

E para aqueles de vocês que anunciam o hotplugging .. O cliente número 1 da OSGi? Eclipse. O que o Eclipse faz após carregar o pacote configurável?

Reinicia.

O OSGi lança seu código NoClassDefFoundErrore ClassNotFoundExceptionsem motivo aparente (provavelmente porque você esqueceu de exportar um pacote no arquivo de configuração OSGi); como possui ClassLoaders, sua classe pode com.example.Foofalhar ao ser convertida, com.example.Foopois na verdade são duas classes diferentes carregadas por dois carregadores de classe diferentes. Ele pode fazer com que o Eclipse inicialize em um console OSGi depois de instalar um plug-in do Eclipse.

Para mim, o OSGi apenas adicionou complexidade (porque adicionou mais um modelo mental para eu agradar), acrescentou aborrecimentos por causa de exceções; Eu realmente nunca precisei da dinamicidade que "oferece". Era intrusivo, pois exigia a configuração do pacote OSGi para todos os módulos; definitivamente não era simples (em um projeto maior).

Por causa da minha má experiência, costumo ficar longe desse monstro, muito obrigado. Eu prefiro sofrer com a dependência do jar, porque é muito mais fácil de entender do que o introduzido pelo OSGi.

Ainda estou para ser um "fã" de OSGi ...

Eu tenho trabalhado com um aplicativo corporativo nas empresas da Fortune 100. Recentemente, o produto que usamos foi "atualizado" para uma implementação OSGi.

iniciando a implantação cba local ... [18/2/14 8: 47: 23: 727 EST] 00000347 CheckForOasis

finalmente implantado e "os seguintes pacotes configuráveis ​​serão desativados e, em seguida, reiniciados" [18/2/14 9: 38: 33: 108 EST] 00000143 AriesApplicat I CWSAI0054I: Como parte de uma operação de atualização para aplicativo

51 minutos ... cada vez que o código é alterado ... A versão anterior (não OSGi) seria implantada em menos de 5 minutos em máquinas de desenvolvimento mais antigas.

em uma máquina com 16 GB de RAM e 40 GB de disco livre e CPU Intel i5-3437U de 1,9 GHz

O "benefício" dessa atualização foi vendido como implementações aprimoradas (de produção) - uma atividade que realizamos cerca de 4 vezes por ano, com talvez 2 a 4 implementações de pequenas correções por ano. Adicionando 45 minutos por dia a 15 pessoas (controle de qualidade e desenvolvedores), não consigo me justificar. Em aplicativos de grandes empresas, se o seu aplicativo é um aplicativo principal, alterá-lo corretamente (pequenas mudanças têm potencial para causar impactos de longo alcance - devem ser comunicadas e planejadas com os consumidores em toda a empresa), uma atividade monumental - arquitetura incorreta para OSGi. Se o seu aplicativo não é um aplicativo corporativo - ou seja, cada consumidor pode ter seu próprio módulo personalizado, provavelmente atingindo seu próprio silo de dados em seu próprio banco de dados silo e executando em um servidor que hospeda muitos aplicativos, talvez veja o OSGi. Finalmente,

Se um aplicativo baseado em Java exigir a adição ou remoção de módulos (estendendo a funcionalidade básica do aplicativo), sem desligar a JVM, o OSGI poderá ser empregado. Geralmente, se o custo de desligar a JVM for maior, apenas para atualizar ou aprimorar a funcionalidade.

Exemplos :

1. Eclipse : fornece plataforma para plug-ins para instalação, desinstalação, atualização e interdependência.
2. AEM : aplicativo WCM, onde a alteração da funcionalidade será direcionada aos negócios, o que não pode permitir tempos de inatividade para manutenção.

Nota : A estrutura Spring parou de oferecer suporte aos pacotes configuráveis ​​OSGI spring, considerando-a como complexidade desnecessária para aplicativos baseados em transações ou em algum momento nessas linhas. Pessoalmente, não considero o OSGI, a menos que seja absolutamente necessário, em algo grande como a construção de uma plataforma.

Trabalho com o OSGi há quase 8 anos e devo dizer que você deve considerar o OSGi apenas se houver necessidade de atualizar, remover, instalar ou substituir um componente no tempo de execução. Isso também significa que você deve ter uma mentalidade modular e entender o que significa modularidade. Há alguns argumentos de que o OSGi é leve - sim, isso é verdade, mas também existem outras estruturas leves e fáceis de manter e desenvolver. O mesmo vale para garantir java blá blá.

O OSGi exige que uma arquitetura sólida seja usada corretamente e é muito fácil criar um sistema OSGi que poderia ser tão facilmente um jar executável independente sem que nenhum OSGi estivesse envolvido.

O OSGi oferece os seguintes benefícios:

■ Um ambiente de execução portátil e seguro baseado em Java

■ Um sistema de gerenciamento de serviços, que pode ser usado para registrar e compartilhar serviços entre pacotes configuráveis ​​e desacoplar provedores de serviços de consumidores de serviços

■ Um sistema de módulo dinâmico, que pode ser usado para instalar e desinstalar dinamicamente módulos Java, que o OSGi chama de bundles

■ Uma solução leve e escalável

Também está sendo usado para trazer portabilidade adicional de middleware e aplicativos no lado móvel. O lado móvel está disponível para WinMo, Symbian, Android, por exemplo. Assim que a integração com os recursos do dispositivo ocorrer, ele poderá ficar fragmentado.

No mínimo, o OSGi faz você PENSAR em modularidade, reutilização de código, versão e, em geral, no encanamento de um projeto.

Outros já descreveram os benefícios em detalhes. Explico aqui os casos práticos que vi ou usei OSGi.

1. Em um de nossos aplicativos, temos fluxo baseado em eventos e o fluxo é definido em plug-ins baseados na plataforma OSGi; amanhã, se algum cliente desejar um fluxo diferente / adicional, ele precisará implantar mais um plug-in, configurá-lo no nosso console e pronto. .
2. Ele é usado para implantar diferentes conectores da loja, por exemplo, suponha que já tenhamos o conector do banco de dados Oracle e, amanhã, seja necessário conectar o mongodb, em seguida, escreva um novo conector e implante-o e configure os detalhes no console e pronto. A implantação de conectores é tratada pela estrutura de plug-in OSGi.

Já existe uma declaração bastante convincente em seu site oficial, posso citar como

A principal razão pela qual a tecnologia OSGi é tão bem-sucedida é que ela fornece um sistema de componentes muito maduro que realmente funciona em um número surpreendente de ambientes. O sistema de componentes OSGi é realmente usado para criar aplicativos altamente complexos, como IDEs (Eclipse), servidores de aplicativos (GlassFish, IBM Websphere, Oracle / BEA Weblogic, Jonas, JBoss), estruturas de aplicativos (Spring, Guice), automação industrial, gateways residenciais, telefones e muito mais.

Quanto aos benefícios para o desenvolvedor?

DESENVOLVEDORES: O OSGi reduz a complexidade, fornecendo uma arquitetura modular para os atuais sistemas distribuídos em larga escala, bem como para os pequenos aplicativos incorporados. A construção de sistemas a partir de módulos internos e prontos para uso reduz significativamente a complexidade e, portanto, as despesas de desenvolvimento e manutenção. O modelo de programação OSGi cumpre a promessa de sistemas baseados em componentes.

Verifique os detalhes em Benefícios do uso do OSGi .