(agora com GigaSpaces)
Desde a versão 3 do Magic xpi, quando ainda se chamava iBolt, o WSO2 é o framework oficial para as interfaces SOAP dos produtos Magic.
Desenvolvido em Java versão 6, originalmente pela Hewlett-Packard (ainda com o nome de SystInet), o WSO2 é usado tanto nas interfaces de “consumo” quanto de “provimento” de webServices SOAP. E esta estrutura permanece na versão 4 do Magic xpi.
A instalação do WSO2 normalmente é um processo automático durante a instalação do próprio Magic xpi:
Mas é possível também fazê-la de forma manual e independente cfe. dicas encontradas nestes dois endereços:
Para o “consumo” de webServices, o Magic xpi necessita que o WSO2 esteja instalado e acessível ao Magic xpi Server, Studio e Monitor. O Magic xpi localiza a instalação do WSO2 através da variável de ambiente %WASP_HOME%:
Atualmente na versão 4, o Magic xpi também necessita desta instalação para que o Monitor possa consultar as informações do GigaSpaces.
Para o “provimento” de webServices, além da instalação acima é necessário também que o WSO2 Server esteja executando, pois é ele quem recebe as solicitações SOAP externas e repassa-as ao Magic xpi:
Quando o Magic xpi provê um webService SOAP, uma classe Java (proxy) é gerada para este serviço segundo a API do WSO2:
Esta classe Java por sua vez, precisa ser implantada (deployed) no WSO2 Server:
Desta forma o webservice SOAP fica exposto através do WSO2 Server, que repassa as chamadas externas ao Magic xpi através das regras codificadas na classe Java do serviço.
O que talvez passe despercebido na maioria das vezes, é que não é obrigatório que o WSO2 Server esteja executando exatamente na mesma máquina do Magic xpi Server.
E é sobre isso que iremos tratar a seguir. Iremos mostrar uma arquitetura onde o WSO2 Server estará executando em um servidor diferente e em um sistema operacional diferente. No nosso exemplo, teremos o Magic xpi Server + GigaSpaces num servidor “A” MS-Windows e o WSO2 Server num servidor “B” Linux.
Ter o WSO2 Server em servidor separado tem seus atrativos.
Nós podemos ter ‘n’ servidores WSO2, independente de quantas máquinas estarão agregadas ao MAGIC_SPACE, sem sobrecarregar o processamento das máquinas que executam o Magic xpi Server:
A instalação do Magic xpi Server + GigaSpaces não será abordada aqui, visto que se trata de uma instalação padrão. Passaremos então diretamente para a instalação do WSO2 Server no Linux. Usaremos o Linux CentOS 5.9:
Pré-Requisitos
Antes de realizar a instalação do WSO2, é preciso que o Linux possua o Java versão 6:
A pasta de instalação do Java versão 6 também precisa estar referenciada nas variáveis de ambiente $JAVA_HOME e $PATH:
O pacote de instalação do WSO2 é disponibilizado na pasta do Magic xpi:
E deve ser copiado para alguma pasta do servidor Linux:
E por último, estes servidores precisam estar conectados de forma que consigam conversar entre si através do protocolo TCP, se possível sem firewalls entre eles.
Instalação
A instalação do WSO2 é iniciada executando-se o comando:
java -jar wso2-soa-enablement-server-java-6.6.jar
A instalação é interativa e a maioria dos valores sugeridos podem ser acatados, como pasta de instalação, portas de comunicação, etc.
O importante é selecionar a opção “server” e “install security support”:
Após a confirmação das opções no assistente de instalação, o WSO2 estará instalado no servidor Linux:
Configuração
O próximo passo é definir a variável de ambiente $WASP_HOME apontando para esta pasta de instalação:
Para que o WSO2 possa efetivamente se comunicar com o GigaSpaces e com o Magic xpi, algumas classes customizadas precisam ser adicionadas à instalação. Elas estão disponíveis na instalação do Magic xpi e devem ser copiadas para a nova instalação do WSO2 no Linux cfe. abaixo:
<Magicxpi_home>\support\uniSSJ.jar “$WASP_HOME”/lib/
<Magicxpi_home>\support\uniRequester.jar “$WASP_HOME”/lib/
<Magicxpi_home>\support\saaj_utils.jar “$WASP_HOME”/lib/
<Magicxpi_home>\support\edevUtils.jar “$WASP_HOME”/lib/
<Magicxpi_home>\support\uniUtils.jar “$WASP_HOME”/lib/
<Magicxpi_home>\java\lib\mgxpi-commons.jar "$WASP_HOME”/lib/
<Magicxpi_home>\java\lib\log4j-1.2.16.jar “$WASP_HOME”/lib/log4j.jar
<Magicxpi_home>\java\lib\mgxpi-gs.jar “$WASP_HOME”/lib/GigaSpaces/
<Magicxpi_home>\GigaSpaces\lib\required\*.* “$WASP_HOME”/lib/GigaSpaces/
NOTA: Os detalhes sobre estas classes a serem copiadas estão também disponíveis neste endereço.
O resultado deverá ser similar a este:
Finalizada a cópia, o arquivo “server.sh” localizado na pasta $WASP_HOME/bin deve ser editado. Após a linha de execução do programa “env.sh” devem ser adicionadas as seguintes configurações:
WASP_CLASSPATH="$WASP_HOME":"$WASP_HOME"/lib/uniSSJ.jar:"$WASP_HOME"/lib/uniRequester.jar:"$WASP_HOME"/lib/saaj_utils.jar:"$WASP_HOME"/lib/mgxpi-commons.jar:"$WASP_HOME"/lib/GigaSpaces/com.springsource.org.aopalliance-1.0.0.jar:"$WASP_HOME"/lib/GigaSpaces/commons-logging.jar:"$WASP_HOME"/lib/GigaSpaces/dsl.jar:"$WASP_HOME"/lib/GigaSpaces/gs-openspaces.jar:"$WASP_HOME"/lib/GigaSpaces/gs-runtime.jar:"$WASP_HOME"/lib/GigaSpaces/org.springframework.aop-3.1.1.RELEASE.jar:"$WASP_HOME"/lib/GigaSpaces/org.springframework.asm-3.1.1.RELEASE.jar:"$WASP_HOME"/lib/GigaSpaces/org.springframework.aspects-3.1.1.RELEASE.jar:"$WASP_HOME"/lib/GigaSpaces/org.springframework.beans-3.1.1.RELEASE.jar:"$WASP_HOME"/lib/GigaSpaces/org.springframework.context.support-3.1.1.RELEASE.jar:"$WASP_HOME"/lib/GigaSpaces/org.springframework.context-3.1.1.RELEASE.jar:"$WASP_HOME"/lib/GigaSpaces/org.springframework.core-3.1.1.RELEASE.jar:"$WASP_HOME"/lib/GigaSpaces/org.springframework.expression-3.1.1.RELEASE.jar:"$WASP_HOME"/lib/GigaSpaces/org.springframework.transaction-3.1.1.RELEASE.jar:"$WASP_HOME"/lib/GigaSpaces/mgxpi-gs.jar:
export WASP_CLASSPATH
E na linha iniciada por “$JAVA_CMD” devemos adicionar a configuração:
-Dcom.magicsoftware.requester.conf=”$WASP_HOME”/mgreq.ini
O argumento -Dcom.magicsoftware.requester.conf deve ser informado antes do argumento -Dtorun=com.idoox.wasp.server.Main.
Também devemos garantir que “$WASP_CLASSPATH” esteja mencionada no argument -cp.
Observe que este argumento (-Dcom.magicsoftware.requester.conf) se refere a um arquivo que não existe.
Devemos agora criar o arquivo “mgreq.ini” na pasta $WASP_HOME:
O conteúdo deste arquivo pode ser copiado do mesmo arquivo “mgreq.ini” que está na pasta de instalação do Magic xpi:
O importante aqui é que as informações de conexão ao GigaSpaces estejam corretas.
Para finalizar, temos de atribuir alguns acessos às pastas/arquivos do WSO2 para permitir execução sob as credenciais de outros usuários, além daquele que realizou a instalação:
chmod 777 $WASP_HOME/log
chmod 777 $WASP_HOME/log/*
chmod 775 $WASP_HOME/store/hsqldb
chmod 777 $WASP_HOME/store/hsqldb/*
chmod 775 $WASP_HOME
chmod 777 $WASP_HOME/app
chmod 777 $WASP_HOME/app/*
chmod 777 $WASP_HOME/Work
Execução
Finalizada a instalação e configuração, o WSO2 Server pode ser iniciando executando-se o programa “serverstart.sh” na pasta $WASP_HOME/bin:
NOTA: Em ambiente normal de produção, este programa deverá ser definido como um daemon do Linux, para inicialização automática.
Testando a Arquitetura
Como dito anteriormente, as classes Java dos webServices providos pelo Magic xpi devem ser implantadas (deployed) no WSO2 Server, que neste caso está em nosso servidor Linux:
Depois, é necessário apenas que os clientes (consumidores) destes serviços direcionem suas chamadas para este servidor Linux.:
E está pronto: o cliente envia sua solicitação através de um envelope SOAP para o WSO2 Server no Linux, que gera uma WorkMessage no MAGIC_SPACE que está no MS-Windows, que é atendida por um Worker do Magic xpi Server também no MS-Windows, e retorna a resposta para o cliente:
