あるメッセージを伝えるちょっとした（非常に嘘っぽい）ビジネスプロセス（以下、BP）を記述することから始めましょう。後でEDNが提供する柔軟性を実証するためにBPの要件を少し複雑にする予定です。
メッセージを構造に基づいて定義する必要があるため、XMLスキーマ定義を用いた伝統的な方法で定義することにします。
今回のBPは、Country要素でメッセージを検証します。Country要素が"US"の場合はある方法でメッセージを処理し、"UK""の場合は別の方法で処理します。Country要素の値がどちらでもない場合には、無効メッセージとして処理します。
これは非常に簡単ですが、経験豊富な開発者であれば、簡単な物事が時間をかけて複雑になっていくことをご存知かと。それゆえ、変化しないことを前提としてコードを書くよりも、我々は柔軟性、モジュール性と拡張性を考慮して構築しようと思います。
上述したように、ビジネス要件に適したこのSOAコンポジットの設計を考えてみましょう。
BPELおよびMediatorプロセスの「カバーの下」に行かなければ、EDNになじみがない読者の方々はbpValidatePerson、Mediator、bpInvalidPersonの間が接続されていないことに気付くかと思います。これはEDNは非常に単純な方法で疎結合にしているからです。お気づきになるかと思いますが、一部のコンポーネントが特定のイベントを発行もしくは読み取ることを、JDeveloperのコンポジットエディタでグラフィカルに表現しています。
このパターンを使うと、非常に簡単にMediatorやBPELプロセスの機能を記述することができます。例えばbpValidatePersonを見てみましょう。これは、メッセージを検証し実装しているビジネスルールに従ってValidPersonイベントもしくはInvalidPersonのイベントを発行します。これだけです。 - モジュール開発の基本的な側面です。ここで重要なのは、このBPELプロセスは有効なメッセージや無効なメッセージの処理方法を知る必要がないため、このプロセスには実装されていません。実際、任意のコンポーネントがサブスクライブしていないイベントを発行することは可能です。このようなイベントは、単にランタイムで破棄されます（初期開発中に特に有用ですね）。
これまでに2個のイベントサブスクライバがコンポジットにあることがわかっています。Mediatorは、ValidPersonイベントを受信して処理し、bpInvalidPersonはInvalidPersonイベントを受信および処理します。受信メッセージが有効であると仮定できる、つまりルーティングルールに適しない場合に渡すそのルーティングルールに適合しないものをDLQ（Dead Letter Queue）に「引き渡す」必要がないため、Mediatorのコーディングを簡素化できます。
では、コンポジットを拡張しましょう。壊さずにモジュラーのままにしたいと思います。しかし変更が必要になることがあります。もしくは、少なくとも追加が必要になることがあります。今必要なのは、受信した全てのメッセージが有効か無効かどうかを監査することです。伝統的なアプローチでは、例えばbpValidatePerson を変更して、データベースアダプタを追加してデータベース表にメッセージをダンプできるようにするかもしれませんが、パラダイムを壊すことを除けば、それで十分です。BPELプロセスには検証という一つの役目があると言ってきました。そして、元の設計のシンプルさを壊したくないのです。ではどうすればいいでしょうか。以下が答えです。
単に新しいBPELプロセスを追加し、そのBPELプロセスがValidPersonイベントとInvalidPersonイベントを読み取るようにすればよいのです！
これにより、何ら構成要素を変更・修正すせず、完全に疎結合/モジュール設計方式を維持したまま、コンポジットに機能を追加することができました。
原文はこちら。
http://blogs.oracle.com/ateamsoab2b/entry/event_delivery_network_edn_a
0 件のコメント:
コメントを投稿