BizTalk Server 2006 または WF? プロジェクトに最適なワークフロー ツールの選択

  • [アーティクル]

ケント ブラウン

twentysix New York (www.26ny.com)

2007 年 11 月

2008 年 2 月改訂

適用対象:

   Microsoft BizTalk Server 2006

   Windows Workflow Foundation

概要：この記事では、さまざまなアプリケーションおよびエンタープライズ統合ワークフロー シナリオで Microsoft BizTalk Server 2006 と Windows Workflow Foundation を選択するためのガイダンスを提供します。 (16ページ印刷)

内容

はじめに

適切なワークフロー ツールを選択するためのプロセス

一般的なワークフロー シナリオ

ホスト内のすべて

Workflow-Technologyの推奨事項

Future-Proofing

まとめ

補遺

謝辞

詳細情報

はじめに

ワークフローは日常的なビジネス プロセスに浸透しているため、ワークフロー ソリューションの構築を直接サポートするプログラミング ツールを見つけることが一般的なニーズです。 Microsoft BizTalk Server 2006 と Windows Workflow Foundation (WF) は、ワークフロー ソリューションをプログラミングするための Microsoft の 2 つの主要なツールです。 ただし、それらの間に明らかな重複があるため、多くのアーキテクトと開発者は、目的に適したワークフロー テクノロジを決定するのが困難です。

これは、WF が今後推奨されるワークフロー テクノロジとして明確に識別されているのに対し、BizTalk Server 2006 はまだエンタープライズ統合のプレミアム サーバー製品であるという事実を考えると特に当てはまります。 BizTalk Serverオーケストレーションが WF を完全にサポートするまで、アーキテクトと開発者は投資するテクノロジを慎重に選択する必要があります。

ワークフローを実装するための適切なテクノロジを選択する際の課題の 1 つは、ワークフローが多くのことを意味する可能性があるということです。その中で、次のようになります。

  • ユーザーが操作してタスクを完了する UI 画面のフロー。
  • アプリケーションまたはサービス内のビジネス ロジックのフロー。
  • ビジネス プロセスを完了するための複数の人間の相互作用。
  • 業務トランザクションを処理するためのシステム間の複数のメッセージ交換の調整。
  • データベースへの (ETL) データの抽出、変換、読み込みのための手順の調整。

ワークフロー シナリオの範囲は多岐にわたり、ヒューマン ワークフロー、アプリケーション ワークフロー、エンタープライズ統合ワークフロー、Data Integration ワークフローの 4 つのカテゴリにグループ化すると役立ちます。

4 つの主要なワークフロー カテゴリのうち、アプリケーション ワークフローとエンタープライズ統合ワークフローは、テクノロジの選択が最も困難な 2 つの領域です。 ヒューマン ワークフローとData Integration ワークフローのシナリオは、ツール選択の観点から見ると非常に簡単です。 ヒューマン ワークフローにはユーザー インターフェイスが必要であり、多くの場合、ドキュメント中心であるため、Microsoft Office SharePoint Server 2007 はヒューマン ワークフロー ソリューションを構築するための推奨プラットフォームです。 Microsoft SQL Server Integration Services (SSIS) は、Data Integrationシナリオに推奨されるツールです。

この記事では、アプリケーション ワークフローとエンタープライズ統合ワークフローのシナリオで、BizTalk Server 2006 と WF のどちらかを選択するためのガイダンスを提供します。

BizTalk Server オーケストレーション エンジン

BizTalk Server オーケストレーション エンジンは、常にBizTalk Serverの魅力的な機能の 1 つです。 導入された時点では、ワークフロー中心のプログラミングを実行するために Microsoft から入手できる最適なツールでした。 BizTalk Server オーケストレーションは、複雑なマルチステップ メッセージ フローを制御して特定のビジネス トランザクションを完了するためのコンポーネントを開発するためのビジュアル プログラミング環境を提供します。

BizTalk Server オーケストレーション コード成果物は、ビジネス アナリストがビジネス プロセスを文書化するために生成する可能性があるフローチャートまたは統合モデリング言語 (UML) アクティビティ図によく似ています。 これらの成果物は、オーケストレーション エンジン ランタイムでコンパイルおよび実行できます。このランタイムは、実行時間の長いトランザクションや補正、持続性、フォールト トレランス、ディザスター リカバリーなどのサービスを提供します。これは、ミッション クリティカルなビジネス トランザクションを自動化するシステムを構築するために重要です。

未来のためのワークフロー基盤

ワークフロー シナリオには異なるカテゴリがありますが、プログラミングの観点から見ると、ワークフロー開発の共通フレームワークを確立するのに十分な共通点があります。 BizTalk Serverのオーケストレーション エンジンは強力ですが、BizTalk Serverの外部で使用するように設計されたことはありません。そのため、他のワークフロー カテゴリBizTalk Serverオーケストレーションを効果的に再利用することはできません。

Microsoft .NET Framework 3.0 でリリースされた WF では、今後 Windows プラットフォーム上のすべてのワークフロー関連のシナリオで使用できる一般的で拡張可能な.NET Frameworkに、ワークフロー中心のビジュアル プログラミング モデルが導入されています。 WF を作成したチームは、BizTalk Server オーケストレーション エンジンの最適な概念を取り入れ、ワークフロー シナリオのより広範な領域の要件を考慮し、それらをすべてサポートできる柔軟性のあるフレームワークを設計することができました。

WF の柔軟性の証拠として、Microsoft Office SharePoint Server 2007 ではこれを使用してヒューマン ワークフロー ソリューションを実装しています。 サード パーティの BPM ベンダーも、独自のワークフロー エンジンを構築するのではなく、WF の上にソリューションを構築することを目的としています。既に複数のベンダーがそうしています。 個々の開発者は WF を使用して、.NET Framework アプリケーションにカスタム アプリケーション ワークフローを実装することもできます。 また、この計画は、エンタープライズ統合ワークフロー ソリューションを実装するためのオーケストレーション エンジンを WF に実装するためのBizTalk Serverの将来のバージョン向けです。

図 1. 適切なワークフロー ツールの使用: BizTalk Server 2006 と WF

適切なワークフロー ツールを選択するためのプロセス

プロジェクトに適したワークフロー ツールを決定するのに役立つガイダンスを提供する方法は、最も一般的なワークフロー シナリオを示して、プロジェクトに最適なシナリオまたはシナリオの組み合わせを決定できるようにします。 次に、どのツール (BizTalk Server 2006 または WF) が最適であるか、およびその理由について、各シナリオに固有のガイダンスを提供します。 さらに、アプリケーション プラットフォーム インフラストラクチャ最適化 (APIO) モデル (organizationのアプリケーション プラットフォームと開発機能の成熟度を評価するためのモデル) を使用して、どちらのツールも効果的に使用できるシナリオでorganization固有のガイダンスを提供します。 最後に、BizTalk Server 2006 および WF のロードマップを確認して、現在構築しているアプリケーションの将来の校正に最適な意思決定を行えるようにします。

一般的なワークフロー シナリオ

スコープをワークフローのアプリケーションとエンタープライズ統合のカテゴリに限定した後でも、検討すべきワークフロー シナリオは幅広く存在します。 図 2 に示すように、スペクトルの一方の側には、WF が適切な選択肢であることが明確に示されているシナリオがあります。 その例として、独立系ソフトウェア ベンダー (ISV) 製品内のワークフロー機能があり、BizTalk Server 2006 のライセンス コストと展開の複雑さは非常に複雑です。 このシナリオでは、ISV として商用ソフトウェアを作成するビジネスを行っており、WF のロイヤリティフリーをホストするために必要な追加のプログラミング作業は、合理的な投資です。

図 2. 統合とワークフローの連続体

その反対側には、企業の IT 部門内に構築されたエンタープライズ統合ソリューションがあり、2006 年BizTalk Serverが適切な選択肢であることが明らかです。 このシナリオでは、ソリューションをスケーラブルで信頼性が高く、管理しやすいものにするために "プラミング" の構築に投資するのではなく、ビジネス価値の生成に集中したいと考えています。そのため、BizTalk Server 2006 のライセンス コストは、提供されるもののために十分に価値があります。

ほとんどのプロジェクトは、スペクトルのこれら 2 つの端の間のどこかに分類されます。 要件によってワークフロー ソリューションが決まる一般的なシナリオを次に示します。

  • UI ページ コントローラー - 複雑なアプリケーションで一般的な要件は、実装されている特定のユース ケースのビジネス ルールに従って UI 画面ナビゲーションを適用することです。 最も簡単な例は、ユーザーが所定の一連の画面を表示してタスクを実行するウィザードです。 多くの場合、ユーザーのアクションとデータの状態に基づく、画面ナビゲーションの可能性のより複雑なグラフです。
    Model-view-controller (MVC) パターンは、このナビゲーション ロジックをフォーム自体から引き出す従来の手法であり、さまざまなユース ケースで簡単かつ再利用可能です。 MVC パターンのコントローラーは、実際にはワークフローまたはステート マシンです。そのため、このようなアプリケーションを実装する際にワークフロー ツールを探すのが自然です。
  • 実行時間の長いビジネス ロジック - ビジネス トランザクションを完了するために多くの手順が必要な場合、ユーザーはプロセスの途中で停止するか、他のユーザーまたはシステムからのアクションを待ってから続行する必要があります。 プロセスを一時的に一時停止 (または "休止状態") し、外部イベントに基づいて再起動する機能は、ワークフローのアイデアの中心です。 ワークフロー エンジンがないと、開発者は、不完全なプロセスの状態を格納し、プロセスが続行されたときにその状態を呼び戻すメカニズムを手動で設計およびコーディングする必要があります。 適切に設計されたワークフロー エンジンを使用すると、この機能は開発者の追加作業なしでネイティブにサポートされます。
  • 動的に更新可能なプロセス フロー — 最初はビジネス プロセスを明確に定義されたシーケンシャル ステップに体系化することは可能ですが、多くの場合、人間は実際の状況を考慮してフローの中流を変更する必要があります。 経費承認プロセスでは、経費報告書を提出した従業員のマネージャーが既定の承認者である可能性があります。 ただし、マネージャーは、タスクを秘書に委任するか (たとえば、マネージャーがゴルフに出向いているため)、上司に承認をエスカレートするか (たとえば、マネージャーが特定の経費のポリシーがわからない場合など) に決定する場合があります。 ユーザーがフローを更新できるようにすることは、多くの場合、フローの可能なすべての順列を事前に予測するよりも簡単です。
  • ビジネス ロジックからのルールの抽象化 — このシナリオでは、ビジネス ルールを他のビジネス ロジックから分離することが目標です。 適切な例として、フォーム検証ルールがあります。 住宅ローン申請プログラムでは、ローン申請フォームには、ユーザーが [送信] ボタンを押してローン申請を送信する前に、フィールド検証ルールのセットが 1 つ含まれている場合があります。 ローン担当者がローンの確認と承認に同じフォームを使用する場合は、プロセスの別の段階にあるため、追加の検証規則が必要です。
    フォームとは別に検証規則を実装すると、さまざまなシナリオでフォームを再利用しやすくなり、そのシナリオに適した一連のルールを評価するだけで適切な検証規則を適用できます。
  • Web サービス アグリゲーター - アプリケーションでは、多くの場合、複数の異なる Web サービスのデータを集計する必要があります。 多くの場合、集計ロジック自体をアプリケーションから抽出し、他のアプリケーションから再利用できる独自の権限でサービスとして公開できます。 多くの場合、これらのサービスは 複合 Web サービスと呼ばれ、成熟したサービス指向アーキテクチャの重要な要素です。 Web サービス アグリゲーター のシナリオは、通常、同期的で実行時間の短いシナリオです。
  • 実行時間の長いビジネス プロセス - この記事では、複数のアプリケーションを統合するサーバー ベースのプロセスを指定するために実行時間の長いビジネス プロセス シナリオを使用します。一方、 ビジネス ロジック は 1 つのアプリケーション内のロジックに使用されます。 マルチスレッド、非同期動作、プロセス状態の永続化、インスタンスを処理するためのメッセージの関連付け、スケーラビリティ、信頼性、トランザクション整合性などのサーバーベースの実行時間の長いビジネス プロセスの要件は、アプリケーション内のビジネス ロジックの場合よりもはるかに高くなります。
  • ビジネス間 (B2B) プロセス : B2B プロセス シナリオは、基本的に Long Running Business Process シナリオと同じですが、前者は内部アプリケーションに加えて組織間にある点が除きます。 そのため、セキュリティ要件が最も重要です。 さらに、特定のデータ形式とトランスポート プロトコルは、ビジネス パートナーによって指示される可能性があるため、さらに制御が少なくなります。そのため、さまざまな形式とプロトコルをサポートし、多数のパートナーの特定のインターチェンジの構成をサポートする機能が必要です。
  • ビジネス プロセスからのルールの抽象化 - ビジネス ロジックからのルールの抽象化シナリオと同様に、このシナリオは、ビジネス プロセスの実行時間の長いシナリオと B2B プロセス シナリオのメイン コードからビジネス ルールを分離する場合に適用されます。 このシナリオでは、より高いレベルのパフォーマンスとスケーラビリティが必要です。 また、多くの場合、プログラミング以外のユーザーがルールを表示および編集できるようにするツールが必要になります。
  • エンタープライズ ルール リポジトリ — このシナリオでは、エンタープライズ内のすべてのアプリケーションから呼び出すことができる中央の共有ルール リポジトリを構築することが目標です。 これにより、重要なビジネス ルールを適用するためのorganization内のすべてのアプリケーションに一貫性が提供されます。 ビジネス プロセスからのルールの抽象化シナリオと同様に、このシナリオでは、非プログラミング者がルールを表示および編集できるようにするための高いスケーラビリティとツールが必要です。 さらに、このシナリオでは、ルール リポジトリが、ワークフロー エンジンとは別の独自のホスティング メカニズムと、さまざまなアプリケーションからルールを実行するためのコンポーネントまたは API を使用して、エンタープライズ内の独自のエンティティとして存在できる必要があります。
  • Enterprise Service Bus (ESB)/Message Broker- 多くの組織では、すべてのサービスに対して標準化された通信インフラストラクチャが必要です。 このインフラストラクチャの 2 つの最も一般的なトポロジは、ESB とメッセージ ブローカーです。 このインフラストラクチャでは、パブリッシュ/サブスクライブ メッセージングとトピック ベース ルーティングが一般的に期待される機能です。

アプリケーション プラットフォーム インフラストラクチャ最適化モデル

一部のワークフロー シナリオでは、BizTalk Server 2006 と WF の両方が技術的な要件を満たしています。 これらのシナリオでは、適切なワークフロー テクノロジを選択するには、ソリューションを特定のorganizationのニーズに合わせる必要があります。 特定のorganizationに適用される推奨事項を作成するために、図 3 に示すように、アプリケーション プラットフォーム インフラストラクチャ最適化 (APIO) モデルを使用します。

図 3: アプリケーション プラットフォーム インフラストラクチャの最適化 (APIO) モデル

APIO モデルは、アプリケーション インフラストラクチャ、アーキテクチャ、開発プラクティスに関して、organizationの成熟度をプロファイリングするための手法です。 このモデルの目的は、ビジネスのニーズを満たす IT ソリューションを提供する際に、組織の機敏性を最適化するためのロードマップを組織に提供することです。

APIO モデルでは、organizationの成熟度に関して次の 4 つのプロファイルを使用します。

  • Basic - 組織はソフトウェアをコストとして扱います。 統合や再利用がほとんどない、主にサイロ化されたアプリケーションがあります。 アプリケーションは、さまざまなプラットフォーム上にある可能性があります。 インフラストラクチャまたは開発手法に対して一貫した標準がありません。彼らは一貫したアーキテクチャビジョンを持っていません。
  • 標準化 - 組織は引き続きソフトウェアをコストとして扱いますが、効率を向上させるための手順を実行しています。 彼らはアーキテクチャのビジョンを持っており、再利用の機会を検討しようとします。 一部のアプリケーションの統合が開始されましたが、主にポイントツーポイントの統合です。
  • Advanced — 組織は、ソフトウェアをビジネス イネーブラーとして扱います。 彼らは専用の建築家と明確な建築ビジョンを持っています。 多くのサービスがあり、高いレベルの再利用を実現しています。 すべてのコア ビジネス プロセスは自動化され、監視されます。 一元化されたパッケージ化された統合プラットフォームを使用します。
  • 動的— 組織は、ソフトウェアを戦略的資産として扱います。 彼らはビジョンと実装において非常に成熟したSAを持っています。 サービスを動的にバージョン管理および再デプロイするための明確なプロセスがあります。 は、ビジネス要件の変更にすばやく適応でき、新しいビジネス パートナーと迅速に統合できます。

自分のいる場所だけでなく、どこに行くのか

APIO モデルでは、ある程度暗黙的なのは、すべてのorganizationが動的プロファイルへの移行を目指すという概念です。 実際には、ビジネスの性質と、テクノロジに関する管理の理念に依存します。 一部の企業は、Basic または標準化されたプロファイルに完全に満足している場合があります。

現在のプロファイルと、短期的および長期的な目標を考慮する必要があります。近い将来の目標が最も重要です。 Basic プロファイルのorganizationは、最終的には動的プロファイルに入ることを望み、最初は標準化されたプロファイルに入ることに焦点を当てることを賢明に選択する場合があります。そのため、そのテクノロジの決定は、主に標準化されたプロファイルと一致する必要があります。

一般に、BizTalk Server 2006 は、高度なプロファイルまたは動的プロファイルで、近い将来の目標を持つ組織により適しています。 このプロファイルで比較的満たされている Basic プロファイルのorganizationには、BizTalk Server 2006 を採用する戦略的動機も、それを効果的に活用する機能もない可能性があるため、投資を行いたくない可能性があります。 ただし、Basic プロファイルのorganizationが高度なプロファイルに積極的に移行することを決定した場合は、BizTalk Server 2006 を採用することが、その方向の戦略的なステップになる可能性があります。

このディスカッションに APIO モデルを導入するポイントは、organizationの現在および対象となる APIO プロファイルの良いアイデアを持つことは、WF と BizTalk Server 2006 のどちらかのテクノロジで技術的なシナリオを適切にサポートできる時期を決定する際に役立つことです。 2 つの異なる組織が異なる選択を行う場合があります。それぞれが組織プロファイルに適した選択を行います。

それはホスト内のすべてです

BizTalk Server 2006 と WF のどちらかを選択する際に考慮すべき最も重要な側面の 1 つは、ワークフローのホスティング要件です。 BizTalk Server 2006 とは異なり、WF では "すぐに使用できる" ホスティングは提供されません。Windows プロセスを確立し、ワークフローを実行するワークフロー ランタイム エンジンを起動するホストを実装する必要があります。

さまざまなワークフロー シナリオを現実的にサポートできるフレームワークを構築するために、WF は、BizTalk Server 2006 などの環境が提供するコア動作を抽象化して、さまざまなホストがこれらのサービスに特定の目的の動作を提供できるようにします。

WF ワークフロー ホストが提供するコア サービスは次のとおりです。

  • スケジュール サービス - ランタイム エンジンがワークフロー インスタンスを実行するために使用するスレッドを作成および管理します。
  • Commit Work Batch サービス - データベース操作にランタイム エンジンによって使用されるトランザクションを管理します。
  • 永続化サービス - ランタイム エンジンによってワークフロー インスタンスに指示されたときに、ワークフロー インスタンスの永続化を処理します。 このサービスは省略可能です。 指定しない場合、ワークフロー インスタンスは永続化されず、有効期間全体にわたってメモリ内で実行する必要があります。
  • 追跡サービス - ワークフロー内で追跡イベントを記録する機能を提供します。 このサービスは省略可能です。

ワークフロー ホストを構築するために必要なもの

ワークフローのシナリオやワークフローに提供する必要があるサービスによっては、WF ホストの構築が簡単であるか、または非常に大きな場合があります。 ワークフローがアプリケーションのコンテキスト内にあるシナリオでは、WF のホストはかなり簡単です。 アプリケーション自体がプロセス ホストとして機能し、最小限の労力で構成できるコア サービスの標準的な実装があります。

ただし、非常にスケーラブルなサーバー ベースのシナリオになると、ホストの必要な高度さが劇的に向上します。 表 1 は、必要になる可能性があるホスト サービスのランドリー リストを示しています。そのほとんどは、BizTalk Server 2006 で提供されています。

表 1 ホスト サービス

  • スケール アウト構成
  • 負荷分散
  • フェールオーバー
  • Throttling
  • スレッドの管理
  • メモリ管理
  • サービスの分離
  • 例外の構成
  • Failed-message management
  • メッセージの追跡
  • アーカイブと消去
  • ID と偽装
  • 複数環境デプロイ モデル
  • 正常性の監視
  • 使用率/パフォーマンスの追跡
  • 複合プロセス状態管理
  • スクリプト
  • 障害復旧
  • 規制に対するコンプライアンス
  • 構成管理

とにかく、あなたは何のビジネスにいますか?

期限が厳しい特定のアプリケーションの構築を任されている場合は、必要なビジネス ロジックの実装に集中する必要があるときに複雑なホストを構築する必要があるため、チームに気を取られたくない可能性があります。 この場合、BizTalk Server 2006 は、堅牢なワークフロー ホストを構築するのではなく、購入する価値があります。 大企業の中央アーキテクチャ チームの一員である場合は、organization全体で使用できるホストの構築に投資することを選択できます。 それでも、この取り組みは軽視しないでください。

Workflow-Technologyの推奨事項

アプリケーション内のシナリオの場合: WF

UI ページ コントローラー、実行時間の長いビジネス ロジック、動的に更新可能なプロセス フロー、Web サービス構成、ビジネス ロジックからのルールの抽象化など、アプリケーション内に含まれるすべてのシナリオでは、WF が適切なワークフロー テクノロジの選択肢です。

アプリケーション中心のシナリオの大部分では、使用パターンには、アプリケーションとワークフローの間の同期的で待機時間の短い相互作用が必要です。これは、BizTalk Server 2006 の強みではありません。 BizTalk Server 2006 は、パフォーマンス上の理由から、これらのシナリオには適していません。BizTalk Serverオーケストレーションは専用の BizTalk Server 上で実行され、クライアント アプリケーションから呼び出す場合は、ネットワーク経由でラウンド トリップが必要です。 さらに、2006 BizTalk Serverの設計では、メッセージボックス データベースにすべてのメッセージを永続化して持続性を高めるという設計により、追加の待機時間が発生します。ワークフローを同期的に呼び出す必要がある場合は、対話型 UI のコンテキストでは受け入れられない可能性があります。

WF は、これらのシナリオに適しています。ワークフローの要件を満たし、2006 年BizTalk Serverよりもシンプルで安価です。 これらのシナリオでは、BizTalk Server 2006 のメッセージング機能 (マッピングとアダプターなど) は必要ありません。 サービスをホストするための要件は少ないため、アプリケーション内で WF ランタイムをホストする場合、大量の作業は必要ありません。

ほとんどのBusiness-Process シナリオの場合: BizTalk Server 2006

サーバー ベースのビジネス プロセスに関連するほとんどのシナリオでは、BizTalk Server 2006 が適切な選択肢です。 これには、B2B プロセス、ビジネス プロセスからのルールの抽象化、エンタープライズ ルール リポジトリ、Enterprise Service Bus (ESB)/Message Broker が含まれます。

これらのシナリオでは、高いスケーラビリティが必要です。 また、実行中のプロセスを表示し、停止して再起動する機能も必要です。 最後に、複数のサーバーへのスケールアウトのサポートが必要です。 これらのシナリオでは、BizTalk Server 2006 の高度なホスティング機能が必要であり、投資に十分な価値があります。

Basic 標準化 上級 動的

WF → BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

図 4: 実行時間の長いビジネス プロセス シナリオ

BizTalk Server 2006 は、通常、長時間実行されるビジネス プロセス シナリオに最適なプラットフォームになります。 これらのプロセスは、非同期で実行時間が長く、ステートフルである傾向があります。 これらのプロセスは、多くの場合、organizationにとってミッション クリティカルであるため、高可用性、可視性、セキュリティ、管理容易性が必要です。 BizTalk Server 2006 のグループまたは "ファーム" トポロジを使用すると、スケーラビリティと冗長性を提供するサーバーの配列を管理できます。

プロセス状態を格納するためのBizTalk Server 2006 の永続化メカニズムには、永続化状態のプライバシーを保護するための堅牢なセキュリティが組み込まれています。これは、規制上の理由から重要になる可能性があります。 BizTalk Server 2006 のビジネス アクティビティ監視 (BAM) は、実行中のプロセスを安全な方法で適切にビジネス レベルで可視化します。 最後に、これらのシナリオでは、多くの場合、レガシ システムを含む異種メッセージ形式とトランスポート プロトコルのサポートが必要になります。

このような理由から、BizTalk Server 2006 は通常、標準化、高度、動的プロファイルを対象とする組織に最適な選択肢になります。 通常、これらの組織は、長時間実行されるビジネス プロセス シナリオをビジネスにとって非常に重要であり、企業内で非常に一般的であると見なします。そのため、2006 年BizTalk Server購入して、標準化されたプラットフォームを確立します。

ただし、基本的な APIO プロファイルに含まれる組織では、WF の方が適している場合があります。 これらの組織は一般に、標準化されたアプリケーション プラットフォームの構築に投資する必要はありません。 代わりに、コストを最小限に抑え、BizTalk Server 2006 のライセンスとハードウェアのコストが非常に大きくなることがあります。 このガイダンスの例外は、さまざまなメッセージ形式とトランスポート プロトコルの高いスケーラビリティ、監視、サポートの要件がある場合です。 この場合、organizationはアプリケーション プラットフォームへの投資に消極的ですが、ホスティング機能とメッセージング機能をゼロから構築するコストが、BizTalk Server 2006 のコストを超える可能性があります。

Basic 標準化 上級 動的

WF

WF → BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

図 5: Web サービス アグリゲーターのシナリオ

BizTalk Server オーケストレーションと WF ワークフローはどちらも、ワークフローから外部で使用する Web サービスと、ワークフローを Web サービスとして公開するための強力なサポートを持っています。 そのため、Web サービス アグリゲーター ソリューションを構築する場合は、実行時間の長いビジネス プロセス ソリューションの場合と同様に、組織のプロファイルとホスティングの要件によって選択が決定されます。

集約 Web サービスが他の Web サービスのみを集計する場合、異種メッセージ形式とトランスポート プロトコルをサポートするBizTalk Server 2006 の機能は、ほとんど価値を追加しません。 ただし、サービスが Web サービスとして公開されていないレガシ環境のデータも集計する必要がある場合、BizTalk Server 2006 は価値を追加します。

使用パターンは迅速で同期的な要求/応答呼び出しであるため、通常、BizTalk Server 2006 によって提供されるメッセージの持続性は重要ではありません。 実際、MessageBox への永続化によって発生する待機時間は、実際には責任です。 このシナリオBizTalk Server 2006 で提供されるメイン値は、多数のサーバー間でのデプロイを管理し、実行中のインスタンスを監視する機能です。 BizTalk Server 2006 の BAM 機能は、サービス レベル アグリーメント (SLA) が満たされていることを監視する場合にも役立ちます。

このような理由から、WF は Web サービス アグリゲーター (特に基本プロファイルと標準化されたプロファイルの組織) を実装する場合に非常に適しています。 BizTalk Server 2006 が有利になる可能性がある例は、さまざまなクライアント組織に対して多数のエンドポイントを管理する必要がある例です。 BizTalk Server 2006 の受信ポートと受信場所の構成では、これを特に処理します。 この場合、証明書も重要であり、証明書を構成して管理し、暗号化/暗号化解除に適用するために、BizTalk Server 2006 のサポートが役立つ場合があります。

Future-Proofing

ソフトウェア ライセンス コストへの投資、ワークフロー テクノロジの学習、特定のワークフロー コンポーネントの構築に対する投資が、将来可能な限り高い価値を提供できるようにしたいと考えています。 特定のワークフロー シナリオとorganizationに適したワークフローを選択するだけでなく、BizTalk Server 2006 および WF の製品ロードマップも考慮する必要があります。 これに対する簡単な答えはありません。 以下のコメントは、どちらのテクノロジを選択しても強い議論をしません。代わりに、決定に役立つデータ ポイントです。

BizTalk Server 2006 R2 の追加内容

BizTalk Server 2006 R2 では、ワークフロー プラットフォームの選択に影響を与える可能性がある 2 つの機能 (WCF アダプターと、WCF と WF の BAM インターセプター) が追加されます。

WCF アダプター

チームが SOA を構築する際にサービスを実装するための標準テクノロジとして Windows Communication Foundation (WCF) を採用している場合、BizTalk Server 2006 が WCF サポートを持っていないという事実は、複合 Web サービスを構築およびホストするためのプラットフォームとして認定されていない可能性があります。 これは、BizTalk Server 2006 がシナリオと APIO プロファイルに最適であった場合でも、WF に向かってプッシュされた可能性があります。

幸いにも、BizTalk Server 2006 R2 で優れた WCF 統合が導入されたので、これは問題ではなくなりました。 BizTalk Server 2006 では、WCF と強力に統合されました。これは、より詳細なサービスから複合サービスを構築し、これらの複合サービスを WCF サービスとして公開するための優れたプラットフォームです。

WF の BAM インターセプター

2 つ目の関連BizTalk Server 2006 R2 機能は、WF の BAM インターセプターの導入です。 ビジネス アクティビティの監視がソリューションの重要な機能である場合は、WF がシナリオに適していた場合に、BAM を利用するために、BizTalk Server 2006 の使用に向けてプッシュされた可能性があります。 WF 用の BAM インターセプターを使用すると、WF がプロジェクトに適したワークフロー テクノロジである場合に WF を選択でき、エンタープライズ ビジネス アクティビティ監視ソリューションとして BAM を引き続き使用できます。

BAM は、BizTalk Server 2006 の機能であり、BizTalk Serverオーケストレーションとメッセージ フローからイベントとデータをキャプチャし、そのデータをポータルに表示して、ビジネス ユーザーにビジネス プロセスのエンドツーエンドの可視性を提供するフレームワークを提供します。 BizTalk Server 2006 アプリケーションで BAM が機能する方法の強力な側面は、BizTalk Server 2006 アプリケーションを展開した後で、BizTalk Server 2006 コード成果物を変更することなく BAM 監視を構成 (または "インストルメント化") できることです。

BAM は、企業全体のビジネス アクティビティ監視ソリューションとして設計されています。そのため、BizTalk Server以外の 2006 アプリケーションでイベントとデータを BAM にフィードできます。 ただし、これを行うための API では、外部アプリケーションでかなりのコードを記述する必要があります。 BizTalk Server 2006 R2 の BAM WF インターセプターは、コードの変更を必要とせずに、BAM 用の WF ワークフローをより簡単にインストルメント化する機能を提供します。 BAM インターセプターを使用すると、WF または WCF ソリューションを再コンパイルすることなく、ビジネス プロセスを追跡できます。統合は、構成ファイルを使用して行われます。

WF SDK BizTalk Server 2006 拡張機能

BIZTALK SERVER 2006 Extensions for WF SDK が発表され、TechEd 2007 でデモが行われました。 この SDK は、BizTalk Server 2006 で WF ワークフローをホストするための簡単なメカニズムを提供します。 このツールは、現在 WF ワークフローを構築し、それらのワークフローの堅牢でスケーラブルなホスティングを実現する簡単な方法を探している .NET 開発者が使用することを目的としています。

SDK には、2 つのカスタム WF アクティビティ (btsReceive アクティビティと btsSend アクティビティ) が用意されており、WF ワークフロー内で 2006 BizTalk Server経由でメッセージを送受信するために使用できます。 開発者は、受信メッセージと送信メッセージの WCF DataContracts と、メッセージ交換パターンを定義する ServiceContract を定義します。 WF ワークフロー内では、図 6 に示すように、定義された ServiceContract を使用するように btsReceive アクティビティと btsSend アクティビティが構成されます。

図 6: 定義された ServiceContract で使用するための btsReceive アクティビティと btsSend アクティビティ

WF ワークフローが完了してコンパイルされたら、ワークフロー プロジェクトを右クリックし、[オーケストレーションの生成] を選択して、WF ワークフローを開始し、2006 メッセージBizTalk Serverルーティングするラッパー オーケストレーションを自動的に生成します (図 7 を参照)。

自動生成されたラッパー オーケストレーションには、 ServiceContract で定義されているメッセージのスキーマが含まれています。 また、BizTalk Server 2006 メッセージの受信、ワークフロー インスタンスの作成と開始、ワークフロー インスタンスへの受信メッセージの受け渡し、送信メッセージの受信、BizTalk Server 2006 メッセージング エンジンへの転送を行うBizTalk Serverオーケストレーションの図形とコードも含まれています。 WF ワークフローのホスティングを完了するには、ラッパー オーケストレーションをコンパイルしてデプロイし、通常の BizTalk Server 2006 メカニズムを使用してバインドするだけです。

図 7: ラッパー オーケストレーションを自動的に生成する

BIZTALK SERVER 2006 for WF ワークフローの堅牢でスケーラブルなホスティング メカニズムを利用するだけでなく、BizTalk Server 2006 Extensions for WF SDK を使用すると、BizTalk Server 2006 メッセージング インフラストラクチャを利用できます。 したがって、2006 BizTalk Serverとの間でメッセージを取得するために使用可能なアダプターの数と、マッピング機能を含むパイプライン処理を利用できます。

BIZTALK SERVER 2006 Extensions for WF SDK は、WF 開発者が 2006 年BizTalk Server上にワークフローを展開できるようにするツールとして使用する必要があります。これは、BizTalk Server 2006 を適切なツールとして特定したシナリオのオーケストレーションの代わりとしてではなく、2006 年の上に展開できるようにします。 一部の WF 図形は、オーケストレーションにラップされている場合は機能しません。 これは、BIZTALK SERVER 2006 Extensions for WF SDK を使用して BizTalk Server 2006 内で WF ワークフローをホストすると、ネイティブ オーケストレーションと同じホスティング動作が提供されないためです。 SDK には、これらの相違点の概要を示す FAQ リスト (クイック スタート ガイドに含まれています) があります。

まとめ

BizTalk Server 2006 および Windows Workflow Foundation は、アプリケーションとエンタープライズ統合ワークフローのカテゴリにワークフロー ソリューションを実装するための Microsoft の主要なツールです。 プロジェクトに適したシナリオを選択するには、まず、対象とするワークフロー シナリオを特定する必要があります。

次に、図 8 の表を使用して、シナリオに推奨されるワークフロー テクノロジを確認します。 アプリケーション内のワークフローの場合は、WF をお勧めします。 ほとんどのサーバー ベースのビジネス プロセスと B2B シナリオでは、2006 年BizTalk Serverすることをお勧めします。

図 8: シナリオ固有のワークフロー テクノロジ

実行時間の長いビジネス プロセスと Web サービス アグリゲーターの両方のシナリオでは、どちらのテクノロジも影響を受けて適用できます。 これらのシナリオでは、organizationの現在および短期的なターゲット APIO プロファイルを評価する必要があります。 高度なプロファイルまたは動的プロファイルに移行している組織は、これらのシナリオにBizTalk Server 2006 を使用する必要があります。 Basic プロファイルと Standard プロファイルの組織は、これらのシナリオで WF を効果的に使用できます。

最後に、ソリューションのリリース日と必要な有効期間を、BizTalk Server 2006 および WF の製品ロードマップに対して考慮する必要があります。 このフレームワークとこの記事のガイダンスを使用すると、プロジェクトに適したワークフローを選択できるようになります。

補遺

誤解を払拭する BizTalk Server 2006 と WF について

WF と BizTalk Server 2006 に関する一般的な誤解と、それらを払拭するために使用する明確な引数を次に示します。

  • WF は、BizTalk Server 2006 の代わりです。いいえ。WF はプログラミング ワークフロー用の Microsoft からの "最新かつ最も優れた" オファリングであるため、BizTalk Server 2006 に慣れていない多くのユーザーは、最初は WF のリリースで古くなったと想定しています。 この印象を修正するための簡単な答えは、WF はあらゆる種類のワークフローを構築するための低レベルの開発者フレームワークですが、BizTalk Server 2006 は、ワークフロー シナリオの特定のカテゴリの高度な機能を備えた本格的なサーバー製品である Enterprise Integration です。 (図 1 を参照)。
    WF では、この機能のごく一部 (ワークフローとビジネス ルール) のみが提供されます。 WF は、BizTalk Server 2006 で提供される他のすべての機能を必要としないシナリオでは、よりシンプルでコスト効率の高いソリューションである可能性があります。2006 年BizTalk Serverサポートするように設計された主要なエンタープライズ統合シナリオでは、2006 BizTalk Serverに代わるものではありません。
  • BizTalk Serverは消え去ろうとしています。いいえ。同様の誤解は、WF が将来のワークフロー ツールとしてリリースされ、BIZTALK SERVERまだ WF を使用するように書き換えられていないため、Microsoft はBizTalk Serverに投資しなくなり、最終的に新しい WF ベースの製品に置き換えるという印象です。 これは単に当たりません。BizTalk Serverは非常に成功した製品であり、それがターゲットとするエンタープライズ統合領域は、Microsoft がサポートに取り組んでいる領域であり続けます。
  • .NET Frameworkよりも 2006 BizTalk Server選択する必要があります。いいえ。BizTalk Server 2006 に慣れていない .NET 開発者は、2006 年BizTalk Serverより WF を選択したくなるかもしれません。単に、"純粋な" .NET を使用する必要があります。 しかし、これは実際には有用な基準ではありません。BizTalk Server 2006 自体は、.NET Framework上に構築されています。
    実際、BizTalk Server 2006 は、ソリューションに適用できる 200 万行を超える .NET コードを表しており、その機能をゼロから開発する時間、トラブル、コストを節約できます。 さらに、BizTalk Server 2006 プログラミング自体は Microsoft Visual Studio .NET 内で実行され、コンポーネントは .NET アセンブリとしてコンパイルおよび展開されます。 さらに、最も重要なBizTalk Server 2006 プロジェクトでは、BizTalk Server 2006 コンポーネントとカスタム .NET コンポーネントが組み合わされるため、2006 年BizTalk Server開発は、外部または異なるものではなく、特殊な .NET 開発と見なす必要があります。
    実際の問題は、BizTalk Server 2006 の機能が、ライセンス コストを正当化するために特定のワークフロー シナリオに十分な価値を提供するかどうかです。 スレッジハンマーを使用して写真をハングさせたくない。大きな岩をつぶすために大工のハンマーを使いたくはありません。
  • 最も多くの機能が優先されます。選択が不十分です。WF の詳細な機能と 2006 年BizTalk Serverの機能を比較する特徴行列を作成できます。 ただし、この比較はあまり役に立ちません。BizTalk Server 2006 には、特にエンタープライズ統合スペースを対象とする多数の機能があります。 これがターゲット シナリオでない場合、機能の比較は意味がありません。 BizTalk Server 2006 は、機能チェックボックスの数に関して勝つ可能性があります。ただし、これらの機能が対象とするワークフロー シナリオに関連していない場合は、apples と oranges の比較です。

謝辞

ポール・アンドリューとクリス・ホーロックス、そしてこの記事をレビューしたすべての人に感謝します。

詳細情報

筆者について

ケント ブラウンは、ニューヨーク市の Microsoft Gold 認定コンサルティング パートナーである 20ix New York のエンタープライズ統合プラクティスのディレクター兼シニア アーキテクトです。 彼は2000年の設立以来、BizTalk Serverに興奮し、この7年間製品の周りでエバンジェリストの役割を果たしてきました。 Kent は、Microsoft BizTalk Virtual Technical Specialist チームのメンバーであり、Microsoft Connected Systems Developer MVP です。 NYC コネクテッド システム ユーザー グループ (http://www.NYCCSUG.org) の創設者およびリーダーです。