O Magic xpi versão 4 está disponível, para download.
É uma nova versão (major release) Magic xpi, com novidades!
Vamos ver as principais.
Primeiro, vamos às…
Boas Notícias
O Studio do Magic xpi 4 é o mesmo que você já conhecia na versão 3:
Assim como sua biblioteca de componentes e serviços:
E o Monitor:
Isso significa que não há necessidade de nenhum investimento adicional em treinamento ou reciclagem, para desenvolver projetos com o novo Magic xpi (como foi necessário na passagem da versão 2.5 para a 3x).
Um projeto na versão 3x precisa ser convertido para a versão 4x, mas isso é um processo automático na abertura do projeto no novo Studio:
Ou seja, tudo muito simples e direto.
NOTA: a biblioteca de componentes de integração/automação está sempre em constante evolução, e a adição de novos não está atrelada a nenhuma versão específica. Qualquer novo service pack pode trazer novidades na biblioteca.
Ok. Agora vamos às…
Excelentes Notícias
O Magic xpi versão 4 vem integrado ao GigaSpace (XAP 9.1.2), uma plataforma ‘cloud ready’ para aplicações (In-Memory DataGrid, Big Data, Clusters, etc…).
Essa mudança é significativa, porém, tem a ver com os bastidores dos projetos.
O GigaSpace está ocupando o espaço que antes era do Magic Broker, e obviamente, adicionando muitos novos recursos. O Magic Broker ainda existe (ele até é instalado), mas não é mais utilizado. uniRQBroker.exe e mgrb.ini não possuem mais função na execução dos projetos Magic xpi. Consulte o documento de release da versão 4, para conhecer mais sobre esta arquitetura nova.
O GigaSpace permite montar um grid de ambientes de execução, onde cada bloco deste grid é chamado Space. No caso dos projetos Magic xpi, Magic Space. Ele permite que este grid seja composto por máquinas diferentes, por exemplo, criando assim um cluster de processamento. O Space pode ser primário, para execução, ou de backup, para assumir a execução em caso de falha no primário.
Novos horizontes de:
- Escalabilidade
- Alta Disponibilidade
- Fail-Over System
surgem com esta nova arquitetura.
Mas não se assuste. Tudo continua simples :-).
Vejamos:
Instalação
O procedimento de instalação é exatamente o mesmo. Apenas uma nova tela surge no InstallShield, para informarmos detalhes a respeito do GigaSpace:
A instalação e configuração padrão do GigaSpace é toda feita automaticamente durante a instalação do Magic xpi.
NOTA: Opte por instalar o GSA como “serviço”, mesmo em máquinas de desenvolvimento/homologação. O “debugger” do Magic xpi Studio não executará se este serviço não estiver executando. Muito menos, o server J. Mas você pode deixar o serviço como “manual” nas máquinas de testes/desenvolvimento, iniciando-o apenas quando necessário. Tenha em mente que o ‘grid’ leva um tempo até ser montado, que pode variar de segundos a minutos. Nenhum projeto iniciará sua execução enquanto o ‘grid’ não estiver montado.
Ambiente
Nós iremos perceber algumas pastas novas na instalação do Magic xpi, justamente referente ao GigaSpace.
O GigaSpace, que a propósito é um produto na plataforma JAVA, possui o seu próprio Monitor:
A configuração padrão do grid são 4 Spaces, sendo 2 primários e 2 backups, divididos em 2 contêineres (gsc). Todos num única máquina/estação/servidor.
Essa provavelmente será nossa configuração na maioria das situações, mas lembre-se: podemos aumentar o grid e também montá-lo em cluster, se necessário.
O serviço criado não é mais do Magic Broker (ele não é mais utilizado). Agora, o serviço é na verdade o GigaSpace.
Antes, tínhamos que registrar a lista de projetos que deveriam iniciar automaticamente no arquivo ‘mgrb.ini’, para que o Magic Broker iniciasse-os durante seu próprio startup.
O conceito permanece o mesmo, mas agora temos de listar estes projetos num arquivo chamado ‘projectsStartup.xml’ na pasta ‘config’, para que o GigaSpace inicie-os durante o seu startup (e após a conclusão da montagem do grid).
Uma outra coisa que mudou significativamente, é em relação aos ‘requesters’.
O conteúdo da pasta ‘Scripts’ do Magic xpi está bastante alterado:
Os antigos ‘requesters’ ISAPI e CGI não mais existem, e o novo ‘requester’ MgWebRequester.dll agora é uma aplicação ASP.NET:
Todas as requisições externas (HTTP, SOAP, REST, etc…) agora precisam ser direcionadas ao GigaSpace, e não mais ao Magic Broker (ele não é mais utilizado). Por isso a necessidade de novos ‘requesters’. Isto suscita 3 observações importantes:
- URLs de sites ou outros sistemas que antes apontavam para os antigos ‘requesters’ (mgrqispi.dll ou mgrqcgi.exe) precisam ser ajustadas para usar o novo ‘requester’ (MgWebRequester.dll), nos projetos migrados da versão 3x.
- Como o novo ‘requester’ disponível (MgWebRequester.dll) é uma aplicação ASP.NET, o webServer compatível com o Magic xpi 4 por enquanto é apenas o IIS.
O novo ‘requester’ disponível (MgWebRequester.dll) está salvo numa pasta chamada ‘bin’. Por padrão, o IIS bloqueia o acesso a pastas com este nome. Por isso, é preciso ir até a Filtragem de Solicitações desta aplicação:
E remover o nome ‘bin’ da lista de segmentos ocultos:
O suporte aos webServices SOAP (consumo ou provimento) permanece sendo através do SSJ 6.6. Sua instalação continua sendo realizada juntamente (automaticamente) com a instalação do Magic xpi. Porém, com alguns componentes .JARs e configurações adicionais. Isto está detalhado neste outro post do blog.
Execução dos Projetos
A inicialização dos projetos continua podendo ser de três formas:
- Automática
- Manual
- Debugger
“Automática” é através de configuração do arquivo ‘projectsStartup.xml’, descrita acima. Quando o grid GigaSpace inicia, todos os projetos Magic xpi iniciam também. Vários projetos podem ser especificados neste arquivo (assim como era com o ‘mgrb.ini’).
“Debugger” é a ativação de depuração, via Magic xpi Studio.
“Manual” é através dos atalhos ‘Start’ e ‘Stop’ na pasta de cada projeto.
NOTA: Independente de qual forma escolher, o serviço do GigaSpace precisa estar executando para que o projeto Magic xpi execute também.
Os atalhos ‘Start’ e ‘Stop’ são normalmente gerados na pasta de cada projeto:
mas o seu conteúdo é totalmente diferente. Eles agora enviam comandos para o GigaSpace, para iniciar ou parar este projeto específico. E nesta etapa entra em cena um novo arquivo de configuração: o ‘Start.xml’.
Este arquivo contém instruções ao GigaSpace sobre o projeto que precisa ser executado. Em especial, uma configuração precisa ser manualmente ajustada: NumberOfWorkers:
Esta configuração deve ser igual ao total de filas da licença (Magic xpi) em uso. Ou igual ao total de filas reservadas com MaxConcurrentRequests. Exemplo:
- O projeto usará uma licença de 8 filas. NumberOfWorkers deve ser ajustado em 8.
- O projeto usará uma licença de 20 filas, mas o IFS.INI do projeto está com ‘MaxConcurrentRequests’ definido em 7. NumberOfWorkers deve ser ajustado em 7.
Outro detalhe importante, são as configurações “ProjectsDirPath” e “Server”. São dados simples, mas que variam de ambiente para ambiente.
É importante atentar para isso quando se transfere/copia um projeto Magic xpi 4 para uma máquina, diferente daquela onde ele foi criado. Se estas configurações não estiverem condizentes com o ambiente, o projeto não executará.
Fora estes pequenos ajustes, não há mistério. Tendo o GigaSpace em execução, aciona-se o atalho ‘Start’ e o projeto inicia:
Como mencionamos logo no início, o Magic xpi Monitor permanece o mesmo.
Mas ele possui uma novidade:
Advanced Monitoring Console
É uma visualização nova que extrai informações on-line diretamente do GigaSpace, sobre o projeto em execução:
Bom, estas são as primeiras impressões e novidades do novo Magic xpi versão 4.
Acesse a página da Magic Community e leia mais sobre os upgrades da versão 3x para o novo 4x.
