Arquiteturas baseadas em espaço com GigaSpaces XAP

Transcrição

1 gigaspaces xap_ Arquiteturas baseadas em espaço com GigaSpaces XAP Arquiteturas baseadas em espaço: a revolução do Big Data. termo arquitetura multicamadas (ou n camadas) faz parte do jargão da TI já há algum tempo. O Separar uma aplicação Web em camadas é uma prática tão popular que quando se fala em arquiteturas web escaláveis é até estranho pensar que podemos usar outras abordagens. Mas será que existem outros meios de se organizar uma aplicação? Dividir a aplicação em várias partes e colocar cada parte em um servidor parece tão intuitivo... E no fundo é! Não é à toa que usamos esse tipo de abordagem há tanto tempo. Escala horizontalmente (até certo ponto, como veremos), facilita a manutenção e a extensão do software, enfim, deixa as coisas organizadas! Caiu uma máquina de frontent, no problem! Ainda há outras três (ou n - 1) ali recebendo requisições e repassando para as máquinas de backend. Contudo, algumas características desse modelo fizeram com que ele se tornasse inadequado para aplicações com fluxo de dados intenso. Com o Big Data, o volume de informações que precisamos processar, armazenar e recuperar aumentou consideravelmente. De cara já percebemos que a rede pode ser um limitante do modelo n camadas. Seria mais fácil se a informação não precisasse percorrer um caminho tão longo dentro da aplicação. Além disso, ainda temos o banco de dados! Ler e gravar do banco, por mais rápido que seja, para algumas tecnologias, ainda requer seeks. Este artigo tem como objetivo apresentar a Arquitetura Baseada em Espaços. Nesta nova abordagem, os dados ficam em uma estrutura em memória chamada space. Pelo fato de os dados ficarem em memória, é necessário usar um mecanismo assíncrono executando em segundo plano para persistir os dados em um banco de dados tradicional. A aplicação não mais será dividida em camadas. Em vez disso, tem-se o conceito de Unidade de Processamento (Processing Unit). O arquivo da aplicação é uma entidade independente das demais e instâncias diferentes da aplicação não compartilham nada entre si (Shared Nothing Architecture). A intercomunicação é toda feita com base no space. Neste artigo, apresentaremos alguns exemplos básicos de uma implementação de SBA chamada GigaSpaces XAP (extreme Application Platform). Apresentaremos como interagir com o espaço (gravar, ler, apagar e atualizar dados), bem como configurar e executar um exemplo básico usando essa tecnologia. Arquitetura multicamadas A arquitetura multicamadas já é um padrão de facto. Praticamente qualquer aplicação web hoje em dia já está logicamente separada em camadas e, na maioria dos casos, executa em produção com camadas físicas divididas em diferentes servidores. A ideia de separar as camadas lógicas em camadas físicas (layers versus tiers), com deploys em diferentes servidores veio principalmente da necessidade de escalar aplicações web. E não é por acaso que esse tipo de arquitetura é tão popular. A separação da aplicação em camadas físicas traz inúmeras vantagens, dentre elas estão: 1. Não há um único ponto de falha. Caso um servidor front-end caia, há outros para atender as requisições dos clientes. O mesmo acontece / 56

2 Neilson Carlos Leite Ramalho é graduado em Ciências de Computação e mestre em Sistemas de Informação pela Universidade de São Paulo. Trabalha atualmente com Java na Avaya Brasil, onde desenvolve aplicações de alto desempenho utilizando SBA. A arquitetura multicamadas é bastante popular em desenvolvimento de aplicações para Web. Resultado de uma evolução das antigas arquiteturas cliente/servidor, a multicamadas possui inúmeras vantagens. Contudo, com o aumento vertiginoso da quantidade de dados, essa arquitetura tornou-se obsoleta. A solução está nas arquiteturas baseadas em espaço, na qual os dados são armazenados em memória e a aplicação passa a ser uma entidade autossuficiente. com os servidores de back-end, ou seja, caso um servidor responsável por processar regras de negócio caia, a carga será distribuída para os outros nós. 2. Separação de responsabilidades. Se a regra de negócio mudar, apenas uma camada será modificada. 3. Embora alguns autores argumentem que a única maneira de se escalar nesse modelo é por meio de escalabilidade vertical (scale up), o fato é que também é possível ter escalabilidade horizontal (scale out). Caso seja identificado um gargalo em alguma das camadas, basta adicionar outros servidores e ajustar os mecanismos de balanceamento de carga. No entanto, é fácil perceber que esse tipo de arquitetura nada mais é do que uma adaptação do modelo cliente servidor para o mundo web. Por algum tempo esse tipo de arquitetura funcionou bem, mas logo veio o tal do Big Data, com aplicações processando milhares de transações por minuto e o volume de dados crescendo exponencialmente. Ao mesmo tempo em que a quantidade de dados aumentou, a velocidade na qual os mesmos devem ser processados também aumentou. Este cenário é o ideal para ilustrar as desvantagens da arquitetura multicamadas, a ver: 1. Arquitetura estática. Esse tipo de arquitetura tem natureza estática, ou seja, apesar de ser possível escalar horizontalmente, o processo não é tão rápido. Um novo servidor deverá ser adquirido, configurado, os jars/wars deverão ser disponibilizados no servidor de aplicação etc. Além disso, algumas empresas ainda adotam a estratégia de não disponibilizar imediatamente ou completamente o novo servidor em produção. Há um período de testes e validações, em que apenas uma pequena parte das requisições é enviada para a nova máquina e o comportamento geral é observado. Todo esse processo é muito lento e complexo, o que torna a arquitetura multicamadas imprópria para soluções nas quais há picos de carga. Se o número de acessos ao sistema é imprevisível, com picos de demanda podendo acontecer a qualquer momento, a solução é criar uma arquitetura com máquinas com uma grande quantidade de memória, alto poder de processamento etc. O resultado é que, em 95% do tempo ou mais, a solução funcionará com carga em torno de 10%. É muito desperdício de recursos. 2. Complexidade. O gerenciamento, a monitoração e a manutenção de muitos servidores distribuídos em camadas físicas não são tarefas triviais. É necessário ter uma equipe bem qualificada e que conheça bem a solução. Muitas camadas separadas também favorecem o aumento de erros. Sem contar que também fica mais difícil encontrar bugs nesses cenários. 3. Gargalos na rede. As camadas se comunicam geralmente por meio de chamadas remotas. Com isso, a rede fica inundada de objetos que vão e que vêm o tempo todo por causa da intercomunicação entre as camadas. Além disso, por mais que os processadores sejam rápidos e que a aplicação seja eficiente em termos de manipulação e transferência de dados, a latên- 57 \

3 cia da rede sempre vai ser um limitante geral no fluxo dos dados. 4. Banco pode ser tornar um gargalo. Banco implica em ler e escrever em disco. Por mais eficiente que seja esse processo em alguns SGBDs, o banco também pode se tornar um limitante na vazão geral dos dados. 5. Escalabilidade não linear. Estudos mostram que a arquitetura multicamadas escala linearmente até certo ponto. Depois disso, o investimento em recursos computacionais acaba não compensando, já que o número de requisições a mais que seria conseguido é insignificante quando comparado ao esforço e o custo do upgrade. Como exemplo, podemos ter situações nas quais a duplicação do número de servidores aumentaria a capacidade de atendimento de requisições em apenas 5%. A Figura 1 ilustra a escalabilidade em arquiteturas multicamadas. Perceba que até certo ponto o aumento da capacidade é satisfatório quando os recursos de hardware aumentam. Depois deste ponto, a capacidade passa a não responder tão bem a aumentos de recursos de hardware, não compensando o investimento em muitos casos. O cenário ideal está ilustrado na Figura Impossibilidade de relatórios em tempo real. Com muitas camadas, o caminho que o dado tem que percorrer desde sua origem (request) até o seu ponto final (tabela no banco) é relativamente longo e demorado. Daí a dificuldade de se ter relatórios em tempo real. Na Figura 3 está ilustrado um exemplo de uma aplicação na arquitetura multicamadas. Arquiteturas Baseadas em Espaço A Arquitetura Baseada em Espaço veio para corrigir os problemas acima citados. A ideia tem como base premissas simples: 1. Coloque todos os dados em memória. Como para a maioria das aplicações um servidor só não é suficiente para armazenar todos os dados em memória, adota-se a estratégia de particionamento e os dados são distribuídos em várias instâncias. 2. Em vez de quebrar a sua aplicação em diversas partes, utilize unidades autossuficientes que não dependam umas das outras. Com isso, para se conseguir a tão desejada escalabilidade horizontal, basta adicionar mais unidades de processamento. 3. O espaço, que é um recurso lógico e único, é utilizado na aplicação para compartilhamento de dados, lógica e eventos. E a lógica (processamento) pode ser colocada junto aos dados (semelhanças com o modelo Map/Reduce?), reduzindo a transferência de dados pela rede e deixando tudo ainda mais rápido. Para ilustrar os conceitos de SBA, utilizaremos o Gigaspaces XAP, porém esses conceitos podem ser aplicados em outras plataformas. De acordo com o próprio site da Gigaspaces, o XAP é: Uma plataforma para escalar horizontalmente aplicações stateful (que mantêm estado entre operações) em ambientes de alto desempenho e baixa latência. Há outros produtos semelhantes no mercado, como, por exemplo, o Coherence da Oracle e o Big Memory da Terracotta. O XAP foi escolhido por ser muito fácil de ser configurado e por oferecer um período de testes de três meses (tempo adequado para quem quer aprender os novos conceitos). A filosofia da Gigaspaces também é muito interessante. Eles possuem um programa de apoio a startups no qual o Gigaspaces XAP é disponibilizado para uso em produção para qualquer propósito e por tempo indeterminado. A única exigência é que a empresa não tenha faturamento superior a U$1 milhão anuais. A docu- capacity capacity crash barrier hardware hardware Figura 1. Escalabilidade não linear. Figura 2. Escalabilidade linear. / 58

4 Figura 3. Arquitetura multicamadas. mentação também é excelente. Há diversos exemplos e códigos para serem baixados. Tem dúvida sobre algum conceito? Problemas com alguma configuração? Basta postar no fórum que em pouco tempo alguém responderá a sua pergunta. Como o XAP é baseado em Spring, não tem muito segredo para começar a desenvolver. Em poucos minutos é possível ter uma aplicação executando em um cluster com replicação, self healing, e com escalabilidade horizontal. Para conseguir contornar os problemas das arquiteturas tradicionais, o Gigaspaces atua em diversas dimensões: 1. O banco de dados vai para o background. Em vez de salvar e ler dados do banco, agora utilizamos o space. Os dados continuam sendo salvos no banco, mas por um processo assíncrono que executa em segundo plano. Como na maioria dos casos o volume de dados é muito grande e não cabe na memória de um só servidor, os dados são então particionados e distribuídos em múltiplas instâncias do space em múltiplos servidores. Em suma, em vez de ler e escrever no disco, agora com o SBA lemos e escrevemos em memória. 2. Mensagens em memória. Com o sistema de mensagens em memória, temos um aumento de desempenho, já que agora não precisamos mais estabelecer conexões com máquinas externas, enviar mensagens para filas etc. 3. Lógica de negócios, dados e mensagens colocados em memória, particionados e em unidades de processamento. 4. Cada partição pode ter backups configurados. Assim, caso um servidor apresente alguma falha, o XAP ativará a partição de backup automaticamente, sem intervenção do administrador do sistema. 5. Como tudo está em memória e em unidades de processamento, as inúmeras camadas físicas não são mais necessárias. Assim, o tempo de resposta total das requisições é reduzido drasticamente e com isso pode-se ter relatórios em tempo real. Resumidamente, o GigaSpaces é um middleware que cuida basicamente de todos os aspectos da aplicação. Intuitivamente, poderíamos dividir o GigaSpaces em três componentes principais: o Data Grid, o Event Grid e o Processing Grid. Com esses componentes podemos gerenciar aplicações que utilizem desde mensageria em memória até jobs Map Reduce. Segue uma descrição breve de cada macrocomponente do GigaSpaces. 1. Data grid onde os dados são armazenados. Representado por instâncias de space. 2. Event grid é a parte do GigaSpaces responsável pelo gerenciamento dos eventos. Há duas estratégias principais: pooling (implementação do pattern de integração Pooling Consumer) e notify (suporte a notificações). 3. Processing Grid permite que o processamento seja colocado junto aos dados (Data-Collocation). Dentre as funcionalidades do Processing Grid temos os Executors. Com eles, podemos executar jobs Map Reduce de uma maneira muito mais rápida do que usando implementações do mercado como o Hadoop, por exemplo. Isso porque no GigaSpaces, os dados ficam em memória. No Hadoop, os dados ficam no HDFS (Hadoop Distributed File System), que embora seja otimizado (já que é baseado no Sistema de Arquivos do Lucene), ainda assim é mais lento do que o acesso direto em memória. Conceitos gerais do GigaSpaces XAP Esta seção apresentará os conceitos principais de SBA tendo como base as implementações do GigaSpaces XAP. Space O space é um In-Memory-Data-Grid (IMDB), ou seja, é uma tecnologia que permite que os dados sejam armazenados em memória e distribuídos em um conjunto de máquinas (cluster). Assim, a aplicação não se comunicará diretamente com o banco e sim com o space, interagindo com o mesmo por meio das APIs disponíveis. Com isso, temos leituras e escritas extremamente rápidas, além dos benefícios da confiabilidade e da tolerância a falhas conseguidos por meio da replicação de dados que acontece entre as instâncias dos spaces no cluster. Também é possível ter mecanismos de persistência para fontes externas (caso seja necessário) usando um serviço de mirror que é assíncrono e executa em segundo plano. Embora a ideia seja utilizar o space como elemento principal para leitura e escrita na aplicação, em alguns casos pode ser interessante utilizá-lo apenas como cache de segundo nível do framework de ORM (geralmente Hibernate). Mesmo nesse caso, os benefícios 59 \

5 são muitos, já que é possível ter cache distribuído e replicado sem muito esforço. Topologias O space pode assumir diversas topologias, de acordo com a necessidade da aplicação, podendo ser uma única instância executando em uma única JVM ou múltiplas instâncias em múltiplas JVMs. De uma maneira geral os dados podem estar replicados ou particionados. No primeiro, há cópias dos dados em todas as instâncias do cluster. No segundo caso, os dados são divididos e cada instância do cluster fica com um subconjunto diferente. Para o caso onde os dados são particionados, ainda é possível definir uma ou mais instâncias de backup para cada partição. A Figura 4 ilustra o espaço particionado. Veja que o space é dividido em múltiplas partições e cada partição está em uma JVM diferente. A Figura 5 ilustra o espaço particionado com backup. Para cada partição um backup é criado e colocado em uma JVM diferente. Os dados escritos na partição primária são então replicados para a partição de backup (geralmente de maneira assíncrona). Na Figura 6 está ilustrado o espaço replicado. Veja que cada instância do espaço contém os mesmos dados. Os mecanismos de replicação se aplicam tanto para o caso em que o espaço é particionado com backup quanto para o caso em que o espaço é replicado. No primeiro, os dados são replicados da instância primária para a instância de backup. Quando o space é replicado, a replicação acontece entre as instâncias do space. A replicação pode ser síncrona ou assíncrona. Para o caso síncrono, a operação é concretizada apenas quando o dado é replicado em todas as instâncias do espaço, podendo haver perda de desempenho. Já no caso assíncrono, ou processo executado por uma thread diferente e com isso a aplicação cliente não é bloqueada. O space pode ficar tanto remoto quanto embutido na aplicação. No caso do space ser remoto, todas as operações geram tráfego de rede e serialização, já que o space está em outra máquina virtual na rede. Para os casos em que o space está dentro da aplicação, o desempenho melhora, já que a latência é menor pelo fato de não serem necessárias chamadas de rede e serializações. Instalando o GigaSpaces XAP 1. Para fazer o download do XAP siga para o seguinte endereço: 2. Escolha a Premium Edition, preencha o formulário e cadastre-se para ter acesso ao download. 3. Descompacte o arquivo em um diretório de sua preferência. Figura 4. Espaço particionado. Figura 5. Espaço particionado com backup. Figura 6. Espaço replicado. / 60

6 4. Para iniciar o XAP, vá para a pasta onde o GigaSpaces XAP está descompactado (GS_HOME no meu caso é C:\gigaspaces-xap-premium ga), naveque até a pasta /bin e execute o arquivo gs-agent.[bat/sh]. Este script iniciará os elementos principais do GigaSpaces, a ver: a. 2 instâncias de GSC elementos semelhantes ao servidor de aplicações. b. 1 instância de GSA é o elemento principal do GigaSpaces. Controla todos os outros elementos em nível de processo. c. 1 instância de GSM é o elemento que controla os SLAs da aplicação. d. 1 instância de LUS Lookup Service é o serviço de lookup. 5. Inicie a interface administrativa. O GigaSpaces disponibiliza duas interfaces administrativas. A Management UI é uma aplicação Java que vem junto com o GigaSpaces e que serve como interface local de administração do ambiente. A Web Management UI é uma aplicação Web que tem o mesmo propósito. Nessas ferramentas, é possível fazer deploys de Processing Units (PUs) e spaces, monitorar as atividades gerais do space, ver estatísticas sobre as operações (leituras, escritas etc.), além de gerenciar os componentes principais do GigaSpaces (gsa, gsm, lus etc.). Para iniciar o Management UI e o Web Management UI, vá até a pasta raiz do GigaSpaces, depois entre no diretório bin e execute os scripts gs-ui.[bat/sh] e gs-webui. [bat/sh], respectivamente. A Erro: Origem da referência não encontrada ilustra a interface do Management UI. maneiras. Dentre elas podemos citar: 1. Deploy do space por meio da Management UI ou Web Management UI. a. Inicie o gs-ui chamando o script gs- -ui.bat ou gs-ui.sh que estão dentro da pasta bin do diretório raiz do GigaSpaces ($GS_HOME/bin/gs-ui.[bat/sh]); Agora clique no segundo ícone da esquerda para direita (Deploy In-Memory Data Grid) b. Na caixa de diálogo que aparecer, preencha o nome do data grid, o número de instâncias e número de backups para cada instância, o tipo do cluster (cluster schema define a topologia do espaço). Veja o exemplo da Figura 8. Ao final, é possível ver as instâncias do espaço na primeira tela do Management UI. Figura 8. Fazendo deploy do Space. c. Para analisar o espaço com mais detalhes, clique na aba Deployed Processing Units. Nesta tela é possível ver as estatísticas do espaço, como leituras, escritas etc. Também podemos efetuar queries por objetos que estão no espaço. A Figura 9 ilustra as estatísticas do space. Figura 7. Tela de administração do GigaSpaces XAP. Pronto! O próximo passo consiste em fazer o deploy de uma instância de space, para que depois possamos criar códigos para salvar, ler, atualizar e apagar objetos do space. Interagindo com o space O space pode ser criado e instanciado de diversas Figura 9. Estatísticas do space. 61 \

7 4. Via Spring O space pode instanciar dentro da sua aplicação (Processing Unit) em um arquivo chamado pu.xml. Este arquivo é na verdade um arquivo xml de configuração do Spring. Assim, o space pode ser criado tanto por meio dos namespaces do Gigaspaces quanto por meio dos beans padrão do Spring. Segue um exemplo de criação do space seguindo o namespace do Gigaspaces: <os-core:space id= space url= /./mundoj /> Agora usando o Spring plain (sem o uso de namespaces): <bean id= space class= org.openspaces.core.space. UrlSpaceFactoryBean > <property name= url value= jini:/*/*/mundoj /> </bean> No primeiro caso o space é local à aplicação, ou seja, está intrínseco à mesma. Isso é definido pela URL do space. Neste caso, o prefixo /./ indica que o space é local. Já no segundo caso, o prefixo jini:// indica a configuração de um space remoto. Para configurar a topologia do space, utiliza-se o arquivo sla.xml, que fica dentro da PU junto com o arquivo pu.xml. Segue um exemplo de configuração de topologia usando tal arquivo. <os-sla:sla cluster-schema= partitionedsync2backup number-of-instances= 2 number-ofbackups= 1 /> Também é possível criar o space programaticamente ou fazendo o deploy via linha de comando. Para mais detalhes, consulte a documentação do GigaSpaces. Com o space disponível no cluster, utilizamos a interface GigaSpace para realizar as operações, que podem ser: Read ler objetos do space. Os critérios podem ser via templates, queries sql ou com base nos ids dos objetos. A API disponibiliza algumas opções para leitura de dados, tais como: read, readmultiple (leitura em batch), readbyid/readbyids, e a leitura assíncrona com o asyncread. Write Permite escrever ou atualizar objetos no space. Na escrita é possível determinar o tempo no qual o objeto ficará no space pelo uso do LeaseTime. Quando o lease time expira, o objeto é removido do space. Take A operação take é semelhante à leitura. Contudo, em vez de apenas retornar o objeto lido, o take também remove o objeto do space. Clear Remove o objeto do space sem retorná-lo ao cliente. Uma instância de GigaSpace pode ser criada de duas maneiras: 1. Usando Spring pode-se usar tanto os namespaces do GigaSpaces quanto os beans padrão do Spring. Exemplo de configuração usando namespaces: <os-core:space id= space url= jini://*/*/mundoj /> <os-core:giga-space id= gigaspace space= space /> Exemplo de configuração plain : <bean id= space class= org.openspaces.core.space.urlspacefactorybean > <property name= url value= jini:/*/*/mundoj /> </bean> <bean id= gigaspace class= org.openspaces.core.gigaspacefactorybean > <property name= Space ref= space /> </bean> 2. Programaticamente: IJSpace space = new UrlSpaceConfigurer( jini://*/*/mundoj ).space(); GigaSpace gigaspace = new GigaSpaceConfigurer(space). gigaspace(); Ou simplesmente: Uma característica bem interessante do GigaSpaces XAP é a capacidade de se auto recuperar (self healing) quando algum problema ocorre com a aplicação (Processing Unit - PU). O GigaSpaces executa as aplicações em containers (estrutura semelhante ao servidor de aplicações). Caso algum container pare de responder, automaticamente o GigaSpaces iniciará uma nova instância da aplicação em outro container. No site da GigaSpaces há um exemplo interessante que demonstra essa e outras funcionalidades. Veja em Your+First+Web+Application. / 62

8 IJSpace space = new UrlSpaceConfigurer( jini://*/*/mundoj ).space(); GigaSpace gigaspace = new GigaSpaceConfigurer(space). gigaspace(); GigaSpace gigaspace = new GigaSpaceConfigurer( new UrlSpaceConfigurer( jini://*/*/mundoj )).gigaspace(); Exemplo completo de uso da API A Listagem 1 ilustra algumas operações básicas de interação com o space. O intuito desse código não é mostrar todas as funcionalidades da GigaSpaces XAP, mas sim apresentar o básico da API. Outras funcionalidades como self healing, mensageria, processamento de eventos e balanceamento de carga automático podem ser testadas nos exemplos disponíveis no site da GigaSpaces. O código completo dessa listagem pode ser baixado do site da revista. Listagem 1. Exemplo de uso da API do GigaSpaces. public class TestandoSBA { // URL do espaço. Neste caso, estamos conectando ao // um space remoto private static final String SPACE_URL = jini://*/*/mundoj ; public static void main(string[] args) { // criando uma instância do space GigaSpace gigaspace = getgigaspaces(space_url); // Criando um objeto do tipo Pessoa Pessoa graciliano = new Pessoa(1, Graciliano Ramos, ); // salvando o objeto p1 no space com um lease // time de 15 segundos // Após os 15 segundos o objeto expira do space gigaspace.write(graciliano, 15000l); // Criando um template para buscar o objeto que foi // salvo Pessoa template = new Pessoa(); template.setnome( Graciliano Ramos ); // usando o template para buscar o objeto no space Pessoa pessoa1 = gigaspace.read(template); if (pessoa1!= null) { // tostring sobrescrito System.out.println( Pessoa 1: + pessoa1); else { System.out.println( Pessoa nao encontrada... ); A classe Pessoa é um POJO com algumas anotações do GigaSpaces. A indica que determinado atributo representará o Id de objetos daquela classe no space. Já a indica que aquele atributo será usado para fazer o roteamento de objetos daquela classe nas partições do space. Isso porque o GigaSpaces usa uma estratégia de roteamento baseada em conteúdo. Basta anotar o atributo SpaceRouting e o GigaSpaces usará o valor do atributo para determinar em que partição do space um objeto ficará. E isso simplifica bastante as coisas! A Listagem 2 apresenta uma parte da classe Pessoa. Listagem 2. A classe public class Pessoa implements Serializable { private static final long serialversionuid = L; private Integer id; private String nome; private String = public Integer getid() { return id; //... A Listagem 3 mostra o método getgigaspaces. Veja que neste caso estamos conectando em um space remoto, ou seja, você deve fazer o deploy de um space chamado mundoj antes de executar o exemplo. Listagem 3. Criando uma instância de GigaSpaces. private static GigaSpace getgigaspaces(string spaceurl) { UrlSpaceConfigurer space = new UrlSpaceConfigurer(spaceURL); // para realizar operações no space, é necessário criar // uma instância de // GigaSpace GigaSpace gigaspace = new GigaSpaceConfigurer(space).gigaSpace(); return gigaspace; Siga os passos descritos abaixo para executar o código descrito neste artigo. 1. Instale e inicie o GigaSpaces conforme já explicado anteriormente. 2. Inicie o gs-ui.[bat/sh] e faça o deploy de um space com os seguintes parâmetros: Data Grid name: mundoj; Space Schema: java space; Cluster schema: partitioned-sync2backup; Number of Instances: 2; Backups: 1; Deixe os outros campos com os valores padrão e em seguida clique em Deploy. 3. Baixe o código de exemplo do site da revista e 63 \

9 Para criar uma variável no Eclipse vá ao menu Window, em seguida, clique em Preferences. No menu da esquerda navegue na árvore até Java > Build Path > Classpath Variables, ou simplesmente digite Classpath Variables na caixa de busca no canto esquerdo da tela. Depois clique em New. No campo de texto name, digite GS_HOME. Clique em folder e selecione a pasta do GigaSpaces (ex: C:\gigaspaces-xap-premium ga ). Clique em OK. Na tela inicial clique em OK novamente e pronto! descompacte-o em um diretório de sua preferência. 4. Abra o Eclipse e importe o projeto MundoJGigaSpaces. Adicione uma nova variável de ambiente chamada GS_HOME que aponte para a pasta onde o GigaSpaces está instalado. No meu caso essa variável está com o valor C:\ gigaspaces-xap-premium ga. 5. Abra a classe TestandoSBA e execute-a dentro do Eclipse mesmo. Considerações finais Este artigo apresentou a Arquitetura Baseada em Espaços e um exemplo básico utilizando uma implementação chamada GigaSpaces XAP. Inicialmente, foram discutidas algumas desvantagens da arquitetura multicamadas. Em seguida, a arquitetura baseada em espaços foi apresentada como uma possível solução para alguns desses problemas. Finalmente, o GigaSpaces XAP foi utilizado para apresentar os conceitos de arquiteturas baseadas em espaços e um exemplo básico de uso da API foi mostrado. É importante ressaltar que para a maioria das aplicações a arquitetura multicamadas ainda é a mais indicada. Contudo, os novos modelos de desenvolvimento de aplicações para a Nuvem exigem que as aplicações sejam reestruturadas e é nesse cenário que a arquitetura baseada em espaços se mostra importante. /referências > Site do GigaSpaces > Artigo: From the dead end to the open road The Scalability Revolution. com/wiki/download/attachments/ / FromDeadEndToOpenRoad.pdf > SBA na Wikipédia / 64