WebLogic Server Process Edition の概要
|
 |
 |
|
WebLogic Server Process Edition では、そのまま使用できる一連のコントロールが提供されており、これを使用すると、リソースのポートフォリオを利用してプロジェクトの統合を開始できます。WebLogic Server Process Edition の Integration コントロールを使用すると、アプリケーションからデータベースやファイル システムなどのエンタープライズ リソースに簡単にアクセスできます。エンタープライズ JavaBean などの他の WebLogic コントロールにもアクセスできます。エンタープライズ リソースに接続する作業はコントロールによって処理されるため、開発者はビジネス プロセスのロジックに専念できます。
以下の節では、WebLogic Server Process Edition の Integration コントロール、その他の使用可能な WebLogic コントロール、非同期インタフェース、および会話について説明します。
この節では、以下の Integration コントロールについて説明します。
ファイル コントロールを使用すると、ファイル システム内でファイルの読み込みや書き込み、または追加を簡単に行えます。ファイルのタイプは次のいずれかです。
ファイル コントロールを作成するときに、指定したディレクトリに格納されているファイルに一致するファイル タイプを選択します。ファイル コントロールは、コピー、名前の変更、削除などのファイル操作をサポートしています。これらの操作は、内容全体を読み込むことなく大きなファイルを操作する場合に使用します。指定したディレクトリに格納されているファイルを一覧表示することもできます。
通常は、操作するファイルごとに個別のファイル コントロールをコンフィグレーションします。ファイル コントロールの設定はいくつかの方法で指定できます。ファイル コントロールのプロパティをデザイン ビューで設定する方法や、FileControl インタフェースの setProperties メソッドを呼び出す方法があります。ファイル コントロールのコンフィグレーション プロパティは動的に変更できます。現在のプロパティ設定を取得するには、getProperties() メソッドを使用します。
ControlContext インタフェースを使用して、実行時にコントロールのプロパティにアクセスしたり、コントロール イベントを処理したりすることもできます。コントロールを使用する開発者によって設定されたプロパティ値は、JWS、JSP、または JPD ファイルでコントロールの宣言の注釈として、または JCX ファイルでインタフェース宣言、コールバック宣言、またはメソッド宣言の注釈として格納されます。
詳細については、WebLogic Workshop ヘルプの「Integration コントロールを使用する」にある「ファイル コントロール」を参照してください。
電子メール コントロールを使用すると、WebLogic Server Process Edition ビジネス プロセスでは、特定の送り先に電子メールを送信できます。電子メール メッセージの本体には、テキスト (プレーン、HTML、または XML) または XML オブジェクトを使用できます。電子メール コントロールはカスタマイズ可能であり、電子メール送信プロパティを注釈内で指定したり、XML 変数として渡される動的なプロパティを使用したりできます。電子メール コントロールを使用して、さまざまなコンテンツ型や、本体と添付ファイルのさまざまな組み合わせを送信できます。
ビジネス プロセスに電子メール コントロールを追加する場合、既存の電子メール コントロール拡張ファイル (.jcx) を使用することも、新しく作成することもできます。
詳細については、WebLogic Workshop ヘルプの「Integration コントロールを使用する」にある「電子メール コントロール」を参照してください。
JMS (Java Message Service) は、メッセージング システムと通信するための Java API です。一般に、メッセージング システムは、メッセージ指向ミドルウェア (MOM) と呼ばれる製品としてパッケージ化されています。WebLogic Server には WebLogic JMS によるメッセージング機能が組み込まれていますが、サードパーティの MOM を使用することもできます。通常、メッセージング システムは、レガシー システムとの通信や異なる環境またはホストで実行されるビジネス コンポーネント間の通信を目的としてエンタープライズ アプリケーションで使用されます。
WLI JMS コントロールを使用すると、WebLogic Workshop ビジネス プロセスは JMS 実装を提供するメッセージング システムと簡単に対話できます。特定の WLI JMS コントロールは、メッセージング システムの個々の機能に関連付けられます。WLI JMS コントロールを定義したら、その他の WebLogic Workshop コントロールと同じようにビジネス プロセスで使用することができます。
WLI JMS コントロールは JMS コントロールの拡張版であり、RawData メッセージ タイプのサポート、動的なプロパティのコンフィグレーション、および新しいトランザクションを開始するか呼び出し側のトランザクションに留まるかを制御する機能などの追加機能を提供します。
詳細については、WebLogic Workshop ヘルプの「Integration コントロールを使用する」にある「WLI JMS コントロール」を参照してください。
サービス ブローカ コントロールを使用すると、ビジネス プロセスでは、別のビジネス プロセス、Web サービス、または Web Service Description Language (WSDL) ファイルで定義された Web サービスやビジネス プロセスとの間で、要求を送信したりコールバックを受信したりできます。サービス ブローカ コントロールでは、コントロールの属性を動的に設定できます。したがって、アプリケーションを再デプロイせずにコントロール属性を再コンフィグレーションできます。
リモートの Web サービスまたはビジネス プロセスは、Web サービスを使用してアクセスされ、WSDL ファイルに記述されます。WSDL ファイルには、Web サービスが実装するメソッドとコールバックを、メソッド名、パラメータ、および戻り値の型を含めて記述します。[アプリケーション] ペインの JPD ファイルを右クリックし、[WSDL ファイルの生成] を選択することによって、任意のビジネス プロセスについて WSDL ファイルを生成することができます。
詳細については、WebLogic Workshop ヘルプの「Integration コントロールを使用する」にある「サービス ブローカ コントロール」を参照してください。
Hyper Text Transfer Protocol (HTTP) コントロールは、WebLogic Platform コントロール アーキテクチャの機能を使用して構築されています。HTTP コントロールのソース ファイルは Jakarta Commons HTTP クライアント パッケージのラッパーです。HTTP コントロールを使用すると、WebLogic Workshop やビジネス プロセスで HTTP リクエストを処理し、特定の URL に応答を送信できます。HTTP コントロールでは、HTTP GET と HTTP POST という 2 つの HTTP モードをサポートしています。GET モードを使用すると、URL を指定してビジネス データを送信できます。POST モードを使用すると、バイナリ、XML、および文字列ドキュメントを送信できます。HTTP プロパティを注釈内に指定したり、XML 変数を介して動的なプロパティを渡したりできます。
MQSeries コントロールでは、PUT や GET などの MQSeries の基本操作を行うことができます。このコントロールを使用して、MQMD 属性の設定および取得を行います。MQSeries コントロールは、XML、バイナリ、テキストなどの複数のメッセージ ペイロード フォーマットをサポートしています。
MQSeries コントロールを使用すると、すべての GET 操作と PUT 操作に適用される MQMD プロパティを設定できます。GET メソッドと PUT メソッドでは、シグネチャの一部として xmlbean オブジェクトを使用します。xmlbean は、MQSchemas.jar にある MQMDHeaders スキーマによって表されます。
MQSeries コントロールには、次のプロパティがあります。
この節では、以下のアプリケーション コントロールについて説明します。
Java コントロールは、プラットフォーム アプリケーションの任意の場所で使用できる再使用可能コンポーネントです。WebLogic Workshop に用意されている組み込みコントロールを使用することも、独自のコントロールを作成することもできます。WebLogic Server Process Edition アプリケーションを構築する際に、Java コントロールを使用すると、リソースへのアクセスを簡単に組み込み、ロジックを効率的にカプセル化できます。
WebLogic Workshop の使用経験がある場合は、データベース コントロール、EJB コントロール、Web サービス コントロールなどの組み込み Java コントロールに関する知識を持っているでしょう。これらのコントロールは IDE に含まれていますが、独自のカスタム Java コントロールを作成することもできます。Java コントロールは、WebLogic Server Process Edition アプリケーションを構成するさまざまなコンポーネント内で使用できます。カスタム Java コントロールを使用してビジネス ロジックを実装し、ビジネス ロジックの実装時に必要に応じて組み込みコントロールを呼び出すことをお勧めします。
詳細については、WebLogic Workshop ヘルプの「Java コントロールを操作する」を参照してください。
データベース コントロールでは、アプリケーションからリレーショナル データベースに簡単にアクセスできます。データベース コントロールを使用して、データベースに対して SQL コマンドを発行できます。データベース コントロールは、データベース クエリを Java オブジェクトに自動的に変換するので、クエリの結果に簡単にアクセスできます。
データベース コントロールは、適切な Java Database Connectivity (JDBC) ドライバが使用可能で、データ ソースが WebLogic Server でコンフィグレーションされていればどのデータベースに対しても処理を行えます。新しいデータベース コントロールをアプリケーションに追加するときに、そのコントロールのデータ ソースを指定します。データ ソースは、コントロールにバインドされるデータベースを示します。
詳細については、WebLogic Workshop ヘルプの「組み込み Java コントロールを使用する」にある「データベース コントロール」を参照してください。
トランザクションとイベントによっては、完了するまでにある程度の時間が必要です。また、中止しないと無限に実行を継続して、リソースを大量に消費するトランザクションとイベントもあります。それでも、その他のトランザクションとイベントは特定の時刻に発生する必要があります。開発者はタイマー コントロールを使用して、指定した時間が経過した場合、または指定した絶対時間に達した場合に応答する方法をコードで指定できます。
タイマー コントロールは、指定した時間が経過したとき、または指定した絶対時間になったときにアプリケーションに通知します。すべてのタイマー コントロールは、com.bea.control.TimerControl 基本クラスのインスタンスです。他の多くのコントロールとは異なり、タイマー コントロールは直接 JWS ファイルで宣言します。タイマー コントロール用のサブクラスは作成しません。
詳細については、WebLogic Workshop ヘルプの「組み込み Java コントロールを使用する」にある「タイマー コントロール」を参照してください。
Web サービス コントロールを使用すると、WebLogic Workshop アプリケーションから外部 Web サービスに簡単にアクセスできます。WSDL (Web Service Definition Language) ファイルをパブリッシュするすべての Web サービスに対して Web サービス コントロールを作成できます。WSDL ファイルには、Web サービスが実装するメソッドとコールバックを、メソッド名、パラメータ、および戻り値の型を含めて記述します。Web サービスがサポートするプロトコルも記述します。
詳細については、WebLogic Workshop ヘルプの「組み込み Java コントロールを使用する」にある「Web サービス コントロール」を参照してください。
エンタープライズ JavaBean (EJB) は、エンタープライズ アプリケーションの Java ソフトウェア コンポーネントです。Java 2 Enterprise Edition (J2EE) 仕様では、EJB のタイプおよび機能と、EJB がデプロイおよび実行される環境 (コンテナ) が定義されます。ソフトウェア開発者から見ると、EJB には EJB の開発およびデプロイメントと、クライアント ソフトウェアからの既存の EJB の使用という 2 つの側面があります。EJB コントロールでは、デプロイされた既存の EJB をアプリケーションから簡単に使用できます。
詳細については、WebLogic Workshop ヘルプの「組み込み Java コントロールを使用する」にある「EJB コントロール」を参照してください。
Java Message Service (JMS) は、メッセージング システムと通信するための Java API です。通常、メッセージング システムは、レガシー システムとの通信や異なる環境またはホストで実行されるビジネス コンポーネント間の通信を目的としてエンタープライズ アプリケーションで使用されます。JMS コントロールを使用すると、WebLogic Workshop に組み込まれているアプリケーションは、WebLogic Server または Message-Oriented Middleware システム (MOM) など、JMS 実装を提供するメッセージング システムと簡単に対話できます。
JMS コントロールを使用すると、WebLogic Workshop Web サービスは JMS 実装を提供するメッセージング システムと簡単に対話できます。特定の JMS コントロールは、メッセージング システムの個々の機能に関連付けられます。JMS コントロールを定義したら、その他の WebLogic Workshop コントロールと同じように Web サービスを使用することができます。
詳細については、WebLogic Workshop ヘルプの「組み込み Java コントロールを使用する」にある「JMS コントロール」を参照してください。
Web サービスなどの Web アプリケーションでは通常、クライアントとサーバ (アプリケーション) 間の通信に Hypertext Transport Protocol (HTTP) を使用しています。HTTP は、リクエスト応答プロトコルです。リクエスト応答プロトコルでは、それぞれの操作は、クライアントからサーバに送信されるリクエスト メッセージ、およびそれに続いてサーバからクライアントに返される応答メッセージで構成されます。処理を正常に完了するには、サーバが常に応答を送信する必要があります。リクエスト中はクライアントがサーバと同期を取るため、そのようなリクエストを同期といいます。サーバが応答するまで、あるいはリクエストがタイムアウトになるまで (所定の時間内に応答が受信されない場合、クライアントはタイムアウトになることがあります)、クライアントは処理を続行できません。
Web アプリケーションでは、アプリケーションの実行する処理の中に、長時間かかるものもあります。銀行のローン決済担当者による承認など、人間のアクションが介在する処理の場合は、完了までに数日かかることもあります。個別のリクエスト応答サイクルを数日に設定できるようにするのは、設計として好ましくないといえます。そのようなリクエストにしたら、クライアント ホストとクライアント ホストの両方で、リソースを不必要に消費することになります。
WebLogic Server Process Edition では、アプリケーションを非同期、つまり、応答の準備ができたときにアプリケーションがクライアントに通知するように設計できます。このように設計すると、要求された処理をアプリケーションが実行している間にも、クライアントが他の作業を続行できます。また、クライアントとアプリケーションの間での各リクエスト応答対話が、できるだけ短いものになります。
以下の節では、非同期性の概要と非同期インタフェースについて説明します。
ソフトウェア コンポーネント間の対話は、同期または非同期にすることができます。メソッドの処理が完了するまで、メソッドの呼び出し元が処理を続行できない場合、その対話は同期です。呼び出されたメソッドが結果をすぐに返して、呼び出し元が処理をそのまま続行できる場合、その対話は非同期です。非同期の対話は一般に、計算を開始しても、その結果を待ちません。このため、呼び出し元が計算の結果を後で取得するための手段が必要です。
Web アプリケーションは分散型という性質のためにレイテンシが予測できず、時には非常に長く待たされることがあります。ネットワーク上で実行中のビジネス プロセスが、バックエンドで人と対話する場合、その処理には何日もかかることがあります。Web 上の対話をすべて同期方式で行う場合は、操作の完了していないクライアントが、許容できないほど長時間にわたってホスト システムのリソースを消費することがあります。
WebLogic Server Process Edition には、クライアントが結果を待っている間に実行をブロックすることのない、非同期の Web サービスおよび非同期の Java コントロールを簡単に構築できるツールが提供されています。WebLogic Server Process Edition には、Web サービスおよび Java コントロールのクライアントに結果を返す方法が複数あるので、状況に最適の方法を選択できます。
非同期の Web サービスを作成するには、1 つまたは複数のメソッドを用意して、クライアントからリクエストを受け入れるようにします。このときクライアントは、処理を開始しても、完了するまで待機はしません。このようなメソッドは通常、すぐに復帰します。そのとき、最初のリクエスト応答対話の応答部分が入力されますが、要求された処理の実際の結果は入力されません。非同期インタフェースでは、長時間かかる処理の結果が準備できたら、その結果をクライアントが取得するというメカニズムも用意します。これを実現するには、次の 2 とおりの方法があります。
Web サービスにコールバックを定義すると、Web サービスでイベントが発生したことをクライアントに通知するメッセージが、Web サービスに定義されます。この設計では、クライアントはまず Web サービスを呼び出して、リクエストを開始します。このリクエスト呼び出しは、通常すぐに復帰します (最初のリクエスト応答対話の完了)。つまりクライアントは、処理が完了するまで待つ必要はありません。その間に、クライアントは他の作業を続行できます。Web サービスまたは Java コントロールでクライアントのリクエストを処理したらコールバックを送信します。つまり、クライアントにメッセージを返して、リクエストが処理されたことを通知し、その結果を渡します。コールバックは 2 番目のリクエスト応答対話を構成します。その対話では、(応答ではなく) リクエストがクライアントに送信されます。コールバック メカニズムの詳細については、WebLogic Workshop ヘルプの「入門 : 非同期性を利用して長期間の処理を実現する」にある「コールバックを使用してクライアントにイベントを通知する」を参照してください。
コールバックを使用するには、2 つの条件に合致している必要があります。第 1 に、Web サービスでコールバックを定義する場合は、その Web サービスが会話型であることが必要です。会話型の Web サービスでは、リクエストの起点を追跡するので、該当する呼び出し元にコールバックを送信できます。第 2 に、クライアントはコールバックの受信機能と解釈機能が必要です。コールバックを Web サービスで定義する場合は、本質的に、メッセージの受信機能が必要なので、クライアント自体が Web サービスであることが必要です。また、受信メッセージを、クライアントが開始した前回のリクエストと相関させる機能も必要です。会話の詳細については、WebLogic Workshop ヘルプの「非同期インターフェースを設計する」にある「会話形式の Web サービスを設計する」を参照してください。
Web (JSP) ページや非会話型 Web サービスのように、Web サービスまたは Java コントロールのクライアントが会話型でない場合は、リクエストが完了したことをクライアントに通知するのに、コールバックは使用できません。さらに、Web サービスのクライアントが、要求されていない受信トラフィックを拒否するホストや、ファイアウォールで保護されているホストに常駐する場合、コールバックは本来、要求されるものではないため、ホストによって拒否されます。また、クライアントがコールバックを受信することもありません。このようなシナリオを処理するには、Web サービスと Java コントロールにポーリング インタフェースが必要です。ポーリング インタフェースでは、クライアントはまず Web サービスまたは Java コントロールを呼び出して、処理を開始できるようにします。このリクエスト呼び出しは同期ですが、通常はすぐに復帰します。つまりクライアントは、処理が完了するまで待つ必要はありません。クライアントは別のタスクを続けることができますが、Web サービスまたは Java コントロールを定期的に呼び出して、保留中のリクエストのステータスを確認する必要があります。定期的な確認でリクエストが完了したことが表示された場合、クライアントは Web サービスまたは Java コントロールを呼び出して結果を取得します。ポーリング インタフェースの実装の詳細については、「コールバックの代わりにポーリングを使用する」を参照してください。
ポーリングとコールバックは、メカニズムは違いますが、目的は非同期を実現することです。使用している Web サービスまたは Java コントロールのクライアントが必要とするメカニズムが、常にこの 2 つのどちらか一方だけであることが絶対確実な場合を除き、あらゆる状況に対処できるように、両方のアプローチを実装した方がよいでしょう。そうすると、コールバックを処理できるクライアントにはコールバックの利便性が提供され、コールバックを受け入れないクライアントにはポーリング インタフェースが提供されます。
この節では、非同期インタフェースを持つ Web サービスと Java コントロールを作成して使用するためのベスト プラクティスについて説明します。最初のトピックでは、コールバックの代わりにポーリングを使用する方法を説明します。次のトピックでは、Web サービスからも JSP (Web) ページからも呼び出すことができる Web サービスと Java コントロールを設計する際のさまざまな設計上の疑問に答えます。
コールバックは本質的に、元のリクエスト (コールバックが応答として返送される相手) と切り離されるので、クライアントのホストにとっては要求しないのに送られてきたメッセージとして認識されます。多くのホストは、要求していないネットワーク トラフィックを拒否します。ホスト自身がこのようなトラフィックを直接拒否するよう設計されているか、ファイアウォールなどのネットワーク セキュリティ機能によって保護されているからです。したがって、このような環境で実行されるクライアントは、コールバックを受信することができません。
コールバックを処理するためのもう 1 つの要件は、クライアントが会話形式になることによって、永続的に存在することです。クライアントが Web アプリケーション (JSP ページ) または非会話形式の Web サービスである場合、コールバックを処理できません。
コールバックを受け入れないクライアントが Web サービスを使用できるようにするには、コールバックの代わりとしてポーリング インタフェースを提供します。ポーリング インタフェースには、クライアントが前のリクエストの結果が準備できたかどうかを判断するための呼び出しを定期的に行う、1 つまたは複数のメソッドを作成します。Web サービスや Java コントロールは設計上は非同期ですが、クライアントとの対話は同期 (非バッファ付き) メソッドにより処理されます。
一般的なポーリング インタフェースは、次の 3 つのメソッドを使って設計されます。
null が返されます。クライアントが Web サービスを呼び出すと、check_status メソッドによって会話が終了します。 ポーリング インタフェースを使用するクライアントは、リクエストのステータスを定期的に確認する必要があります。これは、Web サービスや Java コントロールに、リクエストが処理されたことをクライアントに通知する機能がないためです。また、上記 3 つのメソッドは、バッファ付きでないことにも注意してください。check_status メソッドと get_results メソッドは、void を返しません。また、バッファ付きにすることもできません。start_request メソッドは、check_status が処理される前に確実に処理されている必要があるので、バッファ付きにはできません。バッファ付きメソッドと非バッファ付きメソッドの相対的な処理順序は決まっていないことを覚えておいてください。詳細については、WebLogic Workshop ヘルプの「入門 : 非同期性を利用して長期間の処理を実現する」にある「バッファリングを使用して非同期のメソッドとコールバックを作成する」を参照してください)。
ポーリング インタフェースを実装する方法には、他にもいくつかあります。次の例は、そのうちの 1 つである Conversation.jws サンプル Web サービスのソース コードを示しています。
public class Conversation {/**
/**
* @common:operation
* @jws:conversation phase="start"
*/
public void startRequest()
{
...
}
/**
* @common:operation
* @jws:conversation phase="continue"
*/
public String getRequestStatus()
{
...
}
* @common:operation* @jws:conversation phase="finish"*/public void terminateRequest(){ }
}
クライアントは startRequest メソッドを使用して会話形式の Web サービスからのリクエストを開始します。その後、クライアントは getRequestStatus を定期的に呼び出して、結果を確認します。クライアントは、getRequestStatus を次に呼び出すまでの間、これまでと同様に他の処理を実行できます。getRequestStatus メソッドは、リクエストが完了するまで、そのリクエストが保留中であることを示す応答を返します。リクエストが完了した後でクライアントが getRequestStatus を呼び出すと、その結果がクライアントに返されます。その後、クライアントは terminateRequest を呼び出して、会話を終了します。
この節では、優れた設計の、最適で堅牢な Web サービスまたは Java コントロールを作成するための一般的な設計上のソリューションについて説明します。
Web サービスまたは Java コントロールを構築する上で最初に考えなければならないことは、そのサービスやコントロールを非同期にする必要があるかどうかという点です。中には、非会話形式の同期サービスまたはコントロールで十分だというケースがあります。特に、実装されている機能が比較的少なく、リクエストの処理が短めで、この Web サービスをサポートしている基礎となるインフラストラクチャが安定している場合 (たとえば、障害対策が万全のインターネットを使用していたり、コントロールが同一サーバ上の同期 Web サービスによって呼び出される場合など) は、これにあたります。ただし、これらの要素が 1 でも該当しない場合や、設計の時点では該当するかどうか不明な場合は、サービスまたはコントロールを非同期にしておくことをお勧めします。
コールバックは、非同期の Web サービスまたは Java コントロールを設計するための強力な手段です。ポーリングの場合のように、クライアントがリクエストのステータスを定期的に確認する必要がありません。特に、リクエストの処理に要する時間が特定できない場合や、処理時間がそのつど大幅に変化する場合は、コールバックを使用するのが最も簡潔に非同期と疎結合を実装する方法といえます。コールバックを使用するときは、メソッドとコールバックの両方のバッファリングと組み合わせると、大量のトラフィックを処理する場合に特に効果があります。ただし、コールバックを使用するには、クライアントが着信メッセージを受け入れるように設計されていて、メッセージの配信をサポートする環境でホストされている必要があります。
すべての非同期の Web サービスと Java コントロールにポーリング インタフェースを用意する必要があります。Web サービスまたは Java コントロールが非同期の場合、コールバックを受け入れることのできないクライアントにはポーリング インタフェースが必要です。ポーリング インタフェースがないと、そのようなクライアントは、非同期のメソッド呼び出しによって開始される処理の結果を取得できません。ポーリング インタフェースは Web サービスまたは Java コントロールの基盤インタフェース、そしてコールバックは、コールバックを扱うクライアントにとって便利な「特別」機能と考えてください。
このガイドラインに対する例外は、クライアントがすべて会話型 Web サービスであるか会話型 Web サービスによって呼び出される Java コントロールである Java コントロールです。会話型 WebLogic Workshop の Web サービスは、コールバックを常に受け入れることができます。ただし、Java コントロールは再利用できるように設計してください。Java コントロールのクライアントになるのが WebLogic Workshop Web サービスだけだと想定すると、Java コントロールの再利用が制限されます。
堅牢ですべての状況に対応できる非同期の Web サービスまたは Java コントロールを構築するには、コールバックとポーリング インタフェースの両方を実装することをお勧めします。設計には特に、次のメソッドを追加します。
この設計は、他の方法で実装することもできます。別な方法の詳細については、「コールバックの代わりにポーリングを使用する」を参照してください。
詳細については、WebLogic Workshop ヘルプの「非同期インタフェースを設計する」を参照してください。
1 つの Web サービスで同時に複数のクライアントと通信できます。また、各クライアントと複数回通信することもできます。非同期通信中に Web サービスでクライアント データを追跡できるようにするには、どのデータがどのクライアントに属しているかを記憶し、各クライアントの処理プロセスの段階を追跡する方法が必要です。WebLogic Server Process Edition では、クライアントと Web サービスの間で行われている特定の通信をユニークに識別し、処理間のステートを保持するために、会話を使用します。
会話は、非同期通信に関係するすべての Web サービスに必要不可欠です。この会話とは、Web サービスがコールバックまたはポーリング インタフェースを使用してクライアントと通信したり、コールバックでコントロールを使用したりすることです。
Web サービスとクライアントは、1 つのタスクを完了するために複数回通信する場合があります。また、複数のクライアントが同時に同じ Web サービスと通信する場合もあります。会話を使用すると、直接的な方法で、呼び出し間のデータを追跡して、Web サービスが常に正しいクライアントに応答するようにできます。
会話を使用すると、複数の通信にわたってデータを維持することに伴う以下の 2 つの問題が解決されます。
クライアントがサービスと会話を始めると、会話中にステート関連データを追跡するコンテキストが作成されます。この新しく作成されたコンテキストは、会話 ID で識別されます。会話 ID とは、会話をユニークに識別する文字列のことです。Web サービスでは、この会話 ID を使って、クライアントが実行する各処理で、クライアントとメッセージを相関させます。会話 ID があることで、Web サービスによって送受信されるメッセージが常に、適切なクライアントに関連付けられます。非同期 Web サービスをテストするときに、動作中の会話 ID をテスト ビューで確認できます。
詳細については、WebLogic Workshop ヘルプの「会話形式の Web サービスを設計する」にある「概要 : 会話」を参照してください。
会話は、Web サービスのステート関連データを維持し、Web サービス、そのクライアント、および他のリソースとの間の通信を相関させます。非同期の Web サービス、または単一のリクエストでクライアントや Java コントロールとの通信が複数に及ぶ Web サービスなどを設計する場合は、会話を実装する必要があります。
クライアントが会話を開始するように注釈が付けられたサービス処理を呼び出すと、WebLogic Server Process Edition によって会話コンテキストが作成されます。このコンテキストは、呼び出しとサービスを相関させたり、ステート関連データを維持するために使用されます。
会話が開始されると、WebLogic Server Process Edition では次のことが行われます。
WebLogic Server Process Edition は、これらのタスクを実行するときに、会話用のコンテキストを作成します。会話 ID、永続データ、アイドル時間、存続期間といった各情報は、会話コンテキストの一要素です。
会話 ID は、会話コンテキストの中でも特に有用なアイテムです。この ID は会話ごとに添付され、会話に参加しているそれぞれのリソース、Web サービス、およびクライアントが、どの通信がどの会話に属しているのかを識別できるようにします。会話 ID の詳細については、「会話の概要」を参照してください。
会話をサポートするサービスを構築するときは、会話のいくつかの特性に留意する必要があります。その 1 つは、会話をサポートする 2 つの Web サービス間の相関関係は、WebLogic Server Process Edition によって自動的に処理されるという点です。つまり、会話をサポートする Web サービスが、会話をサポートする別の Web サービスの会話メソッドを呼び出すと、WebLogic Server Process Edition は会話 (会話 ID を含む) を自動的に管理します。
ただし、会話コンテキストのスコープは、そのサービスだけに限定されます。会話の過程で別の Web サービスのメソッドを呼び出したからといって、その Web サービスのステートも保持されるということはありません。相手の Web サービスのステートは、そのサービス自身が維持します。
また、Web サービスのステートは、会話の phase 属性が start、continue、または finish のいずれかにマークされたメソッドまたはコールバック ハンドラが正常に完了した場合にのみ更新されることも覚えておいてください。この留意事項は、サービスの内部メソッドには該当しません。内部メソッドは処理ではないため会話メソッドにはなりません。
詳細については、WebLogic Workshop ヘルプの「会話形式の Web サービスを設計する」にある「会話を実装する」を参照してください。
会話の詳細については、WebLogic Workshop ヘルプの「非同期インターフェースを設計する」にある「会話形式の Web サービスを設計する」を参照してください。
|
|
|