|
|
WLI アプリケーションの作成と開発に関して、いつくかのベスト プラクティスがあります。これらについて、以下の節で説明します。
この節の詳細については、『
ビジネス プロセス構築ガイド』および
WebLogic Integration コントロールを使用するを参照してください。
WLI アプリケーションを開発する際には、均一かつ一貫性のある命名標準に従ってさまざまな WLI アーティファクト (JPD、タスク プラン、コントロール、プロジェクト、ファイルなど) に名前を付ける必要があります。すべてのコントロール、プロセス、メソッド、変数、およびその他の WLI オブジェクト名は、標準のオブジェクト指向標準と Java 名前付け標準に従う必要があります。
WLI バージョン 9.2 では、JPD ファイル、コントロール ファイル、およびデータ トランスフォーメーション ファイルは共通の拡張子 .java を持ちます。各アーティファクトには、容易に識別できるようにサフィックスを追加する必要があります。表 4-1 は、各アーティファクトのネーミング コントロールの例および関連するサフィックスを示します。
大規模プロセスを定義する必要がある場合は、モジュール化することを常にお勧めします。モジュール JPD は、特定のビジネス目標を満たします。モジュール JPD の例は、以下のとおりです。
大規模な JPD は、複数の小規模な JPD またはサブプロセスに分割できます。サブプロセスは、中央またはメインの JPD を使用して呼び出すことができます。プロセス コントロールを使用すると、JPD とサブプロセス (別の JPD) 間で通信できます。メッセージ ブローカまたはパブリッシュ アンド サブスクライブ アーキテクチャを使用して 2 つの JPD を疎結合することもできます。詳細については、「JPD 間の通信」および「JPD のコア実装パターン」を参照してください。
すべての JPD は、開始ノードを持ち、XML ドキュメントを使用して開始されます。パフォーマンスを向上するため、XML ドキュメントはモジュール化し、小さくしてください。ドキュメントのタイプごとに別の XSD を作成することをお勧めします。たとえば、発注書と請求書の両方に 1 つの大規模なスキーマを配置する代わりに、発注書と請求書に個別の XSD を配置します。
JPD および関連ドキュメントのモジュール化は、相対的な概念です。JPD をモジュール化しすぎると、生産性が低下する可能性があります。特定のシナリオに基づいて、バランスのとれたモジュールの決定を行う必要があります。
JPD では、パラレル ノードを使用できます。このノードを使用する前に、このノードのしくみを理解しておくことをお勧めします。パラレル ノードは、関連しているが依存していない複数のタスクを管理するために使用できます。パラレル ノードは、ビジネス レベルの並列処理を目的としています。ただし、実際のタスクは並列処理で実行されません。
タスクは、他のブランチで実行されていない場合に、1 つのブランチでいつでも開始できます。たとえば、タスクを実行しているブランチがパートナに見積りを要求し、応答を待つ場合があります。このブランチが応答を待っている間に、別のブランチがタスクを開始した場合、ビジネス レベルの並行処理が実現されたと言えます。
パラレル ノードには、AND モードと OR モードという 2 つの形式があります。AND モードでは、すべてのパラレル パスの実行が完了している場合にビジネス プロセスが続行されます。OR モードでは、最初に処理を完了したパスが処理を取得します。ビジネス プロセスは、他のパスの処理が停止してから続行されます。
パラレル ノードのブランチは、トランザクションによって分離されています (デフォルトの動作)。パラレル ノードのパフォーマンスを向上するために、この操作を無効にすることもできます。その場合は、次のように、各パラレル要素のソースで、continueTransaction プロパティを true に設定します。
<parallel continueTransaction="true">
JPD の例外および例外ハンドラは、ノード、グループ、プロセスの各レベルで定義できます。例外ハンドラは、以下の順序で実行します。
プロセス レベルでは、プロセス レベルの例外ハンドラ catch all を使用することをお勧めします。
処理されていない例外によって、プロセス エラーが発生する可能性があります。このシナリオを回避するには、freezeOnfailure プロパティを設定します。このプロパティを設定している場合、処理されていない例外があると、プロセスが停止します。この後、プロセスは最後にコミットされたポイントにロールバックされます。これにより、管理者は、最後にコミットされた状態からプロセスを再開できます。
表 4-2 に、JPD の例外を操作する際に従う必要がある設計ガイドラインの概要を示します。
イベント ハンドラを使用すると、外部のイベントは、OnMessage および OnTimeout イベント ハンドラを使用してプロセスに割り込むことができます。OnMessage イベント ハンドラは、クライアント要求を受け取ることができます。タイマー イベントが発生すると、コントロール、受信、およびメッセージ ブローカ サブスクリプションの各メッセージ イベントが呼び出されます。
図 4-1 に、OnMessage および OnTimeout イベント ハンドラの例を示します。
以下の節では、さまざまな JPD トランザクションと補償管理に関するベスト プラクティスについて説明します。
WLI のプロセスは、本質的にはトランザクションです。1 つのプロセスのすべての手順は、Java トランザクション API (JTA) トランザクションのコンテキストの中で実行されます。プロセスを構築すると、「コントロール受信」や「クライアント送信」などのブロック要素の位置に基づいて、暗黙的なトランザクション境界が形成されます。プロセス内のトランザクション境界は、プロセス ノードを追加するたびに変化します。
明示的なトランザクション境界を作成することもできます。これを行うには、連続するノードを選択し、アプリケーションによって作成された暗黙的なノードとは別のトランザクション内でトランザクションを宣言します。リソースの性質やアクセスを提供するコントロールによっては、プロセスによってアクセスされるリソースをトランザクションに含めることもできます。
ステートレス プロセスは、クライアント トランザクション内、または新しいトランザクションの開始時に実行されます。Java クライアントは、JPD プロキシを使用して RMI 上で JPD を呼び出すことができます。このシナリオでは、クライアント トランザクションは JPD に伝播されます。Web サービスとして JPD が呼び出されると、呼び出し側のトランザクションは伝播されません。非同期プロセスの場合も、呼び出し側のトランザクションは JPD に伝播されません。
トランザクション コントロールには、以下の 3 つのタイプがあります。
プロセス内で使用されているすべてのコントロールが XA 準拠のトランザクションである場合は、そのプロセスのトランザクションを使用して、基底のトランザクションのブランチをコミットまたは終了できます。このプロセスには、問題を捕捉し、トランザクションに関する必要な決定を行うための例外ハンドラが必要になります。開発者はトランザクションが開始された位置を認識している必要があります。それは、中止またはロールバックによって制御が開始ポイントに戻され、例外が発生したプロセス内にそのポイントが存在しない可能性があるからです。
XA は、分散トランザクションを管理するために使用するプロトコルです。WLI では、非 XA リソースが分散トランザクションに参加できるように XA が拡張されています。ただし、特定のトランザクションに参加できる非 XA 準拠のトランザクション リソースは 1 つに制限されています。このため、プロセス内で複数の非 XA トランザクション リソースにアクセスする必要がある場合は、それらのリソースへのアクセスを個別の JPD サブプロセスにカプセル化して、元のプロセスから非同期的に呼び出す必要があります。非同期呼び出しが必要になるのは、同期的に呼び出されたサブプロセスが呼び出し側のプロセスと同じトランザクションで実行されるためです。詳細については、『
Integration コントロールを使用する』を参照してください。
電子メール コントロールなどの非トランザクション コントロールは、トランザクションをサポートしていません。非トランザクション コントロールでは、例外処理のための方法が必要になります。トランザクション コントロールの場合は、自動ロールバックを使用します。ビジネスの問題に基づいたエラーを非トランザクション コントロールで処理するには、捕捉した例外を使用します。
JPD は、ACID (原子性 (Atomicity)、一貫性 (Consistency)、独立性 (Isolation)、および持続性 (Durability)) トランザクションと XA トランザクションのサポートを提供するだけでなく、補償のサポートも提供します。補償機能を使用するには、補償を提供する対象のトランザクション ブロックが rollback only としてマークされていないことを確認する必要があります。次に、そのトランザクション ブロックの例外ハンドラ パスを定義し、例外ハンドラ execute on rollback を適切に有効にします。これにより、トランザクションが失敗した場合に、まず例外ハンドラ パスが実行されるようになります。このパスには、元に戻すロジックや補償ロジックを定義できます。図 4-2 に、非トランザクション コントロールの例を示します。
表 4-3 は、JPD のトランザクション特性を決定するためのガイドラインの概要を示します。
ステートレス JPD は、メモリ内でのみ実行されるプロセスです。この状態に永続性はありません。すべてのステートレス プロセスは、ステートレス セッション Bean にコンパイルされます。ステートレス プロセスの目的は、短期間実行するロジックを呼び出すビジネスのシナリオをサポートすることにあるため、高いパフォーマンスが要求されます。
JPD は状態をデータベースに永続化しないため、小さいレイテンシと高いパフォーマンスで実行するために最適化されます。
表 4-4 に、ステートレス プロセスを使用する際に従う必要があるガイドラインの概要を示します。
ステートフル プロセスは、複数のトランザクションのスコープ内で実行されるプロセスです。このプロセスは、その状態をデータベース内に永続化します。JPD の状態は、サーバがクラッシュした場合でも存続します。ステートフル JPD プロセスは、エンティティ Bean にコンパイルされます。ステートフル プロセスは、複雑な、長時間実行されるロジックを含むビジネス シナリオをサポートすることを目的としています。
ステートフル プロセスは、一般に、ステートレス プロセスよりも低速です。ステートレス プロセスは、特に状態を永続化する必要のないシナリオで使用します。状況によっては、ステートフル プロセスを複数のステートレス プロセスに分割できます。図 4-3 に、ステートフル プロセスをステートレス プロセスに分割する方法を示します。
WLI のバージョニング機能を使用すると、現在実行中のプロセスのインスタンスを中断することなくビジネス プロセスに変更を加えることができます。ビジネス プロセスのバージョンを作成する場合、実際には、親のビジネス プロセスと同じパブリック インタフェースを共有するビジネス プロセスの子バージョンを作成します。アクティブとしてマークされているプロセスのバージョンは、実行時に、外部クライアントがパブリック URI を使用してアクセスするプロセスです。定期的な開発サイクルを通して、新しいプロセス バージョンがアプリケーションの新バージョンと共にデプロイされます。
JPD の新バージョンをデプロイすると、既存のインスタンスは、開始したときと同じバージョンの JPD で最後まで実行されます。ビジネス プロセスはバージョニングできますが、当該プロセス、またはスキーマやトランスフォーメーションなど、その他のビジネス プロセス関連のコンポーネントに関連付けられた個別のコントロールはバージョニングできません。ビジネス プロセスをバージョニングする場合は、そのプロセスのサブプロセスもバージョニングする必要があります。それは、親プロセスをバージョニングしても、自動的にサブプロセスにバージョンが割り当てられないからです。
表 4-5 に、JPD のバージョンを設定する際に従う必要があるガイドラインの概要を示します。
JPD は、2 つの方法 (静的または動的) でメッセージ ブローカ チャネルをサブスクライブできます。
プロセスが開始ノードのチャネルをサブスクライブする場合、そのサブスクリプションは静的サブスクリプションと呼ばれます。このサブスクリプションは、アプリケーションがコンパイルされるときに認識され、そのアプリケーションの有効期間にわたって保持されます。
メッセージ ブローカ コントロールを使用して、プロセスがフロー中にメッセージ ブローカ チャネルをサブスクライブする場合、そのサブスクリプションは動的サブスクリプションと呼ばれます。このサブスクリプションは、実行時に開始されて終了します。メッセージ ブローカ チャネルの静的サブスクリプションは、ビジネス プロセスでサブスクリプションの suppressible 属性を設定することで「抑制可能なもの」として指定できます。suppressible 属性に指定できる値は、true および false (デフォルト値は false) です。
シングルトン JPD は、常時実行される JPD のインスタンスを 1 つだけ持ちます。シングルトン JPD を作成するには、まず静的サブスクリプションを使用して JPD を定義し、suppressible 属性を True に設定します。これにより、チャネルの最初のメッセージによって JPD が呼び出され、JPD のインスタンスが 1 つ作成されます。静的チャネルの後続のメッセージでは、新しい JPD インスタンスは作成されません。この方法で作成したシングルトン JPD は、動的サブスクリプションを使用してメッセージの受信を続行できます。
競合状態は、動的サブスクリプションでメッセージ ブローカを使用すると発生する可能性があります。競合が発生すると、サブスクリプションが完了する前に送信されたメッセージは失われます。この問題は、メッセージがデッド レター チャネルに表示され、プロセスが無期限に応答を待機し始めることで明らかになります。
要求メッセージがトランザクションでない場合 (たとえば、Web サービスの呼び出しの場合)、メッセージはすぐに送信されますが、応答のサブスクリプションは、トランザクションがコミットされた場合にのみ行われます。プロセス フローで、メッセージ送信の前にサブスクリプションが記述されている場合は、サブスクリプションが遅れて発生する可能性があります。その場合は、サブスクリプション ノードの後の要求メッセージ送信の前にトランザクションをコミットする (たとえば、空の明示的トランザクションを追加する) ように記述します。
フィルタ処理の完了後に、サブスクライバのないチャネルにメッセージが送信されると、そのメッセージはデッド レター チャネルに転送されます。ほとんどの場合、これは意図された動作でないため、デッド レター チャネルをサブスクライブして、メッセージがそこにパブリッシュされていないかどうかを確認してください。
サービスの品質である at-least-once または once-only を実装するには、特別な手順に従う必要があります。従わなかった場合のデフォルト値は、at-least-once です。プロセス タイプごとの手順は、以下のとおりです。
| 注意 : | すべてのコンピュータ プログラムを正常に完了できるわけではありませんが、高いサービス品質を使用すると、必ずエラーから回復できます。 |
サービス レベル アグリーメント (SLA) では、JPD の目標のパフォーマンスを指定します。内部または外部の取り決めにより、JPD が指定期間内に実行されることが示されます。プロセスの SLA を指定するには、WLI Administration Console で以下のしきい値を設定します (図 4-4)。
これらのしきい値に関連するプロセスのステータスは、プロセス インスタンスごとに以下の方法で追跡します。
プロセス インスタンスの経過時間が警告しきい値に達すると、[プロセス インスタンス概要] ページおよび [プロセス インスタンス詳細] ページに警告が表示されます。SLA しきい値に達するまでの時間も表示されます。経過時間が SLA を超えると、赤いフラグが表示されます。SLA しきい値を超えた時間制限も表示されます。SLA しきい値を設定すると、目的の時間内に実行されないプロセスを簡単に確認できます。これにより、サプライヤとカスタマ間の取り決め、あるいは独自のパフォーマンスの目標に合わせて必要な変更を加えることができます。
プロセスは、さまざまなレベルで追跡できます。システムにはデフォルトのトラッキング レベルが含まれ、これを各プロセスでオーバーライドできます。WLI Administration Console および基底の MBean には、実行中のインスタンスおよびその変数値のモニタ インタフェースが用意されています。変数値は変更できませんが、インスタンス ID またはプロセス ラベルを使用してプロセスをクエリできます。JPD コンテキストである setProcessLabel を呼び出すことにより、インスタンス内にプロセス ラベルを設定できます。表 4-6 に、JPD をモニタするための設計ガイドラインの概要を示します。
JPD のセキュリティ ポリシーを定義できます。セキュリティ ポリシーは、JPD で外部システムまたはバックエンド システムにアクセスするときに使用する ID を制御します。JPD は、起動アプリケーションまたは後からプロセスを呼び出すアプリケーションとして外部システムにアクセスします。このポリシーにより、どちらのアプリケーションとして外部システムにアクセスするかを管理者がコンフィグレーションできます。たとえば、プロセスがチャネルをサブスクライブし、クライアント要求を待機する場合、管理者は、実行ポリシーを設定し、バックエンド リソースにアクセスしているときにクライアント要求の ID を使用できます。
JPD のセキュリティ ポリシーには、次の 4 つの主要コンポーネントがあります。
JPD は、Java Web サービス (JWS) として公開できます。相互運用可能な JPD の開発に関して、次のような制限があります。
図 4-5 に、相互運用性の制限を考慮した推奨アーキテクチャを示します。
WLI アプリケーションには、相互に通信する複数の JPD が含まれます。他の JPD によって呼び出される JPD は、サブプロセスと呼ばれます。表 4-7 に、JPD 間の通信に関するガイドラインの概要を示します。
コントロールは、JPD に不可欠な部分です。WLI 9.2 コントロールは、オープンな Apache Beehive 標準に基づいています。この標準は、JSR-175 標準ベースのアノテーションをサポートしています。コントロールは、再利用可能であり、エンタープライズ リソースに簡単にアクセスできるようになっています。コントロールは、バックエンド システムを呼び出すためにプロセス定義内で使用できます。たとえば、データベース コントロールにより、プロセスは JDBC 接続プールを使用して RDBMS に SQL を送信できます。表 4-8 に、コントロールの使用に関するガイドラインの概要を示します。
多くの場合、コントロール属性はアノテーションを使用して静的に定義されます。ただし、一部のコントロールは、属性を動的に変更する Java API を備えています。サービス ブローカ コントロールやプロセス コントロールなどの動的コントロールは、コントロール属性を動的に設定する機能を備えています。動的バインディング プロセスや遅延バインディング プロセスは、ルックアップ ルールと値の組み合わせを使用して、実行時に属性を決定する場合に使用します。動的バインディングをサポートするコントロールを「動的コントロール」と呼びます。
ルックアップ ルールは設計時に定義します。ルックアップ値は、実行時の変更別に、DynamicProperties.XML ファイルに定義できます。このファイルは、ドメイン内のすべての WLI アプリケーションで共有されるドメイン全体のファイルです。この機能を使用すると、コントロール属性をアプリケーションから完全に切り離すことができます。このファイルは、アプリケーションの実行中に再コンフィグレーションできるため、変更内容を有効にするためにアプリケーションを再デプロイする必要がありません。
プロパティの動的バインディングを確立するには、以下のものを使用します。
現在のプロパティ設定を取得するには、getProperties() メソッドを使用します。
Web サービス コントロールをビジネス プロセスから非同期的に呼び出す場合は、非同期呼び出しをバッファリングして、ビジネス プロセスから Web サービスに送信されたメッセージがキューに追加されていることを確認することをお勧めします。リソースに対する非同期呼び出しは、ビジネス プロセス内のトランザクションの境界を示します。リソースに対する呼び出しは、トランザクションがコミットされるまでキューに追加されません。
リソースに対する呼び出しをバッファリングすることで、トランザクションは、リソースから応答がある前にコミットされます。呼び出しをバッファリングしない場合、ビジネス プロセスは、トランザクションがコミットされるまでHTTP 確認応答を待機する必要があります。この場合は、HTTP 確認応答の前にリソースがビジネス プロセスへの応答を試行する可能性があります。
コントロールのコントロール ファクトリ機能を使用すると、JPD は、同じ JPD の複数のインスタンスと対話できます。ファイル、電子メール、WLI JMS、トレーディング パートナ管理、サービス、およびワークリストの各コントロールは、コントロール ファクトリとして実装できます。たとえば、融資申し込みなどのドキュメントを複数のサービス プロバイダに送信する必要がある場合、JPD は、コントロール ファクトリを使用して複数のサービス コントロール インスタンスを作成し、それらのサービス コントロール インスタンスに対する要求を平行してディスパッチできます。コントロールでコールバックを使用している場合は、呼び出し側のJPD の単一のパラメータ化されたコールバック ハンドラにより、すべてのコントロール インスタンスから受け取ったコールバックを管理できます。
データ トランスフォーメーションおよび操作は、ビジネス プロセスの不可欠な部分です。サービス コンシューマとサービス プロバイダには、さまざまなデータ フォーマットおよびデータ タイプが必要になります。WLI には、データ トランスフォーメーション用に以下のツールが用意されています。
| 注意 : | WLI 9.2 は、WLI 8.1 との下位互換性の維持を目的として XQuery 2002 のランタイム実行をサポートしています。 |
アプリケーションの標準データ モデルを作成することをお勧めします。標準データ モデルは、承認済みの標準形式にデータをマップします。このようなデータ モデルを正しく実装すると、エンタープライズ情報システム （EIS） の中立インタフェースを持つサービスが提供されます。標準データ モデルは、ホストのデータ モデルと受信者のデータ モデルを切り離して、EIS データ フォーマットの参照データ、静的データ、および識別子データを標準フォーマットにマップする方法を指定します。最初にサービス インタフェースの標準を作成すると、その標準によって、エンタープライズ内にデータ タイプとエンティティの共通表現が適用されます。日付、数字、郵便番号、および住所を表す一貫性のある方法を保持する必要があります。
動的トランスフォーメーション コントロールを使用すると、ビジネス プロセスで実行時にトランスフォーメーションを動的に選択して、実行できます。つまり、実行時に呼び出される XQuery、XSLT、または MFL ファイルを選択できます。たとえば、さまざまな支社からドキュメントを受信する統合ハブがある場合、動的トランスフォーメーション コントロールを使用すると、各支社の市外局番に基づいてさまざまなトランスフォーメーションを実行することができます。表 4-9 に、データ トランスフォーメーションに関する設計ガイドラインの概要を示します。
WLI 9.2 のワークリストには、以下のような拡張機能があります。
タスク プランを使用して、JPD の例外を管理できます。ユーザは、例外が発生したときに呼び出されるタスク プランを使用できます。
カスタム ロジックをタスク プランと統合するには、タスク プラン イベント サービスを使用します。
タスク プラン イベントをサブスクライブするには、独自のカスタム イベント リスナを作成して、タスク プランに登録します。カスタム コードは、リスナ クラスに記述できます。このカスタム コードは、タスクに関連付けられた各イベント リスナがタスク プラン イベントによって呼び出されると実行されます。
カスタム ロジックでカスタム割り当てハンドラを使用すると、デフォルトのタスク割り当てを実行時に変更できます。
詳細については、『Worklist の使い方』を参照してください。
|
