Tag Componentes de integração

Integração entre API’S necessita de Intermediação Especializada e não de Improvisação

A integração de processos e sistemas passou a ser uma constante no dia a dia de todas as empresas. Realidades atuais como Mobilidade e Cloud Computing nos levam constantemente a cenários, que não apenas exigem a integração, como tem nela um fator crítico do seu sucesso.

O que muitas empresas tem disponibilizado como soluções para facilitar o processo de integração é o que chamamos de APIs (Application Programming Interface). As APIs nada mais são do que serviços que dão a base ao que chamamos de Arquitetura Orientada a Serviços (SOA).

iStock_000015951999XLarge_Thumb_800x659

Leia mais…

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

Série: “Eu vou para o uniPaaS” – Infraestrutura SOA

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

Novos ‘wizards’ no UniPaaS facilitam muito a criação de componentes, de forma a montar uma solução robusta baseada em serviços e componentes reutilizáveis.

Clique abaixo para fazer o download da vídeo-aula “Componentização e Infraestrutura SOA no uniPaaS”, com aproximadamente 14Mb.

Componentização e arquitetura ‘SOA’ no UniPaaS

(NOTA: gravação à época em que o produto ainda chamava-se eDev10, mas o conteúdo continua válido para o uniPaaS).

Acompanhe aqui toda a série

Integração Baseada em Padrões – Recursos

Glenn Johnson – Senior Vice President – Magic Software Americas.

Em nossos primeiros posts desta série de integração baseada em padrões nós começamos com uma revisão dos Componentes da Integração Baseada em Padrões e dos Serviços da Integração Baseada em Padrões disponíveis como parte de uma solução de arquitetura orientada a serviços. Nós detalhamos especificamente os Componentes e Serviços do iBOLT. Nossa atenção agora se volta para os Recursos da Integração Baseada em Padrões para integração e orquestração de processos de negócios. Uma vez que todo o objetivo deste exercício foi o de fornecer detalhes sobre diversos protocolos, padrões e especificações invocados e acessados pela Suite de Integração iBOLT,  também estou incluindo quatro itens aqui (Controle de Versões, Web Servers, J2EE Servers e sistemas Operacionais) que não são acessados no Repositório de Recursos iBOLT, mas sim apoiados em outros lugares pelo iBOLT. Também estou agrupando os recursos iBOLT que têm correspondência direta na tabela de Componentes , e então não é necessário repetir esta informação aqui.

O Repositório de Recursos define os sistemas externos que o iBOLT precisa acessar durante a execução de um projeto. Isso fornece uma maneira de gerenciar os recursos de um projeto a partir de um local separado, fora do projeto atual. Você pode reutilizar configurações de ambiente predefinidas em diferentes projetos, permitindo que você alterne ambientes de execução rápida e facilmente. O Repositório de Recursos permite as configurações de componentes possam se referir  a um recurso definidos, e herdar suas propriedades.

Estas configurações de recursos podem ser utilizadas com:

  • Componentes
  • Bancos de Dados
  • Web Services
  • Esquemas XML
  • Quaisquer outros recursos definidos pelo usuário

 

Recursos iBOLT E outras  Certificações (n.e.c.) Descrição de Padrões e Certificação 
Database Microsoft SQL Server , Oracle, DB2/400, DB2, Pervasive SQL e ODBC.
UDDI Server UDDI Version 2 OASIS Standard.
Web Services Client SOAP 1.1, SOAP 1.2, WSDL e UDDI com suporte para WS-Security, WS-I,  DIME e MIME.
Web Services Server SOAP 1.1, SOAP 1.2, WSDL e UDDI com suporte para WS-Security, WS-I,  DIME e MIME.
iBOLT Server Especifica endereços TCP/IP e números de Porta de um iBOLT Server nomeado. Um número ilimitado de iBOLT Servers pode interagir uns com os outros.
Version Control (Isso não está listado no Repositório de Recursos iBOLT). Controle de Código Fonte API V1.01.
Web Servers. (Isso não está listado no Repositório de Recursos iBOLT). Para Microsoft® 32 bit Windows: Personal Web Server; IIS v5IIS v6; IIS v7.Apache 2.0Para Microsoft® 64 bit Windows: IIS v6; IIS v7.Para Linux® Server: Apache 2.0.52 
J2EE Servers. (Isso não está listado no Repositório de Recursos iBOLT). IBM WebSphere® Application Server V. 4BEA WebLogic Application Server V.6Fujitsu Interstage Application Server V.5Sun ONE Application Server V.7Oracle OC4J V.9.0.3JBoss Server 2.4

Pramati Server V 3.5 

Sistemas Operacionais. (Isso não está listado no Repositório de Recursos iBOLT). Windows, Linux, IBM i, AIX, HP-UX, Solaris.
Outros Recursos iBOLT. (Estes Recursos iBOLT têm uma correspondência direta na tabela de Componentes iBOLT e podem ser vistos ali com os detalhes individuais). Além das cinco primeiras entradas na tabela, cada um destes recursos externos pode ser especificado na Repositório de Recursos iBOLT: Domino; Dynamics CRM; Email; Exchange 2007; FTP; Google; HL7; HTTP; JD Edwards; JMS; LDAP; MSMQ; Notes DB; Salesforce; SAP A1; SAP B1; SAP R/3; SharePoint; System i; W4; e WebSphereMQ.

O desejo pelos recursos de integração baseada em padrões é baseado em uma necessidade de cumprimento de SOA, bem como em uma necessidade mais prática para padrões abertos puros na integração de sistemas de software corporativos, que são, muitas vezes, proprietários. Eu acho que você irá concordar que estes componentes, serviços e recursos fornecem capacidades completas para integração. Componentes de terceiros e de desenvolvimento próprio podem ser adicionados através do uso do Componente SDK, mas isso raramente é necessário.