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