비동기 요청 디스패처 애플리케이션 디자인 고려사항

비동기 요청 디스패처(ARD)는 서블릿 프로그래밍을 위한 만능 솔루션이 아닙니다. 애플리케이션의 필요 및 ARD 사용 시의 경고를 평가해야 합니다. 모든 포함을 비동기식으로 시작하도록 전환하는 것은 모든 시나리오의 솔루션이 아니지만 현명하게 사용하면 ARD가 응답 시간을 늘릴 수 있습니다.

비동기 요청 디스패처 클라이언트측 구현

  • JavaScript는 응답 출력에 동적으로 기록됩니다.
  • 이 JavaScript가 서버측 결과 제공자로의 Ajax 재요청이 됩니다.
  • 채널의 비동기 입/출력(AIO) 기능으로 인해 Ajax 요청은 스레드를 묶지 않고 대신 포함 콜백을 통해 완료 통지를 받습니다.
  • 클라이언트는 브라우저의 연결 수 제한으로 인해 비동기 포함에 대해 한 번에 하나의 요청만 작성할 수 있습니다.
  • 원래 연결은 포함의 지속 시간 동안 유효해야 합니다. 이는 Ajax 요청에 재사용할 수 없습니다.
  • 다음
    <!--uniquePlaceholderID--><!--1-->
    같은 주석 노드가 페이지 레이아웃에는 영향을 미치지 않으므로 브라우저 오브젝트 모델에 배치됩니다.
  • 완료한 단편이 있을 때마다 클라이언트로 응답이 전송되고 동일 ID의 주석 노드가 교체됩니다. 요청은 모든 단편을 검색할 때까지 작성됩니다.
  • 클라이언트측 집계를 사용할 때에는 지원되는 모든 브라우저에서 애플리케이션을 확인하십시오. 애플리케이션이 getDynamicDataIBMARD 메소드 이름 사용을 피할 수 있도록 오브젝트 지향 JavaScript 프린시펄이 사용됩니다. 이전에 지정된 window.onload가 ARD 온로드 메소드 전에 시작됩니다.

비동기 요청 디스패처 채널 결과 서비스

비동기 JavaScript 코드의 포함 데이터에 대한 요청은 ARD 채널이 웹 컨테이너 요청 핸들링을 통한 이동을 막기 위해 가로챌 수 있는 URL로도 알려진 URI(Uniform Resource Identifier)로 전송됩니다. 이러한 URI는 각 서버 다시 시작마다 고유합니다.

예를 들어, /IBMARD01234567/asyncInclude.js는 결과의 검색을 강제 실행하는 JavaScript의 URI이고 /IBMARD01234567/IBMARDQueryStringEntries?=12000은 ID가 12000인 항목에 대한 결과를 검색하는 데 사용됩니다.

권한 없는 결과 액세스를 방지하기 위해서 서비스 URI 및 ARD 항목에 대해 고유 ID가 생성됩니다. 공통 ID 생성기는 세션과 ARD 간에 공유되므로 세션 구성을 통해 고유하게 구성 가능합니다. 세션 ID는 안전한 것으로 간주되지만 LTPA(Lightweight Third-Party Authentication) 토큰을 사용하는 것만큼 안전하지는 않습니다.

사용자 정의 클라이언트측 집계

사용자 고유의 클라이언트측 집계를 수행하고 싶은 경우에는 isUseDefaultJavascript 메소드가 false로 리턴되어야 합니다. isUseDefaultJavascript 메소드는 AsyncRequestDispatcher에 설정된 AsyncRequestDispatcherConfig 메소드 또는 AsyncRequestDispatcherConfigImpl.getRef 메소드의 일부입니다. AsyncRequestDispatcherConfigImpl.getRef 메소드는 글로벌 구성 오브젝트입니다. 이전 단추 기능에 문제가 있는 경우에는 사용자 고유의 클라이언트측 집계를 수행하고 싶을 수도 있습니다. XMLHttpRequest를 통해 동일한 응답 결과가 있는 여러 개의 요청이 실패할 수 있도록 메모리 누수를 막기 위해서는 일반 결과 서비스에서 결과를 제거해야 합니다. 위치의 적절한 배치를 위해서 플레이스홀더가 코드에
<!--uniquePlaceholderID--><!--x-->
로 쓰여집니다. 여기서 x는 포함의 순서입니다. 결과를 검색하기 위한 엔드포인트가 com.ibm.websphere.webcontainer.ard.endpointURI 요청 속성에서 검색됩니다.
엔드포인트에 요청하면 ARD는 요청 작성 시 가능한 많은 응답 단편을 전송합니다. 그러므로 클라이언트는 모든 단편이 처음에 리턴되지 않는 경우 다시 요청해야 합니다. XMLHttpRequest를 사용하지 않고 결과를 브라우저에 직접 표시하려고 시도하면 잘 구성되지 않은 XML과 관련된 오류가 발생할 수 있습니다. 응답 데이터는 text/xml 컨텐츠 유형으로 다음 형식으로 리턴됩니다.
<div id="2"><BR>Servlet 3--dispatcher3 requesting Servlet3 to sleep for 0 seconds at: 1187967704265 
<BR> Servlet 3--Okay, all done!  This should print pop up: third at: 1187967704281 </div>

AsyncRequestDispatcherConfig 및 AsyncRequestDispatcher에 대한 추가 정보는 API(Application Programming Interface) 문서에서 com.ibm.websphere.webcontainer.async 패키지를 검토하십시오. 생성된 API 문서는 참조 > API - API(Application Programming Interface) 경로의 문서 목차에서 사용 가능합니다.

서버측 집계

클라이언트측 집계와 마찬가지로 서버측 집계는 ARD 채널을 결과 서비스로 사용합니다. ARD 채널은 어떤 비동기 포함이 특정 버퍼 세트에서 발생했는지를 알고 있습니다. 이러한 버퍼에서 포함 플레이스홀더를 검색할 수 있습니다. JSP 버퍼링의 문제로 인해서 포함의 플레이스홀더가 검색된 버퍼에 없을 수도 있습니다. 이 경우 이전 세트에서 누락된 포함 플레이스홀더를 다음 버퍼 세트에서도 찾아야 합니다. ARD는 응답 컨텐츠를 가능한 빨리 클라이언트에 전송할 수 있도록 반복적으로 포함 리턴으로 집계하려고 시도합니다.

동시성

작업 관리자가 포함을 시작하는 데 사용됩니다. 현재 요청된 포함 개수가 작업 관리자 최대 스레드 풀 크기보다 크고 이 크기가 커지지 않으면 현재 스레드에서 작업을 시작하고 플레이스홀더 쓰기를 건너뜁니다. Concurrency Utilities for Java™ EE 사용은 작업 영역, 국제화, 애플리케이션 프로파일, z/OS® 조작 시스템 작업 로드 관리, 보안, 트랜잭션 및 연결 컨텍스트를 포함하여 원래 스레드의 Java EE 컨텍스트의 전파를 수행할 수 있도록 합니다.

타이머

ARD에 단일 타이머가 사용되고 타이머 태스크가 모든 ARD 요청의 제한시간 유형에 대해 작성됩니다. 타이머에 등록된 태스크는 지정된 정확한 시간에 실행되지 않을 수도 있습니다. 타이머가 단일 스레드에서 실행되므로 하나의 제한시간이 다른 제한시간 조치가 완료되기를 기다려야 할 수도 있기 때문입니다. 타이머는 마지막 수단으로 사용됩니다.

원격 요청 디스패처

선택적으로 ARD를 원격 요청 디스패처와 함께 사용할 수도 있습니다. 원격 요청 디스패처는 요청 컨텍스트를 SOAP 메시지로 직렬화하고 원격 서버를 호출하는 데 웹 서비스를 사용하여 코어 그룹의 다른 애플리케이션 서버에서 포함을 실행합니다. 이는 웹 서비스를 통해 SOAP 메시지를 작성 및 전송하는 비용이 요청을 로컬에서 발행하는 것보다 많을 때 유용합니다.

예외

포함된 서블릿에서 예외 발생 시 웹 컨테이너는 예외 유형에 맵핑된 오류 페이지 정의를 통과합니다. 따라서 배치 디스크립터에 정의된 오류 페이지가 집계된 페이지의 일부분으로 표시됩니다. 포함의 경우 동작이 다르면 논리를 오류 페이지 자체에 삽입하십시오. 포함은 비동기식으로 실행되기 때문에 최상위 레벨 서블릿이 계속해서 작동 중이지 않을 수도 있습니다. 그러므로 예외는 정상 포함과 같이 비동기 포함으로부터 다시 전파되지 않습니다. 기타 포함은 부분 페이지를 표시할 수 있도록 완료됩니다.

ARD 작업 관리자에 작업자 스레드가 부족하게 되면 포함은 동기 포함처럼 처리됩니다. 이것이 기본 설정이지만 작업 관리자 또한 이러한 상황이 발생하지 않도록 커집니다. 처리 시 이러한 변경은 처리 중인 사용자에게는 표시되지 않지만 시스템 로그에는 경고 메시지로 한 번 기록되고 사용 가능한 경우 추적 로그에 나머지가 기록됩니다. 포함이 동기식으로 발생하도록 트리거할 수 있는 기타 상태는 시간 간격을 넘어 만료된 요청의 최대 백분율에 도달하거나 결과 저장소의 최대 크기에 도달하는 것입니다.

정상 오류 페이지 처리 범위를 벗어나서 예외가 발생할 수도 있습니다. 예를 들어, 작업 관리자가 작업을 거부할 수 있습니다. 타이머는 포함 응답이 리턴되기를 기다리는 중 만기될 수 있습니다. 결과를 검색하기 위한 일반 서비스의 역할을 하는 ARD 채널이 유효하지 않은 ID를 받을 수도 있습니다. 이 경우 ServletRequest, ServletResponse 및 ServletContext 등과 같이 요청이 작동하기 위한 컨텍스트가 누락되었으므로 오류 페이지 처리에 대한 경로가 없습니다. 이 문제를 완화하기 위해 AsyncRequestDispatcherConfig 인터페이스를 사용하여 사용자 정의 오류 메시지를 제공할 수 있습니다. 기본값은 필요에 따라 제공되고 및 국제화됩니다.

후속 클라이언트측 XMLHttpRequests와 같이 사용자 정의 구성이 설정된 요청 범위 밖에서 예외가 발생할 수도 있습니다. 이 경우 글로벌 구성을 변경해야 합니다. 이는 com.ibm.wsspi.ard.AsyncRequestDispatcherConfigImpl.getRef()를 통해 검색할 수 있습니다.

포함 시작
작업 관리자는 포함이 시작될 때까지 기다려야 하는 시간에 대한 제한시간을 제공합니다. 이는 보통 즉시 발생하므로 이를 사용 가능하게 하는 프로그램적인 방법은 없습니다. 그러나 작업 관리자 설정에서 이를 구성할 수 있습니다. 기본적으로 작업 스케줄 전의 최대 스레드 검사 때문에 이러한 상황이 발생하지 않습니다. AsyncRequestDispatcherConfig 사용 시 setRetriable(true)이 호출된 경우 작업을 재시도할 수 있습니다.
포함 완료
시작된 제한시간이 작업이 승인된 후에 시작됩니다. 콘솔을 통해 구성하거나 AsyncRequestDispatcherConfig.setExecutionTimeoutOverride 메소드를 통해 프로그램적으로 구성할 수 있습니다. 기본값은 60000밀리초 또는 1분입니다. 포함 결과의 자리에 AsyncRequestDispatcherConfig.setExecutionTimeoutMessage의 메시지가 전송됩니다. 이 시작된 제한시간에 도달했지만 실제 포함 결과가 데이터를 비울 준비가 되어 있으면 실제 결과가 우선합니다. 또한 이는 포함이 완료될 때까지 항상 기다리는 insertFragmentBlocking 호출에는 적용되지 않습니다.
결과 만기
클라이언트측이 Ajax 요청을 보내기 위해 서비스에 결과를 보유하므로 클라이언트가 작동 중지되거나 항목을 검색하지 않는 경우 결과가 만료되는 방법이 필요합니다. Ajax 요청은 응답을 전송한 후에 즉시 들어오므로 일반적인 요청에는 기본값 1분이면 충분합니다. 타이머는 AsyncRequestDispatcherConfig의 setExpirationTimeoutOverride 메소드를 통해 프로그램적으로 구성할 수 있습니다. 누군가가 만료되었거나 캐시에서 제거된 항목에 액세스하려고 시도하면 AsyncRequestDispatcherConfig의 getOutputRetrievalFailureMessage 메소드의 메시지가 표시됩니다. 이 메시지는 존재하지 않은 ID로 결과를 요청하는 사람에게 전송되는 것과 동일한 메시지입니다.

포함 또는 단편

어떤 조작을 비동기식으로 수행할 수 있는지와 언제 시작할 수 있는지 고려하십시오. 포함이 완료할 수 있는 시간을 더 가질 수 있도록 요청 시작 시 getFragment 호출이 작성될 때 모든 포함이 완료되는 것이 좋으며 포함이 모두 완료된 경우에는 단편 삽입 시에 추가 버퍼와 집계가 줄어들게 됩니다. 그러나 일반 요청 디스패처 포함과 동일한 패턴을 따르므로 비동기 포함을 호출하는 것이 더 쉽습니다.

웹 컨테이너

ServletContext
크로스 컨텍스트 포함을 수행할 때에는 포함의 대상인 컨텍스트에서 ARD가 사용 가능해야 합니다. 웹 애플리케이션이 ARD에 대해 초기화되어 있어야 하고 해당 서블릿 컨텍스트에 AsyncRequestDispatcher를 검색하기 위한 유효한 메소드가 있어야 하기 때문입니다. 집계 유형은 혼합할 수 없으므로 원래 컨텍스트의 구성에 의해 결정됩니다.
ServletRequest
각 포함마다 요청을 복제해야 합니다. 그렇지 않으면 스레드 간 충돌이 발생할 수 있습니다. 애플리케이션이 기본 요청 오브젝트를 랩핑할 수 있기 때문에, 랩퍼는 CloneNotSupportedException을 작성하는 하나의 메소드인 public Object clone 메소드를 갖는 com.ibm.wsspi.webcontainer.servlet.IServletRequest 인터페이스를 구현해야 합니다.
랩핑 해제는 이 인터페이스를 구현하는 요청 랩퍼를 찾을 때까지 발생합니다. 비구현 랩퍼는 유실됩니다. 그러나 포함에 대해 구성된 서블릿 필터는 응답을 다시 랩핑할 수 있습니다.
ServletRequest 변경사항은 AsyncRequestDispatcherConfig에서 transferState가 사용 가능하고 insertFragmentBlocking이 호출되지 않는 한 최상위 레벨 서블릿으로 다시 전파되지 않습니다.
ServletResponse
com.ibm.websphere.servlet.response.StoredResponse를 확장하는 랩핑된 응답이 ARD에 의해 작성되고 포함으로 전송됩니다. 응답 출력은 원래 응답의 라이프사이클을 넘어서 검색 가능해야 하기 때문입니다.
비동기 포함에 설정된 내부 헤더는 AsyncRequestDispatcher config에서 transferState가 사용 가능하고 insertFragmentBlocking이 호출되지 않는 한 라이프사이클 제한으로 인해 지원되지 않습니다. 표준 헤더는 서블릿 스펙에 지정된 대로 동기 포함에서는 지원되지 않습니다.
포함 필터는 새로운 응답을 다시 랩핑할 수 있고 완료 시에 비워야 합니다.
ServletInputStream
getParameter를 사용하는 애플리케이션 읽기 매개변수는 문제가 되지 않습니다. 매개변수의 구문 분석은 입력 스트림에 대한 동시 액세스를 방지하기 위해 첫 번째 비동기 포함 전에 강제 실행됩니다.
HttpSession
Set-Cookie 헤더가 되는 초기 getSession 호출은 최상위 레벨 서블릿에서 호출해야 합니다. 포함이 언제 시작되는지와 헤더가 이미 비워졌는지 여부를 예측할 수 없기 때문입니다. AsyncRequestDispatcherConfig에서 transferState가 사용 가능하고 insertFragmentBlocking이 호출된 경우는 예외입니다. 이는 주로 헤더를 추가할 때 예외를 작성합니다.
필터
포함에 대한 필터가 있는 경우에는 필터가 비동기 스레드에서 발행됩니다.
중첩된 비동기 포함
중첩된 비동기 포함은 복합 집계이므로 지원되지 않습니다. 그러나 비동기 포함에는 중첩된 동기 포함이 포함됩니다. 중첩된 비동기 포함을 수행하려고 시도하면 동기 포함으로 되돌아갑니다.

트랜잭션

작업 관리자로 제출되는 모든 태스크는 일반적인 엔터프라이즈 Bean의 컨테이너 관리 트랜잭션과 같은 고유의 트랜잭션을 사용하여 호출됩니다. 런타임은 메소드를 시작하기 전에 로컬 트랜잭션을 시작합니다. 태스크는 호출 Java EE 컴포넌트에 대해 고유의 글로벌 트랜잭션이 가능한 경우 이 트랜잭션을 시작할 수 있습니다.

태스크가 예외를 작성하면 모든 로컬 트랜잭션은 롤백됩니다. 메소드가 정상적으로 리턴되면 모든 불완전 로컬 트랜잭션은 Bean에 대해 구성된 해결되지 않은 조치 정책에 따라 완료됩니다. 태스크가 자체 글로벌 트랜잭션을 시작하고 이 글로벌 트랜잭션을 커미트하지 않으면 트랜잭션은 메소드가 리턴될 때 롤백됩니다.

연결 관리

작업 관리자에 제출되는 태스크는 해당 작성 서블릿이 java:comp 자원 참조를 사용하여 얻은 데이터 소스 및 연결 팩토리를 사용할 수 있습니다. 그러나 Bean 메소드는 get, use 또는 close 패턴을 사용하여 해당 연결에 액세스합니다. 태스크의 메소드 호출 사이에는 연결 캐싱이 없습니다. 데이터 소스 또는 연결 팩토리는 캐시 가능하지만 연결은 사용되고 닫히는 모든 메소드 호출에서 검색해야 합니다. 태스크가 글로벌 JNDI(Java Naming and Directory Interface) 이름을 사용하여 연결 팩토리를 검색하는 동안 다음과 같은 이유로 이는 권장되지 않습니다.
  • JNDI 이름은 애플리케이션에서 하드코딩됩니다(예: 특성 또는 문자열 리터럴로).
  • 연결 팩토리는 공유 범위를 지정할 수 없기 때문에 공유되지 않습니다.
비동기 포함은 연결 대기 중인 스레드 수를 늘릴 수 있으므로 로드가 많은 시나리오를 평가하십시오.

성능

포함은 비동기식으로 완료되므로 비동기 포함의 성능을 계산할 때에는 요청의 총 성능 데이터를 고려해야 합니다. 요청의 총 시간이 이전에는 최상위 레벨 서블릿이 완료되는 시간으로 이해되었을 수도 있지만 이제는 해당 서블릿이 포함이 완료되기 전에 종료합니다. 최상위 레벨 서블릿은 여전히 각 포함에 필요한 추가적인 설정 시간의 대부분을 차지합니다.

그러므로 ARD 채널을 통한 완료 요청의 시간을 측정하기 위해서 PMI(Performance Monitoring Infrastructure)에 새로운 ARD 성능 메트릭이 추가되었습니다. 이러한 메트릭의 세분성은 요청 URI 레벨에 있습니다.

ARD는 사용 가능으로 설정해야 하는 선택적 기능이므로 ARD를 사용하지 않더라도 성능 저하는 없습니다. 그러나 ARD 사용 애플리케이션 서버에 상주하는 비ARD 애플리케이션은 ARDChannel의 추가 계층으로 인한 피해를 입습니다. 채널 계층은 어떤 애플리케이션으로 이동하는지를 알지 못하므로 채널 체인에서 모든 애플리케이션에 대해 켜져 있거나 꺼져 있습니다. 이들은 가상 호스트별로 정의됩니다.

보안

서블릿 스펙에 따라 동기 포함 디스패치 시 보안이 호출되지 않습니다. 그러나 보안 컨텍스트는 ServletRequest에서 isUserInRole 및 getUserPrincipal 메소드의 프로그램적인 사용을 지원하기 위해 Concurrency Utilities for Java EE를 통해 전달됩니다. 이 보안 컨텍스트는 또한 웹 서비스 보안을 사용하여 원격 요청 디스패치로 전파될 수도 있습니다.


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



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