[アーティクル]
08/28/2015

January 2009

Volume 24 Number 01

概要 - .NET Framework 4.0 における WCF サービスと WF サービス、そして "Dublin"

Aaron Skonnard | January 2009

この記事は、.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 について

2008 年 10 月の Professional Developer's Conference (PDC) で、マイクロソフトは、Microsoft .NET Framework 4.0 に付属する多数の機能強化点 (具体的には Windows Communication Foundation (WCF) と Windows Workflow Foundation (WF) の分野) の詳細を発表しました。マイクロソフトは、Windows Server に対するいくつかの拡張機能 (コードネーム "Dublin") も発表しました。これらの拡張機能によって、WCF および WF アプリケーションのホスティングと管理のエクスペリエンスが向上します。

WF と WCF を .NET Framework 4.0 に統合したことで、分散サービス指向アプリケーションの開発が簡単になります。柔軟性とビジネスアジリティに優れた完全な宣言型モデルを使用して、ステートフルなワークフローサービスを構築できます。

"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 アクティビティの形式で、2 つの間にいくつかの魅力的な統合が導入されました。これらのアクティビティにより、WF を使用して複数のサービス対話を調整し、実行時間の長い複雑なワークフローを実行するプロセスを単純化できます。これらのアクティビティを使用して、WF ワークフローを WCF エンドポイントで有効にすることにより、その対象を拡大することもできます (図 1 を参照)。これにより、基本的に WF を WCF サービスの実装として採用できます。この記事全体を通して、これを WCF ワークフローサービスと呼ぶことにします。

WCF ワークフローサービス

図 1 WCF ワークフローサービス

WCF ワークフローサービスを .NET Framework 3.5 で実装することもできますが、簡単ではありません。まず、WCF と WF の間の統合層が不十分です。.NET Framework 3.5 では、WCF アーティファクトは WCF プログラミングおよび構成モデルを使用して定義および構成する必要がありますが、ワークフローは別のモデルを使用して定義されます。最終的に、複数のアーティファクトを別々に展開、構成、および管理する必要があります。

難しさのもう 1 つの理由は、現在の基本アクティビティライブラリがフロー制御とロジックのアクティビティに集中しており、作業アクティビティについては多くを提供していないことです。このため、現実のワークフローサービスを WF で実装する前に、カスタムアクティビティのライブラリを作成する必要があります。そのジョブは複雑であるため、一部の開発者は、WF の利点を体験する前に諦めてしまいました。

これらの問題に加えて、現在の WF には、eXtensible Application Markup Language (XAML) のみのワークフローに対するツールサポートも不足しています。XAML のみのワークフローは、分離コードファイルがなく完全に XML ファイルで記述されているため、宣言型ワークフローとも呼ばれます。XAML のみのアプローチでは、優れたワークフローホスティングおよび展開を実現できる可能性があります。宣言型ワークフローが優れている点は、これがどこにでも格納できる単なるデータであり、使用されるアクティビティについて認識している WF ランタイム環境内で実行できることです。

宣言型ワークフローは、クラウド内のランタイムまたはデスクのワークステーションに展開できます (アクティビティがランタイムホストに展開されていることを想定します)。宣言型ワークフローは、バージョン管理も簡単であり、部分的な信頼のシナリオでも使用できます ("クラウド" を考えてください)。XAML のみのモデルも、ツールは XML ファイルを処理するだけなので、ツールの構築が簡単です。

一般に、XAML のみのモデルは、常にテクノロジとしての WF の最終ビジョンでした。これは、設計者が記した初期の文書から明らかです。しかし、現在の WF ツールサポートは、このビジョンを完全には実現していません。XAML のみのワークフローを .NET Framework 3.5 で構築することは可能ですが、現在の Visual Studio テンプレートを回避し、デバッグなどの重要な機能を諦める必要があります。

.NET Framework 4.0 の WCF と WF の主な目標は、XAML のみのモデルを完全に取り込んで、宣言型ワークフローとサービスに関する開発者の作業を簡略化することです。また、マイクロソフトは、宣言型ワークフローサービスを定義できるようにすることで、さらに一歩前進することを望んでいました。つまり、サービスコントラクト定義、エンドポイント構成、実際のサービス実装 (XAML ベースワークフローの形式) など、XAML について完全に定義されている WCF サービスです。

これを実現するために、マイクロソフトは .NET Framework 4.0 に多数の機能強化を追加しました。これには、拡張基本クラスアクティビティライブラリ、より単純なカスタムアクティビティ用プログラミングモデル、新しいフローチャートワークフロータイプ、および多数の WCF 固有機能拡張があります。

WF 基本アクティビティライブラリ

.NET Framework 4.0 には、いくつかの新しいアクティビティを含む拡張された基本アクティビティライブラリが付属しています (図 2 を参照)。マイクロソフトでは、.NET Framework メジャーリリース間に CodePlex を通じて追加の WF アクティビティを使用可能にすることも計画しています。将来のリリース (または CodePlex) では作業アクティビティ (PowerShellCommand アクティビティなど) が追加されるため、カスタムアクティビティの開発の必要性が軽減されます。また、マイクロソフトは CodePlex を使用しているため、どのような追加アクティビティが必要かについてユーザーが意見を述べる機会もあります。

.NET Framework 4.0 では、FlowChart、ForEach、DoWhile、Break アクティビティなど、より多くのフロー制御オプションを提供するいくつかのコアアクティビティが導入されています。新しい FlowChart アクティビティは、Sequential フロー制御モデルと StateMachine フロー制御モデル間に優れた中間点を提供するため、最も関心を引く追加機能の 1 つです。FlowChart では、単純な決定とスイッチで拡張されたステップバイステップアプローチを使用できますが、ワークフロー内の前のアクティビティに戻ることもできます。フローチャートは、一般に、多くのユーザーにとってわかりやすいようです。図 3 に、FlowChart デザイナが Visual Studio 2010 の新しいワークフローデザイナでどのように表示されるかを示します (詳細については、「新しいワークフローデザイナ」を参照してください)。

新しい FlowChart アクティビティデザイナ

図 3 新しい FlowChart アクティビティデザイナ

.NET Framework 4.0 では、CLR メソッドの呼び出し (MethodInvoke)、ワークフロー変数への値の割り当て (Assign)、および実行中のワークフローインスタンスの明示的な永続化 (Persist) のための新しいランタイムアクティビティもいくつか導入されています。

最後に、.NET Framework 4.0 には、ワークフローをサービスとして公開するプロセス、またはワークフローからサービスを使用するプロセスを簡略化する WCF ベースのアクティビティの新しいセットが付属しています。.NET Framework 3.5 では、WCF を通じてメッセージを送受信するための Send および Receive という 2 つのアクティビティが提供されていました。バージョン 4.0 では、一方向メッセージを送受信するための SendMessage および ReceiveMessage アクティビティ (バージョン 3.5 の Send および Receive と同様) と、ClientOperation および ServiceOperation アクティビティを通じた要求/応答操作の上位レベルの抽象化があります。サービス操作を公開するワークフローでは、ServiceOperation アクティビティを使用する必要があります。一方、外部サービスを使用するワークフローでは、ClientOperation アクティビティを使用する必要があります。

これらのコア WCF アクティビティに加えて、.NET Framework 4.0 では、特定のメッセージが正しいワークフローインスタンスに返されることを保証するために、さまざまな一方向操作の相関もサポートされます。これには、WCF を通じて発信メッセージを送信する前に新規相関スコープの定義 (CorrelationScope) および相関値の初期化 (InitializeCorrelation) を行うためのアクティビティが付属します。

新しいワークフローデザイナ

Visual Studio 2010 に追加された新しいワークフローデザイナは、この記事で説明している主要な WCF および WF 機能の多くについて、魅力的なグラフィカルユーザーエクスペリエンスを提供します。スコープに戻るための階層リンクがある改良されたワークフローナビゲーション (複合アクティビティへのドリル)、インプレースアクティビティ編集 ([プロパティ] ウィンドウの必要性を軽減)、ズーム機能、概要ナビゲーションなどの機能があります。また、新しいデザイナは、カスタマイズと再ホスティングについて強化されたモデルを提供します。Visual Studio 2010 では、フローチャートと XAML のみのワークフローをすぐに簡単に使い始めることができる新規または改善されたプロジェクトテンプレートのスイートも提供され、宣言型ワークフローとサービスを処理するときの XAML ベースのデバッグが完全にサポートされます。

WF アクティビティプログラミングモデル

これらの機能強化があっても、カスタムアクティビティの作成が必要な場合があります。これを簡単にするために、マイクロソフトはカスタムアクティビティの基本クラスを再デザインしました。カスタムアクティビティの新しい基本クラスは WorkflowElement と呼ばれ、そこから派生する別のクラス Activity があります。Activity クラスを使用すると、大量のコードを作成しなくても、既存のアクティビティから新しいカスタムアクティビティを簡単に作成できます。

たとえば、図 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 から派生させる場合は現在の動作方法と似ています。ただし、マイクロソフトは、これらのカスタムアクティビティの作成に関連するものをさらに簡略化しました。

カスタムアクティビティの作成を難しくしているものの 1 つは、アクティビティとの間のデータフローの管理です。たとえば、現在は、アクティビティとの間で受け渡される型指定された引数のセットを定義できません。通常、開発者は、ワークフローキューから引数をシリアル化および逆シリアル化するカスタムクラスを作成します (詳細については、Michael Kennedy の「長時間実行処理をサポートする Web アプリケーション」という記事を参照してください)。このプラミングコードの作成は難しくありませんが、アプリケーションフローのモデル化の中心的な目標から離れた余分な作業になります。.NET Framework 4.0 は、大幅な簡略化を約束する新しい 3 つのデータフロー概念でアクティビティプログラミングモデルを拡張します。それらの概念とは、引数、変数、および式です。

引数を使用して、アクティビティとの間のデータフローを定義します。各引数には、入力、出力、入出力など、指定されたバインド方向があります。次の例は、"AuditMessage" という 1 つの入力引数がある単純な 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>

式は、1 つ以上の入力引数を受け取る構成要素であり、これらの入力引数に対して操作または動作を実行してから値を返します。式は、ValueExpression からクラスを派生させることで定義されます。ValueExpression は WorkflowElement から派生するため、アクティビティを使用できる場所であればどこででも式を使用できます。式は、別のアクティビティの引数へのバインドとしても使用できます。次の例では、単純な 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>

注目すべきもう 1 つの点は、ルートアクティビティに関して特別なことは何もないことです。WorkflowElement から派生したものは、ワークフロー内のルートまたは他の場所で使用できます。これにより、さまざまなワークフロースタイルを別のワークフロースタイル内に任意に作成できます (たとえば、シーケンス内のフローチャート内の状態マシンなど)。

これらのプログラミングモデル変更の大部分は、宣言型ワークフローを優良市民にするのに役立ちます。データフロープロパティを定義するために必須であった分離コードファイルが必要でなくなるからです。これはすべて XAML で宣言によって行えるようになりました。ただし、これらはかなり根本的な変更であるため、WF ランタイムへの大幅な変更が必要であり、最終的に .NET Framework 3.x アクティビティとの互換性が断たれます (詳細については、ワークフローの移行の説明を参照してください)。それにもかかわらず、マイクロソフトは、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 4.0 ホスト内でカスタム .NET 3.x アクティビティを簡単にラップできるようにする特別な 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 ベースのメッセージング用に 1 つのコントラクト投影を使用し、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>

この初期ステージの 1 つの欠点は、宣言によるサービスの構築に役立つビジュアルデザイナがないことです。Community Technology Previews (CTP) が展開されるときに、XAML 定義を処理するための開発者にとってなじみのあるデザイナ環境がマイクロソフトによって提供されることを期待しています。

前に述べた宣言型サービスのサポートと WCF ベースのアクティビティに加えて、.NET Framework 4.0 にはその他の下位レベル WCF 実装もいくつか付属しています。その機能の一部によって、新しい "Dublin" 拡張機能でワークフローサービスを管理できるようになります。これらの機能には、改良された構成、メッセージ相関、永続性のある二重通信、永続タイマ、および Event Tracing for Windows (ETW) トレースの統合が含まれます。マネージ環境にサービスをホストするときに価値を追加するその他の機能として、標準制御エンドポイントと自動開始があります。これらの機能については、数か月後に耳にすることになるでしょう。

"Dublin" の必要性

実世界では、WCF および WF の処理に関するもう 1 つの課題は、サーバー環境でサービスとワークフローをホストする場所の決定です。WCF の場合、通常答えはかなり簡単です。最も一般的な選択肢は、Windows Server 2008 の IIS および Windows Process Activation Service (WAS) です。

現在、IIS と WAS の組み合わせによって、着信メッセージに応じたプロセスのアクティブ化、プロセス監視と状態管理、プロセスリサイクル、CLR AppDomain 統合、組み込みセキュリティ、IIS Manager および Windows PowerShell コマンドレットを通じて使用可能になった基本管理機能などのいくつかの主要機能が提供されます。これらの機能の組み合わせによって、通常は IIS/WAS がサーバー環境での WCF サービスのホストの適切な選択肢になります。一般の人はこのような種類の機能の構築を望まないからです。

IIS/WAS は WCF アプリケーションをホストする基盤を提供しますが、これにはいくつかの重要な領域が不足しています。最大の欠点は、サービス管理性の領域にあります。IIS/WAS は、実行中のサービスインスタンスのサービストレース、監視、診断などの WCF 固有のサービス管理機能を実際には提供しません。たとえば、現在、管理者は IIS で構成されたすべての WCF サービスの一覧を表示できません。ホストされているすべてのサービスのステータスをクエリできません。IIS/WAS は、スケールアウト展開または一般的な WCF 構成タスクを簡略化するための組み込みサポートを提供しないため、これが WCF の弱点になります。

サーバーファーム間で実行時間の長いワークフローをサポートするにはステートフルモデルが必要であるため、サーバー環境の WF アプリケーションではホスティングの問題がさらに悪化します。これらの複雑さを理由に、マイクロソフトは .NET Framework 3.0 で WF サーバーホストを出荷しませんでした。開発者は、これを自身で作成する必要がありました。WorkflowServiceHost クラスが導入された .NET Framework 3.5 で初めて、WF ワークフローをすぐに使える WCF サービスとしてホストできるようになったため、WF ワークフローを IIS/WAS にホストできるようにもなりました。

WorkflowServiceHost は好調なスタートを切りましたが、Web サーバーファーム全体でステートフルワークフローを管理するためのツールサポートはなく、実行中のワークフローインスタンスを実行時に監視および管理するためのツールも用意されていませんでした。

サービスおよびワークフロー管理機能については、ほとんどの開発者は、BizTalk Server で提供されているものと同様で一層単純なエクスペリエンスを期待しています。多くの組織は BizTalk 管理のエクスペリエンスを望んでいますが、BizTalk Server MessageBox に由来する統合機能や信頼性セマンティクス (および対応するパフォーマンスへの影響) は必要としていません。WCF および WF アプリケーション用にデザインされた、より軽量なモデルの方が適しています。

"Dublin" のガイド

マイクロソフトは、Windows Server に対する新しい拡張機能のセット (コードネーム "Dublin") に取り組んできました。この拡張機能セットでは、WCF および WF アプリケーションのための貴重なホスティングおよび管理機能が提供されます。"Dublin" は基本的に、Windows Server に付属の IIS/WAS の上に構築されるサービス管理拡張機能のセットです。"Dublin" 拡張機能を使用する場合も、サービスとワークフローは IIS/WAS にホストされますが、アプリケーションでは現在 IIS/WAS に存在しない WCF および WF 固有の追加の管理機能およびツールを使用できます。

さまざまな "Dublin" 拡張機能は、Windows Server Application Server の役割の一部として、将来の Windows Server バージョンで出荷されます。このため、機能のセットは Windows Application Server と呼ばれることがありますが、マイクロソフトで認定されている正式名称ではありません。この記事の残りの部分では、新しい Windows Server Application Server 拡張機能を単純に "Dublin" と呼びます。

"Dublin" 拡張機能で提供される主要機能には、信頼性と永続性のあるサービスおよび実行時間の長いワークフローの管理サポートが含まれます。"Dublin" によって、ファーム全体の個々のサーバーにアプリケーションを展開できるようになり、特定のサービス管理タスクに必要なツールが提供されます。以降のセクションでは、これらの機能について詳細に説明しますが、まず、図 6 に示す全体的なアーキテクチャを見てみましょう。

"Dublin" アーキテクチャ

図 6 "Dublin" アーキテクチャ

ご覧のように、"Dublin" は、サービスの永続性および監視の基盤となるいくつかのランタイムデータベースを提供します。これらのデータベースの上に、.NET Framework によって提供されるランタイムコンポーネントとサービスの層が構築されます。"Dublin" は、これらのランタイムをさらに拡張して、ホスティング、永続化、監視、およびメッセージング機能を統合します。この層が基礎となるランタイムデータベースと連携して、"Dublin" と呼ばれるものを構成します。

アーキテクチャの上部の 2 層は、"Dublin" を人間が使用できるようにするためのものです。Windows PowerShell コマンドレットを介してさまざまな機能のスクリプト化を可能にする管理 API 層があります。その上には、IIS Manager エクスペリエンスがあります。これは、実際には Windows PowerShell コマンドレットの上に構築されるため、現在の IIS 管理者にとってなじみのあるものです。したがって、IIS Manager で行えることはすべて Windows PowerShell でも行うことができます。

マイクロソフトは、このセクションで説明したホスティングおよび管理タスクを実行するために、多数の UI 拡張機能を IIS Manager に追加しました。アプリケーションの展開と構成、アプリケーションの管理、およびアプリケーションの監視用の拡張機能があります。これらの拡張機能は、実行中の、中断しているワークフローインスタンス、永続化されたワークフローインスタンスなどを示すシステムのランタイムダッシュボードも提供します。

"Dublin" 用の WCF ワークフローサービスを構築する

Visual Studio 2010 によって、新しいプロジェクトテンプレートを通じて "Dublin" 拡張機能をターゲットとするサービスの構築が実に簡単になります (図 7 を参照)。このプロジェクトテンプレートによって、"Dublin" で提供されている永続化プロバイダおよび永続化タイマサービスで事前構成された web.config が提供されます。

新しい "Dublin" サービスライブラリを作成する

図 7 新しい "Dublin" サービスライブラリを作成する

プロジェクトを生成した後で、この記事で前に説明したさまざまな手法を使用して、WCF ワークフローサービスの実装に集中できます。新しいワークフローデザイナエクスペリエンスによって、グラフィカルワークフロー開発アプローチを使用してサービス全体を実装できるようになります。完全なワークフローサービスの構築を完了すると、"Dublin" 拡張機能が有効になっている Windows Server にサービスを展開する準備ができます。

通常、サービスを IIS/WAS に展開するには、Web アプリケーションに使用する手法をどれでも使用できます (環境で許可されている場合は、Visual Studio から直接展開できます)。Windows PowerShell コマンドレットを使用して、これらのタスクを自動化することもできます (これらのコマンドレットによって、WCF および WF 環境用の自動化展開スクリプトを作成できます。これらのコマンドレットを使用する場合は、単純に Windows Application Server で Windows PowerShell を開き、"help <command>" と入力して特定のコマンドの使用方法を調べます)。展開後に、IIS Manager を使用して、図 8 で強調されているさまざまな "Dublin" 拡張機能へのアクセスを開始できます。

IIS Manager の "Dublin" 拡張機能

図 8 IIS Manager の "Dublin" 拡張機能

"Dublin" でアプリケーションを展開する

多くの環境では、セキュリティと分離の理由から、開発者がサービスをマネージサーバーに直接展開することはできません。"Dublin" には、アプリケーションのエクスポート/インポート機能を通じてサービスを展開するための代替ソリューションが用意されています。

他のサービスに展開する WCF および WF アプリケーションをパッケージ化するには、IIS Manager で [Application Export] (アプリケーションエクスポート) を選択します。すると、エクスポートするアプリケーションの選択を求めるダイアログが表示されます。場所を指定した後で [Export] (エクスポート) をクリックすると、.zip 拡張子付きのファイルパッケージが生成されます。このパッケージには、すべての WCF および WF コードと、1 つのアプリケーションのすべてのメタデータおよび構成設定が含まれます。"Dublin" 拡張機能を通じて、このパッケージを別のサーバーに移動およびインポートできます。これによって、サーバーを管理する IT プロフェッショナルに .zip ファイルを単純に送信して処理を依頼できるようになりました。

Windows PowerShell Export-Application コマンドレットでも、同じ処理が行われます。アプリケーションエクスポート機能は、システムテスト環境と検証環境でも非常に役立ちます。

WCF および WF アプリケーションをインポートするには、アプリケーションインポート機能を選択するか、または Import-Application コマンドレットを使用します (Get-PackageManifest コマンドレットを使用してパッケージの内容を表示することもできます)。すると、インポート機能によって、インポートするパッケージ (.zip ファイル) の選択を求められます。

プロセス中に、アプリケーション名、アプリケーションプール、およびアプリケーションの物理パスを必要に応じて指定できます。また、"Dublin" は集中永続化構成を提供するため、ワークフローサービスを別のサーバーに展開するときに、アプリケーションレベルでの永続化構成の変更を気にする必要はありません。単純に、新しいサーバーに関連付けられた新しい永続化データベースが使用されます。これらの機能によって、サーバー環境での WCF および WF アプリケーションの展開プロセスは、これらのタスクを担当するシステム管理者にとって非常に取り組みやすいものになります。

アプリケーションを正常に展開した後で、"Dublin" によって提供されている他の拡張機能を通じてサービスの構成を開始できます。たとえば、特定の状況では、システム管理者はデータベースの永続化と追跡のためにランタイム構成を手動で再構成する必要がある場合があります。"Dublin" 拡張機能を使用すると、これはかなり簡単です。既定のビューから [サービス] を選択するだけで、すべてのマネージサービスの一覧が表示され、右側のウィンドウにはさまざまなサービス構成オプションが表示されます (図 9 を参照)。これらのオプションによって、永続化設定、追跡設定、およびセキュリティと調整に関連するその他の WCF 設定を簡単に変更できます。WCF 構成ファイルを操作する必要はありません。

"Dublin" 拡張機能でサービスを表示および構成する

図 9 "Dublin" 拡張機能でサービスを表示および構成する

これらのタスクを実行するために、Get-ServicePersistence、Set-ServicePersistence、Enable-ServiceTracking、Get-TrackingParticipant などの複数の Windows PowerShell コマンドレットが用意されています。このため、アプリケーションサーバー環境の設定と構成の自動化がはるかに簡単になります。

実行中のアプリケーションを管理する

アプリケーションのライフサイクル中に、開発者とシステム管理者は、問題のあるワークフローインスタンスを特定して表示し、必要に応じてそのインスタンスを終了するために、アプリケーションの状態を監視する機能を必要とします。"Dublin" には、これらの一般的な管理ニーズに対応する多数の拡張機能が用意されています。

IIS Manager で [Persisted Instances] (永続化インスタンス) オプションを選択した場合 (図 8 を参照)、永続化され、中断している可能性のある実行中のワークフローインスタンスの概要を示すダッシュボードビューが表示されます (図 10 を参照)。[Overview] (概要) ボックスには、サーバー、サイト、またはアプリケーションに展開されたアプリケーションとサービスの総数が (選択したスコープに応じて) 表示されます。

永続化ワークフローインスタンスを表示する

図 10 永続化ワークフローインスタンスを表示する

[Persisted Instances] (永続化インスタンス) ボックスには、実行中および永続化されたワークフローインスタンスの概要が表示され、ブロックまたは中断 (エラーで終了したことを意味します) されている可能性のあるワークフローインスタンスが示されています。中断されたインスタンスは、通常は人間が直接処理する必要のあるインスタンスであるため、仮想パス、サービス名、または例外の種類に基づいて個別の中断インスタンスを簡単に特定できるようにするボックスが他にいくつか用意されています。

いずれかのリンク (青で示されています) をクリックして、永続化インスタンスの一覧を表示し、それらの詳細を表示できます。この時点で、右側のウィンドウに表示されているアクションから選択することで、サービスインスタンスを手動で中断、終了、または中止できます (図 11 を参照)。サービスインスタンスを中断すると、インスタンスの実行が停止し、新しいメッセージを受信できなくなります。中断されたインスタンスは後で再開でき、その時点でメッセージの受信が再開します。サービスインスタンスを終了すると、インスタンスの実行が停止し、永続化ストアから削除され、再開はできなくなります。最後に、サービスインスタンスを中止すると、特定のインスタンスに関連するメモリ内の状態がクリアされ、最後の永続化ポイント (永続化ストアに格納されています) に戻ります。

個々の永続化インスタンスを表示する

図 11 個々の永続化インスタンスを表示する

Windows PowerShell Get-ServiceInstance および Stop-ServiceInstance コマンドレットは、コマンドラインから実行されるのと同等の機能を提供します。特定のサービスインスタンスを識別するための多数のコマンドラインオプションがあります。

実行中のアプリケーションを更新する

実際のシステムの作業で特に問題になる点の 1 つは、定期的な更新が必要であることです。非常に複雑な分散アプリケーションでは、必要な変更を行うためにデータベース、ビジネスロジック、およびサービスコードを同時に更新しなければならない場合、これを正しく行うのが厄介なことがあります。通常、アプリケーションの実行中に重大な更新を自動的に適用することはできません。

この問題に対処する 1 つの方法は、更新の実行中にアプリケーションをオフラインにすることです。ただし、これについて現実的に考えた場合、Web サイトへの更新を同時に実行しているときに、IIS/WAS アプリケーションをオフラインにする簡単な方法はありません。これも、"Dublin" 拡張機能が単純なオフライン機能を通じて価値を追加する領域です。

IIS Manager でアプリケーションを選択してから、図 8 に示した右側のウィンドウで [Disable Protocols] (プロトコルの無効化) コマンドを選択できます (将来のリリースでは名前が変更される可能性があることに注意してください)。これによって、アプリケーションのサービスのすべてのインスタンスがブロックされた状態で終了するか、実行が自然に終了し、その間、処理する必要のある新しい着信要求は処理されません。

この時点で、基本的にこのアプリケーションのメッセージフローは停止しています。つまり、クライアントはエラーを受信せずにサービスにメッセージを送信できなくなります (BizTalk Server の場合のようにキューに登録されることはありません)。これが背後で動作する方法はかなり単純です。"Dublin" 拡張機能は、この特定のアプリケーションのプロトコルハンドラをすべて単純に削除し、更新の終了後に簡単に復元できるように保存します。

アプリケーションがオフラインになったら、必要な更新を実行できます。更新が終了し、アプリケーションを再びオンラインにする準備ができたら、[Restore Protocols] (プロトコルの復元) コマンドを選択できます。Windows PowerShell Disable-ApplicationMessageFlow および Enable-ApplicationMessageFlow コマンドレットを使用して、コマンドラインからこれらのタスクを実行することもできます。

実行中のアプリケーションを監視する

ビジネスでは、ビジネスがどのように機能し、どのような変更が必要であるかを調べるために、実行中のアプリケーションを監視する機能も必要です。WCF および WF ランタイムには、"Dublin" 拡張機能の基礎となる組み込み追跡インフラストラクチャが既に付属しており、WCF および WF アプリケーション内での監視を簡単に行うことができます。

基本的な追跡を構成する

図 12 基本的な追跡を構成する

.NET Framework 4.0 追跡アーキテクチャには、2 つの主要機能があります。それは、追跡プロファイルと追跡参加者です。開発者は、追跡するイベントをランタイムに指示する追跡プロファイルを定義し、追跡参加者はこれらのイベントをサブスクライブできます。

"Dublin" には、役に立つイベントの共通セットの追跡を簡単にする組み込み追跡プロファイルがいくつか付属しています。IIS Manager で特定のサービスに移動し、右側のウィンドウで [Tracking] (追跡) を選択することで、アプリケーションの追跡を簡単に行うことができます。

続いて、図 12 に示すダイアログが表示されます。このダイアログで、ワークフローとサービスの基本的な追跡機能を構成できます。これを構成した後で、構成に対して適切な更新が行われ、WCF/WF 追跡インフラストラクチャが起動します。

必要に応じて、"Dublin" 拡張機能を通じて追跡データを表示することもできます。永続化サービスインスタンスを調べているときに [View Tracking Data] (追跡データの表示) を選択できます (図 11 を参照)。これにより、監視ストアに対して SQL クエリが実行され、表示できる追跡イベントの一覧が生成されます (図 13 を参照)。カスタムイベントを追跡するときに、カスタム追跡プロファイルを定義し、IIS Manager メインビューの [Tracking Profiles] (追跡プロファイル) オプションを通じてこれらのプロファイルを構成できます。

追跡データを表示する

図 13 追跡データを表示する

この記事では "Dublin" のすべての機能を説明するスペースはありませんが、詳しく説明する価値がある魅力的な機能が他にもあります (詳細については、「"Dublin" のその他の機能」を参照してください)。"Dublin" の役割と、提供される主要機能の一部について読者が明確に理解できたならさいわいです。

"Dublin" から "Oslo" へ?

"Oslo" というコードネームのプラットフォームについて耳にしたことがある場合は、現時点で "Dublin" がそのイニシアティブとどのように関連しているかを疑問に思うことでしょう。まず、"Oslo" は分散アプリケーションをデザイン、構築、および管理する方法を簡略化するためにマイクロソフトが開発している新しいモデリングプラットフォームです。モデリングプラットフォームは、"Oslo" モデリング言語 ("M" とも呼ばれます)、"Oslo" リポジトリ、および "Oslo" モデリングツール ("Quadrant" とも呼ばれます) の 3 つの主要コンポーネントから構成されます。"Oslo" は、実際には、モデル駆動型のアプローチを通じてユーザーエクスペリエンスを単純化するために他のアプリケーションとテクノロジを構築できるプラットフォームです。

"Dublin" のその他の機能

"Dublin" には、この記事で詳細には説明できなかった機能が他にもいくつかあります。ただし、触れておく価値のある機能の 1 つに、集中永続化データベースを通じてファーム全体で永続化サービスインスタンスを管理するためのソリューションなど、既存の負荷分散ソリューションと統合されるサーバーファーム間でのスケールアウト展開のサポートがあります。組み込みのエラー処理ロジックによって、永続化インスタンスは、ファーム内の任意のノードで実行でき、複数のノードで同じインスタンスが競合する場合の競合条件を回避できます。

もう 1 つの重要なコンポーネントは、転送サービスです。このサービスによって、メッセージコンテンツに基づいて集中ルーティングを実行するために、すべての着信メッセージをインターセプトできるようになります。特に、この機能は、高度なサービスバージョン管理ソリューションを構築するための優れた基盤を提供します。

"Dublin" には、Durable Timer Server や Instance Restart Service など、サービスインスタンスのライフサイクルを管理するための主要サービスもいくつか付属しています。"Dublin" では、.NET Framework 4.0 と新しい IIS/WAS 自動開始機能によって提供されるインスタンス制御エンドポイントの利用方法も認識されます。これにより、最初のメッセージを待機するのではなく、マシンの起動時にサービスを開始できます。これらの機能の詳細な記事は、この先数か月の間に発行される予定です。

"Dublin" は、"Oslo" モデリングプラットフォームを利用する最初のテクノロジの 1 つになります。"Oslo" アプリケーションをリポジトリからエクスポートし、"Dublin" に簡単に展開できます。そこで、"Oslo" アプリケーションはこの記事で説明したさまざまなホスティングおよび管理機能を利用できます。モデルを使用してアプリケーションの展開を記述および自動化することは、複雑な IT 環境にとっての利点のように思えます。

"Dublin" と "Oslo" はどちらも成長を続けているため、2 つのテクノロジの統合は引き続き拡大すると思われます。マイクロソフトは、2 つのテクノロジが相互に補完することを意図していると述べています。

BizTalk Server について

よくある別の質問は、"Dublin" が BizTalk Server とどのように関連しているかということです。多くの点で、現在の "Dublin" に見られる機能の多くは BizTalk Server から着想を得ています。どちらのテクノロジも同じような管理機能を提供しますが、フォーカスに関しては大きな違いがあります。"Dublin" は、WCF および WF アプリケーション用にデザインされたホスティングと管理の拡張機能を Windows Server に追加しますが、BizTalk Server は、さまざまなメッセージ形式、転送、およびマッピング手法を使用した、マイクロソフト以外のシステムとアプリケーションの統合に焦点を当てています。

BizTalk Server の主な目的は、過去も今後もマイクロソフト以外のシステム (基幹業務アプリケーション、レガシシステム、RFID デバイス、およびビジネス間プロトコル) との統合です。BizTalk Server は、今後数年間はこれらの中核的な機能に焦点を当て続けます。一般には、主にこのような種類のエンタープライズアプリケーション統合 (EAI) シナリオに焦点を当てる場合は、BizTalk Server を引き続き使用します。

ただし、多くの WCF および WF アプリケーションはこのような種類の統合機能を必要としないため、BizTalk Server では機能が過剰だと感じる場合があります。これはまさに、"Dublin" に適合する状況です。"Dublin" は、類似する管理機能を提供する、より単純な代替物であるからです。"Dublin" 拡張機能は Windows Server のコア部分として出荷され、不要な統合アダプタを購入する必要はないため、結果的に、このようなシナリオでは "Dublin" の方が 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 です。

次の方法で共有

概要 - .NET Framework 4.0 における WCF サービスと WF サービス、そして "Dublin"

その他のリソース