O Que é?
O projeto CAJO é uma biblioteca livre para permitir a interação espontânea e transparente entre Java Virtual Machines simplificando o uso de RMI (Método de Invocação Remota). Ele abstrai todo o clichê relacionado à rede, permitindo que aplicações multi-JVM consistir em objetos comuns. Nenhum arquivo de configuração XML é usado, ou seja tudo é 100% puro Java.
Ele é licenciado sob os termos da GNU Lesser General Public License (LGPL) da versão 3, publicada pela Free Software Foundation.
O projeto CAJO é um subprojeto do Distributed e iniciou em dezembro de 2010. Possui 319 membros e seu administrador é John Catherino.
Ele fornece quatro capacidades fundamentais:
· Um objeto pode se tornar um serviço remotamente exigível;· Um objeto pode fornecer um objeto controlador, para descarregar o processamento para um cliente remoto;
· Um objeto pode fornecer um componente de interface gráfica com o usuário para clientes remotos, browsers e através do Webstart;
· Um objeto pode enviar objetos agentes inteligentes para interagir com objetos remotos em seu nome.
Seu pequeno tamanho, flexibilidade e alto desempenho são inigualáveis.
Características
Prioridades: A consideração mais importante na concepção do projeto CAJO é a necessidade de trabalhar em todos os ambientes com JRE 1.2 ou superior. Não há simplesmente uma base instalada para fazer esta prática. No entanto, isso não significa que as suas aplicações sejam de algum modo restrito. Por exemplo, enquanto CAJO permite que todos os dispositivos como telefones móveis e workstations trabalhem juntos. Você é livre para usar toda a linguagem mais recente, e as características de tempo de execução, desde que os seus dispositivos cooperantes sejam compatíveis.
Características: Uma das características mais importantes do framework é que os aplicativos não têm de ser estruturados em torno dele. Isto torna extremamente fácil de incorporar o framework em aplicativos existentes. Projetos simples orientados a objeto são o necessário. Seus dois principais pontos fortes são a facilidade com que ele permite que máquinas virtuais se juntem dinamicamente para criar um computador virtual e sua capacidade de interfaces remotas sejam ricas aos usuários de modo muito simples.
Limitações: Tendo o RMI como base, o CAJO só funciona entre as aplicações Java. Para aplicações pré-Java isso pode implicar em um esforço significativo para à portabilidade. No entanto, isso é mais do que compensado pela magia do código móvel. Ser capaz de enviar um objeto para outra máquina virtual, incluindo suas definições de classe, é um recurso poderoso que só é fornecido através de Java.
Desempenho: O CAJO é uma camada pequena, altamente eficiente construída em cima de RMI, seu desempenho definitivamente não é pior do que outras tecnologias Java como Jini, ou J2EE, na verdade, é geralmente muito melhor! Ele faz implicar a sobrecarga um pouco mais do que usando protocolos de socket básicos, no entanto o poder e transparência que o RMI fornece, vale bem a pena o custo, e acabaria por ter que ser recriado manualmente, para fornecer todas as funcionalidades do framework.
Persistência: O mecanismo de armazenamento principal utilizado no projeto CAJO é o zedmob. Esta é uma contração de duas palavras: Object comprimidos e Marshalled. Ele permite que referências a objetos mesmo remotamente carregados, serão salvos no disco ou enviados a outras máquinas virtuais remotas. O zedmob persistente no que sua existência é totalmente independente do tempo de vida da máquina virtual usando.
Escalabilidade: A escalabilidade do quadro vem em duas formas, estático e dinâmico. Escalabilidade estática significa que uma única aplicação pode facilmente migrar seus objetos entre várias máquinas virtuais, para acomodar aumento de carga, ou preocupações com a confiabilidade. Na escalabilidade dinâmica, os objetos podem facilmente se juntam, para criar funcionalidades emergentes. Esta segunda tecnologia é muito emocionante, e ainda está na sua infância.
Segurança: Para a confiabilidade do servidor; hospedagem de objetos proxy poderia convidar a possibilidade de um ataque de negação de serviço. Um objeto proxy poderia solicitar mais recursos do que o host proporcionando uma redução de potencial de sua máquina virtual. Alternativamente, a segurança na comunicação pode ser proporcionada de várias maneiras. Por exemplo, a comunicação pode ser efetuada através de SSL, no entanto, a manta de sobrecarga deve ser tomada em consideração. Para contrariar isto, há também uma forma transparente para cifrar individualmente objetos sensíveis, o que pode revelar ambos significativamente mais rápidos, e ainda mais seguro!
Simplicidade: A estrutura do núcleo é muito pequena, e pode ser rapidamente entendido por completo. Apesar de toda a simplicidade, ele oferece ainda mais flexibilidade e poder do que outras estruturas pesadas que são maiores e mais complexas.
Flexibilidade: A estrutura fornece capacidade sem precedentes com RMI convencional: Os clientes podem usar objetos remotos, sem saber de sua interface funcional em tempo de compilação. Para projetos dinamicamente adaptáveis, este é um recurso extremamente valioso, disponível na grande maioria de outras estruturas. (Se não todos).
O que faz?
O projeto CAJO é focado principalmente na criação de aplicações distribuídas robustas, dinâmicas e tolerantes a falhas. Ele é projetado para tornar o desenvolvimento o mais fácil possível. Abaixo estão os conceitos gerais de como isso é feito:
· Cliente anuncia a disponibilidade de recursos através de Multicast;· Os hosts disponíveis escutam e invocam cliente com auto-referência;
· O cliente pede os recursos necessários;
· Cliente usa os recursos de referências;
· Cliente libera todas as referências remotas.
Se a opção multicast não estiver disponível, então os primeiros dois passos são como se segue:
· Cliente contata um ou mais registros de recursos centrais.· Cliente solicita referências aos hosts dos recursos necessários a partir dos registos.
Os passos restantes são os mesmos.
Em ambos os casos, os clientes devem estar preparados para qualquer fornecer recursos remotos que podem falhar de forma imprevisível. Os clientes também devem estar preparados para reiniciar as operações perdidas com outros recursos.
Um recurso do servidor normalmente fornece qualquer, ou todos, de três tipos gerais de funcionalidade:
· É uma utilidade funcional específica.· É um host para um proxy de objeto de um cliente, para offload e computação paralela.
· É um proxy que fornece ao cliente a funcionalidade local.
A etapa final do cliente na liberação de recursos é essencial. Como um paradigma geral, os clientes devem assumir que os servidores irão instanciar o objeto do recurso, a pedido, e não manter a sua referência localmente. Quando os clientes forem nulos sua referência remota para o recurso, pode então, ser recuperado automaticamente no servidor, através da DGC RMI. (Coletor de lixo distribuído)
Agora, uma definição clara e geral de computação Grid e Cluster podem ser declarados:
Grid: hardware do nó heterogêneo, proximidade distante, em curto prazo membros da confederação.
Cluster: hardware do nó homogêneo, proximidade, em longo prazo a adesão confederação.
Como faz?
As seis classes fundamentais do projeto CAJO são a chave para entender completamente o framework. Três são do pacote gnu.CAJO.invoke, e três são de gnu.CAJO.utils.
Pacote gnu.CAJO.invoke:
Invoke: Uma interface de método único, e a essência do framework. O método de um:
Object invoke (String method, Object args) throws Exception;
Define como um objeto chama outro objeto. O nome do método e os argumentos, se houver, são fornecidos. O resultado do método, ou a Exceções, se houver, é devolvido. Ela representa a invocação reflexiva dinâmica, para eliminar a necessidade de criar stubs individuais RMI para cada tipo de objeto, e para que os clientes tenham todas essas stubs também.
RemoteInvoke: uma interface sem corpo. Sua finalidade é a de determinar se uma referência a um objeto é local ou remoto. O teste é simples:
if (object instanceof RemoteInvoke) {
... // the object reference is remote
} else {
... // the object reference is local
}
... // the object reference is remote
} else {
... // the object reference is local
}
Remote: Seu objetivo principal é fazer com que qualquer objeto possa ser chamado remotamente. O objeto controlado remotamente no passado usando o construtor de argumento único, e a referência remota pode ser passado para máquinas virtuais remotas como argumentos de método, ou retornos. Ele implementa a interface Invoke, para permitir que qualquer método público sobre o objeto empacotado possa ser chamado. A única restrição é que não pode lidar com tipos primitivos, os argumentos e tipos de retorno ambos devem ser objetos.
Ele também permite que o método estático invoke ofereça transparência local ou remota completa. Sua assinatura é:
Object invoke (Object objeto, String method, Object args) throws Exception;
Permite a invocação de método em qualquer objeto, local ou remoto! Isso permite que aplicativos para usar um objeto localmente, e depois migrarem para um objeto remoto, sem impacto na fonte. Isto pode criar a necessidade de testes de localização de referência, tal como se explica na descrição da classe RemoteInvoke acima.
É também a casa para o método de configuração crítica estática, utilizada para configurar os parâmetros de rede para operação remota. Ele é geralmente chamado uma vez após a inicialização do aplicativo. Ele também fornece alguns outros métodos utilitários úteis. O stub RMI apenas utilizada por qualquer aplicação para este objeto.
Pacote gnu.CAJO.utils:
ItemServer: Esta classe é usada para ligar objetos remotos, usando nomes de aplicativos específicos, para que suas referências possam ser solicitadas por outras máquinas virtuais. Isso é chamado de ligação estática. Máquinas virtuais remotas geralmente usam o método estático getItem utilitário da classe Remote, para especificar o nome da máquina, e o nome da String sob o qual a referência do objeto remoto é vinculado. Ele também pode ser usado para ligar objetos contidos no jar separados. Isso ajuda muito na funcionalidade do aplicativo modularizada.
Abriga também o método acceptProxies. Quando chamado, vai permitir que máquinas virtuais remotas enviem objetos personalizados, que existem em seu espaço de endereçamento local. Mais sobre isso será mostrado no CodebaseServer.
Multicast: Essa classe é usada para transmitir referências a objetos remotos através da rede. Máquinas virtuais remotas também pode usar essa classe para receber esses anúncios. Isso é chamado de ligação dinâmica. Máquinas virtuais remotas usam o método announce para iniciar sua transmissão de suas referências de objetos remotos, e o método listen, para receber estas transmissões. Ele permite que referências a objetos remotos obtenham de forma espontânea, sem ter que saber o endereço TCP do host que serve.
CodebaseServer: Esta classe auxiliar tem dois propósitos fundamentais. Primeiro, ele é usado para fornecer definições de classe para máquinas virtuais remotas. Isso permite que uma máquina de envio passe objetos definidos localmente, como argumentos de método de retornos ou exceções. E para os objetos que exista localmente no espaço de endereço do receptor como mencionado anteriormente, o receptor deve ter chamado o método acceptProxies, já que esta funcionalidade está desativado por padrão.
A segunda função importante desta classe é de agir como um servidor de aplicação especializada. Ele irá pedir navegadores do cliente visualizador genérico visuais proxy, como um applet ou como um aplicativo via WebStart. Estritamente falando, se essa funcionalidade servidor de aplicação não for necessário, qualquer servidor http ou ftp padrão poderá ser usado em seu lugar. Neste caso, o servidor de arquivos não necessita estar funcionando na mesma máquina, como o servidor CAJO.
Quem utiliza?
Como o projeto CAJO é bastante fundamental em seu propósito - ou seja, distribuição de objetos entre a Máquina Virtual Java transparente - ele está sendo usado por grupos de todos os tamanhos: estudantes universitários, pequenas e grandes empresas, e até governos. Suas principais aplicações são: aplicações de escala, distribuindo usuário interfaces, e controle remoto.
Referencias
At.
Helder Narcizo
