Tag Magic Software

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

Soluções WEB/Enterprise com o uniPaaS – Parte 04

Manoel Frederico

Nos posts anteriores, falamos sobre a arquitetura de soluções WEB/Enterprise (corporativas) com o uniPaaS e também sobre instalação e configuração.

Falamos ainda sobre aplicações/soluções do tipo Request/Response.

Vamos abordar agora um segundo tipo de solução: BrowserClient.

Foi o primeiro movimento do uniPaaS, quando ainda se chamava eDeveloper, em direção ao RIA. Isso foi nos anos de 2000 e 2001.

O client do BrowserClient não é nativo do sistema operacional. Ele utiliza (obrigatoriamente) o Web Browser como interface da solução e é implementado através de Applets (inicialmente disponibilizados em Java, e mais tarde, em .NET) e códigos JavaScript.

O BrowserClient é o que alguns diriam, o “RIA by the book”.

Dá para perceber que as soluções criadas com o BrowserClient serão, em essência, Aplicações Internet.

O Web Browser conectado a um uniPaaS Enterprise Server, através dos requesters HTTP.

A criação de um programa BrowserClient no uniPaaS é muito simples. Ele se dá pelo fato de definir o programa como sendo do tipo ‘Browser’:

Essa definição informa que este programa é um BrowserClient, ou seja, um programa que executará “interativamente” dentro de um Web Browser.

Funcionalmente, ele idêntico a um programa On-Line (interativo através da interface do sistema operacional), mas não existe o módulo Deployment do no lado do usuário final. Apenas o seu navegador internet. Este navegador se comunica com o AppServer remoto do uniPaaS, usando ou o requester CGI, ou o ISAPI.

Do ponto de vista do desenvolvimento, ele também é idêntico aos outros programas interativo (On-Line). E isso é talvez o principal destaque do uniPaaS: um paradigma único de desenvolvimento, sejam quais forem as tecnologias ou ambientes envolvidos.

Todas as (significativas) diferenças entre se fazer uma solução Desktop e uma solução Internet são resolvidas pelo framework (uniPaaS) e o desenvolvedor se concentra em suas regras de negócio, mantendo sempre o mesmo ‘jeito’ de criar/estruturar suas soluções.

A ideia é: desenvolvedor, cuida da implementação do negócio. uniPaaS, da tecnologia.

Mas, é claro, que as coisas não são exatamente (100%) iguais no mundo Desktop e Internet.

Para o desenvolvedor uniPaaS existe uma diferença: a interface.

Ao criar uma aplicações Desktop, a interface com o usuário é desenhada no próprio Studio do uniPaaS.

Para aplicações BrowserClient, ela deve ser criada fora (em outras ferramentas). Isso porque, se a interface com o usuário final será o Web Browser, a ‘tela’ da aplicação será uma página HTML. E o uniPaaS não ambiciona ser um editor de páginas web. Existem muitas outras ferramentas (inclusive ‘free’) especializadas para isso.

O processo é simples:

  • Desenha-se a interface (tela) como uma página HTML:

  • No Studio, faz-se a ligação (bind) entre o objeto HTML e o objeto uniPaaS:

 

Isso faz com que as informações do objeto uniPaaS sejam apresentadas no objeto HTML, e quando alteradas na interface HTML, atualizem também o objeto uniPaaS.

Quando o usuário invoca o programa através do navegador, o uniPaaS intercepta a operação e devolve a ele a página HTML já devidamente alterada, com informações “enxertadas” que vão estabelecer a conexão (sessão) entre o client e o server.

O que o usuário faz no lado client se reflete no lado server, e vice-versa.

Apesar de toda esta versatilidade, o fato concreto é que este tipo de solução uniPaaS (BrowserClient) não tende a se expandir.

E os motivos para isso são (resumidamente):

1)      A tecnologia client (Applets & JavaScripts) utilizada se baseia no Internet Explorer (5.5 ou superior), o que restringe a plataforma do lado do cliente ao MS-Windows.

2)      As constantes inovações no IE, especialmente nos quesitos de segurança, tendem a ‘quebrar’ o funcionamento destes Applets & JavaScripts e isso torna a compatibilidade da tecnologia bastante trabalhosa.

3)      Novas tecnologias, como o RIA Native Client (suportada também pelo uniPaaS) superam em muito os recursos disponíveis no BrowserClient.

De qualquer forma, está aí uma ótima opção para criação de Aplicações Internet Ricas, baseadas em navegadores web.

Em nosso próximo post da série falaremos sobre o RIA Native Client do uniPaaS.

 

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

 

O Poder Inexplorado do uniPaaS 2x – Parte 2

Manoel Frederico

Desde o lançamento do uniPaaS 2.0 (em 2011), temos tentado mostrar a toda a comunidade MAGIC o que realmente isso significa para os profissionais de desenvolvimento de sistemas, e o quanto esta versão é significativa (um marco) na história do produto.

Ter o MS.NET FrameWork à disposição de nossas soluções é realmente algo diferenciado.

Neste post (entre outros), mostramos a facilidade de se evoluir a biblioteca de funções da ferramenta.

Agora, vamos falar de outra coisa: as interfaces.

O FrameWork do MS.NET não permite evoluir apenas as rotinas internas das regras de negócios, mas também as interfaces das nossas soluções uniPaaS.

Na versão 2.1 do uniPaaS há um novo projeto exemplo disponibilizado durante a instalação: Dot Net 3rd Party Samples.

É um projeto que utiliza componentes .NET de terceiros (neste caso, o pacote DevExpress), para demonstrar o quanto as interfaces dos programas uniPaaS podem ser evoluídas, modernas e atraentes.

Veja o que tem de exemplo neste projeto:

IMPORTANTE: o que você está prestes a presenciar são telas nativas, 100% uniPaaS (2.0 ou +):

 

Navigation Bar

 

Ribbon

 

Misc Controls

 

 

Grid

 

 

Gauge

Chart

Pode confessar: você sonhava com isso desde o MAGIC 7, mas não achava que seria possível.

Mas agora é.

 

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

Como Ter um Servidor uniPaaS (ou iBOLT) Robusto e Confiável?

Manoel Frederico

Seria bom poder responder a essa pergunta em uma única linha também. Mas talvez seja necessário uma apostila e, ainda assim, vai ficar faltando alguma coisa.

Mas isso não é motivo para não tentar 🙂

A primeira tarefa para se atingir este objetivo, sem dúvida, é: bom senso.

Bom senso para compreender que não é possível montar uma estrutura infalível. E se for, provavelmente custa tão caro que não estará ao nosso alcance.

Bom senso para avaliar de forma imparcial as situações, especialmente aquelas relacionadas à ‘problemas’, sem a influência de paixões ou modismos.

Bom senso para compreender que as soluções simples não são do mundo real. No mundo real, aquele onde temos que trabalhar, as soluções que nos são exigidas são complexas. E quanto mais complexa a solução, mais oportunidades de problemas existem. A compensação é que, também, quanto mais complexa, mais valiosa é esta solução (aqui estou me referindo como ‘solução’ aos produtos/projetos/softwares que temos que criar).

Bom senso para compreender que existem muitas coisas envolvidas (sistema operacional, gerenciador de dados, hardware, infraestrutura de comunicação, ferramenta de desenvolvimento, bibliotecas de execução, componentes de terceiros, usuário, …), todas elas contribuindo diretamente para o sucesso ou não da solução. Se tudo estiver certo, não vai acontecer mais do que o esperado/devido. Mas basta um elo da cadeia falhar, e já ficamos devendo em termos de resultado. E não adianta querer justificar para o usuário, no caso o cliente, através de “tecniquês”. Ele está esperando receber o que foi comprado: uma solução que funciona. Os detalhes são nossos problemas.

Ok. Se já concordamos quanto ao bom senso, vamos prosseguir. Senão, como diria Chuck Norris: “Tecle ALT+F4!”.

Uma das coisas importantes que nós temos que fazer, nesta busca da solução ideal, é a escolha das ferramentas. E está no plural de propósito.

Existem muitas opções de ferramentas para criamos soluções. E a parte mais legal é: todas podem apresentar problemas.

Podemos enfrentar problemas em soluções criadas com Java (ver aqui).

Podemos enfrentar problemas em soluções criadas com Visual Studio/.NET (ver aqui).

Podemos enfrentar problemas também quando usamos RAD Studio (ver aqui).

(vou citar só estas três plataformas)

E é claro, podemos enfrentar problemas e soluções criados com as ferramentas da MSE (uniPaaS e/ou iBOLT) (ver aqui).

Agora, precisamos concordar em outra coisa (senão, já sabe): Como proceder diante dos problemas?

Podemos resumir em: localizar, corrigir e tentar evitá-los no futuro.

Ok. Até aqui, nenhuma novidade. Tudo óbvio. Mas como que a gente faz, e como que se consegue isso?

Não sabemos se conseguiremos, mas o nosso papel é tentar com todo o empenho.

Localizar

O primeiro passo. E aqui, precisamos muito do bom senso. Nunca vamos localizar nada se ficarmos só olhando para onde o nariz aponta. É preciso uma visão clara e procedimentos cuidadosos para se descobrir a verdade. E muito importante: sem ser tendencioso.

Só a título de ilustração, aconteceu duas vezes comigo: usava máquinas com Windows (em épocas diferentes), em casa e no trabalho, e elas simplesmente travavam (congelavam) sem motivo nenhum. Só desligando e religando (e perdendo parte do trabalho) para poder continuar. E não tinha nada que pudesse dar uma luz. Por meses fiquei xingando a Microsoft e o Windows (nem que fosse em pensamento). Para resumir a história: no trabalho, o problema era superaquecimento do processador (não lembro mais como isso foi descoberto). Resolveu trocando o cooler. Em casa, era desconfiguração do clock da CPU, que ocorria algumas (não sempre) vezes durante queda de energia. Resolveu trocando a pilha da placa-mãe.

(eles provavelmente não verão, mas registro aqui meu pedido de desculpas à turma do Windows, pelos meus maus pensamentos :)).

Historinhas à parte, uma coisa muito importante: imparcialidade na hora de se avaliar as situações (e isso não é fácil, já que desenvolvimento envolve paixão). Sem isso não conseguiremos dar este primeiro passo.

Corrigir

O segundo passo. E aqui, precisamos muito de conhecimento. É fato (não precisa confessar, mas também não precisa negar) que todos nós simplesmente embarcamos de ‘carona’ em muitas tecnologias (ou produtos), sem saber como que a coisa está funcionando, apenas esperando que no fim tudo dê certo.

A necessidade nos conduz a isso.

Mas temos, por obrigação, de nos esforçarmos para aprender e conhecer tudo aquilo com o que estamos lidando. Temos (equipe) que entender do sistema operacional que usamos, do banco de dados que usamos, da infraestrutura que usufruímos, das ferramentas que escolhemos para criar as soluções.

Senão, como vamos corrigir ou melhorar uma situação, sem conhecermos os recursos que dispomos ou o que devemos evitar?

Sem o conhecimento necessário, não temos como avançar.

E sem bom senso para entender isso, somos presas fáceis dos modismos. Sem conhecer a tecnologia em que estamos (e às vezes até o negócio), optamos por abandoná-la porque não sabemos como enfrentar e superar os desafios que aparecem. Vamos atrás dos produtos da moda, sempre na esperança de que eles sejam melhores (ou pelo menos tão bons quanto na propaganda). Mas eles também não têm os seus próprios problemas?

Quando somos seguidores da moda, não há bom senso. Quer saber se está tendo bom senso? Quando decidir abandonar alguma coisa, tente se lembrar dos motivos que o fizeram escolhê-la inicialmente.

Por isso, conhecimento também é essencial. E aqui, vamos tocar numa questão ligada diretamente ao mundo MAGIC: você conhece realmente o uniPaaS e/ou o iBOLT? Talvez você já tenha criado soluções com eles, mas, se preparou bem para isso?

Não diga que ‘sim’, porque a verdade é que ninguém está completamente ‘no ponto’. Tudo é muito dinâmico. É novidade todo o dia. As necessidades mudam, as tecnologias mudam, as ferramentas mudam. O uniPaaS e o iBOLT também mudam. Evoluem.

A necessidade de nós (e não pense que seria diferente com Java, Visual Studio ou Rad Studio) estarmos sempre aprendendo e melhorando é diária. Se não for assim, ficaremos para trás. Porque em algum momento não saberemos mais como corrigir um problema novo (até então desconhecido), evoluir uma funcionalidade ou atender uma nova demanda. Seremos atropelados. E por nossa culpa.

É preciso conhecer, para saber o que fazer.

Evitar o mesmo problema no futuro

Os próximos passos. Com bom senso, e conhecimento.

Se não aprendemos com os problemas, e com os erros, não houve bom senso.

Temos de ter bom senso para saber analisar as situações. E conhecimento, para não ficarmos ‘vendidos’ diante dos problemas.

Em termos de desenvolvimento de sistemas, que é o que fazemos, quantas e quantas vezes o insucesso da solução não estava associado a nossa inexperiência, a falta de conhecimento sobre tudo o que estava envolvido, sobre o negócio? Decisões erradas, conceitos ultrapassados, falta de atualização?

Não podemos ser preguiçosos quanto à aquisição de conhecimento. Isso é falta de bom senso.

E aquisição de conhecimento vem com a experiência, que vem com a repetição e perseverança.

 

Bom, mas o que tem tudo isso a ver com o título do ‘post’? (você esperou até aqui para ver uma grande dica e até agora nada 🙂)

 

Simples: quanto mais você conhecer do uniPaaS (ou do iBOLT), das tecnologias em que estamos envolvidos, dos negócios em que estamos atuando, melhores e mais robustas serão as soluções que criamos. Ou você acha que aquelas 150.000 configurações nos arquivos .INI não afetam em nada os sistemas que você cria?

Acredite: os que decidiram por investir no uniPaaS (ou iBOLT), com bom senso e buscando conhecimento, estão colhendo bons frutos.

 

Mas não fique frustrado. Continuaremos publicando mais dicas em “tecniquês” sobre os produtos, sempre com o intuito de levar mais conhecimento e ajudá-lo a enfrentar e vencer os seus desafios. Nós também aprendemos muito com isso.

E se ficar em situação complicada, peça ajuda. Você não está sozinho.

Busque sempre o conhecimento, e nunca perca o bom senso.

E não desperdice os recursos que estão disponíveis:

 

DevNET: http://devnet.magicsoftware.com/

Blog: http://blog.magicsoftware.com.br/

YouTube: http://www.youtube.com/MagicSoftwareBR

LinkedIn: http://www.linkedin.com/company/magic-software-brasil

facebook: https://www.facebook.com/magicsoftwarebr

Twitter: https://twitter.com/#!/magicsoftwareBR

Grupo de Usuários MAGIC Brasil: http://br.groups.yahoo.com/group/magicbrasil-l/

Grupo de Usuários MAGIC Internacional: http://tech.groups.yahoo.com/group/magicu-l/

Grupo de Usuários iBOLT Brasil: http://br.groups.yahoo.com/group/iboltbrasil-l/

 

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