目次:
- 平易な英語で
- ケーススタディ
ビジネスプロセスを自動化したり、さまざまなレガシー環境を統合したりするためにenterprise application integration(EAI)ミドルウェア製品を既に採用している組織は、オーケストレーションの概念にすでに精通している可能性があります。 これらのシステムでは、集中管理された一連のワークフローロジックにより、2つ以上の異なるアプリケーション間の相互運用性が促進されます。 オーケストレーションの一般的な実装は、複数の外部参加者が中央のオーケストレーションエンジンとインターフェイスできるハブアンドスポークモデルです。
これらのソリューションの作成の背後にある駆動要件の一つは、大規模なビジネスプロセスのマージに対応することでした。 オーケストレーションを使用すると、当初はプロセスを個別に自動化していたソリューションを再開発することなく、異なるプロセスを接続できます。 オーケストレーションは、新しいワークフローロジックを導入することで、このギャップを埋める。 さらに、オーケストレーションを使用すると、ソリューション環境の複雑さを大幅に軽減できます。 ワークフローロジックは、個々のソリューションコンポーネントに埋め込まれた場合よりも抽象化され、より簡単に維持されます。
オーケストレーションの役割は、サービス指向の環境で広がります。 Orchestrationは、ビジネスプロセスロジックをサービス経由で表現できる拡張機能を使用することにより、標準化されたサービスベースの会場でビジネスロジックを表 サービス指向の解決を造るとき、これは自動化されるプロセスを表す論理を収容し、制御する非常に魅力的な手段を提供する。
オーケストレーションは、潜在的な統合エンドポイントをプロセスに提供することによって、サービス設計が求める本質的な相互運用性をさらに オーケストレーションがSOA内でどのように配置されるかの重要な側面は、オーケストレーション自体がサービスとして存在するという事実です。 したがって、オーケストレーションロジックに基づいて構築することで、組織全体のプロセス表現が標準化され、エンタープライズフェデレーショ
図6.32. オーケストレーションは、複雑なアクティビティのほぼすべてのファセットを制御します。
オーケストレーションを標準化する主要な業界仕様は、WEBサービス-ビジネス-プロセス実行言語(WS-BPEL)です。 本書では、WS-BPELを第二世代の主要な拡張として認識しているため、ビジネス-プロセス-モデリングに関する多くの議論の基礎として、WS-BPELの概念と用語をWS-BPELは、この仕様に与えられた最新の名前であり、BPEL4WSとも呼ばれ、単にBPELです。 WS-BPEL言語の主要な部分の概要と、名前の変更がどのように行われたかについての説明は、第16章を参照してください。
平易な英語で
いくつかの車を一緒に洗うことに成功した後、チャック、ボブ、ジム、そして私は私たち自身の会社を始めることにしました。 私達は私達が異なったタイプの異なったクリーニングの条件の車を扱ってもいいように私達の車の洗浄プロセスのステップを形式化します。
このため、当社のプロセスは以下の新しい要件の影響を受けます:
- 私たちは、ピーク時に余分な助けを雇うことにしました。 これは、私たちのチームに参加する二人の追加メンバーまで紹介します。
- この事業にはベンチャーキャピタルがないため、地元のガソリンスタンドと手配をしています。 私達の車の洗浄操作のためのロットの部分を使用することと引き換えに、私達はピーク時間の間にガスポンプ義務と助けることに同意する。
私達の簡単な車の洗浄プロセスは今かなり複雑になりました。 このプロセスは、さまざまな条件やイベントの結果として任意の時点で変更できるという点で固定されなくなりました。
- 私たちの余分な労働者が到着すると、チーム全体のタスク割り当てが変更されます。
- ガソリンスタンドの担当者が余分な助けを必要とする場合、我々は彼らを支援するために私たちの車の洗浄チームメンバーの一人以上を送信する義務が
これらの例は、日常的に発生する予測可能な条件に関連しています。 私たちの操作はさらにいくつかの制約の影響を受けます:
- キャッシュフローが一定額を下回った場合、アルバイトをする余裕はありません。
- 雨が降った場合は、すべての作業が中断されます（キャッシュフローの減少にもつながります）。
これらの制約は、あまり一般的ではありませんが、常に考慮する必要がある条件を導入します。 これらの潜在的な状態を収容するためには、私達は私達の拡大されたプロセスを地図を描き、共通および珍しい条件を取扱うために代わりとなるプ
この計画は、基本的に、個々のステップをプロセスとサブプロセスと結合し、決定点で分割するワークフローです。 この精巧なワークフローは給油所のプロセスおよび私達のパートタイム労働者の到着に起因する延長プロセスとの私達の元のプロセスを組み込む。 このワークフローは、基本的に、個々のプロセス要件と関連するリソース、参加者、イベント、ビジネスルール、およびアクティビティを管理するオーケストレーショ
6.6.1. ビジネスプロトコルとプロセス定義
オーケストレーションを構成するワークフローロジックは、多数のビジネスルール、条件、イベントで構成できます。 オーケストレーションのこれらの部分を総称して、ビジネスタスクの完了を達成するために参加者が相互運用する方法を定義するビジネスプロトコル オーケストレーションによってカプセル化され、表現されるワークフローロジックの詳細は、プロセス定義内に含まれます。
6.6.2. プロセス定義内で識別および記述されたプロセスサービスおよびパートナーサービス
は、許容されるプロセス参加者です。 まず、プロセス自体がサービスとして表され、プロセスサービスが生成されます（図6.33に示すように、別のサービスモデルが発生します）。
図6.33. プロセスサービスは、三つのパートナーサービスからの機能を調整し、公開します。
プロセスサービスとの対話が許可されている他のサービスは、パートナーサービスまたはパートナーリンクとして識別されます。 ワークフローロジックに応じて、processサービスは外部パートナーサービスから呼び出すことも、他のパートナーサービスを呼び出すこともできます(図6.34)。
図6。34. プロセスサービスは、パートナーサービスによって最初に呼び出された後、別のパートナーサービスを呼び出します。
6.6.3. 基本アクティビティと構造化アクティビティ
WS-BPELは、ワークフローロジックを一連の事前定義されたプリミティブアクティビティに分解します。 基本的なアクティビティ(receive、invoke、reply、throw、wait)は、構造化されたアクティビティ(sequence、switch、while、flow、pick)によって提供されるロジックを使用して組み立てることができる基本的なワークフローアクションを表します。 これらの活動を使用して実際のビジネスプロセスロジックを表現する方法については、第16章で説明します。
6.6.4. シーケンス、フロー、リンク
基本的なアクティビティと構造化されたアクティビティは、実行順序が事前定義されるように編成することができます。 シーケンスは、一連の実行順序を決定するリストに関連するアクティビティのグループを整列させます。 シーケンスは、アプリケーションロジックの一部が別の結果に依存している場合に特に便利です。
フローには関連するアクティビティのグループも含まれていますが、実行要件は異なります。 つまり、あるアクティビティのセットが別のアクティビティが終了する前に待機する必要は必ずしもありません。 ただし、すべてのカプセル化されたアクティビティが処理を完了するまで、フロー自体は終了しません。 これにより、個々のフローに存在するアプリケーションロジック間の同期が保証されます。
リンクは、フローの一部であるアクティビティ間の正式な依存関係を確立するために使用されます。 アクティビティが完全に完了する前に、発信リンクで最初に確立された要件が満たされていることを確認する必要があります。 同様に、リンクされたアクティビティを開始する前に、受信リンクに含まれる要件を最初に満たす必要があります。 リンクによって提供されるルールは、同期依存関係とも呼ばれます。
6.6.5. オーケストレーションとアクティビティ
前に定義したように、アクティビティとは、サービス指向ソリューションによって完了される任意の論理作業単位に適用できる一般的な用語です。 したがって、単一のオーケストレーションの範囲は、複雑で、最も可能性の高い長時間実行されるアクティビティに分類できます。
6.6.6. オーケストレーションと調整
オーケストレーションは、WS-BUSINESSACTIVITY調整タイプを組み込むことにより、WS-Coordinationコンテキスト管理フレームワークを完全に利用できます。 この仕様は、複雑で長期的な活動をサポートするように設計された調整プロトコルを定義します。
6.6.7. オーケストレーションとSOA
ビジネスプロセスロジックは、自動化ソリューションのルートにあります。 オーケストレーションは、プロセスロジックが集中化されていても拡張可能で構成可能な自動化モデルを提供します(図6.35)。 オーケストレーションを使用することにより、サービス指向のソリューション環境は本質的に拡張可能で適応的になります。 オーケストレーション自体は、通常、他のアプリケーションの統合の共通点を確立し、実装されたオーケストレーションを主要な統合イネーブラーにします。
図6.35. SOAの他の部分に関連するオーケストレーション。
これらの資質は、組織の俊敏性の向上につながります。:
- オーケストレーションによってカプセル化されたワークフローロジックは、中央の場所で変更または拡張できます。
- オーケストレーションを一元的に配置することで、対応する自動化ソリューションを結びつける接着剤を抽象化することにより、ビジネスプロセスのマージを大幅に容易にすることができます。
- 潜在的に大規模なサービス指向の統合アーキテクチャを確立することにより、オーケストレーションは、基本的なレベルで、多様な統合企業の進化をサポー
オーケストレーションは、異種のコンピューティングプラットフォームに基づくさまざまなアプリケーションを含む組織内のフェデレーション状態を達成するための重要な要素です。 ミドルウェアの進歩により、オーケストレーションエンジン自体がサービス指向環境に完全に統合されます。
サービス指向オーケストレーションの概念は、この章でこれまでに説明したすべての概念を完全に活用しています。 多くの環境では、オーケストレーションがSOAの中心になります。
ケーススタディ
前のケーススタディの例でビジネスアクティビティにラップした一連のステップは、TLSがWS-BusinessActivityプロトコルを使用して、長時間実行され ビジネス活動の範囲はビジネスプロセスを構成することができますが、基盤となるワークフローロジックを表現する標準的な手段をTLSに提供しません。 そのために、TLSはWS-BPELオーケストレーションを採用しています(図6.36)。
図6.36。 オーケストレーションによって管理され、多数の潜在的なパートナー組織が関与する拡張TLS発注書の送信プロセス。
オーケストレーションは、ビジネス活動を包含する包括的なプロセスロジックを確立し、複数のベンダーサービスとの追加の対話シナリオを管理するため たとえば、ある仕入先が注文を履行できない場合、行内の次の仕入先に同じ発注書が送信されます。 このサイクルは、いずれかの仕入先が注文全体を完了するまで(特定の価格制限内)、またはすべての仕入先が照会されるまで繰り返されます。 後者の状況では、システムは、価格、充填される注文の割合、およびバックオーダー条件を考慮した式を適用することによって、テーブル上で最良の取引を
オーケストレーションロジックは、複数のベンダーパートナーサービスの関与や、POが処理されるときに開始されるビジネス活動など、プロセスのすべての側面
キーポイントの概要
- オーケストレーションは、通常、単一の組織が所有するビジネスプロセスロジックの本体を表します。
- オーケストレーションは、ビジネスプロセス定義を正式に定義するビジネスプロトコルを確立します。
- オーケストレーション内のワークフローロジックは、シーケンスとフローに編成できる一連の基本的かつ構造化されたアクティビティに分類されます。
- オーケストレーションは、標準化されたサービスモデルを通じて大量のアプリケーション間およびアプリケーション内ロジックを一元化して制御する手段を確立するため、”SOAの心臓部”と呼ばれてきた。