Dicas de Resolução de Problemas do WS-Notification
Dicas para resolução de problemas de seu sistema de mensagens de publicação e assinatura do WS-Notification para serviços da web.
Para ajudar a identificar e a resolver problemas do WS-Notification,
use os recursos de rastreio e de criação de log do WebSphere Application Server conforme
descrito no Configurando o Rastreio de Componente (CTRACE).
Para ativar o rastreio para o WS-Notification, configure a cadeia de rastreio do servidor de aplicativos como SIBWsn=all=enabled:com.ibm.ws.sib.webservices.*=all=enabled. Se você encontrar algum problema que possa estar relacionado ao WS-Notification, será possível verificar as mensagens de erro no console administrativo do WebSphere Application Server e no arquivo SystemOut.log do servidor de aplicativos. Você também pode ativar o rastreio de depuração do servidor de aplicativos para fornecer um dump de exceção detalhado.
Uma lista das principais restrições conhecidas, aplicadas ao utilizar o WS-Notification, é fornecida no WS-Notification: Restrições Conhecidas.
As mensagens de sistema do WebSphere Application Server são registradas de várias origens, incluindo os componentes e aplicativos do servidor de aplicativos. As mensagens registradas pelos componentes do servidor de aplicativos e produtos IBM associados começam com um identificador de mensagens exclusivo que indica o componente ou o aplicativo que emitiu a mensagem. O prefixo do componente WS-Notification é CWSJN.
O tópico Referência de Solucionador de Problemas: Mensagens contém informações sobre todas as mensagens do WebSphere Application Server, indexadas pelo prefixo da mensagem. Para cada mensagem há uma explicação do problema e detalhes das ações que você possa tomar para resolver o problema.
- Um aplicativo JAX-WS, que é um consumidor bruto das notificações processadas pelo intermediário, deve reconhecer uma ação SOAP do broker de notificação
- O arquivo PublisherRegistrationManager.wsdl não é analisado com sucesso pelo wsimport, a menos que seja incluído o arquivo de ligações do JAX-WS
- O Serviço WS-Notification Recebe uma triggerActionNotSupportedFault
- Há Erros de "Tempo Limite da Conexão" nos seus Logs do Servidor Broker
- Há Erros de "Falta de Memória" nos seus Logs do Servidor Broker
- Aplicativos Clientes do WebSphere Application Server Versão 6.1 Devem Manipular as Condições de Erro Adicionais
- Exceção Ocorre Porque o Repositório SDO Não Está Configurado Corretamente
- Diversas Mensagens São Recebidas por um Consumidor de Notificação para cada Notificação de Eventos
- Problemas Podem Ocorrer ao Excluir Assinantes e Mecanismos do Sistema de Mensagens Administrados
- Há Diferenças Quando Usar os Destinos do Barramento com os Serviços WS-Notification Versão 6.1
- Uma Notificação de Entrada (Aplicativo para Intermediário) Não é Bem Sucedida
- Uma Notificação de Saída (Broker para Aplicativo) Não é Bem Sucedida
- Desativando Recursos com Preservação de Estado que não São Automaticamente Excluídos
- Assinatura Durável que Foi Criada pelo WS-Notification Não Pode Ser Excluída ao Usar o Painel do Barramento de Integração de Serviços
- Parada Administrativa de um Mecanismo do Sistema de Mensagens
- Falhas Como Resultado das Mudanças nas Configurações do Espaço de Tópico e do Namespace de Tópico
- Não é Possível Criar um Serviço WS-Notification Versão 6.1 sem um Repositório SDO Configurado
- Uma Exceção Ocorre Quando um Cliente JAX-WS Que Não Possui Acesso à Internet Tenta entrar em Contato com um Serviço WS-Notification
Um aplicativo JAX-WS, que é um consumidor bruto das notificações processadas pelo intermediário, deve reconhecer uma ação SOAP do broker de notificação
- No arquivo WSDL do aplicativo consumidor bruto, modifique as informações de ligação SOAP
para conter o URI de ação de notificação:
<wsdl:operation name="oneWayRawSubscriptionNotify"> <soap:operation soapAction="http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify" /> <wsdl:input name="oneWayRawSubscriptionNotifyRequest"> <soap:body use="literal" /> </wsdl:input> </wsdl:operation>
- No arquivo WSDL do aplicativo consumidor bruto, modifique o tipo as informações de tipo de porta
para conter o URI de ação de notificação:
<wsdl:operation name="oneWayRawSubscriptionNotify"> <wsdl:input message="impl:oneWayRawSubscriptionNotifyRequest" name="oneWayRawSubscriptionNotifyRequest" wsam:Action="http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify"> </wsdl:input> </wsdl:operation>
- Use uma anotação JAX-WS para especificar o URI de açãohttp://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify no código do aplicativo. Para obter mais informações, consulte a propriedade action da anotação WebMethod no tópico Anotações do JAX-WS.
O arquivo PublisherRegistrationManager.wsdl não é analisado com sucesso pelo wsimport, a menos que seja incluído o arquivo de ligações do JAX-WS
[ERROR] the following naming conflicts occurred:
com.ibm.websphere.wsn.publisher_registration_manager.ResourceNotDestroyedFault
line 2 of file:/path_to_wsdl/PublisherRegistrationManager.wsdl
Essa falha ocorre porque o WSDL do gerenciador de registro do publicador usa as especificações WS-Notification e WS-ResourceLifetime, que fazem referência a um elemento ResourceNotDestroyedFault que compartilha o mesmo nome da mensagem. A seguir há uma parte relevante do arquivo WSDL do gerenciador de registro do publicador:
<wsdl:operation name="DestroyRegistration">
<wsdl:input name="DestroyRegistrationRequest" message="wsn-brw:DestroyRegistrationRequest"
wsam:Action="http://docs.oasis-open.org/wsn/brw-2/PublisherRegistrationManager/DestroyRegistrationRequest"
wsaw:Action="http://docs.oasis-open.org/wsn/brw-2/PublisherRegistrationManager/DestroyRegistrationRequest"/>
<wsdl:output name="DestroyRegistrationResponse" message="wsn-brw:DestroyRegistrationResponse"
wsam:Action="http://docs.oasis-open.org/wsn/brw-2/PublisherRegistrationManager/DestroyRegistrationResponse"
wsaw:Action="http://docs.oasis-open.org/wsn/brw-2/PublisherRegistrationManager/DestroyRegistrationResponse"/>
<wsdl:fault name="ResourceUnknownFault" message="wsrf-rw:ResourceUnknownFault"
wsam:Action="http://docs.oasis-open.org/wsrf/fault"
wsaw:Action="http://docs.oasis-open.org/wsrf/fault"/>
<wsdl:fault name="ResourceNotDestroyedFault" message="wsn-brw:ResourceNotDestroyedFault"
wsam:Action="http://docs.oasis-open.org/wsn/fault" wsaw:Action="http://docs.oasis-open.org/wsn/fault"/>
</wsdl:operation>
<!-- Some parts have been omitted -->
<!-- An extract from WS-ResourceLifetime -->
<wsdl:operation name="Destroy">
<wsdl:input name="DestroyRequest" message="wsrf-rlw:DestroyRequest"
wsam:Action="http://docs.oasis-open.org/wsrf/rlw-2/ImmediateResourceTermination/DestroyRequest"
wsaw:Action="http://docs.oasis-open.org/wsrf/rlw-2/ImmediateResourceTermination/DestroyRequest"/>
<wsdl:output name="DestroyResponse" message="wsrf-rlw:DestroyResponse"
wsam:Action="http://docs.oasis-open.org/wsrf/rlw-2/ImmediateResourceTermination/DestroyResponse"
wsaw:Action="http://docs.oasis-open.org/wsrf/rlw-2/ImmediateResourceTermination/DestroyResponse"/>
<wsdl:fault name="ResourceNotDestroyedFault" message="wsrf-rlw:ResourceNotDestroyedFault"
wsam:Action="http://docs.oasis-open.org/wsrf/fault"
wsaw:Action="http://docs.oasis-open.org/wsrf/fault"/>
<wsdl:fault name="ResourceUnknownFault" message="wsrf-rw:ResourceUnknownFault"
wsam:Action="http://docs.oasis-open.org/wsrf/fault"
wsaw:Action="http://docs.oasis-open.org/wsrf/fault"/>
<wsdl:fault name="ResourceUnavailableFault" message="wsrf-rw:ResourceUnavailableFault"
wsam:Action="http://docs.oasis-open.org/wsrf/fault"
wsaw:Action="http://docs.oasis-open.org/wsrf/fault"/>
</wsdl:operation>
Para resolver esse conflito de nomenclatura, você deverá incluir o arquivo de ligações JAX-WS ibm-wsn-jaxws.xml como um argumento para o comando wsimport. Esse arquivo de ligações assegura que os elementos conflitantes sejam mapeados para diferentes nomes de classes.
c:\was\bin\wsimport -b ibm-wsn-jaxws.xml -keep PublisherRegistrationManager.wsdl
O Serviço WS-Notification Recebe uma triggerActionNotSupportedFault
Você possui um publicador JAX-WS baseado em demanda registrado com um tipo de Versão 7.0 do serviço WS-Notification. Quando o serviço chama qualquer uma das operações na interface PausableSubscriptionManager do publicador, o publicador responderá com uma mensagem de exceção triggerActionNotSupportedFault. As operações que acionam essa mensagem são Renew, Unsubscribe, PauseSubscription ou ResumeSubscription.
Essas mensagens são semelhantes ao seguinte texto no arquivo SystemOut.log do servidor. Neste exemplo, a mensagem de falha é acionada em resposta ao broker que tenta cancelar a assinatura a partir do publicador baseado em demanda.
triggerActionNotSupportedFault triggerActionNotSupportedFault: messageContext:
[MessageContext: logID=urn:uuid:13616A3EB4F278A3DC1221827497002] problemAction:
http://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/UnsubscribeRequest
CWSJN1029W: An attempt was made to perform an operation on a remote NotificationProducer
located with endpoint Address[[xxx/prod_service/NotificationProducerPort]],
ReferenceParams[] but the operation could not be completed. This operation will be
retried automatically in 2 seconds.
The operation failed due to com.ibm.ws.sib.wsn.webservices.WSNWSException:
CWSJN5035E: An internal error occurred: Unable to unsubscribe from remote publisher
at endpoint reference Address[[xxx/prod_service/PausableSubscriptionManagerPort]],
ReferenceParams[] due to javax.xml.ws.soap.SOAPFaultException:
The [action] cannot be processed at the receiver.
O servidor continua tentando cancelar a assinatura sem sucesso a partir do publicador em intervalos de tempo sempre crescentes.
Para resolver esse problema, no arquivo WSDL de seu publicador baseado em demanda, você deve explicitamente especificar a ação SOAP para usar cada uma das operações na interface PausableSubscriptionManager. O URI de ação para usar cada operação está definida na especificação Web Services Base Notification 1.3 (WS-BaseNotification) disponível em http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn. Por exemplo, a ação WS-Addressing para a operação Unsubscribe está definida na especificação comohttp://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/UnsubscribeRequest, portanto, você deve usar essa ação para a operação Unsubscribe no seu arquivo WSDL do publicador. A seguir há um trecho da seção de ligação de tal arquivo WSDL:
<wsdl:binding name="PausableSubscriptionManagerBinding" type="wsn-bw:PausableSubscriptionManager">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />
<wsdl:operation name="Unsubscribe">
<soap:operation soapAction="http://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/UnsubscribeRequest" />
Da mesma forma, você deve especificar as ações correspondentes para as operações Renew, PauseSubscription e ResumeSubscription no seu arquivo WSDL do publicador.
Há Erros de "Tempo Limite da Conexão" nos seus Logs do Servidor Broker
Se você ver erros WebServicesFault( "Connection timed out" ) nos logs do servidor broker WS-Notification e se tiver um número grande de consumidores inscritos no seu serviço WS-Notification, o broker poderá ter excedido o número máximo de conexões no conjunto de conexões do conector de saída HTTP ao enviar as mensagens de notificação de saída para os consumidores inscritos.
Para aumentar o número de conexões HTTP de saída no conjunto, configure a propriedade customizada com.ibm.websphere.webservices.http.maxConnection no servidor ou servidores nos quais seu broker está em execução. Para obter informações adicionais sobre essa propriedade, consulte Propriedades customizadas de transporte HTTP para aplicativos de serviços da Web.
Há Erros de "Falta de Memória" nos seus Logs do Servidor Broker
Se você ver erros "Falta de Memória" nos logs do servidor broker WS-Notification e se tiver um número grande de consumidores inscritos no seu serviço WS-Notification, o broker poderá ter excedido o tamanho de heap JVM disponível alocado para o servidor no qual ele está em execução.
Para aumentar o tamanho máximo de heap para o servidor ou servidores no qual seu broker está em execução, consulte Ajustando a IBM Virtual Machine para Java.
Aplicativos Clientes do WebSphere Application Server Versão 6.1 Devem Manipular as Condições de Erro Adicionais
- • Foi incluída uma nova condição de falha chamada UnableToGetMessagesFault. Ela é retornada em resposta a uma solicitação da operação GetMessages se alguma condição interna significar que não é possível retornar as mensagens. Note que isso é diferente do que não haver nenhuma mensagem a ser retornada, que é manipulado de modo diferente e é o caso mais provável.
- • O esquema para a operação GetMessages não requer mais um valor a ser passado para o número de mensagens a ser retornado. Se nenhum valor for passado, todas as mensagens disponíveis serão retornadas. Isso não afeta os aplicativos clientes do Versão 6.1, que já estão codificados para fornecer um valor.
- • A operação DestroyPullPoint agora emite a condição de falha ResourceUnknownFault além das condições de falha declaradas anteriormente.
O WSDL e os arquivos de esquema fornecidos com o WebSphere Application Server Versão 7.0 ou posterior são atualizados para refletir os padrões da Versão 1.3 final do WS-Notification.
Não é necessário alterar os serviços do WS-Notification existentes. Seus aplicativos clientes existentes também continuarão funcionando intactos, mas se eles também estiverem trabalhando com os serviços do WS-Notification e se desejar que eles manipulem explicitamente as novas condições de falha, gere novamente os stubs de cliente ao usar o arquivo WSDL a partir do novo serviço.
Exceção Ocorre Porque o Repositório SDO Não Está Configurado Corretamente
Se você tentar criar um serviço WS-Notification Versão 1.0 e obtiver o seguinte rastreio de pilha, isso indica que o repositório SDO não está configurado corretamente. Para resolver este problema, consulte Instalando e Configurando o Repositório SDO.
java.lang.Exception: com.ibm.ws.sib.webservices.admin.config.SIBConfigException: CWSWS5010E:
Falha ao armazenar o WSDL localizado em http://www.ibm.com/websphere/wsn/notification-broker
devido à seguinte exceção: com.ibm.ws.sib.webservices.exception.SIBWSUnloggedException:
CWSWS1007E: Ocorreu a seguinte exceção:
com.ibm.ws.sdo.config.repository.impl.RepositoryRuntimeException:
javax.transaction.TransactionRolledbackException: CORBA TRANSACTION_ROLLEDBACK 0x0 No;
A exceção aninhada é: org.omg.CORBA.TRANSACTION_ROLLEDBACK:
javax.transaction.TransactionRolledbackException: ; a exceção aninhada é:
javax.ejb.TransactionRolledbackLocalException: ; a exceção aninhada é:
com.ibm.ws.ejbpersistence.utilpm.PersistenceManagerException:
PMGR1014E: Ocorreu uma exceção ao obter o connection factory:
com.ibm.websphere.naming.CannotInstantiateObjectException:
emitida NameNotFoundException enquanto o NamingManager JNDI estava processando um
objeto javax.naming.Reference. [A exceção raiz é javax.naming.NameNotFoundException:
Contexto: smeagolNode03Cell/nodes/smeagolNode03/servers/server1, nome:
jdbc/com.ibm.ws.sdo.config/SdoRepository:
Primeiro componente no nome com.ibm.ws.sdo.config/SdoRepository não localizado.
[A exceção raiz é org.omg.CosNaming.NamingContextPackage.NotFound:
IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]] vmcid: 0x0 código secundário: 0 concluído: Não.
Diversas Mensagens São Recebidas por um Consumidor de Notificação para cada Notificação de Eventos
Em algumas situações, você pode receber mais notificações em um determinado consumidor de notificação do que o número de notificações de eventos que foram inseridas no intermediário de notificação por um publicador. Por exemplo, você pode publicar 4 mensagens e receber 8, 12, 16 (ou algum outro múltiplo de quatro) mensagens no consumidor de notificação.
Normalmente, isto é causado por haver duas ou mais assinaturas ativas que direcionam o consumidor de notificação - uma situação que poderá ocorrer se o aplicativo do assinante for executado mais de uma vez. Sempre que a operação Subscribe for chamada, uma nova assinatura deverá ser criada pelo intermediário de notificação (consulte a seção 4.2 da especificação Web Services Base Notification), o que causa a entrega de mensagens duplicadas, se existir uma assinatura anterior.
Para verificar se é isso o que está ocorrendo, examine a propriedade SubscriptionReference das notificações recebidas pelo consumidor de notificação. Esta referência de nó de extremidade contém o identificador da assinatura que causou o envio da notificação. Se você encontrar vários identificadores de assinatura diferentes, isto indica que existe mais de uma assinatura ativa.
Os aplicativos do assinante devem desativar assinaturas quando não forem mais necessárias (ou registrá-las com um tempo limite), no entanto, é possível desativá-las de maneira administrativa usando os painéis de tempo de execução, conforme descrito em Listando ou Excluindo Assinaturas Ativas do WS-Notification.
Problemas Podem Ocorrer ao Excluir Assinantes e Mecanismos do Sistema de Mensagens Administrados
- Excluindo Assinantes Administrados
Você deve ser cuidadoso ao excluir e recriar mecanismos de mensagem em membros de barramento para os quais os assinantes administrados por WS-Notification foram configurados, pois em alguns caso isso pode deixar a assinatura do serviço da Web remoto ativa (e passando mensagens de notificação para o servidor local), mesmo apesar de não existir mais nenhum registro dela.
Para evitar esta situação, você deve excluir a configuração do WS-Notification ou apenas os assinantes administrados, em uma etapa separada para excluir o mecanismo do sistema de mensagens. Quando a atualização de configuração dinâmica for então processada, ou se o servidor reiniciado, a assinatura do serviço da web remoto será desativada explicitamente.
Nota: Este problema não ocorrerá se apenas a configuração do WS-Notification tiver sido modificada; ele ocorrerá apenas se o mecanismo do sistema de mensagens também for excluído.- Assinantes Administrados em um Cluster
Ao remover mecanismos do sistema de mensagens de um cluster, remova-os em ordem numérica, do mais alto para o mais baixo, a fim de evitar uma situação em que, por exemplo, existam mecanismos do sistema de mensagens numerados como 001 e 002 e não 000. Isso é para evitar problemas caso você utilize o WS-Notification, o qual atribui significância especial ao primeiro mecanismo do sistema de mensagens criado em um cluster.
Em uma topologia em cluster, pode haver mais de um mecanismo do sistema de mensagens em execução no "membro do barramento" (cluster). Os assinantes administrados são definidos em um ponto de serviço (membro do barramento) e, portanto, existem várias alternativas ao escolher o mecanismo do sistema de mensagens responsável pela criação da assinatura para o serviço da web remoto. Neste caso, o "primeiro" mecanismo do sistema de mensagens no cluster será responsável por efetuar a assinatura. Por exemplo, em um cluster contendo três mecanismos do sistema de mensagens, os mecanismos do sistema de mensagens terão nomes seguindo o padrão xxx-000-yyy, xxx-001-yyy, xxx-002-yyy e as assinaturas de assinantes administrados serão gerenciadas pelo mecanismo do sistema de mensagens "000".
Se você excluir o mecanismo do sistema de mensagens "000" do cluster, em seguida, reiniciar os servidores, as assinaturas administradas agora serão gerenciadas pelo mecanismo do sistema de mensagens "001" - sendo o mecanismo com o número mais baixo no cluster. No entanto, conforme mencionado anteriormente, a exclusão e recriação de mecanismos do sistema de mensagens em membros do barramento para os quais foram configurados assinantes administrados podem deixar a assinatura do serviço da web remoto ativa (e transmitir mensagens de notificação para o servidor local) mesmo se não houver mais nenhum registro dela. Portanto, se outro mecanismo do sistema de mensagens for incluído posteriormente no cluster e não houver nenhum mecanismo do sistema de mensagens xxx-000-yyy definido, o novo mecanismo assumirá o nome de xxx-000-yyy. Portanto, neste caso, é possível que dois mecanismos do sistema de mensagens considerem simultaneamente que estejam gerenciando a assinatura administrada, resultando em diversas assinaturas sendo efetuadas no serviço da web remoto.
Embora pouco provável, se você precisar recriar o mecanismo do sistema de mensagens xxx-000-yyy, poderá evitar mensagens duplicadas de uma assinatura administrada ao concluir as seguintes etapas:- Excluir as assinaturas administradas definidas para este cluster.
- Permitir que os mecanismos do sistema de mensagens existentes observem a alteração. Isto fará com que os mecanismos do sistema de mensagens no cluster excluam as assinaturas administradas que eles consideram estar gerenciando.
- Criar o novo mecanismo do sistema de mensagens no cluster.
- Recriar as assinaturas administradas.
Há Diferenças Quando Usar os Destinos do Barramento com os Serviços WS-Notification Versão 6.1
Normalmente, um destino do barramento é usado conforme descrito em Destinos do barramento. Entretanto, esse não é o caso para serviços do WS-Notification Versão 6.1. O destino associado ao serviço do WS-Notification Versão 6.1 não se relaciona com os tópicos para os quais o serviço do WS-Notification pode tratar pedidos e você não deve alterar ou mediar o destino. No WS-Notification, a configuração de tópicos é manipulada por meio de namespaces de tópico. Para obter informações adicionais, consulte Criando um novo namespace de tópico permanente do WS-Notification.
- Intermediário de notificação
- Gerenciador de assinaturas
- Gerenciador de registro do publicador
Uma Notificação de Entrada (Aplicativo para Intermediário) Não é Bem Sucedida
Os aplicativos que desejam publicar notificações de eventos para o broker usam a operação Notify. Isto é definido como uma operação unidirecional (serviços da web), o que significa que não será possível retornar uma falha (exceção) se não for possível concluir a operação. Portanto, o aplicativo assumirá que a notificação foi bem-sucedida, mas os aplicativos assinantes não receberão a mensagem de notificação.
- Tópico inválido: a expressão de tópico fornecida não corresponde à sintaxe do dialeto indicado ou foi especificado um dialeto não suportado. Este é um erro do aplicativo.
- Namespace de tópico inválido: o aplicativo especifica um namespace de tópico que não foi configurado, mas o administrador especificou (no serviço WS-Notification) que não é permitido usar namespaces dinâmicos.
- Tópico não suportado: o tópico especificado foi proibido por um documento do namespace de tópico que foi aplicado ao namespace de tópico (por exemplo, é um subtópico de um tópico que foi marcado como "final").
- Credenciais inválidas: o ID do usuário ou senha especificada não é válida ou não possui a autoridade necessária. Isto é causado por uma incompatibilidade entre a configuração do aplicativo e as políticas de segurança do servidor.
- Publicador não registrado: O aplicativo tenta enviar uma notificação sem primeiro registrar-se no broker, mas o administrador configurou o serviço WS-Notification para requerer o registro de aplicativos. Isto é causado por um erro do aplicativo - um aplicativo com bom comportamento primeiro deve verificar se ele precisa registrar-se antes da publicação para um intermediário.
- O espaço de tópico do barramento de integração de serviço associado foi desativado.
É necessário monitorar este tipo de exceção rigorosamente, porque ele pode indicar um ataque de negação de serviço e, certamente, indicar que o aplicativo não está funcionando corretamente. A primeira vez que uma notificação de entrada falha a partir de um aplicativo de produção específico, é enviada uma mensagem de aviso para o registro SystemOut do servidor. Se houver mais falhas de notificação para este produtor, as mensagens de aviso cronometradas subseqüentes serão registradas em intervalos de 30 minutos. Informações adicionais são fornecidas com cada mensagem cronometrada para indicar quantas notificações com falha foram recebidas para esse produtor durante o intervalo de 30 minutos.
- O elemento ProducerReference do NotifyMessage fornecido na operação Notify. Este elemento identifica exclusivamente o aplicativo. No entanto, este elemento é opcional.
- O endereço IP do host que originou o pedido. Este endereço pode não identificar exclusivamente o aplicativo, mas restringe sua procura.
Uma Notificação de Saída (Broker para Aplicativo) Não é Bem Sucedida
Uma chamada de serviço da web de saída (broker para aplicativo) não é bem sucedida quando um aplicativo remoto está indisponível para chamada. Isso pode ser o resultado de uma falha do aplicativo, um erro da rede ou um problema de configuração do firewall. Quando as notificações de eventos não são passadas para os aplicativos assinantes, as mensagens construídas sobre as assinaturas ficam retidas no servidor. As mensagens retidas em uma determinada assinatura podem ser observadas ao usar os painéis de tempo de execução, conforme descrito em Listando ou Excluindo Assinaturas Ativas do WS-Notification. As assinaturas para as quais a tentativa de notificação de eventos mais recente falhou desta maneira são marcadas como estando em estado de ERRO quando visualizadas no painel de administração de tempo de execução de assinatura do WS-Notification.
Se o ponto de serviço do WS-Notification não notificar com êxito um aplicativo NotificationConsumer, será enviada uma mensagem de aviso para o log SystemOut do servidor de aplicativos e a assinatura será instruída a esperar por 2 minutos. As razões para uma falha deste tipo podem ser que o serviço da web remoto não esteja disponível no momento ou que as condições de rede impedem o contato entre o servidor local e o serviço.
Após 2 minutos, há uma nova tentativa de notificação. Se a entrega ainda não for possível, a assinatura será colocada de volta em um estado de espera por mais 2 minutos. Se a falha tiver sido causada por um erro de E/S temporário, este padrão será repetido indefinidamente, até que a notificação seja entregue com êxito ou você exclua a assinatura. Se o erro tiver sido causado por uma falha do aplicativo no lado remoto, a notificação será tentada novamente pelo número de vezes definido na configuração "Número máximo de entregas com falha" do destino do espaço de tópico do barramento de integração de serviços do qual a mensagem está sendo recebida. Quando a primeira mensagem de aviso tiver sido enviada para o registro SystemOut, as mensagens de aviso cronometradas subseqüentes serão registradas em intervalos de 30 minutos.
Desativando Recursos com Preservação de Estado que não São Automaticamente Excluídos
O ato de assinar no intermediário ou registrar um publicador cria um recurso com preservação de estado no servidor que consome recursos do sistema enquanto está ativo. Normalmente, um aplicativo especifica um tempo de término como parte do ato de criar estes recursos e, portanto, eles são automaticamente excluídos quando é atingido o tempo de término. No entanto, também é possível que o aplicativo solicite uma existência indefinida para o recurso. Se isto for feito, será possível que os recursos permaneçam no servidor indefinidamente, mesmo que o aplicativo nunca volte a utilizar (ou destruir) o recurso.
É possível visualizar os recursos stateful (assinaturas e registros do publicador) ao usar os painéis de tempo execução descritos em Interagindo no Tempo de Execução com o WS-Notification. Estes painéis também permitem excluir os itens de maneira administrativa, se necessário. Faça isso apenas se tiver certeza de que o aplicativo não está mais utilizando o recurso, porque ocorrerão falhas do aplicativo se o recurso for referido depois de ser excluído.
Assinatura Durável que Foi Criada pelo WS-Notification Não Pode Ser Excluída ao Usar o Painel do Barramento de Integração de Serviços
Ao criar uma assinatura ao usar um aplicativo do WS-Notification, ou seja, ao usar a operação Subscribe, uma ou mais assinaturas duráveis serão criadas no destino do espaço de tópico do barramento de integração de serviço relevante. Você pode visualizar estas assinaturas duráveis nos painéis de tempo de execução do barramento de integração de serviço para o ponto de publicação.
Para excluir uma assinatura que foi criada por um aplicativo do WS-Notification, utilize os painéis de tempo de execução fornecidos pela implementação do WS-Notification, conforme descrito em Interagindo no Tempo de Execução com o WS-Notification. Esta abordagem fecha o consumidor ativo e exclui automaticamente as assinaturas duráveis do barramento de integração de serviço relacionadas.
Parada Administrativa de um Mecanismo do Sistema de Mensagens
O WebSphere Application Server depende de poder acessar um mecanismo do sistema de mensagens do barramento de integração de serviços em execução para enviar e receber mensagens e para criar e recuperar o estado dos vários recursos de serviço da web criados.
É possível parar um mecanismo do sistema de mensagens ao usar a interface MBean ou os painéis de tempo de execução. Isto impede que o WS-Notification atenda com êxito os pedidos de aplicativos que possam surgir durante o período em que o mecanismo do sistema de mensagens estiver parado. Neste caso, as mensagens de erro são registradas conforme descrito em Uma Notificação de Entrada (Aplicativo para Intermediário) Não é Bem Sucedida e em Uma Notificação de Saída (Broker para Aplicativo) Não é Bem Sucedida. Ao parar um mecanismo do sistema de mensagens, todo o processamento do WS-Notification é parado e todos os aplicativos do sistema de mensagens param de funcionar. Quando reiniciar o mecanismo do sistema de mensagens, o processamento do WS-Notification será retomado.
Falhas Como Resultado das Mudanças nas Configurações do Espaço de Tópico e do Namespace de Tópico
Os artefatos de configuração do WS-Notification geralmente dependem dos objetos definidos em outras áreas da configuração do servidor. Por exemplo, os listeners terminais (para os serviços WS-Notification Versão 6.1) pelos quais as solicitações de aplicativo são recebidas e os espaços de tópicos do barramento de integração de serviços para os quais, e dos quais, as mensagens são enviadas.
Os itens a seguir descrevem a ação executada pelo código de tempo de execução do WS-Notification quando ele encontra alterações relevantes nos objetos dos quais depende.
- Excluindo um Espaço de Tópico do Barramento de Integração de Serviço
O espaço de tópico do barramento de integração de serviços é o objeto do sistema de mensagens primário do qual o WS-Notification depende no tempo de execução. As mensagens de notificação de um aplicativo são publicadas no espaço de tópico especificado pelo mapeamento do espaço de nomes de tópico (permanente) especificado pelo administrador.
A exclusão de um espaço de tópico do barramento de integração de serviço tem os seguintes efeitos sobre aplicativos do WS-Notification novos e existentes:- As solicitações RegisterPublisher que usam um namespace de tópico do WS-Notification que faz referência ao espaço de tópico excluído recebem uma mensagem de erro TopicNotSupportedFault.
- Os pedidos Notify para um tópico associado ao espaço de tópico excluído não publicam a mensagem no espaço de tópico (porque ele foi excluído). O aplicativo não é informado, porque não foram emitidas falhas pela operação Notify (consulte Uma Notificação de Entrada (Aplicativo para Intermediário) Não é Bem Sucedida).
- As solicitações de Subscribe que usam um namespace de tópico do WS-Notification que faz referência ao espaço de tópico excluído recebem uma mensagem de erro SubscribeCreateFailedFault.
- Não são enviadas mensagens adicionais para aplicativos que possuem assinaturas existentes no espaço de tópico excluído. A assinatura existente é excluída e qualquer tentativa de chamar operações na assinatura (por exemplo, getCreationTime) resulta em uma mensagem de erro ResourceUnknownFault.
- A exclusão e recriação de um espaço de tópico do barramento de integração de serviço são consideradas duas etapas separadas. As assinaturas existentes são excluídas em resposta à primeira etapa e, portanto, não existirão quando o espaço de tópico for recriado.
- Excluindo um Mapeamento do Espaço de Nomes de Tópico Permanente
A exclusão do mapeamento do espaço de nomes de tópico que foi utilizado para estabelecer uma assinatura (ativa no momento) tem o mesmo efeito que a exclusão do espaço de tópico do barramento de integração de serviço subjacente, conforme definido anteriormente, e as assinaturas que foram criadas utilizando este mapeamento de espaço de nomes são excluídas.
Os registros do publicador e os pontos de pull associados ao mapeamento do espaço de nomes de tópico excluído também são excluídos.
- Alterando um Mapeamento do Espaço de Nomes de Tópico Permanente
Os campos de um mapeamento do espaço de nomes de tópico permanente são campos de leitura, portanto, a única maneira de "alterar" os campos é excluir o mapeamento do espaço de nomes e recriá-lo com novos valores. O efeito da exclusão de um mapeamento do espaço de nomes de tópico permanente está descrito no item anterior.
Não é Possível Criar um Serviço WS-Notification Versão 6.1 sem um Repositório SDO Configurado
java.lang.Exception: com.ibm.ws.sib.webservices.admin.config.SIBConfigException: CWSWS5010E: Falha ao
armazenar o WSDL localizado em http://www.ibm.com/websphere/wsn/notification-broker em razão da seguinte
exceção:
com.ibm.ws.sib.webservices.exception.SIBWSUnloggedException: CWSWS1007E: Ocorreu a seguinte
exceção: com.ibm.ws.sdo.config.repository.impl.RepositoryRuntimeException:
javax.transaction.TransactionRolledbackException: CORBA TRANSACTION_ROLLEDBACK 0x0 Não; a exceção
aninhada é: org.omg.CORBA.TRANSACTION_ROLLEDBACK:
javax.transaction.TransactionRolledbackException: ;
a exceção aninhada é: javax.ejb.TransactionRolledbackLocalException: ;
a exceção aninhada é: com.ibm.ws.ejbpersistence.utilpm.PersistenceManagerException: PMGR1014E:
Ocorreu uma exceção ao obter o connection factory:
com.ibm.websphere.naming.CannotInstantiateObjectException: emitida NameNotFoundException enquanto
o NamingManager JNDI estava processando um objeto javax.naming.Reference.
[A exceção raiz é javax.naming.NameNotFoundException: Contexto:
KADGINNode01Cell/nodes/KADGINNode01/servers/server1, nome:
jdbc/com.ibm.ws.sdo.config/SdoRepository: Primeiro componente no nome
com.ibm.ws.sdo.config/SdoRepository não localizado.
[A exceção raiz é org.omg.CosNaming.NamingContextPackage.NotFound:
IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]] vmcid: 0x0 código secundário: 0 concluído: Não.
Para obter detalhes sobre como configurar o repositório SDO, consulte Instalando e Configurando o Repositório SDO.Uma Exceção Ocorre Quando um Cliente JAX-WS Que Não Possui Acesso à Internet Tenta entrar em Contato com um Serviço WS-Notification
WSDLException (at /definitions/import[1]): faultCode=OTHER_ERROR:
Unable to resolve imported document at 'http://docs.oasis-open.org/wsn/brw-2.wsdl',
relative to 'http://localhost:9082/WSNService1WSNServicePt1NB/Service/WEB-INF/wsdl
/NotificationBroker.wsdl': java.net.UnknownHostException: docs.oasis-open.org
Configure o cliente para usar uma cópia local do arquivo WSDL no lugar ao seguir as instruções no tópico Configurando um Cliente JAX-WS para Resolver o WSDL de um Serviço do WS-Notification sem Seguir Links da Web.