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.
Na figura a seguir, as mensagens são consumidas de um tópico por um nó JMSInput e são produzidas para uma fila JMS em um nó JMSOutput. Os nós são conectados a, e estão na sessão com um provedor JMS. Qualquer nó de entrada do fluxo de mensagens pode informar o Coordenador do Ponto de Sincronização externo quando uma transação do fluxo de mensagens for iniciada ou encerrada e se os recursos que foram tocados pelo fluxo devem ser confirmados ou se deve ser efetuado seu rollback.
IMAGE HERE
O Coordenador do Ponto de Sincronização envia pedidos compatíveis com XA/Open a todos os Gerenciadores de Recursos participantes para informá-los como se preparar, em seguida, as alterações são confirmadas ou sofrem rollback. Os Gerenciadores de Recursos, como o WebSphere MQ, 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 em 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.
Durante a inicialização do gerenciador de filas do WebSphere MQ do intermediário, é executada uma etapa de recuperação inicial para assegurar que qualquer transação pendente seja resolvida antes de os fluxos de mensagens do intermediário iniciarem o processamento de uma nova entrada. As transações pendentes podem ocorrer quando um Gerenciador de Recurso não responder a uma chamada do Gerenciador de Ponto de Sincronização para confirmar ou efetuar rollback de recursos. Um provedor JMS que participa de transações globais do intermediário é incluído nesta etapa de recuperação durante a etapa de inicialização do gerenciador de filas do intermediário.
O arquivo do Comutador redirecionará chamadas de transações XA/Open do Coordenador do Ponto de Sincronização para o Provedor JMS. Isso assegurará que os recursos JMS que participam da transação possam ser coordenados em 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 de 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 Broker. Esse valor é obrigatório. Os parâmetros fornecidos em XAOpenString são delimitados por vírgula e têm posição determinada. Qualquer parâmetro opcional ausente deve ser representado por uma vírgula se outros parâmetros forem fornecidos posteriormente na cadeia.
<Contexto Inicial> é o identificador do Depósito de Informações do Provedor de Contexto Inicial para o provedor JMS. Este valor é obrigatório.
<Local de> é o caminho do arquivo para o arquivo .bindings (não inclua o próprio nome do arquivo) ou o local do diretório LDAP dos objetos administrados por JNDI que podem ser utilizados para criar um depósito de informações do provedor de contexto inicial para a conexão JMS. Consulte o nó JMSInput ou JMSOutput para obter detalhes adicionais sobre como criar os objetos administrados de JNDI. Este valor é obrigatório.
<Proprietário LDAP> Um parâmetro opcional para especificar o proprietário (ID do usuário) que pode ser requerido quando um banco de dados LDAP é utilizado para conter objetos administrados por JNDI.
<Credenciais LDAP> Um parâmetro opcional utilizado para especificar as Credenciais (senha) que podem ser requeridas se um banco de dados LDAP for utilizado para conter os objetos administrados por JNDI e quais são protegidas por senha.
<Depósito de Informações do Provedor de Recuperação> Um parâmetro opcional utilizado para especificar o nome de um objeto Connection Factory de Fila nos objetos administrados por JNDI para fins de recuperação, quando o nome não padrão é requerido.
Você deve especificar uma sub-rotina no arquivo ".ini" do Gerenciador de Filas dos intermediários para cada provedor JMS que você deseja utilizar. Ou seja, deve haver uma sub-rotina para cada novo provedor JMS que pode ser especificado por qualquer nó JMSInput ou JMSOutput incluído em um fluxo de mensagens em execução nesse 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.
De forma semelhante, os parâmetros LDAP devem corresponder aos especificados utilizando o comando mqsicreatebroker ou mqsichangebroker para esse intermediário.
O Nome do Depósito de Informações do Provedor de Recuperação deve corresponder a um nome de Connection Factory criado nos objetos administrados por JNDI. Se omitido, um depósito de informações do provedor padrão chamado "recoveryQCF" será utilizado. Em qualquer caso, este valor deve ser um objeto administrado por JNDI criado anteriormente. Por 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.
As mesmas informações são requeridas, mas elas são configuradas utilizando o snap-in do WebSphere MQ Services para incluir os detalhes no registro. Nesse caso, o arquivo do Comutador é chamado JMSSwitch.dll. Consulte o Guia de Administração do Sistema WebSphere MQ para obter detalhes sobre como atualizar o arquivo qm.ini. Neste caso, uma entrada "Stanza" extra chamada 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
O provedor JMS padrão para essa implementação é o WebSphere MQ. No entanto, se a coordenação da transação for requerida, qualquer provedor JMS poderá ser utilizado, desde que esteja de acordo com a especificação JMS 1.1 e suporte a API JMS XAResource através da sessão JMS.
No entanto, se o designer de mensagem tiver especificado um provedor não compatível com XA, somente o modo não transacional será suportado e o designer também deverá configurar a propriedade Avançada Modo de Transação para não para todos os nós JMSInput e JMSoutput.