Os destinos JMS que fornecem mensagens a um nó JMSInput ou recebem mensagens de um nó JMSOutput podem ser coordenados pelo ponto de sincronização como parte de uma transação global do fluxo de mensagens.
Transações Envolvendo o Coordenador do Ponto de Sincronização
Nesse diagrama, as mensagens são consumidas a partir de um tópico por um nó JMSInput e são produzidas para um nó JMSOutput da fila JMS. Os nós são conectados a, e estão na sessão com um provedor JMS. Qualquer nó input do fluxo de mensagens pode informar o Coordenador do Ponto de Sincronização externo quando uma transação do fluxo de mensagens é inicia e encerrada e se quaisquer recursos que foram utilizados pelo fluxo devem ser confirmados ou devem sofre rollback.
O Coordenador do Ponto de Sincronização envia pedidos compatíveis com XA/Open a todos os Gerenciadores de Recursos participantes para informá-los que devem ser preparados. Quaisquer alterações são, então, confirmadas ou sofrem rollback. Os Gerenciadores de Recursos, como o WebSphere MQ, o DB2 e qualquer provedor JMS compatível com XA, podem participar de uma transação global. O Coordenador do Ponto de Sincronização externo é o WebSphere MQ nas plataformas distribuídas e RRS (Resource Recovery Services) no z/OS.
Os nós JMSInput e JMSOutput podem participar de uma transação global apenas se o provedor JMS ao qual eles estão conectados suportar a interface XA/Open por meio da Classe JMS XAResource. Um provedor JMS de exemplo é o WebSphere MQ Java Client.
Transações Pendentes
As transações pendentes podem ocorrer quando um Gerenciador de Recursos não responde a uma chamada do Gerenciador do Ponto de Sincronização, sendo que a chamada é para confirmar ou efetuar rollback de recursos. Durante a inicialização do gerenciador de filas do WebSphere MQ do intermediário, uma etapa de recuperação inicial é realizada para assegurar que quaisquer transações pendentes sejam resolvidas antes que os fluxos de mensagens do intermediário comecem a processar nova entrada. Um provedor JMS que participa das transações globais do intermediário é incluído nessa etapa de recuperação.
Configuração para Ativar o Suporte à Transação Global
Quando o gerenciador de filas do WebSphere MQ do intermediário é inicializado, ele carrega o arquivo do Comutador. O arquivo do Comutador encaminha as chamadas de transação XA/Open do Coordenador do Ponto de Sincronização para o Provedor JMS. Isso assegura que os recursos JMS que participam da transação podem ser coordenados na sincronização com outros Gerenciadores de Recursos envolvidos na mesma transação.
XAResourceManager: Name=WBIWMQJMS SwitchFile=/<Caminho da Instalação>/lib/JMSSwitch.so XAOpenString=<Depósito de Informações do Provedor de Contexto Inicial>, <Local das Ligações JNDI>' <Proprietário LDAP>, <Credenciais LDAP>, <Nome da Connection Factory de Recuperação> ThreadOfControl=THREADEm que:
<Caminho da Instalação> é o local da instalação do WebSphere Message Broker. Este valor é obrigatório.
Você deve especificar uma sub-rotina no arquivo .ini do gerenciador de filas do intermediário para cada provedor JMS que você deseja utilizar, ou seja, deve haver uma sub-rotina para cada novo provedor JMS, sendo que o provedor JMS pode ser especificado por qualquer nó JMSInput ou JMSOutput incluído em um fluxo de mensagem que está em execução em um intermediário.
Os valores para o depósito de informações do provedor de Contexto Inicial e Local de ligações JNDI na sub-rotina devem corresponder aos especificados nos nós JMSInput ou JMSOutput nos fluxos de mensagens.
Os parâmetros LDAP devem corresponder aos especificados através do comando mqsicreatebroker ou mqsichangebroker.
O nome do Depósito de Informações do Provedor de Recuperação deve corresponder ao nome de um Connection Factory de Fila criado nos objetos administrados por JNDI. Se isso for omitido, um depósito de informações do provedor padrão chamado recoverXAQCF é utilizado. Em qualquer um dos dois casos, esse valor deve referir-se a um objeto administrador por JNDI que já foi criado.
Segue uma sub-rotina de exemplo:
XAOpenString=com.sun.jndi.fscontext.RefFSContextFactory, /u/myJndiFileLocation, , , myRecoveryQCFNameOnde os parâmetros LDAP são omitidos, mas uma Connection Factory de Fila definida é especificada para recuperação.
Como no Linux e Unix, as mesmas informações são requeridas no Windows, mas isso é configurado utilizando o snap-in WebSphere MQ Explorer ou WebSphere MQ Services, dependendo da versão do WebSphere MQ que você está utilizando. No Windows, o arquivo do Comutador é chamado de JMSSwitch.dll. Consulte o WebSphere MQ System Administration Guide para obter detalhes sobre como atualizar o arquivo qm.ini. A entrada extra, chamada de XACloseString, deve corresponder aos valores fornecidos para XAOpenString.
No WebSphere Message Broker, o único provedor JMS atualmente suportado é o IBM WebSphere MQ Java Client. O único modo de transporte suportado no momento para o cliente é o modo BIND. Nenhuma outra etapa de configuração é requerida
Qualquer provedor JMS que esteja em conformidade com o Especificação Java Message Service, Versão 1.1 e que suporte a API JMS XAResource através da sessão JMS pode ser utilizado se a coordenação da transação for requerida.
Se o designer da mensagem tiver especificado um provedor não compatível com XA, somente o modo não transacional é suportado. Nesse caso, você deve configurar a propriedade Modo de Transação para não para todos os nós JMSInput e JMSOutput.