このセクションでは、次のトピックについて説明します。
Natural RPC 機能によって、クライアント Natural プログラムでサーバー Natural のサブプログラムを呼び出すための CALLNAT ステートメントを発行できるようにします。 Natural クライアントおよびサーバーセッションは、同じまたは異なるコンピュータ上で実行します。 例えば、Windows コンピュータ上の Natural クライアントプログラムは、メインフレームデータベースからデータを取得できるよう、メインフレームサーバーに対して
CALLNAT ステートメントを発行できます。 同じ Windows コンピュータが、サーバーとしての役割を果たすことができます。例えば、UNIX 環境で実行している Natural クライアントプログラムが、このサーバー Natural からデータを要求する
CALLNAT ステートメントを発行する場合です。
Natural RPC は、クライアントサーバーコンピューティングの利点を利用します。 一般的なシナリオでは、Windows クライアントコンピュータ上の Natural が、メインフレームコンピュータ上の Natural のサーバーデータにミドルウェア層を使用してアクセスします。 このことには次の利点があります。
クライアント側のエンドユーザーは、グラフィカルユーザーインターフェイスをが備えられた Natural アプリケーションを使用できます。
大規模データベースには、メインフレームサーバー上でアクセスできます。
クライアントからサーバーに適切なデータだけを送信および返信するときには、ネットワークトラフィックを最小限に押さえることができます。
Natural リモートプロシージャコールには、次の動作モードがあります。
これらのモードについて、以降のセクションで詳しく説明します。 これらのモードの長所および短所の比較については、「会話型モードと非会話型モード」を参照してください。
次のオペレーティングシステム環境下の各種プラットフォーム上で Natural RPC を使用することができます。
z/OS
z/VSE
z/VSE
VM/CMS
BS2000/OSD
メインフレーム上の Natural RPC は、次の TP モニタ環境下でサポートされます。
Com-plete
CICS
IMS/TM
TSO
UTM
また、バッチモードでも有効です。
Windows
UNIX
OpenVMS
これらの全プラットフォーム上で、Natural はクライアントおよびサーバーの両方の役割を果たすことができます。
Natural 以外（3GL および他のプログラミング言語）が、クライアント側およびサーバー側でサポートされます。 Natural 以外のクライアントは Natural RPC サーバーと通信が可能であり、Natural クライアントは Natural 以外の RPC サーバーと通信が可能です。 これらは、EntireX RPC の使用により有効となります。
非会話型モードは、1 パートナーとのデータの単一交換を達成するためにだけ使用します。 「会話型モードと非会話型モード」も参照してください。
ローカルおよびリモートのサブプログラムコールを並行して発行できるようにするため、Natural RPC 技法は Natural ステートメント CALLNAT を使用します。 リモートプログラムコールは同時に動作します。 リモートプロシージャコールでは、CALLNAT は単純に次のルートで通信します。
Natural クライアントから発行された CALLNAT は、ミドルウェア層経由で、クライアントにデータを送り返す Natural サーバーに進みます。
通常、ミドルウェア層は、ACI プロトコルを使用する Software AG 製品 EntireX Broker で構成されています。 EntireX Brokerは、通信層として Entire Net-Work または TCP/IP のいずれかを使用します。
RPC 制御フローの詳細な例について、以降で説明します。
リモートプロシージャでの CALLNAT 制御フローの詳細は、次のとおりです。 より明確にするために戻りパスは示していませんが、説明を参照する番号を示しています。
Natural クライアントから、プログラム PGM1 がサブプログラム SUB1 へ CALLNAT を発行します。 PGM1 は、その CALLNAT がローカルまたはリモート CALLNAT のどちらになるのかは認識しません。
ターゲット SUB1 はサーバー上に存在するため、CALLNAT は代わりにスタブサブプログラム SUB1 にアクセスします。 このクライアントスタブサブプログラムは、自動的に作成されたか、または SYSRPC ユーティリティのスタブ生成機能（SG）を使用して手動で作成されたものです。
スタブはターゲットサブプログラムと同じ名前を持ち、プログラム PGM1 およびサーバー上のターゲットサブプログラム SUB1 で使用されるパラメータと同一のパラメータを含みます。 RPC が内部的に使用する制御情報も含まれています。
AUTORPC プロファイルパラメータが "ON" に設定されており、Natural がローカル環境内でサブプログラムを検出できない場合は、Natural はこのサブプログラムをリモートプロシージャコールであると解釈し、実行中にダイナミックにパラメータデータエリア（PDA）を生成します。
Natural は、サービスディレクトリ NATCLTGS 内でもこのサブプログラムを検出しようとします。
SYSRPC のスタブ生成機能の詳細については、「スタブサブプログラムの作成」を参照してください。
スタブなしで操作する場合は、「Natural RPC 自動実行の操作」を参照してください。
次に、スタブは RPC クライアントサービスルーチンへの CALLLNAT を設定します。
クライアント RPC ランタイムは、サービスディレクトリ NATCLTGS で、どのノードおよびサーバー上で CALLNAT を実行する必要があるか、およびログオンが必要かどうかを確認します。
パラメータリストを含む CALLNAT データおよび必要な場合はログオンデータがミドルウェア層へ渡されます。
この例では、このミドルウェア層は Software AG 製品 EntireX Broker で構成されています。 したがって、CALLNAT データは、最初にクライアント上の EntireX Broker スタブへ渡されます。
EntireX Broker スタブから、CALLNAT データが EntireX Brokerへ 渡されます。 EntireX Broker は、次の環境に配置できます。
クライアントコンピュータ
サーバーコンピュータ
第 3 プラットフォーム
データを正常に送信するには、EntireX Broker で登録されているサーバー SRV1 は EntireX Broker 属性ファイル内に定義され、SRV1 はすでに稼動している必要があります。
EntireX Broker 属性ファイル内のサーバー定義については、EntireX Broker ドキュメントを参照してください。
CALLNAT データは、ミドルウェア層から Natural サーバープラットフォーム上の EntireX Broker スタブへ渡され、そこから RPC サーバーサービスルーチンへ渡されます。
RPC サーバーサービスルーチンは、（存在する場合は）ログオンデータを確認し、（要求された場合は）ログオンを実行します。
RPC サーバーサービスルーチンは、ターゲットサブプログラム SUB1 を呼び出し、要求された場合にデータを渡します。
この時点では、ターゲットサブプログラム SUB1 には、ローカルプログラム PGM1 により呼び出された場合と同じように実行するために必要な全データが含まれています。
その後、例えば、サブプログラム SUB1 はサーバーの Adabas データベースへ FIND ステートメントを発行できます。 SUB1 は、ローカルまたはリモート CALLNAT のいずれで起動されたかは認識しません。
Adabas はデータを検出（FIND）し、そのデータを SUB1 へ渡します。
次に、SUB1 は、Adabas データを呼び出し元のサーバーサービスルーチンに返します。 そこから、データはミドルウェア層を経由して PGM1 に渡されます。 手順 1～8 で説明したルートと同じルートですが、順序は逆です。
会話型 RPC は、クライアントとサーバー間の制限された期間のスタティックな接続です。 クライアントによって定義された数多くのサービス（サブプログラム）を提供します。それらはすべて、会話の期間にクライアントが排他的に利用可能な 1 サーバータスク内で実行されます。
OPEN CONVERSATION ステートメントおよび CLOSE CONVERSATION ステートメントを使用してプログラムに実装されます。
複数接続（会話）は同時に存在可能です。 会話 ID でクライアントによって管理され、それぞれが異なるサーバー上で実行されます。 指定された会話に属さないリモートプロシージャコールは、異なるサーバー上の、異なるサーバータスク内で実行されます。
会話中に、サーバー側のリモートサブプログラム間で、コンテキストエリアと呼ばれるデータエリアを定義して共有できます。 詳細については、Natural『ステートメント』ドキュメントの「Natural RPC 用のコンテキスト変数の定義」を参照してください。
会話はローカルまたはリモートになります。
OPEN CONVERSATION USING SUBPROGRAM 'S1''S2'
CALLNAT 'S1' PARMS1
CALLNAT 'S2' PARMS2
CLOSE CONVERSATION ALL
両方のサブプログラム（S1 および S2）には、同じ場所（ローカルまたはリモート）でアクセスする必要があります。 1 会話内でローカルおよびリモート CALLNAT を混在させることはできません。 サブプログラムがリモートで実行されると、両方のサブプログラムが同じサーバータスクによって実行されます。
非会話型 RPC CALLNAT と同様に、会話は最初にローカルで記述およびテストし、その後サーバーへ転送できます。
サブプログラムをローカルに実行する場合は、次のルールが適用されます。
サブプログラムによって、会話のメンバである別のサブプログラムを呼び出すことはできません。
OPEN CONVERSATION ステートメントにリストされていない他のサブプログラムを呼び出すことはできます。 ただし、それらは非会話型モードで実行されます。
サブプログラムをリモートで実行する場合は、次のルールが適用されます。
サブプログラム S1 によって、会話のメンバである別のサブプログラム S2 を呼び出すことができます。
間接的に呼び出されたため、この CALLNAT は非会話型モードで実行されます。 したがって、サブプログラム S2 はコンテキストエリアへのアクセス権を持ちません。
非会話型モードで複数クライアントが複数サーバーにアクセスするクライアントサーバー環境では、異なるクライアントからの同一の CALLNAT 要求が同じサーバー上で実行されるという問題が発生することがあります。
これは、次のことを意味します。例えば、クライアント 1 からの CALLNAT 'S1' がサーバー 1 上のサブプログラム S1 を実行します。この場合、S1 はデータベースにレコードを書き込みます。 クライアント 1 のトランザクションがまだ完了していない（END TRANSACTION なし）ときに、クライアント 2 もサーバー 1 に CALLNAT 'S1' を送ります。したがって、クライアント 1 からのデータは上書きされます。 その後、クライアント 1 が CALLNAT 'S2'（END TRANSACTION を意味する）を送る場合、クライアント 1 は、実際にはクライアント 2 の同一の CALLNAT からのデータが保存されたにも関わらず、自身のデータが正常に保存されたものと認識します。
次の図に、2 つのクライアントおよび 2 つのサーバーでのこの事象を示します。 このようなシナリオでは、同じサーバー上の同じサブプログラムにアクセスする 2 つの異なるクライアントからの 2 つの同一 CALLNAT は制御できません。
上記の例では、クライアント 1 からの CALLNAT 'S2' は、サーバー 1 およびサーバー 2 のサブプログラム S2 にアクセスする可能性があります。 クライアント 2 からの CALLNAT 'S2' も同じ選択肢を持ちます。
同様に、クライアント 1 からの CALLNAT 'S1' は、サーバー 1 およびサーバー 2 のサブプログラム S1 にアクセスする可能性があり、クライアント 2 からの CALLNAT 'S1' も同じ選択肢を持ちます。
サブプログラムが 1 つのサーバータスクコンテキスト内で実行されるように設計されている場合、インターフェイスが問題となる可能性があることは明白です。
会話型モードでの複雑な RPC トランザクションを定義することによって、非会話型 RPC の潜在的な問題を回避できます。
この処理は、会話を開くことによって実行します。 この処理には、クライアント側での OPEN CONVERSATION ステートメントの使用が含まれ、CALLNAT 'S1' および CALLNAT 'S2' を参照します。 このような会話を開くと、1 つのサーバータスク全体（例：サーバー 1）が確保され、この会話が閉じられる前に、他のリモート CALLNAT がこのサーバー上のこの会話を中断することはありません。 また、DEFINE DATA CONTEXT ステートメントを使用することによって、サーバー側で 2 つのサブプログラムの共通コンテキストエリアを定義できます。
一般ルールとして、次のことが適用されます。
サブプログラムの定義済みリストが 1 コンテキスト内で排他的に実行されることを保証するために、会話型 RPC を使用します。
各サブプログラムが異なるサーバータスク内で使用可能か、またはトランザクションが複数のサーバーコールに展開しない場合に、非会話型 RPC を使用します。 この場合の長所は、長時間に渡るサーバーブロックがなく、比較的少数のサーバータスクのみが必要となることです。
会話型 RPC の短所となりうる点は、サーバータスク全体を確保するため、このサーバー上の他のサブプログラムすべてがブロックされることです。 その結果、他の CALLNAT が必然的に待ち状態になったり、サーバータスクをさらに増やして起動する必要性が出てきます。
クライアント側とサーバー側のデータベーストランザクションは、互いに独立して実行されます。 つまり、サーバー側で実行される END TRANSACTION や BACKOUT TRANSACTION は、クライアント側のデータベーストランザクションに影響せず、逆もまた同様です。
各非会話型 CALLNAT の終了時および各会話の終了時に、暗黙的な BACKOUT TRANSACTION がサーバー側で実行されます。 リモート CALLNAT（複数可）によって行われた変更をコミットするには、次のオプションがあります。
会話型以外の CALLNAT
CALLNAT を終了する前に明示的な END TRANSACTION を実行します。
Natural プロファイルパラメータ ETEOP を "ON" に設定します。 これにより、各非会話型 CALLNAT の終了時に暗黙的な END TRANSACTION が生じます。
会話型 CALLNAT
クライアントが会話を終了する前に、サーバーで明示的な END TRANSACTION を実行します。
Natural プロファイルパラメータ ETEOP を "ON" に設定します。 これにより、各会話の終了時に暗黙的な END TRANSACTION が生じます。
CLOSE CONVERSATION ステートメントを実行する前に、クライアント側でアプリケーションプログラミングインターフェイス USR2032N を呼び出します。 これにより、個々の会話の終了時に暗黙的な END TRANSACTION が生じます。
両方のサブプログラム S1 および S2（上図に表示）には、同じ場所（ローカルまたはリモート）でアクセスする必要があります。 1 会話内にローカルおよびリモートの CALLNAT を混在させることはできません。 サブプログラムがリモートで実行されると、両方のサブプログラムが同じサーバータスクによって実行されます。
次の表は、SYSRPC ユーティリティおよび Natural RPC ドキュメントで使用される重要な用語の概要です。
| 用語 | 説明 |
| クライアントスタブ |
クライアント側で クライアントスタブはローカルサブプログラムであり、このサブプログラムを経由して、サーバーサブプログラムが呼び出されます。 クライアントスタブは、対応するサーバーサブプログラムと同じ名前を持ち、同じパラメータを含みます。 |
| EntireX Broker スタブ | Natural RPC ランタイムと、クライアントおよびサーバー間で整列されたデータを交換する EntireX Broker トランスポート層の間のインターフェイス。 |
| 偽装 | 偽装の前提は、Natural RPC サーバーが実行されているオペレーティングシステムへのアクセスが、SAF 対応の外部セキュリティシステムによって制御されていることです。 ユーザー認証は、この外部セキュリティシステムによって実行されます。 偽装とは、認証が成功してユーザーの識別が確立された後、後続の権限チェックがこの識別に基づいて実行されることを意味します。 このことには、外部リソース（データベースやワークファイルなど）へのアクセスの権限チェックが含まれています。 認証が成功した後、ユーザーは "自分の識別を変更" できません。つまり、異なるユーザー ID を使用できません 。 「Security の使用」の「偽装」を参照してください。 |
NATCLTGS |
サービスディレクトリ（下記参照）を実装するために SYSRPC ユーティリティで生成された Natural サブプログラムの名前。
|
| ノード名 | リモート CALLNAT の送信先であるノードの名前。
例えば、EntireX Broker 経由の通信の場合には、ノード名は EntireX Broker 属性ファイルのフィールド BROKER-ID に定義された EntireX Broker の名前です。 |
| RPC パラメータ |
Natural RPC を制御するために使用できるすべてのパラメータについては、Natural の『パラメータリファレンス』ドキュメントに詳細に記載されています。 「プロファイルパラメータ」セクションを参照してください。 |
SERVDIRX |
サービスディレクトリ（下記参照）を実装するために SYSRPC ユーティリティで生成された XML 形式ファイル（Natural テキストメンバ）の名前。
|
| サービスディレクトリ | サービスディレクトリは、サーバーが提供するサービス（サブプログラム）の情報を含みます。 各クライアントノードからローカルでアクセスできるか、またはリモートディレクトリサーバーに配置されている場合は、プロファイルパラメータ RDS で参照できます。
|
| サーバー名 |
EntireX Broker 経由の通信の場合には、サーバー名は、EntireX Broker 属性ファイルのフィールド SERVER に定義された名前です。 |
| サーバータスク | サービス（サブプログラム）を提供する Natural タスクです。 これは、通常、バッチタスクまたは非同期タスクです。 これはサーバー名で識別されます。 |