Escolhendo Provedores de Sistemas de Mensagens para um Ambiente Combinado

Se seu ambiente de sistema de mensagens existente ou planejado envolver ambos os sistemas IBM MQ e WebSphere Application Server, escolha entre o provedor de sistema de mensagens padrão, o provedor de sistema de mensagens do IBM MQ ou uma combinação dos dois, ao considerar seus requisitos de sistema de mensagens, seu ambiente de negócios e as necessidades de cada aplicativo de sistema de mensagens.

Sobre Esta Tarefa

Para um sistema de mensagens entre servidores de aplicativos, com alguma interação com um sistema IBM MQ, é possível usar o provedor de sistemas de mensagens padrão ou o provedor IBM MQ. Nenhum dos provedores é necessariamente melhor que o outro. A escolha de provedores depende principalmente dos fatores relacionados a seu ambiente de negócios e das mudanças planejadas para esse ambiente e, também, do que cada aplicativo JMS precisa fazer. Além disso, esses dois tipos de provedores de sistemas de mensagens não são mutuamente exclusivos:

  • É possível configurar ambos os tipos de provedores em uma célula.
  • Diferentes aplicativos podem utilizar provedores diferentes ou os mesmos.

Os fatores relacionados a seu ambiente de negócios incluem os seguintes:

  • Requisitos de sistema de mensagens
  • Conjunto de habilidades existente
  • Infra-estrutura do sistema de mensagens existente
  • Mudanças planejadas para essa infra-estrutura

A configuração e o gerenciamento de sua infraestrutura do sistema de mensagens serão mais simples se você usar apenas um provedor. Se seu sistema de mensagens estiver principalmente no IBM MQ, provavelmente o provedor de sistema de mensagens do IBM MQ deverá ser escolhido. Da mesma forma, se seu sistema de mensagens estiver principalmente no WebSphere Application Server, provavelmente o provedor de sistema de mensagens padrão deverá ser escolhido.

Se o seu ambiente de negócios não indicar claramente que você deve utilizar apenas um provedor, considere utilizar uma combinação dos dois e escolher o provedor de sistemas de mensagens mais apropriado para cada aplicativo. Uma maneira útil de fazer isso é identificar os tipos de destinos (barramento de integração de serviços ou a fila ou tópico do IBM MQ) que o aplicativo está usando. Se o aplicativo usar apenas destinos de barramento, a opção natural é usar o provedor do sistema de mensagens padrão (solução "DMP"). Se o aplicativo precisar se comunicar com um ou mais destinos do IBM MQ, será possível escolher qualquer uma das seguintes soluções, dependendo do seu ambiente de negócios, cenários de uso e topologias do sistema:
  • Use o provedor de sistemas de mensagens do IBM MQ (solução "MQP").
  • Use o provedor de sistemas de mensagens padrão para integrar um servidor IBM MQ (um gerenciador de filas ou um grupo de filas compartilhadas do IBM MQ) como um membro do barramento (solução "membro do barramento de interoperabilidade DMP").
  • Use o provedor de sistemas de mensagens padrão para integrar uma rede do IBM MQ como um barramento externo, usando links do IBM MQ (solução "interoperabilidade DMP, barramento externo").

Para obter informações adicionais sobre estas soluções, consulte Interoperação com o IBM MQ: comparação de recursos-chave.

Para ajudar a escolher entre essas soluções, diversas das etapas a seguir contêm tabelas nas quais cada linha representa um requisito de negócios ou de sistema, e os asteriscos (*) indicam as soluções que provavelmente serão mais eficazes para atender ao requisito. Estas tabelas são designadas para fornecer orientação geral, em vez de identificar soluções precisas. A maioria dos requisitos tem diversas soluções possíveis, e a ausência de um asterisco não necessariamente significa que você não possa usar essa solução. Para obter a melhor orientação do uso de cada uma dessas tabelas:
  • Concentre-se nas linhas que refletem seus requisitos mais importantes.
  • Para todas as linhas que você considerar, conte o número de asteriscos para cada solução.
As soluções com maior número de asteriscos provavelmente serão as mais eficazes.

Procedimento

  1. Se tiver um limite experimentado de IBM MQ ou de WebSphere Application Server e estiver tentando decidir qual produto melhor atende às suas necessidades de sistema de mensagens, consulte o Comparação do sistema de mensagens do WebSphere Application Server e o IBM MQ.
    Nota: Independente de qualquer um desses produtos que forem escolhidos como o foco principal para seu sistema de mensagens, ainda é possível usar o provedor de sistema de mensagens padrão ou o provedor do IBM MQ para interoperação entre os produtos.
  2. Considere seu ambiente de negócios para saber se é possível utilizar apenas um provedor.
    Ao decidir qual provedor será utilizado, considere as seguintes restrições:
    • Os requisitos de sistema de mensagens atuais e futuros
    • A infraestrutura de sistema de mensagens existente
    • O conjunto de habilidades que você tem em sua organização

    Se a maioria do seu sistema de mensagens for executado atualmente no IBM MQ, continue com essa abordagem e configure o IBM MQ como um provedor JMS externo (ou seja, use o provedor de sistema de mensagens do IBM MQ) no WebSphere Application Server. Se os requisitos JMS do seus aplicativos do WebSphere Application Server forem limitados, será discutido se o uso de um barramento de integração de serviços para esses aplicativos fornece benefício suficiente.

    Se você tiver aplicativos do sistema de mensagens no WebSphere Application Server que não possuírem nenhum requisito para interoperar com sua rede do IBM MQ, use o provedor de sistema de mensagens padrão (o barramento de integração de serviços). Se os requisitos do sistema de mensagens WebSphere Application Server demandarem uma integração mais forte com o WebSphere Application Server, o barramento de integração de serviços fornecerá os seguintes benefícios:

    • Administração integrada
    • Capacidades de alta disponibilidade do WebSphere Application Server
    • Escalabilidade do WebSphere Application Server

    Se escolher usar o provedor de sistema de mensagens padrão para interoperar entre a integração de serviço e o IBM MQ, lembre-se de que há um custo agregado envolvido ao converter as mensagens entre o formato de integração de serviços e o formato do IBM MQ.

    Considere também os seguintes cenários de sistema de mensagens:

    • Um grande backbone instalado dos gerenciadores de filas do IBM MQ, talvez com o produto do message broker.

      Se desejar usar o WebSphere Application Server para executar um aplicativo de sistema de mensagens recém-introduzido, será possível implementar um aplicativo de sistema de mensagens do WebSphere Application Server (JMS) que trocará mensagens com um aplicativo existente que usa uma fila ou um tópico do IBM MQ.

    • Uma instalação do WebSphere Application Server, talvez com aplicativos corporativos e da Web existentes, mas nenhum aplicativo de sistema de mensagens do WebSphere Application Server.

      Se não possuir nenhuma infraestrutura de sistema de mensagens existente, será possível implementar um aplicativo de sistema de mensagens do WebSphere Application Server (JMS) para trocar mensagens com um aplicativo de sistema de mensagens do WebSphere Application Server existente que usa um destino do barramento de integração de serviços.

    • Uma infraestrutura que usa o WebSphere Application Server para conectar os aplicativos de sistema de mensagens WebSphere Application Server.

      Introduza o sistema de mensagens WebSphere Application Server (JMS) entre um par de aplicativos WebSphere Application Server.

    • Uma infraestrutura que inclui ambos IBM MQ e barramentos de integração de serviços. Isso pode ser o resultado de uma fusão ou porque o tráfego de mensagem tende a ser a partir do WebSphere Application Server para o WebSphere Application Server, ou do IBM MQ para o IBM MQ, mas não normalmente entre o WebSphere Application Server e o IBM MQ.

      Implemente um aplicativo de sistema de mensagens do WebSphere Application Server (JMS) para trocar mensagens com um aplicativo que usa uma fila ou um tópico do IBM MQ.

  3. Se o seu ambiente de negócios não indicar claramente que você deve usar apenas um provedor de sistemas de mensagens, utilize uma combinação dos dois e escolha o provedor de sistemas de mensagens mais apropriado para cada aplicativo, com base nos tipos de destino utilizados pelo aplicativo.

    O aplicativo pode precisar trocar mensagens com aplicativos ou serviços parceiros existentes que utilizam um ou mais destinos conhecidos do tipo conhecido. Por outro lado, os aplicativos ou serviços parceiros poderiam, apesar disso, não ser implementados e a opção de tipo de destino poderia continuar aberta, neste caso o arquiteto de soluções precisaria decidir a melhor maneira de conectar os aplicativos ou serviços juntos.

    Se o aplicativo usar vários destinos, haverá quatro resultados possíveis:

    Nota: Se não houver nenhuma razão técnica ou de negócios clara pela qual o aplicativo usa os destinos do IBM MQ em vez de usar os destinos de barramento, e o aplicativo parceiro também for um aplicativo WebSphere Application Server JMS, considere migrar os destinos existentes para a integração de serviço, para que o aplicativo use apenas os destinos de barramento.
  4. Se o aplicativo usar apenas destinos do barramento, configure o aplicativo e seus recursos JMS para utilizarem o provedor de sistemas de mensagens padrão.
  5. Se o aplicativo usar apenas os destinos IBM MQ (filas ou tópicos) use a seguinte lista de verificação para determinar qual solução do provedor será usada.
    Tabela 1. Lista de Verificação do Provedor para um Aplicativo que Usa Apenas os Destinos do IBM MQ. A primeira coluna dessa tabela lista as questões da lista de verificação dos requisitos de negócios ou do sistema de um aplicativo que usa apenas destinos do IBM MQ. Na segunda coluna, os requisitos atendidos pela solução do provedor de sistemas de mensagens do IBM MQ (MQP) são marcados com um asterisco. Na terceira coluna, os requisitos atendidos pela solução do membro do barramento do Default Messaging Provider (interoperabilidade do DMP, membro do barramento) são marcados com um asterisco. Na quarta coluna, os requisitos atendidos pela solução do barramento externo do Default Messaging Provider (interoperabilidade do DMP, barramento externo) são marcados com um asterisco. Nas colunas de dois a quatro, os requisitos não atendidos pela solução mostrada nessa coluna não são marcados com asterisco.
    Pergunta: MQP Interoperação DMP, membro do barramento Interoperação DMP, barramento externo
    É crítico para o desempenho?

    (Se for, use o IBM MQ diretamente, em vez de executar a conversão da mensagem).

    *
    O aplicativo tem que enviar ou receber mensagens grandes (ou seja, mensagens > 500k.)? *
    A transparência do local é desejável para simplificar a programação e a implementação de aplicativos? * *
    O aplicativo deve consumir, a partir de uma fila do IBM MQ, a configuração da qual ele é fixo?

    (Ou seja, a fila não pode ser movida para a integração de serviço e você não deve implementar um aplicativo IBM MQ como estilo de envio para enviar as mensagens para um destino do barramento).

    * *
    O aplicativo parceiro é um aplicativo JMS que será executado fora do WebSphere Application Server, como um barramento ou um cliente do IBM MQ?

    (Não combine a integração de serviço e o IBM MQ, a menos que isso seja necessário; uma solução do IBM MQ ou de integração de serviço pura é mais simples e evita o custo de converter as mensagens entre os formatos da integração de serviço e do IBM MQ).

    *
    O aplicativo de parceiro é um aplicativo não-JMS (não-WebSphere Application Server)?

    (Sempre que possível, escolha uma solução do IBM MQ ou de integração de serviço pura. Use o cliente MQI IBM MQ, o cliente IBM MQ XMS ou o cliente de barramento XMS, dependendo de sua preferência de API).

    *
    Você prefere que o tráfego passe entre sua rede do IBM MQ e os aplicativos do WebSphere Application Server para que ele seja funilado em uma única conexão de execução longa? *
    Você deseja usar os recursos de alta disponibilidade do WebSphere Application Server? *
    O two-phase commit XA (2PC) é necessário entre o aplicativo e um grupo de filas compartilhadas do IBM MQ? * Consulte 1 * Consulte 2
    O two-phase commit XA (2PC) é necessário entre o aplicativo e um cluster do IBM MQ? *
    Você está usando o WebSphere Enterprise Service Bus para mediar as mensagens a partir de, ou entregá-las para, uma fila do IBM MQ?

    (Por exemplo, utilizando adaptadores do WebSphere Business Integration ou conectando-se a um provedor de serviços como o CICS.)

    *
    O aplicativo deve consumir, a partir de uma fila do IBM MQ, a configuração da qual ele é fixo?

    (ou seja, a fila não pode ser movida para a integração de serviço e você não deseja implementar um aplicativo IBM MQ como estilo de envio para enviar as mensagens para um destino do barramento).

    * *  
    Nota:
    • 1 Contanto que o IBM MQ Versão 7.0.1 seja usado.
    • 2 O two-phase commit XA pode ser usado com o link do IBM MQ, mas cobre apenas o envio da mensagem para o link do IBM MQ. Ele não cobre o envio subsequente da mensagem a partir do link do IBM MQ para um gerenciador de filas do IBM MQ usando o armazenamento e encaminhamento.
  6. Se o aplicativo usar uma combinação de destinos do barramento e do IBM MQ, por exemplo, consumir a partir da integração de serviço e enviar para o IBM MQ, então um dos modelos de interoperação do provedor de sistema de mensagens padrão poderá suportar isso ao usar um connection factory ou uma especificação de ativação única. Utilize a seguinte lista de verificação para ajudar a decidir entre um membro do barramento e uma solução de barramento externo.
    Tabela 2. Lista de Verificação do Provedor para um Aplicativo que Usa uma Combinação de Destinos de Barramento e do IBM MQ. A primeira coluna dessa tabela lista as questões da lista de verificação dos requisitos de negócios ou do sistema de um aplicativo que usa uma combinação de destinos de barramento e do IBM MQ. Na segunda coluna, os requisitos atendidos pela solução do membro do barramento do Default Messaging Provider (interoperabilidade do DMP, membro do barramento) são marcados com um asterisco. Na terceira coluna, os requisitos atendidos pela solução do barramento externo do Default Messaging Provider (interoperabilidade do DMP, barramento externo) são marcados com um asterisco. Nas colunas dois e três, os requisitos não atendidos pela solução mostrada nessa coluna não são marcados com um asterisco.
    Pergunta: Interoperação DMP, membro de barramento Interoperação DMP, barramento externo
    O aplicativo deve consumir a partir de uma fila compartilhada do IBM MQ? *
    Você prefere que o tráfego passe entre sua rede do IBM MQ e os aplicativos do WebSphere Application Server para que ele seja funilado em uma única conexão de execução longa? *
    Você precisa que o IBM MQ seja distribuído em versões anteriores ao WebSphere Application Server Versão 7 e IBM MQ Versão 7? *
    Você deseja que os recursos de armazenamento e encaminhamento permitam que o aplicativo continue enviando mensagens quando o gerenciador de filas do IBM MQ estiver indisponível? *
    Prefere não configurar os canais de conexão do servidor?

    (Isto porque eles abrem uma porta, que pode ser considerado um risco à segurança.)

    * Consulte 1
    Você prefere definir um canal de conexão do servidor no lugar de um par de canais emissor e receptor? *
    Você deseja usar apenas as conexões de ligações? *  
    Nota:
    • 1 Isso será aplicável somente se você desejar enviar mensagens do IBM MQ para o barramento de integração de serviços por meio do link do IBM MQ, embora não seja necessário abrir uma porta para seu servidor de aplicativos. Enviar as mensagens a partir do barramento de integração de serviços para o IBM MQ por meio do link do IBM MQ requer que uma porta seja aberta para o gerenciador de filas atravessar seu firewall.
  7. Se os tipos de destino ainda não forem conhecidos, decida as prioridades relativas das preocupações conhecidas e, em seguida, utilize a lista de verificação a seguir para avaliar como cada uma delas é tratada pelas possíveis soluções de provedor.

    A opção subjacente é o tipo de destino que este aplicativo deve usar. Os tipos de destino ainda não são fixos, portanto, qualquer uma das quatro soluções é possível, mas como regra geral, você deve ter como meta a solução "DMP" ou "MQP", porque uma solução do IBM MQ ou de integração de serviço pura é mais simples e evita o custo de converter as mensagens entre os formatos de integração de serviço e do IBM MQ.

    Tabela 3. Lista de Verificação do Provedor para um Aplicativo Cujos Tipos de Destino Ainda Não São Conhecidos. A primeira coluna dessa tabela lista as questões da lista de verificação dos requisitos de negócios ou do sistema de um aplicativo cujos tipos de destino ainda não são conhecidos. Na segunda coluna, os requisitos atendidos pela solução do provedor de sistemas de mensagens padrão (DMP) são marcados com um asterisco. Na terceira coluna, os requisitos atendidos pela solução do provedor de sistema de mensagens do IBM MQ (MQP) são marcadas com um asterisco. Na quarta coluna, os requisitos atendidos pela solução do membro do barramento do provedor de sistemas de mensagens padrão (interoperação DMP, membro do barramento) são marcados com um asterisco. Na quinta coluna, os requisitos atendidos pela solução do barramento externo do provedor de sistemas de mensagens padrão (interoperação DMP, barramento externo) são marcados por um asterisco. Nas colunas dois a cinco, os requisitos que não são atendidos pela solução mostrada na coluna não são marcados com asteriscos.
    Pergunta: DMP MQP Interoperação DMP, membro de barramento Interoperação DMP, barramento externo
    Você possui uma base de qualificações fortes existente para gerenciar o IBM MQ? * * *
    Você deseja que o gerenciamento de todo o sistema de mensagens seja manipulado pela equipe do IBM MQ? *
    Você possui administradores qualificados no WebSphere Application Server mas não no IBM MQ? *
    Deseja um produto de sistema de mensagens com uma grande base instalada (incluindo referências) e uma ampla escolha de ferramentas ISV? *
    Você insiste em comprar um produto licenciado separadamente, além do WebSphere Application Server? *
    Você insiste em instalar e gerenciar um produto separado, além do WebSphere Application Server? *
    Você já está usando o IBM Integration Bus, conhecido em versões anteriores como WebSphere Message Broker?

    (Se sim, você precisa do IBM MQ de qualquer forma).

    * * *
    O aplicativo precisa enviar ou receber mensagens grandes (ou seja, mensagens > 500k.)? *
    A transparência do local é desejável para simplificar a programação e a implementação de aplicativos? * * *
    Todos os requisitos precisam de vários canais ou rotas paralelas? * * *
    O aplicativo parceiro é um aplicativo JMS que também será executado no WebSphere Application Server?

    (A integração de serviço é executada no servidor de aplicativo do WebSphere Application Server. Em plataformas distribuídas, isso significa que está em andamento. [z/OS]Na plataforma z/OS, está em outra região. Portanto, usar o provedor de sistemas de mensagens padrão oferece uma possível vantagem no desempenho em plataformas distribuídas, mas não na plataforma z/OS. )

    *
    O aplicativo parceiro é um aplicativo JMS que será executado fora do WebSphere Application Server, como um barramento ou um cliente do IBM MQ?

    (Não combine a integração de serviço e o IBM MQ, a menos que isso seja necessário; uma solução do IBM MQ ou de integração de serviço pura é mais simples e evita o custo de converter as mensagens entre os formatos da integração de serviço e do IBM MQ).

    * *
    O aplicativo de parceiro é um aplicativo não JMS (não WebSphere Application Server)?

    (Sempre que possível, escolha uma solução do IBM MQ ou de integração de serviço pura. Use o cliente MQI IBM MQ, o cliente IBM MQ XMS ou o cliente de barramento XMS, dependendo de sua preferência de API).

    * *
    A manutenção da ordem de mensagens estritas é importante? *
    O aplicativo requer flexibilidade e conveniência de um cluster do IBM MQ?

    (O armazenamento em cluster do IBM MQ simplifica a administração e fornece paralelismo seletivo de filas em cluster. Ou seja, as instâncias de uma fila em cluster podem ser criadas em quaisquer (mas não necessariamente em todos os) gerenciadores de filas no cluster do IBM MQ. As mensagens enviadas para a fila em cluster podem ser endereçadas para uma instância específica da fila ou uma instância pode ser selecionada dinamicamente com base nas estatísticas de gerenciamento de carga de trabalho. O armazenamento em cluster do WebSphere Application Server fornece alguma dessa flexibilidade, porém, não é possível criar partições de um destino do barramento em um subconjunto de mecanismos de sistema de mensagens em um membro do barramento de cluster).

    * * *
    O aplicativo precisa de um nível de alta disponibilidade fornecido pelas filas compartilhadas do IBM MQ for z/OS? * * *
    Você deseja usar os recursos de alta disponibilidade ou de escalabilidade do armazenamento em cluster do WebSphere Application Server? * * *

Ícone que indica o tipo de tópico Tópico de Tarefa



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tmj_jmsp_mixed
Nome do arquivo: tmj_jmsp_mixed.html