이 섹션에서는 WCF 계약을 정의하고 구현하는 방법을 보여 줍니다. 서비스 계약은 엔드포인트가 외부 세계와 통신하는 것을 지정합니다. 보다 구체적인 수준에서는 요청/회신, 단방향 및 이중과 같은 기본 MEP(메시지 교환 패턴)로 구성된 특정 메시지 집합에 대한 문입니다. 서비스 계약이 논리적으로 관련된 메시지 교환 집합인 경우 서비스 작업은 단일 메시지 교환입니다. 예를 들어 Hello 작업은 분명히 하나의 메시지(호출자가 인사말을 알릴 수 있도록)를 수락해야 하며( 작업의 호의에 따라) 메시지를 반환하거나 반환하지 않을 수 있습니다.
계약 및 기타 핵심 WCF(Windows Communication Foundation) 개념에 대한 자세한 내용은 기본 Windows Communication Foundation 개념을 참조하세요. 이 항목에서는 서비스 계약 이해에 중점을 둡니다. 서비스 계약을 사용하여 서비스에 연결하는 클라이언트를 빌드하는 방법에 대한 자세한 내용은 WCF 클라이언트 개요를 참조하세요.
개요
이 항목에서는 WCF 서비스를 디자인하고 구현하기 위한 높은 수준의 개념적 방향을 제공합니다. 하위 항목은 디자인 및 구현의 세부 사항에 대한 자세한 정보를 제공합니다. WCF 애플리케이션을 디자인하고 구현하기 전에 다음을 수행하는 것이 좋습니다.
서비스 계약의 내용, 작동 방식 및 서비스 계약을 만드는 방법을 이해합니다.
계약이 명시하는 최소 요구 사항이 런타임 구성 또는 호스팅 환경과 맞지 않을 수 있음을 이해합니다.
서비스 계약
서비스 계약은 다음을 지정합니다.
계약이 제공하는 작업입니다.
교환된 메시지 측면에서 작업의 서명입니다.
이러한 메시지의 데이터 형식입니다.
작업의 위치입니다.
서비스와의 성공적인 통신을 지원하는 데 사용되는 특정 프로토콜 및 직렬화 형식입니다.
예를 들어 구매 주문 계약에는 CreateOrder 주문 정보 유형의 입력을 수락하고 주문 식별자를 포함하여 성공 또는 실패 정보를 반환하는 작업이 있을 수 있습니다. 주문 식별자를 수락하고 주문 상태 정보를 반환하는 작업이 있을 GetOrderStatus 수도 있습니다. 이러한 종류의 서비스 계약은 다음을 지정합니다.
구매 주문 계약은
CreateOrder및GetOrderStatus작업으로 구성됩니다.작업에서 입력 메시지 및 출력 메시지를 지정했음을 지정합니다.
이러한 메시지가 전달할 수 있는 데이터입니다.
메시지를 성공적으로 처리하는 데 필요한 통신 인프라에 대한 범주 문입니다. 예를 들어 이러한 세부 정보에는 성공적인 통신을 설정하는 데 필요한 보안 유형과 여부가 포함됩니다.
이러한 종류의 정보를 여러 플랫폼(타사 플랫폼 포함)의 다른 애플리케이션에 전달하기 위해 XML 서비스 계약은 WSDL( Web Services Description Language ) 및 XSD( XML 스키마 )와 같은 표준 XML 형식으로 공개적으로 표현됩니다. 많은 플랫폼의 개발자는 이 공용 계약 정보를 사용하여 사양의 언어를 이해하고 서비스가 지원하는 공용 양식, 형식 및 프로토콜을 설명하여 상호 운용을 사용하도록 설계되었기 때문에 서비스와 통신할 수 있는 애플리케이션을 만들 수 있습니다. WCF가 이러한 종류의 정보를 처리하는 방법에 대한 자세한 내용은 메타데이터를 참조하세요.
계약은 여러 가지 방법으로 표현할 수 있으며 WSDL 및 XSD는 접근성 있는 방식으로 서비스를 설명하는 데 뛰어난 언어이지만 직접 사용하기 어려운 언어이며 서비스 계약 구현이 아닌 서비스에 대한 설명일 뿐입니다. 따라서 WCF 애플리케이션은 관리되는 특성, 인터페이스 및 클래스를 모두 사용하여 서비스의 구조를 정의하고 구현합니다.
클라이언트 또는 다른 서비스 구현자가 필요한 경우 관리되는 형식에 정의된 결과 계약을 메타데이터(WSDL 및 XSD)로 내보낼 수 있습니다. 그 결과 클라이언트 애플리케이션에 대해 설명(공용 메타데이터 사용)할 수 있는 간단한 프로그래밍 모델이 생성됩니다. 기본 SOAP 메시지의 세부 정보, 운송 및 보안 관련 정보 등은 서비스 계약 유형 시스템과 XML 형식 시스템으로 자동으로 변환하는 데 필요한 변환을 수행하는 WCF에 남겨둘 수 있습니다.
계약 설계에 대한 자세한 내용은 서비스 계약 디자인을 참조하세요. 계약 구현에 대한 자세한 내용은 서비스 계약 구현을 참조하세요.
메시지 앞 및 가운데
RPC(원격 프로시저 호출) 스타일 메서드 시그니처에 사용되는 경우 관리되는 인터페이스, 클래스 및 메서드를 사용하여 서비스 작업을 모델링하는 것은 간단합니다. 이 경우 메서드에 매개 변수를 전달하고 반환 값을 받는 것은 개체 또는 다른 코드 형식의 기능을 요청하는 일반적인 형태입니다. 예를 들어 Visual Basic 및 C++ COM과 같은 관리되는 언어를 사용하는 프로그래머는 RPC 스타일 분산 개체 시스템에 내재된 문제를 경험하지 않고도 RPC 스타일 접근 방식(개체 또는 인터페이스 사용 여부)에 대한 지식을 WCF 서비스 계약 생성에 적용할 수 있습니다. 서비스 방향은 RPC 프로그래밍 환경의 용이성과 친숙함을 유지하면서 느슨하게 결합된 메시지 지향 프로그래밍의 이점을 제공합니다.
많은 프로그래머는 Microsoft MSMQ System.Messaging , .NET Framework의 네임스페이스 또는 HTTP 요청에서 구조화되지 않은 XML을 보내는 등의 메시지 지향 애플리케이션 프로그래밍 인터페이스에 더 익숙합니다. 메시지 수준의 프로그래밍에 대한 자세한 내용은 메시지 계약, 서비스 Channel-Level 프로그래밍 및 POX 애플리케이션과의 상호 운용성 사용을 참조하세요.
요구 사항 계층 구조 이해
서비스 계약은 작업을 그룹화합니다. 는 메시지 교환 패턴, 메시지 형식 및 해당 메시지가 전달하는 데이터 형식을 지정합니다. 및 구현이 계약을 지원해야 하는 런타임 동작의 범주를 나타냅니다(예: 메시지를 암호화하고 서명해야 할 수 있음). 서비스 계약 자체는 이러한 요구 사항을 충족하는 방법을 정확하게 지정하지 않고 반드시 충족해야 합니다. 암호화 유형 또는 메시지가 서명되는 방식은 규격 서비스의 구현 및 구성에 달려 있습니다.
계약에 동작을 추가하기 위해 서비스 계약 구현 및 런타임 구성의 특정 항목이 필요한 방식을 확인합니다. 서비스를 사용하도록 노출하기 위해 충족해야 하는 요구 사항 집합은 이전 요구 사항 집합을 기반으로 합니다. 계약이 구현 요구 사항을 충족하는 경우 구현에는 서비스를 실행할 수 있는 더 많은 구성 및 바인딩이 필요할 수 있습니다. 마지막으로 호스트 애플리케이션은 서비스 구성 및 바인딩이 추가하는 모든 요구 사항도 지원해야 합니다.
이 추가 요구 사항 프로세스는 WCF(Windows Communication Foundation) 서비스 애플리케이션을 디자인, 구현, 구성 및 호스팅하는 동안 유의해야 합니다. 예를 들어 계약은 세션을 지원하도록 지정할 수 있습니다. 그렇다면 해당 계약 요구 사항을 지원하도록 바인딩을 구성해야 합니다. 그렇지 않으면 서비스 구현이 작동하지 않습니다. 또는 서비스에 Windows 통합 인증이 필요하고 IIS(인터넷 정보 서비스)에서 호스트되는 경우 서비스가 있는 웹 애플리케이션에는 Windows 통합 인증이 켜져 있고 익명 지원이 꺼져 있어야 합니다. 다양한 서비스 호스트 애플리케이션 유형의 기능 및 영향에 대한 자세한 내용은 호스팅 서비스를 참조하세요.
참고하십시오
- 서비스 계약 설계
- 서비스 계약 구현