|
|
WebLogic Server Process Edition では、そのまま使用できる一連のコントロールが提供されており、これを使用すると、リソースのポートフォリオを利用してプロジェクトの統合を開始できます。WebLogic Server Process Edition の Integration コントロールを使用すると、アプリケーションからデータベースやファイル システムなどのエンタープライズ リソースに簡単にアクセスできます。WebLogic Integration アプリケーションは、WebLogic Workshop の高レベルなコントロールを使用して外部リソースにアクセスすることもできます。BEA Workshop for WebLogic Platform フレームワークでは、BEA Workshop for WebLogic Platform、WebLogic Integration、WebLogic Portal の全コンポーネントでリソースと対話できる一貫したメカニズムが提供されています。エンタープライズ リソースに接続する作業はコントロールによって処理されるため、開発者はビジネス プロセスのロジックに専念できます。
WebLogic Integration コントロールは、オープン ソースである Apache Beehive フレームワーク (http://beehive.apache.org/) に基づいています。Beehive は、軽量なコンポーネント フレームワークで、プログラマがアプリケーション ロジックをカプセル化したり、メタデータ アノテーションをプログラミング モデルに活用するのに役立ちます。開発者は、カスタム コントロールを作成したり、あらかじめ組み込まれているシステム コントロールを使用することができます。
以下の節では、WebLogic Server Process Edition の Integration コントロール、その他の使用可能な WebLogic コントロール、非同期インタフェース、および会話について説明します。
この節では、次の Integration コントロールについて説明します。
ファイル コントロールはファイルに対する操作の実行に使用されます。ビジネス プロセスで、ファイル システム内のファイルの読み込み、書き込み、追加ができます。また、ファイル コントロールは、コピー、名前の変更、削除などのファイル操作をサポートしています。特定のディレクトリに格納されているファイルのリストを取得することもできます。ファイルのタイプは、XmlObject、RawData (バイナリ)、String のいずれかです。
ファイル コントロールで利用可能なメソッドは、ファイルに含まれたデータ型によって異なります。ファイル タイプ String または XmlObject については、文字セット エンコーディングを指定できます。ファイル処理時に、レコード サイズとしてファイルに区切り文字を指定できます。区切り文字が指定されていない場合、ファイルは一度に 1 行ずつ処理されます。ファイル タイプ String の場合は、区切り文字としてバイト数または任意の文字が指定できます。
通常、操作するすべてのファイルのそれぞれに対し個別のファイル コントロールをコンフィグレーションします。ファイル コントロールの設定はいくつかの方法で指定できます。ファイル コントロールのプロパティは、デザイン ビューで設定すること、または FileControl インタフェースの setProperties メソッドを呼び出して設定することができます。ファイル コントロールのコンフィグレーション プロパティは動的に変更できます。現在のプロパティ設定を取得するには、getProperties() メソッドを使用します。
ControlContext インタフェースを使用して、実行時にコントロールのプロパティにアクセスしたり、コントロール イベントを処理したりすることもできます。コントロールを使用する開発者によって設定されたプロパティ値は、JWS、JSP、または JPD ファイルでコントロールの宣言のアノテーションとして、またはコントロール定義ファイルでインタフェース宣言、コールバック宣言、またはメソッド宣言のアノテーションとして格納されます。
詳細については、「Integration コントロールを使用する」の「ファイル コントロール」を参照してください。
電子メール コントロールを使用すると、WebLogic Server Process Edition ビジネス プロセスでは、特定の送り先に電子メールを送信できます。電子メール メッセージの本体には、テキスト (プレーン、HTML、または XML) または XML オブジェクトを使用できます。電子メール コントロールはカスタマイズ可能であり、電子メール送信プロパティをアノテーション内で指定したり、XML 変数として渡される動的なプロパティを使用したりできます。電子メール コントロールを使用して、さまざまなコンテンツ型や、本体と添付ファイルのさまざまな組み合わせを送信できます。
ビジネス プロセスに電子メール コントロールを追加する場合、既存の電子メール コントロール定義ファイルを使用することも、新しく作成することもできます。
詳細については、「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 メッセージ タイプのサポート、動的プロパティのコンフィグレーション、および新しいトランザクションを開始するか呼び出し側のトランザクションに留まるかを制御する機能などの追加機能を提供します。
詳細については、「Integration コントロールを使用する」の「WLI JMS コントロール」を参照してください。
サービス ブローカ コントロールを使用すると、ビジネス プロセスでは、別のビジネス プロセス、Web サービス、または Web Service Description Language (WSDL) ファイルで定義された Web サービスやビジネス プロセスとの間で、要求を送信したりコールバックを受信したりできます。サービス ブローカ コントロールでは、コントロールの属性を動的に設定できます。したがって、アプリケーションを再デプロイせずにコントロール属性を再コンフィグレーションできます。
リモートの Web サービスまたはビジネス プロセスは、Web サービスを使用してアクセスされ、WSDL ファイルに記述されます。WSDL ファイルには、Web サービスが実装するメソッドとコールバックを、メソッド名、パラメータ、および戻り値の型を含めて記述します。[アプリケーション] ペインの JPD ファイルを右クリックし、[WSDL ファイルの生成] を選択することによって、任意のビジネス プロセスについて WSDL ファイルを生成することができます。
| 注意 : | サービス ブローカ コントロールは 9.2 リリースで非推奨になっています。この項目はサポートされなくなり、WebLogic Server Process Edition の次回のメジャー リリースで削除されます。このコントロールは、WebLogic Server Process Edition 8.1 との下位互換性を保つためにのみ含まれています。WebLogic Server Process Edition 8.x JPD と通信する場合にのみ、このコントロールの使用が推奨されます。 |
| 注意 : | 9.2 のサービス ブローカ コントロールは、WS-Addressing、WS-Security、SOAP 1.2 などの最新の Web サービス標準をサポートしません。最新の Web サービス標準を使用するには、BEA Workshop for WebLogic Platform に付属する Web サービス コントロールを使用してください。 |
詳細については、「Integration コントロールを使用する」の「サービス ブローカ コントロール」を参照してください。
Hyper Text Transfer Protocol (HTTP) コントロールは WebLogic Platform コントロール アーキテクチャの機能を使用して構築されています。このコントロールの目的は、BEA Workshop for WebLogic Platform クライアントへの送信 HTTP アクセスを提供することです。Http コントロールは WebLogic Integration で提供される他のコントロールを補完するものであり、BEA Workshop for WebLogic Platform やビジネス プロセスで使用すると、HTTP 要求やプロセスの応答を処理することができます。Http コントロールのソース ファイルは Jakarta Commons HTTP Client パッケージのラッパーです。Http コントロールは HTTP/1.1 固有の機能に準拠しています。
Http コントロールを使用すると、WebLogic Workshop やビジネス プロセスで HTTP 要求を処理し、特定の URL に応答を送信できます。Http コントロールでは、HTTP Get と HTTP Post という 2 つの HTTP モードをサポートしています。Get モードを使用すると、URL を指定してビジネス データを送信できます。Post モードを使用すると、バイナリ、XML、および文字列ドキュメントを送信できます。HTTP プロパティをアノテーション内に指定したり、XML 変数を介して動的なプロパティを渡したりできます。
Http コントロールを使用すると、以下のように、HTTP または HTTPS (セキュアな HTTP) 要求を URL に送信したり、特定の HTTP 応答ヘッダや本体データを受信したりできます。
詳細については、「Integration コントロールを使用する」の「Http コントロール」を参照してください。
MQSeries は、複数のプラットフォームで動作する IBM のミドルウェア製品です。MQSeries を使用すると、アプリケーション間でメッセージを転送できます。送信側アプリケーションはメッセージをキューに入れ、受信側アプリケーションはキューからメッセージを取得します。送信側アプリケーションと受信側アプリケーションが同じプラットフォーム上にある必要はありません。また、送信側アプリケーションと受信側アプリケーションは別々の時刻に実行できます。送り先キューにメッセージが確実に配信されるようにするために必要なストレージ、ログ、および通信の詳細は、すべて MQSeries によって管理されます。
MQSeries は、アプリケーション間のメッセージ転送を可能にする、IBM のメッセージング サービス キューです。送信側アプリケーションはメッセージをキューに入れ、受信側アプリケーションはキューからメッセージを取得します。
MQSeries コントロールは、 ビジネス プロセスで MQSeries キューを使用したメッセージの送受信を可能にします。MQSeries コントロールを使用して、バイナリ、XML、および文字列のメッセージを送受信できます。MQSeries コントロールをコンフィグレーションするときに、MQSeries コントロールのプロパティを指定できます。また、実行時に動的に指定することも可能です。デフォルトでは、MQSeries コントロールは Put および Get メソッドごとにトランザクションを暗黙的に処理します。明示的なトランザクション境界の設定は必要ありません。ただし、トランザクション境界も明示的に設定できます。
SSL の使用により、一方向認証 (サーバサイド) と双方向認証 (クライアントサイド) の両方が可能になります。
詳細については、「Integration コントロールを使用する」の「MQSeries コントロール」を参照してください。
BEA WebLogic Integration と共に MQSeries コントロールおよびイベント ジェネレータを使用しても、「ダイナミック ライブラリ」 を含む MQSeries コントロールを使用する権限が付与されるわけではありません。MQSeries コントロールおよびイベント ジェネレータのユーザがこのような IBM 製品を使用するためには、有効なライセンスを IBM から取得する必要があります。
TIBCO® Rendezvous™ (TIBCO (www.tibco.com) の製品) を使用すると、分散プラットフォームで稼動するアプリケーション間でデータを交換することができます。WebLogic Server Process Edition の TIBCO Rendezvous (TIBCO RV) コントロールは、データへのシームレスな接続、および Rendezvous デーモンを使用したデータの転送を可能にします。認証されたメッセージ配信、分散キューなどの TIBCO Rendezvous によって、提供される機能を使用した通信が可能になります。Rendezvous デーモンがホスト マシン上で稼動しているか、またはリモートでホストにアクセスできれば、送信/受信アプリケーションは複数のプラットフォームに配置することができます。
| 注意 : | TIBCO RV コントロールは、WebLogic Server Process Edition の使用許諾を受けた場合にのみ、BEA Workshop for WebLogic Platform で使用できます。 |
BEA WebLogic Server Process Edition と共に TIBCO RV コントロールおよびイベント ジェネレータを使用しても、「ダイナミック ライブラリ」を含む TIBCO Rendezvous を使用する権限が付与されるわけではありません。TIBCO RV コントロールのユーザがこのような TIBCO 製品を使用するためには、有効なライセンスを TIBCO から取得する必要があります。Rendezvous のライセンス取得方法については、http://www.tibco.com を参照してください。
XML メタデータ キャッシュ コントロールは、XML メタデータ キャッシュで維持された XML メタデータにアクセスおよび XML メタデータを検索するために、ビジネス プロセスで使用されます。このキャッシュは WebLogic Integration Administration Console または MBean API を使用して管理され、このキャッシュを使用することでコンソールに基づいた独自の NetUI の作成が可能になります。XML メタデータ キャッシュはグローバルなドメイン全体のキャッシュです。したがって、そのドメインにデプロイされたどのビジネス プロセスであっても、キャッシュに維持されたデータにアクセスできます。クラスタ内でデータを共有するのにキャッシュを使用できます。キャッシュは主にメタデータのコンフィグレーションの維持に使用されます。データは、String 型のキーと、XML データを含む値のペアとして格納されます。キャッシュのデータは、ファイルベースで格納することにより永続的に使用できるようになります。キャッシュに追加された XML ドキュメントごとに、新しい XML メタデータ キャッシュ ファイルが作成されます。ビジネス プロセスの XML メタデータ キャッシュ コントロールはキーを使用して、キー値に関連付けられた XML メタデータをキャッシュから検索します。詳細については、「Integration コントロールを使用する」の「XML メタデータ キャッシュ コントロール」を参照してください。
この節では、以下のアプリケーション コントロールについて説明します。
Beehive コントロールは、エンタープライズ アプリケーションの任意の場所で使用できる再使用可能コンポーネントです。Workshop for WebLogic Platform に用意されている組み込みコントロールを使用することも、独自のコントロールを作成することもできます。WebLogic Server Process Edition アプリケーションを構築する際に、Beehive コントロールを使用すると、リソースへのアクセスを簡単に組み込み、ビジネス ロジックを効率的にカプセル化できます。コントロールでは、以下が可能です。
コントロールでは、コントロールのプロパティを設定するため Java 5 のアノテーションを利用します。システム コントロールには、アノテーションの設定を通じてパラメータ化される多くのプロパティがあります。カスタム コントロールについては、コントロールの作成者は、コントロール プロパティの任意のセットに対しアノテーションのパラメータ化を定義できます。
コントロールは、Apache Beehive コントロール フレームワークを基に構築されます。詳細については、Apache Beehive ドキュメントの「Controls: Getting Started」を参照してください。
システム コントロールとカスタム コントロールが、コントロールの主な 2 つのタイプです。システム コントロールを使用すると、データベース、EJB、JMS キュー、Web サービスなどの共通アプリケーション リソースに接続できます。これらのコントロールはほとんど修正せずに、またはまったく修正せずにアプリケーションで使用できます。
Workshop for WebLogic Platform は、エンタープライズ リソースにアクセスできるようにすることを主な目的としたシステム コントロールを複数提供しています。たとえば、EJB コントロールを使用してエンタープライズ JavaBeans にアクセスできますし、JMS コントロールを使用して Java Message Service にアクセスできます。システム コントロールの詳細については、「システム コントロールの使用」を参照してください。
カスタム コントロールを使用すると、リソースへのアクセスを完全カスタマイズすること、一部のアプリケーション機能をカプセル化することができます。アプリケーションで任意のタスクを実行するカスタム コントロールを設計できます。
システム コントロールが基づく同じフレームワークに基づいた独自のカスタム コントロールを構築できます。カスタム コントロールの設計は一から開始し、インタフェースおよび実装を設計し、必要に応じて他のコントロールを追加します。1 つのプロジェクトで使用するカスタム コントロールを設計することもできますし、複数のプロジェクトで簡単に再使用できるカスタム コントロールを設計することもできます。カスタム コントロールの詳細については、「カスタム コントロールの開発」を参照してください。
詳細については、「Beehive コントロールの操作」を参照してください。
JDBC コントロールを使用すると、アプリケーションからリレーショナル データベースに簡単にアクセスできます。JDBC コントロールを使用して、データベースに対し SQL コマンドを発行できます。JDBC コントロールは、データベース クエリを Java オブジェクトに自動的に変換するので、クエリの結果に簡単にアクセスできます。
JDBC コントロールは、適切な Java Database Connectivity (JDBC) ドライバが使用可能で、データ ソースが WebLogic Server でコンフィグレーションされていればどのデータベースに対しても処理を行えます。JDBC コントロールをアプリケーションに追加するときに、そのコントロールのデータ ソースを指定します。データ ソースは、コントロールにバインドされるデータベースを示します。
詳細については、「システム コントロールの使用」の「JDBC コントロール」を参照してください。
トランザクションとイベントには、完了するまでにある程度の時間を必要とするものがあります。また、中止しないと無限に実行を継続して、リソースを大量に消費するものもあります。また、特定の時刻に実行する必要のあるものもあります。タイマー コントロールを使用すると、指定した時間間隔が経過したとき、または指定した絶対時間に達したときに、コードで応答することができます。
タイマー コントロールは、次の方法で Web サービスに通知を行うことができます。
すべてのタイマー コントロールは、com.bea.control.TimerControl 基本クラスまたは com.bea.control.TimerControlBean 基本クラスのインスタンスです。タイマー コントロールは直接 .java ファイルで宣言します。タイマー コントロールは、EJB 2.1 タイマー サービスに基づいています。タイマー コントロールは、一定の時間が経過したとき、クライアントに対し最善の方法でコールバックを実行するので、アプリケーション タイマーに適しています。ただし、タイマー コントロールは、正確にはリアルタイムのタイム サービスではありません。タイマー コントロールは、会話型の (ステートフルな) Web サービスでのみ使用可能です。
詳細については、「システム コントロールの使用」の「概要 : タイマー コントロール」を参照してください。
サービス コントロールは、Web サービスのプロキシです。Web サービス クライアントは、このプロキシを使用して Web サービスにアクセスします。サービス コントロールを使用すると、サービス コントロールの簡単なメソッド呼び出しを介して、Web サービス クライアントから Web サービスの操作にアクセスできます。サービス コントロールは、Web サービスとの SOAP メッセージの交換を管理し、Web サービス操作の結果を返します。
すべてのサービス コントロールは、com.bea.control.ServiceControl 基本クラスを拡張したインタフェースです。
サービス コントロールは、アプリケーションと Web サービスの間のインタフェースとして機能します。これにより、アプリケーションで Web サービスのメソッドを呼び出したり、Web サービスのコールバックを処理したりできます。サービス コントロールを使用すると、WSDL ファイルが有効なすべての Web サービスに接続できます。
詳細については、「システム コントロールの使用」の「サービス コントロール」を参照してください。
エンタープライズ JavaBean (EJB) は、エンタープライズ アプリケーションの Java ソフトウェア コンポーネントです。Java 2 Enterprise Edition (J2EE) 仕様では、EJB のタイプおよび機能と、EJB がデプロイおよび実行される環境 (コンテナ) が定義されています。ソフトウェア開発者の視点から見ると、EJB には EJB の開発およびデプロイメントと、クライアント ソフトウェアからの既存の EJB の使用という 2 つの側面があります。EJB コントロールでは、デプロイされた既存の EJB をアプリケーションから簡単に使用できます。
詳細については、「システム コントロールの使用」の「EJB コントロール」を参照してください。
Java Message Service (JMS) は、メッセージング システムと通信するための Java API です。通常、メッセージング システムは、レガシー システムとの通信や異なる環境またはホストで実行されるビジネス コンポーネント間の通信を目的としてエンタープライズ アプリケーションで使用されます。JMS コントロールを使用すると、WebLogic Workshop に組み込まれているアプリケーションは、WebLogic Server または Message-Oriented Middleware システム (MOM) など、JMS 実装を提供するメッセージング システムと簡単に対話できます。
WebLogic Workshop 8.1 で提供されていた JSM コントロールに関する変更を以下に示します。
Workshop for WebLogic の JMS コントロールは、標準 Beehive JMS コントロールです。
詳細については、「システム コントロールの使用」の「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 Web サービス プログラマーズ ガイド』の「高度な JWS プログラミング : 非同期機能の実装」にある「コールバックによるクライアントへのイベントの通知」を参照してください。
コールバックを使用するには、2 つの条件に合致している必要があります。第 1 に、Web サービスでコールバックを定義する場合は、その Web サービスが会話型であることが必要です。会話型の Web サービスでは、リクエストの起点を追跡するので、該当する呼び出し元にコールバックを送信できます。第 2 に、クライアントはコールバックの受信機能と解釈機能が必要です。コールバックを Web サービスで定義する場合は、本質的に、メッセージの受信機能が必要なので、クライアント自体が Web サービスであることが必要です。また、受信メッセージを、クライアントが開始した前回のリクエストと相関させる機能も必要です。会話の詳細については、「会話形式の 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 サービスを呼び出すと、get_results メソッドによって会話が終了します。
ポーリング インタフェースを使用するクライアントは、リクエストのステータスを定期的に確認する必要があります。これは、Web サービスや Java コントロールに、リクエストが処理されたことをクライアントに通知する機能がないためです。また、上記 3 つのメソッドは、バッファ付きでないことにも注意してください。check_status メソッドと get_results メソッドは、void を返しません。また、バッファ付きにすることもできません。start_request メソッドは、check_status が処理される前に確実に処理されている必要があるので、バッファ付きにはできません。バッファ付きメソッドと非バッファ付きメソッドの相対的な処理順序は決まっていないことを覚えておいてください。詳細については、「Web サービス コールバックやコントロール イベントでのバッファリングの使用」を参照してください。
ポーリング インタフェースを実装する方法には、他にもいくつかあります。以下の例は、いくつかある方法の 1 つです。
public class Conversation {@javax.jws.WebMethod
@weblogic.jws.Conversation(weblogic.jws.Conversation.Phase.START)
public void startRequest()
{...
}
@javax.jws.WebMethod
@weblogic.jws.Conversation(weblogic.jws.Conversation.Phase.CONTINUE)
public String getRequestStatus()
{...
}
@javax.jws.WebMethod
@weblogic.jws.Conversation(weblogic.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 コントロールを構築するには、コールバックとポーリング インタフェースの両方を実装することをお勧めします。設計には特に、次のメソッドを追加します。
この設計は、他の方法で実装することもできます。他の方法の詳細については、「コールバックの代わりにポーリングを使用する」を参照してください。
詳細については、Workshop for WebLogic Platform プログラマーズ ガイドの「非同期インタフェースの設計」を参照してください。
1 つの Web サービスで同時に複数のクライアントと通信できます。また、各クライアントと複数回通信することもできます。非同期通信中に Web サービスでクライアント データを追跡できるようにするには、どのデータがどのクライアントに属しているかを記憶し、各クライアントの処理プロセスの段階を追跡する方法が必要です。WebLogic Server Process Edition では、クライアントと Web サービスの間で行われている特定の通信をユニークに識別し、処理間のステートを保持するために、会話を使用します。
会話は、非同期通信に関係するすべての Web サービスに必要不可欠です。この会話とは、Web サービスがコールバックまたはポーリング インタフェースを使用してクライアントと通信したり、コールバックでコントロールを使用したりすることです。
Web サービスとクライアントは、1 つのタスクを完了するために複数回通信する場合があります。また、複数のクライアントが同時に同じ Web サービスと通信する場合もあります。会話を使用すると、直接的な方法で、呼び出し間のデータを追跡して、Web サービスが常に正しいクライアントに応答するようにできます。
会話を使用すると、複数の通信にわたってデータを維持することに伴う以下の 2 つの問題が解決されます。
クライアントがサービスと会話を始めると、会話中にステート関連データを追跡するコンテキストが作成されます。この新しく作成されたコンテキストは、会話 ID で識別されます。会話 ID とは、会話をユニークに識別する文字列のことです。Web サービスでは、この会話 ID を使って、クライアントが実行する各処理で、クライアントとメッセージを相関させます。会話 ID があることで、Web サービスによって送受信されるメッセージが常に、適切なクライアントに関連付けられます。非同期 Web サービスをテストするときに、動作中の会話 ID をテスト ビューで確認できます。
詳細については、「会話形式の 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 のいずれかにマークされたメソッドまたはコールバック ハンドラが正常に完了した場合にのみ更新されることも覚えておいてください。この留意事項は、サービスの内部メソッドには該当しません。内部メソッドは処理ではないため会話メソッドにはなりません。
詳細については、「会話形式の Web サービスの設計」を参照してください。
|
