we are developers

iMaster Developers

iMaster DevelopersPowered by:

APIs e Microsserviços

18 jun, 2012

Criando padrões de fluxo de mensagens usando APIs do WebSphere Message Broker

developerWorks Brasil

Tem 217 artigos publicados com 4709798 visualizações desde 2010

developerWorks Brasil
Publicidade

Um padrão é uma solução reutilizável para um problema comum em um determinado contexto. É imperativo que os clientes criem padrões para fluxos de mensagens reutilizáveis complexos, de forma que possam reutilizar o fluxo em um cenário diferente simplesmente alterando alguns dos valores de configuração.

Um padrão fornece uma solução reutilizável que contém uma abordagem testada para a solução de uma tarefa comum de arquitetura, design ou implementação em um determinado contexto. Ao decidir usar um padrão, muito do trabalho de design e desenvolvimento já é realizado para você, permitindo reduzir esforços de desenvolvimento, teste e operacional, o que economiza tempo e dinheiro.

O IBM WebSphere Message Broker V8 estende a API Java do Message Broker™ e permite modificar instâncias do padrão definido pelo usuário ou desenvolver novos aplicativos do fluxo de mensagens usando o código Java. No passado, era necessário usar o Message Broker Toolkit para desenvolver aplicativos do fluxo de mensagens, mas a nova API Java permite evitar o Toolkit e desenvolver novos fluxos de mensagens usando qualquer IDE Java.

API do WebSphere Message Broker

A API do Message Broker é uma interface de programação que permite que os aplicativos controlem os brokers e seus recursos por meio de uma interface remota. Ela também é conhecida como a API do Configuration Manager Proxy (CMP). O Configuration Manager foi removido na V7 e o nome completo da API foi alterado, mas os termos aplicativo CMP e API do CMP foram mantidos e são usados no centro de informações para se referir à API do Message Broker por questão de continuidade e consistência com o arquivo JAR ConfigManagerProxy.jar, que fornece as classes necessárias. A Figura 1 abaixo mostra os pacotes disponíveis no ConfigManagerProxy.jar – os que estão circulados em vermelho fornecem as classes para as APIs do Message Broker.

Figura 1. Pacotes Java no ConfigManagerProxy.jar

A API do Message Broker consiste somente em uma implementação de Java e é chamada de API Java do Message Broker. Os aplicativos de usuário possuem acesso total às funções e recursos do broker por meio de classes Java que constituem o CMP. Use a API do CMP para interagir com o broker e executar as seguintes tarefas:

  • Criar e modificar aplicativos do fluxo de mensagens
  • Implementar arquivos BAR
  • Alterar as propriedades de configuração do broker
  • Criar, modificar e excluir grupos de execução
  • Consultar e configurar o status do broker e seus recursos associados, além de se informar sobre mudanças de status em relação a:

          – Grupos de execução

          – Fluxos de mensagens implementadas

          – Arquivos implementados usados pelos fluxos de mensagens (como arquivos JAR)

  • Visualizar o log de administração
  • Visualizar o log de atividades

Para aplicativos que interagem com o Message Broker, as classes Java se situam logicamente entre o aplicativo de usuário e o Message Broker, dentro da JVM do aplicativo de usuário. Para conectividade, a API requer as Classes do WebSphere MQ para Java. Conforme mostrado na Figura 2, um programa padrão do fluxo de mensagens é um aplicativo de usuário eficiente que pode instanciar ocorrências de fluxos de mensagens com base em uma definição padrão

Figura 2. APIs do Message Broker

Cenário

Conforme mostrado abaixo, JKRetail é um grande varejista dos EUA com várias lojas em todo o país (pinos vermelhos) e um escritório central na Nebraska (pino verde):

Figura 3. Lojas e escritório central da JKRetail

Como parte de um processo de gerenciamento de inventário e de previsão de vendas, cada loja envia dados do inventário e de vendas para o escritório central no formato XML usando arquivos simples e FTP. O processamento em lote é executado nos dados e uma avaliação é feita para cumprir com os requisitos de inventário das lojas com base em fatores como mês, feriados futuros e tendências culturais locais. O escritório central designa fluxos de mensagens a cada loja para ler dados dos arquivos e executar o processamento em lote. Os dados são enviados em registros individuais para o processamento inteligente de backend. A Figura 4 mostra os vários fluxos de mensagens associados a diferentes lojas:

Figura 4. Integração da loja com o escritório central para gerenciamento de inventário

Esses fluxos de integração são razoavelmente simples e possuem a lógica funcional de leitura de um registro XML individual de um arquivo e envio de um único registro para processamento de backend por meio de filas do WebSphere MQ. A Figura 5 abaixo mostra um fluxo de mensagens de amostra usado para a integração do inventário da Loja 106: 

Figura 5. Integração do gerenciamento de inventário para a Loja 106 da JKRetail

A JKRetail tem um requisito de desenvolver fluxos de mensagens com base em um padrão caso seja necessário abrir novas lojas em um novo local com novos IDs de loja, a fim de minimizar o tempo e o esforço de desenvolvimento. A solução para esse requisito é implementar um padrão usando APIs do WebSphere Message Broker e está descrita em detalhes no restante deste artigo.

A criação de uma solução baseada em padrão envolve três etapas:

  1. Critérios de definição padrão
  2. Conteúdo de projeto padrão
  3. Instanciação de padrão

1. Critérios de definição padrão

Critérios de definição padrão incluem a captura de informações sobre todos os componentes específicos necessários para determinar o comportamento de um padrão de fluxo de mensagens. Para definir o comportamento do padrão de processamento em lote do gerenciamento de inventário, comece identificando os componentes envolvidos e suas propriedades. A Tabela 1 abaixo mostra os componentes e suas propriedades associadas necessárias para criar o padrão de processamento em lote para a JKRetail:

Tabela 1. Componentes e propriedades necessários para desenvolver o padrão de processamento em lote

Componente Propriedade Detalhes da propriedade
Loja STORE_ID Número da loja, como 107
MessageFlow MF_LOCATION Local físico em disco no qual o fluxo de mensagens será criado
MF_NAME Nome do fluxo de mensagens
Nó FileInput FILE_INPUT_NAME Nome do nó FileInput
FILE_INPUT_DIR Local do recebimento de arquivos de dados do inventário
BATCH_FILE_TYPE Tipo de arquivo ou padrão de nome recebido
FILE_INPUT_POLLING Frequência de varredura de novo conteúdo
Nó Compute COMPUTE_NAME Nome do nó Compute
ESQL_FILE_NAME Nome do módulo ESQL
Nó MQOutput MQOUTPUT_NAME Nome do nó MQOutput
MQOUTPUT_QM_NAME Nome do gerenciador de filas ao qual o nó MQOutput deve se conectar
MQOUTPUT_Q_NAME Nome da fila para executar MQPUT

2. Conteúdo do projeto padrão

O projeto padrão conterá:

  • Arquivo de configuração – Este arquivo conterá as propriedades definidas ao configurar os critérios de definição padrão.
  • Classe do código Java – Esta classe Java será usada para implementação padrão e todas as ocorrências do fluxo de mensagens de integração do inventário serão instanciadas a partir dela.

A seção mostra como criar o arquivo de configuração e o código Java do padrão de processamento em lote. Comece criando o arquivo de configuração: crie um de nome simples config.txt com o conteúdo mostrado na Listagem 1 abaixo, que é derivado das propriedades definidas na Tabela 1. Os pares nome-valor especificados em config.txt serão usados ao instanciar fluxos de mensagens para novas lojas de varejo:

Listagem 1. Conteúdo do arquivo de configuração

STORE_ID=107 MF_LOCATION=C:\JKRetailInventoryIntegration MF_NAME=InventoryFromStore107 FILE_INPUT_NAME=Inventory 107 Input FILE_INPUT_DIR=C:\INBOUND\STORE107 BATCH_FILE_TYPE=xml FILE_INPUT_POLLING=10 COMPUTENODE_NAME=FTP_TO_MQ ESQL_FILE_NAME=InventoryFromStore107 MQOUTPUT_NAME=Inventory Backend Processing MQOUTPUT_QM_NAME=ESB01 MQOUTPUT_Q_NAME=INVENTORY.BACKEND

Crie uma classe Java BatchProcessingPattern com um método main(). Inclua uma variável de classe configMap do tipo HashMap, que será usada para armazenar e referenciar as propriedades de configuração padrão, conforme mostrado na Listagem 2:

Listagem 2. Crie a classe Java BatchProcessingPattern

packagecom.ibm.broker.pattern;  importjava.util.HashMap;  public class BatchProcessingPattern {  static HashMap <String,String>configMap = new HashMap <String,String>();     public static void main(String[] args) {       File msgFlow = null;       File esql = null;       FileInputNodefileInput = null;       ComputeNode compute = null;       MQOutputNodemqoutput = null;    } }

A primeira etapa é ler o arquivo de configuração e armazenar os pares nome-valor no configMap. A Listagem 3 abaixo mostra a implementação do método readConfigFile(). Crie esse método na classe BatchProcessingPattern:

Listagem 3. Método readConfigFile() para ler e armazenar o conteúdo do arquivo de configuração padrão

public static void readConfigFile(String filename)    {       File file = newFile(filename);       BufferedReaderbr = null;       try {          br = newBufferedReader(newFileReader(file));       } catch (FileNotFoundExceptionfnfe) {          fnfe.printStackTrace();       }       String line = null;       longtotalLinesProcessed = 0;        try {          while((line=br.readLine())!=null){             totalLinesProcessed ++;             String element[]=line.split("=");             configMap.put( element[0], element[1] );          }       } catch (IOExceptionioe) {          ioe.printStackTrace();       }       finally       {          try {             br.close();          } catch (IOExceptionioe) {             ioe.printStackTrace();          }       }    }

Conforme mostrado na Listagem 4 abaixo, crie o arquivo de fluxo de mensagens físicas criando um método createMessageFlowFile() na classe BatchProcessingPattern. Um fluxo de mensagens com o nome valueof(MF_NAME).msgflow será criado no local valueof(MF_LOCATION). (valueof() representa uma técnica para recuperar valores das entradas no objeto de HashMap configMap.)

Listagem 4. Método createMessageFlowFile() para criar um novo arquivo .msgflow

public static File createMessageFlowFile() { File msgFlow = newFile(configMap.get("MF_LOCATION").toString()+"\\"+                configMap.get("MF_NAME").toString()+".msgflow");     if(!msgFlow.exists())    {       try {          msgFlow.createNewFile();       } catch (IOExceptionioe) {          ioe.printStackTrace();       }    } returnmsgFlow; }

A Listagem 5 abaixo mostra a implementação para gerar um arquivo ESQL físico criando um método createESQLFile() na classe BatchProcessingPattern. O ESQLfile com nome valueof(ESQL_FILE_NAME).esql será criado no local valueof(MF_LOCATION):

Listagem 5. Método createESQLFile() para criar um novo arquivo .esql

public static File createESQLFile() { File esql = newFile(configMap.get("MF_LOCATION").toString()+"\\"+             configMap.get("ESQL_FILE_NAME").toString()+".esql");     if(!esql.exists())    {       try {          esql.createNewFile();       } catch (IOExceptionioe) {          ioe.printStackTrace();       }    } returnesql; }

Agora os arquivos .msgflow e .esql são criados. Inclua o nó FileInput no fluxo de mensagens. Algumas propriedades do nó FileInput são configuradas com base nos valores de configuração em config.txt. Crie o método addFileInputNode(), conforme mostrado na Listagem 6:

Listagem 6. Método addFileInputNode() para criar FileInputNode

public static FileInputNode addFileInputNode(MessageFlowmfST) {    FileInputNodefileInput = (FileInputNode)mfST.getNodeByName                             (configMap.get("FILE_INPUT_NAME").toString());    if(fileInput  == null)    {       fileInput=newFileInputNode();       fileInput.setNodeName(configMap.get("FILE_INPUT_NAME").toString());       fileInput.setInputDirectory(configMap.get("FILE_INPUT_DIR").toString());       fileInput.setFilenamePattern("*"+configMap.get("STORE_ID").toString()+          "*."+configMap.get("BATCH_FILE_TYPE").toString());       fileInput.setProcessedFileAction(ENUM_FILEINPUT_PROCESSEDFILEACTION.          moveToArchiveWithTimestamp);       fileInput.setRecordDetection(ENUM_FILEINPUT_RECORDDETECTION.delimited);       fileInput.setRecordDelimiter(ENUM_FILEINPUT_RECORDDELIMITER.eitherLineend);       fileInput.setWaitInterval(Integer.parseInt(configMap.get          ("FILE_INPUT_POLLING").toString()));       mfST.addNode(fileInput);    }    returnfileInput; }

Crie o método addComputeNode() na classe BatchProcessingPattern para incluir ComputeNode, conforme mostrado na Listagem 7:

Listagem 7. Método addComputeNode() para criar ComputeNode

public static ComputeNode addComputeNode(MessageFlowmfST) {    ComputeNode compute = (ComputeNode)mfST.getNodeByName                          (configMap.get("COMPUTENODE_NAME").toString());    if(compute == null)    {       compute = newComputeNode();       compute.setNodeName(configMap.get("COMPUTENODE_NAME").toString());       mfST.addNode(compute);    } return compute; }

Crie o método addMQOutputNode() na classe BatchProcessingPattern para incluir MQOutputNode, conforme mostrado na Listagem 8:

Listagem 8. Método addMQOutputNode() para criar MQOutputNode

public static MQOutputNode addMQOutputNode(MessageFlowmfST) {    MQOutputNodemqoutput = (MQOutputNode)mfST.getNodeByName(configMap.                           get("MQOUTPUT_NAME").toString());    if(mqoutput == null)    {       mqoutput = newMQOutputNode();       mqoutput.setNodeName(configMap.get("MQOUTPUT_NAME").toString());       mqoutput.setQueueManagerName(configMap.get("MQOUTPUT_QM_NAME").toString());       mqoutput.setQueueName(configMap.get("MQOUTPUT_Q_NAME").toString());       mfST.addNode(mqoutput);    } returnmqoutput; }

Crie o método addESQLContents() na classe BatchProcessingPattern para incluir conteúdo no arquivo ESQL, conforme mostrado na Listagem 9:

Listagem 9. Método addESQLContents() para criar o código ESQL

public static void addESQLContents(File esql) {    DataOutputStream data =  null;    try    {    data = newDataOutputStream(newFileOutputStream(esql,false));    data.write(new String(    "CREATE COMPUTE MODULE Store_"+configMap.get("STORE_ID").toString()+    "      "_FTP_TO_MQ_Compute\n"+    "   CREATE FUNCTION Main() RETURNS BOOLEAN\n"+    "   BEGIN\n"+    "      -- CALL CopyMessageHeaders();\n"+    "      CALL CopyEntireMessage();\n"+    "      RETURN TRUE;\n"+    "   END;\n\n"+    "   CREATE PROCEDURE CopyMessageHeaders() BEGIN\n"+    "      DECLARE I INTEGER 1;\n"+    "      DECLARE J INTEGER;\n"+    "      SET J = CARDINALITY(InputRoot.*[]);\n"+    "      WHILE I < J DO\n"+    "         SET OutputRoot.*[I] = InputRoot.*[I];\n"+    "         SET I = I + 1;\n"+    "      END WHILE;\n"+    "   END;\n\n"+    "   CREATE PROCEDURE CopyEntireMessage() BEGIN\n"+    "      SET OutputRoot = InputRoot;\n"+    "   END;\n"+    "END MODULE;").getBytes());    }    catch(FileNotFoundExceptionfnfe)    {    fnfe.printStackTrace();    }    catch(IOExceptionioe)    {    ioe.printStackTrace();    }    finally    {       try {          data.close();          } catch (IOExceptionioe) {          ioe.printStackTrace();       }    } }

Crie o método connectNodes() na classe BatchProcessingPattern para conectar os nós entre eles, conforme mostrado na Listagem 10:

Listagem 10. Método connectNodes() para conectar nós no fluxo de mensagens

public static void connectNodes(MessageFlowmfST,FileInputNodefileInput,        ComputeNode compute, MQOutputNodemqoutput) {    mfST.connect(fileInput.OUTPUT_TERMINAL_OUT, compute.INPUT_TERMINAL_IN);    mfST.connect(compute.OUTPUT_TERMINAL_OUT, mqoutput.INPUT_TERMINAL_IN); }

Crie o método attachESQLModule() na classe BatchProcessingPattern para conectar o módulo ESQL ao nó compute, conforme mostrado na Listagem 11:

Listagem 11. Método attachESQLModule() para conectar o módulo ESQL ao nó compute

public static void attachESQLModule(File esql, ComputeNode compute) {    try {    ESQLFileesqlFile = newESQLFile(esql);    Vector<ESQLModule>esqlModules = esqlFile.getEsqlModules();    compute.setComputeExpression(esqlModules.get(0));    } catch (IOExceptionioe) {       ioe.printStackTrace();    } }

Atualize o método main para chamar os métodos criados anteriormente em uma sequência lógica, conforme mostrado na Listagem 12:

Listagem 12. Atualizar método main()

public static void main(String[] args)  {     File msgFlow = null;    File esql = null;    FileInputNodefileInput = null;    ComputeNode compute = null;    MQOutputNodemqoutput = null;     try    {    readConfigFile(args[0]);        msgFlow = createMessageFlowFile();        esql = createESQLFile();        MessageFlowmfST = FlowRendererMSGFLOW.read(msgFlow);        fileInput = addFileInputNode(mfST);        compute = addComputeNode(mfST);        mqoutput = addMQOutputNode(mfST);        addESQLContents(esql);        connectNodes(mfST, fileInput, compute, mqoutput);        attachESQLModule(esql, compute);        FlowRendererMSGFLOW.write(mfST,configMap.get("MF_LOCATION").toString());    }    catch(IOExceptionioe)    {        ioe.printStackTrace();    }    catch(MessageBrokerAPIExceptionmbae)    {        mbae.printStackTrace(); }

3. Instanciação padrão

Na instanciação padrão, o padrão é aplicado e uma instância do padrão é criada, que é identificada pelas propriedades nos critérios de definição do padrão. Várias instâncias de uma instância padrão podem existir ao mesmo tempo. Instâncias padrão são independentes entre si, embora possam compartilhar os mesmos valores de argumento. Esta seção explica como executar o programa de geração padrão que cria uma instância do aplicativo do fluxo de mensagens reutilizável.

Para desenvolver e processar aplicativos Java que usam a API Java do Message Broker, instale o seguinte software em seu ambiente de desenvolvimento local:

  • Um IBM JDK para desenvolver aplicativos de API Java do Message Broker. O Message Broker não fornece um JDK, portanto, um ambiente JDK suportado deve ser instalado separadamente.
  • Um IBM Java Runtime Environment (JRE) para executar os aplicativos.
  • Um IDE Java para desenvolvimento, como o Eclipse ou IBM Rational Application Developer.

Executando o código em um ambiente Eclipse

Quando o programa estiver pronto para execução, é possível usar o IDE Java ou a linha de comandos para executar o programa. Seguem as etapas para executar o programa de amostra fornecido neste artigo usando o Eclipse:

  1. Em seu ambiente Eclipse, importe o projeto de amostra, cujo download é possível ser feito no final deste artigo.
  2. Clique com o botão direito do mouse no projeto e selecione Propriedades
  3. Clique em Caminho de Desenvolvimento do Java, selecione a guia Bibliotecas e clique em Incluir Jars Externos.
  4. Para configurar o ambiente de desenvolvimento, navegue até o subdiretório install_dir/classes. Por exemplo, para a Versão 8.0.0.0 em edições do sistema operacional de 32 bits do Windows, navegue até o diretório C:\Program Files\IBM\MQSI\8.0.0.0\classes. Selecione o arquivo ConfigManagerProxy.jar e clique em Abrir. O arquivo é incluído na lista na janela da guia Bibliotecas.
  5. O programa de amostra espera que o local do arquivo de configuração seja transmitido como um argumento de programa, que pode ser configurado nas propriedades Executar Configuração, conforme mostrado abaixo:
    Figura 6. Configurar o argumento de programa para transmitir o local do arquivo de configuração
  6. Edite config.txt, que contém os parâmetros de configuração, e insira os valores para seu ambiente de sistema.
  7. Desenvolva e execute o projeto de amostra.

Executando o código a partir da linha de comandos

Também é possível usar os recursos do sistema para configurar as variáveis de ambiente em máquinas Windows a fim de executar os aplicativos da API Java do Message Broker:

  1. Atualize a variável de ambiente CLASSPATH: Inclua o arquivo JAR da API Java do Message Broker ao CLASSPATH. Por exemplo: configure o caminho de classe = %CLASSPATH%;%install_dir%\classes\ConfigManagerProxy.jar.
  2. Inclua seu diretório de desenvolvimento do Java no caminho de classe da mesma forma.
  3. Use as ferramentas fornecidas pelo seu JDK para desenvolver e executar o projeto de amostra.

Extensão de automação

Depois que os fluxos de mensagens são instanciados, é possível automatizar as tarefas de criação e de implementação do arquivo BAR. Arquivos BAR só podem ser criados usando o Message Broker Toolkit ou o comando mqsicreatebar. Para obter mais informações sobre a criação de arquivos BAR, consulte o tópico comando mqsicreatebar no centro de informações do WebSphere Message Broker V8. Use o comando mqsicreatebar com APIs Java System para executar comandos externos. É possível automatizar o processo de implementação criando um pequeno programa Java, conforme explicado em Implementando um arquivo bar usando a API do CMP.

Conclusão

Este artigo mostrou como criar padrões do fluxo de mensagens a fim de reduzir o ciclo de vida de desenvolvimento de fluxos reutilizáveis. Você também:

  • Aprendeu sobre APIs do WebSphere Message Broker
  • Aprendeu como usar essas APIs para criar padrões do fluxo de mensagens
  • Criou um projeto do padrão de fluxo de mensagens para instanciar fluxos de mensagens
  • Instanciou uma ocorrência de fluxo de mensagens a partir de um padrão
  • Aprendeu sobre as opções adicionais de compilação e implementação do arquivo BAR

Agradecimento

Os autores gostariam de agradecer a Dominic Storey, Software Engineer da equipe de Desenvolvimento do WebSphere Message Broker no Laboratório IBM Hursley, no Reino Unido, por suas importantes sugestões e feedback.

Download

Descrição Nome Tamanho Método de download
Code sample MessageBrokerPattern.zip 4 KB HTTP

Informações sobre métodos de download

Recursos

Recursos de Padrões do WebSphere Message Broker

  • Introduction to patterns in WebSphere Message Broker V7 – Este artigo do developerWorks fornece uma visão geral do uso de padrões para o desenvolvimento do fluxo de mensagens com o WebSphere Message Broker.
  • Introduction to pattern authoring in WebSphere Message Broker V7 – O WebSphere Message Broker V7 Fix Pack 1 apresentou a criação de padrões e este artigo do developerWorks mostra como criar seus próprios padrões para compartilhamento e reutilização no Message Broker.
  • Cheat using WebSphere Message Broker patterns –  Esta entrada do blog do developerWorks mostra como evitar erros comuns ao projetar e desenvolver fluxos de mensagens usando padrões no WebSphere Message Broker. Não é necessário ser especialista no Message Broker para usar os padrões na resolução de problemas de design do fluxo de mensagens.
  • ESB and connectivity patterns  – Esta wiki da IBM está repleta de informações instrutivas detalhadas sobre como usar padrões com o WebSphere Message Broker, WebSphere ESB e DataPower.
  • IBM Redbook: Patterns: SOA design using WebSphere Message Broker and WebSphere ESB – Este IBM Redbook discute os padrões para a integração do WebSphere Message Broker e WebSphere ESB e inclui um cenário para ajudá-lo a projetar, desenvolver e implementar esses produtos. O manual é destinado a clientes que estão considerando o uso de produtos ESB básicos e avançados e precisam de mais informações sobre a arquitetura, o design e a implementação.

Recursos Gerais do WebSphere Message Broker

Recursos do Websphere

Recursos do developerWorks

  • Downloads de avaliação para produtos de software IBM – Downloads gratuitos de avaliação para produtos IBM selecionados como® DB2®, Lotus®, Rational®, Tivoli® e WebSphere®.
  • Blogs do developerWorks – Participe de um bate-papo com usuários e autores do developerWorks, além de editores e desenvolvedores IBM.
  • Recursos de computação em nuvem do developerWorks – Acesse a nuvem IBM ou Amazon EC2, teste um produto de computação em nuvem IBM em uma sandbox, acompanhe as demos de produtos e serviços de computação em nuvem, leia artigos e acesse outros recursos sobre a nuvem.
  • Briefings de tecnologia do developerWorks – Sessões informativas técnicas grátis realizadas por especialistas IBM para acelerar a sua curva de aprendizagem e ajudá-lo a ter sucesso nos seus projetos de software mais desafiadores. Sessões que abordam desde briefings virtuais de 1 hora até sessões ao vivo com duração de meio dia ou um dia em cidades de todo o mundo.
  • Podcasts do developerWorks – Ouça entrevistas e debates interessantes e originais com inovadores de software.
  • developerWorks no Twitter – Confira as mensagens e URLs recentes no Twitter.
  • IBM Education Assistant – Uma coleção de módulos educacionais multimídia que ajudam a compreender melhor os produtos de software IBM e a usá-los de maneira mais eficiente para atender aos requisitos de negócios.

Sobre os autores

Devipriya Selvarajan é Messaging Consultant na equipe do WebSphere Lab Services. Ela lida com a ativação de Parceiros de Negócios para os Dispositivos de SOA do WebSphere Transformation Extender, WebSphere Message Broker, WebSphere MQ e WebSphere DataPower. É possível entrar em contato com Devipriya no endereço dselvara@in.ibm.com.

Rahul Gupta é WebSphere Message Broker Consultant na IBM Índia há cinco anos. Atualmente, trabalha como Technical Consultant de produtos middleware IBM para clientes do varejo nos Estados Unidos. É possível entrar em contato com Rahul no endereço rahul.gupta@in.ibm.com.

De 0 a 10, o quanto você recomendaria este artigo para um amigo?

developerWorks Brasil
Saiba mais

developerWorks Brasil

edit217 Artigo(s)

é o portal de tecnologia da IBM para profissionais de TI de todo o mundo. Colabore, aprenda a criar aplicativos inovadores e compreenda tecnologias avançadas. Acesse mais artigos e tutoriais em www.ibm.com/developerworks/br