Intermediary Router

이 샘플에서는 클라이언트에서 서비스에 직접 액세스하지 못할 수도 있는 네트워크 구성에서 유용한 기본 라우팅 기능을 제공하는 서비스를 구현하는 방법을 보여 줍니다. 이 샘플은 여러 가지 기능을 갖춘 효율적이고 확장 가능한 라우터에 관한 예가 아닙니다.

참고

이 샘플의 설치 절차 및 빌드 지침은 이 항목의 끝부분에 나와 있습니다.

SOAP 매개자가 포함된 일반적인 통신 시나리오에서 클라이언트가 보낸 메시지는 하나 이상의 추가 서비스를 통과한 후 최종 대상, 즉 메시지를 실제로 처리하고 응답이 필요한 경우 이를 제공하는 서비스에 도달합니다. SOAP 매개자는 자신을 통과하는 메시지에 대해 다양한 작업을 수행합니다. 예를 들어, 캐싱 매개자는 캐시된 응답을 메시지에 반환하는데, 이로 인해 요청을 다시 처리해야 하는 서비스의 부담이 줄어듭니다. 부하 분산 매개자는 라운드 로빈 알고리즘을 사용하여 메시지를 여러 가능한 서비스 중 하나에 전달합니다. 스키마 유효성 검사 매개자는 계약의 XSD 및 가능한 경우 다른 프로토콜을 완벽하게 준수하는 메시지만 전달합니다. 이 샘플을 위해 개발된 매개자는 메시지의 헤더 및 내용에 따라 메시지를 적절한 서비스에 라우팅합니다.

SOAP 메시지에 대한 자세한 내용은 XML Web Service Wire Formats을 참조하십시오.

이 샘플에서는 클라이언트 요청을 처리하기 위해 두 가지 응용 프로그램 서비스, 즉 계산기 서비스와 에코 서비스가 배포되었습니다. 서비스의 응용 프로그램 끝점은 내부 네트워크에서만 액세스할 수 있습니다. 서비스의 MEX(메타데이터 교환) 끝점은 공개적으로 액세스 가능합니다. SOAP 라우터는 내부 네트워크의 일부로서 내부 네트워크의 외부에서 들어오는 모든 응용 프로그램 요청은 SOAP 라우터를 통과해야 합니다.

두 서비스에 대해 Service Model Metadata Utility Tool (Svcutil.exe)를 실행하여 클라이언트를 만들고, 두 개의 코드 파일(서비스별로 클라이언트 하나씩)과 하나의 구성 파일을 생성합니다. 첫 번째 서비스에 대해 Svcutil.exe를 실행하여 만들어진 기존 구성 파일에 두 번째 서비스의 구성 정보가 병합되기 때문에 구성 파일은 하나만 생성됩니다. 각 서비스에서 제공한 WSDL(웹 서비스 기술 언어)은 실제 서비스의 주소 대신 SOAP 매개자의 주소를 포함합니다. 따라서 클라이언트가 구성 파일을 수정하거나 SOAP 매개자의 주소를 알 필요가 없습니다.

또한 이 샘플의 라우터 서비스는 두 개의 끝점으로 구성되어 있습니다. 하나는 SOAP 1.2용 HTTP를 사용하여 텍스트 인코딩 메시지를 수신하고, 다른 하나는 SOAP 1.2용 TCP를 사용하여 이진 인코딩 메시지를 수신합니다. 각 응용 프로그램 서비스의 WSDL은 라우터의 올바른 끝점 주소를 사용합니다. 또한 라우터는 구성 파일의 appSettings 섹션에 있는 라우팅 정보를 제공하는데, 다음과 같은 속성이 포함됩니다.

prefixes 및 namespaces - 라우터의 Xpath에 있는 접두사를 확인할 수 있도록 WCF의 기본 XmlNamespaceManager를 업데이트할 때 사용합니다.
xpath 및 epr - XPaths를 EPRs에 매핑하는 라우팅 테이블에 라우팅 항목을 추가할 때 사용합니다.

라우터는 XpathMessageFilterTable(XPathFilterTable<T>) 클래스를 사용하며, 여기서 "T"는 사용자가 제공하는 라우팅 항목을 저장하는 EndpointAddress입니다. 메시지가 수신되면 라우터는 MatchMultiple 메서드를 호출하여 Message 인스턴스를 전달하고 메시지를 전달할 EndpointAddress를 검색합니다.

EchoService 및 CalculatorService 모두 ListenUri 속성을 사용하여 끝점이 수신 대기하는 URI를 설정합니다. 끝점 선언 내부에 제공된 주소는 서비스의 메시지를 전달할 수 있는 라우터 끝점의 주소입니다. 이는 서비스의 WSDL에 나타나는 주소이며, 들어오는 모든 메시지의 WS-Addressing To 헤더와 일치하는지 비교합니다. 그러나 ListenUri 속성에 제공된 주소는 전송에서만 사용하는 끝점의 실제 물리적 수신 대기 주소입니다.

WCF는 이 샘플에서 수행하지 않는 SOAP 매개자 시나리오에서 일반적으로 사용되는 또 다른 동작, 즉 ClientViaBehavior 채널 동작을 제공합니다. ClientViaBehavior는 클라이언트가 전송 채널을 만들어야 하는 URI를 지정할 때 사용합니다. 해당 동작이 클라이언트 끝점의 동작 컬렉션에 있는 경우 전송에서는 제공되는 URI를 사용하고, 스택의 모든 다른 채널 계층에서는 ChannelFactory를 구성할 때 제공된 EndpointAddress를 사용합니다. 또한 이 EndpointAddress는 WS-Addressing To 헤더가 됩니다. 다음 샘플 코드에서는 이 동작을 사용하는 방법을 보여 줍니다.

ChannelFactory<IContract> factory = new ChannelFactory<IContract>(new EndpointAddress("http://hostname/service"));
factory.Endpoint.Behaviors.Add(new ClientViaBehavior(new Uri("http://hostname/intermediary")));
IContract channel = factory.CreateChannel();

SOAP 매개자와 함께 사용하는 또 다른 WCF 기능은 AddressFilter 속성입니다. AddressFilter는 WCF에서 특정 필터와 일치하는 메시지만 수락하기 위해 사용합니다. 서비스 계약의 메서드가 "*"를 Action으로 사용할 경우 주소만 검사합니다. 이 샘플에서는 주소가 항상 정확하므로 이 기능을 사용하지 않습니다. 라우터는 To 헤더가 끝점 주소와 일치하므로 클라이언트의 메시지를 수락하고, 서비스는 전달된 메시지의 To 헤더가 끝점의 논리 주소와 일치하므로 전달된 메시지를 수락합니다.

샘플의 Contracts.cs 파일은 전송 패턴별로 하나씩 다음 네 가지 인터페이스를 정의합니다.

ISimplexDatagramRouter. 이 인터페이스는 단방향 데이터그램 채널에서 메시지를 수락하기 위해 필요합니다. 단방향 HTTP 채널 또는 단방향 TCP 및 NamedPipe 채널에서 메시지를 예상하는 경우 이 인터페이스를 사용하여 끝점을 추가합니다.
IRequestReplyDatagramRouter. 이 인터페이스는 요청-회신 데이터그램 채널에서 메시지를 수락하기 위해 필요합니다. 양방향 HTTP 채널의 메시지에 이 인터페이스를 사용합니다.
ISimplexSessionRouter. 이 인터페이스는 단방향 세션 채널에서 메시지를 수락해야 합니다. 단방향 TCP 및 단방향 NamedPipe 채널에 이 인터페이스를 사용합니다.
IDuplexSessionRouter. 이 인터페이스는 이중 세션 채널용입니다. 이중 TCP 및 이중 NamedPipe 채널에 이 인터페이스를 사용합니다.

RouterBinding은 SOAP 매개자 지원을 위해 만들 수 있는 WCF 바인딩의 예를 제공합니다. 이 시나리오에 필요한 가장 일반적인 설정을 지정할 수 있으며, 실제로 필요한 바인딩 요소만 추가합니다. 또한 기본 구성 지원도 보여 줍니다.

이 샘플에서는 HTTP가 아닌 전송을 사용하므로 웹 호스팅을 사용하지 않습니다. 현재 TCP 활성화는 Windows Vista 및 IIS 7.0에서만 사용 가능합니다.

샘플을 실행하면 작업 요청 및 응답이 클라이언트 콘솔 창에 표시됩니다. 클라이언트를 종료하려면 클라이언트 창에서 Enter 키를 누릅니다.

Echo("Is anyone there?") returned: Is anyone there?
Add(5) returned: 5
Add(-3) returned: 2

샘플을 설치, 빌드 및 실행하려면

C#, C++, Visual Basic .NET 버전의 솔루션을 빌드하려면 Windows Communication Foundation 샘플 빌드의 지침을 따릅니다.
단일 컴퓨터 또는 다중 컴퓨터 구성에서 샘플을 실행하려면 다음 예외 사항과 함께 Windows Communication Foundation 샘플 실행의 지침을 따릅니다.
1. 단일 컴퓨터 및 다중 컴퓨터 구성에는 프로젝트 네 개와 실행 파일 네 개가 필요합니다. 즉, 클라이언트용으로 하나, SOAP 라우터용으로 하나, 그리고 응용 프로그램 서비스별로 하나씩 필요합니다.
2. 다중 컴퓨터 구성에서는 구성 파일 네 개를 다음과 같이 변경해야 합니다.
  CalculatorService 및 EchoService의 App.config 파일에서 21번째 줄을 변경해야 합니다. localhost 호스트 이름 대신 매개자의 실제 호스트 이름을 입력합니다.
  라우터의 App.config 파일에서 15번째 줄을 변경해야 합니다. '|'로 구분된 두 주소는 각각 EchoService 및 CalculatorService의 호스트 이름으로 각각 변경되어야 합니다.
  클라이언트의 App.config 파일에서 5번째 및 7번째 줄을 변경해야 합니다. localhost 호스트 이름 대신 매개자의 실제 호스트 이름을 입력합니다.
  또한 두 응용 프로그램 서비스가 올바른 주소를 사용하도록 업데이트되었다면 이 응용 프로그램 서비스에 대해 Service Model Metadata Utility Tool (Svcutil.exe)를 사용하여 App.config 파일을 다시 생성할 수 있습니다.
클라이언트를 시작하기 전에 Router, EchoService 및 CalculatorService가 모두 실행 중인지 확인합니다. 세 서비스는 각각 시작 시 수신 대기하는 끝점 주소를 출력합니다.

참고

EchoService 및 CalculatorService의 응용 프로그램 끝점은 라우터 주소를 사용합니다.
클라이언트를 실행합니다. 클라이언트는 먼저 EchoService에 연결한 다음 CalculatorService에 연결합니다. Router는 전달 중인 메시지의 WS-Addressing 작업을 양방향으로 출력합니다.

참고

Client.exe와 Router.exe가 서로 다른 컴퓨터에 있는 경우 Client.exe.config에서 <identity/> 섹션의 주석 처리를 제거하고 사용자 계정 이름을 Router.exe를 실행 중인 사용자 중 한 명으로 설정합니다.

Last updated on 2008-09-05

다음을 통해 공유

Intermediary Router

샘플을 설치, 빌드 및 실행하려면

추가 리소스