Client .NETでは,次の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を行う場合は,必ず常設コネクションを確立してください。常設コネクションについては,「2.2 常設コネクション」を参照してください。
リモートAPI機能を使用したRPCを行う場合で,OpenRpcメソッドを呼び出すときは,Client .NET構成定義の<rpc>要素のuse属性にrapを指定し,かつClient .NET構成定義の<rapService>要素を指定します。
リモートAPI機能を使用したサービス要求の流れを次に示します。
図2-2 リモートAPI機能を使用したサービス要求の流れ
OpenTP1のネームサービスを使用したRPCを発行できます。
ネームサービスを使用したRPCでは,サービスを要求する前にOpenRpcメソッドを呼び出す必要があります。また,CUP.NETの実行の最後にCloseRpcメソッドを呼び出す必要があります。
ネームサービスを使用したRPCの流れと,RPCごとにサービス要求先スケジューラを分散させる場合の定義について説明します。
ネームサービスを使用したRPCを行う場合は,Client .NET構成定義の<rpc>要素のuse属性にnamを指定し,かつClient .NET構成定義の<nameService>要素を指定します。
ネームサービスを使用したサービス要求の流れを次に示します。
図2-3 ネームサービスを使用したサービス要求の流れ
ネームサービスを使用したRPCでは,サービス要求先スケジューラの情報をネームサーバからキャッシュに格納し,キャッシュの情報を参照してRPCごとにサービス要求先スケジューラを分散させることができます。RPCごとにサービス要求先スケジューラを分散させる場合のClient .NET側,TP1/Server側の関連する定義について説明します。
RPCごとにサービス要求先スケジューラを分散させる場合は,<nameService>要素のloadBalance属性にtrueを指定します。
これによって,Client .NETは,ネームサーバから複数のサービス要求先スケジューラの情報を取得し,負荷レベルが最も低いサービス要求先スケジューラの情報をキャッシュに格納します。キャッシュに格納されるサービス要求先スケジューラは,一つだけではなく,複数の場合もあります。
キャッシュに格納されたサービス要求先スケジューラが複数ある場合,最初のサービス要求先スケジューラは,ランダムに選択されます。RPCでのサービス要求が2度目以降の場合は,サービス要求先スケジューラの情報を取得するためにキャッシュを参照し,RPCごとにラウンドロビン方式でサービス要求先スケジューラを切り替え,分散させます。
次に示すTP1/Server側の定義のオペランドを指定すると,ネームサーバからサービス要求先スケジューラの情報を取得するときに,スケジューラの負荷情報も同時に取得します。
上記の定義の詳細については,マニュアル「OpenTP1 システム定義」を参照してください。
ネームサービスを使用した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を行えます。
スケジューラダイレクト機能を使用すると,RPCの実行時にOpenTP1のネームサービスを使用しないで,直接スケジューラサービスに問い合わせることができます。
スケジューラダイレクト機能を使用したRPCでは,サービスを要求する前にOpenRpcメソッドを呼び出す必要があります。また,CUP.NETの実行の最後にCloseRpcメソッドを呼び出す必要があります。
スケジューラダイレクト機能を使用したRPCの流れと,RPCごとにサービス要求先スケジューラを分散させる場合の定義について説明します。
スケジューラダイレクト機能を使用したRPCを行う場合は,Client .NET構成定義の<rpc>要素のuse属性にscdを指定し,かつClient .NET構成定義の<scheduleService>要素を指定します。
スケジューラダイレクト機能を使用したサービス要求の流れを次に示します。
図2-5 スケジューラダイレクト機能を使用したサービス要求の流れ
スケジューラダイレクト機能を使用したRPCでは,RPCごとにラウンドロビン方式でサービス要求先スケジューラを切り替え,分散させることができます。RPCごとにサービス要求先スケジューラを分散させる場合は,<scheduleService>要素のhostChange属性にtrueを指定してください。
サービス要求を実行するサーバ(通信先のOpenTP1ノード)を明示的に指定してRPCを発行できます。
通信先を指定したRPCでは,サービス要求先のノード(スケジュールサービス)を指定してサービスを要求できます。サービス要求先のノードの状態に関係なく,サービス要求処理は指定したノードで行われます。
通信先を指定したRPCを行う場合は,CallToメソッドを使用します。
なお,このRPCは,リモートAPI機能を使用したRPC,およびクライアントスタブを使用したRPCとの併用はできません。