Topics
Service-Oriented Architecture
| Mastering SOA |
|
第3部：エンドツーエンドのプロセスへのオーケストレーションJoan Lawson、Dave Shaffer著
エンドツーエンドのビジネス・フローへのサービスのオーケストレーション を実行する機動性のある標準のビジネス・プロセスを構築します。
2007年2月公開 このシリーズの以前のステップでは、バックエンド・アプリケーションのサービスに対応してエンタープライズ・サービス・バス（ESB）でそれらの サービスを公開する、最新の標準およびアーキテクチャ・アプローチの活用方法を説明しました。 ただし、アクセスするクライアントおよびビジネス・プロセスのコンテキストでのみ、それらのすべてのサービスは有効になります。 このステップでは、エンド・ツー・エンドのビジネス・フローに対して、こうしたサービスのオーケストレーションを実行する、機動性をもった標準のビジネ ス・プロセスを構築する方法を中心に説明します。 ビジネス・プロセスは、ビジネス機能を実装するために必要な一連の手順です。 ビジネス・プロセスには、企業内および企業の境界を超えたシステムまたは手動による作業、あるいはその両方が含まれる場合があります。 整合性や規制のためだけにビジネス・プロセスを記述する企業もあります。 ただし、過去数年間で、ITシステムを使用したビジネス・プロセスの実行および監視を自動化する組織の数が増加しています。 ビジネス・プロセス管理（BPM）の採用が加速している重要な要素の1つは、ビジネス・プロセスを実装および実行するWS-BPELなどの幅広く受け入れ られる標準が出現したことであると考えられています。
図1注文処理のBPELプロセスの例
"Mastering SOA"のこのステップでは、これらの標準を使用してビジネス・プロセス・オーケストレーションの課題を解決する方法を説明します。本番環境で正常に動作 したOracle Enterprise Service BusおよびOracle BPEL Process Managerのサービス指向アーキテクチャ（SOA）のいくつかの実装とともに、オラクルのベンダーやMonster Worldwideの経験が組み込まれています。 Monster WorldwideMonster Worldwideは、SOAおよびBPELによって顧客のローカル・ビジネス要件を満たす一方で、グローバルな機動性と拡張性が提供されるので、 BPELは重要な標準になりえると判断しました。 また、いくつかのIT企業がサポートする標準化委員会によってBPELが推進されています。このため、独自の統合プラットフォームの選択によるベンダー強 制のリスクが最小限に抑えられます。 Monster Worldwideのアプリケーションが増加するにつれて、WebサービスやSOAを使用したこれらのアプリケーションを相互につなぐ必要があります。 SOAP、WSDL、XMLスキーマなどのWebサービス標準を活用する標準形式でインタフェースを既存のシステムに公開し、サービスを公開します。 Monster Worldwideは、エンドツーエンドのプロセス・フローに対して、こうしたサービスのオーケストレーションを実行します。 BPELは、このようなオーケストレーションの業界標準です。 ここでは、ほかのOracleユーザーのSOA実装から取得したヒントやコツとともに、Monster WorldwideによるSOAおよびBPELの実装方法の例を確認します。 また、BPEL標準の機能、SOA領域のほかの標準との適合方法、およびOracle SOA Suiteによるこれらの標準を実装するインフラストラクチャの構築方法を学習します。 BPELの基本BPELは、Webサービスに基づいたビジネス・プロセスの動作を指定するXMLベースの言語を定義します。 IBMのWebServices Flow Language（WSFL）およびMicrosoftのXLANG仕様を統合したBPEL4WSバージョン1.0として、最初に公開されたBPELの仕 様が2002年7月にリリースされました。 そして、多くの業界ベンダーとの連携によって、バージョン1.1が2003年にリリースされました。WS-BPEL標準のバージョン2.0は、2007年 初期にOASIS標準化団体からリリースされる予定です。 BPEL標準によって、以前には取得できなかった相互運用性と移植性が組織のビジネス・プロセスで実現します。 相互運用性によって、さまざまなビジネス・プロセス・エンジンで動作するビジネス・プロセスが実現し、多くのベンダーとオープンソースのプラットフォーム から公開されたサービスと相互に作用します。 これは、SOAP、UDDI、WS-Addressing、WSDL、XML、XMLスキーマなどの低いレベルのWebサービス・スタックの上にBPEL 層が存在するので可能です。 ビジネス・プロセス領域の相互運用性は数年間維持できます。ただし、BPELおよびWebサービス標準によってその次のレベルに移行されます。 相互運用性以上に、ビジネス・プロセスの移植性は、まったく新しい概念です。 BPELが提供するプロセスの移植性によって、サポートされた標準準拠のシステムで実行されるツールを使用して、ビジネス・プロセスを定義できます。 現在、小規模のニッチ・ベンダーおよびオープンソース企業と同様に、オラクルやIBMなどの大規模のプラットフォーム・ベンダーもBPELエンジンを使用 できます。 コレオグラフィおよびオーケストレーションビジネス・プロセスのランタイム・ライフ・サイクルを実装するため、さまざまなアクティビティが実行されます。 BPELは、プロセス・コレオグラフィとは異なるWebサービス・オーケストレーション言語です。 IT分野で一般に使用される用語としてのプロセス・コレオグラフィとは、複数の組織のビジネス機能を実装するさまざまな取引先パートナーの相互作用を示し ます。 たとえば、サプライ・チェーン領域の製品購入のフルフィルメントには、購買注文、事前の出荷通知、および2つ以上の企業間の費用の交換が含まれる場合があ ります。 コレオグラフィは、企業ごとの処理の実行方法を説明しません。異なる企業同士で整合を取る方法だけを説明します。 プロセス・オーケストレーションでは、一元化されたプロセスが異なるWebサービス操作を調整します。 中央のコンダクターは、オーケストレーション全体の目標、含まれる操作、および操作の呼出しの順序を認識します。 この一元管理によって、それぞれがほかのサービスへの影響を認識しなくてもWebサービスを追加または削除できます。また、障害や例外が発生した場合に補 正プロセスを実装できます。 プロセス・オーケストレーションとプロセス・コレオグラフィは、サービスのインタフェースとインタラクションを示す点だけが似ていま す。 この問題を取り上げるために、プロセス・オーケストレーションを中心に説明します。 オーケストレーションにBPELを使用する場合、BPEL言語は、操作全体の順序の制御、サービスの呼出し、およびBPELサーバーの実行に使用される標 準を提供します。 Monster Worldwideでのもっとも複雑な統合作業の1つは、注文から請求（Oracle Siebel Customer Relationship ManagementからOracle E-Business Suite）まででした。 2つのメッセージへの元の注文メッセージ（注文データと顧客データで構成されたSiebel生成オブジェクト）の分割、2つのメッセージのデータ変換、お よびOracle E-Business Suiteへのメッセージ送信前の注文データの大幅な強化で要件が構成されました。 また、顧客注文の送信前にOracle E-Business Suiteの顧客プロファイルを作成する必要がありました。 一連のBPELプロセスが構築され、これらの手順が調整されました。 Siebel注文オブジェクトを受信すると、最初のサービスがオブジェクトを2つのメッセージ（顧客と注文）に分割します。 オーケストレーションは、注文データと顧客データを並行して拡張します。 注文データが変換されると、全体の注文データを拡張するサービスに渡されます。 完了すると、オーケストレーションは、顧客メッセージをOracle E-Business Suiteに渡して、注文メッセージを渡す前に正常なレスポンスを待機します。 このオーケストレーションによって、予期された順序ですべてのアクティビティが実行されることがMonsterに対して保証されます。また、プロセス中に 障害が発生した場合に適切な補正がおこなわれることが保証されます。 BPELフレームワークBPELは、Webサービス・コンポーネントを使用して複雑なビジネス・プロセスを開発できる強力な言語です。 BPELプロセスを使用して、呼び出されるWebサービスとその順序を指定できます。 BPELサーバーは、トランザクションに含まれるビジネス・プロセスを追跡し、正しい順序で手順が実行されることを保証して、トランザクション、補正、お よび例外を管理します。 BPELは、オーケストレーション言語から予測されるすべての制御フロー構造（ループと条件文、変数、データ値の割当て、障害ハンドラ の定義など）をサポートします。 BPEL receiveアクティビティを使用し、サービス・インタフェースを通じて最初にクライアントが呼び出す場合に、ビジネス・プロセスのインスタンスを作成 するイベントまたはメッセージを定義します。 このプロセスは、定義されたビジネス・プロセスの順序のアクティビティであるほかのサービスを呼び出します。 通常、レスポンスが生成されます（リプライ）。 途中で、BPELプロセスによるデータ変数の操作（割当て）、障害および例外の処理（スロー）、または一定期間の待機が必要になる場合 があります。 いつでもプロセスを完了（終了）できます。 要素変数は、プロセスの説明全体で使用されるすべてのメッセージおよびデータを定義します。 含まれているサービスに送信されるメッセージやそれらのサービスから受信するメッセージごとに変数が使用されます。 プログラミング言語と同じように、変数を使用してプロセス実行データを処理します。 構造アクティビティには、順番にアクティビティを実行するBPELオーケストレーション（シーケンス）または並行してアクティビティを 実行するBPELオーケストレーション（フロー）が含まれる場合があります。 BPELのもっとも重要な制御フロー・アクティビティは、次のとおりです。
BPELでは、条件処理に基づくビジネス・プロセスの実行を定義できます。 たとえば、北アメリカ、ヨーロッパ、アジア太平洋の地域にMonsterが分割されます。 注文元の地域に基づいて、BPELプロセスは、地域固有のロジックを実行します。 同様に、Monsterは、注文から請求までのBPELフローを定義し、注文サービスを順番に処理しながら顧客および注文を並行して処 理します。 BPELプロセスは、プロセスとやり取りをおこなうパーティのインタフェースを定義するサービス（パートナー・リンク）のオーケスト レーションを実行します。 このようなパートナー・リンクには、BPELプロセスによって呼び出される両方のサービスと、クライアントがBPELプロセス自体を呼び出すインタフェー スがそれぞれ含まれます。 物理的なサービス・エンドポイントへのBPELプロセスの柔軟なバインディングが、設計、配置、または実行時に実行できます。 上記のサービスでは、SiebelおよびOracle E-Business Suiteアダプタが主要なパートナー・リンクとなります。 BPELには、非同期イベントの豊富なサポートがあります。 BPELプロセスでは、クライアントからのメッセージ（リクエスト）の受信を常に待機できます（新しいプロセス・インスタンスの起動に使用されるアクティ ビティと同じBPEL receiveアクティビティ）。 BPELエンジンは、メッセージを受信するまでプロセスの状態を維持し、標準のWS-Addressingまたはカスタム相関メカニズムを通じて、プロセ スの特定のインスタンスにメッセージを関連づけるオーバーヘッドを処理します。 BPELプロセス自体で、同期または非同期のインタフェースをクライアントに公開できます。 同期BPELプロセス操作は、プロセスがクライアントにレスポンスを返すまでクライアントをブロックします。 非同期BPELインタフェースは、一方向に設定できます。また、コールバックを通じてクライアントにレスポンスを返します。 一般的に、長時間実行される操作に非同期プロセスが使用され、短時間実行される操作には同期プロセスが使用されます。 Monsterでの上記の注文から請求までのプロセスは、長時間実行される非同期プロセスです。 上記のロジック以外に、Siebelへのコールバックを通じてOracle E-Business Suiteで作成された請求書の請求書番号が返されます。例外が発生した場合、例外処理プロセスにヒューマン・ワークフローが含まれます。 例外および補正処理ほとんどの場合、ビジネス・プロセスの実用的なユースケースを実装する作業（すべてが順調である場合）は、ビジネス・プロセスの設計お よび実装に関する作業のごく一部です。 想定されるすべての条件（予期しない条件の場合にも対応することが理想的）で適切な処理を実行する強力でリジリエンスのあるプロセスを構築する場合、すべ ての適切な例外処理ロジックの定義にほとんどの時間が費やされます。 プロセスの実行中に例外および障害が発生した場合、実行する処理を開発者が階層的なtry/catch形式で定義できるように、BPELには豊富な例外処 理機能があります。 ただし、例外処理以外に、追加のトランザクション動作を必要とするプロセスもあります。 短時間のフローおよびサービスの領域には、標準のトランザクション・モデルで十分です。トランザクションやロールバックの実行中に、必要に応じてリソース をロックできるXAまたはACIDトランザクション・モデルを使用します。 ただし、外部の組織がサービスを所有する可能性があり、プロセスとサービス・インタフェースの実行に数分、数時間、または数日かかる場 合があるビジネス・プロセス・オーケストレーションの領域では、新しいトランザクション・モデルが必要になります。 これらのモデルは、長時間実行されるトランザクションまたは補正トランザクションと呼ばれます。 トランザクション・コーディネーターが補正トランザクションを自動的に処理できるようにするこの領域での真の標準が待望されている一方で、補正ハンドラと 呼ばれる機能を通じてBPEL言語でこの処理がサポートされます。 補正ハンドラは、エラーが発生する前に正しく実行された作業を明示的に取り消すことができます。 必要に応じて、起動アクティビティを取り消す補正アクティビティと起動アクティビティを組み合わせることができます。 障害が発生した場合、失敗したアクティビティの範囲内ですでに完了した作業の補正ハンドラを使用し、完了した作業を取り消します。 補正ハンドラ・アプローチの短所は、プロセス設計者が各アクティビティを補正する方法を明確に検討する必要があるという点です。 長所は、BPELエンジンが実行時にすべてのアクティビティを追跡し、以前に完了した手順の補正ハンドラだけを実行できる点です。 また、元のアクティビティの完了時に、最新のデータへ補正ハンドラがアクセスできるように、BPELエンジンは実行時にデータのスナップショットを取得し ます。 このアプローチは、トランザクションを補正する明示的なサポートをサービス自体で必要としていないことを意味します。トランザクションを補正するXAや JTAなどの標準がないため、これは有効です。 BPEL 2.0BPEL 2.0は、公開されているOASIS標準としてBPEL 1.1を拡張したものです。 BPEL 2.0には、次のように重要な拡張機能があります。
BPEL 2.0以外では、BPELの拡張機能と関連する標準を確認できる領域に、ヒューマン・ワークフローとサブプロセスの明示的なサポートが含まれます。 （BPEL 2.0について、詳しくはOTNの "新しいSOA標準"シリーズの このテクニカル・ホワイト・ペーパーを参照してください。） ヒューマン・ワークフローWebサービスとしてモデル化されているサービス間のやり取りのためにBPELが設計されました。 これは、手動作業および手動のワークフロー手順に何も言及していないことを意味します。 ただし、BPELには非同期サービスの豊富なサポートがあるので、プロセスの観点からほかの非同期サービスのようにユーザーと手動の手順を表示するヒュー マン・ワークフロー・サービスを実装できます。 このアプローチの利点は、BPELプロセスが100%の標準を維持して、手動および自動のシステム・インタラクションのオーケストレーションを簡単に実行 できることです。 このアプローチは、オラクルが採用したOracle BPEL Process Managerのヒューマン・ワークフロー・サービスのアプローチです。 このアプローチによるユーザー・インタラクションは、プロセス内の手動の承認手順などの簡単なシナリオから、プロセスを続行する前に ユーザーがデータを入力する必要がある複雑なシナリオまで多岐にわたります。 現在、BPEL4Peopleと呼ばれる標準化作業が進行中です。この作業は、ヒューマン・タスクをBPELプロセスに組み込むためにこの手法を標準化す ることを目的としています。 ビジネス・ルールビジネス・ルールは、ビジネスの特定のアクションまたはポリシーを外部で説明するために抽象化する方法です。 頻繁に変化するビジネス・ロジックを、サービスやプロセス・フローに組み込むのではなく、ビジネス・ルールに外部化する開発アプローチを使用すると、企業 は、操作、定義、および制約の説明を素早く実行できます。 ルールが単一のリポジトリに一元化され、中心的なビジネス・プロセスとは別に管理されるので、企業はより効率的に変化に対応できます。 ビジネス・ルールを抽象化して機動性のニーズを満たすことができるシナリオの例を以下に示します。
Monster Worldwideは、おもにコンポーネント製品の緊密な統合から、Oracle SOA Suiteが適切なソリューションであると判断しました。 これらのコンポーネントの1つに、BPELと組み合わせて使用される場合にビジネス・ルールを区分化できるビジネス・ルール・エンジンがあります。 たとえば、販売注文の明細項目の税金を計算する場合に、Monsterでビジネス・ルールを使用します。 Monsterのルールには、仕事および履歴書を仕事検索サイトに投稿する場所を示すルールなど、ビジネス固有のルールも含まれます。 SOAのビジネス・ルール・エンジンを含む2つの主要なアーキテクチャ・アプローチがあります。 ユーティリティ・サービス・レイヤーにビジネス・ルールを実装できます。 一般的にこれらのルールが設計され、多くの場所から活用できる意思決定サービスを提供します。 また、固有の企業行動のサービスとして、ビジネス・ルールを実装できます。 ユーティリティ・サービスでもビジネス・サービスでも、統合されたプロセスの一部としてビジネス・ルールが含まれる場合、手続き型プログラミング言語で ハードコードされた場合よりもさらに柔軟に、プロセスの裏のロジックおよびフローを示すことができます。 ベスト・プラクティスとして、組織でビジネス・プロセスに適したビジネス・ルールを明確に検討し、適宜ビジネス・ルール製品を使用して、ビジネス・ユー ザー・フレンドリーな編集インタフェースでルールを定義および実行することが推奨されます。 設計パターン設計パターンは、"コンテキストにおける問題のソリューション"です。つまり、繰り返される設計の問題への高品質なソリューションを表 します。 過去数年間、ITで設計パターンが大きな注目を集めてきました。現在、サービス・オーケストレーション設計パターンが出現し始めたところです。 このようないくつかのパターンを以下に示します。 エラー・ホスピタル。このパターンは、サービスとして例外処理を提供します。 プロセスの簡潔さとパフォーマンスを最大にするため、簡単な非同期プロセスまたは短時間の同期プロセスとして、ビジネス・プロセスが設計されています。 例外が存在する場合、任意の人的サービスを含む必要な例外管理を提供するエラー・ホスピタル・プロセスにメッセージが公開されます。 多くのサービス・オーケストレーション・パターンがOracle BPEL Process Managerなどのオーケストレーション・エンジンに実装されます。
弊社の統合ミドルウェアのアーキテクチャには、Monsterが使用する多くの設計パターンがあります。
統合BPELプロセスのテスト多くのサービスのオーケストレーションをおこなう長時間実行される非同期プロセスが含まれる場合、テストが重要かつ複雑になります。 完全にプロセスをテストするには、以下の点を確認する必要があります。
結論過去数年間、BPELなどのビジネス・プロセス・オーケストレーション標準やOracle SOA Suiteなどのテクノロジー・プラットフォームの出現と発展を確認してきました。 これらの標準およびプラットフォームが採用されると、一連のベスト・プラクティスおよび設計パターンが出現し始めます。 このようなシリーズで、多くの顧客が概念と知識を共有できるようになれば幸いです。 この記事では、長時間実行されるプロセスとヒューマン・ワークフロー、信頼性の高い通信、Webサービスの使用、プロセスの永続性、補 正処理など、多くの最新のビジネス・アプリケーションで一般的な多数のビジネス・プロセス・オーケストレーション機能および要件を説明しました。 BPELやWebサービスなどの新しい標準の長所は、抽象化とプラットフォーム・インフラストラクチャです。これらの機能が本質的に提 供されるので、IT 企業による配管工事コードの書込みを削減できます。 これらのツールを活用すると、以前よりもビジネス・プロセスの自動化および監視を強力で柔軟にできます。 |
Printer View