Skip to content

Service Toolbox

A Service Toolbox é a API de serviços do MiddleHeaven e uma das peças essenciais na sua arquitetura.

Para o MiddleHeven um serviço é um contrato representado por uma interface Java. O contrato tem várias implementações possiveis ( dai o uso de uma interface Java para o representar). Sendo que um contrato têm várias implementações é necessário um registro de qual implementação está sendo utilizada correntemente.

ServiceRegistry

O objeto ServiceRegistry é um registro de serviços seguindo o padrão Registry. Para registrar um serviço precisamos da interface do contrato, uma implementação desse contrato, e opcionalmente precisamos de parametros para destinguir uma implementação de outra, para o mesmo serviço.

O exemplo clássico de serviços com implementações diferentes usados simultaneamente é o de dicionários. Podemos ter um serviço de dicionário que funciona para portugues e outro para espanhol e podemos querer usar os dois simultaneamente.

Ciclo de Vida de um Serviço

Um serviço pode estar registrado, não-registrado ou em alteração. Quando um serviço está disponivel no ServiceRegistry ele está no estado registrado (REGISTRED). Quando o serviço é removido do registro está não-registrado (UNREGISTRED). Pode acontecer que uma nova implementação do serviço está substituindo a antiga. Durante este processo o serviço não pode ser usado, mas ele está no registro. Durante este processo o serviço está em estado de alteração (UPDATE). O ServiceRegister permite que sejam cadastrados listeners para responder ao estado do serviço.

Quando um serviço é requisitado ao ServiceRegistry não é retornada a implementação do serviço e sim um proxy para essa implementação. Isto porque, quando o serviço é alterado por outro, o objeto que necessita do serviço ainda têm uma referencia válida ao serviço, apenas a implementação muda. O proxy bloqueia o acesso ao serviço enquanto a alteração é feita. Quando o serviço é removido permanentemente o proxy lança uma exceção ServiceNotFoundException. O proxy é capaz de avaliar o estado de acesso ao serviço porque ele recebe os eventos do ciclo de vida do serviço a que está acoplado.

Ativação

Além de ser possivel registrar os serviços no ServiceRegistry diretamente é ainda possivel iniciar um serviço por ativação. O WiringService permite que qualquer objeto possa ser ativado, e isso, claro, inclui os serviços. A ideia é que serviços opcionais possam ser adicionados/alterados a quente durante o funcionamento da aplicação. Para isso basta seguir o processo normal de ativação.

Publicação e Subscrição

Serviços são acessiveis pelo ServiceRegistry e/ou pelo WiringService mas apenas dentro da mesma JVM, no mesmo contexto de classloading. Se quiser que o serviço possa ser acessado de outros contextos ou quiser acessar serviços presentes em outros contexto é necessário algo mais.

O serviço de publicação de serviços tornar os serviços acessiveis por outros mecanismos. Nomeadamente por mecanismos remotos como web services.

O serviço de subscrição de serviços torna possivel trazer serviços externos para dentro do ServiceRegistry. Por exemplo, consumir um web service disponibilizado na web e registrá-lo com uma certa interface no ServiceRegistry. É uma implementação remota do serviço.

Outras opções são ainda interagir com um EBS subscrevendo-se ao ponto de entrada de um processo ou disponibilizar o serviço via Jini ou RMI.

A toolbox de Serviços visa trazer a orientação a serviços para dentro das suas aplicações de uma forma orientada a objetos utilizando interfaces java.

Os serviços de publicação e subscrição ainda não estão implementados mas são uma das ideias para um futuro breve já que são necessários no mundo de hoje onde as aplicação são connectadas. Especialmente se tomarmos em consideração o mundo JME que precisa interagir com um servidor.

Uso

Normalmente quem usa o ServiceRegistry é o próprio MiddleHeaven, para o programador final o uso do WiringService é recomendado. Contudo é bom entender que o ServiceRegistryé o coração do MiddleHeaven já que todos os toolbox têm alguma forma de interagir com isso, seja disponibilizando serviços, seja dependendo de outros serviços.

O WiringService é um motor de injeção automática de dependencia enquanto que o uso do ServiceRegistry é mais próximo ao de um ServiceLocator. O WiringService disponibiliza o escopo de serviço exactamente para esconder o uso do ServiceRegistry para o programador final. Em outras palavras, o ServiceRegistry tem que ser conhecido por quem desenvolve o MiddleHeavem em si, mas não para quem usa o MiddleHeavem para criar suas próprias aplicações. Para esses, o WiringService é o cara.

Dito isto, aqui fica uma demonstração de como seria utilizar o ServiceRegistry:

1
2 // em algum lugar da aplicação (normalmente o Container)
3 ServiceRegistry.register ( NameDirectoryService.class, new JNDINameDirectoryService ()) ;
4
5 // em algum outro lugar da aplicação
6 NameDirectoryService service = ServiceRegistry.getService ( NameDirectoryService. class ) ;
7 // use o serviço
8

Código 1: Exemplo de uso do ServiceRegistry

Por detrás dos Panos

Não ha outras API sendo usadas por detrás dos panos neste toolbox. Apenas o uso extensivo dos padrões Registry, Service, Proxy e Observer. Tudo implementado puramente em Java pelo MiddleHaven. A razão é simples: é uma API muito importante para dependender de outras API externas.

Contudo, existe um “truque” no que diz respeito à forte interação entre o ServiceRegistry e o WiringService. O WiringService é um serviço, pelo que tem que estar registrado no ServiceRegistry, mas ele injeta serviços nos objetos que gerencia, pelo que tem que ser possivel ler do ServiceRegistry. Em particular, lêr-se a ele próprio quando é requisitado para injeção em algum objeto. O que faz isto funcionar é o mecanismo de bootstrap. Durante o bootstrap o container pode registrar o serviço que quiser. Se o MiddleHeaven está rodando dentro de um servidor de aplicação JEE, por exemplo, váris serviços já estão disponivies (transação, envio de email, jndi) Ao registrar os serviços ele ficam automáticamente disponiveis para injeção.

No inicio do desenvolvimento foi cotada a opção de usar OSGi para integrar os serviços. Contudo isso nos deixaria com um modelo muito dependente das limitações do OSGi. Desta forma é possivel criar um mecanismo de subscrição que entenda e utilize serviços OSGi e até encapsular o MiddleHeaven, ou seus serviços, como serviços OSGi. Mas isso é coisa para um futuro bem mais longinquo.

O processo de ativação utilizado pelo MiddleHeaven é bem semelhante ao usado pelo OSGi, mas a resolução de dependencias é feita pelo motor de injeção o que permite que os ativadores apenas tenham que declarar de quais serviços são dependentes e quais eles publicam ao nivel do código sem precisar de artefactos como arquivos de manifesto. A grande diferença é que o MiddleHeaven exige que um serviço seja um contrato + uma implementação, coisa que o OSGi não exige.Isso não é uma limitação porque está mais de acordo com o conceito do padrão Service e permite mais flexibilidade, já que é possivel utilizar proxies.

O Java 7 irá trazer um mecanismo especial para modulurização de código. Este modelo é diferente do seguido pelo OSGi e os dois não são mutuamente excludentes. Esperando para ver no que dá e como o MiddleHeaven se pode beneficiar disso. Por agora um ativador pode estar obtido de arquivos jar devidamente configurados.

Deixe um Comentário

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s

%d bloggers like this: