Hitachi

OpenTP1 Version 7　分散トランザクション処理機能　TP1/Client for .NET Framework 使用の手引

2.1.4　RPCの種類

Client .NETでは，次のRPCを使用できます。

〈この項の構成〉

(1)　リモートAPI機能を使用したRPC

リモートAPI機能を使って，クライアント側のノードにあるUAPが発行したAPIを，OpenTP1がサーバ側に転送してサーバ側のプロセスで代理実行することができます。

リモートAPI機能を要求するクライアント側のノードにあるUAPをrapクライアントといいます。rapクライアントが発行したAPIを，OpenTP1のrapリスナーが受け付け，rapサーバがサーバ側のノードで実行します。rapリスナー，rapサーバはOpenTP1のユーザサービスとして動作します。

リモートAPI機能を使用したRPCでは，OpenTP1上のrapサーバを経由してサービスを要求します。リモートAPI機能を使用すると，Client .NETから確立したコネクションを常に使用してサービスの要求や応答の受信ができます。したがって，ファイアウォールの内側にあるUAPに対しても，サービスを要求できます。なお，リモートAPI機能を使用したRPCは，TP1/Serverのほかに，DCCM3およびTMS-4V/SPを使用できます。

リモートAPI機能を使用したRPCを行う場合は，必ず常設コネクションを確立してください。常設コネクションについては，「2.2　常設コネクション」を参照してください。

リモートAPI機能を使用したRPCを行う場合で，OpenRpcメソッドを呼び出すときは，Client .NET構成定義の<rpc>要素のuse属性にrapを指定し，かつClient .NET構成定義の<rapService>要素を指定します。

リモートAPI機能を使用したサービス要求の流れを次に示します。

図2‒2　リモートAPI機能を使用したサービス要求の流れ

[図データ]

  1. TP1Clientクラスのインスタンスを作成します。

  2. OpenConnectionメソッドを呼び出し，OpenTP1上のrapリスナーを経由して，rapサーバとの間に常設コネクションを確立します。

  3. Callメソッドを呼び出して，rapサーバ経由で該当するSPP.NETまたはSPPにサービスを要求します。

  4. CloseConnectionメソッドを呼び出して，OpenTP1上のrapサーバとの間の常設コネクションを解放します。

ページの先頭へ

(2)　ネームサービスを使用したRPC

OpenTP1のネームサービスを使用したRPCを発行できます。

ネームサービスを使用したRPCでは，サービスを要求する前にOpenRpcメソッドを呼び出す必要があります。また，CUP.NETの実行の最後にCloseRpcメソッドを呼び出す必要があります。

ネームサービスを使用したRPCの流れと，RPCごとにサービス要求先スケジューラを分散させる場合の定義について説明します。

(a)　ネームサービスを使用したRPCの流れ

ネームサービスを使用したRPCを行う場合は，Client .NET構成定義の<rpc>要素のuse属性にnamを指定し，かつClient .NET構成定義の<nameService>要素を指定します。

ネームサービスを使用したサービス要求の流れを次に示します。

図2‒3　ネームサービスを使用したサービス要求の流れ

[図データ]

  1. TP1Clientクラスのインスタンスを作成します。

  2. OpenRpcメソッドを呼び出して，CUP.NETのRPC環境を初期化します。

  3. Callメソッドを呼び出して，該当するSPP.NETまたはSPPにサービスを要求します。※

  4. Callメソッドを呼び出して，Client .NETのキャッシュを検索し，該当するSPP.NETまたはSPPにサービスを要求します。

  5. CloseRpcメソッドを呼び出して，RPC環境を解放します。

注※

Callメソッド内部の処理の流れを次に示します。

  1. 指定されたnamサーバに対してコネクションを確立します。

  2. namサーバにサービス情報取得要求を送信し，namサーバとの間で確立したコネクションを解放します。

  3. namサーバから応答メッセージ送信用のコネクション確立要求を受信後，コネクションを確立してサービス情報を受信します。

  4. サービス情報の受信後，namサーバとのコネクションを解放します。

  5. namサーバからの応答メッセージ中のサービス情報をClient .NETのキャッシュに格納し，その情報を基に，サービスを実行しているOpenTP1上のscdサーバに対してコネクションを確立します。

  6. scdサーバとのコネクション確立後，サービス要求メッセージを送信してコネクションを切断します。

  7. SPP.NETまたはSPPから応答メッセージ送信用のコネクション確立要求を受信後，コネクションを確立して応答メッセージを受信します。

  8. SPP.NETまたはSPPとの間で確立したコネクションを解放します。

(b)　RPCごとにサービス要求先スケジューラを分散させる場合の定義

ネームサービスを使用したRPCでは，サービス要求先スケジューラの情報をネームサーバからキャッシュに格納し，キャッシュの情報を参照してRPCごとにサービス要求先スケジューラを分散させることができます。RPCごとにサービス要求先スケジューラを分散させる場合のClient .NET側，TP1/Server側の関連する定義について説明します。

■ Client .NET側の定義

RPCごとにサービス要求先スケジューラを分散させる場合は，<nameService>要素のloadBalance属性にtrueを指定します。

これによって，Client .NETは，ネームサーバから複数のサービス要求先スケジューラの情報を取得し，負荷レベルが最も低いサービス要求先スケジューラの情報をキャッシュに格納します。キャッシュに格納されるサービス要求先スケジューラは，一つだけではなく，複数の場合もあります。

キャッシュに格納されたサービス要求先スケジューラが複数ある場合，最初のサービス要求先スケジューラは，ランダムに選択されます。RPCでのサービス要求が2度目以降の場合は，サービス要求先スケジューラの情報を取得するためにキャッシュを参照し，RPCごとにラウンドロビン方式でサービス要求先スケジューラを切り替え，分散させます。

キャッシュの有効期限の指定

<nameService>要素のcacheTime属性で，サービス要求先スケジューラの情報を保持する，キャッシュの有効期限を指定できます。

キャッシュにサービス要求先スケジューラの情報を格納したあとで，キャッシュの有効期限を満了した場合，そのサービス要求先スケジューラの情報を破棄します。その後，サービス要求先スケジューラの情報を再度取得して，その情報をキャッシュに格納することで，キャッシュを更新します。

<nameService>要素のcacheTime属性は，<nameService>要素のloadBalance属性にtrueを指定した場合だけ有効になります。

■ TP1/Server側の定義

次に示すTP1/Server側の定義のオペランドを指定すると，ネームサーバからサービス要求先スケジューラの情報を取得するときに，スケジューラの負荷情報も同時に取得します。

スケジュールサービス定義

  • scd_announce_server_status=Y（デフォルト）※1

ユーザサービス定義，またはユーザサービスデフォルト定義

  • loadcheck_interval

  • levelup_queue_count※2

  • leveldown_queue_count※2

注※1

このオペランドにNを指定した場合，スケジューラの負荷レベルは常にLEVEL0（負荷が低い状態）になります。負荷レベルが常にLEVEL0のスケジューラが，Client .NETのサービス要求先スケジューラになった場合，実際の負荷状態に関係なく，常にサービス要求先スケジューラとして選択されます。

注※2

負荷レベルがサービス要求の滞留数で決まる方式とする場合に指定します。

上記の定義の詳細については，マニュアル「OpenTP1 システム定義」を参照してください。

(c)　マルチホームドホスト形態のTP1/Serverに対してRPCを行う場合の定義

ネームサービスを使用したRPCでは，通信先TP1/Serverがマルチホームドホスト形態の場合に通信障害が発生することがあります。これは，CUP.NETが存在するネットワークから，通信先TP1/Serverのシステム共通定義のmy_hostオペランドで指定したホスト名（IPアドレス）に対応するネットワークアダプタに通信できないことが原因です。

これを回避するためには，Client .NET側で，<nameService>要素のmultiHomedHost属性にtrueを指定します。ネットワークの構成例を次の図に二つ示し，それぞれのネットワーク構成でのmultiHomedHost属性の定義の要否を示します。

図2‒4　マルチホームドホスト形態のTP1/Serverに対してRPCを行う場合の例

[図データ]

ネットワーク構成例2のCUP.NETがIPアドレス4と通信するには，<nameService>要素のmultiHomedHost属性にtrueの指定が必要です。この指定がない場合，CUP.NETとIPアドレス4との間では通信障害が発生します。

通信先TP1/Serverがマルチホームドホスト形態で，かつ同じTP1/Server上にサービス要求先のSPPが存在しているときは，<nameService>要素のmultiHomedHost属性にtrueを指定することでRPCが行えるようになります。通信先TP1/Serverのシステム共通定義のall_nodeオペランドに，CUP.NETが接続されていないネットワーク上に存在するTP1/Serverが指定されている場合，このTP1/Server上のSPPに対してRPCを行うと通信障害が発生します。なお，通信先TP1/Serverがマルチホームドホスト形態でない場合，multiHomedHost属性の指定に関係なく，RPCを行えます。

ページの先頭へ

(3)　スケジューラダイレクト機能を使用したRPC

スケジューラダイレクト機能を使用すると，RPCの実行時にOpenTP1のネームサービスを使用しないで，直接スケジューラサービスに問い合わせることができます。

スケジューラダイレクト機能を使用したRPCでは，サービスを要求する前にOpenRpcメソッドを呼び出す必要があります。また，CUP.NETの実行の最後にCloseRpcメソッドを呼び出す必要があります。

スケジューラダイレクト機能を使用したRPCの流れと，RPCごとにサービス要求先スケジューラを分散させる場合の定義について説明します。

(a)　スケジューラダイレクト機能を使用したRPCの流れ

スケジューラダイレクト機能を使用したRPCを行う場合は，Client .NET構成定義の<rpc>要素のuse属性にscdを指定し，かつClient .NET構成定義の<scheduleService>要素を指定します。

スケジューラダイレクト機能を使用したサービス要求の流れを次に示します。

図2‒5　スケジューラダイレクト機能を使用したサービス要求の流れ

[図データ]

  1. TP1Clientクラスのインスタンスを作成します。

  2. OpenRpcメソッドを呼び出して，CUP.NETのRPC環境を初期化します。

  3. Callメソッドを呼び出して，該当するSPP.NETまたはSPPにサービスを要求します。※

  4. CloseRpcメソッドを呼び出して，RPC環境を解放します。

注※

Callメソッド内部の処理の流れを次に示します。

  1. 指定されたscdサーバに対してコネクションを確立します。

  2. scdサーバとのコネクション確立後，サービス要求メッセージを送信してコネクションを切断します。

  3. SPP.NETまたはSPPから応答メッセージ送信用のコネクション確立要求を受信後，コネクションを確立して応答メッセージを受信します。

  4. SPP.NETまたはSPPとの間で確立したコネクションを解放します。

(b)　RPCごとにサービス要求先スケジューラを分散させる場合の定義

スケジューラダイレクト機能を使用したRPCでは，RPCごとにラウンドロビン方式でサービス要求先スケジューラを切り替え，分散させることができます。RPCごとにサービス要求先スケジューラを分散させる場合は，<scheduleService>要素のhostChange属性にtrueを指定してください。

ページの先頭へ

(4)　通信先を指定したRPC

サービス要求を実行するサーバ（通信先のOpenTP1ノード）を明示的に指定してRPCを発行できます。

通信先を指定したRPCでは，サービス要求先のノード（スケジュールサービス）を指定してサービスを要求できます。サービス要求先のノードの状態に関係なく，サービス要求処理は指定したノードで行われます。

通信先を指定したRPCを行う場合は，CallToメソッドを使用します。

なお，このRPCは，リモートAPI機能を使用したRPC，およびクライアントスタブを使用したRPCとの併用はできません。

ページの先頭へ

商品名称に関する表示

All Rights Reserved. Copyright (C) 2006, 2022, Hitachi, Ltd.