Windows Communication Foundation을 사용하여 신뢰할 수 있는 메시징 소개

아티클
05/11/2010

클레멘스 광대
Microsoft Corporation

2006년 7월

적용 대상:
Microsoft Windows Vista
WS-ReliableMessaging 사양

요약: 이 문서에서 Clemens Vasters는 신뢰할 수 있는 메시징 및 세션 지원이 WCF(Windows Communication Foundation)에서 작동하는 방식을 설명합니다. WS-ReliableMessaging 사양의 WCF 구현, 신뢰할 수 있는 배달 및 세션이 관련된 방법 및 이유, WCF 표준 바인딩이 신뢰할 수 있는 메시징을 지원하는지 여부 및 어느 정도까지 지원하는지에 대해 알아봅니다. (인쇄된 페이지 14개)

콘텐츠

(WS-) 신뢰할 수 있는 메시징 작동 방식
신뢰할 수 있는 메시징(및 세션)
표준 바인딩을 사용하는 신뢰할 수 있는 메시징
까다로운 신뢰할 수 있는 세션 지원
단방향, 큐 및 지속성 메시징

신뢰할 수 있는 메시징은 강력하고 동시적인 데이터 처리를 허용하여 확장성을 크게 향상시키는 강력한 소프트웨어 아키텍처를 구현하기 위한 핵심 요소입니다. 또한 신뢰할 수 있는 메시징은 연결될 수 있는 기회가 날마다 증가하지만 네트워크 연결 품질이 거의 허용되지 않는 곳부터 매우 가난한 곳까지 다양한 환경에서 애플리케이션을 작성하기 위한 토대입니다.

큰 단어. 기억나세요? 어째서?

독일 프랑크푸르트와 쾰른 사이의 새로운 InterCity Express 철도는 라인 강의 동쪽 둑과 함께 언덕 위로 파고 올라갔으며, 유럽에서 가장 중요한 수로와 함께 구불구불한 멋진 경치를 대체하기 위해 지어졌습니다. 새로운 트랙은 30 마일 더 짧고, 이동 시간을 1 시간 단축했으며, 18 개의 주요 육교와 30 개의 새로운 터널이 있으며 각각 휴대 전화 리피터 기술에 상당한 투자를 했습니다. 그러나 2003년부터 운영되어 온 이 새로운 트랙은 여전히 예외적입니다.

모바일 인력이 사용하는 스마트 클라이언트 애플리케이션은 사내 데스크톱 애플리케이션과는 통신 요구 사항이 매우 다릅니다. 사용자는 GSM/GPRS, 3G/UMTS 또는 WiFi 연결과 같은 모바일 데이터 서비스를 통해 릴레이되는 VPN 링크를 통해 회사 네트워크에 전화를 걸며 종종 "모바일"은 "이동"과 동의어입니다. 뛰어난 통신 인프라를 갖춘 독일에서도 기차나 자동차의 연결 품질은 환경에 따라 매우 자주 좌우됩니다. 독일의 철도 시스템과 독일의 거리에는 많은 터널이 있으며 그 중 몇 개 이상이 모바일 링크가 붕괴됩니다. 정보를 가져오고 백 엔드 시스템으로 데이터를 보내야 하는 모바일 연결 애플리케이션을 빌드하는 경우 이러한 실제 연결 제약 조건은 상당한 과제입니다. 애플리케이션이 일반 HTTP와 함께 "기본" 웹 서비스를 사용하고 통신 링크가 매우 현실적으로 삭제될 수 있는 경우 애플리케이션의 사용자가 지난 30분 동안 클라이언트 애플리케이션에 입력한 데이터가 실제로 백 엔드 시스템에서 이해하고 저장되었는지 여부를 쉽게 알 수 없습니다. 그리고 네트워크 오류 조건이 있는 경우 언제 어떻게 다시 시도합니까? 더 나쁜 점: 정보의 일괄 처리를 일관되고 특정 순서로 릴레이해야 하고 통신 링크가 간헐적으로 실패하는 경우 어떻게 해야 하나요?

모바일 애플리케이션의 "가끔 연결"은 웹 서비스에서 신뢰할 수 있는 메시징의 원동력 중 하나입니다. 또 다른 하나는 인터넷에서 발생하는 가끔 네트워크 혼잡입니다.

많은 사람들이 HTTP 기반 웹 서비스의 개방성, 플랫폼 독립성 및 보편성을 필요로 하지만, HTTP의 전송 안정성이 본질적으로 부족한 것은 설명된 것과 같은 시나리오에서 매우 문제가 됩니다. 표준화를 위해 OASIS에 제출되고 Windows Communication Foundation에서 구현되는 전송 독립적 WS-ReliableMessaging(또는 WS-RM) 프로토콜을 사용하면 신뢰할 수 없는 연결 및 프로토콜을 통해 신뢰할 수 있는 통신 경로를 만들 수 있습니다. 이렇게 하려면 엔드 투 엔드 통신 세션을 설정하고 통신 흐름에 메시지의 명시적 승인을 도입합니다.

(WS-) 신뢰할 수 있는 메시징 작동 방식

Windows Communication Foundation은 학습할 때처럼 애플리케이션 개발자로부터 WS-ReliableMessaging 사양의 모든 복잡한 세부 정보를 편리하게 숨기고 신뢰할 수 있는 메시징 구현을 서비스 및 서비스 클라이언트에 대한 올바른 바인딩 구성을 선택하는 단순한 문제로 만들지만, 백그라운드에서 그리고 유선에서 무슨 일이 일어나고 있는지 약간 파악하는 것이 확실히 유용합니다.

결국, 당신은 정말 당신이 완전히 이해하는 메커니즘을 신뢰할 수 있습니다, 오른쪽?

신뢰할 수 있는 메시징은 일반적으로 다음과 같이 작동합니다. 클라이언트는 통신 링크를 통해 일련의 메시지(시퀀스가 하나의 메시지만큼 짧을 수 있음)를 보내고 수신자가 메시지를 수신했음을 인정하도록 요청합니다.

승인은 개별적으로, 각 메시지에 대해 또는 일련의 메시지에 대해 단일 승인으로 클라이언트로 다시 전송됩니다. 클라이언트가 승인을 받으면 메시지가 성공적으로 전송되었음을 알 수 있습니다.

TCP(TCP/IP에서와 같이 전송 제어 프로토콜)는 승인 메시지와 함께 작동하여 시퀀스의 모든 데이터 패킷이 두 엔드포인트 간에 안정적으로 전송되도록 합니다. WS-ReliableMessaging 통신 스택에서 약간 더 높고 기본 전송과 독립적으로 동일한 방식으로 매우 많이 작동합니다. 보다 구체적으로 설명: WS-RM은 이러한 엔드포인트가 연결된 방식에 관계없이 두 엔드포인트 간에 단일 SOAP 메시지 또는 SOAP 메시지 시퀀스의 안정적인 배달을 제어하도록 설계되었습니다. 는 메시지가 각 홉에 대해 서로 다른 전송 프로토콜을 사용하여 메시지 라우터 또는 다른 중간자를 통해 이동하는 경우에도 instance.

두 엔드포인트 간에 신뢰할 수 있는 메시징 링크를 설정하려면 먼저 연결 또는 "세션"이라는 개념이 필요합니다. 해당 세션의 컨텍스트에서 전송된 각 메시지에는 순서를 나타내는 고유 번호가 시퀀스로 할당됩니다. 보낸 사람 쪽(또는 "초기자")은 전송된 메시지를 추적하는 임시 캐시를 설정하고 들어오는 승인과 일치합니다. 특정 시간("재시도 시간 제한") 후에 메시지가 승인되지 않으면 메시지가 캐시에서 자동으로 다시 전송됩니다. 승인이 수신되면 캐시에서 메시지를 제거할 수 있습니다.

수신자 쪽(또는 "수락자")은 수락된 메시지를 보관하기 위한 캐시를 설정하여 애플리케이션에 전달하기 전에 저장합니다. 이는 수신 인프라와 애플리케이션에 "끌어오기 관계"가 있을 수 있기 때문에 수행됩니다.

WS-RM 채널이 전송 채널 위에 쌓여 있는 WCF의 채널 아키텍처와 보안 채널과 같은 일부 추가 채널이 도착하면 도착하는 메시지가 전송 채널에 대기합니다.

따라서 이는 실제로 모든 작동 방식에 대한 간단한 설명입니다. 작업자 스레드가 메시지를 처리할 수 있게 될 때마다 서비스 모델은 채널 스택(각 채널이 기본 채널에서 끌어오기)을 통해 해당 전송 큐에서 메시지를 가져와서 작성하는 서비스로 메시지를 디스패치합니다. 모든 메시지가 즉시 동기적으로 작성하는 서비스로 푸시되는 것처럼 보일 수 있지만 실제로는 항상 그러한 풀 푸시 번역이 수행됩니다.

서비스의 사용량에 따라 메시지 도착과 메시지 디스패치 사이에 지연이 있을 수 있으며 RM 채널이 도착 메시지를 빠르게 승인하는 것에 대해 우려하기 때문에 RM 채널은 전송 모델에서 서비스 모델로 버블업될 때 메시지가 흐를 때까지 기다리지 않습니다. 대신, 도착 시 기본 전송 큐에서 사전에 끌어오고, 필요한 승인을 보내고(가능하면 나중에 해당 큐에 도착) 서비스 모델 계층에서 픽업할 수 있는 메시지를 자체 큐에 유지합니다.

또한 이 캐시(또는 큐)는 메시지를 보낸 순서대로 애플리케이션에 배달할 수 있도록 수신된 메시지를 일시적으로 보관하는 역할을 합니다. 시퀀스의 메시지 3과 4가 메시지 2 앞에 도착하는 경우 이러한 "이후" 메시지는 메시지 2가 도착할 때까지 캐시에 보관되므로 시퀀스가 적절한 순서에 도달한 후에만 애플리케이션에 전달됩니다. 이는 애플리케이션에 주문된 배달이 필요하고 메시지 주문 적용이 켜져 있는 경우에 발생합니다(기본 동작임).

주문 배달을 지원하는 것 외에도 메시지 번호를 사용하면 받는 사람 쪽에서 중복 메시지를 검색하고 삭제할 수 있습니다. 보낸 사람에서 받는 사람까지의 경로에서 메시지를 복제하거나 승인이 손실되거나 지연된 경우 보낸 사람 쪽에서 두 번 보낼 수 있습니다.

통신 경로의 각 끝은 두 역할을 모두 수행할 수 있고 자주 수행되기 때문에 "초기자" 및 "수락자"라는 용어는 "클라이언트" 및 "서버" 대신 사용된다는 점에 유의해야 합니다. 양방향 통신에 대해 생각하기 시작하면 "클라이언트" 및 "서버" 용어가 쉽게 혼동됩니다.

요청/응답 통신 패턴이 있다고 가정하는 경우 응답은 요청과 마찬가지로 안정적으로 전달되어야 하므로 응답 당사자는 요청 당사자가 원래 요청에 대해 구현하는 것과 매우 유사한 초기자 메커니즘을 구현해야 합니다. 요청 당사자가 응답에 대한 수락자 역할을 합니다. 응답이 손실되면 응답 당사자가 분개해야 하므로 캐시(및 승인)해야 합니다. 따라서 신뢰할 수 있는 메시징 세션의 양쪽 끝은 아웃바운드 및 인바운드 메시지에 대해 별도의 캐시를 유지 관리합니다.

통신 당사자에게 양방향(이중) 통신 링크가 있을 때마다 응답 당사자는 요청 당사자가 요청을 배달할 수 없는 경우 전송을 다시 시도하는 것처럼 단순히 메시지 전송을 다시 시도할 수 있습니다.

그러나 통신 링크를 통해 응답 당사자가 클라이언트 요청과 관계없이 메시지를 배달할 수 없으면 상황이 좀 더 복잡해집니다. 특히 응답 당사자가 다른 요청과 함께 돌아올 때 요청 당사자에게 아무것도 다시 가져올 수있는 기회가있는 HTTP의 경우입니다.

HTTP를 사용할 때 요청 당사자가 돌아와서 승인되지 않은 응답을 선택하도록 하기 위해 응답 당사자는 간단한 트릭을 사용합니다. 요청 메시지에 대한 승인은 항상 응답에서 피기백됩니다. 이 경우 응답이 손실되는 경우 원래 요청이 실제로 응답 당사자에 도착했고 요청이 이미 처리되었더라도 요청 당사자는 승인을 받지 못하고 요청을 다시 보냅니다. 응답 당사자는 메시지의 시퀀스 번호를 검사하여 이러한 재전송 요청을 검색하고 메시지를 다시 처리하는 대신 메시지 캐시의 원래 요청에서 생성된 캐시된 응답을 처리합니다.

수신된 응답에 대한 승인은 응답 당사자가 응답 캐시를 클린 수 있도록 동일한 신뢰할 수 있는 세션에서 수행한 후속 요청에 대해 피기백됩니다. 응답 승인을 전달하는 요청은 완전히 관련이 없습니다 - 그 메시지는 단순히 따라 강을 건너 다음 편리한 페리 보트 역할을합니다.

WS-ReliableMessaging 세션에 대한 scope "시퀀스"라고 하며 통신 엔드포인트 간에 대역 외로 전송되는 "CreateSequence" 웹 서비스 요청에 의해 설정됩니다. 대역 외는 이 특정 요청이 인프라에 의해 전송되고 처리되며 서비스 모델 수준에서 웹 서비스 호출로 표시되지 않음을 의미합니다. 시퀀스를 시작하는 파티가 작업을 수행하고 모든 미해결 승인을 수집하면 채널이 닫힘에 따라 "TerminateSequence" 요청(대역 외 및 "백그라운드")을 보냅니다.

채널 아키텍처에서 실제로 아래를 찌르는 경우 "CreateSequence" 요청을 받으면 새 채널을 사용할 수 있게 되어 해당 시퀀스에 대한 모든 메시지가 전달되는 것을 볼 수 있습니다. "TerminateSequence" 메시지는 수신자에게 null 메시지를 전달하여 해당 채널이 시퀀스의 끝을 나타내도록 합니다.

신뢰할 수 있는 메시징(및 세션)

여기에 대한 논의를 감안할 때 Windows Communication Foundation이 세션 지원 및 신뢰할 수 있는 메시징 지원이 함께 제공되는 "신뢰할 수 있는 세션"(구체적으로: ReliableSessionBindingElement 클래스 및 reliableSession 구성 섹션)이라는 바인딩 요소를 통해 WS-ReliableMessaging 지원을 제공한다는 것은 놀라운 일이 아닙니다.

또한 신뢰할 수 있는 메시징은 승인을 릴레이하기 위해 양방향 정보 흐름이 필요하기 때문에 UDP(WCF에서 직접 지원되지는 않지만 전송 채널 샘플이 WinFX SDK에 있는 경우) 또는 MSMQ(Microsoft Message Queue)와 같은 단방향 데이터그램 전송과 호환되지 않습니다. 여기서 후자는 이 문서의 끝부분에서 자세히 설명하는 약간 다른 신뢰할 수 있는 전송 옵션입니다.

<customBinding>
   <binding configurationName="customReliableHttpBinding">
      <textMessageEncoding messageVersion="Default" encoding="utf-8" />
      <httpTransport />
   </binding>
<customBinding>

위의 바인딩 구성 코드 조각은 HTTP 전송을 지원하고 메시지를 기본(SOAP 1.2 및 2004년 10월 현재 WS-Addressing) 메시지 형식 버전으로 UTF-8 텍스트로 인코딩하는 매우 간단한 사용자 지정 바인딩입니다.

이 바인딩에 신뢰할 수 있는 메시징 지원을 추가하는 것은 다른 바인딩 요소(밑줄이 그어짐)를 추가하는 것만큼 간단합니다.

<customBinding>
   <binding configurationName="customReliableHttpBinding">
      <reliableSession ordered="true" />
      <textMessageEncoding messageVersion="Default" encoding="utf-8" />
      <httpTransport />
   </binding>
</customBinding>

구성 및 코드에서 추가 옵션을 구성할 수 있는 방법(아래 참조)을 표시하기 위해 여기에 추가하는 바인딩 요소에는 기본적으로 켜져 있는 순서가 지정된 메시지 배달도 명시적으로 필요합니다. 코드의 동등한 바인딩 컴퍼지션은 다음과 같습니다.

// create and configure transport
HttpTransportBindingElement httpTransport = 
      new HttpTransportBindingElement();

// create and configure encoder
TextMessageEncodingBindingElement textMessageEncoding = 
      new TextMessageEncodingBindingElement();
textMessageEncoding.Encoding = System.Text.Encoding.UTF8;
textMessageEncoding.MessageVersion = MessageVersion.Default;

// create and configure reliable session
ReliableSessionBindingElement reliableSession = 
      new ReliableSessionBindingElement();
reliableSession.Ordered = true;

// compose into binding
CustomBinding reliableHttpBinding = 
      new CustomBinding(
            reliableSession,
            textMessageEncoding,
            httpTransport);

바인딩 요소가 있으면 WCF는 서비스의 ServiceHost 가 열리고 엔드포인트에 바인딩되면 HTTP 전송 수신기 위에 신뢰할 수 있는 세션 수신기 인프라를 쌓습니다. 마찬가지로 ChannelFactory가 열리고 따라서 원격 엔드포인트 주소에 바인딩될 때 클라이언트 쪽 HTTP 전송 채널 위에 신뢰할 수 있는 세션 채널 인프라를 쌓습니다. ProxyBase 및 ProxyBase<T>는 ChannelFactory 및 생성된 클라이언트 채널을 만들고 구성하고 여는 편의 래퍼일 뿐입니다.

Aa480191.introtowcfreliablemessaging1(en-us,MSDN.10).gif

그림 1. WCF에서 신뢰할 수 있는 세션 설정

이 매우 간소화된 다이어그램은 WCF에서 신뢰할 수 있는 세션이 설정되는 방법을 보여 줍니다. 첫 번째 애플리케이션 수준 메시지(1)가 프록시를 통해 전송되거나 신뢰할 수 있는 세션 사용 바인딩을 사용하여 전송 주소에 바인딩된 형식화되거나 형식화되지 않은 채널이 전송될 때마다 메시지는 신뢰할 수 있는 세션 출력 채널을 통과합니다.

처음에는 세션이 없으므로 보낸 사람 쪽(1a)에 새 세션이 만들어지고 세션 개체 자체가 (2,3) 대역 외 메시지 "CreateSequence"를 원격 엔드포인트로 보냅니다. 원격 엔드포인트에서 전송 수신기가 메시지를 수락하고 새 전송 채널이 설정됩니다. 그 후 메시지가 신뢰할 수 있는 세션 수신기에 전달됩니다(5). 새 세션(5a)을 만들어 처리된 요청은 요청자에게 (7) 전송되며, 여기서 요청자는 세션 개체(8)로 다시 디스패치되어 시퀀스 생성 왕복을 완료합니다. 그 후(9) 애플리케이션 메시지가 (10) 원격 엔드포인트로 전송되는 출력 전송으로 전달됩니다. 원격 엔드포인트에서 메시지는 세션과 연결된 입력 채널에 의해 처리되고( 11) 신뢰할 수 있는 세션 입력 채널로 전달되고 서비스 instance 마지막으로 디스패치(12)됩니다. 서비스 instance 가능한 응답은 응답 쪽에서 신뢰할 수 있는 세션 출력 채널(13)과 전송 출력 채널(14)을 트래버스하고, 요청자(15)의 전송 입력 채널로 전송한 다음, 신뢰할 수 있는 세션 입력 채널(16)까지 버블링하고 마지막으로 프록시(17)까지 이동합니다.

전송 승인("acks")이 전송되는 방법은 전송 채널의 특정 선택에 따라 달라집니다. 전송 채널이 "이중"이면 메시지 트래픽을 어느 방향으로든 릴레이하기 위해 두 엔드포인트 간에 양방향 전송 연결이 있음을 의미합니다. 승인은 특정 메시지를 통해 대역 외로 전송되며 일반적으로 일괄 처리로 전송됩니다. 전송 채널이 요청/회신 유형인 경우 다음 메시지에서 승인이 피기백됩니다(회신에 대한 요청 ack, 요청에 대한 회신 ack).

세션 및 HTTP

연결 없는 HTTP 전송 바인딩의 경우 신뢰할 수 있는 세션 바인딩 요소는 서비스 계약에 대한 세션 지원을 추가하는 규정된 방법입니다.

HTTP는 연결이 없고 요청은 한 당사자에 의해서만 시작되므로 논리적 연결(즉, 세션)은 일반적으로 각 요청 및 응답과 함께 통신 당사자 간에 공유되는 참조 토큰(쿠키)을 사용하여 생성됩니다.

HTTP 수준의 필수 메커니즘은 핵심 HTTP 사양 RFC2616이 아닌 RFC2965에 설명되어 있으며 양 당사자가 지원하는 것은 엄격히 선택 사항입니다. 이러한 쿠키 기반 세션을 일련의 호출에 대해 웹 메서드별로 사용하도록 설정할 수 있는 ASP.NET 웹 서비스와 달리 WCF는 현재 HttpTransportBindingElement 의 구성 스위치를 통해 엔드포인트별로만 이 동작을 지원합니다.

쿠키 기반 세션 지원을 사용하려면 구성 또는 코드에서 사용자 지정 바인딩을 생성하고 AllowCookies 속성 또는 해당하는 allowCookies 구성 특성을 true로 설정해야 합니다. 베타 2 및 최종 WCF 제품에 이어 CTP(Community Technology Preview)에서 이 옵션은 코드 및 구성의 표준 BasicHttpBinding 및 WSHttpBinding 바인딩에서도 쉽게 액세스할 수 있으며 더 이상 이러한 사용자 지정 바인딩을 생성할 필요가 없습니다.

그러나 HTTP 기반 웹 서비스에 쿠키 기반 세션을 사용하지 않는 데는 여러 가지 이유가 있습니다.

두 당사자는 쿠키를 삭제하여 쿠키 기반 세션 메커니즘을 항상(그리고 RFC2965에 따라) 옵트아웃할 수 있으므로 메커니즘은 매우 신뢰할 수 없습니다.
서비스에서 WSDL 또는 WS-Policy를 통해 클라이언트에 대한 쿠키 기반 세션 지원 요구 사항을 표현하는 표준 방법은 없습니다.
HTTP 수준 쿠키는 메시지 헤더처럼 디지털 서명할 수 없으므로(SSL을 사용하지 않는 한 항상 옵션이 아님) 세션을 도난당하고 제3자가 스푸핑할 수 있는 잠재적인 보안 위협이 발생합니다.

다음과 같은 허수의 세션 사용 계약을 예로 들어 보세요. 이를 통해 여러 대출이 있는 금융 패키지의 서버 쪽 구성을 통해 전체 평균 이자, 수수료 및 결합된 월 상환액과 같은 상태 검색하고 마지막으로 구성된 패키지를 은행의 내부 대출 신청 처리에 제출할 수 있습니다.

[ServiceContract(Session = true)]
public interface IFinancingPackageBuilder
{
   [OperationContract(IsInitiating=true)]
   LoanId AddLoan(LoanInfo loanInfo);
   [OperationContract(OneWay=true,IsInitiating = false)]
   void RemoveLoan(LoanId loanId);
   [OperationContract(IsInitiating = false)]
   PackageStatusInfo GetFinancePackageStatus();
   [OperationContract(OneWay=true,IsTerminating = true)]
   void SubmitApplication(PersonalInfo personalInfo); 
}

위의 서비스 계약 예제에서 파생될 수 있으므로 실제로 세션 지원이 필요한 서비스는 idempotent가 아닌 작업이 있을 수 있으므로 신뢰할 수 있는 메시지 배달의 이점을 즉시 활용하는 것이 매우 일반적입니다.

"Idempotent"는 한 번 또는 두 번 또는 여러 번 동일한 작업을 호출하는지 여부에 관계없이 서비스의 결과 상태가 동일하다는 것을 의미합니다.

위에 표시된 AddLoan 또는 RemoveLoan 작업에서 서비스 상태에 데이터를 증분 방식으로 추가하고 제거하는 것은 아닙니다. 멱등적이지 않은 작업은 메시지 손실 또는 중복의 경우 상당한 골칫거리가 발생할 수 있습니다. 따라서 세션과 신뢰할 수 있는 메시징을 결합하는 것은 앞에서 설명한 대로 인프라 수준에 대한 기술적 추론이 있을 뿐만 아니라 애플리케이션 수준에서 아키텍처를 많이 이해합니다.

HTTP와 달리 연결 지향 TCP 및 명명된 파이프 전송은 기본적으로 세션을 지원합니다. 둘 다에 대해 엔드포인트 간에 연결이 활성 상태로 유지되는 한 암시적 세션이 자동으로 존재합니다. 신뢰할 수 있는 세션 메커니즘을 통해 전송 독립적 안정성을 추가하는 것은 유용하지만 HTTP와 마찬가지로 세션 지원에는 필요하지 않습니다.

이러한 전송 내재 세션 기능 위에 신뢰할 수 있는 세션을 사용할 경우의 기본 이점은 라우팅 시나리오에서 종단 간 신뢰할 수 있는 메시지 배달이며 일시적인 연결 실패에 대한 복원력을 추가한 것입니다.

신뢰할 수 있는 메시징 세션 옵션

신뢰할 수 있는 세션 바인딩 요소와 기본 인프라에는 다음 표에 나열된 몇 가지 구성 속성이 있습니다. 이러한 각 설정은 구성된 통신 엔드포인트의 로컬 동작에만 영향을 줍니다. 즉, 요청/회신 통신의 클라이언트에는 각 서비스 쪽과 다른 설정이 있을 수 있습니다.

언급된 모든 기본값은 베타 2에 대한 예비 값이며 최종 제품에서 변경될 수 있습니다.

속성	Description
AcknowledgementInterval (TimeSpan)	받는 사람이 메시지에 대한 승인을 보낼 때까지 기다려야 하는 간격입니다. 기본값은 2초입니다. 구성된 간격 시간 범위 내에서 수신된 메시지는 네트워크 트래픽을 줄이는 것을 목표로 한 일괄 처리로 승인됩니다. 세션의 첫 번째 메시지는 항상 즉시 승인됩니다. 설정은 하드 제한이 아니라 인프라에 대한 권장 사항입니다. 참고: 이 설정은 양방향 이중 전송 바인딩에만 적용되며 각 요청 메시지가 해당 회신에 대해 승인되고 다음 요청에서 회신이 승인되는 요청/회신 스타일 바인딩에는 영향을 주지 않습니다.
EnableFlowControl (부울)	흐름 제어 기능을 켜거나 끕니다(이 기능은 기본적으로 설정됨). 이 기능을 사용하면 받는 메시지의 수신 쪽 버퍼가 가득 차면 보낸 사람에게 메시지 보내기를 중지하여 네트워크 리소스 낭비를 방지할 수 있습니다. 버퍼가 가득 차면 전송되는 메시지는 삭제되고 재전송이 필요하므로 이러한 메시지를 보내지 않으면 네트워크 리소스를 절약하는 데 도움이 됩니다. 이 최적화된 네트워크 리소스 사용은 수신자 쪽 버퍼의 사용 가능한 용량을 보낸 사람에게 보고하여 활성화되므로 버퍼가 가득 차면 발신자가 메시지를 보내지 않습니다.
MaxTransferWindowSize (Int32)	이 값은 신뢰할 수 있는 각 세션에 대해 로컬 메시지 버퍼에 저장할 수 있는 메시지 수를 지정합니다. 보낸 사람 쪽에서 이 버퍼는 아직 승인되지 않은 메시지를 보유하며 수신자 쪽에서 이 버퍼는 애플리케이션에서 아직 처리되지 않은 메시지를 보유합니다. 이 값의 기본값은 32이고 최소값은 1이고 최대값은 4096입니다. 보낸 사람 버퍼 크기가 세션에서 구성된 제한까지 채워지면 발신자가 차단됩니다. 수신자 버퍼 크기가 세션의 한도까지 채워지면 들어오는 메시지가 삭제됩니다.
InactivityTimeout (TimeSpan)	기본적으로 10분으로 설정되는 비활성 시간 제한은 다른 쪽에서 메시지를 받지 않고(애플리케이션 메시지, 승인 또는 기타 인프라 메시지) 경과할 수 있는 시간을 정의합니다. 애플리케이션 수준 메시지가 전송되지 않는 경우 인프라는 연결이 여전히 유효한지 확인하기 위해 "연결 유지" 메시지를 보내기 시작합니다. 해당 시간 제한 내에 메시지가 수신되지 않으면 세션 오류가 발생합니다.
MaxPendingChannels (Int32)	이 설정은 "보류 중인 채널" 목록에 유지되는 새 클라이언트 시작 세션에 대한 보류 중인 요청 수를 제어합니다. 클라이언트가 새 세션을 설정하려고 할 때마다 채널은 서비스 쪽에서 생성되며 세션이 설정되려면 신뢰할 수 있는 세션 수신기가 수락하고 열어야 합니다. 압력을 받고 인프라가 처리할 수 있는 것보다 더 많은 새 세션에 대한 요청이 쌓일 수 있습니다. 아직 액세스되지 않은 보류 중인 채널의 기본 최대값은 128입니다. 이 임계값에 도달하면 수신기 인프라는 새 세션에 대한 요청을 거부합니다.
MaxRetryCount (Int32)	기본값이 8(최소 1, 최대 20)인 이 값은 전송 실패 시 인프라가 메시지를 다시 보내려고 다시 시도하는 횟수를 지정합니다. 구성된 재시도 횟수에 대해 메시지가 다시 전송되지 않으면 오류를 복구할 수 없는 것으로 간주하여 채널에 오류가 발생합니다.
주문됨 (부울)	이 구성 속성이 true(기본적으로 해당)로 설정된 경우 수신자 쪽 인프라는 모든 메시지를 전송된 정확한 순서로 디스패치합니다. 메시지가 순서대로 도착하면 시퀀스의 누락된 메시지가 도착할 때까지 버퍼링됩니다. false로 설정하면 메시지가 전송된 순서에 관계없이 즉시 서비스로 디스패치됩니다.

이 구성 속성 목록의 놀라운 점은 다시 시도 횟수(MaxRetryCount)를 구성할 수 있지만 다시 시도되는 간격이 구성 가능한 값 목록에 표시되지 않는다는 것입니다.

이는 WCF가 간단한 재시도 시간 제한을 훨씬 넘어서는 신뢰할 수 있는 전송 작업에 몇 가지 정교한 정체 제어 알고리즘을 적용하기 때문입니다. 여기서 사용되는 알고리즘은 대부분의 TCP 구현에서 사용되는 시도되고 입증된 정체 제어 메커니즘과 유사합니다. 일반적으로 재시도 시간 제한 값은 처음에는 다소 관대하며 발신자가 추가 메시지를 계속 보내는 동안 승인되지 않은 상태로 남겨둘 수 있는 메시지 수는 일반적으로 1에서 매우 낮게 시작됩니다. 통신 경로가 빠르고 안정적이며 메시지 손실이 발생하지 않는 것으로 판명되면 시간 제한이 단축되고 발신자는 승인되지 않은 메시지의 수가 증가하여 결국 ack가 돌아올 것으로 예상합니다. 메시지 손실이 발생하면 시간 제한이 짧아지면 더 빨리 다시 전송됩니다. 더 뛰어난 승인을 허용하면 처리량이 높아질 수 있습니다. 통신 경로의 품질이 감소하고 매우 느리거나 가끔 연결이 끊어지면 알고리즘으로 인해 시간 제한이 기하급수적으로 증가하고 허용되는 미해결 승인 수가 크게 감소하여 처리량이 제한되고 실패 허용 오차가 증가합니다.

표준 바인딩을 사용하는 신뢰할 수 있는 메시징

WCF의 표준 바인딩이 세션 및 신뢰할 수 있는 메시징을 지원하는지 여부와 방법은 기본 전송의 고유한 기능과 해당 기능을 지원하기 위해 바인딩에서 암시적으로 신뢰할 수 있는 메시징이 필요한지 여부에 따라 크게 달라집니다.

바인딩	WS-RM 지원	세션 지원
BasicHttpBinding	없음	No
WSHttpBinding	예, 바인딩 요소 또는 구성에서 ReliableSession.Enabled 속성이 true로 설정된 경우입니다.	예, RM이 사용하도록 설정된 경우입니다.
WSDualHttpBinding	항상, 암시적	예, 암시적
NetTcpBinding	예, 바인딩 요소 또는 구성에서 ReliableSession.Enabled 속성이 true로 설정된 경우	예, 암시적
NetNamedPipeBinding	기본 전송으로 보장되는 신뢰할 수 있는 배달 없음	예, 암시적
NetMsmqBinding	기본 전송으로 보장되는 신뢰할 수 있는 배달 없음	예, 트랜잭션 큐가 사용되는 경우 입니다.
MsmqIntegrationBinding	기본 전송으로 보장되는 신뢰할 수 있는 배달 없음	No

BasicHttpBinding은 기본 WS-Security 프로필을 제외하고 WS-* 헤더를 지원하지 않으며 간단한 HTTP 기반 SOAP 메시징만 지원하기 위한 것입니다. 따라서 이 바인딩에서 신뢰할 수 있는 메시징 및 세션을 사용하도록 설정할 수 없습니다.

WSHttpBinding 및 NetTcpBinding은 보낸 사람에서 받는 사람에게 요청 메시지(및 회신 가능)를 흐르는 WS-* 인식 바인딩입니다. 두 바인딩 모두 ReliableSession.Enabled 구성 속성을 true로 설정하여 신뢰할 수 있는 메시징을 사용하도록 설정할 수 있습니다.

세션은 연결 지향 NetTcpBinding의 기본 전송에서 암시적으로 지원되며 이 설정과는 무관하지만 WSHttpBinding을 사용한 세션 지원에는 신뢰할 수 있는 세션이 필요합니다.

두 HTTP 엔드포인트 간에 양방향 대화형 링크를 설정하는 명시적 이중 바인딩 WSDualHttpBinding을 사용하려면 신뢰할 수 있는 메시징과 세션이 작동해야 합니다. 따라서 RM은 암시적으로 사용되며 이 바인딩에 대해 항상 사용하도록 설정됩니다.

앞서 언급한 reliable-session 지원 바인딩을 사용하면 메시지 순서가 항상 적용됩니다. 즉, 메시지가 전송된 정확한 순서로 수신 서비스에 전달됩니다. 이 기능을 해제하려는 경우 앞에서 설명한 대로 사용자 지정 바인딩을 작성하고 ReliableSessionBindingElement에서 Ordered 속성(또는 동등한 구성 특성)을 사용하여 이 메커니즘을 사용하지 않도록 설정해야 합니다.

NetNamedPipeBinding은 명명된 파이프를 통해 신뢰할 수 있는 메시지 배달 및 신뢰할 수 있는 스트림에 대한 Windows 운영 체제의 지원을 기반으로 합니다. 명명된 파이프는 연결 지향적이고 쉽게 지원되는 세션이며 설계상 신뢰할 수 있으며 일반적으로 브리지되지 않으므로 이 바인딩에서 WS-RM을 지원할 필요가 없습니다.

MSMQ(Microsoft Message Queue)는 신뢰할 수 있는 메시지 배달을 구현하기 위해 WS-RM 지원이 필요하지 않은 운영 체제 수준의 신뢰할 수 있는 전송입니다. 대신 NetMsmqBinding에는 MSMQ 가 메시지 배달에 제공할 수 있는 전송 보증을 반영하는 특별한 구성 속성 집합이 있습니다.

MSMQ는 단방향 전송이지만 트랜잭션 지원을 통한 세션도 지원합니다. 기본 큐가 트랜잭션이고 메시지 집합이 트랜잭션 scope 내에서 받는 사람 서비스로 전송되는 경우 트랜잭션 내에서 큐에 대기된 모든 메시지는 세션 scope 내의 받는 사람 서비스에 전달됩니다. 트랜잭션된 메시지 일괄 처리의 마지막 메시지가 전달되면 세션이 닫힙니다.

신뢰할 수 있는 세션 지원 요구

애플리케이션을 코딩할 때 신뢰할 수 있는 메시징 및 세션 지원의 가용성에 따라 몇 가지 가정을 할 수 있습니다. 이렇게 하면 이러한 기능이 애플리케이션의 적절한 작동에 중요한 역할을 하며, 이는 전적으로 올바른 바인딩을 선택하고 구성하는 문제입니다. 이렇게 하면 시스템을 구성하는 사람의 자비로 애플리케이션이 제대로 작동하게 되며, 이로 인해 진단 및 디버그하기가 매우 어려운 문제가 발생할 수 있습니다.

적절한 작동이 신뢰할 수 있는 메시징, 특히 메시지의 정렬된 배달에 따라 달라지는 서비스가 예상대로 작동하는지 확인하려면 DeliveryRequirementsAttribute를 통해 애플리케이션 코드의 사용된 바인딩에서 주문된 배달 지원을 명시적으로 요구할 수 있습니다.

[DeliveryRequirements(RequireOrderedDelivery=true)]
public class FinancingPackageBuilder : IFinancingPackageBuilder
{
   ...
}

구성된 바인딩이 이 특성에 필요한 기능을 지원하지 않는 경우 서비스 호스트는 서비스 호스트를 거부하고 예외를 throw합니다. 바인딩의 까다로운 세션 지원은 계약 선언의 ServiceContractAttribute에 대한 세션 요구 사항을 선언하여 암시적으로 수행됩니다.

[ServiceContract(Session = true)]
public interface IFinancingPackageBuilder
{
...
}

단방향, 큐 및 지속성 메시징

"신뢰할 수 있는 메시징은 강력하고 동시에 데이터를 처리할 수 있으므로 확장성을 크게 향상시키는 강력한 소프트웨어 아키텍처를 구현하는 데 핵심적인 요소입니다." 이 문서의 첫 번째 문장 중 하나이지만 쇠고기는 어디에 있습니까?

기술 무기의 일부로 선택한 모든 전송에서 신뢰할 수 있는 메시지 배달을 일관되게 사용할 수 있게 되면 신뢰할 수 있는 배달 지원이 WS-RM으로 구현되는지 아니면 전송에 내재되어 있는지와 실제로 관련이 없으므로 필요한 배관 코드의 복잡성이나 비용으로 인해 WCF 전에 대부분의 소프트웨어 개발자에게 도달할 수 없는 구현 패턴을 사용하는 훨씬 더 강력한 애플리케이션을 빌드할 수 있습니다. 이전에는 이러한 작업을 수행할 수 없었던 것이 아니라 고객을 위한 비즈니스 기능을 구현하는 것이 주요 관심사인 사람들에게는 매우 어려웠습니다.

백 엔드 애플리케이션에 "동급 금액" 문서를 준비하고 제출하는 클라이언트 애플리케이션을 작성한다고 가정합니다. 구매 주문, 회계 기록 또는 다른 사람의 여행 상환 서류가 될 수 있습니다. 일반적으로 논리는 이러한 레코드를 준비하고 일관성을 위해 유효성을 검사한 다음 추가 처리를 위해 백 엔드 시스템으로 보냅니다. 또한 매우 일반적으로 애플리케이션은 준비한 후 처리 체인의 해당 부분으로 "완료"되며 처리 결과에 대한 알림은 훨씬 나중에 다른 채널을 통해서만 돌아갈 수 있습니다(전자 메일의 방법으로).

신뢰할 수 있는 메시징이 준비되면 클라이언트 애플리케이션은 주로 네트워킹 조건에 관계없이 메시지를 대상으로 가져오는 인프라를 위임할 수 있습니다. 이를 전송할 작업에 대한 로컬, 보낸 사람 쪽 영구 큐와 결합하는 경우("큐"는 MSMQ와 동의어가 아니며, MSMQ가 기본으로 지원되는 WCF와 일치합니다. 사용자 고유의 큐 채널을 작성하려는 경우 로컬 SQL 서비스 instance 이에 적합하며 격리된 스토리지를 포함한 파일 시스템에 적합합니다. 은(는) 신뢰할 수 있는 메시징 연결이 영구적으로 실패하거나 애플리케이션 또는 컴퓨터가 충돌하는 드문 경우에도 합리적으로 안전합니다. 수신 끝에서 큐는 메시지 전송을 처리에서 분리하는 데 매우 좋습니다. 끝에 "안전하게" 메시지가 표시되면 로컬 영구 큐에 작업을 저장하고 해당 큐에서 실제 처리를 읽을 수 있습니다. MSMQ용 WCF의 NetMsmqBinding 은 사용자를 위해 이 작업을 수행합니다. 그러나 다른 모든 바인딩에서는 이러한 기능("지속성 메시징")을 구현해야 합니다. 그리고 이것은 "필수"기능의 눈부신 명백한 누락처럼 보일 수 있지만, 지속성 메시징이 다른 바인딩에서 쉽게 사용할 수없는 이유에 대한 참으로 좋은 이유가있다 :

사실, WCF의 WS-ReliableMessaging 기반 구현 자체의 안정성은 표준에 표현된 것을 제외하고는 해당 원격 파트너에 대해 어떤 가정도 할 수 없는 휘발성 신뢰할 수 있는 메시징 메커니즘에 대한 것만큼이나 "전용"입니다. WS-RM 표준은 WS-ReliableMessaging 전송 프로토콜이기 때문에 와이어에서 발생하는 작업만 다루며, 다른 쪽에서 성공적으로 수신된 후 메시지에 어떤 일이 일어나야 하는지에 대해서는 아무 말도 하지 않습니다. WCF가 메시지 배달, 연결 종료를 위한 햇빛, 우박 또는 지진에 대한 하드 배달 보증을 제공하고 원격 당사자가 표준을 준수하지만 구현에서 특히 견고하지 않은 경우 WCF가 지금 제공하는 수준 이하의 전반적인 서비스 품질로 끝날 것입니다.

트랜잭션 I/O를 완전히 지원하는 엔드 투 엔드 지속성 신뢰할 수 있는 메시징이 필요한 경우 통신 경로의 양쪽 끝을 제어하는 인프라가 필요하며, 이러한 인프라는 Windows 운영 체제 제품군의 일부입니다. 요구 사항인 경우 선택한 WCF 바인딩이 NetMsmqBinding일 수 있습니다. 최적화되지 않은 네트워킹 조건에서 메시지를 손실하지 않는 것이 가장 걱정되거나 더 일반적인 사용 사례인 세션 지원이 필요한 경우 WCF의 신뢰할 수 있는 세션 지원은 이전 Web Services 스택과 비교할 때 올바른 선택이며 큰 도약입니다.

작성자 정보

Clemens Vasters는 Microsoft의 Windows Communication Foundation 팀의 커뮤니티 프로그램 관리자로, 개발자 및 설계자 커뮤니티를 제품 그룹과 연결하는 역할을 담당합니다. 2006년 초에 Microsoft에 합류하기 전에 Microsoft Certified Architect인 Clemens는 newtelligence AG의 CTO였습니다. Clemens는 전 세계 소프트웨어 개발자 컨퍼런스에서 자주 연사로 활동했습니다.