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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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. 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? |
* |
|
* |
* |