-
Notifications
You must be signed in to change notification settings - Fork 0
Service Component Models
Com o intuito de facilitar as ligações dinâmicas entre componentes, diferentes projetos propõem a utilização de uma arquitetura SOA como base para a ligação entre os componentes de uma aplicação. Neste contexto, os componentes fornecem e requerem serviços, os quais são gerenciados pelo container responsável pelo componente através da utilização de um Registro de Serviços.
Dentre os primeiros trabalhos apresentando a combinação dos conceitos presentes nas abordagens de componentes e serviços como solução para a problemática da disponibilidade dinâmica destaca-se a proposta do ServiceBinder[Cervantes 2004]. A ideia central da proposta é permitir que as aplicações se adaptassem, de forma autônoma, às mudanças relativas à disponibilidade de componentes que podem estar fora de seu controle. Assim, as aplicações deveriam ser capazes tanto de substituir componentes que não estivessem mais disponíveis como de incorporar novas funcionalidades fornecidas por novos componentes que se tornassem disponíveis.
De forma concreta, a proposta de Cervantes introduz o padrão arquitetural SOA como mecanismo de integração de componentes, reduzindo o acoplamento entre os elementos que compõem as aplicações. Nesse contexto, a adição, remoção e substituição de componentes podem ser tratadas dinamicamente por um ambiente de execução a partir das informações definidas pelo desenvolvedor, as quais são separadas da lógica de negócio das aplicações.
Dentre os modelos de componentes baseados em serviço, o iPojo vem conseguindo grande projeção. A ideia central deste modelo é viabilizar o desenvolvimento de aplicações dinâmicas a partir de componentes desenvolvidos como "Plain Old Java Objects" (POJOs), de forma que os desenvolvedores possam se concentrar no código de negócio, sem a preocupação com eventuais complexidades decorrentes da adoção de um modelo de componentes.