.NET Framework 4.0과 “Dublin”의 WCF 및 WF 서비스

아티클
06/22/2015

First Look

Aaron Skonnard

이 기사는 .NET Framework 4.0 및 "Dublin"의 시험판 버전을 기준으로 합니다. 모든 정보는 변경될 수 있습니다.

이 기사에서는 다음 내용에 대해 설명합니다.

WF 작업 라이브러리 및 디자이너
.NET Framework 4.0의 향상된 WCF 기능
“Dublin” 확장에 대한 가이드
“Dublin”을 사용한 서비스 구축 및 배포

이 기사에서 사용하는 기술:
.NET Framework 4.0, “Dublin”

.NET Framework 4.0으로의 전환
WF 기본 작업 라이브러리
WF 작업 프로그래밍 모델
.NET Framework 4.0의 추가적인 새로운 WCF 기능
"Dublin"에 대한 필요성
"Dublin"에 대한 가이드
"Dublin"용 WCF 워크플로 서비스 작성
"Dublin"으로 응용 프로그램 배포
실행 중인 응용 프로그램 관리
실행 중인 응용 프로그램 업데이트
실행 중인 응용 프로그램 모니터링
"Dublin"에서 "Oslo"로?
BizTalk Server와의 관계

Microsoft는 2008년 10월 PDC(Professional Developer's Conference)에서 Microsoft .NET Framework 4.0에서 제공될 다양한 향상된 기능, 특히 WCF(Windows Communication Foundation) 및 Windows WF(Workflow Foundation) 분야와 관련된 다양한 기능을 발표했습니다. Microsoft에서는 또한 WCF 및 WF 응용 프로그램을 위한 향상된 호스팅과 관리 환경을 제공하는 코드 이름 "Dublin"이라는 몇 가지 Windows Server 확장을 선보였습니다.

.NET Framework 4.0에 WF와 WCF가 통합됨에 따라 분산 서비스 기반 응용 프로그램을 개발하기가 수월해졌습니다. 향상된 유연성과 비즈니스 민첩성을 제공하는 완전히 선언적인 모델을 사용하여 상태 저장 워크플로 서비스를 작성할 수 있습니다.

"Dublin"에 도입된 새로운 호스팅과 관리 확장은 이러한 프레임워크의 발전을 보완합니다. 프레임워크 자체와 프레임워크를 지원하는 운영 도구의 향상된 기능의 조합을 살펴보면 Windows Server의 응용 프로그램 서버 기능이 커다란 발전을 이루었음을 알 수 있습니다.

이 기사에서는 .NET Framework 4.0의 WCF와 WF의 몇 가지 핵심적인 새 기능을 설명하고 "Dublin" 확장에서 제공되는 새로운 응용 프로그램 서버 기능을 소개하겠습니다.

.NET Framework 4.0으로의 전환

WCF와 WF는 상호 보완적인 기술입니다. 이 두 가지 기술에 익숙하지 않다면 WCF는 외부 기술이고 WF는 내부 기술이라고 생각하면 이해하기 쉽습니다. WCF는 응용 프로그램의 외부 서비스 인터페이스를 공개하는 데 사용되며 WF는 응용 프로그램의 내부 흐름, 상태 및 전환을 기술하는 데 사용됩니다.

.NET Framework 3.5에서는 이 두 기술 간의 몇 가지 매력적인 통합이 추가되었으며, 특히 WF Send 및 Receive 작업 형식으로 추가되었습니다. 이러한 작업을 사용하면 복잡하고 오래 실행되는 워크플로를 위해 여러 서비스 상호 작용을 조율하는 프로세스를 간소화하는 데 WF를 적용할 수 있습니다. WCF 끝점으로 WF 워크플로를 활성화하여 활용 범위를 넓히는 데도 이러한 작업을 사용할 수 있습니다(그림 1 참조). 이를 통해 기본적으로 WF를 WCF 서비스의 구현으로서 적용할 수 있게 됩니다. 이 기사에서는 WCF 서비스를 WCF 워크플로 서비스라고 부르겠습니다.

그림 1 WCF 워크플로 서비스

.NET Framework 3.5에서 WCF 워크플로 서비스를 구현하는 것은 가능하지만 쉬운 작업은 아닙니다. 우선 WCF와 WF 간의 통합 계층에 부족한 부분이 있습니다. .NET Framework 3.5에서 WCF 아티팩트는 WCF 프로그래밍 및 구성 모델을 사용하여 정의 및 구성해야 하지만 워크플로는 다른 모델을 사용하여 정의됩니다. 결과적으로 여러 아티팩트를 별도로 배포, 구성 및 관리해야 합니다.

어려움을 겪는 다른 이유는 현재 기본 작업 라이브러리가 흐름 제어와 논리 작업을 중점적으로 처리하며 작업과 관련된 기능은 충분하게 제공하지 않기 때문입니다. 따라서 WF를 사용하여 현실적인 워크플로 서비스를 구현하려면 사용자 지정 작업 라이브러리를 작성해야 합니다. 이러한 작업은 상당히 복잡하기 때문에 일부 개발자는 WF의 장점을 경험하기 전에 포기하는 경우가 있습니다.

이러한 문제 외에도 현재 WF에는 XAML(eXtensible Application Markup Language) 전용 워크플로에 대한 도구 지원이 없습니다. 이러한 워크플로는 코드 숨김 파일을 사용하지 않고 완전히 XML 파일로 기술되므로 선언적 워크플로라고도 합니다. XAML만을 사용하는 방식은 몇 가지 매력적인 워크플로 호스팅 및 배포 가능성을 현실화할 수 있습니다. 선언적 워크플로의 강점은 이것이 어디에나 저장될 수 있으며 사용되는 작업에 대해 아는 WF 런타임 환경에서 실행될 수 있는 데이터라는 것입니다.

선언적 워크플로는 클라우드의 런타임에 배포하거나 여러분의 자리에 있는 워크스테이션에 배포(작업이 런타임 호스트에 배포했다고 가정하는 경우)할 수 있습니다. 선언적 워크플로는 수정하기가 쉽고 부분 신뢰 시나리오("클라우드"에 대해 생각해 보십시오)에서도 사용할 수 있습니다. XAML 전용 모델은 또한 도구에서 XML 파일만 처리하면 되므로 도구를 개발하기도 쉽습니다.

설계자의 초기 문서에서도 알 수 있듯이 일반적으로 XAML 전용 모델은 WF에서 기술에 대한 궁극적인 비전이었습니다. 그러나 현재의 WF 도구 지원은 이러한 비전을 완벽하게 지원하지 못하고 있습니다. .NET Framework 3.5에서 XAML 전용 워크플로를 작성하는 것이 가능하지만 최신 Visual Studio 템플릿을 사용할 수 없고 디버깅과 같은 중요한 기능을 포기해야 합니다.

.NET Framework 4.0에서 WCF와 WF의 주요 목표는 선언적 모델과 서비스와 관련된 개발자 환경을 간소화하고 XAML 전용 모델을 완전하게 수용하는 것입니다. 또한 Microsoft는 선언적 워크플로 서비스를 정의할 수 있도록 하여 이를 한 차원 향상시키기를 원했습니다. 즉, 서비스 계약 정의, 끝점 구성, 그리고 실제 서비스 구현(XAML 기반 워크플로 형식으로)을 포함하여 WCF 서비스가 완전하게 XAML으로 정의된다는 것입니다.

이를 달성하기 위해 Microsoft는 확장된 기본 클래스 작업 라이브러리, 사용자 지정 작업을 위한 더 간소화된 프로그래밍 모델, 새로운 순서도 워크플로 유형, 그리고 WCF와 관련된 다양한 향상된 기능을 포함하여 .NET Framework 4.0에 향상된 기능을 많이 추가했습니다.

WF 기본 작업 라이브러리

.NET Framework 4.0에는 몇 가지 새로운 작업이 포함되어 있는 향상된 기본 작업 라이브러리가 제공됩니다(그림 2 참조). Microsoft는 또한 주요 .NET Framework 릴리스 중간에 CodePlex를 통해 사용할 수 있는 추가 WF 작업을 개발하는 계획을 가지고 있습니다. 또한 향후 릴리스나 CodePlex에서는 PowerShellCommand 작업과 같은 몇 가지 작업이 추가되어 사용자 지정 작업 개발을 개발해야 할 필요성이 더욱 줄어들 것입니다. 그리고 Microsoft에서도 CodePlex를 사용하므로 여러분이 원하는 추가 작업에 대한 의견이 있다면 Microsoft에 이러한 의견이 전달될 가능성이 높습니다.

.NET Framework 4.0에는 FlowChart, ForEach, DoWhile 및 Break 작업을 포함하여 추가적인 흐름 제어 옵션을 제공하는 몇 가지 핵심 작업이 도입되었습니다. 추가된 작업 중에서도 FlowChart 작업은 Sequential 및 StateMachine 흐름 제어 모델 간에 중간 지점을 제공하는 가장 흥미로운 작업입니다. FlowChart를 사용하면 간단한 결정과 스위치로 향상된 단계별 방식을 적용할 수 있는 것은 물론이고 워크플로의 이전 작업으로 돌아갈 수 있습니다. 일반적으로 많은 사용자들은 순서도에 익숙합니다. 그림 3에는 Visual Studio 2010의 새 워크플로 디자이너에 포함된 순서도 디자이너가 나와 있습니다.

그림 3 새 순서도 작업 디자이너

.NET Framework 4.0에는 CLR 메서드를 호출하는 작업(MethodInvoke), 워크플로 변수에 값을 할당하는 작업(Assign), 실행 중인 워크플로 인스턴스를 명시적으로 지속하는 작업(Persist)을 포함하여 몇 가지 새 런타임 작업도 도입되었습니다.

마지막으로 .NET Framework 4.0에는 워크플로를 서비스로 공개하거나 사용자의 워크플로 내에서 서비스를 사용하기 위한 절차를 간소화하는 새로운 WCF 기반 작업 집합이 추가되었습니다. .NET Framework 3.5에서는 WCF를 통해 메시지를 보내고 받는 Send 및 Receive라는 두 가지 작업을 제공했습니다. 버전 4.0에는 단방향 메시지를 보내고 받는 SendMessage 및 ReceiveMessage 작업(버전 3.5의 Send 및 Receive와 비슷함)이 있으며 ClientOperation 및 ServiceOperation 작업으로 요청/응답 작업을 구현하는 고수준 추상화를 제공합니다. 서비스 작업을 제공하려는 워크플로는 ServiceOperation 작업을 사용해야 합니다. 반면에 외부 서비스를 사용하려는 워크플로는 ClientOperation 작업을 사용해야 합니다.

이러한 핵심 WCF 작업 외에도 .NET Framework 4.0에서는 특정 메시지가 올바른 워크플로 인스턴스로 전달될 수 있도록 보장하기 위한 다양한 단방향 작업 간 상관 관계 지원도 제공합니다. 또한 새로운 상관 관계 범위를 정의하는 작업(CorrelationScope)과 WCF를 통해 아웃바운드 메시지를 전송하기 전에 상관 관계 값을 초기화하는 작업(InitializeCorrelation)을 제공합니다.

새 워크플로 디자이너

Visual Studio 2010에 추가된 새로운 워크플로 디자이너는 이 기사에서 소개된 여러 핵심 WCF 및 WF 기능을 위한 매력적인 그래픽 사용자 인터페이스가 포함되어 있습니다. 이러한 기능에는 범위로 되돌아가기 위해 이동 경로 추적을 수행하는 향상된 워크플로 탐색(복합 작업에 대한 드릴링), 현재 위치에서 작업 편집(속성 창을 사용해야 하는 필요성 감소), 확대/축소, 그리고 개요 탐색과 같은 기능이 있습니다. 또한 새로운 디자이너는 사용자 지정과 다시 호스팅을 위한 개선된 모델을 제공합니다. 이밖에도 Visual Studio 2010에서는 순서도 및 XAML 전용 워크플로를 신속하게 시작할 수 있는 새롭고 개선된 프로젝트 템플릿 세트가 제공되며, 선언적 워크플로 및 서비스에 대한 작업을 위한 완전한 XAML 기반 디버깅 지원도 제공됩니다.

WF 작업 프로그래밍 모델

이러한 향상된 기능이 추가되었지만 여전히 사용자 지정 작업을 작성해야 하는 경우가 있습니다. 그래서 Microsoft는 이 작업을 수월하게 할 수 있도록 사용자 지정 작업을 위한 기본 클래스를 다시 디자인했습니다. 사용자 지정 작업을 위한 새로운 기반 클래스는 WorkflowElement라고 하며 여기에서 파생된 Activity라는 클래스도 있습니다. Activity 클래스를 사용하면 기존 작업을 사용하여 코드를 전혀 작성하지 않거나 조금만 작성하여 수월하게 새 사용자 지정 작업을 만들 수 있습니다.

예를 들어 Figure 4에서는 Activity에서 파생하고 CreateBody를 다시 정의하여 CopyFile이라는 새로운 사용자 지정 작업을 정의하는 방법을 보여 줍니다. 구현에서는 기본 제공 copy-item 명령을 사용하도록 구성된 사용자 지정된 PowerShellCommand 인스턴스를 만듭니다. 이러한 종류의 코드를 작성하고 싶지 않은 경우에는 Visual Studio 2010의 새 워크플로 디자이너를 사용하여 그래픽 작업 디자이너를 통해 손쉽게 사용자 지정 작업을 작성할 수 있습니다.

그림 4 사용자 지정 CopyFile 작업

class CopyFile : Activity
{
    public InArgument<string> Source { get; set; }
    public InArgument<string> Destination { get; set; }

    protected override WorkflowElement CreateBody()
    {
        return new PowerShellCommand
        {
            CommandText = "copy-item",
            Parameters = 
            { 
                { "path", new InArgument<string>(Source) }, 
                { "destination", new InArgument<string>(Destination) } , 
                { "recurse",  new InArgument<bool>(false) } 
            },
        };
    }
}

기존 작업에 기반을 두지 않는 사용자 지정 작업을 처음부터 정의해야 하는 경우 WorkflowElement에서 파생시키고 Execute 메서드를 다시 정의해야 합니다. 이러한 방법은 코드가 조금 더 필요하며 현재 Activity로부터 파생시킬 때의 작동 방식과 비슷합니다. 한편 Microsoft는 이러한 사용자 지정 작업 작성과 관련된 작업을 더욱 간소화시켰습니다.

사용자 지정 작업을 작성하는 것이 어려운 이유 중 하나는 작업에 들어오고 나가는 데이터 흐름을 관리해야 하기 때문입니다. 예를 들어 현재는 작업으로 들어오고 나가는 형식이 지정된 인수 집합을 정의할 수 없습니다. 일반적으로 개발자들은 워크플로 큐로부터 인수를 직렬화 및 역직렬화하는 사용자 지정 클래스를 작성하는 경우가 많습니다(자세한 내용은 Michael Kennedy의 기사 "장기 실행 작업을 지원하는 웹 응용 프로그램" 참조). 이러한 내부 코드를 작성하기는 어렵지 않지만 추가적인 작업이기 때문에 응용 프로그램 흐름을 모델링하는 주요 목표에는 방해가 됩니다. .NET Framework 4.0에서는 작업을 크게 간소화할 수 있는 세 가지 데이터 흐름 개념인 인수, 변수 및 식을 통해 작업 프로그래밍 모델이 확장되었습니다.

작업으로 들어오고 나가는 데이터 흐름은 인수를 사용하여 정의할 수 있습니다. 각 인수에는 입력, 출력 또는 입력/출력과 같은 바인딩 방향을 지정합니다. 다음 예에서는 "AuditMessage"라는 입력 인수 하나가 있는 간단한 Audit 작업을 작성하는 방법을 보여 줍니다.

public class Audit: WorkflowElement {
    public InArgument<string> AuditMessage{ get; set; }

    protected override void Execute(ActivityExecutionContext context) {
        WriteToEventLog(AuditMessage.Get(context));
    }
}

변수는 데이터를 위한 이름이 지정된 저장소를 선언하는 방법입니다. XAML 기반 워크플로에서는 물론 코드에서도 변수를 정의할 수 있습니다. 변수는 워크플로 내에서(중첩된 워크플로 요소 내) 다른 범위로 정의할 수 있으며 디자인 타임에는 워크플로 프로그램 정의의 일부이지만 런타임에는 워크플로 인스턴스에 값이 저장됩니다.

다음 예에서는 message라는 변수를 정의하고, 새로운 Assign 작업으로 변수에 값을 할당한 다음, 이 변수의 값을 앞에서 정의한 사용자 지정 Audit 작업으로 전달하는 XAML 워크플로를 작성하는 방법을 보여 줍니다.

<Sequence 
    xmlns="https://schemas.microsoft.com/netfx/2009/xaml/workflowmodel" 
    xmlns:p="https://schemas.microsoft.com/netfx/2008/xaml/schema" 
    xmlns:s="clr-namespace:Samples;assembly=Samples" 
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml">
    <Sequence.Variables>
        <Variable Name="message" x:TypeArguments="p:String" />
    </Sequence.Variables>
    <Assign x:TypeArguments="p:String" To="[message]" 
        Value="Audit message: something bad happened" />
    <s:Audit Text="[message]" />
</Sequence>

식은 하나 이상의 입력 인수를 받고 이러한 입력 인수에 대해 약간의 작업이나 동작을 수행한 다음 값을 반환하는 구문입니다. 식은 WorkflowElement에서 파생되는 ValueExpression에서 클래스를 파생시켜 정의되므로 작업을 사용할 수 있는 곳에는 어디에나 식을 사용할 수 있습니다. 식은 다른 작업의 인수에 대한 바인딩으로 사용할 수도 있습니다. 이 예는 간단한 Format 식을 정의합니다.

public class Format : ValueExpression<string> {
    public InArgument<string> FormatString { get; set; }
    public InArgument<string> Arg { get; set; }

    protected override void Execute(ActivityExecutionContext context) {
        context.SetValue(Result, 
            String.Format(FormatString.Get(context), Arg.Get(context)));
    }
}

이 식은 다른 작업과 마찬가지로 사용자의 XAML 워크플로에 통합할 수 있습니다. 예를 들어 다음 워크플로는 결과를 이벤트 로그에 기록하기 위해 Format 식의 결과를 Audit 작업으로 전달하는 방법을 보여 줍니다. 여기에서는 Audit의 내용이 message 인수에 매핑된다고 가정합니다.

<Sequence 
    xmlns="https://schemas.microsoft.com/netfx/2009/xaml/workflowmodel" 
    xmlns:p="https://schemas.microsoft.com/netfx/2008/xaml/schema" 
    xmlns:s="clr-namespace:Samples;assembly=Samples" 
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml">
    <Sequence.Variables>
        <Variable Name="message" x:TypeArguments="p:String" />
    </Sequence.Variables>
    <s:Audit>
        <s:Format FormatString="Audit message: {0}" Arg="[message]"/>
    </s:Audit>
</Sequence>

루트 작업에도 역시 특별한 것은 없습니다. WorkflowElement에서 파생되는 모든 것은 워크플로 내의 루트나 어떤 곳에도 사용될 수 있습니다. 이를 통해 워크플로 스타일 내에서 다른 워크플로 스타일을 원하는 대로 구성할 수 있습니다. 예를 들어 시퀀스 내의 순서도 내에 상태 시스템을 구성할 수 있습니다.

이러한 프로그래밍 모델의 변경이 이루어짐에 따라 이제는 데이터 흐름 속성을 정의하기 위한 명령형 코드 숨김 파일이 필요 없게 되었으며 모든 작업을 XAML에서 선언적으로 수행할 수 있습니다. 그러나 이러한 변경은 상당히 근본적인 변경이기 때문에 WF 런타임이 많이 수정되어 궁극적으로 .NET Framework 3.x 작업과의 호환성이 없어졌습니다. 자세한 내용은 워크플로 마이그레이션에 대한 보충 기사를 참조하십시오. 그러나 Microsoft에서는 여전히 WF 프로그래밍 모델을 간소화하는 것이 결과적으로는 WF 개발자에게 이익이 될 것으로 보고 있습니다.

.NET 4.0으로 워크플로 마이그레이션

새로운 .NET Framework 4.0 작업 프로그래밍 모델을 위해서는 핵심 WF 런타임에 상당한 변화가 필요합니다. 결과적으로 .NET Framework 3.0 및 3.5용으로 디자인된 사용자 지정 작업은 몇 가지 세심한 주의가 없으면 .NET Framework 4.0 워크플로 호스트 내에서 실행되지 않습니다.

.NET Framework 4.0에서는 상호 운용성을 높이기 위해 사용자 지정 .NET 3.x 작업을 .NET 4.0 호스트 내에 손쉽게 래핑할 수 있는 특수한 Interop 작업을 제공합니다. 이 방식을 모든 .NET 3.x 작업에 사용할 수 있는 것은 아니며 루트 작업의 경우에는 작동하지 않습니다. 따라서 Visual Studio 2010으로 전환할 때는 새 워크플로를 사용하여(워크플로 디자이너 역시 크게 변경되었음) 워크플로를 다시 디자인하고 새 워크플로 정의 내에서 새 Interop 작업을 사용하여 사용자 지정 .NET 3.x 작업을 래핑해야 합니다.

.NET Framework 4.0의 추가적인 새로운 WCF 기능

워크플로를 사용하여 WCF 서비스를 구현하는 방법을 이해하기는 쉽지만 진정으로 선언적인 워크플로 서비스를 만들려면 선언적 XAML 전용 모델을 사용하여 서비스 계약을 정의하고 끝점 정의를 구성하는 방법이 필요합니다. 바로 이것이 .NET Framework 4.0에서 WCF의 역할입니다. 다음과 같은 WCF 서비스 계약 정의가 있다고 가정해 보겠습니다.

[ServiceContract]
public interface ICalculator
{
    [OperationContract]
    int Add(int Op1, int Op2);
    [OperationContract]
    int Subtract(int Op1, int Op2);
};

.NET Framework 4.0에서는 다음과 같은 XAML 정의를 사용하여 같은 계약을 선언적으로 정의할 수 있습니다.

<ServiceContract Name="ICalculator">
    <OperationContract Name="Add">
        <OperationArgument Name="Op1" Type="p:Int32" />
        <OperationArgument Name="Op2" Type="p:Int32" />
        <OperationArgument Direction="Out" Name="res1" Type="p:Int32" />
   </OperationContract>
   <OperationContract Name="Subtract">
        <OperationArgument Name="Op3" Type="p:Int32" />
        <OperationArgument Name="Op4" Type="p:Int32" />
        <OperationArgument Direction="Out" Name="res2" Type="p:Int32" />
   </OperationContract>
</ServiceContract>

이제 XAML을 사용하여 서비스 계약을 정의했으므로 다음 단계는 계약을 프로젝션하여 연결하는 방식을 정의하는 것입니다. .NET Framework 4.0에는 주고받는 메시지 표현으로부터 논리 계약 정의를 분리하기 위한 계약 프로섹션의 개념이 도입되었습니다. 이를 통해 다른 방식으로 프로젝션되어 다양한 메시징 스타일을 지원하는 단일 서비스 계약을 정의할 수 있게 됩니다.

예를 들어 동일한 논리 서비스 계약에 기반을 두는 SOAP 기반 메시징용 계약 프로젝션과 REST/POX 메시징용 프로젝션을 사용하는 것이 가능합니다. 다음은 방금 정의한 서비스 계약에 대한 SOAP 계약 프로젝션을 정의하는 방법을 보여 줍니다.

<Service.KnownProjections>
    <SoapContractProjection Name="ICalculatorSoapProjection">
        <!-- service contract definition goes here -->
    </SoapContractProjection>
</Service.KnownProjections>

계약 정의와 프로젝션이 준비되었으므로 이제는 XAML로 서비스 논리를 구현할 수 있습니다. XAML 서비스 정의의 루트 요소는 Service입니다. Service 요소는 Service.KnownProjections 자식 요소에 계약과 프로젝션 정의를 포함합니다. 선언적 워크플로인 서비스 구현은 Service.Implementation 요소에 있습니다. 마지막으로 서비스의 끝점 구성은 Service.Endpoints 요소에 있습니다. 그림 5에는 XAML로 되어 있는 전체 선언적 정의가 나와 있습니다.

그림 5 선언적 WCF 서비스

<Service xmlns="clr-namespace:System.ServiceModel;assembly=System.WorkflowServiceModel"
     xmlns:p="https://schemas.microsoft.com/netfx/2008/xaml/schema"
     xmlns:ss="clr-namespace:System.ServiceModel;assembly=System.ServiceModel"
     xmlns:sw="clr-namespace:System.WorkflowServiceModel;assembly=System.WorkfowServiceModel"
     xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
     xmlns:x2="https://schemas.microsoft.com/netfx/2008/xaml">
    <Service.KnownProjections>
        <SoapContractProjection x:Name="ICalculatorSoapProjection">
            <ServiceContract x:Name="ICalculatorContract"
                <OperationContract Name="Add" x:Name="Add">
                    <OperationArgument Name="Op1" Type="p:Int32" />
                    <OperationArgument Name="Op2" Type="p:Int32" />
                    <OperationArgument Direction="Out" Name="Result" 
                     Type="p:Int32" />
                </OperationContract>
            </ServiceContract>
        </SoapContractProjection>
    </Service.KnownProjections>
    <Service.Implementation>
        <sw:WorkflowServiceImplementation>
              <!-- place service implementation here -->
        </sw:WorkflowServiceImplementation>
    </Service.Implementation>
    <Service.Endpoints>
        <Endpoint Uri="http://localhost:8080/calc" 
         ContractProjection="{x2:Reference ICalculatorSoapProjection}">
            <Endpoint.Binding>
                <ss:BasicHttpBinding />
            </Endpoint.Binding>
        </Endpoint>
    </Service.Endpoints>
</Service>

이 초기 단계의 단점 중 하나는 서비스를 선언적으로 작성할 수 있도록 지원하는 시각적 디자이너가 없다는 것입니다. Microsoft가 CTP(Community Technology Previews)가 발표할 때는 XAML 정의를 작성하기 위한 사용하기 편리한 디자이너 환경을 제공하기를 기대해 보겠습니다.

앞에서 언급한 선언적 서비스 지원과 WCF 기반 작업 외에도 .NET Framework 4.0에는 몇 가지 저수준의 향상된 WCF 기능이 되입되었습니다. 이러한 기능 중 일부는 새로운 "Dublin" 확장을 통해 워크플로 서비스를 관리를 가능하게 하기 위한 것입니다. 이러한 기능에는 개선된 구성, 메시지 상관 관계, 견고한 이중 통신, 견고한 타이머, 그리고 ETW(Windows 이벤트 추적) 추적 통합이 포함됩니다. 이밖에도 관리되는 환경에서 서비스를 호스팅할 때 가치를 더하는 다른 기능에는 표준 제어 끝점 및 자동 시작이 포함되며 이러한 기능에 대해서는 앞으로 몇 달 동안 더 다루어질 것입니다.

"Dublin"에 대한 필요성

실제 환경에서 WCF와 WF를 사용할 때의 다른 과제 중 하나는 서버 환경에서 서비스와 워크플로를 호스트하는 위치를 결정하는 것입니다. WCF의 경우 이 대답은 비교적 쉽습니다. 가장 일반적인 선택은 Windows Server 2008의 IIS와 WAS(Windows Process Activation Service)입니다.

현재 IIS와 WAS를 조합하면 들어오는 메시지에 응답하여 프로세스 활성화, 프로세스 모니터링 및 상태 관리, 프로세스 재활용, CLR AppDomain 통합, 기본 제공 보안, 그리고 IIS 관리자와 Windows PowerShell cmdlet을 통해 사용할 수 있는 몇 가지 기본적인 관리 기능을 포함하여 다양한 핵심 기능이 제공됩니다. 이러한 기능을 직접 만들기를 원하는 사람은 거의 없기 때문에 서버 환경에서 WCF 서비스를 호스팅하는 데는 일반적으로 IIS/WAS가 올바른 선택이 됩니다.

IIS/WAS 조합으로 WCF 응용 프로그램 호스팅을 위한 기반이 마련되었지만 몇 가지 중요한 영역에서 부족한 면이 있습니다. 특히 서비스 관리 영역이 가장 부족합니다. IIS/WAS 조합은 서비스 추적, 모니터링, 실행 중인 서비스 인스턴스 진단과 같은 WCF 전용 서비스 관리 기능을 전혀 제공하지 않습니다. 예를 들어 현재로서는 IIS에 구성된 모든 WCF 서비스를 나열하는 작업이 불가능합니다. 호스팅되는 모든 서비스의 상태를 쿼리할 수 없기 때문입니다. IIS/WAS 조합에는 확장 배포 간소화 또는 공통 WCF 구성 작업을 위한 기본 제공 지원도 없는데 특히 후자는 WCF에서 까다로운 부분입니다.

여러 서버 팜에서 장기 실행 워크플로를 지원하려면 기본적으로 상태 저장 모델이 요구되기 때문에 서버 환경에서 WF 응용 프로그램을 호스팅하기는 더욱 까다롭습니다. 이러한 복잡성 때문에 Microsoft는 .NET Framework 3.0에 WF 서버 호스트를 제공하지 않았으며 개발자가 직접 이를 작성해야 합니다. 그러나 .NET Framework 3.5부터는 WorkflowServiceHost 클래스가 도입되면서 기본적으로 WF 워크플로를 WCF 서비스로 호스트할 수 있게 되었으며 이에 따라 IIS/WAS 내에서 WF 워크플로를 호스트하는 것이 가능해졌습니다.

WorkflowServiceHost는 좋은 출발이었지만 전체 여러 웹 서버 팜에서 상태 저장 워크플로를 관리하기 위한 도구 지원이나 런타임에 실행 중인 워크플로 인스턴스를 모니터링 및 관리하기 위한 도구 지원이 없었습니다.

대부분의 개발자는 BizTalk Server와 서비스 및 워크플로 관리 기능 면에서 비슷하면서도 더 간소화된 환경을 원합니다. 많은 조직에서 BizTalk 관리 환경을 원하지만 BizTalk Server MessageBox의 기본적인 통합 기능이나 신뢰성 의미 체계(또한 이에 따른 성능 저하)는 원하지 않은 경우가 많습니다. WCF와 WF 응용 프로그램을 위해 특별히 디자인된 단순한 모델이 더 적절합니다.

"Dublin"에 대한 가이드

Microsoft는 WCF 및 WF 응용 프로그램을 위한 유용한 호스팅 및 관리 기능을 제공하는 코드 이름 "Dublin"이라는 Windows Server 확장 집합을 준비하고 있습니다. "Dublin"은 기본적으로 IIS/WAS에 기반을 두는 서비스 관리 확장의 집합으로 Windows Server의 일부로 제공될 예정입니다. "Dublin" 확장을 사용하면 서비스와 워크플로는 여전히 IIS/WAS에서 호스팅되지만 현재 IIS/WAS에는 없는 추가적인 WCF와 WF 전용 관리 기능과 도구를 응용 프로그램에서 사용할 수 있습니다.

향후 버전의 Windows Server에는 다양한 "Dublin" 확장이 Windows Server 응용 프로그램 서버 역할의 일부로 제공될 것입니다. 이 때문에 이 기능 집합은 Microsoft에서 인정한 공식 이름은 아니지만 Windows Application Server라고 불리기도 합니다. 이 기사의 나머지 부분에서는 이 새로운 Windows Server Application Server 확장을 간단하게 "Dublin"이라고 부르겠습니다.

"Dublin" 확장에서 제공하는 핵심 기능에는 안정적이고 견고한 서비스와 장기 실행 워크플로를 위한 관리 지원이 포함되어 있습니다. "Dublin"을 사용하면 응용 프로그램을 팜의 여러 개별적인 서버에 배포할 수 있으며 세부적인 서비스 관리 작업에 필요한 도구도 제공됩니다. 이러한 기능에 대한 자세한 내용은 다음 섹션에서 설명하기로 하고 먼저 그림 6에 나와 있는 아키텍처 개요를 살펴보겠습니다.

그림 6 “Dublin” 아키텍처

여기에서 볼 수 있듯이 "Dublin"에서는 서비스 지속성과 모니터링을 위한 기반이 되는 몇 가지 런타임 데이터베이스를 제공합니다. .NET Framework에서 제공하는 런타임 구성 요소와 서비스 계층이 있으며 이 계층은 이러한 데이터베이스에 기반을 둡니다. "Dublin"에서는 이러한 런타임을 더욱 확장하여 통합된 호스팅, 지속성, 모니터링 및 메시징 기능을 제공합니다. 이 계층과 기본 런타임 데이터베이스를 합친 것을 "Dublin"이라고 합니다.

아키텍처의 최상위 두 개의 계층은 "Dublin"을 사용할 수 있도록 만들어 주는 것입니다. Windows PowerShell cmdlet을 통해 다양한 기능을 스크립팅할 수 있도록 해 주는 관리 API 계층이 있습니다. 그 위에는 IIS 관리자 환경이 있으며 이는 실질적으로 Windows PowerShell cmdlet에 기반을 두고 있기 때문에 현재 대부분의 IIS 관리자에게 익숙하게 느껴질 것입니다. 따라서 IIS 관리자에서 할 수 있는 모든 일은 Windows PowerShell에서도 할 수 있습니다.

Microsoft는 이 섹션에서 살펴본 다양한 호스팅 및 관리 작업을 수행하기 위한 다양한 UI 확장을 IIS 관리자에 추가했습니다. 그중에서도 응용 프로그램 배포 및 구성, 응용 프로그램 관리, 그리고 응용 프로그램 모니터링을 위한 확장이 있습니다. 이러한 확장은 또한 실행, 일시 중단 또는 지속된 워크플로 인스턴스와 같은 항목을 보여 주는 시스템의 런타임 대시보드도 제공합니다.

"Dublin"용 WCF 워크플로 서비스 작성

Visual Studio 2010에서 새로운 프로젝트 템플릿(그림 7 참조)을 사용하면 매우 손쉽게 "Dublin" 확장을 대상으로 서비스를 작성할 수 있습니다. 이 프로젝트 템플릿은 "Dublin"에서 제공하는 지속성 공급자와 견고한 타이머 서비스로 미리 구성된 web.config를 제공합니다.

그림 7 새로운 “Dublin” 서비스 라이브러리 만들기

프로젝트를 생성한 다음에는 이 기사 앞부분에서 설명한 다양한 기술을 사용하여 WCF 워크플로 서비스를 구현하는 데 집중할 수 있습니다. 새로운 워크플로 디자이너 환경에서는 그래픽 워크플로 개발 방식으로 전체 서비스를 구현하는 것이 가능해졌습니다. 전체 워크플로 서비스 작성을 완료한 다음에는 "Dublin" 확장이 활성화된 Windows Server로 서비스를 배포할 준비가 된 것입니다.

웹 응용 프로그램에 일반적으로 사용하는 모든 기술을 사용하여 서비스를 IIS/WAS로 배포할 수 있습니다. 환경에서 허용하는 경우에는 Visual Studio에서 직접 배포하는 것도 가능합니다. Windows PowerShell cmdlet을 사용하여 이러한 작업을 자동화할 수도 있으며 이러한 cmdlet으로 WCF 및 WF 환경을 위한 자동화된 배포 스크립트를 작성할 수 있습니다. 이러한 cmdlet을 사용해 보려면 Windows Application Server에서 Windows PowerShell을 열고 "help <command>"를 입력하면 특정 명령을 시작하는 방법을 확인할 수 있습니다. 배포한 다음에는 IIS 관리자를 사용하여 그림 8에 표시된 다양한 "Dublin" 확장에 액세스할 수 있습니다.

그림 8 IIS 관리자의 “Dublin” 확장

"Dublin"으로 응용 프로그램 배포

그림 9 “Dublin” 확장으로 서비스 보기 및 구성

Get-ServicePersistence, Set-ServicePersistence, Enable-ServiceTracking 및 Get-TrackingParticipant를 포함하여 이러한 작업을 수행하기 위한 여러 Windows PowerShell cmdlet이 있습니다. 이것은 응용 프로그램 서버 환경의 설정과 구성을 자동화하기가 훨씬 쉽다는 것을 의미합니다.

실행 중인 응용 프로그램 관리

개발자와 시스템 관리자는 응용 프로그램의 수명 주기에서 응용 프로그램 상태를 모니터링하고, 문제가 있는 워크플로 인스턴스 식별 및 확인하며, 필요한 경우 이를 종료할 수 있는 기능이 필요합니다. "Dublin"에는 이러한 일반적인 관리 필요성을 충족하기 위한 다양한 확장이 포함되어 있습니다.

IIS 관리자에서 지속형 인스턴스 옵션을 선택한 경우(그림 8 참조) 지속되었으며 일시 중단이 가능한 실행 중인 워크플로 인스턴스에 대한 개요를 제공하는 대시보드가 표시됩니다. 개요 상자에는 서버, 사이트 또는 응용 프로그램(선택한 범위에 따라)에 배포된 응용 프로그램과 서비스의 전체 수가 표시됩니다.

그림 10 지속형 워크플로 인스턴스 보기

지속형 인스턴스 상자에는 실행 및 지속된 워크플로 인스턴스의 요약이 표시되며, 차단 또는 일시 중단된 항목(오류가 발생하여 종료되었음을 의미)이 강조 표시됩니다. 일시 중단된 인스턴스는 일반적으로 사용자가 직접 처리해야 하는 항목이므로 가상 경로, 서비스 이름 또는 예외 유형별로 수월하게 일시 중지된 인스턴스를 세부적으로 구분할 수 있는 다른 상자가 제공됩니다.

파란색으로 표시된 링크를 클릭하면 지속형 인스턴스의 목록을 표시하고 해당하는 세부 정보를 볼 수 있습니다. 이 시점에는 오른쪽 창에 표시되는 작업에서 선택하여 서비스 인스턴스를 수동으로 일시 중단, 종료 또는 중단할 수 있습니다. 서비스 인스턴스를 일시 중단하면 인스턴스 실행이 중지되고 새 메시지를 수신하지 못하게 됩니다. 일시 중단된 인스턴스는 나중에 다시 시작할 수 있으며 그러면 메시지를 다시 받을 수 있게 됩니다. 서비스 인스턴스를 종료하면 인스턴스 실행이 중지되고 지속성 저장소에서 제거되므로 다시 시작할 수 없습니다. 마지막으로 서비스 인스턴스를 중단하면 지정된 인스턴스와 관련된 메모리 내 상태가 삭제되고 지속성 저장소에 저장되어 있는 마지막 지속성 지점으로 되돌아갑니다.

그림 11 개별 지속형 인스턴스 보기

Windows PowerShell Get-ServiceInstance 및 Stop-ServiceInstance cmdlet은 명령줄에서 동일한 기능을 수행하며 특정 서비스 인스턴스를 식별하기 위한 다양한 명령줄 옵션을 제공합니다.

실행 중인 응용 프로그램 업데이트

실제 시스템과 관련된 작업의 까다로운 측면 중 하나는 주기적으로 이를 업데이트해야 하는 필요성이 있다는 것입니다. 매우 복잡한 분산 응용 프로그램에서 데이터베이스, 비즈니스 논리, 그리고 서비스 코드에 대한 동시 업데이트가 필요한 경우 이를 올바르게 수행하기가 매우 어렵습니다. 일반적으로 응용 프로그램이 실행 중인 동안에는 많은 업데이트를 원자 단위로 적용하는 것이 불가능합니다.

이 문제에 대한 한 가지 해결책은 업데이트를 수행하는 동안 응용 프로그램을 오프라인으로 만드는 것입니다. 그러나 이 방법도 실제로 고려해 보면 웹 사이트에 대한 업데이트를 동시에 수행하는 동안 IIS/WAS 응용 프로그램을 오프라인으로 만드는 쉬운 방법이 없다는 문제가 있습니다. 이러한 영역에 "Dublin" 확장의 간단한 오프라인 기능이 제 역할을 할 수 있습니다.

IIS 관리자에서 응용 프로그램을 선택한 다음 그림 8에 나와 있는 오른쪽 창에서 Disable Protocols(해제 프로토콜) 명령을 선택하면 됩니다. 향후 릴리스에서는 이름이 변경될 수 있으므로 주의하십시오. 이렇게 하면 응용 프로그램 서비스의 모든 인스턴스가 차단된 상태로 종료되거나 자연스럽게 실행이 완료되며 그동안 들어오는 모든 신규 요청은 처리되지 않습니다.

이제 기본적으로 이 응용 프로그램에 대한 메시지 흐름이 중지된 것이며 클라이언트가 서비스에 메시지를 전송하면 오류가 발생합니다. BizTalk Server와는 달리 메시지가 큐에 보관되지 않습니다. 이 작업이 내부적으로 수행되는 방식은 상당히 간단합니다. "Dublin" 확장은 업데이트한 다음 손쉽게 복원할 수 있도록 이 특정 응용 프로그램의 모든 프로토콜 처리기를 제거하고 저장합니다.

응용 프로그램이 오프라인이 되면 필요한 업데이트를 수행할 수 있습니다. 업데이트를 완료하고 응용 프로그램을 다시 온라인으로 전환할 준비가 되면 Restore Protocols(복원 프로토콜) 명령을 선택하면 됩니다. 명령줄에서는 Windows PowerShell Disable-ApplicationMessageFlow 및 Enable-ApplicationMessageFlow cmdlet을 사용하여 이러한 동일한 작업을 수행할 수 있습니다.

실행 중인 응용 프로그램 모니터링

업무가 어떻게 진행되고 있는지 확인하고 어떤 변경이 필요한지 확인하려면 실행 중인 응용 프로그램을 모니터링하는 기능도 필요합니다. WCF와 WF 런타임에서는 "Dublin" 확장의 기반이 되는 추적 인프라를 기본 제공하므로 WCF와 WF 응용 프로그램 내에서 수월하게 모니터링할 수 있습니다.

그림 12 기본적인 추적 구성

.NET Framework 4.0 추적 인프라에는 프로파일 추적과 참가자 추적의 두 주요 요소가 있습니다. 개발자가 런타임에 추적할 이벤트를 알리는 추적 프로필을 정의하면 추적 참가자가 이러한 이벤트를 구독할 수 있습니다.

"Dublin"에는 유용한 일반적인 이벤트 집합을 손쉽게 추적할 수 있도록 몇 가지 기본 제공 추적 프로필이 포함되어 있습니다. IIS 관리자에서 특정 서비스로 이동한 다음 오른쪽 창에서 Tracking(추적)을 선택하면 손쉽게 사용자의 응용 프로그램에 대한 추적을 설정할 수 있습니다.

이렇게 하면 그림 12와 같은 대화 상자가 표시되며 여기에서 워크플로와 서비스에 대한 몇 가지 기본적인 추적 기능을 구성할 수 있습니다. 구성을 완료하면 구성에 대한 적절한 업데이트가 수행되고 WCF/WF 추적 인프라가 시작됩니다.

원하는 경우에는 "Dublin" 확장을 통해 추적 데이터를 볼 수도 있습니다. 지속형 서비스 인스턴스를 조사하는 동안 View Tracking Data(추적 데이터 보기)를 선택할 수 있으며 그러면 모니터링 저장소에 대한 SQL 쿼리를 실행되고 추적 이벤트 목록이 생성됩니다(그림 13 참조). 사용자 지정 이벤트를 추적하려는 경우에는 사용자 지정 추적 프로필을 정의하고 기본 IIS 관리자 보기의 Tracking Profiles(추적 프로필) 옵션을 사용하여 이를 구성할 수 있습니다.

그림 13 추적 데이터 보기

여기에서 "Dublin"의 모든 기능을 설명하기에는 지면이 부족하지만 소개가 필요한 몇 가지 매력적인 기능이 있으며 자세한 내용은 "추가적인 Dublin의 기능" 보충 기사를 참조하십시오. 그러나 이에 앞서 "Dublin"의 역할과 "Dublin"이 제공하는 몇 가지 핵심 기능을 확실하게 이해하는 것이 중요합니다.

"Dublin"에서 "Oslo"로?

코드 이름 "Oslo"라는 플랫폼에 대해 들어 보았다면 이것이 "Dublin"과 어떤 관계가 있는지 궁금할 것입니다. 간단히 소개하자면 "Oslo"는 Microsoft에서 분산 응용 프로그램의 디자인과 개발을 간소화하기 위해 개발 중인 새로운 모델링 플랫폼입니다. 이 모델링 플랫폼은 "M"이라고도 하는 "Oslo" 모델링 언어, "Oslo" 리포지토리, 그리고 "Quadrant"라고도 하는 "Oslo" 모델링 도구의 세 가지 주요 구성 요소로 이루어져 있습니다. "Oslo"는 다른 응용 프로그램과 기술이 기반으로 사용하여 모델링 기반 방식을 통해 사용자 환경을 간소화할 수 있는 플랫폼입니다.

추가적인 Dublin의 기능

이 기사에서 모두 설명할 수는 없지만 "Dublin"에는 몇 가지 다른 기능이 포함되어 있습니다. 그러나 그중에서도 중앙 집중식 지속성 데이터베이스를 통해 팜에서 지속형 서비스 인스턴스를 관리하는 등의 기존 부하 분산 솔루션과 통합되는 서버 팜에 대한 확장 배포 지원에 대해서는 알아둘 필요가 있습니다. 기본 제공 오류 처리 논리를 사용하면 지속형 인스턴스를 팜의 어떤 노드에서나 실행할 수 있으며 여러 노드가 동일한 인스턴스를 위해 경쟁할 때 발생하는 경합 상황이 방지됩니다.

다른 중요 구성 요소로 전달 서비스가 있습니다. 이 서비스를 사용하면 들어오는 모든 메시지를 가로채서 메시지 내용에 따라 중앙 라우팅을 수행할 수 있습니다. 특히 이 기능은 정교한 서비스 버전 관리 솔루션을 개발하기 위한 매우 훌륭한 기반을 제공합니다.

"Dublin"에는 또한 Durable Timer Server 및 Instance Restart Service를 포함하여 서비스 인스턴스의 수명 주기를 관리하기 위한 몇 가지 핵심적인 서비스가 제공됩니다. "Dublin"은 또한 .NET Framework 4.0에서 제공하는 Instance Control Endpoint와 새로운 IIS/WAS 자동 시작 기능을 활용하여 첫 번째 메시지를 기다리지 않고 시스템이 시작하면 즉시 서비스를 시작할 수 있습니다. 앞으로 몇 달 후에 이러한 기능에 대한 기사가 선보일 것입니다.

"Dublin"은 "Oslo" 모델링 플랫폼을 활용하는 최초의 기술 중 하나가 될 것입니다. 리포지토리로부터 "Oslo" 응용 프로그램을 내보내고 손쉽게 "Dublin"으로 배포할 수 있으며 이렇게 하면 이 기사에서 소개한 다양한 호스팅 및 관리 기능을 사용할 수 있습니다. 이렇게 모델을 사용하여 응용 프로그램 배포를 기술 및 자동화하는 방식은 복잡한 IT 환경에 큰 도움이 될 것입니다.

"Dublin"과 "Oslo"가 성숙함에 따라 두 기술 간의 통합도 발전할 것입니다. Microsoft는 두 기술을 매우 상호 보완적으로 만들기 위한 계획을 시작했습니다.

BizTalk Server와의 관계

다른 일반적인 질문은 "Dublin"과 BizTalk Server와는 관계에 대한 것입니다. BizTalk Server는 현재 "Dublin"에서 볼 수 있는 여러 기능에 영감을 제공했다고 할 수 있습니다. 두 기술은 비슷한 관리 기능을 제공하지만 초점이라는 면에서 가장 큰 차이점이 있습니다. "Dublin"은 WCF와 WF 응용 프로그램을 위해 특별하게 디자인된 호스팅 및 관리 확장을 Windows Server에 추가하기 위한 기술이지만 BizTalk Server는 다양한 메시지 형식, 전송 및 매핑 기술을 사용하여 비-Microsoft 시스템과의 응용 프로그램 통합을 중점적으로 다룹니다.

BizTalk Server의 가장 중요한 초점은 과거에도 미래에도 항상 비-Microsoft 시스템(기간 업무 응용 프로그램, 레거시 시스템, RFID 장치 및 BTB 프로토콜)과의 통합일 것입니다. BizTalk Server는 앞으로도 몇 년간 이러한 핵심적인 장점에 주력할 것입니다. 일반적으로 이러한 유형의 EAI(엔터프라이즈 응용 프로그램 통합) 시나리오가 주요 초점인 경우에는 BizTalk Server를 계속 사용하는 것이 좋습니다.

그러나 여러 WCF와 WF응용 프로그램에는 이러한 유형의 통합 기능이 필요하지 않으므로 BizTalk Server는 과도한 투자로 느껴질 수 있습니다. 바로 이러한 경우에 비슷한 관리 기능을 제공하는 단순한 대안인 "Dublin"이 적합합니다. 무엇보다 "Dublin" 확장은 Windows Server의 핵심 기능으로 제공되며 불필요한 통합 어댑터를 구입하지 않아도 되므로 BizTalk Server에 비해 경제적입니다. BizTalk Server의 향후 버전에서는 Windows Server에 추가된 핵심 관리 기능 투자를 활용하기 위해 "Dublin" 확장을 기반으로 활용하게 될 가능성이 높습니다.

이 기사를 작성하는 데 도움을 주신 Eileen Rumwell, Mark Berman, Dino Chiesa, Mark Fussell, Ford McKinstry, Marjan Kalantar, Cliff Simpkins, Kent Brown, Kris Horrocks, 그리고 Kenny Wolf에게 감사 인사를 전합니다.

Aaron Skonnard는 강사 진행 및 온라인 교육 과정을 모두 제공하는 유명한 Microsoft .NET 교육 업체인 Pluralsight의 공동 창립자입니다. Aaron은 다양한 저서, 백서 및 기사를 저술했으며 Pluralsight의 REST, Windows Communication Foundation, 그리고 BizTalk Server에 교육 과정을 제작하기도 했습니다. 문의 사항이 있으면 pluralsight.com/aaron으로 연락하십시오.

추가 리소스