Sağlık Sektöründe Mobbing

Nessa seção abordaremos o diagrama de classes do framework JFault. O diagrama será apresentado quebrado em pacotes para melhor visualização e organização dos componentes.

3.2.1.1 Pacote de meta-tags (com.jfault.annotations)

Esse pacote contém todas as interfaces de anotações (meta-Tags) que são utilizadas pelo framework para identificação dos serviços. As anotações “JfaultCrashFT” e “JFaultTimingFT” são utilizadas pelo framework para identificar os tipos de falhas que deverão ser toleradas em cada serviço. A anotação “JFaultTimingFTSpecificSLA ” é usada para determinar um tempo específico de resposta para uma operação – é a única anotação utilizada em nível de método. As anotações “JFaultStub” e “JFaultRemote” serão respectivamente utilizadas para criação dos componentes de Stub e Proxy do framework.

A Figura 20 mostra o pacote graficamente e a Tabela 5 mostra as anotações disponíveis, juntamente com as os parâmetros que podem ser utilizados em cada anotação e um a descrição detalhada de cada parâmetro.

Figura 20 – Pacote de anotações do JFault

Tabela 5 – Anotações Suportadas pelo JFault

Anotação Descrição Parâmetros Descrição dos

Parâmetros

@JFaultRemote Utilizada no serviço para expô-lo remotamente para utilização.

remoteReferenceName

Descreve o nome no registro RMI do servidor ao qual o serviço em questão será disponibilizado. Esse identificador será utilizado de forma transparente ao cliente pelo Stub gerado pelo

framework.

remoteReferencePort

Define o número da porta em que o serviço deve ser disponibilizado no registro RMI do servidor.

@JFaultStub Utilizada pelo framework para criação do Stub, utilizado pelo cliente da aplicação para acesso remoto aos serviços.

remoteHosts

Define o endereço dos servidores (hosts) onde o serviço está sendo disponibilizado. Se o algoritmo de balanceamento de carga

LB_ROUND_ROBIN_W IGHTED for escolhido a anotação “@” deve ser utilizada após o endereço do servidor, juntamente com o

percentual de

requisições que devem ser enviadas ao mesmo. Exemplo:

@JFaultStub(remoteHo sts={"localhost@80", "169.254.81.102@20"} )

@JfaultCrashFT

Utilizada no serviço para torná-lo tolerante a falhas de colapso.

Para que possa ser utilizada, é necessário que ao menos dois servidores de aplicação sejam incluídos no parâmetro remoteHosts da anotação JFaultStub. algorithm LB_ROUND _ROBIN As requisições serão enviadas para todos os servidores de forma uniforme. LB_ROUND _ROBIN_W EIGHTED As requisições serão enviadas aos servidores conforme um “peso”, que pode ser definido para cada réplica. 70% das requisições para um servidor e 30% para outro, por exemplo.

@JFaultTimingFT

Utilizada para tolerar falhas de tempo no serviço.

O uso dessa anotação sobrescreve o parâmetro de tempo limite de resposta padrão do

framework para o serviço

em questão.

algorithm FT_PREVE_NTION O algoritmo selecionará as réplicas baseado nos tempos anteriores de resposta. O atributo “REPLICA_QTD” define a quantidade de

réplicas que será utilizada. O atributo “GENERAL_SLA” define o tempo máximo de resposta da primeira réplica. GENERAL_ SLA Long REPLICA_Q TD Long @JFaultTimingFT MethodSLA

Utilizada para definir um tempo máximo de resposta do serviço em nível de operação. METHOD_S LA Long O atributo “METHOD_SLA” define o tempo máximo de resposta à nível de operação. Seu uso sobrescreve o atributo “GENERAL_SLA”, utilizado a nível de serviço (de classe).

3.2.1.3 Pacote de Exceções (com.jfault.exceptions)

Esse pacote contém todas as exceções que serão utilizadas pelo framework. A exceção “JFaultGenericException” é a classe base de todas as exceções e pode ocorrer em qualquer situação que não estiver coberta pelas outras, como erros na criação de uma interface ou falhas em registrar um serviço remoto. A “JFaultIOException” é utilizada em qualquer caso de erro relacionado à escrita e leitura de dados, como por exemplo, a escrita de uma classe Java no disco rígido. As exceções “JFaultCrashException”, e

“JFaultSALViolatedException”, são enviadas para o cliente pelo Stub respectivamente quando não existem mais serviços que possam atender as requisições e quando o tempo máximo de espera pelo retorno de um serviço foi excedido. A exceção “JFaultUnknowFailException” ocorre quando uma falha desconhecida e não tratada pelo

framework ocorreu. A Figura 21 mostra o pacote “com.jfault.exceptions”.

Figura 21 – Pacote de exceções do JFault

3.2.1.4 Classes de controle (com.jfault.framework)

Esse pacote, mostrado graficamente na Figura 22, contém as principais classes de controle do framework. A classe “JFaultLog” é utilizada para encapsular os logs do sistema, que podem ser tanto direcionados para a saída do console da aplicação (System.out) quanto para um arquivo. A classe “JFaultConstants” contém todas as constantes utilizadas no framework.

A classe “JFaultInterfaceServices” encapsula toda a lógica de criação de interfaces dentro do framework. Conforme já abordado, os objetos de meta-nível Stub e Proxy são baseados nas mesmas assinaturas dos serviços que estão sendo expostos pelo

framework para acesso remoto. No Java, quando utilizamos o protocolo RMI, faz-se

necessário que as interfaces de acesso remoto sejam criadas, tanto no lado cliente (Stub) quanto no lado servidor (Proxy). Esse é o objetivo da classe “JFaultInterfaceServices”: o seu método principal “generateInterface()” recebe como parâmetro o nome da classe base e sua estrutura de métodos, extraídos com a utilização de reflexão, para gerar em tempo de execução a assinatura dos métodos das interfaces de Stub e Proxy. O método retorna um objeto do tipo “JFaultProxyInterfaceVo”, que contém todo o código necessário para geração das interfaces. O Apêndice A possui o código da classe para referência.

A classe “JFaultRMIServices” contém a implementação necessária de todos os serviços de exposição remota de objetos. Os dois métodos principais “startRegistry()” e “exportObjet()” são utilizados respectivamente para se iniciar um registro RMI e exportar um objeto para ser acessado remotamente. O Apêndice B possui o código da classe para referência.

A classe “JFaultProxyServices” é utilizada para gerar dinamicamente as classes dos objetos de meta-nível Proxies. O método principal da classe “generateProxy” recebe como parâmetro o nome da classe de serviço da aplicação, o nome da interface e a assinatura de todos os métodos. O retorno do método é um objeto do tipo “JFaultProxyVo” que contém toda informação necessária para que a classe do Proxy possa ser criada e compilada dinamicamente (Apêndice C).

A classe “JFaultStubServices” é utilizada pelo JFaultManager para gerar dinamicamente as classes dos objetos de meta-nível Stubs. Existem vários métodos nessa classe, os principais são: “JFaultGenerateStubs()” e “JFaultGenerateStub()”. O método “JFaultGenerateStubs()” é chamado pelo JFaultManager que envia a configuração do projeto que deve ser analisado para verificação dos Stubs presentes. Uma vez que o framework identificou todos os Stubs que devem ser gerados, o método “JFaultGenerateStub()” é chamado internamente na classe, para cada Stub, para que a classe e interface do mesmo possa ser construído, compilado e carregado dinamicamente. Como já visto, a estrutura da classe de serviços que gera o Stub é adquirida através de reflexão (linha 9) e compilada dinamicamente com a API de

compilação dinâmica de acesso programático do Java (linhas 15 e 38). O Apêndice D mostra a implementação do método “JFaultGenerateStub()” em detalhes.

A classe “JFaultManager” representa o serviço que inicia o framework no servidor. O processo de inicialização consiste em localizar os objetos de Proxy a serem criados dinamicamente, criar o código fonte necessário para sua construção, compilar o código e expor os objetos para serem acessados remotamente utilizando-se RMI. O Apêndice E apresenta a implementação do método principal da classe JFaultManager: “exposeClass4RemoteAccess()”.

3.2.1.5 Classes de Serviços de Compilação Dinâmica e Reflexão (com.jfault.jvm)

Esse pacote (Figura 23) contém o núcleo (core) de serviços do framework. A classe “JFaultJvmServices” encapsula toda lógica de compilação dinâmica, efetuada através da API de compilação dinâmica de acesso programático do Java (javax.tools). Atuando em combinação com um class loader específico do framework (“JFaultClassLoader”), é possível inclusive compilar recursos em tempo de execução com class paths adicionados dinamicamente (linha 31 da tabela 17). Isso se torna necessário visto que os Stubs possuem dependências com o projeto da aplicação em si, consequentemente, é necessário que o “JFaultManager” adicione o class path da aplicação nas dependências de compilação. A classe “JFaultReflectionServices” contém toda implementação dos serviços de reflexão do framework, permitindo inspecionar a estrutura de classes (método “getMethods()”) e criar novas instâncias de objetos (método “createInstance()”), ambos em tempo de execução. O Apêndice F apresenta a implementação dos principais métodos das classes.

Figura 23 – Pacote de serviços de Compilação Dinâmica e Reflexão

3.2.1.6 Classes de Encapsulamento (com.jfault.vo)

A Figura 24 mostra o pacote que contém as classes que encapsulam os dados usados pelo framework e são de menor importância para serem detalhadas. As únicas exceções são as classes “JFaultProxyInterfaceVo”, “JFaultProxyClassVo” e “JFaultStubVo” que, além de encapsular os dados que serão utilizados para criação dos objetos de Proxy e Stub, também contém a lógica de implementação desses objetos de meta-nível que são criados pelo próprio framework. As classes de encapsulamento dos Proxies contém a implementação necessária para criação das interfaces e classes de Proxy que serão usadas para exposição remota dos métodos de serviço através de RMI.

A classe “JFaultStubVo”, contém o código Java necessário para tratar as falhas especificadas pelo desenvolvedor da aplicação através das anotações adicionadas nos serviços, além da implementação do método de “hearthBeat()” adicionado dinamicamente pelo framework nos Stubs. É importante mencionar que essa classe pode gerar o código fonte dos Stubs com a mesma estrutura dos serviços, pois quando o código Java é requerido, o objeto já possui encapsulada a estrutura das classes de serviço, previamente adquiridas com a utilização de reflexão. O Apêndice G mostra parte do código fonte Java utilizado para criação do método de “heartBeat()”, injetado nos Stubs pelo framework. O código é adicionado em um objeto Java do tipo “StringBuffer” através da chamada ao

método “append()”. O código fonte encapsulado nesse objeto é posteriormente compilado dinamicamente para criação dos objetos de meta-nível.

Figura 24 – Pacote de controle do framework JFault