Artigos Java Modularidade em Java - Java Magazine 85

De que se trata o artigo:

O artigo aborda o framework OSGi e sua plataforma de serviços, trazendo modularidade para a plataforma Java. A maioria dos conceitos envolvendo o uso de módulos dentro da plataforma OSGi é apresentada no decorrer do artigo com exemplos práticos e comparações ao desenvolvimento Java “tradicional”.


Para que serve:

Apresentar os problemas encontrados atualmente na tentativa de obter recursos de modularidade e versionamento em Java, e como a especificação da plataforma de serviços OSGi se propõe a solucionar tais problemas.


Em que situação o tema é útil:

OSGi é um tema que vem ganhando cada vez mais destaque dos principais fornecedores de software, uma vez que a modularidade e a capacidade de divisão de aplicações complexas em pequenas partes tem se tornado algo muito importante. O tema é útil tanto para desenvolvedores de bundles, desenvolvedores ou arquitetos que estejam em busca de soluções para a criação de uma arquitetura baseada no conceito de ‘plugins’, assim como para usuários de plataformas e servidores que tenham interesse em adotar OSGi em seu núcleo para gestão de módulos.

Modularidade em Java:

O artigo primeiramente apresenta os problemas enfrentados por quem deseja trabalhar com módulos na plataforma Java e ilustra como é difícil criar aplicações modularizadas. A partir desse ponto é tratado de forma teórica e prática como o OSGi endereça os problemas existentes com seu modelo de gestão de módulos de forma dinâmica, controle de dependências e controle do ciclo de vida dos módulos. Por fim, abordamos a camada de serviços provida pelo OSGi e como podemos registrar e obter serviços, além de nos beneficiar da ocultação de conteúdo provida pelo OSGi.

Abordaremos nesse artigo como a especificação OSGi nos permite criar módulos autossuficientes, com alta coesão e baixo acoplamento, adicionando recursos como controle total do ciclo de vida do módulo, segurança e versionamento ao conceito de modularidade dentro da plataforma Java. Veremos de forma teórica e prática os principais fundamentos do uso da tecnologia OSGi, principalmente com foco em como controlar a dependência entre os módulos.

O problema

A modularidade sempre foi um ponto fraco da plataforma Java. Atualmente, o máximo que pode ser obtido em termos de modularidade é a divisão de uma aplicação em arquivos .jar. Tais arquivos são adicionados ao classpath da aplicação que os utiliza e todas as suas classes se tornam disponíveis para uso. A partir desse ponto, vai do bom senso do desenvolvedor o uso correto das APIs disponibilizadas uma vez que não há como proibir o acesso às classes de implementação e forçar o uso somente através das interfaces. E não há também como realizar o versionamento dos módulos ou pacotes.

Dito isso, é possível afirmar que não existe um mecanismo para dividir uma aplicação em pequenas partes, paralelizar o desenvolvimento ou desacoplar porções da aplicação sem o uso de soluções mais complexas e que acabam transpassando as fronteiras de uma única JVM.

Outro problema bastante presente no dia-a-dia do desenvolvedor é a falta de controle que ele tem sobre o classpath da aplicação. Quando classes com o mesmo nome qualificado residem no classpath ao mesmo tempo, é quase certa a ocorrência de exceções do tipo ClassCastException.

A Plataforma de Serviços OSGi resolve esses problemas especificando regras sobre como as classes são carregadas e como deve ser efetuada a associação entre os módulos e os pacotes que são ou não acessíveis. Com isso, a plataforma permite que o desenvolvedor dos módulos desenvolva, instale, controle e evolua módulos de forma desacoplada e independente.

Uma introdução à Plataforma de Serviços OSGi

A Plataforma de Serviços OSGi (OSGi Service Platform) é uma especificação criada pela OSGi Alliance como uma plataforma de integração de componentes. O foco maior dessa especificação é proporcionar a criação de módulos com alta coesão e baixa dependência, que possam ser desenvolvidos independentemente e depois compostos, formando aplicações, ainda que “vivam” e sejam gerenciados de forma totalmente independente uns dos outros.

Apesar de estar recebendo uma maior atenção da comunidade e dos grandes players e fornecedores de TI atualmente, a primeira versão dessa especificação foi concebida no ano 2000. A especificação OSGi possui algo em torno de 10 anos e está em sua quarta versão major, o que demonstra sua maturidade.

O framework que materializa tal especificação é responsável por executar o núcleo da plataforma de serviços OSGi e prover um ambiente Java genérico, seguro e gerenciado, que suporta a instalação de módulos conhecidos como bundles. Esse framework é capaz de instalar, iniciar, interromper e desinstalar tais módulos. Tudo isso é feito de forma dinâmica, gerenciando o ciclo de vida e as dependências entre os módulos.

A plataforma OSGi já faz parte da plataforma Java através da JSR 291, que contém basicamente a especificação da plataforma de serviços OSGi, versão 4, sem alterações. Alinhada a essa JSR, temos a JSR 232, que segue a mesma filosofia da JSR 291, porém com foco em dispositivos móveis, adicionando a capacidade de instalar módulos sob demanda às aplicações Java ME.

Arquitetura OSGi

A Figura 1 apresenta uma visão em alto nível da Plataforma de Serviços OSGi. A imagem foi obtida na especificação OSGi Service Platform Core Specification.

Figura 1. Visão alto nível da Plataforma de Serviços OSGi.

Cada um dos componentes apresentados na Figura 1 possui responsabilidades bem definidas. Alguns são internos ao OSGi como, por exemplo, a camada de módulos (Module). Outros são componentes necessários à execução da JVM sobre a qual a plataforma executa, como a parte de hardware e sistema operacional (Hardware/OS). Alguns dos componentes representam camadas do ambiente OSGi que endereçam problemas encontrados no desenvolvimento Java tradicional. Podemos destacar o seguinte sobre cada uma das camadas:

• Camada de Segurança (Security Layer): A camada de segurança é baseada na especificação de segurança da plataforma Java e preenche algumas das lacunas existentes quando o assunto é a composição da aplicação em módulos que podem ter sido criados por terceiros. Um exemplo é o controle de autenticidade do módulo através da verificação de uma assinatura digital;

• Camada Modular (Module Layer): A camada modular define a semântica para empacotamento dos módulos e estabelece formas de compartilhamento e isolamento de pacotes e classes, o que é chamado de ocultação de conteúdo ou content hiding. A camada modular será uma das mais abordadas nesse artigo;

• Camada de Ciclo de Vida (Life Cycle Layer): A camada de ciclo de vida define os mecanismos pelos quais os bundles são inicializados e finalizados. Define também uma API para emitir e receber notificações sobre eventos ocorridos em relação ao ciclo de vida dos bundles;

• Camada de Serviço ( ...

Quer ler esse conteúdo completo? Tenha acesso completo