Request-Response 메시징
요청/응답 메시징 패턴에서 한 파티가 요청 메시지를 보내고 수신 파티가 응답 메시지를 반환합니다. 요청/응답 처리에 대한 두 가지 일반적인 예에는 브라우저가 HTTP 어댑터를 사용하여 웹 서버와 상호 작용하는 작업과 SOAP(Simple Object Access Protocol) 어댑터를 사용하는 웹 서비스 처리 작업이 있습니다. BizTalk Server 요청과 응답 메시지는 모두 일반적인 게시/구독 방식으로 처리됩니다. 높은 처리량이 필요한 시스템은 개별 메시지에 필요한 짧은 대기 시간과 다르게 구성될 수 있으므로 BizTalk 응용 프로그램의 성능을 조정하는 경우 이를 중요하게 고려해야 합니다.
메시지가 요청/응답형 수신 어댑터에서 수신될 경우 BizTalk Server는 먼저 요청 메시지를 MessageBox 데이터베이스에 게시합니다. 그런 다음 수신 포트에 바인딩된 오케스트레이션일 수도 있는 적합한 등록자가 이 메시지를 수신합니다. 이 등록자는 응답 메시지를 작성한 다음, 요청을 받은 위치에서 수신 포트에 메시지가 다시 전송할 수 있도록 하는 속성과 함께 이 응답 메시지를 MessageBox에 게시합니다. 마지막으로 응답 메시지는 요청을 전송한 수신 어댑터인 요청 게시자에 의해 선택되고 호출 응용 프로그램에 반환됩니다. 아래 다이어그램에서는 이러한 단계를 자세히 그래픽으로 나타냅니다.
메시지
SOAP 어댑터가 수신한 요청/응답 메시지의 흐름
SOAP 어댑터가 엔드포인트 관리자에 메시지를 전송합니다.
엔드포인트 관리자가 MessageBox에 메시지를 게시합니다.
수신 포트에 바인딩되어 메시지에 대한 등록을 갖는 오케스트레이션이 메시지를 수신하여 처리합니다.
오케스트레이션이 MessageBox에 게시된 응답 메시지를 송신합니다.
엔드포인트 관리자가 응답 메시지를 수신합니다.
엔드포인트 관리자가 SOAP 어댑터에 응답을 반환합니다.
내부 구현을 이해하지 못한 경우에는 이러한 유형의 동작이 성능에 끼치는 영향을 인식하지 못할 수 있습니다. BizTalk Server는 처음에는 높은 처리량 시나리오를 위해 조정되지만 낮은 처리량을 사용하는 환경에 적합하도록 구성될 수 있으며 특히 요청/응답 시나리오에서 보다 낮은 대기 시간이 필요한 상황에 맞게 구성될 수도 있습니다. 이러한 시나리오 조정 시 다음과 같은 몇 가지 사항을 고려해야 합니다. 첫 번째로 등록자가 폴링 메커니즘을 사용하여 게시된 메시지를 식별합니다. 폴링 간격이 너무 높게 설정된 경우에는 요청/응답형 상호 작용으로 인해 원하는 시간보다 높은 대기 시간이 설정될 수 있습니다.
이 시나리오에서는 두 개의 구독을 채울 수 있습니다. 즉, 초기 메시지의 구독과 응답 메시지에 대한 구독이 있으며, 이렇게 하면 이 폴링 간격의 영향이 증가합니다. 두 번째로 수신 어댑터가 다양한 크기의 일괄 처리로 MessageBox에 메시지를 삽입하도록 구성됩니다. 대부분의 어댑터에서는 일반적인 어댑터 구성 인터페이스를 사용하거나 BizTalk Server 또는 레지스트리에서 매개 변수를 사용하여 일괄 처리 크기를 구성할 수 있습니다. 일괄 처리 크기가 큰 경우에는 개별 메시지에 대한 대기 시간이 늘어날 수 있습니다. BizTalk Server 성능 특성에 대한 자세한 내용은 지속적인 성능 계획을 참조하세요.