수안이의 컴퓨터 연구실

사용자 환경이란 관련된 콘텐츠 전체와 해당 콘텐츠가 호스팅되는 방식을 함께 일컫는 말로, 이 모든 것에 의해 사용자 환경이 결정됩니다. Windows® Presentation Foundation에서 콘텐츠는 표준 컨트롤, 2D 및 3D 그래픽, 애니메이션, 데이터 바인딩, 레이아웃, 스타일 및 템플릿 지정을 통해 만들어집니다. 그러나 이러한 콘텐츠가 사용자가 눈으로 보고 상호 작용할 수 있는 방식으로 호스팅되지 않는다면 사실상 아무 쓸모없는 것이 됩니다. 콘텐츠는 응용 프로그램 내에 패키지화되어야 하며 창을 통해 표시되어야 합니다. 바로 이것이 응용 프로그램 모델이 편리한 이유입니다.

Windows Presentation Foundation 응용 프로그램 모델은 독립 실행형 응용 프로그램과 브라우저 응용 프로그램이라는 두 가지 응용 프로그램 유형을 구분합니다. 독립 실행형 응용 프로그램에서는 해당 응용 프로그램의 창과 대화 상자, 메시지 상자를 통해 콘텐츠를 표시합니다. 이에 반해 브라우저 응용 프로그램은 브라우저에서 호스팅되는 고유의 페이지로 구성됩니다.

Windows Presentation Foundation은 또한 메뉴 기반 탐색 및 하이퍼링크 기반 탐색이라는 두 가지 유형의 탐색을 구분합니다. 메뉴 기반 응용 프로그램에서 사용자는 기존의 데스크톱 Windows 기반 응용 프로그램과 마찬가지로 메뉴 모음, 도구 모음, 창 및 대화 상자를 통해 콘텐츠와 기능을 탐색하게 됩니다. 하이퍼링크 기반 응용 프로그램에서는 웹 응용 프로그램과 유사한 탐색 환경을 제공합니다.

때문에 독립 실행형 응용 프로그램은 메뉴 기반 탐색을 지원하고, 브라우저 응용 프로그램은 하이퍼링크 기반 탐색을 지원합니다. 그러나 Windows Presentation Foundation 응용 프로그램 모델을 사용하면 이러한 두 가지 요소를 섞어 사용할 수 있습니다. 이러한 경우 하이퍼링크 기반 환경이 부분적으로나 전체적으로, 독립 실행형 응용 프로그램에 통합됩니다. 이와 같은 조합은 반드시 사용자의 이점을 극대화할 수 있는 환경 유형을 기반으로 해야 합니다. 사용할 환경을 결정한 다음에는, Windows Presentation Foundation 응용 프로그램 모델을 통해 이를 빌드할 수 있습니다.

그림 1의 샘플 상자 응용 프로그램을 살펴보겠습니다. 이 응용 프로그램은 독립 실행형이며 메뉴 기반 응용 프로그램으로, 상자 목록을 확인하고, 주문하며, 주문 내용을 보고, 상자 주문을 삭제하는 등의 업무를 수행할 수 있습니다. 이러한 사용자 환경을 제공하려면 모든 응용 프로그램 모델의 기본이 되는 응용 프로그램 생성 방법에 대해 알아야 합니다.

그림 1 상자 응용 프로그램 (작게 보려면 이미지를 클릭하십시오.)

그림 1 상자 응용 프로그램 (크게 보려면 이미지를 클릭하십시오.)

Windows 기반 응용 프로그램은 진입점과 메시지 루프를 모두 포함하는 표준 작업으로 구성되어 있으며 다음과 같은 일반적인 응용 프로그램 서비스가 필요할 수도 있습니다.

• 명령줄 매개 변수 처리
• 종료 코드 반환
• 응용 프로그램 범위 상태
• 처리되지 않는 예외의 검색 및 응답
• 응용 프로그램 수명 관리

Windows Presentation Foundation을 사용하면 작업 및 서비스를 모두 단일 유형인 System.Windows.Application으로 중앙 집중화할 수 있습니다. 이러한 System.Windows.Application은 태그(XAML), 코드(C# 또는 Visual Basic®) 또는 둘의 조합(태그 및 코드 숨김)을 통해 사용할 수 있습니다. Visual Studio® 2005에서 .NET Framework 3.0(이전의 WinFX®) Windows 응용 프로그램 프로젝트에 새로운 인스턴스를 자동으로 추가하므로 응용 프로그램에는 매우 유용합니다.

<!--App.xaml (markup)-->
<Application 
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  x:Class="BoxApplicationWindow.App" 
/>

// App.xaml.cs (코드 숨김)
public partial class App : Application { ... }

Windows Forms 및 Win32®와 같은 Windows 프레젠테이션 기술을 이전에 프로그래밍해 본 적이 있다면, 새로운 기능에 더욱 놀라게 될 것입니다. 이번에는 진입점을 비롯하여, 표준 Windows 기반 응용 프로그램 작업을 설정할 때 사용했던 것처럼 원격으로 보이는 코드를 전혀 사용하지 않습니다. 왜냐하면 사용자를 위해 응용 프로그램 작업이 생성되기 때문입니다. 그림 2에서 확인할 수 있듯이, 응용 프로그램 작업은 Visual Studio 2005에서 응용 프로그램 태그 파일을 ApplicationDefinition 빌드 작업으로 구성한 결과물입니다.

그림 2 응용 프로그램 XAML 파일 설정

내부적으로 이 코드에 상응하는 코드가 만들어집니다.

// App.cs
using System; 

public partial class App : Application 
{
  [STAThread]
  public static void Main() 
  {
    // 응용 프로그램 초기화 및 실행
    App application = new App();
    application.Run();
  }
}

정확히 무엇이 만들어지는지는 중요하지 않으므로 사용자는 복잡한 코드를 직접 작성하거나 이해할 필요가 없습니다. 사용자는 최신 Microsoft 프레젠테이션 기술의 가장 완벽한 응용 프로그램 추상화를 지원받고 있으며 이를 이용하면 태그 하나만으로도 실행되는 응용 프로그램을 만들 수 있습니다. 사용자가 수행해야 할 작업은 응용 프로그램 서비스를 사용하는 것뿐입니다. 독립 실행형 응용 프로그램의 경우, 응용 프로그램이 시작될 때 창이 나타납니다.

창

Windows Presentation Foundation에서 창은 Window 클래스에 해당합니다. 창은 독립 실행형 응용 프로그램의 콘텐츠 호스팅에서 가장 핵심적인 단위입니다. 사용자가 Visual Studio 2005에서 프로젝트 | 새 항목 추가 | WinFX 창을 선택하면 다음과 같은 내용이 생성되며 프로젝트에 창 정의를 추가할 수 있습니다.

<!--MainWindow.xaml (markup)--> 
<Window 
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  x:Class="BoxApplication.MainWindow"
</Window> 

// MainWindow.xaml.cs (코드 숨김)
using System.Windows;
public partial class MainWindow : Window { ... }

창 정의가 추가되면 Visual Studio 2005에서는 자동으로 페이지에 태그 파일 빌드 유형을 구성합니다. 빌드된 태그는 URI(Uniform Resource Identifier)에 의해서만 식별되는 특별한 유형의 리소스로 변환됩니다. 결과적으로 이러한 과정을 통해 Windows Presentation Foundation은 URI로부터 창을 선언적으로 로드할 수 있으며 사용자는 이러한 기능을 사용하여 응용 프로그램이 시작될 때 창이 자동으로 열리도록 지정할 수 있습니다. 아래와 같이 태그에서 Application.StartupUri 특성을 설정합니다.

  <!--App.xaml (markup)-->
  <Application ... StartupUri="MainWindow.xaml"  />

이렇게 하면 그림 3과 같은 창을 만들고 표시할 수 있습니다. 다른 모든 창과 마찬가지로, Windows Presentation Foundation 창에는 Windows Presentation Foundation 콘텐츠 및 컨트롤이 배치되는 클라이언트 영역이 있으며, 테두리, 제목 표시줄 및 이와 관련한 다양한 항목이 포함된 비클라이언트 영역이 있습니다.

그림 3 창과 그 구성 부분

Application.StartupUri에서 만들어진 창은 모덜리스 유형입니다. 즉, 사용자는 해당 응용 프로그램 내에서 다른 창을 사용해도 전혀 제약을 받지 않습니다. 지금까지 다른 창을 만들어 본 적이 없다면 그다지 실감이 나지 않을 수도 있습니다. 다른 모덜리스 창을 표시해야 한다면 복잡한 응용 프로그램인 경우에도 Window.Show를 간단하게 호출하기만 하면 됩니다.

// MainWindow.xaml.cs (코드 숨김)
public partial class MainWindow : Window 
{ 
  void helpContentsMenuItem_Click(object sender, RoutedEventArgs e) 
  {
    HelpWindow window = new HelpWindow();
    window.Owner = this; // 창을 항상 위에 표시
    window.Show();
  }
  ... 
 }

Windows Presentation Foundation은 모달 창도 지원합니다. 이 경우 응용 프로그램 내에서 다른 창을 사용하려고 하면 제약을 받게 됩니다. 항상 그런 것은 아니지만 모달 창은 주로 대화 상자로 사용되며 새 주문을 생성하는 것과 같은 업무를 진행하는 데 필요한 데이터를 수집하게 됩니다. Windows Presentation Foundation에서 모달 창을 표시하려면 Window.ShowDialog를 호출해야 합니다(그림 4 참조).

Window 클래스는 사용자가 대화 상자를 수락 또는 거절하거나 적절한 처리를 위한 호출 코드에 대해 선택 사항을 반환하는 것과 같은 일반적인 대화 상자 동작을 지원합니다.

메시지 상자는 사용자에게 정보를 표시하거나 질문하기 위한 특별한 유형의 대화 상자이며 Windows Presentation Foundation에서 MessageBox 형식을 통해 지원됩니다.

// MainWindow.xaml.cs (코드 숨김)
public partial class MainWindow : Window 
{ 
  void aboutMenuItem_Click(object sender, RoutedEventArgs e) 
  {
    MessageBox.Show("Box Application, Version 1.0");
  }
  ... 
}

메시지 상자, 대화 상자, 창 및 응용 프로그램 폼은 메뉴 기반의 독립 실행형 응용 프로그램 개발 모델의 핵심 기능입니다. 이러한 기능은 이전의 프레젠테이션 기술을 통해서도 계속해서 지원되어 왔습니다. 그러나 Windows Presentation Foundation에서 이 기능은 콘텐츠 탐색의 기본 단위인 페이지에서 시작하는 하이퍼링크 기반 탐색 지원으로 확장되었습니다.

Page 클래스

페이지는 Windows Presentation Foundation에서 HTML 웹 페이지와 유사한 부분으로 웹을 대중화하는 데 기여한 요소입니다. 앞서 언급한 바와 같이, Windows Presentation Foundation은 독립 실행형 응용 프로그램과 브라우저 응용 프로그램 모두에 걸쳐 하이퍼링크 기반 탐색을 지원합니다. Windows Presentation Foundation의 하이퍼링크 기반 탐색 환경에서 콘텐츠의 기본이 되는 것은 페이지입니다.

사용자가 Visual Studio 2005에서 프로젝트 | 새 파일 추가 | WinFX 페이지를 선택하면 프로젝트에 태그 및 코드 숨김 페이지 정의를 추가할 수 있습니다. 그림 5와 같은 코드가 생성됩니다.

Page 태그 파일은 Page 빌드 항목으로 구성됩니다. 창과 마찬가지로 페이지도 URI에서 로드되도록 구성됩니다. 즉, 응용 프로그램이 시작될 때 자동으로 페이지를 로드하도록 Application.StartupUri를 구성할 수 있습니다.

<!--App.xaml (markup)-->
<Application ... StartupUri="HomePage.xaml" />

Page 클래스는 창이 아닐 뿐 아니라 Window에서 파생되지 않으므로 스스로 호스팅할 수 없습니다. 특정 페이지가 StartupUri로 설정된 경우 Application 클래스에서 이를 감지하며 이에 따라 응용 프로그램은 페이지를 호스팅할 수 있는 창을 만들게 됩니다.

Hyperlink 클래스

모든 하이퍼링크 기반 응용 프로그램은 둘 이상의 XAML 페이지를 포함하므로 사용자에게 이러한 페이지를 탐색할 수 있는 방법을 제공해야 합니다. Windows Presentation Foundation을 사용하면 하이퍼링크로 하이퍼링크 기반 탐색을 수행할 수 있습니다. 사용자는 페이지에 다음과 같이 하이퍼링크를 추가할 수 있습니다.

<!--HomePage.xaml (markup)-->
<Page ... >
  ...
      <Hyperlink NavigateUri=          "OrderingGuidelinesPage.xaml">
    Ordering Guidelines
  </Hyperlink>
  ...
</Page>

이 하이퍼링크는 HTML HREF와 동일한 기반 프로그래밍 모델을 사용하여 XAML 페이지를 탐색할 수 있도록 구성되었습니다. 탐색할 URI 및 사용자에게 표시될 텍스트를 지정한 다음 클릭하여 탐색을 시작합니다. 이 문서의 예에서는 URI는 OrderingGuidelinesPage.xaml, 사용자에게 표시할 텍스트는 "Ordering Guidelines"입니다.

HTML 기반 웹 페이지에는 검색 가능한 콘텐츠가 무궁무진하므로 Windows Presentation Foundation과 하이퍼링크를 사용하면 웹 기반의 콘텐츠를 자유롭게 탐색할 수 있습니다. 예를 들어 상자 응용 프로그램의 웹 사이트에 주문 지침이 이미 있는 경우 이를 응용 프로그램 내에서 XAML 페이지로 복제하지 않고 간단히 NavigateUri 속성 값을 변경할 수 있습니다.

<!--HomePage.xaml (markup)-->
<Page ... >
  ...
  <Hyperlink NavigateUri="OrderingGuidelinesPage.html">
    Ordering Guidelines
  </Hyperlink>
  ...
</Page>

NavigationWindow

이 시점에서 몇 가지 의문 사항이 있을 수 있습니다. 페이지가 창이 아니라면 창은 대체 어디서 호스팅되는 것일까요? 하이퍼링크를 클릭할 경우 실제로 탐색 작업을 처리하는 것은 무엇일까요? 그리고 Windows Presentation Foundation 응용 프로그램에서 HTML 웹 페이지 콘텐츠는 어떻게 표시되는 것일까요? 이러한 모든 것을 바로 NavigationWindow가 처리합니다.

Application.StartupUri를 XAML 또는 HTML 페이지로 설정할 경우, 응용 프로그램(XAML 또는 HTML 페이지에서 자체적으로 창을 제공할 수 없음)은 해당 내용을 호스팅할 NavigationWindow의 인스턴스를 만듭니다. NavigationWindow는 Window에서 파생되었으며 그림 6과 같이 브라우저 모양으로 확장됩니다.

그림 6 NavigationWindow를 통해 생성

사용자가 XAML 페이지에 표시된 하이퍼링크를 클릭하면, 하이퍼링크는 특정 URI를 탐색할 것을 NavigationWindow에 요청합니다. NavigationWindow는 해당 URI에 있는 페이지를 로드하고 이를 호스팅합니다. 로딩된 페이지의 URI 위치는 NavigationWindow.Source 속성에 저장되며 로딩된 페이지 콘텐츠는 NavigationWindow.Content 속성에서 제공합니다.

콘텐츠가 변경되는 경우, 탐색이 이루어진 것으로 간주되므로 탐색 기록에 이전 콘텐츠가 추가됩니다. 이 또한 NavigationWindow에 의해 관리됩니다. 탐색 UI에서는 탐색에 사용할 두 가지 단추와 드롭다운 목록을 제공합니다. NavigationWindow의 기본 크롬에 제한될 필요는 없으며 Windows Presentation Foundation의 스타일 지원을 사용하면 고유한 탐색 UI를 쉽게 만들 수 있습니다.

지금까지 하이퍼링크를 통해 탐색을 수행해야 하는 URI를 구성하는 과정에 태그를 사용하는 방법을 살펴보았습니다. 그러나 선언적으로 탐색을 수행할 수 없는 경우가 있습니다. 예를 들어 주문을 확인하려는 경우 Page의 인스턴스를 만들어 확인할 주문에 전달해야 합니다. 이러한 과정은 선언적으로 이루어지지 않습니다. 그 대신 그림 7과 같이 코드를 사용해야 합니다.

하이퍼링크를 클릭하면 Click 이벤트 처리기가 현재 선택된 주문을 받아 인스턴스화 과정에서 이를 ViewOrderPage에 전달합니다. 그 다음 호스트 NavigationWindow의 Navigate 메서드를 호출합니다. 이 메서드는 URI가 아닌 개체로 페이지를 탐색합니다.

호스트 NavigationWindow에 대한 참조를 가져와야 하는 것이 이상하다고 여겨질 수도 있습니다. 이를 수행해야 하는 이유는 Page를 실제로 호스팅하는 것이 무엇인지에 대한 명시적인 정보가 없기 때문입니다. Page는 고유의 Parent 속성을 사용하여 호스트를 확인할 수 있지만 이러한 Parent 속성은 특정 호스트 형식에 대해 엄격하게 형식이 지정된 참조를 반환하지 않고 DependencyObject에 참조를 반환합니다. 따라서 특정 형식으로 Parent를 캐스팅함으로써 Page를 호스팅하는 것이 무엇인지 알게 되는 것입니다. 그러나 Page의 호스트는 여러 다른 형식일 수 있습니다. 결과적으로 다양한 형식의 호스트에서 Page를 호스팅하려는 경우, 호스트 독립적인 방법으로 프로그래밍 방식의 탐색을 수행해야 합니다.

NavigationService

Windows Presentation Foundation에서 페이지와 페이지 호스트 간의 독립성은 NavigationService에 의해 설정됩니다. NavigationService는 탐색, 탐색 기록, 탐색 수명, 콘텐츠 및 콘텐츠 조각에 대한 탐색 서비스 검색과 같은 탐색 엔진의 기본적인 메커니즘을 구현하는 역할을 수행합니다. 그림 8에 서는 NavigationService 형식의 기본 멤버를 보여 줍니다. NavigationWindow는 실제로 고유의 탐색 엔진을 구현하지 않으며 NavigationService의 고유한 인스턴스를 사용합니다. Page는 GetNavigationService를 사용하여 Page를 호스팅하는 NavigationWindow의 NavigationService에 대한 참조를 얻을 수 있습니다.

// HomePage.xaml.cs (코드 숨김)
public partial class HomePage : Page 
{ 
  void viewHyperlink_Click(object sender, RoutedEventArgs e) 
  {
    // 주문 보기
    ViewOrderPage page = new ViewOrderPage(GetSelectedOrder());
    NavigationService ns = 
      NavigationService.GetNavigationService(this);
    ns.Navigate(page);
  }

  Order GetSelectedOrder() { ... }
  ...
}

이와 같은 방법을 사용할 경우 Page는 호스트에 대한 정보 없이도 탐색을 수행할 수 있습니다. Page에서 특수 도우미 속성인 NavigationService를 제공하도록 하는 이러한 방법은 매우 일반적이며 동일한 결과를 얻을 수 있습니다.

// HomePage.xaml.cs (코드 숨김)
public partial class HomePage : Page 
{ 
  void viewHyperlink_Click(object sender, RoutedEventArgs e) 
  {
    // 주문 보기
    ViewOrderPage page = new ViewOrderPage(GetSelectedOrder());
    this.NavigationService.Navigate(page);
  }
  
  Order GetSelectedOrder () { ... }
  ...
}

그림 9에서는 NavigationWindow, NavigationService 및 Page 간의 관계를 보여 주고 있습니다. 그림에서 확인할 수 있듯이, NavigationWindow는 NavigationService의 Content 속성을 재구현합니다. NavigationWindow는 이러한 방법을 통해 대부분의 NavigationService 멤버를 재구현하며 여기에 멤버를 추가하기도 합니다. 예를 들어 BackStack 및 ForwardStack 속성을 각각 사용하여 탐색 기록 앞뒤에 있는 콘텐츠를 열거할 수 있습니다.

그림 9 관계

NavigationService를 집계하는 고유한 사용자 지정 형식을 만들 수는 없습니다. public 형식이기는 하지만 인스턴스화를 방해하는 내부 생성자가 있습니다. 그 대신 세 개의 Windows Presentation Foundation NavigationService 집계 중 한 가지를 기반으로 콘텐츠를 호스팅해야 합니다. 이러한 것을 통틀어 탐색기(navigator)라고 하며 여기에는 NavigationWindow, 프레임 및 브라우저(Windows Presentation Foundation 1.0 버전용 Internet Explorer® 6 및 7만 사용 가능)가 포함됩니다. 고유한 NavigationService 속성을 사용하여 페이지를 코딩할 경우 그림 10과 같이 세 가지 집계 모두에서 변경 없이 호스팅될 수 있습니다.

그림 10 탐색을 위한 코드 사용

가장 흥미로운 부분은 단일 독립 실행형 응용 프로그램 내에서 페이지를 호스팅할 수 있을 뿐 아니라 Internet Explorer를 사용하여 원하는 위치 어디서든 호스팅할 수 있다는 사실일 것입니다.

XAML 브라우저 응용 프로그램

NavigationWindow, 페이지 및 하이퍼링크는 독립 실행형 응용 프로그램 내에서 편리한 방식으로 브라우저 스타일의 사용자 환경을 제공합니다. 간단히 말해 NavigationWindow는 현재 우리가 사용하고 있는 브라우저의 즐겨찾기나 검색 탭 등과 같은 보조 기능이 없을 뿐 엄연한 브라우저입니다. 대부분의 사용자는 브라우저 사용에 능숙하기 때문에 동일한 수준의 기능을 제공하는 응용 프로그램이나 브라우저 통합형 응용 프로그램을 사용하는 것에 불편함을 느끼지 않습니다. 브라우저 호스팅 환경 및 하이퍼링크 기반 환경을 사용함으로써 응용 프로그램이 더 많은 혜택을 제공한다면 XBAP(Windows Presentation Foundation XAML Browser Applications)는 바로 그러한 것을 가능하게 하는 프로그램입니다.

샘플 응용 프로그램의 XBAP 버전을 만들려면 Visual Studio 2005에서 새로운 .NET Framework 3.0 웹 브라우저 응용 프로그램을 만드십시오. 그 다음 샘플의 NavigationWindow 버전에서 파일을 복사하면 됩니다(응용 프로그램 정의 제외). Internet Explorer에서 호스팅되어 실행되는 결과 응용 프로그램은 그림 11에서 볼 수 있습니다.

그림 11 Internet Explorer에서 호스팅되는 응용 프로그램

인트라넷이나 인터넷을 통해 XBAP를 웹 서버에 게시할 수도 있고 실행할 수도 있습니다. .NET Framework 3.0에 포함된 ClickOnce 배포를 통해 이러한 작업을 수행할 수 있습니다. MSBuild는 ClickOnce를 사용하기 위해 사용자가 실행하게 될 실행 파일을 만들고, ClickOnce에서 해당 실행 파일을 다운로드 및 실행하는 데 필요한 두 개의 매니페스트 파일도 만듭니다. 이 중 하나가 응용 프로그램 매니페스트이며 파일 확장명은 .xbap입니다. 응용 프로그램 매니페스트는 사용자가 XBAP를 실행하고자 하는 경우 실제로 탐색하게 되는 파일입니다. 실행 프로세스는 자연스럽게 진행됩니다. XBAP 응용 프로그램을 탐색하는 환경은 브라우저에서 다른 응용 프로그램을 탐색하는 것과 다르지 않습니다.

인터넷을 통해 응용 프로그램을 시작하는 경우 보안이 문제가 될 수 있습니다. 그러한 이유로 XBAP는 설치되지 않습니다. 또한 XBAP는 .NET Framework의 CAS(Code Access Security)를 활용하여 강제 보안 샌드박스(security sandbox)를 통해 사용자를 악성 코드로부터 보호합니다. XBAP는 인터넷 영역에서 시작된 응용 프로그램에 대해 허용된 항목만 실행하며 제한된 작업만 수행합니다. XBAP가 인터넷 영역 내에서 사용할 수 없는 기능을 실행하려고 하는 경우에는 예외 오류가 발생하며 해당 응용 프로그램은 실행이 중단됩니다.

인터넷 영역 권한을 설정할 경우 창 표시, SaveFileDialog 사용, 레지스트리 액세스 및 스크립트를 통한 HTML DOM(Document Object Model) 액세스와 같은 Windows Presentation Foundation 1.0의 다양한 기능을 사용할 수 없게 됩니다. 그러나 CAS 보안에 기반을 둔 XBAP 응용 프로그램의 장점을 활용하기 위해 위와 같은 기능의 사용을 포기하는 경우에도, Windows Presentation Foundation의 핵심적인 기능은 사용할 수 있습니다.

프레임

프레임은 브라우저 스타일의 사용자 환경을 기타 탐색기(독립 실행형 또는 브라우저 기반, 메뉴 또는 하이퍼링크 기반)에 의해 호스팅될 수 있는 콘텐츠로 포함합니다. 이러한 유연성으로 인해 사용자는 원래 의도했던 사용자 환경에 맞춰 이와 같은 기능을 어떤 식으로 사용할지 결정할 수 있습니다.

메뉴 기반의 독립 실행형 응용 프로그램은 도움말 파일과 같은 문서 스타일의 콘텐츠를 통해 탐색하기에는 적합하지 않습니다. 이와 같은 작업에는 하이퍼링크 기반 응용 프로그램이 적합하며 링크는 독립 실행형 응용 프로그램의 창에 쉽게 포함될 수 있습니다. 아래의 그림 12를 참조하십시오. 다음의 태그를 통해 이를 수행할 수 있습니다.

    <!--HelpDialog.xaml (markup)-->
<Window ... >
    <DockPanel>
        <TextBlock 
          Padding="20,20,20,20" 
          DockPanel.Dock="Top" 
          TextWrapping="Wrap" 
          FontSize="15" 
          FontWeight="Bold" >
            Box Application Help
        </TextBlock>
        <Frame Padding="20,0,20,0"           Source="HelpPageContents.xaml" />
    </DockPanel>
</Window>

또는, Windows Presentation Foundation 페이지의 콘텐츠 내에서 호스팅하는 방식으로 프레임을 HTML IFRAME 요소와 같이 사용할 수 있습니다. 그림 13을 참조하십시오. 이에 대한 태그는 다음과 같습니다.

 <!--HelpPage.xaml (markup)-->
 <Page ... >
     <DockPanel>
         <TextBlock 
           Padding="20,20,20,20" 
           DockPanel.Dock="Top" 
           TextWrapping="Wrap" 
           FontSize="15" 
           FontWeight="Bold" >
             Box Application Help
         </TextBlock>
         <Frame ... Source="HelpPageContents.xaml" />
     </DockPanel>
</Page>

그림 12 독립 실행형 창의 검색 가능한 콘텐츠

기본적으로, 프레임이 콘텐츠 내에서 직접 호스팅되거나 다른 탐색기에 의해 간접적으로 호스팅되는 경우 프레임은 부모 탐색기에서 관리하는 탐색 서비스를 사용합니다. 이는 프레임의 탐색 기록이 프레임의 부모 탐색기의 탐색 기록과 함께 저장되어 있다는 것을 의미합니다. 따라서 부모 탐색기의 탐색 기록을 탐색하기 전에 프레임의 탐색 기록을 앞뒤로 모두 탐색해야 합니다. 부모 탐색기가 여러 페이지에서 공유할 수 있는 콘텐츠를 호스팅하는 경우에는 이 방법도 나쁘지 않습니다. 이는 ASP.NET의 마스터/자식 콘텐츠의 상황과 일정 부분 유사합니다.

그림 13 콘텐츠 내에서 호스팅되는 프레임 (작게 보려면 이미지를 클릭하십시오.)

그림 13 콘텐츠 내에서 호스팅되는 프레임 (크게 보려면 이미지를 클릭하십시오.)

반면 한 개의 프레임의 여러 페이지가 단일 논리 콘텐츠 집합을 구성하는 탐색의 경우에는 이 같은 방식이 사용자에게 고역일 수 있습니다. 이러한 예로 한 개 이상의 도움말 페이지가 아닌 단일 도움말 파일을 들 수 있습니다. 사용자가 도움말로 들어가 적절한 도움말 페이지를 탐색할 경우, 지금까지 찾아본 모든 도움말 페이지를 뒤로 돌아가 탐색하지 않고 이전 부모 페이지로 바로 돌아가고 싶을 것입니다. 이런 경우 JournalOwnership 속성을 다음과 같이 설정하여 프레임에서 고유한 탐색 기록을 사용하도록 할 수 있습니다.

<Page ... >
  ...
  <Frame ... JournalOwnership="OwnsJournal" />
  ...
</Page>

JournalOwnership은 프레임이 어떤 “기사”를 사용할지(내부 기사 형식은 탐색 기록을 Windows Presentation Foundation 내에 캡슐화) 결정하도록 설정하는 속성으로 JournalOwnership의 열거 값 중 하나가 될 수 있습니다.

enum JournalOwnership 
{
  Automatic,        // Frame 또는 NavigationWindow에서 호스팅하는 경우 
                    // "UsesParentJournal", 그렇지 않은 경우 
                    // "OwnsJournal"(기본값)
  OwnsJournal,      // Frame에서 탐색 기록 관리
  UsesParentJournal // Frame의 호스트에서 탐색 기록 관리}

프레임이 고유의 탐색 기록을 갖게 되면 그림 14와 같이 그 차이를 명확히 보여 주는 프레임 고유의 탐색 사용자 인터페이스를 표시하게 됩니다.

그림 14 프레임 고유의 탐색 기록 (작게 보려면 이미지를 클릭하십시오.)

그림 14 프레임 고유의 탐색 기록 (크게 보려면 이미지를 클릭하십시오.)

Windows Presentation Foundation 리소스

지금까지 응용 프로그램 어셈블리에 포함되는 페이지에 대해 알아 보았습니다. 콘텐츠는 다양한 위치로부터 로드될 수 있습니다. 코드는 코드를 사용하는 어셈블리에 포함될 수도 있고, 참조 어셈블리에 포함될 수도 있습니다. 아니면 어떤 어셈블리에도 포함되지 않는 느슨한 콘텐츠(loose content) 파일로 구성될 수도 있습니다. 느슨한 콘텐츠는 로컬 디스크나 파일 공유, 또는 웹 사이트에 위치할 수 있습니다. 콘텐츠 조각은 포함된 것이든 느슨한 것이든 관계없이 페이지가 아닙니다. 콘텐츠에는 이미지, 동영상, 오디오와 같은 다양한 미디어가 포함될 수 있습니다. 또한 콘텐츠는 특정 응용 프로그램에 속할 필요도 없습니다. 다른 웹 응용 프로그램에 속하는 HTML 페이지 역시 마찬가지입니다.

이러한 유연성으로 인해 개발자들은 더욱 쉽게 다양한 종류의 시나리오를 처리할 수 있습니다. 하나의 응용 프로그램에 특화된 콘텐츠가 있을 수 있습니다. 또한 그에 반해 해당 응용 프로그램은 이러한 콘텐츠에 매우 독립적일 수 있습니다. 이런 경우 해당 콘텐츠를 어셈블리에 적절하게 포함하는 방법으로 응용 프로그램과 함께 배포합니다. 콘텐츠가 정기적으로 변경되어 새로운 콘텐츠를 다시 배포하기 위해 지속적으로 어셈블리를 다시 빌드해야 하는 응용 프로그램의 경우에는 느슨한 콘텐츠를 지원하기도 합니다. 느슨한 콘텐츠는 공용 위치에 존재하므로 인터넷 및 인트라넷 기반의 XBAP 응용 프로그램은 불필요한 어셈블리를 다운받지 않아도 됩니다. 또한 여러 응용 프로그램에서 콘텐츠를 공유하는 경우도 있습니다. 그러나 이 경우 가용성이 보장되어야 합니다.

이러한 유연성을 활용하기 위해 Windows Presentation Foundation에서는 고유 식별 및 리소스 로드를 위한 특수 메커니즘을 통합했습니다. 이 메커니즘에서는 콘텐츠가 어디에 위치하는지, 콘텐츠가 포함된 것인지 아니면 느슨한 콘텐츠인지 하는 것은 아무런 문제가 되지 않습니다. 이 메커니즘의 기초는 고유 URI를 사용하여 응용 프로그램 리소스를 확인할 수 있는 확장 가능한 구성표인 Pack URI 구성표입니다. Windows Presentation Foundation은 Pack URI 구성표를 사용하여 콘텐츠 로딩과 관련한 여러 가지 일반적인 시나리오를 지원합니다.

이 기사 전체에 걸친 샘플 코드에서는 Application.StartupUri 및 Hyperlink.NavigateUri가 사용될 때마다 Pack URI를 사용하여 창 및 페이지를 확인하고 로드하였습니다.

<!--App.xaml (markup)-->
<Application ... StartupUri="HomePage.xaml" />

이 예는 사용자의 입력 작업을 간소화시켜 주는 것으로, 상대 Pack URI가 사용되었습니다. 이 상대 Pack URI를 절대 Pack URI로 표시하면 다음과 같습니다.

pack://application:,,,/HomePage.xaml

절대 Pack URI는 구성표(pack://), 인증 기관(application:), 경로(,/HomePage.xaml)의 세 가지 주요 부분으로 구성되어 있습니다. 인증 기관은 리소스가 있는 컨테이너의 유형을 나타내며, 경로는 컨테이너에 상대적인 리소스의 위치를 나타냅니다. "application:" 컨테이너는 실제 어셈블리이며 경로는 해당 어셈블리의 루트에 상대적인 리소스의 위치입니다.

절대 Pack URI 또는 상대 Pack URI 중 하나를 사용할 때 콘텐츠는 어셈블리 내에 포함되거나 응용 프로그램 실행 파일에 상대적인 위치에 저장되는 XAML 사용 완화 파일로 존재하게 됩니다. 응용 프로그램 실행 파일과 동일한 폴더 내에 존재하는 XAML 사용 완화 페이지의 경우 Pack URI는 다음과 같습니다.

pack://application:,,,/HomePage.xaml

XAML 사용 완화 파일에 대한 Pack URI는 동일한 이름의 포함된 파일에 대한 Pack URI와 같습니다. 이 둘을 구분하기 위해 Windows Presentation Foundation에서는 기본 확인 메커니즘을 사용하여 어셈블리 내에서 느슨한 리소스를 찾기 전에 먼저 포함된 리소스를 찾습니다.

Pack URI는 참조된 어셈블리 내에 포함된 Windows Presentation Foundation 리소스에 액세스할 때에도 사용할 수 있으며 다음과 같이 약간 다른 구문으로 표시됩니다.

pack://application:,,,/BoxApplicationLibrary;component/HomePage.xaml

이에 해당하는 상대 Pack URI는 다음과 같습니다.

/BoxApplicationLibrary;component/HomePage.xaml

Pack URI를 사용하면 응용 프로그램 원본 위치(응용 프로그램이 시작된 위치)의 리소스를 찾아 로드할 수 있습니다. XBAP 응용 프로그램이 웹 서버에서 시작된 경우 콘텐츠를 최신으로 유지하는 것은 새 콘텐츠를 해당 응용 프로그램의 게시 위치에 끌어 놓는 것만큼 간단합니다. 원본 위치의 느슨한 리소스에 액세스하려면 절대적으로 사용될 수 있는 특수한 형식의 다른 Pack URI를 사용해야 합니다.

pack://siteoforigin:,,,/HomePage.xaml

포함된 페이지 또는 느슨한 페이지와 같은 모든 페이지에 대해 해당 페이지의 조각에 대한 탐색을 사용할 수 있습니다. 웹 스타일 조각 탐색과 같은 방법을 사용하면 됩니다. 다음과 같이 XAML 요소에 Name 특성을 부여함으로써 페이지 조각을 정의할 수 있습니다.

<Page ... >
   <TextBlock Name="Paragraph1" TextWrapping="Wrap">
     ...
   </TextBlock>
</Page>

페이지 조각을 탐색하려면 다음과 같이 페이지 URI에 접미사 "#XAMLElementName"을 추가한 특수한 Pack URI를 사용해야 합니다.

HelpPage3.xaml#Paragraph3

PageFunction

다양한 위치의 하이퍼링크 기반 응용 프로그램에서 파생된 콘텐츠는 여러 다른 위치에 대한 탐색을 허용하므로 작업을 완료하는 것이 어려울 수 있습니다. 하이퍼링크 기반 응용 프로그램에서는 사용자가 특정 페이지를 탐색하는 것을 제한하는 것이 어렵기 때문입니다. 응용 프로그램에서 많은 하이퍼링크를 제공한다 해도 사용자는 브라우저의 주소 표시줄을 통해 가고자 하는 곳으로 이동할 수 있습니다. 결과적으로 사용자는 작업 완료 여부와 관계없이 작업이 시작된 페이지를 그대로 두고 다른 페이지로 이동할 수도 있는 것입니다. 웹에서는 세션 상태 등을 기반으로 하여 웹 페이지에 대한 대화 상자와 유사한 스타일의 동작을 만들 수 있는 여러 가지 방법이 있습니다. 그러나 이러한 방법은 많은 비용이 듭니다. 대화 상자를 통해 문제를 해결할 수 있지만 보안 문제로 인해, 부분적으로 신뢰하는 인터넷 영역에서 실행되는 XBAP와 같은 응용 프로그램에서는 창을 인스턴스화할 수 없습니다.

그러나 Windows Presentation Foundation은 Page 함수를 사용하여 모달 대화 상자 스타일의 메커니즘을 지원합니다. 이는 Page에서 간접적으로 파생되는 generic PageFunction 형식에 캡슐화됩니다. PageFunction은 Page와 유사한 형태이며 유사한 스타일로 빌드됩니다. 그림 15를 참조하십시오.

이러한 Page 함수의 용도는 주문에 의해 캡슐화되는 새 주문 정보를 수집하는 것입니다. 대부분의 작업에서 데이터를 이러한 방식으로 처리하므로 PageFunction은 generic이며 특정 데이터 부분(태그에 대한 특수한 x:TypeArguments 특성)에 대해서만 작동하도록 선언됩니다. x:TypeArguments 값과 generic PageFunction의 형식 인수가 일치하지 않는 경우 컴파일 오류가 발생합니다.

PageFunction을 호출하려면 호출 페이지는 PageFunction을 인스턴스화하고 이를 수동으로 탐색해야 합니다.

// HomePage.cs (코드 숨김)
public partial class HomePage : Page 
{
  void orderHyperlink_Click(object sender, RoutedEventArgs e) 
  {
    OrderABoxPageFunction pageFunction = new OrderABoxPageFunction();
    pageFunction.Return += new ReturnEventHandler<Order>(
      OrderABoxPageFunction_Returned);
    this.NavigationService.Navigate(pageFunction);
  }
  ...
}

그 다음, PageFunction은 호출 페이지에 결과를 반환하기 전에 사용자가 페이지에 대한 작업을 완료할 수 있도록 해야 합니다.

// OrderABoxPageFunction.cs (코드 숨김)
public partial class OrderABoxPageFunction: 
  PageFunction<Order>
{
  void orderHyperlink_Click(object sender, RoutedEventArgs e) 
  {
    // 주문 반환
    this.OnReturn(new ReturnEventArgs<Order>(this.order));
  }
  void cancelHyperlink_Click(object sender, RoutedEventArgs e) 
  {
    // 주문 취소
    this.OnReturn(null);
  }
  ...
}

generic ReturnEventArgs의 인스턴스를 전달하기 위해 PageFunction.OnReturn이 호출되어 반환됩니다. 작업이 수행되면 여기에 PageFunction이 작동하는 인스턴스 형식이 포함됩니다. 그렇지 않은 경우 null 값으로 나타납니다. PageFunction의 반환을 감지하고, ReturnEventArgs 및 해당 데이터를 얻기 위해 호출 페이지는 PageFunction.Returned를 처리해야 합니다. 그림 16을 참조하십시오. 반환된 데이터는 Returned 이벤트 처리기 ReturnEventArgs의 Result 속성에 포함됩니다.

작업이 완료된 후 PageFunction이 탐색 기록에서 제거되었는지 확인하고 싶을 것입니다. 아주 간단한 구성을 통해 이를 알아볼 수 있습니다.

<!--OrderABoxPageFunction.xaml (markup) -->
<PageFunction RemoveFromJournal="True" ... >
  ...
  <!--Content-->
  ...
<PageFunction>

탐색 기록에서 Page 함수를 제거하면 사용자가 Page 함수로 다시 돌아와 탐색하는 것을 막을 수 있습니다. 이렇게 하는 것이 중요한 이유는 사용자가 Page 함수에 액세스하여 데이터를 변경한 다음 다시 데이터를 편집할 가능성이 있기 때문입니다. 이 경우 데이터의 일관성이 손실될 우려가 있습니다.

하나의 작업이 여러 콘텐츠 페이지로 구성되는 경우도 있습니다. 이는 마법사 스타일의 사용자 환경에서 일반적으로 볼 수 있습니다. 이 경우에도 PageFunction을 사용할 수 있습니다. PageFunction은 하나의 Page 함수를 사용할 때와 동일한 방식으로 여러 Page 함수를 처리할 수 있습니다.

정리

Windows Presentation Foundation 응용 프로그램 모델은 유연성이 대단히 뛰어납니다. 기본적으로, 메뉴 기반 탐색과 하이퍼링크 기반 탐색을 모두 지원하는 독립 실행형 응용 프로그램과 브라우저 호스트 응용 프로그램을 모두 사용할 수 있습니다. 또한 응용 프로그램 콘텐츠는 응용 프로그램 어셈블리 또는 참조된 어셈블리에 패키지화될 수 있으며 여러 위치의 느슨한 파일로 지정될 수도 있습니다. 결국 Windows Presentation Foundation 응용 프로그램 모델 내에서 만들어지는 모든 사용자 환경은 사용자가 무엇을 선택하느냐에 따라 그 범위가 정해지게 되는 것입니다.

Craig McMurtry
기술 전도사(Technical Evangelist)
Microsoft Corporation

업데이트한 날짜: 2006년 7월

적용 대상:
Microsoft ASP.NET 2.0
Windows Communication Foundation
인터넷 정보 서비스(IIS)
웹 서비스 사양

의사 결정권자를 위한 조언
기술 비교: 목적
기술 비교: 표준
기술 비교: 개발
내부 아키텍처
Windows Communication Foundation 채택을 위한 사전 준비: 향후 통합 간소화
Windows Communication Foundation 채택을 위한 사전 준비: 향후 마이그레이션 간소화
Windows Communication Foundation 채택
요약

요약:이 기사에서는 ASP.NET 웹 서비스와 Windows Communication Foundation을 비교하며, Windows Communication Foundation의 발표를 앞둔 시점에서 이미 사용 중이거나 계획 단계에 있는 ASP.NET 웹 서비스를 어떻게 처리해야 하는지에 대해 설명합니다.

ASP.NET은 웹 서비스를 빌드하기 위한 .NET Framework 클래스 라이브러리와 도구뿐만 아니라 인터넷 정보 서비스(IIS) 내에서 이러한 웹 서비스를 호스트하기 위한 기능도 제공합니다. Indigo라는 코드명의 Windows Communication Foundation은 소프트웨어 엔터티가 웹 서비스에서 사용되는 프로토콜을 포함한 모든 프로토콜을 사용하여 통신할 수 있도록 하는 .NET 클래스 라이브러리, 도구 및 호스팅 기능을 제공합니다. 이처럼 웹 서비스 빌드를 위한 더욱 새롭고 포괄적인 기술이 등장하고 있는 시점에서 ASP.NET 웹 서비스에 대한 전망을 알아보도록 하겠습니다.

이 문서에서는 두 가지 기술을 비교하고, ASP.NET 웹 서비스 응용 프로그램을 Windows Communication Foundation 응용 프로그램과 함께 사용할 수 있는 방법에 대해 설명합니다. 또한 ASP.NET 웹 서비스를 Windows Communication Foundation으로 마이그레이션하기 위한 준비 방법과 실제로 마이그레이션을 수행하는 방법을 설명합니다.

이 문서에서는 ASP.NET에서 웹 서비스를 빌드하기 위해 제공하는 기능과 Microsoft .NET용 Web Services Enhancements(WSE)를 별개로 취급합니다. WSE를 사용하여 개발된 응용 프로그램에 대한 전망은 다른 곳에서 살펴볼 것입니다.

Windows Communication Foundation은 2006년 하반기에 발표될 예정입니다. Windows Communication Foundation에는 이전 기술인 ASP.NET 웹 서비스와 비교하여 중요한 몇 가지 이점이 있습니다. ASP .NET 웹 서비스를 사용하는 조직에서는 이러한 이점을 고려해야 합니다.

ASP.NET 웹 서비스 도구는 단지 웹 서비스를 빌드하기 위한 것이지만, Windows Communication Foundation은 소프트웨어 엔터티들이 서로 통신하도록 설정되어야 하는 모든 환경에서 사용할 수 있는 도구를 제공합니다. 이는 개발자가 다양한 소프트웨어 통신 시나리오를 적용하기 위해 알아야 하는 기술의 가짓수를 줄여 주며, 따라서 소프트웨어 개발 리소스 비용과 소프트웨어 개발 프로젝트를 완성하는 데 소요되는 시간도 줄여 줍니다.

웹 서비스 개발 프로젝트의 경우에도 Windows Communication Foundation은 ASP.NET 웹 서비스에서 지원하는 것보다 훨씬 많은 웹 서비스 프로토콜을 지원합니다. 이러한 프로토콜은 신뢰할 수 있는 세션과 트랜잭션을 비롯한 여러 가지 장점을 수반하는, 더욱 정교한 솔루션을 제공합니다.

Windows Communication Foundation은 ASP.NET 웹 서비스에서 지원하는 것보다 훨씬 많은 메시지 전송 프로토콜을 지원합니다. ASP.NET 웹 서비스는 HTTP(Hypertext Transfer Protocol)를 통한 메시지 전송만 지원합니다. 그러나 Windows Communication Foundation은 HTTP뿐만 아니라 TCP(Transmission Control Protocol), 명명된 파이프 및 MSMQ(Microsoft Message Queuing)를 통한 메시지 전송도 지원합니다. 더욱 중요한 사실은 Windows Communication Foundation은 추가되는 전송 프로토콜을 지원하도록 즉시 확장 가능하다는 점입니다. 따라서 Windows Communication Foundation을 사용하여 개발된 소프트웨어는 다양한 다른 소프트웨어와 함께 작동하도록 손쉽게 확장할 수 있어 잠재적 투자 수익을 높여 줍니다.

Windows Communication Foundation은 ASP.NET 웹 서비스에서 제공하는 것보다 훨씬 더 풍부한 응용 프로그램 배포 및 관리 기능을 제공합니다. ASP.NET에도 있는 구성 시스템 외에도 Windows Communication Foundation은 구성 편집기, 원하는 수의 중간 단계를 통한 송수신자 간 활동 추적, 추적 뷰어, 메시지 로깅, 많은 수의 성능 카운터 및 WMI(Windows Management Instrumentation) 지원을 제공합니다. 이처럼 풍부한 관리 도구를 사용하면 운영 비용, 실패 위험 및 실제 가동 중단 시간을 줄일 수 있습니다.

ASP.NET 웹 서비스에 대한 Windows Communication Foundation의 이러한 잠재적 이점을 고려할 때, ASP.NET 웹 서비스를 사용하고 있거나 사용할 예정인 조직에서는 다음과 같은 선택을 할 수 있습니다.

• ASP.NET 웹 서비스를 계속 사용하고 Windows Communication Foundation에서 제공하는 이점은 무시합니다. Microsoft의 현재 지원 주기 정책 하에서 ASP.NET 웹 서비스에 대한 기본 지원은 2011년까지, 확장 지원은 2016년까지 제공됩니다. 따라서 ASP.NET 웹 서비스를 계속 사용하더라도 큰 위험은 없습니다.
• 미래의 어느 시점에 Windows Communication Foundation을 채택할 의향을 갖고 ASP.NET 웹 서비스를 계속 사용합니다. 이 문서에서는 새로운 ASP.NET 웹 서비스 응용 프로그램을 미래의 Windows Communication Foundation 응용 프로그램과 함께 사용할 수 있는 가능성을 최대화하는 방법에 대해 설명합니다. 또한 Windows Communication Foundation으로 더 쉽게 마이그레이션할 수 있도록 새 ASP.NET 웹 서비스를 빌드하는 방법도 설명합니다. 그러나 서비스 보안이 중요하거나 신뢰성 또는 트랜잭션 보증이 필요하거나 사용자 지정 관리 기능을 구성해야 한다면 Windows Communication Foundation 채택을 연기하는 것은 잘못된 결정입니다. Windows Communication Foundation은 정확히 이러한 시나리오를 위해 설계되었으며, 기술에 대한 생산 라이선스는 이미 제공되고 있습니다.
• 기존 ASP.NET 웹 서비스 응용 프로그램을 계속 유지하면서 새로운 개발에는 Windows Communication Foundation을 채택합니다. 대부분의 경우 이것이 최적의 선택입니다. Windows Communication Foundation의 이점을 누리면서 이를 사용하기 위해 기존 응용 프로그램을 수정해야 하는 비용은 절약할 수 있기 때문입니다. 이 시나리오에서는 새 Windows Communication Foundation 응용 프로그램과 기존 ASP.NET 응용 프로그램이 공존할 수 있습니다. 또한 새 Windows Communication Foundation 응용 프로그램에서 기존 ASP.NET 웹 서비스를 사용할 수 있으며, Windows Communication Foundation의 ASP.NET 호환 모드를 통해 Windows Communication Foundation을 사용하여 기존 ASP.NET 응용 프로그램에 새 작업 기능을 프로그래밍할 수도 있습니다.
• Windows Communication Foundation을 채택하고 기존 ASP.NET 웹 서비스 응용 프로그램을 Windows Communication Foundation으로 마이그레이션합니다. 조직에서는 개발자들이 ASP.NET 웹 서비스에 대해 알아야 할 필요가 없도록 하기 위해 이 옵션을 선택할 수 있습니다. 그러나 최신 기술 외의 다른 기술에 대한 지원을 배제한다는 것은 비현실적이며, 따라서 이 옵션을 선택하는 이유로는 적절하지 않습니다. Windows Communication Foundation에서 제공되는 기능으로 기존 응용 프로그램이 향상되거나, 기존 ASP.NET 웹 서비스의 기능을 더욱 강력한 새 Windows Communication Foundation 응용 프로그램으로 다시 만드는 경우에만 마이그레이션을 하는 것이 좋습니다. 이 문서에서는 마이그레이션 방법에 대해 설명합니다.

ASP.NET 웹 서비스 기술은 SOAP(Simple Object Access Protocol) over HTTP를 통해 메시지를 송수신하는 응용 프로그램을 빌드하기 위해 개발되었습니다. 메시지의 구조는 XML 스키마를 사용하여 정의할 수 있으며 .NET 개체와 주고 받는 메시지를 용이하게 serialize할 수 있는 도구가 제공됩니다. 이 기술을 사용하면 웹 서비스를 WSDL(Web Services Description Language)로 설명하는 메타데이터를 자동으로 생성할 수 있으며, WSDL에서 웹 서비스용 클라이언트를 생성하는 보조 도구가 제공됩니다.

Windows Communication Foundation은 .NET 응용 프로그램에서 다른 소프트웨어 엔터티와 메시지를 교환할 수 있도록 하기 위한 것입니다. 기본적으로 SOAP가 사용되지만 메시지는 모든 형식을 가질 수 있으며 모든 전송 프로토콜을 통해 전달될 수 있습니다. 메시지의 구조는 XML 스키마를 사용하여 정의할 수 있으며 .NET 개체와 주고 받는 메시지를 serialize할 수 있는 다양한 옵션이 제공됩니다. Windows Communication Foundation은 이 기술을 사용하여 빌드되는 웹 서비스를 WSDL로 설명하는 메타데이터를 자동으로 생성할 수 있으며, WSDL에서 그러한 응용 프로그램을 위한 클라이언트를 생성하는 도구도 제공합니다.

ASP.NET 웹 서비스에서 지원되는 표준 목록은 XML Web Services Created Using ASP.NET (영문)을 참조하십시오.

Windows Communication Foundation에서 지원되는 표준에 대한 자세한 목록은 Web Services Protocols Supported in WCF (영문)를 참조하십시오.

Windows Communication Foundation에는 특정 Windows Communication Foundation 응용 프로그램을 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로 또는 XML에서 serialize할 수 있는 .NET 클래스에 대한 정의가 필요합니다. 물론 이러한 클래스를 수동으로 작성하거나 명령줄 XML 스키마/데이터 형식 지원 유틸리티인 xsd.exe를 사용하여 XML 스키마의 형식 정의에서 생성할 수 있습니다.

System.Xml.Serialization.XmlSerializer를 통해 XML로, 또는 XML에서 serialize할 수 있는 .NET 클래스의 정의에 대해 알아야 하는 주요 사항은 다음과 같습니다.

• .NET 개체의 공용 필드와 속성만 XML로 변환됩니다.
• 클래스에서 IEnumerable 또는 ICollection 인터페이스를 구현하는 경우에만 컬렉션 클래스의 인스턴스를 serialize할 수 있습니다.
• 그 결과 System.Collections.Hashtable과 같은 System.Collections.IDictionary 인터페이스를 구현하는 클래스는 XML로 serialize할 수 없습니다.
• 클래스의 인스턴스가 XML로 표현되는 방식을 정확히 제어하기 위해 System.Xml.Serialization 네임스페이스의 많은 특성 형식을 .NET 클래스 및 그 구성원에 추가할 수 있습니다.

Windows Communication Foundation 응용 프로그램 개발 역시 대개 복합 형식을 정의하는 것부터 시작합니다. Windows Communication Foundation은 ASP.NET 웹 서비스와 같은 .NET 형식을 사용하도록 만들 수 있지만 더 나은 다른 방법이 제공됩니다.

Windows Communication Foundation System.Runtime.Serialization 어셈블리의 System.Runtime.Serialization.DataContract 및 System.Runtime.Serialization.DataMember 특성을 .NET 형식에 추가하여 해당 형식의 인스턴스가 XML로 serialize된다는 점을 표시하고 이 형식에서 serialize되는 특정 필드 또는 속성을 표시할 수 있습니다. 다음의 세 가지 예제는 모두 유효합니다.

//예제 1: 
[DataContract]
public class LineItem
{
    [DataMember]
    public string ItemNumber;
    [DataMember]
    public decimal Quantity;
    [DataMember]
    public decimal UnitPrice;
}

//예제 2: 
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;
        }
    }
}

//예제 3: 
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개 이상 serialize한다고 표시하지만 System.Runtime.Serialization.DataMember 특성은 특정 필드 또는 속성을 serialize한다고 표시합니다. System.Runtime.Serialization.DataContract 특성은 클래스 또는 구조체에 적용될 수 있습니다. System.Runtime.Serialization.DataMember 특성은 필드 또는 속성에 적용될 수 있으며, 이 특성이 적용되는 필드 및 속성은 공개 필드 및 속성이거나 개인 필드 및 속성일 수 있습니다. System.Runtime.Serialization.DataContract 특성을 가진 형식의 인스턴스는 Windows Communication Foundation 용어로 데이터 계약이라고 합니다. 이러한 인스턴스는 Windows Communication Foundation의 System.Runtime.Serialization.DataContractFormatter를 사용하여 XML로 serialize됩니다.

System.Runtime.Serialization.DataContractFormatter, System.Runtime.Serialization.DataContract, System.Runtime.Serialization.DataMember 특성은 System.Xml.Serialization.XmlSerializer와, 그리고 System.Xml.Serialization 네임스페이스의 다양한 특성과 어떻게 다를까요? 중요한 차이점이 많이 있습니다.

1. System.Xml.Serialization.XmlSerializer와 System.Xml.Serialization 네임스페이스의 특성은 XML 스키마에 정의된 유효 형식에 .NET 형식을 매핑할 수 있도록 디자인되었으므로 .NET 형식의 XML 표현 방식을 매우 정확하게 제어할 수 있습니다. System.Runtime.Serialization.DataContractFormatter, System.Runtime.Serialization.DataContract, System.Runtime.Serialization.DataMember 특성은 .NET 형식의 XML 표현 방식에 대한 제어를 극히 제한적으로 제공합니다. 형식 및 해당 필드 또는 속성을 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로 결정됩니다.

2. .NET 형식을 XML로 표현하는 방식에 대해 많은 제어를 허용하지 않기 때문에 System.Runtime.Serialization.DataContractFormatter에 대해 serialize 프로세스의 예측이 매우 쉽고, 따라서 최적화가 더 용이합니다. 결과적으로 System.Runtime.Serialization.DataContractFormatter 디자인의 실질적 이점은 약 10% 정도의 성능 향상에 있습니다.
3. 다음의 두 형식을 비교해 보십시오. 아래의 첫 번째 형식에는 System.Xml.Serialization.XmlSerializer에 의한 serialize 특성이 있습니다.

   [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로 serialize될 형식의 필드 또는 속성을 표시하지 않지만, System.Runtime.Serialization.DataContractFormatter에서 사용하는 System.Runtime.Serialization.DataMember 특성은 serialize될 필드 또는 속성을 명시적으로 보여 줍니다. 따라서 데이터 계약은 응용 프로그램에서 송수신할 데이터의 구조에 관한 명시적 계약이라고도 할 수 있습니다.

4. System.Xml.Serialization.XmlSerializer는 .NET 개체의 공개 구성원만 XML로 변환할 수 있지만 System.Runtime.Serialization.DataContractFormatter는 .NET 개체의 구성원에 대한 액세스 한정자와 관계없이 이러한 구성원을 XML로 변환할 수 있습니다.
5. 형식의 비공개 구성원을 XML로 serialize할 수 있기 때문에 System.Runtime.Serialization.DataContractFormatter에는 XML로 serialize할 수 있는 .NET 형식의 다양성에 대한 제한이 더 적습니다. 특히 Systems.Collections.IDictionary 인터페이스를 구현하는 System.Collections.Hashtable과 같은 XML 형식으로 변환할 수 있습니다. 일반적으로 System.Runtime.Serialization.DataContractFormatter는 형식의 정의를 수정하거나 형식을 위한 래퍼를 개발하지 않고도 기존 .NET 형식의 인스턴스를 serialize할 수 있는 가능성이 훨씬 더 높습니다.
6. 그러나 System.Runtime.Serialization.DataContractFormatter가 형식의 비공개 구성원에 액세스할 수 있다는 점에 기인한 또 다른 결과는 System.Xml.Serialization.XmlSerializer와 달리 완전 신뢰가 필요하다는 점입니다.
7. System.Runtime.Serialization.DataContractFormatter는 버전 관리를 위한 일부 지원을 통합하고 있습니다.
   • System.Runtime.Serialization.DataMember 특성에는 IsRequired 속성이 있습니다. 이 속성에는 새 버전의 데이터 계약에 추가된, 이전 버전에는 없었던 구성원에 대해 false 값을 지정할 수 있기 때문에 새 버전의 데이터 계약이 있는 응용 프로그램에서 이전 버전을 처리할 수 있습니다.
   • 데이터 계약에서 간단한 System.Runtime.Serialization.IExtensibleDataObject 인터페이스를 구현하도록 함으로써 System.Runtime.Serialization.DataContractFormatter가 새 버전의 데이터 계약에 정의된 구성원을 이전 버전의 데이터 계약을 사용하는 응용 프로그램을 통해 전달하도록 허용할 수 있습니다.

이러한 모든 차이점에도 불구하고 System.Xml.Serialization.XmlSerializer에서 기본적으로 형식을 serialize하는 XML은 해당 XML에 대한 네임스페이스가 명시적으로 정의되어 있는 경우 System.RuntimeSerialization.DataContractFormatter에서 형식을 serialize하는 XML과 의미상 동일합니다. 따라서 다음과 같이 두 serializer에서 사용하는 특성을 가지고 있는 클래스는 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;
}

Windows Communication Foundation을 포함하고 있는 소프트웨어 개발 키트에는 서비스 모델 메타데이터 도구라고 하는 svcutil.exe 명령줄 도구가 있습니다. svcutil.exe는 ASP.NET 웹 서비스에서 사용되는 xsd.exe 도구와 마찬가지로 XML 스키마에서 .NET 데이터 형식의 정의를 생성할 수 있습니다. System.Runtime.Serialization.DataContractFormatter에 서 XML 스키마에 의해 정의된 형식의 XML을 내보낼 수 있으면 이러한 .NET 데이터 형식은 데이터 계약이 됩니다. 그렇지 않으면 이러한 형식은 System.Xml.Serialization.XmlSerializer를 통해 seriallize됩니다. 또한 svcutil.exe 도구와 /dataContractOnly 스위치를 사용하여 데이터 계약에서 XML 스키마를 생성할 수도 있습니다.

ASP.NET 웹 서비스에서 System.Xml.Serialization.XmlSerializer를 사용하고, Windows Communication Foundation의 ASP.NET 호환 모드를 통해 Windows Communication Foundation 서비스에서 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 특성을 가진 인터페이스는 서비스에 의해 수행되는 작업에 대한 계약을 설정하며, 같은 계약을 다른 방식으로 구현하는 다양한 클래스에서 동일한 서비스를 다시 사용할 수 있으므로 이 옵션을 사용하는 것이 좋습니다.

Windows Communication Foundation 서비스는 Windows Communication Foundation 끝점을 하나 이상 정의함으로써 제공됩니다. 끝점은 주소, 바인딩 및 서비스 계약으로 정의됩니다. 주소는 서비스가 있는 위치를 정의합니다. 바인딩은 서비스와 통신하는 방법을 지정합니다. 서비스 계약은 서비스에서 수행할 수 있는 작업을 정의합니다.

일반적으로 서비스 계약은 다음과 같이 .NET 인터페이스에 System.ServiceModel.ServiceContract와 System.ServiceModel.OperationContract 특성을 추가함으로써 처음으로 정의됩니다.

[ServiceContract]
public interface IEcho
{
    [OperationContract]
    string Echo(string input);
}

System.ServiceModel.ServiceContract 특성은 인터페이스에서 Windows Communication Foundation 서비스 계약을 정의하도록 지정하고, System.ServiceModel.OperationContract 특성은 서비스 계약의 작업을 정의하는 인터페이스의 메서드가 있는 경우 해당 메서드를 나타냅니다.

서비스 계약은 일단 정의되면 다음과 같이 클래스가 서비스 계약을 정의하는 인터페이스를 구현하도록 함으로써 클래스에서 구현됩니다.

public class Service : IEcho
{
    
    public string Echo(string input)
    {
        return input;
    }
}

서비스 계약을 구현하는 클래스는 Windows Communication Foundation 용어로 서비스 형식이라고 합니다.

다음 단계는 주소와 바인딩을 서비스 형식과 연결하는 것입니다. 이 작업은 일반적으로 파일을 직접 편집하거나 Windows Communication Foundation에서 제공되는 구성 편집기를 사용하여 구성 파일에서 수행됩니다. 다음은 구성 파일 예제입니다.

<?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>

바인딩은 응용 프로그램과 통신하기 위한 프로토콜 집합을 지정합니다. 다음과 같이 일반 옵션을 나타내는 미리 정의된 여러 가지 바인딩이 있습니다.

미리 정의된 바인딩인 System.ServiceModel.BasicHttpBinding은 ASP.NET 웹 서비스에서 지원되는 프로토콜 집합을 통합하고 있습니다.

Windows Communication Foundation 응용 프로그램용 사용자 지정 바인딩은 Windows Communication Foundation에서 개별 프로토콜을 구현하는 데 사용하는 바인딩 요소 클래스들의 컬렉션으로 간단히 정의할 수 있습니다. 새 바인딩 요소를 작성하여 추가 프로토콜을 나타낼 수 있습니다.

서비스 형식의 내부 동작은 behaviors라는 클래스 모음의 속성을 사용하여 조정할 수 있습니다. 다음 예제에서는 System.ServiceModel.ServiceBehavior 클래스를 사용하여 서비스 형식이 멀티스레드 형식이 되도록 지정합니다.

[ServiceBehavior(ConcurrencyMode=ConcurrencyMode.Multiple]
public class DerivativesCalculatorServiceType: IDerivativesCalculator

System.ServiceModel.ServiceBehavior와 같이 프로그래머가 설정할 수 있는 속성이 있는 일부 동작은 특성입니다. 관리자가 설정할 수 있는 속성이 있는 다른 동작은 응용 프로그램의 구성에서 수정할 수 있습니다.

서비스 형식 프로그래밍에서는 System.ServiceModel.OperationContext 클래스가 자주 사용됩니다. 이 클래스의 정적 Current 속성은 작업이 실행되고 있는 컨텍스트에 대한 정보로의 액세스를 제공합니다. 따라서 System.ServiceModel.OperationContext는 System.Web.HttpContext 및 System.EnterpriseServices.ContextUtil 클래스 모두와 비슷합니다.

ASP.NET 웹 서비스는 클래스 라이브러리 어셈블리로 컴파일됩니다. 확장명이 .asmx인 서비스 파일이라는 파일이 제공됩니다. 이 파일에는 서비스에 대한 코드를 포함하고 있는 클래스 및 이 클래스가 있는 어셈블리를 식별하는 @ WebService 지시문이 있습니다.

<%@ WebService Language="C#" Class="Service,ServiceAssembly" %>

서비스 파일은 IIS의 ASP.NET 응용 프로그램 루트에 복사되며, 어셈블리는 이 응용 프로그램 루트의 \bin 하위 디렉터리에 복사됩니다. 그런 다음 응용 프로그램 루트에 있는 서비스 파일의 URL(Uniform Resource Locator)을 통해 이 응용 프로그램에 액세스할 수 있습니다.

Aaron Skonnard는 자신의 칼럼 (영문)에서 .NET Framework 2.0에서 제공되는 HttpListener 클래스를 사용하여 어떤 .NET 응용 프로그램에서든 IIS 외부에서 ASP.NET 웹 서비스를 호스트하는 방법에 대해 설명했습니다. 그러나 Skonnard는 이를 위한 작업은 '간단하지 않다'고 설명하고 있습니다. (영문)

Windows Communication Foundation 서비스는 IIS 5.1이나 6.0, IIS 7의 일부로 제공될 WAS(Windows Activation Service), 그리고 모든 .NET 응용 프로그램 내에서 즉시 호스트가 가능합니다. IIS 5.1 또는 6.0에서 서비스를 호스트하려면 이 서비스가 HTTP를 통신 전송 프로토콜로 사용해야 합니다.

IIS 5.1, IIS 6.0 또는 WAS에서 서비스를 호스트하려면 다음 단계를 따릅니다.

1. 서비스 형식을 클래스 라이브러리 어셈블리로 컴파일합니다.
2. 다음과 같은 서비스 형식을 식별하는 @ ServiceHost 지시문을 포함하는 서비스 파일을 확장명 .svc로 만듭니다.

   <%@ServiceHost language="c#" Service="MyService" %>
   

3. 서비스 파일을 가상 디렉터리에 복사하고 어셈블리를 이 가상 디렉터리의 \bin 하위 디렉터리에 복사합니다.
4. 구성 파일을 가상 디렉터리에 복사하고 파일 이름을 Web.config로 지정합니다.

그러면 응용 프로그램 루트에 있는 서비스 파일의 URL을 통해 해당 응용 프로그램에 액세스할 수 있습니다.

.NET 응용 프로그램에서 Windows Communication Foundation 서비스를 호스트하려면 서비스 형식을 이 응용 프로그램에서 참조하는 클래스 라이브러리 어셈블리로 컴파일하고, Windows Communication Foundation의 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();
}

이 예제에서는 Windows Communication Foundation System.ServiceModel.ServiceHost 생성에서 하나 이상의 전송 프로토콜에 대한 주소가 지정되는 방식을 보여 줍니다. 이러한 주소를 기준 주소라고 합니다.

Windows Communication Foundation 서비스의 끝점에 제공되는 주소는 끝점의 호스트에 대한 기준 주소를 기준으로 하는 상대 주소입니다. 호스트에는 통신 전송 프로토콜당 하나의 기준 주소가 있을 수 있습니다. 끝점의 주소는 호스트의 기준 주소 중 끝점의 통신 전송 프로토콜에 대한 기준 주소의 상대 주소입니다. 위에 있는 구성 파일의 예제에서 끝점으로 선택된 System.ServiceModel.BasicHttpBinding은 HTTP를 전송 프로토콜로 사용하므로 EchoService 끝점의 주소는 호스트의 HTTP 기준 주소의 상대 주소입니다. 위 예제에서 호스트의 경우 HTTP 기준 주소는 http://www.woodgrove.com:8000/입니다. IIS 또는 WAS에서 호스트되는 서비스의 기준 주소는 해당 서비스에 대한 서비스 파일의 URL입니다.

IIS 또는 WAS에서 호스트되고 전송 프로토콜로 HTTP만 사용하도록 구성된 서비스만 Windows Communication Foundation의 ASP.NET 호환 모드 옵션을 사용하도록 만들 수 있습니다. 이 옵션을 사용하려면 다음의 두 단계가 필요합니다.

1. 프로그래머는 다음과 같이 System.ServiceModel.AspNetCompatbilityRequirements 특성을 서비스 형식에 추가하여 ASP.NET 호환 모드가 허용되는지 또는 필수인지 지정해야 합니다.

   [System.ServiceModel.AspNetCompatibilityRequirements(
           RequirementsMode=AspNetCompatbilityRequirementsMode.Require)]
   public class DerivativesCalculatorServiceType: IDerivativesCalculator

2. 관리자는 다음과 같이 ASP.NET 호환 모드를 사용하도록 응용 프로그램을 구성해야 합니다.

   <configuration>
      <system.serviceModel>
         <services>
            [...]
         </services>
   <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
      </system.serviceModel>
   </configuration>

또한 Windows Communication Foundation 응용 프로그램은 서비스 파일의 확장명을 .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>

이 옵션을 사용하면 Windows Communication Foundation을 사용하도록 서비스를 수정할 때 .asmx 서비스 파일의 URL을 사용하도록 구성된 클라이언트를 수정하지 않아도 됩니다.

클라이언트 개발

ASP.NET 웹 서비스용 클라이언트는 .asmx 파일의 URL을 입력으로 제공하는 wsdl.exe 명령줄 도구를 사용하여 생성됩니다. Windows Communication Foundation에서 제공되는 이와 유사한 도구는 svcutil.exe입니다. 이 도구는 서비스 계약과 프록시 클래스에 대한 정의를 포함한 코드 모듈을 생성합니다. 또한 서비스의 주소와 바인딩을 포함한 구성 파일도 생성합니다.

원격 서비스의 클라이언트를 프로그래밍할 때 일반적으로 비동기 패턴에 따라 프로그래밍하는 것이 좋습니다. wsdl.exe 도구로 생성되는 코드는 기본적으로 항상 동기 패턴과 비동기 패턴을 모두 제공합니다. svcutil.exe 도구로 생성되는 코드는 둘 중 한 패턴을 제공할 수 있습니다. 이 도구는 기본적으로 동기 패턴을 제공합니다. 이 도구를 /async 스위치와 함께 실행하면 생성된 코드에서 비동기 패턴을 제공합니다.

ASP.NET의 wsdl.exe 도구로 생성되는 프록시 클래스의 이름이 기본적으로 Windows Communication Foundation의 svcutil.exe 도구로 생성되는 프록시 클래스의 이름과 일치할 것이라는 보장은 없습니다. 특히 System.Xml.Serialization.XmlSerializer를 사용하여 serialize되어야 하는 클래스의 속성 이름에는 기본적으로 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;
    }
}

Windows Communication Foundation에서는 다음과 같이 System.ServiceModel.MessageContract, System.ServiceModel.MessageHeader, System.ServiceModel.MessageBody 특성을 제공하여 서비스에서 송수신되는 SOAP 메시지의 구조를 설명합니다.

[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 속성과 같은 서비스 속성으로 나타나지만 Windows Communication Foundation 구문에서는 메시지 속성으로 더욱 정확하게 나타납니다. Windows Communication Foundation에서는 끝점 구성에 메시지 헤더를 추가할 수도 있습니다.

<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>

이 옵션을 사용하면 클라이언트 또는 서비스에 대한 코드에서 기반 프로토콜 헤더를 참조할 필요가 없습니다. 끝점 구성 방식에 의해 헤더가 메시지에 간단히 추가됩니다.

서비스 설명

wsdl 쿼리를 사용하여 ASP.NET 웹 서비스의 .asmx 파일에 대해 HTTP GET 요청을 발행하면 ASP.NET에서 해당 서비스를 설명하는 WSDL을 생성하게 됩니다. 이 WSDL이 요청에 대한 응답으로 반환됩니다.

ASP.NET 2.0을 통해 서비스가 WS-I(Web Services-Interoperability Organization) 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은 사용자 지정할 수 있습니다. System.Web.Services.Description.ServiceDescriptionFormatExtension의 하위 클래스를 만들어 WSDL에 항목을 추가함으로써 사용자 지정할 수 있습니다.

IIS 5.1, 6.0 또는 WAS에서 호스트되는 HTTP 끝점이 있는 Windows Communication Foundation 서비스의 .svc 파일에 대해 wsdl 쿼리를 사용하여 HTTP GET 요청을 발행하면 Windows Communication Foundation에서 해당 서비스를 설명하는 WSDL로 응답하게 됩니다. .NET 응용 프로그램에서 호스트되는 서비스의 HTTP 기준 주소에 대해 wsdl 쿼리를 사용하여 HTTP GET 요청을 발행해도 같은 효과가 있습니다.

Windows Communication Foundation은 WS-MetadataExchange 요청에 대해서도 서비스를 설명하기 위해 생성하는 WSDL로 응답합니다. ASP.NET 웹 서비스는 WS-MetadataExchange 요청에 대한 지원을 기본적으로 제공하지 않습니다.

Windows Communication Foundation에서 생성하는 WSDL은 광범위하게 사용자 지정할 수 있습니다. System.ServiceModel.ServiceMetadataBehavior 클래스는 WSDL을 사용자 지정하기 위한 몇 가지 기능을 제공하며 System.ServiceModel.Design.IWsdlExporter 구현을 개발하여 완벽하게 제어할 수 있습니다. 또한 다음과 같이 WSDL을 생성하지 않고 지정된 URL에서 정적 WSDL 파일을 사용하도록 Windows Communication Foundation을 구성할 수도 있습니다.

<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 오류의 내용에 대한 제어 범위를 넓힐 수 있습니다.

Windows Communication Foundation 서비스에서는 중요한 정보가 예외를 통해 우발적으로 노출되지 않도록, 처리되지 않은 예외가 클라이언트에 SOAP 오류로 반환되지 않습니다. 디버깅을 위해 처리되지 않은 예외가 클라이언트에 반환되도록 하는 구성 설정이 제공됩니다.

Windows Communication Foundation 프로그래머는 의도적으로 클라이언트에 SOAP 오류를 반환하기 위해 generic 형식의 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 속성을 통해 액세스되는 세션 상태 정보가 실제로 저장되는 위치를 세부적으로 제어할 수 있습니다. 세션 상태 정보는 쿠키, 데이터베이스, 현재 서버의 메모리 또는 지정된 서버의 메모리에 저장될 수 있습니다. 저장 위치는 서비스의 구성 파일에서 선택됩니다.

Windows Communication Foundation은 상태 관리를 위한 확장 가능한 개체를 제공합니다. 확장 가능한 개체는 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 클래스의 상태 정보가 실제로 저장되는 위치를 세부적으로 제어할 수 있지만, 적어도 초기 버전의 Windows Communication Foundation에서는 확장 가능한 개체가 저장되는 위치를 제어할 수 없습니다. 이러한 점이 Windows Communication Foundation 서비스를 위해 ASP.NET 호환 모드를 선택하는 가장 정당한 이유가 됩니다. 구성 가능한 상태 관리가 필수적인 경우 ASP.NET 호환 모드를 채택함으로써 System.Web.HttpContext 클래스의 기능을 ASP.NET에서와 똑같은 방식으로 사용할 수 있으며 System.Web.HttpContext 클래스를 통해 관리되는 상태 정보가 저장되는 위치를 구성할 수도 있습니다.

보안

ASP.NET 웹 서비스의 보안을 유지하기 위한 옵션은 대개 IIS 응용 프로그램의 보안을 유지하는 옵션과 같습니다. Windows Communication Foundation 응용 프로그램은 IIS뿐만 아니라 .NET 실행 파일 내에서도 호스트될 수 있기 때문에 Windows Communication Foundation 응용 프로그램의 보안을 유지하기 위한 옵션은 IIS의 기능에 독립적으로 만들어야 했습니다. 그러나 ASP.NET 웹 서비스에 제공되는 기능은 ASP.NET 호환 모드에서 실행되는 Windows Communication Foundation 서비스에서도 사용할 수 있습니다.

보안: 인증

IIS는 응용 프로그램에 대한 액세스를 제어하는 기능을 제공하므로 이 기능을 통해 익명 액세스 또는 Windows 인증, 다이제스트 인증, 기본 인증, .NET Passport 인증 등 다양한 모드의 인증을 선택할 수 있습니다. Windows 인증 옵션을 사용하면 ASP.NET 웹 서비스에 대한 액세스를 제어할 수 있습니다. Windows Communication Foundation 응용 프로그램이 IIS 내에서 호스트되는 경우에는 이 응용 프로그램에 대한 익명 액세스를 허용하도록 IIS를 구성하여 다양한 다른 옵션과 함께 Windows 인증을 지원하는 Windows Communication Foundation 자체에서 인증을 관리할 수 있도록 해야 합니다. 기본 제공되는 다른 옵션에는 사용자 이름 토큰, X.509 인증서, SAML 토큰 및 InfoCard가 있으며 사용자 지정 인증 메커니즘도 정의할 수 있습니다.

ASP.NET 2.0의 System.Web.HttpContext 클래스에는 특정 종류의 저장소에서 인증된 사용자에 대한 정보를 읽는 방법을 아는 System.Web.Profile.Provider 클래스를 통해 이러한 정보를 저장소에서 자동으로 검색할 수 있는 Profile 속성이 있습니다. 사용자 지정 동작에서 System.Web.Profile.Provider 클래스를 사용하여 프로필 정보를 검색할 수 있지만 이러한 ASP.NET 2.0 메커니즘은 Windows Communication Foundation에서 ASP.NET 호환 모드인 경우를 제외하면 지원되지 않습니다.

보안: 가장

ASP.NET에서는 ASP.NET 웹 서비스가 특정 사용자로, 또는 현재 요청에서 제공된 사용자의 자격 증명으로 가장할 수 있도록 하는 ID 요소를 제공합니다. 이 요소를 사용하면 ASP.NET 호환 모드에서 실행되고 있는 Windows Communication Foundation 응용 프로그램에서 가장을 구성할 수 있습니다.

Windows Communication Foundation의 구성 시스템은 가장할 특정 사용자를 지정하기 위한 자체 ID 요소를 제공합니다. 또한 Windows Communication Foundation 클라이언트 및 서비스는 가장을 위해 별도로 구성할 수 있습니다. 클라이언트는 요청을 전송할 때 현재 사용자로 가장하도록 다음과 같이 구성할 수 있습니다.

<behaviors>
   <endpointBehaviors>
      <behavior name="DerivativesCalculatorClientBehavior">
         <clientCredentials>
            <windows allowedImpersonationLevel="Impersonation"/>
         </clientCredentials>
      </behavior>
   </endpointBehaviors>
</behaviors>

서비스 작업은 현재 요청에서 제공된 사용자의 자격 증명으로 가장하도록 다음과 같이 구성할 수 있습니다.

[OperationBehavior(Impersonation = ImpersonationOption.Required)]
public void Receive(Message input)

보안: ACL을 사용한 인증

ACL(액세스 제어 목록)을 사용하면 .asmx 파일에 대한 액세스를 제한할 수 있습니다. 그러나 Windows Communication Foundation .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 권한 부여 관리자에서 역할 지정을 검색할 수 있는 역할 공급자를 제공합니다.

실제로 역할 공급자 메커니즘은 Windows Communication Foundation 응용 프로그램을 포함한 모든 .NET 응용 프로그램에서 ASP.NET과 별개로 사용할 수 있습니다. 다음은 System.ServiceModel.ServiceAuthorization 동작을 통해 ASP.NET 역할 공급자를 사용하는 옵션이 선택되는 방식을 보여 주는 Windows Communication Foundation 응용 프로그램의 샘플 구성입니다.

<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>

보안: 클래임 기반 인증

Windows Communication Foundation의 가장 중요한 기술 혁신 중 하나는 클래임에 기반하여 보호되는 리소스에 대한 액세스 인증을 완벽하게 지원한다는 것입니다. 클래임은 형식, 권한 및 값으로 구성됩니다. 예를 들어 운전 면허증을 생각해 보십시오. 운전 면허증은 소지인에 대한 클래임 집합으로 구성되는데, 그 중 하나는 소지인의 생년월일입니다. 이 클래임의 형식은 생년월일이며, 값은 운전자의 생년월일입니다. 클래임이 소지인에게 부여하는 권한은 소지인이 클래임 값으로 수행할 수 있는 작업을 지정합니다. 운전자의 생년월일에 대한 클래임의 경우 권한은 단순한 소유입니다. 운전자는 해당 생년월일을 소유하고 있지만 변경하는 등의 작업은 할 수 없습니다. 역할은 단순히 클래임의 한 형식이기 때문에 클래임 기반 인증은 역할 기반 인증을 포함합니다.

클래임 기반 인증은 클래임 집합을 작업의 액세스 요구 사항과 비교하여 그 결과에 따라 작업에 대한 액세스 권한을 부여하거나 거부함으로써 수행됩니다. Windows Communication Foundation에서는 다음과 같이 System.ServiceModel.Description.ServiceAuthorizationBehavior의 ServiceAuthorizationManager 속성에 값을 다시 한 번 지정함으로써 클래임 기반 인증을 실행하는 데 사용할 클래스를 지정할 수 있습니다.

<behaviors>
  <serviceBehaviors>
    <behavior name='ServiceBehavior'>
   <serviceAuthorization 
        serviceAuthorizationManagerType='Service.AccessChecker, Service' />
    </behavior>
  </serviceBehaviors>
</behaviors>

클래임 기반 인증을 실행하는 데 사용되는 클래스는 System.ServiceModel.ServiceAuthorizationManager에서 파생되어야 하며, 여기에서 다시 정의할 유일한 메서드는 AccessCheck() 메서드입니다. Windows Communication Foundation에서는 서비스의 작업이 호출될 때마다 이 메서드를 호출하여 System.ServiceModel.OperationContext 개체를 제공하며, 이 개체의 ServiceSecurityContext.AuthorizationContext 속성에는 사용자에 대한 클래임이 있습니다. 따라서 Windows Communication Foundation에서는 사용자가 인증을 위해 제공한 보안 토큰이 어떤 것이든 이 토큰으로부터 사용자에 대한 클래임을 조합하는 작업을 이미 완료한 상태이며, 이러한 클래임이 요청한 작업에 충분한지 여부를 평가하는 간단한 작업만 남게 됩니다.

Windows Communication Foundation이 어떤 종류의 보안 토큰으로든 자동으로 클래임을 조합한다는 점은 매우 중요한 혁신입니다. 클래임 기반 인증을 위한 코드를 인증 메커니즘과는 완전히 별개로 만들어 주기 때문입니다. 반면 ASP.NET에서 ACL 또는 역할을 사용하는 인증은 Windows 인증과 밀접하게 연결됩니다.

보안: 기밀성

ASP.NET 웹 서비스와 교환되는 메시지의 기밀성은 IIS의 응용 프로그램에서 HTTPS(Secure Hypertext Transfer Protocol)를 사용하도록 구성함으로써 전송 수준에서 보장할 수 있습니다. IIS에서 호스트되는 Windows Communication Foundation 응용 프로그램에 대해서도 마찬가지입니다. 한편 IIS의 외부에서 호스트되는 Windows Communication Foundation 응용 프로그램도 보안 전송 프로토콜을 사용하도록 구성할 수 있습니다. 더 중요한 것은 메시지가 WS-Security 프로토콜을 사용하여 전송되기 전에 메시지의 보안을 유지하도록 Windows Communication Foundation 응용 프로그램을 구성할 수 있다는 점입니다. WS-Security를 사용하여 메시지 본문의 보안만 유지하면 메시지가 기밀을 유지한 상태로 중간 단계를 거쳐 최종 목적지에 도달하도록 할 수 있습니다.

세계화

ASP.NET 구성 언어를 사용하면 개별 서비스의 culture를 지정할 수 있습니다. Windows Communication Foundation에서는 ASP.NET 호환 모드인 경우를 제외하고 이러한 구성 설정을 지원하지 않습니다. ASP.NET 호환 모드를 사용하지 않는 Windows Communication Foundation 서비스를 지역화하려면 서비스 형식을 culture별 어셈블리로 컴파일하고 각 culture별 어셈블리가 별도의 culture별 끝점을 갖도록 합니다.

ASP.NET 웹 서비스

최신 ASP.NET 구현에서 HTTP 요청은 http.sys라는 Windows 커널의 HTTP 구현에서 System.Web.HttpWorkerRequest 개체 형식으로 수신됩니다. System.Web.HttpWorkerRequest 개체는 System.Web.HttpRuntime 개체에 수신되며, 이 개체는 System.Web.HttpWorkerRequest의 데이터로 System.Web.HttpContext 개체를 채웁니다. 요청은 System.Web.HttpRequest 개체인 Request 속성으로 System.Web.HttpContext 개체에 통합됩니다.

.asmx 파일로 배달된 HTTP POST 요청을 나타내는 System.Web.HttpRequest 개체는 기본적으로 System.Web.IHttpHandler 인터페이스를 구현하는 개체에 전달됩니다(Skonnard 2003, 2004). 이 개체는 System.Web.Services.Protocols.WebServiceHandlerFactory 클래스를 사용하여 만들어지며, ASP.NET 웹 서비스 요청 처리기라고도 합니다. Windows Communication Foundation은 ASP.NET 호환 모드로 구성되면 ASP.NET 웹 서비스 요청 처리기의 동작을 모방하는 System.Web.IHttpHandler의 구현을 제공합니다.

ASP.NET 웹 서비스 요청 처리기는 적어도 4가지 작업을 수행해야 합니다. 첫째, HTTP 요청에 통합된 SOAP 메시지를 개발자가 제공하는 SOAP E\extensions의 인스턴스에 전달해야 합니다(Meier, Vasireddy, Babbar 및 Mackman 2004). 둘째, 요청을 처리하기 위해 .asmx 파일에 참조된 클래스의 메서드 중 호출할 메서드를 결정해야 합니다. 셋째, 메서드에서 매개 변수로 예상하는 형식의 인스턴스로 요청이 deserialize되도록 해야 합니다. 넷째, 실제로 메서드를 호출하여 요청으로부터 deserialize한 매개 변수를 이 메서드에 전달해야 합니다.

SOAP 확장은 System.Web.Services.Protocols.SoapExtension에서 파생된 형식입니다. 이 확장은 SOAP 메시지가 처리를 위해 .asmx 파일에서 참조되는 클래스의 메서드로 전달되기 전에 요청에 있는 SOAP 메시지를 액세스하거나 수정하는 데 사용됩니다. 또한 이 확장은 응답 메시지를 액세스 및 수정할 수 있으며 서버뿐만 아니라 클라이언트에도 배포될 수 있습니다. 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 요청을 처리할 때 요청 처리기는 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 메시지 본문 요소의 정규화된 이름을 사용하도록 하려면 서비스를 구현하는 클래스에 System.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 매개 변수를 사용하여 ASP.NET 웹 서비스의 네임스페이스에 대한 기본값을 수정할 수 있습니다.

[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 HTTP 헤더를 서비스의 네임스페이스와 작업 이름으로 분해하여 대상 메서드를 식별하려고 시도하지 않고, 단지 SoapDocumentMethod 특성의 Action 매개 변수에 대해 지정된 값과 일치시킵니다.

일단 ASP.NET 웹 서비스 요청 처리기에서 요청을 처리하기 위해 .asmx 파일에서 참조된 클래스의 메서드 중 호출할 메서드를 식별하면 해당 요청은 이 메서드에서 매개 변수로 예상하는 형식의 인스턴스로 deserialize되어야 합니다. 이를 위해 System.Xml.Serialization.XmlSerializer가 사용됩니다.

기본적으로 요청 처리기는 요청에 통합된 SOAP 메시지가 WSDL 1.1 사양의 문서 스타일과 일치한다고 가정합니다. 이러한 스타일의 메시지에는 임의의 스키마에 따라 구조화된 본문 요소가 있으며, 요청 처리기는 System.Xml.Serialization.XmlSerializer를 사용하여 해당 본문 요소를 .NET 형식으로 deserialize합니다. 다음은 작업 예제입니다.

[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>

여기서 요소 이름은 deserialize될 형식의 이름을 식별합니다. 이 메커니즘도 다음과 같이 사용자 지정할 수 있습니다.

1. 형식의 이름이 SOAP 메시지의 구성 요소에 매핑되는 방식은 System.Xml.XmlElement 및 System.Xml.XmlAttribute 특성을 메서드의 매개 변수에 적용함으로써 사용자 지정할 수 있습니다. System.Xml.XmlElement 특성은 다음과 같이 ASP.NET 웹 서비스 요청 처리기에서 형식을 deserialize할 것이라고 예상하는 XML 요소의 이름을 제어합니다.

   [WebMethod]
   PurchaseOrderType PlaceOrders
   (
       [XmlElement("OrderParameter")]
       PurchaseOrderType order
   );

   System.Xml.XmlAttribute 특성이 매개 변수에 추가된 경우 요청 처리기는 해당 매개 변수를 XML 요소가 아닌 XML 특성에서 deserialize할 것이라고 예상합니다.

2. 요청에 통합된 SOAP 메시지가 문서 스타일과 일치할 것이라는 ASP.NET 웹 서비스 요청 처리기의 기본 예상을 변경하여 해당 SOAP 메시지가 WSDL 1.1 사양의 RPC 스타일과 일치할 것이라고 예상하도록 만들 수 있습니다. 전체 서비스에 대해 SoapRpcService 특성을 사용하거나, 개별 메서드에 대해 SoapRpcMethod 특성을 사용하여 이를 수행할 수 있습니다. 그러나 RPC 스타일 사용은 WS-I Basic Profile 1.1에 포함되지 않고, 따라서 상호 운용성을 낮추기 때문에 이 옵션은 사용하지 않는 것이 좋습니다.

Windows Communication Foundation

Windows Communication Foundation 클라이언트에 사용되는 서비스의 프록시 클래스는 이 클래스의 메서드로 전달되는 매개 변수를 System.ServiceModel.Channels.Message 개체로 serialize합니다. 그러면 해당 개체는 선택한 바인딩으로 수 및 성격이 결정되는 일련의 채널을 통해 전달됩니다. 이 채널은 일반적으로 해당 채널에서 구현하는 프로토콜에 따라 System.ServiceModel.Channels.Message 개체의 Headers 컬렉션에 System.ServiceModel.Channels.MessageHeader 개체를 추가합니다. 일련의 채널에서 마지막 채널은 항상 전송 채널입니다. 전송 채널은 바인딩으로도 성격이 결정되는 인코더를 사용하여 System.ServiceModel.Channels.Message 개체를 전송 채널에서 서버로 전송하는 바이트 스트림으로 serialize합니다. 서버의 수신기는 바이트 스트림을 받은 다음 인코더를 사용하여 바이트 스트림을 System.ServiceModel.Channels.Message 개체로 deserialize합니다. 그 다음 일반적으로 클라이언트의 채널과 일치하는 일련의 채널을 통해 해당 개체가 전달됩니다. 그런 다음 System.ServiceModel.Channels.Message 개체가 System.ServiceModel.Dispatcher.DispatchRuntime 개체로 전달됩니다. System.ServiceModel.Dispatcher.DispatchRuntime 개체는 호출될 서비스 형식의 메서드를 결정하고 System.ServiceModel.Channels.Message 개체의 데이터를 해당 메서드에서 매개 변수로 예상하는 형식의 인스턴스로 deserialize하고 해당 메서드를 호출합니다.

Windows Communication Foundation에서 데이터 전송을 전달하게 되는 채널의 선택과 작업을 서비스 바인딩을 통해 사용자 지정할 수 있을 뿐만 아니라 사용자 지정 채널도 손쉽게 추가할 수 있습니다. 또한 프록시 및 System.ServiceModel.Dispatcher.DispatchRuntime 작업도 이러한 동작을 통해 조정하거나 전체적으로 사용자 지정할 수 있습니다. 즉, ASP.NET에서는 웹 서비스 요청 처리기를 제어하기 위해 많은 특성을 제공하는 반면, Windows Communication Foundation에서는 이와 비슷한 특성 집합뿐만 아니라 프록시 및 System.ServiceModel.Dispatcher.DispatchRuntime을 제어하기 위한 사용자 지정 코드 형식의 스와핑 옵션도 제공합니다.

System.ServiceModel.Dispatcher.DispatchRuntime은 요청을 처리하기 위해 호출되는 서비스 형식의 메서드를 결정할 때 SOAPAction 헤더를 사용합니다. 기본적으로 Windows Communication Foundation 작업에 대한 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 개체의 데이터를 deserialize할 때 System.ServiceModel.Dispatcher.DispatchRuntime은 기본적으로 System.Runtime.Serialization.DataContractFormatter를 사용합니다. XML 요소의 이름을 deserialize되는 클래스와 일치시키기 위한 System.ServiceModel.DataContract와 System.ServiceModel.DataMember 특성의 Namespace 및 Name 매개 변수의 메커니즘에 관해서는 이미 설명했습니다.

다음과 같이 System.ServiceModel.XmlSerializerFormat 특성을 적용함으로써 System.ServiceModel.Dispatcher.DispatchRuntime에서 System.Xml.Serialization.XmlSerializer를 사용하도록 만들 수 있습니다.

[ServiceContract, XmlSerializerFormat]
public interface IEcho

이 특성은 서비스의 개별 작업에도 적용할 수 있습니다.

deserialization에 System.Runtime.Serialization.DataContractFormatter가 사용되고 있는 경우 System.ServiceModel.DataContractFormat 특성을 사용하여 데이터가 문서 스타일 과 RPC 스타일 중 어느 것으로 예상되는지 제어할 수 있습니다. 이 특성은 다음과 같이 서비스 계약 전체 또는 서비스 계약의 개별 작업에 적용할 수 있습니다.

[ServiceContract]
public interface IItemService
{
    [OperationContract]
    [DataContractFormat(Style=OperationFormatStyle.Rpc)]
    public void DeliverItem(ItemMessage itemMessage);
}

현재 ASP.NET을 사용 중이고 앞으로 Windows Communication Foundation을 사용할 예정이라면 새 ASP.NET 웹 서비스가 Windows Communication Foundation 응용 프로그램과 올바르게 작동하도록 하기 위해 다음과 같은 지침을 따릅니다.

일반 권장 사항

새로운 모든 서비스에 대해 ASP.NET 2.0을 채택합니다. ASP.NET 2.0을 채택하면 물론 새 버전의 개선된 기능과 향상된 기능을 사용할 수 있으며 같은 응용 프로그램에서 ASP.NET 2.0 구성 요소를 Windows Communication Foundation 구성 요소와 함께 사용할 수 있게 됩니다.

프로토콜

WS-I Basic Profile 1.1에 대한 부합 여부를 검증하기 위한 ASP.NET 2.0의 새로운 기능을 사용합니다.

[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(
    ConformsTo = WsiProfiles.BasicProfile1_1,
    EmitConformanceClaims=true)]
public interface IEcho

이 프로필을 따르는 ASP.NET 웹 서비스는 일반적으로 상호 운용성이 더 높고, 미리 정의된 Windows Communication Foundation 바인딩인 System.ServiceModel.BasicHttpBinding을 통해 Windows Communication Foundation 클라이언트와 상호 운용이 가능합니다.

서비스 개발

메시지를 SOAPAction HTTP 헤더가 아닌 SOAP 메시지 본문 요소의 정규화된 이름을 기반으로 발송하려면 System.Web.Services.Protocols.SoapDocumentService 특성을 사용하지 마십시오. Windows Communication Foundation은 SOAPAction HTTP 헤더를 사용하여 메시지를 메서드로 발송합니다.

데이터 표현

System.Xml.Serialization.XmlSerializer에서 기본적으로 형식을 serialize하는 XML은 해당 XML의 네임스페이스가 명시적으로 정의되어 있는 경우 System.RuntimeSerialization.DataContractFormatter에 서 형식을 serialize하는 XML과 의미상 동일하다는 점을 상기하십시오. 따라서 앞으로 Windows Communication Foundation을 채택할 예정이면서 현재 ASP.NET 웹 서비스에 사용할 데이터 형식을 정의하는 경우에는 다음을 수행하십시오.

1. XML 스키마가 아닌 .NET 클래스를 사용하여 데이터 형식을 정의합니다.
2. System.Serializable 특성 및 System.Xml.Serialization.XmlRoot 특성만 클래스에 추가하고, 후자를 사용하여 형식에 대한 네임스페이스를 명시적으로 정의합니다. .NET 클래스가 XML로 변환되는 방식을 제어하기 위해 System.Xml.Serialization 네임스페이스의 다른 특성을 추가하지 않습니다.

이러한 접근 방식을 채택하면 .NET 클래스가 전송을 위해 serialize되는 XML을 많은 부분 변경하지 않고도 System.Runtime.Serialization.DataContract 및 System.Runtime.Serialization.DataMember 특성을 추가하여 나중에 .NET 클래스를 데이터 계약으로 만들 수 있습니다. 그러면 ASP.NET 웹 서비스에서 메시지에 사용되는 동일한 형식이 Windows Communication Foundation 응용 프로그램에서 데이터 계약으로 처리될 수 있으며, 이는 다른 이점과 함께 Windows Communication Foundation 응용 프로그램의 성능 향상이라는 이점을 제공합니다.

보안

IIS의 인증 옵션을 사용하지 마십시오. Windows Communication Foundation 클라이언트에서 지원하지 않습니다. Windows Communication Foundation은 표준 프로토콜에 기반한 더욱 풍부한 옵션을 제공하므로 서비스를 보안해야 하는 경우 즉시 Windows Communication Foundation을 채택해야 합니다.

앞으로 새로운 ASP.NET 응용 프로그램을 Windows Communication Foundation으로 더 쉽게 마이그레이션하려면 앞서 설명한 권장 사항과 다음 권장 사항을 모두 따르십시오.

프로토콜

SOAP 1.2에 대한 ASP.NET 2.0 지원을 사용하지 않습니다.

<configuration>
    <system.web>
        <webServices >
            <protocols>
                <remove name="HttpSoap12"/>
            </protocols>      
        </webServices>
    </system.web>   
</configuration>

Windows Communication Foundation에서는 SOAP 1.1, SOAP 1.2와 같은 별개의 프로토콜을 따르는 메시지가 각각 별개의 끝점을 거치도록 요구하기 때문에 SOAP 1.2에 대한 ASP.NET 2.0 지원은 사용하지 않는 것이 좋습니다. ASP.NET 2.0 웹 서비스가 기본 구성대로 SOAP 1.1과 SOAP 1.2를 모두 지원하도록 구성되면 ASP.NET 웹 서비스의 기존 클라이언트 모두와 호환되는 원래 주소의 단일 Windows Communication Foundation 끝점으로 마이그레이션할 수 없습니다.

서비스 개발

• Windows Communication Foundation을 사용하면 인터페이스 또는 클래스에 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 웹 서비스를 계속 정의해야 합니다.
• 인터페이스를 정의하는 메서드에 최소한의 코드만 사용합니다. 메서드의 작업을 다른 클래스에 위임하도록 합니다. 그러면 새로운 Windows Communication Foundation 서비스 형식에서도 상당한 작업을 해당 클래스로 간단하게 위임할 수 있습니다.
• System.Web.Services.WebMethod 특성의 MessageName 매개 변수를 사용하여 서비스 작업에 명시적 이름을 제공합니다.

  [WebMethod(MessageName="ExplicitName")]
  string Echo(string input);

  ASP.NET에서 작업의 기본 이름은 Windows Communication Foundation에서 제공하는 기본 이름과 다르기 때문에 이렇게 하는 것이 중요합니다. 명시적 이름을 제공함으로써 기본 이름을 사용하지 않아도 됩니다.

• 다형적 메서드로 ASP.NET 웹 서비스 작업을 구현하지 마십시오. Windows Communication Foundation에서는 다형적 메서드로 작업을 구현하는 것을 지원하지 않습니다.
• System.Web.Services.Protocols.SoapDocumentMethod 특성을 사용하여 HTTP 요청을 메서드로 라우팅할 SOAPAction HTTP 헤더에 명시적 값을 제공합니다.

  [WebMethod]
  [SoapDocumentMethod(RequestElementName="ExplicitAction")]
  string Echo(string input);
  

• 이 접근 방식을 취할 경우 ASP.NET에서 사용되는 기본 SOAPAction 값을 사용하지 않아도 되며 Windows Communication Foundation에서도 마찬가지입니다.
• SOAP 확장을 사용하지 마십시오. SOAP 확장이 필요한 경우에는 고려하고 있는 SOAP 확장의 목적이 이미 Windows Communication Foundation에서 제공되는 기능인지 확인하십시오. 이 경우 당장은 Windows Communication Foundation을 채택하지 않는다는 방침을 재고하십시오.

상태 관리

서비스의 상태를 유지하지 마십시오. 상태를 유지하는 것은 응용 프로그램의 확장성을 떨어뜨리는 경향이 있을 뿐만 아니라, Windows Communication Foundation에서 ASP.NET 호환 모드를 통해 ASP.NET 메커니즘을 지원하지만 ASP.NET과 Windows Communication Foundation의 상태 관리 메커니즘은 매우 다릅니다.

예외 처리

서비스에서 송수신할 데이터 형식의 구조를 디자인할 때 클라이언트로 전달하려는 서비스에서 발생할 수 있는 다양한 종류의 예외를 표시하기 위한 구조도 디자인합니다.

[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로 serialize할 수 있는 기능을 부여합니다.

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());

이러한 예외 클래스는 다음과 같이 Windows Communication Foundation의 System.ServiceModel.FaultContract<T>에서 즉시 다시 사용할 수 있습니다.

throw new FaultException<AnticipatedException>(anticipatedException);

보안

• ASP.NET 2.0 프로필을 사용하지 마십시오.
• 서비스에 대한 액세스를 제어하기 위해 ACL을 사용하지 마십시오.
• ASP.NET 2.0 역할 공급자를 사용하여 서비스의 리소스에 대한 액세스를 인증하는 방법을 고려합니다.

ASP.NET 웹 서비스와의 공존

ASP.NET으로 개발된 기존 응용 프로그램을 계속 유지하면서 새로운 개발에는 Windows Communication Foundation을 사용하는 방법을 선택할 수 있습니다. Windows Communication Foundation은 모든 시나리오에서 .NET 응용 프로그램과의 원활한 통신을 위한 최적의 선택이 되도록 고안되었기 때문에 ASP.NET으로는 수행할 수 없었던 방식으로 다양한 소프트웨어 통신 문제를 해결하는 표준 도구로 사용할 수 있습니다.

새로운 Windows Communication Foundation 응용 프로그램은 기존 ASP.NET 웹 서비스와 동일한 컴퓨터에 배포될 수 있습니다. 이러한 ASP.NET 웹 서비스에서 버전 2.0 이전의 .NET 버전을 사용하는 경우 ASP.NET IIS 등록 도구를 사용하여 새 Windows Communication Foundation 응용 프로그램을 호스트할 IIS 응용 프로그램에 .NET Framework 2.0을 선택적으로 배포할 수 있습니다. ASP.NET IIS Registration Tool (Aspnet_regiis.exe) (영문) 문서를 참조하십시오. 이 도구에는 IIS 6 관리 콘솔에 기본적으로 제공되는 직관적인 사용자 인터페이스가 있습니다.

Windows Communication Foundation은 사용하여 ASP.NET 호환 모드에서 실행되도록 구성된 Windows Communication Foundation 서비스를 IIS의 기존 ASP.NET 웹 서비스 응용 프로그램에 추가함으로써 기존 ASP.NET 웹 서비스에 새 기능을 추가할 수 있습니다. ASP.NET 호환 모드 덕분에 새로운 Windows Communication Foundation 서비스의 코드는 System.Web.HttpContext 클래스를 통해 기존 ASP.NET 코드와 동일한 응용 프로그램 상태 정보를 액세스 및 업데이트할 수 있으며 동일한 클래스 라이브러리를 공유할 수 있습니다.

ASP.NET 웹 서비스와 클라이언트를 Windows Communication Foundation으로 마이그레이션

Windows Communication Foundation 클라이언트는 ASP.NET 웹 서비스를 사용할 수 있습니다. System.ServiceModel.BasicHttpBinding으 로 구성되는 Windows Communication Foundation 서비스는 ASP.NET 웹 서비스 클라이언트에서 사용할 수 있습니다. ASP.NET 웹 서비스는 Windows Communication Foundation 응용 프로그램과 공존할 수 있으며, Windows Communication Foundation을 사용하여 기존 ASP.NET 웹 서비스에 기능을 추가할 수도 있습니다. Windows Communication Foundation과 ASP.NET 웹 서비스를 함께 사용할 수 있는 이러한 모든 방식을 고려해 보면 ASP.NET 웹 서비스를 Windows Communication Foundation으로 마이그레이션해야 하는 필연적인 이유는 거의 없습니다.

마이그레이션이 필요한 것으로 보이는 일부 경우에서도, 단순히 한 기술에서 다른 기술로 코드를 마이그레이션하는 것은 대부분 올바른 접근 방식이 아니라는 점을 신중하게 고려하십시오. 새로운 기술을 채택하는 이유는 이전 기술로는 따라갈 수 없는 새로운 요구 사항을 충족하기 위한 것이며, 이러한 경우 새로 확장된 요구 사항을 충족하는 새로운 솔루션을 디자인하는 것이 올바른 방법입니다. 새 디자인은 기존 시스템에서의 경험과 해당 시스템이 디자인된 이후 축적된 지식을 활용할 수 있습니다. 또한 새 디자인은 단순히 새 플랫폼에서 이전 디자인을 재생산하는 것이 아니라 새 기술의 완전한 기능을 충분히 고려할 것입니다. 새 디자인의 주요 요소를 프로토타이핑하면 대개 새 시스템에서 기존 시스템의 코드를 다시 사용하는 방법을 명확하게 알 수 있습니다.

단순히 ASP.NET 웹 서비스에서 Windows Communication Foundation으로 이식하는 것이 올바른 솔루션으로 생각되는 일부 경우에 대한 몇 가지 진행 방법 지침이 있습니다. 서비스를 마이그레이션하는 방법과 클라이언트를 마이그레이션하는 방법에 대한 권장 사항이 있습니다.

ASP.NET 웹 서비스를 Windows Communication Foundation으로 마이그레이션

1. 서비스에 대한 포괄적인 테스트 집합이 있는지 확인합니다.
2. 서비스에 대한 WSDL을 생성하고 해당 서비스의 .asmx 파일과 같은 폴더에 복사본을 저장합니다.
3. .NET 2.0을 사용하도록 ASP.NET 웹 서비스를 업그레이드합니다. 먼저 .NET Framework 2.0을 IIS의 응용 프로그램에 배포한 다음 Visual Studio 2005를 사용하여 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/webprojectsVS05.asp? frame=true(영문) 문서의 설명에 따라 코드 변환 프로세스를 자동화함으로써 업그레이드를 수행합니다. 테스트 집합을 실행합니다.
4. 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;
       }
   }

5. 테스트 집합을 실행합니다.
6. 클래스의 메서드 본문에 있는 코드를 원래 클래스에서 사용하도록 만들어진 별개의 클래스로 옮깁니다.

   [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;
       }
   }

7. 테스트 집합을 실행합니다.
8. Windows Communication Foundation 어셈블리인 System.ServiceModel 및 System.Runtime.Serialization에 대한 참조를 ASP.NET 웹 서비스 프로젝트에 추가합니다.
9. Windows Communication Foundation의 svcutil.exe 도구를 실행하여 WSDL에서 Windows Communication Foundation 프록시 클래스를 생성합니다. 생성된 클래스 모듈을 솔루션에 추가합니다.
10. 앞 단계에서 생성된 클래스 모듈에는 인터페이스 정의가 포함됩니다.

    [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)));
        }
    }

11. 프로젝트를 컴파일합니다. 9단계에서 생성된 코드 때문에 일부 형식 정의가 중복되는 오류가 있을 수 있습니다. 일반적으로 형식에 대한 기존 정의를 삭제하여 이러한 오류를 수정합니다. 테스트 집합을 실행합니다.
12. 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)));
        }
    }

13. Windows Communication Foundation 서비스 형식이 될 클래스를 구성하여 ASP.NET 웹 서비스가 다음 항목을 사용하는 경우 Windows Communication Foundation의 ASP.NET 호환 모드를 요구하도록 합니다.
    • System.Web.Services.HttpContext 클래스
    • ASP.NET 프로필
    • .asmx 파일의 ACL
    • IIS 인증 옵션
    • ASP.NET 가장 옵션
    • ASP.NET 전역화

    [System.ServiceModel.AspNetCompatibilityRequirements(
           RequirementsMode=AspNetCompatbilityRequirementsMode.Require)]
    public class Adder: AdderSoap

14. 원래의 .asmx 파일 이름을 .asmx.old로 바꿉니다.
15. 서비스에 대한 Windows Communication Foundation 서비스 파일을 만들고, 이 파일의 확장명을 .asmx로 지정한 다음 IIS의 응용 프로그램 루트에 저장합니다.

    <%@Service Class="MyOrganization.Adder" %>
    <%@Assembly Name="MyServiceAssembly" %>  

16. 서비스에 대한 Windows Communication Foundation 구성을 Web.config 파일에 추가합니다. BasicHttpBinding을 사용하고, 앞 단계에서 만든 .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>
    

17. 구성을 저장합니다.
18. 프로젝트를 컴파일합니다.
19. 테스트 집합을 실행합니다.

ASP.NET 웹 서비스 클라이언트를 Windows Communication Foundation으로 마이그레이션

1. 클라이언트에 대한 포괄적인 테스트 집합이 있는지 확인합니다.
2. Visual Studio 2005를 사용하여 클라이언트 응용 프로그램을 .NET 2.0으로 업그레이드합니다. 테스트 집합을 실행합니다.
3. 클라이언트 프로젝트에서 ASP.NET 프록시 코드를 제거합니다. 이 코드는 대개 wsdl.exe 도구를 사용하여 생성된 모듈에 있습니다.
4. svcutil.exe 도구를 사용하여 Windows Communication Foundation 프록시 코드를 생성합니다. 이 코드를 클라이언트 프로젝트에 추가하고 구성 출력을 클라이언트의 기존 구성 파일에 병합합니다.
5. 응용 프로그램을 컴파일합니다. 기존 ASP.NET 프록시 형식에 대한 참조를 새 Windows Communication Foundation 프록시 형식에 대한 참조로 바꾸어 컴파일 오류를 수정합니다.
6. 테스트 집합을 실행합니다.

ASP.NET 웹 서비스 도구는 단지 웹 서비스를 빌드하기 위한 것이지만, Windows Communication Foundation은 소프트웨어 엔터티들이 서로 통신하도록 설정되어야 하는 모든 환경에서 사용할 수 있는 도구를 제공합니다. 웹 서비스 개발 프로젝트에서도 Windows Communication Foundation은 ASP.NET 웹 서비스에서 지원하는 것보다 더 많은 웹 서비스 프로토콜을 지원합니다. 이러한 프로토콜은 신뢰할 수 있는 세션과 트랜잭션을 비롯한 여러 가지 장점을 수반하는, 더욱 정교한 솔루션을 제공합니다. 대부분의 경우 권장되는 작업 과정은 기존 ASP.NET 웹 서비스 응용 프로그램을 계속 유지하면서 새로운 개발에는 Windows Communication Foundation을 채택하는 것입니다. 이러한 작업 과정은 Windows Communication Foundation의 이점을 누리면서 기존 응용 프로그램을 마이그레이션해야 하는 비용을 절약해 줍니다. 새 Windows Communication Foundation 응용 프로그램은 기존 ASP.NET 웹 서비스를 사용할 수 있으며 기존 ASP.NET 응용 프로그램과 공존할 수 있습니다. Windows Communication Foundation의 ASP.NET 호환 모드 덕분에 Windows Communication Foundation을 사용하여 기존 ASP.NET 응용 프로그램에 새로운 작업 기능을 프로그래밍할 수도 있습니다.