WS-Notification 문제점 해결 팁

웹 서비스를 위한 WS-Notification 공개 및 등록 문제점 해결 팁입니다.

[z/OS]WS-Notification 문제점 식별 및 해결을 도우려면 컴포넌트 추적(CTRACE) 설정에 설명된 대로 WebSphere Application Server 추적 및 로깅 기능을 사용하십시오.

WS-Notification에 대한 추적을 사용으로 설정하려면 애플리케이션 서버 추적 문자열을 SIBWsn=all=enabled:com.ibm.ws.sib.webservices.*=all=enabled로 설정하십시오. WS-Notification에 관련된 것으로 판단되는 문제점이 발생하는 경우 WebSphere Application Server 관리 콘솔 및 애플리케이션 서버 SystemOut.log 파일에서 오류 메시지를 확인할 수 있습니다. 또한 애플리케이션 서버 디버그 추적을 사용하여 자세한 예외 덤프를 제공할 수도 있습니다.

참고: 이 주제는 하나 이상의 애플리케이션 서버 로그 파일을 참조합니다. 권장되는 대안은 분배 및 IBM® i 시스템에서 SystemOut.log, SystemErr.log, trace.logactivity.log 파일을 사용하는 대신 HPEL(High Performance Extensible Logging) 로그를 사용하고 인프라를 추적하도록 서버를 구성하는 것입니다. 원시 z/OS 로깅 기능과 연계하여 HPEL을 사용할 수도 있습니다. HPEL을 사용하는 경우 서버 프로파일 바이너리 디렉토리의 LogViewer 명령행 도구를 사용하여 모든 로그에 액세스하고 정보를 추적할 수 있습니다. HPEL 사용에 대한 자세한 정보는 HPEL을 사용한 애플리케이션 문제점 해결 정보를 참조하십시오.

WS-Notification을 사용할 때 적용되는 알려진 기본 제한사항의 목록은 WS-Notification: 알려진 제한사항에 제공됩니다.

WebSphere Application Server 시스템 메시지는 애플리케이션 서버 컴포넌트 및 애플리케이션을 포함한 다양한 소스로부터 로그됩니다. 애플리케이션 서버 컴포넌트 및 연관된 IBM 제품에 의해 로그되는 메시지는 메시지를 발생한 컴포넌트 또는 애플리케이션을 표시하는 고유 메시지 ID로 시작됩니다. WS-Notification 컴포넌트의 접두부는 CWSJN입니다.

문제점 해결자 참조: 메시지 주제에는 메시지 접두부로 색인화되어 있는 모든 WebSphere Application Server 메시지에 대한 정보가 포함되어 있습니다. 각 메시지마다 문제점에 대한 설명과 문제점 해결을 위해 수행할 수 있는 조치에 대한 세부사항이 제공됩니다.

다음은 일반적으로 발생할 수 있는 문제점을 해결하는 데 도움이 될 수 있는 일련의 팁입니다.

중개 대상 알림의 원 이용자인 JAX-WS 애플리케이션이 알림 브로커 SOAP 조치를 인식해야 함

JAX-WS는 조치 기반 디스패치를 지원하며 JAX-WS 원시 이용자 애플리케이션은 http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify 조치 URI를 승인해야 합니다. 다음 방식 중 하나로 이를 사용 설정할 수 있습니다.
  • 원 이용자 애플리케이션 WSDL 파일에서 알림 조치 URI를 포함하도록 SOAP 바인딩 정보를 수정합니다.
    <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>
  • 원 이용자 애플리케이션 WSDL 파일에서 알림 조치 URI를 포함하도록 포트 유형 정보를 수정합니다.
    <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>
  • JAX-WS 어노테이션을 사용하여 애플리케이션 코드에서 조치 URI http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify를 지정합니다. 자세한 정보는 JAX-WS 어노테이션 주제에서 WebMethod 어노테이션의 action 특성을 참조하십시오.

JAX-WS 바인딩 파일을 포함시키지 않으면 PublisherRegistrationManager.wsdl 파일이 정상적으로 구문 분석되지 않음

WS-Notification 애플리케이션에 대한 WSDL 파일을 압축 파일로 공개한 다음 wsimport 명령을 PublisherRegistrationManager.wsdl 파일에 대해 실행하면 다음 결함 메시지가 표시됩니다.
[ERROR] the following naming conflicts occurred: 
com.ibm.websphere.wsn.publisher_registration_manager.ResourceNotDestroyedFault
line 2 of file:/path_to_wsdl/PublisherRegistrationManager.wsdl

이 결함은 공개자 등록 관리자의 WSDL이 WS-Notification 및 WS-ResourceLifetime 스펙을 둘 다 사용하고 이 두 스펙 모두 같은 메시지 이름을 공유하는 ResourceNotDestroyedFault 요소를 참조하기 때문에 발생합니다. 다음은 공개자 등록 관리자 WSDL 파일의 관련 파트입니다.

  <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>

이 이름 지정 충돌을 해결하려면 JAX-WS 바인딩 파일 ibm-wsn-jaxws.xml을 wsimport 명령에 대한 인수로 포함시켜야 합니다. 이 바인딩 파일은 충돌하는 요소가 서로 다른 클래스 이름으로 맵핑되도록 합니다.

ibm-wsn-jaxws.xml 파일은 app_server_root/util 디렉토리에 있습니다. 예: c:\was\util\ibm-wsn-jaxws.xml. 이 바인딩 파일은 WSDL 파일이 자신과 동일한 디렉토리에 있다고 예상하기 때문에 wsimport 명령을 실행하기 전에 바인딩 파일을 PublisherRegistrationManager.wsdl 파일이 있는 디렉토리로 복사해야 합니다. 다음은 wsimport 명령을 실행하여 ibm-wsn-jaxws.xml 파일을 포함하는 방법의 예입니다.
c:\was\bin\wsimport -b ibm-wsn-jaxws.xml -keep PublisherRegistrationManager.wsdl

WS-Notification 서비스가 triggerActionNotSupportedFault를 수신함

버전 7.0 유형의 WS-Notification 서비스에 등록되어 있는 JAX-WS 수요 기반 공개자가 있습니다. 서비스가 공개자의 PausableSubscriptionManager 인터페이스에 대한 조작을 호출하면 공개자가 triggerActionNotSupportedFault 예외 메시지로 응답합니다. 이 메시지를 트리거하는 조작은 Renew, Unsubscribe, PauseSubscription 또는 ResumeSubscription입니다.

다음 텍스트와 비슷한 메시지를 서버의 SystemOut.log 파일에서 볼 수 있습니다. 이 예제에서 결함 메시지는 수요 기반 공개자로부터 등록 해제하려고 시도하는 브로커에 대한 응답으로 트리거됩니다.

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.

서버는 계속해서 증가하는 시간 간격으로 공개자로부터 실패한 등록 해제를 계속해서 시도합니다.

수요 기반 공개자의 WSDL 파일이 SOAP 조치 패턴을 지정하지 않으면 WS-Addressing이 기본적으로 한 패턴을 생성합니다. 공개자가 해당 바인딩에 PausableSubscriptionManager 포트 유형을 사용하는 경우 WS-Addressing에서 생성되는 기본 조치 패턴은 WS-Notification 스펙에 정의된 조치와 일치하지 않습니다.
참고: 이 문제점은 공개자가 PausableSubscriptionManager 포트 유형을 사용하는 경우에만 발생합니다. 공개자가 SubscriptionManager 포트 유형을 사용하는 경우 WS-Addressing에서 생성되는 기본 조치 패턴은 WS-Notification 스펙의 기본 조치 패턴과 일치합니다.

이 문제점을 해결하려면 수요 기반 공개자의 WSDL 파일에서 PausableSubscriptionManager 인터페이스에서 각 조작에 사용할 SOAP 조치를 명시적으로 지정해야 합니다. 각 조작에 사용할 조치 URI는 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn에 있는 WS-BaseNotification(Web Services Base Notification) 1.3 스펙에서 정의됩니다. 예를 들어, 등록 해제에 대한 WS-Addressing 조치가 http://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/UnsubscribeRequest와 같은 스펙에서 정의되면 자신의 공개자 WSDL 파일에서 등록 해제 조작에 이 조치를 사용해야 합니다. 다음은 그러한 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" />

마찬가지로 공개자 WSDL 파일에서 Renew, PauseSubscription 및 ResumeSubscription 조작에 해당하는 조치를 지정해야 합니다.

브로커 서버 로그에 "연결 제한시간 초과" 오류가 있음

WS-Notification 브로커 서버 로그에 WebServicesFault( "Connection timed out" ) 오류가 있고 WS-Notification 서비스를 등록하는 다수의 이용자가 있는 경우 브로커가 등록 이용자에게 알림 메시지를 전송할 때 HTTP 아웃바운드 커넥터 연결 풀에서 최대 연결 수를 초과했을 수 있습니다.

풀에서 아웃바운드 HTTP 연결 수를 늘리려면 브로커가 실행되고 있는 한 서버 또는 여러 서버에서 com.ibm.websphere.webservices.http.maxConnection 사용자 정의 특성을 설정하십시오. 이 특성에 대한 자세한 정보는 웹 서비스 애플리케이션에 대한 HTTP 전송 사용자 정의 특성의 내용을 참조하십시오.

브로커 서버 로그에 "메모리 부족" 오류가 있음

WS-Notification 브로커 서버 로그에 "메모리 부족" 오류가 있고 WS-Notification 서비스를 등록하는 다수의 이용자가 있는 경우 브로커가 실행 중인 서버에 할당된 사용 가능한 JVM 힙 크기를 브로커가 초과했을 수 있습니다.

브로커가 실행되고 있는 한 서버 또는 여러 서버에서 최대 힙 크기를 늘리려면 Java용 IBM 가상 머신 튜닝의 내용을 참조하십시오.

WebSphere Application Server 버전 6.1 클라이언트 애플리케이션이 추가 오류 조건을 처리해야 함

WebSphere Application Server 버전 6.1에서 WS-Notification에 대한 지원은 WS-Notification 표준의 최종 직전의 승인 공개 검토 초안을 기반으로 합니다. 이후 버전에서 이 지원은 최종 승인 표준을 포함하도록 확장됩니다. WS-Notification 공용 검토 초안과 최종 표준과의 차이점은 다음과 같습니다.
  • • UnableToGetMessagesFault라고 하는 새 장애 조건이 추가되었습니다. 이 장애 조건은 일부 내부 조건이 메시지를 리턴하는 것이 불가능함을 의미하는 경우 GetMessages 조작 요청에 대한 응답으로 리턴됩니다. 이 장애 조건은 리턴할 메시지가 없는 것과는 다르며 그와 다르게 처리되고 좀 더 자주 발생함에 유의하십시오.
  • • GetMessages 조작의 스키마에서 메시지 수 리턴을 위해 값을 더 이상 전달하지 않아도 됩니다. 값이 전달되지 않으면 모든 사용 가능한 메시지가 리턴됩니다. 이는 이미 값을 제공하도록 코드화된 버전 6.1 클라이언트 애플리케이션에는 영향을 미치지 않습니다.
  • • DestroyPullPoint 조작이 이제는 이전에 선언된 장애 조건에 추가하여 ResourceUnknownFault 장애 조건을 예외 처리합니다.

WebSphere Application Server 버전 7.0 이상와 함께 제공되는 WSDL 및 스키마는 최종 버전 1.3 WS-Notification 표준을 반영하기 위해 업데이트됩니다.

기존 WS-Notification 서비스를 변경하지 않아도 됩니다. 기존 클라이언트 애플리케이션도 변경되지 않은 상태로 계속해서 작업하지만 이제 새 WS-Notification 서비스에 대해 작업하고 새 장애 조건을 명시적으로 처리하도록 하려면 새 서비스에서 WSDL 파일을 사용하여 클라이언트를 재생성하십시오.

SDO 저장소가 올바르게 구성되지 않아서 예외가 발생함

버전 6.1 WS-Notification 서비스를 작성하려고 시도하는 중에 다음 스택 추적이 발생하는 경우 SDO 저장소가 올바르게 구성되지 않은 것입니다. 이 문제점을 해결하려면 SDO 저장소 설치 및 구성의 내용을 참조하십시오.

java.lang.Exception: com.ibm.ws.sib.webservices.admin.config.SIBConfigException: CWSWS5010E: 
Failed to store WSDL located at http://www.ibm.com/websphere/wsn/notification-broker 
due to the following exception: com.ibm.ws.sib.webservices.exception.SIBWSUnloggedException: 
CWSWS1007E: The following exception occurred: 
com.ibm.ws.sdo.config.repository.impl.RepositoryRuntimeException: 
javax.transaction.TransactionRolledbackException: CORBA TRANSACTION_ROLLEDBACK 0x0 No; 
nested exception is: org.omg.CORBA.TRANSACTION_ROLLEDBACK: 
javax.transaction.TransactionRolledbackException: ; nested exception is: 
javax.ejb.TransactionRolledbackLocalException: ; nested exception is: 
com.ibm.ws.ejbpersistence.utilpm.PersistenceManagerException: 
PMGR1014E: Exception occurred when getting connection factory: 
com.ibm.websphere.naming.CannotInstantiateObjectException: 
threw NameNotFoundException while the JNDI NamingManager was processing a 
javax.naming.Reference object. [Root exception is javax.naming.NameNotFoundException: 
Context: smeagolNode03Cell/nodes/smeagolNode03/servers/server1, name: 
jdbc/com.ibm.ws.sdo.config/SdoRepository: 
First component in name com.ibm.ws.sdo.config/SdoRepository not found. 
[Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: 
IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]] vmcid: 0x0 minor code: 0 completed: No.

각 이벤트 알림에 대해 알림 이용자가 다중 메시지를 수신함

일부 상황에서 지정된 알림 이용자에서 공개자에 의해 알림 브로커에 삽입된 이벤트 알림의 수보다 많은 알림을 수신할 수 있습니다. 예를 들어, 4개의 메시지를 공개하고 알림 이용자에서 8, 12, 16(또는 다른 4의 배수)개의 메시지를 수신할 수 있습니다.

이는 일반적으로 알림 이용자를 대상으로 하는 둘 이상의 활성 등록이 있기 때문에 발생합니다. 이 상황은 등록자 애플리케이션이 두 번 이상 실행되는 경우에 발생할 수 있습니다. 등록 조작이 호출될 때마다 알림 브로커는 새 등록을 작성해야 하며(웹 서비스 기반 알림 스펙의 섹션 4.2 참조) 이로 인해 이전 등록이 존재하는 경우 중복 메시지가 전달될 수 있습니다.

이러한 경우가 실제로 발생하는지 여부를 확인하려면 알림 이용자가 수신한 알림의 SubscriptionReference 특성을 검사하십시오. 이 엔드포인트 참조는 알림이 전송되도록 하는 등록의 ID를 포함합니다. 둘 이상의 다른 등록 ID가 있는 경우 둘 이상의 활성 등록이 있는 것입니다.

등록자 애플리케이션은 필요하지는 않을 때 등록을 정리해야 합니다(또는 해당 등록을 제한시간에 등록함). 그러나 활성 WS-Notification 등록 나열 또는 삭제에서 설명된 대로 런타임 패널을 사용하여 관리상 정리할 수 있습니다.

관리 대상 등록자 및 메시징 엔진 삭제 시 문제점이 발생할 수 있음

관리 등록자 삭제

일부 경우 더 이상 레코드가 없더라도 원격 웹 서비스 등록을 활성 상태로 유지한 채로 로컬 서버로 알림 메시지를 전달할 수 있기 때문에 WS-Notification 관리된 등록자가 구성된 버스 멤버에서 메시징 엔진을 삭제하고 재작성하는 것에 유의해야 합니다.

이러한 상황을 피하기 위해 메시징 엔진 삭제와는 별도의 단계에서 WS-Notification 구성을 삭제하거나 해당 관리 등록자만 삭제해야 합니다. 동적 구성 업데이트가 처리되거나 서버가 다시 시작되면 원격 웹 서비스 등록이 깨끗하게 정리됩니다.

참고: 이 문제점은 수정되는 WS-Notification 구성만인 경우에는 발생하지 않으며 메시징 엔진도 삭제되는 경우에만 발생합니다.
클러스터에 있는 관리 등록자

클러스터에서 메시징 엔진을 제거하는 경우, 예를 들어 001과 002 번호가 붙은 메시징 엔진은 있고 000은 없는 상황을 피하도록 최상위에서 최하위 번호순으로 제거하십시오. 이는 클러스터에서 첫 번째로 작성된 메시징 엔진에 특별한 의미를 첨부하는 WS-Notification을 사용하는 경우 문제점을 방지하기 위한 것입니다.

클러스터링된 토폴로지에는 "버스 멤버"(클러스터)에서 실행되고 있는 둘 이상의 메시징 엔진이 있을 수 있습니다. 관리 등록자는 서비스 위치(버스 멤버)에 대해 정의되기 때문에 원격 웹 서비스에 대한 등록 작성을 담당하는 메시징 엔진 선택에는 여러 대안이 있습니다. 이 상황에서 클러스터에서 "첫 번째" 메시징 엔진은 등록 작성을 담당합니다. 예를 들어, 세 메시징 엔진을 포함하는 클러스터에서 메시징 엔진은 xxx-000-yyy, xxx-001-yyy, xxx-002-yyy 패턴의 이름을 가지게 되고 관리 등록자 등록은 "000" 메시징 엔진에서 관리됩니다.

클러스터에서 "000" 메시징 엔진을 삭제한 다음 서버를 다시 시작하면 관리 대상 등록이 이제 클러스터에서 가장 낮은 번호 엔진인 "001" 메시징 엔진에 의해 관리됩니다. 그러나 이전에 설명한 대로 관리 등록자가 구성된 버스 멤버에서 메시징 엔진을 삭제하고 다시 작성하면 더 이상 레코드가 없는 경우라도 원격 웹 서비스 등록을 활성 상태로 둘 수 있습니다(그리고 알림 메시지를 로컬 서버에 전달함). 따라서 다른 메시징 엔진이 나중에 클러스터에 추가되고 현재 xxx-000-yyy로 정의된 메시징 엔진이 없는 경우 새 엔진이 xxx-000-yyy 이름을 가져옵니다. 따라서 이 인스턴스에서 두 개의 메시징 엔진이 동시에 관리 등록을 관리하고 있다고 인식하고 그로 인해 원격 웹 서비스에 대해 다중 등록이 작성될 수 있습니다.

거의 발생하지 않는 경우지만 메시징 엔진 xxx-000-yyy를 다시 작성해야 하는 상황에서 다음 단계를 완료하여 관리 등록에서 중복 메시지가 발생하는 것을 피할 수 있습니다.
  • 이 클러스터에 대해 정의된 관리 등록을 삭제합니다.
  • 기존 메시징 엔진이 변경사항을 관찰할 수 있도록 허용합니다. 이렇게 하면 클러스터의 메시징 엔진이 관리하고 있다고 믿고 있는 관리 등록을 삭제합니다.
  • 클러스터에서 새 메시징 엔진을 작성합니다.
  • 관리 등록을 다시 작성합니다.

버전 6.1 WS-Notification 서비스와 버스 대상을 사용하는 경우의 차이점이 있음

일반적으로 버스 대상은 버스 대상에서 설명하는 대로 사용됩니다. 그렇지만 이는 버전 6.1 WS-Notification 서비스의 경우에는 해당하지 않습니다. 버전 6.1 WS-Notification 서비스와 연관된 대상은 WS-Notification 서비스가 요청을 처리하는 토픽에는 연관되지 않으며 대상을 수정하거나 중개하면 안됩니다. WS-Notification에서 토픽 구성은 토픽 네임스페이스를 통해 처리됩니다. 자세한 정보는 새 WS-Notification 영구 토픽 네임스페이스 작성의 내용을 참조하십시오.

버전 6.1 WS-Notification 서비스를 작성하는 경우 마법사는 세 개의 서비스 통합 버스 인바운드 서비스를 WS-Notification 서비스에 대해 구성하며 이들 각각은 세 WS-Notification 서비스 역할 각각에 대응합니다.
  • 알림 브로커
  • 등록 관리자
  • 공개자 등록 관리자
이 인바운드 서비스는 버전 6.1 WS-Notification 서비스와 동일한 서비스 통합 버스에 정의되며 이 인바운드 서비스 각각은 동일한 버스 대상을 참조합니다.

인바운드(중개할 애플리케이션) 알림에 실패함

이벤트 알림을 브로커에 공개하려는 애플리케이션은 알림 조작을 이용합니다. 이는 단방향(웹 서비스) 조작으로 정의되며 조작을 완료할 수 없는 경우에 결함(예외)를 리턴하는 것이 불가능함을 의미합니다. 따라서 애플리케이션은 알림에 성공한 것으로 가정하지만 애플리케이션 등록은 알림 메시지를 수신하지 못합니다.

이 알림은 애플리케이션 오류(올바르지 않은 주제 구문) 또는 애플리케이션 코드와 서버 구성(정의되지 않은 주제 네임스페이스 사용) 간 불일치로 인해 실패할 수 있습니다. 인바운드 알림에 성공하지 못하는 특정 이유는 다음과 같습니다.
  • 주제가 올바르지 않음: 제공된 주제 표현식이 명시된 통용어 또는 지정된 비지원 통용어의 구문과 일치하지 않습니다. 이는 애플리케이션 오류입니다.
  • 주제 네임스페이스가 올바르지 않음: 애플리케이션이 아직 구성되지 않은 주제 네임스페이스를 지정했으나 관리자가 (WS-Notification 서비스에서) 동적 네임스페이스의 사용이 허용되지 않음을 지정했습니다.
  • 주제가 지원되지 않음: 지정된 주제가 주제 네임스페이스에 적용된 주제 네임스페이스 문서에서 금지됩니다(예를 들면, "최종"으로 표시된 주제의 하위 주제임).
  • 신임 정보가 올바르지 않음: 지정된 사용자 ID 또는 비밀번호가 올바르지 않거나 필요한 권한을 가지고 있지 않습니다. 이는 애플리케이션 구성과 서버 보안 정책 간 불일치로 인해 발생합니다.
  • 공개자가 등록되지 않음: 애플리케이션이 브로커에 먼저 등록하지 않은 상태로 알림을 전송하려고 시도하지만 관리자가 애플리케이션의 등록을 요구하도록 WS-Notification 서비스를 구성했습니다. 이는 애플리케이션 오류로 인해 발생합니다. 정상적으로 작동하는 애플리케이션은 브로커에 공개하기 전에 등록이 필요한지 여부를 먼저 확인해야 합니다.
  • 연관된 서비스 통합 버스 주제 영역이 사용 안함으로 설정되었습니다.

이러한 유형의 예외는 자세하게 모니터해야 합니다. 이러한 예외는 서비스 거부(DoS) 공격을 나타내는 것일 수 있고 애플리케이션이 올바르게 작동하고 있지 않음을 분명하게 나타내기 때문입니다. 특정 생성 애플리케이션에서 처음으로 인바운드 알림이 실패하면 경고 메시지가 서버의 SystemOut 로그에 전송됩니다. 해당 생성자에 대한 추가 알림 실패가 있을 경우 후속 제한시간 경과된 경고 메시지가 30분 간격으로 로그됩니다. 각 시간 설정된 메시지에는 30분 간격 동안 해당 생성자에 대해 수신한 실패 알림 수를 표시하는 추가 정보가 제공됩니다.

시스템은 각 경고 메시지를 생성할 때 다음 두 ID 중 하나를 통해 생성하는 애플리케이션을 식별합니다.
  • 알림 조작에서 제공되는 NotifyMessage의 ProducerReference 요소. 이 요소는 애플리케이션을 고유하게 식별합니다. 그러나 이 요소는 선택사항입니다.
  • 요청이 시작된 호스트의 IP 주소입니다. 이 주소는 애플리케이션을 고유하게 식별하지 못할 수 있지만 검색 범위를 좁힐 수 있습니다.
참고: 시스템이 모든 경우에 호스트 IP 주소를 식별할 수 없습니다. 예를 들어, JMS를 통한 SOAP 전송의 경우 발신 호스트의 IP 주소는 사용 가능하지 않거나 해당되지 않습니다.

아웃바운드(애플리케이션에 대한 중개) 알림에 실패함

원격 애플리케이션을 호출에 사용할 수 없는 경우 아웃바운드 웹 서비스 호출(애플리케이션에 대한 중개)에 실패합니다. 이는 애플리케이션 실패, 방화벽 오류 또는 방화벽 구성 문제로 인한 결과일 수 있습니다. 이벤트 알림이 등록 대상 애플리케이션에 전달되지 않으면 서버에서 정지된 등록에 메시지가 쌓입니다. 지정된 등록에 보관되는 메시지는 활성 WS-Notification 등록 나열 또는 삭제에서 설명된 대로 런타임 패널을 사용하여 관찰할 수 있습니다. 이런 식으로 가장 최근 이벤트 알림 시도가 실패한 등록은 WS-Notification 등록 런타임 관리 패널에서 볼 때 ERROR 상태로 표시됩니다.

WS-Notification 서비스 위치가 NotificationConsumer 애플리케이션에 알리는 것에 성공하지 못하는 경우 이 애플리케이션 서버의 SystemOut 로그에 경고 메시지가 전송되고 2분 동안 대기하도록 지시합니다. 이러한 유형의 실패 이유는 원격 웹 서비스가 현재 사용 가능하지 않거나 네트워크 조건으로 인해 로컬 서버와 서비스 간 접속이 불가능하기 때문일 수 있습니다.

2분 후 알림이 재시도됩니다. 여전히 전달이 불가능한 경우 등록이 다시 2분 동안 대기 상태로 돌아갑니다. 실패가 임시 I/O 오류로 인한 실패인 경우 이 패턴은 알림이 성공적으로 전달되거나 이 등록을 삭제할 때까지 무한정 반복됩니다. 오류가 원격 측 애플리케이션 실패로 인한 것이면 메시지를 전송하고 있는 서비스 통합 버스 주제 영역 대상의 "최대 실패 전달 수" 설정에서 정의된 수만큼 알림이 재시도됩니다. 첫 번째 경고 메시지가 SystemOut 로그에 출력된 후에는 후속으로 시간 설정된 경고 메시지가 30분 간격으로 로그됩니다.

자동으로 삭제되지 않는 Stateful 자원 정리

브로커에 대한 등록 또는 공개자 등록 활동은 활성인 동안 시스템 자원을 이용하는 서버에서 Stateful 자원을 작성합니다. 보통 애플리케이션은 이러한 자원 작성 활동의 일부로 종료 시간을 지정하고 그에 따라 종료 시간에 도달하면 해당 자원이 자동으로 삭제됩니다. 그러나 애플리케이션이 자원에 대해 무한 지속 시간을 요청할 수도 있습니다. 이러한 요청이 실행되면 애플리케이션이 자원을 다시 사용(또는 영구 삭제)하기 위해 절대 돌아오지 않더라도 자원이 서버에 무한정 남아있을 수 있습니다.

런타임에 WS-Notification과 상호작용에서 설명된 대로 런타임 패널을 사용하여 Stateful 자원(등록 및 공개자 등록)을 볼 수 있습니다. 이러한 패널은 필요한 경우 항목을 관리상 삭제할 수 있는 기능도 제공합니다. 이러한 삭제는 자원이 삭제된 후에 참조되는 경우 애플리케이션 실패의 원인이 되기 때문에 애플리케이션이 자원을 더 이상 사용하지 않을 것임을 확신하는 경우에만 수행하십시오.

서비스 통합 버스 패널을 사용하는 경우 WS-Notification에서 작성된 지속 가능한 등록을 삭제할 수 없음

WS-Notification 애플리케이션 즉, 등록 조작을 사용하여 등록을 작성하는 경우 관련 서비스 통합 버스 주제 영역 대상에서 하나 이상의 지속 가능한 등록이 작성됩니다. 이러한 지속 가능한 등록은 공개 위치에 대한 서비스 통합 버스 런타임 패널에서 볼 수 있습니다.

공개 위치에 대한 런타임 패널은 하나 이상의 지속 가능한 등록을 삭제할 수 있는 기능도 제공합니다. 그러나 이 기능을 사용하여 WS-Notification 애플리케이션이 작성한 등록을 삭제하면 삭제 조작이 실패합니다. 이는 WS-Notification 구현이 이 지속 가능한 등록에 대해 서버가 실행되는 기간 동안 활성 이용자를 유지하고 있고 활성 이용자가 있는 한 지속 가능한 등록을 삭제할 수 없기 때문입니다.
참고: 이 삭제 제한사항은 JMS 애플리케이션과 같은 다른 애플리케이션이 작성한 지속 가능한 등록에도 적용됩니다.

WS-Notification 애플리케이션에서 작성된 등록을 삭제하려면 런타임에 WS-Notification과 상호작용에서 설명된 대로 WS-Notification 구현에서 제공되는 런타임 패널을 사용하십시오. 이 접근법은 활성 이용자를 닫고 자동으로 관련 서비스 통합 버스 지속 가능한 등록을 삭제합니다.

메시징 엔진의 관리적 중지

WebSphere Application Server는 메시지를 전송 및 수신하고 작성되는 다양한 웹 서비스 자원의 상태를 작성하고 검색하기 위해 실행 중인 서비스 통합 버스 메시징 엔진에 액세스할 수 있어야 합니다.

MBean 인터페이스 또는 런타임 패널을 사용하여 메시징 엔진을 중지할 수 있습니다. 메시징 엔진을 중지하면 메시징 엔진이 중지된 시간 동안 수신될 수 있는 애플리케이션의 요청을 WS-Notification이 처리하는 것을 막을 수 있습니다. 이 상황에서 오류 메시지는 인바운드(중개할 애플리케이션) 알림에 실패함아웃바운드(애플리케이션에 대한 중개) 알림에 실패함에서 설명된 대로 로그됩니다. 메시징 엔진을 중지하면 모든 WS-Notification 처리가 중지되고 모든 메시징 애플리케이션이 작동을 중지합니다. 메시징 엔진을 다시 시작하면 WS-Notification 처리가 재개됩니다.

주제 영역 및 주제 네임스페이스 구성 변경으로 인한 실패

WS-Notification 구성 아티팩트는 서버 구성의 다른 영역에서 정의된 오브젝트에 따라 다른 경우가 많습니다. 예를 들면, (버전 6.1 WS-Notification 서비스의 경우) 애플리케이션 요청이 수신되는 엔드포인트 리스너 및 메시지 전송 위치 또는 대상인 서비스 통합 버스 주제 영역이 있습니다.

다음 항목은 종속되는 오브젝트에서 관련 변경사항이 발생하면 WS-Notification 런타임 코드가 수행하는 조치를 설명합니다.

서비스 통합 버스 주제 영역 삭제

서비스 통합 버스 토픽 영역은 WS-Notification이 런타임 시 의존하는 1차 메시징 오브젝트입니다. 애플리케이션의 알림 메시지는 관리자가 지정한 (영구) 주제 네임스페이스 맵핑에 의해 지정되는 주제 영역에 공개됩니다.

서비스 통합 버스 주제 영역을 삭제하면 새로운 및 기존 WS-Notification 애플리케이션에 다음과 같은 영향을 미칩니다.
  • 삭제된 주제 영역을 참조하는 WS-Notification 주제 네임스페이스 사용 RegisterPublisher 요청이 TopicNotSupportedFault 오류 메시지를 수신합니다.
  • 삭제된 주제 영역과 연관된 주제에 대한 알림 요청은 이미 삭제된 주제 영역에 메시지를 공개하지 않습니다. 알림 조작을 통해 처리된 결함이 없기 때문에 애플리케이션에 결함이 통지되지 않습니다(인바운드(중개할 애플리케이션) 알림에 실패함 참조).
  • 삭제된 주제 영역을 참조하는 WS-Notification 주제 네임스페이스 사용 등록 요청이 SubscribeCreateFailedFault 오류 메시지를 수신합니다.
  • 삭제된 주제 영역에 대한 기존 등록이 있는 애플리케이션에는 추가 메시지가 전달되지 않습니다. 기존 등록이 삭제되고 등록에 대한 조작(예: getCreationTime)을 호출하려고 시도하면 ResourceUnknownFault 오류 메시지가 발생합니다.
  • 서비스 통합 버스 주제 영역을 삭제하고 다시 작성하는 것은 두 개의 개별 단계로 간주됩니다. 기존 등록은 첫 번째 단계에 대한 대응으로 삭제되므로 주제 영역이 다시 작성될 때에는 존재하지 않습니다.
영구 주제 네임스페이스 맵핑 삭제

(현재 활성인) 등록을 설정하는 데 사용된 주제 네임스페이스 맵핑 삭제는 이전에 설명한 대로 기본 서비스 통합 버스 주제 영역을 삭제하는 것과 같은 효과가 있으며 이 네임스페이스 맵핑을 사용하여 작성된 등록은 삭제됩니다.

삭제된 주제 네임스페이스 맵핑과 연관된 공개자 등록 및 풀 위치도 삭제됩니다.

영구 주제 네임스페이스 맵핑 변경

영구 주제 네임스페이스 맵핑의 필드는 읽기 전용 필드이기 때문에 이러한 필드를 "변경"하는 유일한 방법은 네임스페이스 맵핑을 삭제하고 새 값으로 다시 작성하는 것입니다. 영구 주제 네임스페이스 맵핑 삭제의 영향은 이전 항목에 설명되어 있습니다.

구성된 SDO 저장소가 없는 버전 6.1 WS-Notification 서비스를 작성할 수 없음

버전 6.1 WS-Notification 서비스를 작성할 때 WSDL 문서는 SDO 저장소에 저장됩니다. SDO 저장소를 성공적으로 구성하기 전에 관리 콘솔을 사용하거나 스크립트를 통해 버전 6.1 WS-Notification 서비스를 작성하려고 시도하면 다음 예외 메시지가 표시됩니다.
java.lang.Exception: com.ibm.ws.sib.webservices.admin.config.SIBConfigException: CWSWS5010E: Failed to 
store WSDL located at http://www.ibm.com/websphere/wsn/notification-broker due to the following 
exception:
    com.ibm.ws.sib.webservices.exception.SIBWSUnloggedException: CWSWS1007E: The following exception 
        occurred: com.ibm.ws.sdo.config.repository.impl.RepositoryRuntimeException: 
        javax.transaction.TransactionRolledbackException: CORBA TRANSACTION_ROLLEDBACK 0x0 No; nested 
        exception is: org.omg.CORBA.TRANSACTION_ROLLEDBACK: 
        javax.transaction.TransactionRolledbackException: ;
    nested exception is: javax.ejb.TransactionRolledbackLocalException: ;
    nested exception is: com.ibm.ws.ejbpersistence.utilpm.PersistenceManagerException: PMGR1014E: 
        Exception occurred when getting connection factory: 
        com.ibm.websphere.naming.CannotInstantiateObjectException: threw NameNotFoundException while 
        the JNDI NamingManager was processing a javax.naming.Reference object.
    [Root exception is javax.naming.NameNotFoundException: Context: 
        KADGINNode01Cell/nodes/KADGINNode01/servers/server1, name: 
        jdbc/com.ibm.ws.sdo.config/SdoRepository: First component in name 
        com.ibm.ws.sdo.config/SdoRepository not found.
    [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: 
        IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]] vmcid: 0x0 minor code: 0 completed: No.
SDO 저장소 구성 방법에 대한 세부사항은 SDO 저장소 설치 및 구성의 내용을 참조하십시오.

인터넷 액세스 권한이 없는 JAX-WS 클라이언트가 WS-Notification 서비스에 접속하려고 시도하는 중에 예외가 발생함

클라이언트 애플리케이션은 일반적으로 다음 웹 링크를 통해 서비스의 WSDL 파트를 분석합니다. 클라이언트가 실행되는 머신에 인터넷 액세스 권한이 없을 경우 다음 예제와 유사한 예외가 발생합니다.
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

웹 링크를 따르지 않고 WS-Notification 서비스 WSDL을 해석하도록 JAX-WS 클라이언트 구성 주제의 지시사항에 따라 WSDL 파일의 로컬 사본을 대신 사용하도록 클라이언트를 구성하십시오.


주제 유형을 표시하는 아이콘 참조 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rjwsn_prob0
파일 이름:rjwsn_prob0.html