次の方法で共有

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ページ印刷)

内容

紹介

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

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

It's All in the Host

Workflow-Technology 推奨事項

Future-Proofing

結論

補遺

確認

詳細情報

紹介

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

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

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

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

ワークフロー シナリオの範囲は多岐にわたり、Human Workflow、Application Workflow、Enterprise Integration Workflow、Data Integration Workflowの 4 つのカテゴリにグループ化すると便利です。

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

この記事では、アプリケーション ワークフローとエンタープライズ統合ワークフローのシナリオで 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 では、.NET Framework に視覚的なワークフロー中心のプログラミング モデルが導入されています。これは、今後 Windows プラットフォーム上のすべてのワークフロー関連のシナリオで使用できる一般的で拡張可能なモデルです。 WF を作成したチームは、BizTalk Server オーケストレーション エンジンの最適な概念を取り入れ、ワークフロー シナリオのより広範な領域の要件を考慮し、それらすべてをサポートするのに十分な柔軟性を備えたフレームワークを設計することができました。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

APIO モデルでは、すべての組織が動的プロファイルへの移行を目指すという概念は、やや暗黙的です。 実際には、それはビジネスの性質と技術に関する管理の理念に依存します。 一部の企業は、基本プロファイルまたは標準化プロファイルを維持するために完全に満足している可能性があります。

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

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

この説明に APIO モデルを導入するポイントは、組織の現在および対象となる APIO プロファイルを適切に把握することで、WF と BizTalk Server 2006 のどちらかのテクノロジで技術的なシナリオが適切にサポートされる可能性がある場合の決定に役立つことです。 2 つの異なる組織が、それぞれ組織プロファイルに適した選択を行う、異なる選択を行う場合があります。

It's All in the Host

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. ホスト サービス

  • スケールアウト構成
  • 負荷分散
  • フェールオーバー
  • 調整
  • スレッド管理
  • メモリ管理
  • サービスの分離
  • 例外の構成
  • 失敗したメッセージの管理
  • メッセージの追跡
  • アーカイブと消去
  • ID と偽装
  • 複数環境デプロイ モデル
  • 正常性の監視
  • 使用率/パフォーマンスの追跡
  • 複合プロセス状態管理
  • スクリプト
  • ディザスター リカバリー
  • 規制コンプライアンス
  • 構成管理

とにかく、あなたはどのようなビジネスをしていますか?

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

Workflow-Technology 推奨事項

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

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

ほとんどのアプリケーション中心のシナリオでは、使用パターンには、BizTalk Server 2006 の強度ではない、アプリケーションとワークフローの間の同期的で待機時間の短い対話が必要です。 BizTalk Server 2006 は、パフォーマンス上の理由から、これらのシナリオには適していません。BizTalk Server オーケストレーションは専用の BizTalk Server 上で実行され、クライアント アプリケーションからそれらを呼び出す場合は、ネットワーク経由でラウンド トリップする必要があります。 さらに、BizTalk Server 2006 の設計では、持続性のためにすべてのメッセージをメッセージ ボックス データベースに保持するため、待機時間が増加します。ワークフローを同期的に呼び出す必要がある場合は、対話型 UI のコンテキストでは許容できない可能性があります。

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

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

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

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

基本的な 標準化 アドバンスド 動的

WF → BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

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

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

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

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

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

基本的な 標準化 アドバンスド 動的

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 サービス アグリゲーター (特に Basic プロファイルと標準化されたプロファイルの組織) を実装する場合に非常に適した選択肢です。 BizTalk Server 2006 が有利になる例は、さまざまなクライアント組織の多数のエンドポイントを管理する必要がある場合です。 BizTalk Server 2006 の受信ポートと受信場所の構成では、これを特に処理します。 この場合、証明書も重要であり、証明書を構成して管理し、暗号化/暗号化解除に適用するための BizTalk Server 2006 のサポートが役立つ場合があります。

Future-Proofing

ソフトウェア ライセンス コストへの投資、ワークフロー テクノロジの学習、および特定のワークフロー コンポーネントの構築に対する投資が、将来可能な限り高い価値を提供できるようにしたいと考えています。 特定のワークフロー シナリオと組織に適したワークフローを選択するだけでなく、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 がシナリオに適していた場合に、BIZTalk Server 2006 の使用 (BAM を利用するためだけに) にプッシュされている可能性があります。 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 ソリューションを再コンパイルせずにビジネス プロセスを追跡できます。統合は、構成ファイルを使用して行われます。

BizTalk Server 2006 Extensions for WF SDK

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

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

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

WF ワークフローが完了してコンパイルされたら、ワークフロー プロジェクトを右クリックし、オーケストレーションの生成 を選択して、WF ワークフローを開始し、BizTalk Server 2006 メッセージをそのワークフローとの間でルーティングするラッパー オーケストレーションを自動的に生成します (図 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 メッセージング インフラストラクチャを利用できます。 そのため、BizTalk Server 2006 との間でメッセージを送受信するために使用できる多くのアダプターと、マッピング機能を含むパイプライン処理を利用できます。

BizTalk Server 2006 Extensions for WF SDK は、BizTalk Server 2006 を適切なツールとして特定したシナリオでは、BizTalk Server 2006 の代わりにではなく、WF 開発者が BizTalk Server 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 シナリオでは、BizTalk Server 2006 をお勧めします。

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

実行時間の長いビジネス プロセスと Web サービス アグリゲーターの両方のシナリオで、どちらのテクノロジも影響を受けて適用できます。 これらのシナリオでは、組織の現在および短期的なターゲット 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 が提供する他のすべての機能を必要としないシナリオでは、よりシンプルでコスト効率の高いソリューションである可能性があります。BizTalk Server 2006 がサポートするように設計された主要なエンタープライズ統合シナリオでは BizTalk Server 2006 に代わるものではありません。
  • BizTalk Server が消えます。いいえ。 WF は将来のワークフロー ツールとしてリリースされ、BizTalk Server はまだ WF を使用するように書き換えられていないため、Microsoft は BizTalk Server に投資しなくなり、最終的には新しい WF ベースの製品に置き換えられるという印象です。 これは単に当てはまるわけではありません。BizTalk Server は非常に成功した製品であり、それをターゲットとするエンタープライズ統合領域は、Microsoft がサポートに取り組んでいる領域であり続けます。
  • .NET Framework よりも BizTalk Server 2006 を選択する必要があります。いいえ。 BizTalk Server 2006 に慣れていない .NET 開発者は、BizTalk Server 2006 よりも 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 コンポーネントが組み合わせられます。そのため、BizTalk Server 2006 の開発は、外部または異なる開発ではなく、特殊な .NET 開発と見なす必要があります。
    実際の問題は、BizTalk Server 2006 の機能が、ライセンス コストを正当化するのに十分な価値を特定のワークフロー シナリオに提供するかどうかです。 スレッジハンマーを使用して写真をハングさせたくない。大きな岩を押しつぶすために大工のハンマーを使いたくはありません。
  • ほとんどの機能が優先されます。悪い選択。 WF の詳細な機能と BizTalk Server 2006 の機能を比較する機能マトリックスを作成できます。 ただし、この比較はあまり役に立ちません。BizTalk Server 2006 には、特にエンタープライズ統合スペースを対象とする多数の機能があります。 これがターゲット シナリオでない場合、機能の比較は意味がありません。 BizTalk Server 2006 は、機能チェック ボックスの数に関しておそらく勝つでしょう。ただし、これらの機能がターゲットとするワークフロー シナリオに関連していない場合は、apples と oranges の比較になります。

確認

ポール・アンドルーズとクリス・ホーロックス、そしてこの記事を読んだすべての人に感謝します。

詳細情報

作成者について

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