Tag Java

Os irmãos MAGIC: Magic xpa (uniPaaS) & Magic xpi (iBOLT)

Manoel Frederico

Este ‘post’ é pensado inicialmente para os usuários de Magic xpa (uniPaaS) e/ou  Magic xpi (iBOLT) que por vezes ficam na dúvida sobre a finalidade/objetivo de um ou outro, e se eles se completam ou se atrapalham.

Mas é útil também àqueles que desejam conhecer mais sobre a MSE e seus produtos.

Primeiro, um pouco de história (aos que já conhecem, desculpem pela repetição).

O Magic xpa (uniPaaS), hoje na sua versão 2.0, é a evolução do produto MAGIC® da MSE. Você pode conferir mais sobre isso na Linha do Tempo.

Tecnicamente, podemos enxergar o Magic xpa (uniPaaS) como sendo a versão 12 do MAGIC:

Ao longo da história, a MSE observou que boa (e importante) parte dos projetos com o Magic xpa (uniPaaS) tratavam-se de integrações entre diferentes sistemas.

Além da eficiência e rapidez na criação de soluções, o Magic xpa (uniPaaS) também é muito bom na questão de comunicação e acesso a bases de dados, e versátil no que se refere a suporte em diferentes plataformas. Não é o caso de que não existam outras ferramentas que possam fazer bem (ou melhor) as coisas que o Magic xpa (uniPaaS) faz.

Mas que reúnam todas estas qualidades (tecnologia atualizada, multi-plataforma, multi-bases de dados, versatilidade de desenvolvimento, facilidade de manutenção, <…>), aí a coisa já fica escassa. Particularmente, ainda não encontrei (e eu procuro, no bom sentido).

O custo/benefício do Magic xpa (uniPaaS) é muito bom. As empresas que o adotaram, e trabalham profissionalmente com o desenvolvimento de soluções corporativas, sabem disso.

Considerando tudo isso, e as novas demandas das organizações a respeito de integrações entre diferentes sistemas, a MSE criou um novo produto, derivado, ‘irmão mais novo’, o Magic xpi (iBOLT):

 

O Magic xpi (iBOLT) é uma ferramenta de BPMS, para tentar resumir melhor.

É uma ferramenta criada com outra ferramenta: o Magic xpa (uniPaaS).

Sim, o Magic xpi (iBOLT) é desenvolvido (escrito, criado) com o Magic xpa (uniPaaS). Ele já nasceu com muitos anos de experiência na sua área.

Já comparou a estrutura dos dois produtos?

Está tudo lá: MAGIC.INI, MGRB.INI, MGstations.exe, uniRQBroker.exe, etc…

Os módulos da suíte Magic xpi (iBoltMonitor.exe, iBoltServer.exe e iBoltStudio.exe) não são iguais ao módulo de ‘deployment’ do Magic xpa (uniRTE.exe)?

São. E não é por acaso.

O Magic xpi (iBOLT) Studio é formado pelo deployment Magic xpa (iBoltStudio.exe) + uma aplicação Magic xpa (ife.ecf) + arquivo de configuração específico (ife.ini).

No Magic xpi (iBOLT) Monitor temos: iBoltMonitor.exe + ifm.ecf + ifm.ini.

E no Magic xpi (iBOLT) Server: iBoltServer.exe + ifs.ecf + ifs.ini.

O Magic xpi (iBOLT) é, talvez, a melhor propaganda do Magic xpa (uniPaaS). Afinal, se alguém perguntar o que dá para fazer com o Magic xpa (uniPaaS), pode-se dizer: um Magic xpi (iBOLT).

O Magic xpi (iBOLT) explora e exibe os melhores recursos disponíveis no Magic xpa (uniPaaS): componentização, late bind, remote calls, integração Java, integração COM, build automático e dinâmico, isso só para mencionar alguns.

Com todos estes recursos existentes no Magic xpa (uniPaaS), temos no Magic xpi (iBOLT):

Um Studio de desenho de integrações/automações totalmente orientado a processos:

Uma vasta biblioteca de componentes de regras de negócio:

Parametrização gráfica, sem codificação:

Um Monitor de acompanhamento (on-line e off-line) das etapas dos processos de integração:

E um Server, que é o executor dos projetos desenhados com o Studio.

Então, sim, é verdade:

Quando temos um Magic xpi (iBOLT) executando um projeto de integração/automação, tecnicamente é um AppServer Magic xpa (uniPaaS), executando uma aplicação Magic xpa (uniPaaS), formada por vários componentes Magic xpa (uniPaaS), integrados a outros componentes COM, Java e .NET.

 

Já em relação ao Magic xpa (uniPaaS), temos um Studio totalmente ‘table driven’ e livre de codificação (como sempre foi o MAGIC desde a sua versão 1.0):

e um módulo Deployment multi plataforma, multi bancos de dados, que nos permite ter um mesmo paradigma (skill) de desenvolvimento para todos os ambientes suportados:

Um Line/Desktop/Open Client:

RIA Windows:

RIA Windows Mobile:

RIA BlackBerry:

 

NOTA: Previsão para o 1º Semestre de 2012: RIA iPhone e RIA Android.

 

Agora que entendemos esta parte, vamos compreender algumas outras coisas importantes:

 

A)     O Magic xpi (iBOLT) e o Magic xpa (uniPaaS) não competem um com o outro. Eles atuam em harmonia. Possuem o seu foco bem definido. Nas soluções de aplicações RIA e/ou On-Line/Desktop/Open Client, a ferramenta correta é o Magic xpa (uniPaaS). Já nas soluções de Integração e/ou Automação de Processos, a ferramenta correta é o Magic xpi (iBOLT).

Veja que qual seja a área do negócio, ou da necessidade, há um produto (excelente) MSE para atender.

Alguns desenvolvedores entendem que não necessitam do Magic xpi (iBOLT), já que poderiam usar o Magic xpa (uniPaaS) para atender as suas necessidades de automação/integração. É verdade. A comprovação está ali em acima. A pergunta é: por quê? Por que montar uma arquitetura Magic xpa (uniPaaS) AppServer, uma aplicação de integração, se já temos pronto? O Magic xpa (uniPaaS) é muito bom. Mas para projetos desta natureza (automação e/ou integração), o Magic xpi (iBOLT) é ainda melhor e mais eficiente.

B)      O Magic xpi (iBOLT) não tem a preferência (foco principal) da MSE em relação ao Magic xpa (uniPaaS). Esta é uma preocupação que alguns desenvolvedores tiveram (ou tem). O sucesso do Magic xpi (iBOLT) é mais uma garantia da evolução do Magic xpa (uniPaaS). O Magic xpa (uniPaaS) (o irmão mais velho) é a base do Magic xpi (iBOLT) (o irmão mais novo). A MSE tem uma missão clara: sempre disponibilizar tecnologia inovadora, atualizada e eficiente aos clientes de seus produtos, nas áreas em que eles atuam. E a constante evolução e atualização destes produtos comprova isso.

C)      Conhecer ambos, só traz vantagens. O desenvolvedor Magic xpa (uniPaaS) que entra no mundo Magic xpi (iBOLT) já entra em vantagem. Ele conhece a ‘base’ de tudo. E tem um AppServer com uma extensa biblioteca de componentes já prontos. Já o desenvolvedor Magic xpi (iBOLT) que decide conhecer também o Magic xpa (uniPaaS), multiplica as suas capacidades. Ele pode ampliar muito os recursos do produto e da solução (projeto) que está criando. Sem mencionar que o produto Magic xpa (uniPaaS) já está embutido em todos os pacotes Magic xpi (iBOLT).

 

Por isso, quando você opta pelos produtos da MSE (Magic xpa e/ou Magic xpi), você está adquirindo confiança, competência e segurança para as suas soluções corporativas.

 

Como reflexo das constantes mudanças a que estamos passando como empresa e os grandes desenvolvimentos em nossas ofertas de produtos, incluindo a adição de novas habilidades que adotam os últimos avanços tecnológicos, nós renomeamos nosso núcleo de produtos da seguinte forma:

Veja mais em: http://www.magicsoftware.com/pt/produtos-legados

 

Manoel Frederico Silva

Product Manager & MAGIC Evangelist / Magic Software Brasil 

iBOLT e Sistemas de Mensageria

Manoel Frederico

A capacidade de interagir com sistemas de filas de mensagens é um dos vários recursos existentes no iBOLT, através de seus componentes especializados para esta tarefa.

 

Nativamente, três são os sistemas suportados:

Microsoft (MSMQ), Java (JMS) e IBM (WebSphereMQ).

Outros sistemas de mensageria podem facilmente ser implementados através do iBOLT SDK.

Neste “post”, vamos focar na integração entre o iBOLT e o JMS.

Como quase tudo em Java, existem várias opções e formas diferentes de se fazer a mesma coisa. Existem vários provedores de JMS. Escolhemos, para este “post”, o ActiveMQ (da Apache Software Foundation).

Vejamos então os passos para implementar esta integração.

IMPORTANTE: Devido as características específicas de cada provedor JMS, os passos abaixo referem-se à integração com ActiveMQ, apenas. Outros provedores poderão requerer configurações diferentes.

Passo 1

É preciso garantir que a versão utilizada do ActiveMQ tenha sido criada para a mesma versão de Java que o iBOLT está utilizando. Por exemplo: o iBOLT 3.2 utiliza o Java 5 (1.5.x). Já a versão 3.2sp3, utiliza o Java 6 (1.6.x). Diferentes versões do ActiveMQ também exigem diferentes versões do Java.

 

 

Por exemplo: o ActiveMQ 5.4.3 utiliza o Java 5 e o 5.5.1, o Java 6.

É importante que ambos estejam “sintonizados” na mesma versão de Java.

Passo 2

É preciso garantir que o iBOLT encontre as classes do ActiveMQ, contidas nos arquivos JAR distribuídos com o produto. Existem várias formas de se fazer isso em Java. Abaixo, segue uma (não é a única, mas comprovadamente funciona):

  • Crie uma pasta dentro da pasta ‘home’ do iBOLT, e copie todos os JARs do ActiveMQ lá:

  • Edite o arquivo ‘MAGIC.INI’ e relacione estas classes na seção [MAGIC_JAVA], chave: CLASSPATH:

 

Passo 3

Acrescente as definições ‘java.naming.factory.initial’ e ‘java.naming.provider.url’ na seção [MAGIC_JAVA], chave: JVM_ARGS. O iBOLT utiliza JNDI para se comunicar com o provedor JMS e estas configurações farão ele encontrar o ActiveMQ. O valor destas definições vai variar conforme a instalação do provedor JMS:

Passo 4

O JNDI precisa ser configurado explicitamente. Crie um arquivo jndi.properties (ver regras aqui) na mesma pasta onde copiou (passo 2) os JARs do ActiveMQ. Neste arquivo deve ser informado o connectionFactoryNames, e também os nomes das filas que serão acessadas:

Coloque este arquivo jndi.properties dentro de um arquivo JAR. Isso pode ser feito com o comando:  jar –cf <ArquivoJAR> jndi.properties. Veja mais detalhes aqui.

Após, inclua este arquivo JAR na lista informado no ‘MAGIC.INI’, em [MAGIC_JAVA]CLASSPATH:

 

Com estas configurações, o iBOLT está apto a encontrar e conversar com o ActiveMQ.

 

Vejamos então os passos para concretizar esta integração em um projeto.

Passo 1

Devemos criar um “resource” do tipo JMS, e informar no “Connection Factory Name” o mesmo valor que especificamos no arquivo jndi.properties:

 

Passo 2

Utilizamos o componente JMS do iBOLT para fazer o acesso (leitura ou escrita) a um provedor de mensagens Java (neste caso, o ActiveMQ).

Os métodos “Send” são para gravar informações nas filas, e “Get“, para buscar informações da fila:

Quando o iBOLT Server executa o projeto e aciona o componente, os métodos “Get” buscarão dados que existam na fila informada, e os métodos “Send” incluirão dados nesta fila:

 

Manoel Frederico Silva
Product Manager & MAGIC Evangelist / Magic Software Brasil

Comparando uniPaaS e Java: não podemos ficar juntos?

Glenn Johnson – Senior Vice President – Magic Software Americas

Recentemente, realizamos um desafio interessante com uniPaaS Jet. Pedimos a um desenvolvedor independente, já familiarizado com programação Java e sem nenhuma experiência anterior em uniPaaS, para fazer o download do uniPaaS Jet, estudá-lo e criar um programa simples (nós já havíamos pedido a ele para criar o mesmo programa em Java.) Solicitamos que ele anotasse cuidadosamente os recursos necessários e todo esforço envolvido. O uniPaaS mostrou-se mais eficiente em cada categoria analisada. O uniPaaS utilizou metade da memória e metade do armazenamento do arquivo. O uniPaaS exigiu apenas 1% de linhas lógicas e 7% de linhas físicas de código. O programa uniPaaS foi executado pela primeira vez em 1 décimo da quantidade de tempo. O esforço aplicado foi de 202 horas em Java e apenas 3,2 horas em uniPaaS. A duração do projeto foi de 2,63 meses em Java e parte de um único dia em uniPaaS.

Nosso objetivo em relatar esses resultados não é criticar o Java ou apontar suas fraquezas, na verdade o uniPaaS é muito amigável ao Java. Temos alguns desenvolvedores Java em nosso departamento de pesquisa e desenvolvimento. E o mais importante é que nós acreditamos que o uniPaaS pode oferecer muito para as equipes de desenvolvimento Java fornecendo-lhes ferramentas que podem tirar aproveitar de seu investimento em Java, dando-lhes o tipo de vantagens experimentado pelo desenvolvedor independente mencionado acima.

A Integração Java embutida no uniPaaS permite que o uniPaaS faça interface com uma classe Java ou Enterprise JavaBeans (EJB), usando pseudo-referências que representam instâncias de classes Java ou arquivos EJB. Pseudo-referências são um identificador que representa os valores de uma instância de classe em uma variável BLOB. Os programas devem passar este identificador para acessar os métodos e variáveis ​​de uma instância da classe. Uma classe Java é uma definição de modelo dos métodos e variáveis ​​em um determinado tipo de objeto. Um objeto pode ser uma instância específica de uma classe e pode conter valores reais ao invés de variáveis. Para a integração de classes Java através de uma aplicação uniPaaS, você pode acessar métodos estáticos e variáveis, sem a pseudo-referência.

Instâncias Java, métodos estáticos e variáveis ​​são invocados pelo Java uniPaaS e funções EJB. No Java, uma instância de classe é uma implementação específica da classe Java, enquanto um método de classe estática é um método de classe que pode ser chamado sem instanciar a classe. Da mesma forma, uma variável de classe estática é uma variável de classe que pode ser acessada sem instanciar a classe.

Um Enterprise Java Bean (EJB) é uma arquitetura para definição dos componentes do programa Java que são executados em uma rede cliente / servidor. O uniPaaS EJB Component Generator é um assistente que gera um componente contendo programas uniPaaS que chamam uma classe Java ou funções EJB. A Java Native Interface (JNI) permite que programas não-Java possam interagir com os programas Java. O Java Component Generator é um assistente que permite que o uniPaaS automaticamente  acesse classes Java ou arquivos EJB, criando um componente que elimina a necessidade de especificar assinaturas JNI. Você também pode usar o uniPaaS para gerar Enterprise Java Beans (EJBs). Clientes que rodam em um ambiente J2EE são capazes de visualizar e ativar programas uniPaaS como métodos EJB. Você cria os EJBs usando o utilitário Component Builder do uniPaaS.

O uniPaaS pode criar uma instância de uma classe Java que permite que você ative um método, ou consulte e atualize variáveis ​​usando uma pseudo-referência. A pseudo-referência é uma variável BLOB que representa a instância da classe Java. Quando um método é invocado, a variável BLOB retorna ​​para o programa uniPaaS como códigos de retorno de função. Métodos estáticos de classes e variáveis ​​também podem ser acessados ​​sem uma instância da classe Java usando o nome da classe e o método ou o nome da variável.

As funções uniPaaS Java são usadas ​​para simular os métodos de chamada em Java. Cada contexto do motor internamente mapeia entre a pseudo-referência e a referência real.

Por exemplo, um programa uniPaaS pode chamar a função JCreate para criar uma pseudo-referência como Variável Virtual A. A referência real para a instância é, então, internamente, associada com o Variável Virtual A. Qualquer programa uniPaaS no contexto será capaz de acessar os métodos e variáveis ​​do objeto usando JCall (A ,…).

As funções do Java pode ser chamadas por um programa uniPaaS para:

• Criar uma nova instância de uma classe Java
• Chamar um método diretamente da classe Java ou de uma instância
• Reportar e retornar exceções
• Consultar e atualizar valores de variáveis

As funções EJB permitem ao uniPaaS explorar e chamar Enterprise JavaBeans.

Acho que a mensagem importante aqui é que o uniPaaS pode ajudar programadores Java a fazerem uso eficiente de classes Java e EJBs enquanto se beneficiam da eficiência da plataforma de aplicativos inteligente do uniPaaS. Para maiores informações acesse o Magic Software DevNet ou contate nosso representante local.