Craig McMurtry
Microsoft Corporation
2006 년 7 월
해당 제품:
Microsoft ASP.NET 2.0
Windows Communication Foundation
Internet Information Services (IIS)
웹 서비스 사양
목차
의사결정자의 시점
기술 비교: 목적
기술 비교: 표준
기술 비교: 개발
내부 아키텍처
WCF 도입 준비: 통합 간편화
WCF 도입 준비: 이행의 간편화
WCF 도입
요약
개요: 이 백서에서는 ASP.NET 웹 서비스를 Windows Communication Foundation (WCF)와
비교해, WCF 출시가 가까워지고 있는 현재, 기존 및 계획 중의 ASP.NET 웹 서비스를 어떻게 해야 할지 설명합니다.
ASP.NET 는 웹 서비스 구축용의 .NET Framework 클래스 라이브러리 및 도구를 제공 함과 동시에, 이러한
서비스를 Internet Information Services (IIS)로 호스팅하기 위한 기능을 제공합니다. Windows
Communication Foundation (이전의 코드네임Indigo, 이하 WCF)는 웹 서비스로 사용하는
프로토콜도 포함하고, 임의의 프로토콜에 의한 소프트웨어 엔터티간의 통신을 가능하게 하는 .NET 클래스 라이브러리, 도구 및 호스팅
기능을 제공합니다. 이와 같이 웹 서비스 구축을 위한 보다 새로운 목적의 기술이 출현하고 있는 지금 ASP.NET 웹 서비스는 어떠한 대응을 해야 할까요?
이 자료에서는 두가지 기술을 비교 하여, ASP.NET 웹 서비스 응용 프로그램을 WCF 응용 프로그램과 병용하는 방법을 설명합니다. 또, ASP.NET 웹 서비스의 WCF
마이그레이션 준비 방법 및 실제 적용 방법을 설명합니다.
이 자료에서는 ASP.NET 로 제공되는 웹 서비스 구축 기능을 Web Services Enhancements for
Microsoft .NET (WSE)과는 다른 것이라 봅니다. WSE 로 개발한 응용 프로그램은 다른 자료에서
검증합니다.
의사결정자 시점
2006 년 후반에 출시가 예정되어 있는 WCF 에는 ASP.NET 웹 서비스와 비교해 중요한 이점이
있습니다. 기존의
기술을 이용하는 모든 기업들이 이러한 이점을에 대해 검토할 필요가 있습니다.
ASP.NET 웹 서비스의 도구는 웹 서비스 구축만을 목적으로 하는데 반해, WCF 에서는 소프트웨어 엔터티를 서로
통신할 필요가 있는 모든 상황에서 사용하는 도구가 제공됩니다. 따라서, 개발자가 다양한 소프트웨어 통신 시나리오
적용시 알아야 기술의 종류가 줄어듭니다. 결과적으로 소프트웨어개발 리소스 비용을 절약하여, 소프트웨어개발 프로젝트의 소요 시간을 단축할
수 있습니다.
웹 서비스 개발 프로젝트에서 WCF 는 ASP.NET 웹 서비스보다 많은 웹 서비스 프로토콜을
지원합니다. 이러한 프로토콜은 신뢰성이 높은 세션이나 트랜잭션으로 보다 향상된 솔루션을 실현합니다.
WCF 는 ASP.NET 웹 서비스보다 많은 메시지 전송 프로토콜을 지원합니다. ASP.NET 웹 서비스에서는
Hypertext Transfer Protocol (HTTP)에 의한 메시지 송신만 지원됩니다. 한편 WCF 는 HTTP
로의 메시지 송신 뿐만이 아니라, Transmission Control Protocol (TCP), 명명된 파이프 및 Microsoft
Message Queuing (MSMQ) 메시지 송신도 가능합니다. 더 중요한 점은, WCF에서는 전송 프로토콜 지원을 쉽게 확장할 수 있습니다. 따라서, WCF 로 개발한 소프트웨어는
다른 다양한 소프트웨어와 연결되어 쉽게 변경할 수 있습니다. 결과적으로 WCF 투자 대비 결과를 빠른 시간내에 가시적 가능성을 볼 수 있습니다.
WCF 에는 응용 프로그램을 배포하고 관리하기 위한 기능이 ASP.NET 웹 서비스보다 훨씬 다양합니다.
ASP.NET 에서 제공되는 구성 시스템에 추가하여, WCF 에서는 구성 편집기, 임의의 수의 중간 노드를 경유하는
송신측에서
수신측까지의 액티비티 트레이스, 트레이스 뷰어, 메시지 로그, 각종의 성능 카운터 및 Windows Management
Instrumentation 지원이 제공되었습니다. 이러한 풍부한 관리 툴의 집합으로 운용 비용 삭감, 장해
위험 감소, 실제 다운 타임 단축이 가능해집니다.
이상과 같이 WCF 는 ASP.NET 웹 서비스와 비교하여 유리하고 ASP.NET 웹 서비스를 현재
사용하거나 또는 사용을 검토하고 있는 기업에 몇 가지 선택사항이 있습니다.
- 기존 ASP.NET 웹 서비스를 계속 사용하며 WCF에서 제공되는 이점에 활용할 수 있습니다. Microsoft의 현재의 지원 수명 주기 정책에서는 ASP.NET 웹 서비스의 메인 스트림 지원은 적어도 2011 년까지 지속되며, 연장 지원은 적어도 2016 까지 제공될 예정입니다. 따라서, ASP.NET 웹 서비스를 사용해 계속해도 문제는 없습니다.
- 장래 언젠가는 WCF 를 도입하는 것을 전제로, ASP.NET 웹 서비스를 계속 사용한다. 이 자료에서는 새로운
ASP.NET 웹 서비스 응용 프로그램을 향후의 WCF 응용 프로그램과 병용 할 수 있을 가능성을 최대한으로 하는 방법에 대해
설명합니다. 또, 새로운 ASP.NET 웹 서비스를 WCF 로 이행하기 쉬운 형태로 구축하는 방법에 대해도 설명합니다. 다만,
서비스의 보호가 중요한 경우 신뢰성이나 트랜잭션의 보장이 요청 되는 경우 또는 사용자 지정관리 기능을 구축할 필요가 있는 경우에는 WCF 도입을 재고한는 것은 잘못된 판단일지도 모릅니다. WCF 는 확실히 그러한 시나리오를 설계목표로
하고, 이 기술의 프로덕션 라이선스는 이미 취득 가능합니다.
- 신규의 개발 작업에는 WCF 를 채용하면서, 기존의 ASP.NET 웹 서비스 응용 프로그램의 유지 관리를 속행한다. 이
선택사항이 아마 최적이겠지요. 이 경우 WCF 이점을 활용하는 것과 동시에, 기존의 응용 프로그램으로 WCF 를 사용하기
위해서 필요한 변경의 비용을 절약할 수 있습니다. 이 시나리오에서는 새로운 WCF 응용 프로그램을 기존의 ASP.NET 응용
프로그램과 공존시키는 것이 가능합니다. 또 WCF 응용 프로그램으로 기존의 ASP.NET 웹 서비스를 사용할 수 있어 한층 더
WCF 의 ASP.NET 상호교환모드를 이용하고, 기존의 ASP.NET 응용 프로그램의 새로운 운용 기능을 WCF 로 프로그래밍
하는 것도 가능합니다.
- WCF 를 도입해, 기존의 ASP.NET 웹 서비스 응용 프로그램을 WCF로 마이그레이션한 기업은 개발자가
ASP.NET 웹 서비스를 몰라도 끝날 수 있는 목적으로 이 선택사항을 선택하는 경우가 생각할 수 있습니다.
다만, 최신 기술 이외의 기술 지원을 배제할 수 있다는 전망은 비현실적이어서, 이 선택사항을 선택하는 이유로서
적절하지는 않습니다. 마이그레이션 이유로서
가장 적절한 것은 WCF에서 제공되는 기능에 기존의 응용 프로그램의 기능을
강화한다는 목적 또는 새롭고 보다 강력한 WCF 응용 프로그램으로 기존의 ASP.NET 웹 서비스기능을 재현한다는
목적입니다. 이 자료에서는 이행 실현 방법에 대해 설명합니다.
기술 비교: 목적
ASP.NET 웹 서비스 기술은 HTTP 상의 Simple Object Access Protocol (SOAP)를 사용해
메시지를 송수신하는 응용 프로그램을 구축하기 위해서 개발되었습니다. 메시지의 구조는 XML 스키마를 사용해 정의할 수 있어.NET
개체와 교환하는 메시지의 직렬화(Serialization)를 쉽게 하는 도구가 제공됩니다. 이 기술에서는 웹 서비스를 기술하는 메타데이터를 Web
Services Description Language (WSDL)로 자동생성 할 수 있어 WSDL 에서 웹 서비스의 클라이언트를 생성하기
위한 두번째의 도구가 제공됩니다.
WCF는 .NET 응용 프로그램이 다른 소프트웨어 엔터티와 메시지를 교환하는 것을 목적으로 합니다.
기본값에서는 SOAP 가 사용되지만, 메시지는 임의의 형식으로 임의의 전송 프로토콜로 전송할 수 있습니다. 메시지의 구조는
XML 스키마로 정의할 수 있어 .NET 개체와 교환하는 메시지를 직렬화(Serialization)하기 위한 각종 옵션이 있습니다. WSDL 의 기술을 사용해
구축한 응용 프로그램을 기술하는 메타데이터를 WCF 로 자동생성하여 WSDL에서 이러한 응용 프로그램의 클라이언트를 생성하기 위한 도구도
제공됩니다.
기술 비교: 표준
ASP.NET 웹 서비스지원 표준의 일람은 ASP.NET
를 사용해 작성한 XML 웹 서비스 (영어)를 참조해 주세요.
WCF 에서는 보다 많은 표준이 지원 되었습니다. 이것은 WCF
지원 웹 서비스 프로토콜 (영어)로 확인할 수 있습니다.
기술 비교: 개발
ASP.NET 상호교환모드
WCF 에는 ASP.NET 상호교환모드로 어떤 종류의 WCF 응용 프로그램을 ASP.NET 웹 서비스와 같이 프로그래밍
및 구성해, ASP.NET 웹 서비스의 동작을 모방할 수 있습니다. ASP.NET 상호교환모드를 선택하는 방법과 이 옵션의 실제
작용에 대해 자세하게 설명합니다.
데이터 표기
일반적으로 ASP.NET 웹 서비스 개발 작업은 그 서비스로 사용하는 복잡한 데이터 유형을 정의하는 일에서
시작됩니다. ASP.NET 에서는 System.Xml.Serialization.XmlSerializer 에 의존하고, .NET
개체로 표기된 데이터를 XML 로 변환해 서비스 사이에 교환하거나 XML 수신 데이터를 .NET 개체로 변환합니다.
따라서, ASP.NET 서비스로 사용하는 복잡한 데이터 유형을 정의하려면, System.Xml.Serialization.XmlSerializer 가 XML 사이에
직렬화(Serialization)할 수 있는 .NET 클래스 정의가
필요합니다. 이러한 클래스는 수동으로 작성할 수도 있지만, 명령줄
방식의 XML 스키마/데이터 유형 지원 유틸리티인
xsd.exe 를 사용하고, XML 스키마 안의 형식 정의에서 생성할 수도 있습니다.
System.Xml.Serialization.XmlSerializer 가 XML 직렬화(Serialization)할 수 있는 .NET
클래스 정의에서 중요 사항은 다음과 같습니다.
- XML 에 변환되는 것은.NET 개체의 퍼블릭 필드 및 속성 뿐입니다.
- 집합 클래스의 인스턴스를 XML 에 직렬화(Serialization)가능한 것은 클래스가 IEnumerable 또는 ICollection
인터페이스를 구현하는 경우에 한정됩니다.
- 필연적으로 System.Collections.IDictionary 인터페이스를 구현 하고 있는 클래스는
System.Collections.Hashtable 와 같이 XML 에 직렬화(Serialization)할 수 없습니다.
- System.Xml.Serialization 네임 스페이스안에 많은 특성 유형을 .NET 클래스 및 그 멤버에게
추가하고, XML 클래스의 인스턴스 표현 방법을 정확하게 제어할 수 있습니다.
WCF 응용 프로그램의 개발도 복잡한 형식의 정의에서 시작되는 것이 일반적입니다. WCF 에서도 ASP.NET 웹 서비스와
같은 .NET 형 사용이 가능합니다. 다만, 뛰어난 대체 수단이 있습니다.
WCF의 System.Runtime.Serialization 어셈블리의 System.Runtime.Serialization.DataContract
및System.Runtime.Serialization.DataMember 특성을 .NET 형에 추가하여, 그 형식의
인스턴스가 XML 에 직렬화(Serialization) 되는 것을 나타냄과 동시에, 직렬화(Serialization) 대상이 되는 특정의 필드 또는 속성을 지정할 수 있습니다. 다음에
나타내는 세가지 예는 모두 유효합니다.
//Example One:
[DataContract]
public class LineItem
{
[DataMember]
public string ItemNumber;
[DataMember]
public decimal Quantity;
[DataMember]
public decimal UnitPrice;
}
//Example Two:
public class LineItem
{
[DataMember]
private string itemNumber;
[DataMember]
private decimal quantity;
[DataMember]
private decimal unitPrice;
public string ItemNumber
{
get
{
return this.itemNumber;
}
set
{
this.itemNumber = value;
}
}
public decimal Quantity
{
get
{
return this.quantity;
}
set
{
this.quantity = value;
}
}
public decimal UnitPrice
{
get
{
return this.unitPrice;
}
set
{
this.unitPrice = value;
}
}
}
//Example Three:
public class LineItem
{
private string itemNumber;
private decimal quantity;
private decimal unitPrice;
[DataMember]
public string ItemNumber
{
get
{
return this.itemNumber;
}
set
{
this.itemNumber = value;
}
}
[DataMember]
public decimal Quantity
{
get
{
return this.quantity;
}
set
{
this.quantity = value;
}
}
[DataMember]
public decimal UnitPrice
{
get
{
return this.unitPrice;
}
set
{
this.unitPrice = value;
}
}
}
System.Runtime.Serialization.DataContract 특성은 형식의 0 개 이상의 필드 또는
속성을 직렬화(Serialization)하는 것을 나타내는데, System.Runtime.Serialization.DataMember 특성은
특정의 필드 또는 속성을 직렬화(Serialization)하는 것을 나타냅니다. System.Runtime.Serialization.DataContract
특성은 클래스 또는 구조에 적용할 수 있습니다. System.Runtime.Serialization.DataMember
특성은 필드 또는 속성에 적용할 수 있습니다. 이 특성을 적용하는 필드 및 속성은 퍼블릭이든 프라이빗이든 관계없습니다. System.Runtime.Serialization.DataContract
특성을 가지는 형식 인스턴스를 WCF 용어로데이터 계약이라고 합니다. 이것들은 WCF 의 System.Runtime.Serialization.DataContractFormatter
를 사용해 XML 에 직렬화(Serialization) 됩니다.
System.Runtime.Serialization.DataContractFormatter,System.Runtime.Serialization.DataContract
및System.Runtime.Serialization.DataMember 특성은
System.Xml.Serialization.XmlSerializer 및 System.Xml.Serialization 네임 스페이스의
각종 특성과 많은 중요한 차이점이 있습니다.
- System.Xml.Serialization.XmlSerializer 및 System.Xml.Serialization 네임
스페이스의 특성은 .NET 형을 XML 스키마로 정의된 유효한 형식에 매핑을 목적으로 설계되었습니다. 따라서XML로의 .NET 형의 표현 방법을 매우 정확하게 제어할 수 있습니다. System.Runtime.Serialization.DataContractFormatter, System.Runtime.Serialization.DataContract
및System.Runtime.Serialization.DataMember 특성에서는 XML 의 .NET
형의 표현 방법은 거의 제어할 수 없습니다. 지정할 수 있는 것은 형식과 그 필드 또는 속성을 표현하기 위해 XML
로 사용하는 네임 스페이스와 이름 및 XML의 각 필드와 속성의 순서 뿐입니다.
[DataContract(
Namespace="urn:Woodgrove:2006:January:29",
Name="LineItem")]
public class LineItem
{
[DataMember(Name="ItemNumber",IsRequired=true,Order=0)]
public string itemNumber;
[DataMember(Name="Quantity",IsRequired=false,Order = 1)]
public decimal quantity;
[DataMember(Name="Price",IsRequired=false,Order = 2)]
public decimal unitPrice;
}
.NET 형의 표현에 사용하는 XML 구조에 대해, 이외의 사항은 모두 System.Runtime.Serialization.DataContractFormatter
로 결정됩니다.
- XML 로의 .NET 형 표현 방법을 거의 제어할 수 없기 때문에, 직렬화(Serialization) 순서가System.Runtime.Serialization.DataContractFormatter
에서 매우 예측하기 쉬운 것이 되어, 결과적으로 최적화하기 쉬운 것이 되어 있습니다. 따라서 System.Runtime.Serialization.DataContractFormatter 설계에 의한 실용상의 이점은 성능 향상이며, 약 10% 높은 성능이 얻을 수 있습니다.
- 예를 들어 다음의 형식에서는 System.Xml.Serialization.XmlSerializer 에 의한
직렬화(Serialization)의
특성을 지정했습니다.
[Serializable]
[XmlRoot(Namespace="urn:Woodgrove:2006:January:29")]
public class LineItem
{
public string ItemNumber;
public decimal Quantity;
public decimal UnitPrice;
}
한편, 다음 버전에서는 System.Runtime.Serialization.DataContractFormatter
에서 사용하는 특성을 지정했습니다.
[DataContract(Namespace="urn:Woodgrove:2006:January:29")]
public class LineItem
{
[DataMember]
public string ItemNumber;
[DataMember]
public decimal Quantity;
[DataMember]
public decimal UnitPrice;
}
System.Xml.Serialization.XmlSerializer 로 사용하는 특성에서는 형식 필드 또는 속성을
XML 에 직렬화(Serialization)를 지정하지 않았습니다. 한편, System.Runtime.Serialization.DataContractFormatter
에 사용하는System.Runtime.Serialization.DataMember 특성에서는
직렬화(Serialization)하는 필드 또는
속성을 명시적으로 지정합니다. 따라서, 데이터 계약은 응용 프로그램이 송수신하는 데이터 구조에 관한 명시적인
규약입니다.
- System.Xml.Serialization.XmlSerializer 에서는 .NET 개체의 퍼블릭 멤버만 XML 로
변환할 수 있는데, System.Runtime.Serialization.DataContractFormatter
는 멤버의 접근 수식자에 관계없이 .NET 개체 멤버를 XML로 변환할 수 있습니다.
- 형식의 비퍼블릭 멤버를 XML 에 직렬화(Serialization) 가능한 결과에서도 있지만, System.Runtime.Serialization.DataContractFormatter
에서 XML 에 직렬화(Serialization)할 수 있는 .NET 형의 종류에 관한 제한이 적습니다. 구체적으로는 Systems.Collections.IDictionary
인터페이스를 구현하는 System.Collections.Hashtable 와 같은 형식이 XML 에 변환 가능합니다. 일반적으로
기존의 .NET 형의 인스턴스를 형식 정의를 수정하거나 래퍼를 작성하지 않아도 System.Runtime.Serialization.DataContractFormatter
에서 XML 에 직렬화(Serialization)할 수 있을 가능성이 높습니다.
- 다만 System.Runtime.Serialization.DataContractFormatter 에서는 형식
비퍼블릭 멤버에게 접근 가능한 것의 하나의 결과로서, System.Xml.Serialization.XmlSerializer 과는 달리,완전한 신뢰가 필요합니다.
- System.Runtime.Serialization.DataContractFormatter 에는 어느
정도까지의 버전 관리가 지원됩니다.
- System.Runtime.Serialization.DataMember 특성에는 IsRequired
속성이 있습니다. 데이터 계약의 구버전에는 존재하지 않았던 멤버를 신버전에 추가하는 경우 그 멤버에
대해서 이 속성에 false 값을 할당하여 계약의 신버전을 사용하는 응용 프로그램으로 구버전을 처리
가능하게 할 수 있습니다.
- 데이터 계약에 단순한 System.Runtime.Serialization.IExtensibleDataObject
인터페이스를 구현 하여, 신버전의 데이터 계약으로 정의한 멤버를 System.Runtime.Serialization.DataContractFormatter
로 구버전의 계약을 사용하는 응용 프로그램에 건네줄 수 있습니다.
이상과 같은 상위가 있다고는 해도 XML 의 네임 스페이스가 명시적으로 정의 된 경우 System.Xml.Serialization.XmlSerializer 가 기본값으로 형식을 직렬화(Serialization)하는 XML은 System.RuntimeSerialization.DataContractFormatter
가 형식을 직렬화(Serialization)하는 XML 와 의미는 같습니다. 따라서, 다음의 클래스는 양쪽 모두의 직렬변환기로 사용되는 특성
있어, System.Xml.Serialization.XmlSerializer 에서도 System.RuntimeSerialization.DataContractFormatter
가 의미적으로 같은 XML 에 변환됩니다.
[Serializable]
[XmlRoot(Namespace="urn:Woodgrove:2006:January:29")]
[DataContract(Namespace="urn:Woodgrove:2006:January:29")]
public class LineItem
{
[DataMember]
public string ItemNumber;
[DataMember]
public decimal Quantity;
[DataMember]
public decimal UnitPrice;
}
WCF 에 부속의 소프트웨어개발 킷에는 서비스 모델 메타데이터 도구로 불리는 명령줄 도구, svcutil.exe 가 포함되어
있습니다. ASP.NET 웹 서비스로 사용하는 xsd.exe 도구와 같이 svcutil.exe 는 XML 스키마 에서 .NET 데이터
유형의 정의를 생성할 수 있습니다. 이러한 .NET 데이터 유형은 System.Runtime.Serialization.DataContractFormatter
가 XML 스키마로 정의되는 형식의 XML 을 생성할 수 있는 경우에는 데이터 계약이 됩니다. 그렇지 않은
경우에는 System.Xml.Serialization.XmlSerializer 를 사용해 직렬화(Serialization)하는 것이
의도되었습니다.
svcutil.exe 도구에서는 /dataContractOnly 스위치를 사용해 데이터 계약에서 XML 스키마를 생성하는 것도
가능합니다.
ASP.NET 웹 서비스가 System.Xml.Serialization.XmlSerializer 를 사용하고,
WCF 의 ASP.NET 상호교환모드에서는 WCF 서비스가 ASP.NET 웹 서비스 동작을 모방한다 해도 ASP.NET 호환
옵션으로 반드시 System.Xml.Serialization.XmlSerializer 를 사용해야 하는 것은 아닙니다. 이 경우에도
ASP.NET 상호교환모드로 동작하는 서비스에 System.Runtime.Serialization.DataContractFormatter
를 사용할 수 있습니다.
서비스 개발
ASP.NET 로 서비스를 개발하는 경우 단순하게 클래스에 System.Web.Services.WebService
특성을 추가해, 그 클래스의 메서드 서비스의 동작이 되는 메서드에 System.Web.Services.WebMethod
특성을 추가하는 것이 관례가 되고 있습니다.
[WebService]
public class Service : System.Web.Services.WebService
{
[WebMethod]
public string Echo(string input)
{
return input;
}
}
ASP.NET 2.0 에서는 클래스는 아닌 인터페이스에 System.Web.Services.WebService 및 System.Web.Services.WebMethod
특성을 추가해, 그 인터페이스를 구현하는 클래스를 기술하는 옵션이 도입되었습니다.
[WebService]
public interface IEcho
{
[WebMethod]
string Echo(string input);
}
public class Service : IEcho
{
public string Echo(string input)
{
return input;
}
}
이 옵션을 사용하는 것이 바람직한 이유는 System.Web.Services.WebService 특성을 가지는
인터페이스로 구성된 서비스 동작 계약은 다양한 클래스로 재사용 가능하고, 같은 계약을 다른 방법으로 구현 할 수 있기
때문입니다.
WCF 서비스는 1 이상의 WCF 끝점(endpoint)를 정의해서 제공합니다. 끝점(endpoint)는 주소, 바인딩 및 서비스
계약에 의해서 정의합니다. 주소는 서비스의 존재하는 장소를 정의합니다. 바인딩은 서비스와의 통신
방법을 지정합니다. 서비스 계약은 서비스를 실행할 수 있는 동작을 정의합니다.
일반적으로 최초로 서비스 계약을 정의합니다. .NET 인터페이스에 System.ServiceModel.ServiceContract
및System.ServiceModel.OperationContract 특성을 추가해서 정의합니다.
[ServiceContract]
public interface IEcho
{
[OperationContract]
string Echo(string input);
}
System.ServiceModel.ServiceContract 특성은 그 인터페이스가 WCF 서비스 계약을 정의하는
것인 것을 지정합니다. System.ServiceModel.OperationContract
특성은 그 인터페이스의 메서드의 쳐 서비스 계약의 동작을 정의하는 메서드 (있는 경우)를 지정합니다.
서비스 계약을 정의한 후, 그 서비스 계약을 클래스에 구현 합니다. 단순하게, 서비스 계약을 정의한 인터페이스를 클래스로 구현
합니다.
public class Service : IEcho
{
public string Echo(string input)
{
return input;
}
}
서비스 계약을 구현하는 클래스를 WCF 용어로 서비스타입 이라고 합니다.
다음의 스텝은 서비스타입에 주소와 바인딩을 관련짓는 것입니다. 이것은 일반적으로 구성 파일로 실시합니다. 파일을 직접 편집할
수도 있고, WCF 로 제공되는 구성 편집기를 사용할 수도 있습니다. 다음은 구성 파일의 예를 보여줍니다.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<services>
<service name="Service ">
<endpoint
address="EchoService"
binding="basicHttpBinding"
contract="IEchoService "/>
</service>
</services>
</system.serviceModel>
</configuration>
바인딩은 응용 프로그램과 통신하기 위한 프로토콜 집합을 지정합니다. 일반적인 옵션을 나타낸다, 미리 정의된 바인딩이 몇가지
있습니다.
| 이름 |
목적 |
| BasicHttpBinding |
WS-BasicProfile 1.1 및 Basic Security
Profile 1.0 을 지원 하는 웹 서비스 및 클라이언트와의 상호 운용성 |
| WSHttpBinding |
HTTP 상의 WS-* 프로토콜을 지원 하는 웹 서비스 및
클라이언트와의 상호 운용성 |
| WSDualHttpBinding |
이중화 HTTP 통신 (최초의 메시지의 수신 옆이 최초의 송신 측에
직접 응답하는 것이 아니라, WS-* 프로토콜에 준거해 HTTP 상에서 일정기간에 걸쳐 몇회의 응답을 송신) |
| WSFederationBinding |
HTTP 통신 (명시적으로 식별되는 자격 정보 공급자가 발행하는 자격
정보에 근거하고, 서비스의 리소스에의 접근을 제어 가능) |
| NetTcpBinding |
네트워크에서 WCF 소프트웨어 엔터티간의 안전하고 신뢰성이
높은 고성능통신 |
| NetNamedPipeBinding |
같은 컴퓨터 위의 WCF 소프트웨어 엔터티간의 안전하고
신뢰성이 높은 고성능통신 |
| NetMsmqBinding |
MSMQ 에 의한 WCF 소프트웨어 엔터티간의 통신 |
| MsmqIntegrationBinding |
MSMQ 에 의한 WCF 소프트웨어 엔터티와 다른 소프트웨어 엔터티간의
통신 |
| NetPeerTcpBinding |
Windows Peer-to-Peer Networking 에 의한
WCF 소프트웨어 엔터티간의 통신 |
정의된 바인딩인 System.ServiceModel.BasicHttpBinding 에는 ASP.NET 웹 서비스지원
프로토콜 집합이 있습니다.
WCF 응용 프로그램 용무의 사용자 지정 바인딩은 WCF 가 개개의 프로토콜을 구현하기 위해서 사용하는 바인딩 요소 클래스의
집합으로서 쉽게 정의할 수 있습니다. 새로운 프로토콜을 나타내는 새로운 바인딩 요소를 작성할 수 있습니다.
서비스타입의 내부 동작은 동작(Behavior) 으로 불리는 클래스의 패밀리의 속성을 사용해 조정할 수 있습니다.
다음의 예에서는 System.ServiceModel.ServiceBehavior 클래스를 사용하고, 서비스타입을
multi-thread 화를 지정했습니다.
[ServiceBehavior(ConcurrencyMode=ConcurrencyMode.Multiple]
public class DerivativesCalculatorServiceType: IDerivativesCalculator
System.ServiceModel.ServiceBehavior 과 같이 프로그래머가 설정 한다고 생각할 수
있는 속성을 가지는 일부의 동작(Behavior) 특성입니다. 관리자가 설정 한다고 생각할 수 있는 속성을 가지는 그 외의
동작(Behavior)는 응용 프로그램의 구성으로 변경할 수 있습니다.
서비스타입의 프로그래밍에서는 System.ServiceModel.OperationContext 클래스가 빈번히 사용됩니다. 이
클래스의 정적인 Current 속성은 동작을 실행하는 문맥에 관한 정보 접근을 제공합니다. 따라서, System.ServiceModel.OperationContext는 System.Web.HttpContext 및
System.EnterpriseServices.ContextUtil 클래스의 양쪽 모두와 같습니다.
호스팅
ASP.NET 웹 서비스는 클래스 라이브러리 어셈블리에 컴파일 됩니다. 확장자(extension).asmx 의서비스파일로
불리는 파일이 제공됩니다. 이 파일에는 서비스의 코드를 포함한 클래스와 그것이 존재하는 어셈블리를 식별하는 @ WebService
지시문이 들어가 있습니다.
<%@ WebService Language="C#" Class="Service,ServiceAssembly" %>
서비스파일이 IIS 의 ASP.NET 응용 프로그램 루트에 복사되어 어셈블리가 그 응용 프로그램 루트의 \bin 서브 디렉토리에
복사됩니다. 이 시점에서 응용 프로그램 루트내의 서비스파일의 URL 를 사용해 응용 프로그램이 접근 가능하게 됩니다.
.NET Framework 2.0 으로 제공된 HttpListener 클래스를 사용하고, IIS 의 외부의 임의의
.NET 응용 프로그램으로 ASP.NET 웹 서비스를 호스팅하는 방법에 대해 ,Aaron
Skonnard (영어) 해설하고 있지만, Skonnard 자신이 말하듯이
상당한 노력이 필요합니다. (영어)
WCF 서비스는 IIS 5.1 또는 6.0, IIS 7 의 일부분으로서 제공되는 Windows Activation Service
(WAS) 및 임의의 .NET 응용 프로그램으로 쉽게 호스팅 할 수 있습니다. IIS 5.1 또는 6.0 으로 서비스를 호스팅 하려면,
그 서비스가 통신 전송 프로토콜로서 HTTP 를 사용하고 있을 필요가 있습니다.
IIS 5.1, 6.0 또는 WAS 로 서비스를 호스팅하는 순서는 다음과 같습니다.
- 서비스타입을 클래스 라이브러리 어셈블리에 컴파일 합니다.
- 서비스파일을 작성합니다. .svc 확장자(extension)를 사용해, @ ServiceHost 지시문으로
서비스타입을 식별합니다.
<%@ServiceHost language="c#" Service="MyService" %>
- 서비스파일을 가상 디렉터리에 복사해, 가상 디렉터리의 \bin 서브 디렉토리에 어셈블리를 복사합니다.
- 구성 파일을 가상 디렉터리에 복사해, 이름을 Web.config 로 합니다.
이 시점에서 응용 프로그램 루트내의 서비스파일의 URL 을 사용해 응용 프로그램이 접근 가능하게 됩니다.
.NET 응용 프로그램으로 WCF 서비스를 호스팅 하려면, 서비스타입을 응용 프로그램으로 참조하는 클래스 라이브러리 어셈블리에
컴파일 해, WCF 의System.ServiceModel.ServiceHost 클래스를 사용해 그 서비스를 호스팅
하도록, 응용 프로그램을 프로그래밍 합니다. 다음은 간단한 프로그래밍 예입니다.
string httpBaseAddress = "http://www.woodgrove.com:8000/";
string tcpBaseAddress = "net.tcp://www.woodgrove.com:8080/";
Uri httpBaseAddressUri = new Uri(httpBaseAddress);
Uri tcpBaseAddressUri = new Uri(tcpBaseAddress);
Uri[] baseAdresses = new Uri[] {
httpBaseAddressUri,
tcpBaseAddressUri};
using(ServiceHost host = new ServiceHost(
typeof(Service), //"Service" is the name of the service type baseAdresses))
{
host.Open();
[...] //Wait to receive messages
host.Close();
}
이 예 에서 WCF 의 System.ServiceModel.ServiceHost 를 구축할 때에, 전송 프로토콜의 주소를
어떻게 지정할지를 알 수 있습니다. 이러한 주소를기반 주소라고 합니다.
WCF 서비스의 끝점(endpoint)에 제공하는 주소는 그 끝점(endpoint)의 호스트의 기반 주소에 대립되는
주소입니다. 호스트는 통신 전송 프로토콜 마다 한가지의 기반 주소를 사용할 수 있습니다. 끝점(endpoint) 주소는
호스트의 몇개의 기반 주소로 그 끝점(endpoint)의 통신 전송 프로토콜의 기반 주소인 것에 대립됩니다. 앞서 구성 파일의 예에서는
끝점(endpoint)용으로 선택된 System.ServiceModel.BasicHttpBinding 은
전송 프로토콜로서 HTTP 를 사용하므로, 끝점(endpoint) EchoService 주소는 호스트의 HTTP 기반 주소에
대립됩니다. 앞서 예의 호스트의 경우 HTTP 기반 주소는 http://www.woodgrove.com:8000/
입니다. IIS 또는 WAS 로 서비스를 호스팅하는 경우 기반 주소는 그 서비스의 서비스파일 URL 입니다.
WCF 의 ASP.NET 상호교환모드 옵션을 사용할 수 있는 것은 IIS 또는 WAS 로 호스팅 되어 전송 프로토콜로서 HTTP
만으로 구성된 서비스에 한정됩니다. 이 옵션을 온으로 설정하려면, 다음의 두개의 스텝이 필요합니다.
- 프로그래머가System.ServiceModel.AspNetCompatbilityRequirements 특성을
서비스타입에 추가해, ASP.NET 상호교환모드를 허가 하는지, 이 모드가 필수인 것을 지정할 필요가 있습니다.
[System.ServiceModel.AspNetCompatibilityRequirements(
RequirementsMode=AspNetCompatbilityRequirementsMode.Require)]
public class DerivativesCalculatorServiceType: IDerivativesCalculator
- 관리자가 ASP.NET 상호교환모드를 사용하도록 응용 프로그램을 구성할 필요가 있습니다.
<configuration>
<system.serviceModel>
<services>
[...]
</services>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
</system.serviceModel>
</configuration>
WCF 응용 프로그램은 서비스파일의 확장자(extension)로서.svc는 아닌 .asmx
를 사용하도록 구성하는 것도 가능합니다.
<system.web>
<compilation>
<compilation debug="true">
<buildProviders>
<remove extension=".asmx"/>
<add extension=".asmx"
type="System.ServiceModel.ServiceBuildProvider,
Systemm.ServiceModel,
Version=3.0.0.0,
Culture=neutral,
PublicKeyToken=b77a5c561934e089" />
</buildProviders>
</compilation>
</compilation>
</system.web>
이 옵션을 사용하면, WCF 를 사용하도록 서비스를 변경하는 경우 .asmx 서비스파일의 URL 를 사용하도록 구성된 클라이언트를 변경하는
노력를 줄일 수 있습니다.
클라이언트의 개발
ASP.NET 웹 서비스 클라이언트를 생성하려면, 명령줄 도구 wsdl.exe 를 사용해,.asmx 파일의 URL 를 제공합니다. WCF
에서 여기에 상당하는 도구가 svcutil.exe 입니다. 이 도구는 서비스 계약의
정의와 프록시 클래스 정의가 들어간 코드 모듈을 생성합니다. 또, 서비스의 주소 및 바인딩이 들어간 구성 파일도 생성합니다.
리모트 서비스의 클라이언트의 프로그래밍에서는 일반적으로 비동기 패턴에 따라 프로그래밍하는 것을 추천 합니다. wsdl.exe
도구로 생성되는 코드는 항상, 동기 및 비동기 패턴의 양쪽 모두에 기본값으로 대응합니다. svcutil.exe 도구로 생성되는 코드는
어느 쪽인지 한편의 패턴에 대응할 수 있어 기본값에서는 동기 패턴에 대응합니다. 이 도구를 /async 스위치 첨부로 실행하면, 비동기
패턴에 대응하는 코드가 생성됩니다.
ASP.NET의 wsdl.exe 도구로 생성되는 프록시 클래스 안의 기본값의 이름이 WCF 의 svcutil.exe 도구로
생성되는 프록시 클래스 안의 이름과 일치한다고 하는 보장은 없습니다. 특히,
System.Xml.Serialization.XmlSerializer 를 사용해 직렬화(Serialization)할 필요가 있는 클래스의 속성 이름은
svcutil.exe 도구로 생성되는 코드에서는 기본값으로 사픽스Property 가 붙일 수 있지만, wsdl.exe
도구의 경우 그렇지는 않습니다.
메시지의 표기
ASP.NET 웹 서비스에 의해서 송수신하는 SOAP 메시지의 헤더는 사용자 지정 가능합니다. System.Web.Services.Protocols
에서 파생한 클래스의 헤더 구조를 정의해, System.Web.Services.SoapHeader 특성을 사용해
헤더의 존재를 지정합니다.
public class SomeProtocol : SoapHeader
{
public long CurrentValue;
public long Total;
}
[WebService]
public interface IEcho
{
SomeProtocol ProtocolHeader
{
get;
set;
}
[WebMethod]
[SoapHeader("ProtocolHeader")]
string PlaceOrders(PurchaseOrderType order);
}
public class Service: WebService, IEcho
{
private SomeProtocol protocolHeader;
public SomeProtocol ProtocolHeader
{
get
{
return this.protocolHeader;
}
set
{
this.protocolHeader = value;
}
}
string PlaceOrders(PurchaseOrderType order)
{
long currentValue = this.protocolHeader.CurrentValue;
}
}
WCF 에서는 서비스로 교환하는 SOAP 메시지 구조를 기술하기 위해, 특성System.ServiceModel.MessageContract,System.ServiceModel.MessageHeader
및 System.ServiceModel.MessageBody 가 제공되었습니다.
[DataContract]
public class SomeProtocol
{
[DataMember]
public long CurrentValue;
[DataMember]
public long Total;
}
[DataContract]
public class Item
{
[DataMember]
public string ItemNumber;
[DataMember]
public decimal Quantity;
[DataMember]
public decimal UnitPrice;
}
[MessageContract]
public class ItemMesage
{
[MessageHeader]
public SomeProtocol ProtocolHeader;
[MessageBody]
public Item Content;
}
[ServiceContract]
public interface IItemService
{
[OperationContract]
public void DeliverItem(ItemMessage itemMessage);
}
이 구문은 메시지 구조를 명시적으로 표기합니다. 한편, ASP.NET 웹 서비스의 코드에서는 메시지의 구조는 암시적으로
나타나지는 않습니다. 또, ASP.NET의 구문에서는 메시지 헤더는 서비스의 속성 (앞의 예와 같이 ProtocolHeader
속성 등)으로 표기하는데 대해, WCF 구문에서는 헤더를 메시지의 속성으로서 정확하게 표기합니다. 또한 WCF 에서는
끝점(endpoint) 구성에 메시지 헤더를 추가할 수 있습니다.
<service name="Service ">
<endpoint
address="EchoService"
binding="basicHttpBinding"
contract="IEchoService ">
<headers>
<dsig:X509Certificate
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
...
</dsig:X509Certificate>
</headers>
</endpoint>
</service>
이 옵션을 사용하면, 클라이언트 또는 서비스의 코드내의 인프라 프로토콜 헤더 참조를 피하다 일이 생깁니다. 즉,
끝점(endpoint) 구성 방법만으로 메시지에 헤더가 추가됩니다.
서비스의 기술
ASP.NET 웹 서비스의 .asmx 파일에 관해서, 쿼리wsdl 를 사용해 HTTP GET 요청을 발행하면,
ASP.NET 는 그 서비스를 기술하는 WSDL 를 생성합니다. WSDL가 요청의 응답으로서 반환됩니다.
ASP.NET 2.0 에서는 서비스가 Web Services-Interoperability Organization (WS-I)의
Basic Profile 1.1 에 준거하는지검증해, 확실히 준거한다는 주장을 서비스의 WSDL 에 삽입할 수
있습니다. 이것은 System.Web.Services.WebServiceBinding 특성의 ConformsTo 및
EmitConformanceClaims 매개 변수를 사용해 실시합니다.
[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(
ConformsTo = WsiProfiles.BasicProfile1_1,
EmitConformanceClaims=true)]
public interface IEcho
ASP.NET 가 서비스에 대해서 생성하는 WSDL 는 사용자 지정 가능합니다. 이 사용자 지정은 WSDL 에 아이템을 추가하기
위한 System.Web.Services.Description.ServiceDescriptionFormatExtension 서브
클래스를 작성해서 실시합니다.
IIS 5.1, 6.0 또는 WAS 로 호스팅되는 HTTP 끝점(endpoint)에, WCF 서비스의 .svc 파일에 대해,
쿼리wsdl 에 의한 HTTP GET 요청을 발행하면, WCF 는 서비스를 기술하는 WSDL 를 응답합니다. .NET 응용
프로그램으로 호스팅되는 서비스의 HTTP 기반 주소에, 쿼리wsdl 에 의한 HTTP GET 요청을 발행해도 같은
결과가 됩니다.
다만, WCF 는 WS-MetadataExchange 요청에 대해서도 서비스를 기술하는 WSDL 를 생성해 여기에 응답합니다.
한편, ASP.NET 웹 서비스에는 WS-MetadataExchange 요청 지원은 포함되지 않습니다.
WCF 가 생성하는 WSDL는 여러가지로 사용자 지정 할 수 있습니다. System.ServiceModel.ServiceMetadataBehavior
클래스에서는 WSDL를 사용자 지정하기 위한 몇가지 기능이 제공되어, 완전한 제어를 실시하는 System.ServiceModel.Design.IWsdlExporter
구현을 개발할 수 있습니다. WCF 에서는 WSDL 를 생성하지 않는 구성도 가능하고, 특정 UR 로 정적인 WSDL 파일을
사용할 수 있습니다.
<behaviors>
<serviceBehaviors>
<behavior name="DescriptionBehavior">
<metadataPublishing
enableMetadataExchange="true"
enableGetWsdl="true"
enableHelpPage="true"
metadataLocation=
"http://localhost/DerivativesCalculatorService/Service.wsdl"/>
</behavior>
</serviceBehaviors>
</behaviors>
예외 처리
ASP.NET 웹 서비스에서는 미처리의 예외는 SOAP 오류로서 클라이언트에 반환됩니다. 또,System.Web.Services.Protocols.SoapException
클래스의 인스턴스를 명시적으로 예외처리하여, 거기에 따라 클라이언트에 송신 하는 SOAP 오류의 내용을 보다 강력하게 제어할 수도
있습니다.
WCF 서비스에서는 예외에 의해 기밀 정보가 우발적으로 공개되는 것을 막기 위해서, 미처리의 예외는 SOAP 오류로서 클라이언트에
반환되지 않습니다. 디버그 목적으로 미처리의 예외를 클라이언트에 되돌리기 위한 구성도 제공되었습니다.
WCF 의 프로그래밍에서는 클라이언트에 의도적으로 SOAP 오류를 반환하기 위해, 다목적 유형System.ServiceModel.FaultException<T>
의 인스턴스를 예외로 처리할 수있습니다. (T 는 데이터 계약). 또,System.ServiceModel.FaultContract
특성을 동작에 추가하고, 그 동작으로 발생할 가능성이 있는 오류를 지정할 수도 있습니다.
[DataContract]
public class MathFault
{
[DataMember]
public string operation;
[DataMember]
public string problemType;
}
[ServiceContract]
public interface ICalculator
{
[OperationContract]
[FaultContract(typeof(MathFault))]
int Divide(int n1, int n2);
}
그렇게 하는 것으로 서비스의 WSDL 로 예측되는 오류가 보급되어 클라이언트의 프로그래머가 동작으로 발생할 가능성이 있는 오류를
정확하게 상정해, 적절한 catch 구문을 기술할 수 있습니다.
try
{
result = proxy.Divide(value1, value2);
}
catch (FaultException<MathFault> e)
{
Console.WriteLine("FaultException<MathFault>: Math fault while doing "
+ e.Detail.operation
+ ". Problem: "
+ e.Detail.problemType);
}
상태 관리
ASP.NET 웹 서비스의 구현에 사용하는 클래스는 System.Web.Services.WebService 에서 파생
할 수 있습니다.
public class Service : WebService, IEcho
{
public string Echo(string input)
{
return input;
}
}
이 경우 클래스는 System.Web.Services.WebService 기반 클래스의Context 속성을
사용해 System.Web.HttpContext 개체를 접근 하도록 프로그래밍 할 수 있습니다. System.Web.HttpContext
개체의 Application 속성을 통해서 응용 프로그램의 상태정보를 업데이트하여 Session 속성을 통해서 세션의
상태정보를 업데이트합니다.
ASP.NET 에서는 System.Web.HttpContext 의 Session 속성으로 접근 하는 세션 상태정보가
실제로 보존 되는 장소를 상당한 정도까지 제어할 수 있습니다. 이 정보는 Cookie, 데이터베이스, 현재 서버의 메모리 또는
특정의 서버의 메모리에 보존 할 수 있습니다. 그 선택은 서비스의 구성 파일로 실시합니다.
WCF 에서는 상태 관리를 위해서 확장 가능 개체가 제공되었습니다. 확장 가능 개체란 System.ServiceModel.IExtensibleObject<T>
를 구현하는 개체입니다. 가장 중요한 확장 가능 개체는 System.ServiceModel.ServiceHostBase
및System.ServiceModel.InstanceContext 입니다. 전자를 사용하면, 같은 호스트상의 모든
서비스타입의 모든 인스턴스가 접근 가능한 상태를 유지할 수 있습니다. 후자를 사용하면, 하나의 서비스 타입의 같은 인스턴스내에서 실행중의
임의의 코드에 의해 접근 가능한 상태를 유지할 수 있습니다.
다음에 나타난 서비스타입 TradingSystem 에서 System.ServiceModel.ServiceBehavior
특성을 사용하고, 같은 프록시 인스턴스의 모든 호출이 그 서비스타입과 같은 인스턴스에 루팅 되는 것을 지정해 있습니다.
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)]
public class TradingSystem: ITradingService
클래스 DealData 는 하나의 서비스타입의 같은 인스턴스내에서 실행중의 임의의 코드에 의해서 접근 가능한 상태를
정의합니다.
internal class DealData: IExtension<InstanceContext>
{
public string DealIdentifier = null;
public Trade[] Trades = null;
}
서비스 계약의 몇개의 동작을 구현하는 서비스타입의 코드내에서 그 서비스타입의 현재의 인스턴스 상태에 DealData 상태 개체가
추가됩니다.
string ITradingService.BeginDeal()
{
string dealIdentifier = Guid.NewGuid().ToString();
DealData state = new DealData(dealIdentifier);
OperationContext.Current.InstanceContext.Extensions.Add(state);
return dealIdentifier;
}
그 후, 서비스 계약의 다른 동작을 구현하는 코드에 의해서 이 상태 개체를 취득해 변경할 수 있습니다.
void ITradingService.AddTrade(Trade trade)
{
DealData dealData = OperationContext.Current.InstanceContext.Extensions.Find<DealData>();
dealData.AddTrade(trade);
}
ASP.NET 에서는 System.Web.HttpContext 클래스의 상태정보를 실제로 보존 하는 장소를 상당한
정도까지 제어할 수 있습니다. 한편, WCF 가 적어도 최초의 버전에서는 확장 가능 개체의 보존 장소를 제어할 수 없습니다. 이것은
WCF 서비스로 ASP.NET 상호교환모드를 선택하는 최대의 이유가 됩니다. 구성에 의한 상태 관리가 필요한 경우는 ASP.NET
상호교환모드를 선택하는 것으로 System.Web.HttpContext 클래스의 기능을 ASP.NET 와 완전히 똑같이
사용할 수 있어 System.Web.HttpContext 클래스로 관리하는 상태정보 보존 장소도 구성할 수 있습니다.
보안
ASP.NET 웹 서비스를 보호하기 위한 옵션은 그 대부분이 IIS 응용 프로그램을 보호하기 위한 옵션입니다. WCF 응용
프로그램은 IIS 뿐만이 아니라 임의의 .NET 실행가능프로그램 안에서 호스팅 될 가능성이 있기 위해, WCF 응용 프로그램을 보호하기
위한 옵션은 IIS 의 기능 에서 독립시킬 필요가 있었습니다. 다만, ASP.NET 상호교환모드로 동작하는 WCF 서비스에서는
ASP.NET 웹 서비스용으로 제공되는 기능도 사용 가능합니다.
보안: 인증
IIS 에서는 응용 프로그램에의 접근을 제어하는 기능이 제공되어 이것에 의해서 익명 접근 또는 각종의 인증 모드
(Windows 인증, 다이제스트 인증, 기본 인증 및 .NET 패스포트 인증)을 선택할 수 있습니다. ASP.NET 웹 서비스에의
접근을 제어하려면, Windows 인증 옵션을 사용할 수 있습니다. 다만, WCF 응용 프로그램을 IIS 로 호스팅하는 경우 IIS
는 응용 프로그램에의 익명 접근을 허가 하도록 구성해, 인증은 WCF 자신 (Windows 인증의 외, 다양한 옵션을 지원
한다)으로 관리할 수 있도록 할 필요가 있습니다. 그 외의 짜넣어 옵션으로서는 사용자 명토큰, X.509 증명서, SAML 토큰 및 InfoCard 가
있지만 사용자 지정인증 메커니즘을 정의하는 것도 가능합니다.
ASP.NET 2.0 에서는 System.Web.HttpContext 클래스의 Profile 속성을
사용하고, 인증되는 사용자에 관한 정보를 (특정의 종류의 스토어에서 정보를 읽어내는 방법을 인식) System.Web.Profile.Provider
클래스 경유로 스토어 에서 자동적으로 얻을 수 있습니다. ASP.NET 2.0 의 메커니즘은 WCF 에서는 ASP.NET
상호교환모드 이외로 지원 되지 않지만, 사용자 지정 동작으로 System.Web.Profile.Provider 클래스를
사용해 프로파일정보를 얻는 것은 가능합니다.
보안: 위장
ASP.NET 에서는 ASP.NET 웹 서비스가 특정의 사용자나, 현재의 요청으로 제공된 사용자의 자격 정보에서도 위장할
수 있도록하기 위한 아이덴티티 요소가 제공되었습니다. ASP.NET 상호교환모드로 동작하는 WCF 응용 프로그램에서는 이 요소를
사용하고, 위장을 구성할 수 있습니다.
WCF 의 구성 시스템에서는 위장하는 특정의 사용자를 지정하여, 독자적인 아이덴티티 요소가 제공되었습니다. 또,
WCF 클라이언트 및 서비스로, 독자적으로 위장을 구성하는 것도 가능합니다. 클라이언트는 요청을 송신 하는 시점에서 현재의 사용자를
위장하도록 구성할 수 있습니다.
<behaviors>
<endpointBehaviors>
<behavior name="DerivativesCalculatorClientBehavior">
<clientCredentials>
<windows allowedImpersonationLevel="Impersonation"/>
</clientCredentials>
</behavior>
</endpointBehaviors>
</behaviors>
서비스 동작은 현재의 요청으로 제공된 사용자의 자격 정보에서도 위장하도록 구성할 수 있습니다.
[OperationBehavior(Impersonation = ImpersonationOption.Required)]
public void Receive(Message input)
보안: 접근 제어 리스트에 의한 승인
접근 제어 리스트 (ACL)를 사용하고,.asmx 파일에의 접근을 규제할 수 있습니다. 다만, WCF 의 .svc 파일의 ACL 는
ASP.NET 상호교환모드 이외에서는 무시됩니다.
보안: 롤 기반 승인
IIS 의 Windows 인증 옵션을 ASP.NET 구성 언어로 제공되는 승인 요소와 조합해 사용하는 것으로써, 사용자가 속하는
Windows 그룹에 근거하고, ASP.NET 웹 서비스에 관한 롤 기반 승인을 쉽게 실시할 수 있습니다. ASP.NET 2.0 에서는 보다 다목적
기인 롤 기반 승인 메커니즘인 롤 공급자가 도입되었습니다.
롤 공급자는 모두, 사용자에 할당할 수 있었던 롤에 대해 문의하는 간소한 인터페이스를 구현하는 클래스이지만 각 롤 공급자는 그
정보를 다른 소스에서 얻은 방법을 인식하고 있습니다. ASP.NET 2.0 에서는 Microsoft SQL Server 데이터베이스 에서
롤 할당을 취득할 수 있는 롤 공급자와 Windows Server 2003 Authorization Manager 에서 롤 할당을 취득할
수 있는 롤 공급자가 제공되었습니다.
WCF 응용 프로그램도 포함하고,.NET 응용 프로그램에서는 롤 공급자의 메커니즘은 실제로는 ASP.NET 과는 관계없는 것으로
사용할 수 있습니다. 다음에 나타내는 WCF 응용 프로그램의 구성예에서는 ASP.NET 롤 공급자의 사용이 System.ServiceModel.ServiceAuthorization
동작으로 선택되는 옵션인 것을 알 수 있습니다.
<system.serviceModel>
<services>
<service name="Service.ResourceAccessServiceType"
behaviorConfiguration="ServiceBehavior">
<endpoint
address="ResourceAccessService"
binding="wsHttpBinding"
contract="Service.IResourceAccessContract"/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="ServiceBehavior">
<serviceAuthorization principalPermissionMode="UseAspNetRoles"/>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
보안: 클레임(요청) 기반 승인
WCF의 가장 중요한 기술 혁신의 한가지는 보호된 리소스에의 접근에 대한, 클레임 기반 승인의 지원입니다. 클레임은
유형, 권한 및 값에 의해서 구성됩니다. 운전면허를 예로 해 봅시다. 운전면허에는 보유 사람에 관한 일련의 클레임 항목이 있어, 그
중 하나는 생년월일입니다. 이 클레임의 유형는 생년월일로, 그 값은 운전자의 생년월일입니다. 이 클레임에 의해서 보유 사람에게 줄 수
있는 권한에서는 보유 사람이 클레임 값를 사용하고 무엇이 가능할지가 지정 되었습니다. 운전자의 생년월일에 관한 클레임의 경우 그
권한과는 단지 소유하는 것이어, 운전자는 그 생년월일을 소유하지만, 예를 들어 변경할 수 없습니다. 클레임 기반 승인은 롤 기반 승인을 포함 하고 있습니다. 롤은 클레임의
한가지 유형에 지나지 않기 때문입니다.
클레임 기반 승인은 동작의 접근 요건에 대해서 일련의 클레임을 비교 해, 그 비교 결과에 근거해 그 동작에의 접근이 허가 또는
거부되어 실행됩니다. WCF 에서는 System.ServiceModel.Description.ServiceAuthorizationBehavior의 ServiceAuthorizationManager 속성에 역시 값을 할당하는 것으로 클레임 기반 승인을 실행하기 위해서
사용하는 클래스를 지정할 수 있습니다.
<behaviors>
<serviceBehaviors>
<behavior name='ServiceBehavior'>
<serviceAuthorization
serviceAuthorizationManagerType='Service.AccessChecker, Service' />
</behavior>
</serviceBehaviors>
</behaviors>
클레임 기반 승인을 실행하기 위해서 사용하는 클래스는 System.ServiceModel.ServiceAuthorizationManager
에서 파생 할 필요가 있습니다. 치환 하는 메서드는 AccessCheck() 뿐입니다. WCF 는 서비스의 동작이 실행 될
때마다, 이 메서드를 호출해,System.ServiceModel.OperationContext 개체 (사용자에 관한 클레임이ServiceSecurityContext.AuthorizationContext
속성에 포함되어 있다)를 제공합니다. 이와 같이 WCF 에서는 사용자가 인증용으로 제공한 보안 토큰 에서 그 사용자에 관한 클레임의
어셈블리가 이미 완료하고 있으므로, 그러한 클레임이 동작의 조건을 채워 있는지 어떤지의 간단한 평가가 남게만 됩니다.
모든 종류의 보안 토큰 에서 클레임이 자동적으로 어셈블(assemble) 되는 것은 WCF의 중요한 기술
혁신입니다. 이것으로 클레임에 근거하는 승인을 위한 코드가 인증 메커니즘에서 완전하게 독립하기 때문입니다. 이것과는 대조적으로
ASP.NET의 ACL 나 롤을 사용한 승인은 Windows 인증과 긴밀히 결부되어 있습니다.
보안: 기밀성
ASP.NET 웹 서비스로 교환되는 메시지의 기밀성은 IIS 로 Secure Hypertext Transfer Protocol
(HTTPS)를 사용하도록 응용 프로그램을 구성하는 것으로써, 전송 레벨로 확보 되었습니다. IIS 로 호스팅하는 WCF 응용
프로그램에서도 같은 것이 가능합니다. 다만, IIS 의 외부에서 호스팅되는 WCF 응용 프로그램도 안정적인 전송 프로토콜을
사용하도록 구성할 수 있습니다. 한층 더 중요한 점으로서 WCF 응용 프로그램에서는 WS-Security 프로토콜을 사용하고,
전송하기 전부터 메시지를 보호하도록 구성하는 것도 가능합니다. WS-Security 를 사용해 메시지의 본문만을 보호하는
것으로 최종적인 행선지에 도착하기 전의 중간노드에서도 기밀성을 확보할 수 있습니다.
글로벌리제이션
ASP.NET 구성 언어에서는 서비스 마다 문화를 지정할 수 있습니다. WCF 에서는 ASP.NET 상호교환모드 이외에서는 이
구성은 지원 되지 않습니다. ASP.NET 상호교환모드를 사용하지 않는 WCF 서비스를 로컬라이즈 하는 경우는 서비스타입을 특정의 문화
전용의 어셈블리에 컴파일 해, 문화 전용의 어셈블리 마다 문화 전용의 끝점(endpoint)를 사용합니다.
내부 아키텍처
ASP.NET 웹 서비스
ASP.NET의 최신의 구현에서는 HTTP 요청은 Windows 커널 안의 http.sys 로 불리는 HTTP 구현 에서의System.Web.HttpWorkerRequest
개체 라는 형식에서 수신 합니다. System.Web.HttpWorkerRequest 개체를 수신한System.Web.HttpRuntime
개체는 System.Web.HttpWorkerRequest 개체 안의 데이터 에서System.Web.HttpContext
개체를 작성합니다. 요청은 System.Web.HttpContext 개체에 Request 속성에 들어갑니다. 이것이System.Web.HttpRequest 개체입니다.
기본값에서는 .asmx 파일에의 HTTP POST 요청을 나타내는 System.Web.HttpRequest 개체는 System.Web.IHttpHandler
인터페이스를 구현하는 개체에게 건네집니다 (Skonnard 2003, 2004). 이 개체는 System.Web.Services.Protocols.WebServiceHandlerFactory
클래스를 사용해 작성되어 ASP.NET 웹 서비스 요청 처리기로 불리는 경우도 있습니다. WCF 를 ASP.NET
상호교환모드에 구성해 있는 경우 WCF 는 ASP.NET 웹 서비스 요청 처리기의 동작을 모방한 System.Web.IHttpHandler
구현을 제공합니다.
ASP.NET 웹 서비스 요청 처리기는 적어도 4 개의 동작을 실행할 필요가 있습니다. 첫번째는 HTTP 요청에 기본 제공되는
SOAP 메시지를 개발자기 제공되는 몇개의 SOAP E\extensions 인스턴스에 건네줄 필요가 있습니다 (Meier, Vasireddy, Babbar 및 Mackman 2004). 두번째는 요청을 처리하기 위해, .asmx 파일로 참조되는 클래스
메서드를 실행 할지를 결정할 필요가 있습니다. 세번째는 요청을 직렬화(Serialization) 해제하고, 그 메서드가 매개
변수로서 상정하는 유형의 인스턴스로 할 필요가 있습니다. 네번째는 메서드를 실제로 실행 해, 직렬화(Serialization) 해제한 매개 변수를 건네줘야 합니다.
SOAP 확장기능은 System.Web.Services.Protocols.SoapExtension 에서 파생 되는
유형입니다. 이것들을 사용해 요청 안의 SOAP 메시지를 접근 또는 변경하고 나서,.asmx 파일로 참조되고 있는 클래스의 몇개의
메서드에 메시지가 건네받아 처리됩니다. 이것들을 사용해 응답메시지에 접근 하거나 변경하는 것도 가능하고, 서버 뿐만이 아니라
클라이언트에도 구현 할 수 있습니다. SOAP 확장기능의 일반적인 용도는 메시지 로그입니다. 또, 메시지의 암호화에도 사용됩니다.
SOAP 확장기능은 컴퓨터에 도입 떠날 수 있어 모든 서비스에 적용하는 일도 개개의 서비스에 적용할 수도 있습니다. 또, 사용자 지정 System.Web.Services.SoapExtension
특성을 사용하고, 서비스의 특정의 동작에 적용하는 것도 가능합니다.
클래스 메서드를 실행 해 요청을 처리할지를 결정하기 위해서, ASP.NET 웹 서비스 요청 처리기는 기본값으로 요청 안의 SOAPAction
헤더를 사용합니다. 기본값으로 요청 처리기는 SOAPAction 의 HTTP 헤더가 서비스의 네임 스페이스와 거기에
계속 되는 동작의 이름으로 구성된 것과 상정하고 있습니다. 서비스의 기본값의 네임 스페이스는 http://tempuri.org/
이며, 동작의 기본값 이름은 그 동작을 정의하는 메서드의 이름입니다. 따라서, 이 HTTP 요청 처리에서는
POST /asmxservice/service.asmx HTTP/1.1
User-Agent: Mozilla/4.0
Content-Type: text/xml; charset= utf-8
SOAPAction: "http://tempuri.org/Echo"
Host: localhost
Content-Length: 314
Expect: 100-continue
Connection: Keep-Alive
<?xml version="1.0" encoding="UTF-8" ?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<Echo xmlns="http://tempuri.org/">
<input>Hello, World
</input>
</Echo>
</soap:Body>
</soap:Envelope>
요청 처리기는 http://localhost/asmxservice/service.asmx 에 존재하는 파일 안의 @_WebService
지시문으로 참조되는 클래스가 Echo 라는 동작을 가지는 기본값의 네임 스페이스가 있는 서비스를
정의하고 있는 것이라고 봅니다. 또 기본값에서는 이 동작은 클래스Echo 의 메서드에 의해서 구현되는 것과 상정해,
처리기는 이 메서드를 실행 해 요청의 처리를 시도합니다. 이상의 동작은 모두 사용자 지정 가능합니다.
SOAPAction 의 HTTP 헤더 대신에, SOAP 메시지의 본문 요소의 완전 수식 요소명을 사용하고, 요청 처리기에 실행하는
메서드를 식별시키는 것도 가능합니다. 전의 HTTP 요청의 예에서는 본문 요소는 다음과 같습니다.
<Echo xmlns="http://tempuri.org/">
[...]
</soap:Body>
이 요소의 완전 수식 요소명은 http://tempuri.org/Echo 입니다. 이 이름은 SOAPAction 의 HTTP 헤더와
같아서, ASP.NET 웹 서비스 요청 처리기가 이름을 사용해 메시지의 루팅 방법을 어떻게 판별할지는 분명합니다. 요청 처리기에 SOAPAction 의 HTTP
헤더는 아니라 SOAP 메시지의 본문 요소의 완전 수식명을 사용시키려면 , 다음과 같이 서비스를 구현하는 클래스에 S ystem.Web.Services.Protocols.SoapDocumentService 특성을 할당해 루팅
스타일로서 RequestElement 를 지정합니다.
[SoapDocumentService(RoutingStyle = SoapServiceRoutingStyle.RequestElement)]
public class Service : WebService, IEcho
또,System.Web.Services.Protocols.SoapDocumentMethod 특성의
RequestElementName 매개 변수를 사용하고, SOAP 메시지의 본문 요소의 로컬명을 메서드 이름과 다른 것으로 할 수도
있습니다.
[WebMethod]
[SoapDocumentMethod(RequestElementName="OtherName")]
string Echo(string input);
이 경우 ASP.NET 웹 서비스 요청 처리기는 SOAP 메시지의 본문 요소의 로컬명을 메서드 이름과 직접 일치 하는 것이
아니라, 메서드에 할당할 수 있는 System.Web.Services.Protocols.SoapDocumentMethod
특성의 RequestElementName 매개 변수로 지정되는 값과 일치 합니다.
서비스의 네임 스페이스는 System.Web.Services.WebService 특성의 Namespace 매개 변수를 사용하고,
기본값 에서 변경할 수 있습니다.
[WebService(Namespace = "http://www.woodgrove.com/2006/01/29/")]
public interface IEcho
이 예에서는 인터페이스에 적용된 System.Web.Services.WebService 특성의 이 매개 변수의 값을
변경하고 있지만, 유감스럽지만 버그 때문에, 클래스는 아니게 인터페이스에 이 특성이 적용되고 있는 경우는 이 매개 변수를 변경해도
실제로는 아무 효과도 없습니다.
동작의 이름은 그 동작을 구현하는 메서드 이름과는 다른 이름으로 할 수 있습니다. System.Web.Services.WebMethod 특성의 MessageName 매개 변수의 값을 지정합니다.
[WebMethod(MessageName="OtherName")]
string Echo(string input);
이 기능을 사용하고, ASP.NET 웹 서비스 요청 처리기로 다형태 메서드를 판별할 수 있습니다.
[WebMethod(MessageName="OtherName")]
string Echo(string input);
[WebMethod]
string[] Echo(string[] inputs);
메서드에 System.Web.Services.Protocols.SoapDocumentMethod 특성을 추가, 이
특성의 Action 매개 변수에 다음과 같이 값을 지정합니다.
[WebMethod]
[SoapDocumentMethod(Action="urn:echoing:echo")]
string Echo(string input);
이러한 메서드의 경우 ASP.NET 웹 서비스 요청 처리기는 SOAPAction 헤더를 서비스의 네임 스페이스와 동작명으로
분해 대상 메서드를 식별하는 것이 아니라, SOAPAction 의 HTTP 헤더를 SoapDocumentMethod 특성의
Action 매개 변수로 지정되는 값에 단순하게 일치 합니다.
ASP.NET 웹 서비스 요청 처리기가 .asmx 파일로 참조되고 있는 클래스 메서드를 실행 해 요청을 처리해야할 것인가를
식별한 후, 그 요청을 직렬화(Serialization) 해제하고, 그 메서드가 매개 변수로서 상정하는 유형의 인스턴스로 할 필요가 있습니다. 이것에는 System.Xml.Serialization.XmlSerializer 가 사용됩니다.
기본값에서는 요청 처리기가 요청에 있는 SOAP 메시지가 WSDL 1.1 사양으로 도큐먼트 스타일로
불리는 것에 준거한다고 봅니다. 이 스타일의 메시지에는 임의의 스키마에 근거해 구조화 된 본문의 요소가 포함되어 요청
처리기는 System.Xml.Serialization.XmlSerializer 에 의존해 이러한 요소를 .NET 유형에
직렬화(Serialization) 해제합니다. 이 동작의 경우
[WebMethod]
PurchaseOrderConfirmationType PlaceOrders(PurchaseOrderType order);
ASP.NET 웹 서비스 요청 처리기는 다음과 같은 도큐먼트 스타일의 SOAP 메시지를 상정합니다.
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:s1="urn:Woodgrove:2006:January:29" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:tns="http://tempuri.org/"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<tns:PlaceOrders>
<s1:PurchaseOrder>
<s1:Date>2006-01-31</s1:Date>
<s1:LineItems>
<s1:LineItem>
<s1:ItemNumber>1</s1:ItemNumber>
<s1:Quantity>1</s1:Quantity>
<s1:UnitPrice>50.00</s1:UnitPrice>
</s1:LineItem>
</s1:LineItems>
<s1:Total>50.00</s1:Total>
</s1:PurchaseOrder>
</tns:PlaceOrders>
</soap:Body>
</soap:Envelope>
여기서, 각 요소의 이름은 직렬화(Serialization) 해제한 후의 유형 이름을 나타냅니다. 이 메커니즘도 사용자 지정 할 수 있습니다.
- 유형 이름과 SOAP 메시지의 구성요소와의 매핑은 특성System.Xml.XmlElement 및System.Xml.XmlAttribute
를 메서드의 매개 변수에 적용 해서 사용자 지정 할 수 있습니다. System.Xml.XmlElement 특성은
ASP.NET 웹 서비스 요청 처리기가 다음의 유형를 직렬화(Serialization) 해제하면 상정하는 XML 요소의 이름을 제어합니다.
[WebMethod]
PurchaseOrderType PlaceOrders
(
[XmlElement("OrderParameter")]
PurchaseOrderType order
);
특성System.Xml.XmlAttribute 가 매개 변수에 추가 된 경우는 요청 처리기는 이 매개 변수를
XML 요소는 아닌, XML 특성 에서 직렬화(Serialization) 해제하면 상정합니다.
- ASP.NET 웹 서비스 요청 처리기의 기본값의 동작 (요청에 있는 SOAP 메시지가 도큐먼트 스타일에
준거하여 상정하는 것)을 변경해, 메시지가 WSDL 1.1 사양으로 말한 RPC 스타일에 준거하고 있으면
상정되도록 할 수 있습니다. 거기에는 서비스 전체에 대해서는 SoapRpcService 특성을 사용해, 개개의
메서드에 대해서는 SoapRpcMethod 특성을 사용합니다. 다만, 이러한 옵션을 사용하는 것은 추천 할 수
없습니다. 그 이유는 RPC 스타일의 사용은 WS-I Basic Profile 1.1 에 포함되지 않고, 상호 운용성을 해칠
가능성이 있기 때문입니다.
Windows Communication Foundation
WCF 클라이언트로 사용하는 서비스의 프록시 클래스는 자신의 메서드에게 건네진 매개 변수를System.ServiceModel.Channels.Message
개체에 직렬화(Serialization)합니다. 그 후, 이 개체는 일련의 채널 경유로 전달됩니다. 채널의 수 및 성질은 선택한 바인딩에 의해서 정해집니다.
이러한 채널은 일반적으로 채널이 구현 하고 있는 프로토콜에 따르고,System.ServiceModel.Channels.Message
개체의 Headers 컬렉션에System.ServiceModel.Channels.MessageHeader 개체를 추가합니다.
그 마지막 채널은 항상 전송 채널입니다. 이 채널은 엔코더를 사용하고 (이 엔코더의 성질도 바인딩에 의해서 정해집니다),System.ServiceModel.Channels.Message
개체를 바이트 스트림에 직렬화(Serialization)해, 이것을 전송 채널이 서버에 송신 합니다. 서버상의 리스너는 바이트 스트림을 수신 하면, 엔코더를
사용해 이 바이트 스트림을 System.ServiceModel.Channels.Message 개체에
직렬화(Serialization) 해제합니다. 이
개체가 일련의 채널 경유로 전달됩니다. 이러한 채널은 일반적으로 클라이언트 위의 일련의 채널에 대응합니다. 그 후, System.ServiceModel.Channels.Message
개체가System.ServiceModel.Dispatcher.DispatchRuntime 개체에게 건네집니다. System.ServiceModel.Dispatcher.DispatchRuntime
개체는 서비스타입 메서드를 실행하는지를 판별해, System.ServiceModel.Channels.Message
개체 에서의 데이터를 그 메서드가 매개 변수로서 상정하는 유형의 인스턴스에 직렬화(Serialization) 해제, 그 메서드를 실행 합니다.
서비스의 바인딩을 통해서, WCF 내부에서의 데이터 전송에 사용되는 채널의 선택과 동작을 사용자 지정 가능할 뿐만 아니라, 사용자
지정 채널을 추가하는 것도 쉽게 할 수 있습니다. 또, 프록시 및 System.ServiceModel.Dispatcher.DispatchRuntime
동작도 동작(Behavior)를 통해서 조정하거나 완전하게 사용자 지정하거나 할 수 있습니다. 이와 같이 ASP.NET 에서는
웹 서비스 요청 처리기를 제어하기 위한 특성이 다수 제공 되었습니다가 WCF 는 그것들과 같은 특성의 집합을 제공할 뿐만 아니라,
사용자 지정 코드를 사용해 프록시 및 System.ServiceModel.Dispatcher.DispatchRuntime를 제어한다는 옵션도 제공합니다.
서비스타입 메서드를 실행 해 요청을 처리하는지를 판별할 때, System.ServiceModel.Dispatcher.DispatchRuntime
은 SOAPAction 헤더에 의존합니다. 기본값으로 WCF 동작의 SOAPAction 헤더는 서비스의 네임 스페이스와 거기에 계속
되는 서비스 계약명 및 거기에 계속되는 동작명으로 구성됩니다. 서비스 계약의 기본값의 네임 스페이스는 http://tempuri.org/
입니다. 서비스 계약의 기본값 이름은 그 정의에 사용되고 있는 인터페이스 또는 클래스 이름입니다. 동작의 기본값 이름은 그것을 구현
하고 있는 메서드의 이름입니다. 따라서, 이 프로그램의 경우
[ServiceContract]
public interface IDerivativesCalculator
{
[OperationContract]
decimal CalculateDerivative(
string[] symbols,
decimal[] parameters,
string[] functions);
}
SOAPAction 헤더는 http://tempuri.org/IDerivativesCalculator/CalculateDerivative
가 됩니다. 네임 스페이스 및 서비스 계약명은 System.ServiceModel.ServiceContract
특성의 Namespace 및 Name 매개 변수를 사용해 기본값 에서 변경할 수 있습니다. 동작명은 System.ServiceModel.OperationContract
특성의 Name 매개 변수를 사용해 기본값 에서 변경할 수 있습니다.
[ServiceContract(Namespace="OtherNamespace",Name="OtherContractName"]
public interface IDerivativesCalculator
{
[OperationContract(Name="OtherOperationName")]
decimal CalculateDerivative(
string[] symbols,
decimal[] parameters,
string[] functions);
}
System.ServiceModel.Message 개체 에서의 데이터를 직렬화(Serialization) 해제할 때,System.ServiceModel.Dispatcher.DispatchRuntime은 기본값으로System.Runtime.Serialization.DataContractFormatter 를 사용합니다. System.ServiceModel.DataContract 및System.ServiceModel.DataMember
특성의 Namespace 및 Name 매개 변수를 사용하고, XML 요소명을 직렬화(Serialization) 해제 후의 클래스에 일치 시키는
메커니즘은 이미 설명했던 대로입니다.
System.ServiceModel.Dispatcher.DispatchRuntime은 다음과 같이 System.ServiceModel.XmlSerializerFormat
특성을 적용하는 것으로써, System.Xml.Serialization.XmlSerializer 를 사용할 수 있습니다.
[ServiceContract, XmlSerializerFormat]
public interface IEcho
이 특성은 서비스의 개개의 동작에도 적용할 수 있습니다.
직렬화(Serialization) 해제에 System.Runtime.Serialization.DataContractFormatter 를 사용하는
경우는 System.ServiceModel.DataContractFormat 특성을 사용하고, 데이터가 도큐먼트
스타일 또는 RPC 스타일의 어느 쪽에 있으면 상정되는지를 제어할 수 있습니다. 이 특성은 서비스 계약에 적용하는 일도 서비스 계약의
개개의 동작에 적용할 수도 있습니다.
[ServiceContract]
public interface IItemService
{
[OperationContract]
[DataContractFormat(Style=OperationFormatStyle.Rpc)]
public void DeliverItem(ItemMessage itemMessage);
}
WCF 도입 준비: 통합
간편화
ASP.NET 를 현재 사용하고 있어 향후 WCF 를 채용하는 것이 예측되는 경우는 새로운 ASP.NET 웹 서비스가 WCF
응용 프로그램과 확실히 제휴할 수 있도록, 다음의 가이드 라인에 따라 주세요.
전반적인 권장사항
새로운 서비스에는 ASP.NET 2.0 을 채용합니다. 그러면, 신버전의 개량된 기능이나 확장기능을 물론 이용할 수 있습니다. 그
만큼이 아니고, 같은 응용 프로그램 안에서 ASP.NET 2.0 구성요소를 WCF 구성요소와 함께 사용할 수 있을 가능성도 있습니다.
프로토콜
ASP.NET 2.0 새로운 기능을 사용하고, WS-I Basic Profile 1.1 유효성 검사을 확인해 주세요.
[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(
ConformsTo = WsiProfiles.BasicProfile1_1,
EmitConformanceClaims=true)]
public interface IEcho
이 프로파일에 준거하는 ASP.NET 웹 서비스는 일반적으로 상호 운용성이 높고, WCF 정의된 바인딩System.ServiceModel.BasicHttpBinding
을 통해서 WCF 클라이언트와 확실히 상호 운용할 수 있습니다.
서비스 개발
System.Web.Services.Protocols.SoapDocumentService 특성을 사용하고,
SOAPAction 의 HTTP 헤더가 아니고, SOAP 메시지의 본문 요소의 완전 수식명에 근거해 메서드에 메시지를 배포하는 것은
삼가해 주세요. WCF는 SOAPAction 의 HTTP 헤더를 사용해 메서드에 메시지를 배포합니다.
데이터 표기
이미 설명한 것처럼, XML 의 네임 스페이스가 명시적으로 정의 된 경우
System.Xml.Serialization.XmlSerializer 가 기본값으로 형식을 직렬화(Serialization)하는 XML은 System.RuntimeSerialization.DataContractFormatter
가 형식을 직렬화(Serialization)하는 XML 와 의미는 같습니다. 따라서, 앞으로 WCF 를 도입하는 것을 전제로, 현재의 ASP.NET
웹 서비스로 사용하는 데이터 유형을 정의할 때는 다음과 같이 해 주세요.
- XML 스키마는 아니고 .NET 클래스를 사용해 형식을 정의합니다.
- 클래스에는 System.Serializable 특성 및 System.Xml.Serialization.XmlRoot
특성만을 추가합니다. 후자는 그 형식의 네임 스페이스를 명시적으로 정의하기 위해 사용합니다. .NET 클래스의 XML 에의 변환
방법을 제어하는 목적으로 System.Xml.Serialization 네임 스페이스에서 다른 특성을 추가하는 것은 삼가해
주세요.
이 접근 방식을 사용하면, 후의 단계에서 System.Runtime.Serialization.DataContract 및System.Runtime.Serialization.DataMember
특성을 추가하고,.NET 클래스를 데이터 계약으로 할 수 있습니다. 이러한 클래스를 송신을 위해서 직렬화(Serialization)한 XML 를
큰폭으로 변경할 필요는 없습니다. 이 경우 ASP.NET 웹 서비스의 메시지로 사용하고 있는 것과 같은 형식을 WCF 응용 프로그램으로
데이터 계약으로서 처리할 수 있어 WCF 응용 프로그램의 성능의 향상을 시작해 다양한 이점을 얻을 수 있습니다.
보안
IIS 의 인증 옵션은 사용하지 말아 주세요. WCF 클라이언트는 이러한 옵션을 지원하지 않습니다. 서비스를 보호 해야 하는 경우는 곧바로 WCF 를 도입해야 합니다. WCF 가 표준프로토콜에 근거하는 풍부한 옵션을 제공하기 때문입니다.
WCF 도입 준비: 이행의
간편화
새로운 ASP.NET 응용 프로그램을 앞으로 WCF 에 쉽게 이행 할 수 있도록 하려면, 이미 설명한 권장사항에
추가해 다음사항도 따라해 주세요.
프로토콜
ASP.NET 2.0 의 SOAP 1.2 지원을 무효로 합니다.
<configuration>
<system.web>
<webServices >
<protocols>
<remove name="HttpSoap12"/>
</protocols>
</webServices>
</system.web>
</configuration>
이렇게 하는 것이 바람직한 이유는 WCF 에서는 SOAP 1.1, SOAP 1.2 등, 다른 프로토콜에 준거하는 메시지는
프로토콜 따로 다른 끝점(endpoint)를 사용해야합니다. ASP.NET 2.0 웹 서비스가 SOAP 1.1 으로
SOAP 1.2 를 모두 지원 하도록 구성 된 경우 (기본값 설정), ASP.NET 웹 서비스의 기존의 모든 클라이언트와
확실히 호환성이 있는 원래 주소에 있는 단일의 WCF 끝점(endpoint)에 서비스를 이행 할 수 없습니다.
서비스 개발
- WCF 에서는 인터페이스 또는 클래스에 System.ServiceModel.ServiceContract 특성을
적용 해서 서비스 계약을 정의할 수 있습니다. 클래스보다 인터페이스에 이 특성을 적용하는 것을 추천
합니다. 그 계약의 정의는 복수 클래스로, 다양한 방법으로 구현 가능하기 때문입니다. ASP.NET 2.0 은
System.Web.Services.WebService 특성을 인터페이스 및 클래스에
적용하는 것도 가능합니다. 다만, 이미 설명한 것처럼, ASP.NET 2.0 에 존재하는 불편 때문에,
System.Web.Services.WebService 특성의 Namespace 매개 변수는 이 특성을 클래스가 아닌
인터페이스에 적용했을 경우는 무효입니다. 일반적으로 서비스의 네임 스페이스는 System.Web.Services.WebService 특성의 Namespace 매개 변수를 사용해 기본값
(http://tempuri.org) 에서 변경하는 것이 바람직하기 때문에, 계속 System.ServiceModel.ServiceContract
특성을 인터페이스 또는 클래스에 적용해 ASP.NET 웹 서비스를 정의할 필요가 있습니다.
- 이러한 인터페이스를 정의하는 메서드에서는 코드를 가능한 한 줄입니다. 이러한 인터페이스 처리는 다른 클래스에
맡기도록 합니다. 그러면, 새로운 WCF 서비스타입을 사용해도 인터페이스의 실질적인 처리를 이러한 클래스에 간단하게 맡길
수 있습니다.
- System.Web.Services.WebMethod 특성의 MessageName 매개 변수를 사용하고, 서비스의 동작의
명시적인 이름을 지정합니다.
[WebMethod(MessageName="ExplicitName")]
string Echo(string input);
이것이 중요한 이유는 ASP.NET 동작의 기본값 이름이 WCF 로 붙일 수 있는 기본값의 이름과는 다르기
때문입니다. 명시적인 이름을 지정하면, 기본값의 이름에의 의존을 피할 수 있습니다.
- ASP.NET 웹 서비스의 동작을 다형태 메서드로 구현 하지 말아 주세요.WCF 에서는 다형태 메서드에 의한 동작의 구현은
지원 되지 않습니다.
- HTTP 요청을 메서드에 루팅하기 위해서 사용되는 SOAPAction의 HTTP 헤더의 명시적인 값을System.Web.Services.Protocols.SoapDocumentMethod
특성으로 지정합니다.
[WebMethod]
[SoapDocumentMethod(RequestElementName="ExplicitAction")]
string Echo(string input);
- 이 경우도 이 접근 방식을 채용하면, 기본값으로 사용되는 SOAPAction 값이 ASP.NET 와 WCF 로 같은
것으로 의존하는 필요성을 회피할 수 있습니다.
- SOAP 확장기능은 사용하지 말아 주세요. SOAP 확장기능이 필요한 경우는 그 확장기능을 검토하는 목적의 기능이 WCF
로 이미 제공되어 있지 않은지 어떤지를 확인해 주세요. 이것에 해당하는 경우는 WCF 를 빨리는 도입하지 않는다는 판단을
재검토해 주세요.
상태 관리
서비스에서 상태를 유지할 필요가 없습니다. WCF의 ASP.NET 상호교환모드로 ASP.NET 메커니즘이 지원되어도 ASP.NET 와 WCF는
상태를 관리하는 메커니즘이 완전히 다릅니다.
예외 처리
서비스가 송수신하는 데이터 유형의 구조를 설계할 때는 그 서비스로 발생할 수 있는 클라이언트에 전달할 필요가 생길 수
있는 각종 예외를 나타내는 구조도 설계합니다.
[Serializable]
[XmlRoot(
Namespace="ExplicitNamespace", IsNullable=true)]
public partial class AnticipatedException {
private string anticipatedExceptionInformationField;
public string AnticipatedExceptionInformation {
get {
return this.anticipatedExceptionInformationField;
}
set {
this.anticipatedExceptionInformationField = value;
}
}
}
이러한 클래스에는 자기 자신을 XML에 직렬화(Serialization)하는 기능을 줍니다.
public XmlNode ToXML()
{
XmlSerializer serializer = new XmlSerializer(
typeof(AnticipatedException));
MemoryStream memoryStream = new MemoryStream();
XmlTextWriter writer = new XmlTextWriter(
memoryStream, UnicodeEncoding.UTF8);
serializer.Serialize(writer, this);
XmlDocument document = new XmlDocument();
document.LoadXml(new string(
UnicodeEncoding.UTF8.GetChars(
memoryStream.GetBuffer())).Trim());
return document.DocumentElement;
}
그러면, 이러한 클래스를 사용하고, 명시적으로 예외 처리된 System.Web.Services.Protocols.SoapException
인스턴스에 대해 심화 정보를 제공할 수 있습니다.
AnctipatedException exception = new AnticipatedException();
exception.AnticipatedExceptionInformation = "...";
throw new SoapException(
"Fault occurred",
SoapException.ClientFaultCode,
Context.Request.Url.AbsoluteUri,
exception.ToXML());
이러한 예외 클래스는 WCF의 System.ServiceModel.FaultContract<T> 에서 쉽게 재사용
가능합니다.
throw new FaultException<AnticipatedException>(anticipatedException);
보안
- ASP.NET 2.0 의 프로파일은 사용하지 말아 주세요.
- 서비스에의 접근을 제어하는 목적으로 ACL 를 사용하지 말아 주세요.
- 서비스의 리소스에의 접근을 승인하려면, ASP.NET 2.0 롤 공급자 사용을 검토해 주세요.
WCF 도입
ASP.NET 웹 서비스와 공존
신규의 개발 작업에 WCF 를 채용하면서, ASP.NET 로 개발한 기존의 응용 프로그램의 유지 관리를 속행할 수 있습니다. 모든
시나리오로 .NET 응용 프로그램과의 통신을 쉽게 하기 위해서 최적인 선택사항이 되도록 설계된 WCF 는 소프트웨어의
통신에 관련하는 광범위의 문제에 ASP.NET 에서는 불가능한 방법으로 대응한다는 표준툴로서의 역할을 완수할 수 있습니다.
기존의 ASP.NET 웹 서비스와 같은 컴퓨터에, 새로운 WCF 응용 프로그램을 도입할 수 있습니다. 이러한 ASP.NET
웹 서비스로 사용하고 있다 .NET 가 버전 2.0 미만의 경우는 ASP.NET IIS 등록 도구를 사용하고, 새로운 WCF 응용
프로그램을 호스팅하는 IIS 응용 프로그램에 .NET Framework 2.0 을 선택적으로 도입합니다. ASP.NET
IIS 등록 도구 (Aspnet_regiis.exe) 에 관한 도큐먼트를 참조해 주세요. 이 도구에는 IIS 6 관리 콘솔에 기본
제공되는 사용하기 쉬운 사용자 인터페이스가 있습니다.
WCF 를 사용하고, 기존의 ASP.NET 웹 서비스에 신기능을 추가할 수 있습니다. 거기에는 ASP.NET 상호교환모드로
동작하도록 구성한 WCF 서비스를 IIS 의 기존의 ASP.NET 웹 서비스 응용 프로그램에 추가합니다. ASP.NET
상호교환모드를 사용하면, 새로운 WCF 서비스의 코드가 System.Web.HttpContext 클래스를 통해서, 기존의
ASP.NET 코드와 같은 응용 프로그램 상태정보를 접근 및 업데이트 할 수 있습니다. 또, 같을 클래스 라이브러리 공유도 가능합니다.
ASP.NET 웹 서비스 및 클라이언트의 WCF 이행
WCF 클라이언트는 ASP.NET 웹 서비스를 사용할 수 있습니다.
System.ServiceModel.BasicHttpBinding
을 사용해 구성한 WCF 서비스는 ASP.NET 웹 서비스 클라이언트에 의해서 사용 가능합니다. ASP.NET 웹 서비스는
WCF 응용 프로그램과 공존시킬 수 있어 WCF 를 사용해 기존의 ASP.NET 웹 서비스에 기능을 추가하는 것도 가능합니다. 이상과
같이 WCF 와 ASP.NET 웹 서비스는 다양한 방법으로 병용이 가능한 것 에서 ASP.NET 웹 서비스를 WCF 로 이행하지 않으면
안 되는 절실한 이유는 별로 없습니다.
새로운 기술을 채용하는 목적은 기존의 기술에서는 채울 수 없는
새로운 요건을 만족하여, 그 경우 새롭게 확장된 요건에 맞도록 새로운 솔루션을 설계하는 것이 최선책입니다. 새로운
설계에서는 기존의 시스템 경험이나, 그 시스템을 설계했을 때 에서 축적된 견식을 활용할 수 있습니다. 또한 새로운 설계에서는
단지 기존의 설계를 새로운 플랫폼에 재현하는 것이 아니라, 새로운 기술의 기능을 충분히 활용하는 것을 고려해야 합니다. 새로운
설계의 주된 요소를 프로토 타입화한 단계에서 기존의 시스템의 코드를 새로운 시스템으로 재사용 하는 방법은 스스로 밝혀질 것입니다.
ASP.NET 웹 서비스를 WCF 에 단순하게 이식하는 것이 최선책이라고 생각되는 얼마 안되는 경우를 위해서, 이행을 어떻게
진행할까의 가이드 라인을 다음에 보여줍니다. 서비스 이행 방법, 다음에 클라이언트의 이행 방법에 관한 조언을 보여줍니다.
ASP.NET 웹 서비스의 WCF 이행
- 서비스에 관한 종합적인 테스트 모음이 있는 것을 확인합니다.
- 서비스의 WSDL 를 생성해, 그 서비스의 .asmx 파일과 같은 폴더에 복사를 보존 합니다.
- .NET 2.0 을 사용하도록 ASP.NET 웹 서비스를 업그레이드 합니다. 거기에는 최초로 IIS 의 응용
프로그램에 .NET Framework 2.0 을 도입해, 다음에 Visual Studio 2005 를 사용해 코드변환 순서를
자동화합니다 (자세한 것은
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/webprojectsVS05.asp?frame=true
를 참조). 테스트 모음을 실행합니다.
- System.Web.Services.WebService 특성의 Namespace 및 Name 매개 변수에
명시적인 값이 아직 지정되지 않은 경우 그것을 지정합니다. System.Web.Services.WebMethod
특성의 MessageName 매개 변수에 대해도 똑같이 합니다. 또, 요청을 메서드에 루팅하기 위한 SOAPAction 의
HTTP 헤더에 명시적인 값이 아직 지정 되지 않은 경우는 System.Web.Services.Protocols.SoapDocumentMethod
특성의 Action 매개 변수의 기본값을 명시적으로 지정합니다.
[WebService(Namespace = "http://tempuri.org/", Name = "Adder")]
public class Adder
{
[WebMethod(MessageName = "Add")]
[SoapDocumentMethod(Action = "http://tempuri.org/Add")]
public double Add(SumInput input)
{
double sum = 0.00;
foreach (double inputValue in input.Input)
{
sum += inputValue;
}
return sum;
}
}
- 테스트 모음을 실행합니다.
- 클래스의 메서드의 본문에 있는 실질적인 코드를 다른 클래스로 이동해, 그 클래스를 원본 클래스에서 사용하도록합니다.
[WebService(Namespace = "http://tempuri.org/", Name = "Adder")]
public class Adder
{
[WebMethod(MessageName = "Add")]
[SoapDocumentMethod(Action = "http://tempuri.org/Add")]
public double Add(SumInput input)
{
return new ActualAdder().Add(input);
}
}
internal class ActualAdder
{
internal double Add(SumInput input)
{
double sum = 0.00;
foreach (double inputValue in input.Input)
{
sum += inputValue;
}
return sum;
}
}
- 테스트 모음을 실행합니다.
- ASP.NET 웹 서비스 프로젝트에 WCF 어셈블리 System.ServiceModel 및 System.Runtime.Serialization
참조를 추가합니다.
- WCF 의 svcutil.exe 도구를 실행하고, WSDL 에서 WCF 프록시 클래스를 생성합니다. 생성된 클래스 모듈을
솔루션에 추가합니다.
- 전의 스텝에서 생성된 클래스 모듈에는 인터페이스 정의가 포함되어 있습니다.
[System.ServiceModel.ServiceContractAttribute()]
public interface AdderSoap
{
[System.ServiceModel.OperationContractAttribute(
Action="http://tempuri.org/Add",
ReplyAction="http://tempuri.org/Add")]
AddResponse Add(AddRequest request);
}
Modify the definition of the ASP.NET Web service class so that the class is defined as implementing that interface:
[WebService(Namespace = "http://tempuri.org/", Name = "Adder")]
public class Adder: AdderSoap
{
[WebMethod(MessageName = "Add")]
[SoapDocumentMethod(Action = "http://tempuri.org/Add")]
public double Add(SumInput input)
{
return new ActualAdder().Add(input);
}
public AddResponse Add(AddRequest request)
{
return new AddResponse(
new AddResponseBody(
this.Add(request.Body.input)));
}
}
- 프로젝트를 컴파일 합니다. 스텝 9 로 생성된 코드로 일부의 형식 정의가 중복되어, 오류가 발생할 가능성이
있습니다. 이러한 오류를 정정하려면 일반적으로 전부터 존재하던 형식 정의를 삭제합니다. 테스트 모음을 실행합니다.
- System.Web.Services.WebService,System.Web.Services.WebMethod,System.Web.Services.Protocols.SoapDocumentMethod
특성 등 ASP.NET 고유의 특성을 삭제합니다.
public class Adder: AdderSoap
{
public double Add(SumInput input)
{
return new ActualAdder().Add(input);
}
public AddResponse Add(AddRequest request)
{
return new AddResponse(
new AddResponseBody(
this.Add(request.Body.input)));
}
}
- ASP.NET 웹 서비스가 다음의 한쪽에 의존하고 있었을 경우는 WCF 의 ASP.NET 상호교환모드를
사용하도록 클래스 (즉 WCF 서비스타입)를 구성합니다.
- System.Web.Services.HttpContext 클래스
- ASP.NET 프로파일
- .asmx 파일의 ACL
- IIS 인증 옵션
- ASP.NET 위장 옵션
- ASP.NET 글로벌리제이션
[System.ServiceModel.AspNetCompatibilityRequirements(
RequirementsMode=AspNetCompatbilityRequirementsMode.Require)]
public class Adder: AdderSoap
- 원래의 .asmx 파일 이름을 .asmx.old 로 변경합니다.
- 서비스 용무의 WCF 서비스파일을 작성해, 확장자(extension) .asmx 를 붙여 IIS 의 응용 프로그램 루트에
보존 합니다.
<%@Service Class="MyOrganization.Adder" %>
<%@Assembly Name="MyServiceAssembly" %>
- 서비스의 WCF 구성을 WCF 의 Web.config 파일에 추가합니다. 서비스가 BasicHttpBinding 를
사용해, 전단계에서 작성한 확장자(extension) .asmx 첨부의 서비스파일을 사용해, 자신으로 WSDL 를 생성하지
않고, 대신에 위의 스텝 2 의 WSDL 를 사용하도록 구성합니다. 또, 위의 스텝 10 으로 필요라고 판단되었을 경우는
ASP.NET 상호교환모드를 사용하도록 구성합니다.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<compilation>
<buildProviders>
<remove extension=".asmx" />
<add extension=".asmx"
type=
"System.ServiceModel.ServiceBuildProvider, System.ServiceModel, Version=2.0.0.0,
Culture=neutral,
PublicKeyToken=b77a5c561934e089" />
</buildProviders>
</compilation>
</system.web>
<system.serviceModel>
<services>
<service name="MyOrganization.Adder "
behaviorConfiguration="AdderBehavior">
<endpoint
address=""
binding="basicHttpBinding"
contract="AdderSoap "/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="AdderBehavior">
<metadataPublishing
enableMetadataExchange="true"
enableGetWsdl="true"
enableHelpPage="true"
metadataLocation=
"http://MyHost.com/AdderService/Service.wsdl"/>
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment
aspNetCompatibilityEnabled ="true"/>
</system.serviceModel>
</configuration>
- 구성을 보존 합니다.
- 프로젝트를 컴파일 합니다.
- 테스트 모음을 실행합니다.
ASP.NET 웹 서비스 클라이언트의 WCF 이행
- 클라이언트에 관한 종합적인 테스트 모음이 있는 것을 확인합니다.
- Visual Studio 2005 를 사용하고, 클라이언트 응용 프로그램을 .NET 2.0으로 업그레이드 합니다. 테스트
모음을 실행합니다.
- 클라이언트 프로젝트에서 ASP.NET 프록시 코드를 삭제합니다. 이 코드는 일반적으로 wsdl.exe 도구로 생성한
모듈에 들어가 있습니다.
- svcutil.exe 도구를 사용해 WCF 프록시 코드를 생성합니다. 이 코드를 클라이언트 프로젝트에 추가해, 구성 출력을
클라이언트의 기존 구성 파일에 조인합니다.
- 응용 프로그램을 컴파일 합니다. 기존의 ASP.NET 프록시 유형 참조를 새로운 WCF 프록시 유형 참조에
옮겨놓고, 컴파일에러를 정정합니다.
- 테스트 모음을 실행합니다.
요약
ASP.NET 웹 서비스의 도구는 웹 서비스 구축만을 목적으로 하는데, WCF 에서는 소프트웨어 엔터티를 서로 통신시킬 필요가
있다, 모든 상황으로 사용하는 도구가 제공됩니다. 웹 서비스 개발프로젝트도 WCF는 ASP.NET
웹 서비스보다 많은 웹 서비스 프로토콜을 지원합니다. 이러한 프로토콜은 신뢰성이 높은 세션이나 트랜잭션을 시작해 보다 향상된 솔루션을
실현합니다. 대부분의 경우 추천하는 방법은 새로운 개발 작업에는 WCF 를 채용하면서, 기존의 ASP.NET 웹 서비스 응용 프로그램의
유지 관리를 속행하는 것입니다. WCF 이점을 활용하는 것과 동시에, 기존의 응용 프로그램을 이행하는 비용을 절약할 수 있습니다. 새로운 WCF 응용 프로그램은 기존의 ASP.NET 웹 서비스를 사용할 수 있어 기존의
ASP.NET 응용 프로그램과 공존 가능합니다. 한층 더 WCF 의 ASP.NET 상호교환모드를 이용하고, 기존의 ASP.NET 응용
프로그램의 새로운 운용 기능을 WCF 로 프로그래밍 하는 것도 가능합니다.
