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