Há algum tempo a Magic Software lançou uma novidade na sua plataforma de desenvolvimento de aplicações (Magic xpa): uma nova ferramenta de middleware: GigaSpaces, com a capacidade de processamento de dados em memória (IMDG).
Vamos conhecer um pouco mais sobre isto.
As soluções de arquitetura servidora do Magic xpa: Enterprise Server, RIA ou Web, tem em comum a presença de três componentes centrais:
O Requester, que é quem fica exposto aos clientes externos e é diretamente acessível (utilizável) por eles
O Application Server (App Server), que é o engine/runtime Magic xpa que será acionado para execução das rotinas com as regras de negócio e acesso às bases de dados/recursos
O Middleware, que faz a ponte (conexão) entre o Requester e o App Server.
Como estes componentes podem fisicamente residir em ambientes distintos, esta separação é que traz o predicado de “Ambiente Distribuído” às soluções Magic xpa.
Vejamos então as opções de middleware:
Magic Broker como middleware
Opção tradicional desde o antigo Magic 8, é um produto próprio da Magic Software, 32/64 bits, e funciona no sistema PUSH de mensageria:
As mensagens recebidas pelo Requester são transferidas ao “Broker“, que as distribui (empurra) até o App Server.
O Broker é um middleware mais “leve”, que demanda menos hardware (memória e CPU).
GigaSpace XAP como middleware
Opção mais recente, introduzida no Magic xpa 3.0, é um produto de terceiros e distribuído pela Magic Software no formato OEM, Todo desenhado em Java, aceita JVMs 32 bits e 64 bits, e funciona no sistema PULL de mensageria:
As mensagens recebidas pelo Requester são transferidas ao “GigaSpaces” que as retém. O App Server consulta continuamente o middleware, e na existência de novas mensagens, ele as “puxa” e processa.
O GigaSpaces também entrega alta disponibilidade, clustering , load balancing e habilidade na manipulação de grandes volumes de dados e transações (mensagens).
O GigaSpaces é um middleware mais “pesado”, que demanda mais hardware (memória e CPU).
Nós temos então o poder da escolha. Executar nossas aplicações com nosso velho e conhecido Broker ou desfrutar de todas as novidades do GigaSpaces.
Neste post vamos mostrar como configurar seu servidor para execução das aplicações com os dois midlewares: GigaSpaces e Broker, em um ambiente de “produção”.
Usando o Broker
Toda a configuração é centralizada no arquivo “MGRB.INI” que fica na pasta raiz da instalação do Magic xpa.
Se desejar usar um arquivo diferente também é possível, mas é preciso ajustar as parametrizações do serviço no SO:
Os detalhes da estrutura do arquivo MGRB.INI podem ser conhecidos aqui. Neste momento, a seção que nos interessa é a [APPLICATIONS_LIST].
APPNAME=<command>,[<work dir>],[<OS username>], [<OS password>],[<number of times to perform upon broker initialization>],[<maximum number of engines supporting the application to launch on demand>]
Por exemplo:
HelloWorld = MgxpaRuntime.exe /DeploymentMode=B /LicenseName=MGRIA /StartApplication=Projects\HelloWorld\HelloWorld.ecf,,,,1,0
Aqui definimos uma aplicação de nome “HelloWorld“, a ser servida pelo AppServer (MgxpaRuntime.exe) Magic em modo “Background“, usando uma licença “RIA” e abrindo o sistema/aplicação “HelloWorld.ecf“. Um (1) único App Server será carregado na inicialização, e nenhum (0) App Server adicional será carregado quando houver sobrecarga de trabalho deste primeiro. Como não foram informados <OS username> e <OS password>, este App Server executará com as mesmas credenciais (conta) do serviço do Broker, que neste exemplo, é o LocalSystem.
NOTA: Uma conta de domínio pode ser necessária, aqui ou diretamente no serviço do SO, quando o App Server precisar acessar recursos de outras máquinas. Além disso, drives mapeados (G:, V:, …) normalmente não podem ser acessados por serviços. Deve-se então usar o nomes UNC destas pastas (\\<servidor>\<driveG>\, \\<servidor>\<driveV>\, …).
Quando o serviço do Broker inicia, ele executa automaticamente os App Servers configurados no [APPLICATIONS_LIST]:
Múltiplas entradas em [APPLICATIONS_LIST] permitem subir múltiplos projetos no mesmo Broker.
Podemos monitorar (acompanhar) estes App Servers trabalhando, através do Broker Monitor:
O Magic xpa possui três Requesters principais:
MGrqcgi.exe (CGI)
MGrqispi.dll (ISAPI)
MGWebRequester.dll (ASP.NET)
Todos instalados e configurados também por default, no IIS.
Quando o middleware escolhido é o “Broker“, os Requesters a serem utilizados (que podem se comunicar com ele) são o ISAPI (MGrqispi.dll) ou o CGI (MGrqcgi.exe) apenas.
Isso deve ser ajustado em todo sistema cliente que for acessar o Magic xpa Server, bem como no arquivo “MAGIC.INI”, na seção [MAGIC_ENV]InternetDispatcherPath
Exemplo:
Usando o GigaSpace
Toda a configuração é centralizada no arquivo “GigaSpaces-xpa\config\projectsStartup.xml” que fica na pasta raiz da instalação do Magic xpa.
Os detalhes da estrutura do arquivo projectsStartup.xml podem ser conhecidos aqui. Neste momento, os nós que nos interessam são <Project> e <Server>.
<Project Name="{nome_projeto}"
StartApplication="{ecf_a_carregar}"
CMDLineArgs="{argumentos_engine/runtime_appserver}"
ReservedUsersLicenses="{reserva_da_licenca}"
ReservedThreadsLicenses="{reserva_da_licenca}">
<Servers>
<Server host="{nome_servidor_onde_executar}">
<NumberOfInstances AdditionalOnDemand="{instancias_extras}">{instancias}</NumberOfInstances>
<NumberOfWorkers>{workers_de_pooling}</NumberOfWorkers>
<StartApplication></StartApplication>
<CMDLineArgs></CMDLineArgs>
</Server>
</Servers>
</Project>
Exemplo:
<Project Name="HelloWorld"
StartApplication="C:\MSE\Magic\xpa\3.3a\Projects\HelloWorld\HelloWorld.ecf"
CMDLineArgs="/DeploymentMode=B /LicenseName=MGRIA "
ReservedUsersLicenses="0"
ReservedThreadsLicenses="0">
<Servers>
<Server host="SERENNO">
<NumberOfInstances AdditionalOnDemand="0">1</NumberOfInstances>
<NumberOfWorkers>5</NumberOfWorkers>
<StartApplication></StartApplication>
<CMDLineArgs></CMDLineArgs>
</Server>
</Servers>
</Project>
Aqui definimos uma aplicação de nome “HelloWorld“, a ser servida pelo AppServer (MgxpaRuntime.exe) Magic em modo “Background“, usando uma licença “RIA” e abrindo o sistema/aplicação “HelloWorld.ecf“. Um (1) único App Server será carregado na inicialização e executará no servidor de nome “SERENNO“. Nenhum (0) App Server adicional será carregado quando houver sobrecarga de trabalho deste primeiro. Este App Server executará com as mesmas credenciais (conta) do serviço do GigaSpaces, que neste exemplo, é o LocalSystem.
Nenhuma (0) quantidade de threads ou usuários estará sendo reservada exclusivamente para este App Server, a partir da licença em uso.
Um total de cinco (5) workers serão criados no App Server e ficarão consultando o GigaSpaces de forma recorrente (pooling) para saber se há alguma mensagem a ser processada.
O nó <Server> é importante também, porque num ambiente de “cluster” do GigaSpaces por exemplo, é com ele que definimos em quais máquinas (servidores) desejaremos executar os App Servers. Sem “cluster”, ele ainda é necessário para definir-se a quantidade de instâncias do App Server, principais e adicionais, e quantidade de workers por cada uma.
NOTA: Uma conta de domínio pode ser necessária, diretamente no serviço do SO, quando o App Server precisar acessar recursos de outras máquinas. Além disso, drives mapeados (G:, V:, …) normalmente não podem ser acessados por serviços. Deve-se então usar o nomes UNC destas pastas (\\<servidor>\<driveG>\, \\<servidor>\<driveV>\, …).
Quando o serviço do GigaSpaces inicia, ele executa automaticamente os App Servers configurados nos nós <Project> e <Server>:
Múltiplos nós <Project> permitem subir múltiplos projetos no mesmo GigaSpaces.
Podemos monitorar (acompanhar) estes App Servers trabalhando, através do GigaSpaces Monitor:
O Magic xpa possui três Requesters principais:
MGrqcgi.exe (CGI)
MGrqispi.dll (ISAPI)
MGWebRequester.dll (ASP.NET)
Todos instalados e configurados também por default, no IIS.
Quando o middleware escolhido é o “GigaSpaces“, o Requester a ser utilizado (que pode se comunicar com ele) é o ASP.NET (MGWebRequester.dll) apenas.
Isso deve ser ajustado em todo sistema cliente que for acessar o Magic xpa Server, bem como no arquivo “MAGIC.INI”, na seção [MAGIC_ENV]InternetDispatcherPath
Exemplo:
Questões Gerais
Como estamos falando de uma solução “servidora” (Enterprise Server, RIA ou Web), existem ainda algumas configurações gerais no “MAGIC.INI” que são as mesmas em ambos os casos (middleware=Broker ou middleware=GigaSpaces):
[MAGIC_ENV]StartApplication = sempre tem de ter o caminho do ECF a carregar, pois não há nenhuma interatividade com usuários para escolher qual deverá ser a aplicação executada.
[MAGIC_ENV]DeploymentMode = sempre “B“, de background. Isso é obrigatório para as licenças MGENT1, MGENT2, MGRIA e MGWEB.
[MAGIC_ENV]LicenceName = tem de ser uma das licenças do tipo “servidoras” do Magic xpa (MGENT1, MGENT2, MGRIA ou MGWEB). Além disso, é necessário você informar (no momento da solicitação da licença) qual MiddleWare deseja usar. Todas elas funcionam com o Broker, mas somente as que tiverem o flag GS=Y codificado em sua feature, funcionarão com o GigaSpaces.
[MAGIC_ENV]ActivateRequestsServer = sempre “Y” para o engine/runtime do Magic xpa saber que ele deve se comportar como um App Server.
[MAGIC_ENV]ApplicationPublicName = é o nome oficial da aplicação no MiddleWare, à qual o Requester fará sempre referência (APPNAME). Ex: HelloWorld.
Observe que ao invés de ajustar isso no “MAGIC.INI“, existe também a opção de passar estas configurações por linha de comando ao App Server (MgxpaRuntime.exe), como inclusive foi exemplificado mais acima:
/DeploymentMode=B /LicenceName=MGRIA /ActivateRequestsServer=Y [...]
já que toda configuração de linha de comando “sobrepõe” a mesma configuração no MAGIC.INI.
Para terminar: é muito importante que este conceito de arquitetura fique bem compreendido:
“…
O Broker é uma das opções de “MiddleWare”. O GigaSpaces, é outra.
O “App Server” é o runtime Magic xpa, que executa as aplicações/sistemas.
O “Requester” é a porta de entrada, que permite outros softwares terem acesso às rotinas dos sistemas/aplicações que estão rodando no runtime Magic xpa (App Server).
Assim, por serem “MiddleWares”, a função/papel do Broker ou GigaSpaces é: conectar o “Requester” ao “App Server”.
…”
Para receber os artigos do Blog Magic Brasil em primeira mão no seu email registre-se aqui